AWS Shared Responsibility Model

Shared Responsibility Model là nền tảng bảo mật của AWS — định nghĩa rõ AWS chịu trách nhiệm cho cái gì và bạn chịu trách nhiệm cho cái gì. Hiểu sai mô hình này là nguyên nhân phổ biến nhất dẫn đến security incident trong production.

1. Tổng quan

AWS chịu trách nhiệm bảo mật của cloud infrastructure. Bạn chịu trách nhiệm bảo mật trong cloud.

2. Phân chia Trách nhiệm

AWS chịu trách nhiệm — Security OF the Cloud

Lớp	AWS chịu trách nhiệm
Physical security	Data center, access control, cameras, guards
Hardware	Servers, storage, networking equipment
Hypervisor	EC2 isolation giữa các customer
Managed service infra	RDS minor/infra patching, Lambda runtime, DynamoDB internals
Global network	Backbone network, DDoS infrastructure-level
Compliance certs	SOC 2, ISO 27001, PCI DSS (AWS side)

Điều này có nghĩa là gì với bạn

Bạn không cần lo về việc một customer khác trên cùng physical host đọc được memory của EC2 bạn — AWS đảm bảo hypervisor isolation. Nhưng AWS không đảm bảo bạn không bị hack qua SSH port bạn để mở.

Customer chịu trách nhiệm — Security IN the Cloud

Lớp	Bạn chịu trách nhiệm
OS patching	EC2 AMI updates, kernel patches, security fixes
Application security	Code vulnerabilities, dependency updates
IAM	User/role permissions, MFA, access key rotation
Data encryption	Encryption at rest (KMS), in transit (TLS)
Network config	Security Groups, NACLs, VPC routing
Secrets management	API keys, passwords, certificates
Logging & monitoring	CloudTrail, CloudWatch, GuardDuty config
Compliance (your side)	Audit logs, access reviews, policy enforcement

3. Trách nhiệm theo từng Service

Trách nhiệm của customer giảm dần khi lên abstraction level cao hơn.

EC2 — IaaS (Infrastructure as a Service)

AWS quản lý phần cứng, bạn quản lý gần như mọi thứ còn lại:

Lớp	AWS	Customer
Physical host	✅
Hypervisor	✅
Network backbone	✅
AMI / Guest OS		✅ Chọn AMI, patch, update
OS security config		✅ SSH keys, firewall rules
Application		✅ Code, dependencies
Security Groups		✅ Cấu hình inbound/outbound
Data encryption		✅ EBS encryption, TLS
IAM Role cho EC2		✅ Least privilege

Điểm hay bị bỏ qua trên EC2

OS patching: AWS không tự patch EC2. AMI bạn dùng từ 6 tháng trước có thể có hàng chục CVE.
IMDSv2: Phải enforce IMDSv2 để ngăn SSRF attack lấy credentials từ metadata endpoint.
SSM Session Manager: Dùng thay SSH để không cần mở port 22.

RDS — Managed Database

AWS quản lý nhiều hơn, nhưng bạn vẫn chịu trách nhiệm về data và access:

Lớp	AWS	Customer
Physical host	✅
Database engine patching	✅ (minor, auto)	✅ Major version upgrade
Multi-AZ failover	✅
Automated backups	✅ (cơ chế)	✅ Retention period, restore test
Database credentials		✅ Rotate, không hardcode
Security Groups		✅ Chỉ allow app servers, không mở 0.0.0.0/0
Encryption at rest		✅ Bật KMS khi tạo; không thể enable trực tiếp trên DB instance unencrypted đã tồn tại, cần migrate/restore sang instance encrypted nếu bật sau
Encryption in transit		✅ Enforce SSL/TLS connection
IAM DB authentication		✅ Optional nhưng recommended
Data access control		✅ DB user permissions

RDS hay bị nhầm

AWS patch minor versions tự động, nhưng major version upgrade (VD: PostgreSQL 14 → 15) là trách nhiệm của bạn. Nhiều team bỏ qua → chạy DB version EOL, không nhận security patch.

S3 — Object Storage

Lớp	AWS	Customer
Storage infra	✅
11 nines durability	✅
Bucket policy		✅ Public access block
ACL & permissions		✅ Không dùng ACL trừ khi cần
Encryption at rest		✅ Bật SSE-KMS hoặc SSE-S3
Encryption in transit		✅ Enforce HTTPS via bucket policy
Versioning		✅ Bật cho critical buckets
Object logging		✅ S3 Access Logs / CloudTrail
Lifecycle policies		✅ Không để data tích lũy vô thời hạn

S3 Public Bucket — Lỗi 100% thuộc customer

AWS không thể biết bucket của bạn nên public hay private — chỉ bạn mới biết. s3:GetObject allow * với public bucket policy là quyết định của bạn, không phải AWS.

