PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Best practice per la registrazione di audit di PostgreSQL

In ogni sistema IT in cui si svolgono importanti attività aziendali, è importante disporre di un insieme esplicito di politiche e pratiche e assicurarsi che siano rispettate e seguite.

Introduzione all'Auditing

Un audit del sistema informatico è l'esame delle politiche, dei processi, delle procedure e delle pratiche di un'organizzazione per quanto riguarda l'infrastruttura IT rispetto a un determinato insieme di obiettivi. Un audit IT può essere di due tipi generici:

  • Controllo rispetto a una serie di standard su un sottoinsieme limitato di dati
  • Controllo dell'intero sistema

Un audit IT può coprire alcune parti critiche del sistema, come quelle relative ai dati finanziari al fine di supportare una serie specifica di normative (ad es. SOX), o l'intera infrastruttura di sicurezza rispetto a normative come il nuovo regolamento GDPR dell'UE che affronta la necessità per la tutela della privacy e definisce le linee guida per la gestione dei dati personali. L'esempio SOX è del primo tipo sopra descritto mentre il GDPR è del secondo.

Il ciclo di vita dell'audit

Pianificazione

L'ambito di un audit dipende dall'obiettivo dell'audit. L'ambito può coprire un'applicazione speciale identificata da una specifica attività commerciale, come un'attività finanziaria, o l'intera infrastruttura IT che copre la sicurezza del sistema, la sicurezza dei dati e così via. L'ambito deve essere identificato correttamente in anticipo come una fase iniziale nella fase di pianificazione iniziale. L'organizzazione dovrebbe fornire all'auditor tutte le informazioni di base necessarie per aiutare con la pianificazione dell'audit. Queste possono essere le specifiche funzionali/tecniche, gli schemi dell'architettura del sistema o qualsiasi altra informazione richiesta.

Obiettivi di controllo

Sulla base dell'ambito di applicazione, il revisore forma una serie di obiettivi di controllo che devono essere verificati dall'audit. Tali obiettivi di controllo sono attuati attraverso pratiche di gestione che dovrebbero essere in atto al fine di ottenere il controllo nella misura descritta dall'ambito di applicazione. Gli obiettivi di controllo sono associati ai piani di test e insieme costituiscono il programma di audit. Basato sul programma di audit l'organizzazione sottoposta a revisione alloca risorse per facilitare l'auditor.

Risultati

L'auditor cerca di ottenere la prova che tutti gli obiettivi di controllo sono raggiunti. Se per alcuni obiettivi di controllo non esistono tali evidenze, prima il revisore cerca di vedere se esiste un modo alternativo in cui la società gestisce l'obiettivo di controllo specifico e, nel caso in cui tale modalità esista, questo obiettivo di controllo è contrassegnato come compensante e il revisore ritiene che l'obiettivo sia raggiunto. Se tuttavia non ci sono prove che un obiettivo sia stato raggiunto, questo viene contrassegnato come un risultato . Ogni risultato è costituito dalla condizione, criteri, causa, effetto e raccomandazione. Il responsabile IT deve essere in stretto contatto con il revisore per essere informato di tutti i potenziali risultati e assicurarsi che tutte le informazioni richieste siano condivise tra la direzione e il revisore al fine di assicurare che l'obiettivo di controllo sia raggiunto (e quindi evitare il trovare).

Il rapporto di valutazione

Al termine del processo di audit, l'auditor scriverà una relazione di valutazione come sintesi che copre tutte le parti importanti dell'audit, compresi eventuali risultati potenziali, seguita da una dichiarazione sull'adeguatezza dell'obiettivo e da raccomandazioni per eliminare l'impatto dei risultati.

Cos'è l'Audit Logging e perché dovresti farlo?

L'auditor vuole avere pieno accesso alle modifiche su software, dati e sistema di sicurezza. Non solo vuole essere in grado di rintracciare qualsiasi modifica ai dati aziendali, ma anche tenere traccia delle modifiche all'organigramma, alla politica di sicurezza, alla definizione di ruoli/gruppi e alle modifiche all'appartenenza a ruoli/gruppi. Il modo più comune per eseguire un controllo è tramite la registrazione. Sebbene in passato fosse possibile superare un audit IT senza file di registro, oggi è il modo preferito (se non l'unico).

Tipicamente il sistema IT medio comprende almeno due livelli:

  • Banca dati
  • Applicazione (possibilmente sopra un server delle applicazioni)

