Skip to main content

Command Palette

Search for a command to run...

Syllabus GCP Security

Updated
17 min readView as Markdown

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.

Knowledge

Part 1 of 50