1. Mở đầu

Khi làm việc hay quản lý với AWS, bạn bắt buộc phải nắm được cách tính quyền cho các tài nguyên trong AWS.

Các quyền trong AWS được quản lý ở các đơn vị sau:

• Organization SCPs (Service Control Policies)
• Resource-based policies
• IAM permission boundaries
• Session policies
• Identity-based policies

Để tính quyền, bạn chỉ cần đơn giản nhớ 3 nguyên tắc sau:

• Nguyên tắc 1: Nếu có Explicit Deny ở bất cứ đâu thì lập tức Deny.
• Nguyên tắc 2: Nếu có AWS Organization SCPs và AWS Organization SCPs có Implicit Deny thì lập tức Deny.
• Nguyên tắc 3: Nếu nguyên tắc 1 và 2 không thoả mãn, thì lấy IAM permission boundaries (nếu có), session policies (nếu có), identity-based policies (dù có hoặc không) giao với nhau rồi hợp với resource-based policies. Kết quả thu được có Allow thì trả về Allow, nếu không thì trả về Deny (Implicit Deny).

Chú ý:

• Explicit Deny nghĩa là có mệnh đề Deny trong bất kỳ đơn vị quản lý quyền nào.
• Implicit Deny nghĩa là đơn vị quản lý quyền không chỉ định gì về tài nguyên đang xét đến.
• Phép giao và hợp nói trên là phép giao và phép hợp trong toán học.
• Phép giao nói trên chỉ thực hiện cho IAM permission boundaries và session policies nếu có tồn tại 2 đơn vị này, nếu không tồn tại 2 đơn vị này thì không cần tính đến chúng.
• Phép giao nói trên luôn thực hiện cho identity-based policies cho dù nó có tồn tại hay không. Nếu không tồn tại thì mặc định là Implicit Deny cho đơn vị này.
• Trong phép giao nói trên thì Implicit Deny giao với Allow sẽ bằng Implicit Deny.
• Trong phép hợp nói trên thì Implicit Deny hợp với Allow sẽ bằng Allow.

Chỉ cần nhớ 3 nguyên tắc trên là bạn đã nắm được cách tính quyền đối với một tài nguyên trong AWS, còn cách tính đi vào cụ thể sẽ như sau:

2. Cách tính quyền trong AWS

Cách tính quyền đối với một tài nguyên được mô tả ở sơ đồ sau:

• Cột 1: Nếu trong các đơn vị quản lý quyền mà có Explicit Deny đối với tài nguyên đang xét tới thì lập tức Deny và không cần tính tiếp.
• Cột 2: Nếu cột 1 không thoả mãn, thì nếu có Organization SCPs và không có mệnh đề Allow đối với tài nguyên đang xét tới thì lập tức Deny, không cần tính tiếp.
• Cột 3: Nếu cột 2 không thoả mãn, thì nếu có Resource-based policies và có mệnh đề Allow đối với tài nguyên đang xét tới thì lập tức Allow, không cần tính tiếp.
• Cột 4: Nếu cột 3 không thoả mãn, thì nếu có IAM permission boundaries và không có mệnh đề Allow đối với tài nguyên đang xét tới thì lập tức Deny, không cần tính tiếp.
• Cột 5: Nếu cột 4 không thoả mãn, thì nếu có Session policies và không có mệnh đề Allow đối với tài nguyên đang xét tới thì lập tức Deny, không cần tính tiếp.
• Cột 6: Nếu cột 5 không thoả mãn, thì:
  • Nếu có Identity-based policies và không có mệnh đề Allow đối với tài nguyên đang xét tới thì lập tức Deny.
  • Nếu có Identity-based policies và có mệnh đề Allow đối với tài nguyên đang xét tới thì lập tức Allow.
  • Nếu không có Identity-based policies đối với tài nguyên đang xét tới thì lập tức Deny (Implicit Deny).

Bạn cũng nên để ý tới một số chú ý sau:

3. Một số chú ý với các đơn vị tính quyền trong AWS

3.1. Chú ý với Organization SCPs

Xem thêm về AWS Organization tại https://blog.daovanhung.com/post/khi-nao-thi-su-dung-aws-organization.

