Tổng hợp kiến thức “advanced identity in aws”

[ThanhQuyen]

🚀 TỔNG HỢP KIẾN THỨC “ADVANCED IDENTITY IN AWS”


Quản trị danh tính và truy cập (Identity & Access Management – IAM) là nền tảng quan trọng nhất khi xây dựng hệ thống AWS an toàn. Trong môi trường doanh nghiệp, kiến trúc thường dùng nhiều tài khoản AWS cùng các mô hình xác thực nâng cao để đảm bảo bảo mật, phân quyền và kiểm soát.


🌟 1. AWS Organizations – Quản lý nhiều tài khoản AWS tập trung


AWS Organizations cho phép doanh nghiệp:

• Tạo và quản lý nhiều tài khoản AWS trong cùng một tổ chức.
• Dùng Management Account làm tài khoản điều khiển trung tâm.
• Gộp thanh toán về một nơi (Consolidated Billing).
• Tự động tạo tài khoản bằng API.
• Chia tài khoản theo mô hình:
• • Theo business unit (Sales, Retail, Finance)
  • Theo environment (Prod, Dev, Test)
  • Theo project (Project 1, Project 2…)

Mỗi tài khoản chỉ được thuộc duy nhất một Organization.


🌟 2. Organizational Units (OU) – Nhóm tài khoản theo mục đích


OU giúp phân nhóm tài khoản theo:

• Bộ phận
• Môi trường
• Dòng đời dự án

Ví dụ:

• OU Sales chứa các tài khoản Sales
• OU Prod chứa toàn bộ tài khoản sản xuất
• OU Project-1 chứa tài khoản phục vụ dự án 1

Việc phân nhóm rõ ràng giúp áp chính sách và kiểm soát quyền tốt hơn.


🌟 3. Service Control Policies (SCP) – Lớp bảo mật số 1 cho toàn Organization


SCP là lớp “tường lửa quyền hạn” trong AWS Organizations.

• SCP áp lên OU hoặc tài khoản.
• Chỉ được Allow những gì được phép – còn lại bị chặn hết.
• Management Account vẫn có quyền full (SCP không ảnh hưởng).
• SCP áp cho cả Users & Roles trong tài khoản đó.

Ví dụ:

• OU Prod → không được dùng Redshift
• OU HR → không được dùng Lambda
• OU Finance → chặn Athena

Nhờ SCP, doanh nghiệp đảm bảo các tài khoản chỉ được dùng đúng dịch vụ cho phép.


🌟 4. IAM Conditions – Điều kiện kiểm soát truy cập


IAM hỗ trợ nhiều điều kiện (condition) để tăng độ chi tiết khi phân quyền:

• aws:SourceIp – chỉ cho phép truy cập từ IP công ty
• aws:RequestedRegion – hạn chế user chỉ được deploy ở 1 region
• ec2:ResourceTag – chỉ cho phép tác động vào tài nguyên có tag “Owner=Dev”
• aws:MultiFactorAuthPresent – bắt buộc phải bật MFA

Đây là cách để áp chính sách Zero Trust hiệu quả.


🌟 5. IAM cho S3 – Phân biệt quyền ở mức Bucket và Object

• Quyền s3:ListBucket áp dụng ở mức Bucket
  → ARN dạng: arn:aws:s3:::bucket-name
