Mengamankan Aplikasi SaaS Melalui Pengaturan di Tingkat Peramban

CASB Anda mencegah seorang kontraktor mengunduh daftar pelanggan dari Salesforce ke laptop yang tidak dikelola. Lima detik kemudian, kontraktor yang sama memilih seluruh tabel, menyalinnya ke clipboard, menempelkannya ke jendela penulisan email Gmail pribadinya, dan mengklik Kirim. CASB tidak pernah mendeteksinya. Browser-lah yang mendeteksinya — dan dengan kontrol yang tepat, hal itu bisa dicegah. Panduan ini memandu administrator keamanan SaaS dan operator CASB melalui pendekatan bertahap untuk menutup celah tersebut dengan menerapkan kontrol berlapis di tingkat browser — remote browser isolation (RBI), kebijakan secure web gateway SWG), DLP, dan tindakan sesi — di atas penerapan CASB yang sudah ada.

Prasyarat: Hal-hal yang Harus Disiapkan Sebelum Memulai

Sebelum mengaktifkan pengaturan di tingkat peramban, pastikan lingkungan Anda memenuhi empat syarat dasar. Mengabaikan syarat-syarat ini dapat menyebabkan konflik kebijakan, ketidaknyamanan pengguna, dan cakupan yang tidak lengkap.

1. CASB dengan mode proxy maju dan mundur telah diterapkan. Anda memerlukan pemeriksaan lalu lintas secara inline untuk aplikasi SaaS yang diizinkan (proxy mundur) dan visibilitas terhadap shadow IT (proxy maju) sebagai dasar penerapan kebijakan Anda. Jika penerapan CASB Anda hanya berbasis API, Anda tidak memiliki jalur inline yang disediakan oleh kontrol peramban.

2. Mesin kebijakan DLP terpadu. Kontrol di tingkat peramban harus merujuk pada klasifikasi data yang sama — PII, PHI, catatan keuangan, kode sumber, kekayaan intelektual — yang digunakan oleh CASB dan kebijakan DLP email Anda. Jika definisi DLP Anda tersimpan dalam silo terpisah, mulailah dengan mengonsolidasikannya. Klasifikasi yang tidak konsisten dapat menyebabkan satu saluran memblokir apa yang diizinkan oleh saluran lain. Platform DLP terpusat dapat menghindari fragmentasi ini.

3. Integrasi penyedia identitas (IdP) dan penilaian kondisi perangkat. Kontrol peramban menjadi jauh lebih berguna ketika disesuaikan berdasarkan identitas pengguna dan perangkat yang digunakannya. Seorang kontraktor pemasaran yang menggunakan MacBook pribadi seharusnya mendapatkan kontrol yang lebih ketat daripada seorang analis keuangan penuh waktu yang menggunakan perangkat Windows yang dikelola. Hal ini memerlukan federasi SAML/OIDC dengan IdP Anda serta pemeriksaan kondisi perangkat (terkelola vs. tidak terkelola, tingkat patch sistem operasi, status enkripsi disk).

4. Inventarisasi aplikasi SaaS beserta klasifikasi tingkat sensitivitasnya. Anda tidak dapat menentukan cakupan kebijakan browser tanpa mengetahui aplikasi SaaS mana saja yang menyimpan data sensitif. Kelompokkan 20–50 aplikasi SaaS teratas Anda berdasarkan tingkatan sensitivitas data (kritis, tinggi, sedang, rendah). Praktik Terbaik Tata Kelola SaaS dari CSA merekomendasikan untuk menilai risiko pada semua tahap siklus hidup SaaS — evaluasi, adopsi, penggunaan, dan penghentian. Inventarisasi ini menjadi masukan untuk menentukan cakupan kebijakan Anda.

Fase 1: Menutup Celah pada Clipboard dan Unduhan dalam Skenario Berisiko Tinggi

Mulailah dari area yang risikonya paling tinggi dan jumlah penggunanya paling sedikit: perangkat yang tidak dikelola yang mengakses aplikasi SaaS yang sensitif.

