'n Studie oor die implementering van ryvlaksekuriteit in PostgreSQL

As 'n aanvulling op 'n Studie oor die implementering van besigheidslogika op die vlak van PostgreSQL-gebergde funksies и hoofsaaklik vir 'n gedetailleerde antwoord op kommentaar.

Die teoretiese deel word goed beskryf in die dokumentasie PostgreSQL - Rybeskermingsbeleide. Hieronder is 'n praktiese implementering van 'n klein spesifieke besigheidstaak - versteek geskrapte data. Skets gewy aan implementering Rolmodellering met behulp van RLS afsonderlik aangebied word.

Daar is niks nuuts in die artikel nie, daar is geen verborge betekenis of geheime kennis nie. Net 'n skets oor die praktiese implementering van 'n teoretiese idee. As iemand belangstel, lees dit. As jy nie belangstel nie, moenie jou tyd mors nie.

Probleemstelling

Sonder om diep in die vakgebied te duik, kortliks, kan die probleem soos volg geformuleer word: Daar is 'n tabel wat 'n sekere besigheidsentiteit implementeer. Rye in die tabel kan uitgevee word, maar rye kan nie fisies uitgevee word nie; hulle moet versteek word.

Want daar word gesê: “Moenie iets uitvee nie, hernoem dit net. Die internet stoor ALLES"

Langs die pad is dit raadsaam om nie bestaande gestoorde funksies wat met hierdie entiteit werk, te herskryf nie.

Om hierdie konsep te implementeer, het die tabel die kenmerk is_uitgevee. Dan is alles eenvoudig - jy moet seker maak dat die kliënt net die lyne waarin die kenmerk kan sien is_uitgevee onwaar Waarvoor word die meganisme gebruik? Ryvlaksekuriteit.

Implementering

Skep 'n aparte rol en skema

CREATE ROLE repos;
CREATE SCHEMA repos;

Skep die teikentabel

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

Skakel aan Ryvlakbeveiliging

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 ;

Diensfunksie — verwydering van 'n ry in die 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;

Besigheidsfunksie - verwydering van 'n 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;

Bevindinge

Die kliënt vee die dokument uit

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

Na uitvee sien die kliënt nie die dokument nie

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

Maar in die databasis word die dokument nie uitgevee nie, net die kenmerk word verander is_del

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

Dit is wat in die probleemstelling vereis word.

Totale

As die onderwerp interessant is, kan jy in die volgende studie 'n voorbeeld wys van die implementering van 'n rolgebaseerde model vir die skeiding van datatoegang deur gebruik te maak van Ryvlaksekuriteit.

Bron: will.com