Най-добри практики за регистриране на одит на PostgreSQL

Във всяка ИТ система, където се изпълняват важни бизнес задачи, е важно да има изричен набор от политики и практики и да се уверите, че те се спазват и следват.

Въведение в одита

Одитът на системата за информационни технологии е проверка на политиките, процесите, процедурите и практиките на една организация по отношение на ИТ инфраструктурата спрямо определен набор от цели. ИТ одитът може да бъде от два общи типа:

• Проверка на набор от стандарти на ограничен подмножество от данни
• Проверка на цялата система

ИТ одитът може да обхване определени критични части на системата, като например тези, свързани с финансови данни, за да подкрепи специфичен набор от регулации (например SOX) или цялата инфраструктура за сигурност срещу регулации като новия регламент на GDPR на ЕС, който отговаря на необходимостта за защита на поверителността и определя насоките за управление на лични данни. Примерът за SOX е от първия тип, описан по-горе, докато GDPR е от втория.

Жизненият цикъл на одита

Планиране

Обхватът на одита зависи от целта на одита. Обхватът може да обхваща специално приложение, идентифицирано от конкретна бизнес дейност, като финансова дейност, или цялата ИТ инфраструктура, обхващаща сигурността на системата, сигурността на данните и т.н. Обхватът трябва да бъде правилно идентифициран предварително като ранна стъпка в началната фаза на планиране. Организацията трябва да предостави на одитора цялата необходима основна информация, за да помогне при планирането на одита. Това може да са функционални/технически спецификации, диаграми на системната архитектура или друга искана информация.

Цели на контрол

Въз основа на обхвата, одиторът формира набор от контролни цели, които да бъдат тествани от одита. Тези цели на контрол се осъществяват чрез управленски практики, които се предполага, че са налице, за да се постигне контрол до степента, описана в обхвата. Целите на контрола са свързани с планове за изпитване и те заедно съставляват програмата за одит. Въз основа на одитна програма одитираната организация разпределя ресурси, за да улесни одитора.

Констатации

Одиторът се опитва да получи доказателства, че всички цели на контрола са изпълнени. Ако за някаква контролна цел няма такова доказателство, първо одиторът се опитва да види дали има някакъв алтернативен начин, по който компанията се справя с конкретната контролна цел, и в случай, че такъв начин съществува, тогава тази контролна цел се маркира като компенсираща и одиторът счита, че целта е постигната. Ако обаче изобщо няма доказателства, че дадена цел е постигната, това се отбелязва като констатация . Всяка констатация се състои от условие, критерии, причина, следствие и препоръка. ИТ мениджърът трябва да бъде в тесен контакт с одитора, за да бъде информиран за всички потенциални констатации и да се увери, че цялата искана информация се споделя между ръководството и одитора, за да се гарантира, че целта на контрола е изпълнена (и по този начин да се избегне намиране).

Докладът за оценка

В края на одитния процес одиторът ще напише доклад за оценка като обобщение, обхващащо всички важни части от одита, включително всички потенциални констатации, последвано от изявление за това дали целта е адекватно адресирана и препоръки за елиминиране на въздействието на констатациите.

Какво е регистриране на одит и защо трябва да го правите?

Одиторът иска да има пълен достъп до промените в софтуера, данните и системата за сигурност. Той/тя иска не само да може да проследи всяка промяна в бизнес данните, но и да проследи промените в организационната схема, политиката за сигурност, дефиницията на роли/групи и промените в членството на роли/групи. Най-често срещаният начин за извършване на одит е чрез регистриране. Въпреки че в миналото беше възможно да се премине ИТ одит без регистрационни файлове, днес това е предпочитаният (ако не и единственият) начин.

Обикновено средната ИТ система се състои от поне два слоя:

• База данни
• Приложение (евентуално върху сървър на приложения)

Приложението поддържа свои собствени регистрационни файлове, обхващащи потребителския достъп и действия, а базата данни и евентуално сървърните системи на приложения поддържат свои собствени регистрационни файлове. Чистата, лесно използваема информация в регистрационни файлове, която има реална бизнес стойност от гледна точка на одитора, се нарича одитна пътека . Одитните пътеки се различават от обикновените регистрационни файлове (понякога наричани естествени регистрационни файлове) по това:

• Регистрационните файлове не са необходими
• Одиторските пътеки трябва да се съхраняват за по-дълги периоди от време
• Регистрационните файлове добавят допълнителни разходи към ресурсите на системата
• Целта на регистрационните файлове е да помагат на системния администратор
• Целта на одитните пътеки е да помогне на одитора

Обобщаваме горното в следната таблица:

Регистраторите на приложения могат лесно да бъдат приспособени, за да се използват като пътеки за одит. Системните регистрационни файлове не са толкова лесно, защото:

• Те са ограничени във формата си от системния софтуер
• Те действат глобално върху цялата система
• Те нямат преки познания за конкретен бизнес контекст
• Обикновено изискват допълнителен софтуер за по-късен анализ/обработка офлайн, за да създадат удобни за използване одитни пътеки.

От друга страна обаче регистрите на приложения поставят допълнителен софтуерен слой върху действителните данни, по този начин:

• Направете системата за одит по-уязвима към програмни грешки/неправилна конфигурация
• Създаване на потенциална дупка в процеса на регистриране, ако някой се опита да получи достъп до данни директно в базата данни, заобикаляйки системата за регистриране на приложения, като например привилегирован потребител или DBA.
• Да направим системата за одит по-сложна и по-трудна за управление и поддръжка, в случай че имаме много приложения или много софтуерни екипи.

Така че в идеалния случай бихме търсили най-доброто от двете:да имаме използваеми одитни пътеки с най-голямо покритие на цялата система, включително слоя на база данни, и конфигурируеми на едно място, така че самото регистриране да може лесно да бъде одитирано с помощта на други ( системни) регистрационни файлове.

Регистриране на одит с PostgreSQL

Опциите, които имаме в PostgreSQL относно регистрирането на одит са следните:

