میرا نام ڈینس روزکوف ہے، میں پروڈکٹ ٹیم میں Gazinformservice کمپنی میں سافٹ ویئر ڈویلپمنٹ کا سربراہ ہوں جتوبہ. قانون سازی اور کارپوریٹ ضوابط ڈیٹا اسٹوریج کی حفاظت کے لیے کچھ تقاضے عائد کرتے ہیں۔ کوئی بھی نہیں چاہتا کہ فریق ثالث کو خفیہ معلومات تک رسائی حاصل ہو، اس لیے کسی بھی پروجیکٹ کے لیے درج ذیل امور اہم ہیں: شناخت اور تصدیق، ڈیٹا تک رسائی کا انتظام، سسٹم میں معلومات کی سالمیت کو یقینی بنانا، سیکیورٹی ایونٹس کو لاگ ان کرنا۔ لہذا، میں DBMS سیکورٹی کے حوالے سے کچھ دلچسپ نکات کے بارے میں بات کرنا چاہتا ہوں۔

یہ مضمون ایک تقریر کی بنیاد پر تیار کیا گیا تھا۔ @DatabasesMeetup، منظم Mail.ru کلاؤڈ سلوشنز. اگر آپ پڑھنا نہیں چاہتے تو آپ دیکھ سکتے ہیں:

مضمون کے تین حصے ہوں گے:

• کنکشن کو محفوظ کرنے کا طریقہ۔
• اعمال کا آڈٹ کیا ہے اور ڈیٹا بیس کی طرف جو کچھ ہو رہا ہے اور اس سے منسلک ہو رہا ہے اسے کیسے ریکارڈ کرنا ہے۔
• ڈیٹا بیس میں ڈیٹا کو کیسے محفوظ کیا جائے اور اس کے لیے کون سی ٹیکنالوجیز دستیاب ہیں۔

DBMS سیکورٹی کے تین اجزاء: کنکشن پروٹیکشن، ایکٹیویٹی آڈیٹنگ اور ڈیٹا پروٹیکشن

اپنے رابطوں کو محفوظ بنانا

آپ ویب ایپلیکیشنز کے ذریعے براہ راست یا بالواسطہ طور پر ڈیٹا بیس سے جڑ سکتے ہیں۔ ایک اصول کے طور پر، کاروباری صارف، یعنی وہ شخص جو DBMS کے ساتھ کام کرتا ہے، اس کے ساتھ بالواسطہ بات چیت کرتا ہے۔

کنکشن کی حفاظت کے بارے میں بات کرنے سے پہلے، آپ کو ان اہم سوالات کے جوابات دینے کی ضرورت ہے جو اس بات کا تعین کرتے ہیں کہ حفاظتی اقدامات کیسے بنائے جائیں گے:

• کیا ایک کاروباری صارف ایک DBMS صارف کے برابر ہے؟
• چاہے DBMS ڈیٹا تک رسائی صرف ایک API کے ذریعے فراہم کی جائے جسے آپ کنٹرول کرتے ہیں، یا آیا ٹیبلز تک براہ راست رسائی حاصل کی جاتی ہے۔
• آیا DBMS کو ایک علیحدہ محفوظ طبقہ کے لیے مختص کیا گیا ہے، کون اس کے ساتھ تعامل کرتا ہے اور کیسے؛
• چاہے پولنگ/پراکسی اور انٹرمیڈیٹ پرتیں استعمال کی جائیں، جو اس بارے میں معلومات کو تبدیل کر سکتی ہیں کہ کنکشن کیسے بنایا گیا ہے اور کون ڈیٹا بیس استعمال کر رہا ہے۔

اب دیکھتے ہیں کنکشنز کو محفوظ بنانے کے لیے کن ٹولز کا استعمال کیا جا سکتا ہے:

1. ڈیٹا بیس فائر وال کلاس حل استعمال کریں۔ تحفظ کی ایک اضافی تہہ، کم از کم، DBMS میں جو کچھ ہو رہا ہے اس کی شفافیت میں اضافہ کرے گا، اور زیادہ سے زیادہ، آپ اضافی ڈیٹا تحفظ فراہم کر سکیں گے۔
2. پاس ورڈ کی پالیسیاں استعمال کریں۔ ان کا استعمال اس بات پر منحصر ہے کہ آپ کا فن تعمیر کیسے بنایا گیا ہے۔ کسی بھی صورت میں، کسی ویب ایپلیکیشن کی کنفیگریشن فائل میں ایک پاس ورڈ جو DBMS سے جڑتا ہے تحفظ کے لیے کافی نہیں ہے۔ DBMS ٹولز کی ایک بڑی تعداد ہے جو آپ کو کنٹرول کرنے کی اجازت دیتی ہے کہ صارف اور پاس ورڈ کو اپ ڈیٹ کرنے کی ضرورت ہے۔

   آپ صارف کی درجہ بندی کے افعال کے بارے میں مزید پڑھ سکتے ہیں۔ یہاں، آپ MS SQL Vulnerability Assessmen کے بارے میں بھی جان سکتے ہیں۔ یہاں. 

