AWS Security & Encryption: Bản đồ KMS, Secrets, ACM, WAF, Shield, GuardDuty và cách chọn đúng service

Bạn vừa đưa một ứng dụng fintech lên AWS. Tuần sau, đội security đến review và để lại một danh sách câu hỏi khiến bạn toát mồ hôi:

1. “Dữ liệu khách hàng trong S3 và RDS được mã hóa chưa? Khóa mã hóa ai giữ, xoay vòng thế nào, ai có quyền dùng?”
2. “Mật khẩu database và API key đang nằm ở đâu? Đừng nói là hardcode trong code hay biến môi trường nhé. Chúng có tự động xoay vòng không?”
3. “Endpoint public của bạn chống SQL injection và DDoS ra sao? Lỡ bị flood 100 Gbps thì sao?”
4. “Và quan trọng nhất: nếu ngay lúc này có một instance bị chiếm quyền đào coin, hoặc một bucket S3 đang rò rỉ số CMND khách hàng, bạn có biết không?”

Bốn câu hỏi, bốn vấn đề hoàn toàn khác nhau — và AWS không có một service nào giải quyết được cả bốn. Thay vào đó là cả một họ dịch vụ, mỗi cái sinh ra để bịt một lỗ hổng cụ thể: mã hóa và quản lý khóa, lưu trữ secrets, phòng thủ ở biên, và phát hiện mối đe dọa.

Đây cũng chính là kiểu bẫy yêu thích của đề thi SAA: cho một tình huống (“cần mã hóa mà phải tự kiểm soát khóa trong thiết bị phần cứng”, “cần tự động xoay mật khẩu RDS”, “cần tìm PII trong S3”) rồi đưa ra bốn phương án nghe đều hợp lý, và bạn phải chọn đúng một. Ranh giới giữa các service mới là thứ được kiểm tra.

Bài viết này là tấm bản đồ giúp bạn phân biệt chúng. Với mỗi dịch vụ, mình sẽ đi qua: nó giải quyết vấn đề gì, tính năng cốt lõi, use case thực tế, và những điểm hay bị hỏi trong phòng thi.

Lưu ý: Đây là góc nhìn overview để xây mental model và nhận diện nhanh khi đi thi. Mỗi dịch vụ ở đây (đặc biệt là KMS, WAF) đủ sức viết thành một bài deep-dive riêng; bài này tập trung vào ranh giới giữa chúng và lý do tồn tại của từng cái.

1. Bức tranh tổng thể: 4 nhóm phòng thủ

Trước khi đi vào chi tiết, hãy ghim khung tư duy này. Toàn bộ các dịch vụ trong nhóm Security & Encryption rơi vào bốn nhóm, mỗi nhóm trả lời một câu hỏi khác nhau:

Cần phân biệt hai loại dịch vụ bảo mật, vì đề thi rất hay dựa vào ranh giới này:

• Preventive (phòng ngừa): ngăn chuyện xấu xảy ra — mã hóa, WAF chặn request, IAM giới hạn quyền.
• Detective (phát hiện): phát hiện chuyện xấu đã hoặc đang xảy ra — GuardDuty, Inspector, Macie. Chúng không chặn, chúng báo.

Giữ khung này trong đầu, giờ ta đi qua từng nhóm.

2. Encryption 101: ba kiểu mã hóa cần phân biệt

Trước khi nói về service, phải nắm nền tảng: dữ liệu có thể bị tấn công ở hai thời điểm — khi đang truyền trên đường mạng, và khi đang nằm yên trên đĩa. Tương ứng có ba kiểu mã hóa, và mỗi kiểu trả lời một câu hỏi “ai giữ khóa, ai mã hóa”.

Encryption in flight (mã hóa khi truyền) bảo vệ dữ liệu trên đường đi giữa client và server. Dữ liệu được mã hóa trước khi rời máy gửi và chỉ giải mã sau khi tới máy nhận, nên kẻ nghe lén ở giữa (tấn công MITM) chỉ thấy mớ byte vô nghĩa. Đây chính là TLS/SSL, là thứ đứng sau HTTPS. Khóa nằm ở chứng chỉ TLS — và đây là nơi ACM xuất hiện (mục 6).

Server-side encryption at rest (mã hóa phía server khi lưu) bảo vệ dữ liệu nằm yên trên đĩa. Server nhận dữ liệu thô, tự mã hóa rồi mới ghi xuống đĩa, và tự giải mã trước khi trả về cho client. Khóa do server quản lý — trên AWS thường là KMS. Đây là cơ chế đằng sau SSE-S3, SSE-KMS, mã hóa EBS volume, mã hóa RDS. Điểm mấu chốt: server có thấy dữ liệu thô tại thời điểm xử lý.

