Auditing von PostgreSQL mit pgAudit

Audit in der Informationstechnologie (IT) ist ein Prozess zur Untersuchung der IT-Infrastruktur einer Organisation, um sicherzustellen, dass sie die Anforderungen anerkannter Standards oder etablierter Richtlinien erfüllt. Datenschutzvorschriften wie die neuen DSGVO-Vorschriften werden immer strenger, um Benutzerdaten zu schützen. Daher ist es wichtig, dass Ihre Datenbankprüfungen ordnungsgemäß eingerichtet sind, um sicherzustellen, dass sowohl Ihre Anwendung als auch Ihre Benutzerdaten vor Schwachstellen geschützt sind. In diesem Blog-Beitrag werden wir pgAudit besprechen – ein Tool, das die Audit-Protokolle generiert, die zur Erleichterung der Überwachung von PostgreSQL benötigt werden.

Was ist pgAudit?

Die PostgreSQL-Audit-Erweiterung, pgAudit, ist eine Open-Source-Erweiterung, die die Ereignisse in einer PostgreSQL-Datenbank in einem detaillierten Audit-Protokoll protokolliert. Es verwendet die native PostgreSQL-Protokollierungsfunktion, sodass die Audit-Protokolle Teil der PostgreSQL-Protokolle sind. Die Erweiterung basiert auf dem 2ndQuadrant pgAudit-Projekt, das von Simon Riggs, Abhijit Menon-Sen und Ian Barwick verfasst wurde, und enthält Verbesserungen von David Steele von Crunchy Data.

Warum pgAudit statt log_statement=all?

Wir können alle Anweisungen in PostgreSQL protokollieren, indem wir einfach log_statement=all setzen . Warum also überhaupt pgAudit verwenden? Die grundlegende Anweisungsprotokollierung (mithilfe von log_statement ) listet nur die Operationen auf, die für die Datenbank ausgeführt werden. Es bietet keine Möglichkeit, Vorgänge zu filtern, und die Protokolle haben nicht die richtige Formatierung, die für die Überwachung erforderlich ist. pgAudit bietet zusätzlich Granularität zum Protokollieren bestimmter Klassen von Anweisungen wie READ (SELECT und COPY ), WRITE (INSERT , UPDATE , DELETE usw.), DDL usw. Darüber hinaus bietet es Auditing auf Objektebene, bei dem nur Vorgänge für bestimmte Beziehungen protokolliert werden.

Ein weiterer Vorteil von pgAudit gegenüber der einfachen Anweisungsprotokollierung besteht darin, dass es die Details der durchgeführten Operation liefert, anstatt nur die angeforderte Operation zu protokollieren. Ziehen Sie beispielsweise in Erwägung, den anonymen Codeblock mit einer DO-Anweisung auszuführen.

DO $$
BEGIN
	EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;

Die Protokollierung der grundlegenden Anweisung führt zu:

2020-12-20 23:40:11 UTC:157.230.232.139(53064):sgpostgres@test:[9091]: LOG:  statement: DO $$
        BEGIN
            EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
        END $$;

pgAudit protokolliert dieselbe Operation wie:

2020-12-20 23:40:11 UTC:157.230.232.139(53064):sgpostgres@test:[9091]: LOG:  AUDIT: SESSION,4,1,FUNCTION,DO,,,"DO $$
        BEGIN
            EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
        END $$;",<not logged>
2020-12-20 23:40:11 UTC:157.230.232.139(53064):sgpostgres@test:[9091]: LOG:  AUDIT: SESSION,4,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT),<not logged>

Das Obige zeigt deutlich die pgAudit-Funktionalität, die die Operation und ihre Interna mit strukturierter Ausgabe protokolliert, die die Suche erleichtert.

Wie installiere ich pgAudit?

pgAudit ist eine Erweiterung, die aus dem PostgreSQL-Repository heruntergeladen oder aus dem Quellcode kompiliert und erstellt werden kann. Als erster Schritt muss das Paket heruntergeladen und auf dem Computer installiert werden, auf dem PostgreSQL ausgeführt wird (dieses Erweiterungspaket ist auf allen PostgreSQL-Bereitstellungen von ScaleGrid vorinstalliert).

Nach der Installation muss es in PostgreSQL geladen werden. Dies wird durch Hinzufügen von pgaudit erreicht zu den shared_preload_libraries Konfigurationsparameter. Damit diese Konfigurationsänderung wirksam wird, ist ein Neustart von PostgreSQL erforderlich. Der nächste Schritt besteht darin, die Erweiterung in der Datenbank zu aktivieren, indem Sie CREATE EXTENSION pgaudit ausführen .

Nun, da die Erweiterung bereit ist, müssen wir sicherstellen, dass die Konfigurationsparameter für die Erweiterung festgelegt werden, um mit der Protokollierung zu beginnen. Dies kann so einfach sein wie das Setzen des Parameters pgaudit.log um all zu bewerten und pgAudit beginnt mit der Anmeldung in session Modus.

Nun, da wir wissen, wie man pgAudit installiert und aktiviert, lassen Sie uns die beiden Audit-Protokollierungsmodi besprechen, die es bietet, Sitzung und Objekt.

Sitzungs-Audit-Protokollierung

