Tanulmány a sor szintű biztonság megvalósításáról a PostgreSQL-ben

Kiegészítőként a Tanulmány az üzleti logika megvalósításáról a PostgreSQL tárolt függvények szintjén и főleg a részletes válaszért on megjegyzés.

Az elméleti rész jól le van írva a dokumentációban PostgreSQL - Sorvédelmi szabályzatok. Az alábbiakban egy kis gyakorlati megvalósítása látható konkrét üzleti feladat - törölt adatok elrejtése. A megvalósításnak szentelt vázlat Szerepmodellezés RLS segítségével külön bemutatva.

Tanulmány a sor szintű biztonság megvalósításáról a PostgreSQL-ben

A cikkben nincs újdonság, nincs rejtett jelentés vagy titkos tudás. Csak egy vázlat egy elméleti ötlet gyakorlati megvalósításáról. Ha valakit érdekel, olvassa el. Ha nem érdekli, ne pazarolja az idejét.

Probléma nyilatkozat

Anélkül, hogy mélyen belemerülnénk a témakörbe, röviden a probléma a következőképpen fogalmazható meg: Van egy táblázat, amely egy bizonyos üzleti entitást valósít meg. A táblázat sorai törölhetők, de a sorok fizikailag nem törölhetők, el kell rejteni őket.

Mert azt mondják: „Ne törölj semmit, csak nevezd át. Az internet MINDENT tárol"

Útközben nem tanácsos átírni a meglévő tárolt függvényeket, amelyek ezzel az entitással működnek.

A koncepció megvalósításához a táblázat rendelkezik az attribútummal is_deleted. Ezután minden egyszerű - meg kell győződnie arról, hogy az ügyfél csak azokat a sorokat látja, amelyekben az attribútum is_deleted hamis Mire használható a mechanizmus? Sor szintű biztonság.

Реализация

Hozzon létre egy külön szerepet és sémát

CREATE ROLE repos;
CREATE SCHEMA repos;

Hozza létre a céltáblát

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

Mi is Sorszintű biztonság

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 ;

Szerviz funkció — egy sor törlése a táblázatból

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;

Üzleti funkció — dokumentum törlése

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

Álláspontja

Az ügyfél törli a dokumentumot

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

A törlés után a kliens nem látja a dokumentumot

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

De az adatbázisban a dokumentum nem törlődik, csak az attribútum módosul is_del

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

Amire a problémafelvetésben szükség volt.

Teljes

Ha a téma érdekes, a következő tanulmányban példát mutathat be egy szerepalapú modell megvalósítására az adathozzáférés elválasztására a sorszintű biztonság segítségével.

Forrás: will.com

Hozzászólás