Aurora PostgreSQL auf AWS richtig auditieren: So klappt’s

Ein Audit-System für Datenbanken entsteht selten aus heiterem Himmel. Meist folgt die Architektur einem konkreten Bedarf – so auch in diesem Fall. Als ein Team plötzlich eine zuverlässige Protokollierung für direkte Schreib- und Leseoperationen in Aurora PostgreSQL auf AWS benötigte, war klar: Die Lösung würde mehr Aufwand erfordern, als anfangs vermutet.

Doch welche Schritte sind wirklich notwendig, um ein funktionierendes Audit-System für menschliche Nutzer in Aurora PostgreSQL aufzubauen? Und warum scheitern viele Ansätze bereits an grundlegenden Konfigurationen? Dieser Artikel beleuchtet die technischen Herausforderungen, typischen Fallstricke und eine bewährte Architektur, die seit Monaten stabil läuft.

Was genau wird auditiert – und warum ist das wichtig?

Das Ziel ist klar definiert: Es geht um die lückenlose Protokollierung von direkten Datenbankoperationen, die von echten Nutzern ausgeführt werden. Dazu gehören SELECT-, INSERT-, UPDATE- und DELETE-Befehle auf Anwendungstabellen.

Warum dieser Fokus? Weil Anwendungsdienste wie API-Server oder Batch-Jobs legitim Daten ändern müssen. Problematisch wird es erst, wenn Entwickler, Support-Mitarbeiter oder unautorisierte Konten direkt auf die Datenbank zugreifen. In regulierten Umgebungen sind solche Zugriffe nicht nur nachvollziehbar, sondern müssen auch in Echtzeit überwacht werden können.

Dementsprechend unterscheidet sich die Architektur grundlegend von clusterweiten Lösungen. Statt pauschal alle Operationen zu erfassen, wird pgAudit pro Nutzerkonto aktiviert – während Anwendungsdienste bewusst ausgeschlossen bleiben.

Oracle als Referenz: Was Aurora PostgreSQL anders macht

Vergleicht man die Lösung mit Oracle, wird schnell deutlich, warum Aurora PostgreSQL eine andere Herangehensweise erfordert. In Oracle können mit Unified Auditing – einem Feature der Enterprise-Version – granulare Audit-Policies definiert werden. Ein Beispiel:

CREATE AUDIT POLICY user_dml_activity 
    ACTIONS SELECT, INSERT, UPDATE, DELETE 
    ON app_schema.orders 
    WHEN 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') != ''APP_SVC_ACCOUNT''' 
    EVALUATE PER SESSION;
AUDIT POLICY user_dml_activity;

Die Protokolle landen in der strukturierten UNIFIED_AUDIT_TRAIL-Tabelle, die sich direkt mit SQL abfragen lässt. Von dort können die Daten in Tools wie Elasticsearch, Splunk oder OpenSearch exportiert werden. Anomalien wie Bulk-Deletes oder Zugriffe außerhalb der Geschäftszeiten lassen sich so automatisiert erkennen und über PagerDuty oder Opsgenie melden.

Ein entscheidender Unterschied: Bei Oracle stoppt die Datenbank, falls der Tablespace für Audit-Daten volläuft – ein bewusster Trade-off zwischen Verfügbarkeit und Compliance. Aurora PostgreSQL umgeht dieses Risiko, indem pgAudit die Logs in CloudWatch schreibt. Selbst bei Log-Problemen bleibt die Datenbank voll funktionsfähig.

Doch genau hier liegt die Herausforderung: Die Aurora-Logs sind reine Textprotokolle ohne strukturierte Abfragemöglichkeit. Statt einer SQL-Tabelle steht man vor Zeilen wie dieser:

AUDIT: SESSION,1,1,WRITE,INSERT,TABLE,public.orders,"INSERT INTO orders (customer_id, amount) VALUES ($1, $2)"

Um daraus nutzbare Metriken zu extrahieren, ist zusätzlicher Code nötig.

Die optimale Architektur für Aurora PostgreSQL

Eine stabile Audit-Lösung für Aurora PostgreSQL besteht aus mehreren Schichten, die nahtlos zusammenarbeiten. Die folgende Architektur hat sich in der Praxis bewährt:

1. Aurora PostgreSQL mit pgAudit

• Aktivierung der pgaudit-Erweiterung pro Nutzerkonto
• Log-Klasse auf all oder write setzen, um DML-Operationen zu erfassen

