AWS IAM least privilege cho production AWS an toàn, dễ audit

AWS IAM least privilege là nguyên tắc cấp quyền tối thiểu cần thiết để một người dùng, dịch vụ hoặc workload hoàn thành đúng nhiệm vụ, không hơn. Trong môi trường production trên AWS, chỉ một policy quá rộng như AdministratorAccess hoặc s3:* gắn sai chỗ cũng có thể biến một lỗi ứng dụng nhỏ thành sự cố bảo mật nghiêm trọng.

Bài viết này đi theo hướng thực chiến: bắt đầu từ mô hình IAM, cách thiết kế role/policy, ví dụ lệnh AWS CLI, kiểm thử quyền, audit bằng IAM Access Analyzer và CloudTrail, rồi kết thúc bằng checklist nghiệm thu trước khi áp dụng vào production.

Vì sao AWS IAM least privilege quan trọng trong production?

Trong cloud, identity gần như là perimeter mới. Máy chủ EC2, Lambda function, pipeline CI/CD, tài khoản người vận hành và workload Kubernetes đều có thể gọi API AWS. Nếu quyền bị cấp dư, attacker không cần exploit kernel hay network phức tạp; họ chỉ cần lấy được credential và gọi API hợp lệ.

AWS IAM least privilege giúp giới hạn blast radius. Khi credential bị lộ, tác hại chỉ nằm trong phạm vi quyền thật sự cần thiết. Với sysadmin hoặc cloud engineer, đây là lớp phòng thủ nền tảng trước khi nói đến WAF, EDR hay SIEM.

Các khái niệm IAM cần nắm trước khi thiết kế quyền

Principal, action, resource và condition

Principal: ai hoặc cái gì được phép thực hiện hành động, ví dụ IAM user, role, AWS service hoặc federated identity.
Action: API được phép gọi, ví dụ s3:GetObject, ec2:DescribeInstances, logs:PutLogEvents.
Resource: tài nguyên bị tác động, ví dụ bucket S3, secret, log group, KMS key.
Condition: điều kiện bổ sung như IP nguồn, MFA, tag, VPC endpoint hoặc thời gian.

Identity-based policy và resource-based policy

Identity-based policy gắn vào user, group hoặc role. Resource-based policy gắn trực tiếp lên tài nguyên như S3 bucket policy, KMS key policy, SQS queue policy. Trong production, hai loại policy này phải được review cùng nhau, vì chỉ nhìn một phía rất dễ bỏ sót đường truy cập ngoài ý muốn.

Quy trình thiết kế AWS IAM least privilege theo từng bước

Bước 1: mô tả workload và hành vi cần thiết

Đừng bắt đầu bằng việc viết JSON policy. Hãy bắt đầu bằng bảng hành vi:

Dịch vụ nào cần truy cập?
Cần đọc, ghi, xóa hay chỉ liệt kê?
Tài nguyên cụ thể là gì?
Có cần gọi cross-account không?
Có cần giới hạn theo tag, region, VPC endpoint hoặc environment không?

Ví dụ: một ứng dụng backend chỉ cần đọc object cấu hình từ bucket prod-app-config và ghi log vào CloudWatch Logs. Nó không cần xóa object, tạo bucket, đọc toàn bộ S3 account hay sửa IAM.

Bước 2: bắt đầu bằng policy hẹp, không dùng wildcard rộng

Policy mẫu cho workload chỉ đọc một prefix trong S3:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOnlyAppConfigPrefix",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::prod-app-config/backend/*"
    },
    {
      "Sid": "ListOnlyBackendPrefix",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::prod-app-config",
      "Condition": {
        "StringLike": {
          "s3:prefix": "backend/*"
        }
      }
    }
  ]
}

Điểm quan trọng: s3:GetObject dùng ARN object, còn s3:ListBucket dùng ARN bucket. Đây là lỗi rất thường gặp khi viết policy S3.

Bước 3: tạo managed policy và role bằng AWS CLI

Lưu policy vào file app-config-read-policy.json, sau đó tạo policy:

aws iam create-policy   --policy-name ProdBackendReadAppConfig   --policy-document file://app-config-read-policy.json

Output mẫu:

{
  "Policy": {
    "PolicyName": "ProdBackendReadAppConfig",
    "Arn": "arn:aws:iam::123456789012:policy/ProdBackendReadAppConfig",
    "DefaultVersionId": "v1"
  }
}

Tạo trust policy cho EC2 hoặc workload phù hợp. Ví dụ EC2 assume role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

aws iam create-role   --role-name ProdBackendRole   --assume-role-policy-document file://trust-ec2.json

aws iam attach-role-policy   --role-name ProdBackendRole   --policy-arn arn:aws:iam::123456789012:policy/ProdBackendReadAppConfig

Kiểm thử quyền trước khi đưa vào production

Dùng IAM Policy Simulator

Policy Simulator giúp kiểm tra action nào được allow hoặc deny trước khi rollout. Với AWS CLI, có thể dùng:

aws iam simulate-principal-policy   --policy-source-arn arn:aws:iam::123456789012:role/ProdBackendRole   --action-names s3:GetObject s3:DeleteObject s3:ListBucket   --resource-arns arn:aws:s3:::prod-app-config/backend/app.yaml arn:aws:s3:::prod-app-config