Skenario yang mendasari Fase 1: Seorang auditor pihak ketiga masuk ke instance Workday Anda dari laptop pribadinya menggunakan SSO. Proksi terbalik CASB Anda mengautentikasi sesi tersebut dan memblokir pengunduhan file sesuai kebijakan. Namun, auditor tersebut membuka laporan kompensasi karyawan, memilih tiga puluh baris data gaji, menyalinnya, membuka tab baru ke Google Sheet pribadinya, dan menempelkannya. CASB mendeteksi adanya sesi Workday yang terautentikasi dan sesi Google Sheets — dua peristiwa terpisah yang masing-masing diperbolehkan. CASB tidak pernah mendeteksi perpindahan data di antara keduanya karena operasi clipboard sepenuhnya terjadi di dalam konteks rendering browser.

Apa yang perlu diterapkan: Aktifkan remote browser isolation (RBI) remote browser isolation semua sesi perangkat yang tidak dikelola yang mengakses aplikasi SaaS Tingkat 1 (kritis) dan Tingkat 2 (tinggi). RBI menampilkan aplikasi SaaS dalam wadah yang dihosting di cloud dan hanya mengalirkan piksel ke browser pengguna. Arsitektur ini memberi Anda kendali terperinci atas tindakan dalam sesi:

Pembatasan salin/tempel: Blokir operasi baca/tulis clipboard dari sesi yang diisolasi, atau izinkan penempelan ke dalam tetapi blokir penyalinan ke luar untuk mencegah data keluar dari konteks aplikasi SaaS.

Pembatasan unduhan: Mencegah unduhan berkas sepenuhnya dari sesi yang ditampilkan, atau membatasi unduhan hanya pada jenis berkas tertentu.

Pemblokiran pencetakan: Nonaktifkan perintah cetak dan cetak ke PDF.

Tanda air pada tangkapan layar: Menyisipkan tanda air yang terlihat atau forensik yang berisi alamat email pengguna dan cap waktu ke dalam aliran data yang ditampilkan, guna mencegah pengambilan tangkapan layar.

NIST SP 800-53 SC 7 mewajibkan pemisahan komponen sistem dengan mekanisme perlindungan batas untuk mengendalikan aliran informasi dan membatasi potensi bahaya akibat serangan berbahaya serta kesalahan. RBI menciptakan batas tepat seperti ini antara data aplikasi SaaS dan perangkat lokal pengguna, serta menerapkan kontrol aliran informasi yang tidak dapat dilakukan oleh proxy jaringan.

Batasan cakupan: Terapkan pengendalian ini hanya pada perangkat yang tidak dikelola dan kelompok kontraktor pada Fase 1. Perangkat akhir yang dikelola yang telah dipasangi agen dan status keamanannya telah diverifikasi dapat dikenakan pengendalian yang lebih ringan (seperti penambahan tanda air tanpa pemblokiran papan klip) untuk menjaga produktivitas.

Fase 2: Memperluas Penerapan DLP pada Browser ke Perangkat Akhir yang Dikelola dan Cakupan SaaS yang Lebih Luas

Setelah Fase 1 stabil — biasanya setelah 4–6 minggu pengumpulan data telemetri dan penyempurnaan kebijakan — perluas cakupan ke perangkat yang dikelola dan rangkaian aplikasi SaaS yang lebih luas.

Skenario yang menjadi dasar Fase 2: Seorang perwakilan penjualan penuh waktu yang menggunakan laptop yang dikelola mengakses Salesforce melalui Chrome. Ia membuka catatan akun pelanggan, menyalin nama, nama perusahaan, dan nomor telepon kontak tersebut, lalu menempelkannya ke ChatGPT untuk membuat email pendekatan yang dipersonalisasi. Tidak ada file yang diunduh. Tidak ada aturan berbagi data Salesforce yang dilanggar. Namun, informasi pribadi pelanggan (PII) baru saja meninggalkan lingkungan SaaS yang Anda kendalikan dan masuk ke alat AI pihak ketiga melalui papan klip browser.

Menurut Laporan CSA tentang Kondisi Keamanan SaaS (2025), 63% organisasi melaporkan adanya pembagian data secara berlebihan ke pihak eksternal, dan 56% menyatakan bahwa karyawan mengunggah data sensitif ke aplikasi SaaS yang tidak sah — seringkali melalui jalur clipboard dan pengunggahan yang justru terlewatkan oleh mekanisme pengendalian tradisional. DLP tingkat peramban adalah mekanisme pengendalian yang mencegat tindakan-tindakan tersebut sebelum data mencapai tujuan yang tidak sah.

