Een onderzoek naar het implementeren van Row Level Security in PostgreSQL

Als aanvulling op Een onderzoek naar het implementeren van bedrijfslogica op het niveau van opgeslagen PostgreSQL-functies и vooral voor een gedetailleerd antwoord op комментарий.

Het theoretische gedeelte wordt goed beschreven in de documentatie PostgreSQL - Beleid voor rijbescherming. Hieronder vindt u een praktische implementatie van een kleine specifieke zakelijke taak - verwijderde gegevens verbergen. Schets gewijd aan de implementatie Rolmodellering met behulp van RLS afzonderlijk gepresenteerd.

Er staat niets nieuws in het artikel, er is geen verborgen betekenis of geheime kennis. Gewoon een schets over de praktische implementatie van een theoretisch idee. Als iemand geïnteresseerd is, lees het dan. Als u niet geïnteresseerd bent, verspil uw tijd dan niet.

Formulering van het probleem

Zonder diep op het onderwerp in te gaan, kan het probleem in het kort als volgt worden geformuleerd: Er is een tabel die een bepaalde bedrijfsentiteit implementeert. Rijen in de tabel kunnen worden verwijderd, maar rijen kunnen niet fysiek worden verwijderd; ze moeten verborgen zijn.

Want er wordt gezegd: “Verwijder niets, hernoem het gewoon. Het internet slaat ALLES op"

Onderweg is het raadzaam om bestaande opgeslagen functies die met deze entiteit werken niet te herschrijven.

Om dit concept te implementeren, heeft de tabel het attribuut is verwijderd. Dan is alles eenvoudig: u moet ervoor zorgen dat de klant alleen de regels kan zien waarin het attribuut staat is verwijderd vals Waar wordt het mechanisme voor gebruikt? Beveiliging op rijniveau.

uitvoering

Maak een aparte rol en schema

CREATE ROLE repos;
CREATE SCHEMA repos;

Maak de doeltabel

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

We omvatten Beveiliging op rijniveau

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 ;

Servicefunctie — een rij in de tabel verwijderen

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;

Zakelijke functie — een document verwijderen

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

Bevindingen

De klant verwijdert het document

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

Na verwijdering ziet de klant het document niet meer

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

Maar in de database wordt het document niet verwijderd, alleen het attribuut wordt gewijzigd is_del

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

Dat is wat in de probleemstelling werd vereist.

Totaal

Als het onderwerp interessant is, kunt u in het volgende onderzoek een voorbeeld laten zien van de implementatie van een op rollen gebaseerd model voor het scheiden van gegevenstoegang met behulp van Row Level Security.

Bron: www.habr.com