Tidak ada server yang berhasil diambil alih. Tidak ada ransomware yang berjalan. Tidak ada akun administrator yang dicuri.

Seorang pelanggan hanya membuka halaman laporan seperti biasa.

Masalahnya, laporan yang muncul ternyata berisi informasi milik perusahaan lain.

Bagi aplikasi biasa, kondisi tersebut sudah merupakan insiden keamanan serius. Dalam arsitektur multi-tenant, dampaknya lebih mendasar karena sistem telah gagal menjaga batas yang seharusnya memisahkan satu pelanggan dari pelanggan lainnya.

Inilah salah satu persoalan penting dalam multi-tenant security. Keamanan tidak hanya ditentukan oleh kemampuan menjaga penyerang tetap berada di luar server. Sistem juga harus dapat memastikan pengguna yang sah tidak pernah memperoleh akses ke data tenant lain.

Satu record yang muncul pada akun yang salah sudah cukup untuk menunjukkan bahwa fondasi tenant isolation tidak bekerja sebagaimana mestinya.

Multi-Tenant Berdiri di Atas Kepercayaan terhadap Batas Data

Arsitektur multi-tenant banyak digunakan pada aplikasi SaaS karena memungkinkan sejumlah pelanggan menggunakan aplikasi dan infrastruktur yang sama secara efisien.

Model tersebut bukan masalah selama terdapat pemisahan yang konsisten antara satu tenant dan tenant lainnya.

Seorang pelanggan mungkin menggunakan server, service, aplikasi, atau bahkan database yang sama dengan pelanggan lain. Namun, mereka tetap memiliki satu ekspektasi yang tidak dapat ditawar: data dan resource miliknya tidak boleh tersedia bagi tenant lain.

Karena itu, keberhasilan arsitektur multi-tenant sebenarnya tidak hanya diukur dari efisiensi infrastruktur.

Ukuran yang jauh lebih penting adalah apakah batas kepemilikan data tersebut tetap dapat dipertahankan dalam setiap kondisi.

Ketika batas itu gagal, persoalannya bukan lagi sebatas bug aplikasi.

Kepercayaan terhadap arsitektur secara keseluruhan ikut dipertanyakan.

Pengguna yang Berhasil Login Belum Tentu Berhak atas Data yang Diterimanya

Authentication sering menjadi lapisan keamanan pertama yang diperhatikan.

Pengguna memasukkan username dan password. Sistem memverifikasi identitas. Setelah itu, role menentukan fitur yang dapat digunakan.

Namun, pada aplikasi multi-tenant, proses tersebut belum cukup.

Bayangkan seorang Finance Manager dari Perusahaan A berhasil login.

Role yang dimilikinya memang memberikan hak untuk membaca invoice. Secara fungsi, tidak ada yang salah.

Masalah muncul apabila aplikasi hanya memeriksa apakah ia memiliki izin untuk membaca invoice tanpa memastikan invoice tersebut milik Perusahaan A.

Perbedaannya terlihat sederhana, tetapi sangat penting.

Pertanyaan pertama adalah:

“Apakah pengguna ini boleh membaca invoice?”

Sedangkan tenant isolation harus menjawab pertanyaan kedua:

“Invoice milik tenant mana yang boleh dibaca pengguna ini?”

Authorization menentukan tindakan apa yang dapat dilakukan pengguna.

Tenant isolation menentukan batas kepemilikan resource yang dapat dikenai tindakan tersebut.

Keduanya saling berkaitan, tetapi bukan hal yang sama.

Satu Filter yang Terlewat Dapat Membuka Data Pelanggan Lain

Risiko tenant isolation sering muncul bukan karena mekanisme keamanan yang sangat kompleks gagal, tetapi karena perubahan kode yang terlihat kecil.

Bayangkan sebuah tabel invoice berisi transaksi dari banyak pelanggan.