Apa yang akan diterapkan:

SWG menerapkan pemeriksaan DLP pada perangkat akhir yang dikelola. secure web gateway Anda mencegat lalu lintas browser dan menerapkan klasifikasi DLP pada data yang sedang dikirim — termasuk pengiriman data dari kolom formulir, peristiwa penyisipan dari clipboard ke aplikasi web, serta pengunggahan berkas melalui browser. Hal ini mendeteksi skenario pengiriman data dari Salesforce ke ChatGPT seperti yang dijelaskan di atas.

RBI selektif untuk kategori sensitif. Alih-alih memblokir seluruh aktivitas penjelajahan, alihkan sesi ke aplikasi SaaS Tier 1 dan Tier 2 melalui RBI ketika perilaku pengguna memicu sinyal risiko (misalnya, mengakses objek data pelanggan, membuka tampilan ekspor, atau membuka alat AI menggunakan kredensial perusahaan).

Penggunaan tanda air untuk mencegah perekaman sesi. Terapkan tanda air yang terlihat pada sesi yang menampilkan data sensitif sehingga, jika pengguna memotret layarnya, tanda air tersebut dapat melacak gambar tersebut kembali ke pengguna, sesi, dan cap waktu tertentu.

Prinsip perancangan kebijakan dari NIST SP 800-53 AC 4: Mekanisme penegakan akses dapat diterapkan pada tingkat aplikasi dan layanan untuk meningkatkan keamanan informasi serta mengendalikan aliran informasi melampaui apa yang dapat dicapai oleh pengendalian pada tingkat jaringan. DLP dan RBI pada tingkat peramban beroperasi tepat pada tingkat aplikasi dan layanan ini, sehingga menambahkan penegakan yang tidak dapat dijangkau oleh proxy CASB pada tingkat jaringan.

Fase 3: Mengintegrasikan Kontrol Peramban ke dalam Struktur Kebijakan SSE Anda

Menerapkan kontrol peramban sebagai lapisan tersendiri menimbulkan beban operasional: kebijakan terpisah, konsol terpisah, antrean insiden terpisah. Fase 3 menyatukan penegakan di tingkat peramban dengan Security Service Edge (SSE) Anda yang lebih luas sehingga satu mesin kebijakan mengatur keputusan terkait CASB, SWG, DLP, RBI, dan ZTNA.

Skenario yang mendasari Fase 3: SOC Anda menerima tiga peringatan: peringatan CASB bahwa seorang pengguna mengakses aplikasi SaaS bayangan, peringatan SWG bahwa sesi browser pengguna yang sama memicu kecocokan pola DLP, dan peringatan RBI bahwa penyalinan ke clipboard diblokir. Tiga konsol, tiga analis, tiga tiket — untuk satu pengguna yang melakukan satu rangkaian tindakan. Kebijakan SSE Terpadu menggabungkan semua ini menjadi satu peristiwa yang saling terkait dengan satu alur kerja respons.

Apa yang akan diterapkan:

Aturan kebijakan terpadu yang merujuk pada identitas pengguna, status perangkat, tingkatan sensitivitas aplikasi SaaS, klasifikasi data, dan jenis tindakan peramban (unduh, salin ke papan klip, cetak, unggah) dalam satu pernyataan bersyarat.

Isolasi adaptif yang secara otomatis meningkatkan tingkat keamanan sesi menjadi RBI penuh ketika platform SSE mendeteksi kombinasi sinyal — seperti perangkat yang tidak dikelola mengakses aplikasi Tier 1 sementara DLP mendeteksi konten sensitif di halaman tersebut.

Mengirimkan data telemetri sesi ke SIEM/SOAR agar peristiwa di tingkat peramban (pemblokiran papan klip, penyisipan tanda air, dan pencegahan unduhan) dapat ditampilkan bersamaan dengan peristiwa dari CASB, SWG, dan ZTNA untuk keperluan korelasi dan penyelidikan.

Model Kematangan Zero Trust dari CISA mengimbau organisasi untuk mengelola dan mengamankan aplikasi yang telah diterapkan dengan kontrol akses yang terperinci serta perlindungan ancaman yang terintegrasi, guna mencapai tingkat kematangan optimal di seluruh pilar Aplikasi & Beban Kerja serta Data. Mengintegrasikan kontrol tingkat peramban ke dalam kebijakan SSE adalah cara untuk menerapkan panduan tersebut pada aplikasi SaaS yang diakses melalui peramban.

