PostgreSQL aansluiten (pgaudit)

De pgAudit-connector tailt het gestructureerde auditlog van PostgreSQL en zendt één toegangskaart-verbinding per geauditeerde datatoegang uit. De lees/schrijf- modus wordt letterlijk overgenomen van pgAudit’s klasse (READ, WRITE, DDL) — nooit afgeleid uit de SQL-tekst. De connector is read-only over het logbestand en opent nooit een verbinding naar de database.

Voor het algemene bronmodel en de configstructuur, begin met Een bron aansluiten. Deze pagina behandelt PostgreSQL-zijde vereisten, het volledige configoppervlak, attributiemechanismen en operationele overwegingen voor productiedomeinen.

PostgreSQL-vereisten

De connector leest pgAudit-uitvoer, dus PostgreSQL moet geconfigureerd zijn om het te produceren. Installeer de extensie (apt install postgresql-<version>-pgaudit op Debian/Ubuntu), laad het via shared_preload_libraries, herstart, dan CREATE EXTENSION pgaudit in elke database die je wilt observeren.

De minimale postgresql.conf-instellingen voor bruikbare uitvoer:

shared_preload_libraries = 'pgaudit'
pgaudit.log = 'read, write'       # READ en WRITE dekken datatoegang
log_destination = 'jsonlog'        # aanbevolen voor streaming; csvlog werkt ook
logging_collector = on
log_directory = '/var/log/postgresql'
log_filename = 'postgresql.json'

Herstart na shared_preload_libraries; herlaad (SELECT pg_reload_conf()) na de rest. Verifieer door een query uit te voeren en te bevestigen dat een pgAudit-entry verschijnt in het log — het message-veld van de entry bevat de pgAudit gestructureerde regel (klasse, commando, objectnaam). Als alleen standaard PostgreSQL-berichten verschijnen, is de extensie niet geladen of niet geconfigureerd.

Configuratie

De connector wordt geselecteerd door kind: "pgaudit" in het OLIVARES_SOURCES_CONFIG JSON- bestand. Een volledig voorbeeld:

{
  "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"
      }
    }
  ]
}

Alle config-waarden zijn strings. De sleutels zijn eigendom van de pgAudit-connector:

• log_path (vereist) — absoluut pad naar het PostgreSQL-logbestand. De connector leest dit bestand; het ontdekt geen logbestanden op conventie.
• format — csvlog of jsonlog. Standaard csvlog. Bepaalt de parser die de connector gebruikt; het moet overeenkomen met de log_destination die PostgreSQL daadwerkelijk schrijft.
• follow — wanneer "true", tail het bestand continu (streamingmodus). Dit geldt alleen voor jsonlog. Een csvlog-bestand wordt altijd gelezen als batch omdat CSV-records meerdere regels kunnen beslaan, wat een streaming tail onbetrouwbaar maakt. Zie Batch versus streaming hieronder.
• shared_accounts — kommagescheiden lijst van PostgreSQL-rollen of application_name-waarden die gepoold of gedeeld worden over meerdere aanroepers. Toegang geattribueerd aan een van deze wordt bewust gemarkeerd als approximate. Zie Attributie en gedeelde accounts.

Verzin geen configsleutels buiten deze vier. Het configoppervlak van de connector is bewust smal — het leest een logbestand, het beheert geen PostgreSQL.

Attributie en gedeelde accounts

De toegangskaart moet antwoorden “welke agent deed dit.” pgAudit-logentries bevatten de PostgreSQL-rol (gebruiker) en, wanneer ingesteld, de application_name van de sessie. De connector gebruikt beide om de oorsprong van de verbinding op te bouwen.

Per-agent-identiteit verdient een firm verbinding. Wanneer elke agent een aparte application_name instelt op zijn verbinding (of een toegewezen rol gebruikt), attribueert de connector elke toegang ondubbelzinnig en de verbinding is firm.

Gedeelde rollen comprimeren naar approximate. Wanneer meerdere agents een connection pool, een gemeenschappelijk serviceaccount of een generieke application_name delen, kan de connector aanroepers niet scheiden. Elke toegang via die identiteit wordt gemarkeerd als approximate, en het product zegt dat openlijk in plaats van te doen alsof het agents kan onderscheiden die het niet kan. Daarom bestaat shared_accounts: het vooraf declareren van gepoolde identiteiten vertelt de connector om ze onmiddellijk als approximate te markeren.

