Hiểu các loại policy trong IAM: Khi nào nên sử dụng

Tác giả: Matt Luttrell, Anshu Bathla, Jay Goradia, và Josh Joy
Ngày phát hành: 23 MAR 2026
Chuyên mục: Intermediate (200), Security, Identity, & Compliance

Ngày 3 tháng 6 năm 2022: Ngày xuất bản gốc của bài viết này. Bài viết đã được cập nhật để bổ sung các loại chính sách IAM mới: Chính sách kiểm soát tài nguyên.

Bạn quản lý quyền truy cập trong AWS bằng cách tạo các chính sách và đính kèm chúng vào các thực thể (principals) của AWS Identity and Access Management (IAM) (các vai trò, người dùng hoặc nhóm người dùng) hoặc các tài nguyên AWS. AWS đánh giá các chính sách này khi một thực thể IAM đưa ra yêu cầu, chẳng hạn như tải một đối tượng lên một S3 bucket của Amazon Simple Storage Service (Amazon S3). Các quyền trong chính sách sẽ xác định xem yêu cầu có được phép hay bị từ chối. Mặc dù IAM hoạt động chủ yếu ở cấp độ tài khoản AWS riêng lẻ, các tổ chức có nhiều tài khoản AWS có thể mở rộng các kiểm soát truy cập này thông qua AWS Organizations, cung cấp các loại chính sách bổ sung hoạt động cùng với IAM để thực thi các tiêu chuẩn quản trị và bảo mật trên toàn bộ cấu trúc tổ chức của họ. Bằng cách sử dụng AWS Organizations, bạn có thể nhóm các tài khoản trong môi trường đa tài khoản vào các đơn vị tổ chức (OUs), áp dụng các kiểm soát dựa trên chính sách trên các nhóm này.

Trong bài đăng trên blog này, bạn sẽ tìm hiểu cách chọn các loại chính sách phù hợp với yêu cầu bảo mật của mình và xác định nhóm nào nên sở hữu và quản lý từng chính sách. Bạn sẽ khám phá bảy loại chính sách—bao gồm chính sách dựa trên danh tính, chính sách dựa trên tài nguyên, ranh giới quyền hạn, chính sách kiểm soát dịch vụ (SCPs) và chính sách kiểm soát tài nguyên (RCPs)—thông qua một kịch bản thực tế liên quan đến nhiều tài khoản và nhóm AWS.

Các loại chính sách khác nhau và thời điểm sử dụng

AWS có nhiều loại chính sách khác nhau mang lại cho bạn sự linh hoạt mạnh mẽ, và điều quan trọng là phải biết cách thức và thời điểm sử dụng từng loại chính sách. Điều quan trọng nữa là bạn phải hiểu cách cấu trúc quyền sở hữu chính sách IAM để tránh một nhóm tập trung trở thành nút thắt cổ chai. Quyền sở hữu chính sách rõ ràng có thể cho phép các nhóm của bạn di chuyển nhanh hơn, đồng thời vẫn nằm trong các hàng rào bảo vệ an toàn được xác định tập trung.

Tổng quan về chính sách kiểm soát dịch vụ (Service control policies)

Chính sách kiểm soát dịch vụ (SCPs) là một tính năng của AWS Organizations. AWS Organizations là một dịch vụ để nhóm và quản lý tập trung các tài khoản AWS mà doanh nghiệp của bạn sở hữu. SCPs là các chính sách chỉ định quyền tối đa cho một tổ chức, đơn vị tổ chức (OU) hoặc một tài khoản cá nhân. Một SCP có thể giới hạn quyền cho các thực thể trong các tài khoản thành viên, bao gồm cả người dùng gốc của tài khoản AWS.

SCPs được thiết kế để sử dụng làm hàng rào bảo vệ cấp độ thô (coarse-grained guardrails), và chúng không trực tiếp cấp quyền truy cập. Chức năng chính của SCPs là thực thi bất biến bảo mật (security invariants) trên các tài khoản AWS và OUs trong một tổ chức. Bất biến bảo mật là các mục tiêu kiểm soát hoặc cấu hình mà bạn áp dụng cho nhiều tài khoản, OUs hoặc toàn bộ tổ chức được quản lý bởi AWS Organizations. Ví dụ, bạn có thể sử dụng một SCP để ngăn các tài khoản thành viên rời khỏi tổ chức của bạn hoặc để thực thi rằng các tài nguyên AWS chỉ có thể được triển khai đến các AWS Region nhất định.

Tổng quan về chính sách kiểm soát tài nguyên (Resource control policies)

Chính sách kiểm soát tài nguyên (RCPs) là một tính năng của AWS Organizations để quản lý quyền tập trung. RCPs đặt quyền tối đa có sẵn cho các tài nguyên trên toàn tổ chức của bạn. RCPs giúp đảm bảo rằng các tài nguyên trong tài khoản của bạn tuân thủ các nguyên tắc kiểm soát truy cập của tổ chức bạn.

