Tác giả: Keith Lee, Anandprasanna Gaitonde, và Raj Bagwe
Ngày phát hành: 26 JAN 2026
Chuyên mục: AWS Verified Access, Networking & Content Delivery, Technical How-to

Các nhóm bảo mật quản lý môi trường Amazon Web Services (AWS) đa tài khoản phải đối mặt với những thách thức vận hành đáng kể khi triển khai các kiểm soát truy cập nhất quán. Các phương pháp truyền thống đòi hỏi phải nhân đôi cơ sở hạ tầng VPN, quản lý các bastion host riêng biệt trong mỗi tài khoản và duy trì các chính sách bảo mật phân mảnh trên nhiều ứng dụng. Chi phí vận hành này làm tăng chi phí cơ sở hạ tầng và bề mặt tấn công. Bài viết này sẽ hướng dẫn bạn triển khai AWS Verified Access (AVA) trong một kiến trúc tập trung đồng thời thực thi các nguyên tắc zero trust trên toàn bộ tổ chức AWS của bạn.

Verified Access bảo mật quyền truy cập ứng dụng bằng cách đánh giá từng yêu cầu dựa trên danh tính người dùng và tình trạng thiết bị thay vì vị trí mạng. Không giống như các giải pháp dựa trên mạng, Verified Access hoạt động ở lớp ứng dụng để bạn có thể định nghĩa các chính sách truy cập chi tiết bằng ngôn ngữ chính sách Cedar. Khi được triển khai theo mô hình dịch vụ chia sẻ, Verified Access giảm đáng kể bề mặt tấn công của bạn bằng cách loại bỏ việc phơi bày mạng rộng rãi và tập trung quản lý chính sách trên nhiều tài khoản AWS. Bạn triển khai Verified Access trong một tài khoản mạng chuyên dụng, chia sẻ các nhóm truy cập trên các Đơn vị Tổ chức (OU) bằng cách sử dụng AWS Resource Access Manager (AWS RAM), và tích hợp với AWS IAM Identity Center để quản lý danh tính tập trung.

Kiến trúc khách hàng

Hình 1 cho thấy cách các tài khoản workload lưu trữ các ứng dụng riêng tư, một tài khoản mạng chuyên dụng quản lý phiên bản Verified Access tập trung, và tài khoản quản lý cung cấp quản trị tổ chức thông qua AWS IAM Identity Center và AWS RAM.

Hình 1: Kiến trúc Verified Access đa tài khoản

Ba tài khoản workload hiển thị các mẫu ứng dụng khác nhau trên các OU. OU Data Science chứa hai tài khoản: Data Science Workload 1 lưu trữ một ứng dụng web phía sau AWS Application Load Balancer (ALB), trong khi Data Science Workload 2 chạy một cụm cơ sở dữ liệu Amazon Aurora. OU HR chứa tài khoản HR Application với một hệ thống nhân sự dựa trên web. Mỗi workload hoạt động trong các subnet riêng tư trong môi trường Amazon Virtual Private Cloud (Amazon VPC), do đó không có sự phơi bày trực tiếp ra internet. Các Verified Access Group xác định người dùng có thể truy cập ứng dụng nào, với mỗi nhóm chứa các chính sách truy cập và được liên kết với các điểm cuối Verified Access của các ứng dụng hoặc tài nguyên. Verified Access hỗ trợ cả ứng dụng HTTPS và không phải HTTPS, để bạn có thể bảo mật các ứng dụng web, API, cơ sở dữ liệu và hệ thống cũ thông qua một mặt phẳng kiểm soát truy cập thống nhất.

