Sử dụng AWS Lambda với tài khoản AWS Control Tower Audit để kiểm tra cài đặt đa tài khoản của bạn.

Khi bạn xây dựng các workloads trên AWS, bạn được khuyến khích áp dụng chiến lược đa tài khoản để phân tách các workloads vào nhiều tài khoản AWS khác nhau. Bạn có thể làm điều này để phân tách các tài khoản dựa trên các đơn vị kinh doanh khác nhau, các giai đoạn khác nhau của vòng đời phát triển phần mềm (SDLC) hoặc một cách nào đó phù hợp với nhu cầu của tổ chức của bạn. Bất kể phương pháp bạn quyết định áp dụng, chiến lược đa tài khoản cung cấp cho bạn mức độ phân tách công việc và phân chia các quan tâm phù hợp trong môi trường AWS của bạn. Với nhiều năm kinh nghiệm trong việc thiết kế các workloads khác nhau, chúng tôi giới thiệu AWS Control Tower là một dịch vụ cung cấp một khu vực đáp đất được quản lý. Khu vực đáp đất tham chiếu đến một môi trường AWS đa tài khoản được thiết kế tốt. Control Tower cho phép bạn quản lý và điều khiển cài đặt đa tài khoản của mình trên quy mô lớn. Khi môi trường AWS của bạn mở rộng, bạn thường cần kiểm tra các tài nguyên trên nhiều tài khoản AWS khác nhau cho các nhu cầu khác nhau. Trong bài viết này, chúng tôi sẽ chỉ cho bạn cách kiểm tra môi trường AWS đa tài khoản của bạn với sự trợ giúp của AWS Lambda.

Các tài khoản cơ bản của Control Tower

Khi bạn thiết lập Control Tower, bạn sẽ bắt đầu với ba tài khoản AWS cơ bản:

Tài khoản Quản lý (Management account) – Tài khoản này là tài khoản thanh toán chính cho môi trường dựa trên Control Tower của bạn. Bạn sẽ sử dụng tài khoản này để quản lý các tài khoản AWS của mình, các đơn vị tổ chức (OUs) trong AWS Organizations của bạn và để kiểm tra tính tuân thủ của môi trường AWS của bạn với sự trợ giúp của các guardrail được thiết lập cho bảo mật và tuân thủ. Bạn nên tránh chạy bất kỳ khối lượng công việc nào trong tài khoản này.

Tài khoản Lưu trữ Nhật ký (Log Archive account) – Bạn sẽ sử dụng tài khoản Lưu trữ Nhật ký để trung tâm hóa việc lưu trữ và phân tích nhật ký được tạo ra cho các hoạt động API bởi AWS CloudTrail từ các tài khoản AWS khác nhau của bạn. Bạn cũng có thể sử dụng tài khoản này cho một giải pháp ghi nhật ký tập trung cho nhật ký được tạo ra bởi các tài khoản khối lượng công việc của bạn, sử dụng Kinesis Firehose, Amazon OpenSearch Service hoặc các tùy chọn khác.

Tài khoản Kiểm toán (Audit account) – Tài khoản này được sử dụng để cung cấp đội ngũ bảo mật và tuân thủ của bạn đọc và ghi truy cập vào tất cả các tài khoản trong môi trường Control Tower của bạn. Nó cho phép điều này bằng cách cung cấp truy cập chương trình thông qua các chức năng Lambda. Chúng tôi sẽ xem xét tài khoản Kiểm toán chi tiết trong phần tiếp theo, vì đây là trung tâm của chủ đề chúng tôi đang đề cập trong bài viết này.

Tài khoản kiểm toán Control Tower và truy cập giữa các tài khoản

Tài khoản kiểm toán cung cấp khả năng truy cập đọc / ghi được lập trình vào các tài khoản khác được quản lý bởi Control Tower bằng các chức năng Lambda. Bạn cũng có thể chọn sử dụng tài khoản này làm quản trị viên được ủy quyền cho các dịch vụ bảo mật như AWS Security Hub, Amazon GuardDuty, Amazon Macie và các dịch vụ khác. Điều này cho phép bạn tập trung các nhu cầu bảo mật và tuân thủ quy định của mình. Ngoài ra, nó cung cấp cho bạn truy cập vào AWS Organizations API, điều này có thể hữu ích khi bạn muốn kiểm tra các tài khoản khác, như chúng ta sẽ thấy sau này.