RCPs thường được sử dụng để thực thi các kiểm soát chu vi dữ liệu (data perimeter controls) nhằm ngăn chặn việc chia sẻ dữ liệu ngẫu nhiên ra bên ngoài tổ chức của bạn và để kiểm soát việc chia sẻ tài nguyên cũng như các mẫu truy cập liên tài khoản (cross-account access patterns) một cách tập trung. Bạn cũng có thể sử dụng RCPs để triển khai các kiểm soát bảo mật cho các tài nguyên nhạy cảm trên các tài khoản của tổ chức bạn và để thêm một lớp bảo vệ bổ sung cho các tài nguyên như S3 bucket lưu trữ dữ liệu bí mật.

Lưu ý: SCPs là các kiểm soát tập trung vào thực thể (principal-centric controls) chỉ định dịch vụ nào mà người dùng IAM và vai trò IAM của bạn có thể truy cập, tài nguyên nào họ có thể truy cập hoặc các điều kiện mà họ có thể đưa ra yêu cầu (ví dụ: từ các Region hoặc mạng cụ thể). Mặt khác, RCPs là các kiểm soát tập trung vào tài nguyên (resource-centric controls) có thể hạn chế quyền truy cập vào tài nguyên của bạn để chúng chỉ có thể được truy cập bởi các danh tính thuộc tổ chức của bạn hoặc chỉ định các điều kiện mà các danh tính bên ngoài tổ chức của bạn có thể truy cập tài nguyên của bạn. Để hiểu sự khác biệt và các trường hợp sử dụng của SCPs và RCPs, hãy xem Các trường hợp sử dụng chung cho SCPs và RCPs.

Tổng quan về ranh giới quyền hạn (Permissions boundaries)

Ranh giới quyền hạn (Permissions boundaries) là một tính năng IAM nâng cao, trong đó bạn đặt quyền tối đa mà một chính sách dựa trên danh tính có thể cấp cho một thực thể IAM. Khi bạn đặt ranh giới quyền hạn cho một thực thể, thực thể đó chỉ có thể thực hiện các hành động được cho phép bởi cả chính sách dựa trên danh tính và ranh giới quyền hạn của nó.

Ranh giới quyền hạn là một loại chính sách dựa trên danh tính không trực tiếp cấp quyền truy cập. Thay vào đó, giống như một SCP, ranh giới quyền hạn hoạt động như một hàng rào bảo vệ cho các thực thể IAM của bạn, cho phép bạn đặt các kiểm soát truy cập cấp độ thô. Ranh giới quyền hạn thường được sử dụng để ủy quyền việc tạo các thực thể IAM. Ủy quyền cho phép các cá nhân khác trong tài khoản của bạn tạo các thực thể IAM mới, nhưng giới hạn các quyền có thể được cấp cho các thực thể IAM mới.

Tổng quan về chính sách dựa trên danh tính (Identity-based policies)

Chính sách dựa trên danh tính (Identity-based policies) là các tài liệu chính sách mà bạn đính kèm vào một thực thể (các vai trò, người dùng và nhóm người dùng) để kiểm soát những hành động mà một thực thể có thể thực hiện, trên những tài nguyên nào và trong những điều kiện nào. Chính sách dựa trên danh tính có thể được phân loại thêm thành chính sách do AWS quản lý, chính sách do khách hàng quản lý và chính sách nội tuyến. Chính sách do AWS quản lý là các chính sách dựa trên danh tính có thể tái sử dụng được tạo và quản lý bởi AWS. Bạn có thể sử dụng các chính sách do AWS quản lý làm điểm khởi đầu để xây dựng các chính sách dựa trên danh tính của riêng mình, cụ thể cho tổ chức của bạn. Chính sách do khách hàng quản lý là các chính sách dựa trên danh tính có thể tái sử dụng có thể được đính kèm vào nhiều danh tính. Chính sách do khách hàng quản lý hữu ích khi bạn có nhiều thực thể với các yêu cầu truy cập giống hệt nhau. Chính sách nội tuyến là các chính sách dựa trên danh tính được đính kèm vào một thực thể duy nhất. Sử dụng chính sách nội tuyến khi bạn muốn tạo các quyền hạn tối thiểu (least-privilege permissions) cụ thể cho một thực thể cụ thể.

Bạn sẽ có nhiều chính sách dựa trên danh tính trong tài khoản AWS của mình được sử dụng để cấp quyền truy cập trong các kịch bản như truy cập của con người, truy cập của ứng dụng, tải công việc học máy và đường ống triển khai. Các chính sách này nên được cấp độ chi tiết (fine-grained). Bạn sử dụng các chính sách này để trực tiếp áp dụng các quyền hạn tối thiểu cho các thực thể IAM của mình. Bạn nên viết các chính sách với các quyền cho nhiệm vụ cụ thể mà thực thể cần hoàn thành.

Tổng quan về chính sách dựa trên tài nguyên (Resource-based policies)

Chính sách dựa trên tài nguyên (Resource-based policies) là các tài liệu chính sách mà bạn đính kèm vào một tài nguyên như S3 bucket. Các chính sách này cấp cho thực thể được chỉ định quyền thực hiện các hành động cụ thể trên tài nguyên đó và xác định trong những điều kiện nào quyền này được áp dụng. Chính sách dựa trên tài nguyên là các chính sách nội tuyến. Để biết danh sách các dịch vụ AWS hỗ trợ chính sách dựa trên tài nguyên, hãy xem Các dịch vụ AWS hoạt động với IAM.