Query normal mungkin dirancang untuk mencari data berdasarkan nomor invoice sekaligus tenant yang sedang aktif.

Ketika aplikasi dikembangkan lebih lanjut, developer melakukan optimasi dan hanya mencari berdasarkan nomor invoice.

Aplikasi tetap berjalan.

Database tidak mengalami gangguan.

Server juga tidak diretas.

Tetapi apabila nomor invoice milik tenant lain dapat dipanggil, satu lapisan penting dalam data isolation telah hilang.

Situasi seperti ini menunjukkan mengapa keamanan multi-tenant tidak boleh sepenuhnya bergantung pada asumsi bahwa setiap developer akan selalu mengingat tenant context pada setiap query.

Semakin besar aplikasi, semakin banyak endpoint, service, worker, dan integrasi yang perlu menjaga aturan yang sama.

Satu jalur yang terlewat dapat menjadi titik kebocoran.

Tenant ID Bukan Bukti bahwa Pengguna Memiliki Akses

Risiko serupa dapat muncul pada API.

Sebuah aplikasi mungkin menggunakan permintaan seperti:

/api/report?tenant_id=125

Pada kondisi normal, pengguna Tenant 125 akan mendapatkan laporannya sendiri.

Namun, apa yang terjadi ketika angka tersebut diganti menjadi 126?

Jika aplikasi menerima tenant ID dari request lalu langsung mempercayainya, seorang pengguna yang sudah terautentikasi mungkin dapat berpindah konteks ke tenant lain hanya dengan memanipulasi parameter.

Di sinilah terdapat perbedaan penting antara identifier dan authorization.

Tenant ID hanya memberi tahu sistem data mana yang diminta.

Tenant ID tidak membuktikan bahwa pengguna tersebut berhak mengaksesnya.

Server tetap perlu menghubungkan resource yang diminta dengan identity pengguna, tenant yang dimilikinya, serta hak akses yang berlaku.

Prinsip ini juga berlaku untuk identifier lain seperti customer ID, invoice ID, document ID, project ID, hingga file ID.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Dalam pengujian keamanan aplikasi, manipulasi identifier sering menjadi salah satu cara untuk mengevaluasi apakah kontrol akses benar-benar diterapkan berdasarkan kepemilikan resource, bukan sekadar keberhasilan login.

Kebocoran Antar-Tenant Tidak Selalu Terjadi di Database

Pembahasan tenant isolation sering terlalu berpusat pada database.

Padahal, data aplikasi modern dapat melewati banyak komponen sebelum akhirnya sampai kepada pengguna.

Informasi dapat tersimpan atau diproses melalui:

• API;
• cache;
• object storage;
• search engine;
• background worker;
• message queue;
• reporting engine;
• file export;
• analytics;
• notification service.

Artinya, query database yang sudah aman belum membuktikan seluruh sistem memiliki tenant isolation yang benar.

Misalnya, sebuah file laporan tersimpan di object storage dengan identifier yang mudah ditebak. Database mungkin sudah membatasi akses dengan benar, tetapi endpoint download dapat saja tidak melakukan pemeriksaan tenant.

Hasil akhirnya sama.

Pengguna Tenant A memperoleh dokumen Tenant B.

Batas data gagal bukan pada database, tetapi pada jalur lain yang sebelumnya dianggap aman.

Cache Bisa Membocorkan Data tanpa Database Melakukan Kesalahan

Caching digunakan untuk meningkatkan performa aplikasi.

Namun, mekanisme tersebut juga membutuhkan tenant context.

Bayangkan Tenant A membuka dashboard pendapatan.

Aplikasi menyimpan hasil perhitungan tersebut pada cache dengan nama:

dashboard-revenue

Beberapa saat kemudian Tenant B membuka halaman yang sama.

Jika cache key hanya ditentukan berdasarkan nama halaman tanpa membedakan tenant, aplikasi dapat memberikan hasil Tenant A kepada Tenant B.

