0Pricing
SQL Academy · Pelajaran

Kebijakan Keamanan Tingkat Baris

Saring baris secara otomatis untuk setiap pengguna.

Kebijakan Keamanan Tingkat Baris adalah pelajaran SQL Academy gratis di CoddyKit. Ini adalah pelajaran 2 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar SQL Academy, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus SQL Academy mencakup 4 pelajaran total.

Apa Itu Keamanan Tingkat Baris?

Keamanan Tingkat Baris (RLS) adalah fitur PostgreSQL yang memungkinkan Anda mengatur baris mana dari sebuah tabel yang dapat dilihat atau diubah oleh pengguna atau peran basis data tertentu. Daripada menyaring baris dalam setiap kueri, Anda menentukan satu kebijakan, lalu PostgreSQL menerapkannya secara otomatis pada setiap SELECT, INSERT, UPDATE, dan DELETE.

Bayangkan fitur ini sebagai klausa WHERE yang tidak terlihat dan melekat pada tabel itu sendiri, bukan pada kueri tertentu.

Mengaktifkan RLS pada Tabel

RLS dinonaktifkan secara bawaan. Anda harus mengaktifkannya secara eksplisit untuk setiap tabel menggunakan ALTER TABLE ... ENABLE ROW LEVEL SECURITY. Setelah diaktifkan, peran apa pun yang bukan pemilik tabel tidak akan melihat baris apa pun sampai setidaknya satu kebijakan dibuat.

-- Create a sample table
CREATE TABLE orders (
  id        SERIAL PRIMARY KEY,
  owner     TEXT NOT NULL,
  amount    NUMERIC(10,2)
);

-- Enable RLS
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

Membuat Kebijakan Pertama Anda

Kebijakan dibuat dengan CREATE POLICY. Anda memberikan nama, menentukan tabel, dan menyediakan ekspresi USING. Klausa USING adalah ekspresi Boolean yang dievaluasi untuk setiap baris—hanya baris yang ekspresinya menghasilkan TRUE yang terlihat oleh pengguna.

-- Allow each user to see only their own orders
CREATE POLICY orders_owner_policy
  ON orders
  FOR SELECT
  USING (owner = current_user);

Klausa USING dan WITH CHECK

Kebijakan memiliki dua klausa penyaring dengan tujuan yang berbeda:

  • USING — menyaring baris pada operasi pembacaan (SELECT, UPDATE, DELETE). Sebuah baris hanya terlihat jika USING mengembalikan TRUE.
  • WITH CHECK — memvalidasi baris pada operasi penulisan (INSERT, UPDATE). Penulisan hanya diizinkan jika WITH CHECK mengembalikan TRUE. Jika dihilangkan, USING digunakan kembali untuk pemeriksaan penulisan.
-- Allow users to select and insert only their own rows
CREATE POLICY orders_isolation
  ON orders
  FOR ALL
  USING       (owner = current_user)
  WITH CHECK  (owner = current_user);

Cakupan Kebijakan: FOR SELECT, INSERT, UPDATE, DELETE

Satu kebijakan dapat mencakup semua perintah (FOR ALL) atau perintah tertentu. Memisahkan kebijakan berdasarkan perintah memberi Anda kontrol yang terperinci—misalnya, mengizinkan setiap pengguna membaca semua baris, tetapi hanya mengubah baris miliknya sendiri.

-- Everyone can read all orders
CREATE POLICY read_all_orders
  ON orders
  FOR SELECT
  USING (true);

-- But each user can only update their own orders
CREATE POLICY update_own_orders
  ON orders
  FOR UPDATE
  USING       (owner = current_user)
  WITH CHECK  (owner = current_user);

Menggunakan session_user dan current_user

PostgreSQL menyediakan fungsi bawaan untuk mengidentifikasi pengguna aktif di dalam ekspresi kebijakan:

  • current_user — peran yang hak istimewanya sedang aktif (dapat berubah setelah SET ROLE).
  • session_user — peran yang membuka koneksi (tidak pernah berubah selama sesi berlangsung).

Sebagian besar kebijakan RLS mengandalkan current_user karena mencerminkan peran efektif setelah penggantian peran.

-- Inspect the current identity inside a query
SELECT current_user, session_user;

Menerapkan RLS pada Peran Tertentu

Secara default, kebijakan berlaku untuk PUBLIC (semua peran). Anda dapat membatasinya ke peran tertentu menggunakan klausa TO. Ini berguna ketika Anda menginginkan satu kebijakan untuk pengguna biasa dan kebijakan lain untuk peran administrator.

-- Policy only for the 'app_user' role
CREATE POLICY app_user_policy
  ON orders
  FOR SELECT
  TO app_user
  USING (owner = current_user);

-- Separate permissive policy for 'admin' role
CREATE POLICY admin_full_access
  ON orders
  FOR ALL
  TO admin
  USING (true)
  WITH CHECK (true);

Kebijakan PERMISSIVE dan RESTRICTIVE

Beberapa kebijakan pada tabel yang sama dapat berinteraksi dengan dua cara:

  • PERMISSIVE (bawaan) — semua kebijakan PERMISSIVE digabungkan dengan OR. Sebuah baris dapat diakses jika salah satu kebijakan PERMISSIVE mengizinkannya.
  • RESTRICTIVE — kebijakan RESTRICTIVE digabungkan dengan hasil kebijakan PERMISSIVE menggunakan AND. Sebuah baris hanya dapat diakses jika lolos dari kebijakan RESTRICTIVE dan setidaknya satu kebijakan PERMISSIVE.
