کورس کے لیے نئے اندراج کے آغاز کی توقع میں ہم MySQL میں خفیہ کاری کے بارے میں مضامین کی ایک سیریز شائع کرتے رہتے ہیں۔
اس سلسلے کے پچھلے مضمون میں () ہم نے کلیدی والٹس کے بارے میں بات کی۔ اس آرٹیکل میں، ہم دیکھیں گے کہ ماسٹر کی کو کس طرح استعمال کیا جاتا ہے اور لفافے کی خفیہ کاری کے فوائد اور نقصانات پر بات کریں گے۔
لفافے کی خفیہ کاری کے پیچھے خیال یہ ہے کہ خفیہ کاری کے لیے استعمال ہونے والی چابیاں (ٹیبل اسپیس کیز) دوسری کلید (ماسٹر کی) کے ساتھ خفیہ کی جاتی ہیں۔ ٹیبل اسپیس کیز دراصل ڈیٹا کو خفیہ کرنے کے لیے استعمال ہوتی ہیں۔ گرافک طور پر اس کی نمائندگی اس طرح کی جا سکتی ہے:
ماسٹر کلید کیرنگ میں واقع ہے، اور ٹیبل اسپیس کیز انکرپٹڈ ٹیبل اسپیس ہیڈر میں ہیں (ٹیبل اسپیس کے صفحہ 0 پر)۔
اوپر کی تصویر میں:
-
ٹیبل A کو کلید 1 (کلید 1) کے ساتھ انکرپٹ کیا گیا ہے۔ کلید 1 کو ماسٹر کی کا استعمال کرتے ہوئے انکرپٹ کیا جاتا ہے اور ٹیبل A کے ہیڈر میں انکرپٹڈ اسٹور کیا جاتا ہے۔
-
ٹیبل B کو کلید 2 کے ساتھ انکرپٹ کیا گیا ہے۔ کلید 2 کو ماسٹر کی (ماکر کی) کا استعمال کرتے ہوئے انکرپٹ کیا جاتا ہے اور ٹیبل B کے ہیڈر میں انکرپٹڈ اسٹور کیا جاتا ہے۔
-
اور اسی طرح کی.
جب سرور کو ٹیبل A کو ڈکرپٹ کرنے کی ضرورت ہوتی ہے، تو یہ سٹوریج سے ماسٹر کی بازیافت کرتا ہے، ٹیبل A کے ہیڈر سے انکرپٹ شدہ کلید 1 کو پڑھتا ہے، اور کلید 1 کو ڈکرپٹ کرتا ہے۔ ڈکرپٹ شدہ کلید 1 سرور کی میموری میں کیش ہوتی ہے اور اسے ٹیبل A کو ڈکرپٹ کرنے کے لیے استعمال کیا جاتا ہے۔ .
InnoDB
InnoDB میں، اصل انکرپشن اور ڈکرپشن I/O پرت پر کیا جاتا ہے۔ یعنی صفحہ کو ڈسک پر فلش کرنے سے پہلے ہی انکرپٹ کیا جاتا ہے اور ڈسک سے پڑھنے کے فوراً بعد ڈکرپٹ ہوجاتا ہے۔
InnoDB میں، خفیہ کاری صرف ٹیبل اسپیس کی سطح پر کام کرتی ہے۔ اور پہلے سے طے شدہ طور پر، تمام میزیں الگ الگ ٹیبل اسپیس میں بنائی جاتی ہیں ()۔ دوسرے الفاظ میں، ایک ٹیبل اسپیس بنائی گئی ہے جس میں صرف ایک ٹیبل ہو سکتا ہے۔ اگرچہ آپ مین ٹیبل اسپیس میں بھی ٹیبل بنا سکتے ہیں ()۔ لیکن کسی بھی صورت میں، میز ہمیشہ کچھ ٹیبل اسپیس میں واقع ہے. اور چونکہ خفیہ کاری ٹیبل اسپیس کی سطح پر کی جاتی ہے، اس لیے یہ یا تو مکمل طور پر انکرپٹڈ ہے یا ایسا نہیں ہے۔ یعنی، میز کے صرف ایک حصے کو مرکزی میز کی جگہ پر خفیہ کرنا ناممکن ہے۔
اگر کسی وجہ سے آپ نے فائل فی ٹیبل کو غیر فعال کردیا ہے، تو تمام ٹیبل سسٹم ٹیبل اسپیس کے اندر بنائے جاتے ہیں۔ میں آپ innodb متغیر کا استعمال کرتے ہوئے سسٹم ٹیبل اسپیس کو انکرپٹ کرسکتے ہیں۔sysمیز کی جگہانکرپٹ کریں یا انکرپشن تھریڈز کا استعمال کریں، لیکن یہ اب بھی ایک تجرباتی خصوصیت ہے۔ MySQL کے پاس یہ نہیں ہے۔
اس سے پہلے کہ ہم آگے بڑھیں، ہمیں ماسٹر کلید ID کی ساخت کو دیکھنے کی ضرورت ہے۔ یہ UUID، KEY پر مشتمل ہے۔ID اور سابقہ "INNODBKey"۔ یہ اس طرح لگتا ہے: INNODBKey-UUID-KEYID
UUID انکرپٹڈ ٹیبل اسپیس والے سرور کا uuid ہے۔ چابیID محض ایک مسلسل بڑھتی ہوئی قدر ہے۔ پہلی بار ماسٹر کلید KEY بناتے وقتID 1 ہے۔ کلید کی گردش کے دوران، جب ایک نئی ماسٹر کلید بنتی ہے، KEYID = 2 وغیرہ۔ ہم اس سیریز کے اگلے مضامین میں ماسٹر کلید کی گردش کے بارے میں مزید بات کریں گے۔
اب جب کہ ہم جانتے ہیں کہ ایک ماسٹر کلید شناخت کنندہ کیسا لگتا ہے، آئیے انکرپٹڈ ٹیبل اسپیس ہیڈر کو دیکھتے ہیں۔ جب ٹیبل اسپیس کو انکرپٹ کیا جاتا ہے تو ہیڈر میں خفیہ کاری کی معلومات شامل کی جاتی ہیں۔ ایسا لگتا ہے:
KEY ID کلیدی ہے۔ماسٹر کلید ID سے ID جس پر ہم پہلے ہی بات کر چکے ہیں۔ UUID سرور کا uuid ہے، جو ماسٹر کلید شناخت کنندہ میں بھی استعمال ہوتا ہے۔ ٹیبل اسپیس کلید - ایک ٹیبل اسپیس کلید، جو سرور کے ذریعہ تصادفی طور پر تیار کردہ 256 بٹس پر مشتمل ہوتی ہے۔ ابتداء ویکٹر (IV) بھی 256 تصادفی طور پر تیار کردہ بٹس پر مشتمل ہوتا ہے (حالانکہ یہ 128 بٹس ہونا چاہئے)۔ IV کا استعمال AES انکرپشن اور ڈکرپشن کو شروع کرنے کے لیے کیا جاتا ہے (256 بٹس میں سے صرف 128 استعمال ہوتے ہیں)۔ آخر میں ٹیبل اسپیس کلید اور IV کے لیے ایک CRC32 چیکسم ہے۔
اس سارے عرصے میں میں یہ کہہ کر تھوڑا سا آسان کر رہا تھا کہ ہیڈر میں ٹیبل اسپیس کی انکرپٹڈ کلید موجود ہے۔ درحقیقت، ٹیبل اسپیس کلید اور انیشیلائزیشن ویکٹر کو ماسٹر کی کا استعمال کرتے ہوئے ایک ساتھ اسٹور اور انکرپٹ کیا جاتا ہے۔ یاد رکھیں کہ ٹیبل اسپیس کلید اور انیشیلائزیشن ویکٹر کو انکرپٹ کرنے سے پہلے، ان کے لیے ایک CRC32 کا حساب لگایا جاتا ہے۔
CRC32 کی ضرورت کیوں ہے؟
مختصر طور پر، ماسٹر کلید کی درستگی کو یقینی بنانے کے لیے۔ ٹیبل اسپیس کلید اور انیشیلائزیشن ویکٹر کو ڈکرپٹ کرنے کے بعد، چیکسم کا حساب لگایا جاتا ہے اور ہیڈر میں محفوظ CRC32 کے ساتھ موازنہ کیا جاتا ہے۔ اگر چیکسم مماثل ہیں، تو ہمارے پاس درست ماسٹر کلید اور ٹیبل اسپیس کی ہے۔ بصورت دیگر، ٹیبل اسپیس کو غائب کے طور پر نشان زد کیا گیا ہے (ہم بہرحال اسے ڈکرپٹ نہیں کر سکیں گے)۔
آپ پوچھ سکتے ہیں: کلیدی تصدیق کس وقت کی جاتی ہے؟ جواب تب آتا ہے جب سرور شروع ہوتا ہے۔ انکرپٹڈ ٹیبلز/ٹیبل اسپیس والا سرور UUID، KEY کو اسٹارٹ اپ پر پڑھتا ہےہیڈر سے ID اور ماسٹر کلید ID تیار کرتا ہے۔ اس کے بعد یہ کیرنگ سے مطلوبہ ماسٹر کلید حاصل کرتا ہے، ٹیبل اسپیس کی کو ڈکرپٹ کرتا ہے، اور چیکسم کی تصدیق کرتا ہے۔ ایک بار پھر، اگر چیکسم مماثل ہے، تو سب کچھ ٹھیک ہے، اگر نہیں، تو ٹیبل اسپیس کو غائب کے طور پر نشان زد کیا گیا ہے۔
اگر آپ اس سلسلے کا پچھلا مضمون پڑھتے ہیں ()، پھر آپ کو یاد ہوگا کہ سرور پر مبنی کلیدی اسٹور کا استعمال کرتے وقت، سرور کو سٹارٹ اپ پر صرف کلیدی شناخت کنندگان کی فہرست ملتی ہے، یا اس کے بجائے، کلید کی شناخت اور صارف کی شناخت، کیونکہ یہ جوڑا منفرد طور پر کلید کی شناخت کرتا ہے۔ اب میں کہہ رہا ہوں کہ جب سرور شروع ہوتا ہے، تو اسے وہ تمام کلیدیں موصول ہوتی ہیں جن کی اسے جانچ کرنے کی ضرورت ہوتی ہے کہ یہ ٹیبل اسپیس کیز کو ڈکرپٹ کر سکتا ہے۔ تو کیوں شروع کے دوران، سرور اسٹوریج کی صورت میں، صرف کلید لوڈ کی جاتی ہے۔آئی ڈی اور صارفid، اور تمام چابیاں نہیں؟ کیونکہ آپ کو تمام چابیاں کی ضرورت نہیں ہوسکتی ہے۔ یہ بنیادی طور پر ماسٹر کلید کی گردش کی وجہ سے ہے۔ جب ایک ماسٹر کی کو گھمایا جاتا ہے، تو والٹ میں ایک نئی ماسٹر کی بن جاتی ہے، لیکن پرانی کیز کو حذف نہیں کیا جاتا ہے۔ اس طرح، آپ کے پاس سرور کی اسٹور میں بہت سی چابیاں ہوسکتی ہیں جن کی سرور کو ضرورت نہیں ہے اور اس وجہ سے جب سرور شروع ہوتا ہے تو بازیافت نہیں کیا جاتا ہے۔
یہ ماسٹر کلیدی خفیہ کاری کے فوائد اور نقصانات کے بارے میں تھوڑی بات کرنے کا وقت ہے۔ سب سے بڑا فائدہ یہ ہے کہ آپ کو صرف ایک انکرپشن کلید (ماسٹر کی) کی ضرورت ہے، جو آپ کے انکرپٹڈ ڈیٹا سے الگ اسٹور کی جائے گی۔ اس سے سرور کا آغاز تیز ہو جاتا ہے اور اسٹوریج چھوٹا ہو جاتا ہے، جس سے اسے منظم کرنا آسان ہو جاتا ہے۔ اور سنگل ماسٹر کلید کو دوبارہ تخلیق کرنا آسان ہے۔
تاہم، ماسٹر کلید کی خفیہ کاری میں ایک بڑی خرابی ہے: ایک بار ٹیبل اسپیس کو tablespace_key کے ساتھ انکرپٹ کیا جاتا ہے، یہ ہمیشہ اسی کلید کے ساتھ انکرپٹ ہوتا ہے۔ ماسٹر کلید کو گھمانے سے یہاں کوئی فائدہ نہیں ہوتا ہے۔ یہ ایک نقصان کیوں ہے؟ ہم جانتے ہیں کہ MySQL میں کیڑے ہیں جو اچانک کریش اور بنیادی فائل کی تخلیق کا باعث بن سکتے ہیں۔ چونکہ بنیادی فائل میں سرور میموری ڈمپ ہوتا ہے، یہ ہو سکتا ہے کہ ڈمپ میں ڈکرپٹ شدہ ٹیبل اسپیس کلید ہو۔ معاملات کو مزید خراب کرنے کے لیے، ڈکرپٹ شدہ ٹیبل اسپیس کیز میموری میں محفوظ کی جاتی ہیں، جنہیں ڈسک میں تبدیل کیا جا سکتا ہے۔ آپ کہہ سکتے ہیں کہ یہ کوئی نقصان نہیں ہے کیونکہ آپ کو ان فائلوں اور سویپ پارٹیشن تک رسائی کے لیے روٹ رائٹس کی ضرورت ہے۔ جی ہاں. لیکن جڑ صرف تھوڑی دیر کی ضرورت ہے. ایک بار جب کسی کو ڈکرپٹ شدہ ٹیبل اسپیس کلید تک رسائی حاصل ہو جاتی ہے، تو وہ اسے ڈیٹا کو ڈکرپٹ کرنے کے لیے استعمال کرنا جاری رکھ سکتا ہے، یہاں تک کہ روٹ مراعات کے بغیر۔ اس کے علاوہ، ڈسک چوری کی جا سکتی ہے، اور فریق ثالث کے ٹولز کا استعمال کرتے ہوئے سویپ پارٹیشن/کور فائلوں کو پڑھا جا سکتا ہے۔ ٹی ڈی ای کا مقصد ڈسک کے چوری ہونے کے باوجود اسے پڑھنے کے قابل نہیں بنانا ہے۔ میں نئی تیار کردہ چابیاں کے ساتھ میز کی جگہ کو دوبارہ خفیہ کرنا ممکن ہے۔ اس فیچر کو انکرپشن تھریڈز کہا جاتا ہے اور لکھنے کے وقت بھی یہ تجرباتی ہے۔
مزید پڑھ:
ماخذ: www.habr.com