BYOD dan Akses Kontraktor: Mengamankan Perangkat yang Tidak Terkelola Melalui Peramban

Sebuah firma konsultan membutuhkan 200 kontraktor untuk mengakses SharePoint dan Salesforce internal selama enam bulan. Laptop pribadi mereka tidak dapat menginstal agen endpoint; pendaftaran MDM tidak mungkin dilakukan pada perangkat yang juga digunakan kontraktor untuk perbankan pribadi dan menyimpan foto keluarga; dan menyiapkan VDI untuk pengguna sementara akan melebihi anggaran proyek. Browser—aplikasi yang sudah terbuka di setiap laptop tersebut—adalah titik penerapan yang paling praktis yang Anda miliki. Panduan ini memandu para pemimpin keamanan melalui pendekatan bertahap untuk mengamankan akses BYOD dan kontraktor melalui kontrol berbasis browser, mulai dari prasyarat hingga kriteria keberhasilan yang dapat diukur.

Prasyarat: Hal-hal yang Perlu Anda Siapkan Sebelum Memulai

Sebelum mengonfigurasi kontrol akses berbasis browser untuk pengguna BYOD dan kontraktor, pastikan fondasi-fondasi ini sudah terpenuhi. Melewatkan langkah-langkah ini merupakan penyebab paling umum terhambatnya proses implementasi.

Infrastruktur identitas harus mendukung pengguna eksternal. Penyedia Identitas (IdP) Anda harus dapat menangani identitas federasi untuk kontraktor, bukan hanya karyawan. Bayangkan skenario di sebuah firma konsultan: manajer proyek mengirimkan petunjuk orientasi kepada 200 kontraktor pada hari Senin. Jika IdP Anda tidak dapat menerbitkan identitas dengan cakupan terbatas dan jangka waktu tertentu yang terikat pada domain eksternal, Anda akan menghabiskan waktu seminggu itu untuk menyiapkan akun secara manual—dan lupa mencabut aksesnya saat kontrak berakhir. NIST SP 800-46 Rev. 2 secara eksplisit membahas persyaratan keamanan untuk BYOD serta perangkat klien yang dikendalikan oleh kontraktor, mitra bisnis, dan vendor, dengan menekankan pentingnya mengamankan informasi sensitif yang disimpan di dan dikirimkan melalui perangkat-perangkat tersebut.

Inventarisasi aplikasi berdasarkan metode akses. Buat daftar aplikasi yang dibutuhkan oleh kontraktor, baik itu SaaS (dapat diakses melalui proxy forward atau reverse), aplikasi web internal (dapat diakses melalui ZTNA), maupun aplikasi klien tebal (thick client) lama (yang mungkin masih memerlukan VDI). Sebagian besar beban kerja kontraktor berpusat pada SaaS—seperti SharePoint, Salesforce, dan ServiceNow—sehingga penerapan kebijakan berbasis browser dapat diterapkan pada sebagian besar sesi.

Klasifikasi data untuk pemetaan kebijakan DLP. Jika Anda belum mengklasifikasikan apa saja yang termasuk dalam data sensitif pada aplikasi yang akan diakses oleh kontraktor, kebijakan DLP bisa jadi akan memblokir terlalu banyak hal atau justru tidak mendeteksi apa pun. Setidaknya, tentukan pemicu kebijakan untuk PII, catatan keuangan, dan kekayaan intelektual.

Keputusan terkait arsitektur jaringan. NIST SP 800-46 merekomendasikan agar organisasi mempertimbangkan penggunaan solusi kontrol akses jaringan yang memverifikasi status keamanan perangkat klien sebelum mengizinkannya mengakses jaringan internal, serta mempertimbangkan penggunaan jaringan terpisah untuk semua perangkat klien eksternal, termasuk perangkat BYOD dan perangkat yang dikendalikan pihak ketiga. Untuk akses berbasis peramban, hal ini berarti mengalihkan seluruh lalu lintas perangkat yang tidak dikelola melalui platform SSE Anda, alih-alih memberikan akses jaringan langsung.

