منهنجو نالو Denis Rozhkov آهي، مان Gazinformservice ڪمپني ۾ سافٽ ويئر ڊولپمينٽ جو سربراهه آهيان، پراڊڪٽ ٽيم ۾ جتوبا. قانون سازي ۽ ڪارپوريٽ ضابطا ڊيٽا اسٽوريج جي حفاظت لاءِ ڪجهه گهرج لاڳو ڪن ٿا. ڪو به نه ٿو چاهي ته ٽئين پارٽيون ڳجهي معلومات تائين رسائي حاصل ڪن، تنهن ڪري هيٺيان مسئلا ڪنهن به منصوبي لاء اهم آهن: سڃاڻپ ۽ تصديق، ڊيٽا تائين رسائي جو انتظام، سسٽم ۾ معلومات جي سالميت کي يقيني بڻائڻ، سيڪيورٽي واقعن کي لاگ ان ڪرڻ. تنهن ڪري، مان DBMS سيڪيورٽي بابت ڪجهه دلچسپ نقطي بابت ڳالهائڻ چاهيان ٿو.

مضمون تي هڪ تقرير جي بنياد تي تيار ڪيو ويو @DatabasesMeetup، منظم Mail.ru ڪلائوڊ حل. جيڪڏهن توهان پڙهڻ نٿا چاهيو، توهان ڏسي سگهو ٿا:

مضمون جا ٽي حصا هوندا:

• ڪنيڪشن ڪيئن محفوظ ڪجي.
• عملن جو آڊٽ ڇا آهي ۽ ڊيٽابيس جي پاسي تي ڇا ٿي رهيو آهي ۽ ان سان ڳنڍڻ کي ڪيئن رڪارڊ ڪجي.
• ڊيٽابيس ۾ ڊيٽا کي ڪيئن محفوظ ڪجي ۽ ان لاءِ ڪهڙيون ٽيڪنالاجيون موجود آهن.

DBMS سيڪيورٽي جا ٽي حصا: ڪنيڪشن تحفظ، سرگرمي آڊيٽنگ ۽ ڊيٽا تحفظ

توهان جي رابطن کي محفوظ ڪرڻ

توھان ويب ايپليڪيشنن ذريعي سڌو يا اڻ سڌي طرح ڊيٽابيس سان ڳنڍي سگھو ٿا. ضابطي جي طور تي، ڪاروباري صارف، اهو آهي، جيڪو ماڻهو DBMS سان ڪم ڪري ٿو، ان سان اڻ سڌي طرح سان رابطو ڪري ٿو.

ڪنيڪشن جي حفاظت بابت ڳالهائڻ کان اڳ، توهان کي اهم سوالن جا جواب ڏيڻ گهرجن جيڪي طئي ڪن ٿا ته حفاظتي قدمن کي ڪيئن منظم ڪيو ويندو:

• ڇا ھڪڙو ڪاروباري صارف ھڪڙو DBMS صارف جي برابر آھي؟
• ڇا DBMS ڊيٽا تائين رسائي صرف هڪ API ذريعي مهيا ڪئي وئي آهي جنهن کي توهان ڪنٽرول ڪندا آهيو، يا ڇا ٽيبل تائين سڌو سنئون رسائي آهي؛
• ڇا DBMS هڪ الڳ محفوظ حصي کي مختص ڪيو ويو آهي، ڪير ان سان رابطو ڪري ٿو ۽ ڪيئن؛
• ڇا پولنگ/پراڪسي ۽ وچولي پرت استعمال ٿيل آهن، جيڪي معلومات کي تبديل ڪري سگھن ٿيون ته ڪنيڪشن ڪيئن ٺهيل آهي ۽ ڪير ڊيٽابيس استعمال ڪري رهيو آهي.

هاڻي اچو ته ڏسو ته ڪنيڪشن محفوظ ڪرڻ لاءِ ڪهڙا اوزار استعمال ڪري سگهجن ٿا:

1. ڊيٽابيس فائر وال ڪلاس حل استعمال ڪريو. تحفظ جو هڪ اضافي پرت، گهٽ ۾ گهٽ، شفافيت کي وڌائيندو جيڪو DBMS ۾ ٿي رهيو آهي، ۽ وڌ ۾ وڌ، توهان اضافي ڊيٽا تحفظ فراهم ڪرڻ جي قابل هوندا.
2. پاسورڊ پاليسيون استعمال ڪريو. انهن جي استعمال تي منحصر آهي ته توهان جي فن تعمير ڪيئن ٺهيل آهي. ڪنهن به صورت ۾، ويب ايپليڪيشن جي ترتيب واري فائل ۾ هڪ پاسورڊ جيڪو DBMS سان ڳنڍيندو آهي تحفظ لاء ڪافي ناهي. اتي ڪيترائي DBMS اوزار آھن جيڪي توھان کي ڪنٽرول ڪرڻ جي اجازت ڏين ٿا ته صارف ۽ پاسورڊ کي اپڊيٽ ڪرڻ جي ضرورت آھي.

   توھان وڌيڪ پڙھي سگھو ٿا استعمال ڪندڙ جي درجه بندي افعال بابت هتي، توهان پڻ ڳولي سگهو ٿا MS SQL Vulnerability Assessmen بابت هتي. 

3. ضروري معلومات سان سيشن جي تناظر کي بهتر بڻايو. جيڪڏهن سيشن مبهم آهي، توهان نٿا سمجهو ته DBMS ۾ ڪير ڪم ڪري رهيو آهي ان جي فريم ورڪ ۾، توهان ڪري سگهو ٿا، فريم ورڪ جي فريم ورڪ جي اندر، جيڪو ڪم ڪري رهيو آهي ۽ ڇو. اها معلومات آڊٽ ۾ ڏسي سگهجي ٿي.
4. SSL ترتيب ڏيو جيڪڏهن توهان وٽ DBMS ۽ آخري استعمال ڪندڙن جي وچ ۾ نيٽ ورڪ علحدگي نه آهي؛ اهو هڪ الڳ VLAN ۾ ناهي. اهڙين حالتن ۾، اهو ضروري آهي ته چينل کي تحفظ ڏيڻ لاء صارف ۽ ڊي بي ايم ايس پاڻ جي وچ ۾. سيڪيورٽي اوزار پڻ کليل ذريعو ۾ موجود آهن.

اهو ڪيئن اثر انداز ڪندو DBMS جي ڪارڪردگي؟

اچو ته PostgreSQL جو مثال ڏسون ته ڪيئن SSL سي پي يو لوڊ تي اثر انداز ٿئي ٿو، ٽائيم وڌائي ٿو ۽ TPS گھٽائي ٿو، ۽ ڇا اھو گھڻا وسيلا استعمال ڪندو جيڪڏھن توھان ان کي چالو ڪيو.

Pgbench استعمال ڪندي PostgreSQL لوڊ ڪندي ڪارڪردگي ٽيسٽ هلائڻ لاءِ هڪ سادي پروگرام آهي. اهو بار بار حڪمن جي ھڪڙي ترتيب تي عمل ڪري ٿو، ممڪن طور تي متوازي ڊيٽابيس سيشن ۾، ۽ پوء اوسط ٽرانزيڪشن جي شرح جي حساب سان.

ٽيسٽ 1 بغير SSL ۽ SSL استعمال ڪندي - هر ٽرانزيڪشن لاء ڪنيڪشن قائم ڪئي وئي آهي:

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 بغير SSL ۽ SSL استعمال ڪندي - سڀ ٽرانزيڪشن هڪ ڪنيڪشن ۾ ڪيا ويا آهن:

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

ٽيسٽ جا نتيجا:

 
NO SSL
ايس ايس ايل

هر ٽرانزيڪشن لاء هڪ ڪنيڪشن قائم آهي

دير جي اوسط
171.915 MS
187.695 MS

