Казвам се Денис Рожков, аз съм ръководител на разработката на софтуер в компанията Gazinformservice, в продуктовия екип Ятоба. Законодателството и корпоративните разпоредби налагат определени изисквания за сигурността на съхранението на данни. Никой не иска трети страни да получат достъп до поверителна информация, така че следните въпроси са важни за всеки проект: идентификация и удостоверяване, управление на достъпа до данни, гарантиране на целостта на информацията в системата, регистриране на събития за сигурност. Затова искам да говоря за някои интересни точки относно сигурността на СУБД.

Статията е подготвена въз основа на реч на @DatabasesMeetup, организиран Облачни решения на Mail.ru. Ако не искате да четете, можете да гледате:

Статията ще има три части:

• Как да защитим връзките.
• Какво е одит на действията и как да записвате какво се случва от страна на базата данни и свързването с нея.
• Как да защитим данните в самата база данни и какви технологии има за това.

Три компонента на сигурността на СУБД: защита на връзката, одит на дейността и защита на данните

Защита на вашите връзки

Можете да се свържете с базата данни директно или индиректно чрез уеб приложения. По правило бизнес потребителят, т.е. лицето, което работи със СУБД, взаимодейства с него индиректно.

Преди да говорите за защита на връзките, трябва да отговорите на важни въпроси, които определят как ще бъдат структурирани мерките за сигурност:

• Един бизнес потребител еквивалентен ли е на един потребител на СУБД?
• дали достъпът до данните от СУБД се предоставя само чрез API, който контролирате, или дали таблиците се достъпват директно;
• дали СУБД е разпределена в отделен защитен сегмент, кой взаимодейства с нея и как;
• дали се използват пулинг/прокси и междинни слоеве, които могат да променят информацията за това как е изградена връзката и кой използва базата данни.

Сега нека да видим какви инструменти могат да се използват за защита на връзките:

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

   Можете да прочетете повече за функциите за оценка на потребителите тук, можете също да разберете за MS SQL Vulnerability Assessmen тук. 

3. Обогатете контекста на сесията с необходимата информация. Ако сесията е непрозрачна, не разбирате кой работи в СУБД в нейната рамка, можете в рамките на изпълняваната операция да добавите информация за това кой какво прави и защо. Тази информация може да се види в одита.
4. Конфигурирайте SSL, ако нямате мрежово разделение между СУБД и крайните потребители; не е в отделна VLAN. В такива случаи е наложително да се защити каналът между потребителя и самата СУБД. Инструментите за сигурност също са налични в отворен код.

Как това ще повлияе на производителността на СУБД?

Нека да разгледаме примера на PostgreSQL, за да видим как SSL влияе върху натоварването на процесора, увеличава времената и намалява TPS и дали ще консумира твърде много ресурси, ако го активирате.

Зареждането на PostgreSQL с помощта на pgbench е проста програма за провеждане на тестове за производителност. Той изпълнява една последователност от команди многократно, вероятно в паралелни сесии на базата данни, и след това изчислява средната скорост на транзакция.

Тест 1 без SSL и с помощта на SSL — връзката се установява за всяка транзакция:

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require 
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

Тест 2 без SSL и с помощта на SSL — всички транзакции се извършват в една връзка:

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

Други настройки:

scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000

Резултати от теста:

 
БЕЗ SSL
SSL

За всяка транзакция се установява връзка

средна латентност
171.915 мс
187.695 мс

tps включително установяване на връзки
58.168112
53.278062

tps с изключение на установяването на връзки
64.084546
58.725846

процесор
24%
28%

Всички транзакции се извършват в една връзка

средна латентност
6.722 мс
6.342 мс

tps включително установяване на връзки
1587.657278
1576.792883

tps с изключение на установяването на връзки
1588.380574
1577.694766

процесор
17%
21%

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

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

