Как да защитите вашите PostgreSQL бази данни от кибератаки с SQL защитна стена

След това на потребителските роли се предоставя разрешение за достъп до базите данни chinook и pagila, като се изпълняват следните команди като потребител на postgres:

$ psql -d postgres -c "ПРЕДОСТАВЯ ВРЪЗКА КЪМ БАЗА ДАННИ pagila, chinook КЪМ app_user;"$ psql -d chinook -c "ПРЕДОСТАВЯ ИЗПОЛЗВАНЕ НА СХЕМА public TO app_user;"$ psql -d chinook -c "ПРЕДОСТАВЯ ИЗПОЛЗВАНЕ, ИЗБЕРЕТЕ ВСИЧКИ ПОСЛЕДОВАТЕЛНОСТИ В СХЕМАТА public TO app_user;"$ psql -d chinook -c "ПРЕДОСТАВЯТЕ ИЗБОР, ВМЕСВАНЕ, АКТУАЛИЗИРАНЕ, ИЗТРИВАНЕ, ОТСЪЖАНЕ, ЗАПУСКАНЕ, ПРЕПОРЪЧКИ ВЪРХУ ВСИЧКИ ТАБЛИЦИ В СХЕМА public TO app_user -"$ chipsqokc -dchipsqokl - "ПРЕДОСТАВЕТЕ ИЗПЪЛНЕНИЕ НА ВСИЧКИ ФУНКЦИИ В СХЕМАТА public TO app_user;"$ psql -d pagila -c "ПРЕДОСТАВЯНЕ НА ИЗПОЛЗВАНЕ НА SCHEMA public TO app_user;"$ psql -d pagila -c "ПРЕДОСТАВЯНЕ НА ИЗПОЛЗВАНЕ, ИЗБЕРЕТЕ ВСИЧКИ ПОСЛЕДОВАТЕЛИ В SCHEMA public на app_user;"$ psql -d pagila -c "ПРЕДОСТАВЯ ИЗБИРАНЕ, ВМЕСВАНЕ, АКТУАЛИЗИРАНЕ, ИЗТРИВАНЕ, ОТСЪЩАНЕ, ЗАПУСКАНЕ, ПРЕПОРЪЧКИ ВЪРХУ ВСИЧКИ ТАБЛИЦИ В СХЕМАТА public TO app_user;"$ psql -d pagila -c "ПРЕДОСТАВЯ ИЗПЪЛНЕНИЕ НА ВСИЧКИ обществени ФУНКЦИИ КЪМ app_user;"$ psql -d postgres -c "ПРЕДОСТАВЯ СВЪРЗВАНЕ ВЪРХУ БАЗА ДАННИ pagila, chinook КЪМ human_user;"$ psql -d chinook -c "ПРЕДОСТАВЯ ИЗПОЛЗВАНЕ НА СХЕМА public TO human_user;"$ psql -d chinook -c "ПРЕДОСТАВЯ ИЗПОЛЗВАНЕ НА СХЕМА НА human_user;" , ИЗБЕРЕТЕ ВСИЧКИ ПОСЛЕДОВАТЕЛНОСТИ В СХЕМАТА public TO human_user;"$ psql -d chinook -c "ПРЕДОСТАВЯТЕ ИЗБОР, ВМЕСВАНЕ, АКТУАЛИЗИРАНЕ, ИЗТРИВАНЕ, ОТСЪЖАНЕ, ЗАПУСКАНЕ, ПРЕПОРЪЧКИ ВЪРХУ ВСИЧКИ ТАБЛИЦИ В СХЕМА public TO human_user;"$ chipsqokc -dchipsqokc -DELETE, ОТСЪЖАНЕ, TRIGGER "ПРЕДОСТАВЯ ИЗПЪЛНЕНИЕ НА ВСИЧКИ ФУНКЦИИ В СХЕМАТА public TO human_user;"$ psql -d pagila -c "ПРЕДОСТАВЯ ИЗПОЛЗВАНЕ НА СХЕМА public TO human_user;"$ psql -d pagila -c "ПРЕДОСТАВЯ ИЗПОЛЗВАНЕ, ИЗБЕРЕ ЗА ВСИЧКИ ПОСЛЕДОВАТЕЛИ В SCHEMA public;"$ psql -d pagila -c "ПРЕДОСТАВЯ ИЗБИРАНЕ, ВМЕСВАНЕ, АКТУАЛИЗИРАНЕ, ИЗТРИВАНЕ, ОТСЪЗНЯВАНЕ, ЗАПУСКАНЕ, РЕФЕРЕНЦИ ВЪРХУ ВСИЧКИ ТАБЛИЦИ В СХЕМА public TO human_user;"$ psql -d pagila -c "ПРЕДОСТАВЯ ИЗПЪЛНЕНИЕ НА ВСИЧКИ обществени ФУНКЦИИ ДО human_user;"

