V každém IT systému, kde se odehrávají důležité obchodní úkoly, je důležité mít explicitní soubor zásad a postupů a zajistit, aby byly respektovány a dodržovány.
Úvod do auditu
Audit systému informačních technologií je zkoumání zásad, procesů, postupů a praktik organizace týkající se infrastruktury IT s ohledem na určitý soubor cílů. IT audit může mít dva obecné typy:
- Kontrola omezené podmnožiny dat podle souboru standardů
- Kontrola celého systému
IT audit se může týkat určitých kritických částí systému, jako jsou ty, které se týkají finančních údajů, aby podpořil konkrétní soubor předpisů (např. SOX), nebo celou bezpečnostní infrastrukturu proti předpisům, jako je nové nařízení EU GDPR, které řeší potřebu pro ochranu soukromí a stanoví pokyny pro správu osobních údajů. Příklad SOX je prvního typu popsaného výše, zatímco GDPR je druhého typu.
Životní cyklus auditu
Plánování
Rozsah auditu závisí na cíli auditu. Rozsah může zahrnovat speciální aplikaci identifikovanou konkrétní obchodní činností, jako je finanční činnost, nebo celou IT infrastrukturu zahrnující zabezpečení systému, zabezpečení dat a tak dále. Rozsah musí být správně identifikován předem jako raný krok v počáteční fázi plánování. Organizace má poskytnout auditorovi všechny nezbytné podkladové informace, které mu pomohou s plánováním auditu. Mohou to být funkční/technické specifikace, schémata architektury systému nebo jakékoli jiné požadované informace.
Cíle kontroly
Na základě rozsahu auditor vytvoří soubor kontrolních cílů, které mají být auditem testovány. Tyto kontrolní cíle jsou implementovány prostřednictvím manažerských postupů, které mají být zavedeny za účelem dosažení kontroly v rozsahu popsaném rozsahem. Kontrolní cíle jsou spojeny s testovacími plány a společně tvoří program auditu. Na základě auditního programu organizace, která je předmětem auditu, přiděluje zdroje k usnadnění auditu.
Zjištění
Auditor se snaží získat důkazy, že jsou splněny všechny kontrolní cíle. Pokud pro nějaký kontrolní cíl neexistují žádné takové důkazy, auditor se nejprve pokusí zjistit, zda existuje nějaký alternativní způsob, jak společnost naložit s konkrétním kontrolním cílem, a v případě, že takový způsob existuje, je tento kontrolní cíl označen jako kompenzační a auditor se domnívá, že cíl je splněn. Pokud však neexistuje žádný důkaz, že je cíl splněn, je to označeno jako nález . Každý nález se skládá ze stavu, kritérií, příčiny, účinku a doporučení. IT manažer musí být v úzkém kontaktu s auditorem, aby byl informován o všech potenciálních zjištěních, a musí zajistit, aby všechny požadované informace byly sdíleny mezi vedením a auditorem, aby bylo zajištěno, že je splněn kontrolní cíl (a tím se zabrání nález).
Hodnotící zpráva
Na konci procesu auditu auditor sepíše hodnotící zprávu jako souhrn zahrnující všechny důležité části auditu, včetně případných zjištění, po nichž následuje prohlášení o tom, zda je cíl adekvátně řešen, a doporučení pro eliminaci dopadu zjištění.
Co je protokolování auditu a proč byste to měli dělat?
Auditor chce mít plný přístup ke změnám softwaru, dat a bezpečnostního systému. Chce mít nejen možnost sledovat jakoukoli změnu v obchodních datech, ale také sledovat změny organizačního schématu, bezpečnostní politiky, definice rolí/skupin a změny členství v rolích/skupinách. Nejběžnějším způsobem provádění auditu je protokolování. Ačkoli v minulosti bylo možné projít IT auditem bez souborů protokolu, dnes je to preferovaný (ne-li jediný) způsob.
Průměrný IT systém se obvykle skládá z alespoň dvou vrstev:
- Databáze
- Aplikace (případně na aplikačním serveru)
Aplikace uchovává své vlastní protokoly týkající se uživatelského přístupu a akcí a databáze a případně systémy aplikačních serverů uchovávají své vlastní protokoly. Čisté, snadno použitelné informace v souborech protokolu, které mají z pohledu auditora skutečnou obchodní hodnotu, se nazývají audit trail . Auditní záznamy se liší od běžných souborů protokolu (někdy nazývaných nativní protokoly) v tom, že:
- Soubory protokolu jsou zbytečné
- Auditní záznamy by měly být uchovávány po delší dobu
- Soubory protokolů zvyšují režii systémových prostředků
- Účelem souborů protokolu je pomoci správci systému
- Cílem audit trails je pomoci auditorovi
Výše uvedené shrnujeme v následující tabulce:
| Typ protokolu | Aplikace/systém | Audit Trail friendly |
|---|---|---|
| Protokoly aplikací | Aplikace | Ano |
| Protokoly aplikačního serveru | Systém | Ne |
| Protokoly databáze | Systém | Ne |
Protokoly aplikací lze snadno upravit tak, aby je bylo možné použít jako auditní záznamy. Systémové protokoly nejsou tak snadné, protože:
- Jejich formát je omezen systémovým softwarem
- Působí globálně na celý systém
- Nemají přímé znalosti o konkrétním obchodním kontextu
- Obvykle vyžadují další software pro pozdější offline analýzu/zpracování, aby vytvořily použitelné auditní záznamy vhodné pro audit.
Na druhou stranu však protokoly aplikací umisťují nad skutečná data další softwarovou vrstvu, takže:
- Zranitelnost auditního systému vůči chybám/nesprávné konfiguraci aplikací
- Vytvoření potenciální díry v procesu protokolování, pokud se někdo pokusí získat přístup k datům přímo v databázi a obejít systém protokolování aplikace, jako je privilegovaný uživatel nebo správce databáze
- Zkomplikování auditního systému a jeho složitější správa a údržba v případě, že máme mnoho aplikací nebo mnoho softwarových týmů.
V ideálním případě bychom tedy hledali to nejlepší z těchto dvou:Mít použitelné auditní záznamy s největším pokrytím na celém systému včetně databázové vrstvy a konfigurovatelné na jednom místě, takže samotné protokolování lze snadno auditovat pomocí jiných ( systém) protokoly.
Protokolování auditu pomocí PostgreSQL
Možnosti, které máme v PostgreSQL ohledně protokolování auditu, jsou následující:
- Pomocí vyčerpávajícího protokolování ( log_statement =all )
- Napsáním vlastního řešení spouštěče
- Pomocí standardních nástrojů PostgreSQL poskytovaných komunitou, jako je
- audit-trigger 91plus (https://github.com/2ndQuadrant/audit-trigger)
- rozšíření pgaudit (https://github.com/pgaudit/pgaudit)
Je třeba se vyhnout vyčerpávajícímu protokolování alespoň pro standardní použití v pracovních zátěžích OLTP nebo OLAP, protože:
- Vytváří velké soubory, zvyšuje zatížení
- Nemá vnitřní znalosti o tabulkách, ke kterým se přistupuje nebo je upravuje, pouze vytiskne příkaz, který může být blokem DO s tajemným zřetězeným příkazem
- Potřebuje další software/zdroje pro offline analýzu a zpracování (za účelem vytvoření auditních záznamů), které zase musí být zahrnuty do rozsahu auditu, aby byly považovány za důvěryhodné
Ve zbytku tohoto článku vyzkoušíme nástroje poskytované komunitou. Předpokládejme, že máme tuto jednoduchou tabulku, kterou chceme auditovat:
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
Dokumenty o použití spouštěče lze nalézt zde:https://wiki.postgresql.org/wiki/Audit_trigger_91plus. Nejprve si stáhneme a nainstalujeme poskytnutý DDL (funkce, schéma):
$ 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.sqlPoté definujeme spouštěče pro naše tabulky objednávky pomocí základního použití:
myshop=# SELECT audit.audit_table('orders');Tím vytvoříte dva spouštěče v objednávkách tabulek:spouštěč řádku insert_update_delere a spouštěč příkazu oříznutí. Nyní se podívejme, co spoušť dělá:
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 |Poznamenejte si hodnotu updated_fields v aktualizaci (RECORD 2). Existují pokročilejší použití spouštěče auditu, jako je vyloučení sloupců nebo použití klauzule WHEN, jak je uvedeno v dokumentu doc. Zdá se, že spouštěč auditu dělá práci při vytváření užitečných auditních záznamů v tabulce audit.logged_actions. Existují však některá upozornění:
- Žádné SELECTy (spouštěče se nespouštějí na SELECT) ani DDL nejsou sledovány
- Změny provedené vlastníky tabulek a superuživateli lze snadno zfalšovat
- Je třeba dodržovat doporučené postupy týkající se uživatelů aplikace a vlastníků schémat a tabulek aplikace
Pgaudit
Pgaudit je nejnovější přírůstek do PostgreSQL, pokud jde o auditování. Pgaudit musí být nainstalován jako rozšíření, jak je znázorněno na stránce github projektu:https://github.com/pgaudit/pgaudit. Pgaudit se zapisuje do standardního protokolu PostgreSQL. Pgaudit funguje tak, že se zaregistruje při načtení modulu a poskytne háčky pro executorStart, executorCheckPerms, processUtility a object_access. Proto pgaudit (na rozdíl od řešení založených na spouštění, jako je audit-trigger, o kterém jsme hovořili v předchozích odstavcích) podporuje čtení (SELECT, COPY). Obecně s pgaudit můžeme mít dva provozní režimy nebo je používat v kombinaci:
- Protokol auditu SESSION
- Protokol auditu OBJEKT
Protokolování auditu relací podporuje většinu příkazů DML, DDL, privilegia a misc prostřednictvím tříd:
- ČTĚTE (vyberte, zkopírujte z)
- WRITE (vložit, aktualizovat, odstranit, zkrátit, zkopírovat do)
- FUNKCE (volání funkcí a bloky DO)
- ROLE (udělit, zrušit, vytvořit/změnit/zrušit roli)
- DDL (všechny DDL kromě těch v ROLE)
- MISC (zahodit, načíst, kontrolní bod, vysát)
Metatřída „all“ zahrnuje všechny třídy. - vylučuje třídu. Například nakonfigurujeme protokolování auditu relací pro všechny kromě MISC s následujícími parametry GUC v postgresql.conf:
pgaudit.log_catalog = off
pgaudit.log = 'all, -misc'
pgaudit.log_relation = 'on'
pgaudit.log_parameter = 'on'Zadáním následujících příkazů (stejných jako v příkladu spouštění)
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=#V protokolu PostgreSQL získáme následující položky:
% 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>Všimněte si, že text za AUDIT:tvoří dokonalou auditní stopu, téměř připravenou k odeslání auditorovi ve formátu csv připraveném pro tabulkový procesor. Použití protokolování auditu relace nám poskytne záznamy protokolu auditu pro všechny operace patřící do tříd definovaných parametrem pgaudit.log na all tabulky. Existují však případy, kdy si přejeme, aby byla auditována pouze malá podmnožina dat, tj. pouze několik tabulek. V takových případech můžeme upřednostňovat protokolování auditu objektů, které nám poskytuje přesná kritéria pro vybrané tabulky/sloupce prostřednictvím systému oprávnění PostgreSQL. Abychom mohli začít používat protokolování objektového auditu, musíme nejprve nakonfigurovat parametr pgaudit.role, který definuje hlavní roli, kterou bude pgaudit používat. Má smysl nedávat tomuto uživateli žádná přihlašovací práva.
CREATE ROLE auditor;
ALTER ROLE auditor WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION NOBYPASSRLS CONNECTION LIMIT 0;Tuto hodnotu zadáváme pro pgaudit.role v postgresql.conf:
pgaudit.log = none # no need for extensive SESSION logging
pgaudit.role = auditorProtokolování Pgaudit OBJECT bude fungovat tak, že zjistí, zda je uživatel auditor je uděleno (přímo nebo zděděno) právo provést specifikovanou akci provedenou na relacích/sloupcích použitých ve výpisu. Pokud tedy potřebujeme ignorovat všechny tabulky, ale máme podrobné protokolování objednávek tabulek, je to způsob, jak to udělat:
grant ALL on orders to auditor ;Výše uvedeným grantem umožňujeme plné protokolování SELECT, INSERT, UPDATE a DELETE u objednávek tabulek. Uveďme ještě jednou INSERT, UPDATE, DELETE předchozích příkladů a podívejme se na log postgresql:
% 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>Pozorujeme, že výstup je identický s protokolováním SESSION diskutovaným výše s tím rozdílem, že místo SESSION jako typ auditu (řetězec vedle AUDIT:) nyní dostáváme OBJECT.
Jednou výhradou u protokolování OBJECT je, že TRUNCATE nejsou protokolovány. K tomu se musíme uchýlit k protokolování SESSION. Ale v tomto případě nakonec získáme veškerou aktivitu WRITE pro všechny tabulky. Mezi zapojenými hackery probíhají rozhovory o tom, aby každý příkaz byl samostatnou třídou.
Další věc, kterou je třeba mít na paměti, je, že v případě dědičnosti, pokud udělíme přístup auditorovi u nějaké podřízené tabulky, a ne u nadřazené tabulky, akce nadřazené tabulky, které se převedou na akce na řádcích podřízené tabulky, nebudou protokolovány.
Kromě výše uvedeného musí IT pracovníci odpovědní za integritu protokolů zdokumentovat přísný a dobře definovaný postup, který zahrnuje extrakci auditní stopy ze souborů protokolu PostgreSQL. Tyto protokoly mohou být přenášeny na externí zabezpečený server syslog, aby se minimalizovala pravděpodobnost jakéhokoli rušení nebo manipulace.
Shrnutí
Doufáme, že vám tento blog pomohl lépe porozumět osvědčeným postupům pro protokolování auditu v PostgreSQL a proč je vytvoření auditní stopy tak důležité při přípravě na audit IT. Auditní záznam poskytne sadu čistých, použitelných informací, které pomohou váš audit hladce proběhnout.
ClusterControl může pomoci automatizovat a spravovat většinu úloh souvisejících s databázemi a zároveň zajistit zabezpečení, dostupnost a výkon databáze – bez ohledu na vámi zvolený systém. Stáhněte si bezplatnou zkušební verzi ClusterControl ještě dnes, abyste viděli, jak může vaše firma těžit z tohoto nástroje a operací, které provádí. Pokud jste to ještě neudělali, nezapomeňte nás sledovat na Twitteru a LinkedInu a přihlásit se k odběru našeho kanálu a uvidíme se na příštím blogu.