sql >> Databasteknik >  >> RDS >> PostgreSQL

Hur man granskar en PostgreSQL-databas

Revision är ett bra sätt att hålla din data så säker som möjligt och att veta vad som händer i dina databaser. Det krävs också för många säkerhetsföreskrifter eller standarder, som PCI - Payment Card Industry. Detta är inget undantag för din PostgreSQL-databas.

PostgreSQL har förtjänat ett starkt rykte för sin beprövade arkitektur, tillförlitlighet, dataintegritet, robusta funktionsuppsättning, utökningsbarhet och engagemanget från öppen källkodsgemenskapen bakom programvaran för att konsekvent leverera prestanda och innovativa lösningar.

Med det sagt borde det vara ett alternativ att granska en PostgreSQL-databas, eller hur? Tja, svaret är ja. I den här bloggen kommer vi att se vad pgAudit-tillägget är och hur man installerar och använder det i din PostgreSQL-databas.

Vad är pgAudit?

PostgreSQL Audit Extension (pgAudit) tillhandahåller detaljerad sessions- och objektgranskningsloggning via den vanliga PostgreSQL-loggningsfunktionen.

Grundläggande satsloggning kan tillhandahållas av standardloggningsfunktionen med log_statement =all. Detta är acceptabelt för övervakning och andra grundläggande användningar men ger inte den detaljnivå som vanligtvis krävs för revision. Det räcker inte att ha en lista över alla operationer som utförs mot databasen. Det ska också vara möjligt att hitta särskilda uttalanden som är av intresse för en revisor. Standardloggningsfunktionen visar vad användaren begärde, medan pgAudit fokuserar på detaljerna om vad som hände medan databasen tillfredsställde begäran.

Hur man installerar pgAudit på PostgreSQL

I det här exemplet kommer vi att använda en CentOS 7-installation. Vid det här laget antog vi att du har din PostgreSQL-databas installerad, annars kan du följa det här blogginlägget för att få det igång på ett enkelt sätt med ClusterControl.

Nu bör du ha PostgreSQL-förvaret i ditt operativsystem, ungefär så här:

$ cat /etc/yum.repos.d/postgresql.repo

# PGDG Red Hat Enterprise Linux / CentOS stable common repository for all PostgreSQL versions

[pgdg-common]

name=PostgreSQL common for RHEL/CentOS $releasever - $basearch

baseurl=http://download.postgresql.org/pub/repos/yum/common/redhat/rhel-$releasever-$basearch

enabled=1

gpgcheck=0

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG

# PGDG Red Hat Enterprise Linux / CentOS stable repositories:

[pgdg]

name=PostgreSQL 12 $releasever - $basearch

#baseurl=http://yum.postgresql.org/12/redhat/rhel-$releasever-$basearch

baseurl=http://download.postgresql.org/pub/repos/yum/12/redhat/rhel-$releasever-$basearch/

enabled=1

gpgcheck=0

[pgdg-source]

name=PostgreSQL 12 $releasever - $basearch - Source

baseurl=http://yum.postgresql.org/srpms/12/redhat/rhel-$releasever-$basearch

enabled=0

gpgcheck=0

Om du kontrollerar de tillgängliga pgaudit-paketen bör du ha:

pgaudit14_12.x86_64 : PostgreSQL Audit Extension

Så, låt oss installera det:

$ yum install pgaudit14_12

Nu måste du lägga till den i postgresql.conf-konfigurationsfilen, som finns som standard i /var/lib/pgsql/12/data/postgresql.conf, och starta om PostgreSQL-tjänsten för att tillämpa förändringen.

shared_preload_libraries = 'pgaudit, pg_stat_statements'

När du har startat om din databastjänst måste du skapa tillägget:

postgres=# CREATE EXTENSION pgaudit;

CREATE EXTENSION

And now, you can run the following query to check the new extension created:

postgres=# SELECT * FROM pg_available_extensions WHERE name LIKE '%audit%';

  name   | default_version | installed_version |             comment

---------+-----------------+-------------------+---------------------------------

 pgaudit | 1.4.1           | 1.4.1             | provides auditing functionality

(1 row)

pgAudit-konfiguration

Du kan verifiera den aktuella konfigurationen genom att köra följande fråga:

postgres=# SELECT name,setting FROM pg_settings WHERE name LIKE 'pgaudit%';

            name            | setting