Tahap 1: Menetapkan Visibilitas dan Kebijakan Dasar dengan CASB dan SWG

Mulailah dengan menjawab pertanyaan paling mendasar: apa sebenarnya yang dilakukan perangkat yang tidak dikelola dalam aplikasi SaaS Anda saat ini?

Terapkan CASB dalam mode proxy terbalik untuk mencegat sesi dari perangkat yang tidak dikelola yang mengakses aplikasi SaaS yang diizinkan. Proksi terbalik tidak memerlukan agen—kontraktor cukup melakukan otentikasi melalui IdP Anda dan secara transparan diarahkan melalui titik penegakan CASB. Dalam skenario perusahaan konsultan, ketika seorang kontraktor masuk ke Salesforce dari MacBook pribadinya, CASB mendeteksi sesi tersebut, mengklasifikasikan perangkat sebagai perangkat yang tidak dikelola berdasarkan tidak adanya sertifikat klien, dan menerapkan kebijakan perangkat yang tidak dikelola Anda: akses baca saja ke catatan peluang, tidak ada ekspor massal, dan penandaan air pada tampilan layar.

Secara bersamaan, alirkan lalu lintas web dari para pengguna ini melalui SWG Anda untuk menerapkan kebijakan penggunaan yang dapat diterima, memblokir akses ke kategori berisiko tinggi, dan memindai unduhan untuk mendeteksi malware. SWG merupakan garis pertahanan pertama Anda terhadap seorang kontraktor yang mengklik tautan phishing di tab email pribadinya saat juga sedang masuk ke SharePoint perusahaan Anda.

Apa saja yang perlu diukur pada tahap ini:

Jumlah sesi perangkat yang tidak dikelola yang terdeteksi per hari

Aplikasi SaaS yang diakses oleh perangkat yang tidak dikelola (penemuan SaaS bayangan)

Pelanggaran kebijakan yang diblokir (unduhan massal, akses aplikasi tanpa izin)

Waktu rata-rata sejak permohonan pendaftaran kontraktor hingga akses operasional

Fase ini memberi Anda data telemetri yang dapat digunakan untuk membenarkan investasi pada fase-fase berikutnya. Jika CASB Anda menunjukkan bahwa kontraktor mengunduh daftar pelanggan ke perangkat pribadi mereka setiap minggu, maka dasar pertimbangan bisnis untuk Fase 2 sudah jelas dengan sendirinya.

Tahap 2: Menambahkan Remote Browser Isolation Sesi yang Sangat Sensitif

Setelah visibilitas tercapai, langkah selanjutnya adalah menghilangkan endpoint sepenuhnya sebagai vektor ancaman bagi aplikasi-aplikasi Anda yang paling sensitif. Di sinilah remote browser isolation menjadi langkah pengendalian terkuat yang tersedia untuk perangkat yang tidak dikelola.

Bayangkan skenario praktis berikut: seorang kontraktor di firma konsultan perlu meninjau catatan pelanggan di Salesforce yang berisi PII—nama, alamat, dan nilai transaksi. Dengan RBI, sesi Salesforce berjalan di dalam kontainer berbasis cloud. Kontraktor tersebut dapat melihat dan berinteraksi dengan aplikasi seperti biasa melalui browser Chrome atau Safari, tetapi tidak ada data aplikasi, token sesi, atau konten halaman yang pernah sampai ke perangkat lokal. Jika laptop pribadi kontraktor tersebut disusupi oleh keylogger atau program pencuri informasi, malware tersebut tidak akan mendapatkan data yang berguna karena sesi tersebut tidak pernah dijalankan secara lokal.

