PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Best Practices für die PostgreSQL-Audit-Protokollierung

In jedem IT-System, in dem wichtige Geschäftsaufgaben stattfinden, ist es wichtig, über einen expliziten Satz von Richtlinien und Praktiken zu verfügen und sicherzustellen, dass diese respektiert und befolgt werden.

Einführung in die Wirtschaftsprüfung

Ein IT-Systemaudit ist die Prüfung der Richtlinien, Prozesse, Verfahren und Praktiken einer Organisation in Bezug auf die IT-Infrastruktur anhand bestimmter Ziele. Ein IT-Audit kann von zwei allgemeinen Arten sein:

  • Überprüfung anhand einer Reihe von Standards anhand einer begrenzten Teilmenge von Daten
  • Prüfung des gesamten Systems

Ein IT-Audit kann bestimmte kritische Systemteile abdecken, z. B. diejenigen im Zusammenhang mit Finanzdaten, um eine bestimmte Reihe von Vorschriften (z. B. SOX) zu unterstützen, oder die gesamte Sicherheitsinfrastruktur gegen Vorschriften wie die neue EU-DSGVO-Verordnung, die den Bedarf anspricht zum Schutz der Privatsphäre und legt die Richtlinien für die Verwaltung personenbezogener Daten fest. Das SOX-Beispiel ist vom oben beschriebenen ersteren Typ, während die DSGVO vom letzteren ist.

Der Audit-Lebenszyklus

Planung

Der Geltungsbereich einer Prüfung ist abhängig vom Prüfungsziel. Der Geltungsbereich kann eine spezielle Anwendung abdecken, die durch eine bestimmte Geschäftstätigkeit identifiziert wird, z. B. eine Finanztätigkeit, oder die gesamte IT-Infrastruktur, die Systemsicherheit, Datensicherheit usw. umfasst. Der Umfang muss bereits in einem frühen Schritt in der ersten Planungsphase korrekt identifiziert werden. Die Organisation soll dem Auditor alle notwendigen Hintergrundinformationen zur Verfügung stellen, um bei der Planung des Audits zu helfen. Dies können funktionale/technische Spezifikationen, Systemarchitekturdiagramme oder andere angeforderte Informationen sein.

Kontrollziele

Basierend auf dem Geltungsbereich bildet der Auditor eine Reihe von Kontrollzielen, die durch das Audit getestet werden sollen. Diese Kontrollziele werden über Managementpraktiken umgesetzt, die vorhanden sein sollen, um Kontrolle in dem durch den Geltungsbereich beschriebenen Umfang zu erreichen. Die Kontrollziele sind Testplänen zugeordnet und bilden zusammen das Auditprogramm. Basierend auf dem Auditprogramm Die geprüfte Organisation weist Ressourcen zu, um den Prüfer zu unterstützen.

Ergebnisse

Der Prüfer versucht nachzuweisen, dass alle Kontrollziele erreicht werden. Wenn es für ein Kontrollziel keinen solchen Nachweis gibt, versucht der Prüfer zuerst zu sehen, ob es eine alternative Möglichkeit gibt, wie das Unternehmen das spezifische Kontrollziel handhabt, und falls es eine solche gibt, wird dieses Kontrollziel als kompensierend gekennzeichnet und der Prüfer ist der Ansicht, dass das Ziel erreicht ist. Wenn es jedoch keinerlei Hinweise darauf gibt, dass ein Ziel erreicht wurde, wird dies als Befund gekennzeichnet . Jeder Befund besteht aus Zustand, Kriterien, Ursache, Wirkung und Empfehlung. Der IT-Manager muss in engem Kontakt mit dem Prüfer stehen, um über alle möglichen Feststellungen informiert zu sein, und sicherstellen, dass alle angeforderten Informationen zwischen dem Management und dem Prüfer ausgetauscht werden, um sicherzustellen, dass das Kontrollziel erreicht wird (und somit die finden).

Der Bewertungsbericht

Am Ende des Auditprozesses verfasst der Auditor einen Bewertungsbericht als Zusammenfassung, der alle wichtigen Teile des Audits umfasst, einschließlich möglicher Feststellungen, gefolgt von einer Erklärung, ob das Ziel angemessen erreicht wird, und Empfehlungen zur Beseitigung der Auswirkungen der Feststellungen.

