Mening ismim Denis Rojkov, men Gazinformservis kompaniyasida dasturiy ta'minotni ishlab chiqish bo'limi boshlig'i, mahsulot jamoasida Jatoba. Qonunchilik va korporativ me'yoriy hujjatlar ma'lumotlarni saqlash xavfsizligi uchun muayyan talablarni belgilaydi. Hech kim uchinchi shaxslarning maxfiy ma'lumotlarga kirishini xohlamaydi, shuning uchun har qanday loyiha uchun quyidagi masalalar muhim ahamiyatga ega: identifikatsiya va autentifikatsiya, ma'lumotlarga kirishni boshqarish, tizimdagi ma'lumotlarning yaxlitligini ta'minlash, xavfsizlik hodisalarini qayd qilish. Shuning uchun, men DBMS xavfsizligi bilan bog'liq ba'zi qiziqarli fikrlar haqida gapirmoqchiman.

Maqola nutqi asosida tayyorlangan @DatabasesMeetup, tashkil etilgan Mail.ru bulutli echimlar. Agar o'qishni xohlamasangiz, tomosha qilishingiz mumkin:

Maqola uch qismdan iborat bo'ladi:

• Ulanishlarni qanday himoya qilish kerak.
• Harakatlarning auditi nima va ma'lumotlar bazasi tomonida nima sodir bo'layotganini qanday qayd etish va unga ulanish.
• Ma'lumotlar bazasidagi ma'lumotlarni qanday himoya qilish kerak va buning uchun qanday texnologiyalar mavjud.

DBMS xavfsizligining uchta komponenti: ulanishni himoya qilish, faoliyatni tekshirish va ma'lumotlarni himoya qilish

Ulanishlaringizni himoya qilish

Ma'lumotlar bazasiga bevosita yoki bilvosita veb-ilovalar orqali ulanishingiz mumkin. Qoidaga ko'ra, biznes foydalanuvchisi, ya'ni DBMS bilan ishlaydigan shaxs u bilan bilvosita o'zaro ta'sir qiladi.

Ulanishlarni himoya qilish haqida gapirishdan oldin, xavfsizlik choralari qanday tuzilishini aniqlaydigan muhim savollarga javob berishingiz kerak:

• Bitta biznes foydalanuvchisi bitta DBMS foydalanuvchisiga tengmi?
• ma'lumotlar bazasi ma'lumotlariga kirish faqat siz boshqaradigan API orqali taqdim etiladimi yoki jadvallarga to'g'ridan-to'g'ri kirish mumkinmi;
• DBMS alohida himoyalangan segmentga ajratilganmi, u bilan kim va qanday aloqada bo'ladi;
• ulanish qanday qurilganligi va ma'lumotlar bazasidan kim foydalanayotgani haqidagi ma'lumotlarni o'zgartirishi mumkin bo'lgan birlashma/proksi va oraliq qatlamlardan foydalaniladimi.

Keling, ulanishlarni himoya qilish uchun qanday vositalardan foydalanish mumkinligini ko'rib chiqaylik:

1. Ma'lumotlar bazasi xavfsizlik devori sinfi yechimlaridan foydalaning. Qo'shimcha himoya qatlami, hech bo'lmaganda, ma'lumotlar bazasida sodir bo'layotgan voqealarning shaffofligini oshiradi va maksimal darajada, siz qo'shimcha ma'lumotlarni himoya qilish imkoniyatiga ega bo'lasiz.
2. Parol siyosatidan foydalaning. Ulardan foydalanish sizning arxitekturangiz qanday qurilganiga bog'liq. Qanday bo'lmasin, ma'lumotlar bazasi bazasiga ulanadigan veb-ilovaning konfiguratsiya faylida bitta parol himoya qilish uchun etarli emas. Foydalanuvchi va parolni yangilashni talab qilishini nazorat qilish imkonini beruvchi bir qator DBMS vositalari mavjud.

   Siz foydalanuvchilarni baholash funktsiyalari haqida ko'proq o'qishingiz mumkin shu yerda, shuningdek, MS SQL zaifliklarni baholovchilar haqida ham bilib olishingiz mumkin shu yerda. 

