Јас се викам Денис Рожков, раководител сум за развој на софтвер во компанијата Газинформсервис, во тимот на производи Јатоба. Законодавството и корпоративните регулативи наметнуваат одредени барања за безбедноста на складирањето податоци. Никој не сака трети страни да добијат пристап до доверливи информации, затоа следниве прашања се важни за секој проект: идентификација и автентикација, управување со пристапот до податоците, обезбедување на интегритетот на информациите во системот, евиденција на безбедносни настани. Затоа, сакам да зборувам за некои интересни точки во врска со безбедноста на DBMS.

Статијата е подготвена врз основа на говор во @DatabasesMeetup, организирано Mail.ru Cloud Solutions. Доколку не сакате да читате, можете да гледате:

Статијата ќе има три дела:

• Како да ги обезбедите врските.
• Што е ревизија на акции и како да се евидентира што се случува на страната на базата на податоци и да се поврзе со неа.
• Како да се заштитат податоците во самата база на податоци и кои технологии се достапни за ова.

Три компоненти на безбедноста на DBMS: заштита на конекцијата, ревизија на активности и заштита на податоци

Обезбедување на вашите врски

Можете да се поврзете со базата на податоци директно или индиректно преку веб-апликации. По правило, деловниот корисник, односно лицето кое работи со DBMS, индиректно комуницира со него.

Пред да зборувате за заштита на врските, треба да одговорите на важни прашања кои одредуваат како ќе бидат структурирани безбедносните мерки:

• Дали еден деловен корисник е еквивалентен на еден корисник на DBMS?
• дали пристапот до податоците на DBMS е обезбеден само преку API што вие го контролирате или дали до табелите се пристапува директно;
• дали DBMS е доделен на посебен заштитен сегмент, кој и како комуницира со него;
• дали се користат здружени/прокси и средни слоеви, што може да ги промени информациите за тоа како е изградена врската и кој ја користи базата на податоци.

Сега да видиме кои алатки може да се користат за да се обезбедат врски:

1. Користете решенија за класа за заштитен ѕид на базата на податоци. Дополнителен слој на заштита, во најмала рака, ќе ја зголеми транспарентноста на она што се случува во DBMS, а максимално ќе можете да обезбедите дополнителна заштита на податоците.
2. Користете политики за лозинка. Нивната употреба зависи од тоа како е изградена вашата архитектура. Во секој случај, една лозинка во конфигурациската датотека на веб апликација која се поврзува со DBMS не е доволна за заштита. Постојат голем број на алатки за DBMS кои ви дозволуваат да контролирате дали корисникот и лозинката бараат ажурирање.

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

3. Збогатете го контекстот на сесијата со потребните информации. Ако сесијата е непроѕирна, не разбирате кој работи во DBMS во нејзините рамки, можете, во рамките на операцијата што се изведува, да додадете информации за тоа кој што прави и зошто. Оваа информација може да се види во ревизијата.
4. Конфигурирајте SSL ако немате мрежна поделба помеѓу DBMS и крајните корисници; тој не е во посебен VLAN. Во такви случаи, императив е да се заштити каналот помеѓу потрошувачот и самиот DBMS. Безбедносните алатки се исто така достапни во отворен код.

Како ова ќе влијае на перформансите на DBMS?

Ајде да го погледнеме примерот на 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 ms
187.695 ms

tps вклучувајќи воспоставување врски
58.168112
53.278062

tps со исклучок на воспоставување врски
64.084546
58.725846

Процесорот
24%
28%

Сите трансакции се вршат во една врска

просек на латентност
6.722 ms
6.342 ms

tps вклучувајќи воспоставување врски
1587.657278
1576.792883

tps со исклучок на воспоставување врски
1588.380574
1577.694766

Процесорот
17%
21%

При мали оптоварувања, влијанието на SSL е споредливо со грешката во мерењето. Ако количината на пренесените податоци е многу голема, ситуацијата може да биде поинаква. Ако воспоставиме една врска по трансакција (ова е ретко, обично врската се споделува помеѓу корисниците), имате голем број на врски/исклучувања, влијанието може да биде малку поголемо. Односно, може да има ризици од намалени перформанси, но разликата не е толку голема за да не се користи заштита.

Имајте предвид дека постои голема разлика ако ги споредите режимите на работа: работите во иста сесија или на различни. Ова е разбирливо: ресурсите се трошат за создавање на секоја врска.

Имавме случај кога го поврзавме Zabbix во trust mode, односно md5 не беше проверен, немаше потреба од автентикација. Потоа клиентот побара да го овозможи режимот за автентикација md5. Ова стави големо оптоварување на процесорот и перформансите паднаа. Почнавме да бараме начини за оптимизирање. Едно од можните решенија за проблемот е да се имплементираат мрежни ограничувања, да се направат посебни VLAN за DBMS, да се додадат поставки за да се разјасни кој од каде се поврзува и да се отстрани автентикацијата. општо, употребата на различни методи за автентикација влијае на перформансите и бара да се земат предвид овие фактори при дизајнирање на компјутерската моќ на серверите (хардверот) за DBMS.

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

