Vấn đềBạn đang cố gắng lấy mật khẩu cơ sở dữ liệu từ Secrets Manager hoặc tải xuống tệp cấu hình 2KB đã mã hóa từ S3. IAM Role của bạn có quyền AdministratorAccess, nhưng mã nguồn vẫn báo lỗi 403. Cảm giác như đâm đầu vào tường vì về lý thuyết, bạn có quyền làm mọi thứ.

AccessDeniedException: User: arn:aws:iam::123456789012:role/MyRole is not authorized to perform: kms:Decrypt on resource: arn:aws:kms:ap-northeast-1:123456789012:key/abc-123

Nguyên nhân: Cơ chế "Khóa kép"AWS KMS là một trong số ít dịch vụ mà IAM policy không phải là quyết định cuối cùng. Hãy coi nó như một két sắt có hai ổ khóa khác nhau. Để vào được bên trong, bạn cần một chìa khóa từ đội Identity (IAM Policy) và một chìa khóa từ Quản lý két sắt (Key Policy).

Nếu Key Policy không đề cập rõ ràng đến role của bạn, AWS sẽ mặc định là "Từ chối" (Deny). Điều này xảy ra ngay cả khi bạn là Account Admin. Cơ chế an toàn này ngăn chặn một tài khoản admin bị xâm nhập có thể truy cập ngay lập tức vào dữ liệu nhạy cảm được mã hóa 256-bit trên toàn bộ hạ tầng.

Các bước khắc phục### Bước 1: Lấy ARN của KeyHãy xem lại thông báo lỗi của bạn. Chuỗi bắt đầu bằng arn:aws:kms... chính là tài nguyên đang chặn bạn. Hãy sao chép ARN này; bạn sẽ cần nó để tìm đúng key trong số hàng trăm key khác.

Bước 2: Kiểm tra phía IAMIAM Role (MyRole) của bạn vẫn cần quyền cơ bản để giao tiếp với KMS. Mở IAM Console và đảm bảo policy của bạn bao gồm đoạn mã này:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "kms:Decrypt",
            "Resource": "arn:aws:kms:ap-northeast-1:123456789012:key/abc-123"
        }
    ]
}

Bước 3: Sửa Key Policy (Giải pháp thực sự)Đây là nơi 90% các lỗi này được giải quyết. Bạn phải yêu cầu KMS key tin tưởng IAM role của mình.

• Mở KMS Console và tìm key abc-123.- Nhấp vào tab Key policy và chọn Edit.- Chèn statement này vào mảng Statement:``` { "Sid": "AllowMySpecificRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/MyRole" }, "Action": [ "kms:Decrypt", "kms:DescribeKey" ], "Resource": "*" }

**Pro Tip:** Trong một Key Policy, `"Resource": "*"` không có nghĩa là "mọi key trong AWS". Nó chỉ đề cập cụ thể đến duy nhất key mà policy này được gán vào.
### Bước 4: Xử lý truy cập chéo tài khoản (Cross-Account)Bạn đang cố gắng giải mã một key ở Tài khoản B (`444455556666`) bằng một Lambda ở Tài khoản A (`111122223333`)? Điều này yêu cầu một bước "bắt tay". Key Policy của Tài khoản B phải liệt kê đầy đủ ARN của role từ Tài khoản A dưới dạng `Principal`. Nếu không có bước xác nhận rõ ràng này, yêu cầu sẽ luôn thất bại.
## Kiểm tra kết quảĐừng đợi 10 phút để chạy pipeline CI/CD. Hãy sử dụng AWS CLI để xác minh kết quả trong vài giây:

Kiểm tra xem bạn có thấy key không

aws kms describe-key --key-id arn:aws:kms:ap-northeast-1:123456789012:key/abc-123

Thử giải mã giả lập

aws kms decrypt --key-id arn:aws:kms:ap-northeast-1:123456789012:key/abc-123 --ciphertext-blob fileb://encrypted_data.bin

Một phản hồi JSON thành công chứa `KeyMetadata` có nghĩa là bạn đã vượt qua trở ngại thành công.
## Tóm tắt xử lý sự cố- **Quy tắc "Root":** Kiểm tra xem Key Policy của bạn có cho phép người dùng `root` của tài khoản không. Nếu có, các IAM policy sẽ hoạt động bình thường. Nếu thiếu khối này, chỉ những người dùng được liệt kê trong Key Policy mới có thể sử dụng key.- **Service Roles:** Khi sử dụng S3 hoặc Lambda, hãy đảm bảo bạn đang cấp quyền cho **Execution Role**, chứ không phải IAM user cá nhân của bạn.- **CloudTrail:** Nếu vẫn bị kẹt, hãy xem nhật ký CloudTrail. Lọc theo `EventSource: kms.amazonaws.com`. Nhật ký sẽ cho bạn biết chính xác policy nào—IAM hay Key—đã đưa ra lỗi `Access Denied`.