Chính sách dựa trên tài nguyên là tùy chọn cho nhiều tải công việc không trải rộng trên nhiều tài khoản AWS. Quyền truy cập cấp độ chi tiết trong một tài khoản AWS duy nhất thường được cấp bằng chính sách dựa trên danh tính. Các khóa AWS Key Management Service (AWS KMS) và chính sách tin cậy của vai trò IAM là hai ngoại lệ, và cả hai tài nguyên này phải có chính sách dựa trên tài nguyên ngay cả khi thực thể và khóa KMS hoặc vai trò IAM nằm trong cùng một tài khoản. Các vai trò IAM và khóa KMS hoạt động theo cách này như một lớp bảo vệ bổ sung yêu cầu chủ sở hữu tài nguyên (khóa hoặc vai trò) phải rõ ràng cho phép hoặc từ chối các thực thể sử dụng tài nguyên. Đối với các tài nguyên khác hỗ trợ chính sách dựa trên tài nguyên, đây là một số ví dụ về nơi chúng được sử dụng phổ biến nhất:

Cấp quyền truy cập liên tài khoản vào tài nguyên AWS của bạn.
Cấp quyền truy cập dịch vụ AWS vào tài nguyên của bạn khi dịch vụ AWS sử dụng nguyên tắc dịch vụ AWS. Ví dụ, khi sử dụng AWS CloudTrail, bạn phải rõ ràng cấp quyền cho nguyên tắc dịch vụ CloudTrail để ghi tệp vào S3 bucket của Amazon.
Áp dụng các hàng rào bảo vệ truy cập rộng rãi cho các tài nguyên AWS của bạn. Bạn có thể xem một số ví dụ trong bài đăng trên blog IAM giúp bạn dễ dàng quản lý quyền cho các dịch vụ AWS truy cập tài nguyên của bạn.
Áp dụng một lớp bảo vệ bổ sung cho các tài nguyên lưu trữ dữ liệu nhạy cảm, chẳng hạn như bí mật của AWS Secrets Manager hoặc S3 bucket với dữ liệu nhạy cảm. Bạn có thể sử dụng chính sách dựa trên tài nguyên để từ chối quyền truy cập vào các thực thể IAM không nên có quyền truy cập vào dữ liệu nhạy cảm, ngay cả khi được cấp quyền truy cập bằng chính sách dựa trên danh tính. Một từ chối rõ ràng trong chính sách IAM luôn ghi đè một cho phép.

Cách triển khai các loại chính sách khác nhau

Trong phần này, chúng tôi sẽ hướng dẫn bạn qua một ví dụ về thiết kế bao gồm tất cả bốn loại chính sách được giải thích trong bài viết này.

Ví dụ sau đây cho thấy một ứng dụng chạy trên một phiên bản Amazon Elastic Compute Cloud (Amazon EC2) và cần đọc và ghi tệp vào một S3 bucket trong cùng một tài khoản. Ứng dụng cũng đọc (nhưng không ghi) tệp từ một S3 bucket trong một tài khoản khác. Công ty trong ví dụ này, Example Corp, sử dụng chiến lược đa tài khoản, và mỗi ứng dụng có tài khoản AWS riêng. Kiến trúc của ứng dụng được thể hiện trong Hình 1.

Hình 1: Kiến trúc ứng dụng mẫu cần truy cập các S3 bucket trong hai tài khoản AWS khác nhau

Có ba nhóm tham gia vào ví dụ này: Nhóm Cloud Trung tâm (Central Cloud Team), Nhóm Ứng dụng (Application Team) và Nhóm Data Lake (Data Lake Team). Nhóm Cloud Trung tâm chịu trách nhiệm về bảo mật và quản trị tổng thể của môi trường AWS trên tất cả các tài khoản AWS tại Example Corp. Nhóm Ứng dụng chịu trách nhiệm xây dựng, triển khai và chạy ứng dụng của họ trong tài khoản ứng dụng (111111111111) mà họ sở hữu và quản lý. Tương tự, Nhóm Data Lake sở hữu và quản lý tài khoản data lake (222222222222) lưu trữ một data lake tại Example Corp.

Với những thông tin cơ bản đó, chúng tôi sẽ hướng dẫn bạn qua một triển khai cho từng trong bốn loại chính sách và bao gồm giải thích về nhóm nào chúng tôi đề xuất nên sở hữu từng chính sách. Chủ sở hữu chính sách là nhóm chịu trách nhiệm tạo và duy trì chính sách.

Chính sách kiểm soát dịch vụ (Service control policies)

Nhóm Cloud Trung tâm sở hữu việc triển khai các kiểm soát bảo mật nên áp dụng rộng rãi cho tất cả các tài khoản AWS của Example Corp. Tại Example Corp, Nhóm Cloud Trung tâm có hai yêu cầu bảo mật mà họ muốn áp dụng cho tất cả các tài khoản trong tổ chức của họ:

Các cuộc gọi AWS API phải được mã hóa trong quá trình truyền để duy trì các phương pháp bảo mật tốt nhất.
Các tài khoản không thể tự rời khỏi tổ chức.

Nhóm Cloud Trung tâm chọn triển khai các bất biến bảo mật này bằng cách sử dụng SCPs và áp dụng các SCPs vào gốc của tổ chức. Tuyên bố đầu tiên trong Chính sách 1 từ chối tất cả các yêu cầu không được gửi bằng SSL (TLS). Tuyên bố thứ hai trong Chính sách 1 ngăn tài khoản rời khỏi tổ chức.