Стъпка 4:Инсталиране на SQL защитна стена

Инсталирането на SQL защитна стена е лесен процес. Първо, инсталираме пакета.

# rpm -ivh postgresql10-sqlfirewall-3.0-1.el7.x86_64.rpm предупреждение:postgresql10-sqlfirewall-3.0-1.el7.x86_64.rpm:Header V4 RSA/SHA1 подпис, ключ ID ******:NOKEYPreparing...                          ######### ################### [100%]Актуализиране/инсталиране...1:postgresql10-sqlfirewall-3.0-1.el########## ####################### [100%]

След това актуализираме файла postgresql.conf, като променим параметъра shared_preload_libraries.

shared_preload_libraries ='sqlfirewall'

След като приключим, рестартираме услугата PostgreSQL.

# systemctl рестартирайте postgresql-10.service

След като услугата се рестартира, влизаме в екземпляра като потребител на postgres и добавяме разширението към двете примерни бази данни.

$ psql -U postgres -d chinook -c "СЪЗДАВАНЕ НА РАЗШИРЕНИЕ sqlfirewall;"Парола за потребителя postgres:СЪЗДАВАНЕ НА РАЗШИРЕНИЕ -bash-4.2$ psql -U postgres -d pagila -c "СЪЗДАВАНЕ НА РАЗШИРЕНИЕ sqlfirewall;"Парола за потребителя postgres:СЪЗДАВАНЕ НА РАЗШИРЕНИЕ 

Изображението по-долу показва разширенията, инсталирани и в двете бази данни. Обърнете внимание как има специална схема, наречена „sqlfirewall“, създадена и в двете бази данни. Тази схема съдържа всички обекти на базата данни, свързани с работата на защитната стена на SQL.

Можем също да видим, че автоматично се създава нова роля, наречена „sqlfirewall_manager“. Потребителите, които са добавени към тази роля, имат достъп до функции и изгледи в схемата на sqlfirewall.

Стъпка 5:Конфигуриране на SQL защитна стена

След това към postgresql.conf се добавят редица параметри файл. За Red Hat Enterprise Linux и неговите производни дистрибуции, местоположението на директорията по подразбиране за този файл е /var/lib/pgsql/10/data/.

В следния кодов фрагмент ние редактираме файла и добавяме редица параметри.

# vim /var/lib/pgsql/10/data/postgresql.confsqlfirewall.whitelist ='verbose'sqlfirewall.track ='all'sqlfirewall.track_utility ='true'sqlfirewall.save ='вярно'

След това презареждаме цялата конфигурация.

$ psql -U postgres -d postgresPassword за потребител postgres:psql (10.12) Въведете "help" за help.postgres=# ИЗБЕРЕТЕ pg_reload_conf(); pg_reload_conf---------------- t(1 ред)

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

postgres=# ИЗБЕРЕТЕ pg_sleep(1); pg_sleep---------(1 ред)

и след това проверете състоянието на белия списък и в двете бази данни. Ако стъпките са били следвани, и двете бази данни трябва да имат активиран бели списък.

postgres=# \connect pagila Вече сте свързани към базата данни "pagila" като потребител "postgres".pagila=# покажи sqlfirewall.whitelist; sqlfirewall.whitelist----------------------- подробно (1 ред)pagila=# \connect chinook;Сега сте свързани към базата данни "chinook" като потребител "postgres".chinook=# покажи sqlfirewall.whitelist; sqlfirewall.whitelist----------------------- подробно (1 ред)

Нека да преминем през параметрите, които току-що добавихме.

sqlfirewall.whitelist параметърът се използва за активиране на функцията за бели списък на защитната стена. Този параметър може да има една от двете стойности:„подробно“ или „защита“.

С многословната опция SQL Firewall ще покаже предупредително съобщение на потребителя, когато се опита да изпълни заявка, която не е в белия списък, че не им е разрешено да го направят. Когато стойността е зададена на protected, SQL защитната стена ще покаже общо съобщение „отказано разрешение“. Като най-добра практика препоръчваме да зададете стойността на „protect“, което не дава на хакера никаква представа защо командата е отхвърлена. Зададохме този параметър на „подробно“ само с демонстрационна цел.

