AWS Security Maturity Model v2: 4 phase áp dụng thực tế

TL;DR

• SMM v2 xếp 74 kiểm soát thành 4 giai đoạn (Quick Wins 16 / Foundational 20 / Efficient 20 / Optimized 18) theo tỉ lệ tác động/công sức — thứ tự sắp xếp mới là sản phẩm, không phải danh sách.
• Mới trong v2: GenAI Data protection ở Optimized, IAM Data Perimeters/IAM Pipeline/Temporary Elevated Access chuyển lên phase 4, resilience xuyên suốt 4 giai đoạn.
• Giai đoạn 1 phải xong đồng đều mọi account (dùng SCP + StackSets); Giai đoạn 2 theo đợt; Giai đoạn 3 theo BU; Giai đoạn 4 theo năng lực.
• SCP chặn region dùng NotAction miễn trừ service global (iam:*, organizations:*, cloudfront:*, route53:*, sts:*) — miễn trừ sts:* thận trọng, có thể thu hẹp về sts:GetCallerIdentity.
• SCP Block Public Access cần cả s3:PutBucketPublicAccessBlock + s3:PutAccountPublicAccessBlock — chỉ deny một cái là còn đường lách.
• Identity-perimeter SCP phải dùng BoolIfExists (không phải Bool) trên aws:PrincipalIsAWSService — Bool thuần fail closed khi key vắng và để lọt kẻ tấn công.
• Dừng ở phase 3 nếu chưa có đội bảo mật full-time; phase 4 cần độ chín vận hành, không phải checklist.

AWS vừa cập nhật Security Maturity Model lên v2 — một lộ trình có định hướng rõ ràng, chia 74 kiểm soát bảo mật thành 4 giai đoạn, xếp theo tỉ lệ tác động/công sức: Quick Wins → Foundational → Efficient → Optimized. Đây không phải framework tuân thủ mới, cũng không phải Well-Architected phiên bản ngắn gọn. Nó là một cách trả lời câu hỏi mà mọi security lead từng bị hỏi: “có cả trăm thứ phải làm, bắt đầu từ đâu?”. Bài này đi qua cấu trúc của v2, tổng quan từng giai đoạn, những điểm đáng chú ý so với tài liệu AWS khác, và cách mình ánh xạ nó vào một AWS Organization nhiều account trong thực tế. Bài riêng về assessment tool nói về chuyện dùng — bài này nói về chuyện đọc hiểu.

Bối cảnh

Trước khi có SMM, bạn có ba nơi chính để tìm “AWS bảo mật thế nào”:

• AWS Well-Architected — Security Pillar: chi tiết, chính xác, nhưng đánh giá theo từng workload. Không trả lời câu hỏi “tổ chức này đang ở đâu trong hành trình”.
• CIS AWS Foundations Benchmark: checklist cứng, hầu hết là kiểm soát kỹ thuật, không có thứ tự triển khai.
• AWS Prescriptive Guidance: rất nhiều whitepaper, chủ đề rộng, không phải lộ trình duy nhất.

SMM v2 chèn vào giữa những thứ trên với tư thế khác: một lộ trình có ý kiến rõ ràng (opinionated), có thứ tự cụ thể, viết cho người quyết định “làm gì tiếp theo” chứ không phải người triển khai từng kiểm soát. Theo trang chủ, mô hình được soạn bởi team AWS Security specialist, qua peer review, và đã có hơn 50.000 người dùng + hơn 100 AWS Solutions Architect dùng trong năm đầu.

Hình dáng tổng thể là một ma trận:

• Hàng: 4 giai đoạn, mỗi giai đoạn là một mức độ đầu tư tăng dần (ngày → năm).
• Cột: các kiểm soát (74 cái, mỗi giai đoạn 16–20), mỗi kiểm soát liên kết sang một trang chi tiết triển khai.

Điểm mấu chốt: thứ tự có ý nghĩa. Bạn không chọn kiểm soát từ giai đoạn 4 trước vì “nghe hay”. Bạn bò qua giai đoạn 1 trước, vì nếu root account chưa có MFA thì red team là trò xa xỉ.

Vấn đề mà v2 giải quyết tốt hơn v1

Mình không định sa đà vào so sánh v1 vs v2, nhưng có mấy điểm đáng để ý:

1. Thêm kiểm soát về GenAI. Giai đoạn 4 bây giờ có GenAI Data protection — phản ánh việc Bedrock / Q / LLM tự xây đã là một bề mặt tấn công thực tế, không còn là “tương lai”.
2. Tái cấu trúc phần identity. IAM Data Perimeters, IAM Pipeline, Temporary Elevated Access đưa lên Optimized một cách rõ ràng — phản ánh thực tế là data perimeter và JIT access không phải thứ nên cố làm sớm khi tổ chức chưa có SSO.
3. Nhấn mạnh khả năng phục hồi. Evaluate Resilience ở Quick Wins, Disaster Recovery Plan ở Efficient, DR Automation + Chaos Engineering ở Optimized. Resilience không còn là chủ đề riêng mà là cột sống xuyên suốt các giai đoạn.
4. Có assessment tool đi kèm. v1 chỉ có tài liệu. v2 có web tool tự đánh giá xuất JSON + Excel khắc phục — biến tài liệu thành lộ trình có thể theo dõi được.

Giai đoạn 1 — Quick Wins (16 kiểm soát)

Đây là nhóm “làm trong vài ngày, ROI cao”. Danh sách đầy đủ:

1. Assign security contacts
2. Select the regions & block the rest
3. Evaluate Cloud Security Posture
4. Multi-Factor Authentication
5. Root Protection
6. Identity Federation
7. Cleanup unintended access
8. Detect Common Threats
9. Audit API calls
10. Billing alarms
11. Cleanup risky open admin ports
12. Block Public Access
13. Analyze data security posture
14. Act on Critical Findings
15. WAF with managed rules
16. Evaluate Resilience

Đọc kỹ: phần lớn là “bật một cái switch” hoặc “chạy một lần quét”. Cái đắt nhất (con người, không phải tiền) là Cleanup unintended access và Act on Critical Findings — vì chúng yêu cầu đi hỏi từng team xem ai đang thực sự dùng cái gì. Nhưng đây là đầu tư bắt buộc để mọi giai đoạn sau không bị nhiễu.

Hai kiểm soát dễ bị coi nhẹ mà mình thường thấy bỏ qua:

• Select regions & block the rest — dùng SCP aws:RequestedRegion để chặn region không dùng. Không bắt buộc, nhưng nó thu hẹp đáng kể bề mặt tấn công (một account bị xâm nhập chỉ ảnh hưởng 2 region thay vì 17) và là một trong những kiểm soát rẻ nhất trong toàn bộ mô hình.
• Billing alarms — nghe như tài chính chứ không phải bảo mật. Nhưng một cú tăng đột biến chi phí gấp 3 lần bình thường là tín hiệu rất tốt cho việc khai thác crypto-mining sau khi IAM key rò rỉ. Nó là kiểm soát phát hiện đội lốt FinOps.

Giai đoạn 2 — Foundational (20 kiểm soát)

Đây là “hạ tầng lõi” — sau giai đoạn này, tổ chức có baseline bảo mật đủ để ngủ yên:

1. Sec & Regulatory requirements
2. Cloud Security Training Plan
3. Inventory & Config Monitoring
4. Guardrails — Organization policies (SCPs/RCPs)
5. Use Temporary Credentials
6. IMDSv2
7. Advanced Threat Detection
8. Infrastructure vulnerabilities
9. Application Vulnerabilities
10. Limit Network Access
11. Secure EC2 Instances Management
12. Network segmentation (VPCs)
13. Multi-account management
14. Data Encryption at rest
15. Data Backups
16. Discover sensitive data
17. Security in Development
18. No secrets in code
19. Define incident response playbooks
20. Use multiple Availability Zones

Điểm cần đọc kỹ: kiểm soát số 4 — Guardrails với SCP/RCP — là kiểm soát có đòn bẩy lớn nhất giai đoạn này. Một SCP tốt làm được nhiều hơn 10 kiểm soát phát hiện. Ví dụ: deny s3:PutBucketPublicAccessBlock + s3:PutAccountPublicAccessBlock (đủ cặp hai action cấp bucket và cấp account) ở cấp Organization đảm bảo Block Public Access không bị ai vô tình hay cố ý tắt đi — lưu ý đây chỉ bao phủ một đường tấn công, bucket vẫn có thể public qua bucket policy / ACL / website config nếu không có guardrail thêm.