De bestuursimplicatie is direct: een approximate verbinding kan geen firm least-privilege-bevinding ondersteunen. Als je per-agent bestuur over databasetoegang nodig hebt, geef per-agent credentials of application_name-waarden uit. Zie Betrouwbaarheid voor het volledige attributiemodel.

Dekkingstier

pgAudit is clean dekking. De READ-, WRITE- en DDL-klassen zijn gezaghebbend — het auditsubsysteem van PostgreSQL classificeert de statement, en de connector neemt die classificatie letterlijk over. Er is geen inferentie, geen SQL-parsing en geen heuristiek.

De mode van een verbinding is R (lezen), RW (leesschrijven, voor WRITE- en DDL-klassen), of wordt gelaten zoals de klasse dicteert. De connector upgradet of degradeert nooit wat pgAudit rapporteerde. Zie Betrouwbaarheid — dekking voor hoe clean zich verhoudt tot lossy en opaque bronnen.

Batch versus streaming

• csvlog — batch. CSV-records kunnen meerdere regels beslaan (een query met ingebedde newlines produceert een meerregelige rij), dus een streaming tail kan records niet betrouwbaar splitsen. De connector leest het bestand als een complete batch; stel poll_seconds in op de bronentry om op een interval opnieuw te draaien.
• jsonlog met follow: "true" — streaming. Elke JSON-entry is een enkele regel, dus een tail is veilig. De connector houdt het bestand open en zendt verbindingen uit terwijl PostgreSQL ze schrijft.

Voor bijna-realtime verbindingen is jsonlog met follow de aanbevolen configuratie. Voor periodieke audits of databases met lager volume is csvlog batch voldoende.

Hoe de verbindingen eruitzien

Elke pgAudit-logentry die de connector parseert produceert één toegangskaart-verbinding met deze velden:

• Oorsprong — de PostgreSQL-rol, gekwalificeerd door application_name wanneer aanwezig. Voorbeeld: reporting_agent of app_pool/invoice-service.
• Resource — het volledig gekwalificeerde object: database.schema.tabel. Voorbeeld: prod.public.orders.
• Modus — R (van pgAudit-klasse READ) of RW (van pgAudit-klasse WRITE of DDL).
• Attributie — firm als de oorsprong resolvet naar een enkele agentidentiteit, approximate als het overeenkomt met een shared_accounts-entry of niet kan worden gedesambigueerd.
• Bron — identificeert deze connectorinstantie op naam.

De verbinding bevat geen SQL-tekst, geen rijdata en geen queryparameters. Het registreert alleen het structurele feit dat een identiteit een object heeft benaderd in een gegeven modus.

Operationele opmerkingen

Logrotatie. Wanneer PostgreSQL zijn logbestand roteert (via log_rotation_age of log_rotation_size), moet de connector naar het huidige bestand wijzen. Als je rotatie het actieve bestand hernoemt, zal de follow tail het oude bestandsdescriptor blijven lezen totdat het is uitgeput en dan stoppen. Wijs log_path naar een stabiele symlink of gebruik een naamgevingsconventie die de connector kan volgen. De connector beheert rotatie niet zelf.

Drukke domeinen. pgAudit kan aanzienlijk logvolume produceren op drukke databases, vooral met pgaudit.log = 'all'. Beperk pgaudit.log tot de klassen die je nodig hebt (typisch read, write) en overweeg per-database of per-rol filtering via pgaudit.log_relation om ruis te verminderen zonder dekking te verliezen.

Meerdere PostgreSQL-instanties. Elke instantie heeft zijn eigen bronentry nodig in OLIVARES_SOURCES_CONFIG met een aparte name en zijn eigen log_path. Er is geen multi-instantie-ontdekking — elke bron bewaakt precies één logbestand.

Rechten. Het collectorproces heeft leestoegang nodig tot het PostgreSQL-logbestand. Het heeft geen databaseverbinding, PostgreSQL-rol of netwerktoegang tot de databaseserver nodig. Bestandssysteem-leesrecht is de enige vereiste.

Gerelateerd

• Een bron aansluiten — het algemene bronmodel en configstructuur.
• De toegangskaart — wat deze verbindingen opbouwen.
• Betrouwbaarheid — dekking- en attributietiers.
• Eerlijkheid en beperkingen — wat geverifieerd is versus design-fase.