----------------------------+---------

 pgaudit.log                | none

 pgaudit.log_catalog        | on

 pgaudit.log_client         | off

 pgaudit.log_level          | log

 pgaudit.log_parameter      | off

 pgaudit.log_relation       | off

 pgaudit.log_statement_once | off

 pgaudit.role               |

(8 rows)

Låt oss se dessa parametrar en efter en.

  • pgaudit.log :Specificerar vilka klasser av uttalanden som kommer att loggas av sessionsrevisionsloggning. Standardinställningen är ingen. Möjliga värden är:
    • LÄS:VÄLJ och KOPIERA när källan är en relation eller en fråga.
    • SKRIV:INFOGA, UPPDATERA, DELETE, TRUNCATE och COPY när destinationen är en relation.
    • FUNKTION:Funktionsanrop och DO-block.
    • ROLL:Uttalanden relaterade till roller och privilegier:BILJA, ÅTERVÄNDA, SKAPA/ÄNDRA/SLIPPA ROLL.
    • DDL:All DDL som inte ingår i ROLE-klassen.
    • MISC:Diverse kommandon, t.ex. KASSA, HÄMT, KONTROLLPUNKT, VAKUUM, STÄLL IN.
    • MISC_SET:Diverse SET-kommandon, t.ex. SÄTT ROLL.
    • ALLA:Inkludera allt ovan.
  • pgaudit.log_catalog :Anger att sessionsloggning ska vara aktiverad i det fall där alla relationer i en sats finns i pg_catalog. Om du inaktiverar den här inställningen minskar bruset i loggen från verktyg som psql och PgAdmin som frågar mycket i katalogen. Standard är på.
  • pgaudit.log_client :Anger om loggmeddelanden ska vara synliga för en klientprocess som psql. Denna inställning bör i allmänhet lämnas inaktiverad men kan vara användbar för felsökning eller andra ändamål. Standardinställningen är av.
  • pgaudit.log_level :Anger loggnivån som kommer att användas för loggposter. Den här inställningen används för regressionstestning och kan även vara användbar för slutanvändare för testning eller andra ändamål. Standard är logg.
  • pgaudit.log_parameter :Anger att granskningsloggning ska inkludera parametrarna som skickades med uttalandet. När parametrar finns kommer de att inkluderas i CSV-format efter satstexten. Standardinställningen är av.
  • pgaudit.log_relation :Anger om sessionsrevisionsloggning ska skapa en separat loggpost för varje relation (TABLE, VIEW, etc.) som refereras till i en SELECT- eller DML-sats. Detta är en användbar genväg för uttömmande loggning utan att använda objektgranskningsloggning. Standardinställningen är av.
  • pgaudit.log_statement_once :Anger om loggning kommer att inkludera satstexten och parametrarna med den första loggposten för en sats/delsatskombination eller med varje post. Att inaktivera den här inställningen kommer att resultera i mindre utförlig loggning men kan göra det svårare att avgöra vilken sats som genererade en loggpost, även om sats-/delsatsparet tillsammans med process-id borde räcka för att identifiera satstexten som loggats med en tidigare post. Standardinställningen är av.
  • pgaudit.role :Anger huvudrollen som ska användas för objektgranskningsloggning. Flera revisionsroller kan definieras genom att tilldela dem till huvudrollen. Detta gör att flera grupper kan ansvara för olika aspekter av revisionsloggning. Det finns ingen standard.

pgAudit-användning

Nu har vi granskat konfigurationsparametrarna, låt oss se ett exempel på hur man använder det i den verkliga världen.

För att granska alla läs-, skriv- och DDL-frågor, kör:

test1=# set pgaudit.log = 'read,write,ddl';

SET

Och kör sedan följande meningar:

test1=# CREATE TABLE table1 (id int, name text);

CREATE TABLE

test1=# INSERT INTO table1 (id, name) values (1, 'name1');

INSERT 0 1

test1=# INSERT INTO table1 (id, name) values (2, 'name2');

INSERT 0 1

test1=# INSERT INTO table1 (id, name) values (3, 'name3');

INSERT 0 1

test1=# SELECT * FROM table1;

 id | name

----+-------

  1 | name1

  2 | name2

  3 | name3

(3 rows)

Om du kontrollerar PostgreSQL-loggfilen ser du detta:

2020-11-20 19:17:13.848 UTC [25142] LOG:  AUDIT: SESSION,3,1,DDL,CREATE TABLE,,,"CREATE TABLE table1 (id int, name text);",<not logged>

2020-11-20 19:18:45.334 UTC [25142] LOG:  AUDIT: SESSION,4,1,WRITE,INSERT,,,"INSERT INTO table1 (id, name) values (1, 'name1');",<not logged>