tps ڪنيڪشن قائم ڪرڻ سميت
58.168112
53.278062

tps کان سواء ڪنيڪشن قائم ڪرڻ
64.084546
58.725846

سي پي يو
24٪
28٪

سڀ ٽرانزيڪشن هڪ ڪنيڪشن ۾ ڪيا ويا آهن

دير جي اوسط
6.722 MS
6.342 MS

tps ڪنيڪشن قائم ڪرڻ سميت
1587.657278
1576.792883

tps کان سواء ڪنيڪشن قائم ڪرڻ
1588.380574
1577.694766

سي پي يو
17٪
21٪

هلڪو لوڊ تي، SSL جو اثر ماپ جي غلطي جي مقابلي ۾ آهي. جيڪڏهن منتقل ڪيل ڊيٽا جو مقدار تمام وڏو آهي، صورتحال مختلف ٿي سگهي ٿي. جيڪڏهن اسان هر ٽرانزيڪشن تي هڪ ڪنيڪشن قائم ڪريون ٿا (اهو نادر آهي، عام طور تي ڪنيڪشن صارفين جي وچ ۾ ورهايو ويندو آهي)، توهان وٽ وڏي تعداد ۾ ڪنيڪشن/منسلڪات آهن، اثر ٿورو وڏو ٿي سگهي ٿو. اهو آهي، ڪارڪردگي ۾ گهٽتائي جا خطرا ٿي سگهن ٿا، جڏهن ته، فرق ايترو وڏو ناهي جيترو تحفظ استعمال نه ڪرڻ.

مهرباني ڪري نوٽ ڪريو ته هڪ مضبوط فرق آهي جيڪڏهن توهان آپريٽنگ طريقن جو مقابلو ڪريو ٿا: توهان ڪم ڪري رهيا آهيو ساڳئي سيشن ۾ يا مختلف ۾. اهو سمجھڻ وارو آهي: هر ڪنيڪشن ٺاهڻ تي وسيلا خرچ ڪيا ويا آهن.

اسان وٽ هڪ ڪيس هو جڏهن اسان زبڪس کي اعتماد واري موڊ ۾ ڳنڍيو، اهو آهي، md5 چيڪ نه ڪيو ويو، تصديق جي ڪا ضرورت ناهي. پوءِ گراهڪ پڇيو md5 جي تصديق واري موڊ کي فعال ڪرڻ لاءِ. اهو سي پي يو تي هڪ ڳري لوڊ وجهي، ۽ ڪارڪردگي ختم ٿي وئي. اسان بهتر ڪرڻ جا طريقا ڳولڻ شروع ڪيو. مسئلي جو هڪ ممڪن حل اهو آهي ته نيٽ ورڪ پابنديون لاڳو ڪرڻ، ڊي بي ايم ايس لاءِ الڳ VLANs ٺاهيو، سيٽنگون شامل ڪريو ته جيئن اهو واضح ٿئي ته ڪير ڪٿان ڳنڍي رهيو آهي ۽ تصديق کي هٽائي ڇڏيو. توهان تصديق جي سيٽنگ کي به بهتر ڪري سگهو ٿا ته قيمت گھٽائڻ لاءِ جڏهن تصديق کي چالو ڪيو وڃي، پر عام طور تي مختلف طريقن جي استعمال جي تصديق ڪارڪردگي کي متاثر ڪري ٿي ۽ انهن عنصرن کي حساب ۾ رکڻ جي ضرورت آهي جڏهن DBMS لاءِ سرورز (هارڊويئر) جي ڪمپيوٽنگ پاور کي ڊزائين ڪرڻ.

نتيجو: ڪيترن ئي حلن ۾، جيتوڻيڪ تصديق ۾ ننڍڙا ننڍڙا به پروجيڪٽ کي تمام گهڻو متاثر ڪري سگهن ٿا ۽ اهو خراب آهي جڏهن اهو واضح ٿئي ٿو جڏهن صرف پيداوار ۾ لاڳو ٿئي ٿي.

