Isolasi tenant di lapisan aplikasi punya satu kelemahan fatal: ia bergantung pada setiap developer mengingat menambahkan filter di setiap query, selamanya. Row-Level Security memindahkan aturan itu ke database, sehingga meski aplikasi lupa, PostgreSQL yang menolak. Ini jaring pengaman, bukan pengganti disiplin aplikasi.
Cara kerja RLS secara ringkas
Setiap tabel tenant mendapat policy: baris hanya terlihat jika kolom tenant-nya cocok dengan tenant di sesi saat ini. Tenant sesi di-set per transaksi lewat parameter (mis. SET LOCAL app.current_tenant_id), dan policy membacanya.
Karena SET LOCAL terikat ke transaksi, ia otomatis bersih saat transaksi selesai — tidak ada state yang bocor antar-request di connection pool. Ini detail kecil yang, kalau salah, justru menjadi sumber kebocoran baru.
RLS melengkapi, bukan menggantikan filter aplikasi
Aplikasi tetap membawa konteks tenant dan memfilter — itu jalur utama dan yang paling informatif untuk query planner. RLS adalah lapisan kedua: kalau suatu query lupa filter, database menolak alih-alih membocorkan.
Dua lapisan yang saling menutupi jauh lebih kuat daripada satu lapisan yang sempurna. Dan 'sempurna selamanya' bukan asumsi yang aman untuk kode yang disentuh banyak orang selama bertahun-tahun.
Uji kebocoran adalah bagian dari fitur
- Untuk setiap tabel tenant, tulis tes integrasi yang menyetel tenant A, lalu memastikan data tenant B tidak pernah terlihat lewat jalur apa pun.
- Uji juga jalur yang sering lolos: agregasi, join lintas tabel, dan laporan.
- Pastikan role aplikasi tidak punya BYPASSRLS; superuser dan pemilik tabel bisa melewati policy tanpa sadar.
- Perlakukan penambahan tabel tenant baru tanpa policy sebagai kegagalan build, bukan sekadar catatan.
Ringkasan
RLS mengubah isolasi tenant dari 'harap semua orang ingat' menjadi 'database yang menegakkan'. Pakai sebagai lapisan kedua di atas filter aplikasi, set tenant per transaksi, dan jadikan uji kebocoran syarat wajib setiap tabel baru.