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

Đáp án

B — Cấu hình NLB với TLS listener, dùng chứng chỉ từ ACM Private CA, và bật mutual TLS (mTLS) để xác thực chứng chỉ phía client.

Vì sao đúng

Đề yêu cầu xác thực lẫn nhau bằng chứng chỉ — cả máy chủ lẫn client đều chứng minh danh tính.

mTLS khác TLS thông thường ở chiều xác thực:

TLS thông thường:
  Client xác minh chứng chỉ của MÁY CHỦ
  → client biết đang nói chuyện với đúng ai
  → máy chủ KHÔNG biết client là ai (phải xác thực bằng cách khác)

Mutual TLS:
  Client xác minh chứng chỉ máy chủ
  VÀ máy chủ xác minh chứng chỉ CLIENT
  → xác thực HAI CHIỀU ngay ở tầng vận chuyển

Vì sao ACM Private CA: | Nhu cầu | Cơ chế | |---|---| | Cấp chứng chỉ cho CLIENT | CA công khai không cấp chứng chỉ client cho bạn | | Kiểm soát ai được cấp | bạn vận hành CA | | Thu hồi được | CRL hoặc OCSP | | Không tốn chi phí CA công khai cho mỗi client | |

Điểm quan trọng: ACM (công khai) KHÔNG cấp chứng chỉ client — nó chỉ cấp chứng chỉ máy chủ cho tên miền bạn sở hữu. Muốn cấp chứng chỉ cho từng client thì cần CA riêng, và ACM Private CA là dịch vụ được quản lý cho việc đó.

Về NLB và mTLS: | Chế độ | Hành vi | |---|---| | passthrough | NLB chuyển tiếp chứng chỉ client tới backend — backend tự xác minh | | verify | NLB tự xác minh chứng chỉ client với trust store |

Chế độ thứ hai (ra mắt 2023) cho phép NLB chấm dứt mTLS ngay tại load balancer, gỡ gánh nặng xác minh khỏi backend.

Và NLB phù hợp cho mTLS vì nó ở tầng 4: nó chuyển tiếp được nguyên vẹn quá trình bắt tay TLS khi cần, thứ mà ALB (tầng 7) trước đây không làm được.

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

• **A. Cấu hình ALB với HTTPS listener, dùng chứng chỉ ACM, và bật xác thực client bằng chứng chỉ do CA công khai cấp — đây là phương án gần nhất và sai ở nguồn chứng chỉ client: CA công khai không cấp chứng chỉ client cho tổ chức của bạn. Chứng chỉ client cần một CA riêng mà bạn kiểm soát. (ALB có hỗ trợ mTLS từ 2023, nhưng cũng dùng trust store với CA riêng, không phải CA công khai.)
• C. Cấu hình CloudFront với chứng chỉ ACM và bật xác thực client bằng chứng chỉ do CA công khai cấp — CloudFront không hỗ trợ mTLS với client: nó xác thực với origin được (origin custom headers, OAC), nhưng không xác minh chứng chỉ của client cuối. Và lỗi CA công khai như phương án A.
• D. Cấu hình API Gateway với chứng chỉ ACM và bật xác thực client bằng chứng chỉ do CA công khai cấp — API Gateway CÓ hỗ trợ mTLS (từ 2021, cho REST và HTTP API), nên phần cơ chế không sai. Nhưng nó vẫn mắc lỗi CA công khai: trust store của API Gateway là một bundle CA bạn tự tải lên S3, chứa CA riêng của bạn.

Ghi nhớ

Ba dịch vụ AWS hỗ trợ mTLS: | Dịch vụ | Chế độ | |---|---| | NLB | passthrough hoặc verify ← câu này | | ALB | verify (từ 2023), có trust store | | API Gateway | trust store là bundle CA trên S3 | | App Mesh, Service Connect | mTLS giữa các service nội bộ |

Cả ba đều cần CA riêng — đó là điểm chung và là lý do loại các phương án nhắc tới CA công khai.

ACM và ACM Private CA — phân biệt: | | ACM (công khai) | ACM Private CA | |---|---|---| | Cấp chứng chỉ cho | tên miền bạn sở hữu | bất cứ gì bạn muốn | | Chứng chỉ client | ❌ không | ✅ có | | Xuất private key | ❌ không | ✅ có | | Trình duyệt tin cậy | ✅ | ❌ (phải cài CA root) | | Chi phí | miễn phí | tính phí theo CA và chứng chỉ |