• Чрез използване на изчерпателно регистриране ( log_statement =всички)
• Чрез написване на персонализирано решение за задействане
• Чрез използване на стандартни PostgreSQL инструменти, предоставени от общността, като
  • audit-trigger 91plus (https://github.com/2ndQuadrant/audit-trigger)
  • разширение pgaudit (https://github.com/pgaudit/pgaudit)

Изчерпателното регистриране поне за стандартна употреба в OLTP или OLAP работни натоварвания трябва да се избягва, защото:

• Създава огромни файлове, увеличава натоварването
• Няма вътрешни познания за достъпни или модифицирани таблици, просто отпечатва израза, който може да е блок DO с криптичен конкатениран израз
• Има нужда от допълнителен софтуер/ресурси за офлайн анализ и обработка (за да се изготвят одитни пътеки), които от своя страна трябва да бъдат включени в обхвата на одита, за да се считат за надеждни.

В останалата част от тази статия ще изпробваме инструментите, предоставени от общността. Да предположим, че имаме тази проста таблица, която искаме да проверим:

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)

одит-тригер 91plus

Документите за използването на тригера могат да бъдат намерени тук:https://wiki.postgresql.org/wiki/Audit_trigger_91plus. Първо изтегляме и инсталираме предоставения DDL (функции, схема):

$ 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.sql

След това дефинираме тригерите за поръчките на нашите таблици използвайки основната употреба:

myshop=# SELECT audit.audit_table('orders');

Това ще създаде две задействания за поръчки на таблица:задействане на ред insert_update_delere и задействане на израза за съкращаване. Сега нека видим какво прави спусъкът:

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    |

Обърнете внимание на стойността на change_fields в актуализацията (ЗАПИС 2). Има по-разширени употреби на тригера за одит, като изключване на колони или използване на клаузата WHEN, както е показано в документа. Изглежда, че тригерът за одит върши работата по създаването на полезни одитни пътеки в таблицата audit.logged_actions. Има обаче някои предупреждения:

• Не се проследяват SELECT (тригерите не се задействат при SELECT) или DDL
• Промените от собственици на таблици и супер потребители могат лесно да бъдат подправени
• Трябва да се следват най-добрите практики по отношение на потребителя(ите) на приложението и собствениците на схеми и таблици на приложението

Проверка

Pgaudit е най-новото допълнение към PostgreSQL, що се отнася до одита. Pgaudit трябва да бъде инсталиран като разширение, както е показано на страницата на github на проекта:https://github.com/pgaudit/pgaudit. Pgaudit се регистрира в стандартния дневник на PostgreSQL. Pgaudit работи, като се регистрира при зареждане на модула и предоставя куки за executorStart, executorCheckPerms, processUtility и object_access. Следователно pgaudit (за разлика от базираните на тригер решения, като одит-тригер, обсъдени в предишните параграфи) поддържа READs (SELECT, COPY). Обикновено с pgaudit можем да имаме два режима на работа или да ги използваме комбинирано:

• Регистриране на одит на SESSION
• Регистриране на одит на ОБЕКТ

Регистрирането на одит на сесията поддържа повечето DML, DDL, привилегии и други команди чрез класове:

• ЧЕТЕНЕ (изберете, копирайте от)
• ЗАПИШЕТЕ (вмъкнете, актуализирайте, изтрийте, съкратете, копирайте в)
• FUNCTION (извиквания на функции и DO блокове)
• РОЛЯ (предоставяне, отмяна, създаване/промяна/прехвърляне на роля)
• DDL (всички DDL с изключение на тези в ROLE)
• MISC (изхвърляне, извличане, контролна точка, вакуум)

Метакласът „всички“ включва всички класове. - изключва клас. Например нека конфигурираме регистрирането на одит на сесията за всички, с изключение на MISC, със следните GUC параметри в postgresql.conf:

pgaudit.log_catalog = off
pgaudit.log = 'all, -misc'
pgaudit.log_relation = 'on'
pgaudit.log_parameter = 'on'

Като дадете следните команди (същите като в примера за тригера)

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=#

Получаваме следните записи в дневника на PostgreSQL:

% 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>

Имайте предвид, че текстът след AUDIT:представлява перфектна одитна пътека, почти готова за изпращане на одитора в готов за електронни таблици csv формат. Използването на регистриране на одит на сесията ще ни даде записи в журнала за одит за всички операции, принадлежащи към класовете, дефинирани от параметъра pgaudit.log на всички маси. Има обаче случаи, в които искаме само малка част от данните, т.е. само няколко таблици, да бъдат одитирани. В такива случаи може да предпочетем регистриране на одит на обекти, което ни дава фини критерии за избрани таблици/колони чрез системата за привилегии на PostgreSQL. За да започнем да използваме регистрирането на одит на обекти, първо трябва да конфигурираме параметъра pgaudit.role, който дефинира главната роля, която pgaudit ще използва. Има смисъл да не давате на този потребител никакви права за влизане.

CREATE ROLE auditor;
ALTER ROLE auditor WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION NOBYPASSRLS CONNECTION LIMIT 0;

Посочваме тази стойност за pgaudit.role в postgresql.conf:

pgaudit.log = none # no need for extensive SESSION logging
pgaudit.role = auditor

Регистрирането на Pgaudit OBJECT ще работи чрез намиране на потребител одитор се предоставя (пряко или наследено) правото да изпълни посоченото действие, извършено върху отношенията/колоните, използвани в изявление. Така че, ако трябва да игнорираме всички таблици, но имаме подробно регистриране в поръчките на таблици, това е начинът да го направим:

grant ALL on orders to auditor ;

С горното разрешение ние позволяваме пълно SELECT, INSERT, UPDATE и DELETE влизане в поръчките на таблицата. Нека дадем още веднъж INSERT, UPDATE, DELETE от предишните примери и да гледаме дневника на 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>

Забелязваме, че изходът е идентичен с регистрирането на SESSION, обсъдено по-горе, с тази разлика, че вместо SESSION като тип одит (низът до AUDIT:) сега получаваме OBJECT.

Едно предупреждение при регистрирането на OBJECT е, че TRUNCATE не се записват. За това трябва да прибегнем до регистриране на SESSION. Но в този случай получаваме цялата активност WRITE за всички таблици. Има разговори между участващите хакери всяка команда да стане отделен клас.

Друго нещо, което трябва да имате предвид, е, че в случай на наследяване, ако ПРЕДОСТАВИМ достъп на одитора на някаква дъщерна таблица, а не на родителя, действията върху родителската таблица, които се превеждат в действия върху редове на дъщерната таблица, няма да бъдат регистрирани.

В допълнение към горното, ИТ хората, отговарящи за целостта на регистрационните файлове, трябва да документират строга и добре дефинирана процедура, която обхваща извличането на одитната пътека от регистрационните файлове на PostgreSQL. Тези регистрационни файлове може да се предават поточно към външен защитен сървър на системни дневници, за да се сведат до минимум шансовете за намеса или подправяне.

Резюме

Надяваме се, че този блог ви е помогнал да разберете по-добре най-добрите практики за регистриране на одит в PostgreSQL и защо създаването на одитна пътека е толкова важно при подготовката за одит на ИТ. Одитната пътека ще предостави набор от чиста, използваема информация, която ще помогне на вашия одит да върви гладко.

ClusterControl може да помогне за автоматизирането и управлението на повечето задачи, свързани с базата данни, като същевременно гарантира сигурността, наличността и производителността на базата данни — независимо от избраната от вас система. Изтеглете безплатна пробна версия на ClusterControl днес, за да видите как вашият бизнес може да се възползва от инструмента и операциите, които извършва. Ако все още не сте го направили, не забравяйте да ни последвате в Twitter и LinkedIn и да се абонирате за нашата емисия и ще се видим в следващия блог.