Audyt w technologiach informatycznych (IT) to proces badania infrastruktury informatycznej organizacji w celu zapewnienia zgodności z wymaganiami nałożonymi przez uznane standardy lub ustalone zasady. Zasady ochrony danych, takie jak nowe przepisy RODO, stają się coraz bardziej rygorystyczne, aby chronić dane użytkowników, dlatego ważne jest, aby audyty bazy danych były odpowiednio skonfigurowane, aby zapewnić ochronę zarówno aplikacji, jak i danych użytkownika przed lukami w zabezpieczeniach. W tym poście na blogu omówimy pgAudit – narzędzie, które generuje logi audytu potrzebne do ułatwienia audytu PostgreSQL.
Co to jest pgAudit?
Rozszerzenie audytu PostgreSQL, pgAudit, to rozszerzenie typu open source, które rejestruje zdarzenia w bazie danych PostgreSQL w szczegółowym dzienniku audytu. Wykorzystuje natywną funkcję rejestrowania PostgreSQL, więc logi audytu będą częścią dzienników PostgreSQL. Rozszerzenie opiera się na projekcie 2ndQuadrant pgAudit, którego autorami są Simon Riggs, Abhijit Menon-Sen i Ian Barwick, i zawiera ulepszenia Davida Steele z Crunchy Data.
Dlaczego pgAudit przez log_statement=all?
Możemy rejestrować wszystkie instrukcje w PostgreSQL po prostu ustawiając log_statement=all . Po co więc w ogóle używać pgAudit? Logowanie podstawowych instrukcji (za pomocą log_statement ) wyświetla tylko operacje wykonywane na bazie danych. Nie zapewni możliwości filtrowania operacji, a logi nie będą miały odpowiedniego formatowania wymaganego do audytu. pgAudit dodatkowo zapewnia szczegółowość rejestrowania określonych klas instrukcji, takich jak READ (SELECT i COPY ), WRITE (INSERT , UPDATE , DELETE itp.), DDL itp. Ponadto zapewnia audyt na poziomie obiektu, w którym rejestrowane będą tylko operacje na określonych relacjach.
Kolejną zaletą pgAudit w porównaniu z rejestrowaniem podstawowych instrukcji jest to, że udostępnia szczegóły wykonywanej operacji, a nie tylko rejestrowanie żądanej operacji. Na przykład rozważ wykonanie bloku anonimowego kodu za pomocą instrukcji DO.
DO $$ BEGIN EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)'; END $$;
Podstawowe rejestrowanie wyciągów spowoduje:
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 zarejestruje tę samą operację, co:
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>
Powyższe wyraźnie wskazuje funkcjonalność pgAudit, która rejestruje operację i jej elementy wewnętrzne za pomocą ustrukturyzowanych danych wyjściowych, które ułatwiają wyszukiwanie.
Jak przeprowadzić audyt PostgreSQL za pomocą pgAuditKliknij, aby tweetowaćJak zainstalować pgAudit?
pgAudit to rozszerzenie, które można pobrać z repozytorium PostgreSQL lub można je skompilować i zbudować ze źródeł. W pierwszym kroku pakiet musi zostać pobrany i zainstalowany na komputerze z uruchomionym PostgreSQL (ten pakiet rozszerzeń jest preinstalowany we wszystkich wdrożeniach ScaleGrid PostgreSQL).
Po zainstalowaniu należy go załadować do PostgreSQL. Osiąga się to przez dodanie pgaudit do shared_preload_libraries parametr konfiguracyjny. Aby zmiana konfiguracji zaczęła obowiązywać, wymagane jest ponowne uruchomienie PostgreSQL. Następnym krokiem jest włączenie rozszerzenia w bazie danych, uruchamiając CREATE EXTENSION pgaudit .
Teraz, gdy rozszerzenie jest gotowe, musimy upewnić się, że ustawiliśmy parametry konfiguracyjne dla rozszerzenia, aby rozpocząć rejestrowanie. Może to być tak proste, jak ustawienie parametru pgaudit.log do wartości all a pgAudit rozpocznie logowanie w session tryb.
Teraz, gdy wiemy już, jak zainstalować i włączyć pgAudit, omówmy dwa oferowane przez niego tryby rejestrowania audytu:sesję i obiekt.
Logowanie audytu sesji
W trybie sesji pgAudit rejestruje wszystkie operacje wykonywane przez użytkownika. Ustawianie pgaudit.log parametr na dowolną ze zdefiniowanych wartości, inną niż NONE , umożliwi rejestrowanie audytu sesji. pgaudit.log parametr określa klasy wyciągów, które będą logowane w trybie sesyjnym. Możliwe wartości to:READ , WRITE , FUNCTION , ROLE , DDL , MISC , MISC_SET , ALL i NONE .
Ustawianie pgaudit.log parametr do ALL zarejestruje wszystkie wyciągi. Parametr może akceptować wiele klas przy użyciu listy oddzielonej przecinkami, a określone klasy można wykluczyć znakiem –. Na przykład, jeśli chcesz rejestrować wszystkie instrukcje z wyjątkiem MISC klasa, wartość pgaudit.log będzie ALL, -MISC, -MISC_SET . Możesz także włączyć pgAudit, aby utworzyć oddzielny wpis dziennika dla każdego odniesienia do relacji w instrukcji, ustawiając pgaudit.log_relation do włączenia.
Rozważ przykład tworzenia tabeli. Instrukcja SQL będzie wyglądać tak:
CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));
Odpowiednie wpisy w dzienniku kontroli to:
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>
Logowanie audytu obiektów
W szczególnych przypadkach może być wymagane przeprowadzenie audytu tylko określonego zestawu relacji. W takich przypadkach użycie trybu sesji spowoduje jedynie niepotrzebnie dużą liczbę dzienników audytu, które nie odpowiadają wymaganym relacjom. Tryb obiektowy jest szczególnie odpowiedni do tego celu i może kontrolować tylko określony zestaw relacji.
Logowanie audytu obiektów odbywa się za pomocą ról PostgreSQL. Można utworzyć rolę i przypisać uprawnienia dostępu tylko do określonego zestawu relacji. Ta rola powinna być określona w parametrze konfiguracyjnym pgaudit.role . Tryb obiektowy obsługuje tylko SELECT , INSERT , UPDATE i DELETE sprawozdania. Klasy instrukcji, które są rejestrowane, zależą od uprawnień przyznanych roli. Na przykład, jeśli rola ma uprawnienia do wykonywania tylko SELECT , potem tylko SELECT wyciągi będą rejestrowane.
Poniżej znajduje się przykład rejestrowania audytu obiektów:
Utwórz rolę i przyznaj tylko SELECT uprawnienia. Ustaw pgaudit.role do tej roli i uruchom SELECT Instrukcja SQL:
CREATE ROLE audit_person; GRANT SELECT ON persons TO audit_person; SET pgaudit.role = 'audit_person'; SELECT * FROM persons WHERE ID=404;
Powyższa instrukcja select zostanie zarejestrowana jako:
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>
|
Jak interpretować wpis w dzienniku kontroli?
Do tej pory przedstawiliśmy szczegółowe informacje o tym, jak wygląda wpis w dzienniku kontroli, teraz przyjrzyjmy się formatowi wpisu w dzienniku kontroli. Każdy wpis zaczyna się od log_line_prefix wspomnianego przy logowaniu PostgreSQL, a reszta danych wyjściowych będzie w formacie CSV. Rozważ następujący prosty wpis w dzienniku kontroli:
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>
W powyższym wpisie wartość
2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]:
ma format log_line_prefix %t:%r:%u@%d:[%p]: . Treść wpisu kontroli zaczyna się od LOG: AUDIT: wartość i jest zgodny z formatem CSV. Format wartości ma postać:
AUDIT_TYPE,STATEMENT_ID,SUBSTATEMENT_ID,CLASS,COMMAND,OBJECT_TYPE,OBJECT_NAME,STATEMENT,PARAMETER
Przyjrzyjmy się kolejno każdemu z pól:
| Pole | Opis | Wartość z przykładowego wpisu audytu |
|---|---|---|
| AUDIT_TYPE | Wskazuje tryb kontroli:SESJA lub OBIEKT | OBIEKT |
| STATEMENT_ID | Unikalny identyfikator instrukcji dla każdej sesji | 10 |
| SUBSTATEMENT_ID | Identyfikator dla każdej instrukcji podrzędnej w ramach instrukcji głównej | 1 |
| KLASA | Wskazuje klasę instrukcji, takich jak READ, WRITE itp., które są zdefiniowanymi wartościami parametru pgaudit.log. | CZYTAJ |
| POLECENIE | Polecenie użyte w instrukcji SQL | SELECT |
| OBJECT_TYPE | Może to być TABELA, INDEKS, WIDOK itp. | TABELA |
| OBJECT_NAME | W pełni kwalifikowana nazwa obiektu | public.persons |
| OŚWIADCZENIE | Rzeczywiste wykonanie instrukcji | wybierz * z osób gdzie ID=404; |
| PARAMETR | Gdy parametr pgaudit.log_parameter ma wartość true, cytowany plik CSV parametrów jest wyświetlany, jeśli jest obecny, lub „brak”, jeśli nie ma parametrów. Gdy parametr pgaudit.log_parameter nie jest ustawiony, wartością będzie „ |
Wnioskowanie
pgAudit, ze wszystkimi swoimi możliwościami, upraszcza proces audytu poprzez generowanie dziennika audytu. Chociaż istnieje kilka zastrzeżeń, takich jak rejestrowanie obiektów o zmienionych nazwach pod tą samą nazwą, nadal jest to solidne narzędzie, które zapewnia wymaganą funkcjonalność. Jednak informacje z audytu zapisane w dziennikach mogą nie być po prostu idealne dla procesu audytu – proces audytu jest jeszcze lepszy, gdy te logi można przekonwertować na schemat bazy danych, a dane audytu można załadować do bazy danych, dzięki czemu można łatwo przeszukiwać Informacja. Tutaj pomocny jest Analizator logów audytu PostgreSQL (pgAudit Analyze). Więcej informacji można znaleźć na stronach github pgAudit i pgAudit Analyze.
