Pemeriksaan TLS Lokal vs. Berbasis Awan: Pertimbangan dalam Penerapan
- Pemeriksaan TLS mendekripsi, memeriksa, dan mengenkripsi ulang lalu lintas, sehingga teks biasa muncul sebentar di mana pun proses tersebut berlangsung.
- Pemeriksaan lokal memungkinkan pengendalian atas teks biasa dan kunci lokal; evaluasi layanan berbasis awan dan proses pengolahannya secara terpisah.
- Pedoman NSA merekomendasikan agar setiap sesi diperiksa satu kali, di dalam jaringan perusahaan, tanpa menggunakan proxy berantai.
- Menyimpan daftar pengecualian yang telah ditinjau untuk aplikasi yang disematkan, kategori yang sensitif terhadap privasi, dan lalu lintas yang terputus saat diperiksa.
- Client Hello yang terenkripsi, yang diterbitkan sebagai RFC 9849, membatasi visibilitas pasif dan memerlukan penanganan yang cermat.
Pemeriksaan TLS (yang sering kali masih disebut sebagai pemeriksaan SSL) adalah proses menyadap sesi TLS, mendekripsi sesi tersebut menggunakan sertifikat yang tepercaya oleh perusahaan, memeriksa isinya, dan mengenkripsinya kembali sebelum meneruskannya ke tujuan. Tanpa proses ini, gerbang web aman, mesin DLP, dan sandbox hanya dapat melihat metadata tujuan. Dengan proses ini, mereka dapat mendeteksi malware, memblokir eksfiltrasi data, dan menegakkan kebijakan penggunaan yang dapat diterima di dalam sesi terenkripsi.
Keputusannya bukanlah apakah akan melakukan inspeksi, melainkan di mana. Panduan ini membandingkan inspeksi TLS lokal dan berbasis cloud berdasarkan jalur dekripsi, tanggung jawab sertifikat, pengecualian, pencatatan, dan operasional.
Artikel ini merupakan bagian dari panduan Keamanan Hybrid Cloud.
Cara Kerja Inspeksi TLS
Pemeriksaan TLS bekerja dengan cara meminta proxy tepercaya untuk mengakhiri sesi terenkripsi klien, memeriksa isinya, dan membuka sesi terenkripsi baru ke tujuan.
Proksi bertindak sebagai server bagi klien dan sebagai klien bagi tujuan:
- Klien memulai sesi TLS ke sebuah situs web atau aplikasi.
- Proksi tersebut mencegat koneksi dan menampilkan sertifikat untuk tujuan tersebut, yang ditandatangani oleh otoritas sertifikat (CA) inspeksi perusahaan yang dipercaya oleh perangkat klien.
- Proksi membuka sesi TLS-nya sendiri ke tujuan sebenarnya dan memverifikasi sertifikat server tersebut.
- Lalu lintas data didekripsi di antara kedua sesi tersebut, diperiksa, dan dienkripsi kembali.
Ini berarti proxy tersebut memegang kunci yang sangat kuat dan menangani teks biasa (plaintext) untuk setiap sesi yang diperiksa. Saran dari NSA berjudul “Mengelola Risiko dari Pemeriksaan Transport Layer Security” merekomendasikan untuk meminimalkan hal tersebut: lakukan pemeriksaan hanya sekali, di dalam jaringan perusahaan, dan hindari pemeriksaan berulang oleh beberapa proxy pengalih. Peringatan sebelumnya dari CISA mengenai intersepsi HTTPS memperingatkan bahwa produk pemeriksaan yang diimplementasikan dengan buruk dapat melemahkan keamanan TLS, misalnya dengan gagal memvalidasi sertifikat hulu secara benar.
Perbandingan Sekilas: Pemeriksaan TLS Lokal vs. di Awan
Pemeriksaan lokal menyimpan teks biasa dan kunci di infrastruktur Anda, sedangkan pemeriksaan berbasis cloud memindahkannya ke titik kehadiran penyedia layanan.
| Faktor | Pemeriksaan TLS lokal (di lokasi) | Pemeriksaan TLS di awan |
|---|---|---|
| Di mana teks biasa terdapat | Perangkat di pusat data atau cabang Anda | Titik kehadiran penyedia layanan |
| Siapa yang memegang kunci pribadi CA untuk inspeksi? | Anda, jika diinginkan, dapat menggunakan HSM Anda sendiri | Penyedia layanan, atau Anda melalui opsi kunci yang didukung oleh penyedia layanan |
| Paling cocok untuk | Data yang diatur, lalu lintas internal, pengguna di lokasi, OT | Pengguna jarak jauh, lalu lintas langsung ke SaaS |
| Latensi bagi pengguna di lokasi | Tergantung pada kapasitas lokal dan jalur lalu lintas | Tergantung pada jarak titik kehadiran dan perutean |
| Perencanaan kapasitas | Hormat kami; proses dekripsi memerlukan daya komputasi yang tinggi | Penyedia |
| Ketergantungan pada konektivitas eksternal | Tidak diperlukan untuk penerapan kebijakan web lokal; wajib untuk layanan berbasis cloud seperti perlindungan data | Wajib |
| Catatan dan lokasi bukti | Log lokal dapat dikonfigurasi; bukti dari layanan cloud mengikuti kebijakan penyimpanan layanan tersebut | Wilayah penyedia, tergantung pada konfigurasi |
| Upaya operasional | Penentuan ukuran perangkat keras, penerapan patch, siklus hidup sertifikat | Distribusi sertifikat, pengecualian, konfigurasi penyedia |
Sebagian besar organisasi hibrida menggunakan kedua metode tersebut: inspeksi lokal untuk lalu lintas tertentu yang berada di lokasi dan diatur, serta inspeksi berbasis cloud untuk pengguna jarak jauh. Terapkan terminasi TLS pada setiap jalur dan hindari dekripsi berlebihan, termasuk saat gerbang lokal meneruskan lalu lintas untuk layanan yang diterapkan melalui cloud.
Jalur dekripsi
Setiap desain hibrida harus memetakan setiap titik terminasi dan enkripsi ulang TLS serta menghindari pemeriksaan yang berlebihan.
Jalur yang umum antara lain:
- Pengguna kantor ke internet: melalui gerbang lokal, atau melalui terowongan ke titik kehadiran di cloud
- Pengguna jarak jauh ke internet: titik kehadiran di awan, atau dialihkan melalui jaringan backhaul ke gerbang lokal
- Pengguna ke aplikasi pribadi: tentukan apakah dan di mana jalur ZTNA yang dipilih mendukung pemeriksaan TLS
- Sesi peramban: pengaturan di tingkat peramban yang memungkinkan pengguna melihat konten tanpa dekripsi jaringan
- Titik akhir: pemeriksaan berbasis agen pada perangkat
Salah satu risiko dalam lingkungan hibrida adalah dekripsi ganda yang tidak direncanakan. Sebuah cabang mungkin mengirimkan lalu lintas melalui proxy lokal, lalu melalui layanan cloud yang kembali memutus koneksi TLS. Dokumentasikan setiap tahap pemeriksaan yang diperlukan, lindungi setiap batas teks biasa, dan hilangkan tahap-tahap yang berlebihan yang dapat meningkatkan risiko paparan atau menambah kerumitan dalam pemecahan masalah.
Tanggung jawab terkait sertifikat
Keandalan pemeriksaan TLS bergantung sepenuhnya pada keandalan sertifikat yang mendasarinya, jadi tetapkan kepemilikan yang jelas untuk setiap tahap dalam siklus hidup sertifikat:
- Pembuatan dan perlindungan CA. Dokumentasikan lokasi penyimpanan kunci pribadi, siapa saja yang dapat mengaksesnya, dan apakah diperlukan HSM. Pastikan integrasi HSM yang didukung untuk setiap gateway lokal atau layanan cloud beserta versi produknya; jangan berasumsi bahwa integrasi tersebut didukung.
- Distribusi. Cara CA diinstal pada penyimpanan tepercaya sistem operasi dan peramban di perangkat yang dikelola, serta apa yang terjadi pada perangkat yang tidak dikelola.
- Rotasi. Jadwal dan prosedur penggantian CA inspeksi tanpa penghentian operasi.
- Validasi hulu. Pastikan proxy menolak sertifikat tujuan yang tidak sah, kedaluwarsa, atau dicabut, alih-alih menyembunyikannya dari pengguna.
- Dukungan protokol. TLS 1.3 (RFC 8446) harus diperiksa secara native, bukan diturunkan versinya.
Pengecualian lalu lintas
Tidak ada organisasi pun yang seharusnya mendekripsi semua data, jadi buatlah daftar pengecualian yang terdokumentasi dan ditinjau secara berkala:
| Jenis pengecualian | Alasan | Penanganan yang umum |
|---|---|---|
| Aplikasi yang sertifikatnya telah dipasang | Pemeriksaan memutus koneksi | Lakukan pengalihan berdasarkan tujuan; terapkan kontrol reputasi dan kategori |
| Kategori kesehatan, keuangan, dan pribadi | Privasi karyawan, persyaratan hukum, dan persyaratan dewan pekerja | Lewati proses dekripsi; tetap terapkan kebijakan kategori |
| TLS timbal balik dan otentikasi sertifikat klien | Proksi tidak dapat menampilkan sertifikat klien | Lewati atau gunakan fitur pass-through yang didukung |
| Layanan pembaruan dan beberapa protokol OT | Stabilitas dan dukungan vendor | Bypass berdasarkan tujuan dengan akses terbatas |
| QUIC dan HTTP/3 (RFC 9000) | Banyak proxy tidak dapat memeriksa QUIC | Blokir QUIC agar peramban beralih ke TLS melalui TCP, atau pastikan dukungan bawaan |
Tinjau pengecualian setiap tiga bulan sekali. Pengecualian yang sudah tidak berlaku lagi sering kali terlewatkan.
Client Hello yang Terenkripsi dan Dampaknya
Client Hello yang terenkripsi menyembunyikan nama host tujuan dari pengamat pasif, sehingga visibilitas berbasis SNI dan beberapa keputusan terkait bypass perlu ditinjau kembali.
Encrypted Client Hello diterbitkan sebagai RFC 9849 pada tahun 2026. ECH mengenkripsi bagian dari proses handshake TLS yang sebelumnya mengungkapkan nama host tujuan (Server Name Indication) serta bidang-bidang lainnya. Alat-alat pasif yang mengklasifikasikan lalu lintas dengan membaca SNI tidak lagi dapat melihat informasi tersebut pada situs-situs yang mengaktifkan ECH.
Proksi eksplisit yang menghentikan TLS berada dalam posisi yang berbeda, karena mereka membangun sesi sendiri ke tujuan masing-masing. Meskipun demikian, ECH memiliki implikasi operasional:
- Peramban mungkin mengirimkan ekstensi yang mirip ECH meskipun ECH tidak sedang digunakan, sehingga produk pemantauan perlu menanganinya dengan benar.
- RFC tersebut menyebutkan bahwa dalam lingkungan perusahaan yang dikelola, salah satu pendekatannya adalah menonaktifkan ECH melalui kebijakan grup dan mengandalkan klien untuk mematuhi pengaturan tersebut.
- Keputusan terkait kategori dan reputasi yang bergantung pada SNI untuk lalu lintas yang dilewatkan memerlukan alternatif, seperti pengendalian di tingkat DNS atau konfigurasi proxy secara eksplisit.
Pastikan peta jalan ECH dan perilaku pengujian penyedia layanan inspeksi Anda sesuai dengan versi browser terkini.
Penebangan
Catatan pemeriksaan dapat berisi URL, identitas, dan bukti DLP, sehingga isi, lokasi, dan aksesnya memerlukan keputusan yang tegas:
- Kolom mana saja yang dicatat untuk lalu lintas yang telah didekripsi dibandingkan dengan lalu lintas yang dilewati?
- Di mana log-log tersebut disimpan, dan apakah log-log tersebut boleh dibawa keluar dari yurisdiksi
- Jangka waktu penyimpanan, dan siapa saja yang dapat mengakses bukti konten secara lengkap
- Peristiwa apa saja yang diteruskan ke SIEM?
Pemeriksaan lokal memudahkan penyimpanan log dan bukti di dalam negeri. Pemeriksaan berbasis cloud memerlukan konfirmasi mengenai wilayah penyimpanan log penyedia layanan dan kontrol akses. Lihat bagian “Kedaulatan Data” dalam Keamanan Cloud Hibrida.
Pertimbangan operasional
Pemeriksaan lokal menukar upaya operasional dengan kontrol, pemeriksaan berbasis cloud menukar kontrol dengan kemudahan, sedangkan pemeriksaan hibrida memerlukan satu mesin kebijakan agar dapat berfungsi.
Pemeriksaan lokal memerlukan penyesuaian kapasitas perangkat untuk mendekripsi lalu lintas pada beban puncak, memastikan mesin pemeriksaan selalu diperbarui, serta merencanakan penambahan kapasitas perangkat keras atau virtual. Sebagai imbalannya, hal ini memberikan kendali penuh atas teks biasa, kunci, dan log untuk lalu lintas yang diperiksa secara lokal, serta penegakan kebijakan web dan aplikasi pribadi secara lokal tetap berlanjut selama gangguan jaringan WAN atau cloud, sementara layanan yang dijalankan di cloud vendor akan ditangguhkan hingga konektivitas pulih.
Pemeriksaan berbasis cloud mengalihkan perencanaan kapasitas dan pembaruan mesin ke penyedia layanan. Hal ini tetap memerlukan distribusi sertifikat, pengelolaan pengecualian, dan penyempurnaan kebijakan, serta menimbulkan ketergantungan pada ketersediaan dan konektivitas penyedia layanan.
Pemeriksaan hibrida menggabungkan keduanya, tetapi hanya berfungsi dengan baik jika menggunakan satu mesin kebijakan. Jika gerbang lokal dan gerbang cloud memiliki daftar pengecualian serta aturan DLP yang terpisah, pengguna akan diperlakukan secara berbeda tergantung pada lokasinya.
Bagaimana Skyhigh menangani inspeksi lokal dan berbasis cloud
Skyhigh melakukan pemeriksaan TLS secara lokal jika persyaratan kepatuhan mengharuskannya, dan di cloud untuk pengguna jarak jauh, semuanya di bawah satu kebijakan.
Skyhigh Hybrid SSE Mesh menjalankan dekripsi dan inspeksi SSL/TLS secara lokal pada perangkat milik organisasi sendiri jika diwajibkan oleh persyaratan kepatuhan, serta di titik kehadiran (PoP) cloud Skyhigh untuk pengguna jarak jauh, dengan satu mesin kebijakan yang berlaku di kedua lingkungan tersebut. Kebijakan Akses Berbasis Peran ( Secure Web Gateway ) dan Akses Zero Trust diterapkan secara native di gateway, sementara kebijakan perlindungan data diterapkan di cloud Skyhigh pada lalu lintas yang diteruskan oleh gateway. Lalu lintas web yang didekripsi di gateway lokal diperiksa dan dienkripsi ulang di sana untuk penerapan kebijakan web lokal. Jika suatu kebijakan menggunakan layanan yang diterapkan di cloud seperti perlindungan data, gateway akan meneruskan lalu lintas yang relevan ke cloud Skyhigh, di mana kebijakan yang sama diterapkan. Kontrol Browser Aman Tanpa Agen (Agentless Secure Browser Controls) menambahkan pemeriksaan yang mendukung WebSocket terhadap lalu lintas AI dan pesan dalam sesi browser.
Sumber
- NSA. Mengelola Risiko dari Pemeriksaan Keamanan Lapisan Transportasi (November 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
- CISA. “Penyadapan HTTPS Melemahkan Keamanan TLS” (Peringatan TA17-075A, Maret 2017). https://www.cisa.gov/news-events/alerts/2017/03/16/https-interception-weakens-tls-security
- IETF. RFC 8446: Protokol Transport Layer Security (TLS) Versi 1.3. https://www.rfc-editor.org/rfc/rfc8446.html
- IETF. RFC 9849: Client Hello yang Dienkripsi dengan TLS. https://www.rfc-editor.org/rfc/rfc9849.html
- IETF. RFC 9000: QUIC: Protokol Transportasi yang Aman dan Multiplexed Berbasis UDP. https://www.rfc-editor.org/rfc/rfc9000.html
- Skyhigh Security. “Menerapkan Model Hybrid Kini Semakin Mudah Berkat Platform Skyhigh SSE” (3 Oktober 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html
- Skyhigh Security. “Memodernisasi Symantec Edge Secure Web Gateway Anda dengan Skyhigh Hybrid SSE Mesh” (15 Juli 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html