Revision inom informationsteknologi (IT) är en process för att undersöka en organisations IT-infrastruktur för att säkerställa överensstämmelse med de krav som ställs av erkända standarder eller etablerade policyer. Dataskyddsregler, som de nya GDPR-bestämmelserna, blir allt strängare för att skydda användardata, så det är viktigt att dina databasrevisioner är korrekt inställda för att säkerställa att både din applikation och användardata är säkra från sårbarheter. I det här blogginlägget kommer vi att diskutera pgAudit – ett verktyg som genererar de revisionsloggar som behövs för att underlätta granskningen av PostgreSQL.
Vad är pgAudit?
PostgreSQL Audit Extension, pgAudit, är ett tillägg med öppen källkod som loggar händelserna i en PostgreSQL-databas i en detaljerad granskningslogg. Den använder den inbyggda PostgreSQL-loggningsfunktionen, så granskningsloggarna kommer att vara en del av PostgreSQL-loggarna. Tillägget är baserat på 2ndQuadrant pgAudit-projektet författat av Simon Riggs, Abhijit Menon-Sen och Ian Barwick, och inkluderar förbättringar av David Steele från Crunchy Data.
Varför pgAudit över log_statement=all?
Vi kan logga alla uttalanden i PostgreSQL bara genom att ställa in log_statement=all . Så varför använda pgAudit överhuvudtaget? Den grundläggande satsloggningen (med log_statement ) kommer endast att lista de operationer som utförs mot databasen. Det kommer inte att ge möjligheten att filtrera operationer, och loggarna kommer inte att ha rätt formatering som krävs för granskning. pgAudit ger dessutom granularitet för att logga specifika klasser av uttalanden som READ (VÄLJ och COPY ), SKRIV (INSERT , UPPDATERA , RADERA , etc.), DDL etc. Dessutom tillhandahåller det granskning på objektnivå där endast operationer på specifika relationer kommer att loggas.
En annan fördel med pgAudit jämfört med grundläggande uttalandeloggning är att det ger detaljerna om den utförda operationen istället för att bara logga den begärda operationen. Överväg till exempel att köra det anonyma kodblocket med en DO-sats.
DO $$ BEGIN EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)'; END $$;
Den grundläggande satsloggningen kommer att resultera i:
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 loggar samma operation som:
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>
Ovanstående indikerar tydligt pgAudit-funktionen som loggar operationen och dess interna funktioner med strukturerad utdata som förenklar sökningen.
Hur man granskar PostgreSQL med pgAuditKlicka för att tweetaHur installerar man pgAudit?
pgAudit är ett tillägg som är tillgängligt för nedladdning från PostgreSQL-förvaret, eller kan kompileras och byggas från källkod. Som ett första steg måste paketet laddas ner och installeras på maskinen som kör PostgreSQL (det här tilläggspaketet är förinstallerat på alla ScaleGrid PostgreSQL-distributioner).
När den har installerats måste den laddas in i PostgreSQL. Detta uppnås genom att lägga till pgaudit till shared_preload_libraries konfigurationsparameter. En omstart av PostgreSQL krävs för att denna konfigurationsändring ska bli effektiv. Nästa steg är att aktivera tillägget på databasen genom att köra CREATE EXTENSION pgaudit .
Nu när tillägget är klart måste vi se till att ställa in konfigurationsparametrarna för att tillägget ska börja logga. Detta kan vara så enkelt som att ställa in parametern pgaudit.log att värdera all och pgAudit kommer att börja logga in session läge.
Nu när vi vet hur man installerar och aktiverar pgAudit, låt oss diskutera de två revisionsloggningslägen som den erbjuder, session och objekt.
Sessionsgranskningsloggning
I sessionsläge loggar pgAudit alla operationer som utförs av en användare. Ställa in pgaudit.log parameter till något av de definierade värdena, annat än NONE , kommer att aktivera sessionsgranskningsloggning. pgaudit.log parametern anger klasserna av satser som kommer att loggas i sessionsläget. De möjliga värdena är:READ , SKRIV , FUNKTION , ROL , DDL , MISC , MISC_SET , ALLA och INGEN .
Ställa in pgaudit.log parameter till ALL kommer att logga alla uttalanden. Parametern kan acceptera flera klasser med hjälp av en kommaseparerad lista och specifika klasser kan uteslutas med ett –-tecken. Till exempel, om du vill logga alla satser utom MISC class, värdet för pgaudit.log kommer att vara ALL, -MISC, -MISC_SET . Du kan också göra det möjligt för pgAudit att skapa en separat loggpost för varje relationsreferens i en sats genom att ställa in pgaudit.log_relation till på.
Tänk på ett exempel på hur du skapar en tabell. SQL-satsen skulle vara:
CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));
Motsvarande granskningsloggposter är:
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>
Loggning av objektgranskning
I vissa fall kan det krävas att endast granska en specifik uppsättning relationer. I sådana fall kommer användning av sessionsläge endast att resultera i ett onödigt stort antal granskningsloggar som inte motsvarar de nödvändiga relationerna. Objektläget är speciellt lämpat för detta ändamål och kan endast granska en specifik uppsättning relationer.
Objektgranskningsloggning uppnås med hjälp av PostgreSQL-rollerna. En roll kan skapas och tilldelas behörighet för att bara komma åt en specifik uppsättning relationer. Denna roll bör specificeras i konfigurationsparametern pgaudit.role . Objektläget stöder endast SELECT , INSERT , UPPDATERA och DELETE uttalanden. Klasserna av uttalanden som loggas beror på de behörigheter som ges till rollen. Till exempel, om rollen har behörighet att endast utföra SELECT , sedan bara SELECT uttalanden kommer att loggas.
Nedan är ett exempel på objektgranskningsloggning:
Skapa en roll och bevilja endast SELECT behörigheter. Ställ in pgaudit.role till den rollen och kör SELECT SQL-sats:
CREATE ROLE audit_person; GRANT SELECT ON persons TO audit_person; SET pgaudit.role = 'audit_person'; SELECT * FROM persons WHERE ID=404;
Select-satsen ovan kommer att loggas som:
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>
|
Hur tolkar man granskningsloggposten?
Hittills har vi tillhandahållit detaljer om hur granskningsloggposten ser ut, låt oss nu ta en titt på granskningsloggpostens format. Varje post börjar med log_line_prefixet som nämns för PostgreSQL-loggning, och sedan kommer resten av utdata att vara i CSV-format. Tänk på följande enkla granskningsloggpost:
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>
I ovanstående post är värdet
2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]:
är från formatet log_line_prefix %t:%r:%u@%d:[%p]: . Granskningspostens innehåll börjar från LOGG:AUDIT: värde och det följer CSV-format. Värdeformatet har formen:
AUDIT_TYPE,STATEMENT_ID,SUBSTATEMENT_ID,CLASS,COMMAND,OBJECT_TYPE,OBJECT_NAME,STATEMENT,PARAMETER
Låt oss ta en titt på vart och ett av fälten ett efter ett:
| Fält | Beskrivning | Värde från exemplet revisionsinlägg |
|---|---|---|
| AUDIT_TYPE | Indikerar granskningsläget:SESSION eller OBJECT | OBJEKT |
| STATEMENT_ID | Unik satsidentifierare för varje session | 10 |
| SUBSTATEMENT_ID | En identifierare för varje delsats i huvudsatsen | 1 |
| KLASS | Inger klassen av uttalanden som READ, WRITE etc som är definierade värden för parametern pgaudit.log. | LÄS |
| KOMMANDO | Kommandot som används i SQL-satsen | VÄLJ |
| OBJECT_TYPE | Kan vara TABLE, INDEX, VIEW, etc. | TABELL |
| OBJECT_NAME | Det fullständiga objektnamnet | public.persons |
| UTTALANDE | Det faktiska uttalandet som körs | välj * bland personer där ID=404; |
| PARAMETER | När pgaudit.log_parametern är satt till true, listas den citerade CSV-filen med parametrar om den finns, eller "ingen" om det inte finns några parametrar. När pgaudit.log_parameter inte är inställd kommer värdet att vara " |
Inferens
pgAudit, med alla dess möjligheter, förenklar revisionsprocessen genom att generera granskningsloggen. Även om det finns några varningar, som att logga omdöpta objekt under samma namn, är det fortfarande ett robust verktyg som ger den funktionalitet som krävs. Men granskningsinformationen som skrivs i loggar är kanske inte bara idealisk för granskningsprocessen – granskningsprocessen är ännu bättre när dessa loggar kan konverteras till ett databasschema och granskningsdata kan laddas till databasen så att du enkelt kan fråga information. Det är här som PostgreSQL Audit Log Analyzer (pgAudit Analyze) är till hjälp. För mer information, se github-sidorna för pgAudit och pgAudit Analyze.