RBI juga memungkinkan pengendalian data secara terperinci di dalam sesi yang terisolasi. Anda dapat menonaktifkan fungsi salin-tempel, memblokir pencetakan, mencegah pengunduhan berkas, serta menerapkan tanda air dinamis yang menyematkan identitas pengguna ke dalam tangkapan layar. Saat sesi berakhir, wadah tersebut dihancurkan, sehingga tidak meninggalkan sisa data apa pun di perangkat yang tidak dikelola.

Pendekatan ini sejalan secara langsung dengan prinsip-prinsip zero trust. NIST SP 800-207 secara eksplisit mengakui bahwa perangkat yang terhubung ke jaringan mungkin tidak dimiliki atau tidak dapat dikonfigurasi oleh perusahaan, dan bahwa layanan yang dikontrak mungkin mencakup aset yang tidak dimiliki perusahaan yang memerlukan akses jaringan untuk menjalankan fungsinya. RBI merupakan implementasi praktis dari prinsip ini: Anda memberikan akses aplikasi tanpa mempercayai perangkat tersebut.

Kapan sebaiknya menggunakan proxy RBI dibandingkan dengan proxy CASB standar:

Kapan Harus Menggunakan Proksi RBI vs Proksi CASB Standar

Fase 3: Memperluas ZTNA untuk Aplikasi Pribadi

Aplikasi SaaS hanyalah sebagian kecil dari gambaran keseluruhan. Banyak proyek yang melibatkan kontraktor memerlukan akses ke aplikasi web internal—seperti portal khusus, wiki internal, dan lingkungan pengembangan—yang tidak terhubung ke internet.

VPN tradisional memberikan akses terowongan di tingkat jaringan kepada para kontraktor ke lingkungan Anda, yang melanggar setiap prinsip dalam pedoman Zero Trust. Jika salah satu dari 200 kontraktor tersebut memiliki malware di laptop pribadinya dan Anda telah memberikan akses VPN kepadanya, malware tersebut dapat memindai jaringan internal Anda, mencoba melakukan pergerakan lateral, dan menjangkau sistem-sistem yang jauh melampaui cakupan yang seharusnya bagi kontraktor tersebut.

ZTNA / Private Access VPN dengan akses berbasis aplikasi. Kontraktor melakukan otentikasi, kemudian mesin kebijakan mengevaluasi identitas, konteks perangkat, dan sinyal risiko mereka, lalu memberikan akses hanya ke aplikasi internal tertentu yang diizinkan sesuai peran mereka—tidak ada yang lain. Kontraktor tidak pernah melihat atau mengakses jaringan yang mendasarinya.

Tahapan kematangan dalam Model Kematangan Zero Trust CISA memungkinkan organisasi untuk menilai, merencanakan, dan mempertahankan investasi yang diperlukan guna bergerak menuju penerapan zero trust melalui lima pilar: Identitas, Perangkat, Jaringan, Aplikasi dan Beban Kerja, serta Data. Peralihan dari VPN ke ZTNA untuk akses kontraktor merupakan langkah yang dapat diukur dari tingkat kematangan “Tradisional” ke “Awal” pada kedua pilar Perangkat dan Jaringan.

Dalam skenario perusahaan konsultan, ZTNA berarti kontraktor Jane dapat mengakses portal pelacakan proyek internal dari laptop pribadinya di rumah, tetapi ia tidak dapat memindai jaringan, mengakses pengontrol domain, atau berpindah ke aplikasi keuangan. Jika kontraknya berakhir pada hari Jumat, aksesnya dicabut di lapisan aplikasi—tidak perlu repot mengurus sertifikat VPN, tidak perlu membersihkan aturan firewall.

Mengapa VDI dan MDM Tidak Cukup Efektif untuk Akses BYOD dan Kontraktor

Para pemimpin bidang keamanan sering kali mengevaluasi VDI dan MDM sebelum mempertimbangkan pengendalian berbasis peramban. Keduanya memiliki kasus penggunaan yang sah, tetapi tidak ada yang cocok untuk populasi perangkat yang tidak dikelola, bersifat sementara, dan dalam jumlah besar.