Bẫy thường gặp:

• Áp dụng all-at-once. SCP triển khai nhầm là khoá toàn bộ tổ chức. Luôn kiểm thử trong non-prod OU trước, có phương án rollback, và dùng aws:PrincipalOrgID cẩn thận.
• Chỉ có playbook trên Confluence. Define incident response playbooks không chỉ là viết. Phải có tabletop để xác thực — mà tabletop là kiểm soát của giai đoạn 3 (Run TableTop exercises). Cẩn thận chu trình “viết playbook nhưng không ai thử”.
• Bắt buộc IMDSv2. Nhiều workload cũ (ASG cũ, AMI cộng đồng) mặc định vẫn cho phép IMDSv1. Bắt buộc ở cấp account (per-Region) qua EC2 API ModifyInstanceMetadataDefaults — nếu không, bạn vẫn là mục tiêu của SSRF.

Giai đoạn 3 — Efficient (20 kiểm soát)

Giai đoạn này đòi hỏi tổ chức đã có đội bảo mật chuyên trách, và có văn hoá tự động hoá. Danh sách:

1. Design your secure architecture
2. Use infrastructure as code
3. Tagging Strategy
4. Create your compliance reports
5. Least Privilege Review
6. CIAM: security of your customers
7. Custom Threat Detection — SIEM / Security Lake
8. Security Champions Program
9. DevSecOps: Security in the Pipeline
10. Golden Image Pipeline
11. Anti-Malware / EDR / RP
12. Outbound Traffic Control
13. Encryption in transit
14. Threat Modeling
15. Advanced WAF with Custom Rules
16. DDoS Mitigation (Layer 7)
17. Run TableTop exercises
18. Automate critical playbooks
19. Investigations — Root cause analysis
20. Disaster Recovery Plan

Quan sát:

• IaC và Tagging Strategy nằm cạnh nhau không phải ngẫu nhiên. Tagging chỉ có giá trị khi nó được bắt buộc qua code (IaC + SCP phòng ngừa aws:RequestTag), không phải qua “quy tắc đặt tag” trong wiki.
• Security Champions Program là kiểm soát con người, không phải công cụ. Nó là cách một đội bảo mật 5 người giữ được security posture cho một eng org 200 người — uỷ quyền, không làm nút thắt.
• CIAM ở giai đoạn 3, không sớm hơn. Thứ tự này phản ánh việc tổ chức thường phải lo IAM production trước khi lo customer identity. Nếu bạn xây sản phẩm B2C, có thể bạn cần đẩy cái này lên sớm.

Giai đoạn 4 — Optimized (18 kiểm soát)

Đây là giai đoạn mà phần lớn tổ chức không bao giờ cần tới đầy đủ — và điều đó không sao. Danh sách:

1. Sharing security tasks (RACI)
2. Automate evidence gathering
3. IAM Data Perimeters
4. IAM Pipeline
5. Temporary Elevated Access
6. Threat Intelligence
7. VPC Flow Logs Analysis
8. Vulnerability Management Team
9. Zero Trust Access
10. Using abstract services
11. GenAI Data protection
12. Red Team
13. Blue Team
14. Advanced Automations
15. Security Orchestration & Ticketing (SOAR)
16. Automate deviation correction
17. Disaster Recovery Automation
18. Chaos Engineering

Những kiểm soát thuộc nhóm “kinh điển giai đoạn 4”:

• IAM Data Perimeters: dùng SCP + RCP + VPC endpoint policy để đảm bảo dữ liệu của tổ chức chỉ được truy cập từ identity của tổ chức, qua mạng của tổ chức. Đây là endgame của IAM hardening.
• Zero Trust Access: không chỉ là “bỏ VPN”. Là mô hình truy cập trong đó mọi request được xác minh lại theo identity + device + ngữ cảnh. Cần nền tảng riêng (Verified Access, Identity Center, bên thứ ba như Cloudflare Access).
• GenAI Data protection (mới trong v2): guardrail cho Bedrock / Q / LLM tự xây, audit prompt/response, tách data plane. Không có công thức chuẩn — tuỳ tình huống.

Kiểm soát “dễ hiểu nhầm”:

• Red Team / Blue Team không có nghĩa là thuê pentest 1 năm một lần. Ở giai đoạn này, nó có nghĩa là có đội (hoặc nhân viên) chuyên trách mô phỏng kẻ tấn công và kỹ thuật phòng thủ, chạy liên tục — không phải sự kiện.
• Chaos Engineering nghe liên quan độ tin cậy, nhưng ở SMM nó là security chaos: tiêm lỗi khi rotate credential, mô phỏng cấu hình sai IAM permission boundary, v.v. Đo khả năng phát hiện và phục hồi.

Ánh xạ vào AWS Organization thật

Lý thuyết là 4 giai đoạn tuần tự. Thực tế khi áp vào một AWS Organization 30 account, 5 business unit, mình đã học được:

1. Giai đoạn 1 phải xong đồng đều trên mọi account. Không có chuyện “account payments xong Quick Wins nhưng account marketing chưa”. Kẻ tấn công đi tìm account yếu nhất. Dùng SCP + StackSets để bắt buộc.
2. Giai đoạn 2 có thể triển khai theo đợt. Đợt 1: landing zone lõi + production OU. Đợt 2: dev + staging. Đợt 3: sandbox. Bẫy là sandbox hay bị bỏ vì “không production” — rồi sandbox có credential production đã cache.
3. Giai đoạn 3 nên triển khai theo từng business unit. BU đã có chủ sở hữu rõ ràng thì tự chạy; BU chưa rõ thì cần người làm bảo mật dẫn dắt sát. Đừng cố đồng bộ tiến độ.
4. Giai đoạn 4 triển khai theo năng lực, không theo account. Red Team không gắn với một account cụ thể — nó là năng lực của toàn tổ chức. IAM Data Perimeter thì ngược lại: triển khai per-account nhưng cần SCP cấp Org.
5. Kiểm soát xuyên giai đoạn vào cùng một ticket. Ví dụ: IAM Identity Center (giai đoạn 2 Use Temporary Credentials) + Temporary Elevated Access (giai đoạn 4) + IAM Pipeline (giai đoạn 4) nên là cùng một chương trình identity, không phải 3 dự án tách rời.

Đoạn code thực tế cho 5 kiểm soát quan trọng

Phần này không bao phủ hết 74 kiểm soát, nhưng là code thật mình đã triển khai cho 5 kiểm soát có đòn bẩy cao nhất.

1. SCP — Chặn region không dùng (Giai đoạn 1: Select the regions & block the rest)

Áp ở Organization Root hoặc OU cha, miễn trừ các IAM action global (IAM, Organizations, CloudFront, Route53, STS, Support):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "cloudfront:*",
        "route53:*",
        "sts:*",
        "support:*",
        "waf:*",
        "wafv2:*",
        "shield:*",
        "globalaccelerator:*",
        "networkmanager:*",
        "health:*",
        "artifact:*",
        "chatbot:*",
        "tag:GetResources",
        "aws-portal:*",
        "budgets:*",
        "ce:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-southeast-1",
            "us-east-1"
          ]
        }
      }
    }
  ]
}

Vì sao NotAction: IAM, Organizations, Route53, CloudFront, Shield, Global Accelerator, Cloud WAN v.v. là dịch vụ toàn cầu — call log thường xuất hiện ở us-east-1 và sẽ fail điều kiện nếu bạn không miễn trừ chúng. Lưu ý miễn trừ sts:* ở đây là thận trọng — STS thực tế có endpoint regional, nếu lo kẻ tấn công AssumeRole ở region không cho phép, bạn có thể thu hẹp miễn trừ về sts:GetCallerIdentity và sts:DecodeAuthorizationMessage.

Sơ đồ bên dưới cho thấy SCP được đánh giá như thế nào từ Org Root xuống Account — deny ở bất cứ cấp nào đều chặn request, bất kể IAM policy của user/role:

2. SCP — Giữ S3 Block Public Access không bị gỡ (Giai đoạn 2: Guardrails)

Cần deny cả hai IAM action: s3:PutBucketPublicAccessBlock (cấp bucket — cùng action gate set và delete) và s3:PutAccountPublicAccessBlock (cấp account). Nếu chỉ deny cái đầu, kẻ tấn công vẫn có thể nới lỏng config ở tầng account để lách. Deny cho tất cả role ngoài OrgAdminRole:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PreventPublicAccessBlockTampering",
      "Effect": "Deny",
      "Action": [
        "s3:PutBucketPublicAccessBlock",
        "s3:PutAccountPublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/OrgAdminRole",
            "arn:aws:iam::*:role/aws-service-role/*"
          ]
        }
      }
    }
  ]
}

