Giới thiệu về TLS/SSL

Bạn đang xem tài liệu về Apigee Edge.
Truy cập vào tài liệu Apigee X. thông tin

Bảo mật tầng truyền tải (TLS) (tiền thân là Lớp ổ cắm bảo mật (SSL)) là công nghệ bảo mật tiêu chuẩn để thiết lập một đường liên kết được mã hoá giữa máy chủ web và ứng dụng web, chẳng hạn như trình duyệt hoặc ứng dụng. Đường liên kết được mã hoá đảm bảo rằng tất cả dữ liệu truyền giữa máy chủ và ứng dụng vẫn ở chế độ riêng tư. Để sử dụng TLS, ứng dụng khách sẽ gửi một yêu cầu bảo mật đến máy chủ bằng giao thức HTTPS được mã hoá, thay vì giao thức HTTP không được mã hoá.

Edge hỗ trợ TLS một chiều và TLS hai chiều trong cả quá trình triển khai trên đám mây và tại chỗ (để biết các phiên bản TLS được hỗ trợ, hãy xem Phần mềm và phiên bản được hỗ trợ). TLS một chiều cho phép ứng dụng TLS xác minh danh tính của máy chủ TLS. Ví dụ: một ứng dụng chạy trên điện thoại Android (máy khách) có thể xác minh danh tính của API Edge (máy chủ).

Apigee cũng hỗ trợ một hình thức xác thực mạnh mẽ hơn bằng cách sử dụng TLS hai chiều hoặc TLS ứng dụng. Thông thường, bạn sẽ triển khai TLS hai chiều để tăng cường bảo mật toàn diện và bảo vệ dữ liệu của bạn khỏi các cuộc tấn công của máy khách, chẳng hạn như tấn công giả mạo máy khách hoặc tấn công trung gian. Trong TLS hai chiều, ứng dụng sẽ xác minh danh tính của máy chủ, sau đó máy chủ sẽ xác minh danh tính của ứng dụng.

Thuật ngữ TLS

Bạn cần nắm rõ các thuật ngữ và khái niệm quan trọng sau đây trước khi định cấu hình TLS:

Thuật ngữ

Định nghĩa

CA

Tổ chức phát hành chứng chỉ. Một thực thể đáng tin cậy (chẳng hạn như Symantec hoặc VeriSign) được dùng để phát hành chứng chỉ và xác thực tính xác thực của chứng chỉ. Một loại chứng chỉ (gọi là chứng chỉ tự ký) không yêu cầu CA.

Chuỗi chứng chỉ

Thường thì bạn sẽ không có chứng chỉ được ký bằng khoá riêng tư gốc của CA. Thay vào đó, bạn có chứng chỉ cùng với một hoặc nhiều chứng chỉ trung gian tạo thành một chuỗi. Chứng chỉ trung gian cuối cùng trong chuỗi thường được ký bằng khoá riêng tư gốc của CA.

CSR

Yêu cầu ký chứng chỉ. CSR là một tệp được tạo trên máy chủ TLS dựa trên khoá riêng tư. CSR chứa khoá công khai và các thông tin khác như tên, vị trí và tên miền của tổ chức. CA ký CSR để tạo chứng chỉ TLS. Bạn thường tạo CSR khi có một chứng chỉ đã hết hạn và muốn gia hạn chứng chỉ đó.

DER

Quy tắc mã hoá riêng biệt. Định dạng DER là một dạng nhị phân của chứng chỉ thay vì định dạng PEM ASCII. Đôi khi, tệp này có đuôi là .der nhưng thường có đuôi là .cer. Cách duy nhất để phân biệt tệp .cer DER và tệp .cer PEM là mở tệp trong trình chỉnh sửa văn bản và tìm các câu lệnh BEGIN và END. Tất cả các loại chứng chỉ và khoá riêng tư đều có thể được mã hoá ở định dạng DER. DER thường được dùng với các nền tảng Java.

