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

Đáp án

D — Theo thứ tự: ① vô hiệu hoá (inactivate) access key bị lộ, ② tạo cặp key mới, ③ cập nhật ứng dụng dùng key mới, ④ thu hồi thông tin xác thực tạm thời của STS, ⑤ xoá thông tin đăng nhập Console.

Vì sao đúng

Đề nêu hai ràng buộc đối nghịch nhau, và thứ tự là toàn bộ nội dung câu hỏi: | Ràng buộc | Hệ quả | |---|---| | Key đã bị công khai trên repo công cộng | phải chặn NGAY, không chờ | | Ứng dụng production đang dùng key đó | giảm thiểu thời gian gián đoạn |

Vì sao "inactivate" phải là bước ĐẦU TIÊN:

Key đang nằm công khai trên Internet
    → mỗi giây trôi qua là một cơ hội bị lợi dụng
    → chặn trước, sửa ứng dụng sau

Và Inactive khác Delete — đây là điểm tinh tế: | Trạng thái | Đặc điểm | |---|---| | Inactive | key ngừng hoạt động NGAY, nhưng vẫn còn để điều tra và có thể bật lại | | Delete | xoá vĩnh viễn, mất dấu vết |

Vô hiệu hoá cho hiệu quả bảo mật tức thì mà vẫn giữ được đường lui nếu cần khôi phục gấp.

Thứ tự đầy đủ và lý do từng bước:

① Inactivate key bị lộ     → chặn kẻ tấn công NGAY
② Tạo key mới              → chuẩn bị thay thế
③ Cập nhật ứng dụng        → khôi phục dịch vụ
④ Thu hồi STS tạm thời     → kẻ tấn công có thể đã đổi key lấy token
                              tồn tại tới 12 giờ SAU KHI key bị vô hiệu
⑤ Xoá thông tin Console    → dọn dẹp: service account không cần đăng nhập Console

Bước ④ là chi tiết dễ bỏ sót nhất: vô hiệu hoá access key không thu hồi những token STS đã được cấp trước đó. Kẻ tấn công có thể đã gọi AssumeRole hoặc GetSessionToken và đang giữ một phiên còn hiệu lực hàng giờ.

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

• C. Xoá Console → tạo key mới → inactivate key lộ → thu hồi STS → cập nhật ứng dụng — đây là phương án gần nhất và sai ở thứ tự ưu tiên: nó làm hai việc không khẩn cấp trước khi chặn key đang bị lộ. Và cập nhật ứng dụng ở bước cuối kéo dài thời gian gián đoạn.
• A. Xoá Console → tạo key mới → cập nhật ứng dụng → inactivate key lộ → thu hồi STS — key bị lộ vẫn hoạt động qua ba bước đầu, có thể mất nhiều phút tới hàng giờ.
• B. Thu hồi STS trước → inactivate key → tạo key mới → cập nhật ứng dụng → xoá Console — thu hồi STS trước khi vô hiệu key là vô ích: kẻ tấn công vẫn còn key và lấy token mới ngay được. Phải chặn nguồn trước.

Ghi nhớ

Quy trình chuẩn khi access key bị lộ:

① Chặn ngay          → Inactivate (không Delete vội)
② Tạo thay thế       → access key mới
③ Khôi phục dịch vụ  → cập nhật ứng dụng
④ Dọn phiên còn sống → thu hồi STS token
⑤ Dọn dẹp            → xoá key cũ, xoá quyền thừa
⑥ Điều tra           → CloudTrail xem key đã bị dùng làm gì

Ba trạng thái của access key: | Trạng thái | Ý nghĩa | |---|---| | Active | dùng được | | Inactive | ngừng hoạt động, còn tồn tại — bật lại được | | Đã xoá | không khôi phục được |

Cách thu hồi STS token — điểm kỹ thuật đáng nhớ: bạn không thu hồi từng token được, mà phải gắn một inline policy vào IAM entity từ chối mọi hành động với token cấp trước một thời điểm:

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

Ba biện pháp phòng ngừa để tình huống này không lặp lại: | Biện pháp | Chi tiết | |---|---| | Dùng IAM role thay access key | ứng dụng trên EC2, ECS, Lambda không cần key cứng | | Quét mã nguồn tìm bí mật | git-secrets, Amazon CodeGuru, GitHub secret scanning | | IAM Access Analyzer + Credential Report | phát hiện key không dùng, key quá cũ |

Dòng đầu là cách chữa gốc rễ: đề nói ứng dụng dùng hard-coded credentials — đó mới là lỗ hổng thật. Với ứng dụng chạy trên AWS, IAM role loại bỏ hoàn toàn nhu cầu lưu key.

Và một điều nên làm ngay sau sự cố: rà CloudTrail xem key đó đã được dùng từ IP nào và gọi API gì — đề nói "no signs yet of any compromise", nhưng xác nhận bằng log tốt hơn là giả định.

Đáp án

B — Thêm VPC Interface Endpoint cho Secrets Manager và cấu hình subnet của Lambda function dùng endpoint đó.

Vì sao đúng

Đề mô tả tình huống rất rõ: VPC không cho phép lưu lượng ra/vào Internet, Lambda nằm trong VPC, và nó không gọi được Secrets Manager.

Nguyên nhân: Secrets Manager là dịch vụ khu vực có endpoint công khai — nó không nằm trong VPC của bạn. Lambda trong VPC không có đường ra Internet nên không tới được.

Không có VPC endpoint:
  Lambda (trong VPC, không có IGW/NAT)
      ↓ gọi secretsmanager.ap-northeast-1.amazonaws.com
  ✗ không có đường ra → timeout

Có Interface VPC Endpoint:
  Lambda → ENI của endpoint (trong subnet của bạn) → PrivateLink → Secrets Manager
  ✓ KHÔNG rời khỏi mạng AWS

Interface endpoint tạo một ENI có IP riêng tư trong subnet của bạn, và private DNS khiến tên miền dịch vụ tự phân giải về IP đó — nên mã Lambda không cần sửa gì.

aws ec2 create-vpc-endpoint   --vpc-id vpc-0abc123   --service-name com.amazonaws.ap-northeast-1.secretsmanager   --vpc-endpoint-type Interface   --subnet-ids subnet-0aaa subnet-0bbb   --security-group-ids sg-0ccc   --private-dns-enabled

