Chương 33: VPC Service Controls & Organization Policies
Tại sao chương này quan trọng
Trong hầu hết các triển khai GCP production, IAM kiểm soát ai có quyền làm gì. Nhưng IAM không trả lời được câu hỏi: nếu một service account bị xâm phạm, hay nếu có một đường lách từ bên ngoài perimeter tổ chức vào để đọc dữ liệu nhạy cảm thì sao? Đây là vấn đề mà VPC Service Controls (VPC SC) được xây dựng để giải quyết.
VPC SC không phải firewall — nó hoạt động ở tầng API control plane, không phải tầng network. Khi một request gọi vào Cloud Storage API, Cloud SQL API, hay BigQuery API, VPC SC chặn request đó trước khi request đến service, ngay tại tầng kiểm tra của Google. Đây là điểm khác biệt cơ bản: bạn không cần cấu hình network rule hay security group — bạn đang đặt ranh giới bảo mật tại tầng mà dữ liệu thực sự di chuyển — tầng Google API.
Organization Policies bổ sung một cơ chế phòng thủ khác, hoạt động theo hướng ngược lại: thay vì chặn request từ bên ngoài vào, Org Policies ràng buộc hành vi tạo và cấu hình tài nguyên bên trong tổ chức. Bạn không muốn ai đó vô tình tạo VM với external IP? Không muốn GKE node pool tắt auto-upgrade? Đây là công việc của Org Policy.
Hai cơ chế này là defense in depth ở tầng GCP control plane — không thay thế IAM mà bổ sung cho nó từ các góc độ mà IAM không cover được.
Điều kiện tiên quyết
- Hiểu IAM policy model và resource hierarchy (Chương 1, 31)
- Nắm vững VPC networking fundamentals (Chương 3)
- Quen với Cloud Audit Logs
Cấu trúc chapter
| File | Nội dung |
|---|---|
| Kiến Trúc VPC SC & Service Perimeter | Tại sao VPC SC enforce ở API layer, access policy, perimeter types, restricted VIP |
| Access Levels & Context-Aware Access | Basic access levels (IP/geo/device), custom access levels với CEL, tích hợp VPC SC |
| Ingress & Egress Rules — Cross-Perimeter Access | Cấu trúc rule, ingressFrom/ingressTo, egressFrom/egressTo, use cases |
| Dry-Run Mode — Test Trước Khi Enforce | Cơ chế shadow enforcement, audit log, workflow triển khai an toàn |
| Organization Policy Framework & Inheritance | Constraint framework, policy inheritance, merge semantics, exceptions với tags |
| Custom Constraints & CEL Expressions | Định nghĩa custom constraint YAML, CEL syntax, ví dụ thực tế |
| Policy Troubleshooter & Debugging Violations | VPC SC violation analyzer, audit log format, Org Policy debug workflow |
Mental model cốt lõi
Có ba tầng kiểm soát trực giao nhau trong GCP:
┌─────────────────────────────────────────────────────────────┐
│ REQUEST ĐẾN GCP API │
└──────────────────────────┬──────────────────────────────────┘
│
┌────────────▼────────────┐
│ Organization Policy │ ← Tầng 1: Guardrail
│ (Hành vi tài nguyên) │ tổ chức — ràng buộc
└────────────┬────────────┘ configuration
│
┌────────────▼────────────┐
│ VPC Service Controls │ ← Tầng 2: Perimeter
│ (API access boundary) │ chống data exfiltration
└────────────┬────────────┘
│
┌────────────▼────────────┐
│ IAM │ ← Tầng 3: Identity &
│ (Who can do what) │ permission check
└────────────┬────────────┘
│
┌────────────▼────────────┐
│ SERVICE API │
└─────────────────────────┘Mỗi tầng hoạt động độc lập và xử lý các loại rủi ro khác nhau:
- Organization Policy: "Liệu tài nguyên này có được phép tồn tại với cấu hình này không?" — ngăn misconfiguration
- VPC Service Controls: "Liệu request này có đến từ một nguồn đáng tin cậy không?" — ngăn data exfiltration
- IAM: "Liệu danh tính này có quyền thực hiện operation này không?" — access control
Một tổ chức bảo mật tốt cần cả ba.