Đây chỉ là một tập hợp con của các tuyên bố SCP mà Example Corp sử dụng. Example Corp sử dụng chiến lược danh sách từ chối, và cũng phải có một tuyên bố đi kèm với Effect là Allow ở mọi cấp độ của tổ chức mà không được hiển thị trong SCP trong Chính sách 1.

Chính sách 1: SCP đính kèm vào gốc tổ chức AWS Organizations

			
{
        "Id": "ServiceControlPolicy",
        "Version": "2012-10-17",
        "Statement": [{
            "Sid": "DenyIfRequestIsNotUsingSSL",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:SecureTransport": "false"
                }
            }
    },
    {
        "Sid": "PreventLeavingTheOrganization",
        "Effect": "Deny",
        "Action": "organizations:LeaveOrganization",
        "Resource": "*"
    }]
}

		

Chính sách kiểm soát tài nguyên (Resource control policies)

Nhóm Cloud Trung tâm cũng có ba yêu cầu bảo mật bổ sung cho việc triển khai tài nguyên Amazon S3 vào các tài khoản.

Yêu cầu phiên bản TLS tối thiểu là 1.2 cho quyền truy cập S3 bucket.
Bắt buộc mã hóa các đối tượng S3 bằng AWS Key Management Service (AWS KMS).
Từ chối quyền truy cập S3 từ tài khoản AWS bên ngoài tổ chức được quản lý bởi AWS Organizations.

Nhóm Cloud Trung tâm đính kèm các RCPs vào gốc của tổ chức, theo cùng một cách tiếp cận được sử dụng cho SCPs, để chính sách áp dụng trên tất cả các tài khoản.
Chính sách 2 thực thi ba kiểm soát trên các S3 bucket trong tổ chức. Tuyên bố đầu tiên yêu cầu TLS 1.2 cho dữ liệu đang truyền (data-in-transit). Tuyên bố thứ hai yêu cầu mã hóa AWS KMS cho dữ liệu tĩnh (data-at-rest). Tuyên bố thứ ba hạn chế quyền truy cập S3 bucket đối với các thực thể từ các tài khoản trong tổ chức (được xác định bởi example-corp-organization-id), chặn quyền truy cập từ các tài khoản bên ngoài.

Chính sách 2: RCP đính kèm vào gốc tổ chức để thực thi chu vi dữ liệu

			
{
  "Id": "ResourceControlPolicy",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceS3TLSVersion",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "NumericLessThan": {
          "s3:TlsVersion": [
            "1.2"
          ]
        }
      }
    },
    {
      "Sid": "EnforceKMSEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": "true"
        }
      }
    },
    {
      "Sid": "DenyAllExternalS3Access",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalOrgID": "example-corp-organization-id"
        }
      }
    }
  ]
}

		

Chính sách ranh giới quyền hạn (Permissions boundary policies)

Nhóm Cloud Trung tâm muốn đảm bảo rằng họ không trở thành nút thắt cổ chai cho Nhóm Ứng dụng. Họ muốn cho phép Nhóm Ứng dụng triển khai các thực thể và chính sách IAM của riêng họ cho các ứng dụng của họ. Nhóm Cloud Trung tâm cũng muốn đảm bảo rằng bất kỳ thực thể nào được tạo bởi Nhóm Ứng dụng chỉ có thể sử dụng các AWS API mà Nhóm Cloud Trung tâm đã phê duyệt.

Tại Example Corp, Nhóm Ứng dụng triển khai vào môi trường AWS sản xuất của họ thông qua một đường ống tích hợp liên tục/triển khai liên tục (CI/CD). Bản thân đường ống có quyền truy cập rộng rãi để tạo các tài nguyên AWS cần thiết để chạy ứng dụng, bao gồm cả quyền tạo các vai trò IAM bổ sung. Nhóm Cloud Trung tâm triển khai một kiểm soát yêu cầu tất cả các vai trò IAM được tạo bởi đường ống phải có một ranh giới quyền hạn được đính kèm. Điều này cho phép đường ống tạo các vai trò IAM bổ sung, nhưng giới hạn các quyền mà các vai trò IAM mới được tạo có thể có theo những gì được cho phép bởi ranh giới quyền hạn. Sự ủy quyền này tạo ra sự cân bằng cho Nhóm Cloud Trung tâm. Họ có thể tránh trở thành nút thắt cổ chai cho Nhóm Ứng dụng bằng cách cho phép Nhóm Ứng dụng tạo các vai trò và chính sách IAM của riêng họ, đồng thời đảm bảo rằng các vai trò và chính sách IAM đó không có quá nhiều đặc quyền.