Database tidak mengembalikan data yang salah.

Query bahkan mungkin tidak dijalankan karena data langsung berasal dari cache.

Namun dari perspektif pelanggan, hal tersebut tetap merupakan kebocoran informasi.

Contoh sederhana ini menunjukkan prinsip yang lebih besar:

Tenant isolation harus mengikuti data ke mana pun data tersebut bergerak.

Jika konteks tenant hanya dijaga pada controller atau database tetapi hilang ketika masuk ke cache, storage, worker, atau search engine, isolasi sistem sebenarnya belum lengkap.

Background Process Juga Harus Mengetahui Data Milik Siapa

Banyak aplikasi memindahkan pekerjaan berat ke background process.

Pembuatan laporan, pengiriman email, sinkronisasi data, ekspor dokumen, maupun pemrosesan transaksi sering dilakukan melalui message queue atau worker.

Masalah muncul ketika proses tersebut hanya menerima identifier pekerjaan.

Misalnya:

report_id = 78421

Worker kemudian mencari laporan berdasarkan ID tersebut tanpa membawa informasi tenant.

Selama ID selalu benar, sistem mungkin terlihat bekerja dengan baik.

Tetapi ketika terjadi kesalahan mapping, manipulasi input, atau bug pada proses sebelumnya, worker tidak mempunyai konteks tambahan untuk memastikan bahwa resource yang diproses memang milik tenant yang benar.

Karena itu, tenant context tidak boleh dianggap hanya sebagai bagian dari sesi pengguna.

Ia harus menjadi bagian dari aliran data sistem.

API perlu mengetahuinya.

Service perlu membawanya.

Database perlu memvalidasinya.

Worker juga perlu mempertahankannya.

Shared Database Tidak Otomatis Membuat Sistem Tidak Aman

Arsitektur multi-tenant sering dikaitkan dengan penggunaan database bersama. Kondisi ini terkadang menimbulkan kesan bahwa satu database untuk banyak tenant otomatis lebih berbahaya.

Tidak selalu demikian.

Model multi-tenant dapat dibangun dengan berbagai pendekatan, mulai dari resource yang sepenuhnya terpisah hingga resource bersama dengan pemisahan secara logis.

Masing-masing memiliki konsekuensi terhadap biaya, kompleksitas operasional, performa, dan keamanan.

Database bersama tetap dapat menggunakan mekanisme isolasi yang kuat apabila tenant context diterapkan secara konsisten.

Sebaliknya, database terpisah tidak otomatis menyelesaikan seluruh persoalan apabila application layer masih dapat menghubungkan pengguna dengan database tenant yang salah.

Persoalan utamanya bukan sekadar apakah resource digunakan bersama.

Persoalannya adalah:

apakah batas keamanan tetap bekerja ketika resource tersebut digunakan bersama?

Bug Kecil Bisa Berdampak kepada Banyak Pelanggan Sekaligus

Salah satu karakteristik penting sistem multi-tenant adalah codebase dan banyak komponen aplikasi digunakan oleh lebih dari satu pelanggan.

Hal tersebut memberikan efisiensi besar.

Namun, karakteristik yang sama juga dapat memperbesar dampak vulnerability.

Misalnya terdapat satu fungsi untuk mengambil data pelanggan.

Fungsi yang sama digunakan oleh 10 pelanggan.

Kemudian jumlahnya bertambah menjadi 100 pelanggan.

Setelah sistem berkembang, fungsi yang sama mungkin digunakan oleh ribuan tenant.

Jika terdapat kesalahan tenant isolation pada fungsi tersebut, vulnerability tidak hanya berkaitan dengan satu akun.

Potensi dampaknya dapat meluas ke banyak pelanggan sekaligus.

Inilah mengapa cross-tenant data leakage perlu dipandang berbeda dari bug fungsional biasa.

