Ngân hàng đề — AWS Certified Security Specialty

Đáp án

A — Nếu bạn dùng trình phân giải DNS tuỳ chỉnh (custom DNS resolver) thì GuardDuty không truy cập và xử lý được dữ liệu từ nguồn này.

Vì sao đúng

Đề cho một manh mối quyết định: công ty dùng Active Directory tại chỗ làm dịch vụ tên miền cho các EC2 Windows.

Điều đó gần như chắc chắn nghĩa là: các instance được cấu hình dùng DNS server của Active Directory, không dùng trình phân giải mặc định của AWS.

Và đó chính là điều kiện khiến GuardDuty mù với DNS:

Dùng AmazonProvidedDNS (Route 53 Resolver mặc định):
    Instance → truy vấn DNS → Route 53 Resolver
                                    ↓
                              GuardDuty đọc được  ✓

Dùng DNS resolver TUỲ CHỈNH (AD, DNS riêng, bên thứ ba):
    Instance → truy vấn DNS → DNS server của bạn
                                    ↓
                              GuardDuty KHÔNG thấy gì  ✗

Lý do kỹ thuật: GuardDuty lấy dữ liệu DNS từ chính hạ tầng phân giải DNS của AWS. Nếu truy vấn không đi qua đó, không có dữ liệu nào cho GuardDuty đọc.

Đây là một điểm mù thật và đáng lo: DNS là kênh phổ biến cho rò rỉ dữ liệu (DNS tunneling) và liên lạc với máy chủ điều khiển (C2). Mất nguồn dữ liệu này làm giảm đáng kể khả năng phát hiện của GuardDuty.

Cách xử lý: | Cách | Chi tiết | |---|---| | Chuyển sang Route 53 Resolver với forwarding rule | truy vấn tên miền nội bộ chuyển tiếp tới AD, phần còn lại qua AWS | | Bù bằng nguồn khác | Route 53 Resolver query logging, VPC Traffic Mirroring, log của chính DNS server | | Chấp nhận điểm mù | chỉ nếu có kiểm soát bù đắp khác |

Cách đầu là giải pháp đúng nhất và cũng là mô hình lai chuẩn: dùng Route 53 Resolver outbound endpoint + forwarding rule để truy vấn tên miền công ty đi tới AD, còn mọi truy vấn khác vẫn qua trình phân giải AWS — vừa hoạt động vừa giữ được khả năng giám sát.

Vì sao các phương án khác sai

• B. GuardDuty phân tích DNS log từ luồng dữ liệu do tính năng Route 53 Resolver query logging cung cấp; kiểm tra đường dẫn trong cấu hình đó — đây là phương án gần nhất và sai về nguồn dữ liệu: GuardDuty KHÔNG dùng Route 53 Resolver query logging. Nó có kênh nội bộ riêng tới hạ tầng DNS của AWS. (Bạn không cần bật query logging để GuardDuty phân tích DNS — và bật nó cũng không giúp GuardDuty thấy được truy vấn đi qua resolver tuỳ chỉnh.)
• C. GuardDuty chỉ báo cáo về VPC Flow Logs, sự kiện CloudTrail toàn cầu và Kubernetes audit log; nó KHÔNG phân tích DNS log — sai: DNS log là một trong ba nguồn dữ liệu nền tảng của GuardDuty.
• D. Kiểm tra quyền gắn trên IAM role mà GuardDuty dùng để truy cập DNS log — hiểu sai cơ chế: GuardDuty không dùng IAM role của bạn để đọc các nguồn dữ liệu nền tảng. Nó truy cập chúng trực tiếp qua hạ tầng nội bộ của AWS — đó là lý do bạn không phải bật VPC Flow Logs để GuardDuty phân tích lưu lượng.

Ghi nhớ

Ba nguồn dữ liệu nền tảng của GuardDuty: | Nguồn | Phát hiện | Bạn phải bật? | |---|---|---| | VPC Flow Logs | hoạt động mạng bất thường | ❌ KHÔNG — GuardDuty đọc trực tiếp | | DNS logs | domain độc hại, DNS tunneling | ❌ KHÔNG | | CloudTrail | hoạt động API bất thường, thông tin đăng nhập bị lạm dụng | ❌ KHÔNG |

Cột cuối là đặc điểm quan trọng và ít người biết: GuardDuty không tính phí và không đòi bạn bật ba nguồn này. Nếu bạn đã bật VPC Flow Logs cho mục đích riêng, GuardDuty vẫn dùng kênh nội bộ của nó — không liên quan.

Nhưng có ngoại lệ, và đó là nội dung câu hỏi:

DNS log CHỈ khả dụng khi instance dùng trình phân giải DNS của AWS
    → dùng resolver tuỳ chỉnh = mất nguồn dữ liệu này

Các tính năng bảo vệ mở rộng (phải bật riêng, có tính phí): | Tính năng | Bảo vệ | |---|---| | S3 Protection | data event của S3 | | EKS/ECS Runtime Monitoring | hành vi bất thường trong container | | Malware Protection | quét mã độc trên EBS | | RDS Protection | hành vi đăng nhập bất thường vào Aurora | | Lambda Protection | hoạt động mạng của Lambda |

Ba loại finding liên quan tới DNS: | Finding | Ý nghĩa | |---|---| | Backdoor:EC2/C&CActivity.B!DNS | instance truy vấn domain của máy chủ điều khiển | | Trojan:EC2/DNSDataExfiltration | rò rỉ dữ liệu qua DNS tunneling | | Impact:EC2/BitcoinDomainRequest.Reputation | truy vấn domain đào tiền ảo |

Mất ba loại phát hiện này là mất khá nhiều — đó là lý do nên xử lý điểm mù thay vì chấp nhận nó.

Kiến trúc DNS lai đúng cho tình huống của đề:

EC2 trong VPC
    ↓ dùng AmazonProvidedDNS (.2 của VPC CIDR)
Route 53 Resolver
    ├─ tên miền công ty (congty.local) → forwarding rule
    │       ↓ outbound endpoint → AD DNS tại chỗ
    └─ mọi tên miền khác → phân giải bởi AWS
            ↓
      GuardDuty đọc được ✓

Và một biện pháp bổ sung đáng bật cùng lúc: Route 53 Resolver DNS Firewall. Nó CHẶN truy vấn tới domain trong danh sách độc hại — biện pháp phòng ngừa, khác với GuardDuty vốn chỉ phát hiện. Hai thứ này bổ sung nhau và cùng dựa trên việc truy vấn đi qua trình phân giải của AWS.

Đáp án

A, C và E:

• A — Xoay vòng và xoá mọi access key của root và của IAM
• E — Kiểm tra hoá đơn AWS để biết những tài nguyên nào đang bị tính phí
• C — Dùng AWS Git projects để quét tìm dấu vết của việc sử dụng trái phép

Vì sao đúng

Đề mô tả tình huống ứng phó sự cố: tài nguyên trong tài khoản có thể đã bị xâm nhập. Ba đáp án là ba bước đầu tiên trong quy trình chính thức của AWS.

A — chặn nguồn truy cập TRƯỚC TIÊN:

Kẻ tấn công đang giữ thông tin đăng nhập
    → mỗi phút trôi qua là thêm thiệt hại
    → xoay vòng mọi access key NGAY
    → thu hồi phiên STS đang còn hiệu lực

Đây luôn là bước đầu: mọi việc điều tra sau đó đều vô nghĩa nếu kẻ tấn công vẫn còn quyền truy cập.

E — hoá đơn là công cụ phát hiện nhanh và bị đánh giá thấp: | Dấu hiệu trên hoá đơn | Ý nghĩa | |---|---| | EC2 instance ở Region bạn không dùng | đào tiền ảo — mẫu tấn công phổ biến nhất | | Chi phí truyền dữ liệu tăng đột biến | rò rỉ dữ liệu | | Dịch vụ bạn chưa từng bật | SageMaker, Bedrock, EMR bị lạm dụng |

