Cloud & AWSAllow trong một policy chỉ là một phiếu thuận, không phải quyết định cuối. AWS gộp tất cả policy áp lên request rồi đánh giá theo trình tự, và nguyên tắc bao trùm là explicit deny luôn thắng còn mặc định là implicit deny.
Thứ tự đánh giá, rút gọn:
1. Có explicit Deny ở bất kỳ loại policy nào → từ chối, dừng.
2. SCP (AWS Organizations) có cho phép action đó trong account không — SCP không cấp quyền, nó đặt trần.
3. Resource-based policy (bucket policy, KMS key policy, SQS/SNS policy).
4. Permissions boundary của principal — cũng là trần, không phải cấp quyền.
5. Session policy (khi assume role có truyền policy).
6. Identity-based policy gắn vào user/role.
Không có Allow nào ở các bước áp dụng → implicit deny.
Các nguyên nhân thực tế khớp với tình huống này:
- Bucket policy có statement Deny (vd yêu cầu aws:SecureTransport hoặc chỉ cho một VPC endpoint).
- Object mã hoá bằng KMS CMK mà role không có kms:Decrypt trên key đó — quyền S3 đúng nhưng thiếu quyền key.
- Bucket thuộc account khác: cần allow ở cả hai phía — identity policy bên bạn và resource policy bên kia.
- SCP hoặc permissions boundary chặn từ trên xuống.
- Sai ARN: arn:aws:s3:::bucket (bucket) không phủ object; phải là arn:aws:s3:::bucket/*.
Cách gỡ: dùng IAM Policy Simulator để mô phỏng, và đọc CloudTrail — bản ghi AccessDenied cho biết chính xác action, resource và principal nào bị chặn. Khi đó việc còn lại chỉ là xác định policy nào chứa Deny hoặc thiếu Allow.