3. Seans kontekstini kerakli ma'lumotlar bilan boyitish. Agar sessiya noaniq bo'lsa, siz uning doirasida DBMSda kim ishlayotganini tushunmaysiz, bajarilayotgan operatsiya doirasida kim nima va nima uchun qilayotgani haqida ma'lumot qo'shishingiz mumkin. Ushbu ma'lumotni tekshirishda ko'rish mumkin.
4. Agar sizda DBMS va oxirgi foydalanuvchilar o'rtasida tarmoq ajratilmagan bo'lsa, SSL-ni sozlang; u alohida VLAN-da emas. Bunday hollarda iste'molchi va DBMS o'rtasidagi kanalni himoya qilish juda muhimdir. Xavfsizlik vositalari ochiq manbada ham mavjud.

Bu DBMS ishlashiga qanday ta'sir qiladi?

Keling, PostgreSQL misolini ko'rib chiqaylik, SSL protsessor yukiga qanday ta'sir qiladi, vaqtni oshiradi va TPSni pasaytiradi va agar uni yoqsangiz, u juda ko'p resurslarni iste'mol qiladimi yoki yo'qmi.

Pgbench yordamida PostgreSQL-ni yuklash unumdorlik testlarini o'tkazish uchun oddiy dasturdir. U bitta buyruqlar ketma-ketligini takroran, ehtimol parallel ma'lumotlar bazasi seanslarida bajaradi va keyin o'rtacha tranzaksiya tezligini hisoblab chiqadi.

SSLsiz va SSL-dan foydalangan holda 1-test — har bir tranzaksiya uchun ulanish o‘rnatiladi:

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"

SSLsiz va SSL-dan foydalangan holda 2-test — barcha operatsiyalar bitta ulanishda amalga oshiriladi:

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"

Boshqa sozlamalar:

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

Sinov natijalari:

 
SSL YO'Q
SSL

Har bir tranzaksiya uchun ulanish o'rnatiladi

o'rtacha kechikish
171.915 mil
187.695 mil

tps, shu jumladan ulanishlarni o'rnatish
58.168112
53.278062

ulanishlarni o'rnatishdan tashqari tps
64.084546
58.725846

Markaziy protsessor
24%
28%

Barcha operatsiyalar bitta ulanishda amalga oshiriladi

o'rtacha kechikish
6.722 mil
6.342 mil

tps, shu jumladan ulanishlarni o'rnatish
1587.657278
1576.792883

ulanishlarni o'rnatishdan tashqari tps
1588.380574
1577.694766

Markaziy protsessor
17%
21%

Engil yuklarda SSL ta'sirini o'lchash xatosi bilan solishtirish mumkin. Agar uzatilgan ma'lumotlar miqdori juda katta bo'lsa, vaziyat boshqacha bo'lishi mumkin. Har bir tranzaksiya uchun bitta ulanish o'rnatadigan bo'lsak (bu kamdan-kam hollarda, odatda ulanish foydalanuvchilar o'rtasida taqsimlanadi), sizda juda ko'p ulanishlar/uzilishlar mavjud, ta'sir biroz kattaroq bo'lishi mumkin. Ya'ni, ishlashning pasayishi xavfi bo'lishi mumkin, ammo farq himoyadan foydalanmaslik uchun unchalik katta emas.

E'tibor bering, agar siz ish rejimlarini solishtirsangiz, kuchli farq bor: siz bir seansda yoki boshqasida ishlayapsiz. Bu tushunarli: resurslar har bir ulanishni yaratishga sarflanadi.

Bizda Zabbix-ni ishonchli rejimda ulaganimizda, ya'ni md5 tekshirilmagan, autentifikatsiya qilishning hojati yo'q edi. Keyin mijoz md5 autentifikatsiya rejimini yoqishni so'radi. Bu protsessorga katta yuk olib keldi va unumdorlik pasaydi. Biz optimallashtirish yo'llarini izlay boshladik. Muammoning mumkin bo'lgan yechimlaridan biri tarmoq cheklovlarini amalga oshirish, ma'lumotlar bazasi uchun alohida VLAN yaratish, kim qayerdan ulanayotganini aniqlash uchun sozlamalarni qo'shish va autentifikatsiyani olib tashlashdir.Shuningdek, autentifikatsiyani yoqish paytida xarajatlarni kamaytirish uchun autentifikatsiya sozlamalarini optimallashtirishingiz mumkin, ammo Umuman olganda, autentifikatsiyaning turli usullaridan foydalanish ishlashga ta'sir qiladi va ma'lumotlar bazasi uchun serverlarning (apparat) hisoblash quvvatini loyihalashda ushbu omillarni hisobga olishni talab qiladi.