Kerusakan yang muncul tidak hanya berkaitan dengan data yang terekspos, tetapi juga tingkat kepercayaan setiap pelanggan terhadap platform.

Vulnerability Sederhana Dapat Berubah Menjadi Cross-Tenant Access

Sebuah endpoint mungkin menggunakan pola seperti:

/api/customers/1001

Pengguna kemudian mengubah identifier menjadi:

/api/customers/1002

Jika sistem memberikan data pelanggan lain tanpa pemeriksaan kepemilikan yang benar, vulnerability tersebut dapat berkaitan dengan kelemahan object-level authorization.

Namun konteks multi-tenant dapat meningkatkan dampaknya secara signifikan.

Jika Customer 1001 milik Tenant A dan Customer 1002 milik Tenant B, yang terjadi bukan sekadar perpindahan dari satu object ke object lain.

Batas organisasi telah dilewati.

Vulnerability telah berubah menjadi cross-tenant access.

Karena itu, severity kelemahan aplikasi tidak seharusnya hanya dinilai berdasarkan teknik yang digunakan untuk mengeksploitasinya.

Business context dan struktur data di belakangnya perlu ikut diperhitungkan.

Perubahan identifier yang hanya membutuhkan beberapa detik dapat menghasilkan konsekuensi keamanan yang sangat besar apabila berhasil membuka informasi milik organisasi lain.

Menguji Multi-Tenant dengan Satu Akun Memberikan Gambaran yang Terbatas

Pengujian aplikasi multi-tenant perlu mencerminkan struktur akses sebenarnya.

Jika penetration testing hanya dilakukan menggunakan satu akun administrator dari satu tenant, banyak vulnerability masih dapat ditemukan.

Namun, kemampuan untuk membuktikan apakah tenant isolation benar-benar bekerja menjadi terbatas.

Pengujian akan jauh lebih bermakna ketika tersedia beberapa kombinasi identity, misalnya:

Tenant A dengan role administrator.

Tenant A dengan role user.

Tenant B dengan role administrator.

Tenant B dengan role user.

Dari sana, penguji dapat membandingkan apakah resource dan tindakan yang tersedia sudah sesuai batas yang seharusnya.

Administrator Tenant A mungkin boleh melihat seluruh invoice Tenant A.

Namun, hak administrator tidak boleh memberinya akses terhadap invoice Tenant B.

User Tenant A mungkin hanya boleh melihat sebagian data dalam organisasinya sendiri.

User Tenant B tetap tidak boleh memperoleh resource Tenant A meskipun identifier-nya diketahui.

Pendekatan seperti ini membuat penetration testing tidak berhenti pada pertanyaan “apakah endpoint dapat diakses?”, tetapi berlanjut pada pertanyaan “siapa yang seharusnya dapat mengakses resource tersebut dan dalam konteks tenant mana?”

Tenant Isolation Dapat Rusak Lagi Setelah Aplikasi Diperbarui

Sebuah sistem yang aman hari ini belum tentu mempertahankan kondisi yang sama setelah beberapa bulan pengembangan.

Developer mungkin menambahkan endpoint baru.

Tim engineering mengganti ORM.

Query dioptimalkan agar lebih cepat.

Caching diperluas.

Fitur export ditambahkan.

Search engine baru diintegrasikan.

Bulk operation dibuat.

Setiap perubahan tersebut dapat memperkenalkan jalur baru yang harus mempertahankan tenant context.

Karena itu, tenant isolation tidak seharusnya menjadi kontrol yang hanya diuji sekali pada saat aplikasi pertama kali dibuat.

Ia harus menjadi aturan yang terus divalidasi ketika aplikasi berkembang.

Security testing dan authorization regression testing dapat membantu memastikan perubahan fitur tidak secara tidak sengaja membuka kembali jalur akses yang sebelumnya sudah ditutup.

Tenant Isolation Harus Menjadi Aturan yang Tidak Boleh Berubah