Ba dòng giữa là những khác biệt hay bị hỏi: ACM công khai không xuất private key (nên không cài lên EC2 được — xem câu #7690) và không cấp chứng chỉ client.

Bốn thành phần của một hệ thống mTLS: | Thành phần | Việc | |---|---| | CA (ACM Private CA) | cấp chứng chỉ cho cả máy chủ và client | | Chứng chỉ máy chủ | trên NLB/ALB | | Chứng chỉ client | phân phối tới từng client | | Trust store | danh sách CA mà máy chủ tin cậy | | CRL hoặc OCSP | thu hồi chứng chỉ khi client bị xâm nhập |

Dòng cuối là phần hay bị bỏ qua nhưng thiết yếu: không có cơ chế thu hồi thì một chứng chỉ client bị lộ vẫn dùng được tới ngày hết hạn — có thể là hàng năm.

Ba tình huống mTLS phù hợp: | Tình huống | Lý do | |---|---| | Giao tiếp máy-với-máy (B2B API) | không có người dùng để nhập mật khẩu | | Thiết bị IoT | chứng chỉ nhúng trong thiết bị | | Kiến trúc zero trust nội bộ | mọi kết nối phải chứng minh danh tính |

Và một cân nhắc vận hành thật: mTLS đẩy gánh nặng sang việc quản lý vòng đời chứng chỉ. Với hàng nghìn client, bạn cần quy trình tự động cho việc cấp, gia hạn và thu hồi — nếu không, chứng chỉ hết hạn hàng loạt sẽ gây sự cố lớn hơn vấn đề mà mTLS giải quyết.

Đáp án

B và C.

• B — Cấu hình security group của EFS mount target chỉ cho phép lưu lượng NFS (cổng 2049) từ security group của các EC2 instance được phép
• C — Dùng IAM policy kiểm soát truy cập vào EFS file system

Vì sao đúng

Đề yêu cầu hạn chế truy cập EFS chỉ cho một số EC2 instance, và hai phương án này là hai lớp bổ sung nhau: | Lớp | Kiểm soát | |---|---| | B — Security group | MẠNG: instance nào kết nối tới được | | C — IAM policy | DANH TÍNH: principal nào được mount và thao tác gì |

B — security group trên mount target:

Security group của EFS mount target:
  Type: NFS   Protocol: TCP   Port: 2049
  Source: sg-ung-dung   ← security group của EC2 được phép

Tham chiếu security group thay vì CIDR là cách tốt hơn: instance được thay thế hay tự động mở rộng vẫn giữ quyền, không cần sửa rule.

Cổng 2049 là cổng NFS — đây là chi tiết cần thuộc.

C — IAM policy cho EFS access:

{
  "Effect": "Allow",
  "Action": [
    "elasticfilesystem:ClientMount",
    "elasticfilesystem:ClientWrite"
  ],
  "Resource": "arn:aws:elasticfilesystem:ap-northeast-1:123456789012:file-system/fs-0abc123",
  "Condition": {
    "StringEquals": {"elasticfilesystem:AccessPointArn": "arn:aws:elasticfilesystem:...:access-point/fsap-0abc"}
  }
}

Ba action của EFS đáng nhớ: | Action | Việc | |---|---| | ClientMount | gắn file system (chỉ đọc) | | ClientWrite | ghi dữ liệu | | ClientRootAccess | truy cập với quyền root — cấp rất thận trọng |

Vì sao cần cả hai lớp: security group chặn ở tầng mạng, nhưng mọi instance trong security group được phép đều mount được nếu chỉ có lớp đó. IAM policy thêm ràng buộc theo danh tính của instance (qua instance profile), nên hai instance trong cùng security group vẫn có quyền khác nhau được.

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

• A. Cấu hình network ACL của subnet chứa EFS mount target chỉ cho phép NFS từ dải IP của instance được phép — quá thô và dễ hỏng: NACL làm việc ở mức subnet nên nó áp cho mọi tài nguyên trong subnet đó, không chỉ EFS. Và nó không có trạng thái, phải mở cả chiều ra. Dùng CIDR cũng kém linh hoạt hơn tham chiếu security group.
• D. Dùng EFS Access Point hạn chế truy cập vào các thư mục cụ thể — hữu ích nhưng giải quyết vấn đề khác: Access Point kiểm soát thư mục nào và với danh tính POSIX nào, không kiểm soát instance nào truy cập được. (Nó bổ sung tốt cho hai lớp trên — dùng cả ba là cấu hình đầy đủ nhất.)
• E. Dùng AWS PrivateLink truy cập EFS riêng tư — không cần và không áp dụng: EFS mount target đã nằm trong VPC của bạn với IP riêng. Không có lưu lượng nào đi ra Internet để cần PrivateLink.

Ghi nhớ

Bốn lớp kiểm soát truy cập EFS — nên hiểu vai trò từng cái: | Lớp | Kiểm soát | |---|---| | Security group trên mount target | instance nào kết nối được (mạng) | | IAM policy | principal nào mount và ghi được | | File system policy | resource-based policy trên chính EFS | | Access Point | thư mục gốc + danh tính POSIX áp đặt | | Quyền POSIX trên file | user/group/other như hệ thống tệp Linux |

Năm lớp, và chúng độc lập với nhau — truy cập chỉ thành công khi qua được tất cả.

File system policy đáng biết (phương án không có trong đề nhưng quan trọng):

{
  "Effect": "Deny",
  "Principal": {"AWS": "*"},
  "Action": "*",
  "Condition": {"Bool": {"elasticfilesystem:AccessedViaMountTarget": "false"}}
}

Statement này bắt buộc mọi truy cập phải qua mount target trong VPC — chặn truy cập qua API từ ngoài.

Và một statement rất nên có:

{"Effect": "Deny", "Principal": {"AWS": "*"}, "Action": "*",
 "Condition": {"Bool": {"aws:SecureTransport": "false"}}}

Bắt buộc mã hoá khi truyền — kết hợp với tuỳ chọn -o tls khi mount.

Hai mặt mã hoá của EFS: | Mặt | Cách bật | |---|---| | Khi lưu (at rest) | bật lúc TẠO file system — không đổi được sau | | Khi truyền (in transit) | mount -t efs -o tls hoặc EFS mount helper |

Dòng đầu là ràng buộc quan trọng: EFS không mã hoá được sau khi tạo — muốn có thì phải tạo file system mới và sao chép dữ liệu (AWS DataSync). Nên bật ngay từ đầu.

Ba giá trị của EFS Access Point: | Giá trị | Chi tiết | |---|---| | Áp đặt thư mục gốc | ứng dụng chỉ thấy /du-lieu/app1, không thấy phần còn lại | | Áp đặt UID/GID POSIX | mọi thao tác chạy dưới danh tính đó, bất kể user thật | | Đơn giản hoá cho container | mỗi task ECS/EKS một access point |

Dòng đầu là cách phân tách nhiều ứng dụng trên cùng một EFS — mỗi ứng dụng có một access point trỏ vào thư mục riêng, và IAM policy ràng buộc theo elasticfilesystem:AccessPointArn như ví dụ ở trên.

Và một lưu ý về mount target: mỗi AZ có một mount target riêng, mỗi cái có security group riêng. Cấu hình security group cho một mount target mà quên các cái khác là lỗi hay gặp — instance ở AZ đó kết nối được, AZ khác thì timeout.

Đáp án

A — Dùng CloudWatch metric DDoSDetected của AWS Shield Advanced để giám sát và cảnh báo về hoạt động DDoS.

Vì sao đúng

Đề yêu cầu giám sát và cảnh báo về tấn công DDoS, và Shield Advanced phát metric chuyên cho việc đó:

Namespace: AWS/DDoSProtection
Metric:    DDoSDetected
Giá trị:   1 = đang có tấn công, 0 = bình thường
Dimension: ResourceArn

aws cloudwatch put-metric-alarm   --alarm-name canh-bao-ddos   --namespace AWS/DDoSProtection   --metric-name DDoSDetected   --dimensions Name=ResourceArn,Value=arn:aws:cloudfront::123456789012:distribution/E1ABC   --statistic Maximum --period 60 --threshold 1   --comparison-operator GreaterThanOrEqualToThreshold   --evaluation-periods 1   --alarm-actions arn:aws:sns:...:canh-bao-bao-mat

Vì sao --statistic Maximum là đúng: metric là cờ 0/1, nên Maximum trong chu kỳ cho biết có xảy ra tấn công tại bất kỳ thời điểm nào không. Average sẽ làm loãng tín hiệu.

Các metric khác của Shield Advanced: | Metric | Cho biết | |---|---| | DDoSDetected | có tấn công hay không ← câu này | | DDoSAttackBitsPerSecond | quy mô tấn công tầng 3/4 (băng thông) | | DDoSAttackPacketsPerSecond | quy mô theo gói tin | | DDoSAttackRequestsPerSecond | quy mô tấn công tầng 7 |

Và đây là tính năng CHỈ CÓ ở Shield Advanced — Shield Standard (miễn phí, bật sẵn) bảo vệ nhưng không phát metric hay thông báo gì. Đề nói công ty đã dùng Shield Advanced, nên metric này có sẵn.

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

• B. Dùng CloudWatch metric DDoSAttack của AWS Shield Standard để giám sát và cảnh báo — đây là phương án gần nhất và sai ở hai điểm: Shield Standard KHÔNG phát metric DDoS nào (đó là tính năng của Advanced), và DDoSAttack không phải tên metric hợp lệ — tên đúng là DDoSDetected.
• C. Dùng CloudWatch metric BlockedRequests của AWS WAF để giám sát và cảnh báo về hoạt động DDoS — metric có thật nhưng sai mục đích: BlockedRequests đếm request bị WAF rule chặn vì bất kỳ lý do gì (SQL injection, quy tắc tuỳ chỉnh, rate limit). Nó không phân biệt được DDoS với các loại chặn khác, và không phát hiện được DDoS mà WAF không chặn.
• D. Dùng CloudWatch metric AllowedRequests của AWS WAF — càng không phù hợp: đây là số request được cho qua, không nói gì về tấn công.

Ghi nhớ

Shield Standard và Shield Advanced — bảng so sánh cốt lõi: | | Shield Standard | Shield Advanced | |---|---|---| | Chi phí | MIỄN PHÍ, tự động bật | 3.000 USD/tháng + phí truyền dữ liệu | | Bảo vệ | tầng 3/4 phổ biến | tầng 3/4/7 nâng cao | | CloudWatch metric DDoS | ❌ KHÔNG | ✅ CÓ ← điểm của câu này | | Thông báo tấn công | ❌ | ✅ | | Đội ứng phó (SRT) | ❌ | ✅ hỗ trợ 24/7 | | Bảo vệ chi phí | ❌ | ✅ hoàn phí scale do tấn công | | WAF | tính phí riêng | bao gồm | | Báo cáo và phân tích tấn công | ❌ | ✅ |

Ba dòng in đậm ở giữa là lý do trả 3.000 USD/tháng — và với dịch vụ quan trọng, "bảo vệ chi phí" một mình đã có thể đáng giá: 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.

Ba lớp phòng thủ DDoS trên AWS:

Tầng 3/4 (mạng, vận chuyển)  → Shield (Standard + Advanced)
Tầng 7 (ứng dụng)             → WAF (rate-based rule, managed rule)
Kiến trúc                     → CloudFront, Route 53, Auto Scaling

Dòng cuối đáng nói thêm: đặt CloudFront trước ứng dụng là biện pháp chống DDoS hiệu quả về bản chất — nó hấp thụ tấn công ở edge trên hạ tầng toàn cầu của AWS trước khi tới origin.

Ba tài nguyên bảo vệ được bằng Shield Advanced: | Tài nguyên | Ghi chú | |---|---| | CloudFront distribution | | | Route 53 hosted zone | | | ALB, NLB, Elastic IP | | | Global Accelerator | |

Ba thứ nên cấu hình cùng Shield Advanced: | Cấu hình | Lợi ích | |---|---| | Proactive engagement | SRT chủ động liên hệ khi phát hiện tấn công — không cần bạn gọi | | Health-based detection | dùng Route 53 health check để phát hiện chính xác hơn | | Alarm trên DDoSDetected | ← câu này |

Dòng đầu là tính năng đáng bật nhất: đội SRT tự vào cuộc thay vì chờ bạn mở ticket — trong một cuộc tấn công, mỗi phút đều quan trọng.

Và một lưu ý về việc đọc metric: DDoSDetected chỉ được phát khi Shield Advanced xác định đây là DDoS. Một đợt tăng tải bất thường do chiến dịch marketing sẽ không kích hoạt nó — nên nên đặt song song alarm trên metric tải thông thường (RequestCount, TargetResponseTime) để không bỏ sót vấn đề dung lượng không phải do tấn công.

Đáp án

B — Dùng AWS Resource Access Manager (AWS RAM) để chia sẻ subnet trong VPC quản lý tập trung của Account X với các tài khoản thành viên; các tài khoản này khởi chạy workload trong subnet được chia sẻ.

Vì sao đúng

Đề nêu bốn yêu cầu, và VPC Sharing qua AWS RAM thoả cả bốn: | Yêu cầu | Cơ chế | |---|---| | VPC quản lý tập trung, mọi tài khoản dùng chung | RAM chia sẻ subnet | | VPC nằm trong Account X có sẵn | Account X là chủ sở hữu VPC | | Không tài khoản nào dùng VPC riêng của mình | chỉ chia sẻ subnet của Account X | | Không phòng ban nào sửa được tài nguyên của phòng khác | cách ly theo tài khoản |

Cách VPC Sharing hoạt động — điểm mấu chốt là mô hình sở hữu:

Account X (participant owner):
    sở hữu VPC, subnet, route table, NAT gateway, VPC endpoint
        ↓ chia sẻ subnet qua RAM
Account A, B, C (participants):
    khởi chạy EC2, RDS, ALB VÀO subnet đó
    → tài nguyên vẫn THUỘC VỀ tài khoản của họ
    → tài khoản khác KHÔNG nhìn thấy, KHÔNG sửa được

Đây chính là yêu cầu thứ tư: cách ly xảy ra tự nhiên theo ranh giới tài khoản, không cần viết một IAM policy nào để ngăn phòng ban này chạm vào tài nguyên phòng kia.

Và chi tiết "không quá 15 tài khoản" trong đề là gợi ý loại trừ: nó ám chỉ quy mô nhỏ, phù hợp với VPC sharing thay vì phải dựng Transit Gateway.

Ba lợi ích khác của VPC sharing: | Lợi ích | Chi tiết | |---|---| | Không tốn phí truyền dữ liệu giữa các AZ trong cùng subnet | tài nguyên nằm cùng một VPC | | Dùng chung NAT Gateway, VPC endpoint | tiết kiệm đáng kể so với mỗi tài khoản một cái | | Không có CIDR chồng lấn | chỉ có một dải địa chỉ |

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

• D. Cấu hình Transit Gateway trong VPC của Account X; các tài khoản thành viên dùng transit gateway để truy cập subnet chia sẻ — đây là phương án gần nhất và hiểu sai vai trò của Transit Gateway: nó kết nối các VPC RIÊNG BIỆT với nhau, chứ không cho phép tài khoản khác khởi chạy workload vào subnet của bạn. Dùng nó nghĩa là mỗi phòng ban vẫn có VPC riêng — trái thẳng yêu cầu thứ ba.
• C. Thiết lập VPC Peering giữa VPC tập trung và VPC của mọi tài khoản thành viên — cùng lỗi như D, và tệ hơn: peering không bắc cầu, nên với 15 tài khoản cần tới 105 kết nối. Và nó vẫn đòi mỗi tài khoản có VPC riêng.
• A. Dùng AWS Systems Manager để chia sẻ subnet — sai dịch vụ hoàn toàn: Systems Manager quản lý instance đang chạy (vá lỗi, kiểm kê, chạy lệnh). Nó không chia sẻ tài nguyên giữa các tài khoản.

Ghi nhớ

Ba cách kết nối nhiều tài khoản AWS về mặt mạng — bảng phân biệt cốt lõi: | Cách | Mô hình | Phù hợp | |---|---|---| | VPC Sharing (RAM) | MỘT VPC, nhiều tài khoản khởi chạy vào | muốn tập trung hoàn toàn ← câu này | | Transit Gateway | nhiều VPC RIÊNG, nối qua hub | mỗi đơn vị cần VPC riêng, quy mô lớn | | VPC Peering | nhiều VPC riêng, nối từng cặp | vài VPC, không bắc cầu |

Câu hỏi phân biệt:

"Mọi người dùng CHUNG một VPC?" → VPC Sharing "Mỗi bên có VPC riêng, cần nói chuyện với nhau?" → Transit Gateway

Những gì AWS RAM chia sẻ được: | Tài nguyên | Ghi chú | |---|---| | VPC subnet | ← câu này | | Transit Gateway | | | Route 53 Resolver rule | | | License Manager configuration | | | Aurora DB cluster, Capacity Reservation | | | Prefix list, Image Builder component | |

Bốn giới hạn của VPC sharing cần biết: | Giới hạn | Chi tiết | |---|---| | Chỉ chủ VPC sửa được VPC, subnet, route table | participant chỉ khởi chạy tài nguyên | | Participant KHÔNG nhìn thấy tài nguyên của nhau | ← chính là điều đề muốn | | Không xoá được subnet còn tài nguyên của participant | chủ VPC phải phối hợp | | Security group tham chiếu được qua tài khoản | trong cùng VPC chia sẻ |

Dòng cuối là ưu điểm ít người biết: trong VPC chia sẻ, security group tham chiếu chéo tài khoản được — điều không làm được qua VPC peering (xem câu #7700).

Và một cân nhắc vận hành: VPC sharing đặt gánh nặng lên đội quản lý Account X. Mọi thay đổi mạng (thêm subnet, sửa route, thêm VPC endpoint) đều phải qua họ. Với tổ chức mà các phòng ban cần tự chủ về mạng, Transit Gateway là mô hình phù hợp hơn — dù đề này chọn tập trung một cách có chủ ý.

Đáp án

A — Tạo SNS topic với các thành viên đội bảo mật là subscriber; tạo EventBridge rule giám sát đăng nhập userIdentity root từ Console và gửi thông báo tới SNS topic khi phát hiện.

Vì sao đúng

Đề yêu cầu cách hiệu quả nhất để báo cho đội bảo mật mỗi khi root user đăng nhập.

A là luồng ngắn nhất có thể:

Root user đăng nhập Console
    ↓ CloudTrail ghi sự kiện ConsoleLogin
    ↓ EventBridge rule khớp userIdentity.type = "Root"
    ↓ TARGET TRỰC TIẾP là SNS topic
Đội bảo mật nhận email

Event pattern:

{
  "detail-type": ["AWS Console Sign In via CloudTrail"],
  "detail": {
    "userIdentity": {"type": ["Root"]}
  }
}

Điểm phân biệt với phương án B là số mắt xích: | | A | B | |---|---|---| | Luồng | EventBridge → SNS | EventBridge → Lambda → SNS | | Số thành phần | 2 | 3 | | Mã phải viết | KHÔNG | có — một Lambda function | | Phải bảo trì | không | mã, runtime, execution role |

SNS là target trực tiếp của EventBridge — không cần Lambda làm trung gian chỉ để chuyển tiếp thông điệp. Đề hỏi "most efficient way", nên phương án ít thành phần hơn thắng.

Khi nào Lambda thực sự cần thiết: khi bạn muốn định dạng lại thông điệp cho dễ đọc (sự kiện CloudTrail thô khá dài), hoặc làm giàu dữ liệu (tra IP về vị trí địa lý), hoặc thực hiện hành động khắc phục. Chỉ để gửi thông báo thì không cần.

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

• B. Tạo SNS topic; tạo CloudWatch Events rule phát hiện sự kiện API của root user, rule này kích hoạt một Lambda function rồi Lambda publish lên SNS — đây là phương án gần nhất và hoạt động hoàn toàn đúng, nhưng nó thêm một thành phần không cần thiết. (CloudWatch Events và EventBridge là cùng một dịch vụ — EventBridge là tên mới; nên khác biệt thật chỉ nằm ở Lambda thừa.)
• D. Lưu CloudTrail log vào S3 ở tài khoản của đội bảo mật, phân tích bằng Athena, Lambda chạy truy vấn Athena và kích hoạt thông báo — không phải thời gian thực và nhiều công nhất: phải lên lịch chạy truy vấn liên tục, và độ trễ phụ thuộc chu kỳ chạy. Đề muốn biết "every time it is used", tức là ngay khi xảy ra.
• C. Gửi dữ liệu VPC Flow Logs sang SQS, Lambda xử lý và gửi SNS khi phát hiện root đăng nhập — sai nguồn dữ liệu hoàn toàn: VPC Flow Logs ghi lưu lượng mạng (IP, cổng, byte). Nó không chứa thông tin về danh tính người đăng nhập.

Ghi nhớ

Ba cách cảnh báo từ sự kiện CloudTrail — chọn theo nhu cầu: | Cách | Độ trễ | Dùng khi | |---|---|---| | EventBridge rule → SNS | thấp nhất, từng sự kiện | sự kiện đơn lẻ đã đáng báo ← câu này | | CloudWatch Logs metric filter + alarm | vài phút | cần ĐẾM N lần trong khoảng thời gian | | Athena truy vấn theo lịch | cao | phân tích lịch sử, điều tra |

Tiêu chí phân biệt hai dòng đầu là "có cần đếm không": root đăng nhập một lần đã đáng báo → EventBridge. Đăng nhập thất bại 3 lần trong 5 phút → metric filter.

Các target trực tiếp của EventBridge — không cần Lambda trung gian: | Target | Dùng cho | |---|---| | SNS topic | thông báo ← câu này | | SQS queue | xếp hàng xử lý | | Lambda function | logic tuỳ ý | | Step Functions | quy trình nhiều bước | | SSM Automation document | khắc phục tự động không cần viết mã | | Kinesis, ECS task, EC2 API | các trường hợp khác |

Dòng "SSM Automation" đáng nhớ: nó cho phép tự động khắc phục mà không cần viết Lambda — hữu ích cho các hành động chuẩn như cách ly instance, gỡ rule security group.

Hai loại sự kiện đăng nhập cần phân biệt: | detail-type | Bắt gì | |---|---| | AWS Console Sign In via CloudTrail | đăng nhập Console ← câu này | | AWS API Call via CloudTrail | lời gọi API bằng access key |

Cần cả hai cho giám sát root đầy đủ: root có thể vừa đăng nhập Console vừa dùng access key. (Và root không nên có access key — nên nếu bắt được sự kiện loại thứ hai với userIdentity.type = Root, đó đã là một phát hiện đáng điều tra.)

Và một lưu ý về Region: sự kiện đăng nhập Console được ghi ở us-east-1 cho hầu hết trường hợp. Tạo EventBridge rule ở Region khác sẽ không bắt được gì — một chỗ dễ mất công gỡ lỗi.

Đáp án

A và E.

• A — Các danh tính AWS có quyền kms:CreateKey có thể đặt key policy ban đầu và tự cấp cho mình quyền dùng hoặc quản lý khoá
• E — Danh tính IAM tạo ra KMS key KHÔNG được coi là chủ sở hữu khoá. Như mọi danh tính khác, người tạo khoá phải được cấp quyền qua key policy, IAM policy hoặc grant

Vì sao đúng

Hai phát biểu này mô tả đúng mô hình quyền của KMS — và chúng bổ sung cho nhau chứ không mâu thuẫn:

E: Người tạo khoá KHÔNG tự động có quyền
A: NHƯNG người tạo khoá ĐẶT key policy ban đầu
   → nên trong thực tế họ tự cấp quyền cho mình trong chính policy đó

Đây là một điểm bảo mật quan trọng, không phải chuyện câu chữ: quyền kms:CreateKey mạnh hơn nhiều so với vẻ ngoài của nó. Ai có quyền đó có thể tạo khoá và tự trao cho mình toàn quyền quản lý khoá đó, kể cả quyền xoá.

Mô hình quyền của KMS — khác hầu hết dịch vụ AWS: | Đặc điểm | Chi tiết | |---|---| | Key policy là nguồn quyền CHÍNH | bắt buộc, không thể bỏ | | KHÔNG có principal nào mặc định có quyền | kể cả root user, kể cả người tạo | | IAM policy chỉ có tác dụng nếu key policy uỷ quyền cho tài khoản | |

Statement uỷ quyền — thứ mà Console tự thêm khi bạn tạo khoá:

{
  "Sid": "Enable IAM User Permissions",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
  "Action": "kms:*",
  "Resource": "*"
}

Chính statement này mới khiến IAM policy có tác dụng — không có nó thì mọi IAM policy cấp quyền KMS đều vô hiệu.

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

• D. KMS key thuộc về tài khoản tạo ra nó. Riêng root user có toàn quyền trên khoá cho tới khi danh tính khác được cấp quyền — đây là phương án gần nhất và sai ở vế "riêng root user có toàn quyền": tài liệu AWS nêu rõ không principal nào, KỂ CẢ root user, có quyền dùng hay quản lý KMS key cho tới khi quyền đó được cấp trong key policy, IAM policy hoặc grant. Đây chính là lý do một key policy sai có thể khiến khoá không ai dùng được và không ai sửa được.
• C. Uỷ quyền dùng KMS key được cấp qua federated identity hoặc user sign-in. Resource-based policy và ACL là các hình thức uỷ quyền khác mà KMS chấp nhận — KMS KHÔNG hỗ trợ ACL. Ba cơ chế của KMS là key policy, IAM policy và grant.
• B. Quyền với tài nguyên được cấp qua resource-based policy — tài liệu JSON chứa thông tin về tài nguyên, principal và điều kiện — đây là định nghĩa chung đúng về resource-based policy, nhưng nó không phải điểm cần lưu ý riêng khi cấu hình KMS, và nó bỏ sót hai cơ chế còn lại. Không phải một trong hai điểm quan trọng nhất mà câu hỏi tìm.

Ghi nhớ

Ba cơ chế cấp quyền của KMS: | Cơ chế | Đặc điểm | |---|---| | Key policy | BẮT BUỘC — gốc của mọi quyền trên khoá | | IAM policy | chỉ có tác dụng nếu key policy uỷ quyền cho tài khoản | | Grant | cấp quyền tạm thời, chi tiết — dịch vụ AWS dùng nhiều |

Grant đáng biết thêm: nó cho phép cấp quyền hẹp và có thể thu hồi mà không sửa key policy. Nhiều dịch vụ AWS (EBS, RDS, DynamoDB) tự tạo grant khi bạn bật mã hoá:

aws kms create-grant --key-id 1234abcd   --grantee-principal arn:aws:iam::123456789012:role/ung-dung   --operations Decrypt GenerateDataKey   --constraints EncryptionContextSubset={phong-ban=ke-toan}

Bốn khác biệt của KMS so với các dịch vụ khác: | Khác biệt | Hệ quả | |---|---| | Không ai có quyền mặc định | key policy sai = khoá vô dụng vĩnh viễn | | Root user KHÔNG được miễn trừ | ← điểm loại của phương án D | | Người tạo khoá không tự động là chủ | ← phát biểu E | | Không dùng ACL | ← điểm loại của phương án C |

Tình huống tự khoá mình ra khỏi khoá — hậu quả nghiêm trọng nhất:

Key policy chỉ có một statement cho role X
    → role X bị xoá
    → KHÔNG AI dùng được khoá
    → KHÔNG AI sửa được key policy
    → mọi dữ liệu mã hoá bằng khoá đó KHÔNG GIẢI MÃ ĐƯỢC

Lối thoát duy nhất là liên hệ AWS Support. Vì vậy AWS khuyến nghị luôn giữ statement uỷ quyền cho tài khoản trong mọi key policy.

Ba biện pháp kiểm soát quyền kms:CreateKey: | Biện pháp | Lý do | |---|---| | Hạn chế ai có quyền này | nó cho phép tự cấp toàn quyền trên khoá mới | | SCP bắt buộc key policy chứa statement quản trị | đảm bảo không tự khoá | | Giám sát CreateKey qua CloudTrail | biết khoá nào được tạo, bởi ai |

Và một chi tiết về cú pháp: arn:aws:iam::123456789012:root trong Principal không có nghĩa là root user — nó nghĩa là "tài khoản 123456789012", tức là uỷ quyền cho IAM của tài khoản đó quyết định. Đây là điểm hay bị hiểu nhầm và liên quan trực tiếp tới việc phương án D sai.

Đáp án

A — Tạo S3 bucket policy trong tài khoản Audit cho phép người dùng từ tài khoản Finance truy cập bucket.

Vì sao đúng

Đề mô tả triệu chứng rõ ràng: IAM policy đã gắn cho người dùng ở tài khoản Finance nhưng vẫn không truy cập được.

Nguyên nhân: truy cập chéo tài khoản đòi cả HAI phía cùng cho phép.

Cùng tài khoản:
  IAM policy cho phép → ĐỦ

Khác tài khoản:
  ① IAM policy ở tài khoản NGUỒN (Finance) cho phép người dùng gọi
  ② Bucket policy ở tài khoản ĐÍCH (Audit) cho phép principal đó
  → thiếu MỘT trong hai = từ chối

Đây là nguyên tắc nền tảng của truy cập chéo tài khoản trên AWS: không tài khoản nào tự cấp cho mình quyền vào tài nguyên của tài khoản khác. Chủ sở hữu tài nguyên phải chủ động mở.

Bucket policy cần thiết trong tài khoản Audit:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::111122223333:user/nguoi-dung-finance"},
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::bucket-kiem-toan",
      "arn:aws:s3:::bucket-kiem-toan/*"
    ]
  }]
}