Một ví dụ về chính sách ranh giới quyền hạn mà Nhóm Cloud Trung tâm đính kèm vào các vai trò IAM được tạo bởi đường ống CI/CD được hiển thị bên dưới. Chính sách ranh giới quyền hạn này có thể được quản lý tập trung và đính kèm vào các vai trò IAM được tạo bởi các đường ống khác tại Example Corp. Chính sách mô tả các quyền tối đa có thể có mà các vai trò bổ sung được tạo bởi Nhóm Ứng dụng được phép có, và nó giới hạn các quyền đó đối với một số hành động truy cập dữ liệu Amazon S3 và Amazon Simple Queue Service (Amazon SQS). Việc một chính sách ranh giới quyền hạn bao gồm các hành động truy cập dữ liệu là phổ biến khi được sử dụng để ủy quyền tạo vai trò. Điều này là do hầu hết các ứng dụng chỉ cần quyền đọc và ghi dữ liệu (ví dụ: ghi một đối tượng vào S3 bucket hoặc đọc một tin nhắn từ hàng đợi SQS) và chỉ đôi khi cần quyền sửa đổi cơ sở hạ tầng (ví dụ: tạo S3 bucket hoặc xóa hàng đợi SQS). Khi Example Corp áp dụng các dịch vụ AWS bổ sung, Nhóm Cloud Trung tâm sẽ cập nhật ranh giới quyền hạn này với các hành động từ các dịch vụ đó.

Chính sách 3: Chính sách ranh giới quyền hạn đính kèm vào các vai trò IAM được tạo bởi đường ống CI/CD

			
{
  "Id": "PermissionsBoundaryPolicy",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "sqs:ChangeMessageVisibility",
        "sqs:DeleteMessage",
        "sqs:ReceiveMessage",
        "sqs:SendMessage",
        "sqs:PurgeQueue",
        "sqs:GetQueueUrl",
        "logs:PutLogEvents"
      ],
      "Resource": "*"
    }
  ]
}

		

Trong phần tiếp theo, bạn sẽ tìm hiểu cách thực thi rằng ranh giới quyền hạn này được đính kèm vào các vai trò IAM được tạo bởi đường ống CI/CD của bạn.

Chính sách dựa trên danh tính (Identity-based policies)

Trong ví dụ này, các nhóm tại Example Corp chỉ được phép sửa đổi môi trường AWS sản xuất thông qua đường ống CI/CD của họ. Quyền ghi vào môi trường sản xuất không được phép theo cách khác. Để hỗ trợ các vai trò khác nhau cần có quyền truy cập vào tài khoản ứng dụng trong Example Corp, ba vai trò IAM cơ bản với chính sách dựa trên danh tính được tạo trong các tài khoản ứng dụng:

Một vai trò để đường ống CI/CD sử dụng để triển khai tài nguyên ứng dụng.
Một vai trò chỉ đọc cho Nhóm Cloud Trung tâm, với quy trình truy cập tạm thời được nâng cao.
Một vai trò chỉ đọc cho các thành viên của Nhóm Ứng dụng.

Cả ba vai trò cơ bản này đều được sở hữu, quản lý và triển khai bởi Nhóm Cloud Trung tâm.

Nhóm Cloud Trung tâm được cấp một vai trò chỉ đọc mặc định (CentralCloudTeamReadonlyRole) cho phép truy cập đọc vào tất cả các tài nguyên trong tài khoản. Điều này được thực hiện bằng cách đính kèm chính sách ReadOnlyAccess do AWS quản lý vào vai trò của Nhóm Cloud Trung tâm. Bạn có thể sử dụng bảng điều khiển IAM để đính kèm chính sách ReadOnlyAccess, cấp quyền truy cập chỉ đọc vào tất cả các dịch vụ. Khi một thành viên của nhóm cần thực hiện một hành động không được bao gồm bởi chính sách này, họ tuân theo một quy trình truy cập tạm thời được nâng cao để đảm bảo rằng quyền truy cập này hợp lệ và được ghi lại.

Một vai trò chỉ đọc cũng được cấp cho các nhà phát triển trong Nhóm Ứng dụng (DeveloperReadOnlyRole) để phân tích và khắc phục sự cố. Tại Example Corp, các nhà phát triển được phép có quyền truy cập chỉ đọc vào Amazon EC2, Amazon S3, Amazon SQS, AWS CloudFormation và Amazon CloudWatch. Yêu cầu của bạn về quyền truy cập chỉ đọc có thể khác. Một số dịch vụ AWS cung cấp các chính sách được quản lý chỉ đọc riêng của họ, và cũng có chính sách ReadOnlyAccess do AWS quản lý đã đề cập trước đó cấp quyền truy cập chỉ đọc vào tất cả các dịch vụ. Để tùy chỉnh quyền truy cập chỉ đọc trong chính sách dựa trên danh tính, bạn có thể sử dụng các chính sách do AWS quản lý làm điểm khởi đầu và giới hạn các hành động đối với các dịch vụ mà tổ chức của bạn sử dụng. Chính sách dựa trên danh tính tùy chỉnh cho vai trò DeveloperReadOnlyRole của Example Corp được hiển thị bên dưới.

Chính sách 4: Chính sách dựa trên danh tính đính kèm vào vai trò chỉ đọc của nhà phát triển để hỗ trợ truy cập của con người và khắc phục sự cố

			
{
  "Id": "DeveloperRoleBaselinePolicy",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudformation:Describe*",
        "cloudformation:Get*",
        "cloudformation:List*",
        "cloudwatch:Describe*",
        "cloudwatch:Get*",
        "cloudwatch:List*",
        "ec2:Describe*",
        "ec2:Get*",
        "ec2:List*",
        "ec2:Search*",
        "s3:Describe*",
        "s3:Get*",
        "s3:List*",
        "sqs:Get*",
        "sqs:List*",
        "logs:Describe*",
        "logs:FilterLogEvents",
        "logs:Get*",
        "logs:List*",
        "logs:StartQuery",
        "logs:StopQuery"
      ],
      "Resource": "*"
    }
  ]
}

		

