Rivitason tietoturvakäytännöt
Suodattakaa rivit automaattisesti käyttäjäkohtaisesti.
Rivitason tietoturvakäytännöt on ilmainen SQL Academy-oppitunti CoddyKitissä. Tämä on oppitunti 2/4. Voit lukea koko oppitunnin alta ilmaiseksi ja harjoitella sen jälkeen käytännössä selaimessa sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla. Oppitunti kuuluu SQL Academy-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. SQL Academy-kurssilla on yhteensä 4 oppituntia.
Mitä rivitason tietoturva on
Rivitason tietoturva (RLS) on PostgreSQL:n ominaisuus, jonka avulla voitte hallita, mitä taulun rivejä tietty tietokannan käyttäjä tai rooli voi nähdä tai muokata. Sen sijaan että suodattaisitte rivit jokaisessa kyselyssä erikseen, määritätte käytännön kerran, minkä jälkeen PostgreSQL valvoo sitä automaattisesti jokaisessa SELECT-, INSERT-, UPDATE- ja DELETE-toiminnossa.
Voitte ajatella sitä näkymättömänä WHERE-lausekkeena, joka on liitetty itse tauluun eikä mihinkään tiettyyn kyselyyn.
RLS:n ottaminen käyttöön taulussa
RLS on oletusarvoisesti poissa käytöstä. Teidän on otettava se erikseen käyttöön jokaisessa taulussa komennolla ALTER TABLE ... ENABLE ROW LEVEL SECURITY. Kun RLS on käytössä, kaikki roolit, jotka eivät ole taulun omistajia, näkevät nolla riviä, kunnes vähintään yksi käytäntö on luotu.
-- 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;Ensimmäisen käytännön luominen
Käytäntö luodaan komennolla CREATE POLICY. Antakaa sille nimi, määrittäkää taulu ja antakaa USING-lauseke. USING-lauseke on totuusarvolauseke, joka arvioidaan jokaiselle riville — käyttäjä näkee vain ne rivit, joiden kohdalla lauseke palauttaa arvon TRUE.
-- Allow each user to see only their own orders
CREATE POLICY orders_owner_policy
ON orders
FOR SELECT
USING (owner = current_user);USING- ja WITH CHECK -lausekkeet
Käytännöissä on kaksi eri tarkoituksiin käytettävää suodatuslauseketta:
- USING — suodattaa rivit lukutoiminnoissa (SELECT, UPDATE, DELETE). Rivi näkyy vain, jos USING palauttaa arvon TRUE.
- WITH CHECK — tarkistaa rivit kirjoitustoiminnoissa (INSERT, UPDATE). Kirjoitus sallitaan vain, jos WITH CHECK palauttaa arvon TRUE. Jos se jätetään pois, kirjoitusten tarkistuksessa käytetään uudelleen USING-lauseketta.
-- 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);Käytännön kohdistus: FOR SELECT, INSERT, UPDATE, DELETE
Yksi käytäntö voi kattaa kaikki komennot (FOR ALL) tai vain tietyn komennon. Käytäntöjen erottaminen komennoittain antaa tarkemman hallinnan — esimerkiksi voitte sallia kaikkien käyttäjien lukea kaikki rivit, mutta muuttaa vain omia rivejään.
-- 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);session_user- ja current_user-funktioiden käyttäminen
PostgreSQL tarjoaa sisäänrakennetut funktiot aktiivisen käyttäjän tunnistamiseen käytäntölausekkeessa:
- current_user — rooli, jonka käyttöoikeudet ovat parhaillaan aktiivisia (voi muuttua SET ROLE -komennon jälkeen).
- session_user — yhteyden avannut rooli (ei muutu istunnon aikana).
Useimmat RLS-käytännöt perustuvat current_user-arvoon, koska se vastaa roolinvaihdon jälkeen käytössä olevaa roolia.
-- Inspect the current identity inside a query
SELECT current_user, session_user;RLS:n kohdistaminen tiettyihin rooleihin
Oletusarvoisesti käytäntö koskee PUBLIC-roolia (kaikkia rooleja). Voitte rajata sen koskemaan tiettyä roolia käyttämällä TO-lauseketta. Tästä on hyötyä, kun haluatte yhden käytännön tavallisille käyttäjille ja toisen ylläpitäjäroolille.
-- 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);PERMISSIVE- ja RESTRICTIVE-käytännöt
Saman taulun useat käytännöt voivat toimia yhdessä kahdella tavalla:
- PERMISSIVE (oletus) — kaikki sallivat käytännöt yhdistetään OR-operaatiolla. Riviin pääsee, jos mikä tahansa salliva käytäntö sallii sen.
- RESTRICTIVE — rajoittavat käytännöt yhdistetään sallivien käytäntöjen tulokseen AND-operaatiolla. Riviin pääsee vain, jos se läpäisee rajoittavan käytännön ja vähintään yksi salliva käytäntö sallii sen.
-- Restrictive policy: block access to archived orders for everyone
CREATE POLICY no_archived_rows
ON orders
AS RESTRICTIVE
FOR SELECT
USING (amount > 0);RLS:n ohittaminen: BYPASSRLS ja taulujen omistajat
Taulun omistaja ja pääkäyttäjät ohittavat RLS:n oletusarvoisesti ja näkevät aina kaikki rivit. Voitte myöntää roolille BYPASSRLS-määritteen, jos se tarvitsee rajoittamattoman pääsyn ilman pääkäyttäjän oikeuksia. Voitte myös pakottaa omistajan noudattamaan RLS:ää käyttämällä FORCE ROW LEVEL SECURITY -asetusta.
-- 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;Käytäntöjen muokkaaminen ja poistaminen
Voitte päivittää olemassa olevan käytännön komennolla ALTER POLICY tai poistaa sen kokonaan komennolla DROP POLICY. Jos kaikki käytännöt poistetaan RLS:n ollessa edelleen käytössä, muut kuin omistajaroolit eivät pääse mihinkään riviin. Poistakaa RLS kokonaan käytöstä ALTER TABLE -komennolla.
-- 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;Reaalimaailman malli: moniasiakasdatan eristys
Yleinen RLS-malli moniasiakkaisissa SaaS-sovelluksissa on tallentaa tenant_id-sarake jokaiseen tauluun ja käyttää istuntotason muuttujaa (set_config) asiakastunnisteen välittämiseen yhteyden muodostamisen yhteydessä. Käytäntö vertaa sitten kunkin rivin tenant_id-arvoa kyseiseen asetukseen.
-- 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;Tietotesti
Testatkaa ymmärrystänne PostgreSQL:n rivitason suojauskäytännöistä.
Oppitunnin yhteenveto
Tässä oppitunnissa opitte, miten rivitason suojaus suodattaa rivejä automaattisesti käytäntöjen perusteella suoraan tietokantatasolla:
- Ottakaa RLS käyttöön taulussa komennolla ALTER TABLE ... ENABLE ROW LEVEL SECURITY.
- Käyttäkää CREATE POLICY -komentoa yhdessä USING-lausekkeen kanssa luettavien rivien suodattamiseen ja WITH CHECK -lausekkeen kanssa kirjoitettavien rivien tarkistamiseen.
- Rajaatte käytännöt tiettyihin komentoihin (SELECT, INSERT, UPDATE, DELETE, ALL) ja rooleihin TO-lausekkeella.
- Yhdistätte PERMISSIVE-käytännöt (OR-logiikka) ja RESTRICTIVE-käytännöt (AND-logiikka) kerroksittaiseksi käyttöoikeuksien hallinnaksi.
- Taulujen omistajat ja pääkäyttäjät ohittavat RLS:n oletusarvoisesti; käyttäkää FORCE ROW LEVEL SECURITY -asetusta tämän muuttamiseen.
- current_setting()-funktiota käyttävä moniasiakasmalli on tehokas RLS:n reaalimaailman sovellus.
RLS on vakiintunut tapa toteuttaa tietojen eristys siististi ja johdonmukaisesti ilman, että WHERE-lausekkeita tarvitsee hajauttaa jokaiseen sovelluksen kyselyyn.
Opi SQL tekoälytuutorin avulla — ilmaiseksi
Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.
- Kurssit
- 46
- Oppitunnit
- 183
Usein kysytyt kysymykset
Onko oppitunti ”Rivitason tietoturvakäytännöt” ilmainen?
Kyllä – oppitunnin ”Rivitason tietoturvakäytännöt” koko tekstin voi lukea täällä verkossa ilmaiseksi. Jos haluat harjoitella interaktiivisesti sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla sekä avata koko SQL Academy-kurssin, päivitä CoddyKit PROhon. SQL Academy-kurssilla on yhteensä 4 oppituntia.
Mitä opin oppitunnilla ”Rivitason tietoturvakäytännöt”?
Suodattakaa rivit automaattisesti käyttäjäkohtaisesti. Harjoittelet SQL Academy-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.
Tarvitsenko kokemusta aloittaakseni SQL Academy-opiskelun?
Aiempi kokemus ei ole tarpeen. CoddyKitin SQL Academy-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 2/4.
Kuinka kauan ”Rivitason tietoturvakäytännöt”-oppitunnin suorittaminen kestää?
Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.
Voinko kirjoittaa ja suorittaa koodia tällä SQL Academy-oppitunnilla?
Kyllä. Jokainen SQL Academy-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.
Kaikki tämän kurssin oppitunnit
- Roolit ja käyttöoikeudet
- Rivitason tietoturvakäytännöt
- Saraketason käyttöoikeudet
- Käyttöoikeuksien auditointi