Revision i informationsteknologi (IT) er en proces, hvor man undersøger en organisations it-infrastruktur for at sikre overholdelse af de krav, der stilles af anerkendte standarder eller etablerede politikker. Databeskyttelsesregler, såsom de nye GDPR-regler, bliver stadig mere stringente for at beskytte brugerdata, så det er vigtigt, at dine databaserevisioner er sat ordentligt op for at sikre, at både din applikation og brugerdata er sikret mod sårbarheder. I dette blogindlæg vil vi diskutere pgAudit – et værktøj, der genererer de revisionslogfiler, der er nødvendige for at lette revisionen af PostgreSQL.
Hvad er pgAudit?
PostgreSQL Audit Extension, pgAudit, er en open source-udvidelse, der logger hændelserne i en PostgreSQL-database i en detaljeret revisionslog. Den bruger den oprindelige PostgreSQL-logningsfacilitet, så revisionsloggene vil være en del af PostgreSQL-logfilerne. Udvidelsen er baseret på 2ndQuadrant pgAudit-projektet forfattet af Simon Riggs, Abhijit Menon-Sen og Ian Barwick og inkluderer forbedringer af David Steele fra Crunchy Data.
Hvorfor pgAudit over log_statement=all?
Vi kan logge alle udsagn i PostgreSQL blot ved at indstille log_statement=all . Så hvorfor overhovedet bruge pgAudit? Den grundlæggende sætningslogning (ved hjælp af log_statement ) vil kun vise de operationer, der udføres mod databasen. Det giver ikke mulighed for at filtrere operationer, og logfilerne vil ikke være i den korrekte formatering, der kræves til revision. pgAudit giver desuden granularitet til at logge specifikke klasser af udsagn som READ (VÆLG og COPY ), SKRIV (INDSÆT , OPDATERING , SLET osv.), DDL osv. Desuden giver det objektniveau revision, hvor kun operationer på specifikke relationer vil blive logget.
En anden fordel ved pgAudit i forhold til grundlæggende logning af erklæringer er, at det giver detaljerne om den udførte operation i stedet for blot at logge den anmodede handling. Overvej f.eks. at udføre den anonyme kodeblok ved hjælp af en DO-sætning.
DO $$ BEGIN EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)'; END $$;
Den grundlæggende sætningslogning vil resultere 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 vil logge den samme handling 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>
Ovenstående angiver tydeligt pgAudit-funktionaliteten, der logger operationen og dens interne funktioner med struktureret output, der letter søgningen.
Sådan reviderer du PostgreSQL ved hjælp af pgAuditKlik for at tweeteHvordan installeres pgAudit?
pgAudit er en udvidelse, der er tilgængelig til download fra PostgreSQL-lageret, eller som kan kompileres og bygges fra kilden. Som et første trin skal pakken downloades og installeres på maskinen, der kører PostgreSQL (denne udvidelsespakke er forudinstalleret på alle ScaleGrid PostgreSQL-implementeringer).
Når den er installeret, skal den indlæses i PostgreSQL. Dette opnås ved at tilføje pgaudit til shared_preload_libraries konfigurationsparameter. En genstart af PostgreSQL er påkrævet for at denne konfigurationsændring er effektiv. Det næste trin er at aktivere udvidelsen på databasen ved at køre CREATE EXTENSION pgaudit .
Nu hvor udvidelsen er klar, skal vi sørge for at indstille konfigurationsparametrene for udvidelsen for at begynde at logge. Dette kan være så simpelt som at indstille parameteren pgaudit.log at værdisætte alle og pgAudit vil begynde at logge på session tilstand.
Nu hvor vi ved, hvordan man installerer og aktiverer pgAudit, lad os diskutere de to revisionslogningstilstande, det tilbyder, session og objekt.
Sessionsrevisionslogning
I sessionstilstand vil pgAudit logge alle handlinger udført af en bruger. Indstilling af pgaudit.log parameter til enhver af de definerede værdier, bortset fra NONE , vil aktivere logning af sessionsrevision. pgaudit.log parameter angiver de klasser af udsagn, der vil blive logget i sessionstilstand. De mulige værdier er:READ , SKRIV , FUNKTION , ROLE , DDL , MISC , MISC_SET , ALLE og INGEN .
Indstilling af pgaudit.log parameter til ALL vil logge alle udsagn. Parameteren kan acceptere flere klasser ved hjælp af en kommasepareret liste, og specifikke klasser kan udelukkes med et –-tegn. For eksempel, hvis du vil logge alle udsagn undtagen MISC klasse, værdien af pgaudit.log vil være ALL, -MISC, -MISC_SET . Du kan også aktivere pgAudit til at oprette en separat logindgang for hver relationsreference i en sætning ved at indstille pgaudit.log_relation til på.
Overvej et eksempel på oprettelse af en tabel. SQL-sætningen ville være:
CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));
De tilsvarende revisionslogposter er:
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>
Logføring af objektrevision
I særlige tilfælde kan det være nødvendigt kun at revidere et specifikt sæt af relationer. I sådanne tilfælde vil brug af sessionstilstand kun resultere i et unødvendigt stort antal revisionslogfiler, der ikke svarer til de påkrævede relationer. Objekttilstand er specielt velegnet til dette formål og kan kun auditere et specifikt sæt af relationer.
Objektrevisionslogning opnås ved hjælp af PostgreSQL-rollerne. En rolle kan oprettes og tildeles tilladelser til kun at få adgang til et specifikt sæt af relationer. Denne rolle skal angives i konfigurationsparameteren pgaudit.role . Objekttilstand understøtter kun SELECT , INDSÆT , OPDATERING og SLET udsagn. Klasserne af udsagn, der logges, afhænger af de tilladelser, der er givet til rollen. For eksempel, hvis rollen kun har tilladelse til at udføre SELECT , derefter kun SELECT udsagn vil blive logget.
Nedenfor er et eksempel på logning af objektrevision:
Opret en rolle og tildel kun SELECT tilladelser. Indstil pgaudit.role til den rolle og kør SELECT SQL-sætning:
CREATE ROLE audit_person; GRANT SELECT ON persons TO audit_person; SET pgaudit.role = 'audit_person'; SELECT * FROM persons WHERE ID=404;
Ovenstående valgudsagn vil blive logget 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>
|
Hvordan fortolker man revisionslogposten?
Indtil videre har vi givet detaljer om, hvordan revisionslogposten ser ud, lad os nu tage et kig på revisionslogindtastningsformatet. Hver post starter med log_line_prefix nævnt for PostgreSQL-logning, og derefter vil resten af outputtet være i CSV-format. Overvej følgende simple revisionslogpost:
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 ovenstående post er værdien
2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]:
er fra log_line_prefix-formatet %t:%r:%u@%d:[%p]: . Revisionspostens indhold starter fra LOG:AUDIT: værdi, og den følger CSV-format. Værdiformatet har formen:
AUDIT_TYPE,STATEMENT_ID,SUBSTATEMENT_ID,CLASS,COMMAND,OBJECT_TYPE,OBJECT_NAME,STATEMENT,PARAMETER
Lad os tage et kig på hvert af felterne et efter et:
| Felt | Beskrivelse | Værdi fra eksempel på revisionsindtastning |
|---|---|---|
| AUDIT_TYPE | Angiver revisionstilstanden:SESSION eller OBJECT | OBJEKT |
| STATEMENT_ID | Unik sætnings-id for hver session | 10 |
| SUBSTATEMENT_ID | En identifikator for hver undersætning i hovedsætningen | 1 |
| KLASSE | Angiver klassen af udsagn som READ, WRITE osv., der er definerede værdier for pgaudit.log parameter. | LÆS |
| KOMMANDO | Kommandoen brugt i SQL-sætningen | VÆLG |
| OBJECT_TYPE | Kan være TABLE, INDEX, VIEW osv. | TABEL |
| OBJECT_NAME | Det fuldt kvalificerede objektnavn | public.persons |
| UDTALELSE | Den faktiske sætning udført | vælg * blandt personer, hvor ID=404; |
| PARAMETER | Når pgaudit.log_parameter er sat til sand, vises den citerede CSV af parametre, hvis de er til stede, eller "ingen", hvis der ikke er nogen parametre. Når pgaudit.log_parameter ikke er indstillet, vil værdien være " |
Inferens
pgAudit med alle dens muligheder forenkler revisionsprocessen ved at generere revisionssporloggen. Selvom der er nogle få forbehold, såsom logning af omdøbte objekter under samme navn, er det stadig et robust værktøj, der giver den nødvendige funktionalitet. Revisionsinformationen, der er skrevet i logfiler, er muligvis ikke bare ideelle til revisionsprocessen – revisionsprocessen er endnu bedre, når disse logfiler kan konverteres til et databaseskema, og revisionsdata kan indlæses til databasen, så du nemt kan forespørge Information. Det er her, PostgreSQL Audit Log Analyzer (pgAudit Analyze) er nyttig. For mere information henvises til github-siderne i pgAudit og pgAudit Analyze.