Opsi untuk mengonfigurasi TLS

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Lihat Dokumentasi Apigee Edge.

Bagian ini menunjukkan cara mengonfigurasi TLS untuk traffic dari proxy ke target.

Tentang Saya menetapkan opsi TLS di endpoint target atau server target

Target dapat direpresentasikan oleh objek XML seperti di bawah ini:

<HTTPTargetConnection>
    <Properties/>
    <URL>https:myTargetAddress</URL>
    <SSLInfo>
        <Enabled>true</Enabled>
        <Enforce>true</Enforce>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTruststoreRef</TrustStore>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <Protocols>myProtocols</Protocols>
        <Ciphers>myCipher</Ciphers>
    </SSLInfo>
</HTTPTargetConnection>

Area konfigurasi endpoint target yang Anda ubah untuk mengonfigurasi TLS ditentukan oleh Tag <SSLInfo>. Anda menggunakan tag <SSLInfo> yang sama untuk mengonfigurasi endpoint target atau server target.

Untuk mengetahui informasi tentang elemen turunan <SSLInfo>, lihat Konfigurasi TargetEndpoint TLS/SSL.

Tabel berikut menjelaskan elemen konfigurasi TLS yang digunakan oleh Tag <SSLInfo>:

Elemen	Deskripsi
<Enabled>	Blok <SSLInfo> dapat digunakan untuk TLS/SSL satu arah dan dua arah. Jika ditetapkan ke true, <Enabled> menentukan bahwa blok <SSLInfo> harus digunakan. Jika ditetapkan ke false, blok <SSLInfo> akan diabaikan. Nilai default <Enabled> adalah true jika <URL> menentukan protokol HTTPS, dan false jika <URL> menentukan HTTP.
<Enforce>	Menerapkan SSL ketat antara Apigee dan backend target. Jika disetel ke true, koneksi akan gagal untuk target dengan sertifikat tidak valid, sertifikat yang habis masa berlakunya, sertifikat yang ditandatangani sendiri, sertifikat dengan ketidakcocokan nama host, dan sertifikat dengan root yang tidak tepercaya. Kode 4xx gagal atau 5xx ditampilkan. Jika tidak disetel atau disetel ke false, hasil koneksi ke backend target dengan sertifikat yang bermasalah bergantung pada setelan <IgnoreValidationErrors> (lihat di bawah). Respons berhasil (2xx) dapat terjadi dalam kondisi tertentu, jika <IgnoreValidationErrors> disetel ke true.
<ClientAuthEnabled>	Mengaktifkan TLS dua arah (juga dikenal sebagai TLS atau mTLS bersama) antara Apigee dan API klien, atau antara Apigee dan backend target. Mengaktifkan TLS dua arah biasanya mengharuskan Anda menyiapkan truststore di Apigee dan truststore.
<KeyStore>	Keystore yang berisi kunci pribadi yang digunakan untuk autentikasi klien keluar
<KeyAlias>	Alias yang ditentukan saat Anda mengupload sertifikat dan kunci pribadi ke keystore.
<TrustStore>	Keystore yang berisi sertifikat server tepercaya.
<IgnoreValidationErrors>	Menunjukkan apakah error validasi diabaikan. Jika sistem backend menggunakan SNI dan menampilkan sertifikat dengan Nama yang Dibedakan (DN) subjek yang tidak cocok dengan nama host, tidak ada cara untuk mengabaikan {i>error<i} dan koneksi gagal. Catatan: Jika <Enforce> disetel ke true, nilai <IgnoreValidationErrors> diabaikan.
<Ciphers>	Cipher yang didukung untuk TLS/SSL keluar. Jika tidak ada penyandian yang ditentukan, maka semua penyandian yang tersedia untuk JVM akan diizinkan. Untuk membatasi cipher, tambahkan elemen berikut yang mencantumkan cipher yang didukung: <Ciphers> <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher> <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher> </Ciphers>
<Protocols>	Protokol yang didukung untuk TLS/SSL keluar. Jika tidak ada protokol yang ditentukan, maka semua protokol yang tersedia untuk JVM akan diizinkan. Untuk membatasi protokol, tentukan secara eksplisit. Misalnya, untuk hanya mengizinkan TLS v1.2 atau TLS v1.3: <Protocols> <Protocol>TLSv1.2</Protocol> <Protocol>TLSv1.3</Protocol> </Protocols>

Tentang setelan &lt;KeyStore&gt; dan <TrustStore> elemen

Pada contoh di atas, keystore dan truststore ditentukan dengan menggunakan referensi, dalam bentuk:

<KeyStore>ref://myKeystoreRef</KeyStore>
<TrustStore>ref://myTruststoreRef</TrustStore>

Apigee sangat menyarankan agar Anda selalu menggunakan referensi ke keystore dan truststore. J adalah variabel yang berisi nama keystore atau truststore, bukan yang menentukan nama keystore secara langsung. Dalam contoh ini:

• myKeystoreRef adalah referensi yang berisi nama keystore. Dalam contoh ini, nama keystore adalah myKeystore.
• myTruststoreRef adalah referensi yang berisi nama truststore. Dalam contoh ini, nama truststore adalah myTruststore.

Saat masa berlaku sertifikat habis, Anda harus mengupdate server target/endpoint target untuk menentukan keystore atau truststore yang berisi sertifikat baru. Keuntungan dari referensi adalah bahwa Anda bisa memodifikasi nilai referensi untuk mengubah keystore atau truststore tanpa harus ubah server endpoint/target target itu sendiri:

Mengubah nilai referensi tidak mengharuskan Anda menghubungi Google Cloud Customer Care.

