của James Beswick | TRÊN 23 tháng 1 năm 2024| trong API Gateway của Amazon , Serverless | Liên kết cố định |  Chia sẻ

Bài đăng này được viết bởi Thomas Moore, Kiến trúc sư giải pháp cấp cao và Josh Hart, Kiến trúc sư giải pháp cấp cao.

Một bài đăng trên blog trước đây khám phá cách sử dụng Amazon API Gateway để tạo các API REST riêng tư có thể được sử dụng trên các tài khoản AWS khác nhau bên trong đám mây riêng ảo (VPC). API nhiều tài khoản riêng tư rất hữu ích cho các nhà cung cấp phần mềm (ISV) và các công ty SaaS cung cấp kết nối an toàn cho khách hàng cũng như các tổ chức xây dựng API nội bộ và vi dịch vụ phụ trợ.

TLS tương hỗ (mTLS) là một giao thức bảo mật nâng cao cung cấp xác thực hai chiều thông qua chứng chỉ giữa máy khách và máy chủ. mTLS yêu cầu khách hàng gửi chứng chỉ X.509 để chứng minh danh tính của mình khi đưa ra yêu cầu, cùng với quy trình xác minh chứng chỉ máy chủ mặc định. Điều này đảm bảo rằng cả hai bên đều đúng như những gì họ tuyên bố.

Quá trình kết nối mTLS được minh họa trong sơ đồ trên:

1. Máy khách kết nối với máy chủ.
2. Máy chủ xuất trình chứng chỉ của nó, được khách hàng xác minh.
3. Khách hàng xuất trình chứng chỉ của mình và được máy chủ xác minh.
4. Đã thiết lập kết nối TLS được mã hóa.

Khách hàng sử dụng mTLS vì nó cung cấp khả năng xác minh danh tính và bảo mật mạnh hơn so với kết nối TLS tiêu chuẩn. mTLS giúp ngăn chặn các cuộc tấn công trung gian và bảo vệ khỏi các mối đe dọa như nỗ lực mạo danh, chặn dữ liệu và giả mạo. Khi các mối đe dọa trở nên phức tạp hơn, mTLS cung cấp thêm một lớp bảo vệ để xác thực các kết nối.

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

API Gateway Endpoint Khu Vực có hỗ trợ riêng cho mTLS nhưng API Gateway Endpoint riêng tư không hỗ trợ mTLS, vì vậy bạn phải chấm dứt mTLS trước API Gateway. Bài đăng trên blog trước đây cho biết cách xây dựng API mTLS riêng tư bằng quy trình xác minh tự quản lý bên trong vùng chứa chạy proxy NGINX. Kể từ đó, Application Load Balancer (ALB) hiện hỗ trợ mTLS nguyên bản , đơn giản hóa kiến ​​trúc.

Bài đăng này khám phá việc xây dựng API riêng tư mTLS bằng tính năng mới này.

Cấu hình mTLS Application Load Balancer

Bạn có thể bật xác thực lẫn nhau (mTLS) trên Application Load Balancer mới hoặc hiện có. Bằng cách bật mTLS trên trình nghe cân bằng tải, khách hàng phải xuất trình chứng chỉ tin cậy để kết nối. Bộ cân bằng tải xác thực các chứng chỉ trước khi cho phép các yêu cầu tới phần phụ trợ.

Có hai tùy chọn có sẵn khi định cấu hình mTLS trên Application Load Balancer: Chế độ truyền qua và Xác minh bằng chế độ lưu trữ tin cậy.

Ở chế độ Truyền qua , chuỗi chứng chỉ ứng dụng khách được chuyển dưới dạng X-Amzn-Mtls-Clientcert tiêu đề HTTP để ứng dụng kiểm tra ủy quyền. Trong trường hợp này, vẫn có quá trình xác minh phụ trợ. Lợi ích của việc thêm ALB vào kiến ​​trúc 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 dựa trên đường dẫn, cho phép cấu hình định tuyến ứng dụng phức tạp hơn.