Kỳ vọng:

s3:GetObject trên prefix backend/*: allowed.
s3:DeleteObject: implicitDeny.
s3:ListBucket ngoài prefix được phép: denied hoặc không trả dữ liệu mong muốn.

Kiểm tra thực tế bằng assumed role

Assume role rồi thử hành vi được phép và không được phép:

aws sts assume-role   --role-arn arn:aws:iam::123456789012:role/ProdBackendRole   --role-session-name least-privilege-test

Sau khi export credential tạm thời, kiểm tra:

aws s3 cp s3://prod-app-config/backend/app.yaml -
aws s3 rm s3://prod-app-config/backend/app.yaml

Lệnh đọc phải thành công. Lệnh xóa phải thất bại với thông báo gần giống:

An error occurred (AccessDenied) when calling the DeleteObject operation: Access Denied

Audit và tinh chỉnh quyền bằng CloudTrail, Access Analyzer

Dùng CloudTrail để hiểu API thật sự được gọi

CloudTrail ghi lại các API call. Sau vài ngày chạy thử trong staging hoặc canary production, bạn có thể xem workload thật sự gọi API nào. Nếu policy cho phép s3:PutObject nhưng CloudTrail không bao giờ ghi nhận hành vi ghi, hãy xem lại nhu cầu.

Dùng IAM Access Analyzer để phát hiện quyền dư

AWS IAM Access Analyzer hỗ trợ phân tích policy và phát hiện truy cập public/cross-account. Với policy mới, nên chạy validate:

aws accessanalyzer validate-policy   --policy-document file://app-config-read-policy.json   --policy-type IDENTITY_POLICY

Nếu có finding mức ERROR hoặc SECURITY_WARNING, cần xử lý trước khi merge vào production.

Lỗi thường gặp khi triển khai AWS IAM least privilege

Dùng * quá rộng: Action: "s3:*" hoặc Resource: "*" làm mất ý nghĩa least privilege.
Quên quyền phụ thuộc: một số thao tác cần nhiều action liên quan, ví dụ đọc secret có thể cần thêm kms:Decrypt nếu Secret Manager dùng customer managed KMS key.
Không tách môi trường: role staging có quyền production hoặc dùng chung bucket giữa dev/prod.
Trust policy quá mở: cho phép principal không rõ ràng assume role.
Không kiểm tra resource policy: bucket policy hoặc KMS key policy có thể mở quyền dù identity policy nhìn có vẻ chặt.

Troubleshooting nhanh khi gặp AccessDenied

1. Xác định caller identity

aws sts get-caller-identity

Lệnh này cho biết credential hiện tại thuộc account, user hoặc role nào. Rất nhiều sự cố xảy ra đơn giản vì shell đang dùng nhầm profile.

2. Kiểm tra action và resource ARN

Đọc kỹ lỗi để biết action bị deny. Với S3, phân biệt ARN bucket và ARN object. Với KMS, kiểm tra key policy. Với Lambda, kiểm tra cả execution role và resource policy nếu có invoke từ dịch vụ khác.

3. Tìm explicit deny

Explicit deny từ SCP, permission boundary, session policy hoặc resource policy sẽ thắng allow. Nếu IAM policy đã allow nhưng vẫn bị deny, hãy kiểm tra AWS Organizations SCP và permission boundary.

Checklist nghiệm thu trước khi áp dụng

Không còn policy managed kiểu AdministratorAccess cho workload production.
Mỗi role có owner, mô tả mục đích và môi trường rõ ràng.
Policy giới hạn action, resource và condition phù hợp.
Trust policy chỉ cho principal cần thiết assume role.
Đã kiểm thử allow/deny bằng Policy Simulator hoặc test thực tế.
CloudTrail bật đầy đủ cho account và region liên quan.
Access Analyzer không còn finding nghiêm trọng.
Có lịch review quyền định kỳ, tối thiểu mỗi quý hoặc sau thay đổi lớn.

Lab thực hành: chuyển một role quyền rộng sang least privilege

Chọn một workload staging đang dùng policy rộng.
Bật CloudTrail và thu thập API call trong 3-7 ngày.
Liệt kê action thực tế, tài nguyên thực tế và điều kiện cần có.
Viết policy hẹp theo từng nhóm hành vi.
Chạy aws accessanalyzer validate-policy.
Gắn policy mới vào role staging, chạy regression test.
Thử các hành vi không được phép như xóa object, đọc secret khác namespace, gọi API IAM.
Sau khi đạt, rollout production theo canary và theo dõi CloudTrail/alert.

Tài liệu chính thống nên đọc thêm

Kết luận

AWS IAM least privilege không phải là một việc làm một lần rồi quên. Nó là quy trình liên tục: hiểu workload, cấp quyền hẹp, kiểm thử, quan sát log, audit và tinh chỉnh. Khi làm đều đặn, đội vận hành sẽ giảm đáng kể rủi ro credential leak, thao tác nhầm và escalation ngoài ý muốn trong môi trường AWS production.