Менин атым Денис Рожков, мен Газинформсервис компаниясында программалык камсыздоону иштеп чыгуу бөлүмүнүн жетекчисимин, продукт командасынын . Мыйзамдар жана корпоративдик ченемдер маалыматтарды сактоонун коопсуздугуна белгилүү бир талаптарды коёт. Эч ким үчүнчү жактардын купуя маалыматка жетүүсүн каалабайт, ошондуктан ар кандай долбоор үчүн төмөнкү маселелер маанилүү: идентификация жана аутентификация, маалыматтарга кирүү мүмкүнчүлүгүн башкаруу, системадагы маалыматтын бүтүндүгүн камсыздоо, коопсуздук окуяларын каттоо. Ошондуктан, мен DBMS коопсуздугуна байланыштуу кээ бир кызыктуу жагдайлар жөнүндө айткым келет.
макаласында сүйлөгөн сөзүнүн негизинде даярдалды уюштурулган . Окууну каалабасаңыз, көрө аласыз:
Макала үч бөлүктөн турат:
- Байланыштарды кантип коргоо керек.
- Иш-аракеттердин аудити деген эмне жана маалымат базасында эмне болуп жатканын кантип жазуу керек жана ага туташуу.
- Маалымат базасындагы маалыматтарды кантип коргоо керек жана бул үчүн кандай технологиялар бар.
DBMS коопсуздугунун үч компоненти: байланышты коргоо, активдүүлүктү текшерүү жана маалыматтарды коргоо
Сиздин байланыштарды камсыз кылуу
Сиз веб-тиркемелер аркылуу түз же кыйыр түрдө маалымат базасына туташа аласыз. Эреже катары, бизнес-колдонуучу, башкача айтканда, ДББЖ менен иштеген адам аны менен кыйыр түрдө өз ара аракеттенет.
Байланыштарды коргоо жөнүндө сөз кылуудан мурун, коопсуздук чаралары кандай түзүлөөрүн аныктаган маанилүү суроолорго жооп беришиңиз керек:
- Бир бизнес колдонуучу бир DBMS колдонуучуга барабарбы?
- DBMS маалыматтарына кирүү сиз көзөмөлдөгөн API аркылуу гана берилеби же таблицаларга түздөн-түз киреби;
- МББ өзүнчө корголгон сегментке бөлүнгөнбү, аны менен ким жана кантип иштешет;
- бириктирүү/прокси жана ортоңку катмарлар колдонулабы, алар туташуунун кантип курулгандыгы жана маалымат базасын ким колдонуп жаткандыгы тууралуу маалыматты өзгөртө алат.
Эми байланыштарды коргоо үчүн кандай куралдар колдонула тургандыгын карап көрөлү:
- Берилиштер базасынын брандмауэр классынын чечимдерин колдонуңуз. Кошумча коргоо катмары, жок дегенде, МББда болуп жаткан нерселердин ачыктыгын жогорулатат, ал эми максималдуу түрдө сиз кошумча маалыматтарды коргоону камсыздай аласыз.
- Сырсөз саясаттарын колдонуңуз. Аларды колдонуу архитектураңыз кандайча курулганына жараша болот. Кандай болгон күндө да, МБЖга туташкан веб-тиркемесинин конфигурация файлындагы бир сырсөз коргоо үчүн жетишсиз. Колдонуучунун жана сырсөздүн жаңыртылышын талап кылганын көзөмөлдөөгө мүмкүндүк берген бир катар DBMS куралдары бар.
Колдонуучунун рейтинги функциялары жөнүндө көбүрөөк окуй аласыз , ошондой эле MS SQL аялуулугун баалоочулар жөнүндө биле аласыз .
- Сессиянын контекстн зарыл информация менен байытуу. Сеанс бүдөмүк болсо, анда анын алкагында МББда ким иштеп жатканын түшүнбөй жатсаңыз, сиз аткарылып жаткан операциянын алкагында ким эмне кылып жатканы жана эмне үчүн маалымат кошо аласыз. Бул маалыматты аудиттен көрүүгө болот.
- Эгерде сизде DBMS менен акыркы колдонуучулардын ортосунда тармак бөлүнбөсө, SSLди конфигурациялаңыз; ал өзүнчө VLANда эмес. Мындай учурларда, керектөөчү менен СББнын ортосундагы каналды коргоо зарыл. Коопсуздук куралдары ачык булакта да бар.
Бул DBMSтин иштешине кандай таасир этет?
Келгиле, PostgreSQL мисалын карап көрөлү, SSL CPU жүгүнө кандай таасир этет, убакытты көбөйтөт жана TPSти азайтат жана аны иштетсеңиз, ал өтө көп ресурстарды керектейби же жокпу.
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
CPU
24%
28%
Бардык транзакциялар бир байланышта жүзөгө ашырылат
орточо күтүү
6.722 мс
6.342 мс
tps, анын ичинде байланыштарды түзүү
1587.657278
1576.792883
байланыштарды кошпогондо tps
1588.380574
1577.694766
CPU
17%
21%
Жеңил жүктөмдө SSL таасири өлчөө катасы менен салыштырууга болот. Эгерде берилүүчү маалыматтардын көлөмү өтө чоң болсо, абал башкача болушу мүмкүн. Эгер транзакцияга бир байланыш түзсөк (бул сейрек кездешет, адатта байланыш колдонуучулардын ортосунда бөлүштүрүлөт), сизде көп сандагы байланыштар/ажыратуулар бар, таасири бир аз көбүрөөк болушу мүмкүн. Башкача айтканда, өндүрүмдүүлүктү төмөндөтүү коркунучу болушу мүмкүн, бирок айырма коргоону колдонбогондой чоң эмес.
Иштөө режимдерин салыштырсаңыз, катуу айырма бар экенин эске алыңыз: сиз бир эле сессиянын ичинде же ар башка иштеп жатасыз. Бул түшүнүктүү: ресурстар ар бир байланышты түзүүгө жумшалат.
Бизде Zabbixти ишеним режиминде туташтырган учур болгон, башкача айтканда, md5 текшерилген эмес, аутентификациянын кереги жок болчу. Андан кийин кардар md5 аутентификация режимин иштетүүнү суранды. Бул процессорго оор жүк салып, өндүрүмдүүлүк төмөндөп кетти. Биз оптималдаштыруу жолдорун издей баштадык. Көйгөйдүн мүмкүн болгон чечимдеринин бири - тармактык чектөөлөрдү ишке ашыруу, DBMS үчүн өзүнчө VLAN түзүү, ким кайдан туташып жатканын ачыктоо үчүн орнотууларды кошуу жана аутентификацияны алып салуу.Ошондой эле аутентификацияны иштетүүдө чыгымдарды азайтуу үчүн аутентификация орнотууларын оптималдаштырсаңыз болот, бирок жалпысынан аутентификациянын ар кандай ыкмаларын колдонуу өндүрүмдүүлүккө таасирин тийгизет жана МБС үчүн серверлердин (аппараттык каражаттардын) эсептөө күчүн долбоорлоодо ушул факторлорду эске алууну талап кылат.
Корутунду: бир катар чечимдерде, аутентификациядагы кичинекей нюанстар да долбоорго чоң таасир этиши мүмкүн жана бул өндүрүштө ишке ашырылганда гана ачыкка чыкканда жаман болот.
Аракет аудити
Аудит DBMS гана эмес болушу мүмкүн. Аудит ар кандай сегменттерде болуп жаткан нерселер жөнүндө маалымат алуу болуп саналат. Бул маалымат базасынын брандмауэри же DBMS курулган операциялык система болушу мүмкүн.
Коммерциялык ишкана деңгээлиндеги DBMSтерде аудитте баары жакшы, бирок ачык булакта - дайыма эмес. PostgreSQLде эмне бар:
- демейки журнал - камтылган журнал;
- кеңейтүүлөр: pgaudit - демейки журналга жазуу сиз үчүн жетишсиз болсо, кээ бир көйгөйлөрдү чечүүчү өзүнчө орнотууларды колдонсоңуз болот.
Видеодогу отчетко кошумча:
"Негизги билдирүү журналы log_statement = баардыгы менен стандарттык каттоо каражаты тарабынан берилиши мүмкүн.
Бул мониторинг жана башка колдонуу үчүн алгылыктуу, бирок аудит үчүн талап кылынган деталдардын деңгээлин камсыз кылбайт.
Маалымат базасында аткарылган бардык операциялардын тизмеси жетишсиз.
Ошондой эле аудиторду кызыктырган конкреттүү билдирүүлөрдү табуу мүмкүн болушу керек.
Стандарттык журнал колдонуучу эмне сураганын көрсөтөт, ал эми pgAudit маалымат базасы суроону аткарганда эмне болгондугунун чоо-жайына көңүл бурат.
Мисалы, аудитор документтештирилген тейлөө терезесинин ичинде белгилүү бир таблица түзүлгөнүн текшерүүнү каалашы мүмкүн.
Бул негизги аудит жана grep менен жөнөкөй тапшырмадай сезилиши мүмкүн, бирок сизге ушул сыяктуу (атайылап чаташтырган) мисал сунушталсачы?
DO$$
БАШТАЛАТ
АТКАРУУ 'CREATE TABLE import' || 'ant_table(id int)';
END$$;
Стандарттык жазуу сизге төмөнкүлөрдү берет:
LOG: билдирүү: DO $$
БАШТАЛАТ
АТКАРУУ 'CREATE TABLE import' || 'ant_table(id int)';
END$$;
Кызыккан таблицаны табуу таблицалар динамикалык түрдө түзүлгөн учурларда кээ бир код билимин талап кылышы мүмкүн.
Бул идеалдуу эмес, анткени таблицанын аты боюнча жөн гана издөө артык.
Бул жерде pgAudit жардам берет.
Ошол эле киргизүү үчүн, ал журналда бул чыгарылышты чыгарат:
АУДИТ: СЕССИЯ,33,1,ФУНКЦИЯ,ЖАСА,,,"ЖАСА $$
БАШТАЛАТ
АТКАРУУ 'CREATE TABLE import' || 'ant_table(id int)';
END$$;"
АУДИТ: СЕССИЯ,33,2,DDL, ТАБЛИЦАНЫ ТҮЗҮҮ, ТАБЛИЦИ, public.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 = 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 = 'Европа/Москва'
1 CPU, 2,8 ГГц, 2 ГБ оперативдүү эс тутум, 40 ГБ HDD параметрлери менен PostgreSQL DBMSде биз буйруктарды колдонуу менен үч жүктөм сыноо өткөрөбүз:
$ 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%
CPU
72%
91%
Сыноо 1 (50 туташуу)
10 мүнөт ичинде транзакциялардын саны
74169
32445
Транзакциялар/сек
123
54
Орточо кечигүү
405 мс
925 мс
Сыноо 2 (150 туташуу менен 100 мүмкүн)
10 мүнөт ичинде транзакциялардын саны
81727
31429
Транзакциялар/сек
136
52
Орточо кечигүү
550 мс
1432 мс
Өлчөмдөрү жөнүндө
DB өлчөмү
2251 MB
2262 MB
Маалыматтар базасынын журналынын өлчөмү
0 MB
4587 MB
Жыйынтык: толук аудит абдан жакшы эмес. Аудиттин маалыматтары базадагы маалыматтардай чоң, же андан да көп болот. DBMS менен иштөөдө түзүлгөн журналдын көлөмү өндүрүштө кеңири таралган көйгөй болуп саналат.
Башка параметрлерди карап көрөлү:
- Ылдамдык анча деле өзгөрбөйт: журналсыз – 43,74 секунд, каротажда – 53,23 секунд.
- RAM жана CPU иштеши начарлайт, анткени сиз аудит файлын түзүшүңүз керек. Бул өндүрүмдүүлүктө да байкалат.
Байланыштардын саны көбөйгөн сайын, албетте, аткаруу бир аз начарлайт.
Аудити бар корпорацияларда бул андан да кыйын:
- көп маалыматтар бар;
- аудит SIEMдеги syslog аркылуу гана эмес, файлдарда да керек: эгер syslog менен бир нерсе болуп кетсе, анда маалыматтар сакталган маалымат базасына жакын файл болушу керек;
- текшерүү үчүн, киргизүү/чыгаруу дисктерин ысырап кылбоо үчүн өзүнчө текче керек, анткени ал көп орунду ээлейт;
- Маалыматтык коопсуздук кызматкерлери бардык жерде ГОСТ стандарттарына муктаж болуп калат, алар мамлекеттик идентификацияны талап кылат.
Маалыматтарга кирүү мүмкүнчүлүгүн чектөө
Келгиле, маалыматтарды коргоо жана аларга коммерциялык DBMS жана ачык булакта жетүү үчүн колдонулган технологияларды карап көрөлү.
Жалпысынан эмнени колдоно аласыз:
- Процедураларды жана функцияларды шифрлөө жана бүдөмүктөө (Wrapping) - башкача айтканда, окула турган кодду окулбай турган өзүнчө инструменттер жана утилиталар. Ырас, анда аны өзгөртүүгө да, кайра калыбына келтирүүгө да болбойт. Кээде мындай мамиле жок дегенде СДБС тарабында талап кылынат - лицензиялык чектөөлөрдүн логикасы же авторизациялоо логикасы процедура жана функция деңгээлинде так шифрленген.
- Саптар боюнча берилиштердин көрүнүмдүүлүгүн чектөө (RLS) - бул ар кандай колдонуучулар бир таблицаны көргөндө, бирок андагы саптардын башка курамын, башкача айтканда, сап деңгээлинде кимдир бирөөгө бир нерсени көрсөтүү мүмкүн эмес.
- Көрсөтүлгөн маалыматтарды түзөтүү (маскалоо) таблицанын бир тилкесинде колдонуучулар же маалыматтарды же жылдызчаларды гана көрүшөт, башкача айтканда, кээ бир колдонуучулар үчүн маалымат жабылат. Технология кайсы колдонуучуга кирүү деңгээлине жараша эмне көрсөтүлөрүн аныктайт.
- Коопсуздук DBA/Application DBA/DBA мүмкүндүктү башкаруу, тескерисинче, СУБДга кирүүнү чектөө жөнүндө, башкача айтканда, маалыматтык коопсуздук кызматкерлерин маалымат базасынын администраторлорунан жана колдонмолордун администраторлорунан ажыратууга болот. Ачык булакта мындай технологиялар аз, бирок коммерциялык DBMSтерде алар көп. Алар серверлерге кирүү мүмкүнчүлүгү бар көптөгөн колдонуучулар болгондо керек.
- Файл системасынын деңгээлинде файлдарга кирүү мүмкүнчүлүгүн чектөө. Ар бир администратор керектүү маалыматтарга гана кирүү мүмкүнчүлүгүнө ээ болушу үчүн каталогдорго укуктарды жана кирүү артыкчылыктарын бере аласыз.
- Милдеттүү кирүү жана эстутум тазалоо - бул технологиялар сейрек колдонулат.
- Түздөн-түз МБЖдан акырына чейин шифрлөө сервер тарабында ачкычтарды башкаруу менен кардар тарабынан шифрлөө болуп саналат.
- Маалыматтарды шифрлөө. Мисалы, мамычалык шифрлөө маалымат базасынын бир тилкесин шифрлөөчү механизмди колдонгонуңузда.
Бул 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 | text1 | текст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 мс
CPU
15%
35%
ОЗУ
+ 5%
Шифрлөө аткарууга чоң таасирин тийгизет. Убакыт көбөйгөнүн көрүүгө болот, анткени шифрленген маалыматтарды чечмелөө операциялары (жана чечмелөө адатта сиздин логикаңызда сакталат) олуттуу ресурстарды талап кылат. Башкача айтканда, кээ бир маалыматтарды камтыган бардык мамычаларды шифрлөө идеясы өндүрүмдүүлүктүн төмөндөшүнө алып келет.
Бирок, шифрлөө бардык маселелерди чече турган күмүш ок эмес. Шифрленген маалыматтар жана шифрди чечмелөө жана маалыматтарды берүү процессинде чечмелөө ачкычы серверде жайгашкан. Ошондуктан, ачкычтарды маалымат базасынын серверине толук мүмкүнчүлүгү бар адам, мисалы, система администратору кармап алат.
Бардык колдонуучулар үчүн бүт мамыча үчүн бир ачкыч болгондо (баары үчүн эмес, бирок чектелген топтомдун кардарлары үчүн), бул дайыма эле жакшы жана туура боло бербейт. Мына ошондуктан алар аягына чейин шифрлөөнү жүргүзө башташты, СДБда алар кардар жана сервер тарабында маалыматтарды шифрлөөнүн варианттарын карап башташты жана ошол эле ачкыч сактагычтары пайда болду - СББда ачкычты башкарууну камсыз кылган өзүнчө өнүмдөр тарап.
Коммерциялык жана ачык булактагы DBMSдеги коопсуздук өзгөчөлүктөрү
милдеттери
түрү
Сырсөз саясаты
текшерүү
Процедуранын жана функциялардын баштапкы кодун коргоо
RLS
коддоо
Oracle
соода
+
+
+
+
+
MsSql
соода
+
+
+
+
+
соода
+
+
+
+
узартууну
PostgreSQL
бекер
узартууну
узартууну
-
+
узартууну
MongoDb
бекер
-
+
-
-
MongoDB Enterprise'де гана жеткиликтүү
Таблица толук эмес, бирок абал мындай: коммерциялык продуктыларда коопсуздук көйгөйлөрү көптөн бери чечилген, ачык булакта, эреже катары, коопсуздук үчүн кандайдыр бир кошумчалар колдонулат, көптөгөн функциялар жок. , кээде бир нерсе кошууга туура келет. Мисалы, сырсөз саясаттары - PostgreSQL ар кандай кеңейтүүлөргө ээ (, , , , ), сырсөз саясатын ишке ашырган, бирок, менин оюмча, алардын бири да ата мекендик корпоративдик сегменттин бардык керектөөлөрүн камтыбайт.
Эч жерде сизге керектүү нерсе жок болсо, эмне кылуу керек? Мисалы, сиз кардар талап кылган функцияларга ээ эмес, белгилүү бир DBMS колдонгуңуз келет.
Андан кийин, сиз, мисалы, Crypto DB же Garda DB, ар кандай DBMS менен иштеген үчүнчү тараптын чечимдерин колдоно аласыз. Эгерде биз ата мекендик сегменттин чечимдери жөнүндө сөз кыла турган болсок, анда алар ГОСТ жөнүндө ачык булакка караганда жакшыраак билишет.
Экинчи вариант - бул өзүңүзгө керектүү нерсени жазуу, процедура деңгээлинде тиркемеде маалыматтарга жетүү жана шифрлөөнү ишке ашыруу. Ырас, ГОСТ менен кыйыныраак болот. Бирок, жалпысынан, сиз керектүү маалыматты жашыра аласыз, аны DBMSке салып, андан кийин аны кайра алып чыгып, керектүү учурда, тиркеме деңгээлинде чечмелей аласыз. Ошол эле учурда, бул алгоритмдерди тиркемеде кантип коргой турганыңызды дароо ойлонуңуз. Биздин оюбузча, бул МБД деңгээлинде жасалышы керек, анткени ал тезирээк иштейт.
Бул отчет биринчи жолу берилген Mail.ru Cloud Solutions тарабынан. Карабашка спектаклдер жана Telegramдагы иш-чара кулактандырууларына жазылуу .
Тема боюнча дагы эмнени окуу керек:
- .
- .
Source: www.habr.com