Có lý do tại sao bạn muốn có một “Security Account” riêng biệt, đóng role là quản trị viên được ủy quyền tập trung cho các dịch vụ bảo mật của bạn. Không có phương pháp nào được ưa thích hơn phương pháp khác và cả hai đều hoạt động tốt. Sự lựa chọn của bạn thường phụ thuộc vào cách tổ chức các phòng bảo mật và tuân thủ quy định.

Để cho phép truy cập vào các tài khoản khác, Control Tower tạo ra hai role quản lý quyền truy cập AWS Identity and Access Management (IAM) trong tài khoản kiểm toán:

aws-controltower-AuditAdministratorRole

Quyền hạn –
- AWSLambdaExecute – Chính sách quản lý AWS được yêu cầu cho thực thi Lambda
- AssumeRole-aws-controltower-AuditAdministratorRole – Chính sách nội tuyến tùy chỉnh chỉ cho phép role này đảm nhận aws-controltower-AdministratorExecutionRole trong các tài khoản khác
Mối quan hệ tin tưởng – lambda.amazonaws.com

aws-controltower-AuditReadOnlyRole

Quyền hạn –
- AWSLambdaExecute – Chính sách quản lý AWS được yêu cầu cho thực thi Lambda
- AssumeRole-aws-controltower-AuditReadOnlyRole – Chính sách nội tuyến tùy chỉnh chỉ cho phép role này đảm nhận aws-controltower-ReadOnlyExecutionRole trong các tài khoản khác
Mối quan hệ tin tưởng – lambda.amazonaws.com

Hình 1. Sơ đồ kiến trúc hiển thị cách Tài khoản Kiểm toán Control Tower có thể truy cập các tài khoản khác

Hình 1 trên cho thấy các role liên quan đến Kiểm toán trong tài khoản Kiểm toán có thể được sử dụng để truy cập các tài khoản khác. Điều này được kích hoạt bởi các role IAM tương ứng trong mỗi tài khoản được quản lý bởi Control Tower:

aws-controltower-AdministratorExecutionRole

Quyền hạn –
- AdministratorAccess – Chính sách quản lý AWS cấp đầy đủ quyền quản trị viên trong tài khoản này
Mối quan hệ tin tưởng – arn:aws:iam::<AuditAccount>:role/aws-controltower-AuditAdministratorRole

aws-controltower-ReadOnlyExecutionRole

Quyền hạn –
- ReadOnlyAccess – Chính sách quản lý AWS cấp đầy đủ quyền quản trị viên trong tài khoản này
Mối quan hệ tin tưởng –arn:aws:iam::<AuditAccount>:role/aws-controltower-AuditReadOnlyRole

Những role này trong các tài khoản cá nhân có mối quan hệ tin tưởng với các role IAM tập trung vào Audit trong tài khoản AWS Control Tower Audit. Điều này cho phép một chức năng Lambda trong tài khoản Audit sử dụng bất kỳ trong hai role IAM Audit làm role thực thi. Lambda sau đó có thể giả định role tương ứng trong các tài khoản cá nhân dựa trên mối quan hệ tin tưởng. Chúng ta sẽ thấy điều này trong hoạt động khi xem xét một ví dụ sử dụng trong phần tiếp theo.

Lưu ý: Hai role IAM trong các tài khoản công việc cá nhân không tồn tại trong tài khoản Quản lý Control Tower. Điều này là vì Audit Account được dành cho các nhóm an ninh và tuân thủ. Những nhóm này không luôn cần truy cập vào Management Account, đó là tài khoản mạnh nhất trong môi trường Control Tower của bạn và chứa thông tin nhạy cảm về quản trị và thanh toán. Ngoài ra, vì Management Account của bạn không được mong đợi có bất kỳ công việc nào, bạn không cần phải kiểm tra Management Account từ tài khoản Kiểm toán của mình.