Hai Resource là chi tiết bắt buộc và hay bị bỏ sót: | ARN | Cho phép | |---|---| | arn:aws:s3:::bucket | thao tác trên BUCKET: ListBucket, GetBucketLocation | | arn:aws:s3:::bucket/* | thao tác trên OBJECT: GetObject, PutObject |

Chỉ khai một cái thì một nửa thao tác thất bại — triệu chứng thường là "liệt kê được nhưng không tải xuống được", hoặc ngược lại.

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

• B. Tạo S3 bucket policy TRONG TÀI KHOẢN FINANCE cho phép người dùng từ tài khoản Finance truy cập bucket — đây là phương án gần nhất và sai nơi đặt policy: bucket nằm ở tài khoản Audit, nên bucket policy phải đặt ở đó. Bucket policy trong tài khoản Finance áp cho bucket của Finance, không liên quan.
• D. Bật bucket owner enforced trong tài khoản Audit và dùng ACL để cấp quyền chéo tài khoản — mâu thuẫn nội tại: bật BucketOwnerEnforced VÔ HIỆU HOÁ hoàn toàn ACL. Đó chính là mục đích của cài đặt này. Hai vế của phương án loại trừ nhau.
• C. Cấu hình ARN của S3 bucket làm Principal trong IAM trust policy của người dùng — nhầm hoàn toàn về cấu trúc policy: Principal là danh tính thực hiện hành động, không phải tài nguyên. Và IAM user không có trust policy — chỉ IAM role mới có.

Ghi nhớ

Hai mô hình truy cập chéo tài khoản S3: | Mô hình | Cách làm | Ưu điểm | |---|---|---| | Bucket policy trực tiếp | bucket policy nêu principal của tài khoản kia | đơn giản, ít bước ← câu này | | Assume role | tài khoản Audit tạo role, Finance assume vào | kiểm soát tốt hơn, có thể ràng buộc điều kiện, MFA |

Mô hình thứ hai thường được ưa chuộng hơn cho quyền rộng: nó cho phép ràng buộc thời hạn phiên, bắt buộc MFA, và ghi rõ trong CloudTrail ai đã assume role nào.

Ba loại thiết lập quyền sở hữu object của S3 — quan trọng cho tình huống chéo tài khoản: | Thiết lập | Hành vi | |---|---| | BucketOwnerEnforced | ACL TẮT hoàn toàn; chủ bucket sở hữu MỌI object — mặc định cho bucket mới | | BucketOwnerPreferred | chủ bucket sở hữu object nếu người ghi khai ACL bucket-owner-full-control | | ObjectWriter | người ghi sở hữu object — cơ chế cũ |

Vấn đề kinh điển mà BucketOwnerEnforced giải quyết: với ObjectWriter, tài khoản A ghi object vào bucket của tài khoản B, và B không đọc được object trong chính bucket của mình — vì A là chủ object. Đây là nguồn gốc của rất nhiều sự cố trước năm 2021.

Danh sách kiểm tra khi truy cập chéo tài khoản S3 thất bại:

① IAM policy ở tài khoản NGUỒN có cho phép không?
② Bucket policy ở tài khoản ĐÍCH có cho phép principal đó không?
③ Có explicit Deny ở đâu không? (SCP, bucket policy, IAM)
④ Bucket có bật Block Public Access chặn nhầm không?
⑤ Object mã hoá SSE-KMS? → cần quyền trên KMS key ở CẢ HAI phía
⑥ Resource ARN có đủ cả bucket lẫn bucket/* không?

Bước ⑤ là chỗ hay tắc nhất trong thực tế: bucket policy đúng nhưng object mã hoá bằng CMK, và key policy không cho phép principal của tài khoản kia — lỗi trả về vẫn là AccessDenied mà không nói rõ nguyên nhân nằm ở KMS.

Và một công cụ nên dùng: IAM Access Analyzer phát hiện các tài nguyên đang được chia sẻ ra ngoài tài khoản hoặc ngoài tổ chức — hữu ích cả để kiểm chứng cấu hình này đúng ý, lẫn để phát hiện chia sẻ ngoài ý muốn.

Đáp án

B và D.

• D — Bật object-level logging cho S3; tạo EventBridge event pattern khi phát hiện lời gọi PutObject có quyền public-read trong log CloudTrail, đặt target là SNS topic
• B — Cấu hình một Lambda function làm subscriber của SNS topic, hàm này được gọi để khoá lại object trong bucket

Vì sao đúng

Đề yêu cầu ba việc: phát hiện object công khai, thông báo cho đội Governance, và tự động khắc phục. Cặp D+B dựng đúng ba bước đó:

Ai đó tải lên object với public-read
    ↓ D: object-level logging ghi PutObject vào CloudTrail
    ↓ EventBridge khớp pattern
SNS topic
    ├─→ đội Governance and Compliance (thông báo)
    └─→ B: Lambda function (khắc phục — gỡ quyền công khai)

Điểm thiết kế hay của việc dùng SNS làm điểm phân nhánh: một topic phục vụ cả hai mục đích — người nhận thông báo và mã tự động khắc phục — mà không cần hai luồng riêng.

Vì sao cần object-level logging (data event): | Loại sự kiện | Bao gồm | Mặc định | |---|---|---| | Management event | PutBucketPolicy, PutBucketAcl | BẬT | | Data event (object-level) | PutObject, PutObjectAcl, GetObject | TẮT |

PutObject với ACL public-read là data event — không bật thì CloudTrail không ghi, và EventBridge không có gì để khớp.

Event pattern:

{
  "source": ["aws.s3"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["s3.amazonaws.com"],
    "eventName": ["PutObject", "PutObjectAcl"],
    "requestParameters": {"x-amz-acl": ["public-read"]}
  }
}

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

• E. Bật object-level logging; khi có PutObject với public-read, dùng S3 event notification kích hoạt Lambda gửi thông báo qua SNS — đây là phương án gần nhất và sai ở cơ chế: S3 event notification không lọc theo ACL của request. Nó kích hoạt theo loại sự kiện (s3:ObjectCreated:*) và có thể lọc theo prefix/suffix của tên khoá — nhưng không đọc được x-amz-acl. Phải qua CloudTrail và EventBridge mới lọc được điều kiện đó.
• A. Dùng AWS Trusted Advisor kiểm tra quyền public-read của bucket và gọi Lambda gửi SNS ngay khi object công khai được tải lên — hai lỗi: Trusted Advisor kiểm tra theo chu kỳ, không phải thời gian thực, nên không đáp ứng "immediately"; và nó kiểm tra quyền ở mức BUCKET, không phát hiện được từng object công khai.
• C. Dùng AWS Access Analyzer kiểm tra quyền public-read và gọi Lambda gửi SNS ngay khi object công khai được tải lên — cùng vấn đề: IAM Access Analyzer phân tích chính sách ở mức bucket và tài nguyên, chạy theo chu kỳ đánh giá, không giám sát từng object theo thời gian thực.

Ghi nhớ

S3 Event Notification và CloudTrail + EventBridge — bảng phân biệt quan trọng: | | S3 Event Notification | CloudTrail + EventBridge | |---|---|---| | Lọc theo | loại sự kiện, prefix, suffix của khoá | BẤT KỲ trường nào trong sự kiện CloudTrail | | Lọc theo ACL, người gọi, IP nguồn | ❌ KHÔNG | ✅ CÓ | | Độ trễ | rất thấp | thấp | | Cần bật data event? | ❌ | ✅ (tính phí) | | Target | SNS, SQS, Lambda, EventBridge | mọi target của EventBridge |

Quy tắc chọn:

Chỉ cần biết "có object mới" → S3 Event Notification (rẻ hơn, nhanh hơn) Cần biết AI làm, TỪ ĐÂU, VỚI THAM SỐ GÌ → CloudTrail data event + EventBridge

Bốn lớp phòng thủ chống object S3 công khai — nên dùng nhiều lớp: | Lớp | Vai trò | |---|---| | S3 Block Public Access ở mức TÀI KHOẢN | NGĂN CHẶN — lớp mạnh nhất | | SCP chặn s3:PutAccountPublicAccessBlock | không ai tắt được lớp trên | | AWS Config rule + auto remediation | đánh giá liên tục | | CloudTrail + EventBridge | phản ứng theo sự kiện ← câu này | | IAM Access Analyzer | phát hiện chia sẻ ngoài ý muốn |

Dòng đầu đáng nhấn mạnh: bật Block Public Access ở mức tài khoản khiến mọi ACL và bucket policy công khai bị vô hiệu hoá, kể cả khi ai đó cố ý đặt. Nó biến vấn đề này từ "phát hiện và sửa" thành "không thể xảy ra".

Bốn cài đặt của Block Public Access: | Cài đặt | Chặn gì | |---|---| | BlockPublicAcls | chặn ACL công khai MỚI | | IgnorePublicAcls | BỎ QUA mọi ACL công khai đang có | | BlockPublicPolicy | chặn bucket policy công khai mới | | RestrictPublicBuckets | hạn chế truy cập qua policy công khai |

Hai dòng đầu khác nhau ở phạm vi thời gian: cái đầu chặn ACL mới, cái thứ hai vô hiệu hoá cả ACL đã tồn tại — nên bật cả hai mới đủ.

Và một lưu ý về chi phí của giải pháp này: data event của S3 tính phí theo số sự kiện, và bucket có lưu lượng cao sinh rất nhiều. Đặt ReadWriteType: WriteOnly cắt được phần lớn khối lượng vì bạn chỉ quan tâm tới thao tác ghi.

Đáp án

A và C.

• A — AWS Config phải được bật như điều kiện tiên quyết để dùng Security Hub
• C — Khi bật cả GuardDuty và Security Hub, tích hợp hai chiều được bật tự động; GuardDuty lập tức bắt đầu gửi finding sang Security Hub

Vì sao đúng

A — AWS Config là điều kiện tiên quyết thật sự, không phải khuyến nghị:

Security Hub chạy các "control" (kiểm tra bảo mật)
    ↓ phần lớn control dựa trên AWS Config rule
    ↓ Config không bật = không có dữ liệu cấu hình
Security Hub không đánh giá được → control ở trạng thái "No data"

Hai điều cần bật trong Config: | Cần | Lý do | |---|---| | Config recorder đang chạy | thu thập cấu hình tài nguyên | | Ghi mọi loại tài nguyên mà control cần | ghi thiếu loại nào thì control tương ứng không chạy |

Đây là chi phí ẩn đáng lưu ý: bật Security Hub kéo theo bật Config, và Config tính phí theo số configuration item được ghi — với môi trường lớn, khoản này có thể vượt cả phí Security Hub.

C — tích hợp GuardDuty tự động: khi cả hai dịch vụ cùng bật, không cần cấu hình gì thêm — GuardDuty gửi finding sang Security Hub ngay. Đây là mẫu tích hợp chung của Security Hub với các dịch vụ AWS khác.

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

• D. Security Hub dùng resource-linked role để thực hiện kiểm tra bảo mật cho phần lớn control từ AWS Config — đây là phương án gần nhất và sai một từ: cơ chế đúng là service-linked role (AWSServiceRoleForSecurityHub). Không có khái niệm "resource-linked role" trong IAM.
• B. Amazon GuardDuty phải được bật như điều kiện tiên quyết để dùng Security Hub; GuardDuty lập tức bắt đầu gửi finding — sai ở vế điều kiện tiên quyết: GuardDuty là nguồn finding tuỳ chọn, không bắt buộc. Security Hub chạy được mà không có GuardDuty (chỉ là ít dữ liệu hơn). Config mới là thứ bắt buộc.
• E. Theo dõi instance Redshift dùng chưa hết công suất hoặc EC2 quá tải là ví dụ điển hình cho Security Hub — đây là ví dụ của Trusted Advisor, không phải Security Hub. Security Hub tập trung vào tư thế bảo mật và tuân thủ, không phải tối ưu chi phí hay hiệu năng.

Ghi nhớ

Ba khả năng chính của Security Hub: | Khả năng | Chi tiết | |---|---| | Tổng hợp finding | từ nhiều dịch vụ AWS và bên thứ ba, theo định dạng chuẩn ASFF | | Kiểm tra tự động theo chuẩn | CIS AWS Foundations, PCI DSS, AWS Foundational Security Best Practices, NIST | | Hành động tự động | qua EventBridge + custom action |

ASFF (AWS Security Finding Format) là định dạng JSON chuẩn hoá — nó là lý do finding từ GuardDuty, Inspector, Macie và công cụ bên thứ ba hiện chung một chỗ và so sánh được với nhau.

Các nguồn finding tích hợp sẵn: | Dịch vụ | Gửi finding | |---|---| | GuardDuty | mối đe doạ đang diễn ra | | Inspector | lỗ hổng phần mềm | | Macie | dữ liệu nhạy cảm | | IAM Access Analyzer | tài nguyên chia sẻ ra ngoài | | Firewall Manager | tài nguyên chưa được bảo vệ | | AWS Config | tài nguyên không tuân thủ | | Systems Manager Patch Manager | máy chưa vá | | Health, Audit Manager | |

Chiều ngược lại — Security Hub GỬI dữ liệu đi: | Đích | Việc | |---|---| | Amazon Detective | điều tra sâu một finding | | EventBridge | kích hoạt khắc phục | | Đối tác bên thứ ba | Splunk, Jira, ServiceNow, PagerDuty |

Dòng đầu là nội dung của câu #7738 — Detective nhận từ Security Hub, không gửi finding vào.

Ba dịch vụ hay bị nhầm vai trò với Security Hub: | Dịch vụ | Việc thật | |---|---| | Trusted Advisor | khuyến nghị chi phí, hiệu năng, giới hạn dịch vụ, bảo mật cơ bản | | AWS Config | đánh giá cấu hình có tuân thủ không | | Amazon Detective | điều tra nguyên nhân gốc từ log |

Câu hỏi phân biệt:

"Tổng hợp mọi cảnh báo bảo mật, chấm điểm theo chuẩn?" → Security Hub "Tài nguyên nào cấu hình sai chuẩn?" → Config "Vì sao chuyện này xảy ra?" → Detective "Tôi có đang lãng phí tiền không?" → Trusted Advisor

Và một lưu ý về triển khai đa tài khoản: Security Hub hỗ trợ delegated administrator trong AWS Organizations — một tài khoản bảo mật chuyên trách thấy finding của mọi tài khoản thành viên. Kết hợp với cross-Region aggregation, bạn có một bảng điều khiển duy nhất cho toàn tổ chức. (Lưu ý: Security Hub là dịch vụ khu vực, nên tổng hợp đa Region phải được cấu hình rõ ràng — nó không tự động, khác với điều mà phương án D của câu #7738 khẳng định.)

Đáp án

C — Kiểm tra xem quyền kms:Decrypt đã có trong key policy chưa; nếu chưa thì phải thêm vào.

Vì sao đúng

Đề mô tả triệu chứng rất đặc trưng và đó là toàn bộ manh mối:

Tải tệp NHỎ  + thông tin mã hoá  → THÀNH CÔNG
Tải tệp LỚN  + thông tin mã hoá  → Access Denied

Vì sao kích thước lại quyết định: tệp lớn được tải lên bằng multipart upload, và multipart upload cần thêm quyền kms:Decrypt mà tải lên thông thường không cần.

Lý do kỹ thuật:

Tải lên thường (một request):
  S3 gọi kms:GenerateDataKey → mã hoá → xong
  → chỉ cần GenerateDataKey

Multipart upload (nhiều phần):
  S3 gọi kms:GenerateDataKey một lần cho cả phiên
  Mỗi phần cần dùng LẠI data key đó
      → S3 phải GIẢI MÃ data key đã lưu ở mỗi phần
      → cần kms:Decrypt
  Lúc CompleteMultipartUpload cũng cần Decrypt

Và vì tệp nhỏ tải lên thành công, ta biết chắc GenerateDataKey đã có — nên phần thiếu chỉ có thể là Decrypt.

Ngưỡng chuyển sang multipart: | Công cụ | Ngưỡng mặc định | |---|---| | AWS CLI, SDK | 8 MB (multipart_threshold) | | Bắt buộc multipart | tệp trên 5 GB |

Đây là lý do triệu chứng "tệp nhỏ được, tệp lớn không" xuất hiện đột ngột mà không ai đổi gì.

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

• A. Kiểm tra kms:Decrypt đã được khai trong CẢ key policy LẪN IAM policy của người dùng chưa — đây là phương án gần nhất, và về mặt kỹ thuật nó chặt chẽ hơn đáp án được chọn: quyền KMS cần cả hai lớp, nên kiểm tra cả hai là chẩn đoán đúng đắn hơn kiểm tra một. Đáp án C hẹp hơn mà vẫn được chọn — xem ghi chú cuối bài.
• D. Kiểm tra người gọi có kms:GenerateDataKey không; quyền này cần cho multipart upload — quyền đúng nhưng suy luận sai: GenerateDataKey cần cho mọi thao tác ghi với SSE-KMS. Vì tệp nhỏ tải lên thành công, quyền này chắc chắn đã có.
• B. Kiểm tra kms:Encrypt trong key policy — S3 không bao giờ gọi kms:Encrypt cho SSE-KMS. Nó dùng mã hoá phong bì: GenerateDataKey để lấy data key, rồi mã hoá dữ liệu cục bộ bằng data key đó.

Ghi nhớ

Quyền KMS theo thao tác S3 — bảng cần thuộc: | Thao tác | Quyền KMS | |---|---| | GetObject | kms:Decrypt | | PutObject (một phần) | kms:GenerateDataKey | | PutObject (MULTIPART) | kms:GenerateDataKey + kms:Decrypt | | CopyObject | cả hai |

Dòng thứ ba là nội dung của câu hỏi này — và là nguyên nhân của một lớp sự cố khó chẩn đoán, vì lỗi chỉ xuất hiện với tệp vượt ngưỡng.

Quy tắc thực dụng: cấp cả Decrypt và GenerateDataKey cho mọi principal cần ghi vào bucket mã hoá SSE-KMS. Tách riêng chỉ tạo ra loại lỗi này.

Hai lớp quyền của KMS — luôn phải kiểm cả hai:

① KEY POLICY  → nguồn quyền GỐC, bắt buộc
② IAM POLICY  → chỉ có tác dụng nếu key policy uỷ quyền cho tài khoản

Ba triệu chứng KMS thường gặp và nguyên nhân: | Triệu chứng | Thiếu quyền | |---|---| | Đọc được, ghi thất bại | kms:GenerateDataKey | | Tệp nhỏ được, tệp lớn thất bại | kms:Decrypt (multipart) ← câu này | | Ghi được, đọc thất bại | kms:Decrypt |

Ghi chú về chất lượng câu hỏi

Phương án A đúng hơn đáp án được chọn. Vì KMS yêu cầu cả key policy lẫn IAM policy cùng cho phép, việc kiểm tra kms:Decrypt ở cả hai nơi (A) là chẩn đoán đầy đủ, còn chỉ kiểm key policy (C) có thể bỏ sót trường hợp key policy đã uỷ quyền cho tài khoản (Principal: root) mà IAM policy của người dùng mới là chỗ thiếu Decrypt.

Đáp án C vẫn đúng về quyền cần thêm — điều mà câu hỏi thực sự kiểm tra là bạn có biết multipart upload cần Decrypt hay không. Nhưng nếu gặp câu này trong đề thật và cả A lẫn C cùng có mặt, A là lựa chọn an toàn hơn. Ở đây ghi lại để bạn biết chỗ mập mờ, chứ không phải để nghi ngờ kiến thức cốt lõi: multipart upload với SSE-KMS cần kms:Decrypt là điều chắc chắn và được AWS ghi rõ trong tài liệu.

Và một biện pháp giảm chi phí lẫn số lời gọi KMS cho bucket nhiều object: bật S3 Bucket Keys — nó giảm mạnh số lần gọi KMS mà không đổi mức bảo vệ.