In stúdzje oer ymplemintaasje fan Row Level Security yn PostgreSQL

As oanfolling op In stúdzje oer ymplemintaasje fan saaklike logika op it nivo fan PostgreSQL opsleine funksjes и benammen foar in detaillearre antwurd op комментарий.

It teoretyske diel is goed beskreaun yn 'e dokumintaasje PostgreSQL - Rige beskerming belied. Hjirûnder is in praktyske útfiering fan in lyts spesifike saaklike taak - ferbergje wiske gegevens. Sketch wijd oan ymplemintaasje Rolmodeling mei RLS apart presintearre.

D'r is neat nij yn it artikel, d'r is gjin ferburgen betsjutting of geheime kennis. Krekt in skets oer de praktyske útfiering fan in teoretysk idee. As immen ynteressearre is, lês it dan. As jo ​​​​net ynteressearre binne, fergrieme jo tiid net.

Probleemintwurding

Sûnder djip yn it fakgebiet te dûken, koart, kin it probleem as folget formulearre wurde: D'r is in tabel dy't in bepaalde saaklike entiteit ymplemintearret. Rigen yn 'e tabel kinne wiske wurde, mar rigen kinne net fysyk wiske wurde; se moatte ferburgen wurde.

Want der wurdt sein: "Net wiskje neat, omneame it gewoan. It ynternet slacht ALLES op"

Underweis is it oan te rieden om besteande bewarre funksjes dy't wurkje mei dizze entiteit net te herskriuwen.

Om dit konsept út te fieren, hat de tabel it attribút is_deleted. Dan is alles ienfâldich - jo moatte der wis fan wêze dat de klant allinich de rigels kin sjen wêryn it attribút is is_deleted falsk Wat wurdt it meganisme brûkt foar? Row Level Security.

Ymplemintaasje

Meitsje in aparte rol en skema

CREATE ROLE repos;
CREATE SCHEMA repos;

Meitsje de doeltabel

CREATE TABLE repos.file
(
...
is_del BOOLEAN DEFAULT FALSE
);
CREATE SCHEMA repos

Wy omfetsje Rige nivo befeiliging

ALTER TABLE repos.file  ENABLE ROW LEVEL SECURITY ;
CREATE POLICY file_invisible_deleted  ON repos.file FOR ALL TO dba_role USING ( NOT is_deleted );
GRANT ALL ON TABLE repos.file to dba_role ;
GRANT USAGE ON SCHEMA repos TO dba_role ;

Service funksje - wiskje in rige yn 'e tabel

CREATE OR REPLACE repos.delete( curr_id repos.file.id%TYPE)
RETURNS integer AS $$
BEGIN
...
UPDATE repos.file
SET is_del = TRUE 
WHERE id = curr_id ; 
...
END
$$ LANGUAGE plpgsql SECURITY DEFINER;

Business funksje - in dokumint wiskje

CREATE OR REPLACE business_functions.deleteDoc( doc_for_delete JSON )
RETURNS JSON AS $$
BEGIN
...
PERFORM  repos.delete( doc_id ) ;
...
END
$$ LANGUAGE plpgsql SECURITY DEFINER;

Resultaten

De kliïnt wisket it dokumint

SELECT business_functions.delCFile( (SELECT json_build_object( 'CId', 3 )) );

Nei it wiskjen sjocht de kliïnt it dokumint net

SELECT business_functions.getCFile"( (SELECT json_build_object( 'CId', 3 )) ) ;
-----------------
(0 rows)

Mar yn 'e databank wurdt it dokumint net wiske, allinich it attribút wurdt feroare is_del

psql -d my_db
SELECT  id, name , is_del FROM repos.file ;
id |  name  | is_del
--+---------+------------
 1 |  test_1 | t
(1 row)

Wat is wat nedich wie yn 'e probleemstelling.

It resultaat

As it ûnderwerp ynteressant is, kinne jo yn 'e folgjende stúdzje in foarbyld sjen litte fan it útfieren fan in rol-basearre model foar it skieden fan gegevenstagong mei Row Level Security.

Boarne: www.habr.com