Trong bài viết trước, Nâng cao khả năng đàn hồi và chuẩn hoá giám sát, chúng ta đã bàn về các kiểu mẫu thiết kế giúp bạn nâng cao khả năng đàn hồi, đạt tối thiểu thời gian phục hồi, và mở rộng ứng dụng với những giao dịch thời gian dài (hơn 03 phút).
Một chút nhắc lại về tình huống chúng ta trao đổi trong chuỗi bài này là về một hệ thống thương mai điện tử có nhu cầu về siêu tăng trưởng (gấp 10 lần vào giờ cao điểm), chúng ta cũng đã bàn về các thử thách về mặt kỹ thuật và nền tảng và cách để mở rộng back-end ứng dụng mà không ảnh hưởng trải nghiệm của người dùng.
Ngoài việc bản thân website tăng trưởng, các tấn công từ chối dịch vụ (DDoS) cũng tăng gấp 10 lần trong vòng 06 tháng. Một vài tấn công này khiến hệ thống bị ngưng trệ và mất mát doanh thu. Trong bài viết này chúng ta cùng xem cách nhận diện các rủi ro này thông qua triển khai chiến lược đa tài khoản và ứng dụng những triển khai tối ưu AWS Identity and Access Management (IAM).
Chiến lược đa tài khoản đảm bảo bảo mật ở quy mô
Ban đầu các dịch vụ Production và Non-production chạy trong cùng một tài khoản đơn. Điều này có nghĩa là những lỗ hổng trong môi trường Non-production như thường xuyên thay đổi mã nguồn và quản trị truy xuất có thể ảnh hưởng đến môi trường Production. Ngoài ra, việc sử dụng chung các môi trường trong cùng một tài khoản cũng ảnh hưởng đến giới hạn dịch vụ. Điều này bao gồm (nhưng chưa giới hạn) số lượng read replicas trên mỗi CSDL chạy chính trong Amazon Relational Database Service (Amazon RDS), tổng dung lượng cho tất cả máy chủ CSDL trong Auto Scaling Service Quotas cho máy chủ Amazon EC2.
Để nhận diện các vấn đề này, chúng tôi tuân thủ những triển khai tối ưu của chiến lược đa tài khoản. Chúng tôi thiết lập phân tầng đa tài khoản theo Hình 1 bao gồm 08 Organization Units (OUs) để đảm bảo yêu cầu của tổ chức:
- Security PROD OU
- Security SDLC OU
- Infrastructure PROD OU
- Infrastructure SDLC OU
- Workload PROD OU
- Workload SDLC OU
- Sandbox OU
- Transitional OU
Để xác định những điều cần thiết cho nhu cầu của chúng tôi, chúng tôi đã đánh giá AWS Landing Zone và AWS Control Tower. Để giảm thiểu những vận hành trong việc truy trì giải pháp, chúng tôi đã sử dụng AWS Control Tower để triển khai Guardrails với Chính sách kiểm soát dịch vụ SCP (Service Control Policy). Những guardrails này được phân tách giữa môi trường Production và Non-production theo như Hình 1.
Chúng tôi tạo một tài khoản quản trị hay tài khoản thanh toán (Payer or Management Account) với Sandbox OU và Transitional OU bên dưới Root OU. Sau đó chúng tôi di chuyển những tài khoản hiện tại bên dưới Traditional OU và Sandbox OU. Chúng tôi tạo thêm những tài khoản mới với Account Factory và từng chút một di chuyển dịch vụ từ tài khoản AWS hiện tại đến tài khoản Log Archive, Security Account, Network Account, , Shared Services Account mới và ứng dụng guardrails phù hợp. Thêm nữa, chúng tôi di chuyển giải pháp log tập trung trong phần 03 của chuỗi bài viết đến Security Account. Chúng tôi đã di dời ứng dụng Non-production vào Dev và Test Accounts tương ứng để cô lập các loại ứng dụng. Và cuối cùng chúng tôi di chuyển tài khoản hiện tại mà có dịch vụ Production từ Traditional OU đến Workload Production OU.
Hình 1 – Phân tầng đa tài khoản
Triển khai đa tài khoản giúp giảm bớt khó khăn về giới hạn dịch vụ trên mỗi tài khoản. Giúp giảm bớt các yêu cầu biến đổi từ môi trường Non-production và khiến môi trường Production ổn định bền bỉ hơn. Chiến lược đa tài khoản giúp quản trị tài khoản tại quy mô, và giúp nâng cao sự sáng tạo với việc cung cấp một tài khoản riêng biệt với các yêu cầu bảo mật riêng biệt khi triển khai các hệ thống PoC (Proof of Concept) hay trải nghiệm các tính năng mới. Điều này giúp giảm thiểu rủi ro lên môi trường Production và cho phép tự động triển khai guardrails.
Nâng cao quản trị truy xuất và truy xuất quyền tối thiểu (least privilege access)
Khi ứng dụng của công ty siêu tăng tưởng, việc mở rộng không chỉ nằm ở hạ tầng ứng dụng mà còn tăng về tốc độ release mã nguồn, công ty cũng tuyển dụng nhiều nhân sự vào đội ngũ phát triển hơn.
Để nâng cao truy xuất cho người dùng cũ và mới, chúng tôi đã sử dụng AWS Trusted Advisor cho Xoay vòng Access Key IAM. Điều này giúp nhận biết những người dùng không xoay vòng Access Key quá 90 ngày và tự động xoay vòng chúng. Chúng tôi cũng có thể xuất các báo cáo về sử dụng định danh qua IAM Credential Report để nhận diện những người dùng không cần truy xuất qua AWS Console hoặc Access Key. Chúng tôi dần dần gán những người dùng này truy xuất qua IAM Role hơn là IAM Access Keys.
Trong khi xem lại về trụ cột Bảo mật trong AWS Well-Architected Framework, chúng tôi biết được một số ứng dụng sử dụng mật khẩu cố định và không cập nhật xoay vòng sau 90 ngày. Chúng tôi đã thiết kế lại các ứng dụng này và quản trị mật khẩu thông qua AWS Secrets Manager và tuân thủ các thiết kế tối ưu cho hiệu năng.
Ngoài ra chúng tôi thiết lập hệ thống tự động thay đổi mật khẩu cho Amazon RDS và viết hàm AWS Lambda để cập nhật mật khẩu cho ứng dụng bên thứ ba. Một vài ứng dụng chạy trên Amazon EC2 sử dụng IAM access key để truy xuất AWS Service. Chúng tôi đã thiết kế lại phần này thông qua việc gán IAM Role vào máy chủ Amazon EC2. Điều này giúp chúng tôi giảm thiểu các thao tác về vận hành và xoay vòng Access Key.
Sử dụng IAM Access Analyzer, chúng tôi phân tích logs ở AWS CloudTrail và xuất các chính sách của IAM Roles. Điều này giúp chúng tôi xác định những quyền tối thiểu cấp phát cho những Role được đề cập trong bài viết IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity
Để giám sát truy cập AWS cho người dùng nội bộ, chúng tôi đã chuyển người dùng đến AWS Single-Sign-On (AWS SSO) để cấp quyền truy cập. Chúng tôi đã mở tất cả các tính năng trong AWS Organization để sử dụng AWS SSO và tạo các bộ quyền hạn để định nghĩa quyền truy xuất tối đa (boundaries) cho những chức năng khác nhau. Chúng tôi gán các bộ quyền hạn này đến các nhóm người dùng khác nhau và gán người dùng đến các nhóm phù hợp dựa trên chức năng công việc. Điều này giúp chúng tôi giảm thiểu số lượng IAM Policies và sử dụng kiểm soát dựa trên thẻ (tag based control) khi định nghĩa chính sách quyền AWS SSO.
Chúng tôi đã tuân thủ hướng dẫn quản trị truy xuất dựa trên thuộc tính với AWS SSO để ánh xạ thuộc tính của người dùng và sử dụng thẻ để định nghĩa quyền tối đa cho nhóm người dùng. Điều này cho phép chúng tôi cấp quyền truy xuất cho người dùng dựa trên từng đội, dự án hay phòng ban. Chúng tôi cũng triển khai chính sách xác thực hai yếu tố (MFA – Multi Factor Authentication) cho tất cả người dùng AWS SSO thông qua cấu hình MFA cho phép đăng nhập chỉ khi thiết bị MFA đã được đăng ký.
Những cải tiến này đảm bảo chỉ đúng người có thể truy xuất đúng tài nguyên vào đúng thời gian cho phép. Chúng giúp giảm thiểu các rủi ro về bảo mật thông qua việc sử dụng AWS Security Token Service (AWS STS) để tạo ra các truy cập tạm thời. Mật khẩu hệ thống cũng được bảo mật trước những truy xuất không mong muốn và tự động thay đổi để nâng cao bảo mật. AWS SSO cho phép quản trị bảo mật ở quy mô khi chức năng công việc của người dùng thay đổi giữa các đội ngũ.
Kết luận
Trong bài viết này chúng ta đã mô tả những kiểu mẫu thiết kế để triển khai bảo mật tài khoản ở quy mô thông qua chiến lược đa tài khoản và tích hợp AWS SSO. Chúng ta cũng đã trao đổi về những kiểu mẫu thiết kế IAM cho phép truy xuất ít quyền, kiểm tra triển khai tối ưu IAM, cách xem các truy xuất không mong muốn một cách chủ động.
Bài viết này cũng giải thích tại sao bạn cần làm mới mô hình đe doa (threat) trong siêu tăng trưởng và cách những dịch vụ khác nhau đảm bảo kiểm soát bảo mật cho hệ thống. Trong bài viết tiếp theo, chúng ta sẽ tìm hiểu kỹ hơn về các thiết kế bảo mật để nâng cao bảo mật hạ tầng và phản hồi sự cố trong siêu mở rộng (hyperscale).
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.
AWS Study Group 