Jak przeprowadzić audyt bazy danych PostgreSQL

Kontrola to dobry sposób na zapewnienie jak największego bezpieczeństwa danych i sprawdzenie, co dzieje się w Twoich bazach danych. Jest również wymagany w przypadku wielu przepisów lub standardów bezpieczeństwa, takich jak PCI - Payment Card Industry. To nie jest wyjątek dla twojej bazy danych PostgreSQL.

PostgreSQL zdobył silną reputację dzięki sprawdzonej architekturze, niezawodności, integralności danych, solidnemu zestawowi funkcji, rozszerzalności i zaangażowaniu społeczności open source stojącej za oprogramowaniem, aby konsekwentnie dostarczać wydajne i innowacyjne rozwiązania.

Mając to na uwadze, powinna to być opcja audytu bazy danych PostgreSQL, prawda? Cóż, odpowiedź brzmi tak. W tym blogu zobaczymy, czym jest rozszerzenie pgAudit oraz jak je zainstalować i używać w bazie danych PostgreSQL.

Co to jest pgAudit?

Rozszerzenie audytu PostgreSQL (pgAudit) zapewnia szczegółowe rejestrowanie audytu sesji i obiektów za pośrednictwem standardowego narzędzia rejestrowania PostgreSQL.

Podstawowe rejestrowanie instrukcji może być zapewnione przez standardowe narzędzie rejestrowania z log_statement =all. Jest to akceptowalne w przypadku monitorowania i innych podstawowych zastosowań, ale nie zapewnia poziomu szczegółowości zwykle wymaganego do audytu. Nie wystarczy mieć listę wszystkich operacji wykonywanych na bazie danych. Musi być również możliwe odnalezienie konkretnych stwierdzeń, które zainteresują biegłego rewidenta. Standardowa funkcja rejestrowania pokazuje, czego żądał użytkownik, podczas gdy pgAudit skupia się na szczegółach tego, co się stało, gdy baza danych spełniała żądanie.

Jak zainstalować pgAudit na PostgreSQL

W tym przykładzie użyjemy instalacji CentOS 7. W tym momencie przypuszczaliśmy, że masz zainstalowaną bazę danych PostgreSQL, w przeciwnym razie możesz śledzić ten wpis na blogu, aby w łatwy sposób uruchomić ją i uruchomić za pomocą ClusterControl.

Teraz powinieneś mieć repozytorium PostgreSQL w swoim systemie operacyjnym, coś takiego:

$ cat /etc/yum.repos.d/postgresql.repo

# PGDG Red Hat Enterprise Linux / CentOS stable common repository for all PostgreSQL versions

[pgdg-common]

name=PostgreSQL common for RHEL/CentOS $releasever - $basearch

baseurl=http://download.postgresql.org/pub/repos/yum/common/redhat/rhel-$releasever-$basearch

enabled=1

gpgcheck=0

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG

# PGDG Red Hat Enterprise Linux / CentOS stable repositories:

[pgdg]

name=PostgreSQL 12 $releasever - $basearch

#baseurl=http://yum.postgresql.org/12/redhat/rhel-$releasever-$basearch

baseurl=http://download.postgresql.org/pub/repos/yum/12/redhat/rhel-$releasever-$basearch/

enabled=1

gpgcheck=0

[pgdg-source]

name=PostgreSQL 12 $releasever - $basearch - Source

baseurl=http://yum.postgresql.org/srpms/12/redhat/rhel-$releasever-$basearch

enabled=0

gpgcheck=0

Jeśli sprawdzisz dostępne pakiety pgaudit, powinieneś mieć:

pgaudit14_12.x86_64 : PostgreSQL Audit Extension

Zainstalujmy go:

$ yum install pgaudit14_12

Teraz musisz dodać go do pliku konfiguracyjnego postgresql.conf, znajdującego się domyślnie w /var/lib/pgsql/12/data/postgresql.conf i ponownie uruchomić usługę PostgreSQL, aby zastosować zmiana.

shared_preload_libraries = 'pgaudit, pg_stat_statements'

Po ponownym uruchomieniu usługi bazy danych musisz utworzyć rozszerzenie:

postgres=# CREATE EXTENSION pgaudit;

CREATE EXTENSION

And now, you can run the following query to check the new extension created:

postgres=# SELECT * FROM pg_available_extensions WHERE name LIKE '%audit%';

  name   | default_version | installed_version |             comment

---------+-----------------+-------------------+---------------------------------

 pgaudit | 1.4.1           | 1.4.1             | provides auditing functionality

(1 row)

Konfiguracja pgAudit

Aktualną konfigurację można zweryfikować, uruchamiając następujące zapytanie:

postgres=# SELECT name,setting FROM pg_settings WHERE name LIKE 'pgaudit%';

            name            | setting

