1. Giới thiệu

Ngày nay, có nhiều công ty chuyển sang sử dụng cloud nhiều hơn và AWS là lựa chọn hàng đầu của họ. Khi dịch vụ, hệ thống của công ty càng lớn, đòi hỏi công ty cần một bên thứ ba giúp họ cải thiện hệ thống cũng như kiểm tra, xem xét các vấn đề bảo mật trong hệ thống của mình.

Để bên thứ ba có thể khảo sát được hệ thống của mình, các công ty sẽ phải làm cách nào đó cấp quyền cho bên thứ ba truy cập vào tài nguyên của mình. Công ty có thể tạo ra một tài khoản cùng với mật khẩu và trao cho bên thứ ba để họ truy cập vào AWS của mình, nhưng làm cách đó có rủi ro bảo mật rất cao. Thay vào việc tạo một tài khoản cùng mật khẩu để cung cấp cho bên thứ ba thì cross-account IAM Role là một lựa chọn tốt.

Cross-account IAM role là một quyền mà công ty tạo ra và cung cấp nó cho bên thứ ba, bên thứ ba này sẽ dựa vào quyền đó mà truy cập vào tài nguyên của công ty. Role này không đòi hỏi mật khẩu và nó quản lý được 2 thứ sau:

• Tài khoản nào của bên thứ ba được cho phép để truy cập vào tài nguyên.
• Loại tài nguyên nào mà bên thứ ba có thể truy cập được.

Giả sử công ty sử dụng AWS là công ty A và bên thứ ba mà công ty A muốn thuê để kiểm tra cloud cho là công ty B.

2. Vấn đề

Khi công ty A tạo Cross-account IAM role bình thường và đưa link đăng nhập cho công ty B sử dụng thì vấn đề confused deputy có thể xảy ra.

Nghĩa là, khi công ty B cũng làm việc với công ty C và công ty B yêu cầu công ty C đưa cho mình link để truy cập AWS như công ty A đã làm, thì lúc này công ty C có thể đoán hay bằng cách nào đó biết link của công ty A đã tạo và đưa link đó cho công ty B sử dụng.

Bằng cách làm như thế, công ty C đã lừa công ty B rằng link họ đưa là AWS của mình nhưng thực chất lại là của công ty A, công ty B không biết mình đã bị lừa và làm việc bình thường với AWS của công ty A.

Ở ví dụ trên, công ty C sẽ không chiếm được quyền truy cập vào AWS của công ty A nhưng lại khiến công ty B truy cập một cách không mong muốn vào công ty A. Việc công ty B truy cập vào AWS của công ty A là hợp lệ khi nhìn từ phía công ty A nên vấn đề này được gọi là confused deputy:

Ở hình trên thì bên trái là công ty A, ở giữa là công ty B và bên phải là công ty C.

Để giải quyết vấn đề trên, khi tạo cross-account IAM role, bạn nên sử dụng External ID

Chú ý là khi sử dụng External ID, công ty B chỉ có thể sử dụng AWS của công ty A thông qua CLI hoặc SDK chứ không thể sử dụng switch role trên AWS console như thông thường.

3. Tạo cross-account IAM role một cách bảo mật

External ID là một string hay một dãy số mà công ty B sử dụng để định danh các role mà mình sẽ dùng. 

Khi công ty A và công ty C tạo role cho công ty B sử dụng, thì công ty A và C phải yêu cầu công ty B trao cho một external ID để định danh cho từng role.

Công ty B phải hiểu rõ được rằng external ID này là unique đối với từng role của từng công ty, mỗi khi công ty A hay C đưa role để công ty B sử dụng, công ty B phải xác định external ID cho role đó. Bằng cách làm như thế, dù công ty C có cố tình đưa role của công ty A cho công ty B đi chăng nữa, B vẫn nắm được rằng mình đang làm việc với C nên sẽ dùng external ID đã trao đổi trước với C, dẫn tới kết quả là thất bại vì role mà C cố tình đưa đã không khớp với external ID mà B cung cấp.

