Një studim mbi zbatimin e sigurisë së nivelit të rreshtit në PostgreSQL

Si plotësues i Një studim mbi zbatimin e logjikës së biznesit në nivelin e funksioneve të ruajtura PostgreSQL и kryesisht për një përgjigje të detajuar mbi комментарий.

Pjesa teorike është përshkruar mirë në dokumentacion PostgreSQL - Politikat e mbrojtjes së rreshtave. Më poshtë është një zbatim praktik i një të vogël detyrë specifike e biznesit - fshehja e të dhënave të fshira. Skicë kushtuar zbatimit Modelimi i roleve duke përdorur RLS paraqitur veçmas.

Nuk ka asgjë të re në artikull, nuk ka asnjë kuptim të fshehur apo njohuri sekrete. Vetëm një skicë rreth zbatimit praktik të një ideje teorike. Nëse dikush është i interesuar, ta lexojë. Nëse nuk jeni të interesuar, mos e humbni kohën kot.

Formulimi i problemit

Pa u zhytur thellë në fushën e temës, shkurtimisht, problemi mund të formulohet si më poshtë: Ekziston një tabelë që zbaton një subjekt të caktuar afarist. Rreshtat në tabelë mund të fshihen, por rreshtat nuk mund të fshihen fizikisht; ato duhet të fshihen.

Sepse thuhet: “Mos fshini asgjë, thjesht riemërtoni. Interneti ruan GJITHÇKA"

Gjatë rrugës, këshillohet të mos rishkruani funksionet ekzistuese të ruajtura që funksionojnë me këtë ent.

Për të zbatuar këtë koncept, tabela ka atributin është_fshirë. Atëherë gjithçka është e thjeshtë - duhet të siguroheni që klienti të mund të shohë vetëm linjat në të cilat atributi është_fshirë i rremë Për çfarë përdoret mekanizmi? Siguria e nivelit të rreshtit.

Zbatimi

Krijo një rol dhe skemë të veçantë

CREATE ROLE repos;
CREATE SCHEMA repos;

Krijo tabelën e synuar

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

Ndizeni Siguria e nivelit të rreshtit

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 ;

Funksioni i shërbimit — fshirja e një rreshti në 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;

Funksioni i biznesit — fshirja e një dokumenti

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

Gjetjet

Klienti fshin dokumentin

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

Pas fshirjes, klienti nuk e sheh dokumentin

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

Por në bazën e të dhënave dokumenti nuk fshihet, vetëm atributi ndryshohet is_del

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

Kjo është ajo që kërkohej në deklaratën e problemit.

Total

Nëse tema është interesante, në studimin tjetër mund të tregoni një shembull të zbatimit të një modeli të bazuar në role për ndarjen e aksesit të të dhënave duke përdorur sigurinë e nivelit të rreshtit.

Burimi: www.habr.com