----------------------------+---------

 pgaudit.log                | none

 pgaudit.log_catalog        | on

 pgaudit.log_client         | off

 pgaudit.log_level          | log

 pgaudit.log_parameter      | off

 pgaudit.log_relation       | off

 pgaudit.log_statement_once | off

 pgaudit.role               |

(8 rows)

Zobaczmy te parametry jeden po drugim.

pgaudit.log :Określa, które klasy instrukcji będą rejestrowane przez rejestrowanie audytu sesji. Wartość domyślna to brak. Możliwe wartości to:
- CZYTAJ:WYBIERZ i KOPIUJ, gdy źródłem jest relacja lub zapytanie.
- WPISZ:WSTAW, AKTUALIZUJ, USUŃ, OTWIERAJ i KOPIUJ, gdy miejscem docelowym jest relacja.
- FUNKCJA:Wywołania funkcji i bloki DO.
- ROLE:Oświadczenia związane z rolami i uprawnieniami:GRANT, REVOKE, CREATE/ALTER/DROP ROLE.
- DDL:Wszystkie DDL, które nie są zawarte w klasie ROLE.
- MISC:Różne polecenia, np. ODRZUCENIE, POBIERZ, PUNKT KONTROLNY, ODKURZ, USTAW.
- MISC_SET:Różne polecenia SET, np. USTAW ROLĘ.
- WSZYSTKIE:Uwzględnij wszystkie powyższe.
pgaudit.log_catalog :Określa, że rejestrowanie sesji powinno być włączone w przypadku, gdy wszystkie relacje w instrukcji znajdują się w pg_catalog. Wyłączenie tego ustawienia zmniejszy szum w dzienniku z narzędzi takich jak psql i PgAdmin, które intensywnie odpytują katalog. Domyślnie włączone.
pgaudit.log_client :Określa, czy komunikaty dziennika będą widoczne dla procesu klienta, takiego jak psql. To ustawienie należy ogólnie pozostawić wyłączone, ale może być przydatne do debugowania lub do innych celów. Domyślnie jest wyłączone.
pgaudit.log_level :Określa poziom dziennika, który będzie używany dla wpisów dziennika. To ustawienie jest używane do testowania regresji i może być również przydatne dla użytkowników końcowych do testowania lub do innych celów. Wartość domyślna to log.
pgaudit.log_parameter :określa, że rejestrowanie inspekcji powinno zawierać parametry, które zostały przekazane wraz z instrukcją. Gdy parametry są obecne, zostaną one uwzględnione w formacie CSV po tekście instrukcji. Domyślnie jest wyłączone.
pgaudit.log_relation :Określa, czy rejestrowanie inspekcji sesji powinno tworzyć osobny wpis dziennika dla każdej relacji (TABLE, VIEW itp.), do której odwołuje się instrukcja SELECT lub DML. Jest to przydatny skrót do wyczerpującego rejestrowania bez korzystania z rejestrowania audytu obiektów. Domyślnie jest wyłączone.
pgaudit.log_statement_once :Określa, czy rejestrowanie będzie zawierało tekst instrukcji i parametry z pierwszym wpisem dziennika dla kombinacji instrukcji/podinstrukcji, czy z każdym wpisem. Wyłączenie tego ustawienia spowoduje mniej szczegółowe rejestrowanie, ale może utrudnić określenie instrukcji, która wygenerowała wpis dziennika, chociaż para instrukcja/podinstrukcja wraz z identyfikatorem procesu powinna wystarczyć do zidentyfikowania tekstu instrukcji zarejestrowanego z poprzednim wpisem. Domyślnie jest wyłączone.
pgaudit.role :Określa główną rolę, która ma być używana do rejestrowania kontroli obiektów. Wiele ról kontroli można zdefiniować, przypisując je do roli głównej. Dzięki temu wiele grup może być odpowiedzialnymi za różne aspekty rejestrowania audytu. Nie ma domyślnego.

pgAudit Użycie

Teraz sprawdziliśmy parametry konfiguracyjne, zobaczmy przykład, jak z niego korzystać w prawdziwym świecie.

Aby przeprowadzić kontrolę wszystkich odczytów, zapisów i zapytań DDL, uruchom:

test1=# set pgaudit.log = 'read,write,ddl';

SET

Następnie uruchom następujące zdania:

test1=# CREATE TABLE table1 (id int, name text);

CREATE TABLE

test1=# INSERT INTO table1 (id, name) values (1, 'name1');

INSERT 0 1

test1=# INSERT INTO table1 (id, name) values (2, 'name2');

INSERT 0 1

test1=# INSERT INTO table1 (id, name) values (3, 'name3');

INSERT 0 1

test1=# SELECT * FROM table1;

 id | name

----+-------

  1 | name1

  2 | name2

  3 | name3

(3 rows)

Jeśli sprawdzisz plik dziennika PostgreSQL, zobaczysz to:

2020-11-20 19:17:13.848 UTC [25142] LOG:  AUDIT: SESSION,3,1,DDL,CREATE TABLE,,,"CREATE TABLE table1 (id int, name text);",<not logged>

2020-11-20 19:18:45.334 UTC [25142] LOG:  AUDIT: SESSION,4,1,WRITE,INSERT,,,"INSERT INTO table1 (id, name) values (1, 'name1');",<not logged>

2020-11-20 19:18:52.332 UTC [25142] LOG:  AUDIT: SESSION,5,1,WRITE,INSERT,,,"INSERT INTO table1 (id, name) values (2, 'name2');",<not logged>

2020-11-20 19:18:58.103 UTC [25142] LOG:  AUDIT: SESSION,6,1,WRITE,INSERT,,,"INSERT INTO table1 (id, name) values (3, 'name3');",<not logged>

2020-11-20 19:19:07.261 UTC [25142] LOG:  AUDIT: SESSION,7,1,READ,SELECT,,,SELECT * FROM table1;,<not logged>

Oczywiście jest to podstawowy przykład. Możesz użyć parametrów konfiguracyjnych opisanych w poprzedniej sekcji, aby dopasować je do swojej firmy.

Włączanie pgAudit z ClusterControl

Zamiast instalować i włączać pgAudit ręcznie, inną opcją jest użycie ClusterControl CLI do wykonania zadania za Ciebie. W tym celu możesz uruchomić następujące polecenie z serwera ClusterControl:

$ s9s cluster --setup-audit-logging --cluster-id=ID

Gdzie ID jest identyfikatorem klastra PostgreSQL.

Gdy jest uruchomiony, możesz monitorować stan, sprawdzając zadanie ClusterControl. Najpierw potrzebujesz identyfikatora pracy, który możesz uzyskać z listy ofert:

$ s9s job --list

163  18 RUNNING  test_dba                     admins 19:41:45            90% Setup Audit Logging

Teraz sprawdź szczegóły oferty:

$ s9s job --log --job-id=163

Using SSH credentials from cluster.

Cluster ID is 18.

The username is 'root'.

10.10.10.129:5432: Configuring audit logging.

10.10.10.129:5432: Installing 'pgaudit14_12'.

10.10.10.129:5432: Setting pgaudit.log to ROLE,DDL,MISC.

Writing file '10.10.10.129:/var/lib/pgsql/12/data/postgresql.conf'.

10.10.10.129:5432: Restarting PostgreSQL node.

10.10.10.129: waiting for server to shut down.... done

server stopped

waiting for server to start....2020-11-20 19:41:52.069 UTC [25137] LOG:  pgaudit extension initialized

2020-11-20 19:41:52.069 UTC [25137] LOG:  starting PostgreSQL 12.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit

2020-11-20 19:41:52.069 UTC [25137] LOG:  listening on IPv4 address "0.0.0.0", port 5432

2020-11-20 19:41:52.069 UTC [25137] LOG:  listening on IPv6 address "::", port 5432

2020-11-20 19:41:52.080 UTC [25137] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"

2020-11-20 19:41:52.102 UTC [25137] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"

2020-11-20 19:41:52.130 UTC [25137] LOG:  redirecting log output to logging collector process

2020-11-20 19:41:52.130 UTC [25137] HINT:  Future log output will appear in directory "log".

 done

server started

10.10.10.129:5432: Waiting for node to be accessible.

10.10.10.129:5432: pgaudit 1.4.1 is enabled.

To działanie będzie wymagało ponownego uruchomienia usługi bazy danych, które zostanie wykonane przez ClusterControl w tym samym zadaniu. Po ponownym uruchomieniu rozszerzenie pgAudit jest włączone i gotowe do użycia:

postgres=# SELECT * FROM pg_available_extensions WHERE name LIKE '%audit%';

  name   | default_version | installed_version |             comment

---------+-----------------+-------------------+---------------------------------

 pgaudit | 1.4.1           | 1.4.1             | provides auditing functionality

(1 row)

To wszystko! Możesz teraz skonfigurować i używać pgAudit w taki sam sposób, jaki pokazaliśmy wcześniej.

Wnioski

Audyt jest wymagany w przypadku wielu przepisów bezpieczeństwa i jest również przydatny, jeśli chcesz wiedzieć, co się stało w Twojej bazie danych oraz kiedy i kto był za to odpowiedzialny.

W tym blogu mówiliśmy o rozszerzeniu pgAudit PostgreSQL jako dobrym sposobie audytu baz danych PostgreSQL, a także pokazaliśmy, jak zaimplementować je zarówno ręcznie, jak i przy użyciu ClusterControl CLI.

Pamiętaj, że w zależności od konfiguracji pgAudit może generować ogromne ilości danych. Dlatego powinieneś być ostrożny, aby określić, co i jak długo chcesz kontrolować.