Mục tiêu học tập
- Hiểu KMS: key types, envelope encryption, key policy
- Thuộc các tùy chọn mã hóa S3: SSE-S3, SSE-KMS, DSSE-KMS, SSE-C, client-side
- Biết mã hóa at-rest/in-transit trên các data service chính
- Xử lý các lỗi quyền KMS trong pipeline
1. AWS KMS căn bản
- KMS key (trước gọi CMK): key 256-bit không bao giờ rời KMS; thao tác qua API (
Encrypt,Decrypt,GenerateDataKey) - Envelope encryption: KMS sinh data key → dữ liệu mã hóa bằng data key (nhanh, local) → data key được mã hóa bằng KMS key và lưu kèm dữ liệu
- Loại key: AWS managed (
aws/s3... — miễn phí, không kiểm soát policy) vs customer managed (kiểm soát policy/rotation/grant, $1/tháng — chọn khi cần audit/cross-account) vs AWS owned (vô hình) - Key policy là gốc quyền trên key (kết hợp IAM policy); grants cho service dùng tạm
- Rotation: customer managed key bật automatic rotation hàng năm; multi-Region keys cho DR
- Key theo region — dữ liệu mã hóa cross-region cần key ở region đích (hoặc multi-Region key)
2. Mã hóa S3 — bảng phải thuộc
| Tùy chọn | Key do ai quản | Đặc điểm / khi dùng |
|---|---|---|
| SSE-S3 (mặc định từ 2023) | S3 quản (AES-256) | Đơn giản, miễn phí, không audit per-key |
| SSE-KMS | KMS key (aws managed hoặc customer managed) | Audit CloudTrail per key, kiểm soát quyền, cross-account — chuẩn cho data lake |
| SSE-KMS + Bucket Keys | như trên | Giảm mạnh số call KMS (chi phí) cho bucket ghi nhiều |
| DSSE-KMS | KMS, mã hóa 2 lớp | Yêu cầu compliance đặc biệt |
| SSE-C | Khách gửi key theo từng request | Tự quản key, hiếm dùng |
| Client-side | Mã hóa trước khi upload | Zero-trust với AWS, tự lo toàn bộ |
- Enforce: bucket policy từ chối
PutObjectthiếu headers3:x-amz-server-side-encryption(hoặc dùng default encryption + block policy sai) - Bucket Keys: điểm cost hay thi — "chi phí KMS request cao trên bucket SSE-KMS ghi dày" → bật Bucket Keys
3. At-rest và in-transit trên các data service
| Service | At-rest | In-transit |
|---|---|---|
| S3 | SSE-S3/KMS (trên) | TLS; bucket policy aws:SecureTransport: false → Deny |
| Redshift | KMS khi tạo cluster/namespace | TLS (require_ssl) |
| Glue | Security configuration: S3/CloudWatch/bookmark encryption | TLS; JDBC SSL |
| Kinesis/Firehose | Server-side encryption với KMS | TLS |
| MSK | KMS trên EBS | TLS broker-client + in-cluster |
| DynamoDB | Luôn mã hóa (AWS owned/managed/customer key) | TLS |
| EMR | Security configuration: EBS/local disk + S3 (EMRFS) | TLS giữa node |
| OpenSearch | KMS | TLS + node-to-node encryption |
4. Lỗi quyền KMS trong pipeline (troubleshooting)
Pattern lỗi số 1: service đọc/ghi S3 SSE-KMS bị AccessDenied dù quyền S3 đầy đủ:
- Role cần thêm:
kms:Decrypt(đọc),kms:GenerateDataKey(ghi) trên key ARN - Key policy cũng phải cho phép principal đó (key policy là gốc — IAM allow mà key policy không mở thì vẫn fail với key khác account)
- Cross-account: key policy bên A cho account B + IAM bên B cho phép — cả hai phía (giống S3 cross-account)
- Firehose/Glue/Redshift COPY dùng role của chính nó để gọi KMS — cấp quyền cho đúng role đang thực thi
Câu hỏi ôn tập
-
Data lake yêu cầu: audit được mọi lần dùng key giải mã, tự kiểm soát ai dùng key, chia sẻ cross-account. Chọn phương án mã hóa S3 nào?
Xem đáp án
SSE-KMS với customer managed key: CloudTrail ghi mọi
Decrypt/GenerateDataKeytheo key; key policy do bạn kiểm soát (thêm được account khác); rotation bật được. SSE-S3 không có audit per-key, không kiểm soát policy; AWS managed key (aws/s3) không sửa được key policy nên khó cross-account. -
Bucket SSE-KMS nhận hàng triệu object/ngày, chi phí KMS request tăng vọt. Giải pháp một dòng cấu hình?
Xem đáp án
Bật S3 Bucket Keys — S3 dùng một bucket-level key trung gian, giảm số call
GenerateDataKey/Decrypttới KMS tới ~99% cho workload ghi/đọc dày. Không đổi mô hình bảo mật, chỉ giảm chi phí request. -
Glue job có full quyền S3 nhưng AccessDenied khi đọc bucket mã hóa customer managed key của account khác. Kiểm tra gì?
Xem đáp án
Ba chỗ: (1) IAM policy của role Glue có
kms:Decrypttrên key ARN account kia; (2) key policy bên kia cho phép role/account của bạn; (3) bucket policy cho phép cross-account đọc object. Cross-account = resource policy (key + bucket) VÀ identity policy cùng allow. Quên key policy là lỗi phổ biến nhất. -
Yêu cầu "mọi kết nối tới bucket phải dùng TLS". Enforce thế nào?
Xem đáp án
Bucket policy Deny khi
"aws:SecureTransport": "false":{ "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": ["arn:aws:s3:::bucket", "arn:aws:s3:::bucket/*"], "Condition": { "Bool": { "aws:SecureTransport": "false" } } }Explicit Deny chặn mọi request HTTP thường bất kể quyền khác.
-
Envelope encryption hoạt động thế nào và vì sao S3 không gửi cả object lên KMS để mã hóa?
Xem đáp án
KMS chỉ mã hóa payload nhỏ (≤4KB) và không nên nhận dữ liệu lớn. Envelope encryption: S3 gọi
GenerateDataKey→ nhận data key (bản plain + bản đã mã hóa bằng KMS key); object được mã hóa local bằng data key plain (rồi hủy), bản mã hóa của data key lưu kèm object; khi đọc, S3 gọiDecryptbản mã của data key rồi giải mã object local. Nhanh, scale, key gốc không bao giờ rời KMS.
Bài tập thực hành
- Tạo customer managed key, bật rotation, đọc key policy mặc định
- Đặt default encryption SSE-KMS + Bucket Keys cho bucket curated; upload và xem CloudTrail event KMS
- Thêm policy Deny non-TLS vào một bucket lab và test bằng curl http
- Đọc S3 Bucket Keys
Tài liệu tham khảo chính thức
- AWS KMS concepts
- Protecting data with server-side encryption (S3)
- Key policies in KMS
- Glue security configurations
Tiếp theo: Lake Formation nâng cao - LF-tags và Cross-account