Hai điều kiện đi kèm dễ bỏ sót: | Điều kiện | Chi tiết | |---|---| | Security group của endpoint | phải cho phép HTTPS (443) từ security group của Lambda | | enableDnsHostnames và enableDnsSupport bật trên VPC | nếu không, private DNS không hoạt động |

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

• D. Tạo NAT Gateway trong VPC và cấu hình Lambda dùng nó để kết nối Secrets Manager — đây là phương án gần nhất và về mặt kỹ thuật sẽ hoạt động, nhưng nó vi phạm chính sách bảo mật của công ty: NAT Gateway đi ra Internet công cộng. Đề nói rõ VPC "does not allow any network traffic to or from the internet".
• C. Tạo VPC Peering giữa VPC và Secrets Manager — không thực hiện được: VPC peering nối hai VPC với nhau. Secrets Manager không nằm trong một VPC nào cả — nó là dịch vụ khu vực.
• A. Tạo Direct Connect giữa VPC và Secrets Manager — cùng lỗi khái niệm: Direct Connect nối trung tâm dữ liệu tại chỗ với AWS, không nối VPC với một dịch vụ AWS.

Ghi nhớ

Hai loại VPC endpoint — nhớ đúng loại nào cho dịch vụ nào: | Loại | Cơ chế | Dịch vụ | Chi phí | |---|---|---|---| | Gateway endpoint | route table entry | CHỈ S3 và DynamoDB | MIỄN PHÍ | | Interface endpoint | ENI trong subnet (PrivateLink) | hầu hết dịch vụ khác | theo giờ + GB |

Secrets Manager, KMS, SSM, ECR, CloudWatch, SNS, SQS — tất cả đều dùng Interface endpoint.

Ba lỗi thường gặp khi cấu hình Interface endpoint: | Lỗi | Triệu chứng | |---|---| | Security group chặn 443 | timeout khi gọi API | | Không bật private DNS | vẫn phân giải ra IP công khai → không tới được | | Thiếu endpoint cho dịch vụ phụ thuộc | một phần chức năng hoạt động, phần khác không |

Dòng cuối rất hay gặp: một Lambda xoay vòng secret cho RDS cần cả secretsmanager lẫn có thể cả kms (nếu secret mã hoá bằng CMK) — thiếu endpoint thứ hai thì lời gọi vẫn thất bại.

Ba lớp kiểm soát cho Interface endpoint: | Lớp | Kiểm soát | |---|---| | Security group trên endpoint | ai kết nối được | | Endpoint policy | hành động và tài nguyên nào được phép qua endpoint này | | IAM policy | quyền của principal |

Endpoint policy đáng dùng cho môi trường nhạy cảm: nó cho phép nói "qua endpoint này chỉ đọc được đúng secret X", một ràng buộc mà IAM policy của từng role khó bao quát hết.

Và với việc xoay vòng secret trong VPC riêng, nhớ thêm: Lambda xoay vòng cần cả đường tới Secrets Manager LẪN tới chính cơ sở dữ liệu — security group của RDS phải cho phép kết nối từ security group của Lambda, điều mà đề nói kỹ sư đã làm.

Đáp án

B — Cấu hình xác thực dựa trên SAML gắn với một IAM role có PowerUserAccess, và gắn thêm customer-managed policy TỪ CHỐI truy cập RDS ở mọi Region trừ us-east-1.

Vì sao đúng

Đề nêu bốn yêu cầu, và B đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Kiểm soát truy cập bằng Active Directory | SAML federation | | Đặc quyền tối thiểu cho lập trình viên | PowerUserAccess — không có quyền IAM | | Chỉ tạo RDS ở us-east-1 | explicit Deny với condition Region | | Không giới hạn dịch vụ khác ở Region nào | Deny chỉ áp cho rds:* |

SAML federation cho vế Active Directory: người dùng đăng nhập bằng tài khoản AD sẵn có, và không cần tạo IAM user cho từng người — đúng yêu cầu "minimizing the operational burden on the systems administration team".

Và explicit Deny là cơ chế đúng cho ràng buộc Region:

{
  "Effect": "Deny",
  "Action": "rds:*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {"aws:RequestedRegion": "us-east-1"}
  }
}

Vì explicit Deny luôn thắng mọi Allow, policy này chặn RDS ở mọi Region khác mà không đụng tới quyền với dịch vụ khác.

PowerUserAccess là lựa chọn đúng cho "đặc quyền tối thiểu" ở đây: nó cho toàn quyền với dịch vụ AWS nhưng KHÔNG có quyền quản lý IAM — nên lập trình viên không tự nâng quyền của mình được.

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

• A. IAM user cho từng lập trình viên, thêm vào group có PowerUserAccess, gắn policy CHO PHÉP truy cập RDS chỉ ở us-east-1 — hai vấn đề: tạo IAM user cho từng người trái yêu cầu dùng Active Directory và tăng gánh nặng quản trị; và Allow không chặn được gì — PowerUserAccess đã cho phép RDS ở mọi Region, thêm một Allow nữa không loại bỏ quyền đó. Phải dùng Deny.
• D. SAML federation gắn với role có AdministratorAccess, cộng policy từ chối RDS ngoài us-east-1 — đây là phương án gần nhất và chỉ sai ở mức quyền: AdministratorAccess cho cả quyền IAM, nghĩa là lập trình viên tự sửa được policy hạn chế của chính mình. Trái thẳng nguyên tắc đặc quyền tối thiểu.
• C. SAML federation với PowerUserAccess cộng policy từ chối MỌI dịch vụ trừ Service Catalog; trong Service Catalog tạo product chỉ có RDS ở us-east-1 — quá hạn chế: đề nói rõ "without limiting access to other services in any Region", nhưng phương án này khoá lập trình viên chỉ còn Service Catalog. (Service Catalog là công cụ tốt để chuẩn hoá việc cấp phát — nhưng nó không phù hợp với yêu cầu này.)

Ghi nhớ

Thứ tự đánh giá policy của IAM:

① Explicit DENY ở bất kỳ đâu  →  TỪ CHỐI (luôn thắng)
② Explicit ALLOW              →  cho phép
③ Không có gì                 →  implicit deny (từ chối)

Hệ quả thực tế: để thu hẹp quyền đã có, phải dùng Deny — thêm một Allow hẹp hơn không có tác dụng gì.