Стойностите, присвоени на sqlfirewall.track и sqlfirewall.track_utility параметри гарантират, че защитната стена на SQL проследява всички изрази за целите на белия списък.

И накрая, задаване на sqlfirewall.save параметърът на „true“ гарантира, че изразите в белия списък се запазват, дори ако сървърът се рестартира.

Изпълнение на SQL защитна стена

Изпълнението на SQL защитна стена включва извикване на редица функции, които идват с разширението.

Стъпка 1:Разбиране на функциите на защитната стена на SQL

Разширението SQL Firewall създава редица функции в схемата sqlfirewall на базата данни, където е инсталирана. Повечето от тези функции могат да се изпълняват само от суперпотребители или членове на ролята sqlfirewall_manager.

Нека бързо да преминем през някои от тези функции.

sqlfirewall_whitelist_mode е основната функция, с която ще работим. Тази функция позволява белия списък на изразите за конкретен потребител на PostgreSQL. Необходими са два параметъра:единият е потребителското име, другият е whitelist_mode.

режимът на бял списък параметърът може да има три стойности:

• Когато е зададено на „ЗАПИС ”, Защитната стена на SQL ще записва всички изрази, изпълнени от потребителя в белия списък на потребителя
  
• Когато е зададено на „ENFORCE ”, Защитната стена на SQL ще наложи белия списък. Всяко изявление, което не е включено в белия списък, ще доведе до грешка
  
• Стойността на „ИЗКЛ. ” изключва функционалността на белия списък за потребителя и потребителят изобщо няма да може да изпълнява никакви заявки.

Ако искате да премахнете заявките от белия списък за потребител, стартирайте sqlfirewall_whitelist_delete функция вместо това. Тази функция приема един параметър:потребителското име. След като се изпълни, функцията sqlfirewall_whitelist_delete премахва всички изрази от белия списък за потребителя.

sqlfirewall_whitelist_delete_entry функцията се използва за премахване на индивидуални идентификатори на заявка от белия списък на потребителя. Това може да бъде полезно, когато имате твърде много разрешени заявки за потребител и искате да го настроите фино. Функцията приема два параметъра:потребителско име и идентификатор на заявката. Можете да намерите идентификатора на заявката, която искате да изключите от белия списък, като погледнете изгледа sqlfirewall.

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

Можете да експортирате белия списък за потребител с помощта на sqlfirewall_whitelist_export функция. Тази функция приема два параметъра:потребителското име и името на файла, където експортира изразите на потребителя в белия списък. Файлът трябва да е на място, където сървърният процес на PostgreSQL има достъп за запис.

Подобно на функцията sqlfirewall_whitelist_export, функцията sqlfirewall_whitelist_import се използва за импортиране на експортиран файл с бял списък за потребител в различен екземпляр на PostgreSQL за този потребител. Тази функция също приема два параметъра, потребителското име и файла за импортиране. Файлът трябва да е на място, от което сървърният процес на PostgreSQL може да го прочете.

Освен това целевата база данни трябва да бъде двоично копие на изходната база данни – това означава, че целта трябва да бъде част от поточно репликация или PostgreSQL екземпляр, създаден от източник с командата pg_basebackup. Базите данни, създадени от логически дъмп на изходната база данни, не могат да импортират файла с белия списък – в такива случаи белият списък трябва да се конфигурира ръчно.

Стъпка 2:Активиране на белия списък за потребители

Сега, когато имаме някои идеи за функциите на защитната стена на SQL, нека започнем процеса на бели списък както за human_user, така и за app_user в базите данни pagila и chinook.

В кодовия фрагмент по-долу изпълняваме следните команди като суперпотребител на postgres.

postgres=# \connect pagila Вече сте свързани към базата данни "pagila" като потребител "postgres".pagila=# ИЗБЕРЕТЕ sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'RECORD'); sqlfirewall_whitelist_mode---------------------------- t(1 ред)pagila=# ИЗБЕРЕТЕ sqlfirewall.sqlfirewall_whitelist_mode('app_user', ' ЗАПИС');\ sqlfirewall_whitelist_mode---------------------------- t(1 ред)pagila=# \connect chinook Вече сте свързани към базата данни "chinook" като потребител "postgres".chinook=# ИЗБЕРЕТЕ sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'RECORD'); sqlfirewall_whitelist_mode---------------------------- t(1 ред)chinook=# ИЗБЕРЕТЕ sqlfirewall.sqlfirewall_whitelist_mode('app_user', ' ЗАПИС"); sqlfirewall_whitelist_mode---------------------------- t(1 ред)

