Bài đăng này được viết bởi Thomas Moore, Senior Solutions Architect và Josh Hart, Senior Solutions Architect.

Trong bài viết trước khám phá về việc dùng Amazon API Gateway để tạo các private REST API để có thể được sử dụng thông qua các tài khoản AWS khác trong cùng một virtual private cloud (VPC). Các private cross-account API hữu ích cho các nhà cung cấp phần mềm – software vendors (ISV) và các công ty SaaS cung cấp kết nối bảo mật cho khách hàng, và các tổ chức đang xây dựng các API nội bộ và backend microservices.

Mutual TLS (mTLS) là một giao thức bảo mật nâng cao cung cấp xác thực 2 chiều thông qua các chứng chỉ giữa máy chủ và máy khách. mTLS yêu cầu máy khách gửi một chứng chỉ X.509 để chứng minh danh tính của nó khi thực hiện một request, cùng với quá trình xác thực chứng chỉ mặc định của máy chủ. Điều này đảm bảo cả hai bên đều chính xác là họ.

Việc xử lý kết nối mTLS được minh họa trong hình phía trên:

1. Client kết nối tới server.
2. Server đưa ra chứng chỉ của nó và sẽ được xác minh bởi client.
3. Client đưa ra chứng chỉ của nó và được xác minh bởi server.
4. Kết nối TLS mã hóa được hình thành.

Các khách hàng sử dụng mTLS bởi vì nó có cơ chế xác thực bảo mật và định danh mạnh hơn các kết nối TLS thông thường, mTLS giúp chống lại các tấn công man-in-the-middle và bảo vệ khỏi các nguy hiểm như nỗ lực mạo danh, chặn dữ liệu và giả mạo. Vì các mối nguy hiểm trở nên nguy hiểm hơn, mTLS cung cấp thêm một lớp phòng thủ để xác thực các kết nối.

Triển khai mTLS làm tăng chi phí quản lý chứng chỉ, nhưng với các ứng dụng truyền tải dữ liệu có quan trọng hoặc nhạy cảm, việc bảo mật thêm này là quan trọng. Nếu bảo mật được xem là ưu tiên cho các hệ thống và người dùng của bạn, bạn nên cân nhắc triển khai mTLS.

Các Regional API Gateway endpoint có hỗ trợ mTLS sẵn nhưng các private API Gateway endpoint không hỗ trợ mTLS, nên bạn phải dừng mTLS trước API Gateway. Bài viết trước chỉ các xây dựng các private mTLS API bằng việc sử dụng quá trình xác thực tự quản lý bên trong một container chạy NGINX proxy. Từ đó, ALB đã tự hỗ trợ mTLS, giúp đơn giản hoá kiến trúc. 

Trong bài này sẽ khám phá việc xây dựng private mTLS API sử dụng chức năng mới này.

Cấu hình Application Load Balancer mTLS

Bạn có thể cho phép mutual authentication (mTLS) trên một Application Load Balancer mới hoặc đã có sẵn. Với việc cho phép mTLS trên load balancer listener, các client được yêu cầu đưa ra các chứng chỉ tin cậy để kết nối. Load balancer xác thực các chứng chỉ trước khi cho phép các yêu cầu đến backend.

Có 2 lựa chọn khi cấu hình mTLS trên Application Load Balancer: chế độ Passthrough và chế độ  Verify with trust store.

Trong chế độ Passthrough, chuỗi chứng chỉ của client được chuyển dưới dạng một X-Amzn-Mtls-Clientcert HTTP header để kiểm tra authorization. Trong kịch bản này, vẫn có quá trình xác minh bởi backend. Lợi ích khi thêm ALB vào thiết kế là bạn có thể thực hiện định tuyến ứng dụng (lớp 7), chẳng hạn như định tuyến theo đường dẫn, cho phép các cấu hình định tuyến ứng dụng phức tạp hơn.

Trong chế độ Verify with trust store, load balancer xác nhận chứng chỉ của client và chỉ cho phép các client cung cấp chứng chỉ đã xác thực để kết nối. Điều này làm đơn giản việc quản trị và giảm tải trên các ứng dụng backend.

Ví dụ này dùng AWS Private Certificate Authority nhưng các bước giống với các certificate authority (CA) bên thứ 3.

Để cấu hình chứng chỉ Trust Store cho ALB:

1. Tạo một AWS Private Certificate Authority. Chỉ định Common Name (CN) là tiên miền bạn dùng để host ứng dụng (ví dụ api.example.com)
2. Xuất CA bằng CLI hoặc Console và tải tệp Certificate.pem lên một S3 bucket.
3. Tạo một Trust Store, trỏ nó nó chứng chỉ được tải lên ở bước trước.
4. Cập nhật listener của ALB để dùng trust store này và chọn yêu cầu xác thực mTLS.
5. Tạo các chứng chỉ cho các ứng dụng client dựa trên private certificate authority, ví dụ dùng các lệnh sau:

openssl req -new -newkey rsa:2048 -days 365 -keyout my_client.key -out my_client.csr aws acm-pca issue-certificate –certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/certificate_authority_id–csr fileb://my_client.csr –signing-algorithm “SHA256WITHRSA” –validity Value=365,Type=”DAYS” –template-arn arn:aws:acm-pca:::template/EndEntityCertificate/V1 aws acm-pca get-certificate -certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/certificate_authority_id–certificate-arn arn:aws:acm-pca:us-east-1:account_id:certificate-authority/certificate_authority_id/certificate/certificate_id–output text

Để biết thêm chi tiết cho phần này của việc xử lý, đọc thêm Use ACM Private CA for Amazon API Gateway Mutual TLS.