Ba condition key liên quan tới Region: | Condition key | Ý nghĩa | |---|---| | aws:RequestedRegion | Region mà request nhắm tới | | aws:SourceIp | IP nguồn của người gọi | | aws:PrincipalArn | ARN của principal |

Một chi tiết quan trọng về dịch vụ toàn cầu: IAM, CloudFront, Route 53, và một số dịch vụ khác chạy ở us-east-1 hoặc không có Region. Nếu chặn theo aws:RequestedRegion cho mọi dịch vụ, bạn sẽ vô tình chặn chúng — nên dùng NotAction để chừa ra:

{"Effect": "Deny",
 "NotAction": ["iam:*", "cloudfront:*", "route53:*", "support:*"],
 "Resource": "*",
 "Condition": {"StringNotEquals": {"aws:RequestedRegion": "us-east-1"}}}

(Trong câu này, Deny chỉ áp cho rds:* nên vấn đề đó không phát sinh.)

Bốn managed policy hay dùng, theo mức quyền: | Policy | Quyền | |---|---| | AdministratorAccess | toàn quyền, GỒM CẢ IAM | | PowerUserAccess | toàn quyền dịch vụ, KHÔNG có IAM | | ReadOnlyAccess | chỉ đọc mọi dịch vụ | | ViewOnlyAccess | chỉ liệt kê, không xem chi tiết |

Khác biệt giữa hai dòng đầu là điểm phân biệt trong nhiều câu hỏi: PowerUserAccess là lựa chọn chuẩn cho lập trình viên vì nó ngăn việc tự nâng quyền.

Và ba cách kiểm soát Region ở quy mô tổ chức: | Cách | Phạm vi | |---|---| | SCP trong AWS Organizations | toàn bộ tài khoản hoặc OU — mạnh nhất | | IAM policy trên role | ← câu này | | Permissions boundary | trần quyền cho từng entity |

SCP là công cụ mạnh nhất cho ràng buộc kiểu này trong tổ chức nhiều tài khoản — nhưng đề chỉ nói về một nhóm lập trình viên, nên IAM policy trên role là mức phù hợp.

Đáp án

D và E.

• E — Cấu hình CloudTrail gửi trail event tới CloudWatch Logs; tạo metric filter cho log group với pattern eventName = ConsoleLogin và errorMessage = Failed authentication
• D — Tạo CloudWatch alarm với threshold = 3 và period = 5 phút; hành động của alarm là gửi thông báo tới SNS topic mà quản lý đã đăng ký

Vì sao đúng

Đề yêu cầu: thông báo khi đăng nhập thất bại 3 lần liên tiếp trong 5 phút — và cặp E+D dựng đúng luồng đó:

CloudTrail ghi sự kiện đăng nhập
    ↓ E: gửi tới CloudWatch Logs
Metric filter đếm số lần đăng nhập thất bại
    ↓ tạo custom metric
    ↓ D: alarm threshold=3, period=5 phút
SNS → email cho quản lý

Metric filter pattern:

{ ($.eventName = "ConsoleLogin") &&
  ($.errorMessage = "Failed authentication") }

Hai chi tiết trong phương án E là điểm phân biệt với A: | Chi tiết | Đúng | Sai (phương án A) | |---|---|---| | Đích của CloudTrail | CloudWatch Logs | CloudWatch Alarm | | Tên sự kiện | ConsoleLogin | ConsoleSignin |

Cả hai đều là lỗi thật: CloudTrail không gửi thẳng tới Alarm (alarm hoạt động trên metric, không trên log), và ConsoleSignin không phải tên sự kiện hợp lệ — API thật là ConsoleLogin.

Và alarm cần cấu hình đúng ba tham số:

aws cloudwatch put-metric-alarm   --alarm-name canh-bao-dang-nhap-that-bai   --metric-name DangNhapThatBai --namespace BaoMat   --statistic Sum --period 300 --threshold 3   --comparison-operator GreaterThanOrEqualToThreshold   --evaluation-periods 1   --alarm-actions arn:aws:sns:...:canh-bao-bao-mat

--statistic Sum là đúng cho việc đếm; Average sẽ cho kết quả vô nghĩa.

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

• A. Cấu hình CloudTrail gửi trail event tới CloudWatch ALARM; tạo metric filter với eventName là ConsoleSignin — đây là phương án gần nhất và sai ở hai chi tiết vừa nêu: sai đích (phải là Logs) và sai tên sự kiện (phải là ConsoleLogin).
• C. Tạo bảng Athena trỏ tới log CloudTrail trên S3, chạy truy vấn qua Lambda — không phải thời gian thực: Athena truy vấn theo yêu cầu trên dữ liệu đã lưu. Để phát hiện trong cửa sổ 5 phút, bạn phải chạy truy vấn liên tục — tốn kém và phức tạp hơn nhiều so với metric filter.
• B. Tạo hành động thông báo TỪ Lambda function gửi SNS khi kết quả truy vấn cho ra 3 lần trở lên trong 5 phút — phụ thuộc vào phương án C (truy vấn Athena), nên thừa hưởng cùng vấn đề. Và nó là mã tự viết thay cho cơ chế có sẵn.

Ghi nhớ

Luồng chuẩn để cảnh báo từ CloudTrail:

CloudTrail  →  CloudWatch Logs  →  Metric Filter  →  Metric  →  Alarm  →  SNS

Bốn mắt xích, và mỗi cái có vai trò riêng — bỏ qua metric filter là không có metric để đặt alarm.

Ba thành phần của metric filter: | Thành phần | Việc | |---|---| | Filter pattern | điều kiện khớp log | | Metric name và namespace | nơi ghi số đếm | | Metric value | thường là 1 cho mỗi lần khớp |

Cú pháp filter pattern cho log JSON:

{ $.eventName = "ConsoleLogin" }                     // một điều kiện
{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }
{ $.userIdentity.type = "Root" }                      // trường lồng nhau
{ $.errorCode = "*UnauthorizedOperation" }            // wildcard

Ba sự kiện CloudTrail đáng đặt alarm cho bảo mật: | Sự kiện | Ý nghĩa | |---|---| | ConsoleLogin + Failed authentication | thử đăng nhập sai — có thể là brute force | | ConsoleLogin với userIdentity.type = Root | root user đăng nhập — luôn đáng chú ý | | errorCode chứa UnauthorizedOperation | nỗ lực truy cập trái phép |