Vai trò đường ống CI/CD có quyền truy cập rộng rãi vào tài khoản để tạo tài nguyên. Quyền triển khai thông qua đường ống CI/CD nên được kiểm soát và giám sát chặt chẽ. Đường ống CI/CD được phép tạo các vai trò IAM mới để sử dụng với ứng dụng, nhưng các vai trò đó bị giới hạn chỉ trong các hành động được cho phép bởi ranh giới quyền hạn đã thảo luận trước đó. Các vai trò, chính sách và hồ sơ phiên bản EC2 mà đường ống tạo cũng nên được giới hạn trong các đường dẫn vai trò cụ thể. Điều này cho phép bạn thực thi rằng đường ống chỉ có thể sửa đổi các vai trò và chính sách hoặc chuyển vai trò mà nó đã tạo. Điều này giúp ngăn đường ống, và các vai trò được tạo bởi đường ống, nâng cao đặc quyền bằng cách sửa đổi hoặc chuyển một vai trò có đặc quyền cao hơn. Hãy chú ý cẩn thận đến các đường dẫn vai trò và chính sách trong phần Resource của chính sách vai trò đường ống CI/CD sau đây (Chính sách 5). Chính sách vai trò đường ống CI/CD cũng cung cấp một số tuyên bố ví dụ cho phép chuyển và tạo một tập hợp giới hạn các vai trò liên kết dịch vụ (được tạo trong đường dẫn /aws-service-role/). Bạn có thể thêm các vai trò liên kết dịch vụ khác vào các tuyên bố này khi tổ chức của bạn áp dụng các dịch vụ AWS bổ sung.

Chính sách 5: Chính sách dựa trên danh tính đính kèm vào vai trò đường ống CI/CD

			
{
  "Id": "CICDPipelineBaselinePolicy",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "sqs:*",
        "s3:*",
        "cloudwatch:*",
        "cloudformation:*",
        "logs:*",
        "autoscaling:*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "ssm:GetParameter*",
      "Resource": "arn:aws:ssm:*::parameter/aws/service/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateRole",
        "iam:PutRolePolicy",
        "iam:DeleteRolePolicy"
      ],
      "Resource": "arn:aws:iam::111111111111:role/application-roles/*",
      "Condition": {
        "ArnEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::111111111111:policy/PermissionsBoundary"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:AttachRolePolicy",
        "iam:DetachRolePolicy"
      ],
      "Resource": "arn:aws:iam::111111111111:role/application-roles/*",
      "Condition": {
        "ArnEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::111111111111:policy/PermissionsBoundary"
        },
        "ArnLike": {
          "iam:PolicyARN": "arn:aws:iam::111111111111:policy/application-role-policies/*"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:DeleteRole",
        "iam:TagRole",
        "iam:UntagRole",
        "iam:GetRole",
        "iam:GetRolePolicy"
      ],
      "Resource": "arn:aws:iam::111111111111:role/application-roles/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreatePolicy",
        "iam:DeletePolicy",
        "iam:CreatePolicyVersion",
        "iam:DeletePolicyVersion",
        "iam:GetPolicy",
        "iam:TagPolicy",
        "iam:UntagPolicy",
        "iam:SetDefaultPolicyVersion",
        "iam:ListPolicyVersions"
      ],
      "Resource": "arn:aws:iam::111111111111:policy/application-role-policies/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateInstanceProfile",
        "iam:AddRoleToInstanceProfile",
        "iam:RemoveRoleFromInstanceProfile",
        "iam:DeleteInstanceProfile"
      ],
      "Resource": "arn:aws:iam::111111111111:instance-profile/application-instance-profiles/*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": [
        "arn:aws:iam::111111111111:role/application-roles/*",
        "arn:aws:iam::111111111111:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "iam:CreateServiceLinkedRole",
      "Resource": "arn:aws:iam::111111111111:role/aws-service-role/*",
      "Condition": {
        "StringEquals": {
          "iam:AWSServiceName": "autoscaling.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:DeleteServiceLinkedRole",
        "iam:GetServiceLinkedRoleDeletionStatus"
      ],
      "Resource": "arn:aws:iam::111111111111:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:ListRoles",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:GetRole",
      "Resource": [
        "arn:aws:iam::111111111111:role/application-roles/*",
        "arn:aws:iam::111111111111:role/aws-service-role/*"
      ]
    }
  ]
}

		

Ngoài ba vai trò cơ bản với chính sách dựa trên danh tính đã có sẵn mà bạn đã thấy cho đến nay, có một vai trò IAM bổ sung mà Nhóm Ứng dụng tạo bằng cách sử dụng đường ống CI/CD. Đây là vai trò mà ứng dụng chạy trên phiên bản EC2 sẽ sử dụng để lấy và đặt đối tượng từ các S3 bucket trong Hình 1. Quyền sở hữu rõ ràng cho phép Nhóm Ứng dụng tạo chính sách dựa trên danh tính này phù hợp với nhu cầu của họ mà không phải chờ đợi và phụ thuộc vào Nhóm Cloud Trung tâm. Bởi vì đường ống CI/CD chỉ có thể tạo các vai trò có chính sách ranh giới quyền hạn được đính kèm, Chính sách 6 không thể cấp nhiều quyền truy cập hơn chính sách ranh giới quyền hạn cho phép (Chính sách 3).

