# Syllabus GCP Security

## Giai đoạn 0: Nền tảng bắt buộc

1.  **Resource hierarchy thật của tổ chức**
    
    *   Organization → Folder → Project → Resource, cách policy inheritance hoạt động (deny > allow, closest wins cho org policy).
        
    *   Terraform/IaC cho toàn bộ hierarchy (không click tay trên Console ở production).
        
    *   Lab: dựng 1 org giả (hoặc dùng GCP free tier) với 3 folder (prod/staging/dev), viết bằng Terraform.
        
2.  **Landing Zone/Cloud Foundation**
    
    *   Google Cloud's "Enterprise Foundations Blueprint" - đọc và tự triển khai thu nhỏ.
        
    *   Hiểu vì sao mọi công ty lớn đều bắt đầu bằng landing zone trước khi cho dev vào.
        
3.  **IAM cơ bản nhưng đúng cách production dùng**
    
    *   Predefined role vs custom role - production luôn ưu tiên predefined + deny policy, hạn chế custom role tràn lan (khó audit).
        
    *   Nguyên tắc "principal set" - Google Group làm đơn vị cấp quyền, KHÔNG cấp trực tiếp cho user.
        

**Sai lầm thường gặp trong production**: cấp `roles/owner` cho service account "để cho dễ", quên rằng org policy chỉ áp dụng từ điểm cấu hình trở xuống (không hồi tố resource cũ).

## Giai đoạn 1: Configuring Access (Identity, Service Account, Auth, Authorization)

### 1.1 Identity & Federation

*   **Workforce Identity Federation** là hướng chính hiện nay (không cần đồng bộ identity vào Google). GCDS chỉ nên xem là "legacy integration" cho tổ chức còn AD on-prem thuần - học khái niệm là đủ, không cần đào sâu.
    
*   SSO với Okta/Azure AD/Ping - thực hành cấu hình SAML thật, không chỉ đọc lý thuyết.
    
*   Lab: dựng Workforce Identity Federation pool + provider, test login bằng external IdP thật (Okta free trial).
    

### 1.2 Service Account

*   **Không dùng SA key** (JSON key) trong production trừ khi bắt buộc (on-prem/multi-cloud) → dùng **Workload Identity Federation**.
    
*   Nếu buộc dùng key: rotate tự động, org policy `iam.disableServiceAccountKeyCreation`, giám sát bằng Cloud Audit Logs.
    
*   Short-lived credentials, impersonation (`roles/iam.serviceAccountTokenCreator`) thay vì phát key.
    
*   Lab:
    
    *   Thiết lập Workload Identity Federation cho GitHub Actions deploy vào GCP (không key).
        
    *   Viết detection rule (Cloud Logging + Security Command Center) phát hiện khi có SA key mới được tạo ngoài whitelist.
        

### 1.3 Authentication

*   Session/password policy, bắt buộc 2FA (Security Key ưu tiên hơn OTP cho admin).
    
*   OAuth consent screen, scope tối thiểu cho 3rd-party app.
    

### 1.4 Authorization

*   **IAM Conditions**: cấp quyền theo thời gian, IP, resource tag.
    
*   **IAM Deny Policy**: chặn cứng bất kể allow policy nào (dùng cho break-glass exception, chặn SA thoát ra ngoài org).
    
*   **Policy Intelligence** (Policy Analyzer, IAM Recommender, Policy Troubleshooter) - dùng để dọn quyền thừa định kỳ, không phải chỉ set 1 lần.
    
*   **Privileged Access Manager (PAM)**: cấp quyền admin tạm thời, có approval workflow, tự hết hạn.
    
*   Lab: cấu hình PAM cho 1 role nhạy cảm (BigQuery Admin), yêu cầu approval 2 người, tự thu hồi sau 1 giờ.
    

### 1.5 Cloud Asset Inventory

*   Dùng để trả lời câu hỏi mọi SOC/security team đều cần: "resource nào đang public? SA nào có quyền gì trên toàn org?"
    
