Pertanyaan pertama yang diajukan tim IT dan legal perusahaan ketika menilai SaaS keamanan biasanya bukan soal fitur, melainkan: "Kami menyimpan foto selfie personil, jejak GPS, dan data tamu di sistem Anda — bagaimana memastikan perusahaan lain tidak bisa melihatnya?" Artikel ini menjawabnya dari sisi teknis, sejelas mungkin.
Apa itu arsitektur multi-tenant?
Platform SaaS biasanya multi-tenant: banyak perusahaan (tenant) memakai infrastruktur dan aplikasi yang sama demi efisiensi biaya — harga per pelanggan jauh lebih murah daripada server terpisah untuk setiap klien.
Konsekuensinya, isolasi data menjadi tanggung jawab terpenting penyedia platform. Ada dua pendekatan umum:
- Isolasi di lapisan aplikasi — kode aplikasi "berjanji" memfilter data per tenant. Masalahnya: satu bug query bisa langsung membocorkan data lintas tenant.
- Isolasi di lapisan database — database engine sendiri yang menolak akses lintas tenant, apa pun yang terjadi di aplikasi.
Pendekatan kedua inilah yang dipakai Jagain melalui Row-Level Security (RLS) PostgreSQL.
Bagaimana Row-Level Security bekerja?
RLS adalah fitur bawaan PostgreSQL yang membuat database menolak baris data yang bukan milik tenant pengguna yang sedang aktif. Sederhananya, setiap tabel menyimpan kolom tenant_id, dan kebijakan (policy) memaksa setiap query menyaring berdasarkan nilai tersebut:
ALTER TABLE checkpoints ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON checkpoints
USING (tenant_id = current_setting('app.tenant_id')::uuid);
Dengan policy ini aktif, query SELECT dari tenant A secara fisik tidak bisa mengembalikan baris milik tenant B — PostgreSQL membuang baris tersebut sebelum hasil dikirim, terlepas dari bagaimana query ditulis.
Mengapa ini lebih kuat dari "filter di aplikasi"?
Bandingkan dua skenario kegagalan:
- Filter aplikasi: developer lupa menambahkan
WHERE tenant_id = ...pada satu query di satu layanan. Untuk vendor yang isinya ratusan endpoint, kesalahan kecil seperti ini pernah terjadi di industri — dan ketika terjadi, datanya benar-benar keluar. - RLS: bug yang sama terjadi, query tetap dieksekusi tanpa filter — namun database tetap mengembalikan nol baris milik tenant lain. Celahnya tidak pernah sampai ke data.
Prinsipnya sederhana: kesalahan manusia di kode hampir mustahil dihindari 100%, jadi lapisan terakhir pertahanan sebaiknya berada di tempat yang tidak bisa dilewati oleh kesalahan tersebut.
Lapisan pendamping RLS
RLS bukan satu-satunya pengaman. Isolasi data yang layak untuk operasional keamanan setidaknya terdiri dari:
- Enkripsi in-transit (TLS 1.3) — melindungi data saat berjalan dari aplikasi personil ke server.
- Enkripsi at-rest (AES-256) — melindungi foto selfie, dokumen tamu, dan log GPS yang tersimpan.
- Audit trail — setiap akses dan tindakan tercatat dengan aktor dan stempel waktu.
- Backup harian terenkripsi — salinan data tetap terlindungi dengan standar yang sama.
Pertanyaan yang layak Anda ajukan ke vendor SaaS manapun
Ketika menilai platform keamanan (atau SaaS B2B apa pun), pertanyaan-pertanyaan berikut akan memisahkan vendor yang serius dari yang belum:
- Apakah isolasi tenant ditegakkan di database, atau hanya di kode aplikasi?
- Bagaimana penanganan data biometrik (foto selfie) — dienkripsi, disimpan di mana, berapa lama?
- Apakah tersedia audit trail yang bisa kami minta saat insiden?
- Di mana lokasi penyimpanan data, dan bagaimana prosedur penghapusannya saat kontrak berakhir?
Penjelasan arsitektur keamanan Jagain menjawab keempatnya secara terbuka — karena kami percaya vendor keamanan seharusnya paling transparan soal keamanannya sendiri.
Kesimpulan
Multi-tenant bukan hal yang perlu ditakuti — justru membuat platform teruji dalam skala besar dengan biaya wajar. Yang perlu diperiksa adalah bagaimana isolasinya ditegakkan. Dengan PostgreSQL Row-Level Security, enkripsi menyeluruh, dan audit trail, data operasional keamanan Anda tetap menjadi milik Anda semata. Untuk detail teknis lebih lanjut, hubungi tim kami via halaman kontak.