VTI TechBlog!

  • TOPトップ
  • Bài Viết投稿
  • Sự Kiệnイベント
  • Về Chúng Tôi私達について
  • Tuyển Dụng採用情報
  • vti.com.vnホームページ
menu
  • TOPトップ
  • Bài Viết投稿
  • Sự Kiệnイベント
  • Về Chúng Tôi私達について
  • Tuyển Dụng採用情報
  • vti.com.vnホームページ
  • HOME
  • Bài Viết
  • Quản lý AWS IAM theo AWS Security Best Practise

Bài Viết2022.09.05 Bạch Thịnh

Quản lý AWS IAM theo AWS Security Best Practise

iam_best_practise
Share
Tweet
Share
Pin
0 Shares
Post Views: 1,457

Lời nói đầu

Khi sử dụng AWS, bất kể người dùng nào đều bắt đầu bằng việc tạo tài khoản. Tài khoản này được gọi là tài khoản Root hay gọi nôm na là tài khoản gốc rễ. Mọi tài khoản được sinh ra sau sẽ có liên đới với tài khoản Root này, cũng như AWS Service được tạo ra.

Tài khoản mới được sinh ra và service được sinh ra từ tài khoản đó như cành và lá trên một cái cây. Để có được một cái cây khỏe mạnh vững chắc, thì cần phải có giải pháp để quản lý, kiểm tra thường xuyên để cho cây luôn được khỏe mạnh.

Dưới đây là xin tóm gọn những điểm cần chú ý khi sử dụng IAM User đối với môi trường AWS dựa theo tham khảo của Security Best Practise của AWS.

Nội dung bài :

  • Không sử dụng tài khoản Root
  • Cài đặt MFA cho tất cả tài khoản kể cả tài khoản Root
  • Quản lý user theo User Group và phần quyền theo Role
  • Chỉ cấp quyền cần thiết - least-privilege permissions
  • Khoang vùng đối tượng áp dụng trong khai báo Policy
  • Sử dụng Temporary Credential - Chứng chỉ tạm thời đối với tất cả hoạt động liên quan với AWS
  • Quy định chu kì làm mới đối với tất cả chứng chỉ - chứng thực - mật khẩu
  • Thực hiện kiểm tra và xóa users, roles, permissions, policies, and credentials không sử dụng
  • Sử dụng dịch vụ IAM Access Analyzer kiểm định Policy

Không sử dụng tài khoản Root

Để bắt đầu sử dụng dịch vụ AWS Services, mỗi người dùng đều bắt đầu bằng tài khoản Root. Tài khoản này chứa toàn bộ quyền điều khiển của cả môi trường AWS.

Cần tránh sử dụng tài khoản Root khi không cần thiết. Người dùng nên bắt đầu bằng việc tạo các User Group như với quyền hạn được định nghĩa sẵn từ AWS (AWS managed - job function) hoặc quyền hạn được định nghĩa với phạm vi bó hẹp phù hợp với tác vụ được định nghĩa thông qua Policy và được quản lý bằng Role.

Quản lý tài khoản AWS Account theo mô hình Organization.

AWS Organizations の用語と概念 - AWS Organizations

Cài đặt MFA cho tất cả tài khoản kể cả tài khoản Root

Bất kì tài khoản nào được tạo ra trong môi trường AWS đều cần thiết cài đặt bảo vệ 2 lớp. Với cách bảo vệ đơn giản nhất là cài đặt MFA (Multi-Factor Authentication).

Người dùng có thể dễ dàng cài đặt thông qua, IAM Console cùng với thiết bị MFA cứng hoặc mềm như Google Authenticator, Twillo Authy Authenticator.

Enable Multi-Factor Authentication (MFA) – AWS IAM – Twwip

Quản lý user theo User Group và phần quyền theo Role

Với mỗi user được tạo ra trong môi trường AWS cần được nhóm thành những User Group và cấp quyền thông qua Role (Vai trò). User Group là tập hợp nhiều User có cùng Role (Vai trò) giống nhau. Role là tập hợp của nhiều Policy đơn.

Một User có thể nằm trong nhiều User Group từ đó sẽ có nhiều Role khác nhau. Một User không nằm trong User Group nào thì không được phép cấp bất kì một Role nào hay Policy nào.

複数のAWSアカウント管理 - yoshidashingo

Chỉ cấp quyền cần thiết - least-privilege permissions

Đối với mỗi User Group hay Role, cần định nghĩa quyền truy cập rõ ràng và chỉ cấp quyền cần thiết ứng với Role đã được định nghĩa.

Khi cần thêm quyền không có trong Role thì cần phải tạo Role và tạo User Group mới ứng với quyền cần được cấp. Hạn chế việc cấp quyền trực tiếp cho User hay cấp quyền trực tiếp bằng cách sửa Role.

Phân quyền được khoanh vùng(Permission boundaries) và thiết lập lằn ranh (Permission Guardrail) giữa tầng quyền hạn.

IAM エンティティのアクセス許可境界 - AWS Identity and Access Management

Khoanh vùng đối tượng áp dụng trong khai báo Policy

Khi định nghĩa bất kì một Policy nào, cần sử dụng điều kiện (Conditions) để khoanh vùng đối tượng được áp dụng quyền, khai báo rõ đối tượng được áp dụng Policy, tài nguyên, dịch vụ được truy cập rõ ràng.

Ví dụ : Pricipal A được cho phép Allow thực hiện Action B đối với Resource C, với điều kiện phải Resource C phải thuộc tài khoản X

