Одитът в информационните технологии (ИТ) е процес на проверка на ИТ инфраструктурата на организацията, за да се гарантира съответствие с изискванията, наложени от признати стандарти или установени политики. Правилата за защита на данните, като новите разпоредби на GDPR, стават все по-строги за защита на потребителските данни, така че е важно одитите на вашата база данни да са настроени правилно, за да се гарантира, че както вашето приложение, така и потребителските данни са защитени от уязвимости. В тази публикация в блога ще обсъдим pgAudit – инструмент, който генерира регистрационните файлове за одит, необходими за улесняване на одита на PostgreSQL.
Какво е pgAudit?
Разширението за одит на PostgreSQL, pgAudit, е разширение с отворен код, което регистрира събитията в PostgreSQL база данни в подробен дневник за одит. Той използва собственото средство за регистриране на PostgreSQL, така че регистрационните файлове за одит ще бъдат част от регистрационните файлове на PostgreSQL. Разширението се базира на проекта 2ndQuadrant pgAudit, автор на Саймън Ригс, Абхиджит Менон-Сен и Иън Баруик, и включва подобрения от Дейвид Стийл от Crunchy Data.
Защо pgAudit над log_statement=all?
Можем да регистрираме всички изрази в PostgreSQL само като зададем log_statement=all
. Така че защо изобщо да използвате pgAudit? Основното регистриране на оператора (използвайки log_statement
) ще изброява само операциите, извършени спрямо базата данни. Той няма да предостави възможност за филтриране на операции и регистрационните файлове няма да бъдат в правилното форматиране, необходимо за одит. pgAudit допълнително осигурява детайлност за регистриране на специфични класове изрази като READ
(SELECT
и COPY
), WRITE
(INSERT
, UPDATE
, DELETE
и др.), DDL
и т.н. Освен това осигурява одит на ниво обект, където ще се записват само операции върху специфични отношения.
Друго предимство на pgAudit пред основното регистриране на оператори е, че предоставя подробностите за извършената операция, вместо просто да регистрира заявената операция. Например, помислете за изпълнение на анонимния кодов блок с помощта на оператор DO.
DO $$ BEGIN EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)'; END $$;
Регистрирането на основния израз ще доведе до:
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 ще регистрира същата операция като:
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>
Гореното ясно показва функционалността на pgAudit, която регистрира операцията и нейните вътрешни елементи със структуриран изход, който улеснява търсенето.
Как да одитираме PostgreSQL с помощта на pgAuditClick To TweetКак да инсталирам pgAudit?
pgAudit е разширение, което е достъпно за изтегляне от хранилището на PostgreSQL или може да бъде компилирано и изградено от източник. Като първа стъпка пакетът трябва да бъде изтеглен и инсталиран на машината, работеща с PostgreSQL (този пакет с разширение е предварително инсталиран на всички внедрявания на ScaleGrid PostgreSQL).
След като бъде инсталиран, той трябва да бъде зареден в PostgreSQL. Това се постига чрез добавяне на pgaudit
към shared_preload_libraries
конфигурационен параметър. За да бъде ефективна тази промяна в конфигурацията, е необходимо рестартиране на PostgreSQL. Следващата стъпка е да активирате разширението в базата данни, като изпълните CREATE EXTENSION pgaudit
.
Сега, когато разширението е готово, трябва да се уверим, че сме задали конфигурационните параметри за разширението, за да започне да регистрира. Това може да бъде толкова просто, колкото да зададете параметъра pgaudit.log
за стойност all
и pgAudit ще започне да влиза в session
режим.
Сега, когато знаем как да инсталираме и активираме pgAudit, нека обсъдим двата режима на регистриране на одит, които предлага, сесия и обект.
Регистриране на одит на сесия
В режим на сесия pgAudit ще регистрира всички операции, извършени от потребител. Задаване на pgaudit.log
параметър към която и да е от дефинираните стойности, различни от NONE
, ще активира регистрирането на одит на сесията. pgaudit.log
параметър определя класовете изрази, които ще бъдат регистрирани в режим на сесия. Възможните стойности са:READ
, WRITE
, FUNCTION
, ROLE
, DDL
, MISC
, MISC_SET
, ALL
и NONE
.
Настройка на pgaudit.log
параметър към ALL
ще регистрира всички изявления. Параметърът може да приема множество класове, използвайки списък, разделен със запетая, а конкретни класове могат да бъдат изключени със знак –. Например, ако искате да регистрирате всички изрази с изключение на MISC
клас, стойността на pgaudit.log
ще бъде ALL, -MISC, -MISC_SET
. Можете също така да активирате pgAudit да създава отделен запис в регистрационния файл за всяка препратка към релация в израз, като зададете pgaudit.log_relation
за включване.
Разгледайте пример за създаване на таблица. SQL изразът ще бъде:
CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));
Съответните записи в журнала за одит са:
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>
Регистриране на одит на обекти
В определени случаи може да се наложи одит само на конкретен набор от връзки. В такива случаи използването на режим на сесия ще доведе само до ненужно голям брой регистрационни файлове за одит, които не отговарят на необходимите отношения. Обектният режим е особено подходящ за тази цел и може да одитира само определен набор от връзки.
Регистрирането на одита на обекта се постига с помощта на ролите на PostgreSQL. Може да се създаде роля и да се присвоят разрешенията за достъп само до определен набор от връзки. Тази роля трябва да бъде посочена в конфигурационния параметър pgaudit.role
. Обектният режим поддържа само SELECT
, INSERT
, UPDATE
и DELETE
изявления. Класовете оператори, които се записват, зависят от разрешенията, предоставени на ролята. Например, ако ролята има разрешения да изпълнява само SELECT
, след това само SELECT
изявленията ще бъдат регистрирани.
По-долу е даден пример за регистриране на одит на обект:
Създайте роля и дайте само SELECT
разрешения. Задайте pgaudit.role
към тази роля и стартирайте SELECT
SQL израз:
CREATE ROLE audit_person; GRANT SELECT ON persons TO audit_person; SET pgaudit.role = 'audit_person'; SELECT * FROM persons WHERE ID=404;
Горещият оператор select ще бъде регистриран като:
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>
|
Как да тълкуваме записа в регистъра на одита?
Досега предоставяхме подробности за това как изглежда записът в регистъра за одит, сега нека да разгледаме формата на записа в регистрационния файл за одит. Всеки запис започва с log_line_prefix, споменат за регистрирането на PostgreSQL, а след това останалата част от изхода ще бъде във формат CSV. Помислете за следния прост запис в журнала за одит:
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>
В горния запис стойността
2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]:
е от формат log_line_prefix %t:%r:%u@%d:[%p]:
. Съдържанието на записа за одит започва от LOG: AUDIT:
стойност и следва CSV формат. Форматът на стойността е от вида:
AUDIT_TYPE,STATEMENT_ID,SUBSTATEMENT_ID,CLASS,COMMAND,OBJECT_TYPE,OBJECT_NAME,STATEMENT,PARAMETER
Нека разгледаме всяко от полетата едно по едно:
Поле | Описание | Стойност от примерен запис за одит |
---|---|---|
AUDIT_TYPE | Показва режима на одит:SESSION или OBJECT | ОБЕКТ |
STATEMENT_ID | Уникален идентификатор на израза за всяка сесия | 10 |
SUBSTATEMENT_ID | Идентификатор за всеки подизявление в основния израз | 1 |
КЛАС | Показва класа от изрази като READ, WRITE и т.н., които са дефинирани стойности за параметъра pgaudit.log. | ЧЕТЕТЕ |
КОМАНДА | Командата, използвана в SQL израза | ИЗБЕРЕТЕ |
OBJECT_TYPE | Може да бъде ТАБЛИЦА, ИНДЕКС, ИЗГЛЕД и др. | ТАБЛИЦА |
OBJECT_NAME | Пълното име на обекта | public.persons |
ИЗЯВЛЕНИЕ | Действителната изпълнена инструкция | изберете * от лица, където ID=404; |
ПАРАМЕТЪР | Когато pgaudit.log_parameter е настроен на true, цитираният в кавички CSV параметри се посочва, ако присъства, или „няма“, ако няма параметри. Когато pgaudit.log_parameter не е зададен, стойността ще бъде " | <не е регистриран> |
Извод
pgAudit, с всичките си възможности, опростява процеса на одит чрез генериране на дневника на одитната пътека. Въпреки че има няколко предупреждения, като регистриране на преименувани обекти под същото име, той все още е стабилен инструмент, който осигурява необходимата функционалност. Въпреки това, информацията за одит, записана в регистрационни файлове, може да не е идеална просто за процеса на одит – процесът на одит е още по-добър, когато тези регистрационни файлове могат да бъдат преобразувани в схема на база данни и данните от одита могат да бъдат заредени в базата данни, така че да можете лесно да запитвате информация. Това е мястото, където PostgreSQL Audit Log Analyzer (pgAudit Analyze) е полезен. За повече информация вижте страниците на github на pgAudit и pgAudit Analyze.