Titik Integrasi: Di Mana Kontrol Browser Terhubung ke Arsitektur Aplikasi yang Sudah Ada

Pengaturan di tingkat peramban tidak menggantikan alat keamanan yang sudah ada — melainkan mengisi celah dalam penerapan antara alat-alat tersebut. Peta titik-titik integrasi dengan jelas untuk menghindari duplikasi dan memastikan cakupan yang menyeluruh.

Pertimbangkan skenario integrasi di dunia nyata: sebuah organisasi layanan kesehatan menggunakan mode API CASB untuk memindai PHI yang tersimpan di Box dan menerapkan kebijakan berbagi. Namun, ketika seorang perawat praktisi menggunakan tablet pribadinya untuk membuka dokumen pasien melalui browser, pemindaian API tersebut sudah berjalan — hal ini tidak akan mencegah penyalinan diagnosis pasien ke aplikasi pesan melalui clipboard. Sesi RBI dengan pembatasan clipboard dan penandaan air (watermarking) menutup celah tersebut tanpa memerlukan agen endpoint pada tablet pribadi tersebut. Pendekatan Skyhigh Security dalam melindungi aplikasi cloud dari perangkat yang tidak dikelola secara tepat menangani kasus penggunaan ini dengan menggabungkan reverse proxy, RBI, dan DLP dalam satu kebijakan terintegrasi.

Metrik dan Kriteria Keberhasilan

Kontrol di tingkat peramban menghasilkan data telemetri yang tidak dapat dihasilkan oleh penerapan CASB sebelumnya. Tetapkan metrik sebelum penerapan agar Anda dapat menunjukkan manfaatnya dan menyempurnakan kebijakan.

Metrik operasional (dipantau setiap minggu):

Peristiwa pemblokiran clipboard berdasarkan pengguna/aplikasi/jenis perangkat. Lonjakan jumlah pemblokiran clipboard pada pengguna tertentu dapat mengindikasikan adanya upaya pengambilan data secara ilegal atau menandakan bahwa kebijakan yang diterapkan terlalu ketat untuk alur kerja yang sah. Selidiki kasus-kasus yang menyimpang.

Peristiwa pemblokiran unduhan. Lacak berdasarkan aplikasi SaaS dan peran pengguna. Jumlah unduhan yang diblokir dalam jumlah besar dari suatu aplikasi tertentu mungkin menandakan bahwa pengguna memerlukan alternatif yang aman (misalnya, penampil yang hanya dapat dibaca atau alur kerja ekspor yang terkendali).

Tanda air memicu penyelidikan. Hitunglah berapa kali tangkapan layar atau dokumen cetak yang diberi tanda air dapat dilacak kembali ke pengguna melalui penyelidikan. Bahkan angka yang rendah pun membuktikan nilai pencegahannya.

Permintaan pengecualian kebijakan. Pantau jumlah pengguna yang mengajukan permintaan pengecualian terhadap pembatasan browser serta alasan yang dikemukakan. Volume permintaan pengecualian yang tinggi untuk suatu aplikasi tertentu mengindikasikan bahwa kebijakan tersebut perlu disempurnakan.

Metrik pengurangan risiko (dipantau setiap kuartal):

Penurunan jumlah insiden data sensitif yang melibatkan papan klip atau jalur unggahan pada layanan SaaS. Bandingkan volume insiden sebelum dan sesudah penerapan pengendalian peramban untuk aplikasi SaaS dan kelompok pengguna yang sama.

Cakupan pengendalian sesi perangkat yang tidak dikelola. Ukur persentase sesi SaaS pada perangkat yang tidak dikelola yang melewati RBI dibandingkan dengan yang melewatinya tanpa melalui RBI. Targetkan cakupan 95% atau lebih untuk aplikasi Tingkat 1.

Waktu rata-rata untuk mendeteksi upaya eksfiltrasi berbasis browser. Telemetri browser diharapkan dapat memperpendek waktu deteksi dari hitungan hari (jika hanya mengandalkan peringatan pemindaian DLP yang dilakukan setelah kejadian) menjadi hitungan detik (pemblokiran clipboard secara real-time).