Vì sao hoá đơn hiệu quả: kẻ tấn công thường tạo tài nguyên ở những Region bạn không bao giờ nhìn tới. Console mặc định chỉ hiện một Region, còn hoá đơn hiện TẤT CẢ — nên nó thường là nơi phát hiện ra tài nguyên lạ đầu tiên.

C — AWS Git projects là các kho mã nguồn mở AWS cung cấp để rà soát tài khoản, ví dụ aws-security-benchmark và git-secrets. Chúng giúp quét cấu hình và tìm bí mật bị lộ trong mã nguồn — thường chính là nguyên nhân gốc của việc thông tin đăng nhập bị rò rỉ.

Vì sao các phương án khác sai

• F. Dùng báo cáo kiểm tra bảo mật của AWS Trusted Advisor để biết chi tiết về tài nguyên bị xâm nhập — đây là phương án gần nhất và hữu ích ở mức phòng ngừa (nó cảnh báo về security group mở, bucket công khai, MFA chưa bật), nhưng nó không phát hiện tài nguyên đã bị xâm nhập. Nó đánh giá cấu hình, không phát hiện hoạt động độc hại.
• D. Dùng Amazon Inspector để phát hiện tài nguyên bị xâm nhập — sai chức năng: Inspector quét lỗ hổng phần mềm. Nó cho biết máy nào có thể bị tấn công, không cho biết máy nào đã bị tấn công. (Dịch vụ cho việc đó là GuardDuty.)
• B. Dùng báo cáo health check trong AWS Systems Manager để biết chi tiết về tài nguyên bị xâm nhập — không có tính năng như vậy: Systems Manager quản lý vận hành instance (vá, kiểm kê, chạy lệnh), không phát hiện xâm nhập.

Ghi nhớ

Quy trình ứng phó khi nghi ngờ tài khoản AWS bị xâm nhập:

① CHẶN     → xoay vòng/vô hiệu hoá mọi access key, thu hồi phiên STS  ← A
② RÀ SOÁT  → kiểm tra hoá đơn, xem tài nguyên ở MỌI Region            ← E
③ ĐIỀU TRA → CloudTrail: ai gọi API gì, từ IP nào
④ DỌN DẸP  → xoá tài nguyên lạ, xoá IAM user/role không rõ nguồn gốc
⑤ QUÉT     → tìm bí mật bị lộ trong mã nguồn                          ← C
⑥ LIÊN HỆ  → AWS Support nếu cần hỗ trợ
⑦ NGĂN NGỪA→ bật MFA, bỏ access key dài hạn, bật GuardDuty

Cách thu hồi phiên STS — bước hay bị bỏ sót ở ①:

{"Effect": "Deny", "Action": "*", "Resource": "*",
 "Condition": {"DateLessThan": {"aws:TokenIssueTime": "2026-08-30T12:00:00Z"}}}

Vô hiệu hoá access key không thu hồi token STS đã cấp — chúng còn sống tới 12 giờ.

Bốn nơi cần kiểm tra khi rà soát: | Nơi | Tìm gì | |---|---| | Hoá đơn / Cost Explorer | chi phí bất thường ở Region lạ | | IAM | user, role, access key mới xuất hiện | | EC2 ở MỌI Region | instance lạ, thường là loại GPU hoặc compute lớn | | CloudTrail | lời gọi API từ IP không quen |

Dòng thứ ba đáng nhấn mạnh: kiểm tra mọi Region, kể cả những Region bạn không dùng — đó chính là nơi kẻ tấn công thích hoạt động vì ít bị nhìn tới.

Bốn dịch vụ và vai trò trong ứng phó sự cố: | Dịch vụ | Việc | |---|---| | GuardDuty | PHÁT HIỆN hoạt động độc hại | | CloudTrail | ĐIỀU TRA — ai làm gì, khi nào | | Detective | PHÂN TÍCH nguyên nhân gốc, phạm vi lan toả | | Inspector | tìm lỗ hổng (phòng ngừa) | | Trusted Advisor | khuyến nghị cấu hình (phòng ngừa) |

Năm biện pháp ngăn tình huống này tái diễn: | Biện pháp | Hiệu quả | |---|---| | Bật MFA cho root và mọi người dùng | | | XOÁ access key của root | root không bao giờ nên có access key | | Dùng IAM role thay access key dài hạn | loại bỏ thứ có thể bị rò rỉ | | Bật GuardDuty ở MỌI Region | phát hiện sớm | | Quét mã nguồn tìm bí mật | git-secrets, GitHub secret scanning |

Dòng thứ ba là biện pháp gốc rễ: phần lớn sự cố kiểu này bắt đầu từ một access key bị đẩy lên kho mã công khai. Không có key dài hạn thì không có gì để rò rỉ.

Và một biện pháp phát hiện sớm đáng bật: AWS Budgets với cảnh báo ngưỡng chi phí. Nó thường báo động trước cả khi bạn kịp nhìn hoá đơn — với tấn công đào tiền ảo, chi phí tăng vọt trong vài giờ chứ không phải vài ngày.

Đáp án

A và C.

• C — Dùng WAF geo match statement liệt kê các quốc gia cần chặn
• A — Dùng WAF IP set statement khai các địa chỉ IP được cho qua

Vì sao đúng

Đề nêu một yêu cầu có ngoại lệ: chặn một số quốc gia, nhưng cho phép đội phát triển ở một trong những quốc gia bị chặn đó truy cập.

Chính ngoại lệ này quyết định phải dùng WAF chứ không dùng geo restriction của CloudFront: | | CloudFront geo restriction | AWS WAF | |---|---|---| | Chặn theo quốc gia | ✅ | ✅ | | Ngoại lệ theo IP | ❌ KHÔNG | ✅ CÓ | | Chi phí | miễn phí | tính phí |

Đề dùng ALB chứ không phải CloudFront — và ALB không có geo restriction, nên WAF là lựa chọn duy nhất.

Và thứ tự ưu tiên rule là điều quyết định giải pháp hoạt động:

Priority 1: IP set statement → ALLOW  (IP của đội phát triển)
Priority 2: Geo match statement → BLOCK (các quốc gia bị chặn)

WAF đánh giá rule theo priority tăng dần và DỪNG ở rule khớp đầu tiên. Nên:

Request từ IP của đội phát triển (ở nước bị chặn):
    → khớp rule 1 (ALLOW) → CHO QUA, không xét tiếp rule 2  ✓

Request khác từ cùng nước đó:
    → không khớp rule 1
    → khớp rule 2 (BLOCK) → CHẶN  ✓

Đảo ngược thứ tự là hỏng toàn bộ: nếu geo match ở priority 1, đội phát triển bị chặn trước khi rule cho phép được xét tới.

{
  "Rules": [
    {"Name": "ChoPhepDoiPhatTrien", "Priority": 1,
     "Statement": {"IPSetReferenceStatement": {"ARN": "arn:aws:wafv2:...:ipset/doi-phat-trien"}},
     "Action": {"Allow": {}}},
    {"Name": "ChanTheoQuocGia", "Priority": 2,
     "Statement": {"GeoMatchStatement": {"CountryCodes": ["XX", "YY"]}},
     "Action": {"Block": {}}}
  ]
}

Vì sao các phương án khác sai

