کورس کے لیے نئے اندراج کے آغاز کی توقع میں ہم نے آپ کے لیے ایک مفید مضمون کا ترجمہ تیار کیا ہے۔
شفاف ڈیٹا انکرپشن (TDE) میں نمودار ہوا۔ اور MySQL کافی عرصے سے۔ لیکن کیا آپ نے کبھی سوچا ہے کہ یہ کس طرح کام کرتا ہے اور TDE کا آپ کے سرور پر کیا اثر پڑ سکتا ہے؟ مضامین کی اس سیریز میں ہم دیکھیں گے کہ TDE اندرونی طور پر کیسے کام کرتا ہے۔ آئیے کلیدی اسٹوریج کے ساتھ شروع کریں، کیونکہ کسی بھی خفیہ کاری کے کام کرنے کے لیے یہ ضروری ہے۔ اس کے بعد ہم اس بات کا بغور جائزہ لیں گے کہ MySQL/MySQL کے لیے Percona Server میں خفیہ کاری کیسے کام کرتی ہے اور MySQL کے لیے Percona سرور میں کیا اضافی خصوصیات ہیں۔
MySQL کیرنگ
کیرنگ پلگ ان ہیں جو سرور کو مقامی فائل (keyring_file) یا ریموٹ سرور (جیسے HashiCorp Vault) میں کیز کو استفسار کرنے، تخلیق کرنے اور حذف کرنے کی اجازت دیتے ہیں۔ ان کی بازیافت کو تیز کرنے کے لیے چابیاں ہمیشہ مقامی طور پر کیش کی جاتی ہیں۔
پلگ ان کو دو قسموں میں تقسیم کیا جا سکتا ہے:
- مقامی ذخیرہ. مثال کے طور پر، ایک مقامی فائل (ہم اسے فائل پر مبنی کیرنگ کہتے ہیں)۔
- ریموٹ اسٹوریج۔ مثال کے طور پر، والٹ سرور (ہم اسے سرور پر مبنی کیرنگ کہتے ہیں)۔
یہ علیحدگی اہم ہے کیونکہ اسٹوریج کی مختلف اقسام قدرے مختلف طریقے سے برتاؤ کرتی ہیں، نہ صرف چابیاں ذخیرہ کرنے اور بازیافت کرتے وقت، بلکہ انہیں چلاتے وقت بھی۔
فائل سٹوریج کا استعمال کرتے وقت، سٹارٹ اپ پر، سٹوریج کے پورے مواد کو کیشے میں لوڈ کر دیا جاتا ہے: کلیدی آئی ڈی، کلیدی صارف، کلید کی قسم، اور خود کلید۔
سرور سائیڈ اسٹور کی صورت میں (جیسے والٹ سرور)، صرف کلیدی آئی ڈی اور کلیدی صارف کو اسٹارٹ اپ پر لوڈ کیا جاتا ہے، لہذا تمام چابیاں حاصل کرنے سے اسٹارٹ اپ سست نہیں ہوتا ہے۔ چابیاں سستی سے بھری ہوئی ہیں۔ یعنی، کلید خود Vault سے اسی وقت لوڈ کی جاتی ہے جب اس کی اصل ضرورت ہو۔ ایک بار ڈاؤن لوڈ ہونے کے بعد، کلید کو میموری میں محفوظ کر لیا جاتا ہے تاکہ مستقبل میں والٹ سرور سے TLS کنکشن کے ذریعے اس تک رسائی کی ضرورت نہ ہو۔ اگلا، آئیے دیکھتے ہیں کہ کلیدی اسٹور میں کیا معلومات موجود ہیں۔
کلیدی معلومات میں درج ذیل شامل ہیں:
- کلیدی شناخت کلیدی شناخت کنندہ، مثال کے طور پر:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - کلیدی قسم - استعمال شدہ خفیہ کاری الگورتھم پر مبنی کلیدی قسم، ممکنہ اقدار: "AES"، "RSA" یا "DSA"۔
- اہم لمبائی - بائٹس میں کلیدی لمبائی، AES: 16، 24 یا 32، RSA 128، 256، 512 اور DSA 128، 256 یا 384۔
- صارف - چابی کا مالک۔ اگر کلید سسٹم ہے، مثال کے طور پر، ماسٹر کی، تو یہ فیلڈ خالی ہے۔ اگر keyring_udf کا استعمال کرتے ہوئے ایک کلید بنائی گئی ہے، تو یہ فیلڈ کلید کے مالک کی شناخت کرتی ہے۔
- کلید خود
کلید کی شناخت جوڑے کے ذریعہ منفرد طور پر کی جاتی ہے: key_id، صارف۔
چابیاں ذخیرہ کرنے اور حذف کرنے میں بھی فرق ہے۔
فائل اسٹوریج تیز تر ہے۔ آپ سوچ سکتے ہیں کہ کلیدی اسٹور صرف ایک بار فائل کی کلید لکھ رہا ہے، لیکن نہیں، یہاں اور بھی بہت کچھ ہو رہا ہے۔ جب بھی فائل اسٹوریج میں ترمیم کی جاتی ہے، سب سے پہلے تمام مواد کی بیک اپ کاپی بنائی جاتی ہے۔ فرض کریں کہ فائل کو my_biggest_secrets کہا جاتا ہے، پھر بیک اپ کاپی my_biggest_secrets.backup ہوگی۔ اس کے بعد، کیشے کو تبدیل کر دیا جاتا ہے (کیز کو شامل یا حذف کر دیا جاتا ہے) اور، اگر سب کچھ کامیاب ہو جاتا ہے تو، کیشے کو فائل میں ری سیٹ کر دیا جاتا ہے۔ غیر معمولی معاملات میں، جیسے کہ سرور کی خرابی، آپ کو یہ بیک اپ فائل نظر آ سکتی ہے۔ بیک اپ فائل اگلی بار جب چابیاں لوڈ ہوتی ہیں تو حذف ہوجاتی ہیں (عام طور پر سرور کے دوبارہ شروع ہونے کے بعد)۔
سرور سٹوریج میں کلید کو محفوظ کرتے یا حذف کرتے وقت، سٹوریج کو "کی بھیجیں" / "کی کو حذف کرنے کی درخواست" کے حکموں کے ساتھ MySQL سرور سے منسلک ہونا چاہیے۔
آئیے سرور کے آغاز کی رفتار پر واپس آتے ہیں۔ اس حقیقت کے علاوہ کہ لانچ کی رفتار والٹ ہی سے متاثر ہوتی ہے، یہ مسئلہ بھی ہے کہ اسٹارٹ اپ پر والٹ سے کتنی چابیاں حاصل کرنے کی ضرورت ہے۔ یقینا، یہ سرور اسٹوریج کے لئے خاص طور پر اہم ہے۔ سٹارٹ اپ پر، سرور چیک کرتا ہے کہ انکرپٹڈ ٹیبلز/ٹیبل اسپیسز کے لیے کون سی کلید درکار ہے اور اسٹوریج سے کلید کی درخواست کرتا ہے۔ ماسٹر کی انکرپشن والے "کلین" سرور پر، ایک ماسٹر کی ہونی چاہیے، جسے اسٹوریج سے بازیافت کرنا ضروری ہے۔ تاہم، بڑی تعداد میں چابیاں درکار ہو سکتی ہیں، مثال کے طور پر، جب بیک اپ سرور پرائمری سرور سے بیک اپ بحال کر رہا ہو۔ ایسی صورتوں میں، ماسٹر کی کی گردش فراہم کی جانی چاہیے۔ مستقبل کے مضامین میں اس کا مزید تفصیل سے احاطہ کیا جائے گا، اگرچہ یہاں میں یہ نوٹ کرنا چاہوں گا کہ ایک سے زیادہ ماسٹر کیز استعمال کرنے والے سرور کو شروع ہونے میں تھوڑا زیادہ وقت لگ سکتا ہے، خاص طور پر جب سرور کے سائیڈ کی اسٹور کا استعمال ہو۔
اب keyring_file کے بارے میں کچھ اور بات کرتے ہیں۔ جب میں keyring_file تیار کر رہا تھا، میں اس بارے میں بھی فکر مند تھا کہ سرور کے چلنے کے دوران keyring_file کی تبدیلیوں کی جانچ کیسے کی جائے۔ 5.7 میں، چیک فائل کے اعدادوشمار کی بنیاد پر کیا گیا، جو کہ ایک مثالی حل نہیں تھا، اور 8.0 میں اسے SHA256 چیکسم سے تبدیل کر دیا گیا۔
پہلی بار جب آپ keyring_file چلاتے ہیں، تو فائل کے اعداد و شمار اور ایک چیکسم کا حساب لگایا جاتا ہے، جو سرور کو یاد رہتا ہے، اور تبدیلیاں صرف اس صورت میں لاگو ہوتی ہیں جب وہ مماثل ہوں۔ جب فائل تبدیل ہوتی ہے، چیکسم اپ ڈیٹ ہوجاتا ہے۔
ہم پہلے ہی کلیدی والٹس کے بارے میں بہت سے سوالات کا احاطہ کر چکے ہیں۔ تاہم، ایک اور اہم موضوع ہے جو اکثر بھول جاتا ہے یا غلط سمجھا جاتا ہے: سرورز پر چابیاں بانٹنا۔
میرا مطلب ہے؟ کلسٹر میں ہر سرور (مثال کے طور پر، پرکونا سرور) کا والٹ سرور پر ایک الگ مقام ہونا ضروری ہے جس میں پرکونا سرور کو اپنی چابیاں ذخیرہ کرنا ضروری ہیں۔ اسٹوریج میں محفوظ کردہ ہر ماسٹر کلید اپنے شناخت کنندہ کے اندر پرکونا سرور کی GUID پر مشتمل ہوتی ہے۔ یہ کیوں ضروری ہے؟ تصور کریں کہ آپ کے پاس صرف ایک والٹ سرور ہے اور کلسٹر میں موجود تمام پرکونا سرور اس واحد والٹ سرور کو استعمال کرتے ہیں۔ مسئلہ واضح نظر آتا ہے۔ اگر تمام پرکونا سرورز منفرد شناخت کنندگان کے بغیر ماسٹر کلید استعمال کرتے ہیں، جیسے کہ id = 1، id = 2، وغیرہ، تو کلسٹر میں موجود تمام سرورز ایک ہی ماسٹر کلید استعمال کریں گے۔ GUID جو کچھ فراہم کرتا ہے وہ سرورز کے درمیان فرق ہے۔ اگر کوئی منفرد GUID پہلے سے موجود ہے تو پھر سرورز کے درمیان چابیاں بانٹنے کے بارے میں کیوں بات کریں؟ ایک اور پلگ ان ہے - keyring_udf. اس پلگ ان کے ساتھ، آپ کا سرور صارف والٹ سرور پر اپنی چابیاں محفوظ کر سکتا ہے۔ مسئلہ اس وقت ہوتا ہے جب صارف سرور 1 پر ایک کلید بناتا ہے، مثال کے طور پر، اور پھر سرور2 پر اسی ID کے ساتھ کلید بنانے کی کوشش کرتا ہے، مثال کے طور پر:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1انتظار کرو۔ دونوں سرور ایک ہی والٹ سرور استعمال کر رہے ہیں، کیا سرور2 پر keyring_key_store فنکشن کو ناکام نہیں ہونا چاہیے؟ دلچسپ بات یہ ہے کہ اگر آپ ایک سرور پر ایسا کرنے کی کوشش کرتے ہیں تو آپ کو ایک ایرر موصول ہوگا:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0یہ ٹھیک ہے، ROB_1 پہلے سے موجود ہے۔
آئیے پہلے دوسری مثال پر بات کرتے ہیں۔ جیسا کہ ہم نے پہلے کہا، keyring_vault یا کوئی اور کیرنگ پلگ ان تمام کلیدی IDs کو میموری میں محفوظ کرتا ہے۔ لہٰذا، ایک نئی کلید بنانے کے بعد، ROB_1 کو سرور1 میں شامل کیا جاتا ہے، اور اس کلید کو والٹ کو بھیجنے کے علاوہ، کلید کو کیش میں بھی شامل کیا جاتا ہے۔ اب، جب ہم ایک ہی کلید کو دوسری بار شامل کرنے کی کوشش کرتے ہیں، keyring_vault چیک کرتا ہے کہ آیا کیش میں موجود ہے اور ایک ایرر پھینک دیتا ہے۔
پہلی صورت میں صورت حال مختلف ہے. سرور 1 اور سرور 2 میں الگ الگ کیشز ہیں۔ سرور1 اور والٹ سرور پر کلیدی کیشے میں ROB_1 شامل کرنے کے بعد، سرور2 پر کلیدی کیش مطابقت پذیر نہیں ہے۔ سرور2 پر کیشے میں کوئی ROB_1 کلید نہیں ہے۔ اس طرح، ROB_1 کلید keyring_key_store اور Vault سرور پر لکھی جاتی ہے، جو دراصل پچھلی قدر کو اوور رائٹ کر دیتی ہے۔ اب والٹ سرور پر ROB_1 کلید 543210987654321 ہے۔ دلچسپ بات یہ ہے کہ والٹ سرور ایسی کارروائیوں کو بلاک نہیں کرتا اور پرانی قدر کو آسانی سے اوور رائٹ کر دیتا ہے۔
اب ہم دیکھ سکتے ہیں کہ والٹ میں سرور کی تقسیم کیوں اہم ہو سکتی ہے - جب آپ keyring_udf استعمال کر رہے ہیں اور والٹ میں چابیاں محفوظ کرنا چاہتے ہیں۔ والٹ سرور پر اس علیحدگی کو کیسے حاصل کیا جائے؟
والٹ میں تقسیم کرنے کے دو طریقے ہیں۔ آپ ہر سرور کے لیے مختلف ماؤنٹ پوائنٹس بنا سکتے ہیں، یا ایک ہی ماؤنٹ پوائنٹ کے اندر مختلف راستے استعمال کر سکتے ہیں۔ یہ مثالوں کے ساتھ بہترین طور پر بیان کیا گیا ہے۔ تو آئیے پہلے انفرادی ماؤنٹ پوائنٹس کو دیکھیں:
--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)یہاں آپ دیکھ سکتے ہیں کہ سرور1 اور سرور2 مختلف ماؤنٹ پوائنٹس استعمال کر رہے ہیں۔ راستوں کو تقسیم کرتے وقت، ترتیب اس طرح نظر آئے گی:
--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)اس صورت میں، دونوں سرور ایک ہی ماؤنٹ پوائنٹ "mount_point" استعمال کرتے ہیں، لیکن مختلف راستے۔ جب آپ اس راستے کا استعمال کرتے ہوئے سرور1 پر پہلا راز بناتے ہیں، تو والٹ سرور خود بخود ایک "سرور1" ڈائریکٹری بناتا ہے۔ سرور 2 کے لئے سب کچھ یکساں ہے۔ جب آپ mount_point/server1 یا mount_point/server2 میں آخری راز کو حذف کرتے ہیں، تو والٹ سرور ان ڈائریکٹریوں کو بھی حذف کر دیتا ہے۔ اگر آپ راستے کی علیحدگی کا استعمال کرتے ہیں، تو آپ کو صرف ایک ماؤنٹ پوائنٹ بنانا ہوگا اور کنفیگریشن فائلوں کو تبدیل کرنا ہوگا تاکہ سرور الگ راستے استعمال کریں۔ HTTP درخواست کا استعمال کرتے ہوئے ایک ماؤنٹ پوائنٹ بنایا جا سکتا ہے۔ CURL کا استعمال اس طرح کیا جا سکتا ہے:
curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTتمام فیلڈز (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) کنفیگریشن فائل کے پیرامیٹرز کے مطابق ہیں۔ بلاشبہ، آپ ایسا کرنے کے لیے والٹ یوٹیلیٹیز استعمال کر سکتے ہیں۔ لیکن ماؤنٹ پوائنٹ کی تخلیق کو خودکار کرنا آسان ہے۔ مجھے امید ہے کہ آپ کو یہ معلومات مفید معلوم ہوں گی اور ہم آپ کو اس سیریز کے اگلے مضامین میں دیکھیں گے۔
مزید پڑھ:
ماخذ: www.habr.com