Cloud IAM Least Privilege: Thiết Kế Quyền Truy Cập An Toàn Cho AWS, Azure Và GCP

Cloud IAM least privilege là nguyên tắc cấp đúng quyền tối thiểu để một người, workload hoặc service account hoàn thành công việc — không hơn. Trong môi trường cloud, đây không còn là “best practice cho đẹp tài liệu”, mà là lớp phòng thủ quan trọng để giảm blast radius khi token bị lộ, pipeline bị chiếm, hoặc tài khoản admin bị phishing.

Bài viết này đi theo hướng thực chiến cho production/lab: thiết kế role, policy, boundary, break-glass, kiểm toán quyền thừa, ví dụ AWS/Azure/GCP, lệnh kiểm tra, lỗi thường gặp, troubleshooting và checklist nghiệm thu.

1. Least privilege trong cloud khác gì on-prem?

On-prem thường xoay quanh user, group, sudo, ACL hoặc quyền trong ứng dụng. Cloud IAM rộng hơn: một quyền nhỏ có thể tạo tài nguyên, đọc secret, assume role, sửa route, mount disk snapshot hoặc tắt logging. Vì vậy một policy tưởng như vô hại có thể mở đường leo thang đặc quyền.

Ba câu hỏi cần trả lời trước khi cấp quyền:

Ai hoặc cái gì cần quyền? Human user, CI/CD runner, VM, container, Lambda/Function hay third-party tool?
Cần làm hành động gì? Read-only, deploy, rotate secret, restart service, tạo snapshot?
Phạm vi ở đâu? Account/subscription/project nào, region nào, resource tag nào, thời gian bao lâu?

2. Mô hình thiết kế IAM production

2.1. Tách quyền người dùng và workload

Không dùng access key cá nhân để chạy automation. Người dùng nên đăng nhập qua SSO/MFA và assume role tạm thời. Workload nên dùng instance profile, managed identity hoặc service account gắn trực tiếp vào runtime.

2.2. Deny by default, allow có điều kiện

Chỉ cấp quyền allow khi có nhu cầu rõ. Khi có thể, thêm điều kiện theo tag, resource prefix, source IP, MFA, organization/project hoặc thời gian.

2.3. Role theo nhiệm vụ, không theo chức danh mơ hồ

Thay vì “cloud-admin”, hãy dùng role cụ thể: billing-viewer, eks-deployer, backup-operator, incident-readonly. Role càng rõ, review càng dễ.

3. Ví dụ AWS IAM: policy có scope theo bucket