ايڪشن آڊٽ

آڊٽ نه رڳو DBMS ٿي سگهي ٿو. هڪ آڊٽ مختلف حصن ۾ ڇا ٿي رهيو آهي بابت معلومات حاصل ڪرڻ بابت آهي. اهو ٿي سگهي ٿو هڪ ڊيٽابيس فائر وال يا آپريٽنگ سسٽم جنهن تي DBMS ٺهيل آهي.

تجارتي انٽرپرائز سطح DBMSs ۾ سڀ ڪجھ ٺيڪ آڊيٽنگ سان، پر اوپن سورس ۾ - هميشه نه. هتي آهي ڇا PostgreSQL آهي:

• ڊفالٽ لاگ - بلٽ ان لاگنگ؛
• extensions: pgaudit - جيڪڏھن ڊفالٽ لاگنگ توھان لاءِ ڪافي نه آھي، توھان استعمال ڪري سگھوٿا الڳ سيٽنگون جيڪي ڪجھ مسئلا حل ڪن ٿيون.

وڊيو ۾ رپورٽ ۾ اضافو:

"بنيادي بيان لاگنگ مهيا ڪري سگھجي ٿو معياري لاگنگ جي سهولت سان log_statement = all.

اهو مانيٽرنگ ۽ ٻين استعمالن لاءِ قابل قبول آهي، پر تفصيل جي سطح مهيا نٿو ڪري جيڪا عام طور تي آڊيٽنگ لاءِ گهربل هجي.

اهو ڪافي ناهي ته ڊيٽابيس تي ڪيل سڀني عملن جي هڪ فهرست هجي.

اهو پڻ ممڪن آهي ته مخصوص بيانن کي ڳولڻ لاء جيڪي آڊيٽر جي دلچسپي ۾ هجن.

معياري لاگنگ ڏيکاري ٿو ته صارف ڇا جي درخواست ڪئي، جڏهن ته pgAudit ان تفصيل تي ڌيان ڏئي ٿو ته ڇا ٿيو جڏهن ڊيٽابيس سوال تي عمل ڪيو.

مثال طور، آڊيٽر شايد تصديق ڪرڻ چاهي ٿو ته هڪ خاص ٽيبل ٺاهي وئي هئي دستاويزي سار سنڀال ونڊو ۾.

اهو ٿي سگهي ٿو هڪ سادي ڪم وانگر بنيادي آڊيٽنگ ۽ گريپ سان، پر ڇا جيڪڏهن توهان کي پيش ڪيو ويو ته اهڙي شيء سان (عمدي طور تي مونجهارو) مثال:

ڪريو$$
اچو
EXECUTE 'CREATE TABLE Import' || 'ant_table(id int)'؛
END$$؛

معياري لاگنگ توهان کي ڏيندو:

لاگ: بيان: ڪريو $$
اچو
EXECUTE 'CREATE TABLE Import' || 'ant_table(id int)'؛
END$$؛

اهو ظاهر ٿئي ٿو ته دلچسپي جي جدول کي ڳولڻ لاء ڪجهه ڪوڊ ڄاڻ جي ضرورت هجي ڪيسن ۾ جتي جدول متحرڪ طور تي ٺاهيا ويا آهن.

اهو مثالي نه آهي، ڇاڪاڻ ته اهو بهتر ٿيندو ته صرف ٽيبل جي نالي سان ڳولا ڪريو.

اهو آهي جتي pgAudit هٿ ۾ اچي ٿو.

ساڳئي ان پٽ لاء، اهو لاگ ان ۾ هي پيداوار پيدا ڪندو:

آڊٽ: سيشن، 33,1، فنڪشن، ڪريو،،،، ڪريو $$
اچو
EXECUTE 'CREATE TABLE Import' || 'ant_table(id int)'؛
آخر$$؛"
آڊٽ: سيشن، 33,2، ڊي ڊي ايل، ٽيبل ٺاھيو، ٽيبل، عوامي. اھم_ٽيبل، ٺاھيو ٽيبل اھم_ٽيبل (ID INT)