Ba tham số alarm cần hiểu đúng: | Tham số | Việc | |---|---| | Period | độ dài mỗi chu kỳ đánh giá (giây) | | EvaluationPeriods | bao nhiêu chu kỳ liên tiếp phải vi phạm | | Threshold + ComparisonOperator | ngưỡng và phép so sánh |

Với yêu cầu "3 lần trong 5 phút": Period = 300, Threshold = 3, EvaluationPeriods = 1, Statistic = Sum.

Và một lựa chọn thay thế đáng biết: EventBridge rule bắt sự kiện CloudTrail trực tiếp cho độ trễ thấp hơn metric filter (vốn có độ trễ vài phút). Nhưng EventBridge kích hoạt trên TỪNG sự kiện — muốn đếm 3 lần trong 5 phút thì vẫn cần tự dựng bộ đếm, nên metric filter phù hợp hơn cho yêu cầu này.

Đáp án

A, E và F:

• A — Nếu không tìm thấy Allow nào áp dụng được trong SCP, request bị từ chối — dù đó là từ chối ngầm định
• E — Nếu resource-based policy cấp quyền TRỰC TIẾP cho IAM user hoặc session principal đang gọi, thì implicit deny trong identity-based policy, permissions boundary hoặc session policy KHÔNG ảnh hưởng tới quyết định cuối
• F — Resource-based policy cấp quyền cho ARN của IAM ROLE thì BỊ giới hạn bởi implicit deny trong permissions boundary hoặc session policy

Vì sao đúng

Ba phát biểu này mô tả ba quy tắc thật trong cơ chế đánh giá policy của IAM.

A — SCP hoạt động như một trần quyền, và nó là "allow list":

SCP mặc định (FullAWSAccess) cho phép mọi thứ
Nếu bạn thay bằng SCP hẹp hơn:
    → hành động KHÔNG nằm trong Allow của SCP bị TỪ CHỐI
    → dù IAM policy có cho phép

SCP không cấp quyền; nó chỉ giới hạn những gì tài khoản có thể làm.

E và F là cặp đối lập, và khác biệt nằm ở kiểu principal: | Resource policy cấp cho | Bị permissions boundary / session policy giới hạn? | |---|---| | IAM user hoặc session principal cụ thể | ❌ KHÔNG | | IAM role ARN | ✅ CÓ |

Vì sao có khác biệt này: khi resource-based policy nêu đích danh user hoặc phiên, AWS coi đó là cấp quyền trực tiếp cho chính danh tính đang gọi — không cần identity-based policy cho phép thêm. Còn khi nó nêu role ARN, quyền đi qua cơ chế assume role, và các ràng buộc của phiên vẫn áp dụng.

Đây là một trong những chi tiết tinh vi nhất của IAM, và nó ảnh hưởng thật tới thiết kế: cấp quyền cho role ARN an toàn hơn vì permissions boundary vẫn còn tác dụng.

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

• B. Nếu resource-based policy cấp quyền trực tiếp cho IAM user hoặc session principal, thì implicit deny trong identity-based policy, permissions boundary hoặc session policy DẪN TỚI Deny cuối cùng — đây là phương án gần nhất và mâu thuẫn trực tiếp với E: đó chính là trường hợp implicit deny không ảnh hưởng.
• C. Nếu resource-based policy cấp quyền cho ARN của federated user, request trong phiên đó KHÔNG bị giới hạn bởi implicit deny trong permissions boundary hay session policy — sai chiều: với federated user, session policy vẫn áp dụng. (Quy tắc miễn trừ áp cho IAM user và session principal được nêu đích danh, không phải cho mọi kiểu federated.)
• D. Nếu không có explicit Allow trong SCP, request được implicit Allow sau khi SCP được đánh giá — ngược hoàn toàn với A: không có Allow trong SCP nghĩa là bị từ chối.

Ghi nhớ

Thứ tự đánh giá policy của IAM — bảng nền tảng:

① Explicit DENY ở BẤT KỲ loại policy nào  →  TỪ CHỐI (luôn thắng)
② SCP: có Allow không?                     →  không có → từ chối
③ Resource-based policy: có Allow không?
④ Identity-based policy: có Allow không?
⑤ Permissions boundary: có Allow không?
⑥ Session policy: có Allow không?
⑦ Nếu qua hết → CHO PHÉP; ngược lại → implicit deny

Sáu loại policy và vai trò: | Loại | Việc | |---|---| | Identity-based | cấp quyền cho user, group, role | | Resource-based | cấp quyền TRÊN tài nguyên, có Principal | | SCP | TRẦN quyền cho tài khoản/OU — không cấp quyền | | Permissions boundary | TRẦN quyền cho một IAM entity | | Session policy | giới hạn phiên khi assume role | | ACL | cơ chế cũ (S3, cross-account) |

Ba loại giữa đều là TRẦN, không phải nguồn quyền: chúng giới hạn những gì identity-based policy cấp, chứ không tự cấp gì.

Đặc điểm riêng của resource-based policy — điểm mấu chốt của câu này: | Đặc điểm | Chi tiết | |---|---| | Có phần tử Principal | identity-based policy không có | | Cấp quyền chéo tài khoản được | mà không cần assume role | | Cấp trực tiếp cho user/session thì bỏ qua boundary | ← quy tắc E | | Cấp cho role ARN thì boundary vẫn áp dụng | ← quy tắc F |

Ba dịch vụ có resource-based policy hay gặp: S3 (bucket policy), KMS (key policy), Lambda (resource policy), cùng SNS, SQS, Secrets Manager.

Và một hệ quả thực tế đáng nhớ: nếu bạn dựa vào permissions boundary làm rào chắn bảo mật, hãy cấp quyền resource-based cho ROLE ARN, không cho user cụ thể — nếu không, boundary bị bỏ qua và rào chắn không còn tác dụng.

Đáp án

C và D.

• C — Thiết lập CloudWatch Events (EventBridge) rule kích hoạt khi có bất kỳ lời gọi API nào từ root user
• D — Dùng Amazon SNS làm target của rule để thông báo cho đội bảo mật

Vì sao đúng