Ví dụ sử dụng – Tìm các DNS Dangling record

Chúng ta hãy xem cách cơ chế này có thể được sử dụng để xác định các DNS Route 53 public record của Amazon, trỏ đến các địa chỉ IP không còn thuộc sở hữu của các tài khoản trong AWS Organizations của bạn.

Tình huống này, thường được gọi là Dangling DNS, xảy ra khi một record DNS trước đó được tạo ra, trong Route53 hoặc bất kỳ dịch vụ DNS nào khác, bị bỏ quên khi địa chỉ IP cơ bản không còn thuộc sở hữu của bạn và có sẵn cho các người dùng khác trong bể IP công cộng. Tình huống này thường ảnh hưởng đến các subdomain được tạo để lưu trữ các bộ xử lý phi sản xuất, có thể không được quản lý chặt chẽ như các miền bộ xử lý sản xuất. Các kẻ tấn công có thể thực hiện nỗ lực tấn công bằng vũ lực đối với các subdomain chung thông thường này, trỏ đến một địa chỉ IP và cố gắng giành được IP này bằng cách khởi chạy các máy chủ Amazon EC2 mới, các địa chỉ IP Elastic mới hoặc các phương tiện khác để tìm một địa chỉ IP công cộng. Mặc dù kẻ tấn công không thể yêu cầu hoặc được đảm bảo được cấp phát địa chỉ IP này, nhưng có khả năng họ ngẫu nhiên sở hữu địa chỉ IP này. Với subdomain vẫn trỏ đến địa chỉ IP này, kẻ tấn công hiện có quyền truy cập vào tất cả các lưu lượng được khởi đầu chống lại subdomain đó.

Điều kiện tiên quyết

AWS Organizations API mặc định chỉ có thể truy cập từ tài khoản Management. Tuy nhiên, bạn có thể chỉ định tài khoản Audit của mình làm quản trị viên được ủy quyền cho một trong các dịch vụ hỗ trợ quản trị viên được ủy quyền. Làm điều này cho phép bạn sử dụng API Tổ chức trong tài khoản Audit để lấy tất cả các tài khoản trong tổ chức của bạn. Sau đó, bạn có thể lặp lại các tài khoản của mình để thực hiện kiểm tra. Bạn có thể thực thi lệnh dưới đây trong giao diện dòng lệnh AWS (CLI) như một quản trị viên trong tài khoản Management của mình để chỉ định tài khoản Audit làm quản trị viên được ủy quyền.

aws organizations register-delegated-administrator \

–account-id <Your-Audit-Account-Id> \

–service-principal account.amazonaws.com

Với tài khoản Audit được chỉ định là delegated admin, bạn có thể cấu hình role aws-controltower-AuditReadOnlyRole với các quyền tối thiểu để liệt kê các tài khoản. Các role Audit trong Control Tower được quản lý bởi các guardrails phòng ngừa và chỉ có thể được sửa đổi bởi role AWSControlTowerExecution trong tài khoản Management. Với role AWSControlTowerExecution được giả định bởi một người dùng trong tài khoản Management, bạn có thể gán quyền liệt kê tài khoản cho aws-controltower-AuditReadOnlyRole như được hiển thị dưới đây.

“Statement”: [

{

“Sid”: “org-account-policies”,

“Effect”: “Allow”,

“Action”: “organizations:ListAccounts”,

“Resource”: “*”

}

]

Note: Nếu bạn không thể thiết lập tài khoản Audit như một quản trị viên được ủy quyền, bạn có thể sử dụng AWS Systems Manager Parameter Store hoặc một bucket Amazon S3 trong tài khoản Audit, nơi bạn có thể cập nhật các tài khoản theo cách có chương trình khi chúng được đăng ký / hủy đăng ký từ Control Tower bằng AWS Control Tower Lifecycle Events (sự kiện CreateManagedAccount và UpdateManagedAccount). Audit role của bạn sẽ cần các quyền bổ sung để truy cập vào dịch vụ mà bạn quyết định sử dụng.