VDI (Virtual Desktop Infrastructure): VDI menciptakan lingkungan desktop terpusat di server, yang mengalirkan sesi visual ke perangkat pengguna. Teknologi ini sangat cocok untuk lingkungan yang sangat diatur dan memerlukan aplikasi klien tebal. Namun, untuk 200 kontraktor yang mengakses aplikasi SaaS selama enam bulan, VDI terlalu berlebihan. Solusi VDI yang dihosting di cloud biasanya dikenakan biaya puluhan dolar per pengguna per bulan, sedangkan VDI di lokasi sendiri memerlukan modal yang besar untuk server, jaringan, dan perangkat lunak virtualisasi. Untuk proyek yang melibatkan 200 kontraktor, total biaya langganan VDI saja dapat mencapai puluhan ribu dolar selama enam bulan—belum termasuk biaya infrastruktur, lisensi, dan biaya overhead dukungan. VDI juga menimbulkan latensi, gangguan sesi, dan waktu orientasi yang lama, yang membuat pengguna frustrasi dan menurunkan produktivitas.

MDM (Mobile Device Management): MDM mengharuskan pemasangan profil manajemen pada perangkat pribadi kontraktor, yang memberikan organisasi kendali atas pengaturan perangkat, kemampuan untuk menghapus data dari jarak jauh, serta visibilitas terhadap aplikasi yang terpasang. Sebagian besar kontraktor akan menolak. Perangkat mereka adalah milik pribadi; mereka menggunakannya untuk perbankan, email pribadi, dan foto keluarga. Meminta kontraktor untuk mendaftar ke MDM dapat menimbulkan gesekan hukum, keberatan terkait privasi, serta menunda proses onboarding selama beberapa hari atau minggu.

Kontrol berbasis browser (CASB + RBI + SWG + ZTNA): Tanpa agen, tanpa pendaftaran perangkat, tanpa infrastruktur yang perlu diskalakan. Kontraktor cukup membuka browser mereka, melakukan otentikasi melalui IdP Anda, dan kebijakan keamanan diterapkan di lapisan sesi. Waktu onboarding berkurang dari hitungan hari menjadi hitungan menit. Pasar keamanan BYOD mencerminkan pergeseran ini: pasar tersebut bernilai $60,64 miliar pada tahun 2025, dan diproyeksikan mencapai $120,36 miliar pada tahun 2032 dengan CAGR sebesar 10,28% (GII Research, 2026).

Tabel 2: Perbandingan VDI, MDM, dan Kontrol Berbasis Browser

Titik Integrasi: Menyesuaikan Keamanan Browser dengan Arsitektur yang Sudah Ada

Kontrol BYOD berbasis browser tidak beroperasi secara terpisah. Manfaatnya akan semakin besar jika diintegrasikan dengan infrastruktur keamanan yang sudah ada.

IdP dan akses bersyarat: IdP Anda (Azure AD, Okta, Ping) berperan sebagai penjaga gerbang. Konfigurasikan kebijakan akses bersyarat yang mendeteksi perangkat yang tidak dikelola—biasanya ditandai dengan tidak adanya sertifikat klien atau sinyal kepatuhan—dan secara otomatis mengalihkan sesi-sesi tersebut melalui proxy terbalik CASB atau RBI. Ketika seorang kontraktor masuk ke SharePoint dari perangkat yang tidak terdaftar, IdP harus secara otomatis menerapkan jalur akses yang lebih ketat tanpa intervensi manual.

Penyatuan kebijakan DLP: Kebijakan DLP yang sama yang melindungi data pada perangkat akhir yang dikelola harus juga mencakup sesi peramban dari perangkat yang tidak dikelola. Jika kebijakan DLP Anda memblokir ekspor massal catatan pelanggan bagi karyawan, kebijakan tersebut juga harus memblokirnya bagi kontraktor yang mengakses melalui RBI. Laporan IBM Cost of a Data Breach (2024) mengukur risiko tersebut: biaya rata-rata global akibat pelanggaran data mencapai $4,88 juta pada tahun 2024—naik 10% dari tahun sebelumnya, lonjakan terbesar sejak pandemi. Penerapan DLP yang konsisten di seluruh akses yang dikelola dan tidak dikelola mengurangi kemungkinan menjadi bagian dari statistik tersebut.