• Các quyền GetObject / PutObject / DeleteObject áp dụng ở mức Object
  → ARN dạng: arn:aws:s3:::bucket-name/*

Kiến thức này cực quan trọng khi viết chính sách cross-account hoặc public access.


🌟 6. aws:PrincipalOrgID – Chỉ cho phép truy cập từ AWS Organization của bạn


Trong Resource Policy (S3, SNS, SQS…), có thể dùng điều kiện:

"aws:PrincipalOrgID": "o-xxxxxxx"


Điều này đảm bảo:

👉 Chỉ những account thuộc Organization của bạn mới truy cập được tài nguyên đó.
Dùng cực hiệu quả để chặn truy cập ngoài công ty.


🌟 7. IAM Roles vs Resource-Based Policies – Hai cách cấp quyền cross-account


Có 2 cách chia sẻ tài nguyên giữa các tài khoản: 1) Resource Policy (ví dụ: S3 bucket policy)

• Tài nguyên tự mở quyền cho account khác.
• User không mất quyền gốc của họ.

2) IAM Role

• User assume role từ account khác.
• Khi assume ⚠️ họ mất quyền gốc và dùng quyền của role.

Ví dụ trong tài liệu:

User ở Account A cần scan DynamoDB ở Account A và đẩy dữ liệu sang S3 của Account B.
→ Dùng Resource Policy sẽ hợp lý hơn Role, vì user không mất quyền quét DynamoDB.


🌟 8. EventBridge Security – Quyền khi rule kích hoạt target


Khi EventBridge Rule chạy, nó phải có quyền tác động lên target.

• Với Lambda, SNS, SQS… → dùng resource-based policy
• Với Kinesis, ECS task, Systems Manager → cần IAM Role

🌟 9. IAM Permission Boundaries – Giới hạn quyền tối đa của user/role


Permission Boundary:

• Là chính sách xác định mức quyền tối đa user/role có thể nhận.
• Chỉ áp dụng cho user và role (không áp dụng Group).
• Kết hợp tốt với SCP.

Use case:

• Cho phép developer tự gán policy nhưng không thể tự nâng quyền lên admin.
• Hạn chế quyền của một user cụ thể mà không ảnh hưởng OU/tài khoản.

🌟 10. IAM Policy Evaluation Logic – Cách AWS quyết định Allow/Deny


AWS đánh giá quyền dựa trên thứ tự:

1. Explicit Deny → thắng tất cả
2. Allow → chỉ hiệu lực nếu không bị deny khác
3. Implicit Deny → mặc định nếu không có allow

Hiểu logic này giúp debug lỗi IAM dễ hơn.


🌟 11. Amazon Cognito – Xác thực user cho ứng dụng web/mobile


Cognito gồm hai phần: 🔹 Cognito User Pools – Quản lý user

• Đăng ký / đăng nhập
• Reset password
• Xác thực email / phone
• Hỗ trợ MFA
• Đăng nhập bằng Facebook, Google, SAML…
• Tích hợp sẵn với API Gateway và Application Load Balancer

🔹 Cognito Identity Pools – Cấp AWS credentials cho user

• Exchange token từ user pool → thành temporary AWS credentials
• User được truy cập trực tiếp vào AWS (ví dụ S3)
• Có role riêng cho:
• • authenticated users
  • guest users

🌟 12. IAM Identity Center (Successor to AWS SSO)


AWS IAM Identity Center cung cấp:

• Single Sign-On cho toàn bộ account trong Organization
• Truy cập các ứng dụng doanh nghiệp: Salesforce, Box, Microsoft 365…
• SSO vào EC2 Windows
• Tích hợp với:
• • Built-in Identity Store
  • Active Directory
  • Okta, OneLogin…

👉 Khái niệm quan trọng: Permission Sets

• Tập hợp IAM policies
• Assign cho user/group để cấp quyền vào từng tài khoản
• Hỗ trợ Multi-Account Access
• Hỗ trợ ABAC – Attribute-Based Access Control
  (quyền dựa vào thuộc tính người dùng: cost-center, title…)

Ví dụ:
Permission Set “DB Admins” → cho admin database trên cả Dev và Prod.


🌟 13. AWS Directory Services


AWS hỗ trợ ba dạng Active Directory: 🔹 AWS Managed Microsoft AD

• Tạo AD trong AWS, quản lý người dùng tại chỗ
• Tích hợp MFA
• Thiết lập trust với on-prem AD

🔹 AD Connector

• Proxy chuyển yêu cầu từ AWS về AD on-prem để xác thực
• Người dùng quản lý hoàn toàn tại on-prem

🔹 Simple AD

• Directory đơn giản, độc lập
• Không thể join vào on-prem AD

🌟 14. IAM Identity Center với Active Directory


Identity Center có thể:

• Kết nối thẳng AWS Managed AD
• Hoặc kết nối AD on-prem thông qua AD Connector
• Hoặc thiết lập two-way trust qua AWS Managed Microsoft AD

🌟 15. AWS Control Tower – Tự động hóa quản trị multi-account


Control Tower giúp:

• Tạo môi trường multi-account theo best practice
• Tự động hóa quản lý chính sách
• Theo dõi compliance qua dashboard
• Dùng Guardrails để đảm bảo tuân thủ

Có 2 loại Guardrails:

• Preventive – dùng SCP (ví dụ: chặn tạo resource ở region không cho phép)
• Detective – dùng AWS Config (ví dụ: phát hiện resource không có tag → tự động remediate)