Panduan Row-Level Security PostgreSQL 2026 untuk SaaS Multi-Tenant: Isolasi Data, Policy, dan Audit

Mengapa RLS Penting untuk SaaS Multi-Tenant

Dalam arsitektur multi-tenant, satu database melayani banyak pelanggan. Tantangan utamanya adalah isolasi data: tenant A tidak boleh melihat data tenant B. PostgreSQL menyediakan Row-Level Security (RLS) yang memfilter baris secara otomatis berdasarkan kebijakan, sehingga menjadi lapisan defense-in-depth di sisi database.

Dokumentasi resmi PostgreSQL menjelaskan bahwa ketika RLS diaktifkan, akses ke tabel akan default deny jika belum ada kebijakan yang mengizinkan. Ini membuat keamanan lebih eksplisit dan aman untuk aplikasi SaaS modern.

Konsep Dasar RLS yang Harus Dipahami

• ENABLE RLS: mengaktifkan enforcement kebijakan pada tabel.
• CREATE POLICY: mendefinisikan aturan baris yang boleh diakses.
• USING vs WITH CHECK: USING menentukan baris yang boleh dibaca, WITH CHECK menentukan baris yang boleh ditulis/diubah.
• FORCE RLS: memaksa owner tetap tunduk pada kebijakan.

Pola Implementasi yang Aman

1) Simpan tenant_id di setiap tabel tenant

Pastikan setiap tabel bisnis memiliki kolom tenant_id. Gunakan tipe UUID atau string konsisten agar mudah diaudit.

2) Set konteks tenant pada koneksi

Gunakan variabel sesi seperti SET app.tenant_id = '...' saat koneksi dibuat, lalu referensikan di kebijakan. Ini menjaga konsistensi di seluruh query.

3) Buat kebijakan SELECT dan WRITE terpisah

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_select
ON invoices FOR SELECT
USING (tenant_id = current_setting('app.tenant_id')::uuid);

CREATE POLICY tenant_write
ON invoices FOR INSERT, UPDATE
WITH CHECK (tenant_id = current_setting('app.tenant_id')::uuid);

Untuk contoh kebijakan yang siap pakai (misalnya per-user access), panduan RLS di Supabase memberikan pola yang mudah diadaptasi ke SaaS Anda.

Checklist Praktis untuk Produksi

• Aktifkan RLS di semua tabel tenant.
• Gunakan FORCE ROW LEVEL SECURITY bila perlu.
• Pastikan tenant_id selalu di-set saat request masuk.
• Audit kebijakan saat ada perubahan skema.

Kesalahan Umum yang Harus Dihindari

• Policy terlalu longgar (misalnya tidak memeriksa tenant_id).
• RLS tidak aktif pada tabel baru.
• Bypass akses melalui role dengan hak terlalu tinggi.

Audit dan Observability

RLS bukan pengganti logging. Simpan jejak akses data (siapa, tenant mana, dan kapan) agar investigasi insiden lebih cepat. Panduan arsitektur multi-tenant di Microsoft Azure juga menekankan pentingnya desain isolasi dan kontrol akses yang konsisten untuk SaaS skala besar.

Referensi dan Bacaan Lanjutan

• Dokumentasi resmi PostgreSQL tentang Row-Level Security (sumber utama).
• Panduan RLS di Supabase untuk contoh kebijakan praktis.
• Azure Architecture Center: panduan arsitektur multi-tenant.