Integrasi SIEM dan UEBA: Salurkan log sesi dari CASB, RBI, dan ZTNA ke SIEM Anda untuk membangun patokan perilaku terkait aktivitas kontraktor. Jika seorang kontraktor yang biasanya mengakses 20 catatan Salesforce per hari tiba-tiba mengekspor 2.000 catatan, anomali tersebut seharusnya memicu peringatan. Visibilitas dan analitik merupakan salah satu dari tiga kemampuan lintas sektor dalam Model Kematangan Zero Trust CISA, dan telemetri tingkat sesi dari kontrol browser merupakan implementasi praktis dari kemampuan tersebut.

Otomatisasi proses offboarding: Saat kontrak dengan kontraktor berakhir, nonaktifkan identitas IdP mereka. Karena akses bersifat berbasis sesi dan diterapkan di lapisan proxy atau RBI, tidak ada sertifikat VPN yang perlu dicabut, tidak ada agen endpoint yang perlu dihapus, dan tidak ada profil perangkat yang perlu dihapus. Akses tersebut secara otomatis tidak berlaku lagi.

Metrik dan Kriteria Keberhasilan

Ukur hal-hal yang penting. Metrik-metrik ini menunjukkan apakah kontrol akses BYOD berbasis browser dan akses kontraktor Anda berfungsi dengan baik serta menjadi dasar untuk melanjutkan investasi.

Metrik operasional:

Waktu rata-rata hingga kontraktor mendapatkan akses: Mulai dari penyediaan identitas hingga sesi produktif pertama. Target: kurang dari 30 menit. Jika Anda mengukurnya dalam hitungan hari, proses ini perlu diperbaiki.

Volume sesi perangkat yang tidak dikelola: Jumlah total sesi per minggu dari perangkat yang diklasifikasikan sebagai perangkat yang tidak dikelola. Tren kenaikan diperkirakan terjadi seiring dengan meningkatnya tingkat adopsi; sementara tren penurunan saat jumlah tenaga kerja kontraktor tetap stabil mengindikasikan adanya penyimpangan.

Tingkat pelanggaran kebijakan: Jumlah tindakan yang diblokir (unduhan, salin-tempel, akses aplikasi tanpa izin) per 1.000 sesi. Tingkat yang terus-menerus tinggi dapat menandakan bahwa kebijakan terlalu ketat atau bahwa komunikasi dengan pengguna kurang memadai.

Metrik keamanan:

Insiden sisa data nol: Jumlah kejadian kebocoran data yang dapat dilacak ke perangkat yang tidak dikelola. Targetnya adalah nol untuk sesi yang dilindungi RBI.

Tingkat deteksi Shadow SaaS: Jumlah aplikasi SaaS yang tidak disetujui yang diakses oleh perangkat yang tidak dikelola, sebagaimana terdeteksi oleh CASB. Metrik ini seharusnya menurun seiring waktu seiring Anda memperketat kebijakan SWG.

Insiden pencurian kredensial dari perangkat yang tidak dikelola: Serangan berbasis kredensial menyumbang 16% dari seluruh insiden pelanggaran keamanan dan membutuhkan waktu paling lama untuk diidentifikasi serta ditangani, yaitu hampir 292 hari (IBM, 2024). Fitur isolasi sesi RBI diharapkan dapat menekan angka pencurian kredensial akibat serangan berbasis browser hingga mendekati nol.

Metrik biaya:

Biaya per akses kontraktor: Bandingkan total biaya lisensi SSE untuk sesi perangkat yang tidak dikelola dengan biaya VDI yang setara. Selisihnya menjadi dasar pertimbangan Anda untuk memperbarui lisensi.