Client-side encryption (mã hóa phía client) thì ngược lại: client tự mã hóa trước khi gửi đi, và server không bao giờ thấy dữ liệu thô — nó chỉ lưu mớ ciphertext. Client tự quản lý khóa (có thể nhờ KMS qua kỹ thuật envelope encryption). Dùng khi bạn không tin tưởng cả phía lưu trữ, hoặc cần đảm bảo dữ liệu mã hóa đầu-cuối.

3. AWS KMS — trái tim của mã hóa trên AWS

AWS Key Management Service (KMS) là dịch vụ quản lý khóa mã hóa, được tích hợp sẵn với gần như mọi dịch vụ AWS cần mã hóa at-rest (S3, EBS, RDS, DynamoDB, Secrets Manager…).

Thay vì bạn tự tạo và bảo quản khóa, KMS giữ khóa trong một hệ thống được kiểm soát chặt, cho phép bạn cấp/thu quyền dùng khóa qua IAM, và ghi lại mọi lần dùng khóa vào CloudTrail để audit.

3.1. Các loại khóa và quyền sở hữu

KMS có hai loại khóa xét theo thuật toán:

• Symmetric (đối xứng): một khóa duy nhất (AES-256) dùng cho cả mã hóa lẫn giải mã. Khóa không bao giờ rời KMS ở dạng thô — bạn phải gọi API KMS để dùng nó. Đây là loại mặc định, được hầu hết dịch vụ AWS dùng.
• Asymmetric (bất đối xứng): cặp khóa public/private (RSA hoặc ECC). Public key tải về được để mã hóa hoặc xác minh chữ ký bên ngoài AWS; private key ở lại trong KMS. Dùng khi bên gọi không thể gọi API KMS (ví dụ mã hóa từ ngoài AWS), hoặc cho nghiệp vụ ký/xác minh (sign/verify).

Key Policies là điểm dễ sập bẫy. Mỗi KMS key có một resource-based policy gắn trực tiếp lên khóa, và không ai truy cập được khóa nếu policy không cho phép — kể cả root account. Có hai kiểu:

• Default key policy: trao toàn quyền cho account, ủy thác việc phân quyền cho IAM (giống các resource khác).
• Custom key policy: bạn liệt kê tường minh user/role nào được dùng khóa — bắt buộc khi cần chia sẻ khóa cross-account.

3.2. Master key, Data Key, giới hạn 4 KB và Envelope Encryption

Một giới hạn cốt lõi: mỗi lần gọi API Encrypt/Decrypt trực tiếp của KMS chỉ xử lý tối đa 4 KB dữ liệu. Vậy mã hóa một file 1 GB thì sao? Để trả lời, cần nắm khái niệm data key và mô hình khóa hai tầng của KMS.

• KMS key (master key) là khóa gốc không bao giờ rời KMS. Nó không trực tiếp mã hóa dữ liệu của bạn, nhiệm vụ chính là mã hóa và giải mã các Data Encryption Key.
• Data Encryption Key (data key) là khóa do KMS sinh ra theo yêu cầu để mã hóa dữ liệu thật. Đây mới là khóa trực tiếp làm việc với dữ liệu của bạn, và bản thân nó lại được KMS key bảo vệ.

Cơ chế kết hợp hai tầng khóa này gọi là envelope encryption (mã hóa kiểu phong bì): dữ liệu nằm trong “phong bì” được khóa bởi data key, còn data key lại nằm trong một “phong bì” lớn hơn được khóa bởi KMS key. Đây là kỹ thuật xuất hiện rất nhiều trong đề thi.

Quy trình Envelope Encryption:

1. GenerateDataKey trả về hai thứ: data key ở dạng thô (plaintext) để bạn dùng ngay, và chính data key đó ở dạng đã được mã hóa bởi KMS key (gọi là encrypted data key).
2. Bạn dùng data key thô để mã hóa khối dữ liệu lớn ngay trên máy mình (không qua mạng, không vướng giới hạn 4 KB), rồi xóa data key thô khỏi bộ nhớ càng sớm càng tốt.
3. Bạn lưu encrypted data key nằm cạnh ciphertext. Khi cần giải mã, gọi Decrypt gửi encrypted data key cho KMS để lấy lại data key thô, rồi tự giải mã dữ liệu.

