SQL Academy · Lektion

Sikkerhedspolitikker på rækkeniveau

Filtrér automatisk rækker pr. bruger.

Lektion 2 af 413 trin

Sikkerhedspolitikker på rækkeniveau er en gratis SQL Academy-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i SQL Academy, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. SQL Academy-kurset indeholder 4 lektioner i alt.

Hvad er sikkerhed på rækkeniveau?

Sikkerhed på rækkeniveau (RLS) er en PostgreSQL-funktion, der lader dig styre, hvilke rækker i en tabel en bestemt databasebruger eller rolle kan se eller ændre. I stedet for at filtrere rækker i hver forespørgsel definerer du en politik én gang, og PostgreSQL håndhæver den automatisk ved hver SELECT, INSERT, UPDATE og DELETE.

Tænk på det som en usynlig WHERE-klausul, der er knyttet til selve tabellen i stedet for til en bestemt forespørgsel.

Aktivering af RLS på en tabel

RLS er som standard deaktiveret. Du skal udtrykkeligt aktivere det for hver tabel med ALTER TABLE ... ENABLE ROW LEVEL SECURITY. Når det er aktiveret, ser enhver rolle, der ikke ejer tabellen, ingen rækker, før der er oprettet mindst én politik.

-- 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;

Oprettelse af din første politik

En politik oprettes med CREATE POLICY. Du giver den et navn, angiver tabellen og angiver et USING-udtryk. USING-klausulen er et boolesk udtryk, der evalueres for hver række — kun rækker, hvor udtrykket returnerer TRUE, er synlige for brugeren.

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

Klausulerne USING og WITH CHECK

Politikker har to filterklausuler, der tjener forskellige formål:

USING — filtrerer rækker ved læsehandlinger (SELECT, UPDATE, DELETE). En række er kun synlig, hvis USING returnerer TRUE.
WITH CHECK — validerer rækker ved skrivehandlinger (INSERT, UPDATE). En skrivehandling er kun tilladt, hvis WITH CHECK returnerer TRUE. Hvis den udelades, genbruges USING til skrivekontroller.

-- 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);

Politikkens anvendelsesområde: FOR SELECT, INSERT, UPDATE, DELETE

En enkelt politik kan dække alle kommandoer (FOR ALL) eller en bestemt kommando. Når du opdeler politikker efter kommando, får du finkornet kontrol — du kan for eksempel lade alle brugere læse alle rækker, men kun ændre deres egne.

-- 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);

Brug af session_user og current_user

PostgreSQL har indbyggede funktioner, der identificerer den aktive bruger i et politikudtryk:

current_user — rollen, hvis privilegier er aktive i øjeblikket (kan ændres efter SET ROLE).
session_user — rollen, der åbnede forbindelsen (ændres aldrig under sessionen).

De fleste RLS-politikker bruger current_user, fordi den afspejler den effektive rolle efter skift af rolle.

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

Anvendelse af RLS på bestemte roller

Som standard gælder en politik for PUBLIC (alle roller). Du kan begrænse den til en bestemt rolle ved hjælp af TO-klausulen. Det er nyttigt, når du vil have én politik for almindelige brugere og en anden for en administratorrolle.

-- 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);

Tilladende og begrænsende politikker

Flere politikker på den samme tabel kan fungere sammen på to måder:

PERMISSIVE (standard) — alle tilladende politikker kombineres med OR. En række er tilgængelig, hvis en hvilken som helst tilladende politik tillader det.
RESTRICTIVE — begrænsende politikker kombineres med AND med resultatet af de tilladende politikker. En række er kun tilgængelig, hvis den består den begrænsende politik og mindst én tilladende politik.

-- Restrictive policy: block access to archived orders for everyone
CREATE POLICY no_archived_rows
  ON orders
  AS RESTRICTIVE
  FOR SELECT
  USING (amount > 0);

Omgåelse af RLS: BYPASSRLS og tabelejere

Tabelejeren og superbrugere omgår som standard RLS og kan altid se alle rækker. Du kan tildele en rolle attributten BYPASSRLS, hvis den har brug for ubegrænset adgang uden at være superbruger. Omvendt kan du tvinge ejeren til at følge RLS ved hjælp af 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;

Ændring og sletning af politikker

Du kan opdatere en eksisterende politik med ALTER POLICY eller fjerne den helt med DROP POLICY. Hvis du sletter alle politikker, mens RLS stadig er aktiveret, har roller, der ikke er ejere, ingen adgang til rækker. Hvis du vil fjerne RLS helt, skal du deaktivere det med 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;

Praktisk mønster: Isolering af data for flere lejere

Et almindeligt RLS-mønster i SaaS-apps med flere lejere er at gemme en kolonne med tenant_id i hver tabel og bruge en sessionsvariabel (set_config) til at overføre lejeridentifikatoren, når forbindelsen oprettes. Politikken sammenligner derefter hver rækkes tenant_id med denne indstilling.

-- 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;

Test din viden

Test din forståelse af politikker for Row-Level Security i PostgreSQL.

Besvar den i den interaktive lektion

Opsummering af lektionen

I denne lektion har du lært, hvordan Row-Level Security giver dig automatisk, politikstyret filtrering af rækker direkte på databaseniveau:

Aktivér RLS på en tabel med ALTER TABLE ... ENABLE ROW LEVEL SECURITY.
Brug CREATE POLICY med en USING-klausul til at filtrere læsbare rækker og en WITH CHECK-klausul til at validere skrevne rækker.
Begræns politikker til bestemte kommandoer (SELECT, INSERT, UPDATE, DELETE, ALL) og bestemte roller ved hjælp af TO-klausulen.
Kombiner PERMISSIVE-politikker (ELLER-logik) og RESTRICTIVE-politikker (OG-logik) for lagdelt adgangskontrol.
Tabelejere og superbrugere omgår som standard RLS; brug FORCE ROW LEVEL SECURITY til at tilsidesætte dette.
Mønstret med flere lejere, der bruger current_setting(), er en effektiv praktisk anvendelse af RLS.

RLS er standardmetoden til at håndhæve dataisolering rent og konsekvent uden at sprede WHERE-klausuler ud over hver forespørgsel i applikationen.

Gratis at komme i gang

Lær SQL med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 46
Lektioner: 183

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Sikkerhedspolitikker på rækkeniveau” gratis?

Ja — hele teksten til “Sikkerhedspolitikker på rækkeniveau” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af SQL Academy-kurset, skal du opgradere til CoddyKit PRO. SQL Academy-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Sikkerhedspolitikker på rækkeniveau”?

Filtrér automatisk rækker pr. bruger. Du øver dig i SQL Academy med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på SQL Academy?

Der kræves ingen tidligere erfaring. SQL Academy på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.

Hvor lang tid tager lektionen “Sikkerhedspolitikker på rækkeniveau”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne SQL Academy-lektion?

Ja. Alle SQL Academy-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

← Tilbage til SQL Academy