Mục tiêu bài học
Xác định AWS và khách hàng chịu trách nhiệm gì theo loại dịch vụ, không dùng “AWS chịu hết” như câu trả lời.
Bài giảng chi tiết
Bài toán thực tế
Một team cho rằng dùng RDS nghĩa là AWS chịu trách nhiệm toàn bộ database, còn dùng S3 thì bucket mặc định an toàn tuyệt đối. Bài học này sửa cách nghĩ “managed = không cần cấu hình” bằng cách buộc người học xác định ai kiểm soát từng lớp.
Đừ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
- Security of the cloud là trách nhiệm AWS đối với data center, hardware, network vật lý và virtualization.
- Security in the cloud là trách nhiệm khách hàng đối với identity, data, access policy và cấu hình dịch vụ.
- Trách nhiệm thay đổi theo abstraction: EC2 còn Guest OS, RDS giảm OS operation, S3 vẫn cần bucket/access control.
- Shared Responsibility không phải một ranh giới cố định; phải đọc theo dịch vụ và control đang dùng.
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
AWS chịu security of the cloud: data center, phần cứng, mạng vật lý và lớp ảo hóa. Khách hàng chịu security in the cloud: dữ liệu, danh tính, quyền và phần mềm mình kiểm soát. Trách nhiệm thay đổi theo abstraction; vá Guest OS EC2 là khách hàng, bảo vệ hardware là AWS, bucket policy vẫn là khách hàng.
Ví dụ giảng viên: phân loại một quyết định cloud
Shared Responsibility là câu hỏi về ownership, không phải câu “AWS chịu security còn customer chịu data” học thuộc. Hãy hỏi: thành phần nào đang được kiểm soát bởi ai, và control nào chứng minh nó an toàn?
Ví dụ với yêu cầu “database được mã hóa”: AWS vận hành hardware và managed database platform; customer phải chọn encryption option, quản lý key/permission theo dịch vụ, phân loại dữ liệu và kiểm tra application có quyền truy cập đúng. Với EC2, customer còn phải patch Guest OS và cấu hình host firewall. Với S3, AWS bảo vệ hạ tầng object storage nhưng customer vẫn phải quyết định bucket policy, Block Public Access, encryption, lifecycle và ai được đọc object.
Failure drill: tạo ba phát biểu “AWS chịu hết”, “customer chịu hết”, “shared theo service”. Sửa mỗi phát biểu thành câu có điều kiện: dịch vụ nào, lớp nào, control nào, evidence nào. Đây là cách tránh chọn đáp án tuyệt đối trong CLF-C02.
Thực hành có kiểm soát
Lập bảng EC2/RDS/S3 với ba cột AWS, khách hàng và cùng chịu trách nhiệm. Đặt patching, IAM, physical security, data classification vào đúng cột và giải thích bằng câu “ai kiểm soát phần này?”.
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.
- Phân loại đúng Guest OS patching trên EC2 là trách nhiệm khách hàng.
- Phân biệt physical security của AWS với bucket policy của khách hàng.
- Nêu được ít nhất một phần shared responsibility khi dùng managed database.
- Tự sửa một scenario “AWS chịu hết” thành câu trả lời có điều kiện theo service.
Bẫy đề thi và cách tự kiểm tra
AWS bảo vệ infrastructure, không tự biết dữ liệu nào được public. Managed service giảm phần vận hành nhưng không loại bỏ IAM, encryption, network configuration và data responsibility.