2020-11-20 19:18:52.332 UTC [25142] LOG:  AUDIT: SESSION,5,1,WRITE,INSERT,,,"INSERT INTO table1 (id, name) values (2, 'name2');",<not logged>

2020-11-20 19:18:58.103 UTC [25142] LOG:  AUDIT: SESSION,6,1,WRITE,INSERT,,,"INSERT INTO table1 (id, name) values (3, 'name3');",<not logged>

2020-11-20 19:19:07.261 UTC [25142] LOG:  AUDIT: SESSION,7,1,READ,SELECT,,,SELECT * FROM table1;,<not logged>

Det här är naturligtvis ett grundläggande exempel. Du kan använda konfigurationsparametrarna som beskrivs i föregående avsnitt för att passa din verksamhet.

Aktivera pgAudit med ClusterControl

Istället för att installera och aktivera pgAudit manuellt, är ett annat alternativ att använda ClusterControl CLI för att göra jobbet åt dig. För detta kan du köra följande kommando från din ClusterControl-server:

$ s9s cluster --setup-audit-logging --cluster-id=ID

Där ID är PostgreSQL-kluster-id.

Medan den körs kan du övervaka statusen genom att kontrollera ClusterControl-jobbet. Först behöver du jobb-id:t som du kan få från jobblistan:

$ s9s job --list

163  18 RUNNING  test_dba                     admins 19:41:45            90% Setup Audit Logging

Kontrollera nu jobbdetaljerna:

$ s9s job --log --job-id=163

Using SSH credentials from cluster.

Cluster ID is 18.

The username is 'root'.

10.10.10.129:5432: Configuring audit logging.

10.10.10.129:5432: Installing 'pgaudit14_12'.

10.10.10.129:5432: Setting pgaudit.log to ROLE,DDL,MISC.

Writing file '10.10.10.129:/var/lib/pgsql/12/data/postgresql.conf'.

10.10.10.129:5432: Restarting PostgreSQL node.

10.10.10.129: waiting for server to shut down.... done

server stopped

waiting for server to start....2020-11-20 19:41:52.069 UTC [25137] LOG:  pgaudit extension initialized

2020-11-20 19:41:52.069 UTC [25137] LOG:  starting PostgreSQL 12.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit

2020-11-20 19:41:52.069 UTC [25137] LOG:  listening on IPv4 address "0.0.0.0", port 5432

2020-11-20 19:41:52.069 UTC [25137] LOG:  listening on IPv6 address "::", port 5432

2020-11-20 19:41:52.080 UTC [25137] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"

2020-11-20 19:41:52.102 UTC [25137] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"

2020-11-20 19:41:52.130 UTC [25137] LOG:  redirecting log output to logging collector process

2020-11-20 19:41:52.130 UTC [25137] HINT:  Future log output will appear in directory "log".

 done

server started

10.10.10.129:5432: Waiting for node to be accessible.

10.10.10.129:5432: pgaudit 1.4.1 is enabled.

Den här åtgärden kräver en omstart av databastjänsten som kommer att utföras av ClusterControl i samma uppgift. Efter omstart är tillägget pgAudit aktiverat och redo att användas:

postgres=# SELECT * FROM pg_available_extensions WHERE name LIKE '%audit%';

  name   | default_version | installed_version |             comment

---------+-----------------+-------------------+---------------------------------

 pgaudit | 1.4.1           | 1.4.1             | provides auditing functionality

(1 row)

Det är allt! Du kan nu konfigurera och använda pgAudit på samma sätt som vi visade tidigare.

Slutsats

Revision krävs för många säkerhetsföreskrifter och det är också användbart om du vill veta vad som hände i din databas, och när och vem som var ansvarig för det.

I den här bloggen pratade vi om tillägget pgAudit PostgreSQL som ett bra sätt att granska dina PostgreSQL-databaser, och vi visade dig också hur du implementerar det både manuellt och med ClusterControl CLI.

Tänk på att det, beroende på konfigurationen, är möjligt för pgAudit att generera en enorm mängd data. Så du bör vara noga med att avgöra vad du behöver granska och hur länge.


  1. Kan jag köra flera frågor separerade med semikolon med MySQL Connector/J?

  2. cron jobb för att ta bort gammal data från postgres på debian

  3. Hur Round() fungerar i PostgreSQL

  4. Få kolumninformation för en tabell eller vy i SQL Server (T-SQL:sp_columns)