L'applicazione conserva i propri registri che coprono l'accesso e le azioni dell'utente, mentre il database ed eventualmente i sistemi del server delle applicazioni mantengono i propri registri. Le informazioni pulite e facilmente utilizzabili nei file di registro che hanno un reale valore aziendale dal punto di vista dell'auditor sono chiamate traccia di audit . Gli audit trail differiscono dai normali file di registro (a volte chiamati registri nativi) in quanto:

  • I file di registro sono superflui
  • Le tracce di controllo dovrebbero essere conservate per periodi più lunghi
  • I file di registro aggiungono un sovraccarico alle risorse del sistema
  • Lo scopo dei file di registro è aiutare l'amministratore di sistema
  • Lo scopo degli audit trail è aiutare l'auditor

Riassumiamo quanto sopra nella tabella seguente:

Tipo di registro App/Sistema Adatto all'Audit Trail
Registri app App Sì
Registri del server delle app Sistema No
Registri del database Sistema No

I log delle app possono essere facilmente personalizzati per essere utilizzati come audit trail. Registri di sistema non così facilmente perché:

  • Sono limitati nel loro formato dal software di sistema
  • Agiscono globalmente sull'intero sistema
  • Non hanno una conoscenza diretta del contesto aziendale specifico
  • Di solito richiedono software aggiuntivo per l'analisi/elaborazione offline successiva al fine di produrre audit trail utilizzabili e facili da controllare.

Tuttavia, d'altra parte, i registri delle app posizionano un livello software aggiuntivo sopra i dati effettivi, quindi:

  • Rendere il sistema di audit più vulnerabile a bug dell'applicazione/configurazione errata
  • Creare una potenziale falla nel processo di registrazione se qualcuno tenta di accedere ai dati direttamente sul database bypassando il sistema di registrazione dell'app, come un utente privilegiato o un DBA
  • Rendere il sistema di audit più complesso e più difficile da gestire e mantenere nel caso in cui abbiamo molte applicazioni o molti team software.

Quindi, idealmente cercheremmo il meglio dei due:avere audit trail utilizzabili con la massima copertura sull'intero sistema, incluso il livello di database, e configurabile in un unico posto, in modo che la registrazione stessa possa essere facilmente verificata per mezzo di altri ( sistema) registri.

Registrazione di controllo con PostgreSQL

