PostgreSQL Row-Level Security (RLS): Membatasi Data Berdasarkan Pengguna

Dalam aplikasi multi-pengguna, membatasi akses ke tabel saja sering belum cukup. Dua pengguna mungkin sama-sama membutuhkan akses ke tabel orders, tetapi masing-masing hanya boleh melihat pesanan miliknya sendiri. Jika pembatasan hanya dilakukan di kode aplikasi, satu query yang lupa menyertakan filter pengguna dapat membuka data yang seharusnya privat.

Row-Level Security (RLS) pada PostgreSQL menyediakan lapisan kontrol akses di tingkat baris. Kebijakan RLS menentukan baris mana yang boleh dibaca, ditambahkan, diubah, atau dihapus oleh role database. Mekanisme ini membantu memperkuat desain keamanan aplikasi, tetapi tetap harus dipadukan dengan hak akses tabel, autentikasi, dan pengujian yang benar.

Apa itu Row-Level Security?

Secara normal, hak akses PostgreSQL melalui GRANT mengatur apakah suatu role boleh menjalankan operasi terhadap tabel atau kolom. RLS menambahkan aturan yang lebih rinci: baris tertentu dapat diizinkan atau ditolak berdasarkan kondisi, misalnya kolom user_id harus sesuai dengan identitas pengguna yang sedang menjalankan query.

RLS tidak menggantikan GRANT. Role tetap membutuhkan hak akses dasar seperti SELECT atau UPDATE. Setelah RLS diaktifkan, operasi terhadap baris juga harus memenuhi kebijakan yang berlaku. Jika RLS aktif tetapi tidak ada kebijakan yang mengizinkan operasi, PostgreSQL menerapkan pendekatan default-deny untuk akses baris biasa.

Contoh penerapan pada tabel pesanan

Misalkan aplikasi menyimpan pesanan dengan kolom owner_name. Contoh sederhana berikut menunjukkan cara mengaktifkan RLS dan mengizinkan setiap role melihat baris yang namanya cocok dengan role database saat ini.

CREATE TABLE orders (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  owner_name name NOT NULL,
  item text NOT NULL
);

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

GRANT SELECT ON orders TO app_user;

CREATE POLICY orders_read_own
ON orders
FOR SELECT
TO app_user
USING (owner_name = current_user);

Dalam contoh ini, kebijakan hanya berlaku untuk operasi SELECT oleh role app_user. Ekspresi pada USING dievaluasi untuk menentukan baris yang boleh terlihat. Baris milik role lain tidak akan muncul sebagai hasil query biasa bagi role tersebut.

Contoh ini cocok untuk menjelaskan konsep, tetapi aplikasi yang menggunakan satu akun database bersama untuk semua pengguna memerlukan desain identitas yang berbeda. current_user menunjukkan role database yang sedang aktif, bukan otomatis pengguna aplikasi yang sedang login.

Memahami USING dan WITH CHECK

RLS membedakan aturan terhadap baris yang sudah ada dan baris yang akan ditulis:

• USING menentukan baris yang boleh dipilih atau menjadi sasaran operasi seperti UPDATE dan DELETE.
• WITH CHECK menentukan apakah nilai baris baru yang akan dibuat atau dihasilkan oleh INSERT dan UPDATE memenuhi kebijakan.

Contohnya, kebijakan pemilik data dapat mencegah pengguna memindahkan pesanan milik orang lain ke akunnya sendiri melalui perubahan kolom pemilik. Jika WITH CHECK tidak ditulis, perilakunya bergantung pada jenis kebijakan dan aturan bawaan PostgreSQL; untuk desain sensitif, tuliskan maksud kebijakan secara eksplisit agar mudah diaudit.

CREATE POLICY orders_owner_update
ON orders
FOR UPDATE
TO app_user
USING (owner_name = current_user)
WITH CHECK (owner_name = current_user);

Beberapa kebijakan dapat berinteraksi

PostgreSQL dapat menerapkan lebih dari satu kebijakan pada tabel. Kebijakan permissive, yang merupakan jenis default, digabungkan dengan logika OR; kebijakan restrictive digabungkan dengan logika AND. Karena itu, menambahkan kebijakan baru tidak selalu memperketat akses: satu kebijakan permissive yang terlalu luas bisa membuka akses yang tidak diharapkan.

Tentukan role target dan operasi untuk setiap kebijakan. Hindari aturan umum untuk PUBLIC kecuali memang diperlukan. Dokumentasikan alasan setiap kebijakan, lalu uji gabungan seluruh kebijakan, bukan hanya memeriksa satu per satu.

Batasan dan kesalahan yang perlu dihindari

• Jangan mengandalkan RLS sebagai satu-satunya kontrol. Berikan hak tabel minimum melalui GRANT, pisahkan role aplikasi dan administrasi, serta lindungi kredensial database.
• Periksa role istimewa. Superuser dan role dengan atribut BYPASSRLS melewati kebijakan RLS. Pemilik tabel biasanya juga melewatinya, kecuali perilaku itu diubah dengan FORCE ROW LEVEL SECURITY.
• Hati-hati dengan koneksi bersama. Jika seluruh permintaan aplikasi memakai satu role database, kondisi current_user saja tidak membedakan pengguna akhir. Konteks identitas harus dirancang agar tidak bisa dipalsukan oleh input pengguna.
• Uji operasi tulis. Pastikan kebijakan melindungi INSERT, UPDATE, dan DELETE, bukan hanya pembacaan data.
• Perhatikan jalur khusus. Operasi seperti TRUNCATE tidak dikendalikan oleh kebijakan RLS, sehingga hak akses tabel tetap penting.

Checklist sebelum digunakan di produksi

1. Aktifkan RLS pada setiap tabel yang memuat data lintas pengguna atau tenant.
2. Buat kebijakan terpisah untuk operasi dan role yang memang dibutuhkan.
3. Uji dengan role aplikasi biasa, bukan hanya pemilik tabel atau superuser.
4. Tambahkan kasus negatif: pengguna A mencoba membaca, mengubah, atau menghapus baris milik pengguna B.
5. Audit kebijakan setelah perubahan skema dan sertakan pengujian RLS dalam pipeline pengembangan.

Dokumentasi resmi PostgreSQL menjelaskan sintaks, kombinasi kebijakan, dan pengecualian RLS secara lebih lengkap: Row Security Policies.

Kesimpulan

PostgreSQL RLS membantu menegakkan pembatasan akses di tingkat baris langsung di database, sehingga mengurangi risiko data lintas pengguna terbuka akibat query aplikasi yang keliru. Manfaatnya paling terasa ketika kebijakan disusun berdasarkan prinsip hak akses minimum, diuji menggunakan role yang realistis, dan ditinjau bersama kontrol database lainnya. RLS bukan pengganti desain autentikasi yang aman, tetapi merupakan lapisan pertahanan tambahan yang kuat jika diterapkan dengan benar.