Xulosa: bir qator echimlarda autentifikatsiyadagi kichik nuanslar ham loyihaga katta ta'sir ko'rsatishi mumkin va bu faqat ishlab chiqarishda amalga oshirilganda aniq bo'lganda yomon.

Harakat auditi

Audit nafaqat DBMS bo'lishi mumkin. Audit - bu turli segmentlarda sodir bo'layotgan voqealar haqida ma'lumot olish. Bu ma'lumotlar bazasi xavfsizlik devori yoki DBMS qurilgan operatsion tizim bo'lishi mumkin.

Tijorat korporativ darajadagi DBMSlarda audit bilan hamma narsa yaxshi, lekin ochiq manbada - har doim ham emas. PostgreSQL-da nima bor:

• standart jurnal - o'rnatilgan jurnal;
• kengaytmalar: pgaudit - agar standart ro'yxatga olish siz uchun etarli bo'lmasa, ba'zi muammolarni hal qiladigan alohida sozlamalardan foydalanishingiz mumkin.

Videodagi hisobotga qo'shimcha:

"Asosiy bayonot jurnali log_statement = hammasi bo'lgan standart ro'yxatga olish vositasi tomonidan ta'minlanishi mumkin.

Bu monitoring va boshqa maqsadlarda foydalanish uchun qabul qilinadi, lekin odatda audit uchun talab qilinadigan tafsilotlar darajasini ta'minlamaydi.

Ma'lumotlar bazasida bajariladigan barcha operatsiyalar ro'yxatiga ega bo'lish etarli emas.

Bundan tashqari, auditorni qiziqtiradigan aniq bayonotlarni topish mumkin bo'lishi kerak.

Standart ro'yxatga olish foydalanuvchi so'ragan narsani ko'rsatadi, pgAudit esa ma'lumotlar bazasi so'rovni bajarganida nima sodir bo'lganligi tafsilotlariga e'tibor qaratadi.

Masalan, auditor ma'lum bir jadval hujjatlashtirilgan texnik xizmat ko'rsatish oynasida yaratilganligini tekshirishni xohlashi mumkin.

Bu asosiy audit va grep bilan oddiy vazifaga o'xshab ko'rinishi mumkin, ammo agar sizga shunday (qasddan chalkash) misol taqdim etilsa nima bo'ladi:

DO$$
BOSHLASH
'JADVAL TUZISH import qilish' || 'ant_table(id int)';
END$$;

Standart jurnal sizga quyidagilarni beradi:

LOG: bayonot: DO $$
BOSHLASH
'JADVAL TUZISH import qilish' || 'ant_table(id int)';
END$$;

Ko'rinishidan, qiziqarli jadvalni topish uchun jadvallar dinamik ravishda yaratilgan hollarda ba'zi kod bilimlarini talab qilishi mumkin.

Bu ideal emas, chunki oddiygina jadval nomi bo'yicha qidirish afzalroqdir.

Bu erda pgAudit yordam beradi.

Xuddi shu kirish uchun u ushbu chiqishni jurnalda ishlab chiqaradi:

AUDIT: SESSIYA,33,1,FUNKSIYA,BAJARISh,,,"QILISH $$
BOSHLASH
'JADVAL TUZISH import qilish' || 'ant_table(id int)';
END$$;"
AUDIT: SESSION,33,2,DDL,JADVAL YARATISH,JADVAL,Public.important_table,JADVAL YARATING muhim_jadval (ID INT)

Nafaqat DO bloki, balki CREATE TABLE ning toʻliq matni bayon turi, obʼyekt turi va toʻliq nomi qayd qilinadi, bu esa qidiruvni osonlashtiradi.

SELECT va DML bayonotlarini ro'yxatdan o'tkazishda pgAudit bayonotda havola qilingan har bir munosabat uchun alohida yozuvni jurnalga kiritish uchun sozlanishi mumkin.

Muayyan jadvalga tegadigan barcha iboralarni topish uchun tahlil qilish shart emas(*) ».

Bu DBMS ishlashiga qanday ta'sir qiladi?

Keling, to'liq audit yoqilgan holda testlarni o'tkazamiz va PostgreSQL ishlashiga nima bo'lishini ko'ramiz. Keling, barcha parametrlar uchun maksimal ma'lumotlar bazasi jurnalini yoqaylik.

Biz konfiguratsiya faylida deyarli hech narsani o'zgartirmaymiz, eng muhimi, maksimal ma'lumot olish uchun debug5 rejimini yoqishdir.

postgresql.conf