Was ist Audit-Logging und warum sollten Sie es tun?

Der Prüfer möchte vollen Zugriff auf die Änderungen an Software, Daten und dem Sicherheitssystem haben. Er möchte nicht nur jede Änderung der Geschäftsdaten nachvollziehen können, sondern auch Änderungen am Organigramm, der Sicherheitsrichtlinie, der Definition von Rollen/Gruppen und Änderungen der Rollen-/Gruppenzugehörigkeit. Die gebräuchlichste Methode zur Durchführung eines Audits ist die Protokollierung. Obwohl es in der Vergangenheit möglich war, ein IT-Audit ohne Protokolldateien zu bestehen, ist dies heute der bevorzugte (wenn nicht der einzige) Weg.

Typischerweise besteht das durchschnittliche IT-System aus mindestens zwei Schichten:

  • Datenbank
  • Anwendung (möglicherweise auf einem Anwendungsserver)

Die Anwendung führt ihre eigenen Protokolle, die Benutzerzugriffe und -aktionen abdecken, und die Datenbank und möglicherweise die Anwendungsserversysteme führen ihre eigenen Protokolle. Saubere, leicht verwendbare Informationen in Protokolldateien, die aus Sicht des Prüfers einen echten geschäftlichen Wert haben, werden als Audit-Trail bezeichnet . Audit Trails unterscheiden sich von gewöhnlichen Protokolldateien (manchmal als native Protokolle bezeichnet) in folgendem:

  • Logfiles sind entbehrlich
  • Audit-Trails sollten länger aufbewahrt werden
  • Protokolldateien erhöhen den Overhead der Systemressourcen
  • Der Zweck der Protokolldateien besteht darin, dem Systemadministrator zu helfen
  • Audit-Trails sollen dem Auditor helfen

Wir fassen das Obige in der folgenden Tabelle zusammen:

Protokolltyp App/System Audit-Trail-freundlich
App-Protokolle App Ja
App-Serverprotokolle System Nein
Datenbankprotokolle System Nein

App-Protokolle können einfach angepasst werden, um als Audit-Trails verwendet zu werden. Systemprotokolle nicht so einfach, weil:

  • Sie sind in ihrem Format durch die Systemsoftware beschränkt
  • Sie wirken global auf das gesamte System
  • Sie haben kein direktes Wissen über den spezifischen Geschäftskontext
  • Sie benötigen normalerweise zusätzliche Software für die spätere Offline-Analyse/-Verarbeitung, um brauchbare auditfreundliche Audit-Trails zu erstellen.

Andererseits legen App-Protokolle jedoch eine zusätzliche Softwareschicht auf die eigentlichen Daten, also:

  • Das Prüfsystem anfälliger für Anwendungsfehler/Fehlkonfiguration machen
  • Schaffen einer potenziellen Lücke im Protokollierungsprozess, wenn jemand versucht, direkt auf Daten in der Datenbank zuzugreifen und dabei das App-Protokollierungssystem umgeht, z. B. ein privilegierter Benutzer oder ein DBA
  • Das Prüfungssystem wird komplexer und schwieriger zu verwalten und zu warten, falls wir viele Anwendungen oder viele Softwareteams haben.

Idealerweise würden wir also nach dem Besten der beiden suchen:Verwendbare Audit-Trails mit der größten Abdeckung des gesamten Systems, einschließlich der Datenbankschicht, und an einer Stelle konfigurierbar, so dass die Protokollierung selbst leicht mit anderen ( system)-Protokolle.

Auditprotokollierung mit PostgreSQL