Tên thay thế của khoá

Bí danh khoá xác định duy nhất một mục trong kho khoá (chứng chỉ TLS và khoá riêng tư tương ứng) trong kho khoá.

Trong Apigee Edge, KeyAlias được gọi là alias khi bạn tải chứng chỉ/khoá lên kho khoá bằng giao diện người dùng hoặc API.

Kho khoá

Kho khoá là một kho lưu trữ chứa một hoặc nhiều chứng chỉ TLS và một khoá riêng tư tương ứng được dùng để xác định thực thể trong quá trình bắt tay TLS giữa Máy khách và Máy chủ.

Trên kết nối northbound, Bộ định tuyến đóng vai trò là máy chủ và chứng chỉ của bộ định tuyến được lưu trữ trong kho khoá trong Apigee Edge.

Trên kết nối theo hướng nam, Trình xử lý thông báo đóng vai trò là máy khách và máy chủ phụ trợ đóng vai trò là máy chủ. Chứng chỉ ứng dụng và khoá riêng tư của chứng chỉ đó được lưu trữ trong kho khoá trong Apigee Edge.

P7B

Định dạng PKCS #7 hoặc P7B thường được lưu trữ ở định dạng Base64 ASCII và có đuôi tệp là .p7b hoặc .p7c. Chứng chỉ P7B chứa các câu lệnh -----BEGIN PKCS7----- và -----END PKCS7-----. Tệp P7B chỉ chứa các chứng chỉ và chứng chỉ chuỗi, chứ không chứa khoá riêng tư.

PEM

Định dạng Thư được tăng cường tính bảo mật (PEM) là một định dạng ASCII dựa trên văn bản, là phương thức mã hoá Base64 của định dạng Nhị phân theo quy tắc mã hoá riêng biệt (DER). Bạn có thể mở chứng chỉ PEM trong bất kỳ Trình chỉnh sửa văn bản nào và nội dung chứng chỉ thực tế được phân định giữa các câu lệnh -----BEGIN CERTIFICATE----- và -----END CERTIFICATE-----.

Tệp này tuân thủ định dạng X.509 để lưu trữ chứng chỉ, chuỗi chứng chỉ hoặc khoá riêng tư. Nếu chứng chỉ hoặc khoá riêng tư của bạn không được xác định bằng tệp PEM, bạn có thể chuyển đổi chứng chỉ hoặc khoá riêng tư đó thành tệp PEM bằng cách sử dụng các tiện ích như OpenSSL.

PKCS #12/PFX Định dạng PKCS #12 hoặc PFX là một định dạng nhị phân để lưu trữ chứng chỉ máy chủ, mọi chứng chỉ trung gian và khoá riêng tư trong một tệp có thể mã hoá. Tệp PFX thường có các đuôi như .pfx và .p12. Tệp PFX thường được dùng trên các máy Windows để nhập và xuất chứng chỉ cũng như khoá riêng tư.

Khoá riêng tư

Được dùng trên máy chủ TLS để giải mã dữ liệu. Chỉ máy chủ TLS có khoá riêng tư, khoá này không được chia sẻ với các ứng dụng TLS.

Khoá công khai

Được dùng để mã hoá dữ liệu gửi từ máy khách TLS đến máy chủ TLS. Khoá công khai được đưa vào chứng chỉ. Tất cả các ứng dụng TLS đều có bản sao khoá công khai của máy chủ.

Tài liệu tham khảo Các tham chiếu cung cấp một mức độ gián tiếp cho kho khoá; do đó, các thay đổi đối với kho khoá không yêu cầu cập nhật máy chủ ảo miễn là bạn duy trì cùng một tham chiếu và bí danh khoá. Điều này giúp bạn tự thực hiện những thay đổi này và giảm sự phụ thuộc vào Nhóm hỗ trợ Apigee.

Chứng chỉ tự ký

