Collegare PostgreSQL (pgaudit)

Il connettore pgAudit segue il log di audit strutturato di PostgreSQL ed emette un arco della mappa degli accessi per ogni accesso ai dati registrato. La modalità lettura/scrittura viene presa letteralmente dalla classe di pgAudit (READ, WRITE, DDL) — mai inferita dal testo SQL. Il connettore e in sola lettura sul file di log e non apre mai una connessione al database.

Per il modello sorgente generale e la struttura di configurazione, inizia con Collegare una sorgente. Questa pagina copre i prerequisiti lato PostgreSQL, la superficie di configurazione completa, la meccanica di attribuzione e le considerazioni operative per estate di produzione.

Prerequisiti PostgreSQL

Il connettore legge l’output di pgAudit, quindi PostgreSQL deve essere configurato per produrlo. Installa l’estensione (apt install postgresql-<version>-pgaudit su Debian/Ubuntu), caricala tramite shared_preload_libraries, riavvia, poi CREATE EXTENSION pgaudit in ogni database che vuoi osservare.

Le impostazioni minime di postgresql.conf per un output utile:

shared_preload_libraries = 'pgaudit'
pgaudit.log = 'read, write'       # READ and WRITE cover data access
log_destination = 'jsonlog'        # recommended for streaming; csvlog also works
logging_collector = on
log_directory = '/var/log/postgresql'
log_filename = 'postgresql.json'

Riavvia dopo shared_preload_libraries; ricarica (SELECT pg_reload_conf()) dopo il resto. Verifica eseguendo una query e confermando che una voce pgAudit appare nel log — il campo message della voce contiene la riga strutturata pgAudit (classe, comando, nome oggetto). Se appaiono solo messaggi standard di PostgreSQL, l’estensione non è caricata o non è configurata.

Configurazione

Il connettore viene selezionato con kind: "pgaudit" nel file JSON OLIVARES_SOURCES_CONFIG. Un esempio completo:

{
  "sources": [
    {
      "name": "prod-postgres",
      "kind": "pgaudit",
      "tenant": "acme",
      "config": {
        "log_path": "/var/log/postgresql/postgresql.json",
        "format": "jsonlog",
        "follow": "true",
        "shared_accounts": "app_pool,reporting"
      }
    }
  ]
}

Tutti i valori di config sono stringhe. Le chiavi sono di proprietà del connettore pgAudit:

• log_path (obbligatorio) — percorso assoluto al file di log PostgreSQL. Il connettore legge questo file; non scopre file di log per convenzione.
• format — csvlog o jsonlog. Default csvlog. Controlla il parser usato dal connettore; deve corrispondere al log_destination che PostgreSQL sta effettivamente scrivendo.
• follow — quando "true", segui il file continuamente (modalità streaming). Si applica solo a jsonlog. Un file csvlog viene letto come batch perché i record CSV possono estendersi su più righe, rendendo un tail streaming inaffidabile. Vedi Batch vs streaming sotto.
• shared_accounts — lista separata da virgola di ruoli PostgreSQL o valori application_name che sono in pool o condivisi tra più chiamanti. L’accesso attribuito a uno qualsiasi di questi viene marcato approximate deliberatamente. Vedi Attribuzione e account condivisi.

Non inventare chiavi di configurazione oltre queste quattro. La superficie di configurazione del connettore e intenzionalmente ristretta — legge un file di log, non gestisce PostgreSQL.

Attribuzione e account condivisi

La mappa degli accessi deve rispondere a “quale agente ha fatto questo”. Le voci del log pgAudit portano il ruolo (utente) PostgreSQL e, quando impostato, l’application_name della sessione. Il connettore usa entrambi per costruire l’origine dell’arco.

L’identità per agente guadagna un arco firm. Quando ogni agente imposta un application_name distinto sulla sua connessione (o usa un ruolo dedicato), il connettore attribuisce ogni accesso in modo inequivocabile e l’arco e firm.

I ruoli condivisi riducono ad approximate. Quando più agenti condividono un connection pool, un account di servizio comune o un application_name generico, il connettore non può separare i chiamanti. Ogni accesso attraverso quell’identità viene marcato approximate, e il prodotto lo dichiara apertamente anziché fingere di poter distinguere agenti che non può. Ecco perché esiste shared_accounts: dichiarare le identità in pool in anticipo dice al connettore di marcarle approximate immediatamente.

