ProHoster > بلاګ > اداره > په MySQL کې کوډ کول: کیسټور

په MySQL کې کوډ کول: کیسټور

د کورس لپاره د نوي نوم لیکنې د پیل په تمه "ډیټابیس" ستاسو لپاره د ګټورې مقالې ژباړه چمتو کړې.

په MySQL کې کوډ کول: کیسټور

د شفاف ډیټا کوډ کول (TDE) په کې څرګند شو د MySQL لپاره پرکونا سرور او MySQL د یو څه وخت لپاره. مګر ایا تاسو کله هم فکر کړی چې دا څنګه د هود لاندې کار کوي او TDE ستاسو په سرور باندې څه اغیزه کولی شي؟ د دې مقالې لړۍ کې، موږ به یو نظر وګورو چې څنګه TDE په داخلي توګه کار کوي. راځئ چې د کلیدي ذخیره کولو سره پیل وکړو، ځکه چې دا د کار کولو لپاره د کوم کوډ کولو لپاره اړین دی. بیا به موږ نږدې وګورو چې څنګه کوډ کول د MySQL/MySQL لپاره پرکونا سرور کې کار کوي او کوم اضافي ځانګړتیاوې د MySQL لپاره پرکونا سرور کې شتون لري.

د MySQL کیرینګ

کیرینګ هغه پلگ انونه دي چې سرور ته اجازه ورکوي چې په محلي فایل (کیرینګ_فایل) کې یا په ریموټ سرور کې (د مثال په توګه ، په HashiCorp والټ کې) کې کیلي پوښتنې ، رامینځته او حذف کړي. کیلي تل په محلي توګه ساتل کیږي ترڅو د بیرته ترلاسه کولو چټکتیا لپاره.

پلگ انونه په دوه کټګوریو ویشل کیدی شي:

  • ځایی ذخیره. د مثال په توګه، یو محلي فایل (موږ دې ته د فایل پر بنسټ کیرینګ وایو).
  • لیرې ذخیره. د مثال په توګه والټ سرور (موږ دې ته د سرور پر بنسټ کیرینګ وایو).

دا جلا کول مهم دي ځکه چې د ذخیره کولو مختلف ډولونه نه یوازې د کیلي ذخیره کولو او ترلاسه کولو پرمهال یو څه توپیر لري ، بلکه کله چې دوی پیل کیږي.

کله چې د فایل ذخیره وکاروئ ، د ذخیره کولو ټول مینځپانګې په پیل کې کیچ کې بار شوي: کلیدي ID ، کلیدي کارونکي ، کلیدي ډول ، او پخپله کیلي.

د شاته پای پلورنځي په حالت کې (د مثال په توګه ، والټ سرور) ، یوازې کیلي ID او کلیدي کارونکي په پیل کې بار شوي ، نو د ټولو کیلي ترلاسه کول د پیل پیل سست نه کوي. کیلي په سستۍ سره بار شوي. دا دی ، کیلي پخپله د والټ څخه بار کیږي کله چې واقعیا ورته اړتیا وي. د ډاونلوډ کولو وروسته، کیلي په حافظه کې ساتل کیږي ترڅو په راتلونکي کې د والټ سرور ته د 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 ډیزاین کوم، زه د دې په اړه هم اندیښمن وم چې څنګه د کیرینګ_فایل بدلونونو لپاره وګورئ پداسې حال کې چې سرور چلوي. په 5.7 کې، چک د فایل احصایې پراساس ترسره شوی، کوم چې مثالی نه و، او په 8.0 کې دا د SHA256 چکسم سره بدل شو.

د لومړي ځل لپاره keyring_file چلول کیږي، د فایل احصایې او چکسم حساب شوي او د سرور لخوا یاد شوي، او بدلونونه یوازې هغه وخت پلي کیږي چې دوی سره سمون ولري. کله چې فایل بدل شي، چکسم تازه کیږي.

موږ دمخه د کیسټورونو په اړه ډیری پوښتنې پوښلې دي. په هرصورت، یو بل مهم موضوع شتون لري چې ډیری وختونه هیر شوي یا غلط پوهیږي - په سرورونو کې د شریکولو کلیدونه.

زما مطلب څه دی؟ هر سرور (د مثال په توګه، د پرکونا سرور) په کلستر کې باید په والټ سرور کې جلا ځای ولري چیرې چې د پرکونا سرور باید خپلې کیلي ذخیره کړي. په والټ کې زیرمه شوي هر ماسټر کیلي په خپل ID کې د Percona Server 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

انتظار وکړئ. دواړه سرورونه ورته والټ سرور کاروي، ایا باید د 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 یا کوم بل والټ پلگ ان (کیرینګ) په حافظه کې ټولې کلیدي IDs خوندي کوي. نو، د نوې کیلي د جوړولو وروسته، ROB_1 په سرور1 کې اضافه کیږي، او د دې کیلي Vault ته لیږلو سربیره، کیلي هم په کیچ کې اضافه کیږي. اوس، کله چې موږ د دویم ځل ورته کیلي اضافه کولو هڅه کوو، keyring_vault چک کوي چې آیا کیلي په زیرمه کې شتون لري او تېروتنه کوي.

په لومړي حالت کې، وضعیت توپیر لري. سرور1 او سرور2 جلا کیچونه لري. په سرور1 او والټ سرور کې کلیدي زیرمه کې د ROB_1 اضافه کولو وروسته ، په سرور2 کې کلیدي زیرمه له ترکیب څخه بهر ده. په سرور2 کې کیچ د ROB_1 کیلي نلري. په دې توګه، د ROB_1 کیلي د keyring_key_store او د والټ سرور ته لیکل کیږي، کوم چې په حقیقت کې پخوانی ارزښت (!) بیا لیکي. اوس د والټ سرور کې کلیدي 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 = (...)

پدې حالت کې ، دواړه سرورونه ورته ماونټ پوائنټ "ماونټ_پوائنټ" کاروي مګر مختلف لارې. کله چې تاسو د دې لارې په کارولو سره په سرور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) د ترتیب کولو فایل پیرامیټونو سره مطابقت لري. البته، تاسو کولی شئ د ورته کولو لپاره د والټ اسانتیاوې وکاروئ. مګر د ماونټ پوائنټ رامینځته کول اتومات کول اسانه دي. زه امید لرم چې تاسو دا معلومات ګټور ومومئ او تاسو د دې لړۍ په راتلونکو مقالو کې وګورئ.

په MySQL کې کوډ کول: کیسټور

نور یی ولوله:

سرچینه: www.habr.com

Add a comment