MySQL ۾ انڪرپشن: ڪيسٽور

ڪورس لاءِ نئين داخلا جي شروعات جي توقع ۾ "ڊيٽابيس" اسان توهان لاءِ هڪ مفيد مضمون جو ترجمو تيار ڪيو آهي.

شفاف ڊيٽا انڪرپشن (TDE) ۾ ظاهر ٿيو MySQL لاءِ پرڪونا سرور ۽ MySQL ڪافي وقت لاءِ. پر ڇا توهان ڪڏهن سوچيو آهي ته اهو ڪيئن ڪم ڪري ٿو هود هيٺ ۽ توهان جي سرور تي TDE جو ڪهڙو اثر ٿي سگهي ٿو؟ مضمونن جي هن سلسلي ۾ اسين ڏسنداسين ته ڪيئن TDE اندروني طور ڪم ڪري ٿو. اچو ته ڪيئي اسٽوريج سان شروع ڪريون، ڇاڪاڻ ته اهو ڪم ڪرڻ لاءِ ڪنهن به انڪرپشن لاءِ گهربل آهي. پوءِ اسان هڪ ويجھو نظر وجهنداسين ته ڪيئن انڪريپشن ڪم ڪري ٿي Percona سرور for MySQL/MySQL ۽ ڪهڙيون اضافي خاصيتون آهن Percona سرور for MySQL.

MySQL ڪيئرنگ

ڪيئرنگ پلگ ان آهن جيڪي سرور کي مقامي فائل (keyring_file) يا ريموٽ سرور (جهڙوڪ HashiCorp Vault) ۾ ڪيز پڇڻ، ٺاهڻ ۽ حذف ڪرڻ جي اجازت ڏين ٿيون. ڪنجيون هميشه مقامي طور تي محفوظ ڪيون وينديون آهن انهن جي واپسي کي تيز ڪرڻ لاءِ.

پلگ ان کي ٻن ڀاڱن ۾ ورهائي سگھجي ٿو:

• مقامي اسٽوريج. مثال طور، هڪ مقامي فائل (اسان هن کي فائيل تي ٻڌل ڪيئرنگ سڏين ٿا).
• ريموٽ اسٽوريج. مثال طور، والٽ سرور (اسان هن کي سرور تي ٻڌل ڪيئرنگ سڏين ٿا).

هي علحدگيءَ اهم آهي ڇاڪاڻ ته اسٽوريج جا مختلف قسم ٿورو مختلف طريقي سان هلندا آهن، نه صرف ڪنجيون محفوظ ڪرڻ ۽ ٻيهر حاصل ڪرڻ وقت، پر انهن کي هلائڻ وقت پڻ.

جڏهن فائل اسٽوريج استعمال ڪندي، شروع ٿيڻ تي، اسٽوريج جو سمورو مواد ڪيش ۾ لوڊ ڪيو ويندو آهي: ڪي id، ڪيئي استعمال ڪندڙ، ڪيئي قسم، ۽ ڪي پاڻ.

سرور-سائڊ اسٽور جي صورت ۾ (جهڙوڪ والٽ سرور)، صرف ڪيئي آئي ڊي ۽ ڪيئي استعمال ڪندڙ شروع ٿيڻ تي لوڊ ڪيا ويندا آهن، تنهنڪري سڀئي چابيون حاصل ڪرڻ شروع ڪرڻ کي سست نه ڪندو آهي. چابيون سستي سان لوڊ ڪيون ويون آهن. اھو آھي، چاٻي پاڻ کي صرف Vault مان لوڊ ڪيو ويندو آھي جڏھن اھو اصل ۾ گھربل آھي. هڪ دفعو ڊائون لوڊ ٿيڻ بعد، ڪيچي کي ميموري ۾ محفوظ ڪيو ويندو آهي ته جيئن ان کي مستقبل ۾ والٽ سرور تائين TLS ڪنيڪشن ذريعي رسائي جي ضرورت نه پوي. اڳيون، اچو ته ڏسو ته ڪهڙي معلومات اهم اسٽور ۾ موجود آهي.

اهم معلومات ھيٺين تي مشتمل آھي:

• اهم id - اهم سڃاڻپ ڪندڙ، مثال طور:
  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، فائل جا انگ اکر ۽ هڪ چيڪسم ڳڻيا ويندا آهن، جيڪي سرور کي ياد هوندا آهن، ۽ تبديليون صرف لاڳو ٿينديون آهن جيڪڏهن اهي ملن. جڏهن فائل تبديل ٿئي ٿي، چيڪسم کي اپڊيٽ ڪيو ويندو آهي.

اسان اڳ ۾ ئي ڪيترن ئي سوالن کي ڍڪي چڪا آهيون اهم والٽ بابت. تنهن هوندي، اتي هڪ ٻيو اهم موضوع آهي جيڪو اڪثر وساريو ويو آهي يا غلط سمجھيو ويندو آهي: سرور تي چابيون حصيداري ڪرڻ.

منهنجو مطلب ڇا آهي؟ هر سرور (مثال طور، پرڪونا سرور) ڪلستر ۾ لازمي طور تي والٽ سرور تي هڪ الڳ جڳهه هجڻ گهرجي جنهن ۾ Percona سرور کي ان جي ڪنجين کي ذخيرو ڪرڻ گهرجي. اسٽوريج ۾ محفوظ ڪيل هر ماسٽر ڪيئي ان جي سڃاڻپ ڪندڙ جي اندر Percona سرور جي GUID تي مشتمل آهي. اهو ڇو ضروري آهي؟ تصور ڪريو ته توھان وٽ صرف ھڪڙو والٽ سرور آھي ۽ ڪلستر ۾ سڀ Percona سرور اھو واحد والٽ سرور استعمال ڪندا آھن. مسئلو واضح نظر اچي ٿو. جيڪڏهن سڀ Percona سرورز هڪ ماسٽر ڪيئي استعمال ڪن ٿا سواءِ منفرد سڃاڻپ ڪندڙ، جهڙوڪ 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

انتظار ڪريو. ٻئي سرور ساڳيو والٽ سرور استعمال ڪري رهيا آهن، ڇا نه ٿيڻ گهرجي keyring_key_store فنڪشن سرور2 تي ناڪام؟ دلچسپ ڳالهه اها آهي ته، جيڪڏهن توهان هڪ سرور تي ساڳيو ڪم ڪرڻ جي ڪوشش ڪندا، توهان کي هڪ غلطي ملندي:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

اھو صحيح آھي، ROB_1 اڳ ۾ ئي موجود آھي.

اچو ته پهرين ٻئي مثال تي بحث ڪريون. جيئن اسان اڳ ۾ چيو آهي، keyring_vault يا ڪنهن ٻئي ڪيئرنگ پلگ ان ميموري ۾ سڀني اهم ID کي ڪيش ڪري ٿو. تنهن ڪري، نئين ڪيچ ٺاهڻ کان پوء، ROB_1 کي سرور1 ۾ شامل ڪيو ويو آهي، ۽ هن ڪيئي کي Vault ڏانهن موڪلڻ کان علاوه، ڪيش ۾ پڻ شامل ڪيو ويو آهي. هاڻي، جڏهن اسان ساڳئي ڪيٻي کي ٻيو ڀيرو شامل ڪرڻ جي ڪوشش ڪندا آهيون، keyring_vault چيڪ ڪري ٿو ته ڪيش ۾ ڪيچ موجود آهي ۽ هڪ غلطي اڇلائي ٿي.

پهرين صورت ۾ صورتحال مختلف آهي. Server1 ۽ server2 الڳ الڳ ڪيش آهن. سرور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 تي ھي رستو استعمال ڪندي، والٽ سرور پاڻمرادو ٺاھي ٿو "server1" ڊاريڪٽري. سرور 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) ٺاھڻ واري فائل جي پيرا ميٽرن سان ملن ٿا. يقينن، توھان استعمال ڪري سگھوٿا والٽ يوٽيلٽيز کي ائين ڪرڻ لاءِ. پر ماؤنٽ پوائنٽ جي ٺاھڻ کي خودڪار ڪرڻ آسان آھي. مون کي اميد آهي ته توهان کي اها معلومات مفيد ملندي ۽ اسان توهان کي هن سيريز جي ايندڙ مضمونن ۾ ڏسندا سين.

وڌيڪ پڙهو:

• Sysbench ۽ بي ترتيب متغير جي ورڇ

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