Tham khảo : Policy References

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PolicyGenerationBucketPolicy",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
           "arn:aws:iam::AWS-account-ID:user/user-name-1", 
           "arn:aws:iam::AWS-account-ID:user/user-name-2"
         ]
      },
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/AWSLogs/organization-id/${aws:PrincipalAccount}/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "organization-id"
        },
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::${aws:PrincipalAccount}:role/service-role/AccessAnalyzerMonitorServiceRole*"
        }
      }
    }
  ]
}

Sử dụng Temporary Credential - Chứng chỉ tạm thời đối với tất cả hoạt động liên quan với AWS

Không sử dụng một chứng chỉ hay chứng thực (Credential) cố định đối với tất cả hoạt động liên quan với AWS. Khi một chứng chỉ hay chứng thực bị lộ hoặc giả mạo sẽ gây ra ảnh hưởng rất nghiêm trọng đến tài nguyên liên quan tới chứng chỉ hay chứng đó, gây sự bất ổn cho toàn bộ môi trường AWS.

Một chứng chỉ hay chứng thực (Credential) chỉ được cấp trong khoảng thời gian cố định và cần được làm mới theo chu kì ngắn hay được còn gọi là Temporary Credential - Chứng chỉ tạm thời.

Đối với hệ thống cần có thời gian làm việc dài với môi trường AWS cần chuyển sang cách sử dụng Profile (Role) thay cho việc sử dụng chứng chỉ hay chứng thực (Credential).

Tham khảo: Hướng dẫn cài đặt AWS Temporary Credential

AWS: EC2 Roles and Instance Profiles - giterror

Quy định chu kì làm mới đối với tất cả chứng chỉ - chứng thực - mật khẩu

Đối với chứng chỉ - chứng thực - mật khẩu hay thông tin bảo mật nào đều cần được quy định chu kì làm mới. Đối với mật khẩu là Password Policy, còn đối với chứng chỉ - chứng thực (Credential) là Expire Time (Thời gian hiệu lực).

Để thực hiện một cách tự động có thể dùng dịch vụ CloudWatch EventBridge để tạo thông báo khi thời gian hiệu lực sắp kết thúc hoặc tự động cập nhật lại thông tin bằng dịch vụ AWS Secret Manager.

Đối với thông tin như Key dùng để mã hóa, AWS có cung cấp dịch vụ KMS mang chức năng tự động làm mới Key theo một khoảng thời gian nhất định.

AWS Secrets Manager(シークレットのローテーション、管理、取得)| AWS

Thực hiện kiểm tra và xóa users, roles, permissions, policies, and credentials không sử dụng

Với users, roles, permissions, policies, and credentials có thời gian không hoạt động dài cần được xóa bỏ hoặc tạm thời vô hiệu hóa (deactived).

Thông qua màn hình IAM Console, người quản trị dễ dàng nắm bắt thông tin hoạt động cuối cùng thông qua mục "last accessed information" của IAM User và Access Advisor.

Access Advisor - Mastering AWS Security [Book]

Sử dụng dịch vụ IAM Access Analyzer kiểm định Policy

IAM Access Analyer có chức năng phân biệt và nhận định tài nguyên hoặc account có sử dụng, có liên quan tới tài nguyên ở bên ngoài. Phân tích kiểm định Policy dựa theo cú pháp và best practices nhanh chóng đưa ra thông tin về Policy chưa chính xác hoặc cần sửa đổi cho người dùng.

IAM Access Analyzer còn có khả năng tạo Policy dựa theo hoạt động của một tài nguyên nào đó dựa theo hoạt động được ghi lại bởi CloudTrail.

Bên cạnh đó, IAM Access Analyzer sẽ định kì scan toàn bộ hệ thống nhằm đưa ra thông tin và phân tích về Policy sớm nhất cho người quản trị.

AWS IAM Access Analyzer | AWS Security Blog
Share
Tweet
Share
Pin
0 Shares
  • Bài Viết

aws accountaws cliaws iamaws organizationsaws stscredentials

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Elastic Beanstalk: Các chiến lược để deploy
Hướng dẫn cài đặt AWS Temporary Credential với Assume Role(Switch Role) kết hợp MFA

RECOMMENDこちらの記事も人気です。

  • Bài Viết
    2020.10.13

    XGBoost - Bài 1: Toàn cảnh về Ensemb…

  • Bài Viết
    2021.6.19

    Amazon Elasticsearch Service Best Pr…

  • Bài Viết
    2021.12.8

    Giới hạn khả năng scale của Lambda v…

  • Bài Viết
    2021.8.23

    DSinRL: Phân tích tình hình Covid-19…

  • Bài Viết
    2019.9.9

    Hướng dẫn căn chỉnh bài viết trên VT…

  • Bài Viết
    2021.10.31

    Connect với EC2 Windows Instance bằn…

  • Bài Viết
    2020.10.8

    Giới thiệu về hệ thống nhúng

  • Bài Viết
    2021.10.31

    Cách mình đã viết Cloudformation tem…

Tags

.Net AI Android ApiGateway APP AWS aws cli AWS Cloud9 AWS Elasticseach aws sts BrSE C# chatbot cloud CloudTeam credentials Data Science devops Docker Elasticseach G1 git golang gryqhon ios IoT java lambda linux luyen thi Machine Learning N2 pmp python RPA s3 SE Serverless solution architect Tangai365 Unit Test vti XGBoost 採用 新卒

Recent Comments

  • Nguyen Tien Su on Nước Nhật vui vẻ – Văn hóa công sở
  • Nguyễn Ngọc Nam on XGBoost – Bài 3: Xây dựng XGBoost model
  • Tan Phan on Cài đặt nhanh AWS Java SDK (StepFunctions)
  • Private123 on Leo núi Phú Sĩ – lên đỉnh cùng VTI

Link

  • VTI VietNam
  • VTI VietNam FB
  • VTI Japan
  • VTI Japan FB

©Copyright2025 VTI TechBlog!.All Rights Reserved.