Bật S3 Block Public Access ở account level để prevent accidental exposure.

Lambda — Serverless

AWS quản lý nhiều nhất trong 4 service này:

Lớp	AWS	Customer
Execution environment	✅
Runtime patching (nodejs, python, java...)	✅
Scaling infra	✅
Network isolation	✅
Function code		✅ Application vulnerabilities
IAM Execution Role		✅ Least privilege, không dùng AdministratorAccess
Environment variables (secrets)		✅ Không hardcode secrets, dùng Secrets Manager
Dependencies		✅ Update libraries, scan CVE
VPC config		✅ Nếu cần private resource access
Concurrency limits		✅ Set reserved concurrency để tránh DDoS

4. Use Case Thực Tế

Case 1: EC2 bị hack do không patch OS

Scenario: Production EC2 chạy Ubuntu 20.04 AMI từ 14 tháng trước. Attacker exploit CVE-2023-4911 (Looney Tunables — glibc privilege escalation).

Timeline:
  Oct 2023: CVE-2023-4911 published
  Team: Không có patch management process
  Nov 2023: Attacker exploit → root access → data exfiltration

AWS responsibility: Hypervisor isolation (OK), physical security (OK)
Customer responsibility: ✅ OS patching, AMI updates

Verdict: AWS đảm bảo host bên dưới an toàn. Guest OS là trách nhiệm của bạn.

Fix:

# AWS Systems Manager Patch Manager — tự động patch EC2
aws ssm create-patch-baseline \
  --name "Ubuntu-Security-Baseline" \
  --operating-system UBUNTU \
  --approval-rules '{"PatchRules":[{
    "PatchFilterGroup":{
      "PatchFilters":[{"Key":"PRIORITY","Values":["Required","Important"]}]
    },
    "ApproveAfterDays":7
  }]}'

# Schedule maintenance window để apply patches
aws ssm create-maintenance-window \
  --name "weekly-patching" \
  --schedule "cron(0 2 ? * SUN *)" \
  --duration 4 \
  --cutoff 1 \
  --allow-unassociated-targets false

Case 2: Access Key bị leak lên GitHub

Scenario: Developer push code lên GitHub public repo kèm AWS Access Key trong .env file. Trong vòng 4 phút, bot scan và bắt đầu mine crypto → bill tháng đó $47,000.

AWS responsibility: Detect và notify (AWS đã gửi email cảnh báo)
Customer responsibility: ✅ Secret management, không commit credentials

Verdict: AWS có automated credential exposure detection (scan GitHub, PyPI, npm) và notify, nhưng không thể ngăn bạn hardcode key. Thời gian phản ứng của bạn là yếu tố quyết định.

Fix:

# Ngay lập tức khi phát hiện leak
aws iam delete-access-key --access-key-id AKIAIOSFODNN7EXAMPLE

# Kiểm tra activity từ key đó
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=<user> \
  --start-time 2026-04-01T00:00:00Z

Prevention: Dùng IAM Role thay Access Key. Nếu bắt buộc dùng key, lưu trong AWS Secrets Manager hoặc biến môi trường CI/CD — không bao giờ commit vào code.

5. So sánh theo Service Model

Mức độ trách nhiệm của customer giảm dần từ IaaS → PaaS → Serverless:

Shared Responsibility by Service Model

Tiêu chí	EC2 (IaaS)	RDS / EKS (Managed)	Lambda / S3 (Serverless)
OS patching	✅ Bạn	AWS (partial)	AWS
Runtime update	✅ Bạn	AWS	AWS
Scaling infra	✅ Bạn	AWS	AWS
IAM & Permissions	✅ Bạn	✅ Bạn	✅ Bạn
Data encryption	✅ Bạn	✅ Bạn	✅ Bạn
Network config	✅ Bạn	✅ Bạn	✅ Bạn (partial)
App security	✅ Bạn	✅ Bạn	✅ Bạn
Secrets mgmt	✅ Bạn	✅ Bạn	✅ Bạn

Serverless không có nghĩa là "no responsibility"

Lambda loại bỏ trách nhiệm OS patching — nhưng bạn vẫn phải lo về:

IAM execution role (least privilege)
Vulnerable dependencies trong deployment package
Secrets trong environment variables
Input validation để tránh injection

1. Tổng quan​

2. Phân chia Trách nhiệm​

AWS chịu trách nhiệm — Security OF the Cloud​

Customer chịu trách nhiệm — Security IN the Cloud​

3. Trách nhiệm theo từng Service​

EC2 — IaaS (Infrastructure as a Service)​

RDS — Managed Database​

S3 — Object Storage​

Lambda — Serverless​

4. Use Case Thực Tế​

Case 1: EC2 bị hack do không patch OS​

Case 2: Access Key bị leak lên GitHub​

5. So sánh theo Service Model​