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 server dan klien tetap bersifat pribadi. Untuk menggunakan TLS, klien membuat permintaan aman ke server menggunakan protokol HTTPS terenkripsi, bukan protokol HTTP yang tidak dienkripsi.

Edge mendukung TLS satu arah dan TLS dua arah dalam deployment cloud dan on-premise (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 Edge API (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, diikuti dengan server yang 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 autentisitas sertifikat. Satu jenis sertifikat, yang disebut sertifikat ditandatangani sendiri, tidak memerlukan CA.

Rantai sertifikat

Sering kali Anda tidak akan memiliki sertifikat yang ditandatangani oleh kunci pribadi root CA. 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. Anda biasanya membuat CSR saat memiliki sertifikat yang sudah tidak berlaku dan ingin memperpanjangnya.

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 denkode 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 rantai sertifikat, 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 mana pun dan konten sertifikat yang sebenarnya dibatasi antara pernyataan -----BEGIN CERTIFICATE----- dan -----END CERTIFICATE-----.

Format ini mematuhi format X.509 untuk menyimpan sertifikat, rantai sertifikat, atau kunci pribadi. Jika sertifikat atau kunci pribadi tidak ditentukan oleh file PEM, Anda dapat mengonversinya ke 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 ini 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 memberikan tingkat indirection untuk keystore; oleh karena itu, perubahan keystore tidak memerlukan pembaruan host virtual selama referensi dan alias kunci yang sama dipertahankan. Hal ini memungkinkan Anda melakukan perubahan ini secara mandiri 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

Server Name Indication. Memungkinkan beberapa target HTTPS ditayangkan dari alamat IP dan port yang sama tanpa mengharuskan 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 ditampilkan 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. Hal ini hanya diperlukan jika Anda telah mengonfigurasi TLS dua arah antara klien dan Apigee.

Pada koneksi ke selatan, 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 direferensikan sebagai truststore di mana pun digunakan (misalnya, di host virtual, endpoint target, server target, dll.).

Host virtual

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

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

Host virtual yang mengaktifkan SSL dapat dikonfigurasi dalam mode TLS satu arah atau dua arah. Konfigurasinya menggunakan hal berikut:

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

TLS/SSL satu arah

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

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

  • Klien mengeluarkan 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 yang masuk kemudian divalidasi dengan sertifikat di truststore-nya.

Dalam TLS satu arah, Edge dapat menjadi 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:

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

  • Klien dan server memiliki keystore sendiri. Keystore klien berisi sertifikat dan kunci pribadinya, dan keystore server berisi sertifikat dan kunci pribadinya.
  • Server TLS menampilkan sertifikatnya kepada klien TLS untuk mengautentikasi dirinya sendiri. Klien kemudian memverifikasi identitas server sebelum mengirim sertifikatnya ke server.
  • Klien TLS menampilkan 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 dalam 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 menjadi server atau klien sebagai berikut:

  • Edge sebagai server

    Edge adalah server yang menghosting endpoint TLS, dengan endpoint TLS yang 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 Server Name Indication (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 Cloud Pribadi.

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 informasi tentang cara mengaktifkan SNI untuk penginstalan di tempat, lihat Menggunakan SNI dengan Edge.

Arah 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 (Pemroses Pesan) dan server backend disebut sebagai southbound. Message Processor adalah komponen Apigee Edge yang melakukan proxy permintaan API ke server target backend.

Gambar berikut mengilustrasikan koneksi northbound dan southbound untuk Apigee Edge:

Arus menuju utara dan selatan. Aplikasi klien ke Router adalah northbound. Kemudian, ke Pemroses Pesan. Message Processor ke Server Backend adalah southbound.