1. Phân biệt AWS Organization Account và IAM User

Đừng nhầm lẫn giữa hai khái niệm Account và User khi sử dụng AWS:

• Account là tài khoản root của bạn để bạn đăng nhập vào AWS, account luôn có email và thẻ credit đính kèm.
• User là tài khoản mà account của bạn tạo ra và phân phát cho người khác dùng. User không cần email, chỉ cần username và password.

=> Account chính là tài khoản để tạo và quản lý nhiều User trong AWS.

Xem thêm về IAM tại đây.

 

Thông thường, khi chúng ta đăng ký sử dụng AWS ta chỉ đăng ký một root account và sau đó từ root account này tạo ra một root IAM User, ta thường đăng nhập vào AWS console bằng root IAM User (chứ không bằng root account) và tạo ra nhiều IAM User khác cho những engineer khác sử dụng. Root account chỉ được sử dụng khi cần setting những thứ có quyền cao nhất, hoặc để chi trả tiền chi phí mà thôi. Khi bạn đăng ký root account trên AWS, bắt buộc bạn phải nhập thẻ credit vào, còn IAM User thì chỉ cần tạo ra username và password là xong.

Như vậy, trong trường hợp, bạn muốn có những account khác nhau để quản lý các AWS khác nhau nhằm mục đích phân chia rạch ròi, bảo mật,... các ứng dụng hay phòng ban thì bạn thường sẽ làm gì?

Ta không thể sử dụng IAM Group cho mục đích trên được vì IAM chỉ là nơi để quản lý các quyền hạn, không phải là nơi để phân cấp các dịch vụ. Và IAM Group không thể chứa các IAM Group con và không thể quản lý các khoản thanh toán riêng biệt được. Đây là những vấn đề liên quan tới tổ chức chứ không liên quan tới phân quyền.

Ta có thể đăng ký AWS bằng nhiều account với nhiều email khác nhau, khi cần sử dụng dịch vụ hoặc phòng ban nào đó, ta sẽ đăng nhập vào account tương ứng để sử dụng. Làm như thế sẽ rất mất công logout rồi login nhiều lần khác nhau, vấn đề thanh toán tiền cũng bị hoàn toàn tách biệt nhau.

=> AWS Organization chính là lựa chọn cho bạn.

 

2. AWS Organization dùng để làm gì?

AWS Organization là nơi quản lý các account, các account này chỉ có một hoặc một nhóm người có quyền hạn cao nhất quản lý, không phải là IAM User mà các developer sử dụng để thao tác với AWS.

Mục đích của AWS Organization như mình đã nói ở trên, để phân chia quản lý theo phòng bạn, dịch vụ, môi trường vận hành,...

 

Bài toán ví dụ: Công ty của bạn có 2 team ứng với 2 product khá to là ProductA và ProductB, mỗi team lại có nhiều engineer sử dụng AWS để phát triển, mỗi product lại có 2 môi trường là prod và dev.

Về phía quản lý, bạn muốn những điều sau:

• Bạn muốn 2 team phải được quản lý riêng biệt, thanh toán chi phí cho AWS riêng biệt nhưng vẫn gộp được lại ở account cao nhất của bạn để thanh toán 1 lần. Điều này giúp việc kiểm toán của công ty được dễ dàng hơn.
• Bạn cũng muốn rằng việc thay đổi qua lại các account cũng phải nhanh chóng tiện lợi chứ không logout rồi login như cách thông thường nói phía trên.

Về phía các team, họ sẽ muốn những điều sau:

• User ở các môi trường khác nhau sẽ không thể nhìn thấy tài nguyên của nhau. Nghĩa là user trên dev sẽ không nhìn thấy các tài nguyên trên môi trường prod.
• ProductA không được nhìn thấy và thao tác với các tài nguyên của ProductB nếu không được cho phép và ngược lại.

 

Với những điều kiện trên, bạn có nghĩ rằng sử dụng IAM Group là được?

IAM Group sẽ không thoả mãn những yêu cầu sau:

• Quản lý 2 team riêng biệt, quản lý thanh toán riêng biệt.
• IAM Group mục đích là để phân chia quyền, tức là ở mức độ thao tác chứ không phải ở mức độ quản lý. Nhìn từ phía người quản lý AWS Organization mới là lựa chọn thích hợp.

 

AWS Organization sẽ giúp bạn thoả mãn các điều kiện trên, nó là nơi quản lý các account, các Organizational Unit (OU) (là ProductA, ProductB mình nói ở trên) có thể chứa nhiều account khác nhau. Mỗi account phải có một email riêng biệt, các công ty thường lấy chung một địa chỉ email với các prefix khác nhau, ví dụ [email protected] và [email protected] chẳng hạn.

Vậy ta sẽ thiết kế AWS Organization như thế nào trong trường hợp này?