Đề yêu cầu giám sát và báo cáo mọi hoạt động của root user, và cặp C+D dựng luồng ngắn nhất:

Root user gọi API
    ↓ CloudTrail ghi sự kiện
    ↓ C: EventBridge rule khớp userIdentity.type = "Root"
    ↓ D: SNS topic
Đội bảo mật nhận email

Event pattern:

{
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "userIdentity": {"type": ["Root"]}
  }
}

Vì sao EventBridge phù hợp cho yêu cầu này: | Đặc điểm | Chi tiết | |---|---| | Gần thời gian thực | độ trễ thấp hơn metric filter của CloudWatch Logs | | Kích hoạt trên TỪNG sự kiện | đúng yêu cầu "mọi hoạt động root" | | Nhiều loại target | SNS, Lambda, Step Functions, SQS | | Không cần đếm hay đặt ngưỡng | mọi lời gọi root đều đáng báo |

Điểm quan trọng: giám sát root user không cần ngưỡng. Khác với đăng nhập thất bại (cần đếm 3 lần), root user gọi API là sự kiện đáng chú ý ngay từ lần đầu — nên EventBridge phản ứng trên từng sự kiện là đúng, không cần metric filter và alarm.

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

• E. Thiết lập AWS Config rule kích hoạt sự kiện xuống SNS trên mọi lời gọi API từ root user — đây là phương án gần nhất và dùng sai dịch vụ: AWS Config đánh giá cấu hình tài nguyên có tuân thủ không (bucket có mã hoá không, security group có mở port 22 không). Nó không theo dõi lời gọi API.
• A. Thiết lập AWS Trusted Advisor giám sát lời gọi API của root user — Trusted Advisor đưa ra khuyến nghị về chi phí, hiệu năng, bảo mật, giới hạn dịch vụ. Nó không giám sát API call theo thời gian thực. (Nó có kiểm tra "root account MFA enabled" — nhưng đó là kiểm tra trạng thái, không phải giám sát hoạt động.)
• B. Thiết lập AWS Inspector giám sát lời gọi API của root user — Inspector quét lỗ hổng bảo mật cho EC2, container và Lambda (CVE, cấu hình mạng). Không liên quan tới API call.

Ghi nhớ

Bốn dịch vụ giám sát và vai trò — nhóm hay nhầm: | Dịch vụ | Việc | |---|---| | CloudTrail | GHI ai gọi API nào | | EventBridge | PHẢN ỨNG với sự kiện theo mẫu | | CloudWatch | metric, log, alarm theo ngưỡng | | AWS Config | cấu hình tài nguyên có tuân thủ không | | Inspector | quét lỗ hổng | | Trusted Advisor | khuyến nghị tối ưu |

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

"Ai đã làm gì?" → CloudTrail "Phản ứng ngay khi có sự kiện X" → EventBridge "Báo khi vượt ngưỡng đếm được" → CloudWatch alarm "Tài nguyên có cấu hình đúng chuẩn không?" → Config

Hai cách cảnh báo từ CloudTrail — chọn theo nhu cầu: | Cách | Đặc điểm | Dùng khi | |---|---|---| | EventBridge rule | từng sự kiện, độ trễ thấp | sự kiện đơn lẻ đã đáng báo | | CloudWatch Logs metric filter + alarm | đếm và so ngưỡng | cần N lần trong khoảng thời gian |

Câu này dùng cách đầu; câu #7677 (đăng nhập thất bại 3 lần) dùng cách thứ hai — và tiêu chí phân biệt là có cần đếm hay không.

Ba mẫu event pattern hữu ích cho giám sát bảo mật:

// Root user gọi API
{"detail": {"userIdentity": {"type": ["Root"]}}}

// Thao tác phá huỷ
{"detail": {"eventName": ["DeleteBucket", "DeleteDBInstance", "TerminateInstances"]}}

// Nỗ lực trái phép
{"detail": {"errorCode": [{"prefix": "AccessDenied"}]}}

Và ba thực hành bắt buộc với root user: | Thực hành | Chi tiết | |---|---| | Bật MFA phần cứng | root là danh tính mạnh nhất trong tài khoản | | KHÔNG tạo access key cho root | và xoá nếu đã có | | Chỉ dùng root cho vài tác vụ bắt buộc | đổi thông tin thanh toán, đóng tài khoản |

Vì root gần như không bao giờ nên được dùng, mọi hoạt động của nó đều là ngoại lệ đáng điều tra — đó là lý do cảnh báo trên từng sự kiện là thiết kế đúng.

Đáp án

B và C.

• C — Bật CloudTrail trail cho mọi tài khoản và mọi dịch vụ, ghi log vào CloudWatch Logs có mã hoá bằng KMS key
• B — Dùng AWS Config rule kiểm toán thay đổi tài nguyên và theo dõi tuân thủ, chạy đánh giá theo tần suất bạn chọn; viết Config custom rule để kích hoạt đánh giá khi tài nguyên trong phạm vi rule thay đổi cấu hình

Vì sao đúng

Đề nêu yêu cầu rất cụ thể: liên tục đánh giá, kiểm toán và giám sát CẤU HÌNH của tài nguyên AWS — và cặp B+C phủ hai mặt của việc đó: | Mặt | Cơ chế | |---|---| | Ai đã làm gì (hoạt động) | C — CloudTrail | | Cấu hình có ĐÚNG CHUẨN không | B — AWS Config |

C — CloudTrail cho vết kiểm toán:

Trail bật cho MỌI tài khoản + MỌI dịch vụ
    ↓ ghi vào CloudWatch Logs (mã hoá KMS)
Truy vấn được, đặt alarm được, giữ lâu dài được

Vế mã hoá bằng KMS không phải chi tiết thừa: log kiểm toán chứa thông tin nhạy cảm về hạ tầng, và với ngành tài chính và y tế thì mã hoá là yêu cầu bắt buộc.

B — Config cho việc đánh giá tuân thủ liên tục:

# Config rule đánh giá khi tài nguyên thay đổi
{
  "ConfigRuleName": "s3-bucket-phai-ma-hoa",
  "Source": {"Owner": "AWS",
             "SourceIdentifier": "S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED"},
  "Scope": {"ComplianceResourceTypes": ["AWS::S3::Bucket"]}
}

