PostgreSQL verbinden (pgaudit)

Detaillierter Pro-Konnektor-Leitfaden zur Beobachtung von PostgreSQL-Datenbankzugriffen durch pgAudit — Log-Format-Setup, Streaming-Aufnahme.

Der pgAudit-Konnektor verfolgt das strukturierte Audit-Log von PostgreSQL und gibt eine Zugriffskarten-Kante pro auditiertem Datenzugriff aus. Der Lese-/Schreibmodus wird wörtlich von pgAudits Klasse (READ, WRITE, DDL) übernommen — nie aus dem SQL-Text abgeleitet. Der Konnektor ist schreibgeschützt über die Logdatei und öffnet nie eine Verbindung zur Datenbank.

Für das allgemeine Quellmodell und die Config-Struktur beginnen Sie mit Eine Quelle verbinden. Diese Seite behandelt PostgreSQL-seitige Voraussetzungen, die vollständige Config-Oberfläche, Zuordnungsmechanik und betriebliche Überlegungen für Produktionsumgebungen.

PostgreSQL-Voraussetzungen

Der Konnektor liest pgAudit-Ausgabe, daher muss PostgreSQL so konfiguriert sein, dass es diese produziert. Installieren Sie die Erweiterung (apt install postgresql-<version>-pgaudit auf Debian/Ubuntu), laden Sie sie über shared_preload_libraries, starten Sie neu, dann CREATE EXTENSION pgaudit in jeder Datenbank, die Sie beobachten wollen.

Die minimalen postgresql.conf-Einstellungen für nützliche Ausgabe:

shared_preload_libraries = 'pgaudit'
pgaudit.log = 'read, write'       # READ und WRITE decken Datenzugriff ab
log_destination = 'jsonlog'        # empfohlen fuer Streaming; csvlog funktioniert auch
logging_collector = on
log_directory = '/var/log/postgresql'
log_filename = 'postgresql.json'

Neustart nach shared_preload_libraries; Reload (SELECT pg_reload_conf()) nach dem Rest. Verifizieren Sie, indem Sie eine Abfrage ausführen und bestätigen, dass ein pgAudit-Eintrag im Log erscheint — das message-Feld des Eintrags enthält die strukturierte pgAudit-Zeile (Klasse, Befehl, Objektname). Wenn nur Standard-PostgreSQL- Nachrichten erscheinen, ist die Erweiterung nicht geladen oder nicht konfiguriert.

Konfiguration

Der Konnektor wird durch kind: "pgaudit" in der OLIVARES_SOURCES_CONFIG-JSON-Datei ausgewählt. Ein vollständiges Beispiel:

{
  "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-Werte sind Zeichenketten. Die Schlüssel gehören dem pgAudit-Konnektor:

log_path (erforderlich) — absoluter Pfad zur PostgreSQL-Logdatei. Der Konnektor liest diese Datei; er entdeckt keine Logdateien per Konvention.
format — csvlog oder jsonlog. Standard ist csvlog. Steuert den Parser, den der Konnektor verwendet; er muss mit dem log_destination übereinstimmen, das PostgreSQL tatsächlich schreibt.
follow — bei "true" die Datei kontinuierlich verfolgen (Streaming-Modus). Dies gilt nur für jsonlog. Eine csvlog-Datei wird als Batch gelesen, weil CSV-Datensätze Zeilenumbrüche überspannen können, was ein Streaming-Tail unzuverlässig macht. Siehe Batch vs Streaming unten.
shared_accounts — kommagetrennte Liste von PostgreSQL-Rollen oder application_name-Werten, die über mehrere Aufrufer gepoolt oder geteilt werden. Zugriff, der einem davon zugeordnet wird, wird absichtlich als approximate markiert. Siehe Zuordnung und geteilte Konten.

Erfinden Sie keine Config-Keys über diese vier hinaus. Die Config-Oberfläche des Konnektors ist absichtlich schmal — er liest eine Logdatei, er verwaltet kein PostgreSQL.

Zuordnung und geteilte Konten

Die Zugriffskarte muss die Frage beantworten: “Welcher Agent hat das getan.” pgAudit- Log-Einträge tragen die PostgreSQL-Rolle (Benutzer) und, wenn gesetzt, den application_name der Sitzung. Der Konnektor verwendet beides, um den Ursprung der Kante zu bilden.

Pro-Agent-Identität verdient eine feste Kante. Wenn jeder Agent einen unterscheidbaren application_name auf seiner Verbindung setzt (oder eine dedizierte Rolle verwendet), ordnet der Konnektor jeden Zugriff eindeutig zu und die Kante ist firm.

Geteilte Rollen kollabieren zu approximate. Wenn mehrere Agenten einen Connection- Pool, ein gemeinsames Dienstkonto oder einen generischen application_name teilen, kann der Konnektor die Aufrufer nicht trennen. Jeder Zugriff über diese Identität wird als approximate markiert, und das Produkt sagt das offen, anstatt vorzugeben, Agenten unterscheiden zu können, die es nicht unterscheiden kann. Darum existiert shared_accounts: Das Deklarieren gepoolter Identitäten im Voraus teilt dem Konnektor mit, sie sofort als approximate zu markieren.

Die Governance-Implikation ist direkt: Eine approximate-Kante kann keinen festen Least-Privilege-Befund stützen. Wenn Sie Pro-Agent-Governance über Datenbankzugriff brauchen, geben Sie Pro-Agent-Credentials oder application_name-Werte aus. Siehe Genauigkeit für das vollständige Zuordnungsmodell.

Abdeckungsstufe

pgAudit ist clean-Abdeckung. Die READ-, WRITE- und DDL-Klassen sind autoritativ — PostgreSQLs Audit-Subsystem klassifiziert die Anweisung, und der Konnektor übernimmt diese Klassifikation wörtlich. Es gibt keine Ableitung, kein SQL-Parsing und keine Heuristik.

Der mode einer Kante ist R (Lesen), RW (Readwrite, für WRITE- und DDL-Klassen) oder wie es die Klasse vorgibt. Der Konnektor stuft nie hoch oder herab, was pgAudit gemeldet hat. Siehe Genauigkeit — Abdeckung dafür, wie clean sich mit lossy und opaque Quellen vergleicht.

Batch vs Streaming

csvlog — Batch. CSV-Datensätze können Zeilenumbrüche überspannen (eine Abfrage mit eingebetteten Zeilenumbrüchen erzeugt eine mehrzeilige Zeile), sodass ein Streaming-Tail Datensätze nicht zuverlässig trennen kann. Der Konnektor liest die Datei als vollständigen Batch; setzen Sie poll_seconds auf dem Quelleintrag, um in einem Intervall erneut auszuführen.
jsonlog mit follow: "true" — Streaming. Jeder JSON-Eintrag ist eine einzelne Zeile, sodass ein Tail sicher ist. Der Konnektor hält die Datei offen und gibt Kanten aus, während PostgreSQL sie schreibt.

Für nahezu Echtzeit-Kanten ist jsonlog mit follow die empfohlene Konfiguration. Für periodische Audits oder niedrigvolumige Datenbanken ist csvlog-Batch ausreichend.

Wie die Kanten aussehen

Jeder pgAudit-Log-Eintrag, den der Konnektor parst, erzeugt eine Zugriffskarten-Kante mit diesen Feldern:

Ursprung — die PostgreSQL-Rolle, qualifiziert durch application_name, wenn vorhanden. Beispiel: reporting_agent oder app_pool/invoice-service.
Ressource — das voll qualifizierte Objekt: database.schema.table. Beispiel: prod.public.orders.
Modus — R (von pgAudit-Klasse READ) oder RW (von pgAudit-Klasse WRITE oder DDL).
Zuordnung — firm, wenn der Ursprung sich auf eine einzelne Agentenidentität auflöst, approximate, wenn er einem shared_accounts-Eintrag entspricht oder nicht eindeutig ist.
Quelle — identifiziert diese Konnektorinstanz nach Name.

Die Kante trägt keinen SQL-Text, keine Zeilendaten und keine Abfrageparameter. Sie zeichnet nur die strukturelle Tatsache auf, dass eine Identität auf ein Objekt in einem bestimmten Modus zugegriffen hat.

Betriebliche Hinweise

Log-Rotation. Wenn PostgreSQL seine Logdatei rotiert (über log_rotation_age oder log_rotation_size), muss der Konnektor auf die aktuelle Datei zeigen. Wenn Ihre Rotation die aktive Datei umbenennt, wird der follow-Tail weiter den alten Dateideskriptor lesen, bis er erschöpft ist, und dann stoppen. Richten Sie log_path auf einen stabilen Symlink oder verwenden Sie eine Namenskonvention, der der Konnektor folgen kann. Der Konnektor verwaltet die Rotation nicht selbst.

Hochvolumige Umgebungen. pgAudit kann auf stark frequentierten Datenbanken erhebliches Log-Volumen produzieren, besonders mit pgaudit.log = 'all'. Beschränken Sie pgaudit.log auf die Klassen, die Sie brauchen (typischerweise read, write) und erwägen Sie Pro-Datenbank- oder Pro-Rollen-Filterung über pgaudit.log_relation, um Rauschen zu reduzieren, ohne Abdeckung zu verlieren.

Mehrere PostgreSQL-Instanzen. Jede Instanz braucht ihren eigenen Quelleintrag in OLIVARES_SOURCES_CONFIG mit einem eigenen name und ihrem eigenen log_path. Es gibt keine Multi-Instanz-Entdeckung — jede Quelle beobachtet genau eine Logdatei.

Berechtigungen. Der Kollektorprozess braucht Lesezugriff auf die PostgreSQL-Logdatei. Er braucht keine Datenbankverbindung, keine PostgreSQL-Rolle und keinen Netzwerkzugang zum Datenbankserver. Dateisystem-Leseberechtigung ist die einzige Anforderung.