Намайг Денис Рожков гэдэг, би Газинформсервис компанийн програм хангамж хөгжүүлэлтийн дарга, бүтээгдэхүүний багт ажилладаг. . Хууль тогтоомж, аж ахуйн нэгжийн зохицуулалт нь мэдээллийн хадгалалтын аюулгүй байдалд тодорхой шаардлагыг тавьдаг. Гуравдагч этгээд нууц мэдээлэлд нэвтрэхийг хэн ч хүсэхгүй байгаа тул аливаа төслийн хувьд дараахь асуудлууд чухал байдаг: таних, баталгаажуулах, өгөгдөлд хандах хандалтыг удирдах, систем дэх мэдээллийн бүрэн бүтэн байдлыг хангах, аюулгүй байдлын үйл явдлыг бүртгэх. Тиймээс би DBMS-ийн аюулгүй байдлын талаар сонирхолтой зүйлсийн талаар ярихыг хүсч байна.
дээрх илтгэл дээр үндэслэн нийтлэлийг бэлтгэв зохион байгуулсан . Уншихыг хүсэхгүй байгаа бол үзэх боломжтой:
Нийтлэл гурван хэсгээс бүрдэнэ.
- Холболтыг хэрхэн хамгаалах вэ.
- Үйлдлийн аудит гэж юу вэ, мэдээллийн баазын тал дээр юу болж байгааг хэрхэн бүртгэх, түүнтэй холбогдох.
- Мэдээллийн сан дахь өгөгдлийг хэрхэн хамгаалах, үүнд ямар технологи ашиглах боломжтой вэ.
DBMS аюулгүй байдлын гурван бүрэлдэхүүн хэсэг: холболтын хамгаалалт, үйл ажиллагааны аудит, мэдээллийн хамгаалалт
Таны холболтыг хамгаалж байна
Та мэдээллийн сантай шууд болон шууд бусаар вэб програмаар холбогдож болно. Дүрмээр бол бизнесийн хэрэглэгч, өөрөөр хэлбэл DBMS-тэй ажилладаг хүн түүнтэй шууд бусаар харилцдаг.
Холболтыг хамгаалах талаар ярихаасаа өмнө аюулгүй байдлын арга хэмжээг хэрхэн зохион байгуулахыг тодорхойлох чухал асуултуудад хариулах хэрэгтэй.
- Нэг бизнесийн хэрэглэгч нь нэг DBMS хэрэглэгчтэй тэнцэх үү?
- DBMS өгөгдөлд хандах хандалт нь зөвхөн таны удирддаг API-ээр хангагдсан эсэх, эсвэл хүснэгтэд шууд хандах эсэх;
- DBMS нь тусдаа хамгаалагдсан сегментэд хуваарилагдсан эсэх, түүнтэй хэн, хэрхэн харьцдаг;
- Холболт хэрхэн хийгдсэн, мэдээллийн санг хэн ашиглаж байгаа талаарх мэдээллийг өөрчлөх боломжтой нэгтгэх/прокси болон завсрын давхаргууд ашиглаж байгаа эсэх.
Одоо холболтыг хамгаалахын тулд ямар хэрэгслийг ашиглаж болохыг харцгаая.
- Өгөгдлийн сангийн галт ханын ангиллын шийдлүүдийг ашигла. Нэмэлт хамгаалалтын давхарга нь доод тал нь DBMS-д болж буй үйл явдлын ил тод байдлыг нэмэгдүүлэх бөгөөд дээд тал нь та нэмэлт мэдээллийн хамгаалалтыг хангах боломжтой болно.
- Нууц үгийн бодлогыг ашиглах. Тэдний хэрэглээ нь таны архитектур хэрхэн баригдсанаас хамаарна. Ямар ч тохиолдолд DBMS-д холбогдсон вэб програмын тохиргооны файлд нэг нууц үг хамгаалалтад хангалтгүй. Хэрэглэгч болон нууц үг шинэчлэх шаардлагатай эсэхийг хянах боломжийг олгодог олон тооны DBMS хэрэгслүүд байдаг.
Та хэрэглэгчийн үнэлгээний функцуудын талаар илүү ихийг уншиж болно , та мөн MS SQL эмзэг байдлын үнэлгээний талаар олж мэдэх боломжтой .
- Чуулганы агуулгыг шаардлагатай мэдээллээр баяжуулах. Хэрэв сесс тунгалаг бол түүний хүрээнд DBMS-д хэн ажиллаж байгааг ойлгохгүй байгаа бол та хийж буй үйлдлийнхээ хүрээнд хэн, яагаад юу хийж байгаа талаарх мэдээллийг нэмж болно. Энэ мэдээллийг аудитаас харж болно.
- Хэрэв танд DBMS болон эцсийн хэрэглэгчдийн хооронд сүлжээний тусгаарлалт байхгүй бол SSL-г тохируулна уу; энэ нь тусдаа VLAN-д байдаггүй. Ийм тохиолдолд хэрэглэгч болон DBMS хоёрын хоорондох сувгийг хамгаалах нь зайлшгүй шаардлагатай. Аюулгүй байдлын хэрэгслүүдийг мөн нээлттэй эх сурвалжид ашиглах боломжтой.
Энэ нь DBMS-ийн гүйцэтгэлд хэрхэн нөлөөлөх вэ?
PostgreSQL-ийн жишээг харцгаая, SSL нь CPU-ийн ачаалалд хэрхэн нөлөөлж, цаг хугацааг нэмэгдүүлж, TPS-ийг бууруулдаг, хэрэв та үүнийг идэвхжүүлбэл хэт их нөөцийг ашиглах эсэхийг харцгаая.
PostgreSQL-г pgbench ашиглан ачаалах нь гүйцэтгэлийн тест хийх энгийн програм юм. Энэ нь нэг командын дарааллыг давтан, магадгүй өгөгдлийн сангийн зэрэгцээ сессүүдэд гүйцэтгэж, дараа нь гүйлгээний дундаж хурдыг тооцдог.
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 ms
187.695 ms
tps, түүний дотор холболтыг бий болгох
58.168112
53.278062
холбохоос бусад tps
64.084546
58.725846
CPU-ийн
24%
28%
Бүх гүйлгээг нэг холболтоор гүйцэтгэдэг
хоцролтын дундаж
6.722 ms
6.342 ms
tps, түүний дотор холболтыг бий болгох
1587.657278
1576.792883
холбохоос бусад tps
1588.380574
1577.694766
CPU-ийн
17%
21%
Хөнгөн ачааллын үед SSL-ийн нөлөөг хэмжилтийн алдаатай харьцуулж болно. Хэрэв шилжүүлсэн өгөгдлийн хэмжээ маш их байвал нөхцөл байдал өөр байж болно. Хэрэв бид нэг гүйлгээ бүрт нэг холболт үүсгэвэл (энэ нь ховор тохиолддог, ихэвчлэн холболтыг хэрэглэгчдийн хооронд хуваалцдаг) танд олон тооны холболт/тасралт байгаа тул нөлөөлөл нь арай том байх болно. Өөрөөр хэлбэл, гүйцэтгэл буурах эрсдэлтэй байж болох ч ялгаа нь хамгаалалт ашиглахгүй байх тийм ч том биш юм.
Хэрэв та үйлдлийн горимуудыг харьцуулж үзвэл хүчтэй ялгаа байгааг анхаарна уу: та нэг сесс дотор эсвэл өөр өөр горимд ажиллаж байна. Энэ нь ойлгомжтой: холболт бүрийг бий болгоход нөөцийг зарцуулдаг.
Бид Zabbix-ийг итгэлцлийн горимд холбосон тохиолдол гарсан, өөрөөр хэлбэл md5 шалгагдаагүй, баталгаажуулалт хийх шаардлагагүй байсан. Дараа нь үйлчлүүлэгч md5 баталгаажуулалтын горимыг идэвхжүүлэхийг хүссэн. Энэ нь CPU-д их ачаалал өгч, гүйцэтгэл буурсан. Бид оновчтой болгох арга замыг хайж эхэлсэн. Асуудлыг шийдэх боломжит шийдлүүдийн нэг нь сүлжээний хязгаарлалтыг хэрэгжүүлэх, DBMS-д тусад нь VLAN хийх, хэн хаанаас холбогдож байгааг тодорхой болгох тохиргоог нэмж, баталгаажуулалтыг арилгах явдал юм.Мөн та баталгаажуулалтыг идэвхжүүлэх үед зардлыг бууруулахын тулд баталгаажуулалтын тохиргоог оновчтой болгох боломжтой. Ерөнхийдөө баталгаажуулалтын янз бүрийн аргуудыг ашиглах нь гүйцэтгэлд нөлөөлдөг бөгөөд DBMS-ийн серверүүдийн (техник хангамж) тооцоолох хүчийг боловсруулахдаа эдгээр хүчин зүйлсийг харгалзан үзэх шаардлагатай.
Дүгнэлт: Олон тооны шийдлүүдийн хувьд баталгаажуулалтын жижиг нюансууд ч гэсэн төсөлд ихээхэн нөлөөлж болох бөгөөд энэ нь зөвхөн үйлдвэрлэлд хэрэгжсэн тохиолдолд тодорхой болох нь муу юм.
Үйл ажиллагааны аудит
Аудит нь зөвхөн DBMS байж болохгүй. Аудит нь янз бүрийн сегментүүдэд болж буй үйл явдлын талаархи мэдээллийг олж авах явдал юм. Энэ нь өгөгдлийн сангийн галт хана эсвэл DBMS-ийг суурилуулсан үйлдлийн систем байж болно.
Арилжааны аж ахуйн нэгжийн түвшний DBMS-д аудитын хувьд бүх зүйл сайн байдаг, гэхдээ нээлттэй эх сурвалжид - үргэлж биш. PostgreSQL-д юу байгааг энд харуулав.
- анхдагч бүртгэл - суурилуулсан бүртгэл;
- өргөтгөлүүд: pgaudit - хэрэв анхдагч бүртгэл танд хангалттай биш бол та зарим асуудлыг шийдвэрлэх тусдаа тохиргоог ашиглаж болно.
Видео дээрх тайланд нэмэлт:
"Үндсэн мэдэгдлийн бүртгэлийг log_statement = all гэсэн стандарт бүртгэлийн хэрэгслээр хангаж болно.
Энэ нь хяналт-шинжилгээ болон бусад хэрэглээнд зөвшөөрөгдөх боловч аудит хийхэд ихэвчлэн шаардлагатай нарийвчилсан түвшнийг өгдөггүй.
Мэдээллийн сан дээр хийгдсэн бүх үйлдлүүдийн жагсаалт байх нь хангалтгүй юм.
Мөн аудиторын сонирхлыг татахуйц тодорхой мэдэгдлүүдийг олох боломжтой байх ёстой.
Стандарт бүртгэл нь хэрэглэгчийн хүссэн зүйлийг харуулдаг бол pgAudit нь өгөгдлийн сангаас асуулгыг гүйцэтгэх үед юу болсон талаар дэлгэрэнгүй мэдээлэл өгдөг.
Жишээлбэл, аудитор тодорхой хүснэгтийг баримтжуулсан засвар үйлчилгээний цонхонд үүсгэсэн эсэхийг шалгахыг хүсч болно.
Энэ нь үндсэн аудит болон grep-тэй энгийн ажил мэт санагдаж болох ч танд үүнтэй төстэй (санаатай төөрөгдүүлсэн) жишээ үзүүлбэл яах вэ:
DO$$
BEGIN
'CREATE TABLE импорт' ГҮЙЦЭТГЭХ || 'ant_table(id int)';
END$$;
Стандарт бүртгэл танд дараахь зүйлийг өгнө.
LOG: мэдэгдэл: DO $$
BEGIN
'CREATE TABLE импорт' ГҮЙЦЭТГЭХ || 'ant_table(id int)';
END$$;
Хүснэгтийг динамикаар үүсгэсэн тохиолдолд сонирхсон хүснэгтийг олохын тулд зарим кодын мэдлэг шаардагддаг бололтой.
Хүснэгтийн нэрээр хайх нь илүү тохиромжтой тул энэ нь тийм ч тохиромжтой биш юм.
Энд pgAudit хэрэг болно.
Ижил оролтын хувьд энэ нь энэ гаралтыг бүртгэлд гаргах болно:
АУДИТ: ХУРАЛ,33,1,ФУНКЦ,ХИЙХ,,,"ХИЙХ $$
BEGIN
'CREATE TABLE импорт' ГҮЙЦЭТГЭХ || 'ant_table(id int)';
END$$;"
АУДИТ: ХУРАЛДААН,33,2,DDL,ХҮСНЭГТ ҮЗҮҮЛЭХ,ХҮСНЭГТ,нийтийн.чухал_хүснэгт,ХҮСНЭГТ ҮҮСГЭХ чухал_хүснэгт (id INT)
Зөвхөн DO блок бүртгэгдээд зогсохгүй CREATE TABLE-ийн өгүүллийн төрөл, объектын төрөл, бүтэн нэр бүхий бүтэн текстийг оруулснаар хайлт хийхэд хялбар болно.
SELECT болон DML мэдэгдлүүдийг бүртгэхдээ pgAudit-г мэдэгдэлд дурдсан харилцаа тус бүрд тусад нь оруулахаар тохируулж болно.
Тодорхой хүснэгтэд хүрсэн бүх мэдэгдлийг олохын тулд задлан шинжлэх шаардлагагүй () ”.
Энэ нь DBMS-ийн гүйцэтгэлд хэрхэн нөлөөлөх вэ?
Бүрэн аудитыг идэвхжүүлсэн тестийг ажиллуулж, PostgreSQL гүйцэтгэлд юу тохиолдохыг харцгаая. Бүх параметрийн мэдээллийн сангийн бүртгэлийг дээд зэргээр идэвхжүүлье.
Бид тохиргооны файлд бараг юу ч өөрчлөхгүй, хамгийн чухал зүйл бол хамгийн их мэдээлэл авахын тулд дибаг5 горимыг асаах явдал юм.
postgresql.conf
log_destination = 'stderr'
logging_collector = асаалттай
log_truncate_on_rotation = асаалттай
бүртгэлийн_эргэлтийн_нас = 1d
бүртгэлийн_эргэлтийн_хэмжээ = 10MB
log_min_messages = дибаг хийх 5
log_min_error_statement = дибаг хийх 5
log_min_duration_statement = 0
debug_print_parse = асаалттай
debug_print_rewritten = асаалттай
дибаг_хэвлэх_төлөвлөгөө = асаалттай
debug_pretty_print = асаалттай
log_checkpoints = асаалттай
бүртгэлийн_холболтууд = асаалттай
бүртгэлийн_тасралт = асаалттай
бүртгэлийн_үргэлжлэх хугацаа = асаалттай
log_hostname = асаалттай
log_lock_wait = асаалттай
log_replication_commands = асаалттай
log_temp_files = 0
log_timezone = 'Европ/Москва'
1 CPU, 2,8 GHz, 2 GB RAM, 40 GB 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 sec
53,23 sec
RAM
24%
40%
CPU-ийн
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 болон CPU-ийн гүйцэтгэл муудах болно. Энэ нь бүтээмжид ч мэдэгдэхүйц юм.
Холболтын тоо нэмэгдэхийн хэрээр гүйцэтгэл нь бага зэрэг муудах болно.
Аудиттай корпорациудад энэ нь илүү хэцүү байдаг:
- маш их өгөгдөл байдаг;
- Аудит нь зөвхөн SIEM-д syslog-ээр дамжуулан төдийгүй файлуудад шаардлагатай: хэрэв syslog-д ямар нэг зүйл тохиолдвол өгөгдөл хадгалагдаж буй өгөгдлийн сангийн ойролцоо файл байх ёстой;
- Аудитын хувьд маш их зай эзэлдэг тул оролт гаралтын дискэнд дэмий үрэхгүй байхын тулд тусдаа тавиур хэрэгтэй;
- Мэдээллийн аюулгүй байдлын ажилтнуудад хаа сайгүй ГОСТ стандарт шаардлагатай байдаг тул төрийн үнэмлэх шаардлагатай байдаг.
Мэдээллийн хандалтыг хязгаарлаж байна
Арилжааны DBMS болон нээлттэй эх сурвалжид өгөгдлийг хамгаалах, түүнд хандахад ашигладаг технологиудыг харцгаая.
Та ерөнхийдөө юу ашиглаж болох вэ:
- Процедур, функцийг шифрлэх, бүдгэрүүлэх (Боодол) - өөрөөр хэлбэл унших боломжтой кодыг унших боломжгүй болгодог тусдаа хэрэгсэл, хэрэгслүүд. Үнэн бол үүнийг өөрчлөх эсвэл дахин засварлах боломжгүй. Заримдаа энэ арга нь дор хаяж DBMS талд шаардлагатай байдаг - лицензийн хязгаарлалтын логик эсвэл зөвшөөрлийн логик нь процедур болон функцийн түвшинд яг шифрлэгдсэн байдаг.
- Мэдээллийн харагдах байдлыг мөрөөр хязгаарлах (RLS) гэдэг нь өөр өөр хэрэглэгчид нэг хүснэгтийг хардаг боловч түүний доторх мөрүүдийн өөр бүтэцтэй, өөрөөр хэлбэл мөрийн түвшинд байгаа хүнд ямар нэг зүйлийг харуулах боломжгүй байдаг.
- Үзүүлсэн өгөгдлийг засварлах (маск хийх) нь хүснэгтийн нэг баганад байгаа хэрэглэгчид өгөгдөл эсвэл зөвхөн одоор харах, өөрөөр хэлбэл зарим хэрэглэгчдийн хувьд мэдээлэл хаагдах болно. Технологи нь аль хэрэглэгчийг хандалтын түвшинд тулгуурлан юу харуулахыг тодорхойлдог.
- Аюулгүй байдлын DBA/Application DBA/DBA хандалтын хяналт нь DBMS-д хандах хандалтыг хязгаарлах, өөрөөр хэлбэл мэдээллийн аюулгүй байдлын ажилтнуудыг өгөгдлийн сангийн администраторууд болон програмын администраторуудаас тусгаарлах явдал юм. Нээлттэй эх сурвалжид ийм технологи цөөхөн байдаг ч арилжааны DBMS-д маш олон байдаг. Өөрсдөө серверт хандах боломжтой олон хэрэглэгчид байгаа үед тэдгээр нь шаардлагатай байдаг.
- Файлын системийн түвшинд файлд хандах хандалтыг хязгаарлаж байна. Администратор бүр зөвхөн шаардлагатай өгөгдөлд хандах эрхтэй байхын тулд та лавлах эрх, хандалтын эрхийг олгож болно.
- Заавал нэвтрэх, санах ойг цэвэрлэх - эдгээр технологийг бараг ашигладаггүй.
- 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 | текст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 ms
50,203 ms
CPU-ийн
15%
35%
RAM
+ 5%
Шифрлэлт нь гүйцэтгэлд ихээхэн нөлөөлдөг. Шифрлэгдсэн өгөгдлийн шифрийг тайлах үйлдлүүд (мөн шифрийг тайлах нь ихэвчлэн таны логикт оршдог) ихээхэн нөөц шаарддаг тул цаг хугацаа нэмэгдсэн нь харагдаж байна. Өөрөөр хэлбэл, зарим өгөгдөл агуулсан бүх баганыг шифрлэх санаа нь гүйцэтгэл буурахад хүргэдэг.
Гэсэн хэдий ч шифрлэлт нь бүх асуудлыг шийддэг мөнгөн сум биш юм. Шифрийг тайлах, дамжуулах явцад шифрлэгдсэн өгөгдөл болон код тайлах түлхүүр нь сервер дээр байрладаг. Тиймээс системийн администратор гэх мэт мэдээллийн сангийн серверт бүрэн хандах эрхтэй хэн нэгэн түлхүүрүүдийг барьж болно.
Бүх хэрэглэгчдэд (бүгд биш ч гэсэн хязгаарлагдмал багцын үйлчлүүлэгчид) нэг түлхүүр байгаа бол энэ нь үргэлж сайн бөгөөд зөв байдаггүй. Тийм ч учраас тэд төгсгөл хоорондын шифрлэлт хийж эхэлсэн бөгөөд DBMS-д тэд клиент болон серверийн тал дахь өгөгдлийг шифрлэх сонголтыг авч үзэж эхэлсэн бөгөөд ижил түлхүүр хадгалалтууд гарч ирэв - DBMS дээр түлхүүрийн удирдлагыг хангадаг тусдаа бүтээгдэхүүнүүд тал.
Арилжааны болон нээлттэй эхийн DBMS дахь аюулгүй байдлын онцлогууд
Чиг үүрэг
Төрөл
Нууц үгийн бодлого
Аудит
Процедур, функцүүдийн эх кодыг хамгаалах
RLS
Encryption
Oracle-ийн
арилжааны
+
+
+
+
+
MsSql
арилжааны
+
+
+
+
+
арилжааны
+
+
+
+
өргөтгөлүүд
PostgreSQL
Чөлөөт
өргөтгөлүүд
өргөтгөлүүд
-
+
өргөтгөлүүд
MongoDb
Чөлөөт
-
+
-
-
Зөвхөн MongoDB Enterprise-д ашиглах боломжтой
Хүснэгт нь бүрэн гүйцэд биш боловч нөхцөл байдал ийм байна: арилжааны бүтээгдэхүүнүүдэд аюулгүй байдлын асуудлыг удаан хугацаанд шийдэж ирсэн, нээлттэй эх сурвалж дээр дүрмээр бол аюулгүй байдлын үүднээс зарим төрлийн нэмэлтүүдийг ашигладаг, олон функц байхгүй байна. , заримдаа та ямар нэг зүйл нэмэх хэрэгтэй. Жишээлбэл, нууц үгийн бодлого - PostgreSQL олон төрлийн өргөтгөлтэй (, , , , ), нууц үгийн бодлогыг хэрэгжүүлдэг боловч миний бодлоор тэдгээрийн аль нь ч дотоодын корпорацийн сегментийн бүх хэрэгцээг хангадаггүй.
Танд хэрэгтэй зүйл хаана ч байхгүй бол яах вэ? Жишээлбэл, та үйлчлүүлэгчийн шаарддаг функцгүй тодорхой DBMS ашиглахыг хүсч байна.
Дараа нь та өөр өөр DBMS-тэй ажилладаг гуравдагч талын шийдлүүдийг ашиглаж болно, жишээлбэл Crypto DB эсвэл Garda DB. Хэрэв бид дотоодын сегментийн шийдлүүдийн талаар ярьж байгаа бол тэд ГОСТ-ийн талаар нээлттэй эх сурвалжаас илүү сайн мэддэг.
Хоёрдахь сонголт бол өөрт хэрэгтэй зүйлээ өөрөө бичих, программ дахь өгөгдөлд хандах, шифрлэлтийг процедурын түвшинд хэрэгжүүлэх явдал юм. Үнэн, ГОСТ-тэй энэ нь илүү хэцүү байх болно. Гэхдээ ерөнхийдөө та өгөгдлийг шаардлагатай бол нууж, DBMS-д хийж, дараа нь татаж авч, шаардлагатай бол кодыг тайлж, програмын түвшинд хийж болно. Үүний зэрэгцээ эдгээр алгоритмуудыг програмд хэрхэн хамгаалах талаар даруй бодож үзээрэй. Бидний бодлоор үүнийг DBMS түвшинд хийх ёстой, учир нь энэ нь илүү хурдан ажиллах болно.
Энэ тайланг анх удаа танилцуулав Mail.ru Cloud Solutions. Хараачбусад үзүүлбэрүүд болон Telegram дээр үйл явдлын зарлалыг захиалах .
Энэ сэдвээр өөр юу унших вэ:
- .
- .
Эх сурвалж: www.habr.com