*   Asset search (`gcloud asset search-all-resources`, `search-all-iam-policies`), inventory export định kỳ ra BigQuery, policy analysis, drift detection (so sánh state hiện tại vs baseline Terraform).
    
*   Lab: viết script/Cloud Function chạy định kỳ, tìm toàn bộ resource có `allUsers`/`allAuthenticatedUsers` trên toàn org, cảnh báo nếu phát hiện mới.
    

**Sai lầm thường gặp trong production**: dùng IAM Recommender rồi apply thẳng không review (có thể phá workflow đang chạy); quên rằng basic role (Owner/Editor/Viewer) không nên tồn tại ở project prod; không có Asset Inventory nên không biết mình đang "public" cái gì cho tới khi bị scan bởi bên ngoài.

## Giai đoạn 2: Organization Policy

Production GCP Security phụ thuộc rất nhiều vào Org Policy - đây là lớp "guardrail" áp dụng cho toàn bộ org/folder, không cần con người nhớ để tuân thủ.

### 2.1 Các constraint quan trọng

*   `iam.disableServiceAccountKeyCreation` - chặn tạo SA key.
    
*   `compute.vmExternalIpAccess`/`compute.restrictVpcPeering` - chặn external IP không kiểm soát.
    
*   `gcp.resourceLocations` - giới hạn khu vực địa lý (data residency).
    
*   `iam.allowedPolicyMemberDomains` (Domain Restricted Sharing) - chặn share resource ra ngoài domain tổ chức.
    
*   `compute.trustedImageProjects` - chỉ cho phép boot từ image đã duyệt.
    
*   `gcp.requireCMEK...` (theo từng service) - bắt buộc CMEK cho dữ liệu nhạy cảm.
    
*   `iam.disableServiceAccountCreation`, `sql.restrictPublicIp`, `compute.requireOsLogin`.
    

### 2.2 Custom Org Policy

*   Viết constraint riêng khi predefined không đủ (dùng CEL - Common Expression Language).
    

### 2.3 Vận hành

*   Baseline policy nên set ở **org level**, exception có kiểm soát ở folder/project level (không set ngược lại).
    
*   Test bằng **dry-run** trước khi enforce toàn org (đặc biệt với constraint có thể phá pipeline đang chạy).
    

**Lab**: xây 1 bộ org policy baseline hoàn chỉnh bằng Terraform cho org giả (10+ constraint ở trên), áp dụng, rồi thử tạo resource vi phạm để xác nhận bị chặn.

**Sai lầm thường gặp trong production**: enforce `iam.disableServiceAccountKeyCreation` toàn org ngay lập tức mà không audit trước workload nào đang phụ thuộc key → gãy pipeline; đặt exception ở project level nhưng quên document lý do, 1 năm sau không ai nhớ tại sao có exception đó.

## Giai đoạn 3: Network Security & Boundary Protection

### 3.1 Perimeter

*   Cloud NGFW (hierarchical firewall policy ở org/folder, không chỉ VPC firewall rule rời rạc).
    
*   IAP thay cho VPN/bastion truyền thống cho SSH/RDP - production hiện đại gần như luôn dùng IAP.
    
*   Cloud Armor (WAF) - cấu hình rule thật chống OWASP Top 10, rate limiting, adaptive protection.
    
*   Lab: dựng 1 web app sau HTTPS LB + Cloud Armor, thử tấn công SQLi/XSS giả lập để xem rule chặn.
    

### 3.2 Segmentation

*   Shared VPC (host project/service project) - mô hình chuẩn cho tổ chức nhiều team.
    
*   **VPC Service Controls (VPC-SC)** - phần khó nhất, hay bị bỏ qua khi học thi nhưng cực quan trọng ở production để chống data exfiltration.
    
*   Lab: dựng perimeter VPC-SC quanh 1 project chứa dữ liệu nhạy cảm, thử export dữ liệu ra ngoài để xác nhận bị chặn, rồi cấu hình ingress/egress rule để mở đúng luồng cần thiết.
    

