Uno studio sull'implementazione della sicurezza a livello di riga in PostgreSQL

Come complemento a Uno studio sull'implementazione della logica aziendale a livello delle funzioni memorizzate PostgreSQL и principalmente per una risposta dettagliata su commento.

La parte teorica è ben descritta nella documentazione PostgreSQL - Politiche di protezione delle righe. Di seguito è riportata un'implementazione pratica di un piccolo attività aziendale specifica: nascondere i dati cancellati. Schizzo dedicato all'implementazione Modellazione dei ruoli utilizzando RLS presentati separatamente.

Non c'è nulla di nuovo nell'articolo, non c'è significato nascosto o conoscenza segreta. Solo uno schizzo sull'implementazione pratica di un'idea teorica. Se qualcuno è interessato, lo legga. Se non sei interessato, non perdere tempo.

Formulazione del problema

Senza entrare in profondità nell’argomento, brevemente, il problema può essere formulato come segue: Esiste una tabella che implementa una determinata entità aziendale. Le righe nella tabella possono essere eliminate, ma le righe non possono essere eliminate fisicamente; devono essere nascoste.

Perché è detto: “Non cancellare nulla, basta rinominarlo. Internet memorizza TUTTO"

Lungo il percorso, è consigliabile non riscrivere le funzioni memorizzate esistenti che funzionano con questa entità.

Per implementare questo concetto, la tabella ha l'attributo è_cancellato. Quindi tutto è semplice: devi assicurarti che il cliente possa vedere solo le righe in cui è presente l'attributo è_cancellato falso A cosa serve il meccanismo? Sicurezza a livello di riga.

implementazione

Creare un ruolo e uno schema separati

CREATE ROLE repos;
CREATE SCHEMA repos;

Creare la tabella di destinazione

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

Includiamo Sicurezza a livello di riga

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 ;

Funzione di servizio — eliminare una riga nella tabella

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;

Funzione aziendale — eliminare un documento

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

Giudizio

Il client elimina il documento

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

Dopo l'eliminazione, il cliente non vede il documento

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

Ma nel database il documento non viene cancellato, viene modificato solo l'attributo is_del

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

Questo è quanto richiesto nella dichiarazione del problema.

risultato

Se l'argomento è interessante, nel prossimo studio puoi mostrare un esempio di implementazione di un modello basato sui ruoli per separare l'accesso ai dati utilizzando la sicurezza a livello di riga.

Fonte: habr.com