</>Học Dev
Bài học

Tuần 7 - Ngày 1: Encryption với KMS — at-rest và in-transit

Tuần 7 – Ngày 1

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ọnKey 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-KMSKMS 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 Keysnhư trênGiảm mạnh số call KMS (chi phí) cho bucket ghi nhiều
DSSE-KMSKMS, mã hóa 2 lớpYêu cầu compliance đặc biệt
SSE-CKhách gửi key theo từng requestTự quản key, hiếm dùng
Client-sideMã hóa trước khi uploadZero-trust với AWS, tự lo toàn bộ
  • Enforce: bucket policy từ chối PutObject thiếu header s3: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

ServiceAt-restIn-transit
S3SSE-S3/KMS (trên)TLS; bucket policy aws:SecureTransport: false → Deny
RedshiftKMS khi tạo cluster/namespaceTLS (require_ssl)
GlueSecurity configuration: S3/CloudWatch/bookmark encryptionTLS; JDBC SSL
Kinesis/FirehoseServer-side encryption với KMSTLS
MSKKMS trên EBSTLS broker-client + in-cluster
DynamoDBLuôn mã hóa (AWS owned/managed/customer key)TLS
EMRSecurity configuration: EBS/local disk + S3 (EMRFS)TLS giữa node
OpenSearchKMSTLS + 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

  1. 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/GenerateDataKey theo 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.

  2. 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/Decrypt tớ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.

  3. 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 Gluekms:Decrypt trê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.

  4. 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.

  5. 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ọi Decrypt bả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


Tiếp theo: Lake Formation nâng cao - LF-tags và Cross-account