### 3.3 Private Connectivity

*   Private Google Access, Private Service Connect, Cloud NAT.
    
*   HA VPN/Interconnect cho hybrid - hiểu khi nào dùng cái nào (băng thông, SLA, chi phí).
    

**Sai lầm thường gặp trong production**: bật VPC-SC cho toàn bộ org ngay lập tức làm sập pipeline CI/CD đang cần gọi API xuyên project - luôn dùng **dry-run mode** trước.

## Giai đoạn 4: Data Protection

*   **Sensitive Data Protection (DLP)**: inspect + de-identify PII trong BigQuery/Cloud Storage, pseudonymization, format-preserving encryption - thực hành trên dataset giả có PII.
    
*   **CMEK vs EKM vs Google-managed**: quyết định dựa trên yêu cầu compliance (ai giữ key, khả năng thu hồi key tức thời).
    
*   **Confidential Computing**: khi nào cần (dữ liệu nhạy cảm xử lý trong bộ nhớ, multi-party computation, quy định ngành).
    
*   **Secret Manager**: rotate tự động, IAM binding theo least privilege, không bao giờ để secret trong biến môi trường tĩnh hoặc code.
    
*   **Securing AI workloads**: kiểm soát truy cập model/dataset training, bảo vệ Gemini Enterprise/Agent Platform khỏi prompt injection, data leakage qua agent có quyền truy cập công cụ ngoài.
    
    *   Lab: build 1 agent demo dùng Gemini + tool-calling, thử prompt injection để rò rỉ secret, sau đó áp guardrail.
        

**Sai lầm thường gặp trong production**: bật CMEK nhưng không có quy trình backup/rotate key rõ ràng → mất key = mất dữ liệu vĩnh viễn.

## Giai đoạn 5: GKE & Container Security

GKE/Cloud Run chiếm tỷ trọng rất lớn trong production GCP hiện nay; đây là khoảng trống lớn nhất của syllabus gốc.

### 5.1 Cluster Hardening

*   Private cluster (không có node có public IP), authorized network cho control plane.
    
*   Shielded GKE Nodes (chống rootkit/bootkit ở tầng node).
    
*   Binary Authorization - chỉ cho phép deploy image đã ký, đã qua attestation.
    

### 5.2 Workload Security

*   Workload Identity (GKE) - SA cho pod không dùng key, ánh xạ KSA ↔ GSA.
    
*   Pod Security Standards (thay thế PodSecurityPolicy đã deprecated) - baseline/restricted profile.
    
*   Security Context: chạy non-root, read-only root filesystem, drop capabilities.
    
*   seccomp/AppArmor profile để giới hạn syscall.
    

### 5.3 Supply Chain cho container

*   Artifact Registry + vulnerability scanning tự động.
    
*   SBOM (Software Bill of Materials) sinh tự động trong CI.
    
*   SLSA framework (mức độ đảm bảo chuỗi cung ứng).
    
*   Cosign - ký và verify image trước khi deploy (kết hợp Binary Authorization).
    

### 5.4 Runtime Protection

*   Container Threat Detection (SCC) - phát hiện hành vi bất thường trong container đang chạy (reverse shell, added binary, unexpected outbound).
    
*   Falco (nếu không dùng GKE Enterprise/Autopilot có sẵn) cho runtime detection tuỳ chỉnh.
    
*   SCC runtime signals tích hợp vào detection pipeline chung (Giai đoạn 7).
    

### 5.5 Multi-cluster/Fleet

*   GKE Fleet để quản lý policy tập trung nhiều cluster.
    
*   Anthos Policy Controller (dựa trên OPA/Gatekeeper) - enforce policy Kubernetes-native (constraint template), tương tự vai trò Org Policy nhưng ở tầng K8s.
    

**Lab**: dựng 1 private GKE cluster, bật Workload Identity + Binary Authorization + Pod Security Standard (restricted), deploy 1 image chưa ký để xác nhận bị chặn, sau đó ký bằng Cosign và deploy lại thành công.

