Các biện pháp kiểm soát bảo mật thiết yếu để ngăn chặn việc xóa tài khoản trái phép trong AWS Organizations

Tác giả: Nivedita Tripathi, Ryan Bates, và Samir Behara
Ngày phát hành: 17 MAR 2026
Chuyên mục: AWS Organizations, Management & Governance, Management Tools, Security & Governance, Security, Identity, & Compliance

Khi các tài khoản thành viên AWS bị xâm nhập, kẻ tấn công có thể xóa chúng khỏi tổ chức của bạn, vô hiệu hóa tất cả các biện pháp kiểm soát quản trị. Trong bài viết này, bạn sẽ tìm hiểu cách bảo vệ môi trường AWS của mình khỏi việc tài khoản bị xâm nhập rời khỏi AWS Organization bằng cách sử dụng các biện pháp kiểm soát bảo mật theo lớp, bao gồm các chính sách kiểm soát dịch vụ (SCP), di chuyển tài khoản an toàn và quản lý quyền truy cập root tập trung.

AWS bảo mật cơ sở hạ tầng chạy đám mây, trong khi bạn chịu trách nhiệm bảo mật khối lượng công việc và dữ liệu của mình trên đám mây. Để làm được điều đó, AWS Organizations bao gồm các biện pháp kiểm soát bảo mật ngăn chặn việc xóa tài khoản trái phép và duy trì quản trị trên các tài khoản của bạn.

Chúng tôi sẽ đề cập đến bốn biện pháp kiểm soát: ngăn chặn việc xóa tài khoản trái phép bằng Chính sách kiểm soát dịch vụ (SCP), thiết lập các quy trình khẩn cấp (break-glass) cho các lần di chuyển hợp pháp, chuyển tài khoản trực tiếp giữa các tổ chức và vô hiệu hóa quyền truy cập root cho các tài khoản thành viên.

Điều kiện tiên quyết
Để thực hiện bài viết này, bạn phải quen thuộc với AWS Organizations và các khái niệm chiến lược đa tài khoản. Bạn phải có quyền truy cập vào tài khoản quản lý AWS Organizations với các quyền để:

Tạo và đính kèm chính sách kiểm soát dịch vụ — organizations:CreatePolicy, organizations:AttachPolicy
Quản lý các đơn vị tổ chức —organizations:CreateOrganizationalUnit, organizations:MoveAccount
Bật quản lý quyền truy cập root tập trung — iam:EnableOrganizationsRootCredentialsManagement

Thiết kế cấu trúc đơn vị tổ chức (OU) của bạn để đảm bảo bảo mật và linh hoạt
Nếu mô hình kinh doanh của bạn yêu cầu thường xuyên cho phép các tài khoản thành viên rời khỏi tổ chức, chẳng hạn như các nhà cung cấp dịch vụ được quản lý, nhà bán lẻ hoặc các tổ chức có tỷ lệ thay đổi tài khoản cao, thì bạn nên thiết kế cấu trúc OU của mình với quy trình làm việc này ngay từ đầu.

Hãy cân nhắc việc tạo các OU chuyên dụng cho các giai đoạn vòng đời tài khoản khác nhau (onboarding, active, off-boarding) và chỉ áp dụng SCP DenyLeaveOrganization cho các OU chứa các tài khoản cần duy trì quản trị lâu dài. Cách tiếp cận này bảo mật cơ sở hạ tầng cốt lõi của bạn và đơn giản hóa việc di chuyển cho các tài khoản có vòng đời ngắn.

Tạo cấu trúc OU phân cấp cân bằng giữa các biện pháp kiểm soát bảo mật với tính linh hoạt trong vận hành. Áp dụng SCP DenyLeaveOrganization cho các OU sản xuất và phát triển của bạn để bảo vệ các khối lượng công việc quan trọng, đồng thời duy trì một OU chuyển tiếp riêng biệt không có hạn chế này để di chuyển tài khoản có kiểm soát.

Kiến trúc OU được đề xuất:

OU sản xuất: Áp dụng SCP DenyLeaveOrganization để ngăn các tài khoản chạy khối lượng công việc sản xuất rời khỏi tổ chức của bạn.
OU phát triển: Áp dụng cùng SCP để duy trì quản trị đối với môi trường phát triển và thử nghiệm.
OU chuyển tiếp: Giữ OU này không có SCP DenyLeaveOrganization để đóng vai trò là khu vực dàn dựng có kiểm soát cho các tài khoản chuẩn bị rời khỏi tổ chức.

Khi một tài khoản cần rời khỏi tổ chức của bạn vì lý do kinh doanh hợp pháp, tài khoản quản lý của bạn có thể chuyển nó đến OU chuyển tiếp, nơi hoạt động rời khỏi cho tài khoản thành viên trở nên khả thi. Điều này tạo ra một quy trình phê duyệt rõ ràng và duy trì khả năng hiển thị trong suốt quá trình di chuyển.

Xin lưu ý rằng tài khoản quản lý có thể xóa các tài khoản thành viên khỏi tổ chức, vì vậy nếu không có nhu cầu hợp pháp để các tài khoản thành viên tự rời đi, bạn không cần triển khai cách tiếp cận OU chuyển tiếp cho các tài khoản rời đi.

Để được hướng dẫn chi tiết về cách tổ chức và quản lý cấu trúc OU của bạn, hãy làm theo các phương pháp hay nhất của AWS để quản lý các đơn vị tổ chức với AWS Organizations.

Triển khai chính sách kiểm soát dịch vụ từ chối hành động rời khỏi tổ chức
Để ngăn các tài khoản thành viên rời khỏi tổ chức của bạn, hãy triển khai một SCP từ chối hành động organizations:LeaveOrganization cho các tài khoản thành viên. Biện pháp kiểm soát phòng ngừa này đảm bảo các tài khoản vẫn nằm trong khuôn khổ quản trị của bạn, giữ cho các biện pháp kiểm soát bảo mật và chính sách tổ chức của bạn được duy trì.

Tạo SCP bằng AWS Management Console

Đăng nhập vào bảng điều khiển AWS Organizations bằng tài khoản quản lý của bạn.
Trong ngăn điều hướng, chọn Policies.
Chọn và bật các chính sách kiểm soát dịch vụ.
Chọn Create policy.
Nhập tên chính sách, ví dụ: “DenyLeaveOrganization”.
Trong trình chỉnh sửa chính sách, nhập JSON sau:

			
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

		

Nhấp vào Create policy.

Tạo SCP bằng AWS CLI

Chạy lệnh sau để tạo chính sách.

			
aws organizations create-policy \
--name DenyLeaveOrganization \
--type SERVICE_CONTROL_POLICY \
--description "Prevents member accounts from leaving the organization" \
--content '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"organizations:LeaveOrganization","Resource":"*"}]}'

		

Lưu ý ID chính sách từ đầu ra để sử dụng trong bước tiếp theo.

Sau khi tạo chính sách, hãy áp dụng SCP DenyLeaveOrganization cho OU Sản xuất và OU Phát triển của bạn trong khi giữ OU Chuyển tiếp không bị hạn chế.

Đính kèm SCP vào các OU của bạn bằng AWS Management Console

Điều hướng đến AWS Organizations.
Chọn OU mục tiêu, Production hoặc Development.
Chọn tab Policies.
Chọn Attach và chọn chính sách ‘DenyLeaveOrganization’.
Lặp lại cho mỗi OU yêu cầu chính sách.

Đính kèm SCP vào các OU của bạn bằng AWS CLI

Đính kèm chính sách vào các OU mục tiêu của bạn bằng ID chính sách từ bước tạo: aws organizations attach-policy --policy-id p-xxxxxxxx --target-id r-xxxx
Xác minh việc đính kèm chính sách: aws organizations list-targets-for-policy --policy-id p-xxxxxxxx
Lặp lại cho mỗi OU yêu cầu chính sách.

Biện pháp kiểm soát này chặn các nỗ lực rời đi ở cấp API thông qua bảng điều khiển, CLI hoặc SDK. Để biết các phương pháp hay nhất về bảo vệ tài khoản quản lý của bạn, hãy tham khảo tài liệu.