Phiên bản Verified Access tập trung được lưu trữ trong tài khoản mạng chuyên dụng đóng vai trò là điểm vào an toàn cho tất cả các yêu cầu truy cập từ xa. Phiên bản này xử lý xác thực và ủy quyền cho mọi nỗ lực kết nối, đánh giá danh tính người dùng và tình trạng thiết bị dựa trên các chính sách đã định nghĩa trước khi cho phép lưu lượng truy cập đến các ứng dụng backend. Các chính sách truy cập sử dụng ngôn ngữ chính sách Cedar để định nghĩa các điều kiện chi tiết dựa trên thuộc tính người dùng, tư cách thành viên nhóm và trạng thái tuân thủ thiết bị. Cách tiếp cận này đảm bảo rằng các quyết định truy cập xem xét nhiều yếu tố bảo mật thay vì chỉ dựa vào vị trí mạng.

Tài khoản quản lý cung cấp quản trị toàn tổ chức thông qua hai dịch vụ chính. IAM Identity Center đóng vai trò là nhà cung cấp danh tính trung tâm, quản lý tài khoản người dùng, tư cách thành viên nhóm và quy trình xác thực trên toàn bộ tổ chức. AWS RAM cho phép chia sẻ an toàn các Verified Access Group cho các OU cụ thể. Điều này có nghĩa là mỗi đơn vị kinh doanh có thể tạo điểm cuối trong khi kế thừa các chính sách bảo mật phù hợp.

Lợi ích chính của kiến trúc

• Quản lý bảo mật tập trung: Tài khoản mạng quản lý tất cả các tài nguyên Verified Access, nhà cung cấp tin cậy và chính sách từ một vị trí duy nhất, giảm độ phức tạp trong vận hành và cung cấp các tiêu chuẩn bảo mật nhất quán.
• Chia sẻ tài nguyên: Các Verified Access Group được chia sẻ thông qua AWS RAM cho phép các OU tạo điểm cuối ứng dụng trong khi tự động kế thừa các chính sách bảo mật phù hợp.
• Thực thi chính sách nhất quán: Các chính sách bảo mật thống nhất áp dụng trên tất cả các đơn vị kinh doanh và ứng dụng, loại bỏ sự sai lệch cấu hình và các lỗ hổng bảo mật xảy ra với quản lý truy cập phân tán.

Bạn phải cấu hình IAM Identity Center ở chế độ tổ chức từ tài khoản quản lý để quản lý tập trung quyền truy cập của người dùng và nhóm trên các tài khoản thành viên. Để biết hướng dẫn cấu hình chi tiết, hãy tham khảo Hướng dẫn sử dụng IAM Identity Center.

Thiết lập môi trường của bạn

Trước khi triển khai giải pháp này, hãy hoàn thành các bước sau trong tài khoản quản lý của bạn:

• Bật phiên bản Tổ chức của IAM Identity Center trong AWS Region nơi bạn dự định triển khai giải pháp.
• Tạo các người dùng và nhóm sau trong IAM Identity Center theo Hướng dẫn sử dụng IAM Identity Center.

• Bật chia sẻ tài nguyên trong AWS Organizations của bạn bằng AWS RAM.
• Tạo Cấu trúc Tổ chức
  • Tạo một tài khoản mạng chuyên dụng cho các tài nguyên mạng chia sẻ theo các phương pháp hay nhất về đa tài khoản
  • Tạo OU: HR Team OU và Data Science Team OU
  • Tạo các tài khoản thành viên: HR Application (trong HR OU), và Data Science Workload 1 và 2 (trong Data Science OU)
• Tạo ARN chứng chỉ SSL Amazon Certificate Manager (ACM) cho hrapp và dsapp được cung cấp trong các tài khoản tương ứng của chúng. Bạn có thể sử dụng chứng chỉ SSL do CA đáng tin cậy hoặc CA riêng tư cấp (chỉ khuyến nghị cho môi trường thử nghiệm).
• Nếu bạn muốn tạo chứng chỉ CA riêng tư cho môi trường “Chỉ thử nghiệm”, thì bạn có thể sử dụng quy trình sau. Quy trình này tạo chứng chỉ CA riêng tư cho tên miền ứng dụng “hrapp” và “dsapp”, và tải nó lên ACM.
  • Tạo khóa riêng bằng openssl:

openssl genrsa -out private.key 2048

Lệnh này tạo một khóa riêng RSA 2048-bit an toàn và lưu vào tệp ‘private.key’.

