Bảo mật CloudCloud Security
Thuộc bộ kiến thức DevSecOps Roadmap.
Tổng quan
Bảo mật cloud (cloud security) là tập hợp các thực hành, kiểm soát và công cụ dùng để bảo vệ dữ liệu, workload và hạ tầng chạy trên các nền tảng public cloud (AWS, Azure, GCP, v.v.). Nó khác với bảo mật on-premises truyền thống ở một điểm mấu chốt: nhà cung cấp cloud (cloud provider) và khách hàng (customer) cùng chia sẻ trách nhiệm bảo mật, và ranh giới giữa hai bên thay đổi tùy theo loại dịch vụ đang sử dụng (IaaS, PaaS, hay SaaS). Hiểu sai ranh giới này chính là nguyên nhân lớn nhất dẫn đến các vụ vi phạm dữ liệu trên cloud — không phải do các cuộc tấn công tinh vi, mà là do những misconfiguration (cấu hình sai) đơn giản mà khách hàng để lại trong phần stack mà họ vốn luôn phải chịu trách nhiệm.
Bài viết này bao quát Shared Responsibility Model (mô hình trách nhiệm chia sẻ), các misconfiguration chiếm phần lớn các sự cố cloud trong thực tế, IAM (Identity and Access Management) ở quy mô cloud, Cloud Security Posture Management (CSPM), bảo vệ dữ liệu (mã hóa và quản lý khóa), bảo mật mạng trên cloud, log/audit trail, và một góc nhìn ngắn gọn về các cân nhắc bảo mật đa cloud/đa vùng (multi-cloud/multi-region). Bài viết dựa trực tiếp trên Identity and Access Management và Cryptography Fundamentals, đồng thời kết nối tới Container and Kubernetes Security, Monitoring and Logging, và Enterprise Security at Scale để đào sâu hơn về quản trị đa cloud/đa tài khoản. Về chi tiết mạng, xem Cloud Networking; về các bài phân tích chuyên sâu theo từng nhà cung cấp, xem Cloud knowledge base.
Kiến thức nền tảng
Shared Responsibility Model
Mọi nhà cung cấp cloud lớn (AWS, Azure, GCP) đều dùng một biến thể của Shared Responsibility Model: nhà cung cấp chịu trách nhiệm bảo mật của cloud (hạ tầng vật lý, host virtualization, và — tùy dịch vụ — cả phần managed software stack), còn khách hàng chịu trách nhiệm bảo mật trong cloud (cách họ cấu hình, sử dụng, và xây dựng trên nền tảng đó).
Ranh giới chính xác di chuyển theo một phổ (spectrum) tùy vào service model:
| Lớp (Layer) | IaaS (VD: EC2, Compute Engine, Azure VMs) | PaaS (VD: RDS, Cloud SQL, App Service) | SaaS (VD: Microsoft 365, Salesforce) |
|---|---|---|---|
| Bảo mật vật lý / trung tâm dữ liệu | Provider | Provider | Provider |
| Host OS / hypervisor | Provider | Provider | Provider |
| Hạ tầng mạng (backbone, mạng vật lý) | Provider | Provider | Provider |
| Vá lỗi guest OS (OS patching) | Customer | Provider | Provider |
| Middleware/runtime | Customer | Provider | Provider |
| Mã ứng dụng (application code) | Customer | Customer | Provider |
| Cấu hình network & firewall (security group, VPC/subnet) | Customer | Customer (thường vẫn áp dụng, VD: DB subnet group) | Provider (customer cấu hình chính sách truy cập ở tầng tenant) |
| Identity and access management (ai được làm gì) | Customer | Customer | Customer |
| Phân loại và mã hóa dữ liệu | Customer | Customer | Customer |
| Bản thân dữ liệu (nội dung, backup, retention) | Customer | Customer | Customer |
Những điểm rút ra từ bảng trên:
- Identity, access control và dữ liệu luôn luôn là trách nhiệm của customer, bất kể bạn dịch chuyển lên cao đến đâu trong stack (IaaS → SaaS). Đây là lý do vì sao misconfiguration về IAM và bảo vệ dữ liệu luôn là hai vùng rủi ro thường trực trên mọi service model.
- Khi chuyển từ IaaS sang SaaS, provider gánh nhiều hơn phần kỹ thuật của stack, nhưng trách nhiệm cấu hình và quản trị access của customer không bao giờ biến mất — nó chỉ dịch chuyển từ “vá OS” sang “cấu hình đúng các thiết lập bảo mật tenant và quyền người dùng.”
- Tài liệu của provider luôn là nguồn tham khảo chính xác nhất — nên luôn tra cứu cho từng dịch vụ cụ thể đang dùng. AWS, Azure, GCP đều xuất bản sơ đồ shared responsibility riêng (xem phần Tài liệu tham khảo), và ranh giới có thể khác nhau tinh tế theo từng dịch vụ (VD: control plane của managed Kubernetes so với self-managed node).
Một sai lầm phổ biến và tốn kém là mặc định “cloud provider lo hết phần bảo mật.” Trên thực tế, provider chỉ bảo mật nền tảng (platform); gần như mọi vụ vi phạm cloud nổi tiếng trong thập kỷ qua (rò rỉ S3 bucket, lộ Elasticsearch/MongoDB, lộ credential cloud) đều là lỗi ở phía customer của ranh giới trách nhiệm.
Nguyên nhân số 1 gây ra các vụ vi phạm cloud: misconfiguration
Nhiều báo cáo ngành (Verizon DBIR, Gartner, CSA “Egregious Eleven”/“Pandemic Eleven”) liên tục xác định misconfiguration — không phải zero-day exploit — là nguyên nhân gốc rễ hàng đầu của các vụ vi phạm dữ liệu trên cloud. Các mẫu hình phổ biến:
| Misconfiguration | Vì sao xảy ra | Tác động điển hình |
|---|---|---|
| Public storage bucket (S3, Azure Blob, GCS) | Bucket được tạo với ACL mặc định hoặc “public read” cho tiện (VD: phục vụ static asset), rồi quên rằng nó cũng chứa dữ liệu nhạy cảm; hoặc bucket policy cấp "Principal": "*" | Lộ dữ liệu hàng loạt — PII của khách hàng, credential, tài liệu nội bộ bị search engine index hoặc bot tự động scrape chỉ trong vài phút sau khi tạo |
| IAM role/policy cấp quyền quá rộng | Dùng wildcard action/resource ("Action": "*", "Resource": "*") để “cho chạy được,” rồi không bao giờ siết lại; gán các managed policy rộng (VD: AdministratorAccess) cho service role trong khi chỉ cần quyền đọc một resource | Di chuyển ngang (lateral movement) và leo thang đặc quyền (privilege escalation) — một workload giá trị thấp bị compromise (VD: web server) có thể pivot để chiếm toàn bộ account |
| Security group / NSG mở quá rộng | Rule kiểu 0.0.0.0/0 trên SSH (22), RDP (3389), hoặc cổng database được mở “tạm thời” lúc setup rồi không bao giờ gỡ bỏ | Bị quét cổng (port scanning) toàn Internet phát hiện trong vài giờ; brute-force hoặc khai thác cổng quản trị/database bị lộ |
| Dữ liệu không mã hóa khi lưu trữ (unencrypted data at rest) | Không rà soát thiết lập mặc định, hoặc tắt mã hóa để “đơn giản hóa” quá trình migrate hay giảm độ trễ/chi phí cảm nhận | Dữ liệu có thể đọc được ở dạng plaintext nếu storage media, snapshot, hay backup bị lộ hoặc xử lý sai khi loại bỏ; thường vi phạm trực tiếp các framework tuân thủ (PCI DSS, HIPAA, GDPR) |
| Truy cập không giới hạn vào giao diện quản trị (console, Kubernetes API server, cloud metadata service) | Cấu hình mặc định mở, hoặc để tiện khi debug | Compromise toàn bộ hạ tầng qua tấn công SSRF-to-metadata-service (đánh cắp credential của instance) hoặc truy cập trực tiếp console/API |
| Logging bị tắt hoặc không được rà soát | Tắt logging để tiết kiệm chi phí, hoặc log không được đẩy về nơi tập trung, chống giả mạo | Vi phạm không bị phát hiện trong nhiều tháng; không có dấu vết forensic khi phản ứng sự cố |
| Snapshot/AMI/image được chia sẻ công khai | Chia sẻ disk snapshot hoặc machine image để demo/troubleshoot, rồi quên đưa lại về private | Bất kỳ ai cũng có thể khôi phục snapshot và đọc toàn bộ nội dung, kể cả secret được nhúng sẵn trong image |
| Credential mặc định hoặc key dài hạn không được xoay vòng | Access key của root/admin account được tạo một lần và không bao giờ rotate; mật khẩu mặc định của managed service không được đổi | Credential-stuffing và key dài hạn bị lộ cho phép attacker duy trì quyền truy cập khó phát hiện |
Điểm chung: không cái nào trong số này đòi hỏi kỹ thuật khai thác cao cấp. Đây đều là thất bại của default-deny — ai đó đã mở một thứ gì đó (cố ý vì tiện lợi, hoặc vô tình) và không có kiểm soát tự động nào bắt được trước khi nó chạy production. Đây chính xác là khoảng trống mà CSPM (xem bên dưới) được thiết kế để lấp đầy.
Khái niệm chính
Cloud IAM ở quy mô lớn
Môi trường cloud nhân bản thách thức identity and access management đã mô tả trong Identity and Access Management: thay vì vài chục tài khoản nhân viên, một môi trường cloud trưởng thành có hàng nghìn service identity (role, service account, managed identity) được tạo ra và sử dụng bởi pipeline, workload, và automation — thường nhiều hơn số identity con người tới cả một bậc độ lớn.
Các khái niệm cốt lõi của cloud IAM:
- Least privilege (nguyên tắc đặc quyền tối thiểu) ở quy mô cloud. Mỗi principal (người hoặc máy) chỉ nên có đúng quyền cần thiết cho tác vụ cụ thể, giới hạn vào đúng resource cần dùng — không phải quyền toàn account hay wildcard. Trong thực tế, điều này nghĩa là viết policy hẹp, giới hạn theo resource (VD: “đọc object trong
s3://my-bucket/reports/*” thay vì “đọc/ghi mọi S3 bucket”). - Role vs. user vs. service account/managed identity.
- IAM user là identity dài hạn (người hoặc ứng dụng) với credential gắn trực tiếp — ngày càng bị khuyến cáo hạn chế, thay bằng role.
- IAM role (AWS) / service account (GCP) / managed identity (Azure) là identity có thể được “assume,” cấp credential ngắn hạn và tự động xoay vòng cho workload (instance EC2, Lambda function, pod Kubernetes, job CI/CD) thay vì nhúng một static key.
- Ưu tiên role/service account thay vì access key dài hạn giúp loại bỏ hẳn một nhóm rủi ro: static credential bị lộ mà không có hạn sử dụng.
- Permission boundary và Service Control Policy (SCP) / organization policy. Một permission boundary (AWS) hoặc organization policy (GCP)/Azure Policy giới hạn quyền tối đa mà một role có thể có hoặc được cấp, ngay cả khi sau này có ai đó gắn một policy quá rộng vào — đây là một guardrail chống leo thang đặc quyền được thiết kế sẵn, chứ không chỉ dựa vào review thủ công.
- Truy cập cross-account/cross-project nên đi qua cơ chế role assumption tường minh (
AssumeRole, workload identity federation) kèm điều kiện (source account, MFA, dải IP) thay vì chia sẻ credential dài hạn. - Truy cập just-in-time / quyền nâng cao tạm thời cho các kịch bản break-glass (VD: truy cập production khẩn cấp) thay vì cấp quyền admin thường trực.
- Rà soát access định kỳ và cắt bỏ quyền không dùng — các công cụ phân tích IAM trên cloud (AWS IAM Access Analyzer, GCP Policy Analyzer/Recommender, Azure AD access review) gắn cờ những quyền đã cấp nhưng không sử dụng để loại bỏ, thu hẹp dần “vùng ảnh hưởng” (blast radius) của bất kỳ identity nào bị compromise theo thời gian.
CSPM — Cloud Security Posture Management
Công cụ CSPM liên tục và tự động quét account/subscription/project trên cloud để tìm misconfiguration, so sánh trạng thái thực tế của các resource với benchmark bảo mật và quy tắc best-practice — lấp đúng khoảng trống được xác định ở trên là nguyên nhân số 1 gây vi phạm.
CSPM làm gì:
- Quét cấu hình liên tục trên toàn bộ estate cloud (mọi account, region, và loại resource), không chỉ ở thời điểm deploy — bắt được cả những thay đổi trôi dạt (drift) do sửa tay trên console, chứ không chỉ những thay đổi đi qua IaC/CI.
- So sánh với chuẩn (benchmarking) như CIS Benchmarks (CIS AWS/Azure/GCP Foundations Benchmark), CSA Cloud Controls Matrix, và các trụ cột bảo mật well-architected riêng của từng provider, gắn cờ độ lệch (VD: “S3 bucket X cho phép public read,” “security group Y cho phép 0.0.0.0/0 trên cổng 22,” “IAM role Z có quyền admin không sử dụng”).
- Ưu tiên hóa rủi ro và ngữ cảnh. CSPM hiện đại tương quan các phát hiện với mức độ phơi nhiễm (resource có hướng ra Internet không?), identity (một role bị compromise có tiếp cận được dữ liệu nhạy cảm không?), và độ nhạy cảm của dữ liệu, giúp đội ngũ ưu tiên xử lý một số ít phát hiện thực sự rủi ro thay vì chìm trong hàng nghìn cảnh báo ưu tiên thấp.
- Ánh xạ tuân thủ (compliance mapping). Tự động ánh xạ các phát hiện sang các framework tuân thủ (PCI DSS, HIPAA, SOC 2, ISO 27001) để phục vụ báo cáo audit.
- Tự động khắc phục (auto-remediation, tùy chọn). Một số công cụ CSPM có thể tự động hoàn tác một thay đổi rủi ro (VD: khóa lại public access trên bucket) hoặc tạo ticket/workflow để review thủ công.
CSPM khớp vào pipeline DevSecOps như thế nào:
- Trước khi deploy (shift-left): IaC scanning (Checkov, tfsec, KICS — được trình bày trong bài CI/CD and Supply Chain Security) bắt lỗi cấu hình Terraform/CloudFormation trước khi nó được apply, dùng cùng bộ rule mà CSPM áp dụng lúc runtime.
- Sau khi deploy (liên tục): CSPM chạy trên môi trường thực tế theo lịch (hoặc qua các luồng sự kiện cloud-native như AWS Config, Azure Policy, GCP Security Command Center) để bắt drift — thay đổi do sửa tay trên console, do script automation cấu hình sai, hoặc do credential bị compromise.
- Vòng phản hồi (feedback loop): Các phát hiện được định tuyến về đội sở hữu (qua ticketing, Slack, hay dashboard bảo mật) kèm hướng dẫn khắc phục rõ ràng, và những lỗi lặp lại giúp xác định module IaC/guardrail pipeline nào cần siết chặt để lỗi đó không tái diễn.
- Gating (chặn deploy): Một số tổ chức nối các phát hiện CSPM vào cổng deploy — một workload không được lên production, hoặc một thay đổi không được merge, nếu nó tạo ra phát hiện mức độ “critical.”
Các công cụ CSPM/cloud-native security tiêu biểu: AWS Security Hub + AWS Config, Microsoft Defender for Cloud, Google Security Command Center, Wiz, Prisma Cloud, Orca Security.
Bảo vệ dữ liệu trên cloud
Bảo vệ dữ liệu dựa trên hai trụ cột: mã hóa dữ liệu ở mọi nơi nó tồn tại, và kiểm soát các khóa dùng để làm điều đó.
- Mã hóa khi lưu trữ (encryption at rest). Các dịch vụ storage trên cloud (S3, EBS, Azure Disk Storage, GCS, Cloud SQL/RDS) hỗ trợ mã hóa at-rest, ngày nay thường bật mặc định, nhưng trước đây thường là opt-in — luôn kiểm tra tường minh thay vì mặc định cho là đã bật. Mã hóa at-rest bảo vệ dữ liệu nếu media vật lý, snapshot, hay backup bị đánh cắp hoặc xử lý sai khi loại bỏ, và thường được yêu cầu bởi các framework tuân thủ (PCI DSS, HIPAA, GDPR).
- Mã hóa khi truyền (encryption in transit). TLS nên được terminate càng gần workload càng tốt, và traffic nội bộ giữa các service (không chỉ ở edge công khai) cũng nên được mã hóa, đặc biệt khi đi qua nhiều availability zone, region, hay mạng dùng chung/multi-tenant — hãy giả định mạng nội bộ có thể bị quan sát.
- Tích hợp KMS. Cloud Key Management Service (AWS KMS, Azure Key Vault, GCP Cloud KMS) quản lý khóa mã hóa với bảo vệ có hỗ trợ phần cứng (tùy chọn HSM-backed), policy truy cập chi tiết (ai được dùng khóa để encrypt/decrypt so với ai được quản lý/rotate), audit log cho mọi lần sử dụng khóa, và rotate khóa tự động hoặc theo lịch. Xem Cryptography Fundamentals để nắm các khái niệm nền tảng (mã hóa đối xứng/bất đối xứng, key rotation, envelope encryption).
- Envelope encryption là mẫu hình chuẩn trên cloud: dữ liệu được mã hóa bằng một data key tạo ra tại chỗ (nhanh), và chính data key đó lại được mã hóa (“wrap”) bởi một khóa do KMS quản lý. Cách này tránh việc phải gửi dữ liệu lớn tới dịch vụ KMS, và cho phép rotate khóa KMS mà không cần mã hóa lại toàn bộ dữ liệu bên dưới.
- Customer-managed key (CMK) so với provider-managed key. Dùng customer-managed key cho phép tổ chức kiểm soát key policy, lịch rotate, và khả năng thu hồi quyền truy cập (crypto-shredding) độc lập với cloud provider — quan trọng với các yêu cầu pháp lý hoặc hợp đồng liên quan đến chủ quyền dữ liệu (data sovereignty) và “quyền được lãng quên.”
- Phân loại dữ liệu (data classification) nên là căn cứ cho quyết định mã hóa và truy cập — không phải mọi dữ liệu đều cần cùng một mức kiểm soát, và phân loại dữ liệu (public, internal, confidential, restricted) từ đầu giúp áp dụng policy nhất quán (VD: “dữ liệu restricted phải dùng customer-managed key và không được rời khỏi region X”) một cách tự động thông qua tagging và policy-as-code.
- Quản lý secret (API key, credential database, certificate) nên nằm trong một secrets manager chuyên dụng (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault) có rotate tự động — không bao giờ để trong source code, biến môi trường commit vào version control, hay file config không mã hóa.
Bảo mật mạng trên cloud
Bảo mật mạng trên cloud tái sử dụng các khái niệm quen thuộc (phân đoạn/segmentation, giảm thiểu phơi nhiễm, defense-in-depth) nhưng triển khai theo cách khác so với mạng on-premises. Xem Cloud Networking để có cái nhìn đầy đủ; những điểm liên quan đến bảo mật nổi bật:
-
Security group vs. NACL (thuật ngữ AWS; về khái niệm tương tự ở các provider khác).
Khía cạnh Security Group NACL (Network ACL) Phạm vi Gắn vào từng resource riêng lẻ (instance, ENI, load balancer) Gắn vào một subnet — áp dụng cho mọi thứ bên trong Trạng thái Stateful — traffic trả về tự động được phép Stateless — rule inbound và outbound phải khai báo riêng biệt tường minh Cách đánh giá rule Mọi rule “allow” khớp đều được đánh giá (default deny, ngầm định) Rule được đánh giá theo thứ tự đánh số, khớp đầu tiên thắng Dùng điển hình Kiểm soát truy cập chính hằng ngày (allow-list ở mức instance) Lớp bảo vệ thô hơn ở mức subnet, VD: chặn một dải IP xấu đã biết cho toàn bộ subnet Best practice: dùng security group làm kiểm soát chính (gắn bộ rule hẹp nhất cho từng resource — VD: chỉ cho phép cổng 443 từ security group của load balancer, không phải từ
0.0.0.0/0), và dùng NACL như một lớp an toàn bổ sung, thô hơn. -
Private subnet. Các workload không cần expose trực tiếp ra Internet (database, service nội bộ, worker node) nên đặt trong private subnet không có route tới internet gateway, chỉ ra Internet (nếu cần) qua NAT gateway, và chỉ được truy cập inbound qua load balancer hoặc bastion/jump host đặt ở public subnet.
-
Bảo mật VPC. Phân đoạn các môi trường (production, staging, dev) thành các VPC riêng biệt hoặc ít nhất là các subnet riêng với ranh giới routing/security-group nghiêm ngặt giữa chúng; dùng VPC Flow Log để ghi lại các kết nối được chấp nhận/từ chối phục vụ phát hiện và điều tra; dùng VPC endpoint / Private Link để truy cập dịch vụ cloud (S3, KMS, v.v.) mà không cần đi qua Internet công khai.
-
Tư thế zero trust. Coi mạng cloud là vốn dĩ không đáng tin cậy thay vì dựa vào giả định “ở trong VPC = đáng tin,” xác thực và phân quyền traffic giữa các service (mTLS, chính sách service mesh) bên cạnh các kiểm soát ở tầng mạng.
-
Web Application Firewall (WAF) và bảo vệ DDoS (AWS Shield/WAF, Azure Front Door + WAF, Cloud Armor) nằm ở edge, phía trước các ứng dụng/API hướng ra công khai, lọc các mẫu tấn công phổ biến (SQL injection, XSS, credential stuffing) và hấp thụ các cuộc tấn công khối lượng lớn trước khi chúng chạm tới hạ tầng ứng dụng.
Logging và audit trên cloud
Mọi provider lớn đều cung cấp một dịch vụ audit trail ở cấp account/organization — AWS CloudTrail, Azure Activity Log/Monitor, GCP Cloud Audit Logs — ghi lại mọi lời gọi API thực hiện trên account: ai (identity nào), hành động gì, trên resource nào, từ đâu (source IP), và khi nào, bất kể lời gọi thành công hay bị từ chối.
Vì sao điều này đặc biệt quan trọng với bảo mật cloud:
- Thường là bản ghi duy nhất của các thay đổi qua console/API. Không giống application log (chỉ ghi lại những gì code của bạn chủ động log), cloud audit log ghi lại mọi hành động quản trị — kể cả bản thân misconfiguration (VD: “ai đã đổi ACL của bucket này thành public, và khi nào”).
- Tính bất biến (immutability) và chống giả mạo rất quan trọng. Audit log nên được đẩy về một account/subscription/project riêng biệt với quyền ghi bị giới hạn (hoặc tầng storage write-once) để attacker dù có compromise được account chính cũng không thể xóa bằng chứng về những gì đã làm.
- Tập trung hóa trên nhiều account/region/organization. Trong mô hình multi-account, một account logging trung tâm nên tổng hợp dữ liệu CloudTrail/Activity Log/Audit Log từ mọi account thành viên, đẩy vào một nền tảng SIEM hoặc log analytics để tương quan và cảnh báo.
- Cảnh báo cho các hành động rủi ro cao. Đăng nhập root/admin, thay đổi IAM policy, thay đổi security group, tắt chính logging, và thay đổi public-access của storage là những trigger phổ biến cho cảnh báo thời gian thực, vì đây là những hành động gắn liền nhất với cả misconfiguration lẫn compromise đang diễn ra.
Xem Monitoring and Logging để hiểu pipeline logging/observability rộng hơn (đẩy log, tích hợp SIEM, cảnh báo) mà cloud audit log là đầu vào.
Lập kế hoạch bảo mật multi-cloud và multi-region (tóm lược)
Các tổ chức chạy workload trên nhiều cloud provider hoặc nhiều region đối mặt với thêm các cân nhắc lập kế hoạch, được trình bày sâu hơn trong Enterprise Security at Scale:
- Thực thi policy nhất quán trên các provider. Mỗi provider có mô hình IAM, định dạng log, và công cụ bảo mật native riêng — một lớp policy-as-code chung (VD: OPA/Rego, hoặc một CNAPP hỗ trợ đa provider) giúp tránh tư thế bảo mật lệch nhau giữa các cloud.
- Chủ quyền và cư trú dữ liệu (data residency/sovereignty). Yêu cầu pháp lý (GDPR và các quy định tương tự) có thể ràng buộc region nào được phép lưu trữ hoặc xử lý dữ liệu; kiến trúc multi-region phải theo dõi và thực thi điều này theo từng phân loại dữ liệu.
- Tầm nhìn tập trung (centralized visibility). Một “single pane of glass” (CSPM/CNAPP hỗ trợ multi-cloud, hoặc một SIEM trung tâm nhận dữ liệu từ mọi provider) là cần thiết để tránh các điểm mù xuất hiện khi mỗi cloud được giám sát riêng lẻ.
- Liên kết identity xuyên cloud (identity federation). VD: một identity provider của công ty liên kết vào AWS IAM Identity Center, Azure AD, và GCP Workforce Identity Federation, tránh phải duy trì các kho identity riêng biệt, dễ trôi dạt cho từng provider.
- Disaster recovery và failover qua các region/provider phải được lập kế hoạch và kiểm thử với cùng tư thế bảo mật như môi trường chính — một lần failover vội vàng sang region phụ chưa được hardening đầy đủ là nguồn sự cố phổ biến.
Best Practices
Bảng checklist bảo mật cloud
| Khu vực | Mục checklist |
|---|---|
| Shared responsibility | Xác nhận, với từng dịch vụ đang dùng, chính xác lớp nào provider bảo mật và lớp nào team phải tự bảo mật — đừng mặc định |
| Storage | Chặn public access mặc định ở cấp account/organization (VD: S3 Block Public Access); chỉ allowlist ngoại lệ tường minh |
| IAM | Áp dụng least privilege; ưu tiên role/service account thay vì key dài hạn; dùng permission boundary/SCP để giới hạn quyền tối đa |
| IAM | Bắt buộc MFA cho mọi user con người, đặc biệt là root/admin account; loại bỏ việc dùng root/owner account cho vận hành hằng ngày |
| IAM | Rà soát access định kỳ; loại bỏ quyền không dùng và identity đã cũ |
| Network | Security group/NACL mặc định deny; không có 0.0.0.0/0 trên cổng quản trị (SSH, RDP, cổng database) |
| Network | Đặt data store và service nội bộ trong private subnet, không có route trực tiếp ra Internet |
| Network | Bật VPC Flow Log; triển khai WAF/bảo vệ DDoS phía trước endpoint công khai |
| Data | Bật mã hóa at-rest mặc định trên mọi dịch vụ storage; bắt buộc TLS cho mọi dữ liệu in-transit |
| Data | Dùng KMS với customer-managed key cho dữ liệu nhạy cảm; bật key rotation tự động |
| Data | Phân loại dữ liệu và áp dụng chính sách truy cập/mã hóa dựa trên phân loại, không phải theo cảm tính |
| Secrets | Lưu mọi credential/API key/certificate trong secrets manager có rotation; không bao giờ trong code hay config plain |
| Logging | Bật audit logging cấp account (CloudTrail/Activity Log/Audit Log) trên mọi account/subscription/project, mọi region |
| Logging | Đẩy audit log về account riêng, giới hạn quyền truy cập; cảnh báo khi có thay đổi IAM/security group/public-access |
| CSPM | Chạy quét CSPM liên tục theo CIS Benchmarks; tích hợp IaC scanning trước khi deploy với cùng bộ rule |
| Multi-cloud | Duy trì một tầm nhìn xuyên provider thống nhất về tư thế bảo mật; liên kết identity tập trung thay vì theo từng cloud riêng lẻ |
| Governance | Gắn tag/label resource với owner, environment, và phân loại dữ liệu để hỗ trợ thực thi policy tự động |
| Review | Định kỳ kiểm tra lại các giả định bằng mô phỏng tấn công thực tế (VD: một workload quyền thấp bị compromise có tiếp cận được dữ liệu nhạy cảm không?) |
Các thực hành bổ sung
- Tự động hóa guardrail, đừng dựa vào review thủ công. Misconfiguration là một vấn đề về khối lượng (volume) — cùng một nhóm lỗi lặp lại trên hàng nghìn resource nhanh hơn bất kỳ quy trình review con người nào có thể theo kịp; CSPM và policy-as-code tồn tại chính xác để lấp khoảng trống này một cách liên tục.
- Giả định đã bị breach (assume breach). Thiết kế IAM, phân đoạn mạng, và mã hóa sao cho một credential hay workload bị compromise chỉ có “vùng ảnh hưởng” giới hạn thay vì mở đường tới toàn bộ estate.
- Xem thay đổi trên console cloud nghiêm túc như thay đổi code. Khi có thể, quản lý hạ tầng qua IaC và CI/CD (có review và IaC scanning) thay vì click tay ad hoc trên console, và cảnh báo khi có thay đổi thủ công như một tín hiệu, không chỉ là artifact để audit.
- Rà soát lại tường minh các thiết lập mặc định. Nhiều mặc định của provider đã cải thiện theo thời gian (VD: S3 Block Public Access nay đã mặc định bật cho bucket mới), nhưng resource cũ và các dịch vụ không mặc định vẫn có thể cần hardening tường minh.
- Đối chiếu chéo với bảo mật container và Kubernetes (Container and Kubernetes Security) khi workload chạy trên managed Kubernetes (EKS/AKS/GKE) — cloud IAM và Kubernetes RBAC giao nhau ở tầng identity của node/pod (IRSA, Workload Identity, pod-managed identity), và cả hai phải được hardening cùng nhau.
Tài liệu tham khảo
- AWS — Shared Responsibility Model
- Microsoft Azure — Shared Responsibility in the Cloud
- Google Cloud — Shared Responsibility and Shared Fate
- CIS Benchmarks
- Cloud Security Alliance — Top Threats to Cloud Computing (Pandemic/Egregious Eleven)
- Cloud Security Alliance — Cloud Controls Matrix (CCM)
- AWS — Security Best Practices in IAM
- NIST SP 800-144 — Guidelines on Security and Privacy in Public Cloud Computing
Part of the DevSecOps Roadmap knowledge base.
Overview
Cloud security is the set of practices, controls, and tools used to protect data, workloads, and infrastructure running on public cloud platforms (AWS, Azure, GCP, and similar). It differs from traditional on-premises security in one crucial way: the cloud provider and the customer both hold security responsibilities, and the boundary between them shifts depending on the type of service being consumed (IaaS, PaaS, or SaaS). Misunderstanding that boundary is the single biggest driver of cloud breaches — not sophisticated attacks, but simple misconfigurations left by the customer inside the portion of the stack they were always responsible for.
This note covers the Shared Responsibility Model, the misconfigurations that account for the overwhelming majority of real-world cloud incidents, cloud-scale identity and access management, Cloud Security Posture Management (CSPM), data protection (encryption and key management), cloud network security, logging/audit trails, and a brief look at multi-cloud/multi-region considerations. It builds directly on Identity and Access Management and Cryptography Fundamentals, and connects forward to Container and Kubernetes Security, Monitoring and Logging, and Enterprise Security at Scale for deeper multi-cloud/multi-account governance. For networking specifics, see Cloud Networking, and for provider-specific deep dives, see the Cloud knowledge base.
Fundamentals
The Shared Responsibility Model
Every major cloud provider (AWS, Azure, GCP) uses some version of the Shared Responsibility Model: the provider is responsible for the security of the cloud (the physical infrastructure, host virtualization, and — depending on the service — the managed software stack), while the customer is responsible for security in the cloud (how they configure, use, and build on top of what the provider gives them).
The exact split moves along a spectrum depending on the service model:
| Layer | IaaS (e.g., EC2, Compute Engine, Azure VMs) | PaaS (e.g., RDS, Cloud SQL, App Service) | SaaS (e.g., Microsoft 365, Salesforce) |
|---|---|---|---|
| Physical/data center security | Provider | Provider | Provider |
| Host OS / hypervisor | Provider | Provider | Provider |
| Network infrastructure (backbone, physical network) | Provider | Provider | Provider |
| Guest OS patching | Customer | Provider | Provider |
| Middleware/runtime | Customer | Provider | Provider |
| Application code | Customer | Customer | Provider |
| Network & firewall configuration (security groups, VPC/subnets) | Customer | Customer (often still applies, e.g., DB subnet groups) | Provider (customer configures tenant-level access policy) |
| Identity and access management (who can do what) | Customer | Customer | Customer |
| Data classification and encryption choices | Customer | Customer | Customer |
| Data itself (content, backups, retention) | Customer | Customer | Customer |
Key takeaways from this table:
- Identity, access control, and data are always the customer’s responsibility, no matter how far up the stack (IaaS → SaaS) you move. This is why IAM misconfiguration and data protection remain the two evergreen risk areas across every service model.
- As you move from IaaS to SaaS, the provider absorbs more of the technical stack, but the customer’s configuration and access-governance responsibility never disappears — it just shifts from “patch the OS” to “configure tenant security settings and user permissions correctly.”
- Provider documentation is authoritative and should always be consulted for the specific service in use — AWS, Azure, and GCP each publish their own shared responsibility diagrams (see References), and the split can vary subtly by individual service (e.g., a managed Kubernetes control plane vs. self-managed nodes).
A common and costly mistake is assuming “the cloud provider handles security,” full stop. In practice, the provider secures the platform; almost every publicized cloud breach in the last decade (S3 bucket leaks, exposed Elasticsearch/MongoDB instances, leaked cloud credentials) was a failure on the customer side of the line.
The #1 cause of cloud breaches: misconfiguration
Multiple industry reports (Verizon DBIR, Gartner, CSA “Egregious Eleven”/“Pandemic Eleven”) consistently identify misconfiguration, not zero-day exploits, as the leading root cause of cloud data breaches. Common patterns:
| Misconfiguration | Why it happens | Typical impact |
|---|---|---|
| Public storage buckets (S3, Azure Blob, GCS) | Bucket created with default or “public read” ACL for convenience (e.g., serving static assets), forgetting it also holds sensitive data; or a bucket policy grants "Principal": "*" | Mass data exposure — customer PII, credentials, internal documents indexed by search engines or scraped by automated bots within minutes of creation |
| Overly permissive IAM roles/policies | Using wildcard actions/resources ("Action": "*", "Resource": "*") to “get it working,” then never tightening; broad managed policies (e.g., AdministratorAccess) attached to service roles that only need read access to one resource | Lateral movement and privilege escalation — a compromised low-value workload (e.g., a web server) can pivot to full account takeover |
| Open security groups / NSGs | Rules like 0.0.0.0/0 on SSH (22), RDP (3389), or database ports left open “temporarily” during setup and never removed | Internet-wide port scanning finds the service within hours; brute-force or exploitation of exposed management/database ports |
| Unencrypted data at rest | Default settings not reviewed, or encryption disabled to “simplify” a migration or reduce perceived latency/cost | Data readable in plaintext if storage media, snapshots, or backups are exposed or improperly disposed of; often a direct compliance violation (PCI DSS, HIPAA, GDPR) |
| Unrestricted network access to management interfaces (consoles, Kubernetes API server, cloud metadata service) | Default-open configuration, or convenience during debugging | Full infrastructure compromise via SSRF-to-metadata-service attacks (stealing instance credentials) or direct console/API access |
| Disabled or unreviewed logging | Logging turned off to save cost, or logs not shipped to a central, tamper-resistant location | Breaches go undetected for months; no forensic trail during incident response |
| Snapshot/AMI/image sharing set to public | Sharing a disk snapshot or machine image for a demo or troubleshooting, and forgetting to revert it to private | Anyone can restore the snapshot and read its entire contents, including secrets baked into the image |
| Default credentials or unrotated long-lived keys | Root/admin account access keys created once and never rotated; default passwords left unchanged on managed services | Credential-stuffing and long-lived leaked keys give attackers persistent, hard-to-detect access |
The common thread: none of these require an advanced exploit. They are default-deny failures — someone opened something up (deliberately, for convenience, or accidentally) and no automated control caught it before it reached production. This is exactly the gap CSPM (see below) is designed to close.
Key Concepts
Cloud IAM at scale
Cloud environments multiply the identity and access management challenge described in Identity and Access Management: instead of a handful of employee accounts, a mature cloud environment has thousands of service identities (roles, service accounts, managed identities) created and used by pipelines, workloads, and automation, often outnumbering human identities by an order of magnitude.
Core cloud IAM concepts:
- Least privilege at cloud scale. Every principal (human or machine) should hold only the permissions required for its specific task, scoped to the specific resources it needs — not account-wide or wildcard access. In practice this means writing narrow, resource-scoped policies (e.g., “read objects under
s3://my-bucket/reports/*” rather than “read/write all S3 buckets”). - Roles vs. users vs. service accounts/managed identities.
- IAM users are long-lived human or application identities with directly attached credentials — increasingly discouraged in favor of roles.
- IAM roles (AWS) / service accounts (GCP) / managed identities (Azure) are assumable identities that issue short-lived, automatically rotated credentials to a workload (an EC2 instance, a Lambda function, a Kubernetes pod, a CI/CD job) instead of embedding a static key.
- Preferring roles/service accounts over long-lived access keys eliminates an entire class of risk: leaked static credentials with no expiry.
- Permission boundaries and Service Control Policies (SCPs) / organization policies. A permission boundary (AWS) or organization policy (GCP)/Azure Policy caps the maximum permissions a role can ever have or be granted, even if someone later attaches an overly broad policy to it — a guardrail against privilege escalation by design, not just by review.
- Cross-account/cross-project access should go through explicit role assumption (
AssumeRole, workload identity federation) with conditions (source account, MFA, IP range) rather than shared long-lived credentials. - Just-in-time / temporary elevated access for break-glass scenarios (e.g., emergency production access) instead of standing admin permissions.
- Regular access reviews and unused-permission trimming — cloud IAM analyzers (AWS IAM Access Analyzer, GCP Policy Analyzer/Recommender, Azure AD access reviews) flag granted-but-unused permissions so they can be removed, shrinking the blast radius of any single compromised identity over time.
CSPM — Cloud Security Posture Management
CSPM tools continuously and automatically scan cloud accounts/subscriptions/projects for misconfigurations, comparing the live state of cloud resources against security benchmarks and best-practice rules — closing exactly the gap identified above as the #1 cause of breaches.
What CSPM does:
- Continuous configuration scanning across the entire cloud estate (all accounts, regions, and resource types), not just at deployment time — catching drift introduced by manual console changes, not only changes that go through IaC/CI.
- Benchmarking against standards such as the CIS Benchmarks (CIS AWS/Azure/GCP Foundations Benchmark), the CSA Cloud Controls Matrix, and provider-specific well-architected security pillars, flagging deviations (e.g., “S3 bucket X allows public read,” “security group Y allows 0.0.0.0/0 on port 22,” “IAM role Z has unused admin permissions”).
- Risk prioritization and context. Modern CSPM correlates findings with exposure (is the resource internet-facing?), identity (does a compromised role reach sensitive data?), and data sensitivity, so teams triage the handful of findings that represent real risk instead of drowning in thousands of low-priority alerts.
- Compliance mapping. Automatically maps findings to compliance frameworks (PCI DSS, HIPAA, SOC 2, ISO 27001) for audit reporting.
- Auto-remediation (optional). Some CSPM tools can automatically revert a risky change (e.g., re-block public access on a bucket) or trigger a ticket/workflow for manual review.
How CSPM fits into DevSecOps pipelines:
- Pre-deployment (shift-left): IaC scanning (Checkov, tfsec, KICS — covered in the CI/CD and Supply Chain Security topic) catches misconfigured Terraform/CloudFormation before it is ever applied, using the same rule sets CSPM enforces at runtime.
- Post-deployment (continuous): CSPM runs against the live environment on a schedule (or via cloud-native event streams like AWS Config, Azure Policy, GCP Security Command Center) to catch drift — changes made manually in the console, by a misconfigured automation script, or by a compromised credential.
- Feedback loop: Findings are routed back to the owning team (via ticketing, Slack, or a security dashboard) with clear remediation guidance, and repeat offenders inform which IaC modules/pipeline guardrails need to be tightened so the same misconfiguration cannot recur.
- Gating: Some organizations wire CSPM findings into deployment gates — a workload cannot go live, or a change cannot merge, if it introduces a “critical” severity finding.
Representative CSPM/cloud-native security tools: AWS Security Hub + AWS Config, Microsoft Defender for Cloud, Google Security Command Center, Wiz, Prisma Cloud, Orca Security.
Data protection in the cloud
Data protection rests on two pillars: encrypting data wherever it exists, and controlling the keys used to do so.
- Encryption at rest. Cloud storage services (S3, EBS, Azure Disk Storage, GCS, Cloud SQL/RDS) support encryption at rest, often enabled by default today, but historically opt-in — always verify it explicitly rather than assuming. Encryption at rest protects data if physical media, snapshots, or backups are stolen or improperly disposed of, and is frequently mandated by compliance frameworks (PCI DSS, HIPAA, GDPR).
- Encryption in transit. TLS should terminate as close to the workload as practical, and internal service-to-service traffic (not just the public edge) should also be encrypted, especially across availability zones, regions, or shared/multi-tenant networks — assume the internal network can be observed.
- KMS integration. Cloud Key Management Services (AWS KMS, Azure Key Vault, GCP Cloud KMS) manage encryption keys with hardware-backed protection (HSM-backed options available), fine-grained access policies (who can use a key to encrypt/decrypt vs. who can manage/rotate it), audit logging of every key usage, and automatic or scheduled key rotation. See Cryptography Fundamentals for the underlying concepts (symmetric/asymmetric encryption, key rotation, envelope encryption).
- Envelope encryption is the standard cloud pattern: data is encrypted with a fast, locally generated data key, and that data key is itself encrypted (“wrapped”) by a KMS-managed key. This avoids sending bulk data to the KMS service and lets the KMS key be rotated without re-encrypting the underlying data.
- Customer-managed keys (CMK) vs. provider-managed keys. Using customer-managed keys gives the organization control over key policies, rotation schedule, and the ability to revoke access (crypto-shredding) independent of the cloud provider — important for regulatory or contractual requirements around data sovereignty and the “right to be forgotten.”
- Data classification should drive encryption and access decisions — not all data warrants the same controls, and classifying data (public, internal, confidential, restricted) up front makes it possible to apply consistent policies (e.g., “restricted data must use a customer-managed key and cannot leave region X”) automatically via tagging and policy-as-code.
- Secrets management (API keys, database credentials, certificates) belongs in a dedicated secrets manager (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault) with automatic rotation — never in source code, environment variables checked into version control, or unencrypted config files.
Network security in the cloud
Cloud network security reuses familiar concepts (segmentation, least-exposure, defense-in-depth) but implements them differently than on-premises networking. See Cloud Networking for the full treatment; the security-relevant highlights:
-
Security groups vs. NACLs (AWS terminology; conceptually similar across providers).
Aspect Security Groups NACLs (Network ACLs) Scope Attached to individual resources (instance, ENI, load balancer) Attached to a subnet — applies to everything in it State Stateful — return traffic automatically allowed Stateless — inbound and outbound rules must both be defined explicitly Rule evaluation All matching “allow” rules evaluated (default deny, implicit) Rules evaluated in numbered order, first match wins Typical use Primary day-to-day access control (instance-level allow-listing) Coarse-grained subnet-level guardrail, e.g., blocking a known-bad IP range for an entire subnet Best practice: use security groups as the primary control (attach the narrowest rule set to each resource — e.g., allow port 443 only from the load balancer’s security group, not from
0.0.0.0/0), and use NACLs as a secondary, coarse-grained safety net. -
Private subnets. Workloads that do not need direct internet exposure (databases, internal services, worker nodes) should sit in private subnets with no route to an internet gateway, reaching the internet only outbound (if needed at all) via a NAT gateway, and reachable inbound only through a load balancer or bastion/jump host in a public subnet.
-
VPC security. Segment environments (production, staging, dev) into separate VPCs or at minimum separate subnets with strict routing/security-group boundaries between them; use VPC Flow Logs to record accepted/rejected connections for detection and forensics; use VPC endpoints / Private Link to reach cloud services (S3, KMS, etc.) without traversing the public internet.
-
Zero trust posture. Treat the cloud network as inherently untrusted rather than relying on “inside the VPC = trusted” — authenticate and authorize service-to-service traffic (mTLS, service mesh policies) in addition to network-layer controls.
-
Web Application Firewall (WAF) and DDoS protection (AWS Shield/WAF, Azure Front Door + WAF, Cloud Armor) sit at the edge in front of public-facing applications and APIs, filtering common attack patterns (SQL injection, XSS, credential stuffing) and absorbing volumetric attacks before they reach application infrastructure.
Logging and audit in the cloud
Every major provider offers an account/organization-wide audit trail service — AWS CloudTrail, Azure Activity Log/Monitor, GCP Cloud Audit Logs — that records every API call made against the account: who (which identity), what action, on which resource, from where (source IP), and when, regardless of whether the call succeeded or was denied.
Why this matters for cloud security specifically:
- It is often the only record of console/API-driven changes. Unlike application logs, which only capture what your own code chooses to log, cloud audit logs capture every administrative action — including the misconfiguration itself (e.g., “who changed this bucket’s ACL to public, and when”).
- Immutability and tamper resistance matter. Audit logs should be shipped to a separate account/subscription/project with restricted write access (or a write-once storage tier) so that an attacker who compromises the primary account cannot also erase the evidence of what they did.
- Centralization across accounts/regions/organizations. In multi-account setups, a central logging account should aggregate CloudTrail/Activity Log/Audit Log data from every member account, feeding a SIEM or log analytics platform for correlation and alerting.
- Alerting on high-risk actions. Root/admin login, IAM policy changes, security group changes, disabling of logging itself, and public-access changes to storage are common triggers for real-time alerts, since these are the actions most associated with both misconfiguration and active compromise.
See Monitoring and Logging for the broader logging/observability pipeline (log shipping, SIEM integration, alerting) that cloud audit logs feed into.
Multi-cloud and multi-region security planning (brief)
Organizations running workloads across multiple cloud providers or many regions face additional planning considerations, covered in depth in Enterprise Security at Scale:
- Consistent policy enforcement across providers. Each provider has its own IAM model, logging format, and native security tooling — a common policy-as-code layer (e.g., OPA/Rego, or a CNAPP that spans providers) helps avoid divergent security postures per cloud.
- Data residency and sovereignty. Regulatory requirements (GDPR and similar regimes) may constrain which regions data can be stored or processed in; multi-region architectures must track and enforce this per data classification.
- Centralized visibility. A single pane of glass (CSPM/CNAPP with multi-cloud support, or a central SIEM ingesting from all providers) is necessary to avoid blind spots that appear when each cloud is monitored in isolation.
- Identity federation across clouds (e.g., a single corporate identity provider federating into AWS IAM Identity Center, Azure AD, and GCP Workforce Identity Federation) avoids maintaining separate, drifting identity stores per provider.
- Disaster recovery and failover across regions/providers must be planned and tested with the same security posture as primary environments — a rushed failover to an under-hardened secondary region is a common source of incidents.
Best Practices
Cloud security checklist
| Area | Checklist item |
|---|---|
| Shared responsibility | Confirm, per service in use, exactly which layers the provider secures vs. which the team must secure — don’t assume |
| Storage | Block public access by default at the account/organization level (e.g., S3 Block Public Access); explicitly allowlist exceptions |
| IAM | Enforce least privilege; prefer roles/service accounts over long-lived keys; use permission boundaries/SCPs to cap maximum privilege |
| IAM | Require MFA for all human users, especially root/admin accounts; eliminate use of the root/owner account for daily operations |
| IAM | Run regular access reviews; remove unused permissions and stale identities |
| Network | Default-deny security groups/NACLs; no 0.0.0.0/0 on management ports (SSH, RDP, database ports) |
| Network | Place data stores and internal services in private subnets with no direct internet route |
| Network | Enable VPC Flow Logs; deploy WAF/DDoS protection in front of public endpoints |
| Data | Enable encryption at rest by default on all storage services; enforce TLS for all data in transit |
| Data | Use a KMS with customer-managed keys for sensitive data; enable automatic key rotation |
| Data | Classify data and apply access/encryption policy based on classification, not ad hoc judgment |
| Secrets | Store all credentials/API keys/certificates in a secrets manager with rotation; never in code or plain config |
| Logging | Enable account-wide audit logging (CloudTrail/Activity Log/Audit Logs) in every account/subscription/project, in every region |
| Logging | Ship audit logs to a separate, restricted-access account; alert on IAM/security-group/public-access changes |
| CSPM | Run continuous CSPM scanning against CIS Benchmarks; integrate IaC scanning pre-deployment with the same rule set |
| Multi-cloud | Maintain a single, cross-provider view of posture; federate identity centrally rather than per-cloud |
| Governance | Tag/label resources with owner, environment, and data classification to support automated policy enforcement |
| Review | Periodically test assumptions with actual attack simulation (e.g., can a compromised low-privilege workload reach sensitive data?) |
Additional practices
- Automate guardrails, don’t rely on manual review. Misconfiguration is a volume problem — the same class of mistake recurs across thousands of resources faster than any human review process can track; CSPM and policy-as-code exist precisely to close this gap continuously.
- Assume breach. Design IAM, network segmentation, and encryption so that a single compromised credential or workload has a limited blast radius rather than a path to the entire estate.
- Treat cloud console changes as seriously as code changes. Where possible, manage infrastructure through IaC and CI/CD (with review and IaC scanning) rather than ad hoc console clicks, and alert on manual changes as a signal, not just an audit artifact.
- Revisit default settings explicitly. Many provider defaults have improved over time (e.g., S3 Block Public Access is now default-on for new buckets), but older resources and non-default services may still need explicit hardening.
- Cross-reference with container and Kubernetes security (Container and Kubernetes Security) when workloads run on managed Kubernetes (EKS/AKS/GKE) — cloud IAM and Kubernetes RBAC intersect at the node/pod identity layer (IRSA, Workload Identity, pod-managed identities) and both must be hardened together.
References
- AWS — Shared Responsibility Model
- Microsoft Azure — Shared Responsibility in the Cloud
- Google Cloud — Shared Responsibility and Shared Fate
- CIS Benchmarks
- Cloud Security Alliance — Top Threats to Cloud Computing (Pandemic/Egregious Eleven)
- Cloud Security Alliance — Cloud Controls Matrix (CCM)
- AWS — Security Best Practices in IAM
- NIST SP 800-144 — Guidelines on Security and Privacy in Public Cloud Computing