VPC Service Controls — Perimeter API & Chống Data Exfiltration
Tại sao quan trọng trong production
Hãy xem xét một attack scenario: attacker đánh cắp OAuth token hoặc service account key của một user trong organization. Token này valid theo IAM — attacker có đầy đủ permissions của user đó. Họ chạy:
gcloud storage cp gs://sensitive-bucket/database-dump.csv /tmp/IAM check: pass — token hợp lệ, user có Storage Object Viewer. Firewall check: không áp dụng — đây là API call đến Google API endpoint, không phải TCP connection giữa VMs.
Kết quả: data exfiltration thành công mặc dù có đầy đủ IAM và firewall configuration.
VPC Service Controls (VPC-SC) được thiết kế để chặn chính xác scenario này. Nó không phải firewall — nó là một API access boundary enforce ở GCP control plane, tách biệt hoàn toàn với IAM và network firewall. Ngay cả với credentials hợp lệ, một request từ ngoài perimeter đến service được protected sẽ bị deny ở tầng API.
Internal Model — Cơ Chế Hoạt Động Bên Trong
VPC-SC không phải firewall, không phải IAM
Mental model quan trọng nhất: VPC-SC là một lớp access control thứ ba, trực giao với IAM và firewall.
Request đến GCP API
│
▼
┌─────────────────────────────────┐
│ VPC Service Controls Perimeter │ ← kiểm tra: request từ đâu?
│ (network/identity context) │
└─────────────────┬───────────────┘
│ (pass)
▼
┌─────────────────────────────────┐
│ IAM │ ← kiểm tra: có quyền không?
│ (identity/resource permission) │
└─────────────────┬───────────────┘
│ (allow)
▼
Truy cập resourceCả hai lớp phải pass. Có IAM permission không có nghĩa là có VPC-SC access. Ngược lại, ở trong perimeter không có nghĩa là có IAM permission.
Enforce tại GCP API layer
VPC-SC enforce tại Google's API infrastructure — cùng nơi IAM check xảy ra. Khi request đến API endpoint (ví dụ: storage.googleapis.com), Google's backend kiểm tra:
- Request này đến từ trong một perimeter không?
- Service được requested có nằm trong perimeter không?
- Nếu cross-perimeter, có ingress/egress rule nào cho phép không?
Enforcement point này là ở tầng control plane, trước khi request đến actual storage backend. Không có network path nào bypass được — ngay cả traffic qua Cloud Interconnect hay VPN đến GCP cũng phải pass VPC-SC kiểm tra trước khi access Google APIs.
Service Perimeter
Service perimeter là đơn vị cơ bản của VPC-SC. Nó define:
- Protected projects: danh sách GCP projects nằm bên trong perimeter
- Restricted services: danh sách Google APIs bị protect (Cloud Storage, BigQuery, Pub/Sub, v.v.)
Khi một service được thêm vào restricted services list của perimeter:
- Tất cả API requests đến service đó trong protected projects phải đến từ trong perimeter
- Tất cả API requests từ service đó ra ngoài perimeter bị block theo mặc định
┌────────────────────────────────────────────────────────┐
│ Service Perimeter "finance-perimeter" │
│ │
│ Protected Projects: [finance-prod, finance-analytics] │
│ Restricted Services: [BigQuery, Cloud Storage, KMS] │
│ │
│ Project: finance-prod │
│ ┌──────────────────────────────────────────────────┐ │
│ │ BigQuery Dataset: customer_data │ │
│ │ GCS Bucket: sensitive-reports │ │
│ └──────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────┘
▲ ▲
│ Blocked by default │ Allowed (same perimeter)
(Outside access) (Inside perimeter access)Access Levels — Context-Aware Authorization
Access Levels là cơ chế cho phép access vào perimeter từ bên ngoài, dựa trên context của request (không phải chỉ identity). Một Access Level là một tập hợp điều kiện:
- IP ranges: chỉ allow từ corporate office IP ranges
- Device policies: chỉ devices đã enrolled trong enterprise MDM
- Identity: chỉ specific users hoặc service accounts
- Geolocation: chỉ từ specific countries
Ví dụ: Access Level "corporate-office-access":
conditions:
- ipSubnetworks:
- "192.168.1.0/24" # Office network
- "10.0.0.0/8" # Internal VPN
devicePolicy:
requireScreenLock: true
requireAdminApproval: trueKhi user truy cập protected service từ office network (IP 192.168.1.x) với device đã comply policy, Access Level match và access được granted.
Ingress và Egress Rules — Cross-Perimeter Access
Trong thực tế production, không phải tất cả access đều từ trong perimeter. Có các legitimate cross-perimeter use cases:
Ingress Rules: cho phép traffic vào perimeter từ bên ngoài.
ingressPolicies:
- ingressFrom:
sources:
- accessLevel: "accessPolicies/ACCESS_POLICY_ID/accessLevels/corporate-access"
- resource: "projects/external-analytics-project"
identities:
- "serviceAccount:etl-sa@external-project.iam.gserviceaccount.com"
ingressTo:
resources:
- "projects/finance-prod"
operations:
- serviceName: "bigquery.googleapis.com"
methodSelectors:
- method: "BigQueryService.GetTable"
- method: "BigQueryService.ListTables"Egress Rules: cho phép traffic ra khỏi perimeter.
egressPolicies:
- egressFrom:
identities:
- "serviceAccount:dataflow-sa@finance-prod.iam.gserviceaccount.com"
egressTo:
resources:
- "projects/shared-artifacts-project"
operations:
- serviceName: "artifactregistry.googleapis.com"Ingress/Egress rules cung cấp granularity cao hơn Perimeter Bridges (cơ chế cũ cho phép two-way communication giữa hai perimeters).
Restricted VIP và Private VIP
VPC-SC cung cấp hai loại virtual IP cho Google API access:
Restricted VIP (199.36.153.4/30):
- Chỉ cho phép requests đến services được bảo vệ bởi VPC-SC
- Requests đến services không hỗ trợ VPC-SC qua Restricted VIP sẽ bị fail
- Dùng để enforce rằng tất cả requests phải đi qua perimeter path
Private VIP (199.36.153.8/30):
- Cho phép requests đến tất cả Google APIs (cả VPC-SC protected và không)
- Không enforce VPC-SC restriction
- Dùng khi cần access một mix của services, cả protected và unprotected
Best practice cho environments cần data exfiltration prevention: dùng Restricted VIP và đảm bảo firewall rules block traffic ra 199.36.153.8/30 (Private VIP) để ngăn bypass.
Data Exfiltration Prevention — Scenarios Thực Tế
Scenario 1: Stolen credentials từ internet
Attacker có OAuth token của user nội bộ, thử access từ external IP.
VPC-SC check: IP không trong Access Level nào → request denied ngay cả khi credentials valid.
Scenario 2: Malicious insider copy data ra project khác
Insider dùng gcloud storage cp gs://finance-bucket/data.csv gs://personal-bucket/:
VPC-SC check:
gs://finance-buckettrong protected project → egress checkgs://personal-buckettrong project ngoài perimeter → không có egress rule allow- Request denied: "Request violates VPC Service Controls"
Scenario 3: Compromised VM exfiltrate qua BigQuery export
VM bị compromise chạy BigQuery extract job để export data ra GCS bucket ngoài perimeter:
VPC-SC check:
- VM trong perimeter, nhưng destination GCS bucket ngoài perimeter
bq extractcommand calls BigQuery API với destination ngoài perimeter → denied
Scenario 4: Phishing với service account key
SA key bị leak, attacker dùng từ máy cá nhân:
VPC-SC check:
- SA identity hợp lệ (IAM pass)
- Source IP không trong Access Level → denied
Dry-Run Mode — Test Trước Khi Enforce
VPC-SC có thể operate trong dry-run mode (còn gọi là simulation mode). Trong dry-run, perimeter evaluate tất cả requests nhưng không actually deny — thay vào đó ghi log violations vào Cloud Logging.
# Chuyển perimeter sang dry-run
gcloud access-context-manager perimeters dry-run update PERIMETER \
--restricted-services=bigquery.googleapis.com,storage.googleapis.comDry-run log xuất hiện trong Cloud Logging với google.identity.accesscontextmanager.v1.ServicePerimeterViolation.
Workflow recommended:
- Deploy perimeter trong dry-run mode
- Chờ 1-2 tuần để observe traffic patterns
- Phân tích violations — add necessary ingress/egress rules
- Verify không còn unexpected violations
- Switch sang enforce mode
Bỏ qua dry-run là nguyên nhân phổ biến nhất gây outage khi deploy VPC-SC lần đầu — các service dependencies không được expect thường bị miss.
Constraints & Điểm Mù
Unsupported services
Không phải tất cả Google services đều hỗ trợ VPC-SC. Services không trong danh sách supported có thể behave unexpectedly khi project của chúng nằm trong perimeter và chúng access protected services.
Theo GCP documentation: "Unexpected issues might occur when unsupported services attempt accessing protected resource data within the same project."
Trước khi add một service vào perimeter, kiểm tra xem tất cả services trong project đó có supported không.
Metadata vs Data
VPC-SC bảo vệ data access, không phải metadata access. Ví dụ:
- List tên các buckets trong project: không được protect (metadata)
- Đọc content của bucket: được protect (data)
IAM phải đảm bảo metadata cũng được protect đúng cách.
Không phải tất cả lateral movement được chặn
VPC-SC chặn cross-perimeter API access. Nhưng lateral movement trong perimeter vẫn có thể xảy ra. Nếu VM A và VM B cùng trong một perimeter, VM A vẫn có thể gọi VM B qua HTTP hay gRPC không qua Google APIs.
VPC-SC không thay thế firewall rules cho east-west traffic — nó complement firewall rules bằng cách control API access.
Perimeter bridges (legacy)
Perimeter bridges là cơ chế cũ cho phép hai perimeters communicate. Ingress/Egress rules mới granular hơn và được recommend thay thế. Bridges nên được migrate dần.
Khi Nào Nên Dùng VPC-SC
VPC-SC có chi phí vận hành đáng kể (cấu hình phức tạp, maintenance, risk outage khi không cẩn thận). Chỉ nên deploy khi:
- Compliance yêu cầu: HIPAA, PCI-DSS, SOC 2, FedRAMP thường require data access controls vượt ra ngoài IAM
- Dữ liệu extremely sensitive: PII, financial records, trade secrets — nơi credential theft là threat model thực sự
- Multi-tenant environments: nhiều teams/customers share GCP organization, cần isolation giữa các tenants
- Regulated industries: tài chính, healthcare — nơi auditors expect rõ ràng về boundary
Không phải mọi GCP deployment cần VPC-SC. Cho startup hay environments không có compliance requirement và không có extremely sensitive data, complexity của VPC-SC có thể không worth it.