Và "custom rule kích hoạt khi cấu hình thay đổi" là điểm mạnh riêng của Config: | Chế độ kích hoạt | Khi nào chạy | |---|---| | Configuration change | ngay khi tài nguyên thay đổi | | Periodic | theo lịch (1, 3, 6, 12, 24 giờ) | | Cả hai | kết hợp |

Chế độ đầu cho đúng nghĩa "continuously assessing" mà đề yêu cầu.

Vì sao Config chứ không phải công cụ khác: nó lưu lịch sử cấu hình của từng tài nguyên theo thời gian, nên trả lời được câu hỏi kiểm toán "bucket này có được mã hoá vào ngày 15 tháng trước không?" — thứ mà CloudTrail (chỉ ghi sự kiện) không trả lời trực tiếp được.

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

• D. Dùng EventBridge giám sát mẫu sự kiện gần thời gian thực, kích hoạt Lambda tự động hoàn tác thay đổi trái phép; gửi thông báo qua SNS — đây là phương án gần nhất và là cơ chế khắc phục tốt, nhưng nó không phải công cụ ĐÁNH GIÁ TUÂN THỦ: nó phản ứng với sự kiện, nhưng không cho biết trạng thái tuân thủ tổng thể của các tài nguyên. (Nó bổ sung tốt cho Config — Config phát hiện, EventBridge kích hoạt khắc phục.)
• E. Dùng tích hợp CloudTrail với SNS để tự động thông báo hoạt động API trái phép, cộng Lambda hoàn tác thay đổi — cùng vấn đề: đây là giám sát hoạt động, không phải đánh giá cấu hình. Và đề đã có vế CloudTrail ở phương án C với cách triển khai đầy đủ hơn.
• A. Dùng CloudWatch Logs agent thu thập log AWS SDK, tìm mẫu khớp lời gọi API thay đổi trạng thái, alarm qua SNS, lưu trữ vào S3 và phân tích bằng Athena — cách tiếp cận sai từ gốc: log SDK nằm ở phía client và không đầy đủ (không bắt được thao tác từ Console hay từ dịch vụ khác). CloudTrail là nguồn đúng và đã có sẵn.

Ghi nhớ

Bốn dịch vụ quản trị và tuân thủ — nhớ đúng vai: | Dịch vụ | Trả lời | |---|---| | CloudTrail | "AI đã làm gì, khi nào?" | | AWS Config | "Tài nguyên có cấu hình ĐÚNG CHUẨN không?" | | Security Hub | "Tổng hợp phát hiện từ nhiều nguồn, chấm điểm theo chuẩn" | | EventBridge | "Phản ứng khi có sự kiện X" |

Cả bốn nên dùng cùng nhau trong một khung quản trị đầy đủ:

CloudTrail   → ghi mọi hoạt động
Config       → đánh giá tuân thủ liên tục
Security Hub → tổng hợp và chấm điểm theo CIS, PCI DSS, AWS Foundational
EventBridge  → kích hoạt khắc phục tự động

Ba khả năng của AWS Config: | Khả năng | Chi tiết | |---|---| | Configuration history | lịch sử cấu hình từng tài nguyên theo thời gian | | Config rules | managed rule (hàng trăm cái) hoặc custom rule | | Conformance pack | bộ rule đóng gói theo chuẩn: PCI DSS, HIPAA, NIST |

Conformance pack đáng biết cho ngành chịu quản lý: thay vì cấu hình từng rule, bạn triển khai một gói chuẩn sẵn và có ngay bảng điểm tuân thủ.

Ba cách viết custom rule: | Cách | Chi tiết | |---|---| | Lambda function | linh hoạt nhất, viết bằng mã | | Guard custom policy | viết bằng ngôn ngữ Guard, không cần mã | | Managed rule có tham số | tuỳ chỉnh rule sẵn có |

Dòng giữa là lựa chọn ít công nhất cho quy tắc đơn giản — xem thêm câu về CloudFormation Guard.

Và một điểm về việc kích hoạt tự động khắc phục: Config có remediation action dựng sẵn dùng SSM Automation document — nên bạn không nhất thiết phải tự viết Lambda như phương án D mô tả.

Đáp án

C — Kết hợp AWS Direct Connect với AWS Site-to-Site VPN.

Vì sao đúng

Đề nêu ba yêu cầu, và chỉ sự kết hợp này thoả cả ba: | Yêu cầu | Cơ chế | |---|---| | Bắt buộc mã hoá IPsec cho mọi liên lạc ngoài cơ sở | Site-to-Site VPN — IPsec | | Workload nhạy cảm với độ trễ | Direct Connect — đường riêng, độ trễ ổn định | | Giữ trung tâm dữ liệu tại chỗ | kiến trúc lai |

Điểm mấu chốt: Direct Connect KHÔNG mã hoá dữ liệu.

Direct Connect một mình:
  ✓ độ trễ thấp và ổn định (đường riêng, không qua Internet)
  ✗ KHÔNG mã hoá — dữ liệu đi ở dạng rõ trên đường truyền

Site-to-Site VPN một mình:
  ✓ mã hoá IPsec
  ✗ đi qua INTERNET → độ trễ biến động, không đảm bảo

Kết hợp cả hai:
  ✓ chạy VPN IPsec BÊN TRONG Direct Connect
  → vừa mã hoá vừa có độ trễ ổn định

Đây là kiến trúc chuẩn cho các tổ chức có yêu cầu tuân thủ về mã hoá đường truyền kèm workload nhạy cảm với độ trễ — đúng mô tả trong đề.

Cách triển khai: dựng VPN tunnel qua public VIF của Direct Connect, hoặc dùng AWS Direct Connect + Transit Gateway với VPN attachment.

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

• D. Dùng Direct Connect, vì nó mã hoá lưu lượng đang truyền theo mặc định — đây là phương án gần nhất và mắc đúng hiểu lầm phổ biến nhất về Direct Connect: nó KHÔNG mã hoá gì cả. Nó là một kết nối mạng riêng — riêng tư về mặt định tuyến, nhưng dữ liệu đi ở dạng rõ.
• B. Dùng VPC peering hỗ trợ MACsec để mã hoá dữ liệu từ trung tâm dữ liệu tới AWS — hai lỗi: VPC peering nối hai VPC với nhau, không nối trung tâm dữ liệu tại chỗ với AWS; và MACsec là tính năng của Direct Connect (mã hoá ở tầng 2 trên các cổng chuyên dụng), không phải của VPC peering.
• A. Dùng AWS PrivateLink thiết lập kết nối riêng giữa AWS và trung tâm dữ liệu — PrivateLink phơi một DỊCH VỤ qua endpoint riêng tư trong VPC, nó không phải cơ chế kết nối mạng lai. Truy cập PrivateLink từ tại chỗ vẫn cần Direct Connect hoặc VPN làm nền.