نه رڳو DO بلاڪ لاگ ان ٿيل آهي، پر CREATE TABLE جو مڪمل متن بيان جي قسم، اعتراض جي قسم، ۽ مڪمل نالو سان، ڳولا کي آسان بڻائي ٿو.

جڏهن SELECT ۽ DML بيانن کي لاگ ان ڪريو، pgAudit بيان ۾ ڏنل هر تعلق لاءِ الڳ داخلا لاگ ڪرڻ لاءِ ترتيب ڏئي سگهجي ٿو.

سڀني بيانن کي ڳولڻ لاءِ ڪنهن به تجزيي جي ضرورت ناهي جيڪي ڪنهن خاص ٽيبل کي ڇڪيندا آهن(*).

اهو ڪيئن اثر انداز ڪندو DBMS جي ڪارڪردگي؟

اچو ته مڪمل آڊيٽنگ فعال ٿيڻ سان ٽيسٽون هلون ۽ ڏسو ته ڇا ٿئي ٿو PostgreSQL ڪارڪردگي. اچو ته سڀني پيراگرافن لاءِ وڌ ۾ وڌ ڊيٽابيس لاگنگ کي فعال ڪريون.

اسان ترتيب واري فائل ۾ تقريبا ڪجھ به تبديل نه ڪندا آهيون، سڀ کان اهم شيء آهي ڊيبگ 5 موڊ کي چالو ڪرڻ لاء وڌ کان وڌ معلومات حاصل ڪرڻ لاء.

postgresql.conf

log_destination = 'stderr'
logging_collector = آن
log_truncate_on_rotation = آن
log_rotation_age = 1d
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 = 'يورپ/ماسڪو'

PostgreSQL DBMS تي 1 CPU، 2,8 GHz، 2 GB RAM، 40 GB HDD جي پيٽرولن سان، اسان حڪمن کي استعمال ڪندي ٽي لوڊ ٽيسٽ ڪندا آهيون:

$ 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 MS
925 MS

ٽيسٽ 2 (150 ڪنيڪشن سان گڏ 100 ممڪن)

10 منٽن ۾ ٽرانزيڪشن جو تعداد
81727
31429

ٽرانزيڪشن / سيڪنڊ
136
52

سراسري دير
550 MS
1432 MS

سائيز جي باري ۾

ڊي بي سائيز
2251 MB
2262 MB

ڊيٽابيس لاگ سائيز
0 MB
4587 MB

هيٺيون لڪير: هڪ مڪمل آڊٽ تمام سٺو ناهي. آڊٽ مان ڊيٽا ايتري وڏي هوندي جيترو ڊيٽابيس ۾ موجود ڊيٽا، يا ان کان به وڌيڪ. لاگنگ جي مقدار جيڪا پيدا ٿئي ٿي جڏهن ڊي بي ايم ايس سان ڪم ڪري ٿي پيداوار ۾ هڪ عام مسئلو آهي.

اچو ته ٻين پيراگرافن کي ڏسو:

• رفتار گهڻو تبديل نٿو ڪري: بغير لاگنگ - 43,74 سيڪنڊ، لاگنگ سان - 53,23 سيڪنڊ.
• رام ۽ سي پي يو جي ڪارڪردگي متاثر ٿيندي، جيئن توهان کي آڊٽ فائل ٺاهڻ جي ضرورت آهي. اهو پڻ پيداوار ۾ قابل ذڪر آهي.

جيئن ته ڪنيڪشن جو تعداد وڌي ٿو، قدرتي طور تي، ڪارڪردگي ٿورڙي خراب ٿيندي.

آڊٽ سان ڪارپوريشنن ۾ اهو اڃا به وڌيڪ ڏکيو آهي:

• ڊيٽا جو تمام گهڻو آهي؛
• آڊيٽنگ جي ضرورت آهي نه رڳو SIEM ۾ syslog ذريعي، پر فائلن ۾ پڻ: جيڪڏهن syslog کي ڪجهه ٿئي ٿو، اتي لازمي طور تي ڊيٽابيس جي ويجهو هڪ فائل هجڻ گهرجي جنهن ۾ ڊيٽا محفوظ ڪئي وئي آهي؛
• آڊيٽنگ لاءِ هڪ الڳ شيلف جي ضرورت آهي ته جيئن I/O ڊسڪ کي ضايع نه ڪري، ڇاڪاڻ ته اهو تمام گهڻو جاء وٺندو آهي؛
• اهو ٿئي ٿو ته معلومات سيڪيورٽي ملازمن کي هر جڳهه GOST معيار جي ضرورت آهي، انهن کي رياست جي سڃاڻپ جي ضرورت آهي.

ڊيٽا تائين رسائي کي محدود ڪرڻ

اچو ته ڏسو ٽيڪنالاجيون جيڪي ڊيٽا کي بچائڻ لاءِ استعمال ٿين ٿيون ۽ ان کي تجارتي DBMSs ۽ اوپن سورس ۾ پهچن ٿيون.

توهان عام طور تي ڇا استعمال ڪري سگهو ٿا:

1. انڪريپشن ۽ طريقيڪار ۽ ڪمن جي اوچائي (ريپنگ) - اهو آهي، الڳ الڳ اوزار ۽ افاديت جيڪي پڙهڻ جي قابل ڪوڊ کي اڻ پڙهيل بڻائين. سچ پچ ته پوءِ ان کي نه بدلائي سگهجي ٿو ۽ نه ئي وري ٻيهر ٺاهي سگهجي ٿو. اهو طريقو ڪڏهن ڪڏهن گهٽ ۾ گهٽ DBMS پاسي جي ضرورت آهي - لائسنس جي پابنديون يا اختيار جي منطق جو منطق صحيح طور تي طريقيڪار ۽ فنڪشن جي سطح تي انڪوڊ ٿيل آهي.
2. قطارن (RLS) ذريعي ڊيٽا جي نمائش کي محدود ڪرڻ اهو آهي جڏهن مختلف استعمال ڪندڙ هڪ ٽيبل کي ڏسن ٿا، پر ان ۾ قطارن جو هڪ مختلف ٺهيل آهي، اهو آهي ته، قطار جي سطح تي ڪنهن کي ڪجهه ڏيکاري نه ٿو سگهجي.
3. ڏيکاريل ڊيٽا کي ايڊٽ ڪرڻ (ماسڪنگ) تڏهن ٿيندو آهي جڏهن استعمال ڪندڙ ٽيبل جي هڪ ڪالمن ۾ يا ته ڊيٽا يا صرف ستاري ڏسندا آهن، يعني ڪجهه صارفين لاءِ معلومات بند ڪئي ويندي. ٽيڪنالاجي اهو طئي ڪري ٿو ته ڪهڙو صارف ڏيکاريو ويو آهي انهن جي رسائي جي سطح جي بنياد تي.
4. سيڪيورٽي DBA/ايپليڪيشن DBA/DBA رسائي ڪنٽرول آهي، بلڪه، DBMS تائين رسائي کي محدود ڪرڻ جي باري ۾، اهو آهي، معلومات سيڪيورٽي ملازمن کي ڊيٽابيس جي منتظمين ۽ ايپليڪيشن ايڊمنسٽريٽرن کان الڳ ڪري سگهجي ٿو. اوپن سورس ۾ ڪجھه اهڙيون ٽيڪنالاجيون آهن، پر تجارتي ڊي بي ايم ايس ۾ انهن مان ڪافي آهن. انهن جي ضرورت آهي جڏهن اتي ڪيترائي صارف آهن جن وٽ سرور تائين رسائي آهي.
5. فائل سسٽم جي سطح تي فائلن تائين رسائي کي محدود ڪرڻ. توھان حق ڏئي سگھو ٿا ۽ ڊاريڪٽري تائين رسائي جا مراعات ڏئي سگھو ٿا ته جيئن ھر منتظم کي صرف ضروري ڊيٽا تائين رسائي حاصل ٿئي.
6. لازمي رسائي ۽ ميموري صاف ڪرڻ - اهي ٽيڪنالاجيون گهٽ ۾ گهٽ استعمال ڪيا ويا آهن.
7. DBMS کان سڌي طرح آخر کان آخر تائين انڪرپشن ڪلائنٽ-سائڊ انڪرپشن آهي سرور جي پاسي تي اهم انتظام سان.
8. ڊيٽا انڪريشن. مثال طور، ڪالمن انڪرپشن اهو آهي جڏهن توهان هڪ ميکانيزم استعمال ڪندا آهيو جيڪو ڊيٽابيس جي هڪ ڪالمن کي انڪرپٽ ڪري ٿو.

