Lộ trình
Amazon Web ServicesCơ bảnTuần 3: Bảo mật, Giám sát & Quản lýBài 15 / 30

Ngày 15: Bảo mật nâng cao — IAM Roles và KMS

Thời lượng: 45 phút
Mục tiêu: 2 nhiệm vụ chính
Tiến độ lộ trình
aws-clf-c02ngày 15
hoàn thành15 / 30 bài
Bối cảnh bài học

Dùng temporary credentials cho workload và hiểu KMS quản lý key, không thay thế IAM.

đọc hiểuthực hànhcheckpoint
Bài giảng hôm nay

Học hiểu, rồi mới thực hành

Dùng temporary credentials cho workload và hiểu KMS quản lý key, không thay thế IAM.

Bắt đầu đọc bài giảng

Nhiệm vụ bài học hôm nay

  • Tìm hiểu MFA, IAM Policy, Security Groups
  • Thực hành tạo policy giới hạn quyền theo nguyên tắc least privilege
Instructor walkthrough

Bài giảng chi tiết: từ bài toán đến bằng chứng

Scenario xuyên suốt

Một EC2 cần đọc S3 và một database cần mã hóa; developer đang định đặt access key trong code và dùng một KMS key không có policy rõ ràng. Bài học tách IAM role, trust policy, permission policy và KMS boundary.

01Đọc bài toán

Xác định actor, workload, constraint và trạng thái cuối cần đạt.

02Vẽ luồng / boundary

Chỉ ra request, dependency, identity và failure domain trước khi chọn công cụ.

03Chọn và thực hành

Thay đổi nhỏ nhất trong lab cô lập; command nào cũng phải nói rõ nó kiểm tra điều gì.

04Kiểm chứng / recovery

Đối chiếu trạng thái thực tế, tạo một failure variant và ghi cách hoàn tác.

Cách nối lý thuyết với thực tế
  • Trust policy xác định principal được assume role; permissions policy xác định action/resource được phép.
  • Instance profile đưa role vào EC2 để nhận credential tạm thời.
  • KMS quản lý key cryptographic; quyền dùng key còn phụ thuộc key policy/IAM và encryption context.
  • Encryption at rest không thay encryption in transit, IAM hoặc data classification.

Mục tiêu bài học

Dùng temporary credentials cho workload và hiểu KMS quản lý key, không thay thế IAM.

Bài giảng chi tiết

Bài toán thực tế

Một EC2 cần đọc S3 và một database cần mã hóa; developer đang định đặt access key trong code và dùng một KMS key không có policy rõ ràng. Bài học tách IAM role, trust policy, permission policy và KMS boundary.

Đừng học nội dung này như một danh sách tên dịch vụ. Hãy đi theo chuỗi: requirement → khái niệm → quyết định → bằng chứng. Một câu trả lời tốt phải nói được vì sao lựa chọn phù hợp, phương án gần nhất bị loại ở đâu, và kiểm tra nào chứng minh lựa chọn đó hoạt động.

Khái niệm được giải thích theo scenario

  1. Trust policy xác định principal được assume role; permissions policy xác định action/resource được phép.
  2. Instance profile đưa role vào EC2 để nhận credential tạm thời.
  3. KMS quản lý key cryptographic; quyền dùng key còn phụ thuộc key policy/IAM và encryption context.
  4. Encryption at rest không thay encryption in transit, IAM hoặc data classification.

Ví dụ khi gặp một scenario mới, hãy thay các từ khóa trong đề bằng một hệ thống cụ thể: ai là người dùng, dữ liệu đi qua đâu, thành phần nào có thể lỗi, quyền nào cần có và điều gì phải được quan sát. Cách làm này giúp phân biệt các đáp án gần đúng thay vì chọn theo trí nhớ tên service.

flowchart LR
  A[Scenario / requirement] --> B[Concept and boundary]
  B --> C[Service or control choice]
  C --> D[Evidence and trade-off]
  D --> E[Failure variant]

Khái niệm cốt lõi

EC2 và Lambda nên nhận quyền qua IAM role: trust policy xác định ai được assume, permissions policy xác định được làm gì. KMS quản lý cryptographic key và quyền encrypt/decrypt; encryption at rest không tự đảm bảo encryption in transit. Key policy và IAM policy cùng ảnh hưởng request.

Ví dụ giảng viên: phân loại một quyết định cloud

Role có hai câu hỏi: ai được assume và sau khi assume được làm gì. KMS có thêm câu hỏi ai được dùng key cho encryption context nào, key policy/IAM policy cho phép ra sao và key lifecycle được quản lý thế nào. Vì vậy “EC2 có role” chưa chứng minh EC2 đọc được object encrypted.

Vẽ flow EC2 → instance profile → STS credentials → S3 object → KMS decrypt. Tạo negative case: role được GetObject nhưng key policy không cho decrypt; positive case: cả object policy và key permission đúng. Không sửa bằng cách mở key cho mọi principal.

Thực hành có kiểm soát

Đọc một role policy và tách principal trong trust policy khỏi action/resource trong permissions policy. Kiểm tra encryption của S3/EBS/RDS trong tài khoản lab. Không tạo KMS key nếu chưa hiểu rotation, key policy và cleanup.

Expected state và recovery

Trước khi thực hành, ghi rõ target/account/region, trạng thái hiện tại và output mong đợi. Sau thao tác, kiểm chứng bằng trạng thái thực tế hoặc command phù hợp; nếu kết quả sai, giữ lại evidence, quay về thay đổi nhỏ nhất và cleanup đúng owner. Không coi exit code 0 hoặc thông báo “success” là bằng chứng duy nhất.

  1. Phân biệt trust policy và permissions policy.
  2. Giải thích vì sao access key trong code/AMI là anti-pattern.
  3. Nêu được KMS key policy và IAM policy cùng ảnh hưởng request.
  4. Phân biệt encryption at rest với in transit.

Bẫy đề thi và cách tự kiểm tra

Role là identity assumable, không phải user dùng chung. Cách cấp quyền EC2 đọc S3 đúng là instance profile/role, không nhúng access key vào code hoặc AMI.

Terminal reference

Command list và cách dùng

Chạy từng lệnh theo đúng thứ tự. Trước các lệnh có thể tạo hoặc thay đổi tài nguyên, hãy kiểm tra profile, account và region.

Commands · read-only checkpoints
aws sts get-caller-identity --profile study
aws iam list-roles --profile study --max-items 10 --output table
aws kms list-keys --profile study --query "Keys[0:5].KeyId" --output table
Hands-on lab

Thực hành theo scenario

Đọc một trust policy và permissions policy mẫu, đánh dấu principal/action/resource/condition. Lập flow EC2 → instance profile → temporary credentials → S3. Kiểm tra encryption metadata của resource có sẵn ở chế độ read-only; không tạo key hoặc lưu secret thật.

Evidence checkpoint

Kiểm chứng kết quả

Không coi lệnh chạy thành công là đủ. Hãy đối chiếu output với trạng thái mong đợi:

  • Phân biệt trust policy và permissions policy.
  • Giải thích vì sao access key trong code/AMI là anti-pattern.
  • Nêu được KMS key policy và IAM policy cùng ảnh hưởng request.
  • Phân biệt encryption at rest với in transit.
Transfer to exam / production

Bẫy thường gặp và trade-off

Role là identity assumable, không phải user dùng chung. Cách cấp quyền EC2 đọc S3 đúng là instance profile/role, không nhúng access key vào code hoặc AMI.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Cách phù hợp để EC2 đọc S3 mà không lưu access key trong code?

Kết thúc bài

Checklist trước khi sang Ngày 2