AWS SMM Assessment Tool: đánh giá posture trong một chiều

TL;DR

• React SPA thuần client-side (OSS Mode with no Amplify initialization) — câu trả lời nằm trong localStorage, không gửi ra server.
• Đi qua 4 giai đoạn SMM (Quick Wins → Foundational → Efficient → Optimized), xuất ra assessment.json để bảo toàn state + remediation.xlsx để nhập vào backlog.
• Không cần credential AWS, không xác minh thực tế — phải đi cặp với Prowler hoặc Security Hub để đối chiếu câu trả lời tự đánh giá với cấu hình thật.
• Đừng làm hết 4 giai đoạn trong một buổi; workshop 2 tiếng đủ Quick Wins + nửa Foundational, và export JSON là checkpoint duy nhất.
• Commit JSON vào repo private với ngày trong tên file (ví dụ smm-assessment-2026-05-04.json) — đây là cách duy nhất có lịch sử phiên bản.
• Ánh xạ Excel sang tracker: Phase → Epic, Domain → Label, Not Started ưu tiên hơn In Progress; kiểm soát không có người phụ trách sau 2 tuần = không bao giờ xong.
• Giá trị nằm ở nhịp định kỳ, không phải lần đánh giá đầu — re-assessment hàng quý mới ra xu hướng; lần một chỉ là audit.

AWS vừa có một web app miễn phí dùng để tự đánh giá security posture theo AWS Security Maturity Model: assessment-tool.maturitymodel.security.aws.dev. Bài này mình ghi lại cách tool hoạt động, quy trình khi dùng cho một AWS Organization nhiều account, những gì nó xuất ra (JSON, kế hoạch khắc phục Excel), và các đánh đổi thực tế so với cách làm thủ công bằng spreadsheet hay so với scanner CSPM. Mục tiêu là giúp bạn quyết định có nên đưa nó vào vòng đánh giá bảo mật định kỳ của mình hay không.

Bối cảnh

AWS Security Maturity Model (SMM) — hiện đã lên v2 — là một framework có định hướng rõ ràng, được soạn bởi team AWS Security specialist, qua peer review, hiện có hơn 100 AWS Solutions Architect dùng và đã vượt 50.000 người dùng trong năm đầu. Nó nằm cạnh Well-Architected Framework và Cloud Adoption Framework nhưng khác về mục tiêu. Well-Architected hỏi “workload này có được thiết kế tốt không?”. Cloud Adoption hỏi “tổ chức có sẵn sàng lên cloud không?”. SMM thì trả lời một câu cụ thể hơn: sắp xếp kiểm soát bảo mật của AWS theo thứ tự nên làm trước — làm sau, dựa trên tỷ lệ tác động/công sức.

Cấu trúc là một ma trận giai đoạn × kiểm soát: 4 giai đoạn, mỗi giai đoạn chứa 16–20 kiểm soát cụ thể (ví dụ Multi-Factor Authentication, Zero Trust Access, Chaos Engineering), mỗi kiểm soát liên kết tới một trang triển khai chi tiết.

• Quick Wins — những hành động tác động cao có thể làm trong một vài ngày: bật MFA cho root, cấu hình security contact, bật GuardDuty, bật CloudTrail Organization trail.
• Foundational — hạ tầng bảo mật lõi: IAM Identity Center, SCP, KMS CMK, phân đoạn mạng VPC, tập trung log.
• Efficient — năng lực nâng cao: guardrail infrastructure-as-code, pipeline DevSecOps, phát hiện tuỳ biến, khắc phục tự động.
• Optimized — thực hành trưởng thành: zero-trust access, red/blue team, chaos engineering, tự động hoá tuân thủ liên tục.

Mô hình thì ai cũng đọc được dưới dạng tài liệu web. Vấn đề là: khi một tổ chức có 50 account và 10 business unit, đọc tài liệu xong rồi tự ngồi đánh giá từng kiểm soát trên từng account là một công việc dễ bị bỏ dở. Đây là chỗ assessment tool ra đời để giải quyết.

Vấn đề

Trước khi có assessment tool, mình tự đánh giá maturity bằng một spreadsheet dài 200 dòng, mỗi dòng một kiểm soát, 4 cột trạng thái theo giai đoạn. Cách làm đó có ba điểm đau rõ rệt:

1. Spreadsheet drift. Mỗi quý mở file ra cập nhật, không nhớ lần trước dùng bản nào, và mỗi khi chia sẻ qua email cho bên liên quan để xác nhận là có thêm một bản sao trôi nổi. Kết quả cuối cùng thường là một file tên assessment-final-v3-real-FINAL.xlsx.
2. Không có chuẩn hoá chấm điểm. “Partially implemented” mỗi lần đánh giá lại hiểu khác nhau. Kiểm soát Enable GuardDuty in all regions lần trước tick “done” khi bật ở 3/17 region, lần sau đòi đủ 17/17 mới tick — làm số liệu giữa các quý không so sánh được.
3. Đầu ra không hành động được. Xuất ra PDF gửi lãnh đạo thì đẹp, nhưng kỹ sư nhận về không biết bắt đầu từ đâu — không có người phụ trách khắc phục, không có ước lượng công sức, không có liên kết tới runbook.

Những giải pháp nửa vời không đủ:

• AWS Trusted Advisor / Security Hub findings: quét được trạng thái thực tế nhưng chỉ dừng ở “có/không”, không xếp theo giai đoạn maturity và không hỏi về quy trình (ví dụ: “có incident response playbook và đã chạy tabletop chưa?” thì scanner không trả lời được).
• Prowler / ScoutSuite: xuất sắc cho kiểm soát kỹ thuật, nhưng chỉ đánh giá những gì chạy được trên AWS API. Quản trị, rủi ro bên thứ ba, quy trình IR thì ngoài phạm vi.
• AWS Well-Architected Tool trong Console: cho từng workload, không cho toàn bộ tổ chức, và câu hỏi không ánh xạ 1-1 với các giai đoạn của SMM.

Assessment tool này lấp khoảng trống đó: nó là một bộ câu hỏi có hướng dẫn đi theo cấu trúc của SMM, với trạng thái quản lý được, xuất có cấu trúc, và chạy hoàn toàn trên trình duyệt người dùng.

Kiến trúc

Quan sát từ HTML và bundle JS, tool là một React SPA thuần client-side. Comment trong HTML ghi rõ Version: 2.0.1 - OSS Mode with no Amplify initialization — tức phiên bản hiện hành bỏ toàn bộ call backend, không gửi dữ liệu ra ngoài sau khi trang tải xong.

[browser]
   │
   ├── React app (Vite bundle)
   │     ├── questionnaire UI (per-phase, per-domain)
   │     ├── scoring engine
   │     └── state → localStorage / in-memory
   │
   ├── jsonExportGenerator     → download assessment.json
   └── excelRemediationGenerator → download remediation.xlsx

Thành phần	Mục đích	Công nghệ quan sát được
Host	Hosting tĩnh công khai	*.security.aws.dev phía sau CloudFront
Frontend	SPA	React + Vite (assets/index-*.js, modulepreload)
UI kit	Thư viện component	Bundle tên ui-libs, forms, charts
Module AWS-specific	Logic phân loại theo dịch vụ	aws-core, aws-security, aws-management, aws-infrastructure, aws-data
Xuất dữ liệu	JSON + Excel	jsonExportGenerator, excelRemediationGenerator
Trạng thái	Chỉ phía client	OSS Mode with no Amplify initialization
CSP	Tối thiểu	<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Điểm cần lưu ý về threat model: vì không có backend, không có lưu trữ phía server. Refresh trình duyệt sau khi xoá storage là mất dữ liệu. Đây vừa là ưu điểm (không rò rỉ dữ liệu) vừa là nhược điểm (không có lịch sử phiên bản, không chia sẻ được link giữa team).

Triển khai

Dưới đây là quy trình mình dùng cho một AWS Organization hạ tầng doanh nghiệp — khoảng 30 account, 6 business unit.

1. Chuẩn bị input trước khi mở tool

Tool sẽ hỏi nhiều câu cần sự tham gia của nhiều team. Mở tool ra rồi mới đi hỏi từng người là nhanh bỏ dở. Chuẩn bị sẵn:

• Từ đội platform / landing zone: danh sách account, cấu trúc OU, SCP hiện có, region đang dùng.
• Từ đội identity: có dùng IAM Identity Center không, có SSO không, IAM user còn lại bao nhiêu, mức độ phủ MFA.
• Từ security ops: trạng thái GuardDuty / Security Hub / Config, đích đến CloudTrail, chính sách lưu trữ.
• Từ đội ứng dụng: cổng bảo mật CI/CD, quét IaC, quét secret.
• Từ đội IR: có playbook không, tần suất tabletop, mục tiêu thời gian phát hiện / thời gian phản hồi.

Mất khoảng 1–2 ngày đi hỏi. Không chuẩn bị bước này, điểm sẽ sai lệch theo hướng lạc quan vì người đánh giá tự trả lời “chắc là có”.

2. Chạy đánh giá

1. Vào https://assessment-tool.maturitymodel.security.aws.dev/
2. Chọn giai đoạn: Quick Wins → Foundational → Efficient → Optimized
3. Trong mỗi giai đoạn, trả lời từng domain (IAM, Detective, Infra, Data, IR, AppSec, Resilience)
4. Mỗi câu 3-4 mức: Not Started / In Progress / Implemented / N/A
5. Lưu tạm qua Export JSON

Kinh nghiệm: đừng cố làm cả 4 giai đoạn trong một buổi. Một workshop 2 tiếng đủ cho Quick Wins + một nửa Foundational. Phần còn lại để buổi khác, giữa các buổi thì xuất JSON để không mất trạng thái.

3. Nhập lại và hoàn thiện

1. Mở tool lại ở buổi sau
2. Nhập JSON đã xuất
3. Tiếp tục từ chỗ dừng
4. Cuối cùng: xuất JSON (nguồn sự thật) + xuất Excel (kế hoạch khắc phục)

JSON nên commit vào một repo private, có ngày tháng trong tên file (smm-assessment-2026-05-04.json). Đây là cách tốt nhất để có lịch sử phiên bản mà tool không hỗ trợ sẵn.

4. Biến đầu ra thành backlog

File Excel xuất ra liệt kê các kiểm soát chưa triển khai, sắp xếp theo giai đoạn. Nhập file này vào tracker (Jira, Linear, GitHub Issues) với ánh xạ:

• Phase → Epic
• Domain → Label
• Mỗi kiểm soát chưa xong → Story hoặc Task
• Not Started → ưu tiên cao hơn In Progress

Gán người phụ trách ngay trong buổi họp read-out với bên liên quan. Kiểm soát không có người phụ trách sau 2 tuần = kiểm soát không bao giờ xong.

Cân nhắc bảo mật

Vì tool chạy trên trình duyệt của người đánh giá, có mấy điểm cần lưu ý:

Dữ liệu được lưu ở đâu. Bundle có dấu hiệu rằng trạng thái nằm ở client (localStorage hoặc in-memory). Câu trả lời của bạn về “GuardDuty có bật không” hay “team có IR playbook không” bản thân nó không phải secret, nhưng khi xuất ra JSON và gửi qua email/Slack thì file đó nên coi là chỉ dùng nội bộ: nó tiết lộ chính xác những khoảng trống bảo mật của tổ chức, là một lộ trình tiện lợi cho kẻ tấn công nếu rò rỉ.

Không gắn thông tin xác thực AWS. Tool không yêu cầu access key, không gọi AWS API. Khác với Prowler, Security Hub, hay AWS Well-Architected Tool, nó không xác minh thực tế — bạn trả lời “GuardDuty bật ở 17 region” thì tool tin bạn. Điều này có nghĩa: đừng tự đánh giá một mình. Luôn đi cặp với một scanner (Prowler, Security Hub) để đối chiếu câu trả lời với trạng thái thực.

Không chia sẻ link có dữ liệu nhúng. Vì trạng thái chỉ nằm ở client, không có cách nào “chia sẻ link tới đánh giá đã điền một nửa”. Đừng mất thời gian tìm. Cách vòng qua là xuất JSON rồi gửi file.

CSP của tool là tối thiểu, chỉ có upgrade-insecure-requests. Không phải lỗ hổng, nhưng bạn đang tin vào AWS để không serve script độc hại từ domain *.security.aws.dev. Mức độ tin cậy đó với mình là chấp nhận được, nhưng nên ghi nhận trong threat model nội bộ.

Vận hành

Đánh giá một lần thì giá trị tức thời, nhưng để có giá trị dài hạn thì cần đưa vào nhịp định kỳ:

• Đánh giá lại hàng quý. Mỗi quý mình ngồi xuống, nạp JSON cũ, cập nhật trạng thái mới. 30 phút nếu ít thay đổi, 2 tiếng nếu có đổi landing zone.
• Kích hoạt theo sự kiện. Sau mỗi lần đưa một dịch vụ AWS mới vào production (ví dụ thêm Redshift cluster), hoặc sau sự cố, đánh giá lại phần liên quan.
• Chỉ số theo dõi. Ghi nhận số kiểm soát Not Started giảm qua từng quý. Nếu số đó không giảm trong 2 quý liên tiếp, đánh giá đang thành checklist điền form chứ không còn thúc đẩy hành động.
• Báo cáo lãnh đạo. Xuất Excel, lọc Not Started trong Quick Wins → gửi CISO. Quick Wins mà chưa xong sau 6 tháng là một cuộc trò chuyện cần có với lãnh đạo.
• Runbook tham chiếu. Mỗi kiểm soát chưa xong nên có liên kết tới runbook nội bộ hoặc tài liệu AWS chính thức trong mô tả của ticket. Nếu không có, kỹ sư sẽ google và có thể lạc.

Đánh đổi

Quyết định	Lựa chọn	Mình chọn	Vì
Tool client-only vs có backend lưu đánh giá	Client-only (như hiện tại)	Client-only	Không có rủi ro chia sẻ dữ liệu, không cần cấp account. Đánh đổi: tự quản phiên bản.
Tự đánh giá vs dựa vào scanner	Cả hai, bổ trợ	Tool SMM + Prowler / Security Hub	Tool bắt được governance/quy trình; scanner bắt được drift kỹ thuật. Một cái không đủ.
Đánh giá một mình (1 người bảo mật) vs workshop nhiều team	Workshop	Workshop	Câu hỏi chạm 4-5 team. Một mình sẽ lạc quan thiên lệch. Đánh đổi: mất 1 ngày họp.
Commit JSON vào repo vs giữ trên laptop	Commit repo private	Commit repo	Audit trail, so sánh giữa các quý. Đánh đổi: cần xử lý repo đó như nhạy cảm nội bộ.
Làm toàn bộ 4 giai đoạn cùng lúc vs cuốn chiếu	Cuốn chiếu	Quick Wins → Foundational trước	Quick Wins có ROI cao nhất. Làm hết Optimized trước khi MFA root bật là sai thứ tự.
Coi đầu ra là lộ trình vs coi là báo cáo	Lộ trình	Lộ trình (có người phụ trách, có deadline)	Báo cáo không ai đọc. Lộ trình có ticket sẽ được làm.

Bài học

• Tool này thay spreadsheet, không thay scanner. Nếu đang kỳ vọng nó quét AWS account của bạn và tự điền — sai kỳ vọng. Nó là một khung hỏi đáp có cấu trúc.
• Giá trị nằm ở nhịp định kỳ, không phải ở lần đánh giá đầu tiên. Lần một mất 4 tiếng nhưng thấy nhiều khoảng trống dễ vá. Từ lần hai trở đi mới thấy xu hướng: domain nào đang cải thiện, domain nào dậm chân.
• Đừng tự điền một mình. Câu hỏi về IR, DevSecOps, tuân thủ nằm ngoài phạm vi hiểu biết của một kỹ sư bảo mật đơn lẻ. Workshop với đội platform, appsec, IR cho kết quả chính xác hơn rất nhiều.
• Xuất JSON là checkpoint chính. Bảo toàn trạng thái giữa các buổi, so sánh giữa các quý, nhập lại vào tool. Coi nó như file migration.
• Quick Wins trước, không thương lượng. Nếu root account chưa có MFA, không đáng bàn về red team. Thứ tự giai đoạn là cố ý.

Tham khảo

• AWS Security Maturity Model — trang tài liệu gốc mô tả từng giai đoạn và kiểm soát.
• AWS Security Maturity Model Assessment Tool — chính là tool của bài này.
• AWS Well-Architected Framework — Security Pillar — framework bổ sung, đánh giá theo workload.
• Prowler — scanner mình dùng để đối chiếu trạng thái kỹ thuật với câu trả lời tự đánh giá.
• CIS AWS Foundations Benchmark — checklist khác, nhiều kiểm soát trùng với giai đoạn Foundational của SMM.