Với các tiên quyết được đặt, đây là các bước để thể hiện cách bạn có thể xác định các record DNS dính của công cộng Amazon Route 53 trong môi trường AWS của mình. Mã hoàn chỉnh và tự động hóa để thiết lập chức năng Lambda này trong tài khoản Control Tower Audit của bạn bằng AWS Serverless Application Model có sẵn trong dự án GitHub này.

Bước 1. Truy xuất và lặp lại các tài khoản Control Tower và giả định role aws-controltower-*

Trước tiên, chúng ta sẽ truy xuất tất cả các tài khoản trong AWS Organizations của bạn và lặp lại chúng để giả định role aws-controltower* trong mỗi tài khoản bằng cách sử dụng AWS Security Token Service (STS). Trong ví dụ này, chúng ta chỉ muốn lấy danh sách các record DNS bị lỗi, vì vậy chúng ta giả định role với khả năng đọc, tức là role aws-controltower-ReadOnlyExecutionRole; nếu trường hợp sử dụng của bạn yêu cầu tạo / cập nhật / xóa bất kỳ tài nguyên nào từ tài khoản, hãy giả định role aws-controltower-AuditAdministratorRole thay vào đó.

client = boto3.client(‘organizations’)

response = client.list_accounts()

sts_connection = boto3.client(‘sts’)

acct_b = sts_connection.assume_role(

RoleArn=”arn:aws:iam::<AccountId>:role/aws-controltower-ReadOnlyExecutionRole”,

RoleSessionName=”cross_acct_lambda”

)

ACCESS_KEY = acct_b[‘Credentials’][‘AccessKeyId’]

SECRET_KEY = acct_b[‘Credentials’][‘SecretAccessKey’]

SESSION_TOKEN = acct_b[‘Credentials’][‘SessionToken’]

Trong quá trình lặp lại các tài khoản, bạn cần bỏ qua tài khoản quản lý (Management account), vì nó không có các Audit role Control Tower như đã mô tả trước đó. Tùy thuộc vào trường hợp sử dụng của bạn, bạn có thể chọn loại bỏ các tài khoản kiểm toán và lưu trữ nhật ký.

Bước 2. Lấy các vùng lưu trữ từ Route 53

Trong bước này, chúng ta lấy các vùng lưu trữ từ Amazon Route 53.

client = boto3.client(

‘route53’,

aws_access_key_id=ACCESS_KEY,

aws_secret_access_key=SECRET_KEY,

aws_session_token=SESSION_TOKEN,

)

response = client.list_hosted_zones()

Route53 hỗ trợ Private hosted zone, chỉ có thể giải quyết được từ bên trong một VPC. Như một thực hành tốt, bất kỳ mục nhập DNS nào chỉ có tính nội bộ nên được thiết lập dưới một Private hosted zone. Vì chúng ta chỉ quan tâm đến các record DNS có thể giải quyết từ bên ngoài, Private hosted zones sẽ được lọc ra khỏi bước tiếp theo.

Bước 3: Lấy A records từ hosted zone

Ở bước này, chúng ta sẽ lấy các record tài nguyên trong một hosted zone từ bước trước.

response = client.list_resource_record_sets(

HostedZoneId='<HostedZoneID>’

)

Route 53 hỗ trợ nhiều loại record DNS như CNAME, PTR, TXT và những loại khác. Chúng ta chỉ quan tâm đến loại record A không được đặt tên định danh (non-aliased A record), được sử dụng để liên kết địa chỉ IP với record DNS. Tất cả các loại record khác sẽ được lọc bỏ ở bước tiếp theo.

Bước 4: Xác định xem bạn có sở hữu EIP hay không

Một mẫu phổ biến để quản lý các mục nhập DNS cho các khối lượng công việc đối ngoại được lưu trữ trên các phiên bản EC2 là bằng cách ánh xạ tên miền đến Elastic IPs. Elastic IPs cung cấp địa chỉ IPv4 tĩnh có thể được liên kết với các phiên bản EC2 để các thay đổi đối với địa chỉ IP công khai trên phiên bản EC2 có thể được thực hiện một cách mượt mà với record DNS và thế giới bên ngoài. Một phương pháp để xác định xem EIP vẫn thuộc sở hữu của tài khoản hay không là quét các nhật ký CloudTrail để xem liệu có thực hiện cuộc gọi API DisassociateAddress cho EIP hay không. Như mô tả trong đoạn mã bên dưới, chúng ta cũng có thể sử dụng API EC2 để mô tả địa chỉ IP – một lỗi trong phản hồi sẽ chỉ ra rằng EIP hiện không thuộc sở hữu của tài khoản.