Atau, Anda dapat menentukan nama keystore dan nama truststore secara langsung:

<KeyStore>myKeystore</KeyStore>
<TrustStore>myTruststore</TrustStore> 

Jika Anda secara langsung menentukan nama keystore atau truststore, maka Anda harus hubungi Google Cloud Customer Care.

Opsi ketiga adalah menggunakan variabel alur:

<KeyStore>{ssl.keystore}</KeyStore>
<TrustStore>{ssl.truststore}</TrustStore> 

Dengan cara kerja variabel alur, Anda dapat mengupdate keystore atau {i>truststore<i} seperti referensi. Untuk informasi selengkapnya, lihat Menggunakan variabel alur untuk menetapkan nilai TLS/SSL secara dinamis.

Tentang mengonfigurasi TLS

Semua pelanggan Apigee, baik yang berbayar maupun evaluasi, memiliki kontrol penuh atas konfigurasi endpoint target/server target. Selain itu, pelanggan Apigee berbayar memiliki kendali penuh atas Properti TLS.

Menangani sertifikat yang sudah tidak berlaku

Jika masa berlaku sertifikat TLS habis, atau jika konfigurasi sistem Anda berubah sehingga sertifikat tidak lagi valid, maka Anda perlu memperbarui sertifikat. Saat mengonfigurasi TLS untuk endpoint/server target target, sebaiknya tentukan performa pembaruan itu sebelum Anda melakukan konfigurasi apa pun.

Catatan: Anda tidak dapat memperbarui keystore atau truststore yang ada untuk menambahkan sertifikat baru. Anda harus membuat keystore/truststore baru saat memperbarui sertifikat. Biasanya, Anda membuat keystore/truststore baru dan mengupload sertifikat baru sebelum sertifikat di masa berlaku keystore/truststore lama habis. Hal ini memungkinkan Anda menguji keystore/truststore baru dan melakukan rollback ke keystore/truststore lama jika ada masalah.

Saat masa berlaku sertifikat habis

Di Apigee, Anda menyimpan sertifikat di salah satu dari dua tempat:

• Keystore - Berisi sertifikat TLS dan kunci pribadi yang digunakan untuk mengidentifikasi entitas selama handshake TLS.
• Truststore - Berisi sertifikat tepercaya di klien TLS yang digunakan untuk memvalidasi sertifikat server TLS yang diberikan ke klien. Sertifikat ini biasanya sertifikat yang ditandatangani sendiri, sertifikat yang ditandatangani oleh CA tepercaya, atau sertifikat yang digunakan sebagai bagian dari sertifikat dua arah TLS (juga dikenal sebagai TLS atau mTLS bersama).

Jika suatu sertifikat di keystore sudah tidak berlaku, dan Anda menggunakan referensi ke keystore, Anda tidak dapat mengupload sertifikat baru ke keystore. Sebagai gantinya, Anda:

1. Buat keystore baru.
2. Upload sertifikat baru ke keystore baru menggunakan nama alias yang sama seperti di keystore lama.
3. Perbarui referensi di endpoint target/server target untuk menggunakan keystore baru.

Jika masa berlaku sertifikat di truststore sudah tidak berlaku, dan Anda menggunakan referensi ke truststore, Anda:

1. Buat truststore baru.
2. Upload sertifikat baru ke truststore baru. Nama alias tidak penting untuk truststore. Catatan: Jika sertifikat adalah bagian dari rantai, Anda harus membuat satu file yang berisi semua sertifikat dan unggah file tersebut ke satu alias, atau unggah semua sertifikat di rantai secara terpisah ke truststore menggunakan alias yang berbeda untuk setiap sertifikat.
3. Perbarui referensi di server target/endpoint target untuk menggunakan truststore.

Ringkasan metode untuk memperbarui data yang sudah tidak berlaku sertifikat

Metode yang Anda gunakan untuk menentukan nama keystore dan truststore di endpoint target/server target menentukan cara Anda melakukan update sertifikat. Anda dapat menggunakan:

• Referensi
• Nama langsung
• Variabel flow

Masing-masing metode ini memiliki dampak yang berbeda terhadap proses pembaruan, seperti yang dijelaskan dalam tabel berikut:

Jenis konfigurasi	Cara memperbarui/mengganti sertifikat	Penggunaan
Referensi (Direkomendasikan)	Untuk keystore, buat keystore baru dengan nama baru dan alias dengan nama yang sama dengan alias lama. Untuk truststore, buat truststore dengan nama baru.	Perbarui referensi ke keystore atau truststore. Tidak perlu menghubungi Dukungan Apigee.
Variabel aliran	Untuk keystore, buat keystore baru dengan nama baru dan alias dengan nama yang sama atau dengan nama baru. Untuk truststore, buat truststore dengan nama baru.	Teruskan variabel alur yang telah diupdate pada setiap permintaan dengan nama keystore, alias, atau keystore baru truststore. Tidak perlu menghubungi Dukungan Apigee.
Langsung	Membuat keystore, alias, dan truststore baru.	Deploy ulang proxy.
Langsung	Hapus keystore atau truststore dan buat ulang dengan nama yang sama.	Permintaan API akan gagal hingga keystore dan alias baru ditetapkan. Jika keystore digunakan untuk TLS dua arah (juga dikenal sebagai TLS atau mTLS bersama) antara Apigee dan layanan backend, hubungi Google Cloud Customer Care untuk memulai ulang Pemroses Pesan.
Langsung	Khusus untuk truststore, upload sertifikat baru ke truststore.	Hubungi Google Cloud Customer Care untuk memulai ulang Pemroses Pesan.