Ghi nhớ

Ba cách kết nối trung tâm dữ liệu tại chỗ với AWS: | Cách | Mã hoá | Độ trễ | Chi phí | |---|---|---|---| | Site-to-Site VPN | ✅ IPsec | biến động (qua Internet) | thấp | | Direct Connect | ❌ KHÔNG | thấp và ổn định | cao hơn | | Direct Connect + VPN | ✅ | thấp và ổn định | cao nhất |

Bảng này là nội dung cốt lõi của câu hỏi — và dòng "Direct Connect không mã hoá" là điểm bị hiểu nhầm nhiều nhất.

Hai cách mã hoá trên Direct Connect: | Cách | Tầng | Đặc điểm | |---|---|---| | Site-to-Site VPN qua DX | tầng 3 (IPsec) | phổ biến, hoạt động trên mọi loại DX | | MACsec | tầng 2 | chỉ trên cổng chuyên dụng 10/100 Gbps, mã hoá theo chặng |

MACsec đáng biết: nó mã hoá ở tầng liên kết dữ liệu với overhead thấp hơn IPsec, nhưng chỉ có trên một số loại cổng và chỉ bảo vệ chặng giữa router của bạn và thiết bị AWS.

Ba loại virtual interface (VIF) của Direct Connect: | Loại | Dùng để | |---|---| | Private VIF | truy cập VPC qua IP riêng | | Public VIF | truy cập dịch vụ công khai của AWS — cần cho VPN qua DX | | Transit VIF | kết nối tới Transit Gateway |

Dòng giữa quan trọng cho kiến trúc này: để dựng VPN qua Direct Connect, thường dùng public VIF làm đường truyền cho tunnel.

Và ba lựa chọn về tính sẵn sàng cho Direct Connect: | Mức | Cấu hình | |---|---| | Phát triển | một kết nối DX | | Production | hai kết nối DX ở hai vị trí khác nhau | | Tối đa | DX kép + VPN dự phòng |

Mức cuối là mẫu thường thấy ở tổ chức tài chính: VPN đóng vai trò dự phòng khi DX gặp sự cố — và vì VPN vốn đã có, nó cũng là đường mã hoá sẵn sàng.

Đáp án

B — Cấu hình traffic mirror target trỏ tới thiết bị giám sát; tạo traffic mirror filter với rule cho lưu lượng ra: TỪ CHỐI gói có IP đích nằm trong CIDR của VPC và CHẤP NHẬN mọi gói ra khác; và rule cho lưu lượng vào: TỪ CHỐI gói có IP nguồn nằm trong CIDR của VPC và CHẤP NHẬN mọi gói vào khác.

Vì sao đúng

Đề nêu hai yêu cầu giám sát, và chúng cần được diễn đạt chính xác bằng filter rule: | Yêu cầu | Rule tương ứng | |---|---| | Mọi lưu lượng RỜI KHỎI VPC | outbound: loại bỏ gói đi tới chính VPC, giữ phần còn lại | | Mọi lưu lượng có nguồn NGOÀI VPC | inbound: loại bỏ gói từ chính VPC, giữ phần còn lại |

Logic "từ chối cái bên trong, chấp nhận phần còn lại" là cách diễn đạt đúng:

Lưu lượng RA:
  đích nằm trong VPC CIDR   → lưu lượng NỘI BỘ → không quan tâm → REJECT
  đích ngoài VPC CIDR       → RỜI KHỎI VPC     → cần giám sát   → ACCEPT

Lưu lượng VÀO:
  nguồn nằm trong VPC CIDR  → lưu lượng NỘI BỘ → REJECT
  nguồn ngoài VPC CIDR      → TỪ BÊN NGOÀI     → ACCEPT

Và VPC Traffic Mirroring là công cụ đúng vì đề cần "content inspection": | | Traffic Mirroring | VPC Flow Logs | |---|---|---| | Nội dung | TOÀN BỘ gói tin (payload) | chỉ METADATA: IP, cổng, số byte | | Dùng cho | kiểm tra nội dung, phát hiện xâm nhập, gỡ lỗi sâu | phân tích luồng, kiểm toán kết nối | | Chi phí | cao hơn | thấp |

Đề yêu cầu "content inspection, troubleshooting, and threat monitoring" — cả ba đều cần nội dung gói tin, và Flow Logs không cung cấp được.

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

• C. Cấu hình traffic mirror target; tạo filter với rule cho TCP inbound, và filter khác với rule cho UDP inbound — đây là phương án gần nhất và thiếu vế lưu lượng RA: đề yêu cầu giám sát cả hai chiều. Và lọc theo giao thức không phân biệt được trong/ngoài VPC — nó vẫn bắt cả lưu lượng nội bộ.
• A. Bật VPC Flow Logs, cấu hình traffic mirror với Flow Logs làm NGUỒN và thiết bị làm target — lẫn lộn hai cơ chế: nguồn của traffic mirror là ENI, không phải Flow Logs. Hai dịch vụ này độc lập với nhau.
• D. Bật VPC Flow Logs và publish trực tiếp lên CloudWatch để phân tích và cảnh báo — Flow Logs không có nội dung gói tin, nên không đáp ứng được "content inspection".

Ghi nhớ

Bốn thành phần của VPC Traffic Mirroring: | Thành phần | Việc | |---|---| | Mirror source | ENI của instance cần giám sát | | Mirror target | ENI, NLB, hoặc Gateway Load Balancer của thiết bị giám sát | | Mirror filter | rule quyết định gói nào được sao chép | | Mirror session | nối source với target qua filter |

Cấu trúc một mirror filter rule: | Trường | Giá trị | |---|---| | Rule number | thứ tự đánh giá — số nhỏ trước | | Direction | ingress hoặc egress | | Rule action | accept hoặc reject | | Protocol, port range | tuỳ chọn | | Source / Destination CIDR | bắt buộc |