Volume tiket layanan bantuan terkait akses kontraktor: Kontrol berbasis browser seharusnya menghasilkan lebih sedikit tiket dukungan dibandingkan VDI atau MDM karena tidak ada perangkat lunak klien yang perlu diatasi masalahnya.

Kesalahan Umum

Memperlakukan semua perangkat yang tidak dikelola secara sama. Seorang kontraktor yang mengakses dokumentasi proyek yang tidak sensitif tidak memerlukan pengendalian yang sama dengan kontraktor yang menangani data pribadi pelanggan (PII). Penerapan RBI yang berlebihan pada setiap sesi akan meningkatkan biaya dan latensi. Gunakan pengelompokan berbasis risiko: proxy CASB untuk aplikasi dengan tingkat sensitivitas rendah, dan RBI untuk aplikasi dengan tingkat sensitivitas tinggi.

Melupakan data yang sedang dikirim antar aplikasi. Anda telah membatasi akses ke Salesforce dengan RBI, tetapi kontraktor masih dapat menyalin nama pelanggan dari Salesforce, menempelkannya ke alat AI generatif di tab sebelah, dan mendapatkan respons yang mencakup data yang diperkaya. Padukan RBI dengan kebijakan SWG yang membatasi akses ke alat AI generatif dari sesi perangkat yang tidak dikelola—atau alihkan akses ke alat AI melalui isolasi juga. Skyhigh menguraikan kontrol tambahan untuk skenario ini dalam panduannya mengenai perlindungan aplikasi cloud dari perangkat yang tidak dikelola.

Mengabaikan alur kerja offboarding. Proses pemberian akses selalu menjadi fokus utama; sementara pencabutan akses hanya mendapat catatan kecil. Otomatiskan pemicu offboarding yang terikat dengan tanggal berakhirnya kontrak di sistem SDM atau pengadaan Anda. Seorang kontraktor yang masih memiliki akses tiga bulan setelah proyeknya berakhir merupakan ancaman internal, terlepas dari apakah ia bermaksud demikian atau tidak.

Mengabaikan komunikasi dengan pengguna. Para pekerja lepas yang baru pertama kali berurusan dengan RBI mungkin akan melaporkan bahwa “aplikasi ini terasa berbeda” atau bahwa fitur salin-tempel tidak berfungsi. Tanpa komunikasi proaktif yang menjelaskan alasan adanya kontrol-kontrol tersebut dan perilaku apa saja yang dibatasi olehnya, Anda akan menghadapi solusi alternatif yang dilakukan secara diam-diam—seperti para pekerja lepas yang mengirimkan data melalui email ke akun pribadi mereka untuk menghindari pembatasan unduhan.

Menerapkan kontrol peramban tanpa DLP. Isolasi peramban tanpa data loss prevention pintu yang terkunci namun jendelanya terbuka. RBI mencegah data mencapai perangkat, tetapi DLP memastikan bahwa data dalam sesi tersebut tidak dapat disalurkan keluar melalui saluran yang disetujui—seperti unggah ke akun penyimpanan awan pribadi, kirim email ke alamat non-perusahaan, atau cetak ke berkas PDF lokal. IBM menemukan bahwa 35% insiden pelanggaran melibatkan data bayangan—informasi yang disimpan di sumber data yang tidak dikelola (IBM, 2024)—yang menegaskan bagaimana pergerakan data yang tidak terkendali menimbulkan biaya dan risiko.

Menganggap satu model penerapan cocok untuk semua. Beberapa kelompok pengguna mungkin lebih diuntungkan dengan ekstensi browser yang ringan pada perangkat yang dikelola, sementara kontraktor menggunakan RBI tanpa agen. Sesuaikan pengaturan dengan kondisi perangkat dan jenis pengguna, alih-alih memaksakan satu pendekatan tunggal untuk seluruh tenaga kerja Anda.