Имахме случай, когато свързахме Zabbix в режим на доверие, тоест md5 не беше проверен, нямаше нужда от удостоверяване. Тогава клиентът поиска да активира режима за удостоверяване на md5. Това натовари много процесора и производителността падна. Започнахме да търсим начини за оптимизиране. Едно от възможните решения на проблема е да се приложат мрежови ограничения, да се направят отделни VLAN за СУБД, да се добавят настройки, за да стане ясно кой откъде се свързва и да се премахне удостоверяването.Можете също така да оптимизирате настройките за удостоверяване, за да намалите разходите, когато активирате удостоверяването, но като цяло използването на различни методи за удостоверяване влияе върху производителността и изисква тези фактори да се вземат предвид при проектирането на изчислителната мощност на сървърите (хардуера) за СУБД.

Заключение: в редица решения дори малки нюанси в удостоверяването могат значително да повлияят на проекта и е лошо, когато това стане ясно само когато се внедри в производството.

Одит на действие

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

В комерсиалните СУБД на корпоративно ниво всичко е наред с одита, но в отворен код - не винаги. Ето какво има PostgreSQL:

• дневник по подразбиране - вградено логване;
• разширения: pgaudit - ако регистрирането по подразбиране не е достатъчно за вас, можете да използвате отделни настройки, които решават някои проблеми.

Допълнение към репортажа във видеото:

„Регистрирането на основни отчети може да бъде предоставено от стандартно средство за регистриране с log_statement = all.

Това е приемливо за наблюдение и други употреби, но не предоставя нивото на детайлност, което обикновено се изисква за одит.

Не е достатъчно да имате списък на всички операции, извършени в базата данни.

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

Стандартното регистриране показва какво е поискал потребителят, докато pgAudit се фокусира върху подробностите за случилото се, когато базата данни е изпълнила заявката.

Например, одиторът може да поиска да провери дали определена таблица е създадена в рамките на документиран прозорец за поддръжка.

Това може да изглежда като проста задача с основен одит и grep, но какво ще стане, ако ви бъде представен нещо като този (умишлено объркващ) пример:

НАПРАВЕТЕ $$
ЗАПОЧНЕТЕ
ИЗПЪЛНЕТЕ 'CREATE TABLE import' || 'ant_table(id int)';
КРАЙ$$;

Стандартното регистриране ще ви даде това:

LOG: израз: DO $$
ЗАПОЧНЕТЕ
ИЗПЪЛНЕТЕ 'CREATE TABLE import' || 'ant_table(id int)';
КРАЙ$$;

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

Това не е идеално, тъй като би било за предпочитане просто да търсите по име на таблица.

Това е мястото, където pgAudit идва на помощ.

За същия вход той ще произведе този изход в дневника:

ОДИТ: SESSION,33,1,FUNCTION,DO,,,"DO $$
ЗАПОЧНЕТЕ
ИЗПЪЛНЕТЕ 'CREATE TABLE import' || 'ant_table(id int)';
КРАЙ$$;"
ОДИТ: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)

Записва се не само блокът DO, но и пълният текст на CREATE TABLE с тип оператор, тип обект и пълно име, което прави търсенето по-лесно.

Когато регистрира SELECT и DML изрази, pgAudit може да бъде конфигуриран да регистрира отделен запис за всяка връзка, посочена в израза.

Не се изисква синтактичен анализ, за ​​да се намерят всички изрази, които засягат определена таблица(*) ».

Как това ще повлияе на производителността на СУБД?

Нека да проведем тестове с активиран пълен одит и да видим какво се случва с производителността на PostgreSQL. Нека активираме максимално регистриране в базата данни за всички параметри.

Не променяме почти нищо в конфигурационния файл, най-важното е да включите режима debug5, за да получите максимална информация.

postgresql.conf

