Tentang TLS/SSL

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X. info

Transport Layer Security (TLS), yang pendahulunya adalah Secure Sockets Layer (SSL), adalah teknologi keamanan standar untuk membuat link terenkripsi antara server web dan klien web, seperti browser atau aplikasi. Link terenkripsi memastikan bahwa semua data yang melewati antara server dan klien tetap bersifat pribadi. Untuk menggunakan TLS, klien membuat permintaan aman ke server menggunakan protokol HTTPS terenkripsi, bukan protokol HTTP yang tidak terenkripsi.

Edge mendukung TLS satu arah dan TLS dua arah dalam deployment cloud dan lokal (untuk versi TLS yang didukung, lihat Software yang didukung dan versi yang didukung). TLS satu arah memungkinkan klien TLS memverifikasi identitas server TLS. Misalnya, aplikasi yang berjalan di ponsel Android (klien) dapat memverifikasi identitas API Edge (server).

Apigee juga mendukung bentuk autentikasi yang lebih kuat menggunakan TLS dua arah, atau klien. Anda biasanya menerapkan TLS dua arah untuk meningkatkan keamanan menyeluruh dan melindungi data Anda dari serangan klien seperti spoofing klien atau serangan man-in-the-middle. Dalam TLS dua arah, klien memverifikasi identitas server, lalu server memverifikasi identitas klien.

Terminologi TLS

Anda harus memahami istilah dan konsep penting berikut sebelum mengonfigurasi TLS:

Istilah

Definisi

CA

Certificate Authority. Entitas tepercaya, seperti Symantec atau VeriSign, yang digunakan untuk menerbitkan sertifikat dan memvalidasi keaslian sertifikat. Salah satu jenis sertifikat, yang disebut sertifikat yang ditandatangani sendiri, tidak memerlukan CA.

Rantai sertifikat

Sering kali Anda tidak memiliki sertifikat yang ditandatangani oleh kunci pribadi root CA Anda. Sebagai gantinya, Anda memiliki sertifikat bersama dengan satu atau beberapa sertifikat perantara yang membentuk rantai. Sertifikat perantara terakhir dalam rantai biasanya ditandatangani oleh kunci pribadi root CA.

CSR

Permintaan Penandatanganan Sertifikat. CSR adalah file yang dibuat di server TLS berdasarkan kunci pribadi. CSR berisi kunci publik dan informasi lainnya seperti nama, lokasi, dan nama domain organisasi. CA menandatangani CSR untuk membuat sertifikat TLS. Biasanya Anda membuat CSR saat memiliki sertifikat yang masa berlakunya telah berakhir dan ingin memperbaruinya.

DER

Distinguished Encoding Rules. Format DER adalah bentuk biner sertifikat, bukan format PEM ASCII. Terkadang memiliki ekstensi file .der, tetapi sering kali memiliki ekstensi file .cer. Satu-satunya cara untuk mengetahui perbedaan antara file .cer DER dan file .cer PEM adalah dengan membuka file di editor teks dan mencari pernyataan BEGIN dan END. Semua jenis sertifikat dan kunci pribadi dapat dienkode dalam format DER. DER biasanya digunakan dengan platform Java.

Alias kunci

Alias kunci mengidentifikasi entri keystore (sertifikat TLS dan kunci pribadi yang sesuai) secara unik di keystore.

Di Apigee Edge, KeyAlias disebut sebagai alias saat Anda mengupload sertifikat/kunci ke keystore menggunakan UI atau API.

Keystore

Keystore adalah repositori yang berisi satu atau beberapa sertifikat TLS dan kunci pribadi yang sesuai yang digunakan untuk mengidentifikasi entitas selama TLS handshake antara Klien dan Server.

Pada koneksi northbound, Router bertindak sebagai server dan sertifikatnya disimpan di keystore di Apigee Edge.

Pada koneksi southbound, Message Processor bertindak sebagai klien dan server backend bertindak sebagai server. Sertifikat klien dan kunci pribadinya disimpan di keystore di Apigee Edge.

