Mục tiêu bài học
Thiết kế quyền từ nhu cầu công việc, ưu tiên temporary credentials và least privilege.
Bài giảng chi tiết
Bài toán thực tế
Một developer cần đọc object trong một bucket nhưng không được xóa, ghi hoặc truy cập bucket khác. Cấp AdministratorAccess giải quyết nhanh nhưng tạo rủi ro lớn; mục tiêu là đọc policy, cấp đúng action/resource và kiểm chứng quyền bằng một thao tác an toàn.
Đừ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
- Authentication xác định principal; authorization quyết định action trên resource.
- Policy gồm Effect, Action, Resource và có thể có Condition; implicit deny mặc định, explicit deny luôn thắng.
- Group quản lý user theo vai trò; role cấp credential tạm thời cho người hoặc workload.
- Least privilege cần được kiểm tra qua access pattern thực tế, không chỉ nhìn tên policy.
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
Authentication trả lời “bạn là ai”; authorization trả lời “bạn được làm gì”. IAM policy có Effect, Action, Resource và Condition; implicit deny mặc định, explicit deny luôn thắng. Group giúp quản lý theo vai trò; role cấp credential tạm thời cho người/workload; Root không dùng hàng ngày.
Ví dụ giảng viên: phân loại một quyết định cloud
Một request IAM không chỉ có “user có policy hay không”. Hãy lần lượt xác định principal, action, resource, context/condition, identity policy, resource policy, permission boundary và guardrail nếu có. Sau đó áp dụng quy tắc: mặc định deny; allow phù hợp mới mở quyền; explicit deny áp dụng thì thắng allow.
Ví dụ developer chỉ được đọc prefix reports/2026/ trong bucket company-data: policy nên giới hạn s3:GetObject vào ARN của prefix, không cấp s3:* trên *. Nhưng đọc object còn có thể phụ thuộc encryption key, bucket policy, organization SCP và identity thực tế. Vì vậy lab phải kiểm chứng cả một request được phép và một request bị từ chối.
Role phù hợp cho workload vì credential thường là tạm thời và không nằm trong source code. Group phù hợp để gom user theo job function. Root là emergency/billing-level identity, không phải profile cho command hàng ngày.
Thực hành có kiểm soát
Đọc một policy S3 read-only và xác định action/resource. Kiểm tra bằng Policy Simulator hoặc thao tác read-only. Không dùng Resource=* nếu không cần, không tạo Root access key và không commit secret.
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.
- Chỉ ra được action/resource mà policy cho phép.
- Dự đoán đúng kết quả của một request Allow và một request bị implicit/explicit deny.
- Giải thích vì sao EC2 nên dùng role/instance profile thay vì access key trong code.
- Thu hẹp được
Resourcetừ wildcard khi scenario đã biết bucket/prefix cụ thể.
Bẫy đề thi và cách tự kiểm tra
IAM User thường có credential dài hạn; IAM Role là identity assumable. “Least privilege”, “explicit deny overrides allow” và “use role instead of access key in EC2” là các tín hiệu quan trọng.