*   Tạo chứng chỉ bằng khóa riêng:

openssl req -new -x509 -nodes -sha1 -days 365 -extensions v3_ca -key private.key -out certificate.crt

Lệnh này tạo một chứng chỉ X.509 tự ký có giá trị trong 365 ngày bằng khóa riêng đã tạo trước đó. Nó tạo một chứng chỉ SSL hoàn chỉnh có thể được sử dụng cho môi trường thử nghiệm hoặc các ứng dụng nội bộ.

*   Hệ thống sẽ nhắc bạn nhập chi tiết tạo chứng chỉ:

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:<COUNTRY>
State or Province Name (full name) [Some-State]:<STATE>
Locality Name (eg, city) []:<CITY>
Organization Name (eg, company) [Internet Widgits Pty Ltd]:<ORGANIZATION NAME>
Organizational Unit Name (eg, section) []:<UNIT NAME>
Common Name (e.g. server FQDN or YOUR name) []:<APPLICATION DOMAIN NAME>
Email Address []:<EMAIL ADDRESS>

*   Nhập chứng chỉ vào ACM bằng [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html):

aws acm import-certificate --certificate fileb://certificate.crt --private-key fileb://private.key --region us-west-2
{
     "CertificateArn": "arn:aws:acm:<REGION>:<ACCOUNT ID>:certificate/<CERTIFICATE ID>"
}

Triển khai giải pháp

Để triển khai phiên bản Verified Access trung tâm:

1. Đăng nhập vào AWS Management Console trong tài khoản mạng của bạn.
2. Điều hướng đến dịch vụ AWS CloudFormation.
3. Chọn Create stack và chọn With new resources (standard).
4. Tải lên tệp mẫu AVA-CentralInstance.yaml.
5. Cấu hình các tham số stack bằng cách sử dụng các giá trị trong bảng sau.
   
6. Xem lại cấu hình stack và chọn Create stack.
7. Điều hướng đến phiên bản Verified Access bằng cách điều hướng đến VPC, sau đó Verified Access, và Verified Access instances, như trong Hình 2.

Hình 2: Trang các phiên bản Verified Access hiển thị phiên bản đã triển khai với ID phiên bản, dấu thời gian tạo và các nhà cung cấp tin cậy liên quan

8. Điều hướng đến tab Verified Access trust providers để xác minh IAM Identity Center đã cấu hình là nhà cung cấp tin cậy danh tính người dùng, như trong Hình 3.

Hình 3: Nhà cung cấp tin cậy danh tính người dùng trong tab Nhà cung cấp tin cậy Verified Access

9. Chọn tab Verified Access groups để xem ID nhóm truy cập đã cấu hình và chính sách liên quan, như trong Hình 4.

Hình 4: Các nhóm Verified Access hiển thị các nhóm đã tạo

Triển khai ứng dụng web AVA trong tài khoản HR

1. Đăng nhập vào Console trong tài khoản HR của bạn.
2. Điều hướng đến dịch vụ CloudFormation.
3. Chọn Create stack và chọn With new resources (standard).
4. Tải lên AVA-AppEndpoint.yaml với các tham số sau.
   
5. Xem lại cấu hình stack và chọn Create stack.
6. Sau khi stack được triển khai, điều hướng đến VPC, sau đó AWS Verified Access, và Verified Access endpoints.
7. Xác minh rằng điểm cuối được liên kết với HR Verified Access Group được chia sẻ với HR OU từ tài khoản Networking, như trong Hình 5.

Hình 5: Điểm cuối Verified Access cho ứng dụng HR

Triển khai ứng dụng web AVA trong tài khoản Data Science Workload 1

1. Thực hiện các bước tương tự như Triển khai ứng dụng web AVA trong tài khoản HR ngoại trừ
   1. Sử dụng tài khoản Data Science
   2. Sử dụng VerifiedAccessGroupId cho Data Science Team
   3. Sử dụng dsapp cho AppName

Triển khai điểm cuối cơ sở dữ liệu AVA trong tài khoản Data Science Workload 2