1. CloudWatch Logs als zentraler Sammelpunkt

• Aurora PostgreSQL schreibt alle Audit-Logs direkt in CloudWatch
• Keine lokale Speicherung von Logs – vollständige Trennung von Datenbank und Protokollen

1. EventBridge als Trigger für Verarbeitung

• Alle fünf Minuten wird eine EventBridge-Regel ausgelöst, um neue Log-Einträge zu verarbeiten

1. Lambda-Funktion zur Filterung und Aggregation

• Führt eine Log-Insights-Abfrage aus
• Filtert Störsignale wie Metadaten-Abfragen oder Toolspezifische Initialisierungsbefehle
• Zählt relevante Operationen und veröffentlicht eine Metrik in CloudWatch

1. CloudWatch-Alarm für Benachrichtigungen

• Löst aus, wenn die Metrik einen Schwellenwert überschreitet (z. B. mehr als 0 ungewöhnliche Operationen)

1. SNS als Verteiler für Vorfälle

• Benachrichtigungen werden an Incident-Plattformen wie PagerDuty oder direkt per E-Mail versendet

Ein entscheidender Vorteil dieser Architektur: Die Lambda-Funktion protokolliert nicht nur die erkannte Aktivität, sondern auch den Zeitpunkt der Erkennung – eine wichtige Information für Compliance-Anforderungen.

Typische Fallstricke und wie man sie vermeidet

1. pgAudit ist aktiviert – aber es passiert nichts

Die Aktivierung von pgAudit ist ein zweistufiger Prozess, der oft falsch verstanden wird. Zunächst muss der Parameter pgaudit in shared_preload_libraries hinzugefügt und der Cluster neu gestartet werden. Doch damit ist es nicht getan.

Fehler: Ohne die folgende Anweisung werden keine Logs erzeugt:

CREATE EXTENSION pgaudit;

Ein einfacher Check zeigt das Problem:

SELECT * FROM pg_extension WHERE extname = 'pgaudit';

Falls diese Abfrage keine Zeile zurückgibt, ist die Erweiterung nicht installiert – und die Audit-Lösung bleibt unsichtbar. Erst nach dieser Anweisung und einem erneuten ALTER USER-Befehl wie

ALTER USER john_doe SET pgaudit.log TO 'all';

beginnt die Protokollierung.

2. Das Signal-Rausch-Verhältnis ist katastrophal

Die ersten Log-Einträge aus einer Produktionsumgebung wirken oft überwältigend. Jedes Datenbank-Tool – von DBeaver bis pgAdmin – löst bei einer Verbindung eine Flut von Metadaten-Abfragen aus:

• SELECT version()
• SELECT * FROM pg_shdescription
• SET application_name='DBeaver 23.2.0'
• SELECT oid, typarray FROM pg_type

Ohne gezielte Filterung würde jede dieser Zeilen eine Alarmierung auslösen. Das Ergebnis: Warnmüdigkeit und die Gefahr, echte Vorfälle zu übersehen.

Die Lösung liegt in einer schrittweisen Anreicherung der Log-Insights-Abfrage. Ein Beispiel für eine wirksame Filterung:

fields @timestamp, @message, @logStream, @log
| filter @message like /AUDIT:/
| filter (@message like /SELECT/ or @message like /INSERT/ or @message like /UPDATE/ or @message like /DELETE/)
| filter @message not like /SELECT version()/
| filter @message not like /pg_shdescription/
| filter @message not like /pg_catalog/
| filter @message not like /information_schema/
| filter @message not like /SET application_name/

Erst durch diese feingranulare Ausfilterung werden relevante Operationen sichtbar.

Fazit: Ein Audit-System ist kein Projekt, sondern ein Prozess

Ein funktionierendes Audit-System für Aurora PostgreSQL auf AWS erfordert mehr als nur die Aktivierung einer Erweiterung. Es ist eine Kombination aus präziser Konfiguration, gezielter Log-Filterung und einer robusten Architektur, die menschliche Fehlerquellen minimiert.

Die größte Herausforderung liegt weniger in der Technik als in der kontinuierlichen Anpassung: Neue Tools, veränderte Nutzergewohnheiten und sich entwickelnde Compliance-Anforderungen machen regelmäßige Überprüfungen der Filterregeln notwendig. Wer diese Dynamik erkennt und von Anfang an auf Flexibilität setzt, vermeidet nicht nur technische Fallstricke, sondern auch die gefährlichste Falle von allen: die Illusion der Sicherheit.