Có cặp bucket + account block mới là guardrail đủ — chỉ cần một trong hai tầng bị nới lỏng là public-by-default quay lại.

3. Terraform — Bắt buộc IMDSv2 cấp account (Giai đoạn 2: IMDSv2)

Dùng EC2 API ModifyInstanceMetadataDefaults. Cần AWS provider v5.70+ (Terraform core 1.5+ là đủ):

resource "aws_ec2_instance_metadata_defaults" "imdsv2_only" {
  http_tokens                 = "required"   # IMDSv2 mandatory
  http_put_response_hop_limit = 2
  http_endpoint               = "enabled"
  instance_metadata_tags      = "enabled"
}

Quan trọng: mặc định này theo từng region. Triển khai tất cả region bạn dùng (xem SCP ở mục 1 cho danh sách). CloudFormation hiện chưa có resource có sẵn — phải dùng Custom::* Lambda-backed resource gọi EC2 SDK.

4. SCP — Bắt buộc tag khi tạo tài nguyên (Giai đoạn 3: Tagging Strategy)

Yêu cầu tag CostCenter và Owner khi tạo EC2 instance, EBS volume, RDS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireTagsOnCreate",
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances",
        "ec2:CreateVolume",
        "rds:CreateDBInstance"
      ],
      "Resource": [
        "arn:aws:ec2:*:*:instance/*",
        "arn:aws:ec2:*:*:volume/*",
        "arn:aws:rds:*:*:db:*"
      ],
      "Condition": {
        "Null": {
          "aws:RequestTag/CostCenter": "true",
          "aws:RequestTag/Owner": "true"
        }
      }
    }
  ]
}

Null trả về true khi key không được cung cấp — deny khi thiếu tag. Với S3 bucket thì dùng s3:CreateBucket + điều kiện khác vì S3 tag đi qua API riêng.

Lưu ý: SCP này chỉ bắt buộc tại thời điểm tạo. Nếu caller tạo tài nguyên không tag rồi gọi ec2:CreateTags / rds:AddTagsToResource để tag sau, nó sẽ lách. Để vá: deny thêm mấy action AddTags* khi aws:ResourceTag/<key> chưa có, hoặc dùng aws:TagKeys với ForAllValues:StringEquals để ràng buộc tag key được phép đặt.

5. Data Perimeter — SCP identity perimeter (Giai đoạn 4: IAM Data Perimeters)

Đảm bảo mọi request lên S3/KMS/… trong account phải đến từ identity của Organization:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessFromNonOrgIdentities",
      "Effect": "Deny",
      "Action": [
        "s3:*",
        "kms:*",
        "secretsmanager:*",
        "dynamodb:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:PrincipalOrgID": "o-xxxxxxxxxx"
        },
        "BoolIfExists": {
          "aws:PrincipalIsAWSService": "false"
        }
      }
    }
  ]
}

Lưu ý quan trọng: BoolIfExists thay vì Bool là bắt buộc. aws:PrincipalIsAWSService vắng mặt với mọi principal không phải AWS service (IAM user, role, account ngoài) — dùng Bool thuần thì điều kiện fail closed và deny không kích hoạt đúng lúc cần (chính kẻ tấn công bên ngoài). Đây là lỗi phổ biến khi tự viết data perimeter; AWS sample dùng BoolIfExists để xử lý đúng trường hợp này.

Đây chỉ là identity perimeter — một trong ba lớp của data perimeter. Cần bổ sung resource perimeter (resource-based policy trên bucket/key, chặn identity ngoài org) và network perimeter (VPC endpoint policy). Đủ 3 lớp mới gọi là Data Perimeter hoàn chỉnh.

Tham khảo triển khai đủ 3 lớp: AWS Data Perimeter — reference policies.

Bẫy thường gặp khi đọc SMM v2