P7B

Format PKCS #7 atau P7B biasanya disimpan dalam format ASCII Base64 dan memiliki ekstensi file .p7b atau .p7c. Sertifikat P7B berisi pernyataan -----BEGIN PKCS7----- dan -----END PKCS7-----. File P7B hanya berisi sertifikat dan sertifikat rantai, bukan kunci pribadi.

PEM

Format Privacy Enhanced Mail (PEM) adalah format ASCII berbasis teks yang merupakan encoding Base64 dari format Distinguished Encoding Rules (DER) biner. Sertifikat PEM dapat dibuka di Editor Teks apa pun dan konten sertifikat sebenarnya dibatasi di antara pernyataan -----BEGIN CERTIFICATE----- dan -----END CERTIFICATE-----.

File ini mematuhi format X.509 untuk menyimpan sertifikat, rantai sertifikat, atau kunci pribadi. Jika sertifikat atau kunci pribadi Anda tidak ditentukan oleh file PEM, Anda dapat mengonversinya menjadi file PEM menggunakan utilitas seperti OpenSSL.

PKCS #12/PFX Format PKCS #12 atau PFX adalah format biner untuk menyimpan sertifikat server, sertifikat perantara, dan kunci pribadi dalam satu file yang dapat dienkripsi. File PFX biasanya memiliki ekstensi seperti .pfx dan .p12. File PFX biasanya digunakan di komputer Windows untuk mengimpor dan mengekspor sertifikat dan kunci pribadi.

Kunci pribadi

Digunakan di server TLS untuk mendekripsi data. Hanya server TLS yang memiliki kunci pribadi—kunci tersebut tidak dibagikan kepada klien TLS.

Kunci publik

Digunakan untuk mengenkripsi data yang dikirim dari klien TLS ke server TLS. Kunci publik disertakan dalam sertifikat. Semua klien TLS memiliki salinan kunci publik server.

Referensi Referensi menyediakan tingkat pengalihan untuk keystore; oleh karena itu, perubahan keystore tidak memerlukan update host virtual selama referensi dan alias kunci yang sama dipertahankan. Dengan demikian, Anda dapat melakukan sendiri perubahan ini dan mengurangi dependensi dengan tim Dukungan Apigee.

Sertifikat yang ditandatangani sendiri

Sertifikat yang tidak ditandatangani oleh CA tepercaya. Penerbit dan subjek identik; keduanya ditandatangani dengan kunci pribadi yang cocok dengan kunci publik yang dikandungnya.

SNI

Indikasi Nama Server. Memungkinkan beberapa target HTTPS ditayangkan dari alamat IP dan port yang sama tanpa mewajibkan target tersebut menggunakan sertifikat yang sama.

Sertifikat TLS

File digital yang mengidentifikasi entitas dalam transaksi TLS. Sertifikat, atau cert, dapat digunakan untuk mengidentifikasi server TLS dan klien TLS, bergantung pada konfigurasi TLS.

Truststore

Berisi sertifikat tepercaya di klien TLS yang digunakan untuk memvalidasi sertifikat server TLS yang diberikan kepada klien. Sertifikat ini biasanya merupakan sertifikat yang ditandatangani sendiri atau sertifikat yang tidak ditandatangani oleh CA tepercaya.

Pada koneksi northbound, sertifikat aplikasi klien disimpan di truststore di Apigee Edge. Ini hanya diperlukan jika Anda telah mengonfigurasi TLS dua arah antara klien dan Apigee.

Pada koneksi southbound, sertifikat server backend disimpan di truststore di Apigee Edge. Hal ini diperlukan jika Anda ingin memverifikasi sertifikat backend di Apigee Edge dalam komunikasi TLS satu arah atau dua arah antara Apigee Edge dan server backend.

Apigee Edge tidak memiliki objek truststore terpisah. Oleh karena itu, truststore dibuat sebagai objek keystore, tetapi dirujuk sebagai truststore di mana pun digunakan (misalnya, di host virtual, endpoint target, server target, dll.).