Laporan DBIR Verizon 2025 menemukan bahwa 60% insiden kebocoran data melibatkan faktor manusia — yaitu tindakan pengguna yang mengklik, menyalin, mengunggah, dan menempel. Kontrol di tingkat browser menghasilkan data telemetri penegakan terhadap tindakan manusia ini secara tepat, sehingga memberikan visibilitas kepada SOC Anda terhadap vektor serangan yang sama sekali terlewatkan oleh kontrol jaringan dan API. Sementara itu, Forrester melaporkan bahwa sekitar satu dari lima pelanggaran data berasal dari insiden yang dilakukan oleh pihak internal (2026), dan kontrol sesi browser memberikan penegakan langsung dan real-time terhadap clipboard dan jalur unggahan yang paling sering dimanfaatkan oleh pihak internal.

Kesalahan Umum

Kesalahan 1: Menerapkan isolasi RBI penuh untuk semua pengguna sejak hari pertama. Isolasi streaming piksel penuh mengubah pengalaman menjelajah. Latensi sedikit meningkat, beberapa ekstensi browser berhenti berfungsi, dan aplikasi web yang kompleks mungkin ditampilkan secara berbeda. Jika Anda menerapkan ini kepada 5.000 karyawan secara bersamaan, tim bantuan teknis akan protes, dan pimpinan akan membatalkan proyek tersebut. Mulailah dengan perangkat yang tidak dikelola dan aplikasi berisiko tinggi. Perluas secara bertahap.

Kesalahan 2: Menerapkan kebijakan browser yang sama untuk perangkat yang dikelola dan yang tidak dikelola. Laptop kontraktor yang tidak dikelola memerlukan pemblokiran clipboard penuh dan pencegahan unduhan. Perangkat akhir perusahaan yang dikelola dengan agen, enkripsi disk yang terverifikasi, dan patch terbaru mungkin hanya memerlukan penandaan air (watermarking) serta pembatasan penempelan selektif. Bedakan kebijakan berdasarkan status perangkat. Profil risiko kredensial yang disusupi pada perangkat yang dikelola dengan EDR secara mendasar berbeda dari yang ada pada perangkat yang tidak dikelola tanpa visibilitas — kebijakan browser Anda harus mencerminkan perbedaan tersebut.

Kesalahan 3: Mengabaikan tujuan alat AI dalam kebijakan DLP. Banyak organisasi mengonfigurasi DLP browser untuk memblokir unggahan ke kategori shadow IT tradisional — penyimpanan cloud pribadi, webmail — namun lupa menyertakan asisten AI. Alat AI kini termasuk di antara tujuan tidak sah yang paling umum untuk data yang disalin dan diunggah. Perbarui kategori URL SWG dan DLP Anda untuk menyertakan layanan AI generatif, dan terapkan pembatasan clipboard dan unggahan yang sama seperti yang Anda terapkan pada aplikasi tidak sah lainnya.

Kesalahan 4: Memperlakukan kontrol browser sebagai proyek terpisah, bukan sebagai perluasan kebijakan SSE. Jika kontrol browser berada di konsol terpisah dengan kebijakan tersendiri, kontrol tersebut akan menjadi satu alat lagi yang diabaikan oleh SOC. Integrasikan kontrol tersebut ke dalam platform SSE Anda mulai dari Fase 3 ke depan agar peristiwa browser dapat dikorelasikan dengan peristiwa CASB, SWG, dan ZTNA dalam satu alur kerja insiden.

Kesalahan 5: Mengabaikan pengelompokan aplikasi SaaS berdasarkan tingkat sensitivitas sebelum menyusun kebijakan. Tanpa inventarisasi SaaS yang dikelompokkan berdasarkan tingkat sensitivitas, Anda bisa saja melakukan pemblokiran berlebihan (mengisolasi aplikasi berisiko rendah dan membuat pengguna frustrasi) atau pemblokiran yang kurang (membiarkan aplikasi kritis tanpa pengendalian). Perusahaan besar secara rutin menggunakan puluhan hingga ratusan layanan SaaS, dan pengelompokan ini bukanlah hal opsional — ini merupakan landasan kebijakan yang tepat sasaran untuk menghindari celah keamanan sekaligus mencegah protes pengguna.