Các bước thực hiện như sau:

• Công ty A lúc tạo cross-account role sẽ nhập Account ID của công ty B và External ID đã trao đổi trước đó với công ty B:

• Công ty A tạo role xong sẽ cung cấp role ARN cho công ty B sử dụng:

• Công ty B sau khi nhận được role trên từ A, sẽ thực thi câu lệnh để có thể sử dụng role đó. Chú ý là khi role có external ID, công ty B sẽ không thể sử dụng AWS console để truy cập vào tài nguyên của A mà phải sử dụng CLI hoặc SDK:

// assume role không có external ID sẽ báo lỗi
$ aws sts assume-role --role-arn arn:aws:iam::222222222222:role/hungdv-CA --role-session-name tmp

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::111111111111:user/accountB is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::222222222222:role/hungdv-CA


// assume role có external ID sẽ thành công
$ aws sts assume-role --role-arn arn:aws:iam::222222222222:role/hungdv-CA --external-id 123456789 --role-session-name tmp
{
    "Credentials": {
        "AccessKeyId": "ASIASP...",
        "SecretAccessKey": "tWJcc0IoW3S...",
        "SessionToken": "abcxyz...",
        "Expiration": "2021-03-17T18:07:04+00:00"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "AROASPQBOKCITOPP2PJOM:tmp",
        "Arn": "arn:aws:sts::222222222222:assumed-role/hungdv-CA/tmp"
    }
}

Các Best Practices nâng cao cho Cross-Account Access trong AWS

Cross-Account access giúp bạn cho phép người dùng hoặc dịch vụ từ tài khoản khác (hoặc tổ chức khác) truy cập tài nguyên AWS của bạn một cách có kiểm soát. Tuy nhiên, ngoài việc sử dụng External ID để tránh tấn công confused deputy như trong bài gốc, có một số best practices nâng cao mà các chuyên gia bảo mật AWS thường áp dụng để giảm rủi ro bảo mật và duy trì kiểm soát chặt chẽ khi làm việc với nhiều tài khoản:

1. Áp dụng nguyên tắc Least Privilege cho tất cả Role Cross Account

Khi tạo IAM Role cho truy cập xuyên tài khoản, bạn nên đảm bảo:

• Role chỉ có các quyền cần thiết nhất để thực thi công việc, không cấp quyền rộng hơn mức cần thiết.
• Không dùng wildcard (*) trong policy cho đến khi thực sự cần thiết.
• Xem xét tách quyền theo chức năng nhỏ hơn thay vì gộp tất cả vào một role đơn.

Việc này giúp giảm bề mặt tấn công và tránh việc một role bị lợi dụng để thực hiện nhiều hành động ngoài phạm vi dự kiến.

2. Sử dụng IAM Access Analyzer để kiểm tra trust policy

AWS IAM Access Analyzer có thể tự động phát hiện các trust policy hay resource policy có khả năng cấp quyền cross-account không mong muốn.
Bạn nên:

• Định kỳ xem kết quả phân tích Access Analyzer để tìm role có trust relationship quá rộng.
• Sử dụng chức năng này như một phần của quy trình kiểm tra bảo mật hàng tháng.

Công cụ này giúp bạn phát hiện các cấu hình vô tình cho phép truy cập từ một bên thứ ba mà bạn không dự định.

3. Thiết lập guardrails với AWS Organizations và SCP

Khi quản lý nhiều tài khoản AWS dưới một tổ chức, Service Control Policies (SCPs) từ AWS Organizations giúp bạn:

• Áp dụng những giới hạn quyền tối thiểu ở cấp tổ chức
• Ngăn chặn việc tạo role hoặc policy có quyền vượt quá phạm vi cho phép
• Giảm rủi ro do sai sót cấu hình ở tài khoản con

SCP hoạt động như một “trường bảo vệ” bên ngoài các role và policy, giúp bạn kiểm soát quyền ở quy mô lớn hơn.