3. ضروری معلومات کے ساتھ سیشن کے سیاق و سباق کو بہتر بنائیں۔ اگر سیشن مبہم ہے، تو آپ سمجھ نہیں پا رہے ہیں کہ DBMS میں کون اس کے فریم ورک کے اندر کام کر رہا ہے، آپ آپریشن کیے جانے کے فریم ورک کے اندر، اس بارے میں معلومات شامل کر سکتے ہیں کہ کون کیا کر رہا ہے اور کیوں۔ یہ معلومات آڈٹ میں دیکھی جا سکتی ہیں۔
4. اگر آپ کے پاس DBMS اور اختتامی صارفین کے درمیان نیٹ ورک کی علیحدگی نہیں ہے تو SSL کو ترتیب دیں؛ یہ علیحدہ VLAN میں نہیں ہے۔ ایسے معاملات میں، صارفین اور خود DBMS کے درمیان چینل کی حفاظت کرنا ضروری ہے۔ سیکیورٹی ٹولز اوپن سورس میں بھی دستیاب ہیں۔

یہ DBMS کی کارکردگی کو کیسے متاثر کرے گا؟

آئیے PostgreSQL کی مثال دیکھتے ہیں کہ کس طرح SSL CPU لوڈ کو متاثر کرتا ہے، اوقات میں اضافہ کرتا ہے اور TPS کو کم کرتا ہے، اور اگر آپ اسے فعال کرتے ہیں تو یہ بہت زیادہ وسائل استعمال کرے گا۔

پی جی بینچ کا استعمال کرتے ہوئے 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

امتحانی نتائج:

 
NO 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 تصدیقی موڈ کو فعال کرنے کو کہا۔ اس نے سی پی یو پر بہت زیادہ بوجھ ڈالا، اور کارکردگی گر گئی۔ ہم نے اصلاح کے طریقے تلاش کرنا شروع کر دیے۔ مسئلے کا ایک ممکنہ حل نیٹ ورک کی پابندیوں کو نافذ کرنا، DBMS کے لیے علیحدہ VLANs بنانا، یہ واضح کرنے کے لیے سیٹنگز شامل کرنا کہ کون کہاں سے جڑ رہا ہے اور تصدیق کو ہٹانا ہے۔ آپ تصدیق کو فعال کرتے وقت لاگت کو کم کرنے کے لیے توثیق کی ترتیبات کو بھی بہتر بنا سکتے ہیں، لیکن عام طور پر توثیق کے مختلف طریقوں کا استعمال کارکردگی کو متاثر کرتا ہے اور DBMS کے لیے سرورز (ہارڈ ویئر) کی کمپیوٹنگ پاور کو ڈیزائن کرتے وقت ان عوامل کو مدنظر رکھنا ضروری ہے۔

نتیجہ: متعدد حلوں میں، یہاں تک کہ توثیق میں چھوٹی باریکیاں بھی پروجیکٹ کو بہت زیادہ متاثر کر سکتی ہیں اور یہ اس وقت برا ہوتا ہے جب یہ صرف پیداوار میں لاگو ہونے پر ہی واضح ہوجاتا ہے۔

ایکشن آڈٹ

آڈٹ نہ صرف DBMS ہو سکتا ہے۔ ایک آڈٹ مختلف حصوں میں کیا ہو رہا ہے اس کے بارے میں معلومات حاصل کرنے کے بارے میں ہے۔ یہ یا تو ڈیٹا بیس فائر وال ہو سکتا ہے یا آپریٹنگ سسٹم جس پر DBMS بنایا گیا ہے۔

تجارتی انٹرپرائز لیول DBMSs میں آڈیٹنگ کے ساتھ سب کچھ ٹھیک ہے، لیکن اوپن سورس میں - ہمیشہ نہیں۔ PostgreSQL کے پاس یہ ہے:

• ڈیفالٹ لاگ - بلٹ ان لاگنگ؛
• extensions: pgaudit - اگر آپ کے لیے پہلے سے طے شدہ لاگنگ کافی نہیں ہے، تو آپ الگ سیٹنگز استعمال کر سکتے ہیں جو کچھ مسائل کو حل کرتی ہے۔

ویڈیو میں رپورٹ میں اضافہ:

"بنیادی بیان لاگنگ log_statement = all کے ساتھ معیاری لاگنگ کی سہولت کے ذریعہ فراہم کی جاسکتی ہے۔

یہ نگرانی اور دیگر استعمال کے لیے قابل قبول ہے، لیکن یہ تفصیل کی سطح فراہم نہیں کرتا ہے جو عام طور پر آڈیٹنگ کے لیے درکار ہے۔

ڈیٹا بیس پر کیے گئے تمام آپریشنز کی فہرست ہونا کافی نہیں ہے۔

ایسے مخصوص بیانات کو تلاش کرنا بھی ممکن ہونا چاہیے جو آڈیٹر کی دلچسپی کے ہوں۔

معیاری لاگنگ ظاہر کرتی ہے کہ صارف نے کیا درخواست کی ہے، جبکہ pgAudit اس بات کی تفصیلات پر توجہ مرکوز کرتا ہے کہ جب ڈیٹا بیس نے استفسار کیا تو کیا ہوا۔

مثال کے طور پر، آڈیٹر اس بات کی تصدیق کرنا چاہتا ہے کہ ایک مخصوص ٹیبل ایک دستاویزی بحالی ونڈو کے اندر بنایا گیا تھا۔

یہ بنیادی آڈیٹنگ اور گریپ کے ساتھ ایک آسان کام کی طرح لگتا ہے، لیکن کیا ہوگا اگر آپ کو اس طرح کی (جان بوجھ کر مبہم) مثال پیش کی جائے:

کرو$$
براہ مہربانی دوبارہ کوشش کریں
'ٹیبل امپورٹ بنائیں' پر عمل کریں۔ 'ant_table(id int)'؛
END$$؛

معیاری لاگنگ آپ کو یہ دے گا:

LOG: بیان: DO $$
براہ مہربانی دوبارہ کوشش کریں
'ٹیبل امپورٹ بنائیں' پر عمل کریں۔ 'ant_table(id int)'؛
END$$؛

ایسا معلوم ہوتا ہے کہ دلچسپی کے جدول کو تلاش کرنے کے لیے کچھ کوڈ کے علم کی ضرورت ہو سکتی ہے ان صورتوں میں جہاں میزیں متحرک طور پر بنائی جاتی ہیں۔

یہ مثالی نہیں ہے، کیونکہ یہ صرف ٹیبل کے نام سے تلاش کرنا بہتر ہوگا۔

یہ وہ جگہ ہے جہاں pgAudit کام آتا ہے۔

اسی ان پٹ کے لیے، یہ لاگ میں یہ آؤٹ پٹ تیار کرے گا:

آڈٹ: سیشن، 33,1، فنکشن، کرو،،،" $$ کرو
براہ مہربانی دوبارہ کوشش کریں
'ٹیبل امپورٹ بنائیں' پر عمل کریں۔ 'ant_table(id int)'؛
END$$;"
آڈٹ: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)

نہ صرف DO بلاک لاگ کیا گیا ہے، بلکہ CREATE TABLE کا مکمل متن بھی بیان کی قسم، آبجیکٹ کی قسم، اور مکمل نام کے ساتھ، تلاش کرنا آسان بناتا ہے۔

SELECT اور DML سٹیٹمنٹس کو لاگ کرتے وقت، pgAudit کو بیان میں حوالہ دیا گیا ہر تعلق کے لیے الگ اندراج لاگ کرنے کے لیے کنفیگر کیا جا سکتا ہے۔

کسی خاص ٹیبل کو چھونے والے تمام بیانات کو تلاش کرنے کے لیے کسی تجزیہ کی ضرورت نہیں ہے۔*) ».

یہ DBMS کی کارکردگی کو کیسے متاثر کرے گا؟

آئیے مکمل آڈیٹنگ کے ساتھ ٹیسٹ چلائیں اور دیکھیں کہ PostgreSQL کارکردگی کا کیا ہوتا ہے۔ آئیے تمام پیرامیٹرز کے لیے زیادہ سے زیادہ ڈیٹا بیس لاگنگ کو فعال کریں۔