Một chứng chỉ không được CA đáng tin cậy ký. Đơn vị phát hành và chủ thể giống hệt nhau; chúng được ký bằng khoá riêng tư khớp với khoá công khai mà chúng chứa.

SNI

Chỉ báo tên máy chủ. Cho phép nhiều mục tiêu HTTPS được phân phát từ cùng một địa chỉ IP và cổng mà không yêu cầu các mục tiêu đó sử dụng cùng một chứng chỉ.

Chứng chỉ TLS

Một tệp kỹ thuật số xác định một thực thể trong giao dịch TLS. Bạn có thể dùng chứng chỉ hoặc cert để xác định máy chủ TLS và ứng dụng TLS, tuỳ thuộc vào cấu hình TLS.

Truststore

Chứa các chứng chỉ đáng tin cậy trên một ứng dụng TLS dùng để xác thực chứng chỉ của máy chủ TLS được trình bày cho ứng dụng. Các chứng chỉ này thường là chứng chỉ tự ký hoặc chứng chỉ không được CA đáng tin cậy ký.

Trên kết nối hướng bắc, chứng chỉ của ứng dụng khách được lưu trữ trong truststore trong Apigee Edge. Bạn chỉ phải cung cấp thuộc tính này nếu đã định cấu hình TLS hai chiều giữa máy khách và Apigee.

Trên kết nối southbound, các chứng chỉ của máy chủ phụ trợ được lưu trữ trong truststore trong Apigee Edge. Đây là yêu cầu bắt buộc nếu bạn muốn xác minh chứng chỉ của phần phụ trợ trong Apigee Edge trong giao tiếp TLS một chiều hoặc hai chiều giữa Apigee Edge và máy chủ phụ trợ.

Apigee Edge không có đối tượng truststore riêng. Do đó, truststore được tạo dưới dạng một đối tượng kho khoá, nhưng được tham chiếu dưới dạng truststore bất cứ khi nào được sử dụng (ví dụ: trong máy chủ ảo, điểm cuối đích, máy chủ đích, v.v.).

Máy chủ ảo

Máy chủ ảo đại diện cho điểm cuối API Apigee cho các ứng dụng khách. Đây là một thực thể hỗ trợ việc lưu trữ nhiều tên miền (với việc xử lý riêng từng tên) trên một máy chủ (hoặc nhóm máy chủ). Điều này cho phép một máy chủ chia sẻ tài nguyên của mình, chẳng hạn như bộ nhớ và chu kỳ xử lý, mà không yêu cầu tất cả các dịch vụ được cung cấp phải sử dụng cùng một tên máy chủ lưu trữ.

Máy chủ ảo có thể phân phát lưu lượng truy cập HTTP hoặc HTTPS (đã bật SSL).

Bạn có thể thiết lập máy chủ ảo có hỗ trợ SSL ở chế độ TLS một chiều hoặc hai chiều. Thẻ này được định cấu hình bằng những thông tin sau:

  • Một hoặc nhiều hostalias (tên DNS của điểm cuối API).
  • Cổng
  • Kho khoá
  • Bí danh khoá để xác định duy nhất một trong các chứng chỉ máy chủ trong kho khoá.
  • Không bắt buộc, một truststore (trong TLS hai chiều, nơi bật tính năng xác thực máy khách).

TLS/SSL một chiều

Hình sau đây minh hoạ quy trình bắt tay TLS/SSL để xác thực một chiều giữa máy khách TLS và máy chủ TLS:

Trong cấu hình TLS một chiều, quá trình bắt tay diễn ra như sau:

  • Máy khách gửi yêu cầu phiên đến máy chủ.
  • Máy chủ phản hồi bằng một chứng chỉ chứa khoá công khai của máy chủ. Chứng chỉ này đến từ kho khoá của máy chủ, trong đó cũng chứa khoá riêng tư của máy chủ. Khoá riêng tư không bao giờ được gửi đến máy khách.
  • Đối với chứng chỉ đã ký, ứng dụng sẽ sử dụng một truststore chứa các chứng chỉ máy chủ và khoá công khai để xác thực rằng chuỗi chứng chỉ được ký bởi một Tổ chức phát hành chứng chỉ (CA) đáng tin cậy.
  • Máy khách và máy chủ trao đổi thêm một số thông báo để xác thực khoá.
  • Máy khách bắt đầu chuyển dữ liệu TLS với máy chủ.