log_destination = 'stderr'
logging_collector = включено
log_truncate_on_rotation = включено
log_rotation_age = 1г
log_rotation_size = 10MB
log_min_messages = отстраняване на грешки5
log_min_error_statement = отстраняване на грешки5
log_min_duration_statement = 0
debug_print_parse = включено
debug_print_rewritten = включено
debug_print_plan = включен
debug_pretty_print = включено
log_checkpoints = включено
log_connections = включено
log_disconnections = включено
log_duration = включено
log_hostname = включено
log_lock_wait = включено
log_replication_commands = включено
log_temp_files = 0
log_timezone = 'Европа/Москва'

На СУБД PostgreSQL с параметри 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD, провеждаме три теста за натоварване, използвайки командите:

$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmark

Резултати от тестовете:

Без регистриране
С дърводобив

Общо време за попълване на базата данни
43,74 сек
53,23 сек

RAM
24%
40%

процесор
72%
91%

Тест 1 (50 връзки)

Брой транзакции за 10 минути
74169
32445

Транзакции/сек
123
54

Средна латентност
405 ms
925 ms

Тест 2 (150 връзки със 100 възможни)

Брой транзакции за 10 минути
81727
31429

Транзакции/сек
136
52

Средна латентност
550 ms
1432 ms

Относно размерите

Размер на DB
2251 MB
2262 MB

Размер на регистрационния файл на базата данни
0 MB
4587 MB

В крайна сметка: пълен одит не е много добър. Данните от одита ще бъдат толкова големи, колкото данните в самата база данни или дори повече. Количеството регистриране, което се генерира при работа с СУБД, е често срещан проблем в производството.

Нека да разгледаме другите параметри:

• Скоростта не се променя много: без регистриране - 43,74 секунди, с регистриране - 53,23 секунди.
• Производителността на RAM и CPU ще пострада, тъй като трябва да генерирате файл за проверка. Това се забелязва и в производителността.

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

В корпорациите с одит е още по-трудно:

• има много данни;
• одитът е необходим не само чрез syslog в SIEM, но и във файлове: ако нещо се случи с syslog, трябва да има файл близо до базата данни, в която се записват данните;
• необходим е отделен рафт за одит, за да не се хабят I/O дискове, тъй като заема много място;
• Случва се служителите по информационна сигурност да се нуждаят от стандарти GOST навсякъде, те изискват държавна идентификация.

Ограничаване на достъпа до данни

Нека да разгледаме технологиите, които се използват за защита на данни и достъп до тях в комерсиални СУБД и отворен код.

Какво можете да използвате като цяло:

1. Криптиране и обфускация на процедури и функции (Wrapping) - т.е. отделни инструменти и помощни програми, които правят четливия код нечетим. Вярно е, че тогава не може нито да се промени, нито да се преработи обратно. Този подход понякога се изисква поне от страна на СУБД - логиката на лицензионните ограничения или логиката на оторизацията е криптирана точно на ниво процедура и функция.
2. Ограничаването на видимостта на данните по редове (RLS) е, когато различни потребители виждат една таблица, но различен състав от редове в нея, тоест нещо не може да се покаже на някого на ниво ред.
3. Редактирането на показаните данни (Маскиране) е когато потребителите в една колона на таблицата виждат или данни, или само звездички, т.е. за някои потребители информацията ще бъде затворена. Технологията определя на кой потребител какво се показва въз основа на неговото ниво на достъп.
4. Сигурност DBA/Application DBA/DBA контрол на достъпа е по-скоро за ограничаване на достъпа до самата СУБД, тоест служителите по сигурността на информацията могат да бъдат отделени от администраторите на бази данни и администраторите на приложения. Има малко такива технологии в отворения код, но има много от тях в комерсиалните СУБД. Те са необходими, когато има много потребители с достъп до самите сървъри.
5. Ограничаване на достъпа до файлове на ниво файлова система. Можете да предоставите права и привилегии за достъп до директории, така че всеки администратор да има достъп само до необходимите данни.
6. Задължителен достъп и изчистване на паметта - тези технологии се използват рядко.
7. Криптирането от край до край директно от СУБД е криптиране от страна на клиента с управление на ключове от страната на сървъра.
8. Криптиране на данни. Например колонно криптиране е, когато използвате механизъм, който криптира една колона от базата данни.

