๐ฌ๐ง Read this article in English
TL;DR: Transisi mendadak ke sistem kerja remote telah mengekspos keterbatasan arsitektur VPN tradisional. Akses remote zero trust menawarkan model keamanan yang secara fundamental berbeda โ model yang mengasumsikan tidak ada pengguna atau perangkat yang dapat dipercaya begitu saja. Namun, mencabut VPN Anda dalam semalam bukanlah langkah yang praktis maupun disarankan. Strategi yang tepat sangat bergantung pada arsitektur Anda saat ini, profil risiko, dan kematangan operasional perusahaan.
Enam Bulan Berjalan, dan Celah Mulai Terlihat
Enam bulan lalu, sebagian besar perusahaan menganggap akses remote sebagai sebuah fasilitas tambahan โ sesuatu yang diperuntukkan bagi eksekutif yang sedang bepergian atau untuk bekerja dari rumah sesekali di hari Jumat. Kemudian bulan Maret 2020 terjadi. Seluruh tenaga kerja beralih ke sistem remote hanya dalam hitungan hari, bukan bulan. Tim IT bergegas untuk menskalakan infrastruktur VPN yang tidak pernah dirancang untuk menangani 100% karyawan yang terhubung secara bersamaan dari jaringan rumah dengan kualitas dan keamanan yang sangat bervariasi.
Saya telah berbicara dengan puluhan pemimpin IT sejak pandemi dimulai, dan polanya selalu sama: lisensi VPN dibeli karena panik, bottleneck pada bandwidth langsung muncul, dan help desk kewalahan menangani masalah konektivitas. Yang lebih mengkhawatirkan, tim keamanan menyadari bahwa risiko pergerakan lateral (lateral movement) yang sebelumnya mereka anggap dapat dikelola tiba-tiba menjadi ancaman eksistensial. Inilah konteks di mana akses remote zero trust telah bergeser dari sekadar konsep masa depan menjadi diskusi mendesak di ruang direksi.
Pertanyaan yang terus saya dengar cukup sederhana: haruskah kita bertahan dengan VPN, beralih ke zero trust, atau menjalankan keduanya? Jawabannya, seperti biasa, adalah “tergantung” โ tetapi saya dapat membantu Anda memetakan faktor-faktor penentunya.
Memahami Model VPN Tradisional
Virtual Private Network (VPN) telah menjadi mekanisme akses remote standar selama lebih dari dua dekade. Konsepnya lugas: membuat terowongan (tunnel) terenkripsi antara perangkat pengguna jarak jauh dan jaringan perusahaan. Setelah terhubung, pengguna secara efektif berada “di dalam” perimeter jaringan dan dapat mengakses sumber daya seolah-olah mereka sedang duduk di meja kantor mereka.
Model ini berfungsi cukup baik di bawah kondisi tertentu:
- Persentase tenaga kerja yang bekerja secara remote relatif kecil pada waktu tertentu
- Sebagian besar aplikasi dan data berada di on-premises
- Perusahaan memiliki perimeter jaringan yang terdefinisi dengan jelas
- IT dapat menerapkan kepatuhan endpoint sebelum memberikan akses VPN
Asumsi mendasar di balik VPN adalah kepercayaan berbasis perimeter (perimeter-based trust): begitu Anda berada di dalam tembok pertahanan, Anda dipercaya. Hal ini masuk akal ketika “di dalam” berarti kantor fisik dengan perangkat yang dikelola pada jaringan yang terkontrol. Hal ini menjadi sangat tidak masuk akal ketika “di dalam” berarti laptop pribadi di jaringan Wi-Fi rumah yang digunakan bersama, dengan smart TV keluarga dan konsol game anak remaja yang berada di subnet yang sama.
Di Mana VPN Mulai Gagal Saat Diskalakan
Masalah yang paling sering saya temui di tahun 2020 terbagi dalam tiga kategori:
Performa dan skalabilitas. Konsentrator VPN memiliki kapasitas yang terbatas. Ketika 5.000 karyawan membutuhkan koneksi simultan alih-alih 500 orang seperti biasanya, Anda akan membentur batas perangkat keras, batasan lisensi, dan kendala bandwidth. Menarik kembali seluruh lalu lintas jaringan (backhauling) melalui pusat data terpusat akan menambah latensi, terutama untuk aplikasi berbasis cloud โ yang mana ini ironis, karena lalu lintas bergerak dari rumah pengguna ke pusat data, lalu ke cloud, dan kembali lagi.
Akses yang terlalu luas. Sebagian besar implementasi VPN memberikan akses di tingkat jaringan (network-level access). Setelah terhubung, pengguna sering kali dapat menjangkau jauh lebih banyak sumber daya daripada yang dibutuhkan oleh peran mereka. Seorang staf account payable yang terhubung melalui VPN secara teknis mungkin dapat mengakses server tim engineering. Permukaan serangannya (attack surface) menjadi sangat besar, dan jika sebuah kredensial disusupi, penyerang mewarisi akses luas yang sama.
Celah visibilitas endpoint. Solusi VPN tradisional memverifikasi identitas pengguna pada saat koneksi dibuat, tetapi sering kali hanya melakukan validasi berkelanjutan yang sangat terbatas terhadap postur perangkat, perilaku pengguna, atau faktor risiko kontekstual di sepanjang sesi tersebut.
Apa Sebenarnya Makna dari Akses Remote Zero Trust
Zero trust bukanlah sebuah produk yang bisa Anda beli. Ini adalah sebuah filosofi arsitektur, yang paling sering dikaitkan dengan model yang diartikulasikan oleh analis Forrester Research, John Kindervag, pada tahun 2010. Prinsip intinya: jangan pernah percaya, selalu verifikasi (never trust, always verify). Tidak ada pengguna, perangkat, atau lokasi jaringan yang dipercaya begitu saja. Setiap permintaan akses dievaluasi secara individual berdasarkan identitas, kesehatan perangkat, konteks, dan kebijakan.
Secara praktis, arsitektur akses remote zero trust berbeda dari VPN dalam beberapa hal krusial:
| Dimensi | VPN Tradisional | Akses Remote Zero Trust |
|---|---|---|
| Model kepercayaan | Percaya setelah autentikasi di perimeter | Verifikasi berkelanjutan; tidak ada kepercayaan implisit |
| Cakupan akses | Akses tingkat jaringan | Akses tingkat aplikasi (mikro-segmentasi) |
| Visibilitas | Terbatas setelah terhubung | Pemantauan perilaku pengguna dan perangkat secara berkelanjutan |
| Eksposur jaringan | Pengguna bergabung dengan jaringan | Aplikasi disembunyikan; pengguna hanya terhubung ke sumber daya yang diizinkan |
| Kesiapan cloud | Membutuhkan backhauling atau split tunneling | Mendukung koneksi direct-to-cloud secara bawaan |
Dengan zero trust, jaringan itu sendiri menjadi kurang relevan. Seorang karyawan remote mengakses aplikasi tertentu melalui proksi atau broker yang sadar identitas (identity-aware). Mereka tidak pernah “bergabung” dengan jaringan perusahaan. Aplikasi itu sendiri tidak terlihat oleh siapa pun yang belum diotorisasi dan diverifikasi secara eksplisit. Hal ini secara dramatis mengurangi permukaan serangan.
Kerangka Kerja NIST untuk Zero Trust
Bagi perusahaan yang mencari panduan terstruktur, NIST Special Publication 800-207 (diterbitkan pada Agustus 2020) menyediakan kerangka kerja arsitektur zero trust yang netral terhadap vendor. Kerangka kerja ini mendefinisikan tiga pendekatan inti:
- Enhanced Identity Governance โ keputusan akses didorong oleh identitas dan kebijakan, sering kali menggunakan proksi yang sadar identitas.
- Micro-Segmentation โ segmentasi tingkat jaringan yang membatasi pergerakan lateral dengan menempatkan kontrol granular di sekitar beban kerja individual.
- Software-Defined Perimeter (SDP) โ infrastruktur jaringan disembunyikan dari pengguna yang tidak berwenang; akses dijembatani berdasarkan per-sesi.
Sebagian besar implementasi zero trust di dunia nyata menggabungkan elemen dari ketiganya. Poin utamanya bukanlah memilih salah satu, melainkan memahami komponen mana yang mampu mengatasi profil risiko spesifik Anda.
Menentukan Pilihan: VPN, Akses Remote Zero Trust, atau Pendekatan Hibrida
Di sinilah saya menolak pemikiran biner tersebut. Pertanyaannya bukanlah “VPN atau zero trust?” โ melainkan “di mana posisi kita saat ini, dan apa jalur paling bertanggung jawab untuk melangkah ke depan?”
Kapan VPN Masih Masuk Akal (Untuk Saat Ini)
Jika perusahaan Anda sangat bergantung pada on-premises โ sistem ERP lama, file server, aplikasi thick-client โ VPN tetap menjadi kebutuhan praktis. Solusi zero trust sangat unggul dalam menjembatani akses ke aplikasi modern berbasis web. Namun, solusi ini kurang elegan ketika sumber daya yang dimaksud adalah sistem akuntansi berusia 15 tahun yang membutuhkan koneksi jaringan langsung agar dapat berfungsi.
VPN juga masuk akal sebagai solusi jangka pendek ketika Anda membutuhkan kapasitas instan dan tim Anda tidak memiliki keahlian untuk mengimplementasikan arsitektur zero trust dengan aman. Model zero trust yang diimplementasikan dengan buruk dapat menciptakan hasil yang lebih fatal daripada VPN yang dikelola dengan baik.
Kapan Zero Trust Harus Menjadi Prioritas
Jika lingkungan IT Anda didominasi oleh cloud โ aplikasi SaaS, beban kerja IaaS, aplikasi web modern โ akses remote zero trust harus menjadi strategi utama Anda. Manfaatnya berlipat ganda:
- Permukaan serangan yang berkurang: Aplikasi tidak terekspos ke internet. Pengguna hanya terhubung ke apa yang diizinkan untuk mereka akses.
- Pengalaman pengguna yang lebih baik: Tidak ada klien VPN yang perlu dikoneksikan. Perutean direct-to-cloud menghilangkan penalti latensi dari backhaul.
- Penilaian risiko berkelanjutan: Postur perangkat, perilaku pengguna, dan sinyal kontekstual dievaluasi di sepanjang sesi, tidak hanya saat login.
- Kepatuhan yang disederhanakan: Log akses yang granular memudahkan pembuktian akses dengan hak istimewa terendah (least-privilege access) kepada auditor.
Realitas Hibrida
Sebagian besar perusahaan yang bekerja sama dengan saya beroperasi dalam status hibrida โ dan akan terus demikian untuk beberapa waktu ke depan. Mereka memiliki sistem lama (legacy) yang membutuhkan akses tingkat jaringan berdampingan dengan alat SaaS modern yang lebih baik dilayani oleh zero trust. Pendekatan praktisnya adalah menjalankan keduanya, dengan peta jalan migrasi yang jelas.
Berikut adalah kerangka kerja yang saya gunakan saat menasihati klien:
- Inventarisasi aplikasi Anda โ kategorikan berdasarkan model penerapan (on-prem, IaaS, SaaS), tingkat sensitivitas, dan populasi pengguna.
- Identifikasi kandidat migrasi bernilai tinggi โ aplikasi berbasis cloud dengan basis pengguna yang luas akan mendapatkan manfaat terbesar dari penerapan zero trust di awal.
- Pertahankan VPN untuk akses sistem legacy โ tetapi batasi cakupannya. Segmentasikan akses VPN sehingga pengguna hanya menjangkau sistem legacy spesifik yang mereka butuhkan.
- Terapkan identitas sebagai control plane โ terlepas dari penggunaan VPN atau zero trust, manajemen identitas yang kuat (MFA, akses bersyarat, kepatuhan perangkat) adalah hal yang tidak bisa ditawar.
- Tetapkan garis waktu penghentian (sunset timeline) โ VPN harus menjadi pengecualian, bukan aturan. Tentukan pencapaian (milestones) untuk memigrasikan beban kerja dan menghentikan ketergantungan pada VPN.
Realitas Implementasi dan Kesalahan Umum
Saya ingin berterus terang tentang satu hal: zero trust secara konseptual memang elegan, tetapi secara operasional sangat menuntut. Perusahaan yang paling sering kesulitan adalah mereka yang memperlakukannya sebagai pembelian teknologi alih-alih perubahan arsitektur.
Kematangan identitas adalah prasyarat. Zero trust bergantung pada identitas yang andal dan konsisten. Jika infrastruktur identitas Anda terfragmentasi โ banyak direktori, penegakan MFA yang tidak konsisten, akun yatim (orphaned accounts) โ Anda harus memperbaikinya terlebih dahulu. Tidak ada solusi zero trust yang dapat mengkompensasi kekacauan identitas.
Visibilitas perangkat lebih penting dari yang Anda kira. Anda tidak dapat membuat keputusan kepercayaan tentang endpoint yang tidak dapat Anda lihat. Alat endpoint detection and response (EDR), mobile device management (MDM), dan pengesahan kesehatan perangkat (device health attestation) bersifat fundamental, bukan opsional.
Jangan meremehkan manajemen perubahan. Pengguna yang terbiasa dengan VPN akan memiliki banyak pertanyaan. Staf IT yang mengelola alat keamanan yang berpusat pada jaringan akan membutuhkan pelatihan ulang. Pemilik aplikasi harus berpartisipasi dalam definisi kebijakan. Ini adalah perubahan organisasional, bukan sekadar perubahan teknis.
Pemilihan vendor membutuhkan ketelitian. Pasar dibanjiri dengan branding “zero trust”. Setiap vendor CASB, SDP, ZTNA, dan SASE mengklaim label tersebut. Lakukan evaluasi berdasarkan prinsip-prinsip NIST 800-207, bukan sekadar teks pemasaran. Mintalah vendor untuk mendemonstrasikan bagaimana mereka menangani tantangan integrasi legacy spesifik Anda, bukan hanya skenario ideal (greenfield) mereka.
Pertanyaan yang Sering Diajukan (FAQ)
Apakah akses remote zero trust hanya untuk perusahaan berskala besar (enterprise)?
Tidak. Prinsip-prinsipnya berlaku pada skala apa pun. Faktanya, perusahaan yang lebih kecil dengan lingkungan yang didominasi cloud sering kali dapat mengadopsi zero trust lebih cepat karena mereka memiliki lebih sedikit ketergantungan pada sistem lama. Beberapa vendor menawarkan solusi zero trust network access (ZTNA) dengan model penetapan harga yang terjangkau bagi perusahaan pasar menengah. Persyaratan utamanya bukanlah ukuran perusahaan โ melainkan kematangan identitas dan pemahaman yang jelas tentang lanskap aplikasi Anda.
Dapatkah saya mengimplementasikan zero trust tanpa mengganti VPN saya saat ini?
Tentu saja, dan bagi sebagian besar perusahaan, ini adalah pendekatan yang direkomendasikan. Mulailah dengan merutekan akses ke aplikasi cloud melalui broker zero trust sambil mempertahankan VPN untuk sistem on-premises lama. Seiring berjalannya waktu, saat Anda memodernisasi atau mempensiunkan beban kerja lama, jejak VPN akan menyusut. Pendekatan bertahap ini mengurangi risiko dan menghindari disrupsi dari transisi total secara mendadak.
Bagaimana zero trust memengaruhi pengalaman pengguna akhir?
Jika diimplementasikan dengan baik, zero trust biasanya meningkatkan pengalaman pengguna. Pengguna terhubung langsung ke aplikasi tanpa harus meluncurkan klien VPN, menunggu pembuatan tunnel, atau berurusan dengan masalah split-tunneling. Autentikasi ditangani melalui single sign-on dan MFA adaptif. Gesekan operasionalnya menurun, bukan meningkat โ yang mana ini merupakan salah satu argumen terkuat untuk mendapatkan dukungan eksekutif.
Apa hubungan antara zero trust dan SASE?
Secure Access Service Edge (SASE), sebuah kerangka kerja yang dicetuskan oleh Gartner pada tahun 2019, menyatukan layanan jaringan dan keamanan ke dalam model yang dikirimkan melalui cloud. ZTNA adalah komponen dari SASE, berdampingan dengan SD-WAN, cloud access security brokers (CASB), dan firewall-as-a-service. Anggaplah SASE sebagai arsitektur yang lebih luas dan akses remote zero trust sebagai salah satu kemampuan intinya. Perusahaan yang mengejar SASE secara alami akan mengadopsi prinsip-prinsip zero trust, tetapi Anda tidak memerlukan penerapan SASE secara penuh untuk mulai mengimplementasikan ZTNA.
Ke Mana Arah Perkembangan Ini
Saya tidak berpikir VPN akan menghilang sepenuhnya โ setidaknya tidak dalam lima tahun ke depan. Terlalu banyak sistem kritis yang membutuhkan akses tingkat jaringan, dan rentang waktu migrasi untuk aplikasi lama diukur dalam hitungan tahun, bukan kuartal. Namun, arahnya sudah jelas.
Pandemi telah memadatkan satu dekade evolusi kerja remote menjadi enam bulan. Perusahaan yang telah berinvestasi dalam keamanan cloud-native yang berpusat pada identitas mampu menavigasi momen ini dengan hambatan yang jauh lebih sedikit. Mereka yang masih bergantung pada model berbasis perimeter akan merasakan tekanan yang sangat nyata.
Akses remote zero trust bukanlah sebuah tren. Ini adalah titik akhir logis dari model keamanan yang menyadari bahwa perimeter jaringan telah memudar. Pengguna Anda ada di mana-mana. Aplikasi Anda ada di mana-mana. Model keamanan Anda harus mengikuti realitas tersebut.
Rekomendasi saya: mulailah dengan identitas. Benahi MFA dan akses bersyarat Anda. Inventarisasi aplikasi Anda. Pilih dua atau tiga kandidat berdampak tinggi untuk ZTNA dan jalankan proyek percontohan (pilot) yang terkontrol. Pertahankan VPN untuk hal-hal yang masih membutuhkannya, tetapi berhentilah berinvestasi di dalamnya sebagai arsitektur jangka panjang Anda. Perusahaan yang menggunakan periode ini untuk membangun fondasi zero trust โ meskipun secara bertahap โ akan berada pada posisi yang jauh lebih baik untuk menghadapi apa pun yang akan terjadi selanjutnya.