Xin lưu ý rằng SCP không áp dụng cho tài khoản quản lý và chỉ ảnh hưởng đến các tài khoản thành viên trong tổ chức. Đây là lý do tại sao việc bảo vệ tài khoản quản lý của bạn bằng các biện pháp kiểm soát bảo mật mạnh nhất có thể – bao gồm MFA, quyền truy cập hạn chế, chỉ thông tin xác thực tạm thời và giám sát toàn diện là điều cần thiết.

Ghi lại các quy trình khẩn cấp (break-glass)
Nếu bạn cần cho phép các tài khoản cụ thể rời khỏi tổ chức trong quá trình di chuyển tài khoản, sáp nhập, mua lại hoặc thoái vốn, hãy thiết lập một quy trình chính thức với các quy trình phê duyệt được ghi lại và các cơ chế kỹ thuật.

Chọn cơ chế khẩn cấp (break-glass) phù hợp cho kịch bản của bạn: Khi một tài khoản cần rời khỏi tổ chức của bạn, hãy chuyển nó từ OU hiện tại sang OU chuyển tiếp thông qua quy trình quản lý thay đổi tiêu chuẩn của bạn. Khi ở trong OU chuyển tiếp, tài khoản có thể thực hiện hoạt động rời đi mà không bị hạn chế bởi SCP DenyLeaveOrganization. Cách tiếp cận này duy trì các biện pháp kiểm soát bảo mật trên tất cả các tài khoản đang hoạt động mà không yêu cầu bạn tạm thời xóa SCP khỏi toàn bộ gốc tổ chức của mình.

Thiết lập quy trình ngoại lệ được ghi lại cho việc rời khỏi tài khoản thành viên
Các tài khoản thành viên rời khỏi tổ chức của bạn một cách độc lập – bên ngoài quy trình di chuyển dựa trên lời mời an toàn – nên được coi là các trường hợp ngoại lệ yêu cầu phê duyệt chính thức. Mỗi yêu cầu ngoại lệ phải bao gồm lý do kinh doanh rõ ràng giải thích tại sao tài khoản không thể sử dụng quy trình chuyển giao từ tổ chức sang tổ chức tiêu chuẩn, cùng với việc xem xét và phê duyệt từ các nhóm bảo mật và quản trị CNTT để xác thực sự phù hợp với các yêu cầu chính sách bảo mật và quản trị.

Ghi lại ngoại lệ này trong cơ sở bảo mật của bạn, ghi chú rõ ràng rằng OU chuyển tiếp chỉ tồn tại để dàn dựng tài khoản tạm thời trong quá trình di chuyển được phê duyệt mà không thể sử dụng quy trình chuyển giao dựa trên lời mời tiêu chuẩn. Tài liệu này thiết lập trách nhiệm giải trình, tạo dấu vết kiểm toán cho các đánh giá tuân thủ và đảm bảo rằng các ngoại lệ đối với các biện pháp kiểm soát bảo mật của bạn là có chủ ý, có lý do chính đáng và có giới hạn thời gian.

Di chuyển tài khoản an toàn trong quá trình sáp nhập và mua lại
Trong quá trình sáp nhập, mua lại hoặc hợp nhất tổ chức, AWS Organizations hỗ trợ chuyển tài khoản trực tiếp, an toàn giữa các tổ chức – ngăn tài khoản trở thành độc lập. Tài khoản quản lý của tổ chức đích gửi lời mời đến tài khoản đang di chuyển. Khi được chấp nhận, tài khoản sẽ chuyển đổi liền mạch từ tổ chức nguồn sang tổ chức đích mà không bao giờ hoạt động bên ngoài quản trị tổ chức. Các chính sách kiểm soát dịch vụ (SCP), ghi nhật ký và giám sát được áp dụng liên tục trong suốt quá trình di chuyển, duy trì tư thế bảo mật và tạo ra các dấu vết kiểm toán hoàn chỉnh thông qua AWS CloudTrail.