• B. Tạo rule deny cho các quốc gia bị chặn trong NACL gắn với từng EC2 instance — hai lỗi: NACL gắn với subnet, không gắn với instance; và NACL không biết gì về quốc gia — nó chỉ làm việc với địa chỉ IP. Muốn chặn một nước bằng NACL thì phải liệt kê hàng nghìn dải IP và cập nhật liên tục.
• D. Dùng ALB IP set statement khai các IP được cho qua — ALB không có "IP set statement": đó là khái niệm của AWS WAF. ALB chỉ có listener rule, và chúng định tuyến theo đường dẫn hoặc host header, không lọc theo IP.
• E. Dùng ALB geo match statement liệt kê các quốc gia cần chặn — cùng lỗi: ALB không có geo match. Chức năng đó thuộc WAF (và CloudFront geo restriction).

Ghi nhớ

Ba cách chặn theo địa lý — chọn theo nhu cầu: | Cách | Có ngoại lệ? | Chi phí | Dùng với | |---|---|---|---| | CloudFront geo restriction | ❌ | miễn phí | chỉ CloudFront | | WAF geo match | ✅ | tính phí | CloudFront, ALB, API Gateway | | Route 53 geolocation routing | — | phí DNS | định tuyến, KHÔNG chặn |

Tiêu chí chọn giữa hai dòng đầu:

Chặn thuần theo quốc gia, không ngoại lệ, dùng CloudFront → geo restriction (miễn phí, xem câu #7729) Cần ngoại lệ, hoặc dùng ALB → WAF ← câu này

Thứ tự đánh giá rule trong WAF Web ACL:

Rule priority 0 → 1 → 2 → ...
    Khớp và action là Allow hoặc Block → DỪNG, quyết định luôn
    Khớp và action là Count             → ghi nhận rồi TIẾP TỤC
    Không khớp rule nào                 → dùng DEFAULT ACTION của Web ACL

Default action là chi tiết quan trọng: | Default action | Ý nghĩa | |---|---| | Allow | mặc định cho qua — rule dùng để CHẶN ← mô hình của câu này | | Block | mặc định chặn — rule dùng để CHO PHÉP (danh sách trắng) |

Bốn loại statement của WAF: | Loại | Việc | |---|---| | GeoMatchStatement | theo quốc gia (mã ISO hai chữ) | | IPSetReferenceStatement | theo danh sách IP/CIDR có tên | | RateBasedStatement | giới hạn tần suất (xem câu #7710) | | ByteMatchStatement, RegexMatchStatement | khớp nội dung request | | AndStatement, OrStatement, NotStatement | kết hợp logic |

IP set là tài nguyên riêng, quản lý độc lập với rule — nên đội phát triển đổi IP thì chỉ cập nhật IP set, không phải sửa Web ACL:

aws wafv2 update-ip-set --name doi-phat-trien --scope REGIONAL   --id abc123 --lock-token xyz   --addresses 203.0.113.0/24 198.51.100.15/32

Ba lưu ý khi triển khai: | Lưu ý | Lý do | |---|---| | Bắt đầu với action Count | xem rule sẽ chặn bao nhiêu request thật trước khi bật Block | | Bật log WAF | xác minh rule nào đang khớp (xem câu #7740) | | Nhớ IP của đội phát triển có thể đổi | IP động cần cơ chế cập nhật, hoặc dùng VPN có IP tĩnh |

Dòng cuối là vấn đề vận hành thật: đội phát triển làm việc từ xa thường có IP thay đổi. Giải pháp bền hơn là cho họ kết nối qua VPN của công ty có IP tĩnh, hoặc dùng xác thực ứng dụng thay vì dựa vào IP — chặn theo địa lý vốn chỉ nên là lớp bổ sung, không phải cơ chế kiểm soát truy cập chính.

Đáp án

D — Triển khai quy tắc tường lửa cục bộ bằng iptables trên các instance.

Vì sao đúng

Đề nêu ràng buộc quyết định: các đội đối tác cần truy cập SSH KHÔNG PHẢI root, và cần chặn họ dùng instance metadata service để lấy thông tin đăng nhập IAM.

Vì sao đây là mối nguy thật:

Người có shell trên instance:
    curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>
    → nhận về access key, secret key, session token của IAM ROLE
    → dùng chúng để chạm tới MỌI tài nguyên AWS mà role được phép

Đây chính là "assault on other AWS account resources" mà đề nói tới.

iptables với module owner chặn theo NGƯỜI DÙNG — đúng nhu cầu:

iptables --insert OUTPUT 1   --proto tcp --destination 169.254.169.254/32   --match owner ! --uid-owner root   --jump REJECT

Đọc rule này: từ chối mọi kết nối tới địa chỉ metadata trừ khi tiến trình chạy dưới quyền root.

Kết quả đúng như đề cần: | Ai | Truy cập metadata | |---|---| | Người dùng SSH không phải root (đối tác) | ❌ bị chặn | | Tiến trình chạy dưới root (ứng dụng, agent AWS) | ✅ vẫn dùng được |

Đây là điểm phân biệt với phương án C: tắt hẳn metadata service sẽ cắt luôn IAM role của chính ứng dụng — CloudWatch agent, SSM Agent, và bất kỳ SDK nào đều ngừng hoạt động.

(Với IPv6, cần thêm rule tương ứng cho fd00:ec2::254.)

Vì sao các phương án khác sai

• C. Tắt hẳn instance metadata service trên mọi instance — đây là phương án gần nhất và chặn được vấn đề, nhưng nó chặn quá tay: instance mất hoàn toàn khả năng dùng IAM role. Ứng dụng cần gọi API AWS sẽ phải quay lại dùng access key cứng — một bước lùi lớn về bảo mật.
• B. Cấu hình bắt buộc IMDSv2; phương thức hướng phiên sẽ không phản hồi các truy vấn request/response thông thường — hiểu sai IMDSv2 bảo vệ cái gì: nó chống SSRF (kẻ tấn công lừa ứng dụng web gọi tới metadata từ bên ngoài) bằng cách yêu cầu một token PUT trước. Nhưng người có shell trên máy lấy token đó dễ dàng:

  TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token"     -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
  curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/...
  

  IMDSv2 không bảo vệ trước người dùng cục bộ — mà đó chính là mối đe doạ trong đề.
• A. Cài phần mềm ngăn chặn xâm nhập (IPS) trên mỗi instance để chặn truy cập metadata — sai công cụ: IPS phát hiện và chặn mẫu tấn công mạng. Chặn một địa chỉ IP cụ thể theo người dùng là việc của tường lửa cục bộ, không phải IPS. Và nó nặng nề hơn nhiều so với một rule iptables.

Ghi nhớ

Ba cách kiểm soát instance metadata service: | Cách | Hiệu quả | Ảnh hưởng ứng dụng | |---|---|---| | Tắt hẳn IMDS | chặn tuyệt đối | ứng dụng mất IAM role | | Bắt buộc IMDSv2 | chống SSRF từ bên ngoài | không ảnh hưởng | | iptables theo người dùng | chặn người dùng cục bộ, giữ IAM role | không ảnh hưởng ← câu này |

Ba cách này chống ba mối đe doạ khác nhau — không thay thế nhau, và nên dùng kết hợp.

IMDSv1 và IMDSv2 — khác biệt và giới hạn: | | IMDSv1 | IMDSv2 | |---|---|---| | Cách gọi | GET trực tiếp | PUT lấy token, rồi GET kèm token | | Chống SSRF | ❌ | ✅ | | Chống người dùng có shell | ❌ | ❌ — token lấy được dễ dàng | | Giới hạn hop | — | http-put-response-hop-limit mặc định 1 |

hop-limit là cơ chế bảo vệ quan trọng của IMDSv2: với giá trị 1, gói tin lấy token không đi qua được container hay proxy — ngăn container thoát ra lấy thông tin đăng nhập của host.

Cấu hình IMDSv2 bắt buộc:

aws ec2 modify-instance-metadata-options   --instance-id i-0abc123   --http-tokens required   --http-put-response-hop-limit 1   --http-endpoint enabled

Ba mối đe doạ nhắm vào IMDS và biện pháp tương ứng: | Mối đe doạ | Biện pháp | |---|---| | SSRF qua ứng dụng web | IMDSv2 bắt buộc | | Container thoát ra lấy quyền của host | hop limit = 1 | | Người dùng có shell trên máy | iptables theo user ← câu này |

Và giải pháp kiến trúc tốt hơn cho tình huống của đề: nếu instance được chia sẻ cho bên ngoài, hãy cân nhắc không gắn IAM role có quyền đáng kể vào nó ngay từ đầu. Nguyên tắc là: máy mà người ngoài có shell thì không nên giữ thông tin đăng nhập chạm được tới tài nguyên quan trọng.

Bốn biện pháp bổ sung cho instance chia sẻ với bên ngoài: | Biện pháp | Lợi ích | |---|---| | IAM role quyền tối thiểu tuyệt đối | thiệt hại có hạn nếu bị lấy | | Tài khoản AWS riêng cho môi trường demo | cách ly hoàn toàn khỏi sản xuất | | Dùng Session Manager thay SSH | kiểm toán được toàn bộ phiên | | Ghi log phiên | biết ai đã gõ gì |

Dòng thứ hai là biện pháp mạnh nhất: đặt môi trường trình diễn trong một tài khoản riêng biến "assault on other AWS account resources" thành điều không thể xảy ra, bất kể ai lấy được gì trên máy đó.

Đáp án

A — Dùng encryption context để xác minh tính xác thực của lời gọi API KMS và tính toàn vẹn của bản mã do API Decrypt trả về.

Vì sao đúng

Đề dùng đúng thuật ngữ kỹ thuật: "authenticated encryption with associated data" (AEAD) — và encryption context chính là phần "associated data" đó.

Cách AEAD hoạt động trong KMS:

Encrypt(dữ liệu, encryption_context)
    → bản mã được RÀNG BUỘC mật mã học với encryption context
    → context được lưu dạng RÕ trong metadata của bản mã

Decrypt(bản mã, encryption_context)
    → KMS kiểm tra context có KHỚP với lúc mã hoá không
    → SAI context = giải mã THẤT BẠI, dù có đủ quyền

Ba thuộc tính mà encryption context cung cấp: | Thuộc tính | Chi tiết | |---|---| | Tính toàn vẹn | sửa bản mã hoặc context là giải mã hỏng | | Tính xác thực | chỉ giải mã được nếu biết đúng context | | Khả năng kiểm toán | context xuất hiện trong CloudTrail dạng rõ |

Ví dụ dùng:

kms.encrypt(
    KeyId='alias/khoa-ho-so',
    Plaintext=du_lieu,
    EncryptionContext={'ho-so-id': 'HS-12345', 'phong-ban': 'y-te'}
)

# Giải mã PHẢI truyền đúng context
kms.decrypt(
    CiphertextBlob=ban_ma,
    EncryptionContext={'ho-so-id': 'HS-12345', 'phong-ban': 'y-te'}
)

Và nó dùng được làm điều kiện trong policy — đây là ứng dụng mạnh nhất:

{"Effect": "Allow", "Action": "kms:Decrypt", "Resource": "*",
 "Condition": {"StringEquals": {
   "kms:EncryptionContext:phong-ban": "y-te"}}}

Role của phòng y tế chỉ giải mã được dữ liệu của phòng y tế — dù dùng chung một KMS key.

Vì sao các phương án khác sai

• B. Dùng chiến lược mã hoá phong bì (envelope encryption) của KMS để xác minh tính xác thực của lời gọi API và bảo vệ tính toàn vẹn của bản mã — đây là phương án gần nhất và nhầm mục đích của cơ chế: mã hoá phong bì là cách quản lý khoá hiệu quả (data key mã hoá dữ liệu, root key mã hoá data key). Nó không cung cấp associated data và không xác thực gì.
• C. Dùng MFA để xác minh tính xác thực của lời gọi API KMS — sai tầng: MFA xác thực người dùng, không xác thực dữ liệu. Nó không ràng buộc bản mã với ngữ cảnh nào cả.
• D. Dùng AWS CloudHSM để xác minh tính xác thực của lời gọi API và bảo vệ tính toàn vẹn của bản mã — CloudHSM là nơi LƯU khoá trong phần cứng chuyên dụng. Nó không liên quan tới AEAD hay associated data.

Ghi nhớ

Encryption context là gì và không phải gì: | Là | Không phải | |---|---| | Cặp khoá–giá trị dạng RÕ, được xác thực | bí mật — nó KHÔNG được mã hoá | | Associated data cho AEAD | cơ chế sinh khoá khác nhau | | Ghi vào CloudTrail — hữu ích cho kiểm toán | thay thế cho quyền IAM | | Dùng làm điều kiện trong key policy | |

Dòng đầu bên phải là cảnh báo quan trọng: đừng bao giờ đặt dữ liệu nhạy cảm vào encryption context — nó nằm dạng rõ trong metadata và trong log CloudTrail. Dùng cho định danh, phân loại, tên bên thuê — không dùng cho mật khẩu hay thông tin cá nhân.

Ba API của KMS chấp nhận encryption context: | API | Ghi chú | |---|---| | Encrypt / Decrypt | phải khớp nhau chính xác | | GenerateDataKey | context áp cho data key | | ReEncrypt | có context nguồn và context đích riêng |

Quy tắc khớp: context phải giống hệt cả khoá lẫn giá trị. Thứ tự các cặp không quan trọng, nhưng phân biệt chữ hoa chữ thường.

Ba ứng dụng thực tế của encryption context: | Ứng dụng | Cách dùng | |---|---| | Phân tách theo bên thuê (multi-tenant) | {"tenant-id": "khach-hang-A"} + điều kiện trong policy | | Ràng buộc theo tài nguyên | {"bucket": "ho-so-y-te", "key": "hs-12345.pdf"} | | Kiểm toán chi tiết | biết chính xác dữ liệu nào được giải mã, khi nào |

Dòng đầu là mẫu mạnh nhất: một KMS key phục vụ nhiều khách hàng, nhưng role của khách hàng A không giải mã được dữ liệu của khách hàng B — vì policy ràng buộc theo context.

Dịch vụ AWS tự đặt encryption context — điều đáng biết khi đọc CloudTrail: | Dịch vụ | Context | |---|---| | S3 | {"aws:s3:arn": "arn:aws:s3:::bucket/khoa"} | | EBS | {"aws:ebs:id": "vol-0abc123"} | | Secrets Manager | {"SecretARN": "...", "SecretVersionId": "..."} |

Nên bạn viết được policy ràng buộc theo tài nguyên cụ thể mà không cần tự quản lý context:

{"Condition": {"StringLike": {
   "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::ho-so-y-te/*"}}}

Và một chi tiết về khả năng khôi phục: vì giải mã bắt buộc phải có đúng encryption context, ứng dụng của bạn phải lưu lại hoặc dựng lại được context đó. Mất context nghĩa là mất khả năng giải mã — nên hãy dùng những giá trị suy ra được từ chính dữ liệu (như đường dẫn tệp hoặc ID bản ghi), đừng dùng giá trị ngẫu nhiên phải lưu riêng.

Đáp án

A — Dùng Amazon Detective kết hợp với Amazon GuardDuty để giám sát hoạt động độc hại và nhanh chóng xác định nguyên nhân gốc của các vấn đề bảo mật thông qua các tập dữ liệu được liên kết.

Vì sao đúng

Đề mô tả chính xác vấn đề mà Detective được tạo ra để giải quyết: mất vài giờ phân tích để hiểu nguyên nhân gốc của một sự cố, dù đã có đầy đủ CloudTrail và VPC Flow Logs.

Vấn đề không phải thiếu dữ liệu — mà là dữ liệu nằm rời rạc:

CloudTrail:      hàng triệu bản ghi lời gọi API
VPC Flow Logs:   hàng chục triệu bản ghi luồng mạng
GuardDuty:       một finding nói "có gì đó bất thường"

→ Nối chúng lại bằng tay = hàng giờ truy vấn thủ công

Detective làm chính việc nối đó, tự động:

Detective tự thu thập CloudTrail + VPC Flow Logs + GuardDuty finding + EKS audit log
    ↓ dựng ĐỒ THỊ HÀNH VI
Quan hệ giữa: tài khoản ↔ người dùng ↔ role ↔ IP ↔ instance ↔ finding
    ↓ theo trục thời gian
"Điều gì bất thường so với hành vi bình thường của thực thể này?"

Ba câu hỏi Detective trả lời nhanh mà truy vấn thủ công thì chậm: | Câu hỏi | Detective cung cấp | |---|---| | Hành vi này có bất thường không? | so với đường cơ sở lịch sử của chính thực thể đó | | Nó bắt đầu từ đâu? | dòng thời gian đầy đủ của thực thể | | Nó đã lan tới đâu? | đồ thị các tài nguyên liên quan |

Và ưu điểm vận hành đáng kể: Detective không đòi bạn cấu hình nguồn dữ liệu. Nó lấy trực tiếp từ hạ tầng AWS — bật là chạy, không cần bật VPC Flow Logs hay xuất log đi đâu.

Vì sao cần cả GuardDuty: Detective là công cụ điều tra, không phải công cụ phát hiện. Nó cần một điểm khởi đầu — và finding của GuardDuty chính là điểm đó.

Vì sao các phương án khác sai

• D. Dùng AWS Security Hub, nơi tổng hợp, sắp xếp và ưu tiên cảnh báo từ nhiều dịch vụ AWS để phân tích dữ liệu bảo mật ở một chỗ, tiện cho việc phân tích nguyên nhân gốc — đây là phương án gần nhất và Security Hub là mảnh ghép quan trọng, nhưng nó tổng hợp cảnh báo, không phân tích nguyên nhân. Nó cho bạn danh sách "có những vấn đề gì", còn câu hỏi "vì sao và như thế nào" là của Detective. (Trong thực tế bạn đi từ Security Hub sang Detective — xem câu #7738.)
• B. Cấu hình GuardDuty giám sát liên tục, tích hợp vào hệ thống quy trình và gọi Lambda tự động khắc phục — GuardDuty phát hiện, không điều tra: nó nói "có hoạt động đáng ngờ ở instance X", nhưng không nói vì sao và nó đã dẫn tới đâu. Và tự động khắc phục là hành động, không phải phân tích nguyên nhân.
• C. Dùng Amazon Inspector quét lỗ hổng, tích hợp Security Hub và EventBridge để tự động hoá quy trình phân tích nguyên nhân gốc — sai loại dữ liệu: Inspector tìm lỗ hổng phần mềm chưa vá. Nó không phân tích log và không dựng được chuỗi sự kiện của một sự cố.

Ghi nhớ

Bốn dịch vụ và bốn câu hỏi khác nhau: | Dịch vụ | Trả lời | |---|---| | GuardDuty | "CÓ chuyện gì bất thường không?" — phát hiện | | Security Hub | "Tổng hợp mọi cảnh báo, tôi ở mức tuân thủ nào?" — tổng hợp | | Detective | "VÌ SAO chuyện đó xảy ra, nó lan tới đâu?" — điều tra | | Inspector | "Phần mềm có lỗ hổng không?" — phòng ngừa |

Bốn dịch vụ này bổ sung nhau và tạo thành một quy trình hoàn chỉnh:

Inspector    → giảm rủi ro trước khi có sự cố
GuardDuty    → phát hiện khi có sự cố
Security Hub → tập hợp và ưu tiên
Detective    → điều tra nguyên nhân và phạm vi

Bốn nguồn dữ liệu của Detective — tự động, không cần cấu hình: | Nguồn | Cung cấp | |---|---| | CloudTrail | ai gọi API gì | | VPC Flow Logs | luồng mạng | | GuardDuty finding | điểm khởi đầu điều tra | | EKS audit log | hoạt động trong cụm Kubernetes | | RDS login activity | đăng nhập cơ sở dữ liệu |

Ba khả năng đặc trưng của Detective: | Khả năng | Chi tiết | |---|---| | Đồ thị hành vi | quan hệ giữa các thực thể theo thời gian | | Đường cơ sở tự học | "IP này chưa từng gọi API này trong 45 ngày qua" | | Finding groups | nhóm các finding liên quan thành một sự cố duy nhất |

Dòng cuối tiết kiệm rất nhiều thời gian: thay vì điều tra 20 finding riêng lẻ, Detective cho biết chúng là một cuộc tấn công với một chuỗi nguyên nhân chung.

Ba lưu ý khi dùng Detective: | Lưu ý | Chi tiết | |---|---| | Cần bật GuardDuty ít nhất 48 giờ trước | Detective cần dữ liệu để dựng đường cơ sở | | Là dịch vụ theo Region | bật ở mọi Region cần điều tra | | Hỗ trợ delegated administrator | một tài khoản bảo mật điều tra cho cả tổ chức |

Và một lưu ý về chi phí: Detective tính phí theo khối lượng dữ liệu nạp vào (GB log mỗi tháng). Với môi trường lớn, khoản này đáng kể — nhưng so với "vài giờ phân tích" mỗi lần có sự cố mà đề mô tả, nó thường vẫn rẻ hơn thời gian của đội bảo mật.

Cuối cùng, một điểm về chính tình huống trong đề: sự cố xuất phát từ lỗi nội bộ của đội hỗ trợ, không phải tấn công. Detective vẫn hữu ích — nó dựng lại được chuỗi thao tác dẫn tới sự cố. Nhưng cho loại vấn đề này, CloudTrail Lake hoặc CloudWatch Logs Insights truy vấn trực tiếp cũng là công cụ hợp lý, và thường rẻ hơn.

Đáp án

B — Xem xét thông báo về lạm dụng và trả lời, giải thích cách bạn sẽ ngăn hoạt động lạm dụng đó tái diễn trong tương lai.

Vì sao đúng

Đề mô tả tình huống chính thức: AWS gửi abuse notice báo rằng tài nguyên trong tài khoản của bạn bị báo cáo có hoạt động lạm dụng.

Quy trình chính thức của AWS yêu cầu bạn PHẢN HỒI, và có thời hạn:

AWS gửi abuse notice tới địa chỉ liên hệ về lạm dụng của tài khoản
    ↓ bạn có thời hạn phản hồi (thường 24 giờ)
    ├─ TRẢ LỜI với nguyên nhân + biện pháp khắc phục  → tài khoản an toàn
    └─ KHÔNG trả lời → AWS có thể ĐÌNH CHỈ tài khoản

Nội dung phản hồi cần có ba phần: | Phần | Chi tiết | |---|---| | Điều gì đã xảy ra | nguyên nhân gốc — instance bị xâm nhập, cấu hình sai, hay hành vi hợp lệ bị hiểu nhầm | | Bạn đã làm gì | biện pháp đã thực hiện để dừng nó | | Ngăn tái diễn thế nào | thay đổi về quy trình hoặc kỹ thuật |

Vì sao trả lời là bắt buộc chứ không phải tuỳ chọn: AWS không thể biết bạn có đang xử lý hay không. Im lặng bị hiểu là tài khoản đã bị bỏ mặc hoặc đang bị kiểm soát bởi kẻ tấn công — và biện pháp bảo vệ những người dùng khác trên Internet là đình chỉ tài khoản đó.

Ba loại hoạt động thường bị báo cáo: | Loại | Nguyên nhân thường gặp | |---|---| | Quét cổng, brute force | instance bị xâm nhập, dùng làm bàn đạp | | Phát tán mã độc, lừa đảo | website bị chiếm quyền | | Gửi thư rác | EC2 gửi email hàng loạt | | Vi phạm bản quyền | nội dung lưu trữ trên S3 |

Và điều đáng nhớ: phần lớn abuse notice không phải do bạn cố ý làm gì sai — mà do một tài nguyên của bạn đã bị người khác chiếm quyền. Nên bước điều tra đầu tiên thường là kiểm tra xem instance đó có bị xâm nhập không.

Vì sao các phương án khác sai

• A. Đảm bảo các instance và ứng dụng được bảo mật đúng theo mô hình trách nhiệm chung — đây là phương án gần nhất và là việc đúng nên làm, nhưng nó không phải bước ứng phó với thông báo. Làm việc này mà không trả lời AWS thì tài khoản vẫn có nguy cơ bị đình chỉ.
• C. Đội AWS Trust & Safety cung cấp HỖ TRỢ KỸ THUẬT cho các vấn đề liên quan tới lạm dụng; liên hệ để họ hỗ trợ giải quyết — hiểu sai vai trò của đội này: Trust & Safety xử lý báo cáo lạm dụng, họ không cung cấp hỗ trợ kỹ thuật để bạn gỡ lỗi hệ thống. Hỗ trợ kỹ thuật là của AWS Support.
• D. Hỗ trợ kỹ thuật từ Trust & Safety chỉ dành cho tài khoản Enterprise và Business; nâng cấp tài khoản rồi liên hệ — cùng lỗi như C, cộng thêm một điều kiện không có thật. Abuse notice áp cho mọi tài khoản bất kể gói hỗ trợ, và việc phản hồi không đòi gói trả phí nào.

Ghi nhớ

Quy trình xử lý abuse notice:

① ĐỌC kỹ thông báo    → xác định tài nguyên nào, hành vi gì, thời điểm nào
② ĐIỀU TRA            → tài nguyên đó có bị xâm nhập không?
③ KHẮC PHỤC           → cách ly, snapshot điều tra, dừng hoạt động
④ TRẢ LỜI AWS         → nguyên nhân + biện pháp + kế hoạch ngăn tái diễn  ← BẮT BUỘC
⑤ NGĂN NGỪA           → sửa lỗ hổng gốc rễ

Bước ④ có thời hạn — đừng để tới khi điều tra xong hoàn toàn mới trả lời. Nếu cần thêm thời gian, hãy trả lời rằng bạn đang điều tra và nêu các bước đã làm.

Hai kênh liên hệ khác nhau của AWS — đừng nhầm: | Kênh | Xử lý | |---|---| | AWS Trust & Safety (abuse@amazonaws.com) | báo cáo lạm dụng — cả chiều gửi lẫn nhận | | AWS Support | hỗ trợ kỹ thuật, sự cố dịch vụ |

Ba cách đặt liên hệ để không bỏ lỡ thông báo: | Việc | Lý do | |---|---| | Đặt "Alternate Contact" cho Security và Operations | thông báo tới đúng đội, không nằm trong hộp thư của một cá nhân | | Dùng hộp thư nhóm, không dùng email cá nhân | người nghỉ việc không làm mất kênh liên lạc | | Kiểm tra hộp thư rác | abuse notice hay bị lọc |

Dòng đầu là việc nên làm ngay hôm nay nếu chưa làm: rất nhiều tài khoản bị đình chỉ chỉ vì thông báo gửi tới email của người đã rời công ty.

Ba nguyên nhân gốc phổ biến và cách ngăn: | Nguyên nhân | Biện pháp | |---|---| | Access key bị lộ trong mã nguồn | dùng IAM role, quét bí mật trong repo | | Instance chưa vá bị khai thác | Inspector + Patch Manager | | Security group mở cổng quản trị ra Internet | Config rule restricted-ssh, dùng Session Manager |

Và một biện pháp phát hiện sớm để bạn biết trước khi AWS phải báo: bật GuardDuty ở mọi Region. Các finding như UnauthorizedAccess:EC2/SSHBruteForce (chiều đi ra) hoặc Backdoor:EC2/Spambot báo hiệu chính xác những hành vi sẽ dẫn tới abuse notice — và phát hiện chúng trước cho bạn cơ hội xử lý mà không có báo cáo từ bên ngoài nào cả.

Đáp án

C — Tạo một CMK MỚI và nhập key material mới vào đó; sau đó trỏ key alias của CMK cũ sang CMK mới.

Vì sao đúng

Đề nêu hai ràng buộc, và chúng xung đột với nhau theo cách thú vị: | Ràng buộc | Hệ quả | |---|---| | Phải dùng key material do công ty tự nhập | origin = EXTERNAL | | Mọi khoá phải xoay vòng hằng năm | cần cơ chế xoay vòng |

Xung đột: KMS key với key material nhập khẩu KHÔNG hỗ trợ xoay vòng tự động.

Key material AWS_KMS  → RotateKeyOnDemand hoặc tự động hằng năm ✓
Key material EXTERNAL → KHÔNG có xoay vòng tự động ✗

Lý do hiển nhiên: AWS không có key material mới của bạn để thay vào — chỉ bạn mới sinh ra nó được.

Nên xoay vòng thủ công, và alias là mắt xích khiến việc đó không gây gián đoạn:

Trước:
  alias/khoa-san-xuat  ──→  CMK-cũ (key material năm 2025)

Sau khi xoay vòng:
  alias/khoa-san-xuat  ──→  CMK-mới (key material năm 2026)
  CMK-cũ vẫn TỒN TẠI  ──→  để giải mã dữ liệu cũ

Vì sao phải GIỮ CMK cũ — đây là điểm quan trọng nhất: | Dữ liệu | Cần khoá nào | |---|---| | Mã hoá TỪ NAY trở đi | CMK mới (qua alias) | | Đã mã hoá TRƯỚC ĐÓ | CMK CŨ — không có nó là mất vĩnh viễn |

Và alias là lý do ứng dụng không cần sửa gì:

# Mã ứng dụng không đổi qua các lần xoay vòng
kms.encrypt(KeyId='alias/khoa-san-xuat', Plaintext=du_lieu)

Chỉ cần cập nhật alias:

aws kms update-alias --alias-name alias/khoa-san-xuat   --target-key-id <id-cua-CMK-moi>

Vì sao các phương án khác sai

• A. Bật xoay vòng tự động cho KMS key có key material nhập khẩu để xoay vòng hằng năm — đây là phương án gần nhất và không thực hiện được: xoay vòng tự động chỉ hoạt động với key material do KMS sinh ra (origin AWS_KMS). Với key material nhập khẩu, tuỳ chọn này không khả dụng.
• B. Liên kết CMK hiện có với key material mới rồi chạy thao tác List để cập nhật liên kết — không có cơ chế như vậy: bạn không "gắn key material mới" vào một CMK đang có. Muốn nhập material khác thì phải DeleteImportedKeyMaterial trước — và làm vậy mất khả năng giải mã toàn bộ dữ liệu cũ. Thao tác List cũng không liên quan gì.
• D. Xoá KMS key cũ trước rồi tạo khoá mới cùng tên ngay lập tức, nhập key material mới vào — phá huỷ dữ liệu: xoá CMK cũ khiến mọi dữ liệu mã hoá bằng nó không giải mã được nữa (xem câu #7737). Và "cùng tên" không giúp gì — khoá được nhận dạng bằng key ID, không phải tên.

Ghi nhớ

Xoay vòng khoá theo loại key material: | Origin | Xoay vòng tự động | Cách xoay vòng | |---|---|---| | AWS_KMS | ✅ hằng năm hoặc chu kỳ tuỳ chọn | bật một cờ | | EXTERNAL | ❌ KHÔNG | tạo CMK mới + chuyển alias ← câu này | | AWS_CLOUDHSM | ❌ | tương tự thủ công |

Xoay vòng tự động của KMS hoạt động thế nào — khác hẳn xoay vòng thủ công: | | Tự động (AWS_KMS) | Thủ công (alias) | |---|---|---| | Key ID và ARN | KHÔNG đổi | đổi (CMK mới) | | Key material cũ | KMS giữ lại bên trong | CMK cũ vẫn tồn tại | | Ứng dụng phải sửa | ❌ | ❌ (nhờ alias) | | Dữ liệu cũ | tự giải mã được | cần giữ CMK cũ |

Điểm chung quan trọng: cả hai cách đều KHÔNG mã hoá lại dữ liệu cũ. Xoay vòng chỉ ảnh hưởng tới dữ liệu mã hoá từ đó trở đi.

Ba lý do dùng key material nhập khẩu: | Lý do | Chi tiết | |---|---| | Yêu cầu tuân thủ về nguồn gốc khoá | ← câu này | | Giữ bản sao khoá ngoài AWS | escrow | | Xoá tức thì khi cần | DeleteImportedKeyMaterial (xem câu #7702) |

Bốn cái giá phải trả: | Cái giá | Chi tiết | |---|---| | Bạn chịu trách nhiệm bảo quản | mất key material = mất dữ liệu vĩnh viễn | | Không xoay vòng tự động | ← câu này | | Quy trình nhập phức tạp | tải public key + import token, mã hoá, nhập | | Không dùng được multi-Region key nhập tự động | phải nhập riêng từng Region |

Ba thực hành khi quản lý alias: | Thực hành | Lý do | |---|---| | Ứng dụng LUÔN dùng alias, không dùng key ID | xoay vòng không cần sửa mã | | Đặt tên alias theo mục đích, không theo ngày | alias/khoa-ho-so chứ không phải alias/khoa-2026 | | Ghi tài liệu CMK nào phục vụ giai đoạn nào | cần khi khôi phục dữ liệu cũ |

Dòng cuối là việc phải làm sau vài năm xoay vòng: bạn sẽ có nhiều CMK cũ, và khi cần khôi phục một bản sao lưu từ 2027, phải biết nó dùng CMK nào. Gắn tag cho từng CMK với khoảng thời gian nó phục vụ là cách đơn giản để không lạc.

Và một lưu ý về xoá CMK cũ: đừng xoá chúng theo lịch dọn dẹp. Chỉ xoá khi bạn chắc chắn không còn bản sao lưu, snapshot hay object nào được mã hoá bằng nó — và điều đó thường có nghĩa là sau khi mọi dữ liệu trong chu kỳ lưu trữ đã hết hạn.

Đáp án

D và E.

• D — Tạo AWS WAF rule của riêng bạn trong Web ACL để giảm thiểu cuộc tấn công
• E — Bạn có thể liên hệ AWS Support để được hỗ trợ giảm thiểu nếu là khách hàng Shield Advanced

Vì sao đúng

Đề mô tả tình huống khẩn cấp: tấn công DDoS tầng ứng dụng (tầng 7) đang diễn ra, và cần phản ứng tức thì để hạn chế thiệt hại.

D — WAF là công cụ đúng cho tấn công tầng 7:

Tấn công tầng 7 = request HTTP hợp lệ về mặt giao thức
    → không phân biệt được bằng cách lọc IP hay cổng
    → phải phân tích NỘI DUNG request để tìm mẫu chung
WAF rule tuỳ chỉnh làm được điều đó

Ba loại rule thường dùng để dập một cuộc tấn công đang diễn ra: | Rule | Chống | |---|---| | Rate-based rule | request dồn dập từ một IP | | Byte match / regex | User-Agent, đường dẫn, header đặc trưng của bot | | Geo match | tấn công tập trung từ một khu vực | | CAPTCHA / Challenge | phân biệt người và bot mà không chặn hẳn |

Dòng cuối đáng ưu tiên trong lúc bị tấn công: Challenge gửi một thử thách JavaScript im lặng — bot không vượt qua, người dùng thật không nhận ra. Nó giảm rủi ro chặn nhầm so với Block khi bạn phải ra quyết định gấp.

E — Shield Response Team (SRT): với Shield Advanced, bạn có quyền gọi đội chuyên trách của AWS 24/7. Họ có công cụ và tầm nhìn ở tầng hạ tầng mà bạn không có, và họ viết hoặc điều chỉnh WAF rule thay bạn ngay trong lúc tấn công.

Nên hai đáp án này bổ trợ nhau: bạn tự dập bằng WAF ngay lập tức, đồng thời gọi SRT vào cuộc.

Vì sao các phương án khác sai

• C. Giám sát các metric CloudWatch: kích thước tối đa của Auto Scaling group, CPUUtilization và NetworkIn của EC2 để phát hiện tấn công DDoS và gửi thông báo SNS — đây là phương án gần nhất và là giám sát hợp lý, nhưng nó chỉ phát hiện và thông báo. Đề nói tấn công đang diễn ra và hỏi phản ứng để kiểm soát thiệt hại — biết thêm về cuộc tấn công không làm nó dừng lại.
• A. Bật GuardDuty để tự động giám sát hoạt động độc hại và chặn truy cập trái phép — GuardDuty KHÔNG chặn gì cả: nó chỉ phát hiện và sinh finding. Và nó không được thiết kế để phát hiện DDoS — đó là việc của Shield.
• B. Định nghĩa một SSM document chặn mọi cổng dễ bị tấn công, khoá truy cập công khai vào S3, và dừng lưu lượng Internet tới các EC2 bị ảnh hưởng — cách chữa tệ hơn bệnh: dừng lưu lượng Internet tới EC2 nghĩa là tự làm ứng dụng ngừng phục vụ — chính là mục tiêu mà kẻ tấn công muốn đạt được. Và khoá S3 không liên quan gì tới DDoS tầng 7.

Ghi nhớ

Ba lớp phòng thủ DDoS trên AWS: | Lớp | Chống | Chi phí | |---|---|---| | Shield Standard | tầng 3/4 phổ biến | MIỄN PHÍ, bật sẵn cho mọi tài khoản | | AWS WAF | tầng 7 theo quy tắc | tính phí | | Shield Advanced | tầng 3/4/7 nâng cao + SRT + bảo vệ chi phí | 3.000 USD/tháng |

Tấn công tầng 3/4 và tầng 7 — phân biệt: | | Tầng 3/4 | Tầng 7 | |---|---|---| | Ví dụ | SYN flood, UDP reflection | HTTP flood, slowloris, tấn công vào API tốn tài nguyên | | Đặc điểm | khối lượng lớn, gói tin dị thường | request HỢP LỆ, khó phân biệt với người dùng thật | | Chống bằng | Shield (tự động) | WAF (cần quy tắc) |

Dòng giữa giải thích vì sao tầng 7 khó hơn: một request HTTP GET tới trang chủ là hoàn toàn hợp lệ — vấn đề chỉ là có một triệu cái như vậy mỗi giây.

Bốn quyền lợi của Shield Advanced: | Quyền lợi | Chi tiết | |---|---| | Shield Response Team (SRT) | hỗ trợ 24/7 trong lúc tấn công ← đáp án E | | Bảo vệ chi phí | hoàn phí cho chi phí scale do tấn công gây ra | | WAF bao gồm | không tính phí riêng | | Metric và báo cáo chi tiết | DDoSDetected và các metric quy mô (xem câu #7716) |

Dòng thứ hai đáng nhắc: một cuộc tấn công lớn có thể sinh hoá đơn truyền dữ liệu và auto scaling rất lớn — và bảo vệ chi phí một mình đã có thể bù lại phần lớn phí thuê bao.

Bốn biện pháp kiến trúc giảm rủi ro DDoS — chuẩn bị trước, không phải lúc bị tấn công: | Biện pháp | Lợi ích | |---|---| | CloudFront trước ứng dụng | hấp thụ tấn công ở edge, trên hạ tầng toàn cầu của AWS | | Auto Scaling | chịu tải cao hơn thay vì sập | | Ẩn origin, chỉ nhận từ CloudFront | kẻ tấn công không đánh thẳng vào origin được | | Route 53 (đã có bảo vệ DDoS sẵn) | DNS không thành điểm sập |

Dòng thứ ba là việc hay bị quên: đặt CloudFront trước nhưng vẫn để ALB nhận lưu lượng từ 0.0.0.0/0 thì kẻ tấn công tìm ra IP của ALB và bỏ qua toàn bộ lớp bảo vệ. Dùng prefix list com.amazonaws.global.cloudfront.origin-facing trong security group của ALB để bịt đường đó.

Ba việc nên chuẩn bị TRƯỚC khi bị tấn công: | Việc | Lý do | |---|---| | Bật proactive engagement của Shield Advanced | SRT tự vào cuộc, không cần bạn mở ticket | | Uỷ quyền trước cho SRT sửa Web ACL | tiết kiệm thời gian quý giá lúc khẩn cấp | | Có sẵn runbook và WAF rule mẫu | không phải viết rule lần đầu trong lúc hoảng |

Dòng đầu là khác biệt lớn nhất về thời gian phản ứng — thay vì bạn phát hiện, gọi hỗ trợ, chờ tiếp nhận, thì SRT đã đang xử lý.

Đáp án

B — Kiểm tra xem thông tin đăng nhập của IAM user có nằm trong tệp .aws/credentials không. Vì thông tin này có thứ tự ưu tiên CAO HƠN thông tin của role, nó sẽ được dùng cho các lời gọi API. Xoá tệp credentials đó.

Vì sao đúng

Đề mô tả triệu chứng rất cụ thể: IAM role đã gắn vào instance, nhưng lời gọi API vẫn thực hiện dưới danh nghĩa một IAM user.

Nguyên nhân nằm ở chuỗi tìm kiếm thông tin đăng nhập (credential provider chain) của AWS SDK và CLI:

① Tham số truyền trực tiếp trong mã
② Biến môi trường          AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
③ Tệp ~/.aws/credentials   ← THỦ PHẠM
④ Tệp ~/.aws/config
⑤ Container credentials    (ECS task role)
⑥ IMDS — IAM ROLE của instance  ← ĐỨNG CUỐI

SDK dừng ở nguồn ĐẦU TIÊN tìm thấy — nên nếu ai đó từng chạy aws configure trên máy này, tệp .aws/credentials được tạo ra và luôn thắng IAM role.

Triệu chứng đặc trưng giúp nhận diện:

aws sts get-caller-identity
# Kỳ vọng: "Arn": "arn:aws:sts::123456789012:assumed-role/role-ung-dung/i-0abc123"
# Thực tế: "Arn": "arn:aws:iam::123456789012:user/nguoi-nao-do"

Cách khắc phục:

rm ~/.aws/credentials
# Kiểm tra cả biến môi trường (mức ưu tiên còn cao hơn)
env | grep AWS_
# và các profile khác
cat ~/.aws/config

Và đây là vấn đề bảo mật, không chỉ là cấu hình sai: access key dài hạn nằm trên đĩa của một EC2 instance là thứ có thể bị đánh cắp — đúng loại rủi ro mà IAM role sinh ra để loại bỏ.

Vì sao các phương án khác sai

• C. IAM role gắn vào không đủ quyền để gọi API, nên thông tin đăng nhập mặc định của instance được dùng thay; hãy thêm quyền cho role — đây là phương án gần nhất và mô tả một cơ chế không tồn tại: AWS SDK KHÔNG tự chuyển sang nguồn khác khi bị từ chối quyền. Nếu role thiếu quyền, lời gọi trả về AccessDenied — nó vẫn được thực hiện dưới danh nghĩa role, không đổi sang user nào cả.
• A. Instance cần được làm mới (refresh) sau khi gắn IAM role — không cần: gắn hoặc đổi instance profile có hiệu lực trong vòng vài phút mà không cần khởi động lại. Và nếu vấn đề là độ trễ, triệu chứng sẽ là "không có thông tin đăng nhập", chứ không phải "dùng nhầm IAM user".
• D. Bạn không liên kết được IAM role với task definition của Amazon ECS; liên kết không báo lỗi nhưng thông tin đăng nhập không được dùng — hãy dùng service-based role — sai cả nội dung lẫn ngữ cảnh: ECS CÓ hỗ trợ IAM role cho task (task role), và đề đang nói về EC2 instance, không phải ECS task.

Ghi nhớ

Chuỗi tìm kiếm thông tin đăng nhập — bảng cần thuộc:

① Tham số trong mã (hard-code)
② Biến môi trường
③ ~/.aws/credentials
④ ~/.aws/config
⑤ Container credentials (ECS/EKS)
⑥ IMDS (IAM role của EC2)

IAM role đứng CUỐI — nghĩa là bất kỳ nguồn nào ở trên cũng ghi đè nó.

Ba nơi cần kiểm tra khi role không được dùng: | Nơi | Lệnh | |---|---| | Biến môi trường | env \| grep AWS_ | | Tệp credentials | cat ~/.aws/credentials | | Tệp config (profile) | cat ~/.aws/config |

Nhớ kiểm tra cho ĐÚNG người dùng đang chạy ứng dụng — ứng dụng chạy dưới user app thì tệp cần xem là /home/app/.aws/credentials, không phải của ec2-user.

Lệnh chẩn đoán quan trọng nhất:

aws sts get-caller-identity

Nó cho biết chính xác danh tính đang được dùng — và nên là lệnh đầu tiên khi gỡ lỗi mọi vấn đề về quyền.

Ba lợi ích của IAM role so với access key trên EC2: | Lợi ích | Chi tiết | |---|---| | Thông tin đăng nhập TẠM THỜI | tự xoay vòng, hết hạn sau vài giờ | | Không có bí mật nào trên đĩa | không có gì để rò rỉ | | Không cần xoay vòng thủ công | bỏ hẳn nhu cầu ở câu #7724 |

Ba biện pháp đảm bảo role thực sự được dùng: | Biện pháp | Chi tiết | |---|---| | Kiểm tra trong quy trình triển khai | chạy sts get-caller-identity và xác nhận là role | | Không cài AWS CLI profile trên máy sản xuất | và không chạy aws configure ở đó | | Quét tìm access key trên đĩa | như một phần của kiểm tra tuân thủ |

Và một điểm về nguồn gốc vấn đề: tệp .aws/credentials trên một instance sản xuất thường xuất hiện vì ai đó gỡ lỗi trên máy đó rồi quên dọn — hoặc tệ hơn, vì nó được nướng sẵn vào AMI. Trường hợp thứ hai nghiêm trọng hơn nhiều: mọi instance khởi chạy từ AMI đó đều mang theo cùng một access key, và AMI có thể đã được chia sẻ.

Cuối cùng, một biến thể đáng biết: với container trên ECS, thứ tự cũng tương tự — task role (⑤) thắng IMDS của instance (⑥), nhưng vẫn thua biến môi trường và tệp credentials trong image. Nên đóng gói access key vào container image gây ra đúng vấn đề này ở quy mô lớn hơn.