Salah satu pendekatan yang lebih kuat adalah memperlakukan tenant isolation sebagai invariant.

Artinya, ada satu kondisi yang harus selalu benar, terlepas dari perubahan fitur maupun arsitektur:

Resource milik Tenant A tidak boleh diberikan kepada identity Tenant B.

Kemudian seluruh komponen sistem mengikuti aturan tersebut.

Identity membawa tenant context.

API memvalidasi tenant.

Service mempertahankan context tersebut.

Database membatasi data berdasarkan tenant.

Cache membedakan data antar-tenant.

Storage membatasi kepemilikan file.

Background worker mempertahankan konteks pekerjaan.

Search engine melakukan filtering yang sesuai.

Logging juga memastikan data sensitif tenant tidak terbuka kepada pengguna yang tidak berhak.

Dengan pendekatan ini, tenant isolation tidak lagi menjadi kumpulan pemeriksaan terpisah yang harus diingat developer pada setiap fungsi.

Ia menjadi karakteristik keamanan sistem secara keseluruhan.

Server yang Tidak Diretas Belum Membuktikan SaaS Aman

Kita sering membayangkan kegagalan cybersecurity sebagai kejadian besar.

Server berhasil diretas.

Database dicuri.

Administrator account diambil alih.

Malware masuk ke infrastruktur.

Namun pada aplikasi multi-tenant, insiden yang sangat serius dapat dimulai dari sesuatu yang jauh lebih sederhana.

Seorang pelanggan membuka laporan dan melihat data milik perusahaan lain.

Tidak ada exploit yang rumit.

Tidak ada server yang perlu dikuasai.

Namun batas keamanan yang menjadi dasar kepercayaan terhadap platform sudah tidak lagi dapat diandalkan.

Karena itu, pertanyaan mengenai multi-tenant security seharusnya tidak berhenti pada:

“Apakah server aplikasi kami aman?”

Pertanyaan yang jauh lebih penting adalah:

“Dapatkah kami membuktikan bahwa setiap request, API, query, cache, file, worker, dan proses bisnis selalu mengetahui resource tersebut milik tenant yang mana?”

Sebab dalam arsitektur multi-tenant, kegagalan tidak harus dimulai ketika penyerang berhasil masuk ke server.

Kadang kegagalan sudah terjadi ketika sistem memberikan data yang benar kepada orang yang salah.

Uji Keamanan Aplikasi Multi-Tenant Bersama Fourtrezz

Aplikasi SaaS dan sistem multi-tenant memiliki pola risiko yang tidak selalu dapat ditemukan hanya melalui pengujian fungsi aplikasi.

Authorization, tenant isolation, API, business logic, konfigurasi, hingga hubungan antar-resource perlu diuji dari perspektif keamanan untuk memastikan pengguna tidak dapat keluar dari batas akses yang telah ditentukan.

Fourtrezz (PT Tiga Pilar Keamanan) menyediakan layanan cybersecurity untuk membantu perusahaan mengevaluasi risiko pada aplikasi dan infrastruktur melalui Penetration Testing dan Vulnerability Assessment. Fourtrezz juga memiliki kapabilitas cybersecurity lain yang mendukung perusahaan dalam memahami risiko keamanan sistem secara lebih menyeluruh.

Melalui penetration testing, pengujian dapat diarahkan bukan hanya untuk mencari vulnerability teknis, tetapi juga mengevaluasi authorization, manipulasi request, API security, business logic, dan potensi cross-tenant access yang mungkin tidak terlihat dalam pengujian fungsional biasa.

Bagi perusahaan yang mengembangkan SaaS, aplikasi internal multi-company, marketplace, platform B2B, maupun sistem dengan banyak organisasi dalam satu aplikasi, pengujian tenant isolation dapat menjadi bagian penting sebelum kelemahan tersebut berkembang menjadi kebocoran data pelanggan.

Hubungi Fourtrezz:
Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]