Cách tiếp cận dựa trên lời mời này giải quyết hầu hết các trường hợp sử dụng di chuyển hợp pháp đồng thời ngăn chặn các lỗ hổng bảo mật xảy ra khi các tài khoản hoạt động độc lập. Các tài khoản quản lý không cần phải xóa thủ công các tài khoản thành viên – quy trình lời mời xử lý các chuyển đổi tự động. Sau khi di chuyển, hãy xác thực rằng các chính sách thích hợp được áp dụng, cập nhật các chính sách IAM với ID tổ chức chính xác và xem xét cấu hình thanh toán, cài đặt thuế và chuyển Reserved Instances. Để được hướng dẫn chi tiết, hãy tham khảo Hướng dẫn sử dụng AWS Organizations về di chuyển tài khoản.

Loại bỏ các lỗ hổng truy cập root trong tài khoản thành viên
Thông tin xác thực người dùng root trong các tài khoản thành viên đại diện cho cấp độ truy cập đặc quyền cao nhất trong môi trường AWS của bạn. Kể từ khi ra mắt AWS Centralized Root Access Management vào năm 2025, các tài khoản thành viên mới được tạo không còn có thông tin xác thực root theo mặc định – đây hiện là hành vi tiêu chuẩn cho tất cả các tài khoản mới trong tổ chức của bạn. Các tài khoản thành viên mới được tạo tự động được cấp phép mà không có thông tin xác thực root, loại bỏ nhu cầu về các biện pháp bảo mật sau cấp phép như cấu hình xác thực đa yếu tố.

Đối với các tài khoản hiện có được tạo trước khi mặc định này có hiệu lực, việc xóa thông tin xác thực root tồn tại lâu dài là nhanh chóng và đơn giản. AWS Centralized Root Access Management cho phép bạn xóa thông tin xác thực root – bao gồm mật khẩu, khóa truy cập, chứng chỉ ký và thiết bị MFA trên toàn bộ tổ chức của bạn trực tiếp từ tài khoản quản lý. Bạn không cần phải đăng nhập vào từng tài khoản thành viên riêng lẻ.

Cách tiếp cận tập trung này duy trì bảo mật nhất quán trên các tài khoản thành viên. Nó cũng giảm chi phí vận hành bằng cách loại bỏ khoảng cách lỗ hổng giữa việc tạo tài khoản và cấu hình bảo mật. Để được hướng dẫn chi tiết về việc triển khai quản lý quyền truy cập root tập trung, hãy tham khảo quản lý tập trung quyền truy cập root cho các tài khoản thành viên để biết thêm thông tin.

Xóa thông tin xác thực root bằng AWS Management Console

Mở bảng điều khiển IAM bằng tài khoản quản lý.
Trong ngăn điều hướng dưới Access Management, chọn root access management.
Nếu quản lý quyền truy cập root tập trung chưa được bật, một biểu ngữ hoặc lời nhắc sẽ xuất hiện ở đầu trang.
Chọn Enable để kích hoạt nó. Nếu không có lời nhắc nào như vậy xuất hiện, tính năng này đã được bật trong tổ chức của bạn. Sau khi được bật, trang sẽ hiển thị cấu trúc tổ chức của bạn với các tài khoản thành viên.
Chọn một tài khoản và xem lại bảng điều khiển Root user credentials ở bên phải. Đối với bất kỳ tài khoản nào vẫn có thông tin xác thực root đang hoạt động, hãy chọn Delete root credentials để xóa chúng.

Hình 1: Quản lý quyền truy cập root

Bật quản lý quyền truy cập root tập trung bằng AWS CLI

Bật quản lý quyền truy cập root tập trung bằng cách chạy lệnh sau (an toàn để chạy ngay cả khi đã được bật – trả về trạng thái tính năng hiện tại), aws iam enable-organizations-root-credentials-management
Xác minh các tính năng đã bật để xác nhận cấu hình, aws iam list-organizations-features
Xem lại đầu ra để xác nhận việc bật thành công. Nếu tính năng đã được bật, bạn sẽ thấy như sau:

			
{
"OrganizationId": "o-xxxxxxxxxxxx",
"EnabledFeatures": [
"RootSessions",
"RootCredentialsManagement"
]
}

		

Nếu tính năng chưa được bật, aws iam list-organizations-features sẽ trả về một mảng EnabledFeatures trống như hiển thị ở đây.

			
{
"OrganizationId": "o-xxxxxxxxxxxx",
"EnabledFeatures": []
}

