In elk IT-systeem waar belangrijke zakelijke taken plaatsvinden, is het belangrijk om een expliciete reeks beleidsregels en praktijken te hebben en ervoor te zorgen dat deze worden gerespecteerd en gevolgd.
Inleiding tot auditing
Een IT-systeemaudit is het onderzoek van het beleid, de processen, procedures en praktijken van een organisatie met betrekking tot IT-infrastructuur tegen een bepaalde reeks doelstellingen. Een IT-audit kan van twee algemene typen zijn:
- Controleren aan de hand van een reeks standaarden op een beperkte subset van gegevens
- Het hele systeem controleren
Een IT-audit kan betrekking hebben op bepaalde kritieke systeemonderdelen, zoals die met betrekking tot financiële gegevens ter ondersteuning van een specifieke reeks voorschriften (bijv. SOX), of de volledige beveiligingsinfrastructuur tegen voorschriften zoals de nieuwe EU AVG-verordening die in de behoefte voorziet voor de bescherming van de privacy en stelt de richtlijnen voor het beheer van persoonsgegevens vast. Het SOX-voorbeeld is van het eerste type dat hierboven is beschreven, terwijl de AVG van het laatste is.
De auditlevenscyclus
Planning
Het bereik van een audit is afhankelijk van de auditdoelstelling. Het toepassingsgebied kan betrekking hebben op een speciale toepassing die wordt geïdentificeerd door een specifieke bedrijfsactiviteit, zoals een financiële activiteit, of de hele IT-infrastructuur die systeembeveiliging, gegevensbeveiliging enzovoort omvat. Als vroege stap in de initiële planningsfase moet de scope vooraf correct worden geïdentificeerd. De organisatie wordt geacht de auditor alle nodige achtergrondinformatie te verstrekken om te helpen bij het plannen van de audit. Dit kunnen de functionele/technische specificaties, systeemarchitectuurdiagrammen of andere gevraagde informatie zijn.
Controledoelstellingen
Op basis van de reikwijdte vormt de accountant een set van beheersingsdoelstellingen die door de controle worden getoetst. Die beheersingsdoelstellingen worden geïmplementeerd via managementpraktijken die geacht worden aanwezig te zijn om beheersing te bereiken in de mate die door de reikwijdte wordt beschreven. De beheersingsdoelstellingen zijn gekoppeld aan testplannen en vormen samen het auditprogramma. Gebaseerd op het auditprogramma de organisatie onder controle wijst middelen toe om de auditor te faciliteren.
Bevindingen
De auditor probeert bewijs te verkrijgen dat aan alle interne beheersingsdoelstellingen wordt voldaan. Als er voor een bepaalde interne beheersingsdoelstelling geen dergelijk bewijs is, probeert de auditor eerst te zien of er een alternatieve manier is waarop de onderneming de specifieke interne beheersingsdoelstelling afhandelt, en als een dergelijke manier bestaat, wordt deze interne beheersingsdoelstelling gemarkeerd als compenserend en de auditor van oordeel is dat de doelstelling is bereikt. Als er echter helemaal geen bewijs is dat een doel is bereikt, wordt dit gemarkeerd als een bevinding . Elke bevinding bestaat uit de aandoening, criteria, oorzaak, gevolg en aanbeveling. De IT-manager moet in nauw contact staan met de auditor om op de hoogte te zijn van alle mogelijke bevindingen en ervoor te zorgen dat alle gevraagde informatie wordt gedeeld tussen het management en de auditor om te verzekeren dat de controledoelstelling wordt bereikt (en zo te voorkomen dat de vinden).
Het beoordelingsrapport
Aan het einde van het auditproces zal de auditor een beoordelingsrapport schrijven als samenvatting waarin alle belangrijke onderdelen van de audit zijn opgenomen, inclusief eventuele bevindingen, gevolgd door een verklaring of de doelstelling adequaat is aangepakt en aanbevelingen voor het elimineren van de impact van de bevindingen.
Wat is auditregistratie en waarom zou u het doen?
De auditor wil volledige inzage hebben in de wijzigingen op software, data en het beveiligingssysteem. Hij/zij wil niet alleen eventuele wijzigingen in de bedrijfsgegevens kunnen opsporen, maar ook wijzigingen in het organigram, het beveiligingsbeleid, de definitie van rollen/groepen en wijzigingen in het rol/groepslidmaatschap. De meest gebruikelijke manier om een audit uit te voeren is via logging. Hoewel het in het verleden mogelijk was om een IT-audit te doorstaan zonder logbestanden, is dit tegenwoordig de geprefereerde (zo niet de enige) manier.
Typisch bestaat het gemiddelde IT-systeem uit ten minste twee lagen:
- Database
- Applicatie (mogelijk bovenop een applicatieserver)
De applicatie houdt zijn eigen logboeken bij waarin gebruikerstoegang en acties worden beschreven, en de database en mogelijk de applicatieserversystemen houden hun eigen logboeken bij. Schone, gemakkelijk bruikbare informatie in logbestanden die echte zakelijke waarde heeft vanuit het oogpunt van de auditor, wordt een audit trail genoemd. . Audittrails verschillen van gewone logbestanden (soms native logs genoemd) doordat:
- Logbestanden zijn overbodig
- Auditsporen moeten voor langere perioden worden bewaard
- Logbestanden voegen overhead toe aan de systeembronnen
- Het doel van logbestanden is om de systeembeheerder te helpen
- Het doel van audit trails is om de auditor te helpen
We vatten het bovenstaande samen in de volgende tabel:
| Logtype | App/Systeem | Audit Trail vriendelijk |
|---|---|---|
| App-logboeken | App | Ja |
| App-serverlogboeken | Systeem | Nee |
| Databaselogboeken | Systeem | Nee |
App-logboeken kunnen eenvoudig worden aangepast om als audittrails te worden gebruikt. Systeemlogs zijn niet zo gemakkelijk omdat:
- Ze worden in hun formaat beperkt door de systeemsoftware
- Ze werken wereldwijd op het hele systeem
- Ze hebben geen directe kennis over een specifieke zakelijke context
- Ze hebben meestal aanvullende software nodig voor latere offline ontleding/verwerking om bruikbare auditvriendelijke audittrails te produceren.
Aan de andere kant plaatsen app-logboeken een extra softwarelaag bovenop de feitelijke gegevens, dus:
- Het auditsysteem kwetsbaarder maken voor applicatiefouten/verkeerde configuratie
- Een potentieel gat in het logproces creëren als iemand rechtstreeks toegang probeert te krijgen tot gegevens in de database zonder het app-logsysteem te omzeilen, zoals een bevoorrechte gebruiker of een DBA
- Het auditsysteem complexer en moeilijker te beheren en te onderhouden maken voor het geval we veel applicaties of veel softwareteams hebben.
Dus idealiter zouden we op zoek zijn naar het beste van de twee:bruikbare audittrails hebben met de grootste dekking op het hele systeem, inclusief databaselaag, en op één plek configureerbaar, zodat de logging zelf gemakkelijk kan worden gecontroleerd door middel van andere ( systeem) logs.
Auditregistratie met PostgreSQL
De opties die we hebben in PostgreSQL met betrekking tot het loggen van audits zijn de volgende:
- Door uitgebreide logboekregistratie te gebruiken ( log_statement =all )
- Door een aangepaste triggeroplossing te schrijven
- Door standaard PostgreSQL-tools te gebruiken die door de community worden geleverd, zoals
- audit-trigger 91plus (https://github.com/2ndQuadrant/audit-trigger)
- pgaudit-extensie (https://github.com/pgaudit/pgaudit)
Uitputtende logboekregistratie, in ieder geval voor standaardgebruik in OLTP- of OLAP-workloads, moet worden vermeden omdat:
- Produceert enorme bestanden, verhoogt de belasting
- Heeft geen innerlijke kennis van tabellen die worden geopend of gewijzigd, drukt gewoon de instructie af die een DO-blok kan zijn met een cryptische aaneengeschakelde instructie
- Heeft aanvullende software/bronnen nodig voor offline parsing en verwerking (om de audittrails te produceren) die op hun beurt moeten worden opgenomen in de reikwijdte van de audit om als betrouwbaar te worden beschouwd
In de rest van dit artikel zullen we de tools van de community uitproberen. Laten we aannemen dat we deze eenvoudige tabel hebben die we willen controleren:
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
De documenten over het gebruik van de trigger zijn hier te vinden:https://wiki.postgresql.org/wiki/Audit_trigger_91plus. Eerst downloaden en installeren we de meegeleverde DDL (functies, schema):
$ 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.sqlVervolgens definiëren we de triggers voor onze tafel orders met het basisgebruik:
myshop=# SELECT audit.audit_table('orders');Dit creëert twee triggers op tafelorders:een insert_update_delere rijtrigger en een trigger voor het afkappen van een instructie. Laten we nu eens kijken wat de trigger doet:
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 |Let op de waarde changes_fields op de Update (RECORD 2). Er zijn meer geavanceerde toepassingen van de controletrigger, zoals het uitsluiten van kolommen of het gebruik van de WHEN-component zoals weergegeven in het document. De audit-trigger lijkt zeker het werk te doen van het creëren van bruikbare audittrails in de audit.logged_actions-tabel. Er zijn echter enkele kanttekeningen:
- Geen SELECT's (triggers worden niet geactiveerd bij SELECT's) of DDL worden bijgehouden
- Veranderingen door tafeleigenaren en supergebruikers kunnen gemakkelijk worden geknoeid
- Er moeten best practices worden gevolgd met betrekking tot de app-gebruiker(s) en app-schema- en tabelleneigenaren
Pgaudit
Pgadit is de nieuwste toevoeging aan PostgreSQL wat auditing betreft. Pgaudit moet als een extensie worden geïnstalleerd, zoals weergegeven op de github-pagina van het project:https://github.com/pgaudit/pgaudit. Pgaudit logt in het standaard PostgreSQL-logboek. Pgaudit werkt door zichzelf te registreren bij het laden van de module en voorziet in hooks voor de executorStart, executorCheckPerms, processUtility en object_access. Daarom ondersteunt pgaudit (in tegenstelling tot op triggers gebaseerde oplossingen zoals audit-trigger besproken in de vorige paragrafen) READs (SELECT, COPY). Over het algemeen kunnen we met pgaudit twee werkingsmodi hebben of ze gecombineerd gebruiken:
- SESSIE-controlelogboekregistratie
- OBJECT-auditregistratie
Logboekregistratie van sessie-audits ondersteunt de meeste DML-, DDL-, privilege- en misc-opdrachten via klassen:
- LEZEN (selecteren, kopiëren van)
- SCHRIJVEN (invoegen, bijwerken, verwijderen, inkorten, kopiëren naar)
- FUNCTIE (functieaanroepen en DO-blokken)
- ROLE (rol toekennen, intrekken, creëren/wijzigen/laten vallen)
- DDL (alle DDL behalve die in ROL)
- MISC (weggooien, ophalen, checkpoint, vacuüm)
Metaklasse "alle" omvat alle klassen. - exclusief een klasse. Laten we bijvoorbeeld sessie-auditregistratie configureren voor iedereen behalve MISC, met de volgende GUC-parameters in postgresql.conf:
pgaudit.log_catalog = off
pgaudit.log = 'all, -misc'
pgaudit.log_relation = 'on'
pgaudit.log_parameter = 'on'Door de volgende commando's te geven (hetzelfde als in het triggervoorbeeld)
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=#We krijgen de volgende vermeldingen in het PostgreSQL-logboek:
% 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>Merk op dat de tekst na AUDIT:een perfecte audit trail vormt, bijna klaar om naar de auditor te worden verzonden in spreadsheet-ready csv-formaat. Door sessie-auditregistratie te gebruiken, krijgen we auditlogboekvermeldingen voor alle bewerkingen die behoren tot de klassen die zijn gedefinieerd door de pgaudit.log-parameter op all tafels. Er zijn echter gevallen waarin we willen dat slechts een kleine subset van de gegevens, d.w.z. slechts een paar tabellen, worden gecontroleerd. In dergelijke gevallen geven we misschien de voorkeur aan het loggen van objectcontroles, wat ons fijnmazige criteria geeft boven geselecteerde tabellen/kolommen via het privilegesysteem van PostgreSQL. Om te beginnen met het loggen van Object-audits, moeten we eerst de parameter pgaudit.role configureren die de masterrol definieert die pgaudit zal gebruiken. Het is logisch om deze gebruiker geen inlogrechten te geven.
CREATE ROLE auditor;
ALTER ROLE auditor WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION NOBYPASSRLS CONNECTION LIMIT 0;We specificeren deze waarde voor pgaudit.role in postgresql.conf:
pgaudit.log = none # no need for extensive SESSION logging
pgaudit.role = auditorPgaudit OBJECT-loggen werkt door te vinden of gebruiker auditor krijgt (direct of overgenomen) het recht om de gespecificeerde actie uit te voeren die wordt uitgevoerd op de relaties/kolommen die in een instructie worden gebruikt. Dus als we alle tafels moeten negeren, maar gedetailleerde logboekregistratie hebben voor tafelorders, dan is dit de manier om het te doen:
grant ALL on orders to auditor ;Door de bovenstaande toekenning maken we volledige SELECT-, INSERT-, UPDATE- en DELETE-loggen op tafelorders mogelijk. Laten we nogmaals de INSERT, UPDATE, DELETE van de vorige voorbeelden geven en het postgresql-logboek bekijken:
% 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>We zien dat de output identiek is aan de SESSION-logging die hierboven is besproken, met het verschil dat we in plaats van SESSION als audittype (de string naast AUDIT:) nu OBJECT krijgen.
Een waarschuwing bij het loggen van OBJECT is dat TRUNCATE's niet worden vastgelegd. Hiervoor moeten we onze toevlucht nemen tot SESSIE-logging. Maar in dit geval krijgen we uiteindelijk alle WRITE-activiteit voor alle tabellen. Er zijn gesprekken tussen de betrokken hackers om van elk commando een aparte klasse te maken.
Een ander ding om in gedachten te houden is dat in het geval van overerving, als we toegang verlenen aan de auditor op een onderliggende tabel, en niet de bovenliggende tabel, acties op de bovenliggende tabel die worden vertaald naar acties op rijen van de onderliggende tabel, niet worden geregistreerd.
Naast het bovenstaande moeten de IT-mensen die verantwoordelijk zijn voor de integriteit van de logbestanden een strikte en goed gedefinieerde procedure documenteren die de extractie van de audittrail uit de PostgreSQL-logbestanden omvat. Die logs kunnen naar een externe beveiligde syslog-server worden gestreamd om de kans op interferentie of manipulatie te minimaliseren.
Samenvatting
We hopen dat deze blog u heeft geholpen om de beste werkwijzen voor het loggen van audits in PostgreSQL beter te begrijpen en waarom het maken van een audittrail zo belangrijk is bij de voorbereiding op een IT-audit. Een audittrail biedt een reeks duidelijke, bruikbare informatie die ervoor zorgt dat uw audit soepel verloopt.
ClusterControl kan helpen bij het automatiseren en beheren van de meeste databasegerelateerde taken, terwijl databasebeveiliging, beschikbaarheid en prestaties worden gegarandeerd, ongeacht het door u gekozen systeem. Download vandaag nog een gratis proefversie van ClusterControl om te zien hoe uw bedrijf kan profiteren van de tool en de bewerkingen die het uitvoert. Als je dat nog niet hebt gedaan, volg ons dan op Twitter en LinkedIn, en abonneer je op onze feed, dan zien we je in de volgende blog.