Le opzioni che abbiamo in PostgreSQL per quanto riguarda la registrazione di controllo sono le seguenti:

  • Utilizzando una registrazione esaustiva ( log_statement =all )
  • Scrivendo una soluzione trigger personalizzata
  • Utilizzando gli strumenti PostgreSQL standard forniti dalla comunità, come
    • audit-trigger 91plus (https://github.com/2ndQuadrant/audit-trigger)
    • estensione pgaudit (https://github.com/pgaudit/pgaudit)

La registrazione esaustiva almeno per l'utilizzo standard nei carichi di lavoro OLTP o OLAP dovrebbe essere evitata perché:

  • Produce file enormi, aumenta il carico
  • Non ha una conoscenza interna delle tabelle a cui si accede o si modifica, stampa semplicemente l'istruzione che potrebbe essere un blocco DO con un'istruzione criptica concatenata
  • Necessita di software/risorse aggiuntivi per l'analisi e l'elaborazione offline (al fine di produrre gli audit trail) che a loro volta devono essere inclusi nell'ambito dell'audit, per essere considerati affidabili

Nel resto di questo articolo proveremo gli strumenti forniti dalla community. Supponiamo di avere questa semplice tabella che vogliamo controllare:

myshop=# \d orders
                                       Table "public.orders"
   Column   |           Type           | Collation | Nullable |              Default               
------------+--------------------------+-----------+----------+------------------------------------
 id         | integer                  |           | not null | nextval('orders_id_seq'::regclass)
 customerid | integer                  |           | not null |
 customer   | text                     |           | not null |
 xtime      | timestamp with time zone   |           | not null | now()
 productid  | integer                  |           | not null |
 product    | text                     |           | not null |
 quantity   | integer                  |           | not null |
 unit_price | double precision         |           | not null |
 cur        | character varying(20)    |           | not null | 'EUR'::character varying
Indexes:
    "orders_pkey" PRIMARY KEY, btree (id)

attivatore di controllo 91plus

I documenti sull'utilizzo del trigger possono essere trovati qui:https://wiki.postgresql.org/wiki/Audit_trigger_91plus. Per prima cosa scarichiamo e installiamo il DDL fornito (funzioni, schema):

$ wget https://raw.githubusercontent.com/2ndQuadrant/audit-trigger/master/audit.sql
$ psql myshop
psql (10.3 (Debian 10.3-1.pgdg80+1))
Type "help" for help.
myshop=# \i audit.sql

Quindi definiamo i trigger per la nostra tabella ordini utilizzando l'utilizzo di base:

myshop=# SELECT audit.audit_table('orders');

Questo creerà due trigger sugli ordini di tabella:un trigger di riga insert_update_delere e un trigger di istruzione tronca. Ora vediamo cosa fa il trigger:

myshop=# insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);      
INSERT 0 1
myshop=# update orders set quantity=3 where id=2;
UPDATE 1
myshop=# delete from orders  where id=2;
DELETE 1
myshop=# select table_name, action, session_user_name, action_tstamp_clk, row_data, changed_fields from audit.logged_actions;
-[ RECORD 1 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | I
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:15:10.887268+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"2", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    |
-[ RECORD 2 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | U
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:16:12.829065+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"2", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    | "quantity"=>"3"
-[ RECORD 3 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | D
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:16:24.944117+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"3", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    |

Notare il valore modificato_fields nell'aggiornamento (RECORD 2). Esistono usi più avanzati del trigger di controllo, come l'esclusione di colonne o l'utilizzo della clausola WHEN come mostrato nel documento. Il trigger di audit sembra sicuramente fare il lavoro di creare utili audit trail all'interno della tabella audit.logged_actions. Tuttavia ci sono alcuni avvertimenti:

  • Nessun SELECT (i trigger non si attivano su SELECT) o DDL vengono tracciati
  • Le modifiche apportate dai proprietari dei tavoli e dai super utenti possono essere facilmente manomesse
  • È necessario seguire le best practice relative agli utenti dell'app e ai proprietari di tabelle e schemi dell'app
Scarica il whitepaper oggi Gestione e automazione di PostgreSQL con ClusterControlScopri cosa devi sapere per distribuire, monitorare, gestire e ridimensionare PostgreSQLScarica il whitepaper

Pgaudi

Pgaudit è l'ultima aggiunta a PostgreSQL per quanto riguarda l'auditing. Pgaudit deve essere installato come estensione, come mostrato nella pagina github del progetto:https://github.com/pgaudit/pgaudit. Registri Pgaudit nel registro PostgreSQL standard. Pgaudit funziona registrandosi al caricamento del modulo e fornendo hook per executorStart, executorCheckPerms, processUtility e object_access. Pertanto pgaudit (a differenza delle soluzioni basate su trigger come audit-trigger discusse nei paragrafi precedenti) supporta le LETTURE (SELECT, COPY). Generalmente con pgaudit possiamo avere due modalità di funzionamento o usarle combinate:

  • Registrazione dell'audit SESSIONE
  • Registrazione di controllo dell'OGGETTO

La registrazione dell'audit della sessione supporta la maggior parte dei comandi DML, DDL, privilegi e vari tramite classi:

  • LEGGI (seleziona, copia da)
  • SCRIVI (inserisci, aggiorna, elimina, tronca, copia in)
  • FUNCTION (chiamate di funzioni e blocchi DO)
  • RUOLO (concedi, revoca, crea/modifica/rilascia ruolo)
  • DDL (tutti i DDL tranne quelli in ROLE)
  • MISC (scarto, recupero, checkpoint, vuoto)

La metaclasse "tutti" include tutte le classi. - esclude una classe. Ad esempio, configuriamo la registrazione dell'audit della sessione per tutti tranne MISC, con i seguenti parametri GUC in postgresql.conf:

pgaudit.log_catalog = off
pgaudit.log = 'all, -misc'
pgaudit.log_relation = 'on'
pgaudit.log_parameter = 'on'

Dando i seguenti comandi (gli stessi dell'esempio del trigger)

myshop=# insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);
INSERT 0 1
myshop=# update orders set quantity=3 where id=2;
UPDATE 1
myshop=# delete from orders  where id=2;
DELETE 1
myshop=#

Otteniamo le seguenti voci nel registro di PostgreSQL:

% tail -f data/log/postgresql-22.log | grep AUDIT:
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:37.352 EEST psql [email protected] line:7 LOG:  AUDIT: SESSION,5,1,WRITE,INSERT,TABLE,public.orders,"insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);",<none>
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:50.120 EEST psql [email protected] line:8 LOG:  AUDIT: SESSION,6,1,WRITE,UPDATE,TABLE,public.orders,update orders set quantity=3 where id=2;,<none>
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:59.888 EEST psql [email protected] line:9 LOG:  AUDIT: SESSION,7,1,WRITE,DELETE,TABLE,public.orders,delete from orders  where id=2;,<none>

Si noti che il testo dopo AUDIT:costituisce un audit trail perfetto, quasi pronto per essere spedito all'auditor in formato CSV pronto per il foglio di calcolo. L'uso della registrazione dell'audit della sessione ci fornirà le voci del registro dell'audit per tutte le operazioni appartenenti alle classi definite dal parametro pgaudit.log su all tavoli. Tuttavia ci sono casi in cui desideriamo che solo un piccolo sottoinsieme di dati, ovvero solo alcune tabelle vengano controllate. In questi casi potremmo preferire la registrazione dell'audit degli oggetti che ci fornisce criteri granulari per tabelle/colonne selezionate tramite il sistema dei privilegi di PostgreSQL. Per iniziare a utilizzare la registrazione dell'audit degli oggetti, dobbiamo prima configurare il parametro pgaudit.role che definisce il ruolo principale che pgaudit utilizzerà. Ha senso non concedere a questo utente alcun diritto di accesso.

CREATE ROLE auditor;
ALTER ROLE auditor WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION NOBYPASSRLS CONNECTION LIMIT 0;

Noi specifichiamo questo valore per pgaudit.role in postgresql.conf:

pgaudit.log = none # no need for extensive SESSION logging
pgaudit.role = auditor

La registrazione di Pgaudit OBJECT funzionerà trovando se l'utente auditor viene concesso (direttamente o ereditato) il diritto di eseguire l'azione specificata eseguita sulle relazioni/colonne utilizzate in un'istruzione. Quindi, se dobbiamo ignorare tutte le tabelle, ma abbiamo una registrazione dettagliata per gli ordini delle tabelle, questo è il modo per farlo:

grant ALL on orders to auditor ;

Con la concessione di cui sopra abilitiamo la registrazione completa SELECT, INSERT, UPDATE ed DELETE sugli ordini delle tabelle. Diamo ancora una volta INSERT, UPDATE, DELETE degli esempi precedenti e guardiamo il log postgresql:

% tail -f data/log/postgresql-22.log | grep AUDIT:
[local] [60683] 5b040125.ed0b 2018-05-22 14:41:41.989 EEST psql [email protected] line:7 LOG:  AUDIT: OBJECT,2,1,WRITE,INSERT,TABLE,public.orders,"insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);",<none>
[local] [60683] 5b040125.ed0b 2018-05-22 14:41:52.269 EEST psql [email protected] line:8 LOG:  AUDIT: OBJECT,3,1,WRITE,UPDATE,TABLE,public.orders,update orders set quantity=3 where id=2;,<none>
[local] [60683] 5b040125.ed0b 2018-05-22 14:42:03.148 EEST psql [email protected] line:9 LOG:  AUDIT: OBJECT,4,1,WRITE,DELETE,TABLE,public.orders,delete from orders  where id=2;,<none>

Osserviamo che l'output è identico alla registrazione SESSION discussa sopra con la differenza che invece di SESSION come tipo di audit (la stringa accanto a AUDIT:) ora otteniamo OBJECT.

Un avvertimento con la registrazione OBJECT è che i TRUNCATE non vengono registrati. Dobbiamo ricorrere alla registrazione della SESSIONE per questo. Ma in questo caso finiamo per ottenere tutta l'attività di SCRITTURA per tutte le tabelle. Ci sono discussioni tra gli hacker coinvolti per rendere ogni comando una classe separata.

Un'altra cosa da tenere a mente è che nel caso dell'ereditarietà se CONCEDIAMO l'accesso all'auditor su una tabella figlio, e non sul genitore, le azioni sulla tabella genitore che si traducono in azioni sulle righe della tabella figlio non verranno registrate.

In aggiunta a quanto sopra, il personale IT preposto all'integrità dei log deve documentare una procedura rigorosa e ben definita che copra l'estrazione dell'audit trail dai log file di PostgreSQL. Tali registri potrebbero essere trasmessi in streaming a un server syslog sicuro esterno al fine di ridurre al minimo le possibilità di interferenze o manomissioni.

Riepilogo

Ci auguriamo che questo blog ti abbia aiutato a comprendere meglio le best practice per la registrazione di audit in PostgreSQL e perché la creazione di un audit trail è così importante nella preparazione di un audit IT. Un audit trail fornirà una serie di informazioni pulite e utilizzabili che aiuteranno il tuo audit a procedere senza intoppi.

ClusterControl può aiutare ad automatizzare e gestire la maggior parte delle attività relative al database, garantendo al contempo la sicurezza, la disponibilità e le prestazioni del database, indipendentemente dal sistema scelto. Scarica oggi stesso una prova gratuita di ClusterControl per vedere come la tua azienda può trarre vantaggio dallo strumento e dalle operazioni che esegue. Se non l'hai già fatto, assicurati di seguirci su Twitter e LinkedIn e iscriviti al nostro feed e ci vedremo nel prossimo blog.