Secure Web Gateway Migrasi: Daftar Periksa Proses Transisi dan Pemulihan
- Migrasi SWG memerlukan inventarisasi, uji coba, pengujian, peluncuran bertahap, dan pengembalian ke kondisi semula yang telah diuji, sama seperti peralihan sistem produksi pada umumnya.
- Otentikasi, sertifikat TLS dan pengecualiannya, pengalihan lalu lintas, serta integrasi ICAP atau DLP merupakan hal-hal yang paling berisiko.
- Jalankan gateway baru secara paralel dan pindahkan pengguna secara bertahap, bukan sekaligus.
- Tentukan pemicu rollback dan kriteria penerimaan sebelum gelombang produksi pertama, bukan saat terjadi insiden.
- Migrasi merupakan kesempatan terbaik untuk menghapus aturan-aturan yang sudah bertahun-tahun tidak digunakan dan pengecualian-pengecualian yang sudah usang.
Migrasi " secure web gateway " memindahkan proses pemeriksaan lalu lintas web dan kebijakan dari satu platform proxy ke platform proxy lainnya, baik dari perangkat on-premises ke perangkat baru, ke layanan cloud, maupun ke model hybrid. Daftar periksa ini mencakup seluruh tahapan: inventarisasi, perancangan target, penerjemahan kebijakan, persiapan rollback, uji coba, pengujian, peralihan bertahap, dan penerimaan.
Artikel ini merupakan bagian dari panduan Keamanan Hybrid Cloud. Untuk informasi lebih lanjut mengenai Blue Coat , ProxySG, dan Symantec Edge SWG, silakan lihat artikel “Blue Coat ” dan “ProxySG End of Life: Migration Planning”.
Tahap 1: Inventarisasi
Fase 1 mendokumentasikan kondisi terkini infrastruktur gateway, pengalihan lalu lintas, identitas, pemeriksaan TLS, kebijakan, dan integrasi sebelum pekerjaan perancangan dimulai.
Infrastruktur
- Setiap gateway: model, versi perangkat lunak, lokasi, peran, dan tanggal akhir masa pakai (untuk ProxySG dan Edge SWG, lihat artikel siklus hidup dari Broadcom)
- Volume lalu lintas dan throughput puncak per situs, beserta porsi dekripsi TLS
- Jumlah pengguna per situs dan untuk akses jarak jauh
- Rantai proxy hulu dan hilir, penyeimbang beban, serta desain failover
Pengalihan lalu lintas
- Pengaturan proxy eksplisit, berkas PAC, dan WPAD
- Titik intersepsi transparan (WCCP, perutean berbasis kebijakan)
- Terowongan dari cabang (IPsec, GRE)
- Agen pada titik akhir
- Pengecualian untuk penjualan langsung melalui internet
Identitas
- Ruang otentikasi (SAML, Kerberos/IWA, LDAP, sertifikat klien)
- Pemetaan grup yang digunakan dalam kebijakan
- Lalu lintas yang tidak terotentikasi (server, IoT, OT) dan cara penanganannya
Pemeriksaan TLS
- Pemeriksaan CA, lokasi utama, masa berlaku, dan metode distribusi
- Daftar pengecualian dekripsi beserta alasannya dan pemiliknya
Kebijakan
- Ekspor kebijakan secara lengkap, termasuk urutan aturan, kategori, daftar khusus, dan pengecualian
- Aturan yang tidak pernah diterapkan dalam 90 hari terakhir (calon untuk dihapus)
Integrasi
- Koneksi ICAP ke DLP, antivirus, dan sandboxing
- Penerusan log ke SIEM dan alat pelaporan
- Pemantauan dan pemberitahuan
Tahap 2: Perancangan target
Pada Tahap 2, ditentukan lokasi mana saja yang akan diperiksa serta kelompok pengguna mana saja yang akan diperiksa, serta bagaimana penanganan lalu lintas, sertifikat, dan log akan dilakukan.
- Tentukan di mana setiap situs dan kelompok pengguna akan diperiksa: di lokasi, di cloud, atau dalam model hybrid
- Tentukan metode pengalihan lalu lintas untuk masing-masing: proxy eksplisit atau PAC untuk jaringan yang dikelola, agen atau pengaturan peramban untuk pengguna yang berpindah-pindah, serta terowongan untuk cabang-cabang
- Pastikan penempatan pemeriksaan TLS agar setiap aliran data hanya didekripsi satu kali. Pedoman NSA menyarankan agar pemeriksaan dilakukan satu kali di dalam jaringan perusahaan dan menghindari pemeriksaan berulang oleh proxy yang dirangkai (NSA)
- Kapasitas ukuran untuk throughput puncak setelah dekripsi ditambah pertumbuhan
- Merancang ketersediaan tinggi dan perilaku saat terjadi kegagalan
- Tentukan di mana log dan bukti DLP akan disimpan
- Rencanakan penerapan CA inspeksi baru atau pengalihan CA inspeksi yang sudah ada, serta pastikan penyimpanan kunci yang didukung dan integrasi HSM yang diperlukan
Tahap 3: Penerapan kebijakan
Fase 3 mengadaptasi kebijakan yang ada ke dalam platform baru melalui pemetaan yang terstruktur dan tervalidasi, bukan melalui konversi berkas secara langsung.
- Peta setiap aturan sumber ke aturan tujuan yang setara, atau tandai aturan tersebut untuk dihapus
- Mapping kategori URL antar vendor dan mengevaluasi perbedaan pada kategori yang berdampak besar
- Buat ulang daftar khusus, daftar putih, dan daftar hitam
- Terjemahkan aturan yang bergantung pada otentikasi dan konfirmasikan pemetaan grup
- Buat kembali metode untuk melewati proses dekripsi, dan tinjau masing-masing metode tersebut untuk memastikan apakah masih diperlukan
- Gantilah proses serah-terima DLP berbasis ICAP dengan layanan perlindungan data milik platform itu sendiri jika memungkinkan, pastikan di mana proses pemeriksaan dilakukan, atau bangun kembali integrasinya
- Catat setiap perubahan dan setiap aturan yang tidak berlaku lagi beserta alasannya, sesuai dengan proses pengendalian perubahan konfigurasi Anda (NIST SP 800-128 menjelaskan praktik manajemen konfigurasi yang berfokus pada keamanan)
Beberapa platform menyediakan fitur impor otomatis untuk polis yang sudah ada. Anggaplah setiap proses impor sebagai titik awal yang masih perlu ditinjau dan diuji.
Tahap 4: Persiapan rollback
Fase 4 menetapkan pemicu dan mekanisme rollback sebelum uji coba. Lakukan pengujian rollback selama uji coba dan pastikan kesiapan sebelum setiap gelombang peluncuran ke produksi.
Pemicu rollback (contoh)
- Kegagalan otentikasi yang melebihi ambang batas yang telah disepakati
- Aplikasi yang sangat penting bagi bisnis tidak dapat diakses selama lebih dari waktu yang telah disepakati
- Tiket helpdesk yang melebihi kelipatan tertentu dari nilai dasar
- Telah dipastikan bahwa pengendalian keamanan tersebut tidak diterapkan
Mekanisme rollback
- Pertahankan gateway lama agar tetap beroperasi dan terus diperbarui hingga tahap penerimaan akhir
- Pastikan perubahan pada berkas PAC, DNS, dan rute tetap memiliki versi agar dapat dikembalikan ke versi sebelumnya
- Pertimbangkan waktu penyimpanan dalam cache DNS dan PAC dalam perkiraan rollback
- Pastikan bahwa CA inspeksi lama tetap dianggap tepercaya di perangkat selama masa transisi
- Tentukan siapa saja yang berwenang untuk menyetujui rollback, dan dokumentasikan langkah-langkahnya
- Lakukan pengembalian ke versi sebelumnya selama tahap uji coba dan pastikan kesiapan sebelum setiap gelombang migrasi
Tahap 5: Uji Coba
Pada Fase 5, kelompok percontohan yang representatif akan dioperasikan pada gateway baru, secara paralel dengan gateway lama, selama setidaknya satu siklus bisnis.
- Pilihlah pengguna percontohan yang mewakili departemen-departemen utama, jenis perangkat, dan lokasi, termasuk staf TI dan beberapa pengguna bisnis yang aktif
- Jalankan gateway baru secara paralel dengan gateway lama
- Arahkan lalu lintas pilot ke gateway baru melalui PAC, agen, atau perubahan perutean yang dapat dibatalkan dengan cepat
- Berikan saluran yang jelas kepada pengguna uji coba untuk melaporkan masalah
- Laksanakan program percontohan tersebut setidaknya selama satu siklus bisnis penuh, termasuk akhir bulan jika berlaku
Tahap 6: Pengujian
Fase 6 menguji setiap aspek yang akan dirasakan perbedaannya oleh pengguna, mulai dari otentikasi hingga kinerja dan failover.
| Area uji coba | Hal-hal yang perlu diverifikasi |
|---|---|
| Otentikasi | Pengguna dan grup teridentifikasi dengan benar; SSO berfungsi; lalu lintas sistem yang tidak terotentikasi berjalan sesuai rancangan |
| Kebijakan Kategori dan URL | Kategori "Diizinkan", "Diblokir", dan "Diperingatkan" berperilaku sama seperti di sumbernya |
| Pemeriksaan TLS | Sertifikat yang dipercaya di semua perangkat yang dikelola; dapat melewati pembatasan di tempat kerja; aplikasi yang disematkan berfungsi |
| Perlindungan terhadap ancaman | Sampel malware uji coba dan URL yang diketahui berbahaya diblokir |
| DLP | Dokumen pengujian untuk setiap kelas data akan terdeteksi saat diunggah |
| Aplikasi bisnis | 50 Aplikasi Web dan Layanan SaaS Teratas yang Penting bagi Bisnis: Berfungsi dari Awal hingga Akhir |
| Kinerja | Waktu pemuatan halaman dan throughput pada jam-jam sibuk masih dalam batas yang wajar |
| Penebangan | Peristiwa masuk ke SIEM dengan kolom-kolom yang diharapkan |
| Failover | Kegagalan node gateway ditangani tanpa menimbulkan dampak bagi pengguna |
Tahap 7: Migrasi bertahap
Pada Fase 7, pengguna dan situs dipindahkan ke gateway baru secara bertahap, dimulai dari situs-situs dengan risiko terendah.
- Kelompokkan pengguna dan situs ke dalam gelombang berdasarkan risiko dan kompleksitas, dimulai dari situs berisiko rendah
- Beritahukan setiap gelombang terlebih dahulu, dengan menyertakan kontak pendukung
- Jadwalkan gelombang di luar periode-periode bisnis yang kritis
- Siapkan tim di ruang komando selama beberapa jam pertama setiap gelombang
- Pantau tiket helpdesk, tingkat pemblokiran, dan tingkat kesalahan dibandingkan dengan nilai acuan
- Berhenti sejenak di antara gelombang untuk menyelesaikan masalah sebelum melanjutkan
Tahap 8: Penerimaan dan penonaktifan
Fase 8 memastikan bahwa kriteria penerimaan telah terpenuhi, kemudian menonaktifkan gateway, sertifikat, dan kontrak yang lama.
Kriteria penerimaan (contoh)
- Semua pengguna dan situs telah dipindahkan
- Volume layanan bantuan telah kembali ke tingkat normal selama dua minggu
- Semua kasus uji berhasil di lingkungan produksi
- Catatan dan laporan yang telah diverifikasi oleh tim operasi keamanan dan kepatuhan
- Daftar pengecualian telah ditinjau dan disetujui
Penonaktifan
- Hapus gateway lama dari berkas PAC, pengaturan rute, dan DNS
- Cabut dan hapus CA inspeksi lama dari perangkat, jika telah diganti
- Arsipkan log lama sesuai dengan kebijakan penyimpanan
- Hapus data dari perangkat keras secara aman dan buanglah
- Menutup lisensi dan kontrak dukungan
Jadwal umum
Jangka waktu bergantung pada besarnya harta warisan dan tingkat kerumitan polis.
Sebuah organisasi dengan satu lokasi dapat menyelesaikan proses migrasi dalam hitungan minggu. Perusahaan besar dengan banyak lokasi sering kali melakukan penerapan secara paralel dan adopsi bertahap selama enam hingga dua belas bulan, menurut Skyhigh Security.
Bagaimana Skyhigh mendukung migrasi SWG
Skyhigh mendukung migrasi SWG melalui penerapan paralel, impor kebijakan CPL yang telah diverifikasi, serta model penerapan yang fleksibel.
Skyhigh Hybrid SSE Mesh diimplementasikan bersamaan dengan gateway yang sudah ada sehingga kebijakan dapat diverifikasi dengan lalu lintas paralel sebelum proses peralihan dilakukan. Skyhigh mengonversi kebijakan CPL ( Blue Coat ) yang sudah ada ke dalam konsol kebijakan terpadu melalui proses impor yang terverifikasi, dan kebijakan tersebut dibuat di konsol cloud Skyhigh. Kebijakan untuk aplikasi web dan aplikasi pribadi dapat diterapkan pada gateway di lokasi, sementara lalu lintas yang memerlukan perlindungan data yang diterapkan di cloud diteruskan ke cloud Skyhigh. Pengguna jarak jauh dilayani melalui titik kehadiran (PoP) di cloud. Skyhigh SWG dapat dijalankan di lokasi, model hybrid, atau di cloud, sehingga migrasi ini tidak memaksa perubahan pada model penerapan. Program Modernisasi "Blue Coat " menambahkan dukungan layanan dan kompensasi komersial bagi pelanggan yang memenuhi syarat.
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
- NIST. SP 800-128: Panduan Pengelolaan Konfigurasi Sistem Informasi yang Berfokus pada Keamanan. https://csrc.nist.gov/pubs/sp/800/128/upd1/final
- Broadcom. Penghentian dukungan dan siklus hidup produk untuk Edge SWG (ProxySG) dan Advanced Secure Gateway (KB 151102). https://knowledge.broadcom.com/external/article/151102/end-of-life-and-product-lifecycle-for-pr.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
- 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