L’implicazione per la governance e diretta: un arco approximate non può supportare una segnalazione firm di privilegio minimo. Se hai bisogno di governance per agente sull’accesso al database, emetti credenziali o valori application_name per agente. Vedi Fedeltà per il modello di attribuzione completo.

Livello di copertura

pgAudit offre copertura clean. Le classi READ, WRITE e DDL sono autorevoli — il sottosistema di audit di PostgreSQL classifica la dichiarazione, e il connettore prende quella classificazione letteralmente. Non c’e inferenza, nessun parsing SQL e nessuna euristica.

La mode di un arco e R (lettura), RW (lettura-scrittura, per le classi WRITE e DDL), o lasciata come detta la classe. Il connettore non promuove ne declassa mai ciò che pgAudit ha riportato. Vedi Fedeltà — copertura per come clean si confronta con sorgenti lossy e opaque.

Batch vs streaming

• csvlog — batch. I record CSV possono estendersi su più righe (una query con newline incorporati produce una riga multilinea), quindi un tail streaming non può dividere i record in modo affidabile. Il connettore legge il file come batch completo; imposta poll_seconds sulla voce sorgente per rieseguire a intervalli.
• jsonlog con follow: "true" — streaming. Ogni voce JSON e una singola riga, quindi un tail è sicuro. Il connettore tiene il file aperto ed emette archi man mano che PostgreSQL li scrive.

Per archi quasi in tempo reale, jsonlog con follow e la configurazione raccomandata. Per audit periodici o database a volume inferiore, il batch csvlog e sufficiente.

Come appaiono gli archi

Ogni voce del log pgAudit che il connettore analizza produce un arco della mappa degli accessi con questi campi:

• Origine — il ruolo PostgreSQL, qualificato da application_name quando presente. Esempio: reporting_agent o app_pool/invoice-service.
• Risorsa — l’oggetto completamente qualificato: database.schema.tabella. Esempio: prod.public.orders.
• Modalità — R (dalla classe READ di pgAudit) o RW (dalla classe WRITE o DDL di pgAudit).
• Attribuzione — firm se l’origine si risolve a una singola identità agente, approximate se corrisponde a una voce shared_accounts o non può essere disambiguata.
• Sorgente — identifica questa istanza del connettore per nome.

L’arco non porta testo SQL, dati di riga, ne parametri di query. Registra solo il fatto strutturale che un’identità ha acceduto a un oggetto in una data modalità.

Note operative

Rotazione dei log. Quando PostgreSQL ruota il suo file di log (tramite log_rotation_age o log_rotation_size), il connettore deve essere puntato al file corrente. Se la tua rotazione rinomina il file attivo, il tail follow continuera a leggere il vecchio descrittore di file fino all’esaurimento e poi si fermera. Punta log_path a un symlink stabile o usa una convenzione di naming che il connettore possa seguire. Il connettore non gestisce la rotazione da solo.

Estate ad alto volume. pgAudit può produrre un volume di log sostanziale su database occupati, specialmente con pgaudit.log = 'all'. Circoscrivi pgaudit.log alle classi di cui hai bisogno (tipicamente read, write) e considera il filtraggio per database o per ruolo tramite pgaudit.log_relation per ridurre il rumore senza perdere copertura.

Istanze PostgreSQL multiple. Ogni istanza necessita della propria voce sorgente in OLIVARES_SOURCES_CONFIG con un name distinto e il proprio log_path. Non c’e scoperta multi-istanza — ogni sorgente monitora esattamente un file di log.

Permessi. Il processo collector necessita di accesso in lettura al file di log PostgreSQL. Non necessita di una connessione al database, di un ruolo PostgreSQL o di alcun accesso di rete al server del database. Il permesso di lettura a livello di filesystem e l’unico requisito.

Correlati

• Collegare una sorgente — il modello sorgente generale e la struttura di configurazione.
• La mappa degli accessi — ciò che questi archi costruiscono.
• Fedeltà — livelli di copertura e attribuzione.
• Trasparenza e limiti — cosa è verificato rispetto a cosa e in fase di progettazione.