Traffic terenkripsi Transport Layer Security (TLS) mencakup sebagian besar traffic web. Karena pelaku ancaman sering menggunakan saluran terenkripsi ini untuk menyembunyikan aktivitas berbahaya, penting untuk memeriksa traffic ini sebelum mencapai tujuannya.
Secure Web Proxy menyediakan layanan pemeriksaan TLS terintegrasi yang memungkinkan Anda mencegat dan mendekripsi traffic HTTPS. Dengan mendapatkan visibilitas ke dalam permintaan terenkripsi, Secure Web Proxy dapat menerapkan kebijakan keamanan lanjutan—seperti pemfilteran URL pada jalur permintaan lengkap dan pemeriksaan header HTTP—untuk melindungi lingkungan Anda dari ancaman yang tersembunyi dalam tunnel terenkripsi.
Cara kerjanya
Pemeriksaan TLS berfungsi dengan membuat dua koneksi terenkripsi terpisah, dengan Secure Web Proxy yang bertindak sebagai perantara yang aman.
Handshake klien: saat klien mencoba terhubung ke situs eksternal, seperti
www.example.com, Secure Web Proxy akan menangkap permintaan tersebut.Pembuatan sertifikat: Secure Web Proxy membuat sertifikat sementara untuk
www.example.comsecara real time. Bergantung pada mode penerbitan sertifikat yang dikonfigurasi, proxy akan meminta sertifikat entitas akhir langsung dari CA Service untuk setiap domain atau menandatanganinya secara lokal menggunakan sertifikat CA perantara yang di-cache dari kumpulan CA.Validasi kepercayaan: klien kemudian menerima sertifikat sementara tersebut.
Titik pemeriksaan: traffic didekripsi dalam instance Secure Web Proxy. Pada tahap ini, kebijakan keamanan diterapkan ke data HTTP teks biasa.
Handshake server: Secure Web Proxy kemudian memulai koneksi TLS kedua ke server tujuan yang sebenarnya. Traffic dienkripsi ulang dan dikirim ke alamat tujuan.
Fitur utama
Layanan pemeriksaan TLS Secure Web Proxy menawarkan framework yang fleksibel dan skalabel untuk mengelola traffic terenkripsi melalui kemampuan berikut:
Kepercayaan pribadi terintegrasi: integrasi bawaan dengan CA Service menyediakan repositori dengan tingkat ketersediaan tinggi dan dikelola Google untuk CA pribadi Anda.
Root of trust yang fleksibel: menggunakan root certificate authority (CA) lokal yang ada untuk menandatangani subordinate CA yang dihosting di CA Service. Kemudian, Anda dapat membuat dan mengelola root certificate yang benar-benar baru langsung di dalam CA Service.
Dekripsi spesifik: gunakan
SessionMatcheruntuk menentukan dengan tepat traffic mana yang akan didekripsi. Anda dapat memicu pemeriksaan TLS berdasarkan parameter berikut:- Nama domain situs: mencocokkan situs tertentu menggunakan ekspresi reguler dan daftar domain.
- Kriteria jaringan: menargetkan rentang alamat IP sumber atau blok CIDR tertentu, seperti
10.0.0.0/24, untuk menentukan batas jaringan. - Logika Boolean: menggabungkan beberapa kondisi—seperti IP sumber dan URL tujuan—untuk membuat aturan keamanan yang sangat spesifik.
Arsitektur kebijakan yang skalabel:
Kebijakan khusus: menetapkan kebijakan pemeriksaan TLS dan kumpulan CA yang unik ke setiap kebijakan Secure Web Proxy untuk isolasi yang ketat.
Kebijakan bersama: menyederhanakan pengelolaan kebijakan dengan membagikan satu konfigurasi pemeriksaan TLS ke beberapa kebijakan proxy.
Visibilitas Uniform Resource Identifier (URI) lengkap: memeriksa seluruh URI (termasuk domain, jalur, dan string kueri, seperti
www.example.com/downloads/malware.exe), bukan hanya nama domain.Kontrol akses yang akurat: gunakan pemeriksaan TLS untuk menerapkan kebijakan untuk jalur tertentu dari sebuah situs. Misalnya, Anda dapat mengizinkan akses ke
www.example.com/documentation, tetapi memblokirwww.example.com/uploads.Dukungan CA perantara: mengurangi biaya penggunaan CA Service dengan menyimpan satu CA perantara dalam cache secara lokal untuk menandatangani sertifikat entitas akhir, alih-alih mengeluarkan permintaan per domain langsung ke CA Service. Untuk mengetahui informasi selengkapnya, lihat Mode penerbitan sertifikat.
Peran certificate authority dalam pemeriksaan TLS
Untuk memeriksa traffic terenkripsi, Secure Web Proxy bertindak sebagai perantara tepercaya. Hal ini melibatkan proses terkoordinasi antara proxy, CA Service, dan perangkat klien.
Persyaratan kepercayaan klien
Pemeriksaan TLS dirancang untuk lingkungan tempat organisasi memiliki kontrol administratif atas perangkat klien, seperti laptop, server, atau virtual machine (VM) terkelola.
Kepercayaan container agen: saat merutekan traffic web keluar dari agen AI dalam container, seperti di Cloud Run atau Google Kubernetes Engine (GKE), Anda harus mengekspor sertifikat root CA dari kumpulan CA atau infrastruktur kunci publik (PKI) pribadi dan memasukkannya ke dalam trust store sertifikat container. Misalnya, Anda dapat mengonfigurasi runtime container atau menetapkan variabel lingkungan
AGENT_GATEWAY_ROOT_CERTIFICATESatauSSL_CERT_FILE. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi root CA, lihat Menyiapkan inspeksi TLS di "Men-deploy Secure Web Proxy sebagai Gateway Agen".Trust anchor pribadi: karena Secure Web Proxy menampilkan sertifikat yang ditandatangani oleh CA internal Anda, bukan Public CA, klien hanya memercayai koneksi jika CA root pribadi Anda telah diinstal sebelumnya.
Cakupan administratif: koneksi dari hardware yang tidak dikelola biasanya memicu peringatan
Insecure connectionkarena perangkat ini tidak memiliki trust anchor khusus organisasi Anda.
Menangani kegagalan intersepsi
Bahkan di perangkat terkelola, koneksi tertentu tidak dapat disadap karena penyematan sertifikat. Penyematan sertifikat terjadi saat aplikasi di-hardcode untuk hanya menerima kunci publik tertentu atau rantai CA publik tertentu.
- Contoh penyematan sertifikat: layanan umum yang menggunakan penyematan mencakup update sistem Windows dan macOS, update Google Chrome, dan aplikasi seluler keamanan tinggi tertentu.
- Hasil penyematan sertifikat: saat Secure Web Proxy menampilkan sertifikat yang ditandatangani, aplikasi akan mendeteksi bahwa sertifikat tersebut tidak cocok dengan ekspektasi hardcode-nya dan menghentikan koneksi.
Mitigasi dan kontrol yang akurat
Untuk mencegah gangguan layanan pada aplikasi yang disematkan atau untuk menjaga privasi
situs sensitif, Anda dapat menggunakan atribut SessionMatcher untuk mengabaikan
pemeriksaan. Anda dapat membatasi atau melewati pemeriksaan berdasarkan parameter berikut:
- Atribut tujuan: nama domain yang sepenuhnya memenuhi syarat (FQDN) tertentu.
- Atribut sumber: tag aman, akun layanan, atau alamat IP.
- Logika kustom: menggunakan ekspresi boolean untuk mengecualikan traffic tertentu saat memeriksa lingkungan lainnya.
Mode penerbitan sertifikat
Secure Web Proxy mendukung dua mode untuk menyediakan sertifikat yang digunakan untuk mendekripsi traffic selama proses pemeriksaan TLS. Pilihan ini bergantung pada persyaratan biaya, performa, dan logging audit Anda.
Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi penandatanganan CA perantara lokal.
Penandatanganan CA perantara lokal
Jika Anda menetapkan certificateIssuanceMode ke LOCAL_INTERMEDIATE_CA_SIGNING,
Secure Web Proxy akan meminta satu sertifikat CA perantara dari kumpulan CA
Anda. Proxy meng-cache CA perantara ini dan menandatangani sertifikat entitas akhir
individual secara lokal untuk domain yang diperlukan.
Fitur mode penerbitan sertifikat penandatanganan CA perantara lokal adalah sebagai berikut:
Biaya CA Service yang lebih rendah: permintaan ke CA Service dibatasi pada siklus refresh CA perantara (biasanya sekali per hari) bukan terjadi untuk setiap domain, sehingga biaya transaksi menjadi lebih rendah.
Pengurangan visibilitas: setiap sertifikat entitas akhir yang ditandatangani proxy Anda secara lokal tidak dicatat dalam log audit CA Service.
Penyediaan leaf langsung
Jika Anda menetapkan certificateIssuanceMode ke DIRECT_LEAF_PROVISIONING,
Secure Web Proxy akan langsung berkomunikasi dengan pool CA Service
Anda untuk setiap domain unik guna meminta sertifikat entitas akhir.
Fitur mode penerbitan sertifikat penyediaan leaf langsung adalah sebagai berikut:
Kemampuan observasi yang lebih baik: setiap permintaan sertifikat yang dihasilkan dicatat dalam log audit CA Service, sehingga Anda dapat melacak dan mengaudit semua aktivitas pembuatan sertifikat.
Biaya CA Service yang lebih tinggi: karena permintaan dikirim ke CA Service untuk setiap domain, proses ini dapat menyebabkan biaya transaksi yang lebih tinggi di lingkungan yang memiliki beberapa domain unik atau tugas proxy.
Metode konfigurasi certificate authority
Untuk mengaktifkan pemeriksaan TLS, siapkan certificate authority (CA) Anda menggunakan salah satu metode berikut:
Subordinate CA di CA Service: menggunakan root CA eksternal yang ada untuk menandatangani subordinate CA yang disimpan dalam Google Cloud.
Root CA eksternal: menggunakan root CA eksternal untuk menandatangani sertifikat yang dibuat saat runtime melalui subordinate CA.
Root CA yang dikelola Google: buat root certificate baru langsung dalam CA Service untuk menandatangani subordinate CA Anda.
Untuk mengetahui informasi selengkapnya tentang metode ini, lihat Membuat kumpulan CA subordinat.