Как това се отразява на производителността на СУБД?

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

Нека тестваме с pgcrypto. Нека създадем таблица с криптирани данни и обикновени данни. По-долу са командите за създаване на таблици, в първия ред има полезна команда - създаване на самото разширение с регистрация в СУБД:

CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));

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

Избор от таблица без функция за криптиране:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

Хронометърът е включен.

  ID | текст1 | текст2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 реда)

Време: 1,386 ms

Избор от таблица с функция за криптиране:

psql -c "timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txt

Хронометърът е включен.

  ID | декриптиране | декриптиране
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 реда)

Време: 50,203 ms

Резултати от теста:

 
Без криптиране
Pgcrypto (декриптиране)

Примерни 1000 реда
1,386 ms
50,203 ms

процесор
15%
35%

RAM
 
+ 5%

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

Шифроването обаче не е сребърен куршум, който решава всички проблеми. Декриптираните данни и ключът за декриптиране по време на процеса на декриптиране и предаване на данните се намират на сървъра. Следователно ключовете могат да бъдат прихванати от някой, който има пълен достъп до сървъра на базата данни, като например системен администратор.

Когато има един ключ за цялата колона за всички потребители (дори и не за всички, а за клиенти от ограничен набор), това не винаги е добро и правилно. Ето защо те започнаха да правят криптиране от край до край, в СУБД започнаха да обмислят опции за криптиране на данни от страна на клиента и сървъра и се появиха същите хранилища за ключове - отделни продукти, които осигуряват управление на ключове в СУБД страна.

Пример за такова криптиране в MongoDB

Функции за сигурност в търговски и СУБД с отворен код

функции
Тип
Политика за пароли
Проверка
Защита на изходния код на процедури и функции
RLS
Encryption

Оракул
търговски
+
+
+
+
+

MsSql
търговски
+
+
+
+
+

Ятоба
търговски
+
+
+
+
разширения

PostgreSQL
Безплатно
разширения
разширения
-
+
разширения

MongoDb
Безплатно
-
+
-
-
Предлага се само в MongoDB Enterprise

Таблицата далеч не е пълна, но ситуацията е следната: в комерсиалните продукти проблемите със сигурността са решени отдавна, в отворен код като правило се използват някакви добавки за сигурност, много функции липсват , понякога трябва да добавите нещо. Например правила за пароли - PostgreSQL има много различни разширения (1, 2, 3, 4, 5), които прилагат политики за пароли, но според мен нито една от тях не покрива всички нужди на вътрешния корпоративен сегмент.

Какво да направите, ако никъде нямате това, от което се нуждаете? Например искате да използвате конкретна СУБД, която няма функциите, изисквани от клиента.

След това можете да използвате решения на трети страни, които работят с различни СУБД, например Crypto DB или Garda DB. Ако говорим за решения от домашния сегмент, тогава те знаят за GOST по-добре, отколкото в отворен код.

Вторият вариант е сами да напишете това, от което се нуждаете, да внедрите достъп до данни и криптиране в приложението на ниво процедура. Вярно е, че ще бъде по-трудно с GOST. Но като цяло можете да скриете данните според нуждите, да ги поставите в СУБД, след това да ги извлечете и декриптирате според нуждите, направо на ниво приложение. В същото време веднага помислете как ще защитите тези алгоритми в приложението. Според нас това трябва да стане на ниво СУБД, защото ще работи по-бързо.

Този доклад беше представен за първи път на @Databases Meetup от Mail.ru Cloud Solutions. Вижте видео други изпълнения и се абонирайте за съобщения за събития в Telegram Около Kubernetes в Mail.ru Group.

Какво още да прочетете по темата:

1. Повече от Ceph: MCS облачно блоково съхранение.
2. Как да изберете база данни за проект, за да не се налага да избирате отново.

Източник: www.habr.com