Điểm cần nhớ: thấy đề nhắc tới dữ liệu lớn hơn 4 KB → nghĩ ngay tới envelope encryption / GenerateDataKey.

Vậy vì sao lại cần tách biệt master key và data key? Đây là một giải pháp tổng thể. Một phần của giải pháp nằm ở việc offload 1 phần workload encrypt/decrypt nặng nề xuống client. Việc encrypt/decrypt 1 object lớn là tốn kém, giải pháp data key này cho phép quá trình encrypt/decrypt có thể diễn ra ở client.

3.3. Key Rotation, region-scope và throttling

Key rotation (xoay vòng khóa) là thay khóa định kỳ để giảm thiệt hại nếu khóa lộ:

• AWS Managed Keys: tự động xoay mỗi năm một lần, bạn không can thiệp.
• Customer Managed Keys: xoay tự động là tùy chọn. Từ tháng 4/2024, AWS cho phép cấu hình chu kỳ linh hoạt từ 90 ngày đến 2560 ngày (mặc định 365 ngày) và còn xoay theo yêu cầu (on-demand) bất cứ lúc nào.
• Khóa import: không xoay tự động được, phải làm thủ công.

Điểm tinh tế và rất hay được hỏi: tại sao xoay khóa mà dữ liệu cũ vẫn giải mã được?

Khi KMS xoay một khóa, nó sinh ra một backing key mới nhưng vẫn giữ lại toàn bộ các backing key cũ. Quan trọng nhất: Key ID và ARN không hề đổi, vỏ cũ nhưng ruột mới. Mỗi ciphertext (hoặc mỗi encrypted data key) mang theo metadata ghi rõ nó được mã hóa bằng phiên bản backing key nào. Khi giải mã, KMS đọc metadata đó và tự chọn đúng backing key tương ứng:

• Dữ liệu cũ: dùng lại backing key cũ để giải mã.
• Dữ liệu mới: mã hóa bằng backing key mới.

Key rotation không mã hóa lại dữ liệu cũ. Dữ liệu cũ vẫn được mã hoá bằng backing key cũ cho tới khi bạn chủ động re-encrypt (ví dụ gọi API ReEncrypt). Và vì ứng dụng chỉ tham chiếu khóa qua Key ID không đổi, toàn bộ quá trình này trong suốt — bạn không cần sửa code hay cấu hình gì.

KMS key là một regional resource — khóa không thể rời region của nó (ngoại lệ là Multi-Region Keys). Khi copy snapshot mã hóa sang region khác, bạn phải re-encrypt bằng khóa của region đích.

KMS có giới hạn số request/giây. Khi vượt, API trả về ThrottlingException — xử lý bằng exponential backoff (thử lại với khoảng chờ tăng dần) hoặc xin tăng quota. Đây là nguyên nhân kinh điển khiến S3 replication hay batch job mã hóa hàng loạt bị lỗi.

3.4. Multi-Region Keys

Mặc định khóa KMS key bị giới hạn trong một region.

Multi-region keys phá vỡ điều đó: một bộ khóa KMS giống hệt nhau được AWS sao chép và đặt ở nhiều region - có cùng Key ID và backing key. Gồm một primary key và các replica key.

Nhờ đó, bạn mã hóa dữ liệu ở region A và giải mã ở region B mà không cần gọi cross-region hay re-encrypt — vì khóa hai bên là một.

Lưu ý các khóa này được quản lý độc lập (mỗi cái có key policy riêng) dù chia sẻ cùng backing key.

Multi-region keys không phải lựa chọn mặc định — đa phần dữ liệu nên ở một region. Chỉ dùng Multi-Region Keys khi thật sự có nhu cầu đa region, vì mỗi khóa ở mỗi region đều bị tính tiền riêng.

3.5. S3 Replication với dữ liệu đã mã hóa

S3 Replication là 1 cơ chế sao chép bất đồng bộ, tự động và 1 chiều từ bucket nguồn sang 1 hoặc nhiều bucket đích, hoạt động dựa trên sự thay đổi object của S3 Versioning chứ không phải quét định kỳ.

Mỗi khi có object được tạo mới hoặc thay đổi, S3 sinh ra 1 version mới, version đó trở thành một “đơn vị công việc” trong hàng đợi replication nội bộ. S3 dùng một IAM role mà bạn chỉ định trong replication rule để thay mặt bạn đọc object từ nguồn và ghi sang đích — nghĩa là quyền replicate tách bạch khỏi quyền của người upload, và với cross-account replication thì bucket policy bên đích phải cho phép role đó ghi vào.