Trước khi tới thiết kế, ta cần xem qua hoạt động của AWS Organization.

 

3. Cách hoạt động của AWS Organization

3.1. AWS Organization có xung đột quyền với các đơn vị quản lý quyền khác không?

Bạn xem bài viết cụ thể về cách tính quyền trong AWS tại https://blog.daovanhung.com/post/cach-tinh-quyen-trong-aws.

Một câu hỏi đặt ra là nếu AWS Organization cũng phân chia quyền thì IAM để làm gì và 2 bên có xảy ra xung đột nhau không?

IAM dùng để tạo và gán quyền ở mức tế bào, IAM có thể gán cho user, service,... AWS Organization nhìn từ phía quản lý để phân quyền, như VD trên thì TeamA không được truy cập vào tài nguyên của TeamB và ngược lại.

AWS Organization và IAM phải giao với nhau thì mới có thể sử dụng được. Nếu IAM có cấp quyền cho TeamA sử dụng tài nguyên nào đó của TeamB nhưng AWS Organization không cho phép thì cũng không thể. Và, dù AWS Organization có cho TeamA truy cập tài nguyên của TeamB nhưng IAM không cho phép cũng không thể. 

Tóm lại là AWS Organization và IAM phải giao nhau.

         

Với cách hoạt động như vậy, dù cho user có vô thức cấp quyền cho user khác đi chăng nữa, user khác đó cũng sẽ cũng không truy cập được vào nếu như AWS Organization không cho phép. Điều này giúp cho vấn đề bảo mật được chặt chẽ hơn, vì user làm việc với IAM rất nhiều và người quản lý không quản lý được mọi hoạt động của các user.

 

3.2. Quản lý quyền trong AWS Organization

AWS Organization có thể gán quyền cho organization root, organizationl unit (OU) hoặc account:

• Khi gán quyền cho organization root, mọi OU và account trong organization đó sẽ thừa kế quyền đó.
• Khi gán quyền cho một OU, những OU và account nằm trong OU đó sẽ thừa kế quyền đó.
• Khi gán quyền cho một account, quyền đó chỉ tác động duy nhất tới account đó.
• Quyền của một account chính là giao của các quyền kế thừa và quyền được gán cho chính mình. Chính vì lý do này nên bạn phái gán quyền ở tất cả các tầng của account bao gồm cả chính account thì account đó mới có quyền.

Ví dụ: Tuy account của bạn nằm trong một OU có AWSFullAccess nhưng nếu bạn không gán quyền cho chính account đó thì account đó cũng không có quyền gì hết.

• Quyền trong AWS Organization chỉ là nơi cho phép có thể sử dụng quyền đó chứ không phải là nơi xác định sẽ được sử dụng quyền đó. Bạn phải chỉ định quyền đó trong IAM permission thì account mới có quyền chính thức.

4. Thiết kế

Với bài toán đặt ra ở phần trên, ta có thể thiết kế AWS Organization như sau:

    

Ở hình trên thì:

• SECURITY là OU chứa các account chuyên về thiết lập security trong công ty, các account này có quyền hạn đặc biệt như thao tác với log, cloudtrail, security hub,...
• INFRA là OU chứa các môi trường và các team, đây là nơi để các engineer sử dụng aws để phát triển sản phẩm
• SANDBOX là OU chứa các account để test thử AWS, bạn dùng các account ở đây để test các thiết lập thử rồi mới thiết lập ở môi trường chính.

 

Mỗi OU trên biểu đồ trên sẽ có ít nhất một account nằm trong đó, account có email mình ghi ở một bên của OU.

Account nằm trong OU con sẽ phải nằm trong vùng phân quyền của OU cha ông phía trên. Ví dụ, OU PROD trong INFRA chỉ có thể chỉ định quyền nằm trong khoảng quyền hạn của OU INFRA, không thể thiết lập quá quyền hạn này. Lưu ý rằng, mặc định các account sẽ không thấy tài nguyên của nhau, nếu bạn muốn account này có thể nhìn thấy tài nguyên của account kia thì phải sử dụng chức năng switch role của AWS Organization.

OU productA và productB nằm ở 2 nhánh khác nhau nên sẽ không có quyền gì của nhau, productA không thể nhìn thấy và truy cập vào tài nguyên của productB và ngược lại.

Switch account trong AWS Organization sẽ không mất công logout login khi bạn tạo nhiều account như cách truyền thống.

Bạn có thể tham khảo cách truy cập các account bằng cách switch role tại https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html

 

Bài này chỉ trong phạm vi giới thiệu và trình bày lý thuyết về AWS Organization. Phần thực hành có dịp sẽ viết ở một bài khác.

 

Link tham khảo:

https://aws.amazon.com/organizations/

https://aws.amazon.com/organizations/getting-started/best-practices/

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html