Tác giả: Sagar Desarda và Yutaka Oka
Ngày phát hành: 02 FEB 2026
Chuyên mục: Amazon CloudFront, Networking & Content Delivery, Technical How-to
Bắt đầu từ hôm nay, Amazon CloudFront mở rộng khả năng TLS hai chiều (mTLS) tới các origin của khách hàng, cho phép xác thực đầu cuối thực sự trên toàn bộ đường dẫn kết nối—từ người xem đến các origin của khách hàng. CloudFront đã hỗ trợ viewer mTLS giữa người xem và CloudFront, để khách hàng có thể xác thực mạnh mẽ các client trước khi lưu lượng truy cập đi vào vành đai của họ. Với lần ra mắt này, lưu lượng truy cập đó giờ đây có thể tiếp tục qua mTLS từ CloudFront đến origin, bảo toàn danh tính mã hóa và sự tin cậy trên mọi chặng. Kết quả là một đường dẫn yêu cầu được xác thực hoàn toàn, loại bỏ sự tin cậy ngầm, cho phép kiến trúc zero-trust, phòng thủ chuyên sâu mà không làm giảm hiệu suất tại biên.
Tại sao mTLS giữa CloudFront và origin lại quan trọng
Việc mở rộng mTLS từ biên đến origin chuyển đổi sự tin cậy từ dựa trên vành đai sang dựa trên danh tính trên toàn bộ vòng đời yêu cầu. Khách hàng có thể bật viewer mTLS và origin mTLS trên CloudFront để loại bỏ sự tin cậy ngầm giữa các tầng và thực thi quyền truy cập ít đặc quyền nhất tại origin. Điều này quan trọng đối với các khối lượng công việc được quy định và có rủi ro cao, nơi quyền truy cập origin phải được xác thực rõ ràng và có thể kiểm toán thay vì giả định. Nhiều lợi ích cụ thể theo ngành được giới thiệu với viewer mTLS giờ đây áp dụng đầu cuối. Chúng bao gồm danh tính client mạnh mẽ cho API, xác thực thiết bị và tuân thủ quy định, được kích hoạt bởi xác thực hai chiều từ người dùng cuối thông qua CloudFront đến origin. Để khám phá sâu hơn các trường hợp sử dụng đó theo ngành, hãy tham khảo bài viết trước của chúng tôi về viewer mTLS, vẫn là nền tảng để hiểu cách mTLS đầu cuối mở rộng các nguyên tắc zero-trust ra ngoài biên.
mTLS hoạt động như thế nào
Trong TLS tiêu chuẩn, quản lý chứng chỉ chủ yếu là một chiều. Máy chủ trình bày một chứng chỉ được client xác thực dựa trên một Certificate Authority (CA) đáng tin cậy, trong khi client vẫn không được xác thực ở lớp vận chuyển. Về mặt vận hành, điều này giữ cho việc quản lý chứng chỉ trực tiếp: các nhóm chỉ cung cấp, xoay vòng và giám sát chứng chỉ cho máy chủ, thường sử dụng công cụ tự động và các CA được công khai tin cậy. Danh tính client, nếu cần, được đẩy lên stack vào các cơ chế lớp ứng dụng, chẳng hạn như API keys, OAuth tokens hoặc headers.
mTLS thay đổi cơ bản mô hình này bằng cách giới thiệu xác thực hai chiều. Cả client và server đều phải trình bày các chứng chỉ hợp lệ và xác minh chúng dựa trên các CA đáng tin cậy. Do đó, quản lý chứng chỉ mở rộng từ việc quản lý một tập hợp nhỏ, được xác định rõ ràng các chứng chỉ máy chủ sang quản lý các đội chứng chỉ client tiềm năng lớn. Điều này đưa ra các cân nhắc vận hành mới: cấp phát và thu hồi chứng chỉ, tự động hóa vòng đời, phân phối sự tin cậy của CA và kiểm soát phạm vi ảnh hưởng khi chứng chỉ bị xâm phạm hoặc cần xoay vòng.
Khi mTLS được chấm dứt tại biên CloudFront, nó hấp thụ phần lớn sự phức tạp vận hành này bằng cách hoạt động như điểm thực thi chứng chỉ để xác thực client. Khách hàng quản lý các trust anchor và chính sách client, trong khi CloudFront xử lý xác thực ở quy mô lớn. Với mTLS được mở rộng đến origin, quản lý chứng chỉ vẫn phù hợp với mô hình này: CloudFront trình bày chứng chỉ client của riêng nó cho origin và xác thực chứng chỉ của origin để đáp lại. Điều này bảo toàn xác thực hai chiều mà không yêu cầu các origin phải quản lý hoặc tin cậy chứng chỉ cho mọi người dùng cuối trực tiếp.
Điều kiện tiên quyết
Các điều kiện tiên quyết sau đây là cần thiết để bật tính năng này:
- Chuẩn bị một chứng chỉ client X.509v3 (định dạng PEM), có extended key usage (clientAuth)
- Các máy chủ origin được cấu hình để yêu cầu xác thực mTLS và xác thực chứng chỉ client
- Chọn AWS Region US East (us-east-1) trên AWS Certificate Manager (ACM).
Hướng dẫn chi tiết
Việc triển khai xác thực mTLS giữa CloudFront và các origin của bạn bao gồm ba bước chính: lấy chứng chỉ client thông qua ACM, cấu hình máy chủ origin của bạn và bật mTLS trên CloudFront distribution của bạn.
Bước 1: Cấu hình chứng chỉ client
CloudFront hỗ trợ chứng chỉ client từ hai nguồn, mỗi nguồn phù hợp với các nhu cầu vận hành khác nhau: AWS Private Certificate Authority và các CA của bên thứ ba.
AWS Private Certificate Authority (được khuyến nghị)
AWS Private Certificate Authority cung cấp vòng đời chứng chỉ được quản lý hoàn toàn với gia hạn tự động và tích hợp ACM liền mạch. Cách tiếp cận này loại bỏ chi phí quản lý chứng chỉ thủ công.
Để yêu cầu chứng chỉ:
- Mở bảng điều khiển ACM và đảm bảo bạn đang ở Region US East (N. Virginia).
- Chọn Request a certificate > Request a private certificate.
- Chọn CA của bạn và nhập tên miền của bạn.
- Chọn thuật toán khóa ưu tiên của bạn và xác nhận quyền gia hạn.
- Chọn Request.
Hình 1: Bắt đầu yêu cầu chứng chỉ SSL/TLS mới trong AWS Certificate Manager để bật HTTPS an toàn cho các điểm cuối ứng dụng.
Các CA của bên thứ ba
Nhập các chứng chỉ hiện có từ cơ sở hạ tầng CA riêng của bạn để duy trì các quy trình quản lý chứng chỉ hiện tại trong khi có được khả năng mTLS của CloudFront, như được hiển thị trong Hình 2 (bên dưới).
Để nhập chứng chỉ:
- Trong bảng điều khiển ACM, chọn Import a certificate.
- Cung cấp certificate body, private key và certificate chain (tất cả ở định dạng PEM).
- Chọn Import certificate.
Chứng chỉ client phải bao gồm extended key usage (clientAuth) để xác thực mTLS.
Hình 2: Tải lên chứng chỉ client và private key hiện có vào AWS Certificate Manager để quản lý an toàn các chứng chỉ được sử dụng để xác thực mTLS với AWS.
Bước 2: Bật mTLS trên các origin
Cấu hình xác thực mTLS cho mỗi origin yêu cầu xác thực dựa trên chứng chỉ, như được hiển thị trong Hình 3 (bên dưới):
- Trong bảng điều khiển CloudFront, điều hướng đến tab Origins của distribution của bạn.
- Chọn origin bạn muốn cấu hình và chọn Edit.
- Trong cài đặt origin, chuyển đổi mTLS sang On.
- Chọn chứng chỉ client của bạn từ menu thả xuống.
- Lưu các thay đổi của bạn.
Hình 3: Cài đặt CloudFront cho phép xác thực mTLS cho các yêu cầu origin, cho phép CloudFront thực thi xác thực dựa trên chứng chỉ trên origin.
Tính linh hoạt theo từng origin
mTLS được cấu hình ở cấp độ origin, do đó bạn có thể gán các chứng chỉ khác nhau cho các origin khác nhau trong cùng một distribution. Điều này cho phép các chính sách bảo mật được tùy chỉnh. Ví dụ, sử dụng chứng chỉ bảo mật cao cho các API endpoint trong khi áp dụng xác thực tiêu chuẩn cho các origin phân phối nội dung tĩnh, như được hiển thị trong Hình 4 (bên dưới).
Hình 4: CloudFront thiết lập TLS hai chiều với origin, đảm bảo các yêu cầu được xác thực và mã hóa từ biên đến các dịch vụ backend.
Cân bằng bảo mật và hiệu suất với mTLS đầu cuối trên CloudFront
Việc bật mTLS đầu cuối—từ người dùng cuối đến CloudFront, và từ CloudFront đến origin—gây ra một số chi phí phụ trội trong quá trình thiết lập kết nối. Điều này là do mỗi phân đoạn yêu cầu xác thực chứng chỉ và các hoạt động mã hóa để xác thực cả hai bên. Tuy nhiên, chi phí phụ trội này chủ yếu giới hạn ở giai đoạn bắt tay và không ảnh hưởng đến việc truyền dữ liệu ứng dụng ở trạng thái ổn định. Các cơ chế tái sử dụng kết nối—chẳng hạn như gộp kết nối (connection pooling) và sử dụng các kết nối keep-alive dài hạn trên CloudFront—giảm chi phí này trên nhiều yêu cầu của người dùng cuối. Điều này giảm thiểu tác động đến cả độ trễ và thông lượng cho hầu hết các khối lượng công việc. CloudFront lưu trữ một phần đáng kể lưu lượng truy cập tại biên, do đó phần lớn các yêu cầu không bao giờ đến origin, điều này tiếp tục giảm tác động hiệu suất tương đối. Với TLS 1.3 và quản lý chứng chỉ phù hợp, sự đánh đổi giữa chi phí thiết lập kết nối cao hơn một chút và xác thực đầu cuối mạnh mẽ là có lợi. Chúng tôi khuyến nghị triển khai mTLS như một biện pháp kiểm soát thực hành tốt nhất để bảo mật lưu lượng ứng dụng được phân phối qua CloudFront.
Đối với quản lý chứng chỉ, AWS Private CA hợp lý hóa quy trình với việc xử lý vòng đời hoàn toàn tự động và thông báo gia hạn theo các khoảng thời gian 45, 30, 15, 7 và 1 ngày. Nếu bạn đang sử dụng chứng chỉ của bên thứ ba, hãy thiết lập một quy trình để gia hạn thủ công kịp thời nhằm tránh bất kỳ gián đoạn nào trong kết nối mTLS.
Kết luận
mTLS giữa Amazon CloudFront và origin lấp đầy một trong những lỗ hổng tin cậy thường bị bỏ qua nhất trong các kiến trúc biên hiện đại. Mặc dù Phần 1 đã thiết lập danh tính và xác thực mạnh mẽ giữa người dùng cuối và CloudFront, việc mở rộng mTLS đến origin đảm bảo rằng mọi chặng trong đường dẫn yêu cầu đều được xác thực, mã hóa và ủy quyền. Điều này chuyển bảo mật từ mô hình dựa trên IP và mạng sang mô hình tin cậy mã hóa, nơi origin chỉ phục vụ lưu lượng truy cập có thể chứng minh nó đến từ CloudFront. Khi các ứng dụng ngày càng dựa vào các biên phân tán, API riêng tư và các nguyên tắc zero-trust, mTLS từ CloudFront đến origin trở thành một biện pháp kiểm soát nền tảng chứ không phải là một bước tăng cường tùy chọn. Khi kết hợp, mTLS của người dùng cuối và mTLS của origin cung cấp sự đảm bảo danh tính đầu cuối thực sự, giảm bề mặt tấn công, hợp lý hóa việc tuân thủ và tạo ra một vành đai ứng dụng kiên cường.
Về tác giả
Sagar Desarda
Sagar Desarda là Trưởng bộ phận Tổ chức Quản lý Tài khoản Kỹ thuật (TAM) cho các ISV về Dữ liệu, AI và Khả năng Quan sát trên khắp NAMER. Các nhóm của Sagar hợp tác với khách hàng để tối ưu hóa kiến trúc AWS của họ, đảm bảo hoạt động liền mạch của các ứng dụng quan trọng đối với doanh nghiệp, đẩy nhanh việc áp dụng và thúc đẩy thành công tiếp cận thị trường trên khắp Bắc Mỹ. Ngoài ra, Sagar còn là lãnh đạo AMER cho nhóm Chuyên gia Dịch vụ Mạng Biên, nơi anh thúc đẩy tăng trưởng kinh doanh mới, nuôi dưỡng các cam kết kỹ thuật và là tác giả của các ấn phẩm hướng tới khách hàng.
Yutaka Oka
Yutaka Oka là Kiến trúc sư Giải pháp Chuyên gia Biên cao cấp có trụ sở tại Tokyo. Trọng tâm chính của anh là giúp khách hàng tối ưu hóa và bảo mật việc phân phối nội dung bằng cách sử dụng các Dịch vụ Biên của AWS.
TAGS: Amazon CloudFront
AWS Study Group 