ہم کنفیگریشن فائل میں تقریباً کچھ بھی نہیں بدلتے، سب سے اہم چیز زیادہ سے زیادہ معلومات حاصل کرنے کے لیے ڈیبگ 5 موڈ کو آن کرنا ہے۔

postgresql.conf

log_destination = 'stderr'
لاگنگ_کلیکٹر = آن
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_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 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 سیکنڈ
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 ایم ایس

سائز کے بارے میں

ڈی بی سائز
2251 MB
2262 MB

ڈیٹا بیس لاگ سائز
0 MB
4587 MB

پایان لائن: مکمل آڈٹ بہت اچھا نہیں ہے۔ آڈٹ کا ڈیٹا اتنا ہی بڑا ہوگا جتنا کہ ڈیٹا بیس میں موجود ڈیٹا، یا اس سے بھی زیادہ۔ لاگنگ کی مقدار جو DBMS کے ساتھ کام کرتے وقت پیدا ہوتی ہے پیداوار میں ایک عام مسئلہ ہے۔

آئیے دوسرے پیرامیٹرز کو دیکھیں:

• رفتار زیادہ تبدیل نہیں ہوتی: لاگنگ کے بغیر - 43,74 سیکنڈ، لاگنگ کے ساتھ - 53,23 سیکنڈ۔
• RAM اور CPU کی کارکردگی متاثر ہوگی، کیونکہ آپ کو ایک آڈٹ فائل بنانے کی ضرورت ہے۔ یہ پیداواری صلاحیت میں بھی نمایاں ہے۔

جیسے جیسے کنکشنز کی تعداد میں اضافہ ہوتا ہے، قدرتی طور پر، کارکردگی قدرے خراب ہوتی جائے گی۔

آڈٹ کے ساتھ کارپوریشنوں میں یہ اور بھی مشکل ہے:

• ڈیٹا کی ایک بہت ہے؛
• آڈیٹنگ کی ضرورت نہ صرف SIEM میں syslog کے ذریعے ہوتی ہے، بلکہ فائلوں میں بھی ہوتی ہے: اگر syslog کو کچھ ہوتا ہے، تو ڈیٹا بیس کے قریب ایک فائل ہونی چاہیے جس میں ڈیٹا محفوظ کیا جاتا ہے۔
• آڈیٹنگ کے لیے ایک علیحدہ شیلف کی ضرورت ہے تاکہ I/O ڈسکوں کو ضائع نہ کیا جائے، کیونکہ یہ کافی جگہ لیتی ہے۔
• ایسا ہوتا ہے کہ انفارمیشن سیکیورٹی ملازمین کو ہر جگہ GOST معیارات کی ضرورت ہوتی ہے، انہیں ریاست کی شناخت کی ضرورت ہوتی ہے۔

ڈیٹا تک رسائی کو محدود کرنا

آئیے ان ٹیکنالوجیز کو دیکھتے ہیں جو ڈیٹا کی حفاظت اور تجارتی DBMSs اور اوپن سورس میں اس تک رسائی کے لیے استعمال ہوتی ہیں۔

آپ عام طور پر کیا استعمال کرسکتے ہیں:

1. طریقہ کار اور افعال کی خفیہ کاری اور مبہم ہونا (ریپنگ) - یعنی الگ الگ ٹولز اور یوٹیلیٹیز جو پڑھنے کے قابل کوڈ کو ناقابل تلافی بناتے ہیں۔ سچ ہے، پھر اسے نہ تو تبدیل کیا جا سکتا ہے اور نہ ہی اسے دوبارہ بنایا جا سکتا ہے۔ کبھی کبھی کم از کم DBMS کی طرف اس نقطہ نظر کی ضرورت ہوتی ہے - لائسنس کی پابندیوں کی منطق یا اجازت کی منطق کو طریقہ کار اور فنکشن کی سطح پر ٹھیک ٹھیک انکرپٹ کیا جاتا ہے۔
2. قطاروں (RLS) کے ذریعے ڈیٹا کی مرئیت کو محدود کرنا اس وقت ہوتا ہے جب مختلف صارفین ایک ٹیبل دیکھتے ہیں، لیکن اس میں قطاروں کی ایک مختلف ساخت، یعنی قطار کی سطح پر کسی کو کچھ نہیں دکھایا جا سکتا۔
3. ظاہر کردہ ڈیٹا میں ترمیم (ماسکنگ) اس وقت ہوتی ہے جب ٹیبل کے ایک کالم میں صارفین یا تو ڈیٹا یا صرف ستارے دیکھتے ہیں، یعنی کچھ صارفین کے لیے معلومات بند کر دی جاتی ہیں۔ ٹیکنالوجی اس بات کا تعین کرتی ہے کہ کس صارف کو ان کی رسائی کی سطح کی بنیاد پر کیا دکھایا گیا ہے۔
4. سیکورٹی DBA/Application DBA/DBA رسائی کنٹرول، بلکہ، خود DBMS تک رسائی کو محدود کرنے کے بارے میں ہے، یعنی معلومات کے تحفظ کے ملازمین کو ڈیٹا بیس کے منتظمین اور ایپلیکیشن ایڈمنسٹریٹرز سے الگ کیا جا سکتا ہے۔ اوپن سورس میں ایسی چند ٹیکنالوجیز ہیں، لیکن کمرشل ڈی بی ایم ایس میں ان کی کافی مقدار موجود ہے۔ ان کی ضرورت اس وقت ہوتی ہے جب بہت سے صارفین خود سرور تک رسائی رکھتے ہوں۔
5. فائل سسٹم کی سطح پر فائلوں تک رسائی کو محدود کرنا۔ آپ ڈائریکٹریز کو حقوق اور رسائی کے مراعات دے سکتے ہیں تاکہ ہر منتظم کو صرف ضروری ڈیٹا تک رسائی حاصل ہو۔
6. لازمی رسائی اور میموری صاف کرنا - یہ ٹیکنالوجیز شاذ و نادر ہی استعمال ہوتی ہیں۔
7. ڈی بی ایم ایس سے براہ راست اینڈ ٹو اینڈ انکرپشن کلائنٹ سائڈ انکرپشن ہے جس میں سرور سائیڈ پر کلیدی انتظام ہے۔
8. ڈیٹا کی خفیہ کاری۔ مثال کے طور پر، کالم انکرپشن اس وقت ہوتی ہے جب آپ ایک ایسا طریقہ کار استعمال کرتے ہیں جو ڈیٹا بیس کے ایک کالم کو انکرپٹ کرتا ہے۔

یہ 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 ms

انکرپشن فنکشن کے ساتھ ٹیبل سے انتخاب:

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

اسٹاپ واچ آن ہے۔

  آئی ڈی | ڈکرپٹ | ڈکرپٹ
——+——————+———
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 لائنیں)

وقت: 50,203 ms

امتحانی نتائج:

 
خفیہ کاری کے بغیر
پی جی کریپٹو (ڈیکرپٹ)

نمونہ 1000 قطاریں۔
1,386 ایم ایس
50,203 ایم ایس

CPU
15٪
35٪

رام
 
+ 5٪

خفیہ کاری کا کارکردگی پر بڑا اثر پڑتا ہے۔ یہ دیکھا جا سکتا ہے کہ ٹائمنگ بڑھ گئی ہے، کیونکہ انکرپٹڈ ڈیٹا کے ڈکرپشن آپریشنز (اور ڈکرپشن عام طور پر اب بھی آپ کی منطق میں لپیٹی جاتی ہے) کے لیے اہم وسائل کی ضرورت ہوتی ہے۔ یعنی، کچھ ڈیٹا پر مشتمل تمام کالموں کو خفیہ کرنے کا خیال کارکردگی میں کمی سے بھرا ہوا ہے۔

تاہم، خفیہ کاری چاندی کی گولی نہیں ہے جو تمام مسائل کو حل کرتی ہے۔ ڈیٹا کو ڈکرپٹ اور ٹرانسمٹ کرنے کے عمل کے دوران ڈکرپٹ شدہ ڈیٹا اور ڈیکرپشن کلید سرور پر موجود ہوتی ہے۔ لہذا، چابیاں کسی ایسے شخص کی طرف سے روکا جا سکتا ہے جسے ڈیٹا بیس سرور تک مکمل رسائی حاصل ہو، جیسے کہ سسٹم ایڈمنسٹریٹر۔

جب تمام صارفین کے لیے پورے کالم کے لیے ایک کلید ہو (چاہے سب کے لیے نہ ہو، لیکن ایک محدود سیٹ کے کلائنٹس کے لیے)، یہ ہمیشہ اچھا اور درست نہیں ہوتا۔ یہی وجہ ہے کہ انہوں نے اینڈ ٹو اینڈ انکرپشن کرنا شروع کیا، ڈی بی ایم ایس میں انہوں نے کلائنٹ اور سرور سائیڈ پر ڈیٹا کو انکرپٹ کرنے کے آپشنز پر غور کرنا شروع کیا، اور وہی کلیدی والٹ سٹوریج ظاہر ہوئے - علیحدہ مصنوعات جو ڈی بی ایم ایس پر کلیدی انتظام فراہم کرتی ہیں۔ طرف

