Traffic yang dienkripsi 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 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 bertindak sebagai perantara yang aman.
Handshake klien: saat klien mencoba terhubung ke situs eksternal, seperti
www.example.com, Secure Web Proxy akan mencegat permintaan.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 leaf secara langsung dari Layanan CA 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 pada data HTTP teks biasa.
Server handshake: 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 yang sangat tersedia dan dikelola Google untuk CA pribadi Anda.
Root of trust yang fleksibel: gunakan certificate authority (CA) root lokal yang ada untuk menandatangani CA subordinat yang dihosting di CA Service. Kemudian, Anda dapat membuat dan mengelola sertifikat root yang benar-benar baru langsung dalam CA Service.
Dekripsi spesifik: gunakan
SessionMatcheruntuk menentukan secara tepat traffic mana yang akan didekripsi. Anda dapat memicu pemeriksaan TLS berdasarkan parameter berikut:- Nama domain situs: cocokkan situs tertentu menggunakan ekspresi reguler dan daftar domain.
- Kriteria jaringan: menargetkan rentang alamat IP sumber atau blok Classless Inter-Domain Routing (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 dapat diskalakan:
Kebijakan khusus: tetapkan kebijakan pemeriksaan TLS dan kumpulan CA unik ke setiap kebijakan Secure Web Proxy untuk isolasi yang ketat.
Kebijakan bersama: menyederhanakan pengelolaan kebijakan dengan membagikan satu konfigurasi pemeriksaan TLS di beberapa kebijakan proxy.
Visibilitas Uniform Resource Identifier (URI) lengkap: periksa seluruh URI (termasuk domain, jalur, dan string kueri, seperti
www.example.com/downloads/malware.exe), bukan hanya nama domain.Kontrol akses yang presisi: gunakan pemeriksaan TLS untuk menerapkan kebijakan bagi jalur tertentu di 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 melakukan caching lokal pada satu CA perantara untuk menandatangani sertifikat leaf, alih-alih menerbitkan 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. Proses ini melibatkan proses terkoordinasi antara proxy, Layanan CA, dan perangkat klien.
Persyaratan kepercayaan klien
Pemeriksaan TLS dirancang untuk lingkungan tempat organisasi memiliki kontrol administratif atas perangkat klien, seperti laptop terkelola, server, atau virtual machine (VM).
- Trust anchor pribadi: Karena Secure Web Proxy menampilkan sertifikat yang ditandatangani oleh CA internal Anda, bukan CA publik, 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 anchor tepercaya khusus organisasi Anda.
Menangani kegagalan intersepsi
Bahkan di perangkat terkelola, koneksi tertentu tidak dapat dicegat karena penyematan sertifikat. Penyematan sertifikat terjadi saat aplikasi dikodekan secara permanen untuk menerima hanya 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 dengan keamanan tinggi tertentu.
- Hasil pemasangan pin di sertifikat: saat Secure Web Proxy menampilkan sertifikat bertanda tangannya, aplikasi mendeteksi bahwa sertifikat tersebut tidak cocok dengan ekspektasi yang dikodekan secara permanen dan menghentikan koneksi.
Mitigasi dan kontrol yang presisi
Untuk mencegah gangguan layanan pada aplikasi yang disematkan atau untuk menjaga privasi situs sensitif, Anda dapat menggunakan atribut SessionMatcher untuk melewati 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: gunakan ekspresi boolean untuk mengecualikan traffic tertentu sambil memeriksa lingkungan lainnya.
Mode penerbitan sertifikat
Secure Web Proxy mendukung dua mode untuk menyediakan sertifikat yang digunakannya untuk mendekripsi traffic selama proses pemeriksaan TLS. Pilihan ini bergantung pada persyaratan biaya, performa, dan audit logging Anda.
Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi penandatanganan CA menengah lokal.
Penandatanganan CA perantara lokal
Jika Anda menyetel certificateIssuanceMode ke LOCAL_INTERMEDIATE_CA_SIGNING,
Secure Web Proxy akan meminta satu sertifikat CA perantara dari kumpulan CA
Anda. Proxy menyimpan CA perantara ini dalam cache dan menandatangani setiap sertifikat leaf secara lokal untuk domain yang diperlukan.
Fitur mode penerbitan sertifikat penandatanganan CA perantara lokal adalah sebagai berikut:
Biaya Layanan CA yang lebih rendah: permintaan ke Layanan CA dibatasi pada siklus refresh CA perantara (biasanya sekali per hari) daripada terjadi untuk setiap domain, sehingga menghasilkan biaya transaksi yang lebih rendah.
Berkurangnya kemampuan observasi: setiap sertifikat leaf yang ditandatangani proxy Anda secara lokal tidak dicatat dalam log audit Layanan CA.
Penyediaan leaf langsung
Jika Anda menyetel certificateIssuanceMode ke DIRECT_LEAF_PROVISIONING,
Secure Web Proxy akan berkomunikasi langsung dengan kumpulan Layanan CA
Anda untuk setiap domain unik guna meminta sertifikat leaf.
Fitur mode penerbitan sertifikat penyediaan leaf langsung adalah sebagai berikut:
Kemampuan observasi yang lebih baik: setiap permintaan sertifikat yang dibuat dicatat dalam log audit Layanan CA, sehingga Anda dapat melacak dan mengaudit semua aktivitas pembuatan sertifikat.
Biaya Layanan CA yang lebih tinggi: karena permintaan dikirim ke Layanan CA 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 otoritas sertifikat (CA) Anda menggunakan salah satu metode berikut:
CA turunan di CA Service: gunakan CA root eksternal yang ada untuk menandatangani CA turunan yang disimpan dalam Google Cloud.
CA root eksternal: menggunakan CA root eksternal untuk menandatangani sertifikat yang dibuat saat runtime melalui CA subordinat.
CA root yang dikelola Google: buat sertifikat root baru langsung dalam Layanan CA untuk menandatangani CA bawahan Anda.
Untuk mengetahui informasi selengkapnya tentang metode ini, lihat Membuat kumpulan CA bawahan.