Policy dưới đây cho phép đọc danh sách bucket cụ thể và đọc object trong prefix reports/:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::company-prod-data",
      "Condition": {"StringLike": {"s3:prefix": ["reports/*"]}}
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::company-prod-data/reports/*"
    }
  ]
}

Kiểm tra caller hiện tại:

aws sts get-caller-identity
aws iam simulate-principal-policy   --policy-source-arn arn:aws:iam::123456789012:role/report-reader   --action-names s3:GetObject s3:DeleteObject   --resource-arns arn:aws:s3:::company-prod-data/reports/test.csv

Output mong muốn: s3:GetObject được allowed, s3:DeleteObject bị implicitDeny.

4. Ví dụ Azure RBAC: dùng built-in role trước khi custom role

Azure có nhiều built-in role đủ dùng: Reader, Monitoring Reader, Backup Operator, Contributor theo resource group. Hạn chế cấp Owner/Contributor ở subscription root.

az account show
az role assignment list --assignee user@company.com --all -o table
az role assignment create   --assignee user@company.com   --role "Monitoring Reader"   --scope /subscriptions/<sub-id>/resourceGroups/rg-prod-web

Nếu cần custom role, chỉ thêm action tối thiểu. Đừng copy Contributor rồi xóa vài quyền cho có.

5. Ví dụ Google Cloud IAM: ưu tiên predefined role hẹp

Trong GCP, tránh cấp roles/editor ở project. Dùng predefined role hẹp hoặc custom role khi cần.

gcloud auth list
gcloud projects get-iam-policy my-prod-project --format=json   | jq '.bindings[] | select(.role|test("owner|editor"))'
gcloud projects add-iam-policy-binding my-prod-project   --member="serviceAccount:backup@my-prod-project.iam.gserviceaccount.com"   --role="roles/storage.objectViewer"

Với service account, kiểm tra key tĩnh:

gcloud iam service-accounts keys list   --iam-account backup@my-prod-project.iam.gserviceaccount.com

Nếu có thể, thay key file bằng Workload Identity Federation hoặc metadata identity của runtime.

6. Break-glass account: có nhưng phải bị khóa chặt

Production vẫn cần tài khoản khẩn cấp khi SSO lỗi hoặc incident nghiêm trọng. Nhưng break-glass không được dùng hằng ngày.

Bật MFA phần cứng hoặc phương thức mạnh nhất có thể.
Lưu credential trong vault có quy trình phê duyệt.
Alert ngay khi đăng nhập hoặc assume role.
Review log sau mỗi lần dùng.
Đổi secret/rotate credential sau incident.

7. Audit quyền thừa và đường leo thang

Quyền nguy hiểm không chỉ là admin. Một số quyền có thể leo thang:

Tạo/sửa IAM policy hoặc gán role.
Pass role cho compute/serverless.
Đọc secret manager, parameter store, key vault.
Tạo access key hoặc service account key.
Sửa CI/CD pipeline hoặc image registry.
Tắt audit log, sửa bucket log hoặc xóa trail.

Lịch audit đề xuất: quyền admin hằng tuần, quyền production hằng tháng, service account/key hằng tháng, external vendor hằng quý.

8. Troubleshooting lỗi IAM thường gặp

8.1. “AccessDenied” nhưng policy có allow

Kiểm tra explicit deny, permission boundary, service control policy, conditional access, resource policy và KMS/key policy. Trong AWS, một bucket policy deny có thể chặn dù identity policy allow.

8.2. Role đúng nhưng sai scope

Azure/GCP rất hay lỗi do gán role ở resource group/project khác. Luôn in ra subscription/project hiện tại trước khi debug.

8.3. Token cache cũ

CLI có thể giữ credential cũ. Hãy logout/login lại hoặc refresh token:

aws sts get-caller-identity
az account clear && az login
gcloud auth revoke && gcloud auth login

8.4. Service account key bị lộ

Disable key ngay, rotate secret liên quan, kiểm tra audit log theo thời gian key bị lộ và thay bằng identity federation nếu có thể.

9. Checklist nghiệm thu Cloud IAM least privilege

Mọi human user dùng SSO/MFA, không dùng access key dài hạn cho việc thường ngày.
Workload dùng role/managed identity/service account gắn runtime, không hardcode secret.
Không có Owner/Administrator rộng nếu không có lý do và thời hạn.
Policy giới hạn action, resource, condition theo tag/prefix/scope phù hợp.
Break-glass account có MFA, alert và quy trình review.
Audit log IAM được bật, không cho role vận hành tắt log.
Đã kiểm tra quyền nguy hiểm: pass role, create key, attach policy, read secret.
Có lịch review quyền định kỳ và owner cho từng role.
Có test positive/negative: quyền cần dùng chạy được, quyền ngoài phạm vi bị deny.

10. Bài lab cuối bài

Chọn một cloud sandbox và thực hành:

Tạo một bucket/storage container chỉ dành cho báo cáo.
Tạo role chỉ đọc đúng prefix hoặc resource group/project nhỏ.
Chạy CLI để xác minh read thành công và delete bị từ chối.
Bật audit log rồi thử một thao tác denied để xem log.
Tạo checklist review quyền cho team của bạn.

Hoàn thành lab này giúp bạn biến least privilege từ khẩu hiệu thành quy trình kiểm chứng được.

Kết luận

Cloud IAM least privilege là nền tảng của bảo mật cloud hiện đại. Hãy thiết kế quyền theo nhiệm vụ, scope nhỏ, credential tạm thời, logging đầy đủ và review định kỳ. Khi quyền bị cấp thừa, sự cố nhỏ có thể thành incident lớn; khi quyền được thiết kế đúng, bạn giảm đáng kể blast radius mà vẫn giữ được tốc độ vận hành.