Skip to content

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

FileNội dung
Kiến Trúc VPC SC & Service PerimeterTại sao VPC SC enforce ở API layer, access policy, perimeter types, restricted VIP
Access Levels & Context-Aware AccessBasic access levels (IP/geo/device), custom access levels với CEL, tích hợp VPC SC
Ingress & Egress Rules — Cross-Perimeter AccessCấu trúc rule, ingressFrom/ingressTo, egressFrom/egressTo, use cases
Dry-Run Mode — Test Trước Khi EnforceCơ chế shadow enforcement, audit log, workflow triển khai an toàn
Organization Policy Framework & InheritanceConstraint 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 ViolationsVPC 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.