Nếu bạn so sánh chính sách dựa trên danh tính được đính kèm vào vai trò của phiên bản EC2 (Chính sách 6 bên trái) với chính sách ranh giới quyền hạn đã mô tả trước đó (Chính sách 3 bên phải), bạn có thể thấy rằng các hành động được cho phép bởi vai trò của phiên bản EC2 cũng được cho phép bởi chính sách ranh giới quyền hạn. Các hành động phải được cho phép bởi cả hai chính sách để phiên bản EC2 thực hiện các hành động s3:GetObject và s3:PutObject. Quyền tạo một bucket sẽ bị từ chối ngay cả khi vai trò được đính kèm vào phiên bản EC2 được cấp quyền thực hiện hành động s3:CreateBucket vì hành động s3:CreateBucket vượt quá các quyền được cho phép bởi ranh giới quyền hạn.

Chính sách 6: Chính sách dựa trên danh tính bị ràng buộc bởi ranh giới quyền hạn và đính kèm vào phiên bản EC2 của ứng dụng | Chính sách 3: Chính sách ranh giới quyền hạn đính kèm vào các vai trò IAM được tạo bởi đường ống CI/CD.

			
{
  "Id": "ApplicationRolePolicy",
  "Version": "2012-10-17",
  "Statement": [
	{   
      "Effect": "Allow",    
      "Action": [
         "s3:PutObject",
         "s3:GetObject"
    ],    
    "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET1/*"
  },
{   
      "Effect": "Allow",    
      "Action": [
         "s3:GetObject"
      ],    
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET2/*"
    }
  ]
}

		

Chính sách 3: Chính sách ranh giới quyền hạn đính kèm vào các vai trò IAM được tạo bởi đường ống CI/CD

			
{
  "Id": "PermissionsBoundaryPolicy",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "sqs:ChangeMessageVisibility",
        "sqs:DeleteMessage",
        "sqs:ReceiveMessage",
        "sqs:SendMessage",
        "sqs:PurgeQueue",
        "sqs:GetQueueUrl",
        "logs:PutLogEvents"
      ],
      "Resource": "*"
    }
  ]
}

		

Resource-based policies

Trong ví dụ này, resource-based policy duy nhất cần thiết được gắn vào bucket nằm trong tài khoản bên ngoài tài khoản ứng dụng (DOC-EXAMPLE-BUCKET2 trong tài khoản data lake ở Hình 1).

Để cho phép truy cập trong kịch bản cross-account, cả identity-based policy và resource-based policy đều phải cấp quyền cho cùng một hành động trên bucket Amazon S3.

Chính sách bucket dưới đây chỉ cho phép thực hiện hành động GetObject trên bucket, bất kể role của ứng dụng (ApplicationRole) được cấp những quyền gì từ identity-based policy của nó (Policy 6).

Resource-based policy này thuộc quyền sở hữu của Data Lake Team, đội chịu trách nhiệm quản lý tài khoản data lake (222222222222) cũng như chính policy này (Policy 7).

Cách thiết lập này cho phép Data Lake Team có toàn quyền kiểm soát việc các đội bên ngoài tài khoản AWS của họ có thể truy cập vào bucket S3 như thế nào.

Chính sách 7: Chính sách dựa trên tài nguyên đính kèm vào S3 bucket trong tài khoản data lake bên ngoài (222222222222)

			
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/application-roles/ApplicationRole"
      },
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET2/*"
    }
  ]
}

		

Không cần chính sách dựa trên tài nguyên trên S3 bucket trong tài khoản ứng dụng (DOC-EXAMPLE-BUCKET1 trong Hình 1). Quyền truy cập cho ứng dụng được cấp vào S3 bucket trong tài khoản ứng dụng bằng chính sách dựa trên danh tính. Quyền truy cập có thể được cấp bằng chính sách dựa trên danh tính hoặc chính sách dựa trên tài nguyên khi quyền truy cập nằm trong cùng một tài khoản AWS.

Tổng hợp

Hình 2 cho thấy kiến trúc và bao gồm các chính sách khác nhau cùng với các tài nguyên mà chúng được đính kèm. Bảng sau đây tóm tắt các chính sách IAM khác nhau được triển khai vào môi trường AWS của Example Corp, và chỉ định nhóm nào chịu trách nhiệm cho từng chính sách.

Hình 2: Kiến trúc ứng dụng mẫu với đường ống CI/CD được sử dụng để triển khai cơ sở hạ tầng

Các chính sách được đánh số trong Hình 2 tương ứng với các số chính sách trong bảng sau.

Số chính sách	Mô tả chính sách	Loại chính sách	Chủ sở hữu chính sách	Đính kèm vào
1	Thực thi SSL và ngăn các tài khoản thành viên rời khỏi tổ chức cho tất cả các thực thể trong tổ chức	Chính sách kiểm soát dịch vụ (SCP)	Central Cloud Team	Gốc tổ chức
2	Thực thi TLS 1.2 và mã hóa KMS cho các S3 bucket trên toàn tổ chức	Chính sách kiểm soát tài nguyên (RCP)	Central Cloud Team	Gốc tổ chức
3	Hạn chế quyền tối đa cho các vai trò được tạo bởi đường ống CI/CD	Ranh giới quyền hạn (Permissions boundary)	Central Cloud Team	Tất cả các vai trò được tạo bởi đường ống (ApplicationRole)
4	Chính sách chỉ đọc được giới hạn phạm vi	Chính sách dựa trên danh tính	Central Cloud Team	Vai trò IAM
5	Chính sách đường ống CI/CD	Chính sách dựa trên danh tính	Central Cloud Team	Vai trò IAM
6	Chính sách được ứng dụng đang chạy sử dụng để đọc và ghi vào các S3 bucket	Chính sách dựa trên danh tính	Application Team	trên phiên bản EC2
7	Chính sách bucket trong tài khoản data lake cấp quyền truy cập cho một vai trò trong tài khoản ứng dụng	Chính sách dựa trên tài nguyên	Data Lake Team	S3 Bucket trong tài khoản data lake
8	Chính sách chỉ đọc rộng rãi	Chính sách dựa trên danh tính	Central Cloud Team	Vai trò IAM

Kết luận
Trong bài đăng trên blog này, bạn đã tìm hiểu về bốn loại chính sách khác nhau: chính sách dựa trên danh tính, chính sách dựa trên tài nguyên, chính sách kiểm soát dịch vụ (SCPs), chính sách kiểm soát tài nguyên (RCPs), chính sách ranh giới quyền hạn và chính sách kiểm soát tài nguyên. Bạn đã thấy các ví dụ về các tình huống mà mỗi loại chính sách thường được áp dụng. Sau đó, bạn đã đi qua một ví dụ thực tế mô tả một triển khai sử dụng các loại chính sách này.

Bằng cách triển khai nhiều loại chính sách IAM theo cách tiếp cận phân lớp, bạn có thể đạt được kiểm soát truy cập mạnh mẽ tuân theo nguyên tắc quyền hạn tối thiểu (least privilege) đồng thời cho phép các nhóm tự chủ. Chiến lược phòng thủ chuyên sâu (defense-in-depth strategy) này giúp ngăn chặn truy cập trái phép thông qua nhiều điểm kiểm tra đánh giá chính sách.

Bạn có thể sử dụng bài đăng trên blog này làm điểm khởi đầu để phát triển chiến lược IAM của tổ chức mình. Bạn có thể quyết định rằng bạn không cần tất cả các loại chính sách được giải thích trong bài viết này, và điều đó không sao cả. Không phải mọi tổ chức đều cần sử dụng mọi loại chính sách. Bạn có thể cần triển khai các chính sách khác nhau trong môi trường sản xuất so với môi trường sandbox. Các khái niệm quan trọng cần rút ra từ bài viết này là các tình huống mà mỗi loại chính sách có thể áp dụng, và tầm quan trọng của quyền sở hữu chính sách rõ ràng. Chúng tôi cũng khuyên bạn nên tận dụng xác thực chính sách trong AWS IAM Access Analyzer khi viết chính sách IAM để xác thực chính sách của bạn theo ngữ pháp chính sách IAM và các phương pháp hay nhất.

Để biết thêm thông tin, bao gồm các chính sách được mô tả trong giải pháp này và ứng dụng mẫu, hãy xem kho lưu trữ GitHub how-and-when-to-use-aws-iam-policy-blog-samples. Kho lưu trữ này hướng dẫn bạn qua một triển khai ví dụ sử dụng đường ống CI/CD với AWS CodePipeline. Nếu bạn có bất kỳ câu hỏi nào, vui lòng đăng chúng trong chủ đề AWS Identity and Access Management re:Post hoặc liên hệ với Hỗ trợ AWS.

Về tác giả

Matt Luttrell

Matt là Kiến trúc sư Giải pháp cấp cao trong nhóm Giải pháp Danh tính AWS. Khi không dành thời gian chạy theo các con, anh ấy thích trượt tuyết, đạp xe và thỉnh thoảng chơi trò chơi điện tử.

Jay Goradia

Jay là Quản lý Tài khoản Kỹ thuật (TAM) tại AWS, làm việc chặt chẽ với các khách hàng doanh nghiệp để đẩy nhanh hành trình lên đám mây của họ thông qua hướng dẫn chiến lược và chuyên môn kỹ thuật. Với nền tảng bảo mật của mình, anh ấy giúp các tổ chức hiểu rõ các phương pháp bảo mật tốt nhất trong AWS.

Anshu Bathla

Anshu là Tư vấn viên trưởng – SRC tại AWS, có trụ sở tại Gurugram, Ấn Độ. Anh ấy làm việc với khách hàng thuộc nhiều lĩnh vực khác nhau để giúp củng cố cơ sở hạ tầng bảo mật và đạt được các mục tiêu bảo mật của họ. Ngoài công việc, Anshu thích đọc sách và làm vườn tại nhà.

Josh Joy

Josh là Kỹ sư Bảo mật Danh tính cấp cao với AWS Identity giúp đảm bảo an toàn và bảo mật các điểm tích hợp AWS Auth. Josh thích đi sâu và làm việc ngược lại để giúp khách hàng đạt được kết quả tích cực.

TAGS: IAM, Security, Security Blog