**Sai lầm thường gặp trong production**: bật Workload Identity nhưng vẫn để lại default node SA có quyền rộng (Editor) - workload vẫn có thể "leo" quyền qua metadata server nếu cấu hình sai; quên rằng Pod Security Standard chỉ enforce ở namespace được gắn label, các namespace mới tạo mặc định không có bảo vệ.

## Giai đoạn 6: DevSecOps & Supply Chain Security

### 6.1 IaC Security

*   Scan Terraform trước khi apply: `tfsec`, `Checkov`.
    
*   Policy-as-code với **OPA (Open Policy Agent)** - viết rule Rego để chặn Terraform plan vi phạm chuẩn (VD: không cho tạo bucket public).
    
*   Lab: tích hợp Checkov vào CI, chặn merge PR nếu Terraform có bucket không mã hoá hoặc firewall mở `0.0.0.0/0`.
    

### 6.2 CI/CD Security

*   Hardening GitHub Actions/GitLab CI: giới hạn quyền `GITHUB_TOKEN`, pin action version theo SHA (không dùng tag di động), OIDC/WIF thay vì secret tĩnh.
    
*   Cloud Build security: least-privilege SA riêng cho từng pipeline, không dùng default Cloud Build SA (quyền quá rộng).
    

### 6.3 Secrets Detection

*   `Gitleaks`/`Trufflehog` chạy pre-commit và trong CI để chặn secret lọt vào git history.
    
*   Lab: cố tình commit 1 fake API key, xác nhận pipeline chặn merge.
    

### 6.4 Dependency Security

*   SCA (Software Composition Analysis) - quét dependency (npm/pip/maven) tìm CVE đã biết.
    
*   Artifact Analysis (tích hợp Artifact Registry) cho container image.
    

**Sai lầm thường gặp trong production**: chỉ scan lúc build image lần đầu, không re-scan định kỳ khi có CVE mới công bố cho base image cũ đang chạy → "vulnerability debt" âm thầm tích luỹ.

## Giai đoạn 7: Automation & Detection Engineering

### 7.1 Shift-left/CI/CD security

*   Automating security scanning CVE qua CI/CD pipeline (kết hợp SCA ở 6.4).
    
*   Container/VM image hardening tự động (Packer, distroless image, patch pipeline).
    
*   Security Health Analytics custom module - viết rule riêng phát hiện misconfiguration đặc thù tổ chức.
    

### 7.2 Logging strategy

*   Thiết kế log sink theo mô hình: aggregated sink ở org level → BigQuery (cho SIEM/threat hunting) + Cloud Storage (long-term retention/compliance) → export sang SIEM ngoài (nếu multi-cloud).
    
*   Data access audit log - mặc định TẮT cho hầu hết dịch vụ, phải bật thủ công và cân nhắc chi phí.
    
*   Lab: thiết kế + Terraform hoá 1 logging strategy hoàn chỉnh cho tổ chức giả định 3 team.
    

### 7.3 Google SecOps (Chronicle)

*   Ingest log qua feed/forwarder, viết & maintain parser tuỳ chỉnh.
    
*   **YARA-L** - viết detection rule thật (không chỉ đọc), test qua Rules Engine.
    
*   Risk Analytics, entity graph, reference list để giảm false positive.
    
*   Lab: viết 3 detection rule YARA-L cho kịch bản thật: (1) đăng nhập bất thường ngoài giờ, (2) SA key mới + dùng ngay từ IP lạ, (3) data exfiltration pattern qua BigQuery export.
    

### 7.4 Security Command Center (SCC)

*   Cấu hình SCC Premium/Enterprise, Event Threat Detection, toxic combination detection.
    
*   Tích hợp SCC finding → Google SecOps case → SOAR playbook (luồng thật end-to-end).
    

**Sai lầm thường gặp trong production**: bật ingest tất cả log vào SecOps mà không tính chi phí → hoá đơn khổng lồ; viết detection rule quá rộng → alert fatigue, đội SOC bỏ qua alert thật.