4. Áp dụng session tags / role tags để kiểm soát quyền nâng cao

Khi số lượng role và trust relationship tăng lên, việc quản lý từng role một có thể trở nên phức tạp. Đặc biệt trong SaaS hoặc khi nhiều ứng dụng assume role, bạn có thể dùng:

• Session tags / role tags để kiểm soát quyền theo thuộc tính
• Áp dụng điều kiện ABAC (Attribute Based Access Control) thay vì phân quyền tĩnh

Tags giúp bạn gán quyền dựa trên các thuộc tính của phiên assume role (như “project”, “environment”, “team”) thay vì viết policy thủ công cho mỗi trường hợp.

5. Giám sát và audit activity cross-account

Một phần quan trọng của bảo mật là theo dõi hành vi truy cập:

• Bật logging cho CloudTrail và đảm bảo logs được gửi về centralized S3/CloudWatch
• Thiết lập cảnh báo khi có hoạt động assume role không thường xuyên hoặc từ các nguồn IP bất thường
• Định kỳ rà soát các session assume role và phản hồi kịp thời nếu phát hiện dấu hiệu đáng ngờ

Việc này giúp bạn phát hiện các hoạt động trái phép sớm hơn, ngay cả khi attacker đã có thông tin để assume role.

6. Giới hạn thời gian session và yêu cầu điều kiện xác thực

AWS cung cấp tùy chọn để giới hạn thời gian một session assume role có hiệu lực. Bạn nên:

• Thiết lập thời gian session ngắn hơn theo mức độ nhạy cảm của quyền
• Kết hợp với MFA hoặc điều kiện IP/region để tăng mức kiểm soát

Việc giới hạn thời gian và điều kiện cũng là một cách giảm rủi ro khi credential bị lộ.

7. Tận dụng temporary credentials & federation (IAM Identity Center / SSO)

Thay vì dùng IAM Users lâu dài để assume cross-account roles, bạn nên:

• Sử dụng federation với các Identity Provider (IdP) như AWS IAM Identity Center hoặc OIDC
• Người dùng assume role bằng cách authenticate qua IdP, nhận temporary credentials
• Tránh sử dụng access keys cố định — giảm rủi ro bị lộ lâu dài

Điều này giúp bạn duy trì mô hình bảo mật hiện đại mà AWS khuyến nghị, đặc biệt trong môi trường lớn với nhiều team và ứng dụng.

INDA Academy tự hào là đơn vị tiên phong trong việc đào tạo phân tích dữ liệu và AI chuyên sâu, đặc biệt cho khối ngành Ngân hàng – Tài chính – Bảo hiểm tại Việt Nam. Sau hơn 12 năm “thực chiến” cùng những dòng chảy dữ liệu khổng lồ, chúng tôi đã xây dựng nên một hệ sinh thái đào tạo toàn diện, giúp hàng nghìn học viên chuyển mình từ người mới bắt đầu trở thành những chuyên gia lành nghề, sẵn sàng đáp ứng tiêu chuẩn khắt khe của các doanh nghiệp lớn.

Điểm khác biệt lớn nhất tại INDA chính là triết lý đào tạo dựa trên các dự án thực tế (Project-based) và lộ trình cá nhân hóa nhờ ứng dụng AI. Chúng tôi không chỉ dạy bạn cách sử dụng công cụ, mà còn truyền tải tư duy khai phá giá trị từ dữ liệu để đưa ra quyết định kinh doanh chính xác.

Tìm hiểu thêm về các khóa học TẠI ĐÂY:
Lộ trình đào tạo Data Engineer
Lộ trình đào tạo Data Analyst
Lộ trình đào tạo Tester
Khóa học Data Engineer nâng cao – Thực chiến 5 dự án doanh nghiệp
Khóa học Data Analyst nâng cao – Thực chiến 5 dự án doanh nghiệp

Link tham khảo:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html

Nguồn: Internet