Менің атым Денис Рожков, мен Газинформсервис компаниясында бағдарламалық жасақтаманы әзірлеу бөлімінің бастығымын, өнім тобында . Заңнама және корпоративтік ережелер деректерді сақтау қауіпсіздігіне белгілі бір талаптарды қояды. Ешкім үшінші тұлғалардың құпия ақпаратқа қол жеткізуін қаламайды, сондықтан кез келген жоба үшін келесі мәселелер маңызды: сәйкестендіру және аутентификация, деректерге қол жеткізуді басқару, жүйедегі ақпараттың тұтастығын қамтамасыз ету, қауіпсіздік оқиғаларын тіркеу. Сондықтан мен ДҚБ қауіпсіздігіне қатысты кейбір қызықты жайттар туралы айтқым келеді.
Мақала баяндамасы негізінде дайындалды ұйымдастырылған . Оқығыңыз келмесе, мынаны көре аласыз:
Мақала үш бөлімнен тұрады:
- Қосылымдарды қалай қорғауға болады.
- Әрекеттердің аудиті дегеніміз не және дерекқор жағында не болып жатқанын қалай жазу және оған қосылу.
- Дерекқордағы деректерді қалай қорғауға болады және бұл үшін қандай технологиялар бар.
ДҚБЖ қауіпсіздігінің үш құрамдас бөлігі: қосылымды қорғау, әрекетті тексеру және деректерді қорғау
Байланыстарыңызды қорғау
Дерекқорға тікелей немесе жанама түрде веб-қосымшалар арқылы қосылуға болады. Әдетте, бизнес пайдаланушы, яғни ДҚБЖ-мен жұмыс істейтін адам онымен жанама түрде әрекеттеседі.
Қосылымдарды қорғау туралы айтпас бұрын, қауіпсіздік шаралары қалай құрылымдалатынын анықтайтын маңызды сұрақтарға жауап беру керек:
- Бір іскери пайдаланушы бір ДҚБЖ пайдаланушысына баламалы ма?
- ДҚБЖ деректеріне қол жеткізу тек сіз басқаратын API арқылы қамтамасыз етілетінін немесе кестелерге тікелей қатынасу мүмкіндігін;
- ДҚБЖ жеке қорғалатын сегментке бөлінген бе, онымен кім және қалай әрекеттеседі;
- қосылымның қалай құрылғаны және дерекқорды кім пайдаланатыны туралы ақпаратты өзгерте алатын біріктіру/прокси және аралық қабаттардың пайдаланылғаны ма.
Енді қосылымдарды қорғау үшін қандай құралдарды қолдануға болатынын көрейік:
- Дерекқор брандмауэр класының шешімдерін пайдаланыңыз. Қосымша қорғаныс қабаты, кем дегенде, ДҚБЖ-да болып жатқан оқиғалардың ашықтығын арттырады, ал максимумда сіз қосымша деректерді қорғауды қамтамасыз ете аласыз.
- Құпия сөз саясаттарын пайдаланыңыз. Оларды пайдалану архитектураңыздың қалай салынғанына байланысты. Кез келген жағдайда, ДҚБЖ-ға қосылатын веб-бағдарламаның конфигурация файлындағы бір құпия сөз қорғау үшін жеткіліксіз. Пайдаланушы мен құпия сөздің жаңартуды қажет ететінін басқаруға мүмкіндік беретін бірқатар ДҚБЖ құралдары бар.
Пайдаланушы бағалау функциялары туралы толығырақ оқуға болады , сонымен қатар MS SQL осалдығын бағалаушылар туралы білуге болады .
- Сеанстың контекстін қажетті ақпаратпен байытыңыз. Сеанс мөлдір емес болса, оның шеңберінде ДҚБЖ-да кім жұмыс істеп жатқанын түсінбесеңіз, орындалып жатқан операция шеңберінде кім не істеп жатқаны және не үшін екені туралы ақпаратты қосуға болады. Бұл ақпаратты аудитте көруге болады.
- ДҚБЖ мен соңғы пайдаланушылар арасында желілік бөліну болмаса, SSL конфигурациялаңыз; ол бөлек VLAN желісінде емес. Мұндай жағдайларда тұтынушы мен ДҚБЖ өзі арасындағы арнаны қорғау міндетті болып табылады. Қауіпсіздік құралдары ашық көзде де қол жетімді.
Бұл ДҚБЖ өнімділігіне қалай әсер етеді?
SSL процессордың жүктемесіне қалай әсер ететінін, уақытты көбейтетінін және TPS-ті азайтатынын және оны қоссаңыз, тым көп ресурстарды тұтынатынын білу үшін PostgreSQL мысалын қарастырайық.
pgbench арқылы PostgreSQL жүктеу - өнімділік сынақтарын орындауға арналған қарапайым бағдарлама. Ол пәрмендердің бір тізбегін қайталап, мүмкін параллельді дерекқор сеанстарында орындайды, содан кейін транзакцияның орташа жылдамдығын есептейді.
SSL жоқ және SSL арқылы 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"SSL жоқ және SSL арқылы 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Тест нәтижелері:
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 = барлығы бар стандартты тіркеу құралы қамтамасыз ете алады.
Бұл мониторинг және басқа пайдалану үшін қолайлы, бірақ әдетте аудит үшін қажетті егжей-тегжейлі деңгейді қамтамасыз етпейді.
Деректер базасында орындалатын барлық операциялардың тізімі болуы жеткіліксіз.
Сондай-ақ аудиторды қызықтыратын нақты мәлімдемелерді табу мүмкіндігі болуы керек.
Стандартты журнал жүргізу пайдаланушының сұрағанын көрсетеді, ал pgAudit дерекқор сұрауды орындаған кезде не болғанының мәліметтеріне назар аударады.
Мысалы, аудитор нақты кестенің құжатталған техникалық қызмет көрсету терезесінде жасалғанын тексергісі келуі мүмкін.
Бұл негізгі аудит пен grep арқылы қарапайым тапсырма сияқты көрінуі мүмкін, бірақ сізге осындай (әдейі шатастыратын) мысал ұсынылса ше?
DO$$
BEGIN
'CREATE TABLE import' || ОРЫНДАУ 'ant_table(id int)';
END$$;
Стандартты журнал сізге мынаны береді:
LOG: мәлімдеме: DO $$
BEGIN
'CREATE TABLE import' || ОРЫНДАУ 'ant_table(id int)';
END$$;
Қызықтыратын кестені табу үшін кестелер динамикалық түрде жасалған жағдайларда кейбір код білімі қажет болуы мүмкін.
Бұл өте қолайлы емес, өйткені жай ғана кесте атауы бойынша іздеген жөн.
Бұл жерде pgAudit пайдалы болады.
Дәл сол енгізу үшін ол журналда осы нәтижені шығарады:
АУДИТ: СЕССИЯ,33,1,ФУНКЦИЯ,ЖАСАУ,,,"ЖАСАУ $$
BEGIN
'CREATE TABLE import' || ОРЫНДАУ 'ant_table(id int)';
END$$;"
АУДИТ: СЕССИЯ,33,2,DDL,КЕСТЕ ЖАСАУ,КЕСТЕ,public.important_table,КЕСТЕНІ ЖАСАУ маңызды_кесте (ID INT)
Тек DO блогы ғана емес, сонымен қатар оператор түрі, нысан түрі және толық аты бар CREATE TABLE толық мәтіні тіркеледі, бұл іздеуді жеңілдетеді.
SELECT және DML мәлімдемелерін тіркеу кезінде pgAudit мәлімдемеде сілтеме жасалған әрбір қатынас үшін бөлек жазбаны тіркеуге теңшелуі мүмкін.
Белгілі бір кестеге тиетін барлық мәлімдемелерді табу үшін талдау қажет емес(). «
Бұл ДҚБЖ өнімділігіне қалай әсер етеді?
Толық тексеру қосылған сынақтарды іске қосып, PostgreSQL өнімділігімен не болатынын көрейік. Барлық параметрлер үшін ең көп дерекқор журналын қосуға рұқсат етіңіз.
Біз конфигурация файлында ештеңені өзгертпейміз, ең бастысы - максималды ақпаратты алу үшін debug5 режимін қосу.
postgresql.conf
log_destination = 'stderr'
logging_collector = қосулы
log_truncate_on_rotation = қосулы
журнал_айналу_жас = 1күн
журнал_айналдыру_өлшемі = 10 МБ
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_hostname = қосулы
log_lock_wait = қосулы
log_replication_commands = қосулы
log_temp_files = 0
log_timezone = 'Еуропа/Мәскеу'
1 процессор, 2,8 ГГц, 2 ГБ жедел жады, 40 ГБ HDD параметрлері бар PostgreSQL ДҚБЖ-да біз пәрмендерді пайдаланып үш жүктеме сынамасын жүргіземіз:
$ 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 сек
ЖЖҚ
24%
40%
Орталық Есептеуіш Бөлім
72%
91%
Сынақ 1 (50 қосылым)
10 минуттағы транзакциялар саны
74169
32445
Транзакциялар/сек
123
54
Орташа кідіріс
405 мс
925 мс
Сынақ 2 (150 мүмкін болатын 100 қосылым)
10 минуттағы транзакциялар саны
81727
31429
Транзакциялар/сек
136
52
Орташа кідіріс
550 мс
1432 мс
Өлшемдері туралы
ДҚ өлшемі
2251 МБ
2262 МБ
Деректер қоры журналының өлшемі
0 Мб
4587 Мб
Қорытынды: толық аудит өте жақсы емес. Аудит деректері дерекқордағы деректер сияқты үлкен немесе одан да көп болады. ДҚБЖ-мен жұмыс істеу кезінде жасалатын тіркеу көлемі өндірісте жиі кездесетін мәселе болып табылады.
Басқа параметрлерді қарастырайық:
- Жылдамдық көп өзгермейді: тіркеусіз – 43,74 секунд, журналға түсіру кезінде – 53,23 секунд.
- ЖЖҚ және процессордың өнімділігі төмендейді, өйткені сізге аудит файлын жасау қажет. Бұл өнімділікте де байқалады.
Қосылымдар саны артқан сайын, әрине, өнімділік аздап нашарлайды.
Аудиті бар корпорацияларда бұл қиынырақ:
- деректер көп;
- аудит тек SIEM жүйесінде syslog арқылы ғана емес, сонымен қатар файлдарда да қажет: егер syslog бірдеңе болса, деректер сақталатын дерекқорға жақын файл болуы керек;
- енгізу/шығару дискілерін ысырап етпеу үшін аудит үшін бөлек сөре қажет, өйткені ол көп орын алады;
- Ақпараттық қауіпсіздік қызметкерлеріне барлық жерде ГОСТ стандарттары қажет, олар мемлекеттік сәйкестендіруді талап етеді.
Деректерге қол жеткізуді шектеу
Деректерді қорғау және оларға коммерциялық ДҚБЖ және ашық көзде қол жеткізу үшін қолданылатын технологияларды қарастырайық.
Жалпы нені қолдануға болады:
- Процедуралар мен функцияларды шифрлау және жасыру (Wrapping) – яғни оқылатын кодты оқылмайтын ететін бөлек құралдар мен утилиталар. Рас, оны өзгертуге де, қайта өңдеуге де болмайды. Бұл тәсіл кейде ДҚБЖ жағында қажет болады – лицензиялық шектеулер логикасы немесе авторизация логикасы процедура мен функция деңгейінде дәл шифрланады.
- Деректердің жолдар бойынша көрінуін шектеу (RLS) - бұл әртүрлі пайдаланушылар бір кестені, бірақ ондағы жолдардың басқа құрамын көргенде, яғни жол деңгейінде біреуге бір нәрсені көрсету мүмкін емес.
- Көрсетілген деректерді өңдеу (маскировка) кестенің бір бағанындағы пайдаланушылар деректерді немесе тек жұлдызшаларды көргенде, яғни кейбір пайдаланушылар үшін ақпарат жабылады. Технология қай пайдаланушыға қол жеткізу деңгейіне қарай не көрсетілетінін анықтайды.
- Қауіпсіздік DBA/Application DBA/DBA қатынасын басқару, керісінше, ДҚБЖ өзіне қол жеткізуді шектеуге қатысты, яғни ақпараттық қауіпсіздік қызметкерлерін дерекқор әкімшілерінен және қолданба әкімшілерінен бөлуге болады. Ашық бастапқы кодта мұндай технологиялар аз, бірақ коммерциялық ДҚБЖ-да олар көп. Олар серверлерге қол жеткізе алатын көптеген пайдаланушылар болған кезде қажет.
- Файлдық жүйе деңгейінде файлдарға қол жеткізуді шектеу. Әрбір әкімшінің тек қажетті деректерге қол жеткізуі үшін каталогтарға құқықтар мен кіру артықшылықтарын бере аласыз.
- Міндетті қол жеткізу және жадты тазарту - бұл технологиялар сирек қолданылады.
- Тікелей ДҚБЖ-дан түпкілікті шифрлау сервер жағында кілттерді басқарумен клиенттік шифрлау болып табылады.
- Деректерді шифрлау. Мысалы, бағаналық шифрлау дерекқордың бір бағанын шифрлайтын механизмді пайдаланған кезде.
Бұл ДҚБЖ өнімділігіне қалай әсер етеді?
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 мс
Шифрлау функциясы бар кестеден таңдау:
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 мс
Тест нәтижелері:
Шифрлаусыз
Pgcrypto (шифрын шешу)
1000 жол үлгісі
1,386 мс
50,203 мс
Орталық Есептеуіш Бөлім
15%
35%
ЖЖҚ
+ 5%
Шифрлау өнімділікке үлкен әсер етеді. Шифрланған деректердің шифрын шешу операциялары (және шифрды шешу әдетте сіздің логикаңызға оралады) айтарлықтай ресурстарды қажет ететіндіктен, уақыттың ұлғайғанын көруге болады. Яғни, кейбір деректері бар барлық бағандарды шифрлау идеясы өнімділіктің төмендеуіне әкеледі.
Дегенмен, шифрлау барлық мәселелерді шешетін күміс оқ емес. Шифрдан шығарылған деректер мен шифрды шешу және деректерді беру процесі кезіндегі кілт серверде орналасады. Сондықтан кілттерді жүйелік әкімші сияқты дерекқор серверіне толық рұқсаты бар адам ұстай алады.
Барлық пайдаланушылар үшін бүкіл баған үшін бір кілт болған кезде (тіпті барлығы үшін болмаса да, шектеулі жиынның клиенттері үшін), бұл әрқашан жақсы және дұрыс бола бермейді. Сондықтан олар түпкілікті шифрлауды бастады, ДҚБЖ-да олар клиент пен сервер жағындағы деректерді шифрлау нұсқаларын қарастыра бастады, сол сияқты кілттік қоймалар пайда болды - ДҚБЖ-да кілттерді басқаруды қамтамасыз ететін бөлек өнімдер. жағы.
Коммерциялық және ашық бастапқы ДҚБЖ қауіпсіздік мүмкіндіктері
Функциялар
Түрі
Құпиясөз саясаты
тексеру
Процедуралар мен функциялардың бастапқы кодын қорғау
RLS
шифрлау
Oracle
коммерциялық
+
+
+
+
+
MsSql
коммерциялық
+
+
+
+
+
коммерциялық
+
+
+
+
кеңейтімдер
PostgreSQL
Тегін
кеңейтімдер
кеңейтімдер
-
+
кеңейтімдер
MongoDb
Тегін
-
+
-
-
Тек MongoDB Enterprise жүйесінде қол жетімді
Кесте толық емес, бірақ жағдай былай: коммерциялық өнімдерде қауіпсіздік мәселелері ұзақ уақыт бойы шешілген, ашық көзде, әдетте, қауіпсіздік үшін кейбір қосымшалар қолданылады, көптеген функциялар жоқ. , кейде бірдеңе қосуға тура келеді. Мысалы, құпия сөз саясаты - PostgreSQL көптеген әртүрлі кеңейтімдерге ие (, , , , ), құпия сөз саясатын жүзеге асыратын, бірақ, менің ойымша, олардың ешқайсысы отандық корпоративтік сегменттің барлық қажеттіліктерін қамтымайды.
Қажетті нәрсе еш жерде болмаса не істеу керек? Мысалы, тұтынушы талап ететін функциялары жоқ нақты ДҚБЖ пайдаланғыңыз келеді.
Содан кейін әртүрлі ДҚБЖ-мен жұмыс істейтін үшінші тарап шешімдерін пайдалана аласыз, мысалы, Crypto DB немесе Garda DB. Егер біз отандық сегменттің шешімдері туралы айтатын болсақ, онда олар ГОСТ туралы ашық көзге қарағанда жақсы біледі.
Екінші нұсқа - өзіңізге қажет нәрсені жазу, процедура деңгейінде қолданбада деректерге қол жеткізуді және шифрлауды жүзеге асыру. Рас, ГОСТ-пен қиынырақ болады. Бірақ жалпы алғанда, деректерді қажетінше жасыруға, оны ДҚБЖ-ға қоюға, содан кейін оны қалпына келтіруге және қажетінше қолданба деңгейінде шифрын ашуға болады. Сонымен қатар, қолданбада осы алгоритмдерді қалай қорғайтыныңызды дереу ойластырыңыз. Біздің ойымызша, мұны ДҚБЖ деңгейінде жасау керек, себебі ол жылдамырақ жұмыс істейді.
Бұл баяндама алғаш рет осында ұсынылды Mail.ru Cloud Solutions. Қараңызбасқа қойылымдар және Telegram-да оқиғалар туралы хабарландыруларға жазылу .
Тақырып бойынша тағы не оқу керек:
- .
- .
Ақпарат көзі: www.habr.com