PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

Одит на PostgreSQL с помощта на pgAudit

Одитът в информационните технологии (ИТ) е процес на проверка на ИТ инфраструктурата на организацията, за да се гарантира съответствие с изискванията, наложени от признати стандарти или установени политики. Правилата за защита на данните, като новите разпоредби на 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>

Интересувате ли се от напълно управлявано PostgreSQL решение?

За да научите повече за това как доставчик на DBaaS като ScaleGrid може да ви помогне да управлявате вашите PostgreSQL бази данни, вижте нашата страница PostgreSQL. Вижте как ScaleGrid може да ви позволи да се съсредоточите повече върху разработването на вашия продукт и по-малко върху управлението на бази данни.

Как да тълкуваме записа в регистъра на одита?

Досега предоставяхме подробности за това как изглежда записът в регистъра за одит, сега нека да разгледаме формата на записа в регистрационния файл за одит. Всеки запис започва с 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.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. В Postgres липсва грешка при въвеждане на клауза FROM при заявка с клауза WITH

  2. Плъзгаща се средна въз основа на времеви печати в PostgreSQL

  3. Добавете години към дата в PostgreSQL

  4. Използване на автоматизация за ускоряване на тестовете за издаване на PostgreSQL

  5. Как да запазите данните да не се сортират?