Можем също да потвърдим, като изпълним функцията sqlfirewall_whitelist_users().

$ psql -U postgres -d pagila -c "SELECT sqlfirewall.sqlfirewall_whitelist_users();"Парола за потребител postgres: sqlfirewall_whitelist_users ---------------------------- (17479,human_user ,ЗАПИСИ ) (17480,app_user ,ЗАПИСИ )(2 реда)$ psql -U postgres -d chinook -c "SELECT sqlfirewall.sqlfirewall_whitelist_users();"Парола за потребител postgres: sqlfirewall_whitelist_users ---------------------------- (17479,human_user ,ЗАПИСИ ) (17480,app_user ,ЗАПИСИ )(2 реда)

Стъпка 3:Изпълнение на работно натоварване

С активиран белия списък и запис, ние преминаваме към акаунта на app_user и изпълняваме някои заявки, както е показано по-долу. Забележете как app_user избира различни „идентификационни полета“ (customer_id, staff_id, EmployeeID и т.н.) от различни таблици.

postgres=# \c - app_userPassword за потребител app_user:Вече сте свързани към базата данни "postgres" като потребител "app_user".postgres=> \connect pagila Вече сте свързани към базата данни "pagila" като потребител "app_user".pagila => ИЗБЕРЕТЕ customer_id, first_name, last_name, email FROM public.customer;...pagila=> SELECT payment_id, client_id, payment_date, amount FROM public.payment;...pagila=> SELECT staff_id, first_name, last_name, email FROM public .staff;...pagila=> \connect chinook;Сега сте свързани към базата данни "chinook" като потребител "app_user".chinook=> ИЗБЕРЕТЕ "CustomerId", "FirstName", "LastName", "Phone" ОТ public. "Customer";...chinook=> ИЗБЕРЕТЕ "EmployeeId", "FirstName", "LastName", "Phone", "Email" FROM public."Employee";...

След това преминаваме към акаунта human_user и изпълняваме някои прости заявки към някои от таблиците, до които е достъпен app_user.

postgres=# \c - human_userPassword за потребител human_user:Вече сте свързани към базата данни "postgres" като потребител "human_user".postgres=> \connect pagila;Сега сте свързани към базата данни "pagila" като потребител "human_user" .pagila=> ИЗБЕРЕТЕ дата_на_плащане, сума ОТ public.payment;...pagila=> ИЗБЕРЕТЕ първо_име, фамилия, имейл ОТ public.customer;...pagila=> \connect chinook;Сега сте свързани с базата данни "chinook" като user "human_user".chinook=> ИЗБЕРЕТЕ "FirstName", "Lastname", "Phone", "Email" FROM public."Employee";...

Ако отправим заявка към изгледа sqlfirewall  от някоя от базите данни като потребител на postgres, можем да видим заявките, които са били в белия списък за всеки потребител.

Стъпка 4:Налагане на белия списък

С примерно работно натоварване, което сега е заснето, ние прилагаме белия списък за двата потребителски акаунта и в двете бази данни, като изпълним следните команди. Командите трябва да се изпълняват от суперпотребител; в този случай ги изпълняваме като потребител postgres.

postgres=# \connect pagila;Сега сте свързани към базата данни "pagila" като потребител "postgres".pagila=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'ENFORCE'); sqlfirewall_whitelist_mode---------------------------- t(1 ред)pagila=# ИЗБЕРЕТЕ sqlfirewall.sqlfirewall_whitelist_mode('app_user', ' ПРИЛОЖИ“); sqlfirewall_whitelist_mode---------------------------- t(1 ред)pagila=# \свържете chinook;Сега сте свързани към базата данни "chinook" като потребител "postgres".chinook=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'ENFORCE'); sqlfirewall_whitelist_mode---------------------------- t(1 ред)chinook=# ИЗБЕРЕТЕ sqlfirewall.sqlfirewall_whitelist_mode('app_user', ' ПРИЛОЖИ“); sqlfirewall_whitelist_mode---------------------------- t(1 ред)

Стъпка 5:Тестване

За да тестваме белия списък, ние влязохме в базата данни pagila като human_user и се опитахме да изпълним командите, които бяха изпълнявани преди