Rule được đánh giá theo thứ tự số và dừng ở rule khớp đầu tiên — nên đặt rule reject cho lưu lượng nội bộ ở số nhỏ, rule accept bao quát ở số lớn:

Rule 100: egress, REJECT, destination = 10.0.0.0/16   (VPC CIDR)
Rule 200: egress, ACCEPT, destination = 0.0.0.0/0

So sánh ba công cụ quan sát mạng của VPC: | Công cụ | Cung cấp | Dùng khi | |---|---|---| | VPC Flow Logs | metadata luồng | kiểm toán kết nối, phân tích mẫu, rẻ | | Traffic Mirroring | toàn bộ gói tin | kiểm tra nội dung, IDS/IPS | | Network Access Analyzer | phân tích đường đi khả dĩ | kiểm chứng cấu hình mạng |

Ba giới hạn của Traffic Mirroring cần biết: | Giới hạn | Chi tiết | |---|---| | Chỉ hỗ trợ một số loại instance | Nitro-based | | Tốn băng thông | lưu lượng nhân đôi — tính vào hạn mức của instance | | Chi phí | cao hơn Flow Logs đáng kể |

Dòng giữa là cân nhắc thực tế quan trọng: mirror toàn bộ lưu lượng của một instance tải cao có thể làm nghẽn chính instance đó — nên dùng filter để chỉ mirror phần cần thiết, đúng như đáp án B làm.

Và một lưu ý về việc chọn target: với nhiều nguồn cần giám sát, Gateway Load Balancer là target tốt hơn ENI đơn lẻ — nó phân phối lưu lượng qua nhiều thiết bị giám sát và tự xử lý tính sẵn sàng.

Đáp án

C — Tạo IAM role cho Lambda function có quyền truy cập S3 bucket, cấu hình role đó làm EXECUTION ROLE của Lambda, và xác nhận bucket policy không explicit deny Lambda function hoặc execution role của nó.

Vì sao đúng

Đề hỏi cách hiệu quả nhất để cấp quyền cho Lambda truy cập S3 trong cùng một tài khoản.

Execution role là cơ chế chuẩn:

Lambda function chạy → assume EXECUTION ROLE
    → mọi lời gọi AWS API dùng quyền của role đó
    → không có key nào được lưu ở đâu cả

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::kho-anh/*"
}

Và trong CÙNG một tài khoản, identity-based policy là ĐỦ — đây là điểm phân biệt với phương án A:

Cùng tài khoản:   identity-based policy đủ → KHÔNG cần bucket policy
Khác tài khoản:   cần CẢ HAI — bucket policy (bên sở hữu) + IAM policy (bên gọi)

Vế "xác nhận bucket policy không explicit deny" là chi tiết đúng và cần thiết: vì explicit Deny luôn thắng mọi Allow, một bucket policy có Deny sẽ chặn Lambda dù IAM policy cho phép. Nên kiểm tra là bước hợp lý — nhưng thêm Allow vào bucket policy thì không cần.

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

• A. Tạo IAM role cấp quyền S3, cấp quyền cần thiết TRÊN BUCKET POLICY, và xác nhận bucket policy không deny Lambda — đây là phương án gần nhất và hoạt động được, nhưng nó thừa: với cùng một tài khoản, bucket policy không cần thiết. Và quan trọng hơn, nó thiếu bước gắn role làm execution role — chỉ "tạo role" mà không gán thì Lambda không dùng được nó.
• B. Tạo EC2 key pair, lưu private key trong Secrets Manager, sửa Lambda lấy private key từ Secrets Manager để dùng khi giao tiếp với S3 — nhầm hoàn toàn về cơ chế xác thực: EC2 key pair dùng để SSH vào instance, không liên quan gì tới việc gọi API AWS. S3 không nhận private key SSH.
• D. Tạo security group, gắn vào Lambda, và gắn bucket policy cho phép truy cập qua security group ID — nhầm tầng kiểm soát: security group lọc lưu lượng mạng, còn đây là vấn đề quyền. Và bucket policy không nhận security group ID làm principal — nó chỉ nhận IAM principal (user, role, account).

Ghi nhớ

Nguyên tắc quan trọng nhất về xác thực trên AWS:

Dịch vụ AWS gọi dịch vụ AWS khác thì dùng IAM ROLE, không dùng access key.

Áp dụng cho: Lambda (execution role), EC2 (instance profile), ECS (task role), SageMaker (execution role), Glue (job role).

Ba loại role liên quan tới Lambda: | Role | Việc | |---|---| | Execution role | Lambda dùng để gọi dịch vụ khác | | Resource-based policy | cho phép dịch vụ khác GỌI Lambda | | Invoke permission | quyền của người gọi Lambda |

Hai dòng đầu ngược chiều nhau và hay bị nhầm:

Lambda → S3         : cần EXECUTION ROLE có quyền S3
S3 event → Lambda   : cần RESOURCE-BASED POLICY trên Lambda cho phép s3.amazonaws.com

Khi nào cần bucket policy bên cạnh IAM policy: | Tình huống | Cần bucket policy? | |---|---| | Cùng tài khoản | ❌ IAM policy là đủ | | Khác tài khoản | ✅ cần CẢ HAI | | Cần Deny bao quát | ✅ ví dụ: chặn mọi truy cập không qua VPC endpoint | | Cấp quyền cho principal ngoài AWS | ✅ |

Ba quyền S3 thường cần cho Lambda xử lý ảnh: | Quyền | Việc | |---|---| | s3:GetObject | đọc ảnh gốc | | s3:PutObject | ghi thumbnail | | s3:ListBucket | liệt kê (nếu cần duyệt thư mục) |

Nếu bucket dùng SSE-KMS, cần thêm: | Quyền KMS | Việc | |---|---| | kms:Decrypt | đọc object đã mã hoá | | kms:GenerateDataKey | GHI object mới |

Dòng thứ hai hay bị bỏ sót: đọc được nhưng ghi thất bại là triệu chứng kinh điển của việc thiếu GenerateDataKey.

Và một lưu ý về đặc quyền tối thiểu: giới hạn Resource tới đúng prefix cần thiết, không dùng arn:aws:s3:::*. Với hàm tạo thumbnail, thường là đọc từ anh-goc/* và ghi vào thumbnail/* — hai statement riêng, mỗi cái một prefix.