1. Đăng nhập vào Console trong tài khoản “Data Science Workload 2” của bạn.
2. Điều hướng đến dịch vụ CloudFormation.
3. Chọn Create stack và chọn With new resources (standard).
4. Tải lên AVA-DatabaseEndpoint.yaml.
5. Cấu hình các tham số stack bằng cách sử dụng các tham số sau:

6. Xem lại cấu hình stack và chọn Create stack.
7. Sau khi stack được triển khai, điều hướng đến VPC, sau đó AWS Verified Access, và Verified Access endpoints.
8. Xác minh điểm cuối được liên kết với Data Science Verified Access Group được chia sẻ với Data Science OU từ tài khoản Networking.

Hình 6: Điểm cuối Verified Access cho cơ sở dữ liệu Data Science

Kiểm thử giải pháp

Kiểm tra kết nối đến cơ sở dữ liệu (điểm cuối AVA không phải HTTP)

Để kiểm tra kết nối cơ sở dữ liệu, hãy sử dụng các bước sau:

1. Cài đặt và cấu hình client Verified Access theo tài liệu client Verified Access.
2. Xác thực bằng thông tin đăng nhập “dsuser” khi được client kết nối nhắc.
3. Truy xuất tên miền điểm cuối cơ sở dữ liệu từ bảng điều khiển Verified Access endpoints trong tài khoản mạng của bạn.

Hình 7: Bảng điều khiển AWS hiển thị tên miền điểm cuối Verified Access và chi tiết, được sử dụng để cấu hình kết nối cơ sở dữ liệu.

4. Kết nối đến cơ sở dữ liệu Aurora PostgreSQL bằng client psql:

psql -h <AVA Database Endpoint Domain Name> -p 5432 -U postgres

Hình 8: Lệnh kết nối PostgreSQL sử dụng tên miền điểm cuối AVA

Hình 9: Kiểm tra kết nối cơ sở dữ liệu cho thấy quyền truy cập thành công của dsuser theo các quyền của chính sách AVA

Kiểm tra ứng dụng web HR (điểm cuối AVA HTTP)

Bạn có thể truy cập ứng dụng web HR (điểm cuối AVA HTTP) bằng trình duyệt với tên DNS công khai (AppName + TopLevelDomain) được cung cấp trong khi cung cấp stack CloudFormation cho các ứng dụng.

Bạn cần thêm mục nhập CNAME trong máy chủ DNS của mình cho Tên DNS công khai với tên miền đích là tên miền điểm cuối AVA. Truy xuất điểm cuối Verified Access của hrapp để cấu hình DNS CNAME bằng lệnh sau trên tài khoản Networking hoặc trên console bằng cách điều hướng đến VPC -> Verified Access Endpoints.

aws ec2 describe-verified-access-endpoints --query "VerifiedAccessEndpoints[?starts_with(EndpointDomain, 'hrapp')].{Id:VerifiedAccessEndpointId,Domain:EndpointDomain}" --output json

[{
"Id": "vae-0ed285ba0830e1234",
"Domain": "hrapp.edge-0e0936e537a3d789X.vai-04d6968cb8d47b2XX.prod.verified-access.us-west-2.amazonaws.com"
}]

1. Tìm kiếm tên mà bạn đã cấu hình cho điểm cuối Verified Access.
2. Đăng nhập qua Verified Access bằng “hruser”, và chọn Next.

Hình 10: Màn hình đăng nhập ứng dụng kết nối Verified Access cho quyền truy cập không phải HTTP

3. Nhập mật khẩu cho “hruser” và chọn Sign In.

Hình 11: Màn hình đăng nhập ứng dụng kết nối Verified Access cho quyền truy cập không phải HTTP

4. Đăng nhập thành công sẽ chuyển hướng bạn đến trang chủ ứng dụng web “HRApp” như trong Hình 12.

Hình 12: Trang web ứng dụng HR sau khi xác thực thành công

