Giới thiệu về TLS/SSL

Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về 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 đườ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 đều ở 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 cách sử dụng giao thức HTTPS đã mã hoá, thay vì giao thức HTTP chưa mã hoá.

Edge hỗ trợ TLS một chiều và TLS hai chiều trong cả môi trường triển khai trên đám mây và tại chỗ (đối với các phiên bản TLS được hỗ trợ, hãy xem phần Phần mềm được hỗ trợ và các 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 (ứng dụng khách) có thể xác minh danh tính của các API Edge (máy chủ).

Apigee cũng hỗ trợ một hình thức xác thực mạnh hơn bằng cách sử dụng TLS hai chiều hoặc ứng dụng. Bạn thường 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 mình khỏi các cuộc tấn công máy khách, chẳng hạn như giả mạo máy khách hoặc tấn công giả mạo trung gian. Trong TLS hai chiều, ứng dụng xác minh danh tính của máy chủ, sau đó máy chủ xác minh danh tính của ứng dụng.

Thuật ngữ TLS

Bạn nên làm quen với 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

Canada

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, 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ỉ, được 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ư. Tệp 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ó chứng chỉ đã hết hạn và muốn gia hạn.

DER

Quy tắc mã hoá được phân 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 tệp là .der nhưng thường có đuôi tệp là .cer. Cách duy nhất để phân biệt tệp .cer DER với tệp .cer PEM là mở tệp trong trình chỉnh sửa văn bản và tìm 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á theo định dạng DER. DER thường được dùng với các nền tảng Java.

Biệt hiệu khoá

Bí danh khoá xác định duy nhất một mục nhập 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 dùng để xác định thực thể trong quá trình bắt tay TLS giữa Ứng dụng khách và Máy chủ.

Trên kết nối hướng bắc, 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 từ dưới lên, 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 ứng dụng đượ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 ASCII Base64 và có đuôi tệp là .p7b hoặc .p7c. Chứng chỉ P7B chứa câu lệnh -----BEGIN PKCS7----- và -----END PKCS7-----. Tệp P7B chỉ chứa các chứng chỉ và chuỗi chứng chỉ, 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à định dạng ASCII dựa trên văn bản, là một mã hoá Base64 của định dạng Quy tắc mã hoá đặc biệt (DER) nhị phân. 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 tách giữa các câu lệnh -----BEGIN CERTIFICATE----- và -----END CERTIFICATE-----.

Định dạng 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 tệp đó 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à đị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 máy Windows để nhập và xuất chứng chỉ cũng như khoá riêng tư.

Khoá riêng tư

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

Khoá công khai

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

Tài liệu tham khảo Các tệp 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à cùng một tệp tham chiếu và bí danh khoá được duy trì. Điều này giúp bạn tự thực hiện những thay đổi này và giảm các phần phụ thuộc với Nhóm hỗ trợ Apigee.

Chứng chỉ tự ký

Chứng chỉ không do một CA đáng tin cậy ký. Bên 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 phân phát nhiều mục tiêu HTTPS 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

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 khách 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 ứ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 do CA đáng tin cậy ký.

Trên kết nối từ bắc đến nam, các chứng chỉ của ứng dụng khách hàng được lưu trữ trong kho tin cậy 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 ứng dụng và Apigee.

Trên kết nối từ dưới lên, các chứng chỉ của máy chủ phụ trợ được lưu trữ trong kho tin cậy trong Apigee Edge. Bạn bắt buộc phải làm việc này nếu muốn xác minh chứng chỉ của phần phụ trợ trong Apigee Edge theo phương thức 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 kho tin cậy riêng. Do đó, kho lưu trữ đáng tin cậy được tạo dưới dạng đối tượng kho khoá, nhưng được tham chiếu dưới dạng kho lưu trữ đáng tin cậy bất cứ khi nào được sử dụng (ví dụ: trong máy chủ lưu trữ ảo, điểm cuối mục tiêu, máy chủ mục tiêu, 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 nó, 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ủ.

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

Bạn có thể định cấu hình máy chủ ảo hỗ trợ SSL ở chế độ TLS một chiều hoặc hai chiều. Tệp này được định cấu hình bằng các 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, kho lưu trữ đáng tin cậy (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 cho thấy quy trình bắt tay TLS/SSL để xác thực một chiều giữa ứng dụng 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:

  • Ứng dụng 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. Chứng chỉ này đến từ kho khoá của máy chủ, kho khoá này 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 ứng dụng.
  • Đối với chứng chỉ đã ký, ứng dụng sử dụng một kho tin cậy chứa 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á.
  • Ứng dụng khách bắt đầu chuyển dữ liệu TLS với máy chủ.

Hình sau đây cho thấy quy trình bắt tay TLS/SSL bằng cách sử dụng kho tin cậy 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 do một CA đáng tin cậy ký, thì bạn sẽ tạo một kho lưu trữ tin cậy trên ứng dụng. Ứng dụng sẽ điền vào kho tin cậy của mình bằng các chứng chỉ máy chủ và khoá công khai mà ứng dụng tin cậy. 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 kho tin cậy 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 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 khách 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àm ứng dụng khách TLS

    Edge đóng vai trò là ứ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ư.

TLS hai chiều

Hình sau đây cho thấy quy 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:

  • Máy khách và máy chủ đều có kho khoá riêng. Kho khoá của ứng dụng chứa chứng chỉ và khoá riêng tư, còn kho khoá của máy chủ chứa chứng chỉ và khoá riêng tư.
  • Máy chủ TLS hiển thị chứng chỉ của mình 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 ứng dụng đến máy chủ.
  • Ứng dụng TLS hiển thị chứng chỉ của ứng dụng cho máy chủ TLS để xác thực chính ứng dụng với máy chủ.

Hình sau đây cho thấy quá trình bắt tay TLS bằng cách sử dụng kho tin cậy không bắt buộc:

Trong trường hợp này, quy 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 do một CA đáng tin cậy ký, thì bạn sẽ tạo một kho lưu trữ tin cậy trên ứng dụng. Ứng dụng có một bản sao của chứng chỉ máy chủ trong kho tin cậy. Trong quá trình bắt tay TLS, ứng dụng so sánh chứng chỉ trong kho tin cậy 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 ứng dụng TLS sử dụng chứng chỉ tự ký hoặc chứng chỉ không 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 chủ.Máy chủ có một bản sao của chứng chỉ ứng dụng trong kho lưu trữ đáng tin cậy. Trong quá trình bắt tay TLS, máy chủ so sánh chứng chỉ trong kho tin cậy với chứng chỉ do máy khách gửi để xác minh danh tính của máy khách.

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

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

  • Edge làm 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 khách là một ứng dụng đang cố 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 ứng dụng.

  • Edge làm ứng dụng

    Edge đóng vai trò là ứ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ư.

    Edge cũng phải xác định một kho khoá chứa chứng chỉ cần thiết để tự xác thực với dịch vụ phụ trợ và tuỳ ý là một kho 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 do một 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ừ 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à ứng dụng TLS, trong cả quá trình cài đặt trên đám mây và trên đám mây riêng tư.

Với SNI (phần mở rộng 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 lượt 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 (northbound) đề cập đến điểm cuối API mà các ứng dụng khách sử dụng để gọi Proxy API. Thông thường, Trình đị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 (Trình định tuyến) được gọi là phía bắc.

Trong Apigee, hướng nam (southbound) đề cập đến điểm cuối mục tiêu mà Apigee sử 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 (chiều từ máy khách đến máy chủ). Trình xử lý thông báo là một thành phần của Apigee Edge, giúp chuyển tiếp các yêu cầu API đến máy chủ đích phụ trợ.

Hình sau đây minh hoạ các kết nối hướng bắc và hướng nam cho Apigee Edge:

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