log_destination = 'stderr'
logging_collector = yoqilgan
log_truncate_on_rotation = yoqilgan
log_aylanish_yoshi = 1 kun
log_rotation_size = 10MB
log_min_messages = disk raskadrovka 5
log_min_error_statement = disk raskadrovka 5
log_min_duration_statement = 0
debug_print_parse = yoqilgan
debug_print_rewritten = yoqilgan
debug_print_plan = yoqilgan
debug_pretty_print = yoqilgan
log_checkpoints = yoqilgan
log_connections = yoqilgan
log_disconnections = yoqilgan
log_duration = yoqilgan
log_hostname = yoqilgan
log_lock_wait = yoqilgan
log_replication_commands = yoqilgan
log_temp_files = 0
log_timezone = "Yevropa/Moskva"

1 protsessor, 2,8 gigagertsli chastota, 2 GB RAM, 40 GB HDD parametrlariga ega PostgreSQL ma'lumotlar bazasida biz buyruqlar yordamida uchta yuk sinovini o'tkazamiz:

$ 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

Sinov natijalari:

Ro‘yxatga olish yo‘q
Ro'yxatga olish bilan

Ma'lumotlar bazasini to'ldirishning umumiy vaqti
43,74 soniya
53,23 soniya

RAM
24%
40%

Markaziy protsessor
72%
91%

Sinov 1 (50 ta ulanish)

10 daqiqa ichida tranzaktsiyalar soni
74169
32445

Tranzaksiyalar/sek
123
54

O'rtacha kechikish
405 mil
925 mil

Sinov 2 (150 ta ulanish, 100 ta mumkin)

10 daqiqa ichida tranzaktsiyalar soni
81727
31429

Tranzaksiyalar/sek
136
52

O'rtacha kechikish
550 mil
1432 mil

O'lchamlar haqida

JB hajmi
2251 MB
2262 MB

Ma'lumotlar bazasi jurnalining o'lchami
0 MB
4587 MB

Xulosa: to'liq audit juda yaxshi emas. Auditdan olingan ma'lumotlar ma'lumotlar bazasidagi ma'lumotlar kabi yoki undan ham kattaroq bo'ladi. DBMS bilan ishlashda hosil bo'ladigan jurnallar miqdori ishlab chiqarishda keng tarqalgan muammo hisoblanadi.

Keling, boshqa parametrlarni ko'rib chiqaylik:

• Tezlik unchalik o'zgarmaydi: ro'yxatga olishsiz - 43,74 soniya, ro'yxatga olish bilan - 53,23 soniya.
• RAM va protsessor unumdorligi yomonlashadi, chunki siz audit faylini yaratishingiz kerak. Bu hosildorlikda ham seziladi.

Ulanishlar soni ortishi bilan, tabiiyki, ishlash biroz yomonlashadi.

Auditga ega korporatsiyalarda bu yanada qiyinroq:

• juda ko'p ma'lumotlar mavjud;
• audit faqat SIEMda syslog orqali emas, balki fayllarda ham zarur: agar syslog bilan biror narsa yuz bersa, ma'lumotlar saqlanadigan ma'lumotlar bazasiga yaqin fayl bo'lishi kerak;
• kirish/chiqarish disklarini isrof qilmaslik uchun audit uchun alohida javon kerak, chunki u juda ko'p joy egallaydi;
• Axborot xavfsizligi xodimlariga hamma joyda GOST standartlari kerak bo'ladi, ular davlat identifikatsiyasini talab qiladi.

Ma'lumotlarga kirishni cheklash

Keling, tijorat ma'lumotlar bazasi va ochiq manbalarda ma'lumotlarni himoya qilish va ularga kirish uchun ishlatiladigan texnologiyalarni ko'rib chiqaylik.

Odatda nimadan foydalanishingiz mumkin:

1. Protseduralar va funksiyalarni shifrlash va xiralashtirish (Wrapping) - ya'ni o'qilishi mumkin bo'lgan kodni o'qib bo'lmaydigan qilib qo'yadigan alohida vositalar va yordamchi dasturlar. To'g'ri, uni o'zgartirish ham, qayta tiklash ham mumkin emas. Bunday yondashuv ba'zan hech bo'lmaganda DBMS tomonida talab qilinadi - litsenziya cheklovlari yoki avtorizatsiya mantig'i protsedura va funktsiyalar darajasida aniq shifrlangan.
2. Satrlar bo'yicha ma'lumotlarning ko'rinishini cheklash (RLS) - bu turli foydalanuvchilar bitta jadvalni ko'rishlari, lekin undagi qatorlarning boshqa tarkibi, ya'ni biror narsani satr darajasida kimgadir ko'rsatish mumkin emas.
3. Ko'rsatilgan ma'lumotlarni tahrirlash (maskalash) - jadvalning bir ustunidagi foydalanuvchilar ma'lumotlarni yoki faqat yulduzchalarni ko'rishlari, ya'ni ba'zi foydalanuvchilar uchun ma'lumotlar yopiladi. Texnologiya qaysi foydalanuvchiga kirish darajasiga qarab nima ko'rsatilishini aniqlaydi.
4. Xavfsizlik DBA/Ilova DBA/DBA kirishni boshqarish, aksincha, ma'lumotlar bazasi ma'lumotlar bazasining o'ziga kirishni cheklash bilan bog'liq, ya'ni axborot xavfsizligi xodimlarini ma'lumotlar bazasi ma'murlari va ilovalar ma'murlaridan ajratish mumkin. Ochiq kodli manbalarda bunday texnologiyalar kam, ammo ular tijorat DBMSlarida juda ko'p. Ular serverlarga kirish huquqiga ega ko'plab foydalanuvchilar mavjud bo'lganda kerak bo'ladi.
5. Fayl tizimi darajasida fayllarga kirishni cheklash. Siz har bir administrator faqat kerakli ma'lumotlarga kirish huquqiga ega bo'lishi uchun kataloglarga huquqlar va kirish imtiyozlarini berishingiz mumkin.
6. Majburiy kirish va xotirani tozalash - bu texnologiyalar kamdan-kam qo'llaniladi.
7. To'g'ridan-to'g'ri DBMSdan uchigacha shifrlash - bu server tomonida kalitlarni boshqarish bilan mijoz tomonidan shifrlash.
8. Ma'lumotlarni shifrlash. Masalan, ustunli shifrlash ma'lumotlar bazasining bitta ustunini shifrlaydigan mexanizmdan foydalanganda.

Bu DBMS ishlashiga qanday ta'sir qiladi?

Keling, PostgreSQL-da ustunli shifrlash misolini ko'rib chiqaylik. Pgcrypto moduli mavjud bo'lib, u tanlangan maydonlarni shifrlangan shaklda saqlashga imkon beradi. Bu faqat ba'zi ma'lumotlar qimmatli bo'lsa foydali bo'ladi. Shifrlangan maydonlarni o'qish uchun mijoz shifrni ochish kalitini uzatadi, server ma'lumotlarni shifrlaydi va mijozga qaytaradi. Kalitsiz hech kim sizning ma'lumotlaringiz bilan hech narsa qila olmaydi.

Keling, pgcrypto bilan sinab ko'raylik. Keling, shifrlangan ma'lumotlar va oddiy ma'lumotlar bilan jadval tuzamiz. Quyida jadvallarni yaratish buyruqlari keltirilgan, birinchi qatorda foydali buyruq mavjud - kengaytmaning o'zini DBMS ro'yxatdan o'tkazish bilan yaratish:

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'));

Keyinchalik, har bir jadvaldan ma'lumotlar namunasini yaratishga harakat qilaylik va bajarilish vaqtlarini ko'rib chiqaylik.

Shifrlash funksiyasisiz jadvaldan tanlash:

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

Sekundomer yoqilgan.

  id | matn1 | matn 2
——+——-+——-
1 | 1    | 1
2 | 2    | 2
3 | 3    | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 qator)

Vaqt: 1,386 ms

Shifrlash funksiyasiga ega jadvaldan tanlash:

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

Sekundomer yoqilgan.

  id | shifrini ochish | shifrini ochish
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 qator)

Vaqt: 50,203 ms

Sinov natijalari:

 
Shifrlashsiz
Pgcrypto (shifrini ochish)

1000 qator namunasi
1,386 mil
50,203 mil

Markaziy protsessor
15%
35%

RAM
 
+ 5%

Shifrlash ishlashga katta ta'sir ko'rsatadi. Ko'rinib turibdiki, vaqt ko'paygan, chunki shifrlangan ma'lumotlarni dekodlash operatsiyalari (va shifrni hal qilish odatda sizning mantiqingizga o'ralgan) katta resurslarni talab qiladi. Ya'ni, ba'zi ma'lumotlarni o'z ichiga olgan barcha ustunlarni shifrlash g'oyasi ishlashning pasayishiga olib keladi.