Theo cùng một quy trình xác minh, bạn có thể kiểm tra quyền truy cập ứng dụng web “DSApp” bằng điểm cuối Verified Access để cung cấp xác thực an toàn và kết nối được ủy quyền.

Các điểm cần cân nhắc

Việc triển khai Verified Access trên nhiều tài khoản cần lập kế hoạch cẩn thận một số yếu tố chính. Các điểm cuối Verified Access hoạt động trong các subnet VPC và kết nối trực tiếp với các ứng dụng cùng VPC mà không cần Transit Gateway hoặc VPC peering, với sự hỗ trợ cho các VPC được chia sẻ thông qua chia sẻ subnet. Trước khi triển khai, hãy xác minh hạn ngạch dịch vụ trong các AWS Region mục tiêu và đảm bảo rằng các ứng dụng được cấu hình để chỉ chấp nhận lưu lượng truy cập từ các nhóm bảo mật điểm cuối Verified Access. Điều này ngăn chặn kết nối ngay cả khi kẻ tấn công phát hiện địa chỉ IP ứng dụng. Sử dụng chia sẻ Verified Access Group để duy trì các chính sách nhất quán tự động mở rộng sang các tài khoản mới trong các OU. Giám sát hiệu suất dưới điều kiện tải dự kiến và các đợt lưu lượng truy cập được xác thực, ghi nhớ thời gian chờ HTTP idle 60 giây, để cung cấp trải nghiệm người dùng tối ưu trong khi duy trì kiểm soát truy cập zero-trust.

Kết luận

AWS Verified Access hợp lý hóa việc quản lý ứng dụng an toàn trên nhiều tài khoản AWS bằng cách tập trung các kiểm soát bảo mật và loại bỏ nhu cầu về cơ sở hạ tầng VPN và bastion host riêng biệt. Thông qua một tài khoản mạng chuyên dụng và AWS RAM, các tổ chức có thể thực thi các chính sách bảo mật nhất quán trên các OU đồng thời hợp lý hóa việc tích hợp ứng dụng. Cách tiếp cận tập trung này cung cấp khả năng hiển thị bảo mật thống nhất, kế thừa chính sách tự động cho các tài khoản mới và giảm chi phí cơ sở hạ tầng trong khi duy trì các nguyên tắc zero trust. Bắt đầu triển khai của bạn ngay hôm nay bằng cách xem lại Hướng dẫn bắt đầu Verified Access.

Về tác giả

Raj Bagwe
Raj Bagwe là Kiến trúc sư Giải pháp Cấp cao tại Amazon Web Services, có trụ sở tại San Francisco, California. Với hơn 6 năm làm việc tại AWS, anh ấy giúp khách hàng điều hướng các thách thức công nghệ phức tạp và chuyên về Kiến trúc Đám mây, Bảo mật và Di chuyển. Trong thời gian rảnh rỗi, anh ấy huấn luyện một đội robot và chơi bóng chuyền. Có thể liên hệ với anh ấy qua tài khoản X @rajesh_bagwe.

Keith Lee
Keith Lee là Kiến trúc sư Giải pháp Đối tác tại Amazon Web Services (AWS). Anh ấy tập trung vào việc phát triển quan hệ đối tác và thúc đẩy việc áp dụng các công nghệ mới. Anh ấy làm việc để mở rộng các mối quan hệ chiến lược, xác định cơ hội để các đối tác tận dụng các giải pháp AWS và tạo điều kiện triển khai các công nghệ đám mây tiên tiến trên nhiều ngành công nghiệp khác nhau.

Anandprasanna Gaitonde
Với tư cách là Kiến trúc sư Giải pháp Chính tại AWS, Anand chịu trách nhiệm giúp khách hàng thiết kế và vận hành các giải pháp được kiến trúc tốt để giúp họ áp dụng đám mây AWS thành công. Anh ấy tập trung vào AWS Networking, các mẫu kiến trúc Resilience và Serverless để xây dựng các giải pháp trên đám mây cho các ngành dọc khác nhau. Ngoài công việc, anh ấy thích đi du lịch, chơi quần vợt và bơi lội.