Hình sau đây minh hoạ quá trình bắt tay TLS/SSL bằng cách sử dụng một truststore không bắt buộc trên máy khách:

Nếu máy chủ TLS sử dụng chứng chỉ tự ký hoặc chứng chỉ không phải do một CA đáng tin cậy ký, thì bạn sẽ tạo một kho lưu trữ đáng tin cậy trên máy khách. Ứng dụng sẽ điền sẵn các chứng chỉ máy chủ và khoá công khai mà ứng dụng tin tưởng vào truststore. Khi máy khách nhận được một chứng chỉ, chứng chỉ đến sẽ được xác thực dựa trên các chứng chỉ trong truststore của máy khách.

Trong TLS một chiều, Edge có thể là máy chủ hoặc ứng dụng khách như sau:

  • Edge là máy chủ TLS

    Edge là máy chủ lưu trữ điểm cuối TLS, trong đó điểm cuối TLS tương ứng với một proxy API được triển khai cho một máy chủ ảo. Ứng dụng này là một ứng dụng đang cố gắng truy cập vào proxy API. Trong trường hợp này, Edge có kho khoá chứa chứng chỉ và khoá riêng tư.

  • Edge là ứng dụng TLS

    Edge đóng vai trò là ứng dụng truy cập vào một dịch vụ phụ trợ. Trong trường hợp này, dịch vụ phụ trợ tương ứng với máy chủ lưu trữ một điểm cuối TLS. Do đó, máy chủ phụ trợ có một kho khoá chứa chứng chỉ và khoá riêng tư của máy chủ đó.

TLS hai chiều

Hình sau đây minh hoạ quá trình bắt tay TLS/SSL để xác thực TLS hai chiều giữa máy khách và máy chủ:

Trong TLS hai chiều, quá trình bắt tay diễn ra như sau:

  • Cả máy khách và máy chủ đều có kho khoá riêng. Kho khoá của máy khách chứa chứng chỉ và khoá riêng tư của máy khách, còn kho khoá của máy chủ chứa chứng chỉ và khoá riêng tư của máy chủ.
  • Máy chủ TLS xuất trình chứng chỉ cho ứng dụng TLS để tự xác thực. Sau đó, ứng dụng sẽ xác minh danh tính của máy chủ trước khi gửi chứng chỉ của máy chủ.
  • Ứng dụng TLS trình bày chứng chỉ của mình cho máy chủ TLS để xác thực chính nó với máy chủ.

Hình sau đây minh hoạ quá trình bắt tay TLS bằng cách sử dụng một truststore không bắt buộc:

Trong trường hợp này, quá trình bắt tay diễn ra như sau:

  • Nếu máy chủ TLS sử dụng chứng chỉ tự ký hoặc chứng chỉ không phải do CA đáng tin cậy ký, thì bạn sẽ tạo một kho lưu trữ đáng tin cậy trên máy khách. Ứng dụng có một bản sao chứng chỉ của máy chủ trong truststore. Trong quá trình bắt tay TLS, ứng dụng sẽ so sánh chứng chỉ trong truststore của ứng dụng với chứng chỉ được gửi từ máy chủ để xác minh danh tính của máy chủ.
  • Nếu máy khách TLS sử dụng chứng chỉ tự ký hoặc chứng chỉ không phải do CA đáng tin cậy ký, thì bạn sẽ tạo một truststore trên máy chủ.Máy chủ có một bản sao chứng chỉ của máy khách trong truststore của máy chủ. Trong quá trình bắt tay TLS, máy chủ so sánh chứng chỉ trong truststore với chứng chỉ được gửi từ ứng dụng để xác minh danh tính của ứng dụng.