Акциска ревизија

Ревизијата може да биде не само DBMS. Ревизијата е за добивање информации за тоа што се случува во различни сегменти. Ова може да биде или заштитен ѕид на базата на податоци или оперативен систем на кој е изграден DBMS.

Во комерцијалните DBMS на ниво на претпријатија сè е во ред со ревизијата, но во отворен код - не секогаш. Еве што има PostgreSQL:

• стандардно најавување - вградено најавување;
• екстензии: pgaudit - ако стандардното евидентирање не е доволно за вас, можете да користите посебни поставки кои решаваат некои проблеми.

Дополнување на извештајот во видеото:

„Основното евидентирање на искази може да биде обезбедено од стандарден објект за евидентирање со log_statement = сите.

Ова е прифатливо за мониторинг и други намени, но не го обезбедува нивото на детали што обично се потребни за ревизија.

Не е доволно да се има листа на сите операции извршени во базата на податоци.

Исто така, треба да биде можно да се најдат конкретни изјави кои се од интерес за ревизорот.

Стандардно логирање покажува што бара корисникот, додека pgAudit се фокусира на деталите за тоа што се случило кога базата на податоци го извршила барањето.

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

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

DO$$
ПОЧНЕТЕ
ИЗВРШЕТЕ „КРЕИРАЈ ТАБЕЛА увоз“ || 'ant_table (id int)';
КРАЈ $$;

Стандардна логирање ќе ви го даде ова:

LOG: изјава: НАПРАВИ $$
ПОЧНЕТЕ
ИЗВРШЕТЕ „КРЕИРАЈ ТАБЕЛА увоз“ || 'ant_table (id int)';
КРАЈ $$;

Се чини дека наоѓањето на табела од интерес може да бара одредено знаење за кодот во случаи кога табелите се креираат динамички.

Ова не е идеално, бидејќи би било подобро едноставно да се пребарува по име на табелата.

Ова е местото каде што pgAudit ни доаѓа.

За истиот влез, ќе го произведе овој излез во дневникот:

РЕВИЗИЈА: СЕСИЈА,33,1,ФУНКЦИЈА,ПРАВИ,,,"ПРАВИ $$
ПОЧНЕТЕ
ИЗВРШЕТЕ „КРЕИРАЈ ТАБЕЛА увоз“ || '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 може да се конфигурира да евидентира посебен запис за секоја врска наведена во изјавата.

Не е потребно парсирање за да се најдат сите искази што допираат одредена табела(*) ».

Како ова ќе влијае на перформансите на DBMS?

Ајде да извршиме тестови со овозможена целосна ревизија и да видиме што ќе се случи со перформансите на PostgreSQL. Ајде да овозможиме максимално евидентирање на базата на податоци за сите параметри.

Не менуваме речиси ништо во конфигурациската датотека, најважно е да го вклучите режимот debug5 за да добиете максимални информации.

postgresql.conf

log_destination = 'stderr'
logging_collector = вклучено
log_truncate_on_rotation = вклучено
log_rotation_age = 1d
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 DBMS со параметри од 1 процесор, 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

Крајна линија: целосната ревизија не е многу добра. Податоците од ревизијата ќе бидат големи колку податоците во самата база на податоци, па дури и повеќе. Количината на логирање што се генерира при работа со DBMS е чест проблем во производството.

Ајде да погледнеме во други параметри:

• Брзината не се менува многу: без логирање - 43,74 секунди, со логирање - 53,23 секунди.
• Перформансите на RAM и процесорот ќе страдаат, бидејќи треба да генерирате ревизорска датотека. Ова е забележливо и во продуктивноста.

Како што се зголемува бројот на врски, нормално, перформансите малку ќе се влошат.

Во корпорациите со ревизија е уште потешко:

• има многу податоци;
• ревизијата е потребна не само преку syslog во SIEM, туку и во датотеки: ако нешто се случи со syslog, мора да има датотека блиску до базата на податоци во која се зачувуваат податоците;
• Потребна е посебна полица за ревизија за да не се трошат I/O дисковите, бидејќи зазема многу простор;
• Се случува на вработените во информациската безбедност да им требаат стандарди ГОСТ насекаде, тие бараат државна идентификација.

Ограничување на пристапот до податоци

Да ги погледнеме технологиите што се користат за заштита на податоците и пристап до нив во комерцијални DBMS и со отворен код.

Што генерално можете да користите:

1. Шифрирање и замаглување на процедури и функции (Wrapping) - односно, одделни алатки и алатки што го прават читливиот код нечитлив. Точно, тогаш тоа не може ниту да се промени ниту да се рефакторира назад. Овој пристап понекогаш е потребен барем на страната на DBMS - логиката на ограничувањата на лиценцата или логиката на авторизација е шифрирана токму на ниво на процедура и функција.
2. Ограничувањето на видливоста на податоците по редови (RLS) е кога различни корисници гледаат една табела, но различен состав на редови во неа, односно нешто не може да се прикаже некому на ниво на ред.
3. Уредувањето на прикажаните податоци (маскирање) е кога корисниците во една колона од табелата гледаат или податоци или само ѕвездички, односно за некои корисници информациите ќе бидат затворени. Технологијата одредува на кој корисник што му се прикажува врз основа на нивото на пристап.
4. Безбедност DBA/Application Контролата на пристап DBA/DBA е, напротив, за ограничување на пристапот до самиот DBMS, односно, вработените во безбедноста на информациите можат да се одвојат од администраторите на базата на податоци и администраторите на апликациите. Има неколку такви технологии во отворен код, но ги има многу во комерцијалните DBMS. Тие се потребни кога има многу корисници со пристап до самите сервери.
5. Ограничување на пристапот до датотеки на ниво на датотечен систем. Можете да давате права и привилегии за пристап до директориумите, така што секој администратор има пристап само до потребните податоци.
6. Задолжителен пристап и чистење на меморијата - овие технологии ретко се користат.
7. Шифрирањето од крај до крај директно од DBMS е шифрирање од страна на клиентот со управување со клучеви на страната на серверот.
8. Шифрирање на податоци. На пример, колонообразно шифрирање е кога користите механизам кој шифрира една колона од базата на податоци.

Како ова влијае на перформансите на DBMS?

Да го погледнеме примерот на колонообразно шифрирање во PostgreSQL. Постои pgcrypto модул, тој ви овозможува да ги зачувате избраните полиња во шифрирана форма. Ова е корисно кога само некои податоци се вредни. За да ги прочита шифрираните полиња, клиентот пренесува клуч за дешифрирање, серверот ги дешифрира податоците и ги враќа на клиентот. Без клучот, никој не може да направи ништо со вашите податоци.

Ајде да тестираме со pgcrypto. Ајде да создадеме табела со шифрирани податоци и редовни податоци. Подолу се наредбите за креирање табели, во првата линија има корисна команда - креирање на самата екстензија со регистрација на DBMS:

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%

Енкрипцијата има големо влијание врз перформансите. Може да се види дека времето е зголемено, бидејќи операциите за дешифрирање на шифрирани податоци (а дешифрирањето обично сè уште е обвиткано во вашата логика) бараат значителни ресурси. Односно, идејата за шифрирање на сите колони што содржат некои податоци е полн со намалување на перформансите.

Сепак, шифрирањето не е сребрена куршума што ги решава сите проблеми. Дешифрираните податоци и клучот за дешифрирање за време на процесот на дешифрирање и пренос на податоците се наоѓаат на серверот. Затоа, клучевите може да бидат пресретнати од некој кој има целосен пристап до серверот на базата на податоци, како што е системскиот администратор.

Кога има едно копче за целата колона за сите корисници (дури и ако не за сите, туку за клиенти од ограничен сет), тоа не е секогаш добро и точно. Затоа почнаа да прават шифрирање од крај до крај, во DBMS почнаа да разгледуваат опции за шифрирање податоци на страната на клиентот и серверот, а се појавија истите тие складишта во сводот на клучеви - посебни производи кои обезбедуваат управување со клучеви на DBMS страна.

Пример за такво шифрирање во MongoDB

Безбедносни карактеристики во комерцијални и DBMS со отворен код

Функции
Тип
Политика за лозинка
Ревизија
Заштита на изворниот код на процедури и функции
RLS
Енкрипција

Oracle
комерцијална
+
+
+
+
+

MsSql
комерцијална
+
+
+
+
+

Јатоба
комерцијална
+
+
+
+
екстензии

PostgreSQL
слободен
екстензии
екстензии
-
+
екстензии

МонгоДб
слободен
-
+
-
-
Достапно само во MongoDB Enterprise

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

Што да направите ако никаде го немате она што ви треба? На пример, сакате да користите специфичен DBMS што ги нема функциите што ги бара клиентот.

Потоа можете да користите решенија од трети страни кои работат со различни DBMS, на пример, Crypto DB или Garda DB. Ако зборуваме за решенија од домашниот сегмент, тогаш тие знаат за ГОСТ подобро отколку во отворен код.

Втората опција е сами да напишете што ви треба, да имплементирате пристап до податоци и шифрирање во апликацијата на ниво на процедура. Точно, ќе биде потешко со ГОСТ. Но, генерално, можете да ги скриете податоците по потреба, да ги ставите во DBMS, потоа да ги вратите и да ги дешифрирате по потреба, токму на ниво на апликација. Во исто време, веднаш размислете како ќе ги заштитите овие алгоритми во апликацијата. Според нас, ова треба да се направи на ниво на DBMS, бидејќи ќе работи побрзо.

Овој извештај првпат беше претставен на @Databases Meetup од Mail.ru Cloud Solutions. Погледнете видео други изведби и претплатете се на најавите за настани на Telegram Околу Kubernetes во Mail.ru Group.

Што друго да се прочита на темата:

1. Повеќе од Ceph: складирање на блокови во облак MCS.
2. Како да изберете база на податоци за проект за да не треба повторно да избирате.

Извор: www.habr.com