Xác thực private API Gateway mTLS với ALB

Sử dụng chế độ ALB Verify with trust store cùng với API Gateway có thể cho phép private API với mTLS mà không có nặng nhọc trong hoạt động của dịch vụ self-managed proxy.

Bạn có thể sử dụng khuôn mẫu này để truy cập API Gateway trong cùng một tài khoản AWS hoặc liên tài khoản.

Mẫu tài khoản giống nhau cho phép các client trong cùng VPC dùng private API Gateway bằng việc gọi tới Application Load Balancer URL. ALB được cấu hình để xác thực chứng chỉ được cung cấp bởi client qua trust store trước khi truyền request tới API Gateway.

Nếu chứng chỉ không hợp lệ, API không bao giờ nhận được request. Một resource policy trong API Gateway đảm bảo có thể các request chỉ được cho phép thông qua VPC endpoint, và một security group trong VPC endpoint đảm bảo nó chỉ có thể nhận request từ ALB. Điều này ngăn chặn client bỏ qua mTLS bằng cách gọi trực tiếp các API Gateway endpoint hoặc VPC endpoint.

Mẫu cross-account sử dụng AWS PrivateLink cung cấp khả năng kết nối tới ALB endpoint một cách bảo thông qua các tài khoản và các VPC. Nó tránh việc phải kế nối các VPC với nhau bằng  VPC Peering hoặc AWS Transit Gateway và cho phép các nhà cung cấp phần mềm cung cấp các dịch vụ SaaS cho khách hàng cuối của họ. Mẫu này có sẵn để triển khai bằng code mẫu trong GitHub repository.

Luồng đi của client request trong kiến trúc cross-account như sau:

1. Một client sử dụng ứng dụng gửi một request tới producer API endpoint.
2. Request được định tuyến qua AWS PrivateLink tới một Network Load Balancer trong tài khoản khách hàng. Network Load Balancer là một dịch vụ bắt buộc của AWS PrivateLink.
3. NLB sử dụng Application Load Balancer làm kiểu của Target Group.
4. ALB listener được cấu hình cho mTLS trong chế độ Verify with trust store.
5. Một quyết định authorization được tạo ra để so sánh chứng chỉ client với chuỗi trong chứng chỉ trust store. 
6. Nếu chứng chỉ client được cho phép, thì request được định tuyến tới API Gateway thông qua api thực thi của VPC Endpoint. Một API Gateway resource policy được dùng để cho phép các kết nối chỉ qua VPC endpoint.
7. Bất cứ API Gateway authentication and authorization thêm nào được thực hiện, ví dụ như dùng một Lamda authorizer để xác thực một JSON Web Token (JWT).

Sử dụng ví dụ được triển khai từ GitHub repo, đây là response được trả về từ một request thành công với chứng chỉ hợp lệ:

$ curl -key my_client.key -cert my_client.pem https://api.example.com/widgets {“id”:”1″,”value”:”4.99″}

Khi gửi chứng chỉ không hợp lệ, sẽ nhận được phản hồi sau:

curl: (35) Recv failure: Connection reset by peer

Các tên miền tùy chỉnh

Một lợi ích nữa khi triển khai giải pháp mTLS với ALB là hỗ trợ cho các tên miền tùy chỉnh private. Private API Gateway endpoint hiện tại không hỗ trợ các tên miền tùy chỉnh. Nhưng trong trường hợp này, các client đầu tiên kết nối tới ALB endpoint có hỗ trợ tên miền tuỳ chỉnh. Code mẫu triển khai các tên miền private tùy chỉnh sử dụng chứng chỉ public AWS Certificate Manager (ACM) trên ALB nội bộ, và một Amazon Route 53 host DNS zone. Nó cho phép bạn cung cấp một URL tĩnh đến khách hàng để nếu API Gateway bị thay thế thì khách hàng không cần phải cập nhật code.

Danh sách chứng chỉ thu hồi (Certificate revocation list)

Một tùy chọn là một lớp bảo mật khác, bạn có thể cấu hình một danh sách chứng chỉ thu hồi cho trust store trên ALB. Các danh sách thu hồi cho phép bạn hủy và vô hiệu hóa các chứng chỉ đã phát hành trước khi chúng hết hạn. Bạn có thể dùng chức năng này loại bỏ khách hàng hoặc từ chối các thông tin xác thực bị xâm phạm.

Bạn có thể thêm danh sách chứng chỉ thu hồi cho trust store mới hoặc đã có. Danh sách được cung cấp thông qua Amazon S3 URI ở tệp định dạng PEM.

Kết luận

Bài này chúng ta đã khám phá cách cung cấp xác thực mTLS cho private API Gateway endpoint. Trong bài trước đã đưa ra cách làm thế nào để đạt được việc này bằng việc dùng Nginx proxy tự quản. Bài này đơn giản hóa kiến trúc bằng việc dùng mTLS được hỗ trợ sẵn cho ALB.

Mẫu mới này tập trung xác thực tại edge, hợp lý hóa triển khai và giảm thiểu chi phí tổ chức so với xác thực tự quản. AWS Private Certificate Authority và các danh sách chứng chỉ thu hồi kết hợp với các thông tin xác thực được quản lý và các security policy. Nó giúp dễ dàng hơn cho việc tiết lộ private API một cách an toàn qua nhiều tài khoản và VPC.

Xác thực chéo và các kiểm soát an ninh tiến bộ đang phát triển trong thận trọng khi thiết kế các workload đám mây bảo mật. Để bắt đầu, xem GitHub repository.

Để xem thêm thông tin học về serverless, ghé Serverless Land.