client = boto3.client(

‘ec2’,

aws_access_key_id=ACCESS_KEY,

aws_secret_access_key=SECRET_KEY,

aws_session_token=SESSION_TOKEN,

)

response = client.describe_addresses(

PublicIps=[‘<IP Address>’]

)

Bước 5: Xử lý các trường hợp khi EIP không thuộc sở hữu của bạn

Các địa chỉ IP được tìm thấy không thuộc sở hữu của bạn có thể được xử lý theo nhiều cách khác nhau. Chúng có thể được xuất ra một bucket S3 hoặc thông báo đến một nhóm sử dụng một sự kiện SNS. Như một quá trình khắc phục, bạn có thể kích hoạt phương thức change_resource_record_sets() để xóa record vi phạm, cho đó bạn có thể sử dụng role aws-controltower-AuditAdministratorRole. Trong trường hợp của chúng tôi, một báo cáo Audit về các phát hiện được xuất ra một bucket S3; mỗi record trong đầu ra chứa số tài khoản AWS, ID của Hosted Zone, Record Set Name, địa chỉ IP, và nếu địa chỉ IP thuộc sở hữu của tài khoản hay không.

Các ví dụ sử dụng khác

Chúng tôi đã mô tả chi tiết về tình trạng record DNS lơ lửng trong bài viết này. Dưới đây là một số ví dụ khác về các tình huống có thể sử dụng cơ chế này:

Xác định tài khoản AWS nào sở hữu một địa chỉ IP công cộng cụ thể hoặc địa chỉ Elastic IP.
Tìm hiểu có bao nhiêu tài khoản AWS đã bật Security Hub, GuardDuty hoặc các dịch vụ tương tự.
Kích hoạt VPC Flow logs trên tất cả các tài khoản của bạn.
Thu thập thông tin về các ổ đĩa gp2 trên tất cả các tài khoản của bạn có thể được chuyển đổi sang gp3.

Mặc dù các ví dụ trên có thể gợi ý rằng bạn muốn luôn đọc hoặc cập nhật tất cả các tài khoản trong AWS Organizations của bạn, nhưng bạn cũng có thể nhắm vào một tập hợp nhỏ hơn các tài khoản cho các tình huống sử dụng cụ thể mà có thể không áp dụng rộng rãi trên tất cả các tài khoản của bạn. Bạn có thể khám phá được nhiều tình huống khác nơi cơ chế này có thể được sử dụng.

Kết luận

Các dịch vụ Quản lý và Quản trị AWS cung cấp các giải pháp cho nhiều trường hợp sử dụng thông thường và chúng tôi liên tục nâng cao chúng để hỗ trợ nhu cầu quản trị, bảo mật và tuân thủ của bạn với sự cố gắng tối thiểu. Trong bài đăng này, chúng tôi mô tả cách bạn có thể sử dụng Tài khoản kiểm toán AWS Control Tower để kiểm tra hoặc ảnh hưởng đến các thay đổi trên các tài khoản khác trong AWS Organizations của bạn, bằng cách sử dụng AWS Lambda. Chúng tôi đã minh họa điều này với một bản triển khai mẫu cho một trường hợp sử dụng. Cơ chế này cung cấp cho bạn một lựa chọn tiện lợi để quản lý theo cách có hệ thống các trường hợp sử dụng đa tài khoản của bạn. Bạn có thể tận dụng các role và mối quan hệ mà Control Tower tạo ra cho bạn, vì vậy bạn không cần phải phát triển một giải pháp tùy chỉnh cho mục đích này.

Các tài nguyên bổ sung

Bài được dịch từ bài viết trên AWS Blogs, bạn có thể xem bài viết gốc tại đây.