VPC Service Controls — Kiến Trúc và Service Perimeter

Tại sao VPC SC quan trọng trong production

IAM là cơ chế kiểm soát truy cập chuẩn của GCP, nhưng nó có một điểm mù cơ bản: IAM kiểm soát danh tính, không kiểm soát ngữ cảnh của request. Nếu một service account với đúng quyền Cloud Storage admin bị xâm phạm và kẻ tấn công sử dụng nó để copy dữ liệu ra khỏi tổ chức, IAM không ngăn được — từ góc nhìn của IAM, đây là một request hợp lệ.

VPC Service Controls giải quyết vấn đề này bằng cách thêm một tầng kiểm tra ngữ cảnh của request: request đến từ network nào, từ project nào, từ địa chỉ IP nào, từ thiết bị nào. Đây là điều mà IAM không làm được — và đây là lý do tại sao VPC SC là primary control để ngăn data exfiltration trong GCP.

Theo Google Cloud documentation, VPC SC "creates a security perimeter around Google Cloud resources to mitigate the risk of data exfiltration." Khác với firewall chặn ở tầng network (L4), VPC SC chặn ở tầng GCP API control plane — tức là trước khi request được Google service xử lý.

Internal Model: VPC SC Enforce Ở Đâu và Thế Nào

Điểm enforce: tầng API, không phải network

Để hiểu VPC SC, cần hiểu rõ nơi nó can thiệp vào request lifecycle. Khi một client gọi gcloud storage cp gs://my-bucket/secret.data /local/path, request này đi qua các bước sau:

Client
  │
  ├─► DNS resolution: storage.googleapis.com
  │
  ├─► TLS handshake với Google servers
  │
  ├─► Authentication (JWT token validation)
  │
  ├─► [VPC SC CHECK] ← Đây là điểm enforce
  │     VPC SC kiểm tra:
  │     - Request đến từ VPC network nào?
  │     - IP address của client là gì?
  │     - Project nguồn và đích có trong cùng perimeter?
  │     - Có access level phù hợp không?
  │
  ├─► IAM Authorization (nếu VPC SC pass)
  │
  └─► Cloud Storage Service xử lý request

Điểm quan trọng: VPC SC không thay đổi gì về networking. Nếu bạn có thể kết nối TCP đến storage.googleapis.com, bạn vẫn kết nối được sau khi bật VPC SC — nhưng request của bạn sẽ bị deny ở tầng API nếu vi phạm policy. Đây là khác biệt cơ bản so với firewall rule.

Google's managed enforcement infrastructure

VPC SC được enforce bởi một component bên trong Google's API infrastructure, không phải bởi bất kỳ VM hay proxy nào mà khách hàng quản lý. Điều này có nghĩa:

1. Zero performance overhead trên data path: Request không đi qua thêm bất kỳ hop nào — VPC SC là một check trong pipeline xử lý của Google API
2. Coverage tự động: Mọi API call đến protected service đều được check — không có cách nào "bypass" qua một route khác
3. Không cần agent: Không cần cài đặt gì trên VM hay node

Access Policy — Container cho VPC SC configuration

Trước khi tạo service perimeter, phải có một access policy. Access policy là tài nguyên ở tầng organization hoặc folder chứa toàn bộ VPC SC configuration:

Organization (google.com)
└── Access Policy (accessPolicies/1234567890)
    ├── Access Levels (conditions cho phép access)
    │   ├── corp-network (IP range 10.0.0.0/8)
    │   └── trusted-device (Endpoint Verification)
    └── Service Perimeters
        ├── production-perimeter
        └── data-perimeter

Mỗi organization thường chỉ có một access policy ở cấp organization. Ngoài ra còn có scoped policies — access policies được gán cho folder hoặc project cụ thể, cho phép phân quyền quản trị VPC SC xuống các team con.

Một điểm quan trọng: access levels được định nghĩa trong access policy và có thể được tái sử dụng bởi nhiều service perimeter khác nhau trong cùng policy.

Service Perimeter — Ranh Giới Bảo Mật Thực Sự

Perimeter là gì?

Service perimeter là ranh giới logic xác định tập hợp Google Cloud projects (hoặc VPC networks) và các Google services được bảo vệ. Khi một project nằm trong perimeter:

• Inbound: Request từ bên ngoài perimeter đến resources bên trong bị blocked by default, trừ khi được cho phép bởi ingress rules hoặc access levels
• Outbound: Request từ bên trong perimeter đến resources bên ngoài bị blocked by default, trừ khi được cho phép bởi egress rules

┌────────────────────────────────────────────────────────────┐
│                      Service Perimeter                     │
│                                                            │
│  ┌──────────────┐    ┌──────────────┐    ┌─────────────┐  │
│  │  Project A   │    │  Project B   │    │  Project C  │  │
│  │  (BigQuery)  │◄──►│  (Dataflow)  │◄──►│ (Cloud GCS) │  │
│  └──────────────┘    └──────────────┘    └─────────────┘  │
│          ▲                                      ▲          │
│          │ Protected services:                  │          │
│          └──── BigQuery, GCS, Cloud SQL ────────┘          │
└────────────────────┬───────────────────────────────────────┘
                     │
              VPC SC checks all
              cross-perimeter requests
                     │
         ┌───────────▼───────────┐
         │   External request    │
         │  (bị block by default)│
         └───────────────────────┘

Hai loại perimeter

Regular perimeter là loại phổ biến nhất. Nó bảo vệ projects và services bên trong, blocking tất cả cross-perimeter traffic không được authorize.

Bridge perimeter là một loại perimeter đặc biệt không bảo vệ resources mà chỉ cho phép hai regular perimeters giao tiếp với nhau. Google khuyến nghị hạn chế dùng bridges vì chúng làm phức tạp topology và tăng khó khăn trong debugging. Thay vào đó, nên dùng ingress/egress rules cho cross-perimeter access.

Protected resources: dạng project và VPC network

Perimeter có thể bảo vệ theo hai cách:

Project-level protection: Thêm toàn bộ Google Cloud project vào perimeter. Tất cả resources trong project đó đều được bảo vệ bởi các services đã được enable trên perimeter.

VPC network-level protection: Thêm VPC network cụ thể vào perimeter. Chỉ traffic đến/từ VPC network đó mới bị check bởi VPC SC — các VM trong VPC đó khi gọi protected services sẽ được kiểm tra context (có phải từ within perimeter không).

Sự khác biệt quan trọng: khi bảo vệ theo VPC network, một project có thể có nhiều VPC networks, và chỉ VPC network được liệt kê mới được coi là "bên trong perimeter". Điều này cho phép architecture phức tạp hơn nơi một project vừa có VPC trong perimeter lẫn VPC ngoài perimeter.

Protected services — danh sách services được enforce

Không phải mọi Google Cloud service đều được VPC SC bảo vệ. Danh sách các services hỗ trợ VPC SC (Supported products and limitations) rất dài và không ngừng mở rộng.

Các services quan trọng nhất trong danh sách:

Service	Use case chính
storage.googleapis.com	Cloud Storage — ngăn exfiltration data ra bucket ngoài
bigquery.googleapis.com	BigQuery — ngăn query data ra project ngoài
sqladmin.googleapis.com	Cloud SQL — bảo vệ database access
secretmanager.googleapis.com	Secret Manager — bảo vệ secrets
cloudkms.googleapis.com	Cloud KMS — bảo vệ cryptographic keys
container.googleapis.com	GKE control plane API
artifactregistry.googleapis.com	Artifact Registry

Khi cấu hình perimeter, bạn có thể chọn restrict tất cả supported services hoặc chỉ restrict một danh sách cụ thể. Google khuyến nghị restrict tất cả supported services để tối thiểu hóa attack surface.

Restricted VIP — Cơ Chế Truy Cập Private

Tại sao cần restricted VIP?

Khi VM trong VPC (không có internet access) cần gọi Google APIs, traffic đi qua Private Google Access. Có hai endpoint:

• private.googleapis.com → 199.36.153.8/30 — cho phép truy cập tất cả Google APIs
• restricted.googleapis.com → 199.36.153.4/30 — chỉ cho phép truy cập các Google APIs hỗ trợ VPC SC

Điểm mấu chốt của restricted.googleapis.com: dải IP 199.36.153.4/30 không được quảng bá ra internet. Nghĩa là:

1. VM trong VPC có thể route đến 199.36.153.4/30 qua Private Google Access
2. Client từ internet không thể trực tiếp reach 199.36.153.4/30
3. Nếu một kẻ tấn công bằng cách nào đó exfiltrate data qua một service, họ không thể redirect traffic qua restricted.googleapis.com từ internet

Tại sao phải dùng restricted.googleapis.com trong môi trường VPC SC?

Nếu dùng private.googleapis.com thay vì restricted.googleapis.com, VM trong perimeter vẫn có thể truy cập các Google services không hỗ trợ VPC SC — và VPC SC không check những service đó. Điều này tạo ra một "lỗ hổng" trong perimeter: data có thể bị exfiltrate qua các services không được bảo vệ.

# Cấu hình DNS đúng trong VPC trong perimeter:
# DNS phải resolve storage.googleapis.com về 199.36.153.4/30

# Private zone trong Cloud DNS:
# googleapis.com → 199.36.153.4 (CNAME về restricted.googleapis.com)

# Route trong VPC:
# 199.36.153.4/30 → default-internet-gateway (hoặc Cloud Router)

Đây là lý do tại sao khi thiết lập VPC SC, cần phải đồng thời cấu hình:

1. DNS để resolve *.googleapis.com về restricted VIP
2. VPC route cho 199.36.153.4/30
3. Firewall rules cho phép egress đến 199.36.153.4/30

Perimeter Enforcement Model — Cơ Chế Đánh Giá Request

Khi một request đến VPC SC checkpoint, hệ thống đánh giá theo flow sau:

Request đến
    │
    ├─── Nguồn và đích có trong cùng perimeter? → YES → Allowed (free communication)
    │
    ├─── Nguồn BÊN TRONG, đích BÊN NGOÀI?
    │         └── Có egress rule phù hợp? → YES → Allowed
    │                                     → NO  → DENIED
    │
    ├─── Nguồn BÊN NGOÀI, đích BÊN TRONG?
    │         ├── Có access level phù hợp? → YES → Allowed
    │         └── Có ingress rule phù hợp? → YES → Allowed
    │                                      → NO  → DENIED
    │
    └─── Không match bất kỳ rule nào → DENIED (default deny)

Nguyên tắc default deny là cốt lõi của VPC SC: không có exception ngầm định, không có "implicit allow" dựa trên network topology. Mọi cross-perimeter access phải được explicitly authorize.

Mối quan hệ VPC SC và IAM

VPC SC và IAM đều phải pass — chúng không thay thế nhau:

Request → [VPC SC Check] → [IAM Check] → Service

Nếu VPC SC DENY: request bị block, IAM không được kiểm tra
Nếu VPC SC ALLOW + IAM DENY: request bị block ở IAM
Nếu VPC SC ALLOW + IAM ALLOW: request được xử lý

Khi VPC SC deny một request, error message trả về là HTTP 403 với body chứa:

{
  "error": {
    "code": 403,
    "message": "Request is prohibited by organization's policy.",
    "status": "PERMISSION_DENIED",
    "details": [...]
  }
}

Error này trông giống IAM permission denied nhưng khác về nguyên nhân — và đây là một trong những nguồn confusion phổ biến khi troubleshooting.

Giới Hạn Kỹ Thuật Cần Biết

Supported services chỉ là một phần: Không phải mọi GCP service đều có VPC SC support. Nếu bạn rely on một service chưa được hỗ trợ, bạn không thể include nó trong perimeter.

Perimeter enforcement không retroactive: Khi add một project vào perimeter, các resources đang tồn tại không bị tự động kiểm tra cho đến khi có request mới.

Service account impersonation: Nếu một service account bên ngoài perimeter impersonate một service account bên trong, request vẫn được evaluate theo context của caller gốc (bên ngoài), không phải context của service account bị impersonate.

Shared VPC requirement: Khi project thuộc Shared VPC, phải include cả host project lẫn service projects vào perimeter. Nếu chỉ include service project mà thiếu host project, VPC SC không thể correctly evaluate network context.

Eventual consistency: Thay đổi trong perimeter configuration không được apply ngay lập tức trên toàn bộ infrastructure của Google. Thời gian propagation có thể lên đến vài phút.

References

• VPC Service Controls Overview
• Service Perimeters Details and Configuration
• Supported Products and Limitations
• Design and Architect Service Perimeters
• Private Google Access and VPC SC