Khi bật S3 Replication, việc replicate object đã mã hóa có vài quy tắc dễ quên:

• Object không mã hóa và object SSE-S3 được replicate mặc định.
• Object SSE-C (khóa do khách cung cấp): được hỗ trợ.
• Object SSE-KMS: phải bật tường minh trong cấu hình replication. Bạn cần chỉ định KMS key ở region đích, và cấp cho IAM role làm nhiệm vụ replication quyền kms:Decrypt trên khóa nguồn cùng kms:Encrypt trên khóa đích. Vì mỗi object là một lần gọi KMS, replicate hàng loạt rất dễ đụng trần throttling của KMS — khi đó cần xin tăng quota.

3.6. Chia sẻ AMI đã mã hóa qua account khác

Muốn hiểu việc chia sẻ AMI giữa các account, trước hết phải biết một AMI (Amazon Machine Image — bản mẫu để khởi tạo EC2 instance) thực chất gồm những gì?

Một AMI có ba thành phần: metadata (tên, kiến trúc CPU…), launch permission (ai được phép dùng AMI này để launch instance), và BlockDeviceMappings (AMI tham chiếu tới những EBS volume nào).

Khi bạn tạo AMI từ một instance qua create-image, AWS làm hai việc: chụp một snapshot cho từng EBS volume đang gắn vào instance, rồi ghi một bản ghi AMI trỏ tới các snapshot đó. Lúc launch thì ngược lại — AWS khôi phục các volume mới, hoàn toàn độc lập với volume gốc, từ những snapshot này.

Chi phí lưu trữ AMI thực chất là chi phí lưu trữ snapshot, các thành phần còn lại không đáng kể. Và vì snapshot là thứ đứng sau, xóa AMI không đồng nghĩa với xóa snapshot — nhiều khi xóa AMI nhưng snapshot vẫn còn đó thì vẫn bị tính tiền.

Vì AMI là tài nguyên theo region, “chia sẻ AMI” có hai cách với ý nghĩa rất khác nhau về chi phí và vòng đời:

• Cấp launch permission — thêm account ID, organization ID hoặc OU ID của bên đích vào launch permission của AMI (modify-image-attribute --launch-permission). AMI vẫn nằm ở account nguồn, account nguồn vẫn trả phí lưu trữ, và nếu account nguồn xóa AMI thì bên đích không launch được nữa. Đây là kiểu “cho dùng nhờ”, không phải “cho sở hữu”.
• Copy sang account đích — bên đích chạy copy-image để tạo ra một AMI mới thuộc sở hữu của chính mình và tự làm chủ vòng đời. Cách này cần account nguồn cấp hai quyền: launch permission trên AMI, và createVolumePermission trên từng snapshot đứng sau AMI. Quyền trên snapshot là bước hay bị quên nhất — thiếu nó, bên đích thấy AMI nhưng lệnh copy sẽ fail.

Vì copy bản chất là đọc snapshot, bước đầu tiên là tìm ra các snapshot đứng sau AMI:

aws ec2 describe-images --image-ids ami-0abc123 \
  --query 'Images[0].BlockDeviceMappings[*].Ebs.SnapshotId'

Rồi cấp quyền đọc trên từng snapshot cho account đích — chính bước hay bị bỏ sót:

aws ec2 modify-snapshot-attribute --snapshot-id snap-0aaa111 \
  --attribute createVolumePermission --operation-type add \
  --user-ids 222233334444

Khi AMI được mã hóa, có thêm vài ràng buộc về khóa. Bạn không thể chia sẻ một snapshot mã hóa bằng khóa AWS-managed mặc định (aws/ebs) — trước tiên account nguồn phải tự copy AMI của mình sang một Customer Managed Key rồi mới chia sẻ phiên bản đó. Ngoài ra phải thêm statement vào key policy của CMK cho phép account đích các quyền kms:DescribeKey, kms:Decrypt, kms:CreateGrant trên khóa. Thiếu quyền KMS thì dù đã share snapshot, bên đích vẫn không giải mã được để copy.

Cuối cùng, khi copy, bên đích nên re-encrypt bằng khóa của chính mình ngay trong bước đó để cắt hẳn phụ thuộc vào khóa của account nguồn về sau:

aws ec2 copy-image \
  --source-region us-east-1 --source-image-id ami-0abc123 \
  --region us-east-1 --name "app-base-v1.2" \
  --encrypted --kms-key-id <CMK-của-account-đích>