Die Optionen, die wir in PostgreSQL bezüglich der Audit-Protokollierung haben, sind die folgenden:

  • Durch die Verwendung umfassender Protokollierung ( log_statement =all )
  • Indem Sie eine benutzerdefinierte Auslöserlösung schreiben
  • Durch die Verwendung von PostgreSQL-Standardtools, die von der Community bereitgestellt werden, wie z. B.
    • Audit-Trigger 91plus (https://github.com/2ndQuadrant/Audit-Trigger)
    • pgaudit-Erweiterung (https://github.com/pgaudit/pgaudit)

Eine umfassende Protokollierung zumindest für die Standardverwendung in OLTP- oder OLAP-Workloads sollte aus folgenden Gründen vermieden werden:

  • Erzeugt riesige Dateien, erhöht die Last
  • Hat kein inneres Wissen über Tabellen, auf die zugegriffen oder die geändert werden, sondern gibt nur die Anweisung aus, die ein DO-Block mit einer kryptisch verketteten Anweisung sein könnte
  • Benötigt zusätzliche Software/Ressourcen für Offline-Parsing und -Verarbeitung (um die Audit-Trails zu erstellen), die wiederum in den Umfang des Audits aufgenommen werden müssen, um als vertrauenswürdig zu gelten

Im Rest dieses Artikels werden wir die von der Community bereitgestellten Tools ausprobieren. Nehmen wir an, wir haben diese einfache Tabelle, die wir prüfen möchten:

myshop=# \d orders
                                       Table "public.orders"
   Column   |           Type           | Collation | Nullable |              Default               
------------+--------------------------+-----------+----------+------------------------------------
 id         | integer                  |           | not null | nextval('orders_id_seq'::regclass)
 customerid | integer                  |           | not null |
 customer   | text                     |           | not null |
 xtime      | timestamp with time zone   |           | not null | now()
 productid  | integer                  |           | not null |
 product    | text                     |           | not null |
 quantity   | integer                  |           | not null |
 unit_price | double precision         |           | not null |
 cur        | character varying(20)    |           | not null | 'EUR'::character varying
Indexes:
    "orders_pkey" PRIMARY KEY, btree (id)

Audit-Trigger 91plus

Die Dokumentation zur Verwendung des Triggers finden Sie hier:https://wiki.postgresql.org/wiki/Audit_trigger_91plus. Zuerst laden wir die bereitgestellte DDL (Funktionen, Schema) herunter und installieren sie:

$ wget https://raw.githubusercontent.com/2ndQuadrant/audit-trigger/master/audit.sql
$ psql myshop
psql (10.3 (Debian 10.3-1.pgdg80+1))
Type "help" for help.
myshop=# \i audit.sql

Dann definieren wir die Auslöser für unsere Tisch-Bestellungen unter Verwendung der grundlegenden Verwendung:

myshop=# SELECT audit.audit_table('orders');

Dadurch werden zwei Trigger für Tabellenaufträge erstellt:ein insert_update_delere-Zeilentrigger und ein truncate-Anweisungstrigger. Sehen wir uns nun an, was der Trigger macht:

myshop=# insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);      
INSERT 0 1
myshop=# update orders set quantity=3 where id=2;
UPDATE 1
myshop=# delete from orders  where id=2;
DELETE 1
myshop=# select table_name, action, session_user_name, action_tstamp_clk, row_data, changed_fields from audit.logged_actions;
-[ RECORD 1 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | I
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:15:10.887268+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"2", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    |
-[ RECORD 2 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | U
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:16:12.829065+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"2", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    | "quantity"=>"3"
-[ RECORD 3 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | D
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:16:24.944117+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"3", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    |

Notieren Sie den Wert der geänderten_Felder auf dem Update (RECORD 2). Es gibt fortgeschrittenere Verwendungen des Audit-Triggers, z. B. das Ausschließen von Spalten oder die Verwendung der WHEN-Klausel, wie im Dokument gezeigt. Der Audit-Trigger scheint die Aufgabe zu erfüllen, nützliche Audit-Trails in der Tabelle audit.logged_actions zu erstellen. Es gibt jedoch einige Vorbehalte:

  • Es werden keine SELECTs (Trigger werden bei SELECTs nicht ausgelöst) oder DDL verfolgt
  • Änderungen durch Tabelleneigentümer und Superuser können leicht manipuliert werden
  • In Bezug auf App-Benutzer und App-Schema- und Tabellenbesitzer müssen Best Practices befolgt werden
Laden Sie noch heute das Whitepaper PostgreSQL-Verwaltung und -Automatisierung mit ClusterControl herunterErfahren Sie, was Sie wissen müssen, um PostgreSQL bereitzustellen, zu überwachen, zu verwalten und zu skalierenLaden Sie das Whitepaper herunter

Pgaudit

Pgaudit ist die neueste Ergänzung zu PostgreSQL, was die Prüfung betrifft. Pgaudit muss als Erweiterung installiert werden, wie auf der Github-Seite des Projekts gezeigt:https://github.com/pgaudit/pgaudit. Pgaudit loggt sich in das standardmäßige PostgreSQL-Log ein. Pgaudit funktioniert, indem es sich beim Laden des Moduls selbst registriert und Hooks für executorStart, executorCheckPerms, processUtility und object_access bereitstellt. Daher unterstützt pgaudit (im Gegensatz zu Trigger-basierten Lösungen wie Audit-Trigger, die in den vorherigen Abschnitten besprochen wurden) READs (SELECT, COPY). Im Allgemeinen können wir mit pgaudit zwei Betriebsmodi haben oder sie kombiniert verwenden:

  • Sitzungs-Audit-Protokollierung
  • OBJECT-Audit-Protokollierung

Die Protokollierung der Sitzungsprüfung unterstützt die meisten DML-, DDL-, Privilegien- und Misc-Befehle über Klassen:

  • LESEN (auswählen, kopieren von)
  • WRITE (einfügen, aktualisieren, löschen, abschneiden, kopieren nach)
  • FUNCTION (Funktionsaufrufe und DO-Blöcke)
  • ROLE (Rolle erteilen, entziehen, erstellen/ändern/löschen)
  • DDL (alle DDL außer denen in ROLE)
  • MISC (Verwerfen, Abrufen, Checkpoint, Vakuum)

Die Metaklasse „all“ umfasst alle Klassen. - schließt eine Klasse aus. Lassen Sie uns zum Beispiel die Sitzungs-Audit-Protokollierung für alle außer MISC mit den folgenden GUC-Parametern in postgresql.conf konfigurieren:

pgaudit.log_catalog = off
pgaudit.log = 'all, -misc'
pgaudit.log_relation = 'on'
pgaudit.log_parameter = 'on'

Durch Eingabe der folgenden Befehle (die gleichen wie im Trigger-Beispiel)

myshop=# insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);
INSERT 0 1
myshop=# update orders set quantity=3 where id=2;
UPDATE 1
myshop=# delete from orders  where id=2;
DELETE 1
myshop=#

Wir erhalten die folgenden Einträge im PostgreSQL-Protokoll:

% tail -f data/log/postgresql-22.log | grep AUDIT:
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:37.352 EEST psql [email protected] line:7 LOG:  AUDIT: SESSION,5,1,WRITE,INSERT,TABLE,public.orders,"insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);",<none>
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:50.120 EEST psql [email protected] line:8 LOG:  AUDIT: SESSION,6,1,WRITE,UPDATE,TABLE,public.orders,update orders set quantity=3 where id=2;,<none>
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:59.888 EEST psql [email protected] line:9 LOG:  AUDIT: SESSION,7,1,WRITE,DELETE,TABLE,public.orders,delete from orders  where id=2;,<none>

Beachten Sie, dass der Text nach AUDIT:einen perfekten Prüfpfad darstellt, der fast bereit ist, an den Prüfer im tabellenkalkulationsfähigen CSV-Format gesendet zu werden. Durch die Verwendung der Protokollierung der Sitzungsüberwachung erhalten wir Überwachungsprotokolleinträge für alle Vorgänge, die zu den Klassen gehören, die durch den Parameter pgaudit.log auf all definiert sind Tische. Es gibt jedoch Fälle, in denen wir möchten, dass nur eine kleine Teilmenge der Daten, d. h. nur wenige Tabellen, geprüft werden. In solchen Fällen bevorzugen wir möglicherweise die Objekt-Audit-Protokollierung, die uns über das Berechtigungssystem von PostgreSQL feinkörnige Kriterien für ausgewählte Tabellen/Spalten liefert. Um mit der Verwendung der Objekt-Audit-Protokollierung zu beginnen, müssen wir zuerst den Parameter pgaudit.role konfigurieren, der die Master-Rolle definiert, die pgaudit verwenden wird. Es ist sinnvoll, diesem Benutzer keine Login-Rechte zu geben.

CREATE ROLE auditor;
ALTER ROLE auditor WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION NOBYPASSRLS CONNECTION LIMIT 0;

Diesen Wert geben wir für pgaudit.role in postgresql.conf an:

pgaudit.log = none # no need for extensive SESSION logging
pgaudit.role = auditor

Die Protokollierung von Pgaudit OBJECT funktioniert, indem der Benutzer auditor gefunden wird erhält (direkt oder geerbt) das Recht, die angegebene Aktion auszuführen, die für die in einer Anweisung verwendeten Beziehungen/Spalten ausgeführt wird. Wenn wir also alle Tische ignorieren müssen, aber eine detaillierte Protokollierung der Tischaufträge haben, ist dies der Weg, dies zu tun:

grant ALL on orders to auditor ;

Durch die obige Gewährung ermöglichen wir die vollständige SELECT-, INSERT-, UPDATE- und DELETE-Protokollierung von Tabellenaufträgen. Lassen Sie uns noch einmal INSERT, UPDATE, DELETE der vorherigen Beispiele geben und das postgresql-Protokoll ansehen:

% tail -f data/log/postgresql-22.log | grep AUDIT:
[local] [60683] 5b040125.ed0b 2018-05-22 14:41:41.989 EEST psql [email protected] line:7 LOG:  AUDIT: OBJECT,2,1,WRITE,INSERT,TABLE,public.orders,"insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);",<none>
[local] [60683] 5b040125.ed0b 2018-05-22 14:41:52.269 EEST psql [email protected] line:8 LOG:  AUDIT: OBJECT,3,1,WRITE,UPDATE,TABLE,public.orders,update orders set quantity=3 where id=2;,<none>
[local] [60683] 5b040125.ed0b 2018-05-22 14:42:03.148 EEST psql [email protected] line:9 LOG:  AUDIT: OBJECT,4,1,WRITE,DELETE,TABLE,public.orders,delete from orders  where id=2;,<none>

Wir stellen fest, dass die Ausgabe mit der oben besprochenen SESSION-Protokollierung identisch ist, mit dem Unterschied, dass wir anstelle von SESSION als Audit-Typ (die Zeichenfolge neben AUDIT:) jetzt OBJECT.

erhalten

Eine Einschränkung bei der OBJECT-Protokollierung besteht darin, dass TRUNCATEs nicht protokolliert werden. Dazu müssen wir auf das SESSION-Logging zurückgreifen. Aber in diesem Fall erhalten wir am Ende alle WRITE-Aktivitäten für alle Tabellen. Es gibt Gespräche zwischen den beteiligten Hackern, um jeden Befehl zu einer separaten Klasse zu machen.

Eine andere zu beachtende Sache ist, dass im Falle einer Vererbung, wenn wir dem Prüfer Zugriff auf eine untergeordnete Tabelle GEWÄHREN und nicht auf die übergeordnete Tabelle, Aktionen auf der übergeordneten Tabelle, die zu Aktionen auf Zeilen der untergeordneten Tabelle führen, nicht protokolliert werden.

Darüber hinaus müssen die für die Integrität der Protokolle verantwortlichen IT-Mitarbeiter ein strenges und genau definiertes Verfahren dokumentieren, das die Extraktion des Audit-Trails aus den PostgreSQL-Protokolldateien abdeckt. Diese Protokolle können an einen externen sicheren Syslog-Server gestreamt werden, um die Wahrscheinlichkeit von Störungen oder Manipulationen zu minimieren.

Zusammenfassung

Wir hoffen, dass dieser Blog Ihnen geholfen hat, Best Practices für die Audit-Protokollierung in PostgreSQL besser zu verstehen und warum die Erstellung eines Audit-Trails bei der Vorbereitung auf ein IT-Audit so wichtig ist. Ein Audit-Trail liefert eine Reihe von sauberen, verwendbaren Informationen, die Ihnen helfen, Ihr Audit reibungslos durchzuführen.

ClusterControl kann dabei helfen, die meisten datenbankbezogenen Aufgaben zu automatisieren und zu verwalten und gleichzeitig die Sicherheit, Verfügbarkeit und Leistung der Datenbank zu gewährleisten – unabhängig vom gewählten System. Laden Sie noch heute eine kostenlose Testversion von ClusterControl herunter, um zu sehen, wie Ihr Unternehmen von dem Tool und den damit durchgeführten Vorgängen profitieren kann. Wenn Sie es noch nicht getan haben, folgen Sie uns auf Twitter und LinkedIn und abonnieren Sie unseren Feed, und wir sehen uns im nächsten Blog.