Host virtual

Virtual host mewakili endpoint API Apigee untuk aplikasi klien. Entitas ini membantu dalam menghosting beberapa nama domain ( dengan penanganan terpisah untuk setiap nama) di satu server (atau kumpulan server). Hal ini memungkinkan satu server membagikan resource-nya, seperti memori dan siklus prosesor, tanpa mengharuskan semua layanan yang disediakan menggunakan nama host yang sama.

Host virtual dapat menayangkan traffic HTTP atau HTTPS (yang mendukung SSL).

Host virtual yang mendukung SSL dapat dikonfigurasi dalam mode TLS satu arah atau dua arah. Fitur ini dikonfigurasi dengan hal berikut:

  • Satu atau beberapa hostalias (nama DNS endpoint API).
  • Port
  • Keystore
  • Alias kunci untuk mengidentifikasi secara unik salah satu sertifikat server di keystore.
  • Secara opsional, truststore (dalam TLS dua arah, tempat autentikasi klien diaktifkan).

TLS/SSL satu arah

Gambar berikut menunjukkan handshake TLS/SSL untuk otentikasi satu arah antara klien TLS dan server TLS:

Dalam konfigurasi TLS satu arah, handshake-nya adalah sebagai berikut:

  • Klien mengirimkan permintaan sesi ke server.
  • Server merespons dengan sertifikat, yang berisi kunci publiknya. Sertifikat ini berasal dari keystore server, yang juga berisi kunci pribadi server. Kunci pribadi tidak pernah dikirim ke klien.
  • Untuk sertifikat yang ditandatangani, klien menggunakan truststore yang berisi sertifikat server dan kunci publik untuk memvalidasi bahwa rantai sertifikat ditandatangani oleh Certificate Authority (CA) tepercaya.
  • Klien dan server bertukar beberapa pesan lagi untuk memvalidasi kunci.
  • Klien memulai transfer data TLS dengan server.

Gambar berikut menunjukkan handshake TLS/SSL menggunakan truststore opsional di klien:

Jika server TLS menggunakan sertifikat yang ditandatangani sendiri atau sertifikat yang tidak ditandatangani oleh CA tepercaya, Anda harus membuat truststore di klien. Klien mengisi truststore-nya dengan sertifikat server dan kunci publik yang dipercayainya. Saat klien menerima sertifikat, sertifikat masuk kemudian divalidasi berdasarkan sertifikat di truststore-nya.

Dalam TLS satu arah, Edge dapat berupa server atau klien sebagai berikut:

  • Edge sebagai server TLS

    Edge adalah server yang menghosting endpoint TLS, dengan endpoint TLS sesuai dengan proxy API yang di-deploy ke host virtual. Klien adalah aplikasi yang mencoba mengakses proxy API. Dalam skenario ini, Edge memiliki keystore yang berisi sertifikat dan kunci pribadi.

  • Edge sebagai klien TLS

    Edge bertindak sebagai klien yang mengakses layanan backend. Dalam hal ini, layanan backend sesuai dengan server yang menghosting endpoint TLS. Oleh karena itu, server backend memiliki keystore yang berisi sertifikat dan kunci pribadinya.

TLS dua arah

Gambar berikut menunjukkan handshake TLS/SSL untuk autentikasi TLS dua arah antara klien dan server:

Pada TLS dua arah, handshake-nya adalah sebagai berikut:

  • Klien dan server memiliki keystore masing-masing. KeyStore klien berisi sertifikat dan kunci pribadinya, dan KeyStore server berisi sertifikat dan kunci pribadinya.
  • Server TLS memberikan sertifikatnya kepada klien TLS untuk mengautentikasi dirinya sendiri. Klien kemudian memverifikasi identitas server sebelum mengirimkan sertifikatnya ke server.
  • Klien TLS memberikan sertifikatnya ke server TLS untuk mengautentikasi dirinya ke server.

Gambar berikut menunjukkan handshake TLS menggunakan truststore opsional:

Dalam skenario ini, handshake-nya adalah sebagai berikut:

  • Jika server TLS menggunakan sertifikat yang ditandatangani sendiri atau sertifikat yang tidak ditandatangani oleh CA tepercaya, Anda harus membuat truststore di klien. Klien memiliki salinan sertifikat server di truststore-nya. Selama TLS handshake, klien membandingkan sertifikat di truststore-nya dengan sertifikat yang dikirim dari server untuk memverifikasi identitas server.
  • Jika klien TLS menggunakan sertifikat yang ditandatangani sendiri atau sertifikat yang tidak ditandatangani oleh CA tepercaya, Anda harus membuat truststore di server.Server memiliki salinan sertifikat klien di truststore-nya. Selama TLS handshake, server membandingkan sertifikat di truststore-nya dengan sertifikat yang dikirim dari klien untuk memverifikasi identitas klien.

Klien atau server atau keduanya dapat menggunakan truststore.

Dalam TLS dua arah, Edge dapat berupa server atau klien sebagai berikut:

  • Edge sebagai server

    Edge adalah server yang menghosting endpoint TLS, dengan endpoint TLS sesuai dengan proxy API. Klien adalah aplikasi yang mencoba mengakses proxy API. Dalam skenario ini, Edge memiliki keystore yang berisi sertifikat dan kunci pribadi, serta memerlukan truststore yang berisi sertifikat klien dan rantai CA.

  • Edge sebagai klien

    Edge bertindak sebagai klien yang mengakses layanan backend. Dalam hal ini, layanan backend sesuai dengan server yang menghosting endpoint TLS. Oleh karena itu, server backend memiliki keystore yang berisi sertifikat dan kunci pribadinya.

    Edge juga harus menentukan keystore yang berisi sertifikat yang diperlukan untuk memvalidasi dirinya sendiri ke layanan backend, dan secara opsional truststore yang berisi sertifikat dari server backend jika server menggunakan sertifikat yang ditandatangani sendiri atau sertifikat yang tidak ditandatangani oleh CA tepercaya.

Hal penting yang perlu diingat adalah Edge cukup fleksibel untuk mendukung TLS dua arah terlepas dari cara Anda mengonfigurasinya.

Dukungan SNI

Edge mendukung penggunaan Indikasi Nama Server (SNI) dari proxy API ke Edge, dengan Edge bertindak sebagai server TLS, dan dari Edge ke endpoint target, dengan Edge bertindak sebagai klien TLS, baik dalam penginstalan Cloud maupun Private Cloud.

Dengan SNI, yang merupakan ekstensi TLS/SSL, beberapa target HTTPS dapat ditayangkan dari alamat IP dan port yang sama tanpa mengharuskan target tersebut menggunakan sertifikat yang sama.

Untuk mengetahui informasi tentang cara mengaktifkan SNI untuk penginstalan di tempat, lihat Menggunakan SNI dengan Edge.

Menuju utara dan selatan

Di Apigee, northbound mengacu pada endpoint API yang digunakan oleh aplikasi klien untuk memanggil Proxy API. Biasanya, Router adalah titik entri di Apigee Edge dan menangani permintaan masuk ke Apigee Edge. Oleh karena itu, di Apigee, endpoint yang digunakan untuk komunikasi antara aplikasi klien dan Apigee Edge (Router) disebut sebagai northbound.

Di Apigee, southbound mengacu pada endpoint target yang digunakan Apigee untuk berkomunikasi dengan server backend. Oleh karena itu, di Apigee, endpoint yang digunakan untuk komunikasi antara Apigee Edge (Message Processor) dan server backend disebut sebagai southbound. Message Processor adalah komponen Apigee Edge yang memproksi permintaan API ke server target backend.

Gambar berikut mengilustrasikan koneksi utara dan selatan untuk Apigee Edge:

Alur utara dan selatan. Aplikasi klien ke Router bersifat utara. Kemudian ke Message Processor. Message Processor ke Backend Server bersifat southbound.