اهو ڪيئن اثر انداز ڪري ٿو DBMS جي ڪارڪردگي؟

اچو ته ڏسو 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 (Decrypt)

نموني 1000 قطارون
1,386 MS
50,203 MS

سي پي يو
15٪
35٪

رام
 
+ 5٪

انڪرپشن جو ڪارڪردگي تي وڏو اثر آھي. اهو ڏسي سگهجي ٿو ته وقت وڌي ويو آهي، ڇو ته انڪريپٽ ٿيل ڊيٽا جي ڊيڪرپشن آپريشنز (۽ ڊيڪرپشن عام طور تي اڃا تائين توهان جي منطق ۾ لپي وئي آهي) اهم وسيلن جي ضرورت آهي. اهو آهي، ڪجهه ڊيٽا تي مشتمل سڀني ڪالمن کي انڪرپٽ ڪرڻ جو خيال ڪارڪردگي ۾ گهٽتائي سان ڀريل آهي.

بهرحال، انڪرپشن هڪ سلور بلٽ ناهي جيڪو سڀني مسئلن کي حل ڪري ٿو. ڊيٽا کي ڊريپ ڪرڻ ۽ منتقل ڪرڻ جي عمل دوران ڊڪرپٽ ٿيل ڊيٽا ۽ ڊيڪرپشن چيڪ سرور تي واقع آهن. تنهن ڪري، چابيون ڪنهن ماڻهو طرفان مداخلت ڪري سگهجن ٿيون جنهن وٽ ڊيٽابيس سرور تائين مڪمل رسائي آهي، جهڙوڪ سسٽم منتظم.

جڏهن سڀني استعمال ڪندڙن لاءِ پوري ڪالمن لاءِ هڪ ڪنجي آهي (جيتوڻيڪ سڀني لاءِ نه، پر هڪ محدود سيٽ جي گراهڪن لاءِ)، اهو هميشه سٺو ۽ درست ناهي. اهو ئي سبب آهي ته انهن آخر کان آخر تائين انڪرپشن ڪرڻ شروع ڪيو، ڊي بي ايم ايس ۾ انهن ڪلائنٽ ۽ سرور سائڊ تي ڊيٽا انڪرپٽ ڪرڻ جي اختيارن تي غور ڪرڻ شروع ڪيو، ۽ اهي ساڳيون ڪيئي والٽ اسٽوريج ظاهر ٿيا - الڳ پروڊڪٽس جيڪي ڊي بي ايم ايس تي اهم انتظام مهيا ڪن ٿيون. طرف.

MongoDB ۾ اهڙي انڪرپشن جو هڪ مثال

سيڪيورٽي خاصيتون تجارتي ۽ اوپن سورس DBMS ۾

ڪارڪن
قسم
پاسورڊ پاليسي
آڊيٽ
طريقيڪار ۽ افعال جي ماخذ ڪوڊ جي حفاظت
آر ايل
بچاء ڪوڊنگ

