Tác giả: Tatyana Yatskevich và Harsha Sharma
Ngày phát hành: 26 MAR 2025
Chuyên mục: Announcements, Intermediate (200), Security, Identity, & Compliance, Technical How-to
Mọi tổ chức đều cố gắng trao quyền cho các nhóm để thúc đẩy đổi mới đồng thời bảo vệ dữ liệu và hệ thống của họ khỏi sự truy cập ngoài ý muốn. Đối với các tổ chức có hàng nghìn tài nguyên Amazon Web Services (AWS) trải rộng trên nhiều tài khoản, các rào chắn quyền hạn (permissions guardrails) trên toàn tổ chức có thể giúp duy trì các cấu hình an toàn và tuân thủ. Ví dụ: một số dịch vụ AWS hỗ trợ chính sách dựa trên tài nguyên (resource-based policies) có thể được sử dụng để cấp cho các danh tính quyền thực hiện các hành động trên các tài nguyên mà chúng được đính kèm. Với việc quản lý các chính sách dựa trên tài nguyên thường được giao cho chủ sở hữu ứng dụng, các nhóm security trung tâm sử dụng các rào chắn quyền hạn để giúp đảm bảo rằng các cấu hình sai sót có thể xảy ra không dẫn đến việc truy cập ngoài ý muốn vào các tài nguyên này.
Trong bài viết này, chúng tôi thảo luận về cách bạn có thể sử dụng chính sách kiểm soát tài nguyên (resource control policies – RCPs) để hạn chế tập trung quyền truy cập vào các tài nguyên. Chúng tôi trình bày cách RCP có thể giúp cải thiện tư thế security của bạn đồng thời cho phép các nhà phát triển tự do hơn trong việc quản lý tài nguyên của họ, từ đó giảm thiểu sự xung đột giữa các nhóm security trung tâm và nhóm ứng dụng. Sử dụng một trường hợp sử dụng mẫu, chúng tôi sẽ khám phá các cân nhắc chính để thiết kế và triển khai RCP một cách hiệu quả trong tổ chức của bạn ở quy mô lớn.
Nếu bạn chưa quen với RCP, chúng tôi khuyên bạn nên bắt đầu với bài viết Giới thiệu chính sách kiểm soát tài nguyên (RCP), một loại chính sách ủy quyền mới trong AWS Organizations, cung cấp phần giới thiệu về RCP và vai trò của chúng trong chiến lược security của bạn.
Hành trình triển khai RCP
RCP là một loại chính sách ủy quyền trong AWS Organizations. RCP hoạt động cùng với chính sách kiểm soát dịch vụ (service control policies – SCPs) để giúp thiết lập các rào chắn quyền hạn trên nhiều tài khoản trong tổ chức của bạn. Để hiểu sự khác biệt và các trường hợp sử dụng của chúng, hãy xem Các trường hợp sử dụng chung cho SCP và RCP và Thực thi các kiểm soát phòng ngừa trên toàn doanh nghiệp với AWS Organizations.
Chúng tôi khuyên bạn nên triển khai các rào chắn quyền hạn, bao gồm RCP, bằng cách sử dụng quy trình lặp lại sau, bao gồm năm giai đoạn (như trong Hình 1).
- Kiểm tra các mục tiêu kiểm soát security của bạn
- Thiết kế các rào chắn quyền hạn
- Dự đoán các tác động tiềm ẩn
- Triển khai các rào chắn quyền hạn
- Giám sát các rào chắn quyền hạn
Hình 1: Hành trình triển khai các rào chắn quyền hạn
Cách tiếp cận theo từng giai đoạn này giúp đảm bảo việc tích hợp RCP hiệu quả vào chiến lược security của bạn, cải thiện tư thế security của bạn đồng thời giúp duy trì tính liên tục trong kinh doanh. Hãy cùng khám phá chi tiết từng giai đoạn triển khai RCP và phác thảo các cân nhắc chính cho một chiến lược triển khai hiệu quả.
Giai đoạn 1: Kiểm tra các mục tiêu kiểm soát security của bạn
Bước đầu tiên trong việc triển khai RCP là xác định các lĩnh vực mà RCP có thể giúp cải thiện tư thế security của bạn hoặc tối ưu hóa việc triển khai các kiểm soát cho các mục tiêu kiểm soát security cụ thể của tổ chức bạn.
Các mục tiêu kiểm soát của bạn có thể bị ảnh hưởng bởi nhiều yếu tố khác nhau như yêu cầu tuân thủ và quy định, nghĩa vụ pháp lý và hợp đồng, các loại tải công việc, phân loại dữ liệu và mô hình mối đe dọa của tổ chức bạn. Sau khi các mục tiêu kiểm soát của bạn được xác định rõ ràng và ưu tiên, hãy xác định những mục tiêu có thể đạt được bằng cách sử dụng RCP.
Giống như SCP, RCP được thiết kế để thiết lập các kiểm soát truy cập thô (coarse-grained access controls), các bất biến security (security invariants) hiếm khi thay đổi và đóng vai trò là ranh giới luôn bật trên nhiều tài nguyên AWS trong các tài khoản của bạn. RCP không dùng để quản lý các kiểm soát truy cập chi tiết (fine-grained access controls). Bạn sẽ tiếp tục sử dụng các chính sách như chính sách dựa trên tài nguyên và chính sách dựa trên danh tính để áp dụng các quyền hạn đặc quyền tối thiểu (least-privilege permissions).
Cụ thể hơn, sau đây là các mục tiêu kiểm soát chính mà bạn có thể đạt được bằng cách sử dụng RCP:
- Thiết lập một vùng bảo vệ dữ liệu (data perimeter) xung quanh các tài nguyên AWS của bạn. Ví dụ: bạn có thể sử dụng RCP để giúp đảm bảo rằng chỉ các danh tính đáng tin cậy mới có thể truy cập các tài nguyên AWS của bạn.
- Giảm thiểu rủi ro phó nhầm lẫn dịch vụ chéo (cross-service confused deputy). Bạn có thể sử dụng RCP để giúp đảm bảo rằng các tài nguyên AWS của bạn chỉ được các dịch vụ AWS truy cập thay mặt cho tổ chức của bạn.
- Áp dụng các kiểm soát truy cập nhất quán cho các tài nguyên AWS của bạn bất kể danh tính nào đang truy cập chúng. Ví dụ: bạn có thể sử dụng RCP để giúp đảm bảo các Amazon Simple Storage Service (Amazon S3) bucket của bạn yêu cầu TLS v1.2 trở lên để mã hóa khi truyền (in-transit encryption).
Để biết thêm các trường hợp sử dụng và các loại kiểm soát có thể được triển khai bằng RCP, bạn có thể khám phá kho lưu trữ ví dụ về chính sách kiểm soát tài nguyên. Trong bài viết này, chúng tôi trình bày cách giúp đảm bảo rằng chỉ các danh tính đáng tin cậy mới có thể truy cập các IAM role của AWS Identity and Access Management (IAM) của bạn.
Hãy bắt đầu với kịch bản được minh họa trong Hình 2. Nhóm cloud trung tâm của công ty bạn quản lý tổ chức AWS Organizations của công ty bạn, bao gồm hai tài khoản AWS của công ty. Một IAM principal trong Tài khoản A phải có khả năng đảm nhận (assume) một IAM role trong Tài khoản B để thực hiện các hoạt động hàng ngày. Để phù hợp với mục tiêu kiểm soát rộng hơn là Chỉ các danh tính đáng tin cậy mới có thể truy cập tài nguyên của tôi, nhóm security trung tâm muốn đảm bảo rằng IAM role trong Tài khoản B (tài nguyên của tôi) chỉ có thể được đảm nhận bởi các IAM principal thuộc về tổ chức của họ (các danh tính đáng tin cậy).
Hình 2: Kịch bản đơn giản mô tả một danh tính đáng tin cậy truy cập vào một IAM role
Một cách để đạt được mục tiêu kiểm soát này là tuân theo nguyên tắc đặc quyền tối thiểu (least-privilege) và đảm bảo rằng chính sách tin cậy role (role trust policy), chính sách dựa trên tài nguyên được đính kèm vào IAM role, chỉ cho phép truy cập vào các danh tính yêu cầu quyền truy cập đó. Sau đây là một ví dụ về chính sách tin cậy cấp quyền cho Role A trong Tài khoản A để đảm nhận Role B trong Tài khoản B.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GrantCrossAccountAccess",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<span style="color: #ff0000;font-style: italic"><my-account-a-id></span>:role/RoleA"
},
"Action": "sts:AssumeRole"
}
]
}
Trong các tổ chức chỉ có một vài tài khoản, các nhóm trung tâm thường quản lý các chính sách này. Mặc dù mô hình quản trị tập trung này giúp đảm bảo rằng các chính sách tin cậy được áp dụng cho các role luôn bị giới hạn đối với các danh tính đáng tin cậy, nhưng nó cũng có thể cản trở năng suất của các nhóm ứng dụng khi hoạt động ở quy mô lớn hơn.
Giả sử rằng công ty của bạn đã bắt đầu phát triển dấu chân cloud của mình đến mức nhóm security trung tâm của bạn hiện phải đạt được cùng một mục tiêu kiểm soát với hàng trăm IAM role trải rộng trên nhiều tài khoản AWS, như được trình bày trong Hình 3.
Hình 3: Hạn chế truy cập bằng cách quản lý các chính sách tin cậy IAM role riêng lẻ
Ở quy mô này, chúng tôi thấy các tổ chức ủy quyền quản lý quyền hạn cho các nhóm ứng dụng để hỗ trợ tốt hơn sự phát triển kinh doanh của họ và trao quyền cho các nhà phát triển đổi mới nhanh hơn. Mặc dù các nhóm security trung tâm không còn kiểm soát hoàn toàn các quyền hạn được cấp cho các tài nguyên trên các tài khoản AWS, nhưng họ phải đảm bảo rằng quyền truy cập phù hợp với tiêu chuẩn security của tổ chức họ. Ví dụ: họ có thể muốn đảm bảo rằng câu lệnh GrantCrossAccountAccess hiện được quản lý bởi các nhà phát triển không vô tình cấp quyền truy cập vào một tài khoản không thuộc về tổ chức của họ. Trước đây, các nhóm security trung tâm thường đạt được điều này bằng cách phát triển các cơ chế tự động để chèn một câu lệnh tiêu chuẩn vào tất cả các chính sách tin cậy. Câu lệnh này giúp đảm bảo rằng quyền truy cập vẫn bị giới hạn trong tổ chức của họ, ngay cả khi các nhà phát triển định cấu hình quyền truy cập rộng rãi cho các role của họ. Sau đây là một ví dụ về chính sách tin cậy trong đó một nhà phát triển đã cấp quyền cho một tài khoản bên ngoài thông qua câu lệnh GrantCrossAccountAccess. Tuy nhiên, do câu lệnh RestrictAccessToMyOrg được nhóm security trung tâm thêm vào chính sách, tài khoản bên ngoài sẽ không thể sử dụng các quyền hạn này.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GrantCrossAccountAccess",
"Effect": "Allow",
"Principal": {
"AWS":"arn:aws:iam::<span style="color: #ff0000;font-style: italic"><noncorp-account-id></span>:role/<span style="color: #ff0000;font-style: italic"><role-name></span>"
},
"Action": "sts:AssumeRole"
},
{
"Sid": "RestrictAccessToMyOrg",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringNotEqualsIfExists": {
"aws:PrincipalOrgID": "<span style="color: #ff0000;font-style: italic"><my-org-id></span>"
},
"BoolIfExists": {
"aws:PrincipalIsAWSService": "false"
}
}
}
]
}
Câu lệnh RestrictAccessToMyOrg sử dụng các khóa điều kiện aws:PrincipalOrgID và aws:PrincipalIsAWSService để hạn chế quyền truy cập đối với các principal trong tổ chức của bạn hoặc đối với AWS service principals. Toán tử BoolIfExists với khóa điều kiện aws:PrincipalIsAWSService là bắt buộc nếu các role mà bạn đang áp dụng kiểm soát là service roles được các dịch vụ AWS sử dụng để thực hiện các hoạt động thay mặt cho bạn. Khi một dịch vụ AWS đảm nhận một service role, nó sử dụng AWS service principal của nó, một danh tính thuộc sở hữu của AWS và không thuộc về tổ chức của bạn.
Các nhóm security trung tâm có thể, ví dụ, sử dụng AWS Config rules để phát hiện các cấu hình sai sót và sau đó sử dụng AWS Config remediation để tự động thêm câu lệnh RestrictAccessToMyOrg vào các chính sách tin cậy của IAM role khi các IAM role mới được tạo hoặc chính sách tin cậy của chúng bị thay đổi. Mặc dù việc thêm câu lệnh RestrictAccessToMyOrg vào các chính sách tin cậy có thể được tự động hóa, RCP có thể đơn giản hóa đáng kể việc thực thi các kiểm soát thô như vậy trong môi trường đa tài khoản.
Giai đoạn 2: Thiết kế các rào chắn quyền hạn
Các nhóm security trung tâm có thể triển khai các rào chắn quyền hạn bằng cách tạo một RCP chặn tập trung quyền truy cập bên ngoài vào các IAM role. RCP mà bạn sẽ triển khai chứa các hạn chế tương tự như câu lệnh RestrictAccessToMyOrg mà bạn đã sử dụng trong chính sách tin cậy IAM.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictAccessToMyOrg",
"Effect": "Deny",
"Principal": "*",
"Action": "sts:AssumeRole",
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:PrincipalOrgID": "<span style="color: #ff0000;font-style: italic"><my-org-id></span>"
},
"BoolIfExists": {
"aws:PrincipalIsAWSService": "false"
}
}
}
]
}
Giống như SCP, bạn đính kèm RCP vào một tài khoản, đơn vị tổ chức (OU) hoặc root của tổ chức bạn. Sau khi được đính kèm, RCP tự động áp dụng cho các tài nguyên áp dụng—trong trường hợp này là IAM role—trong phạm vi của thực thể AWS Organizations đó. Cách tiếp cận tập trung này giúp giảm bớt nhu cầu sửa đổi hàng trăm chính sách tin cậy trên nhiều tài khoản, giảm chi phí vận hành cho các nhóm security trung tâm và giúp đảm bảo các kiểm soát truy cập nhất quán được áp dụng ở quy mô lớn. RCP cũng giúp bạn đạt được sự phân tách nhiệm vụ (separation of duties) với các nhà phát triển vẫn quản lý các quyền hạn đặc quyền tối thiểu của họ trong các chính sách tin cậy và quản trị viên áp dụng các kiểm soát truy cập thô trong RCP. Nếu các nhà phát triển mắc lỗi cấu hình khi quản lý quyền hạn cho các ứng dụng của họ, các kiểm soát truy cập phòng ngừa được triển khai bằng RCP sẽ giúp đảm bảo rằng họ tuân thủ các nguyên tắc kiểm soát truy cập của tổ chức bạn. Xem Cách logic mã thực thi của AWS đánh giá các yêu cầu cho phép hoặc từ chối truy cập để hiểu cách các loại chính sách khác nhau tác động đến quy trình ủy quyền.
Nếu bạn đang chuyển đổi các kiểm soát hiện có từ các chính sách dựa trên tài nguyên sang RCP, hãy tận dụng cơ hội để đánh giá lại thiết kế kiểm soát dựa trên các mục tiêu kiểm soát hiện tại của bạn và các lợi ích bổ sung mà RCP mang lại. Ví dụ: các kiểm soát trước đây của bạn có thể bị giới hạn đối với các loại tài nguyên cụ thể, chẳng hạn như IAM role trong trường hợp sử dụng này, hoặc đối với các tài khoản cụ thể, chẳng hạn như những tài khoản lưu trữ dữ liệu nhạy cảm nhất. RCP cho phép bạn mở rộng các kiểm soát sang các tài nguyên bổ sung trên toàn bộ tổ chức của bạn, giảm chi phí vận hành thông qua quản lý tập trung các rào chắn quyền hạn.
Nếu bạn cần áp dụng kiểm soát đối với các tài nguyên chưa được RCP bao phủ, bạn có thể triển khai hoặc giữ lại tính năng tự động hóa tùy chỉnh của mình để thực thi các kiểm soát bằng các chính sách dựa trên tài nguyên. Xem Danh sách các dịch vụ AWS hỗ trợ RCP và Các tài nguyên và thực thể không bị RCP hạn chế và lập kế hoạch cho các kiểm soát bổ sung nếu áp dụng.
Trong khi thiết kế RCP của bạn, hãy xem xét các nguyên tắc sau.
Thiết kế để đạt được sự xuất sắc trong vận hành (operational excellence)
Một nền tảng quan trọng để triển khai và vận hành hiệu quả các rào chắn quyền hạn như RCP là tổ chức môi trường AWS của bạn bằng cách sử dụng nhiều tài khoản. Ranh giới tài khoản và việc đặt tải công việc một cách chiến lược trên chúng cho phép bạn áp dụng các kiểm soát truy cập phù hợp với độ nhạy cảm của dữ liệu và các yêu cầu truy cập cụ thể. Việc nhóm các tài khoản thành các OU trong AWS Organizations cho phép kiểm soát truy cập hiệu quả hơn, ngay cả trong các tình huống yêu cầu truy cập đa tài khoản. Hình 4 minh họa một cấu trúc tổ chức mẫu, trình bày cách RCP có thể được áp dụng ở nhiều cấp độ khác nhau của hệ thống phân cấp tổ chức để tuân thủ các yêu cầu security của các tải công việc khác nhau.
Hình 4: Một cấu trúc tổ chức mẫu với RCP được áp dụng ở nhiều cấp độ khác nhau
Khi hoạt động ở quy mô lớn, hãy cân nhắc ủy quyền quản lý chính sách cho một tài khoản security trung tâm trong tổ chức của bạn. Với ủy quyền dựa trên tài nguyên của AWS Organizations, các nhóm trung tâm không cần truy cập vào tài khoản quản lý cho bất kỳ thay đổi hoặc khắc phục sự cố nào liên quan đến SCP hoặc RCP.
Xem lại bài viết Đạt được sự xuất sắc trong vận hành với các cân nhắc thiết kế cho SCP của AWS Organizations, tập trung vào SCP nhưng cũng bao gồm các nguyên tắc cơ bản để thiết kế và triển khai các rào chắn quyền hạn ở quy mô lớn. Những cân nhắc này cũng áp dụng cho RCP để cho phép sự xuất sắc trong vận hành. Ngoài ra, hãy xem hạn mức của AWS Organizations và đánh giá RCP để biết các hạn mức liên quan đến RCP và các chi tiết triển khai độc đáo.
Xác định quản trị (governance) của bạn
Việc thiết lập quản trị rõ ràng giúp bạn xác định cách triển khai và quản lý liên tục RCP trong tổ chức của bạn. Điều này bao gồm mô hình vận hành, quy trình quản lý thay đổi và quy trình xử lý ngoại lệ. RCP cung cấp các kiểm soát ủy quyền tương tự như SCP và do đó nên tích hợp với khuôn khổ quản trị hiện có của bạn thay vì yêu cầu giám sát riêng. Ví dụ: nếu quy trình quản lý thay đổi của bạn yêu cầu phê duyệt hai người cho các thay đổi SCP, bạn nên cân nhắc áp dụng cùng một quy trình phê duyệt cho việc triển khai RCP. Bạn cũng nên áp dụng các cơ chế tương tự mà bạn hiện đang sử dụng để ngăn chặn các thay đổi trái phép hoặc phát hiện sự sai lệch trong các chính sách của bạn.
Lập kế hoạch cho các trường hợp ngoại lệ
Có thể có những kịch bản mà bạn có một vài tài nguyên nên được truy cập công khai hoặc bởi các danh tính không thuộc về tổ chức của bạn. Nếu bạn đang tổ chức các tài nguyên của mình trên nhiều tài khoản và OU dựa trên các yêu cầu tuân thủ của chúng hoặc một bộ kiểm soát chung, thì rất có thể bạn có các tài nguyên đó trong một bộ tài khoản hoặc OU chuyên dụng, chẳng hạn như OU Public Data trong Hình 4. Các tài khoản hoặc OU này có thể có các chính sách áp dụng phù hợp với các yêu cầu truy cập độc đáo của chúng.
Một tùy chọn khác để đáp ứng các kịch bản này là sử dụng khóa điều kiện aws:ResourceAccount hoặc aws:ResourceOrgPaths để loại trừ một số tài khoản khỏi kiểm soát. Ví dụ: chính sách sau sẽ từ chối quyền truy cập vào các danh tính bên ngoài tổ chức của bạn khỏi việc đảm nhận IAM role trừ khi danh tính đó là AWS service principal hoặc role đang được truy cập thuộc về Tài khoản A.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictAccessToMyOrgExceptMyAccounts",
"Effect": "Deny",
"Principal": "*",
"Action": "sts:AssumeRole",
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:PrincipalOrgID": "<span style="color: #ff0000;font-style: italic"><my-org-id></span>",
"aws:ResourceAccount": "<span style="color: #ff0000;font-style: italic"><my-account-a-id></span>"
},
"BoolIfExists": {
"aws:PrincipalIsAWSService": "false"
}
}
}
]
}
Cũng có thể có những tình huống mà các đối tác đáng tin cậy hoặc các công ty mua lại của công ty bạn cần được cấp một ngoại lệ để truy cập vào một tập hợp con các tài nguyên của công ty bạn được phân phối trên nhiều tài khoản. Ví dụ: công ty bạn có thể tích hợp với các công cụ Quản lý Tư thế Security Cloud (CSPM) đảm nhận các role trong tài khoản của bạn để đánh giá tư thế security của tài khoản của bạn, như được hiển thị trong Hình 5.
Hình 5: Minh họa việc cấp các trường hợp ngoại lệ cho các đối tác đáng tin cậy
Khi triển khai kiểm soát bằng RCP mà theo mặc định sẽ áp dụng cho tất cả các tài nguyên của thực thể mà nó được đính kèm, bạn có thể quản lý các ngoại lệ cụ thể của tài nguyên bằng cách sử dụng khóa điều kiện aws:ResourceTag. Ngoài ra, hãy sử dụng khóa ngữ cảnh aws:PrincipalAccount để cấp ngoại lệ có điều kiện dựa trên ID tài khoản AWS của đối tác đáng tin cậy.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictAccessToMyOrgExceptTaggedRoles",
"Effect": "Deny",
"Principal": "*",
"Action": "sts:AssumeRole",
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:PrincipalOrgID": "<span style="color: #ff0000;font-style: italic"><my-org-id></span>",
"aws:ResourceTag/partner-access-exception": "trusted-partner"
},
"BoolIfExists": {
"aws:PrincipalIsAWSService": "false"
}
}
},
{
"Sid": "RestrictAccessForTaggedRoles",
"Effect": "Deny",
"Principal": "*",
"Action": "sts:AssumeRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/partner-access-exception": "trusted-partner"
},
"StringNotEqualsIfExists": {
"aws:PrincipalAccount": "<span style="color: #ff0000;font-style: italic"><trusted-partner-account-id></span>"
}
}
}
]
}
Hãy xem xét hai câu lệnh trong RCP trên:
RestrictAccessToMyOrgExceptTaggedRoles
Câu lệnh này giúp đảm bảo rằng các role của bạn chỉ có thể được đảm nhận bởi các danh tính thuộc về tổ chức của bạn hoặc bởi AWS service principals, trừ khi một role được gắn thẻpartner-access-exceptionđược đặt thànhtrusted-partner.RestrictAccessForTaggedRoles
Câu lệnh này hạn chế quyền truy cập hơn nữa bằng cách giúp đảm bảo rằng các role có thẻpartner-access-exceptionchỉ có thể được đảm nhận bởi các danh tính thuộc về tài khoản đối tác đáng tin cậy của bạn.
Nếu bạn có một tập hợp tài nguyên đã biết, có phạm vi hẹp cần được loại trừ, bạn cũng có thể sử dụng phần tử chính sách IAM, NotResource, để liệt kê Amazon Resource Names (ARN) của các tài nguyên cần loại trừ khỏi kiểm soát.
Khi triển khai các quy trình ngoại lệ dựa trên thẻ, việc thiết lập các kiểm soát nghiêm ngặt đối với việc quản lý thẻ là rất quan trọng. Các sửa đổi trái phép đối với các thẻ trên tài nguyên, principal hoặc phiên có thể ảnh hưởng đến tư thế security của bạn bằng cách cho phép truy cập ngoài ý muốn. Bạn nên triển khai các kiểm soát để giúp ngăn chặn việc thao túng thẻ trái phép. Ví dụ: SCP sau hạn chế việc sử dụng thẻ partner-access-exception đối với role admin để người dùng trái phép không thể thay đổi kiểm soát bằng cách đính kèm, tách hoặc sửa đổi thẻ.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictAccessToExceptionTag",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:PrincipalArn": "<span style="color: #ff0000;font-style: italic"><admin-role-arn></span>"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"partner-access-exception"
]
}
}
}
]
}
Bạn cũng nên đảm bảo rằng thẻ partner-access-exception không thể được chuyển dưới dạng session tag khi các danh tính đảm nhận role. Xem RCP mẫu trong kho lưu trữ ví dụ về chính sách vùng bảo vệ dữ liệu.
Giai đoạn 3: Dự đoán các tác động tiềm ẩn
Trước khi triển khai RCP, bạn cần hiểu tác động tiềm ẩn của chúng đối với tổ chức của bạn. Việc giới thiệu các chính sách mới hoặc sửa đổi các chính sách hiện có mà không có sự xác thực thích hợp có thể làm gián đoạn sự cân bằng giữa security và năng suất của bạn. Hãy lưu ý rằng các chính sách quá hạn chế có thể vô tình cản trở các luồng dữ liệu hợp pháp cần thiết để đạt được các mục tiêu kinh doanh của bạn.
Cân nhắc sử dụng AWS Identity and Access Management Access Analyzer để giám sát các quyền hạn hiệu quả trên các tài nguyên trong tổ chức của bạn. Đối với ví dụ về IAM role của chúng tôi, hãy sử dụng bộ phân tích truy cập bên ngoài của tổ chức để xác định các IAM role trong tổ chức của bạn được chia sẻ với các thực thể bên ngoài. Phân tích này sẽ giúp bạn tạo các ngoại lệ thích hợp hoặc khóa bất kỳ quyền truy cập quá rộng nào.
Một phương pháp hiệu quả khác để đánh giá tác động là xem xét và phân tích hoạt động tài khoản của bạn bằng cách sử dụng AWS CloudTrail. Ví dụ: nếu bạn tập trung tất cả các nhật ký CloudTrail của mình trong một S3 bucket, bạn có thể sử dụng Amazon Athena để truy vấn các nhật ký này. Cụ thể, hãy tìm kiếm các lệnh gọi API STS được thực hiện đối với các IAM role của bạn bởi các danh tính bên ngoài tổ chức của bạn. Sau đó, so sánh kết quả với danh sách các đối tác đáng tin cậy đã biết của bạn và những đối tác mà bạn đã tính đến trong RCP của mình. Dựa trên phân tích này, hãy xác định xem bạn có cần thêm thẻ partner-access-exception vào các IAM role bổ sung hay không và tinh chỉnh thêm chính sách trước khi thực thi. Điều này là cần thiết để đảm bảo các tích hợp đối tác đáng tin cậy tiếp tục hoạt động như mong đợi khi bạn thực thi RCP của mình. Hơn nữa, hãy sử dụng phân tích này để xác định bất kỳ mẫu truy cập bất hợp pháp nào trong môi trường của bạn và lập kế hoạch cho các biện pháp khắc phục cần thiết, nâng cao hơn nữa tư thế security của bạn như một phần của việc triển khai RCP.
Để được hướng dẫn chi tiết về cách thực hiện phân tích tác động trong môi trường của bạn, hãy xem Phân tích hoạt động tài khoản của bạn để đánh giá tác động và tinh chỉnh các kiểm soát, mô tả các công cụ và tùy chọn bạn cần để có thể tiến hành phân tích.
Giai đoạn 4: Triển khai các rào chắn quyền hạn
Khi bạn chuyển sang giai đoạn triển khai, hãy xem xét các yếu tố chính sau để thúc đẩy việc triển khai suôn sẻ đồng thời tăng cường tư thế security của bạn.
Tự động hóa và tích hợp triển khai
Sử dụng các pipeline triển khai hiện có của bạn để triển khai RCP, giống như bạn làm với SCP. Cách tiếp cận này sẽ giảm thiểu chi phí vận hành đồng thời duy trì tính nhất quán trong việc triển khai các kiểm soát của bạn.
Bạn có thể sử dụng loại tài nguyên AWS::Organizations::Policy của AWS CloudFormation để triển khai RCP dưới dạng cơ sở hạ tầng dưới dạng mã (IaC) bằng cách sử dụng pipeline tích hợp liên tục và phân phối liên tục (CI/CD) của bạn. Nếu bạn đang sử dụng AWS Control Tower và giải pháp Customizations for AWS Control Tower (CfCT) để quản lý tài khoản và muốn triển khai RCP tùy chỉnh của mình, hãy sử dụng rcp làm deploy_method trong tệp kê khai CfCT. Bạn cũng có thể tận dụng các kiểm soát dựa trên RCP do AWS Control Tower cung cấp để hợp lý hóa việc triển khai.
Triển khai dần dần theo từng giai đoạn
Cũng như SCP, AWS đặc biệt khuyên bạn không nên đính kèm RCP trong môi trường production mà không kiểm tra kỹ lưỡng tác động của các chính sách đối với các tài nguyên trong tài khoản của bạn. Thực hiện theo các quy trình CI/CD tiêu chuẩn và bắt đầu triển khai RCP của bạn trong các môi trường thấp hơn bằng cách đính kèm chúng vào các tài khoản hoặc OU thử nghiệm riêng lẻ trước. Sau khi bạn xác thực rằng các kiểm soát hoạt động như mong đợi, hãy dần dần quảng bá RCP lên các môi trường cao hơn.
Nếu mục tiêu của bạn là chuyển đổi một kiểm soát hiện có từ các chính sách dựa trên tài nguyên sang RCP, hãy giữ nguyên các chính sách dựa trên tài nguyên của bạn trong khi tiến hành triển khai dần dần. Sau khi bạn đã hoàn tất việc triển khai RCP và xác nhận rằng chúng hoạt động như mong đợi, bạn có thể cân nhắc hủy kích hoạt tính năng tự động hóa mà bạn đã sử dụng để áp dụng kiểm soát bằng các chính sách dựa trên tài nguyên. Cách tiếp cận này cho phép bạn triển khai RCP mà không ảnh hưởng đến tư thế security hiện có của bạn hoặc làm gián đoạn các quy trình kinh doanh.
Ngoài ra, hãy cân nhắc triển khai RCP cho một tập hợp con các tài nguyên hoặc tài khoản trước để giới hạn phạm vi tác động và tạo cơ hội để kiểm tra và tinh chỉnh các quy trình triển khai và vận hành của bạn. Bạn có thể tuân theo cách tiếp cận ưu tiên tiêu chuẩn của mình để xác định các đợt triển khai, ví dụ: bắt đầu với các tài nguyên hoặc tài khoản lưu trữ dữ liệu nhạy cảm hoặc gây ra rủi ro cao nhất, dựa trên các thực tiễn vận hành hiện tại của bạn và các kiểm soát khác có thể được áp dụng. Để biết thêm các best practice, hãy xem OPS06-BP03 Áp dụng các chiến lược triển khai an toàn trong sách trắng AWS Well-Architected Framework: Operation Excellence Pillar.
Giai đoạn 5: Giám sát các rào chắn quyền hạn
Cuối cùng, thiết lập các quy trình giám sát để giúp đảm bảo rằng các kiểm soát ngăn chặn truy cập bên ngoài vào các tài nguyên của bạn hoạt động như mong đợi. Bạn có thể sử dụng các công cụ tương tự mà bạn đã sử dụng để phân tích tác động. Ví dụ: bạn có thể sử dụng các phát hiện truy cập bên ngoài của IAM Access Analyzer để hiểu tác động của RCP của bạn đối với các quyền hạn tài nguyên. Thông tin này sẽ giúp bạn xác minh rằng RCP của bạn được tạo ra theo đúng ý định của bạn và lập kế hoạch hành động khắc phục, nếu cần. Bạn cũng có thể đặt cảnh báo cho các lần xuất hiện của các mẫu truy cập ngoài ý muốn được quan sát trong nhật ký CloudTrail của bạn.
Hơn nữa, hãy làm theo cách tiếp cận theo từng giai đoạn được nêu trong bài viết này để thường xuyên xem xét và cập nhật các kiểm soát của bạn để giúp đảm bảo rằng chúng phù hợp với các mục tiêu kinh doanh và security đang phát triển. Xem xét các yếu tố như thay đổi tổ chức, thay đổi trong mối quan hệ đối tác, thay đổi mức độ quan trọng của dữ liệu và cơ hội mở rộng phạm vi RCP của bạn. Quá trình cải tiến liên tục này giúp duy trì tính hiệu quả của các kiểm soát security của bạn đồng thời hỗ trợ tăng trưởng và chuyển đổi kinh doanh.
Kết luận
Trong bài viết này, chúng tôi đã thảo luận về cách triển khai hiệu quả các kiểm soát truy cập thô trên các tài nguyên AWS ở quy mô lớn bằng cách sử dụng RCP. Bạn có thể sử dụng cách tiếp cận triển khai theo từng giai đoạn được mô tả ở đây để đạt được các mục tiêu kiểm soát security của mình đồng thời giảm thiểu rủi ro làm gián đoạn các quy trình kinh doanh của bạn. Bạn có thể áp dụng cùng một cách tiếp cận để triển khai các kiểm soát phòng ngừa khác, chẳng hạn như SCP, trên môi trường đa tài khoản của bạn.
Hãy nhớ rằng RCP, giống như SCP, cung cấp một cơ chế mạnh mẽ để thực thi các kiểm soát thô trên nhiều tài khoản trong tổ chức của bạn. Chúng không thay thế các kiểm soát đặc quyền tối thiểu của bạn và nên là một phần của cách tiếp cận nhiều lớp, rộng hơn đối với security dữ liệu, bao gồm các nguyên tắc thiết kế security well-architected khác.
Nếu bạn có phản hồi về bài viết này, hãy gửi nhận xét trong phần Comments bên dưới. Nếu bạn có câu hỏi về bài viết này, hãy liên hệ với AWS Support.
Về tác giả
Tatyana Yatskevich
Tatyana là Principal Solutions Architect trong nhóm AWS Identity. Cô làm việc với khách hàng để giúp họ xây dựng và vận hành trên AWS một cách an toàn và hiệu quả.
Harsha W Sharma
Harsha là Principal Solutions Architect của AWS tại New York. Anh làm việc với các khách hàng Dịch vụ Tài chính Toàn cầu để giúp họ thiết kế và phát triển các kiến trúc có khả năng mở rộng, bảo mật và đàn hồi trên AWS.
AWS Study Group 