MongoDB میں اس طرح کے خفیہ کاری کی ایک مثال

تجارتی اور اوپن سورس DBMS میں حفاظتی خصوصیات

افعال
قسم
پاس ورڈ کی پالیسی
آڈٹ
طریقہ کار اور افعال کے سورس کوڈ کی حفاظت کرنا
آر ایل ایس۔
خفیہ کاری

اوریکل
تجارتی
+
+
+
+
+

ایم ایس کیو ایل
تجارتی
+
+
+
+
+

جتوبہ
تجارتی
+
+
+
+
ملانے

PostgreSQL کی
مفت
ملانے
ملانے
-
+
ملانے

مونگو ڈی بی
مفت
-
+
-
-
صرف MongoDB انٹرپرائز میں دستیاب ہے۔

ٹیبل مکمل سے بہت دور ہے، لیکن صورت حال یہ ہے: تجارتی مصنوعات میں، سیکورٹی کے مسائل ایک طویل عرصے سے حل کیے گئے ہیں، اوپن سورس میں، ایک اصول کے طور پر، سیکیورٹی کے لیے کسی نہ کسی قسم کے ایڈونز استعمال کیے جاتے ہیں، بہت سے افعال غائب ہیں۔ ، کبھی کبھی آپ کو کچھ شامل کرنا پڑتا ہے۔ مثال کے طور پر، پاس ورڈ کی پالیسیاں - PostgreSQL میں بہت سے مختلف ایکسٹینشنز ہیں (1, 2, 3, 4, 5)، جو پاس ورڈ کی پالیسیاں نافذ کرتی ہیں، لیکن، میری رائے میں، ان میں سے کوئی بھی گھریلو کارپوریٹ طبقہ کی تمام ضروریات کو پورا نہیں کرتا ہے۔

اگر آپ کے پاس وہ چیز نہیں ہے جس کی آپ کو کہیں ضرورت ہے تو کیا کریں۔? مثال کے طور پر، آپ ایک مخصوص DBMS استعمال کرنا چاہتے ہیں جس میں وہ فنکشنز نہیں ہیں جن کی کسٹمر کو ضرورت ہے۔

پھر آپ فریق ثالث کے حل استعمال کر سکتے ہیں جو مختلف DBMSs کے ساتھ کام کرتے ہیں، مثال کے طور پر، Crypto DB یا Garda DB۔ اگر ہم گھریلو طبقہ کے حل کے بارے میں بات کر رہے ہیں، تو وہ GOSTs کے بارے میں اوپن سورس سے بہتر جانتے ہیں۔

دوسرا آپشن یہ ہے کہ آپ اپنی ضرورت کو خود لکھیں، طریقہ کار کی سطح پر ایپلی کیشن میں ڈیٹا تک رسائی اور انکرپشن کو لاگو کریں۔ سچ ہے، یہ GOST کے ساتھ زیادہ مشکل ہو جائے گا. لیکن عام طور پر، آپ ضرورت کے مطابق ڈیٹا کو چھپا سکتے ہیں، اسے DBMS میں ڈال سکتے ہیں، پھر اسے دوبارہ حاصل کر سکتے ہیں اور ضرورت کے مطابق درخواست کی سطح پر اسے ڈکرپٹ کر سکتے ہیں۔ اسی وقت، فوری طور پر سوچیں کہ آپ ایپلی کیشن میں ان الگورتھم کی حفاظت کیسے کریں گے۔ ہماری رائے میں، یہ DBMS کی سطح پر کیا جانا چاہئے، کیونکہ یہ تیزی سے کام کرے گا.

یہ رپورٹ سب سے پہلے پیش کی گئی۔ @Databases Meetup بذریعہ Mail.ru کلاؤڈ حل۔ دیکھو ویڈیو دیگر پرفارمنس اور ٹیلی گرام پر ایونٹ کے اعلانات کو سبسکرائب کریں۔ Mail.ru گروپ پر Kubernetes کے ارد گرد.

موضوع پر اور کیا پڑھنا ہے۔:

1. Ceph سے زیادہ: MCS کلاؤڈ بلاک اسٹوریج.
2. کسی پروجیکٹ کے لیے ڈیٹا بیس کا انتخاب کیسے کریں تاکہ آپ کو دوبارہ انتخاب نہ کرنا پڑے.

ماخذ: www.habr.com