## Giai đoạn 8: Threat Hunting & Threat Intelligence

*   Chủ động hunt (không chờ alert): xây hypothesis từ threat intel (Google Threat Intelligence - GTI), kiểm tra IOC trong log lịch sử (retrohunt).
    
*   Phân tích entity risk score, hành vi user bất thường (UEBA).
    
*   Lab: lấy 1 bộ IOC công khai (VD từ báo cáo GTI/Mandiant), viết query BigQuery/Log Analytics quét ngược 90 ngày log giả lập.
    

## Giai đoạn 9: Incident Response

*   Playbook: containment → investigation → eradication → recovery → post-mortem (blameless).
    
*   Forensic: snapshot disk, memory capture trước khi tắt máy, chain of custody.
    
*   SOAR (Google SecOps): tự động hoá bước lặp lại (block IP, disable account, tạo ticket), giữ quyết định quan trọng (isolate server, escalate) cho con người.
    
*   **Tabletop exercise** - công ty thật luôn làm định kỳ: giả lập breach, chạy thử toàn bộ quy trình với team thật.
    
*   Lab: tự viết 1 kịch bản incident giả (VD: leaked SA key bị dùng từ nước ngoài để spin up crypto-mining instance), chạy full playbook containment → root cause → báo cáo.
    

## Giai đoạn 10: Attack Simulation/Purple Team Lab

Tabletop exercise (Giai đoạn 9) là diễn tập trên giấy. Purple team là diễn tập **thật trên hệ thống**, cách duy nhất kiểm chứng detection coverage thật sự.

### 10.1 Kịch bản tấn công mẫu

*   Tạo SA key trái phép → dùng ngay từ IP lạ.
    
*   Privilege escalation qua quyền `iam.serviceAccounts.actAs` bị cấp thừa.
    
*   Exfiltration attempt: export dữ liệu BigQuery ra ngoài project không được whitelist.
    
*   Lateral movement: từ 1 VM bị compromise, thử truy cập metadata server để lấy token của SA gắn trên VM.
    

### 10.2 Đánh giá coverage (Blue team side)

*   Với mỗi kịch bản trên, kiểm tra: Chronicle có phát hiện? SCC có tạo finding? SOAR có tự động response đúng không? Thời gian từ hành động → alert (MTTD) là bao lâu?
    
*   Map từng kịch bản vào **MITRE ATT&CK for Cloud** để biết mình đang cover kỹ thuật nào, còn hở kỹ thuật nào.
    

**Lab**: chạy 4 kịch bản ở 10.1 trong 1 project cô lập, ghi lại bảng: kịch bản → có bị phát hiện? → thời gian phát hiện → có response tự động? → gap cần vá.

**Sai lầm thường gặp trong production**: chỉ purple-team 1 lần rồi thôi - cần lặp lại định kỳ (mỗi khi thêm detection rule mới hoặc thay đổi kiến trúc) vì coverage suy giảm dần theo thời gian (rule cũ, threat mới).

## Giai đoạn 11: Compliance & Observability

*   Mapping control ↔ khung tuân thủ thật tổ chức cần (ISO 27001, SOC 2, PCI-DSS, hoặc quy định VN như Nghị định 13/2023 về bảo vệ dữ liệu cá nhân nếu áp dụng).
    
*   **Assured Workloads**: chỉ cần nắm khái niệm + use case (data residency/sovereignty, ngành có quy định đặc thù như chính phủ/tài chính) - không cần đào sâu bằng IAM/VPC-SC/SecOps, vì đây là tính năng niche, ít tổ chức dùng tới.
    
*   Dashboard SOC: MTTD, MTTR, coverage theo MITRE ATT&CK, false positive rate - KPI thật SOC lead cần báo cáo hàng tháng.
    
*   Health monitoring cho chính pipeline bảo mật (silent source detection - phát hiện khi 1 nguồn log ngừng gửi, dấu hiệu attacker đã tắt logging).
    

