SSL/TLS adalah protokol kriptografi yang paling banyak digunakan di internet. Secara teknis, TLS adalah penerus SSL, meskipun istilah tersebut terkadang digunakan secara bergantian, seperti dalam dokumen ini.
Transport Layer Security (TLS) digunakan untuk mengenkripsi informasi saat dikirim melalui jaringan, sehingga memberikan privasi antara klien dan server atau load balancer. Load Balancer Aplikasi atau Load Balancer Jaringan proxy yang menggunakan SSL memerlukan setidaknya satu kunci pribadi dan sertifikat SSL.
Halaman ini membahas sertifikat SSL dan enkripsi dalam pengiriman antara Load Balancer Aplikasi atau Load Balancer Jaringan proxy yang menggunakan SSL dan kliennya. Untuk mengetahui detail tentang enkripsi dalam pengiriman antara load balancer Google Cloud dan backend-nya, lihat Enkripsi ke backend.
Metode konfigurasi sertifikat
Google Cloud menawarkan tiga metode konfigurasi sertifikat untuk Load Balancer Aplikasi yang menggunakan proxy HTTPS target dan Load Balancer Jaringan proxy yang menggunakan proxy SSL target.
Proxy target mereferensikan sertifikat SSL Compute Engine: dengan metode ini, proxy target load balancer dapat mereferensikan hingga 15 resource sertifikat SSL Compute Engine. Setiap resource sertifikat SSL Compute Engine berisi kunci pribadi, sertifikat yang sesuai, dan—opsional—sertifikat CA.
Proxy target mereferensikan peta sertifikat Certificate Manager: dengan metode ini, proxy target load balancer mereferensikan satu peta sertifikat. Peta sertifikat mendukung ribuan entri secara default, dan dapat diskalakan hingga jutaan entri. Setiap entri berisi data kunci pribadi dan sertifikat.
Proxy target mereferensikan sertifikat Certificate Manager secara langsung: dengan metode ini, proxy target load balancer dapat mereferensikan hingga 100 sertifikat Certificate Manager.
Dukungan load balancer
Tabel berikut menunjukkan metode konfigurasi sertifikat yang didukung oleh setiap load balancer.
| Load balancer | Metode konfigurasi sertifikat | |||
|---|---|---|---|---|
| Sertifikat SSL Compute Engine | Certificate Manager (peta sertifikat) | Certificate Manager (sertifikat individual) | ||
| Load Balancer Aplikasi (proxy HTTPS target) | ||||
| Load Balancer Aplikasi eksternal global |
Dikelola sendiri Dikelola Google |
Dikelola sendiri Dikelola Google |
||
| Load Balancer Aplikasi klasik |
Dikelola sendiri Dikelola Google |
Dikelola sendiri Dikelola Google |
||
| Load Balancer Aplikasi eksternal regional |
Dikelola sendiri Dikelola Google |
Dikelola sendiri Dikelola Google |
||
| Load Balancer Aplikasi internal regional |
Dikelola sendiri Dikelola Google |
Dikelola sendiri Dikelola Google |
||
| Load Balancer Aplikasi internal lintas region |
Dikelola sendiri Dikelola Google |
|||
| Load Balancer Jaringan Proxy (proxy SSL target) | ||||
| Load Balancer Jaringan proxy eksternal global |
Dikelola sendiri Dikelola Google |
Dikelola sendiri Dikelola Google |
||
| Load Balancer Jaringan proxy klasik |
Dikelola sendiri Dikelola Google |
Dikelola sendiri Dikelola Google |
||
Aturan metode konfigurasi
Google Cloud menerapkan aturan metode konfigurasi sertifikat berikut:
Untuk load balancer yang mendukung sertifikat SSL Compute Engine dan peta sertifikat Certificate Manager: proxy target load balancer dapat secara bersamaan mereferensikan peta sertifikat dan satu atau beberapa sertifikat SSL Compute Engine.
Untuk load balancer yang mendukung sertifikat SSL Compute Engine dan sertifikat Certificate Manager yang terpasang langsung: proxy target load balancer hanya dapat dikonfigurasi untuk mereferensikan hingga 15 sertifikat SSL Compute Engine atau hingga 100 sertifikat Certificate Manager, bukan kombinasi keduanya.
Jenis sertifikat
Google Cloud mendukung sertifikat yang dikelola sendiri dan dikelola Google.
Sertifikat SSL yang dikelola sendiri
Sertifikat SSL yang dikelola sendiri adalah sertifikat yang Anda peroleh, sediakan, dan perpanjang sendiri. Sertifikat yang dikelola sendiri dapat berupa salah satu dari jenis Public key certificate berikut:
- Validasi Domain (DV)
- Validasi Organisasi (OV)
- Sertifikat Extended Validation (EV)
Anda dapat membuat sertifikat SSL yang dikelola sendiri menggunakan:
Resource sertifikat SSL Compute Engine: untuk mengetahui informasi selengkapnya, lihat Menggunakan sertifikat SSL yang dikelola sendiri.
Certificate Manager: untuk mengetahui informasi selengkapnya, lihat Ringkasan deployment dalam dokumentasi Certificate Manager.
Sertifikat SSL yang dikelola Google
Sertifikat SSL yang dikelola Google adalah sertifikat yang Google Cloud diperoleh, dikelola, dan diperpanjang secara otomatis. Sertifikat yang dikelola Google selalu berupa sertifikat Domain Validation (DV). Sertifikat ini tidak menunjukkan identitas organisasi atau individu yang terkait dengan sertifikat tersebut.
Sertifikat yang dikelola Google menggunakan karakter pengganti hanya didukung oleh Certificate Manager saat menggunakan otorisasi DNS.
Anda dapat membuat sertifikat SSL yang dikelola Google menggunakan:
- Resource sertifikat SSL Compute Engine: hanya resource
sslCertificatesCompute Engine global yang mendukung sertifikat SSL yang dikelola Google;regionSslCertificatestidak mendukungnya. Sertifikat SSL Compute Engine global hanya mendukung sertifikat yang dikelola Google dan dipercaya secara publik. Untuk mengetahui informasi selengkapnya, baca bagian Menggunakan sertifikat SSL yang dikelola Google. - Certificate Manager: Sertifikat Certificate Manager (global dan regional) mendukung sertifikat yang dikelola Google yang dipercaya secara publik dan sertifikat yang dikelola Google yang dipercaya secara pribadi. Untuk mengetahui informasi selengkapnya, lihat Sertifikat dalam dokumentasi Certificate Manager.
Jenis kunci yang didukung
Load balancer mendukung sertifikat yang menggunakan kunci pribadi dari berbagai jenis kunci. Tabel berikut menunjukkan dukungan jenis kunci, bergantung pada apakah sertifikat bersifat global atau regional, dan apakah sertifikat dikelola sendiri atau dikelola Google.|
Jenis sertifikat SSL arrow_forward Jenis kunci arrow_downward |
Sertifikat SSL Compute Engine | Sertifikat SSL Certificate Manager | ||||
|---|---|---|---|---|---|---|
| Global | Regional | Global dan regional | ||||
| Kelola sendiri | Dikelola Google dan dipercaya secara publik | Kelola sendiri | Kelola sendiri | Dikelola Google dan dipercaya secara publik | Dikelola Google dan dipercaya secara pribadi | |
| RSA-2048 | ||||||
| RSA-3072 | ||||||
| RSA-4096 | ||||||
| ECDSA P-256 | ||||||
| ECDSA P-384 | ||||||
Menggunakan sertifikat dengan kunci ECDSA
Bagian ini membahas alasan kami merekomendasikan ECDSA daripada RSA sebagai praktik terbaik untuk kunci penandatanganan sertifikat.
Jenis kunci yang akan digunakan
ECDSA P-256 adalah pilihan jenis kunci yang direkomendasikan untuk sebagian besar sertifikat TLS, yang menawarkan keamanan kriptografis yang kuat serta performa yang sangat baik untuk operasi penandatanganan dan penggunaan bandwidth jaringan yang efisien.
Beberapa kemungkinan alasan untuk menggunakan jenis kunci sertifikat lainnya adalah sebagai berikut:
- Jika Anda perlu mendukung klien lama yang tidak mendukung sertifikat ECDSA, Anda dapat memberikan sertifikat RSA-2048 selain sertifikat ECDSA P-256.
- Jika Anda memiliki persyaratan kepatuhan khusus yang mengharuskan Anda menggunakan ukuran kunci yang lebih besar atau jenis kunci tertentu, kunci ECDSA P-384, RSA-2048, RSA-3072, dan RSA-4096 dapat digunakan.
Alasan memilih ECDSA daripada RSA
Keunggulan utama ECDSA terletak pada kemampuannya untuk memberikan tingkat keamanan kriptografis yang setara dengan kunci yang jauh lebih kecil dibandingkan dengan RSA. Efisiensi ini menghasilkan manfaat performa dan resource yang nyata. Kunci yang lebih kecil tidak berarti keamanan yang lebih lemah—ECDSA didasarkan pada masalah logaritma diskret kurva elips, yang memberikan keamanan yang lebih kuat per unit kunci, dan dalam beberapa kasus, efisiensi komputasi yang lebih baik dibandingkan dengan RSA.
Contoh:
- Kunci ECDSA 256-bit memberikan tingkat keamanan yang serupa dengan kunci RSA-3072.
- Kunci ECDSA 384 bit memberikan tingkat keamanan yang lebih tinggi daripada ukuran kunci RSA yang didukung secara luas.
Manfaat utama ECDSA:
Performa: Operasi penandatanganan ECDSA jauh lebih ringan secara komputasi dibandingkan operasi RSA yang memberikan tingkat keamanan yang setara. Hal ini mengurangi beban CPU dan latensi, yang sangat penting untuk sistem dengan throughput tinggi atau sensitif terhadap latensi.
Efisiensi: kunci dan tanda tangan yang lebih kecil memerlukan lebih sedikit bandwidth dan penyimpanan, yang sangat bermanfaat untuk lingkungan dengan resource terbatas seperti perangkat seluler dan IoT.
Beberapa sertifikat SSL
Load Balancer Aplikasi atau Load Balancer Jaringan proxy dapat menghosting dua atau beberapa sertifikat SSL secara bersamaan saat proxy targetnya dikonfigurasi menggunakan metode konfigurasi sertifikat yang didukung. Sebagai praktik terbaik, gunakan Certificate Manager saat beberapa sertifikat SSL diperlukan.
Untuk load balancer yang mendukung sertifikat SSL Compute Engine: proxy target load balancer dapat merujuk hingga 15 sertifikat SSL Compute Engine. Resource sertifikat SSL Compute Engine pertama yang direferensikan adalah sertifikat default (utama) untuk proxy target.
Untuk load balancer yang mendukung peta sertifikat Certificate Manager: proxy target load balancer mereferensikan satu peta sertifikat. Peta sertifikat mendukung ribuan entri peta sertifikat. Anda dapat mengonfigurasi entri sertifikat mana yang merupakan sertifikat default (utama) untuk peta sertifikat.
Untuk load balancer yang mendukung referensi langsung sertifikat Certificate Manager: proxy target load balancer dapat mereferensikan hingga 100 sertifikat Certificate Manager. Resource sertifikat SSL Certificate Manager pertama yang direferensikan adalah sertifikat default (utama) untuk proxy target.
Untuk informasi selengkapnya, lihat:
Proxy target dan sertifikat SSL dalam dokumentasi load balancing.
Kuota dan batas resource dalam dokumentasi Certificate Manager.
Proses pemilihan sertifikat
Proses pemilihan sertifikat berikut berlaku untuk load balancer yang proxy targetnya merujuk ke beberapa sertifikat SSL Compute Engine atau beberapa sertifikat Certificate Manager.
Proses pemilihan sertifikat akan berbeda jika proxy target load balancer merujuk ke peta sertifikat Certificate Manager. Untuk mengetahui detail tentang proses pemilihan sertifikat dari peta sertifikat, lihat Logika pemilihan sertifikat dalam dokumentasi Certificate Manager.
Setelah klien terhubung ke load balancer, klien dan load balancer
menegosiasikan sesi TLS. Selama negosiasi sesi TLS, klien mengirimkan daftar cipher TLS yang didukungnya (dalam ClientHello) ke load balancer. Load balancer memilih sertifikat yang algoritma kunci publiknya kompatibel dengan klien. Klien juga dapat mengirim nama host server name indication (SNI) ke load balancer sebagai bagian dari negosiasi ini. Data nama host SNI terkadang digunakan
untuk membantu load balancer memilih sertifikat yang harus dikirim ke klien.
Jika proxy target load balancer hanya mereferensikan satu sertifikat, sertifikat tersebut akan digunakan, dan nilai nama host SNI yang dikirim oleh klien tidak relevan.
Jika proxy target load balancer mereferensikan dua sertifikat atau lebih, load balancer akan menggunakan proses berikut untuk memilih satu sertifikat:
Jika klien tidak mengirim nama host SNI dalam
ClientHello-nya, load balancer akan menggunakan sertifikat pertama dalam daftar sertifikatnya.Jika klien mengirimkan nama host SNI yang tidak cocok dengan nama umum (CN) sertifikat mana pun dan tidak cocok dengan nama alternatif subjek (SAN) sertifikat mana pun, load balancer akan menggunakan sertifikat pertama dalam daftar sertifikatnya.
Dalam semua situasi lainnya, load balancer memilih sertifikat menggunakan proses pencocokan berikut:
Pencocokan dilakukan terhadap atribut sertifikat nama umum (CN) dan nama alternatif subjek (SAN). Jika hanya satu sertifikat yang cocok dengan nama host SNI, load balancer akan memilih sertifikat tersebut. Jika beberapa sertifikat cocok dengan nama host SNI, load balancer akan memprioritaskannya dalam urutan berikut:
Pencocokan nama host persis: pencocokan persis dengan CN atau SAN lebih diprioritaskan daripada pencocokan karakter pengganti.
Kecocokan nama host karakter pengganti: jika tidak ada kecocokan persis, load balancer akan memeriksa kecocokan CN atau SAN karakter pengganti. Karakter pengganti (
*) hanya cocok dengan subdomain tingkat pertama (misalnya,*.pets.example.comcocok dengancats.pets.example.com, bukan*.example.com).Jenis kunci sertifikat: Sertifikat ECDSA lebih disukai daripada sertifikat RSA.
Ukuran rantai sertifikat: jika beberapa sertifikat memiliki kekhususan kecocokan dan algoritma kunci publik yang sama, load balancer akan memprioritaskan sertifikat dengan ukuran rantai sertifikat yang lebih kecil (dalam byte) untuk meminimalkan bandwidth jaringan selama TLS handshake.
Untuk mengilustrasikan metode pencocokan, pertimbangkan proxy target yang mereferensikan dua sertifikat berikut:
Sertifikat A
- CN:
cats.pets.example.com - SAN:
cats.pets.example.com,*.pets.example.com,*.example.com
- CN:
Sertifikat B
- CN:
dogs.pets.example.com - SAN:
dogs.pets.example.com,*.pets.example.com,*.example.com
- CN:
Sekarang, pertimbangkan skenario berikut:
Jika nama host SNI yang dikirim oleh klien adalah
cats.pets.example.com, load balancer akan menggunakan Sertifikat A.Jika nama host SNI yang dikirim oleh klien adalah
ferrets.pets.example.com, tidak ada kecocokan persis, dan Sertifikat A serta Sertifikat B cocok dengan*.pets.example.comdalam daftar SAN-nya. Jika kedua sertifikat menggunakan algoritma kunci publik yang sama, load balancer akan memilih sertifikat dengan ukuran rantai sertifikat yang lebih kecil. Jika ukuran rantai sertifikat juga identik, load balancer akan memilih antara Sertifikat A atau Sertifikat B, dan Anda tidak dapat mengontrol sertifikat mana yang dipilih.
Setelah sertifikat dipilih, load balancer akan mengirimkan sertifikat tersebut kepada klien hanya jika sertifikat yang dipilih menggunakan algoritma kunci publik yang kompatibel dengan cipher yang dikirim oleh klien di
ClientHello. Negosiasi TLS akan gagal jika klien tidak mendukung cipher suite yang menyertakan algoritma kunci publik (ECDSA atau RSA) dari sertifikat yang dipilih load balancer.
Harga
Untuk mengetahui harga sertifikat SSL Compute Engine dan harga Cloud Load Balancing, lihat Harga jaringan: Cloud Load Balancing.
Untuk mengetahui harga Certificate Manager, lihat halaman harga Certificate Manager.
Langkah berikutnya
Coba sendiri
Jika Anda baru menggunakan Google Cloud, buat akun untuk mengevaluasi performa produk kami dalam skenario dunia nyata. Pelanggan baru juga akan mendapatkan kredit gratis senilai $300 untuk menjalankan, menguji, dan men-deploy workload.
Mulai secara gratis