Ứng dụng hoặc máy chủ hoặc cả hai đều có thể sử dụng truststore.

Trong TLS hai chiều, Edge có thể là máy chủ hoặc ứng dụng khách như sau:

  • Edge là máy chủ

    Edge là máy chủ lưu trữ điểm cuối TLS, trong đó điểm cuối TLS tương ứng với một proxy API. Ứng dụng này là một ứng dụng đang cố gắng truy cập vào proxy API. Trong trường hợp này, Edge có một kho khoá chứa chứng chỉ và khoá riêng tư, đồng thời yêu cầu một kho tin cậy chứa chứng chỉ và chuỗi CA của máy khách.

  • Edge là ứng dụng

    Edge đóng vai trò là một ứng dụng truy cập vào dịch vụ phụ trợ. Trong trường hợp này, dịch vụ phụ trợ tương ứng với máy chủ lưu trữ điểm cuối TLS. Do đó, máy chủ phụ trợ có một kho khoá chứa chứng chỉ và khoá riêng tư của máy chủ đó.

    Edge cũng phải xác định một kho khoá chứa chứng chỉ cần thiết để xác thực chính nó với dịch vụ phụ trợ và tuỳ ý là một kho lưu trữ đáng tin cậy chứa chứng chỉ từ máy chủ phụ trợ nếu máy chủ sử dụng chứng chỉ tự ký hoặc chứng chỉ không được CA đáng tin cậy ký.

Điều quan trọng cần nhớ là Edge đủ linh hoạt để hỗ trợ TLS hai chiều, bất kể bạn quyết định định cấu hình như thế nào.

Hỗ trợ SNI

Edge hỗ trợ việc sử dụng Chỉ báo tên máy chủ (SNI) từ các proxy API đến Edge, trong đó Edge đóng vai trò là máy chủ TLS và từ Edge đến các điểm cuối mục tiêu, trong đó Edge đóng vai trò là máy khách TLS, trong cả các bản cài đặt Cloud và Private Cloud.

Với SNI (một tiện ích của TLS/SSL), nhiều mục tiêu HTTPS có thể được phân phát từ cùng một địa chỉ IP và cổng mà không yêu cầu các mục tiêu đó sử dụng cùng một chứng chỉ.

Để biết thông tin về cách bật SNI cho một bản cài đặt tại chỗ, hãy xem bài viết Sử dụng SNI với Edge.

Hướng Bắc và hướng Nam

Trong Apigee, hướng bắc đề cập đến điểm cuối API mà các ứng dụng khách dùng để gọi API Proxy. Thông thường, Bộ định tuyến là điểm truy cập trong Apigee Edge và xử lý các yêu cầu đến Apigee Edge. Do đó, trong Apigee, điểm cuối dùng để giao tiếp giữa ứng dụng khách và Apigee Edge (Bộ định tuyến) được gọi là hướng bắc.

Trong Apigee, hướng nam đề cập đến điểm cuối đích mà Apigee dùng để giao tiếp với máy chủ phụ trợ. Do đó, trong Apigee, điểm cuối dùng để giao tiếp giữa Apigee Edge (Trình xử lý thông báo) và máy chủ phụ trợ được gọi là southbound (hướng nam). Message Processor là một thành phần của Apigee Edge, có chức năng làm proxy cho các yêu cầu API đến các máy chủ đích phụ trợ.

Hình sau đây minh hoạ các kết nối chiều đi và chiều về cho Apigee Edge:

Luồng lưu thông theo hướng bắc và hướng nam. Ứng dụng khách đến Bộ định tuyến là hướng bắc. Sau đó, hãy chuyển đến Message Processor (Bộ xử lý tin nhắn). Bộ xử lý thông báo đến Máy chủ phụ trợ là hướng nam.