• Các quyền không áp dụng cho master account mà chỉ áp dụng cho member account.
• Khi có thừa kế quyền trong AWS Organization thì quyền cuối cùng của Account chính là giao của các quyền thừa kế và quyền được gán cho OU hoặc Account. Chính vì lý do này, bạn phải Allow ở tất cả các tầng của Account thì account đó mới có quyền.
• AWS Organization SCPs cũng giống như IAM Permission Boundaies chỉ xác định quyền tối đa có thể sử dụng chứ không phải là nơi chỉ định quyền hạn, nếu muốn cho phép sử dụng tài nguyên nào đó bạn phải chỉ định quyền đó ở các đơn vị resource-based policies, session policies hoặc identity-based policies.
• AWS Organization SCPs chỉ áp dụng cho những account nằm trong nó mà không áp dụng cho những account khác. Ví dụ nếu S3 bucket trao quyền cho một cross-account không nằm trong AWS Organization thì SCPs sẽ không áp dụng được cho cross-account này.

3.2. Chú ý với IAM permission boundaries

• IAM Permission Boundaies cũng giống như AWS Organization chỉ xác định quyền tối đa có thể sử dụng chứ không phải là nơi chỉ định quyền hạn, nếu muốn cho phép sử dụng tài nguyên nào đó bạn phải chỉ định quyền đó ở các đơn vị resource-based policies, session policies hoặc identity-based policies.

3.3. Chú ý với Resource-based policies

• Theo nguyên tắc 3, dù IAM permission boundaries, session policies hay identity-based policies không chỉ định gì nhưng Resource-based policies có Allow sẽ cho kết quả là Allow. Nhưng resource-based polices trong AWS KMS lại có một chút đặc biệt. Dưới đây mình giải thích về tính quyền trong AWS KMS:

Giả sử bạn tạo AWS CMK với policy sau:

{
    "Id": "key-consolepolicy-3",
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::11111111111:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allow use of the key",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::22222222222:user/hungdv-kms"
            },
            "Action": [
                "kms:Encrypt"
            ],
            "Resource": "*"
        }
    ]
}

JavaScript

Bạn để ý Statement ở trên có 2 object, object đầu tiên cho phép những thứ sau:

• account 11111111111:root có toàn quyền với CMK này.
• Mọi user nằm trong account 11111111111:root mặc định sẽ không có quyền trực tiếp gì với CMK này nhưng lại có quyền sử dụng IAM permission để cấp quyền sử dụng CMK này (bao gồm cả cấp quyền cho chính mình).

Ví dụ: Alice là một user nằm trong account 11111111111:root thì Alice có thể tạo một iam policy cấp quyền cho mình sử dụng cmk key này.

Object thứ 2 nằm trong Statement trên là user hungdv-kms, user này không trực thuộc account 11111111111:root. Với việc chỉ định Explicit Allow trực tiếp trong cmk policy như trên, hungdv-kms sẽ có quyền sử dụng key này để encrypt.

Nhưng hungdv-kms không thể tạo một IAM policy cấp quyền cho mình sử dụng key này để decrypt.

Nói tóm lại, khi bạn sử dụng KMS AWS thì:

• Nếu bạn Explicit Allow trong chính resource-based policy thì kết quả là Allow.
• Nếu bạn Explicit Allow trong Identity-based policies nhưng bạn không trực thuộc account được phép sử dụng IAM để cấp quyền thì kết quả trả về là Deny.
• Bạn vẫn phải bảo toàn nguyên tắc 1 nêu ở phần đầu, nghĩa là nếu có Explicit Deny trong identity-based policy và user này được cấp quyền sử dụng IAM policy để sử dụng KMS key thì trả về Deny.

Link tham khảo:

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html

Nguồn: Internet

>> Đọc thêm:

KHOÁ HỌC TRUY VẤN VÀ THAO TÁC DỮ LIỆU SQL TỪ CƠ BẢN ĐẾN NÂNG CAO

KHÓA HỌC DATA WAREHOUSE : TỔNG HỢP, CHUẨN HÓA VÀ XÂY DỰNG KHO DỮ LIỆU TRONG DOANH NGHIỆP

KHÓA HỌC DATA MODEL – THIẾT KẾ MÔ HÌNH DỮ LIỆU TRONG DOANH NGHIỆP

LỘ TRÌNH TRỞ THÀNH DATA ENGINEER CHO NGƯỜI MỚI BẮT ĐẦU