Trong chế độ Xác minh bằng lưu trữ tin cậy , bộ cân bằng tải sẽ xác thực chứng chỉ ứng dụng khách và chỉ cho phép các ứng dụng khách cung cấp chứng chỉ tin cậy kết nối. Điều này giúp đơn giản hóa việc quản lý và giảm tải cho các ứng dụng phụ trợ.

Ví dụ này sử dụng Tổ chức phát hành chứng chỉ riêng của AWS nhưng các bước thực hiện tương tự đối với tổ chức phát hành chứng chỉ bên thứ ba (CA).

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

1. Tạo Cơ quan cấp chứng chỉ riêng AWS. Chỉ định Tên chung (CN) làm miền bạn sử dụng để lưu trữ ứng dụng tại (ví dụ: api.example.com).
2. Xuất CA bằng CLI hoặc Bảng điều khiển và tải Chứng chỉ.pem kết quả lên bộ chứa Amazon S3 .
3. Tạo Trust Store , trỏ cái này vào chứng chỉ đã tải lên ở bước trước.
4. Cập nhật trình xử lý Application Load Balancer của bạn để sử dụng kho tin cậy này và chọn hành vi xác minh mTLS bắt buộc.
5. Tạo chứng chỉ cho ứng dụng khách dựa trên cơ quan cấp chứng chỉ riêng, ví dụ bằng cách sử dụng các lệnh sau:

bash

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 về phần này của quy trình, hãy xem  Sử dụng ACM Private CA cho Amazon API Gateway Mutual TLS .

Xác minh mTLS của API Gateway riêng bằng ALB

Việc sử dụng chế độ Lưu trữ tin cậy bằng tính năng Xác minh ALB cùng với API Gateway có thể kích hoạt các API riêng tư bằng mTLS mà không phải chịu gánh nặng vận hành như dịch vụ proxy tự quản lý.

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

Mẫu tài khoản tương tự cho phép khách hàng bên trong VPC sử dụng API Gateway riêng bằng cách gọi URL Application Load Balancer. ALB được định cấu hình để xác minh chứng chỉ ứng dụng khách được cung cấp dựa trên kho tin cậy trước khi chuyển yêu cầu đến API Gateway.

Nếu chứng chỉ không hợp lệ, API sẽ không bao giờ nhận được yêu cầu. Chính sách tài nguyên trên API Gateway đảm bảo rằng các yêu cầu can chỉ được phép thông qua VPC Endpoint và nhóm bảo mật trên VPC Endpoint đảm bảo rằng nhóm chỉ có thể nhận yêu cầu từ ALB. Điều này ngăn máy khách bỏ qua mTLS bằng cách gọi trực tiếp các điểm cuối API Gateway hoặc VPC.

Mẫu tài khoản chéo sử dụng AWS PrivateLink cung cấp khả năng kết nối với điểm cuối ALB một cách an toàn trên các tài khoản và trên các VPC. Nó giúp tránh nhu cầu kết 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 dịch vụ SaaS cho khách hàng cuối của họ. Mẫu này có sẵn để triển khai dưới dạng mã mẫu trong kho GitHub .

Luồng yêu cầu của khách hàng thông qua kiến ​​trúc nhiều tài khoản như sau:

1. Một ứng dụng khách trong ứng dụng tiêu dùng gửi yêu cầu đến điểm cuối API của nhà sản xuất.
2. Yêu cầu được định tuyến qua AWS PrivateLink tới Cân bằng tải mạng trong tài khoản người tiêu dùng. Cân bằng tải mạng là một yêu cầu của dịch vụ AWS PrivateLink.
3. Network Load Balancer sử dụng Application Load Balancer-type Target Group.
4. Trình nghe Application Load Balancer được định cấu hình cho mTLS ở chế độ xác minh bằng lưu trữ tin cậy.
5. Quyết định ủy quyền được đưa ra để so sánh chứng chỉ ứng dụng khách với chuỗi trong kho lưu trữ chứng chỉ ủy thác.
6. Nếu chứng chỉ ứng dụng khách được cho phép thì yêu cầu sẽ được chuyển đến API Gateway thông qua VPC Endpoint thực thi-api. Chính sách tài nguyên API Gateway được sử dụng để chỉ cho phép kết nối thông qua VPC Endpoint.
7. Mọi hoạt động xác thực và ủy quyền API Gateway bổ sung đều được thực hiện, chẳng hạn như sử dụng trình ủy quyền Lambda để xác thực Mã thông báo Web JSON (JWT).

Sử dụng ví dụ được triển khai từ kho lưu trữ GitHub , đây là phản hồi dự kiến ​​từ một yêu cầu thành công có chứng chỉ hợp lệ:

bash

curl –key my_client.key –cert my_client.pem https://api.example.com/widgets 

{“id”:”1”,”value”:”4.99”}

Khi chuyển 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

Tên miền tùy chỉnh

Một lợi ích bổ sung khi triển khai giải pháp mTLS với Application Load Balancer là hỗ trợ các tên miền tùy chỉnh riêng. API Gateway Endpoint riêng hiện không hỗ trợ tên miền tùy chỉnh. Nhưng trong trường hợp này, trước tiên, khách hàng sẽ kết nối với điểm cuối ALB, điểm cuối này hỗ trợ miền tùy chỉnh. Mã mẫu triển khai các miền tùy chỉnh riêng bằng chứng chỉ AWS Certification Manager (ACM) công khai trên ALB nội bộ và vùng DNS được lưu trữ trên Amazon Route 53 . Điều này cho phép bạn cung cấp URL tĩnh cho người tiêu dùng để nếu API Gateway được thay thế thì người tiêu dùng không cần cập nhật mã của họ.

Danh sách thu hồi chứng chỉ

Theo tùy chọn, với tư cách là một lớp bảo mật khác, bạn cũng có thể định cấu hình danh sách thu hồi chứng chỉ cho kho lưu trữ tin cậy trên ALB . Danh sách thu hồi cho phép bạn thu hồi và vô hiệu hóa các chứng chỉ đã cấp trước ngày hết hạn. Ví dụ: bạn có thể sử dụng tính năng này để loại bỏ khách hàng hoặc từ chối thông tin xác thực bị xâm phạm.

Bạn có thể thêm danh sách thu hồi chứng chỉ vào kho tin cậy mới hoặc hiện có. Danh sách được cung cấp qua URI Amazon S3 dưới dạng tệp có định dạng PEM.

Phần kết luận

Bài đăng này khám phá các cách cung cấp xác thực TLS lẫn nhau cho các API Gateway Endpoint riêng tư. Bài đăng trước cho biết cách đạt được điều này bằng proxy NGINX tự quản lý. Bài đăng này đơn giản hóa kiến ​​trúc bằng cách sử dụng hỗ trợ mTLS gốc hiện có sẵn cho Application Load Balancer.

Mẫu mới này tập trung xác thực ở biên, hợp lý hóa việc triển khai và giảm thiểu chi phí hoạt động so với xác minh tự quản lý. Danh sách thu hồi chứng chỉ và Cơ quan cấp chứng chỉ riêng của AWS tích hợp với thông tin xác thực được quản lý và chính sách bảo mật. Điều này giúp việc hiển thị API riêng tư một cách an toàn trên các tài khoản và VPC dễ dàng hơn.

Xác thực lẫn nhau và kiểm soát bảo mật tiến bộ ngày càng trở nên quan trọng khi kiến ​​trúc khối lượng công việc an toàn trên nền tảng đám mây. Để bắt đầu, hãy truy cập kho lưu trữ GitHub .

Để biết thêm tài nguyên học tập phi máy chủ, hãy truy cập Serverless Land .