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

Edge mendukung TLS satu arah dan TLS dua arah di cloud dan deployment lokal (untuk versi TLS yang didukung, lihat Software yang didukung dan versi yang didukung). TLS satu arah memungkinkan klien TLS untuk 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 secara menyeluruh dan melindungi data Anda dari serangan klien seperti spoofing klien atau serangan man-in-the-middle. Pada 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:

Masa Berlaku

Definisi

Kanada

{i>Certificate Authority<i}. Entitas tepercaya, seperti Symantec atau VeriSign, 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 menengah yang membentuk rantai. Sertifikat perantara terakhir dalam rantai tersebut biasanya ditandatangani oleh kunci pribadi root CA.

CSR

Permintaan Penandatanganan Sertifikat. CSR adalah file yang dihasilkan di server TLS berdasarkan kunci pribadi. CSR berisi kunci publik dan informasi lainnya seperti nama organisasi, lokasi, dan nama domain. CA menandatangani CSR untuk membuat sertifikat TLS. Anda biasanya membuat CSR saat sertifikat habis masa berlakunya dan ingin memperpanjangnya.

DER

Aturan Encoding yang Dibedakan. Format DER adalah bentuk biner sertifikat, bukan format ASCII PEM. Terkadang ekstensi tersebut memiliki ekstensi file .der tetapi sering kali memiliki ekstensi file .cer. Satu-satunya cara untuk membedakan antara file DER .cer dan file PEM .cer adalah dengan membuka file dalam 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 secara unik mengidentifikasi entri keystore (sertifikat TLS dan kunci pribadi yang terkait) 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 dalam keystore di Apigee Edge.

Pada koneksi southbound, Pemroses Pesan bertindak sebagai klien, dan server backend bertindak sebagai server. Sertifikat klien dan kunci pribadinya disimpan dalam 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 biner yang Distinguished Encoding Rules (DER). Sertifikat PEM dapat dibuka di Editor Teks dan konten sertifikat sebenarnya dibatasi di antara pernyataan -----BEGIN CERTIFICATE----- dan -----END CERTIFICATE-----.

Kunci ini sesuai dengan format X.509 untuk menyimpan sertifikat, rantai sertifikat, atau kunci pribadi. Jika sertifikat atau kunci pribadi 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, semua 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 serta kunci pribadi.

Kunci pribadi

Digunakan di server TLS untuk mendekripsi data. Hanya server TLS yang memiliki kunci pribadi—kunci tersebut tidak dibagikan dengan 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 level 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 melayani 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 adalah identik, yang ditandatangani dengan kunci pribadi yang cocok dengan kunci publik yang ada di dalamnya.

SNI

Indikasi Nama Server. Memungkinkan beberapa target HTTPS disalurkan 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 pada klien TLS yang digunakan untuk memvalidasi sertifikat server TLS yang diberikan kepada klien. Sertifikat ini biasanya berupa sertifikat yang ditandatangani sendiri atau sertifikat yang tidak ditandatangani oleh CA tepercaya.

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

Pada koneksi southbound, sertifikat server backend disimpan dalam truststore di Apigee Edge. Hal ini diperlukan jika Anda ingin memverifikasi sertifikat backend di Apigee Edge melalui 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 merepresentasikan endpoint Apigee API untuk aplikasi klien. Ini adalah entitas yang membantu menghosting beberapa nama domain (dengan penanganan terpisah untuk setiap nama) pada satu server (atau kumpulan server). Hal ini memungkinkan satu server untuk berbagi resource-nya, seperti siklus memori dan prosesor, tanpa mengharuskan semua layanan yang disediakan untuk menggunakan nama host yang sama.

Host virtual dapat menyalurkan traffic HTTP atau HTTPS (berkemampuan SSL).

Host virtual dengan SSL diaktifkan dapat dikonfigurasi dalam mode TLS satu arah atau dua arah. Konfigurasi ini dikonfigurasi dengan kode 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 (di TLS dua arah, dengan 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 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 tersebut ditandatangani oleh Certificate Authority (CA) tepercaya.
  • Klien dan server bertukar beberapa pesan untuk memvalidasi kunci.
  • Klien memulai transfer data TLS dengan server.

Gambar berikut menunjukkan handshake TLS/SSL menggunakan truststore opsional pada 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 dipercaya. Saat klien menerima sertifikat, sertifikat yang masuk kemudian divalidasi dengan sertifikat di truststore-nya.

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

  • Edge sebagai server TLS

    Edge adalah server yang menghosting endpoint TLS, tempat 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 adalah sebagai berikut:

  • Klien dan server memiliki keystore sendiri. Keystore klien berisi sertifikat dan kunci pribadinya, sedangkan keystore server berisi sertifikat dan kunci pribadinya.
  • Server TLS menyajikan sertifikatnya ke klien TLS untuk mengautentikasi dirinya sendiri. Selanjutnya, klien akan memverifikasi identitas server sebelum mengirim sertifikatnya ke server.
  • Klien TLS menyajikan sertifikatnya ke server TLS untuk mengautentikasi dirinya sendiri ke server.

Gambar berikut menunjukkan handshake TLS menggunakan truststore opsional:

Dalam skenario ini, handshake adalah sebagai berikut:

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

Klien atau server atau keduanya dapat menggunakan {i>truststore<i}.

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

  • Edge sebagai server

    Edge adalah server yang menghosting endpoint TLS, dengan endpoint TLS terkait 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 dan rantai CA klien.

  • 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.

Yang penting untuk diingat adalah Edge cukup fleksibel untuk mendukung TLS dua arah, terlepas dari cara Anda memutuskan untuk mengonfigurasinya.

Dukungan SNI

Edge mendukung penggunaan Server Name Indication (SNI) dari proxy API ke Edge, dengan Edge berfungsi sebagai server TLS, dan dari Edge ke endpoint target, dengan Edge bertindak sebagai klien TLS, dalam penginstalan Cloud dan Private Cloud.

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

Untuk mengetahui informasi tentang cara mengaktifkan SNI untuk pemasangan di lokasi, lihat Menggunakan SNI dengan Edge.

Ke arah utara dan selatan

Di Apigee, arah utara mengacu pada endpoint API yang digunakan oleh aplikasi klien untuk memanggil Proxy API. Biasanya, Router adalah titik entri di Apigee Edge dan menangani permintaan yang 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, arah selatan 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. Pemroses Pesan adalah komponen Apigee Edge yang melakukan proxy permintaan API ke server target backend.

Gambar berikut mengilustrasikan koneksi ke arah utara dan selatan untuk Apigee Edge:

Aliran ke arah utara dan selatan. Aplikasi klien ke {i>Router<i} berada di arah utara. Kemudian ke Pemroses Pesan. Pemroses Pesan ke Server Backend menuju ke selatan.