Im Sitzungsmodus protokolliert pgAudit alle von einem Benutzer durchgeführten Vorgänge. Setzen der pgaudit.log -Parameter auf einen der definierten Werte, außer NONE , aktiviert die Protokollierung der Sitzungsüberwachung. Die pgaudit.log Der Parameter gibt die Klassen von Anweisungen an, die im Sitzungsmodus protokolliert werden. Die möglichen Werte sind:READ , WRITE , FUNCTION , ROLE , DDL , MISC , MISC_SET , ALL und NONE .

Setzen der pgaudit.log Parameter auf ALL wird alle Aussagen protokollieren. Der Parameter kann mehrere Klassen mit einer durch Kommas getrennten Liste akzeptieren und bestimmte Klassen können mit einem – Zeichen ausgeschlossen werden. Zum Beispiel, wenn Sie alle Anweisungen außer MISC protokollieren möchten Klasse, der Wert von pgaudit.log wird ALL, -MISC, -MISC_SET sein . Sie können pgAudit auch aktivieren, um einen separaten Protokolleintrag für jede Beziehungsreferenz in einer Anweisung zu erstellen, indem Sie pgaudit.log_relation festlegen ein.

Betrachten Sie ein Beispiel zum Erstellen einer Tabelle. Die SQL-Anweisung wäre:

CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));

Die entsprechenden Prüfprotokolleinträge sind:

2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,CREATE SEQUENCE,SEQUENCE,public.persons_id_seq,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>
2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,CREATE TABLE,TABLE,public.persons,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>
2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,CREATE INDEX,INDEX,public.persons_pkey,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>
2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,ALTER SEQUENCE,SEQUENCE,public.persons_id_seq,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>

Objekt-Audit-Protokollierung

In bestimmten Fällen kann es erforderlich sein, nur einen bestimmten Satz von Beziehungen zu prüfen. In solchen Fällen führt die Verwendung des Sitzungsmodus nur zu einer unnötig großen Anzahl von Audit-Protokollen, die nicht den erforderlichen Beziehungen entsprechen. Der Objektmodus ist für diesen Zweck besonders geeignet und kann nur einen bestimmten Satz von Beziehungen prüfen.

Objekt-Audit-Protokollierung wird mithilfe der PostgreSQL-Rollen erreicht. Eine Rolle kann erstellt und ihr die Berechtigungen zugewiesen werden, nur auf einen bestimmten Satz von Beziehungen zuzugreifen. Diese Rolle sollte im Konfigurationsparameter pgaudit.role angegeben werden . Der Objektmodus unterstützt nur SELECT , INSERT , UPDATE und DELETE Aussagen. Die Klassen von Anweisungen, die protokolliert werden, hängen von den Berechtigungen ab, die der Rolle erteilt wurden. Zum Beispiel, wenn die Rolle die Berechtigung hat, nur SELECT auszuführen , dann nur noch SELECT Anweisungen werden protokolliert.

Unten ist ein Beispiel für die Objekt-Audit-Protokollierung:

Erstellen Sie eine Rolle und gewähren Sie nur SELECT Berechtigungen. Legen Sie die pgaudit.role fest zu dieser Rolle und führen Sie SELECT aus SQL-Anweisung:

CREATE ROLE audit_person;
GRANT SELECT ON persons TO audit_person;
SET pgaudit.role = 'audit_person';
SELECT * FROM persons WHERE ID=404;

Die obige select-Anweisung wird protokolliert als:

2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]: LOG:  AUDIT: OBJECT,10,1,READ,SELECT,TABLE,public.persons,select * from persons where ID=404;,<not logged>

Wie interpretiert man den Audit-Log-Eintrag?

Bisher haben wir Details dazu bereitgestellt, wie der Audit-Log-Eintrag aussieht, jetzt werfen wir einen Blick auf das Format des Audit-Log-Eintrags. Jeder Eintrag beginnt mit dem für die PostgreSQL-Protokollierung erwähnten log_line_prefix, und der Rest der Ausgabe erfolgt im CSV-Format. Betrachten Sie den folgenden einfachen Überwachungsprotokolleintrag:

2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]: LOG:  AUDIT: OBJECT,10,1,READ,SELECT,TABLE,public.persons,select * from persons where ID=404;,<not logged>

Im obigen Eintrag ist der Wert

2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]: 

hat das Format log_line_prefix %t:%r:%u@%d:[%p]: . Der Inhalt des Prüfeintrags beginnt mit LOG: AUDIT: Wert und folgt dem CSV-Format. Das Werteformat hat folgende Form:

AUDIT_TYPE,STATEMENT_ID,SUBSTATEMENT_ID,CLASS,COMMAND,OBJECT_TYPE,OBJECT_NAME,STATEMENT,PARAMETER

Sehen wir uns die einzelnen Felder einzeln an:

Schlussfolgerung

pgAudit vereinfacht mit all seinen Möglichkeiten den Audit-Prozess, indem es das Audit-Trail-Protokoll generiert. Obwohl es einige Vorbehalte gibt, wie das Protokollieren umbenannter Objekte unter demselben Namen, ist es immer noch ein robustes Tool, das die erforderliche Funktionalität bietet. Die in Protokolle geschriebenen Audit-Informationen sind jedoch möglicherweise nicht nur ideal für den Audit-Prozess – der Audit-Prozess ist sogar noch besser, wenn diese Protokolle in ein Datenbankschema konvertiert werden können und Audit-Daten in die Datenbank geladen werden können, sodass Sie sie einfach abfragen können Information. Hier hilft der PostgreSQL Audit Log Analyzer (pgAudit Analyze). Weitere Informationen finden Sie auf den GitHub-Seiten von pgAudit und pgAudit Analyze.