Tổng quan phân quyền trên AWS Identity

and Access Management

AWS hiện là nhà cung cấp dịch vụ cloud đi tiên phong và đứng đầu thị
trường cloud, với hơn 200 service.

AWS cloud đã tạo nên một hệ sinh thái khổng lồ đáp ứng hầu hết các nhu
cầu điện toán đám mây, với một hệ thống sinh thái lớn yêu cầu khả năng
quản trị chặt chẽ, linh hoạt và bảo mật.

Để tránh các mất mát không đáng có, việc quản trị truy cập và phân
quyền là tất yếu và vô cùng quan trọng khi sử dụng cloud. Bài viết
mong muốn đem lại cái nhìn tổng quan cách AWS Identity and Access
Management quản lý phân quyên trên các tài nguyên.

1. Khái niệm phân quyền

Phân quyền là việc tạo ra một tập hợp các chính sách quyết định
"một chủ thể được phép thực thi một hành động trên một tài nguyên hay
không"

 Chính sách - policy : là đơn vị cơ bản và quan trong nhất trong quá
trính phân quyền, trong aws một hầu hết policy có định dạng json và
có các syntax và cấu trúc được aws quy đinh củ thể.

 Chủ thể - principal bao gồm : user, role, federated user, application.
Chủ thể gửi các request yêu cầu thực hiện một action trên resouce.
  Hành động - action là hành động thực hiện trên tài nguyên được
định nghĩa trong từng service .
 Tài nguyên - resource là một đối tượng trong service.

Với aws việc phân quyền và định danh nhằm kiểm soát các truy cập vào tài
nguyên từ các định danh (IAM Identity) trong cùng tài khoản, đảm bảo việc
các service làm việc với nhau an toàn và kiểm xoát các truy cập tài nguyên
từ ngoài tài khoản. Bao gồm các truy cập định danh bên ngoài tài khoản và
truy cập không định danh tới các tài nguyên công khai.

Tham khảo thêm :

https://docs.aws.amazon.com/service-authorization/latest/reference/
reference_policies_actions-resources-contextkeys.html

2. Chính sách - policy

Một policy được định nghĩa theo cấu trúc json và bao gồm các thuộc tính
cơ bản:
 Statement: Mỗi một policy đều có ít nhất một statement, statement
dùng để chỉ định action nào được thực thi và tài nguyên nào được
truy cập. Statement gồm các thành phần
o Sid: Là một chuỗi uniq dùng để nhận dạng statement

o Effect: Chỉ định các actions được liệt kê là Alllow/Deny

o Action: Liệt kê các hành động bạn muốn thực thi
(ec2:CreateImage, ec2:CreateNetworkAcl...)
o Principal: Là tài khoản/người dùng/role được cho phép hoặc bị
từ chối truy cập vào tài nguyên AWS
o Resource: Chính là tài nguyên AWS mà bạn muốn áp dụng
những actions bên trên
o Condition: Chỉ định các điều kiện bắt buộc phải tuân theo khi
áp dụng policy này dựa trên các condition key được định nghĩa
theo từng resouce, action (service-specific condition key ) và
dựa trên các contex key (global condition key ).

Ví dụ :
Link tham khảo:
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_grammar.html

Mỗi policy là tập hợp của các các statement và mỗi statement quy định
việc DENY/ALLOW một hoặc nhiều action được thực hiện trên một hoặc
nhiều resource. Policy aws có thể chỉ định chủ thể có hiệu lực với quy tắc
trên statement với Principal dựa trên cơ chế Resource-base policy (chỉ áp
dụng với một số resource )
3. IAM Identity

 AWS account root user: root user được tạo khi bạn tạo một
account, nó có quyền cao nhất trong account, không thể bị xoá và
chỉnh sửa phân quyền. Root user chỉ nên được sử dụng các tác vụ
riêng biệt. Aws khuyên cáo không nên sử dụng root user tạo các
credentials và không nên sử dụng aws account root user cho các
hoạt động thông thường.
 IAM users là một chủ thể được người dùng tạo trong aws và được sử
dụng để đại diện cho một người hoặc một service tương tác với AWS.
IAM user có thể được xác thực bằng name và password hoặc sử
dụng với aws api, aws cli bằng các credentials được tạo.

 IAM groups là một đại diện cho tập hợp các user. Được sử dụng để
phân quyên cho một nhóm các user có chung một nhóm các policy.
Một group được phân quyên giống như các user dựa trên các policy
được gắn và các user trong group cũng sẽ được áp dụng chung các
chính sách trong policy. Nhớ đó dễ dàng quản lý phân quyên cho
từng nhóm người dùng trong aws account.

 IAM roles tương tự như các user được gắn các policy để phân
