🇬🇧 Read this article in English
TL;DR: Risiko SaaS sprawl adalah salah satu ancaman yang paling diremehkan oleh banyak organisasi saat ini. Ketika perusahaan mengadopsi perangkat cloud dengan kecepatan darurat selama setahun terakhir, sebagian besar kehilangan jejak tentang berapa banyak aplikasi yang sebenarnya mereka jalankan, siapa yang memiliki akses, dan data apa yang mengalir di antara aplikasi tersebut. Pemborosan finansialnya nyata, tetapi risiko keamanan dan kepatuhannya jauh lebih buruk. Untuk mengambil alih kendali, visibilitas adalah prioritas pertama, tata kelola kedua, dan kedisiplinan berkelanjutan adalah yang ketiga.
Shadow Cloud yang Tidak Pernah Dibicarakan Orang
Setiap eksekutif yang saya ajak bicara memahami strategi cloud mereka di tingkat makro. Mereka bisa menjelaskan tentang jejak AWS atau Azure mereka, peluncuran Office 365, hingga implementasi Salesforce. Namun, apa yang tidak bisa mereka jawab — dan di sinilah risiko SaaS sprawl menjadi berbahaya — adalah berapa banyak aplikasi SaaS yang sebenarnya sedang berjalan di seluruh organisasi mereka saat ini. Bukan aplikasi yang disetujui IT. Tapi jumlah aslinya.
Sebagian besar menebak angka yang rendah. Sangat rendah. Sebuah perusahaan skala menengah dengan 500 karyawan biasanya menjalankan sekitar 200 hingga 350 aplikasi SaaS yang berbeda. [Sumber: Productiv 2021 State of SaaS Report] Perusahaan besar (enterprise) dengan ribuan karyawan secara rutin melampaui angka 600. Ketika saya membagikan angka-angka ini kepada klien, reaksinya hampir selalu sama: tidak percaya, diikuti dengan kekhawatiran yang tertahan.
Kekhawatiran itu sangat beralasan. Selama lima belas bulan terakhir, urgensi untuk menjaga bisnis tetap berjalan di tengah pandemi membuat jalan pintas pengadaan (procurement shortcuts) tidak hanya ditoleransi — tetapi juga diperlukan. Tim pemasaran butuh alat kolaborasi baru. Tim keuangan butuh add-on untuk pelaporan. Tim HR butuh platform keterlibatan karyawan untuk tenaga kerja yang tersebar. Tim-tim ini mendaftar ke berbagai alat menggunakan kartu kredit, menyelesaikan masalah mendesak mereka, dan melanjutkan pekerjaan. Tidak ada yang pantas disalahkan atas hal itu. Namun, tagihannya — baik dari sisi finansial, operasional, maupun keamanan — kini mulai berdatangan.
Seperti Apa Sebenarnya Wujud SaaS Sprawl?
SaaS sprawl bukanlah sebuah kegagalan dramatis yang terjadi dalam semalam. Ini adalah akumulasi lambat dari keputusan-keputusan kecil dan rasional yang secara kolektif menciptakan hasil yang irasional. Inilah yang biasanya saya temukan ketika membantu organisasi mengaudit jejak SaaS mereka:
- Aplikasi redundan yang menyelesaikan masalah yang sama. Tiga alat manajemen proyek berbeda di empat departemen. Dua platform manajemen kontrak yang tidak terintegrasi satu sama lain. Workspace Slack dan tenant Microsoft Teams berjalan bersamaan karena tidak ada yang mengambil keputusan tegas.
- Langganan yatim piatu (Orphaned subscriptions). Lisensi masih aktif untuk karyawan yang sudah resign berbulan-bulan lalu. Akun trial yang otomatis berubah menjadi paket berbayar. Alat yang dibeli untuk proyek spesifik yang sudah selesai, tetapi langganannya tidak pernah dihentikan.
- Vendor yang tidak dievaluasi dengan akses ke data sensitif. Alat analitik versi gratis (free-tier) yang dihubungkan oleh analis junior ke database produksi. Platform desain yang menyimpan materi klien tanpa adanya perjanjian pemrosesan data. Layanan transkripsi AI yang memproses rekaman rapat rahasia.
- Tidak ada sumber kebenaran tunggal (single source of truth) untuk apa yang ada. IT melacak aplikasi yang mereka sediakan. Tim pengadaan (procurement) melacak aplikasi yang melalui purchase order (PO). Tidak ada yang mencatat alat yang didapat melalui laporan pengeluaran (expense reports), versi gratis, atau kartu kredit departemen.
Ini bukan skenario hipotetis. Ini adalah kenyataan yang saya temui di sebagian besar organisasi yang bekerja sama dengan saya, termasuk perusahaan yang dikelola dengan baik dan memiliki fungsi IT yang matang.
Memahami Risiko SaaS Sprawl yang Sebenarnya
Pemborosan finansial akibat SaaS sprawl paling sering mendapat sorotan, dan jumlahnya memang signifikan. Gartner memperkirakan bahwa 25% lisensi SaaS tidak digunakan atau kurang dimanfaatkan di perusahaan pada umumnya. [Sumber: Gartner 2020 IT Spending Forecast] Untuk perusahaan yang menghabiskan $2 juta setiap tahun untuk langganan SaaS, itu berarti $500.000 terbuang sia-sia. Bukan angka yang bisa diabaikan.
Namun, risiko finansial adalah bagian yang mudah. Anda menemukannya, Anda membatalkannya, Anda menghemat uang. Risiko yang lebih sulit adalah yang tidak muncul di neraca keuangan sampai ada sesuatu yang tidak beres.
Eksposur Keamanan
Setiap aplikasi SaaS adalah permukaan serangan (attack surface). Semuanya. Setiap alat yang dihubungkan karyawan ke data perusahaan menciptakan titik masuk potensial, jalur eksfiltrasi data potensial, dan potensi kompromi kredensial. Serangan Colonial Pipeline mengingatkan setiap eksekutif tentang apa yang terjadi ketika satu kredensial yang bocor bertemu dengan sistem yang tidak dipantau secara memadai. SaaS sprawl melipatgandakan risiko tersebut ke tingkat yang tidak dapat diukur secara akurat oleh sebagian besar tim keamanan — karena mereka tidak mengetahui ruang lingkup penuh dari apa yang mereka lindungi.
Pertimbangkan apa yang terjadi ketika seorang karyawan menghubungkan alat SaaS yang tidak disetujui ke penyedia identitas (identity provider) Anda menggunakan OAuth. Alat tersebut kini memiliki token yang memberikan akses berkelanjutan ke data spesifik, sering kali tanpa mengharuskan pengguna untuk melakukan autentikasi ulang. Jika vendor SaaS tersebut diretas — dan vendor kecil dengan anggaran keamanan terbatas adalah target utama — data Anda terekspos tanpa ada kegagalan dari sistem Anda sendiri.
Risiko Kepatuhan dan Regulasi
Jika organisasi Anda menangani data pribadi di bawah GDPR, UU PDP, HIPAA, atau kerangka regulasi lainnya, Anda perlu mengetahui di mana data tersebut berada. Setiap aplikasi SaaS yang memproses, menyimpan, atau mentransmisikan data yang diatur secara hukum harus didokumentasikan, dinilai, dan dikelola. Anda tidak dapat mematuhi persyaratan residensi data jika Anda tidak tahu bahwa data Anda sedang diproses di server dalam yurisdiksi yang belum Anda setujui. Anda juga tidak dapat merespons permintaan akses subjek data jika Anda tidak tahu sistem mana saja yang menyimpan data tersebut.
Saya pernah bekerja sama dengan sebuah perusahaan di sektor kesehatan tahun lalu yang menemukan, saat audit rutin, bahwa tim operasional telah menggunakan alat berbagi file tingkat konsumen (consumer-grade) untuk bertukar dokumen berisi informasi kesehatan yang dilindungi. Alat tersebut tidak memiliki BAA (Business Associate Agreement). Tidak ada enkripsi saat data diam (encryption at rest). Tidak ada audit logging. Eksposur ini bukanlah teori — ini adalah pelanggaran kepatuhan yang memerlukan notifikasi dan remediasi. Alat itu hanya memakan biaya $12 per bulan. Namun biaya remediasinya mencapai enam digit dolar.
Risiko Integrasi dan Integritas Data
Ketika beberapa alat menyelesaikan masalah yang sama, data menjadi terfragmentasi di berbagai sistem. Informasi pelanggan berada di tiga platform berbeda tanpa sinkronisasi. Data keuangan diekspor dari satu alat, dimanipulasi di spreadsheet, dan diimpor ke alat lain. Setiap perpindahan data (handoff) memunculkan kemungkinan kesalahan, penundaan, dan inkonsistensi.
Bagi siapa pun yang pernah bekerja dengan sistem keuangan — dan saya menghabiskan bertahun-tahun di dunia itu — hal ini seharusnya mengkhawatirkan. Integritas pelaporan keuangan bergantung pada sumber data yang otoritatif dengan input yang terkendali. SaaS sprawl merusak kendali tersebut di lapisan operasional, menciptakan masalah rekonsiliasi yang baru muncul selama siklus tutup buku dan audit.
Mengapa Ini Terjadi dan Mengapa Terus Bertahan
Menyalahkan karyawan karena mengadopsi alat baru adalah hal yang tidak produktif dan tidak akurat. SaaS sprawl adalah masalah struktural, bukan masalah perilaku. Hal ini terus bertahan karena beberapa faktor sistemik:
Proses pengadaan IT dirancang untuk era yang berbeda. Akuisisi perangkat lunak tradisional melibatkan evaluasi berbulan-bulan, proof of concept (PoC), negosiasi kontrak, dan penerapan. Vendor SaaS dengan sengaja merekayasa produk mereka untuk melewati proses tersebut. Uji coba gratis, pendaftaran mandiri (self-service), tagihan bulanan ke kartu korporat — hambatan-hambatan tersebut sengaja dihilangkan. Model tata kelola Anda harus memperhitungkan realitas tersebut, bukan melawannya.
Anggaran yang terdesentralisasi mengaburkan gambaran total. Ketika setiap departemen memiliki anggaran perangkat lunaknya sendiri, tidak ada yang mengagregasi total pengeluaran SaaS di tingkat organisasi. Tim keuangan hanya melihat item pengeluaran individual. Tim IT hanya melihat aplikasi yang mereka kelola. Kesenjangan di antara kedua pandangan itulah yang menjadi tempat berkembang biaknya sprawl.
Pandemi mempercepat adopsi tanpa tata kelola yang sepadan. Pada bulan Maret 2020, prioritas utamanya adalah bertahan hidup. Membuat orang bisa bekerja dari jarak jauh. Menjaga bisnis tetap berjalan. Alat-alat diadopsi hanya dalam hitungan hari, padahal biasanya butuh waktu berbulan-bulan untuk dievaluasi. Itu adalah keputusan yang tepat pada saat itu. Namun delapan belas bulan kemudian, solusi sementara tersebut telah menjadi perlengkapan permanen, dan tata kelolanya belum mampu mengejar ketertinggalan.
Kerangka Kerja untuk Mengambil Alih Kendali
Saya menggunakan pendekatan empat fase dengan klien yang menyeimbangkan antara ketelitian dan pragmatisme. Tujuannya bukan untuk menghentikan adopsi SaaS — itu akan menjadi kontraproduktif dan mustahil. Tujuannya adalah membuat sprawl terlihat, terkelola, dan terbatasi.
Fase 1: Penemuan dan Inventarisasi
Anda tidak dapat mengelola apa yang tidak dapat Anda lihat. Mulailah dengan membangun inventaris lengkap dari setiap aplikasi SaaS yang digunakan di seluruh organisasi. Ini membutuhkan beberapa sumber data:
- Data keuangan: Tarik setiap tagihan langganan dari kartu korporat, laporan pengeluaran, dan utang usaha (accounts payable) selama 12 bulan terakhir. Kategorikan berdasarkan vendor dan departemen.
- Log jaringan dan SSO: Analisis log lalu lintas jaringan dan catatan identity provider untuk mengidentifikasi aplikasi yang melakukan autentikasi terhadap direktori Anda. Alat seperti audit token OAuth di Google Workspace atau Azure AD dapat memunculkan aplikasi yang tidak Anda ketahui keberadaannya.
- Platform manajemen SaaS: Alat seperti Zylo, Productiv, atau Torii dapat mengotomatiskan penemuan dengan menggabungkan data keuangan, autentikasi, dan penggunaan. Untuk organisasi yang lebih besar, investasi ini akan cepat balik modal.
- Survei departemen: Minta setiap pimpinan tim untuk membuat daftar alat yang digunakan tim mereka. Ini akan menangkap aplikasi versi gratis (free-tier) yang tidak muncul dalam data keuangan atau jaringan.
Hasilnya harus berupa satu register terkonsolidasi: nama aplikasi, vendor, pemilik, biaya, jumlah pengguna, klasifikasi data, dan status persetujuan.
Fase 2: Penilaian Risiko dan Rasionalisasi
Dengan inventaris di tangan, nilai setiap aplikasi berdasarkan tiga dimensi:
| Dimensi | Pertanyaan Kunci |
|---|---|
| Nilai Bisnis | Apakah alat ini aktif digunakan? Apakah alat ini melayani fungsi yang tidak tercakup oleh platform yang sudah disetujui? Apakah menghapusnya akan menciptakan celah yang nyata? |
| Keamanan & Kepatuhan | Data apa yang diakses atau disimpan oleh alat ini? Apakah vendor memenuhi standar keamanan Anda? Apakah perjanjian yang diperlukan (DPA, BAA) sudah ada? |
| Efisiensi Biaya | Berapa biaya per pengguna? Apakah ada alat redundan yang bisa dikonsolidasikan? Apakah kita membayar lisensi yang tidak kita gunakan? |
Klasifikasikan setiap aplikasi ke dalam salah satu dari empat kategori: Pertahankan (disetujui dan dikelola), Konsolidasikan (redundan — migrasikan pengguna ke alat standar), Perbaiki (bernilai tetapi butuh perbaikan keamanan atau kepatuhan), atau Hentikan (batalkan dan hapus akses).
Fase 3: Implementasi Tata Kelola
Bangun kerangka tata kelola yang ringan yang memungkinkan adopsi sambil tetap mempertahankan kendali. Kebijakan kaku yang membutuhkan persetujuan berminggu-minggu untuk alat baru apa pun hanya akan mendorong shadow IT semakin dalam ke bawah tanah. Alih-alih demikian, pertimbangkan pendekatan bertingkat:
- Tier 1 — Katalog pra-persetujuan: Pertahankan daftar alat SaaS yang telah dievaluasi dan disetujui, yang dapat diadopsi siapa saja tanpa persetujuan tambahan. Ini memberi karyawan kecepatan dan pilihan dalam batas yang terkendali.
- Tier 2 — Tinjauan standar: Alat baru yang menangani data non-sensitif melalui proses tinjauan yang disederhanakan — kuesioner keamanan, pemeriksaan klasifikasi data, persetujuan biaya — dengan target penyelesaian lima hari kerja.
- Tier 3 — Penilaian penuh: Alat yang akan memproses data sensitif, teregulasi, atau keuangan memerlukan penilaian vendor komprehensif termasuk audit keamanan, tinjauan hukum, dan tinjauan arsitektur.
Kuncinya adalah membuat jalur yang benar menjadi jalur yang mudah. Jika alat yang disetujui berkualitas baik dan proses persetujuan Anda cepat, orang-orang akan menggunakannya.
Fase 4: Pemantauan dan Tinjauan Berkelanjutan
SaaS sprawl bukanlah masalah yang bisa Anda selesaikan sekali saja. Ini membutuhkan pemantauan terus-menerus. Tetapkan ritme kuartalan untuk meninjau register aplikasi, memeriksa data utilisasi, mengaudit pemberian akses OAuth baru, dan merekonsiliasi biaya langganan. Tetapkan kepemilikan — biasanya peran dalam manajemen aset IT atau kantor CIO — sehingga akuntabilitasnya jelas.
Pertanyaan yang Sering Diajukan (FAQ)
Bagaimana cara memperkirakan risiko SaaS sprawl kami saat ini jika kami belum pernah melakukan audit?
Mulailah dengan estimasi keuangan kasar. Tarik data kartu kredit dan laporan pengeluaran selama 12 bulan dan saring tagihan perangkat lunak yang berulang. Berdasarkan pengalaman saya, jumlah vendor SaaS yang berbeda akan dua hingga tiga kali lebih tinggi daripada yang telah didokumentasikan oleh IT. Kesenjangan itu adalah indikator risiko awal Anda. Gabungkan hal ini dengan audit token OAuth dari identity provider Anda untuk mengidentifikasi aplikasi yang melakukan autentikasi ke direktori Anda tanpa persetujuan formal. Dua titik data ini saja akan memberi Anda gambaran arah mengenai eksposur risiko dalam waktu seminggu.
Siapa yang harus memiliki kepemilikan atas tata kelola SaaS — IT, pengadaan, atau keuangan?
Ketiganya harus dilibatkan, tetapi kepemilikan harus berada di tangan IT, khususnya dalam manajemen aset IT atau kantor CIO. IT berada di posisi terbaik untuk menilai implikasi keamanan, integrasi, dan arsitektur. Tim pengadaan membawa keahlian manajemen kontrak dan vendor. Tim keuangan memberikan visibilitas pengeluaran dan penegakan anggaran. Kesalahan yang paling sering saya lihat adalah menyerahkan tata kelola hanya kepada tim pengadaan, yang cenderung mengoptimalkan biaya tetapi mengabaikan dimensi keamanan dan integritas data yang justru mewakili risiko terbesar.
Apakah SaaS sprawl terutama merupakan masalah perusahaan besar?
Tidak. Faktanya, perusahaan skala menengah (mid-market) sering kali menghadapi risiko relatif yang lebih tinggi karena mereka memiliki pola adopsi yang sama dengan enterprise, namun dengan sumber daya tata kelola yang lebih sedikit. Sebuah perusahaan dengan 200 orang dapat dengan mudah mengakumulasi 150 atau lebih langganan SaaS. Tanpa fungsi manajemen aset IT yang berdedikasi — yang umumnya tidak dimiliki oleh perusahaan skala menengah — sprawl sama sekali tidak terpantau. Pengeluaran SaaS per karyawan di organisasi skala menengah sering kali lebih tinggi daripada di enterprise, justru karena tidak ada negosiasi atau konsolidasi terpusat.
Haruskah kita melarang karyawan mendaftar alat SaaS secara mandiri?
Pembatasan menyeluruh adalah hal yang kontraproduktif. Hal itu memperlambat kerja tim dan mendorong adopsi lebih jauh ke dalam bayang-bayang. Pendekatan yang lebih baik adalah membuat katalog alat yang telah disetujui sebelumnya yang mencakup kebutuhan paling umum — kolaborasi, manajemen proyek, desain, analitik — dan memudahkan pengajuan penambahan alat baru. Padukan ini dengan kontrol teknis seperti pembatasan cakupan OAuth dan penegakan SSO untuk alat apa pun yang mengakses data perusahaan. Tujuannya adalah otonomi yang terarah, bukan pelarangan.
Waktu Bertindak adalah Sebelum Audit Berikutnya — atau Kebocoran Data Berikutnya
Risiko SaaS sprawl adalah masalah yang terus berlipat ganda. Setiap bulan yang berlalu tanpa visibilitas menambah lebih banyak aplikasi, lebih banyak eksposur data, lebih banyak pemborosan biaya, dan lebih banyak potensi celah kepatuhan. Organisasi yang akan berhasil menavigasi beberapa tahun ke depan adalah mereka yang memperlakukan portofolio SaaS mereka dengan ketelitian yang sama seperti mereka menerapkan kontrol pada infrastruktur, jumlah karyawan, dan keuangan.
Pandemi memaksa adopsi cloud yang cepat dan tidak terstruktur. Saat itu hal tersebut memang diperlukan. Namun, yang tidak diperlukan — dan tidak dapat diterima — adalah membiarkan postur darurat tersebut menjadi model operasi permanen. Alat-alat sudah tersedia untuk mendapatkan visibilitas. Kerangka kerja sudah ada untuk mengimplementasikan tata kelola. Yang dibutuhkan sekarang adalah keputusan eksekutif untuk memprioritaskannya.
Mulailah dengan inventaris. Anda mungkin tidak akan menyukai apa yang Anda temukan. Tetapi Anda akan berada dalam posisi yang jauh lebih baik daripada para eksekutif yang tidak pernah melihatnya sama sekali.