Oracle
تجارتي
+
+
+
+
+

MsSql
تجارتي
+
+
+
+
+

جتوبا
تجارتي
+
+
+
+
ملان

PostgreSQL
واندو
ملان
ملان
-
+
ملان

مونگو ڊي بي
واندو
-
+
-
-
صرف MongoDB انٽرپرائز ۾ موجود آهي

ٽيبل مڪمل ٿيڻ کان پري آهي، پر صورتحال هي آهي: تجارتي شين ۾، سيڪيورٽي مسئلا هڪ ڊگهي وقت تائين حل ڪيا ويا آهن، اوپن سورس ۾، ضابطي جي طور تي، سيڪيورٽي لاء ڪجهه قسم جا اضافو استعمال ڪيا ويا آهن، ڪيترائي افعال غائب آهن. ، ڪڏهن ڪڏهن توهان کي ڪجهه شامل ڪرڻو پوندو. مثال طور، پاسورڊ پاليسيون - PostgreSQL ۾ ڪيتريون ئي مختلف واڌايون آهن (1, 2, 3, 4, 5)، جيڪي پاسورڊ پاليسين تي عمل ڪندا آهن، پر، منهنجي خيال ۾، انهن مان ڪو به گهريلو ڪارپوريٽ سيڪشن جي سڀني ضرورتن کي پورو نٿو ڪري.

ڇا ڪجي جيڪڏهن توهان وٽ نه هجي جيڪا توهان کي ڪٿي به گهربل هجي؟ مثال طور، توهان هڪ مخصوص DBMS استعمال ڪرڻ چاهيو ٿا جنهن ۾ اهي ڪم نه آهن جيڪي ڪسٽمر کي گهربل آهن.

پوءِ توھان استعمال ڪري سگھو ٿا ٽئين پارٽي حل جيڪي ڪم ڪن مختلف DBMSs سان، مثال طور، Crypto DB يا Garda DB. جيڪڏهن اسان گهريلو ڀاڱي مان حل جي باري ۾ ڳالهائي رهيا آهيون، پوء اهي GOSTs جي باري ۾ ڄاڻن ٿا ڀلي کليل ذريعو کان.

ٻيو اختيار اهو آهي ته جيڪو توهان کي گهربل هجي اهو لکو، پروسيس جي سطح تي ايپليڪيشن ۾ ڊيٽا جي رسائي ۽ انڪرپشن کي لاڳو ڪريو. سچ، اهو GOST سان وڌيڪ ڏکيو ٿيندو. پر عام طور تي، توھان ضرورت مطابق ڊيٽا کي لڪائي سگھوٿا، ان کي ڊي بي ايم ايس ۾ وجھو، پوءِ ان کي ٻيهر حاصل ڪريو ۽ ضرورت جي مطابق ان کي ڊريڪٽ ڪريو، ساڄي ايپليڪيشن جي سطح تي. ساڳئي وقت، فوري طور تي سوچيو ته توهان ايپليڪيشن ۾ انهن الگورتھم کي ڪيئن بچائيندا. اسان جي راء ۾، اهو ٿيڻ گهرجي DBMS سطح تي، ڇاڪاڻ ته اهو تيزيء سان ڪم ڪندو.

هي رپورٽ پهريون ڀيرو پيش ڪئي وئي @Databases Meetup طرفان Mail.ru Cloud Solutions. ڏس видео ٻين پرفارمنس ۽ ٽيليگرام تي واقعن جي اعلانن جي رڪنيت حاصل ڪريو Mail.ru گروپ تي ڪبرنيٽس جي چوڌاري.

موضوع تي ٻيو ڇا پڙهو:

1. Ceph کان وڌيڪ: MCS ڪلائوڊ بلاڪ اسٽوريج.
2. هڪ منصوبي لاءِ ڊيٽابيس ڪيئن چونڊيو ته جيئن توهان کي ٻيهر چونڊڻ جي ضرورت ناهي.

جو ذريعو: www.habr.com