Зовем се Денис Рожков, ја сам шеф развоја софтвера у компанији Газинформсервице, у тиму производа . Законодавство и корпоративни прописи намећу одређене захтеве за безбедност чувања података. Нико не жели да трећа лица добију приступ поверљивим информацијама, тако да су следећа питања важна за сваки пројекат: идентификација и аутентификација, управљање приступом подацима, обезбеђење интегритета информација у систему, евидентирање безбедносних догађаја. Стога желим да говорим о неким занимљивим тачкама у вези са сигурношћу ДБМС-а.
Чланак је припремљен на основу говора на организовано . Ако не желите да читате, можете погледати:
Чланак ће имати три дела:
- Како обезбедити везе.
- Шта је ревизија радњи и како снимити шта се дешава на страни базе података и повезивање са њом.
- Како заштитити податке у самој бази података и које технологије су за то доступне.
Три компоненте безбедности ДБМС-а: заштита везе, ревизија активности и заштита података
Осигуравање ваших веза
Можете се повезати са базом података директно или индиректно преко веб апликација. По правилу, пословни корисник, односно особа која ради са ДБМС-ом, комуницира са њим индиректно.
Пре него што причате о заштити веза, морате да одговорите на важна питања која одређују како ће безбедносне мере бити структурисане:
- Да ли је један пословни корисник еквивалентан једном кориснику ДБМС-а?
- да ли се приступ ДБМС подацима обезбеђује само преко АПИ-ја који контролишете или се табелама приступа директно;
- да ли је ДБМС додељен посебном заштићеном сегменту, ко са њим комуницира и како;
- да ли се користе обједињавање/прокси и међуслојеви, што може променити информације о томе како је веза изграђена и ко користи базу података.
Сада да видимо који алати се могу користити за обезбеђивање веза:
- Користите решења класе заштитног зида базе података. Додатни слој заштите ће, у најмању руку, повећати транспарентност онога што се дешава у ДБМС-у, а максимално ћете моћи да обезбедите додатну заштиту података.
- Користите смернице за лозинку. Њихова употреба зависи од тога како је изграђена ваша архитектура. У сваком случају, једна лозинка у конфигурационој датотеци веб апликације која се повезује на ДБМС није довољна за заштиту. Постоји велики број ДБМС алата који вам омогућавају да контролишете да ли корисник и лозинка захтевају ажурирање.
Можете прочитати више о функцијама оцењивања корисника , такође можете сазнати о МС СКЛ процењивачу рањивости .
- Обогатите контекст сесије потребним информацијама. Ако је сесија непрозирна, не разумете ко ради у ДБМС-у у њеним оквирима, можете, у оквиру операције која се изводи, додати информације о томе ко шта ради и зашто. Ове информације се могу видети у ревизији.
- Конфигуришите ССЛ ако немате мрежно раздвајање између ДБМС-а и крајњих корисника; није у засебном ВЛАН-у. У таквим случајевима, неопходно је заштитити канал између потрошача и самог ДБМС-а. Безбедносни алати су такође доступни у отвореном коду.
Како ће то утицати на перформансе ДБМС-а?
Хајде да погледамо пример ПостгреСКЛ-а да видимо како ССЛ утиче на оптерећење ЦПУ-а, повећава тајминг и смањује ТПС, и да ли ће трошити превише ресурса ако га омогућите.
Учитавање ПостгреСКЛ-а помоћу пгбенцх-а је једноставан програм за покретање тестова перформанси. Извршава једну секвенцу команди више пута, могуће у паралелним сесијама базе података, а затим израчунава просечну брзину трансакције.
Тест 1 без ССЛ-а и коришћењем ССЛ-а — веза се успоставља за сваку трансакцију:
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 без ССЛ-а и коришћењем ССЛ-а — све трансакције се обављају у једној вези:
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Резултати теста:
НО ССЛ
ССЛ
Веза се успоставља за сваку трансакцију
просек кашњења
КСНУМКС МС
КСНУМКС МС
тпс укључујући успостављање веза
58.168112
53.278062
тпс искључујући успостављање веза
64.084546
58.725846
Процесор
100%
100%
Све трансакције се обављају у једној вези
просек кашњења
КСНУМКС МС
КСНУМКС МС
тпс укључујући успостављање веза
1587.657278
1576.792883
тпс искључујући успостављање веза
1588.380574
1577.694766
Процесор
100%
100%
При малим оптерећењима, утицај ССЛ је упоредив са грешком мерења. Ако је количина пренетих података веома велика, ситуација може бити другачија. Ако успоставимо једну везу по трансакцији (ово је реткост, обично се веза дели између корисника), имате велики број конекција/прекидања, утицај може бити мало већи. То јест, могу постојати ризици од смањења перформанси, међутим, разлика није толико велика да се не користи заштита.
Имајте на уму да постоји велика разлика ако упоредите режиме рада: радите у истој сесији или у различитим. Ово је разумљиво: ресурси се троше на стварање сваке везе.
Имали смо случај када смо Заббик повезали у режиму поверења, односно мд5 није проверен, није било потребе за аутентификацијом. Затим је купац затражио да омогући режим мд5 аутентификације. Ово је довело до великог оптерећења ЦПУ-а, а перформансе су пале. Почели смо да тражимо начине за оптимизацију. Једно од могућих решења проблема је имплементација мрежних ограничења, прављење засебних ВЛАН-ова за ДБМС, додавање подешавања да би било јасно ко се одакле повезује и уклањање аутентификације. Такође можете оптимизовати подешавања аутентификације како бисте смањили трошкове приликом омогућавања аутентификације, али генерално, употреба различитих метода аутентификације утиче на перформансе и захтева узимање ових фактора у обзир приликом пројектовања рачунарске снаге сервера (хардвера) за ДБМС.
Закључак: у бројним решењима чак и мале нијансе у аутентификацији могу у великој мери да утичу на пројекат и лоше је када то постане јасно тек када се имплементира у продукцији.
Акциона ревизија
Ревизија може бити не само ДБМС. Ревизија се односи на добијање информација о томе шта се дешава у различитим сегментима. Ово може бити или заштитни зид базе података или оперативни систем на којем је изграђен ДБМС.
У комерцијалним ДБМС-овима на нивоу предузећа све је у реду са ревизијом, али у отвореном коду - не увек. Ево шта ПостгреСКЛ има:
- подразумевани дневник - уграђено евидентирање;
- екстензије: пгаудит - ако подразумевано евидентирање није довољно за вас, можете користити одвојена подешавања која решавају неке проблеме.
Додатак извештају у видеу:
„Основно евидентирање исказа може бити обезбеђено помоћу стандардног уређаја за евидентирање са лог_статемент = алл.
Ово је прихватљиво за праћење и друге употребе, али не пружа ниво детаља који је типично потребан за ревизију.
Није довољно имати списак свих операција извршених на бази података.
Такође би требало да буде могуће пронаћи специфичне изјаве које су од интереса за ревизора.
Стандардно евидентирање показује шта је корисник тражио, док се пгАудит фокусира на детаље онога што се догодило када је база података извршила упит.
На пример, ревизор може желети да провери да ли је одређена табела креирана унутар документованог периода одржавања.
Ово може изгледати као једноставан задатак са основном ревизијом и греп-ом, али шта ако вам се прикаже нешто попут овог (намерно збуњујућег) примера:
ДО$$
БЕГИН
ИЗВРШИТЕ 'КРЕИРАЈТЕ увоз ТАБЛЕ' || 'ант_табле(ид инт)';
ЕНД$$;
Стандардно евидентирање ће вам дати ово:
ЛОГ: изјава: ДО $$
БЕГИН
ИЗВРШИТЕ 'КРЕИРАЈТЕ увоз ТАБЛЕ' || 'ант_табле(ид инт)';
ЕНД$$;
Чини се да проналажење табеле од интереса може захтевати извесно познавање кода у случајевима када се табеле креирају динамички.
Ово није идеално, јер би било пожељно једноставно претраживати по имену табеле.
Овде пгАудит добро долази.
За исти улаз, произвешће овај излаз у дневнику:
РЕВИЗИЈА: СЕСИЈА,33,1,ФУНКЦИЈА,УРАДИТИ,,,"УРАДИТИ $$
БЕГИН
ИЗВРШИТЕ 'КРЕИРАЈТЕ увоз ТАБЛЕ' || 'ант_табле(ид инт)';
ЕНД$$;"
РЕВИЗИЈА: СЕССИОН,33,2,ДДЛ,КРЕИРАЈ ТАБЕЛУ,ТАБЕЛУ,публиц.импортант_табле,ЦРЕАТЕ ТАБЛЕ импортант_табле (ид ИНТ)
Не само да се блок ДО евидентира, већ и цео текст ЦРЕАТЕ ТАБЛЕ са типом исказа, типом објекта и пуним именом, што олакшава претрагу.
Приликом евидентирања СЕЛЕЦТ и ДМЛ исказа, пгАудит се може конфигурисати да евидентира посебан унос за сваки однос наведен у исказу.
Није потребно рашчлањивање да би се пронашли сви искази који додирују одређену табелу () ».
Како ће то утицати на перформансе ДБМС-а?
Хајде да покренемо тестове са омогућеном потпуном ревизијом и видимо шта се дешава са перформансама ПостгреСКЛ-а. Омогућимо максимално евидентирање базе података за све параметре.
Не мењамо скоро ништа у конфигурационој датотеци, најважније је да укључите режим дебуг5 да бисте добили максималне информације.
постгрескл.цонф
лог_дестинатион = 'стдерр'
логгинг_цоллецтор = укључено
лог_трунцате_он_ротатион = укључено
лог_ротатион_аге = 1д
лог_ротатион_сизе = 10МБ
лог_мин_мессагес = дебуг5
лог_мин_еррор_статемент = дебуг5
лог_мин_дуратион_статемент = 0
дебуг_принт_парсе = укључено
дебуг_принт_ревриттен = укључено
дебуг_принт_план = укључено
дебуг_претти_принт = укључено
лог_цхецкпоинтс = укључено
лог_цоннецтионс = укључено
лог_дисцоннецтионс = укључено
лог_дуратион = укључено
лог_хостнаме = укључено
лог_лоцк_ваит = укључено
лог_реплицатион_цоммандс = укључено
лог_темп_филес = 0
лог_тимезоне = 'Европа/Москва'
На ПостгреСКЛ ДБМС са параметрима од 1 ЦПУ, 2,8 ГХз, 2 ГБ РАМ, 40 ГБ ХДД, спроводимо три теста оптерећења помоћу команди:
$ 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Резултати теста:
Нема евидентирања
Са сечом
Укупно време попуњавања базе података
КСНУМКС сек
КСНУМКС сек
Рам
100%
100%
Процесор
100%
100%
Тест 1 (50 веза)
Број трансакција за 10 минута
74169
32445
Трансакције/сек
123
54
Просечно кашњење
КСНУМКС мс
КСНУМКС мс
Тест 2 (150 веза са 100 могућих)
Број трансакција за 10 минута
81727
31429
Трансакције/сек
136
52
Просечно кашњење
КСНУМКС мс
КСНУМКС мс
О величинама
ДБ сизе
КСНУМКС МБ
КСНУМКС МБ
Величина дневника базе података
КСНУМКС МБ
КСНУМКС МБ
Закључак: пуна ревизија није баш добра. Подаци из ревизије биће велики колико и подаци у самој бази података, или чак и више. Количина евидентирања која се генерише при раду са ДБМС-ом је уобичајен проблем у производњи.
Погледајмо друге параметре:
- Брзина се не мења много: без евидентирања - 43,74 секунди, са евидентирањем - 53,23 секунде.
- Перформансе РАМ-а и ЦПУ-а ће патити, јер морате да генеришете датотеку ревизије. То је приметно и у продуктивности.
Како се број веза повећава, наравно, перформансе ће се благо погоршати.
У корпорацијама са ревизијом је још теже:
- има много података;
- ревизија је потребна не само преко сислог-а у СИЕМ-у, већ иу датотекама: ако се нешто деси са сислог-ом, мора постојати датотека близу базе података у којој се подаци чувају;
- посебна полица је потребна за ревизију како се не би трошили И/О дискови, јер заузима пуно простора;
- Дешава се да запосленима за безбедност информација свуда требају ГОСТ стандарди, захтевају државну идентификацију.
Ограничавање приступа подацима
Хајде да погледамо технологије које се користе за заштиту података и приступ њима у комерцијалним ДБМС-овима и отвореном коду.
Шта генерално можете да користите:
- Шифровање и замагљивање процедура и функција (Враппинг) – то јест, одвојени алати и услужни програми који чине читљиви код нечитљивим. Истина, тада се не може ни мењати ни рефакторисати назад. Овај приступ је понекад потребан барем на страни ДБМС-а – логика ограничења лиценце или логика ауторизације је шифрована прецизно на нивоу процедуре и функције.
- Ограничавање видљивости података по редовима (РЛС) је када различити корисници виде једну табелу, али у њој различит састав редова, односно не може се некоме нешто показати на нивоу реда.
- Уређивање приказаних података (Маскирање) је када корисници у једној колони табеле виде или податке или само звездице, односно за неке кориснике информације ће бити затворене. Технологија одређује ком кориснику се шта приказује на основу њиховог нивоа приступа.
- Безбедносна ДБА/Апликација ДБА/ДБА контрола приступа се ради о ограничавању приступа самом ДБМС-у, односно запослени у безбедности информација могу бити одвојени од администратора база података и администратора апликација. Мало је таквих технологија у отвореном коду, али их има доста у комерцијалним ДБМС-овима. Потребни су када има много корисника са приступом самим серверима.
- Ограничавање приступа датотекама на нивоу система датотека. Можете доделити права и привилегије приступа директоријумима тако да сваки администратор има приступ само неопходним подацима.
- Обавезни приступ и чишћење меморије - ове технологије се ретко користе.
- Енкрипција од краја до краја директно из ДБМС-а је шифровање на страни клијента са управљањем кључевима на страни сервера.
- Шифровање података. На пример, колонско шифровање је када користите механизам који шифрује једну колону базе података.
Како то утиче на перформансе ДБМС-а?
Погледајмо пример колонарског шифровања у ПостгреСКЛ-у. Постоји пгцрипто модул, који вам омогућава да чувате изабрана поља у шифрованом облику. Ово је корисно када су само неки подаци вредни. Да би прочитао шифрована поља, клијент преноси кључ за дешифровање, сервер дешифрује податке и враћа их клијенту. Без кључа нико не може ништа да уради са вашим подацима.
Хајде да тестирамо са пгцрипто. Хајде да направимо табелу са шифрованим подацима и редовним подацима. Испод су команде за креирање табела, у првом реду налази се корисна команда - креирање самог екстензије са ДБМС регистрацијом:
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Штоперица је укључена.
ид | тект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 мс
Избор из табеле са функцијом шифровања:
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Штоперица је укључена.
ид | дешифровати | дешифровати
——+—————+————
1 | к31 | к31
2 | к32 | к32
3 | к33 | к33
...
999 | к393939 | к393939
1000 | к31303030 | к31303030
(1000 редова)
Време: 50,203 мс
Резултати теста:
Без енкрипције
Пгцрипто (дешифровање)
Узорак 1000 редова
КСНУМКС мс
КСНУМКС мс
Процесор
100%
100%
Рам
+ КСНУМКС%
Шифровање има велики утицај на перформансе. Може се видети да се тајминг повећао, пошто операције дешифровања шифрованих података (а дешифровање је обично још увек умотано у вашу логику) захтевају значајне ресурсе. То јест, идеја о шифровању свих колона које садрже неке податке је препуна смањења перформанси.
Међутим, шифровање није сребрни метак који решава све проблеме. Дешифровани подаци и кључ за дешифровање током процеса дешифровања и преноса података налазе се на серверу. Стога кључеве може пресрести неко ко има пун приступ серверу базе података, као што је администратор система.
Када постоји један кључ за целу колону за све кориснике (чак и ако не за све, али за клијенте ограниченог скупа), то није увек добро и исправно. Због тога су почели да раде енд-то-енд енкрипцију, у ДБМС-у су почели да разматрају опције за шифровање података на страни клијента и сервера, а појавила су се иста та кључна складишта - одвојени производи који обезбеђују управљање кључевима на ДБМС-у. страна.
Сигурносне функције у комерцијалним и отвореним ДБМС-има
Функције
Тип
Политика лозинке
Ревизија
Заштита изворног кода процедура и функција
РЛС
Шифровање
пророчанство
комерцијални
+
+
+
+
+
МсСкл
комерцијални
+
+
+
+
+
комерцијални
+
+
+
+
Ектенсионс
ПостгреСКЛ
бесплатно
Ектенсионс
Ектенсионс
-
+
Ектенсионс
МонгоДб
бесплатно
-
+
-
-
Доступно само у МонгоДБ Ентерприсе
Табела је далеко од потпуне, али ситуација је следећа: у комерцијалним производима безбедносни проблеми су већ дуго решени, у отвореном коду се по правилу користе неки додаци за безбедност, недостају многе функције , понекад морате нешто да додате. На пример, политике лозинки - ПостгреСКЛ има много различитих екстензија (, , , , ), који имплементирају политику лозинки, али, по мом мишљењу, ниједна од њих не покрива све потребе домаћег корпоративног сегмента.
Шта да радите ако нигде немате оно што вам треба? На пример, желите да користите одређени ДБМС који нема функције које клијент захтева.
Затим можете користити решења независних произвођача која раде са различитим ДБМС-овима, на пример, Црипто ДБ или Гарда ДБ. Ако говоримо о решењима из домаћег сегмента, онда они знају за ГОСТ-ове боље него у отвореном коду.
Друга опција је да сами напишете оно што вам треба, имплементирате приступ подацима и шифровање у апликацији на нивоу процедуре. Истина, са ГОСТ-ом ће бити теже. Али генерално, можете сакрити податке по потреби, ставити их у ДБМС, затим их преузети и дешифровати по потреби, директно на нивоу апликације. Истовремено, одмах размислите како ћете заштитити ове алгоритме у апликацији. По нашем мишљењу, то би требало урадити на нивоу ДБМС, јер ће то брже радити.
Овај извештај је први пут представљен на би Маил.ру Цлоуд Солутионс. Погледајостале представе и претплатите се на најаве догађаја на Телеграму .
Шта још читати на тему:
- .
- .
Извор: ввв.хабр.цом