Kết luận
Bảo vệ AWS Organizations của bạn khỏi việc tài khoản bị xâm nhập đòi hỏi các biện pháp kiểm soát bảo mật theo lớp cân bằng giữa bảo vệ và tính linh hoạt trong vận hành. Chính sách kiểm soát dịch vụ DenyLeaveOrganization chặn việc xóa tài khoản trái phép và duy trì giám sát quản trị liên tục. Khả năng di chuyển tài khoản dựa trên lời mời giữa các tổ chức hỗ trợ các nhu cầu kinh doanh hợp pháp như sáp nhập, mua lại và hợp nhất, mà không tạo ra các lỗ hổng bảo mật. Việc loại bỏ quyền truy cập root thông qua AWS Centralized Root Access Management loại bỏ con đường đặc quyền cao nhất có thể bỏ qua các biện pháp kiểm soát bảo mật của bạn.

Các biện pháp kiểm soát này ngăn chặn thông tin xác thực bị xâm nhập xóa tài khoản khỏi tổ chức của bạn, giữ cho các chính sách kiểm soát dịch vụ và ghi nhật ký hoạt động trong quá trình di chuyển, và đảm bảo rằng các sự cố bảo mật vẫn có thể được kiểm soát trong khuôn khổ quản trị của bạn, để bạn có thể phát hiện, phản hồi và khắc phục sự cố nhanh hơn.

Bắt đầu bằng cách thiết kế cấu trúc OU của bạn, ghi lại các quy trình khẩn cấp (break-glass) của bạn, sau đó áp dụng SCP DenyLeaveOrganization và bật AWS Centralized Root Access Management. Thường xuyên xem xét cấu trúc OU của bạn, kiểm toán các yêu cầu ngoại lệ và giám sát các nỗ lực truy cập trái phép thông qua AWS CloudTrail. Coi quản trị tài khoản là một biện pháp kiểm soát bảo mật quan trọng để giữ cho môi trường AWS của bạn an toàn, tuân thủ và phù hợp với các mục tiêu kinh doanh của bạn. Để biết thêm các ví dụ và mẫu chính sách kiểm soát dịch vụ, hãy khám phá kho lưu trữ GitHub về các ví dụ SCP của AWS.

Về tác giả

Nivedita Tripathi

Nivedita Tripathi là Giám đốc sản phẩm cấp cao cho AWS Organizations. Cô tập trung vào việc hỗ trợ khách hàng xây dựng và mở rộng cơ sở hạ tầng đám mây của họ trên nhiều tài khoản, đồng thời tận dụng các phương pháp hay nhất về bảo mật và quản trị, cũng như duy trì trong các giới hạn tuân thủ do các tổ chức thiết lập. Bên cạnh niềm đam mê công nghệ, Nivedita thích âm nhạc, du lịch vòng quanh thế giới và dành thời gian cho gia đình.

Ryan Bates

Ryan là Quản lý tài khoản kỹ thuật (Technical Account Manager) tại AWS. Anh ấy thích học hỏi và giúp đỡ mọi người bằng những gì mình đã học được. Ryan đã có hơn 20 năm kinh nghiệm trong lĩnh vực CNTT và chịu trách nhiệm hỗ trợ người dùng cuối, hỗ trợ cơ sở hạ tầng và xây dựng các phòng ban CNTT. Khi không bận tâm đến khách hàng, Ryan thích dành thời gian cho gia đình, nếm rượu vang hoặc ghé thăm Disneyland.

Samir Behara

Samir Behara là Kiến trúc sư cơ sở hạ tầng đám mây cấp cao (Senior Cloud Infrastructure Architect) tại AWS Professional Services. Anh ấy đam mê giúp khách hàng đẩy nhanh quá trình hiện đại hóa CNTT thông qua các chiến lược áp dụng đám mây. Samir có nền tảng kỹ thuật phần mềm sâu rộng và thích đi sâu vào kiến trúc ứng dụng và quy trình phát triển để thúc đẩy hiệu suất, hiệu quả hoạt động và tăng tốc độ đổi mới.