quyền nhưng thay vì đại diên cho 1 người . Role có thể được sử
dụng để ủy quyền cho một principal (không thể chỉ định *). Đặc
điểm:
o Không có long-term credentials hoặc name password cho
phép bạn truy cập aws
o Được sử dụng để cấp quyền tạm thời cho các application,
user, service trước đó không có quyền truy cập
o Iam role có thể cấp quyền truy cập tạm thời cho các
service quyền truy cập resource của 1 service khác (aws
service role) hoặc uỷ quyền truy cập cho 1 service khác
(aws service-linked role, AWS service role for an EC2
instance)
o Cơ chế trust police là 1 resource-based police cho phép
chỉnh định principal được phép sử dụng role.
 Temporary credentials in IAM là một giấy phép tạm thời được sử
dụng cho các tác vụ ngắn hạn, các giấy phép tạm thời có quyền truy
cập dựa trên IAM Identity được chỉ định (user hoặc role).
4. Chính sách và phân quyền trong IAM
Trong aws người dùng kiểm soát phân quyền bằng cách tạo ra chính
sách - policies và gắn chúng với IAM identities (users, groups of users, or
roles) hoặc AWS resources. Tập hợp các policy có hiệu lực trên chủ thể
và trên resouce quyết định kết quả phân quyền ALLOW hoặc DENY

Policy Type
Để đáp ứng các nhu cấu phân quyền cho các định danh, các resource, kiểm
soát quyền của các định danh (IAM Identity) và xác đinh quyền truy cập của
các account trong Origanizations. Aws sử dụng nhiều policy type cho từng
mục đích khác nhau.

 Identity-based policies – json policy permission các chính sách dựa

trên danh tính được sử dụng để phân quyền cho các Identity (user,
role, group). Có định dạng JSON và được quản lý theo 3 nhóm:
o Managed policies là các chính sách độc lập bạn có thể sử dụng
cho nhiều Identity. Được chia thành 2 loại
 AWS managed policies: các chính sách do aws tạo và
quản lý.
 Customer managed policies: các chính sách do người
dùng tạo và quản lý
o Inline policies các chính sách do người dùng tạo và chị được
gắn với một Identity duy nhất và sẽ bị xoá khi identity bị xoá.
o Hướng dẫn sử dụng indentity-based policy

 Resource-based policies – json policy permission là một inline policy

được gắn với 1 resource, một resource-based policies quy định
các principal được áp dụng chính sách và sử dụng condition để kiểm
soát truy cập. Nó cho phép các principal ngoài account sử dụng các
tài nguyên trong account. Đặc điểm:
 o Khi resource-based policy chỉ định 1 principal là một principal
của một account khác, principal vẫn cần được cấp phép sử
dụng các resource bởi Identity-based policy của account sở
hữa principal (tham khảo ví dụ)
o IAM có 1 loại resource-based policy là trust role policy được
gắn cho IAM role cho phép role chỉ định Trusted entities và
thực hiện cross-account access.
o IAM roles và resource-based policy vẫn có sự khác biệt trong
cơ chế ủy quyền cross-account access (tham khảo thêm)

 Permissions boundaries – json policy permission là một managed

policy được sử dụng cho role và user nhằm hạn chế giới hạn phân
quyền tối đa các chủ thể có thể thực hiện.Đặc điểm:
o Các user hoặc role không thể thực hiện các yêu cầu vi phạm
policies mà Permissions boundaries quy định.
o Resource-based policy không bị giới hạn bởi Permissions
boundaries
o Permissions boundaries không cấp quyền cho chủ thể

 Organizations SCPs – json policy permission Sử dụng AWS

Organizations service control policy (SCP) để định nghĩa phân quyền
tối đa cho các account members của
một organization hoặc organization unit (ou). Tương tự Permissions
boundaries không cấp quyền cho chủ thể. Đặc điểm:
o Không ảnh hưởng tới các principal ngoài account trong
resource-based policy
o Không hạn chế quyền của user và role trong management
account
o SCP áp dụng cho tất cả user, role bao gồm các root user thuộc
các account được thêm vào aws Organizations hoặc ou
o SCP không áp dụng cho các service-linked role
  Access control lists (ACLs) được sử dụng để cho phép thực hiện
cross-account access, acl chỉ định các principals của các account khác
để kiểm soát truy cập. ACL không sử dụng đinh dạng JSON policy, acl
không thể sử dụng với các principals trong cùng account.
 Session policies – json policy permission được sử dụng cho các
