Lời nói đầu:
Trong môi trường AWS, để quản lý quyền truy cập giữa các services với nhau người dùng cần thực hiện định nghĩa "văn bản quy định quyền hạn" hay còn gọi là Policy. Policy này được được gắn vào resources có trong môi trường AWS như services, users, một nhóm users, hay "vai trò" - role. Policy quy định "cho phép" và "không cho phép" và thường được viết dưới dạng JSON.
Trong AWS có hỗ trợ 6 loại Policy bao gồm:
- Identity-based policies.
- Resource-based policies.
- Permissions boundaries.
- Organizations SCPs.
- Access Control Lists (ACLs).
- Session policies.
Việc hiểu, định nghĩa đúng Policy giúp cho môi trường AWS hoạt động ổn định, hiệu quả và an toàn. Dưới đây là một số tóm tắt về những loại Policy ở trên và cách viết Policy.
Các loại Policy:
- Identity-based policies : là Policy được gắn vào IAM identities như user, group mà user thuộc về và role. Identity-based policies định nghĩa quyền cho đối tượng thuộc IAM Identities.
- Resouce-based policies : là Policy được định nghĩa trực tiếp hay inline gắn vào services. Có thể lấy ví dụ như S3 Bucket Policy hay IAM Role trusted Policy. Resource-based policies định nghĩa quyền cho chủ thể hay Principal được chỉ định rõ ràng trong Policy. Principal có thể cùng một AWS Account hoặc khác AWS Account. Principal có thể là một trong những loại sau : AWS Account và root user, IAM roles, Role sessions, IAM users, Federated user session, aws services.
- Permissions boundaries : là Policy được định nghĩa với nội dung quy định quyền hạn cao nhất mà Identity-based policies có thể cấp cho IAM identities (user hay roles) mà không định nghĩa "cho phép" hay "không cho phép". Permissions boundaries không định nghĩa quyền hạn cao nhất mà Resouce-based policies cấp cho một entity.
- Organizaions SCPs (AWS Organizations service control policy): được dùng để định nghĩa quyền hạn cao nhất mà cho một account members thuộc về một Organization Unit. SCPs giới hạn quyền hạn có thể cấp bởi Identity-based policies và Resouce-based policies cho entities (users hoặc role) trong một AWS Account nhưng không cấp quyền. (Tham khảo cách setup)
- Acces Control Lists (ACLs) : được sử dụng để cho phép một tài khoản khác truy cập vào resouces được gắn ACL. ACL không định nghĩa quyền hạn cho entities thuộc cùng một account. ACLs khá giống với Resouce-based policies mặc dù nó là một loại Policy nhưng lại không định nghĩa dưới dạng cấu trúc JSON.
- Session policies : được sử dụng cấp quyền hạn tạm thời - trong một thời gian có hạn định. Có thể lấy ví dụ như việc Assume Role hay Switch Role, tạo Credentials tạm thời cho một entity để thực hiện truy cập vào resources mà entity không có quyền truy cập.(Tham khảo cách tạo Assume Role - Switch Role)
Cấu trúc của Policy
Policy được viết dưới dạng cấu trúc JSON, bao gồm thành phần như sau:
{
"Version": "2012-10-17",
"Statement": {
"Sid": "AllowRemoveMfaOnlyIfRecentMfa",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice",
"iam:DeleteVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}",
"Condition": {
"NumericLessThanEquals": {"aws:MultiFactorAuthAge": "3600"}
}
}
}- Version : Phiên bản của Policy theo best practice là phiên bản '2012-10-17'.
- Statement : Nội dung quy định quyền hạn.
- Sid : Statement Id có thể có hoặc không
- Effect : "cho phép" (Allow) hoặc "không cho phép" (Deny)
- Pricipal (Chỉ yêu cầu trong một số trường hợp cụ thể) : nếu tạo Resouce-based policies thì phải chỉ rõ aws account, user, role, hoặc user đã có liên kết tới khi muốn chỉ định "cho phép" hoặc "không cho phép". Nếu tạo IAM Permission Policy để gắn vào user hoặc role thì không phải chỉ định thành phần này.(Tham khảo)
- Action : bao gồm một list các tương tác được "cho phép" và "không được cho phép"
- Resource (Chỉ yêu cầu trong một số trường hợp cụ thể) : nếu tạo Resouce-based policies thì thành phần này không nhất thiết phải được chỉ định. Tuy nhiên, nếu tạo IAM permission Policies cho entities thì cần phải chỉ định. Nếu không được chỉ định thì ngầm định đối tượng được gắn vào chính là Resouce.
- Condition : chỉ định thêm điều kiện quy định chặt chẽ lên Principal, Resouce hay entities, đối tượng được áp dụng Policy. Để xác định Condition mà đối tượng hướng đến có hỗ trợ hay không xin tham khảo tại đây.
Trong trường hợp muốn cấp nhiều quyền khác nhau bằng cách tạo nhiều Statement cho một Policy để cấp cho entities (user hoặc role). Policy được định nghĩa như phía dưới. Trong trường hợp định nghĩa quá nhiều quyền trong một Policy , mục đích sử dụng của Policy có thể bị yếu đi do nội dung của Policy không được tường minh. Nếu cần thiết thì nên tạo nhiều Policy và tổng hợp lại thành Role :
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "FirstStatement",
"Effect": "Allow",
"Action": ["iam:ChangePassword"],
"Resource": "*"
},
{
"Sid": "SecondStatement",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Sid": "ThirdStatement",
"Effect": "Allow",
"Action": [
"s3:List*",
"s3:Get*"
],
"Resource": [
"arn:aws:s3:::confidential-data",
"arn:aws:s3:::confidential-data/*"
],
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}
]
}Kết bài:
Một môi trường AWS khỏe mạnh phải bắt nguồn từ gốc rễ khỏe mạnh, gốc rễ đó bắt nguồn từ chính aws user, role và định nghĩa rằng buộc giữa các service. Hãy nắm chắc cách quản lý IAM cũng như Policy để tự tin hơn trong quản lý môi trường AWS.
Tham khảo thêm về IAM Policy, thành phần của Policy hay toán tử được cung cấp sẵn cho phần Policy Condition và nhiều cài đặt khác tại đây.
Leave a Reply