## Phụ lục: Internals

Phần này không bắt buộc để "vận hành tốt", nhưng cần nếu mục tiêu là **thiết kế hệ thống** hoặc debug những case cực hiếm/khó ở tầng sâu.

### IAM

*   Token issuance flow (OAuth 2.0 internals), Security Token Service (STS).
    
*   Workload Identity Federation internals: cách GCP verify external token (OIDC/SAML assertion) trước khi đổi sang short-lived GCP token.
    
*   JWT validation chain.
    

### VPC Service Controls

*   Request evaluation engine: thứ tự đánh giá ingress/egress rule, access level, VPC accessible service.
    
*   Cách perimeter engine xử lý request xuyên nhiều perimeter (perimeter bridge).
    

### Chronicle

*   Ingestion pipeline: raw log → parser → UDM (Unified Data Model) → indexing.
    
*   Detection execution engine: cách YARA-L rule được compile và chạy trên streaming vs batch data.
    

### SCC

*   Finding lifecycle (ACTIVE → MUTED/RESOLVED), cách source (built-in detector vs custom/3rd-party) publish finding, event correlation logic cho toxic combination.
    

**Cách học phần này**: đọc kỹ Architecture Center + release notes, thử nghiệm bằng cách quan sát log/finding thực tế thay đổi khi mình thay đổi 1 biến số (VD: đổi 1 access level trong VPC-SC rồi xem log audit ghi lại quyết định allow/deny thế nào).

## Lộ trình thực hành đề xuất (20–24 tuần, song song học + lab)

| Tuần | Trọng tâm | Deliverable thực tế |
| --- | --- | --- |
| 1–2 | Landing zone + IAM | Terraform module resource hierarchy + IAM baseline |
| 3 | Cloud Asset Inventory | Script quét resource public toàn org |
| 4 | Organization Policy | Bộ org policy baseline (10+ constraint) qua Terraform |
| 5–6 | Service Account & Workload Identity | Pipeline CI/CD không dùng key |
| 7–8 | Network (NGFW, IAP, Cloud Armor) | App demo có WAF + IAP, test pen-test cơ bản |
| 9 | VPC Service Controls | Perimeter chặn exfiltration, có dry-run report |
| 10 | Data protection (DLP, CMEK, Secret Manager) | Pipeline xử lý PII tự động redact |
| 11–12 | GKE & Container Security | Cluster hardened + Binary Authorization + Cosign |
| 13 | DevSecOps & Supply Chain | CI pipeline có Checkov/Gitleaks/SCA chặn merge |
| 14–15 | Logging + SecOps ingest + YARA-L | 3 detection rule hoạt động, test bằng log giả |
| 16 | SCC + SOAR integration | 1 playbook end-to-end tự động |
| 17 | Threat hunting | Báo cáo hunt từ 1 bộ IOC thật |
| 18 | Incident response | Tabletop exercise + after-action report |
| 19–20 | Attack Simulation/Purple Team | Bảng coverage 4 kịch bản tấn công, gap analysis |
| 21–24 | Compliance mapping + dashboard + Internals (tuỳ chọn) | Dashboard SOC + control matrix cho 1 khung (VD SOC 2) |

## Nguồn tham khảo

*   Google Cloud **Security Foundations Guide** + **Enterprise Foundations Blueprint** (thiết kế thật, không phải danh sách tính năng).
    
*   Google Cloud Architecture Center - mục "Security" và "GKE security overview".
    
*   Google SecOps/Chronicle documentation - phần YARA-L reference chi tiết.
    
*   MITRE ATT&CK for Cloud/for Containers - dùng để tự đánh giá coverage detection.
    
*   SLSA.dev - chuẩn supply chain security cho container/artifact.
    
*   OPA/Gatekeeper documentation - cho Policy Controller trên GKE.
    
*   Các postmortem/incident report công khai (Google, các công ty lớn) để học cách viết root cause analysis thật.