Hiện nay, các cơ quan chính phủ luôn lâm vào tình cảnh phải chật vật để đáp ứng được khung các chính sách kiểm soát bảo mật bắt buộc đối với các cấu hình và dịch vụ được triển khai trên nền tảng điện toán đám mây. Thậm chí việc có được Quyền điều hành (Authority to Operate – ATO) đôi khi họ có thể phải mất đến 18 tháng. Nhằm rút ngắn được quá trình này, Amazon Web Services (AWS) đã phát triển Bộ tăng tốc môi trường bảo mật AWS (AWS Secure Environment Accelerator – ASEA), một công cụ mã nguồn mở được thiết kế để giúp triển khai và vận hành bảo mật trên môi trường AWS đa tài khoản.
Được thiết kế với sự tham vấn của Trung tâm An ninh mạng Canada (Canadian Centre for Cybersecurity – CCCS) và Ban Ngân khố của Chính phủ Canada, ASEA tự động hóa việc cấu hình các dịch vụ AWS với mục đích đáp ứng các điểu khoản nghiêm ngặt trong CCCS Medium Cloud Security Profile controls của chính phủ Canada. Tự động hóa ASEA đã tiết kiệm trung bình cho khách hàng tới ba tháng – điểm này đặc biệt phù hợp cho nhóm các chính phủ đang trong cảnh khó khăn về thời gian và nguồn nhân lực. Bài đăng này mô tả cách các cơ quan chính phủ có thể triển khai ứng dụng một trong web đơn giản (single-page application – SPA) cùng với việc sử dụng backend API và cơ sở dữ liệu trong ASEA.
Kiến trúc AWS ASEA
ASEA workload trong AWS account sẽ được triển khai dựa trên các tài nguyên mạng sẵn có, các thành phần mạng này được định trước đó tuân theo các mục đích sử dụng. Trong hình trên:
Virtual Private Cloud – VPC và các mạng con (subnets): được thiết kế theo mô hình nhiều lớp: Các subnet để triển khai ứng dụng và dữ liệu đều được triển khai ở các Vùng khả dụng khác nhau (Availability Zones. App subnets được thiết kế cho tài nguyên cấp ứng dụng và Data subnets được thiết kế cho tài nguyên cơ sở dữ liệu.
Security Group: App_sg và Data_sg trong mỗi tài khoản AWS ASEA workload đã định cấu hình trước quy tắc “Allow Inbound”. Ví dụ: Data_sg cho phép các database-port và chỉ chấp nhận lưu lượng truy cập từ App_sg. Các Security Group không thể sửa đổi được; chúng được bảo vệ bởi Chính sách Kiểm soát Dịch vụ (Service Control Policies – SCP). Tuy nhiên, các nhóm có thể tạo các security group bổ sung mà họ có thể quản lý.
Các VPC sẽ được kết nối tới Transit Gateway, nơi lưu lượng mạng được chuyển đến VPC trung tâm, từ đó được định tuyến ra truy cập internet. Lưu lượng mạng này, theo mặc định được chạy qua next generation firewalls (NGFW), tại đây lưu lượng truy cập được siết chặt theo các chính sách bảo mật được cấu hình firewalls. Nếu các workload API thiết lập kết nối với bất kỳ tài nguyên API bên ngoài nào, lưu lượng mạng đều phải được kiểm soát bởi các chính sách trên firewall như trên.
Hình 2 sau đây là kiến trúc tham chiếu cho ASEA với các vùng bôi đỏ được vẽ bổ sung để làm nổi bật luồng lưu lượng từ ASEA workload account tới internet
Các thành phần chính của kiến trúc serverless application của ASEA
Việc đảm bảo tính an toàn khi xây dựng các ứng dụng trong môi trường AWS với việc sử dụng guardrails, restrictive networking và reduced permissions luôn là một nhiệm vụ khó khăn đối với bất kì tổ chức hay doanh nghiệp nào. Kiến trúc ứng dụng không máy chủ, như được mô tả trong Hình 1, được thu gọn và thúc đẩy cách các nhóm có thể xây dựng hệ thống với ASEA. Hãy chia kiến trúc đó thành ba thành phần chính: web front-end, backend API và cơ sở dữ liệu.
Web front-end
Ứng dụng đơn trang ( single-page application – SPA) là một ứng dụng web mà người dùng tương tác bằng trình duyệt web. Nó bao gồm các nội dung tĩnh như HTML, CSS, JavaScript và hình ảnh. SPA có thể được triển khai an toàn bằng cách sử dụng Amazon CloudFront, mạng phân phối nội dung toàn cầu (CDN) của Amazon, với cấu hình sử dụng Dịch vụ lưu trữ đơn giản của Amazon (Amazon S3) làm nguồn cho nội dung tĩnh. Trong sơ đồ kiến trúc ASEA ở trên (Hình 1), biểu tượng chính giữa Amazon CloudFront và Amazon S3 đại diện cho origin access identity cho phép CloudFront truy cập an toàn vào nội dung trong Amazon S3. Tất cả public buckets đã bị vô hiệu hóa trong ASEA. CloudFront có thể được cấu hình với nhiều nguồn dựa trên các đường dẫn yêu cầu. Trong kiến trúc này, có hai nguồn: 1 là truy xuất các file tĩnh SPA với đường dẫn “/ *” và 2 là gửi yêu cầu đến một api backend sử dụng đường dẫn “/ api *.
Backend API
Khi triển khai backend API HTTPS (với lưu lượng truy cập chiều inbound), Amazon API Gateway giúp các developer dễ dàng tạo, duy trì, giám sát và bảo mật các API ở mọi quy mô. Nó có thể chuyển tiếp các truy cập HTTP / HTTPS tới các tài nguyên nằm trong VPC và bảo mật bằng cách thiết lập tích hợp các VPC-link. Trong kiến trúc được đề xuất này (Hình 1), các yêu cầu API HTTPS được gửi đến Amazon API Gateway, thông qua CloudFront và được chueyern tới các container AWS Fargate serverless chạy trên Amazon Elastic Container Service (Amazon ECS) nằm trong một VPC riêng. API Gateway có thể hạn chế các yêu cầu sao cho chỉ CloudFront mới có thể khởi tạo các yêu cầu tới nó bằng cách sử dụng AWS Web Application Firewall (AWS WAF) thông qua việc sử dụng các quy tắc chỉ chấp nhận các yêu cầu có tiêu đề và giá trị phù hợp.
Database
Dịch vụ cơ sở dữ liệu quan hệ của Amazon (Amazon Relational Database Service – Amazon RDS) giúp dễ dàng thiết lập, vận hành và mở rộng quy mô cơ sở dữ liệu quan hệ trên đám mây. Khi triển khai trong ASEA, các RDS sẽ được triển khai trong các data-subnet. Điều này kiểm soát tại tầng mạng và Availability Zones mà cơ sở dữ liệu Amazon RDS sẽ được triển khai. Security group Data_sg cũng có thể được sử dụng để hạn chế kết nối với cơ sở dữ liệu.
Sau khi cơ sở dữ liệu Amazon RDS được khởi tạo, làm cách nào để các thành viên developer có thể kết nối với nó? Có hai lựa chọn như sau:
Thông qua kết nối trực tiếp hạ tầng mạng onprem tới AWS VPC -: các kết nối này sử dụng AWS Site-to-Site VPN hoặc AWS Direct Connect đã được thiết lập trong môi trường AWS. Security-group của cơ sở dữ liệu Amazon RDS sẽ cho phép các kết nối từ dải IP của hạ tầng mạng tại “mặt đất” tương ứng.
Thông qua sử dụng Elastic Compute Cloud (Amazon EC2): tương tự như các sử dụng một bastion-host (hoặc jump-box), nhưng khác ở chỗ có thể truy cập công khai. Trong ASEA, các IAM Role cho các EC2 (hay Instance Profile) đã được định cấu hình trước để sử dụng AWS Systems Manager Session Manager (SSM) để quản lý và cấu hình các AWS EC2. Khởi chạy Amazon Machine Image (AMI), chẳng hạn như Amazon Linux 2, đã được cài đặt sẵn SSM-Agent. Bằng cách phân phối và kiểm soát vai trò quản lý thông qua các quyền truy cập và nhận dạng (IAM) thích hợp (hoặc nếu bạn không chọn, ASEA sẽ tự động chỉ định vai trò đó) thì trình quản lý phiên SSM (SSM Session Manager) sẽ là công cụ an toàn để kết nối tơi các phiên bản private Amazon EC2 instances.
Hoàn thiện các mảnh ghép
Để giúp khách hàng đẩy nhanh việc áp dụng kiến trúc này, bạn có thể tìm thấy cơ sở hạ tầng với Infrastructure as code – IaC trên kho lưu trữ GitHub. Dự án này sử dụng AWS Cloud Development Kit – AWS CDK để xác định tài nguyên AWS bằng ngôn ngữ lập trình TypeScript. Các nhóm develoepr có thể nhanh chóng áp dụng dự án này bằng cách cập nhật cấu hình của nó để trỏ đến vị trí của SPA build folder. Ví dụ: Angular dist xây dựng folder output tới một dự án mã API có chứa Dockerfile. Việc triển khai CDK sẽ tạo tất cả các tài nguyên AWS được mô tả ở trên, tải lên các SPA static files, xây dựng và đẩy Docker container và định cấu hình Amazon ECS để chạy container.
Với ASEA, ngày càng có nhiều động lực đằng sau việc đưa Government of Canada’s PROTECTED B / Medium Integrity / Medium Availability (PBMM) workloads lên AWS – với 30 lần triển khai cho đến nay. Các khách hàng Công tại Anh và Úc cũng đang áp dụng ASEA một cách tương tự. Mỗi ATO đạt được trên khắp thế giới đều cung cấp những bài học mới được tích hợp vào thêm vào ASEA và các gói giải pháp mẫu nếu khả thi.
Đối với các nhóm chính phủ muốn tăng tốc khởi việc sử dụng các PBMM workload trên đám mây, AWS ASEA là điểm khởi đầu nguồn mở, an toàn, đáng tin cậy. Để biết thêm thông tin về việc đáp ứng nhu cầu tuân thủ của bạn trên AWS, cũng như chi tiết hơn về việc áp dụng ASEA, liên hệ với OSAM để được giải đáp thắc mắc nhé.