Điểm này nối lại với tính chất region-scope ở mục 3.3: vì khóa KMS không rời được region của nó, chia sẻ AMI mã hóa qua region khác cũng là một lần copy-image re-encrypt bằng khóa của region đích.

4. AWS CloudHSM — khi bạn cần kiểm soát hoàn toàn phần cứng

Với KMS, AWS quản lý phần mềm sinh và lưu khóa (dù bạn kiểm soát chính sách). Nhưng một số tổ chức (ngân hàng, chính phủ) có yêu cầu compliance khắt khe hơn: khóa phải nằm trong thiết bị phần cứng chuyên dụng mà AWS không thể chạm tới. Đó là lý do AWS CloudHSM tồn tại.

CloudHSM cung cấp các HSM đơn-tenant (dành riêng cho bạn, không chia sẻ), đạt chuẩn FIPS 140-2 Level 3. AWS chỉ lo cấp phát và bảo trì phần cứng; còn bạn tự quản lý khóa và user — AWS không có quyền truy cập vào khóa của bạn.

Đặc điểm cần nhớ:

• Hỗ trợ cả symmetric lẫn asymmetric, và là lựa chọn tốt khi dùng SSE-C (vì bạn tự giữ khóa).
• Truy cập khóa qua các thư viện chuẩn ngành: PKCS#11, JCE, CNG — không qua AWS API. IAM ở đây chỉ dùng để quản lý vòng đời cụm HSM, không dùng để gọi khóa.
• Triển khai theo cluster đa AZ để có tính sẵn sàng cao (HA).
• Custom Key Store: KMS có thể dùng cụm CloudHSM của bạn làm nơi lưu khóa — bạn được tiện lợi của API KMS nhưng khóa vật lý nằm trong HSM của riêng mình.

So sánh nhanh KMS vs CloudHSM — câu hỏi kinh điển của SAA:

Quy tắc đi thi: thấy “dedicated HSM”, “FIPS 140-2 Level 3”, “phải tự kiểm soát khóa, AWS không được chạm vào” → CloudHSM. Còn lại, mặc định là KMS.

5. Secrets & Config: SSM Parameter Store vs Secrets Manager

Câu hỏi số 2 của đội security — “mật khẩu DB và API key nằm ở đâu” — được giải bởi hai dịch vụ. Cả hai đều cất giá trị đã mã hóa, nhưng sinh ra cho hai mục đích hơi khác nhau.

5.1. SSM Parameter Store

AWS Systems Manager Parameter Store là kho lưu trữ phân cấp cho dữ liệu cấu hình và secrets. Bạn cất giá trị dưới dạng plain text hoặc SecureString (mã hóa bằng KMS), tổ chức theo đường dẫn cây như /my-app/prod/db-url.

Nhưng có một điểm mấu chốt mà phần lớn người ôn thi bỏ qua — và nó chính là chìa khóa để hết phân vân khi đề đưa ra cả Parameter Store lẫn Secrets Manager: Parameter Store không phải một dịch vụ secret độc lập. Nó là một thành phần bên trong AWS Systems Manager — cùng nhà với Run Command, Automation, Session Manager, Patch Manager. Nó ra đời để chính các công cụ vận hành đó có chỗ lấy tham số (parameter): khi một Automation document hay Run Command cần biết “dùng AMI nào” hay “đọc config nào”, nó đọc từ Parameter Store. Tức là Parameter Store sinh ra từ nhu cầu của hệ vận hành SSM, không phải từ nhu cầu quản lý secret. Việc nó lưu được secret (qua SecureString) chỉ là tính năng phụ, không phải lý do tồn tại.

Hệ quả thực dụng cho phòng thi: khi tình huống nghiêng về quản lý secret đúng nghĩa — tự động xoay vòng, credential database, vòng đời của một secret — thì dù Parameter Store “lưu được”, lựa chọn thiết kế đúng vẫn là Secrets Manager. Parameter Store hợp với config vận hành và secret đơn giản, ít thay đổi.

Tính năng cốt lõi:

• Phân cấp + phân quyền theo path: cấp quyền IAM cho cả nhánh /my-app/prod/*.
• Versioning, audit qua CloudTrail, thông báo qua EventBridge.
• Tham chiếu được tới Secrets Manager (qua đường dẫn /aws/reference/secretsmanager/...) và tới các public parameter của AWS (ví dụ lấy AMI ID mới nhất của Amazon Linux).
• Hai tier:

Điểm cần nhớ: Parameter Store không có cơ chế xoay vòng tự động sẵn — muốn xoay phải tự dựng bằng Lambda + EventBridge.

5.2. AWS Secrets Manager

AWS Secrets Manager là dịch vụ chuyên biệt cho secrets, sinh ra để bù đúng cái Parameter Store thiếu: tự động xoay vòng (automatic rotation). Đây là điểm khác biệt lớn nhất.

Tính năng cốt lõi:

• Tự động xoay secret theo lịch, thực thi qua một Lambda function. Đặc biệt có tích hợp gốc với RDS, Aurora, Redshift, DocumentDB — Secrets Manager có thể tự sinh và tự xoay thông tin đăng nhập database mà không cần bạn viết code.
• Bắt buộc mã hóa bằng KMS (không có lựa chọn để trống như Parameter Store).
• Multi-region secrets: nhân bản secret sang region khác (cho DR và app đa region).
• Tích hợp dynamic reference trong CloudFormation, App Runner, ECS…

Đánh đổi là chi phí: khoảng $0.40/secret/tháng cộng phí API — đắt hơn hẳn Parameter Store standard (miễn phí).

6. AWS Certificate Manager (ACM) — chứng chỉ TLS/SSL

Quay lại encryption in flight ở mục 2: muốn web chạy HTTPS bạn cần chứng chỉ TLS/SSL. Tự đi mua, cài, rồi nhớ gia hạn từng năm là cực hình. AWS Certificate Manager (ACM) tự động hóa toàn bộ: cấp phát, quản lý và triển khai chứng chỉ.

Tính năng cốt lõi:

• Chứng chỉ public miễn phí — bạn chỉ trả tiền cho resource (ELB, CloudFront…) chứ không trả tiền cho cert.
• Tự động gia hạn với chứng chỉ do ACM cấp (điểm cộng lớn, hết cảnh quên gia hạn gây sập site).
• Hỗ trợ import chứng chỉ bên thứ ba, nhưng cert import thì không tự gia hạn được.
• Hai cách xác thực sở hữu domain: DNS validation (khuyến nghị — cho phép tự động gia hạn) và Email validation.
• Private CA (ACM Private CA): cấp chứng chỉ nội bộ cho hệ thống private (có tính phí).

Hai điểm bẫy hay gặp trong phòng thi:

• ACM tích hợp với ELB (ALB/NLB/CLB), CloudFront và API Gateway — nhưng không gắn trực tiếp lên EC2 được, vì bạn không export được private key của public cert ra ngoài. Muốn HTTPS trên EC2 thì phải dùng cert tự quản hoặc đặt sau một load balancer.
• ACM là dịch vụ theo region. Với CloudFront, chứng chỉ bắt buộc nằm ở region us-east-1 (N. Virginia) — đây là một trong những bẫy region được hỏi nhiều nhất.

7. Phòng thủ ở biên: WAF, Shield, Firewall Manager

Câu hỏi số 3 — chặn web exploit và DDoS — thuộc về ba dịch vụ làm việc cùng nhau, mỗi cái một lớp.

7.1. AWS WAF — tường lửa tầng ứng dụng (Layer 7)

AWS WAF (Web Application Firewall) lọc lưu lượng HTTP/HTTPS ở tầng 7 để chặn các web exploit phổ biến: SQL injection, XSS, và bot xấu.

Bạn gắn WAF lên: Application Load Balancer, API Gateway, CloudFront, AppSync (GraphQL), Cognito User Pool, App Runner.

Lưu ý không gắn được lên Network Load Balancer (vì NLB ở tầng 4, không hiểu HTTP).

Cấu hình qua một Web ACL chứa các rule:

• IP set: chặn/cho phép theo danh sách IP.
• Rule khớp nội dung HTTP: theo header, body, URI, query string.
• Size constraints, geo-match (chặn theo quốc gia).
• Managed rule groups: bộ rule dựng sẵn của AWS và đối tác trên Marketplace.
• Rate-based rules: giới hạn số request/IP trong khoảng thời gian — đây là cơ chế chống DDoS ở tầng 7.

Web ACL là theo region, ngoại trừ khi gắn với CloudFront thì là global (ở edge).

Một bẫy kiến trúc kinh điển: cần WAF nhưng lại cần IP tĩnh. Vì WAF không gắn được lên NLB (thứ cho IP tĩnh), giải pháp là đặt ALB sau AWS Global Accelerator (Global Accelerator cấp 2 anycast IP tĩnh) rồi gắn WAF lên ALB.

7.2. AWS Shield — chống DDoS

DDoS là kiểu tấn công làm nghẽn hệ thống bằng lượng truy cập khổng lồ từ nhiều nguồn. AWS chống DDoS qua Shield, có hai mức:

• Shield Standard: miễn phí, tự động bật cho mọi khách hàng AWS. Chống các tấn công phổ biến ở tầng 3/4 (SYN flood, UDP flood, reflection). Không cần làm gì cả.
• Shield Advanced: trả phí $3.000/tháng cho cả tổ chức (cộng phí data transfer). Bảo vệ nâng cao cho EC2, ELB, CloudFront, Global Accelerator, Route 53, kèm:
  • Đội phản ứng DDoS 24/7 (SRT).
  • DDoS cost protection: hoàn lại chi phí bị đội lên do hệ thống tự scale để hấp thụ tấn công.
  • Tự động giảm thiểu DDoS tầng ứng dụng: tự tạo WAF rule (WAF được bao gồm miễn phí cho resource đã bảo vệ).
  • Metric và hiển thị real-time.

7.3. AWS Firewall Manager — quản lý tập trung toàn tổ chức

AWS Firewall Manager giải bài toán quy mô: khi có hàng chục account trong một AWS Organizations, làm sao áp cùng một bộ rule bảo mật cho tất cả mà không cấu hình tay từng account?

Firewall Manager cho phép định nghĩa policy tập trung quản lý: WAF rules (Web ACL), Shield Advanced, Security Groups, AWS Network Firewall (lọc lưu lượng ở tầng VPC), và Route 53 Resolver DNS Firewall.

Điểm mạnh nhất: rule được tự động áp cho resource mới ngay khi chúng được tạo trên toàn tổ chức → đảm bảo compliance liên tục, không lo account nào bị bỏ sót.

Phân biệt bộ ba này — câu hỏi rất hay ra. Điều cốt lõi: WAF, Shield và Firewall Manager được dùng cùng nhau cho phòng thủ toàn diện, nhưng mỗi cái trả lời một nhu cầu khác nhau. Khung quyết định:

• Định nghĩa rule luôn là việc của WAF. Bộ Web ACL rule luôn được khai báo trong WAF, dù sau đó bạn quản lý chúng bằng gì.
• Cần bảo vệ chi tiết cho một vài resource → WAF là đủ và đúng. Khi chỉ cần lọc request ở tầng 7 cho một vài resource, WAF đứng một mình là lựa chọn chính xác.
• Cần dùng WAF trên nhiều account, tăng tốc cấu hình, tự động bảo vệ resource mới → Firewall Manager (+ WAF). Firewall Manager không thay thế WAF; nó quản lý và áp WAF rule ở quy mô toàn tổ chức và tự gắn cho resource mới khi chúng xuất hiện.
• Hay bị DDoS, cần thêm tính năng cao cấp → Shield Advanced. Shield Advanced bổ sung lên trên WAF: hỗ trợ chuyên trách từ SRT, advanced reporting, cost protection, tự động giảm thiểu DDoS tầng ứng dụng. Nếu thường xuyên hứng DDoS, đây là thứ đáng cân nhắc mua.

Cách ghi nhớ một dòng: WAF = rule chi tiết trên resource; Firewall Manager = áp WAF/Shield trên nhiều account & tự động hóa; Shield Advanced = lớp DDoS cao cấp chồng lên WAF.

7.4. Best practices chống DDoS

AWS có hẳn whitepaper về kháng DDoS, trong đó gom các khuyến nghị thành những best practice được đánh số (BP1, BP2, …) và xếp chúng lên một kiến trúc tham chiếu. Tư tưởng xuyên suốt: chặn tấn công càng gần biên càng tốt, trước khi nó kịp chạm tới hạ tầng cốt lõi trong VPC.

Kiến trúc tham chiếu chống DDoS của AWS, hấp thụ tấn công ở edge trước khi vào VPC

Đọc kiến trúc trên theo lớp: lưu lượng người dùng đi vào qua các edge service (Global Accelerator, Route 53, WAF, CloudFront) — đây là nơi hấp thụ phần lớn tấn công — rồi mới tới VPC chứa ELB, API Gateway và tầng compute (Auto Scaling group) trong các subnet. Vài nguyên tắc cốt lõi hay được hỏi:

• Giảm thiểu ở edge: đẩy lưu lượng qua CloudFront, Global Accelerator, Route 53 để hấp thụ và phân tán tấn công ngay tại các edge location, trước khi nó chạm tới origin. Global Accelerator còn hữu ích khi backend không tương thích với CloudFront và tích hợp sẵn với Shield.
• Sẵn sàng scale để hấp thụ: dùng Auto Scaling và CloudFront/Global Accelerator để “nuốt” lưu lượng tấn công thay vì gục ngã.
• Phòng thủ tầng ứng dụng: WAF với rate-based rule, geo-match, managed rule; cache ở CloudFront để giảm tải cho origin; API Gateway throttling.
• Giảm bề mặt tấn công: giấu origin (chỉ cho CloudFront truy cập origin qua Security Group + custom header), dùng Security Group/NACL chặt chẽ, bảo vệ các API endpoint.

8. Phát hiện mối đe dọa & dữ liệu nhạy cảm: GuardDuty, Inspector, Macie

Câu hỏi số 4 — “làm sao biết mình đang bị tấn công hay rò rỉ dữ liệu” — thuộc nhóm detective. Ba dịch vụ này không chặn tấn công; chúng phát hiện và cảnh báo. Phân biệt đúng ba cái này là một trong những câu chắc chắn có trong đề.

8.1. Amazon GuardDuty — phát hiện mối đe dọa

Amazon GuardDuty là dịch vụ phát hiện mối đe dọa thông minh, dùng machine learning, phát hiện bất thường và threat intelligence để tìm hoạt động độc hại.

Ưu điểm lớn: chỉ cần bật một nút, không cần cài agent.

Nó phân tích các nguồn log sẵn có:

• CloudTrail logs (management events + S3 data events).
• VPC Flow Logs (lưu lượng mạng).
• DNS query logs.
• Tùy chọn mở rộng: EKS audit logs, đăng nhập RDS/Aurora, hoạt động mạng của Lambda, S3, và quét malware trên EBS volume.

Khi phát hiện bất thường, GuardDuty sinh finding và đẩy qua EventBridge để bạn tự động phản ứng (gọi Lambda, gửi SNS). Nó bắt được các mối đe dọa như: instance bị chiếm để đào tiền mã hóa (cryptomining), hành vi do thám (reconnaissance), bất thường trong việc gọi API, và rò rỉ IAM credential.

Bổ sung gần đây (12/2024): GuardDuty Extended Threat Detection tự động tương quan nhiều tín hiệu thành một chuỗi tấn công đa giai đoạn (ví dụ: chiếm credential → sau đó exfiltrate dữ liệu) và gộp thành một finding mức critical duy nhất — miễn phí cho mọi khách hàng GuardDuty.

Mẹo nhớ: thấy đề nhắc “phân tích VPC Flow Logs / DNS logs / CloudTrail để phát hiện hành vi bất thường” hoặc “chống đào coin” → GuardDuty.

8.2. Amazon Inspector — quản lý lỗ hổng

Amazon Inspector tự động hóa quản lý lỗ hổng (vulnerability management) — quét xem workload của bạn có dính lỗ hổng bảo mật đã biết hay không. Nó chỉ làm việc với ba loại tài nguyên:

• EC2 instance: quét lỗ hổng phần mềm (đối chiếu cơ sở dữ liệu CVE) và khả năng bị truy cập từ mạng (network reachability), thông qua SSM agent.
• Container image trong ECR: quét khi image được push.
• Lambda function: quét lỗ hổng trong code và dependency.

Inspector quét liên tục, chấm điểm rủi ro cho từng lỗ hổng, và gửi finding tới Security Hub và EventBridge.

Điểm cần khắc cốt: Inspector chỉ lo EC2, ECR, Lambda — không đụng tới dữ liệu trong S3.

Mẹo nhớ: thấy “CVE”, “lỗ hổng phần mềm”, “quét container image”, “vulnerability” → Inspector.

8.3. Amazon Macie — bảo vệ dữ liệu nhạy cảm

Amazon Macie là dịch vụ bảo mật và quyền riêng tư dữ liệu, dùng machine learning và so khớp mẫu (pattern matching) để phát hiện và bảo vệ dữ liệu nhạy cảm trong S3. Cụ thể, nó tự rà soát các bucket S3 và phát hiện PII — thông tin định danh cá nhân — rồi cảnh báo qua EventBridge.

Use case: tuân thủ quy định về quyền riêng tư (GDPR, PCI-DSS…), trả lời câu hỏi “PII của khách hàng đang nằm rải rác ở những bucket nào?”.

Mẹo nhớ: thấy “PII”, “dữ liệu nhạy cảm”, “S3”, “quyền riêng tư” → Macie.