temporary cendentials hoặc feradated user nhằm cấp quyền truy
cập cho các định danh tạm thời dựa trên Identity-based policy được
áp dụng. Có thể hiểu nếu một temporary cendentials không được
cấp quyền bởi một session policy sẽ bị từ chối hành động hoặc nếu
request được chấp thuận bởi session policy nhưng không được cấp
quyền bởi Identity-based policy sẽ bị từ chối.

Nếu chia tách theo mục đính sử dụng ta sẽ có: Identity-based policy,
Session policy, Resource-based policy là các chính sách cấp quyền. Với
Permission boundaries, Organization SCPs là các chính sách hạn chế
quyền truy cập.

5. Policy evaluation logic

Khi một principal thực hiện một request thông qua aws api, aws cli, aws
management console một request được gửi đến aws và được sử lý theo
các bước:

1. Authentication - principal được xác thực danh tính. Trong mốt số

trường hợp với 1 số service như s3 cho truy cập từ các anonymous
user không cần xác thực danh tính.
2. Processing the request context - aws sử lý thông tin trong request
và xác định các policy được áp dụng
3. Evaluating policies within a single account - aws tổng hợp tất cả
policy theo policy type, điều này ảnh hưởng đến thứ tự ưa tiên trong
đánh giá policy
 4. Determining whether a request is allowed or denied within an
account - aws sẽ xác định request được cho phép hay từ chối dựa
trên policy đã được tổng hợp và request context

Quy trình đánh giá request ALLOW/DENY trong account

Được aws chia thành 6 bước đánh giá dựa trên phân loại policy:

1. Deny evaluation bất cứ Deny statement nào trong policy từ bất cư

policy type được tổng hợp và đánh giá đầu tiên. Nếu Deny statement
được áp dụng, request sẽ bị từ chối

2. Oraganizations policy Nếu principal thuộc một account được áp

dụng Organization policy từ SCP, request phải tuân thủ policy từ
Oraganization policy, nếu không sẽ bị từ chối . Ngay cả khi request
đến từ aws account root user vẫn sẽ phải được cấp quyền từ
Oraganization policy.
3. Resource-based policy Nếu policy từ Resource-based policy chấp
thuận request, request sẽ được chấp thuận ngay lập tức.

4. IAM permission boundaries nếu principal được áp dụng permission

boundaries và request không được cấp phép bởi các policy trong IAM
permission boundaries, request sẽ bị từ chối.

5. session policy nếu principal là một temporary credentials nó phải

tuân thủ session policy nếu không sẽ bị từ chối truy cập.

6. Identity-based policy nếu principal không được áp dụng resource-

based policy thì nó bắt buộc phải được cấp quyền bởi Identity-based
policy để được thực hiện.
Quy trình đánh giá request ALLOW/DENY trong cross-
account

Việc truy cập tài nguyên bằng 1 định danh thuộc một account khác yêu cầu
sự cho phép từ một resource-based policy được chỉ định bởi resource cần
truy cập.

Quá trình đánh giá yêu cầu các bước:

1. Tổng hợp Identity-based policy được áp dụng với principal từ

Trusted AccountA và xác nhận quyền truy cập từ các policy được áp
dụng.
 2. Nếu request được chấp thuận trong Trusted AccountA sẽ được gửi
đến Trusting AccountB, sẽ tiếp tục được xác nhận bởi các resource-
based policy được áp dụng nên resource. Nếu được chấp thuận
request sẽ được thực hiện.

6. Authorization strategy
Với aws IAM cho phép bạn thực hiện 2 chiến lược phân quyền Attribute-
based access control (ABAC) và role-based access control (RBAC). Trong đó:

 RBAC phân quyền dựa trên vai trò là cách thức phân quyền theo đó
bạn tạo ra các phân quyên theo vai trò người sử dụng (Dev,
Database admin,...). Trong IAM, việc này tương đương với tạo ra các
policy và gắn với các định danh. Điều này giúp cấp tối thiểu các đặc
quyền cho người sử dụng
 ABAC phân quyền dưa trên thuộc tính theo đó các chính sách định
nghĩa phân quyền dựa trên thuộc tính của tài nguyên và của người
sử dụng. Từ đó đạt được sự linh hoạt và kiểm soát dễ dàng các phân
quyền. Trong IAM ABAC được sử dụng dựa trên các tag được gắn với
các resource và Identity để dễ dàng phân quyền theo nhóm các tài
nguyên và nhóm định danh.