Biroq, shifrlash barcha muammolarni hal qiladigan kumush o'q emas. Shifrlangan ma'lumotlar va shifrni ochish va ma'lumotlarni uzatish jarayonida shifrni ochish kaliti serverda joylashgan. Shuning uchun, kalitlarni ma'lumotlar bazasi serveriga to'liq kirish huquqiga ega bo'lgan shaxs, masalan, tizim ma'muri ushlab turishi mumkin.

Barcha foydalanuvchilar uchun butun ustun uchun bitta kalit mavjud bo'lganda (hamma uchun bo'lmasa ham, lekin cheklangan to'plamdagi mijozlar uchun), bu har doim ham yaxshi va to'g'ri emas. Shuning uchun ular oxirigacha shifrlashni boshladilar, DBMSda ular mijoz va server tomonida ma'lumotlarni shifrlash variantlarini ko'rib chiqishni boshladilar va o'sha kalitlar omborlari paydo bo'ldi - DBMSda kalitlarni boshqarishni ta'minlaydigan alohida mahsulotlar tomoni.

MongoDB-da bunday shifrlashga misol

Tijorat va ochiq kodli ma'lumotlar bazasida xavfsizlik xususiyatlari

Vazifalar
Kesuvchi apparat
Parol siyosati
audit
Protseduralar va funktsiyalarning manba kodini himoya qilish
RLS
shifrlash

Oracle
tijorat
+
+
+
+
+

MsSql
tijorat
+
+
+
+
+

Jatoba
tijorat
+
+
+
+
kengaytmalari

PostgreSQL
Ozod
kengaytmalari
kengaytmalari
-
+
kengaytmalari

MongoDb
Ozod
-
+
-
-
Faqat MongoDB Enterprise-da mavjud

Jadval to'liq emas, ammo vaziyat shunday: tijorat mahsulotlarida xavfsizlik muammolari uzoq vaqt davomida hal qilingan, ochiq manbada, qoida tariqasida, xavfsizlik uchun qandaydir qo'shimchalar qo'llaniladi, ko'plab funktsiyalar etishmayapti. , ba'zan siz biror narsa qo'shishingiz kerak. Masalan, parol siyosati - PostgreSQL juda ko'p turli xil kengaytmalarga ega (1, 2, 3, 4, 5), parol siyosatini amalga oshiradigan, ammo, mening fikrimcha, ularning hech biri mahalliy korporativ segmentning barcha ehtiyojlarini qoplamaydi.

Agar biror joyda kerakli narsangiz bo'lmasa, nima qilish kerak? Masalan, siz mijoz talab qiladigan funksiyalarga ega bo'lmagan ma'lum ma'lumotlar bazasidan foydalanmoqchisiz.

Keyin siz turli xil DBMSlar bilan ishlaydigan uchinchi tomon echimlaridan foydalanishingiz mumkin, masalan, Crypto DB yoki Garda DB. Agar biz mahalliy segmentdagi echimlar haqida gapiradigan bo'lsak, ular GOSTlar haqida ochiq manbadan ko'ra yaxshiroq bilishadi.

Ikkinchi variant - o'zingizga kerak bo'lgan narsalarni yozish, protsedura darajasida dasturda ma'lumotlarga kirish va shifrlashni amalga oshirish. To'g'ri, GOST bilan qiyinroq bo'ladi. Ammo umuman olganda, siz kerakli ma'lumotlarni yashirishingiz, uni DBMSga qo'yishingiz, keyin uni olishingiz va kerak bo'lganda shifrini ochishingiz mumkin, to'g'ridan-to'g'ri dastur darajasida. Shu bilan birga, dasturda ushbu algoritmlarni qanday himoya qilishingiz haqida darhol o'ylab ko'ring. Bizning fikrimizcha, bu DBMS darajasida amalga oshirilishi kerak, chunki u tezroq ishlaydi.

Ushbu hisobot birinchi marta taqdim etilgan @Ma'lumotlar bazalari uchrashuvi Mail.ru Cloud Solutions tomonidan. Qarang видео boshqa chiqishlar va Telegram’dagi voqealar anonsiga obuna bo‘ling Mail.ru guruhida Kubernetes atrofida.

Mavzu bo'yicha yana nimani o'qish kerak:

1. Cephdan ko'proq: MCS bulutli blokli saqlash.
2. Loyiha uchun ma'lumotlar bazasini qanday tanlash kerak, shuning uchun siz yana tanlov qilishingiz shart emas.

Manba: www.habr.com