chinook=# \c - human_user;Парола за потребител human_user:Вече сте свързани към базата данни "chinook" като потребител "human_user".chinook=> \connect pagila;Сега сте свързани към базата данни "pagila" като потребител " human_user".pagila=> ИЗБЕРЕТЕ дата_на_плащане, сума ОТ public.payment;...pagila=> ИЗБЕРЕТЕ име, фамилия, имейл ОТ public.customer;...

Командите са успешни. Това е така, защото тези команди са били изпълнявани от human_user преди и са били в белия списък.

Сега се опитваме да изпълним следната команда. Обърнете внимание как human_user се опитва да изпълни заявка с две допълнителни полета. Тази заявка беше стартирана от app_user преди.

pagila=> ИЗБЕРЕТЕ pay_id, client_id, payment_date, сума ОТ public.payment;

Изявлението се проваля със съобщение като това:

ГРЕШКА:  Изпълнението на изявление, което не е в белия списък, е забранено 

Това се случва, защото human_user преди това е изпълнил команда, за да избере само две полета от тази таблица, а не допълнителните полета (идентификатор на плащане и идентификатор на клиента), до които се опитва да получи достъп сега. Защитната стена на SQL записа предишната му заявка като известно работно натоварване и добави тази заявка в белия списък. Докато се опитва да добави тези две нови полета в заявката си, защитната стена го блокира.

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

И така, какво се случва, ако потребителят се нуждае от тези две допълнителни полета за законна цел? В такъв случай режимът на белия списък за потребителя трябва да бъде променен отново на „ЗАПИСВАНЕ“, за да могат да се изпълняват новите заявки и  защитната стена на SQL да може да ги включи в белия списък.

Нека проведем още един тест, преди да приключим. Този път ще приемем, че хакер е компрометирал акаунта на app_user и иска да изпълни изявление за изтриване срещу таблицата „плащане“. Не забравяйте, че сме предоставили на потребителя привилегии DELETE и TRUNCATE на таблицата.

Така че влизаме като app_user и изпълняваме оператор DELETE.

pagila=> \c - app_userPassword за потребител app_user:Вече сте свързани към базата данни "pagila" като потребител "app_user".pagila=> ИЗТРИВАНЕ ОТ public.payment; ГРЕШКА:  Изпълнението на изявление, което не е в белия списък, е забранено 

Заключение

Изявлението е отхвърлено, защото не е в белия списък. Дори когато потребителят има право да изтрие данни от таблицата, защитната стена на SQL правилно ги е блокирала.

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

DBA и системните администратори обаче трябва да са наясно с няколко точки:

На първо място, когато режимът на белия списък на потребителя е зададен на „ЗАПИС“, SQL защитната стена не спира потребителя да изпълнява каквато и да е заявка. С други думи, SQL защитната стена трябва първо да бъде обучена, преди да може да блокира потребител. Ето защо е важно да се гарантира, че нормалните привилегии за достъп до базата данни се прилагат и към всеки потребителски акаунт. Това е още по-важно, защото членовете на ролите суперпотребител и sqlfirewall_manager са освободени от правилата на защитната стена. Защитната стена на SQL не е заместител на съществуващата защита на базата данни – тя е там, за да я допълни.

Второ, когато включва в белия списък отделни изрази SELECT, INSERT, UPDATE и DELETE, защитната стена на SQL ще третира имената на обекти, използвани в тези команди, написани в различни случаи (главни, смесени или малки букви), като едни и същи. Всички други команди ще бъдат сравнени на базата на текстовите низове на заявката. Така например защитната стена на SQL ще третира „BEGIN“ и „begin“ и „Begin“ като част от отделни заявки.

Трето, белият списък на защитната стена на SQL не се реплицира автоматично до възли в режим на готовност в среда за репликация. Можете обаче да експортирате бели списъци с помощта на функцията sqlfirewall_whitelist_export и да ги импортирате в друг сървър, като използвате функцията sqlfirewall_whitelist_import. За съжаление архивирането на базата данни или схемата sqlfirewall и възстановяването  в целевия екземпляр няма да работи. Освен това целевият сървър трябва да има същия потребителски акаунт, за да бъде полезен белият списък.

Трябва внимателно да се обмислят всички възможни типове заявки, които потребителят може да изпълни към база данни и да се изпълнява белият списък в режим „ЗАПИС“ толкова дълго, колкото е необходимо, за да се уловят всички нормални работни натоварвания. Твърде малкото заснемане може да ограничи потребителски акаунт от изпълнение на легитимни заявки, докато твърде дългото записване може ненужно да добави команди към белия списък. Това може да причини забавяне на защитната стена на SQL, когато тя сравнява изрази в режим на прилагане.