• Dùng SMM như framework tuân thủ. Không phải. Nó không thay ISO 27001 / SOC 2 / PCI. Nó là lộ trình kỹ thuật để đạt posture, không phải audit trail. Tuân thủ đi song song.
• Cherry-pick kiểm soát từ giai đoạn 4. “Công ty mình làm Zero Trust Access thôi, bỏ qua giai đoạn 1–2”. Sớm hay muộn sẽ có sự cố chứng minh bạn sai.
• Coi ‘Optimized’ là mục tiêu cuối của mọi tổ chức. Không phải. Một startup 10 người không cần Red Team + Chaos Engineering. Biết dừng đúng chỗ là một kỹ năng.
• Không theo dõi việc triển khai lại. Kiểm soát không phải “tick một lần xong mãi”. MFA có thể tick xong hôm nay, 6 tháng sau có service account mới không MFA, rà soát lại.
• Không ánh xạ vào backlog thật. Đọc xong 74 kiểm soát, gật gù, đóng tab. Không có ticket, không có người phụ trách, không có deadline = không có gì xảy ra.

Đánh đổi

Câu hỏi	Lựa chọn	Mình chọn	Vì
Đi theo SMM v2 hay tự xây maturity model riêng?	Theo SMM	Theo SMM	Team AWS soạn, qua peer review, cộng đồng lớn — tự xây chỉ nên khi có lý do cụ thể.
Coi SMM là đủ hay kết hợp với CIS / Well-Architected?	Kết hợp	SMM làm lộ trình, CIS + WA làm checklist kiểm tra	SMM có ý kiến về thứ tự, CIS có ý kiến về cụ thể, WA có ý kiến về workload.
Theo dõi kiểm soát trong spreadsheet hay tool?	Tool (assessment tool chính chủ)	Tool	Spreadsheet drift nhanh, không có lịch sử phiên bản có cấu trúc.
Làm toàn bộ giai đoạn 1 trước khi đụng giai đoạn 2, hay song song?	Giai đoạn 1 trước	Giai đoạn 1 trước	Giai đoạn 1 rẻ và ROI cao, hoàn thành xong thì phát hiện drift ở các giai đoạn sau dễ hơn.
Theo đuổi giai đoạn 4 hay dừng ở giai đoạn 3?	Tuỳ tổ chức	Dừng ở giai đoạn 3 nếu không có đội bảo mật toàn thời gian	Giai đoạn 4 cần độ chín vận hành, không phải checklist tính năng.
Đánh giá lại theo quý hay theo năm?	Quý	Quý	Dịch vụ AWS thay đổi quá nhanh; năm là quá lâu.

Bài học

• Thứ tự là sản phẩm chính của SMM, không phải bản thân kiểm soát. Nhiều người tưởng giá trị nằm ở danh sách. Không — danh sách CIS / Well-Architected cũng có. Giá trị nằm ở việc AWS đã sắp xếp sẵn theo tác động/công sức.
• 74 kiểm soát không phải 74 dự án. Nhiều kiểm soát nên gom thành chương trình (identity, threat detection, resilience) để tránh silo.
• Đầu tư vào Quick Wins phải là quý đầu tiên. Đưa ra lộ trình 1 năm với Quick Wins trải đều là triệu chứng sai mô hình.
• Phần lớn giá trị của SMM đến ở lần đánh giá lại thứ ba. Lần đầu thấy khoảng trống, lần hai thấy tiến độ, lần ba thấy xu hướng. Nếu dừng sau lần 1 thì mới chỉ là audit.
• Viết bản tiếng Việt cho bên liên quan nội bộ nếu cần. Mô hình bằng tiếng Anh, nhưng CTO / CISO người Việt hiểu tiếng Việt sẽ ra quyết định nhanh hơn. Đây không phải lười dịch — là giảm ma sát.

Tham khảo

• AWS Security Maturity Model v2 — trang tài liệu chính thức, nguồn sự thật cho danh sách kiểm soát.
• AWS Security Maturity Model Assessment Tool — web app tự đánh giá đi kèm mô hình.
• Bài riêng về assessment tool — quy trình dùng tool, xuất JSON/Excel, đánh đổi.
• AWS Well-Architected Framework — Security Pillar — đánh giá theo workload, bổ sung cho SMM.
• CIS AWS Foundations Benchmark — checklist cứng, nhiều kiểm soát trùng với giai đoạn Foundational.
• AWS Prescriptive Guidance — Security — tài liệu sâu cho từng kiểm soát.