W każdym systemie informatycznym, w którym odbywają się ważne zadania biznesowe, ważne jest posiadanie wyraźnego zestawu zasad i praktyk oraz upewnienie się, że są one przestrzegane i przestrzegane.
Wprowadzenie do audytu
Audyt systemu informatycznego to badanie polityk, procesów, procedur i praktyk organizacji dotyczących infrastruktury IT pod kątem określonego zestawu celów. Audyt IT może być dwojakiego rodzaju:
- Sprawdzanie zestawu standardów na ograniczonym podzbiorze danych
- Sprawdzenie całego systemu
Audyt informatyczny może objąć pewne krytyczne części systemu, takie jak te związane z danymi finansowymi w celu obsługi określonego zestawu regulacji (np. SOX) lub całą infrastrukturę bezpieczeństwa w stosunku do regulacji, takich jak nowe rozporządzenie UE RODO, które odpowiada na potrzebę za ochronę prywatności i ustala wytyczne dotyczące zarządzania danymi osobowymi. Przykład SOX należy do pierwszego typu opisanego powyżej, podczas gdy RODO należy do drugiego.
Cykl audytu
Planowanie
zakres audytu zależy od celu audytu. Zakres może obejmować specjalną aplikację identyfikowaną przez konkretną działalność gospodarczą, np. działalność finansową, lub całą infrastrukturę informatyczną obejmującą bezpieczeństwo systemu, bezpieczeństwo danych i tak dalej. Zakres musi być wcześniej prawidłowo zidentyfikowany jako wczesny krok w początkowej fazie planowania. Organizacja ma za zadanie dostarczyć audytorowi wszelkich niezbędnych informacji ogólnych, które pomogą w zaplanowaniu audytu. Mogą to być specyfikacje funkcjonalne/techniczne, schematy architektury systemu lub wszelkie inne wymagane informacje.
Cele kontrolne
Na podstawie zakresu audytor tworzy zestaw celów kontroli, które mają być przetestowane przez audyt. Te cele kontroli są realizowane poprzez praktyki zarządzania, które mają być stosowane w celu uzyskania kontroli w zakresie określonym przez zakres. Cele kontroli są powiązane z planami testów i razem tworzą program audytu. Na podstawie programu audytu audytowana organizacja przydziela zasoby w celu ułatwienia audytorowi.
Wyniki
Kontroler stara się uzyskać dowody, że wszystkie cele kontroli są spełnione. Jeżeli dla jakiegoś celu kontroli nie ma takiego dowodu, biegły rewident stara się najpierw sprawdzić, czy istnieje alternatywny sposób, w jaki firma radzi sobie z określonym celem kontroli, a w przypadku gdy taki sposób istnieje, ten cel kontroli jest oznaczony jako kompensujący a biegły rewident uważa, że cel został osiągnięty. Jeśli jednak nie ma żadnych dowodów na to, że cel został osiągnięty, jest to oznaczane jako znalezienie . Każde odkrycie składa się z warunku, kryteriów, przyczyny, skutku i zalecenia. Kierownik IT musi pozostawać w bliskim kontakcie z audytorem, aby być informowanym o wszystkich potencjalnych ustaleniach i upewnić się, że wszystkie wymagane informacje są udostępniane między kierownictwem a audytorem, aby zapewnić osiągnięcie celu kontroli (a tym samym uniknąć znalezienie).
Raport oceniający
Pod koniec procesu audytu audytor napisze raport oceniający jako podsumowanie obejmujące wszystkie ważne części audytu, w tym wszelkie potencjalne ustalenia, po których nastąpi oświadczenie, czy cel jest odpowiednio zrealizowany, oraz zalecenia dotyczące wyeliminowania wpływu ustaleń.
Co to jest rejestrowanie audytu i dlaczego należy to robić?
Audytor chce mieć pełny dostęp do zmian w oprogramowaniu, danych i systemie bezpieczeństwa. Chce nie tylko śledzić wszelkie zmiany w danych biznesowych, ale także śledzić zmiany w schemacie organizacyjnym, polityce bezpieczeństwa, definicji ról/grup i zmianach członkostwa w rolach/grupach. Najczęstszym sposobem przeprowadzenia audytu jest logowanie. Chociaż w przeszłości można było przejść audyt IT bez plików dziennika, dziś jest to preferowany (jeśli nie jedyny) sposób.
Zazwyczaj przeciętny system informatyczny składa się z co najmniej dwóch warstw:
- Baza danych
- Aplikacja (prawdopodobnie na serwerze aplikacji)
Aplikacja prowadzi własne logi obejmujące dostęp i działania użytkowników, a baza danych i ewentualnie systemy serwerów aplikacji utrzymują własne logi. Czyste, łatwe do wykorzystania informacje w plikach dziennika, które mają rzeczywistą wartość biznesową z perspektywy audytora, są nazywane ścieżką audytu . Ścieżki audytu różnią się od zwykłych plików dziennika (czasami nazywanych dziennikami natywnymi) tym, że:
- Pliki dziennika są zbędne
- Ścieżki audytu powinny być przechowywane przez dłuższy czas
- Pliki dziennika zwiększają obciążenie zasobów systemu
- Celem plików dziennika jest pomoc administratorowi systemu
- Celem ścieżek audytu jest pomoc audytorowi
Powyższe podsumowujemy w poniższej tabeli:
| Typ dziennika | Aplikacja/system | Przyjazny dla ścieżki audytu |
|---|---|---|
| Dzienniki aplikacji | Aplikacja | Tak |
| Dzienniki serwera aplikacji | System | Nie |
| Dzienniki bazy danych | System | Nie |
Dzienniki aplikacji można łatwo dostosować do wykorzystania jako ścieżki audytu. Logi systemowe nie są tak łatwe, ponieważ:
- Są ograniczone pod względem formatu przez oprogramowanie systemowe
- Działają globalnie w całym systemie
- Nie mają bezpośredniej wiedzy na temat konkretnego kontekstu biznesowego
- Zazwyczaj wymagają one dodatkowego oprogramowania do późniejszego parsowania/przetwarzania offline w celu stworzenia użytecznych ścieżek audytu przyjaznych dla audytu.
Jednak z drugiej strony dzienniki aplikacji umieszczają dodatkową warstwę oprogramowania na wierzchu rzeczywistych danych, w ten sposób:
- Sprawianie, że system audytu jest bardziej podatny na błędy aplikacji/niewłaściwą konfigurację
- Tworzenie potencjalnej dziury w procesie rejestrowania, jeśli ktoś próbuje uzyskać dostęp do danych bezpośrednio w bazie danych z pominięciem systemu rejestrowania aplikacji, takiego jak uprzywilejowany użytkownik lub administrator danych
- Sprawienie, by system audytu był bardziej złożony i trudniejszy w zarządzaniu i utrzymaniu w przypadku, gdy mamy wiele aplikacji lub wiele zespołów programistycznych.
Idealnie więc, szukalibyśmy najlepszego z dwóch:posiadanie użytecznych ścieżek audytu z największym pokryciem całego systemu, w tym warstwy bazy danych, i konfigurowanie w jednym miejscu, tak aby samo rejestrowanie mogło być łatwo audytowane za pomocą innych ( systemowe) dzienniki.
Logowanie audytów za pomocą PostgreSQL
Opcje jakie mamy w PostgreSQL dotyczące rejestrowania audytu są następujące:
- Korzystając z wyczerpującego rejestrowania (log_statement =all)
- Pisząc niestandardowe rozwiązanie wyzwalacza
- Przy użyciu standardowych narzędzi PostgreSQL udostępnianych przez społeczność, takich jak
- audit-trigger 91plus (https://github.com/2ndQuadrant/audit-trigger)
- Rozszerzenie pgaudit (https://github.com/pgaudit/pgaudit)
Należy unikać wyczerpującego rejestrowania przynajmniej w przypadku standardowego użycia w obciążeniach OLTP lub OLAP, ponieważ:
- Produkuje ogromne pliki, zwiększa obciążenie
- Nie ma wewnętrznej wiedzy na temat tabel, do których uzyskuje się dostęp lub które są modyfikowane, po prostu wyświetla instrukcję, która może być blokiem DO z tajemniczą połączoną instrukcją
- Potrzebuje dodatkowego oprogramowania/zasobów do parsowania i przetwarzania offline (w celu stworzenia ścieżek audytu), które z kolei muszą być objęte zakresem audytu, aby można je było uznać za wiarygodne
W dalszej części tego artykułu wypróbujemy narzędzia udostępnione przez społeczność. Załóżmy, że mamy tę prostą tabelę, którą chcemy sprawdzić:
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)wyzwalacz audytu 91plus
Dokumentację dotyczącą używania wyzwalacza można znaleźć tutaj:https://wiki.postgresql.org/wiki/Audit_trigger_91plus. Najpierw pobieramy i instalujemy dostarczone DDL (funkcje, schemat):
$ 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.sqlNastępnie definiujemy wyzwalacze dla naszych zamówień przy użyciu podstawowego użycia:
myshop=# SELECT audit.audit_table('orders');Spowoduje to utworzenie dwóch wyzwalaczy dla zamówień tabel:wyzwalacza wiersza insert_update_delere i wyzwalacza instrukcji obcinania. Zobaczmy teraz, co robi wyzwalacz:
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 |Zwróć uwagę na wartość change_fields w aktualizacji (RECORD 2). Istnieją bardziej zaawansowane zastosowania wyzwalacza audytu, takie jak wykluczanie kolumn lub użycie klauzuli WHEN, jak pokazano w dokumencie. Wyzwalacz audytu z pewnością wydaje się wykonywać zadanie tworzenia przydatnych śladów audytu w tabeli audit.logged_actions. Istnieją jednak pewne zastrzeżenia:
- Brak SELECTów (wyzwalacze nie uruchamiają się przy SELECTach) lub DDL są śledzone
- Zmiany wprowadzane przez właścicieli stołów i superużytkowników można łatwo modyfikować
- Należy przestrzegać najlepszych praktyk dotyczących użytkowników aplikacji oraz właścicieli schematów aplikacji i tabel
Pgaaudit
Pgaudit to najnowszy dodatek do PostgreSQL, jeśli chodzi o audyt. Pgaudit musi być zainstalowany jako rozszerzenie, jak pokazano na stronie github projektu:https://github.com/pgaudit/pgaudit. Pgaudit loguje się w standardowym logu PostgreSQL. Pgaudit działa, rejestrując się po załadowaniu modułu i udostępniając haki dla executorStart, executorCheckPerms, processUtility i object_access. Dlatego pgaudit (w przeciwieństwie do rozwiązań opartych na wyzwalaczach, takich jak audyt-trigger omówiony w poprzednich akapitach) obsługuje READ (SELECT, COPY). Generalnie z pgaudit możemy mieć dwa tryby działania lub używać ich łącznie:
- Logowanie audytu SESJI
- Logowanie audytu OBJECT
Rejestrowanie audytu sesji obsługuje większość poleceń DML, DDL, uprawnień i misc za pośrednictwem klas:
- CZYTAJ (wybierz, skopiuj z)
- WRITE (wstaw, zaktualizuj, usuń, przytnij, skopiuj do)
- FUNKCJA (wywołania funkcji i bloki DO)
- ROLA (przyznaj, odwołaj, utwórz/zmień/upuść rolę)
- DDL (wszystkie DDL oprócz tych w ROLE)
- MISC (odrzuć, pobierz, punkt kontrolny, odkurz)
Metaklasa „all” obejmuje wszystkie klasy. - wyklucza zajęcia. Na przykład skonfigurujmy rejestrowanie audytu sesji dla wszystkich z wyjątkiem MISC, z następującymi parametrami GUC w postgresql.conf:
pgaudit.log_catalog = off
pgaudit.log = 'all, -misc'
pgaudit.log_relation = 'on'
pgaudit.log_parameter = 'on'Wydając następujące polecenia (takie same jak w przykładzie wyzwalacza)
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=#W logu PostgreSQL otrzymujemy następujące wpisy:
% 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>Zauważ, że tekst po AUDIT:stanowi doskonałą ścieżkę audytu, prawie gotową do wysłania do audytora w formacie csv gotowym do użycia w arkuszu kalkulacyjnym. Korzystanie z rejestrowania audytu sesji da nam wpisy dziennika audytu dla wszystkich operacji należących do klas zdefiniowanych przez parametr pgaudit.log na wszystkich tabele. Są jednak przypadki, w których życzymy sobie tylko małego podzbioru danych, tj. tylko kilku tabel do audytu. W takich przypadkach możemy preferować rejestrowanie audytu obiektów, które daje nam szczegółowe kryteria dla wybranych tabel/kolumn za pośrednictwem systemu uprawnień PostgreSQL. Aby zacząć korzystać z rejestrowania audytu obiektów, musimy najpierw skonfigurować parametr pgaudit.role, który definiuje główną rolę, której będzie używał pgaudit. Nie należy przyznawać temu użytkownikowi żadnych praw logowania.
CREATE ROLE auditor;
ALTER ROLE auditor WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION NOBYPASSRLS CONNECTION LIMIT 0;Wartość tę określamy dla pgaudit.role w postgresql.conf:
pgaudit.log = none # no need for extensive SESSION logging
pgaudit.role = auditorLogowanie Pgaudit OBJECT będzie działać, sprawdzając, czy użytkownik audytor otrzymuje (bezpośrednio lub dziedzicznie) prawo do wykonania określonej akcji na relacjach/kolumnach użytych w zestawieniu. Jeśli więc musimy zignorować wszystkie tabele, ale mamy szczegółowe logowanie do zamówień stolików, jest to sposób na zrobienie tego:
grant ALL on orders to auditor ;Dzięki powyższemu grantowi umożliwiamy pełne logowanie SELECT, INSERT, UPDATE i DELETE na zamówieniach tabel. Podajmy jeszcze raz INSERT, UPDATE, DELETE z poprzednich przykładów i obejrzyjmy dziennik 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>Zauważamy, że dane wyjściowe są identyczne z logowaniem SESSION omówionym powyżej, z tą różnicą, że zamiast SESSION jako typu audytu (ciąg obok AUDIT:) teraz otrzymujemy OBJECT.
Jedynym zastrzeżeniem związanym z rejestrowaniem OBJECT jest to, że TRUNCATE nie są rejestrowane. W tym celu musimy skorzystać z logowania SESSION. Ale w tym przypadku otrzymujemy całą aktywność WRITE dla wszystkich tabel. Wśród zaangażowanych hakerów prowadzone są rozmowy, aby każde polecenie było oddzielną klasą.
Kolejną rzeczą, o której należy pamiętać, jest to, że w przypadku dziedziczenia, jeśli UDZIELIMY dostępu audytorowi do jakiejś tabeli podrzędnej, a nie do rodzica, działania na tabeli nadrzędnej, które przekładają się na działania na wierszach tabeli podrzędnej, nie będą rejestrowane.
Oprócz powyższego, informatycy odpowiedzialni za integralność dzienników muszą udokumentować ścisłą i dobrze zdefiniowaną procedurę, która obejmuje wyodrębnianie ścieżki audytu z plików dziennika PostgreSQL. Te logi mogą być przesyłane strumieniowo do zewnętrznego bezpiecznego serwera syslog w celu zminimalizowania prawdopodobieństwa jakiejkolwiek ingerencji lub manipulacji.
Podsumowanie
Mamy nadzieję, że ten blog pomógł Ci lepiej zrozumieć najlepsze praktyki rejestrowania audytu w PostgreSQL i dlaczego tworzenie ścieżki audytu jest tak ważne w przygotowaniu do audytu IT. Ścieżka audytu zapewni zestaw czystych, użytecznych informacji, które pomogą w sprawnym przeprowadzeniu audytu.
ClusterControl może pomóc zautomatyzować i zarządzać większością zadań związanych z bazą danych, zapewniając jednocześnie bezpieczeństwo, dostępność i wydajność bazy danych — niezależnie od wybranego systemu. Pobierz bezpłatną wersję próbną ClusterControl już dziś, aby zobaczyć, jak Twoja firma może skorzystać na tym narzędziu i wykonywanych przez niego operacjach. Jeśli jeszcze tego nie zrobiłeś, śledź nas na Twitterze i LinkedIn oraz zasubskrybuj nasz kanał, a do zobaczenia w następnym blogu.
