En studie om implementering av Row Level Security i PostgreSQL

Som et supplement til En studie om implementering av forretningslogikk på nivå med PostgreSQL-lagrede funksjoner и hovedsakelig for et detaljert svar på комментарий.

Den teoretiske delen er godt beskrevet i dokumentasjonen PostgreSQL - Retningslinjer for radbeskyttelse. Nedenfor er en praktisk gjennomføring av en liten spesifikk forretningsoppgave - skjule slettede data. Skisse dedikert til implementering Rollemodellering ved hjelp av RLS presentert separat.

Det er ikke noe nytt i artikkelen, det er ingen skjult mening eller hemmelig kunnskap. Bare en skisse om den praktiske gjennomføringen av en teoretisk idé. Hvis noen er interessert, les den. Hvis du ikke er interessert, ikke kast bort tiden din.

Formulering av problemet

Uten å dykke dypt inn i fagområdet, kort, kan problemet formuleres som følger: Det er en tabell som implementerer en bestemt forretningsenhet. Rader i tabellen kan slettes, men rader kan ikke slettes fysisk, de må skjules.

For det sies: «Ikke slett noe, bare gi det nytt navn. Internett lagrer ALT"

Underveis er det tilrådelig å ikke omskrive eksisterende lagrede funksjoner som fungerer med denne enheten.

For å implementere dette konseptet har tabellen attributtet er_slettet. Da er alt enkelt - du må sørge for at klienten bare kan se linjene der attributtet er_slettet falsk Hva brukes mekanismen til? Sikkerhet på radnivå.

implementering

Lag en egen rolle og skjema

CREATE ROLE repos;
CREATE SCHEMA repos;

Lag måltabellen

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

Vi inkluderer Radnivå sikkerhet

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 ;

Servicefunksjon — sletting av en rad i tabellen

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;

Forretningsfunksjon — slette et dokument

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

Funn

Klienten sletter dokumentet

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

Etter sletting ser ikke klienten dokumentet

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

Men i databasen slettes ikke dokumentet, bare attributtet endres is_del

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

Noe som var nødvendig i problemformuleringen.

Total

Hvis temaet er interessant, kan du i neste studie vise et eksempel på implementering av en rollebasert modell for å skille datatilgang ved hjelp av Row Level Security.

Kilde: www.habr.com