-- Restrictive policy: block access to archived orders for everyone
CREATE POLICY no_archived_rows
  ON orders
  AS RESTRICTIVE
  FOR SELECT
  USING (amount > 0);

Melewati RLS: BYPASSRLS dan Pemilik Tabel

Pemilik tabel dan pengguna super secara default melewati RLS dan selalu melihat semua baris. Anda dapat memberikan atribut BYPASSRLS kepada suatu peran jika peran tersebut memerlukan access tanpa batas tanpa menjadi pengguna super. Sebaliknya, Anda dapat memaksa pemilik untuk mematuhi RLS menggunakan FORCE ROW LEVEL SECURITY.

-- Force the table owner to also obey RLS policies
ALTER TABLE orders FORCE ROW LEVEL SECURITY;

-- Grant BYPASSRLS to a trusted service account
ALTER ROLE service_account BYPASSRLS;

Mengubah dan Menghapus Kebijakan

Anda dapat memperbarui kebijakan yang sudah ada dengan ALTER POLICY atau menghapusnya sepenuhnya dengan DROP POLICY. Menghapus semua kebijakan saat RLS masih diaktifkan berarti tidak ada baris yang dapat diakses oleh peran yang bukan pemilik. Untuk menghapus RLS sepenuhnya, nonaktifkan RLS dengan ALTER TABLE.

-- Rename a policy
ALTER POLICY orders_owner_policy ON orders
  RENAME TO user_isolation_policy;

-- Update the USING expression
ALTER POLICY user_isolation_policy ON orders
  USING (owner = current_user AND amount >= 0);

-- Remove a policy
DROP POLICY admin_full_access ON orders;

-- Disable RLS entirely on the table
ALTER TABLE orders DISABLE ROW LEVEL SECURITY;

Pola Dunia Nyata: Isolasi Data Multi-Penyewa

Pola RLS yang umum dalam aplikasi SaaS multi-penyewa menyimpan kolom tenant_id di setiap tabel dan menggunakan variabel tingkat sesi (set_config) untuk meneruskan pengenal penyewa saat koneksi dibuat. Kebijakan tersebut kemudian membandingkan tenant_id pada setiap baris dengan pengaturan itu.

-- Table with tenant isolation column
CREATE TABLE documents (
  id         SERIAL PRIMARY KEY,
  tenant_id  TEXT NOT NULL,
  title      TEXT
);

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

-- Policy reads the tenant from a session variable
CREATE POLICY tenant_isolation
  ON documents
  FOR ALL
  USING       (tenant_id = current_setting('app.tenant_id'))
  WITH CHECK  (tenant_id = current_setting('app.tenant_id'));

-- Application sets the variable before running queries
SELECT set_config('app.tenant_id', 'tenant_42', true);

-- Now only tenant_42 documents are visible
SELECT * FROM documents;

Uji Pengetahuan

Uji pemahaman Anda tentang kebijakan Keamanan Tingkat Baris di PostgreSQL.

Ringkasan Pelajaran

Dalam pelajaran ini, Anda mempelajari bagaimana Keamanan Tingkat Baris memberi Anda penyaringan baris otomatis berbasis kebijakan langsung pada tingkat basis data:

  • Enable RLS pada tabel dengan ALTER TABLE ... ENABLE ROW LEVEL SECURITY.
  • Gunakan CREATE POLICY dengan klausa USING untuk menyaring baris yang dapat dibaca dan klausa WITH CHECK untuk memvalidasi baris yang ditulis.
  • Batasi cakupan kebijakan ke perintah tertentu (SELECT, INSERT, UPDATE, DELETE, ALL) dan peran tertentu menggunakan klausa TO.
  • Gabungkan kebijakan PERMISSIVE (logika OR) dan RESTRICTIVE (logika AND) untuk kontrol access berlapis.
  • Pemilik tabel dan pengguna super secara default melewati RLS; gunakan FORCE ROW LEVEL SECURITY untuk menggantikan perilaku ini.
  • Pola multi-penyewa yang menggunakan current_setting() merupakan penerapan RLS dunia nyata yang sangat bermanfaat.

RLS adalah cara standar untuk menerapkan isolasi data secara rapi dan konsisten tanpa menyebarkan klausa WHERE ke setiap kueri aplikasi.

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Kebijakan Keamanan Tingkat Baris” gratis?

Ya — teks lengkap “Kebijakan Keamanan Tingkat Baris” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus SQL Academy, upgrade ke CoddyKit PRO. Kursus SQL Academy mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Kebijakan Keamanan Tingkat Baris”?

Saring baris secara otomatis untuk setiap pengguna. Kamu berlatih SQL Academy dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai SQL Academy?

Tidak diperlukan pengalaman sebelumnya. SQL Academy di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 2 dari 4.

Berapa lama pelajaran “Kebijakan Keamanan Tingkat Baris” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran SQL Academy ini?

Ya. Setiap pelajaran SQL Academy menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

  1. Peran dan Hak Istimewa
  2. Kebijakan Keamanan Tingkat Baris
  3. Izin Tingkat Kolom
  4. Mengaudit Akses
← Kembali ke SQL Academy