Kwa kutarajia kuanza kwa uandikishaji mpya kwa kozi hiyo Tumekuandalia tafsiri ya makala muhimu.
Usimbaji Data wa Uwazi (TDE) ulionekana na MySQL kwa muda mrefu. Lakini umewahi kufikiria jinsi inavyofanya kazi chini ya kofia na ni athari gani TDE inaweza kuwa nayo kwenye seva yako? Katika mfululizo huu wa makala tutaangalia jinsi TDE inavyofanya kazi ndani. Wacha tuanze na uhifadhi muhimu, kwani hii inahitajika ili usimbuaji wowote ufanye kazi. Kisha tutaangalia kwa undani jinsi usimbaji fiche unavyofanya kazi katika Seva ya Percona kwa MySQL/MySQL na ni vipengele gani vya ziada vya Percona Server ya MySQL inayo.
Keyring ya MySQL
Uwekaji wa ufunguo ni programu jalizi zinazoruhusu seva kuuliza, kuunda, na kufuta vitufe katika faili ya ndani (keyring_file) au kwenye seva ya mbali (kama vile HashiCorp Vault). Vifunguo huwekwa kwenye akiba kila wakati ili kuharakisha urejeshaji wao.
Plugins inaweza kugawanywa katika makundi mawili:
- Hifadhi ya ndani. Kwa mfano, faili ya ndani (tunaita hii ufunguo wa msingi wa faili).
- Hifadhi ya mbali. Kwa mfano, Seva ya Vault (tunaita hii ufunguo wa msingi wa seva).
Mgawanyiko huu ni muhimu kwa sababu aina tofauti za uhifadhi hufanya tofauti kidogo, sio tu wakati wa kuhifadhi na kurejesha funguo, lakini pia wakati wa kuziendesha.
Wakati wa kutumia hifadhi ya faili, wakati wa kuanza, maudhui yote ya hifadhi yanapakiwa kwenye kashe: kitambulisho cha ufunguo, mtumiaji wa ufunguo, aina ya ufunguo, na ufunguo yenyewe.
Kwa upande wa duka la msingi wa seva (kama vile Vault Server), kitambulisho cha ufunguo tu na mtumiaji muhimu hupakiwa wakati wa kuanza, kwa hivyo kupata funguo zote hakupunguzi kasi ya kuanza. Funguo hupakiwa kwa uvivu. Hiyo ni, ufunguo yenyewe hupakiwa kutoka kwa Vault tu wakati inahitajika. Mara baada ya kupakuliwa, ufunguo umehifadhiwa kwenye kumbukumbu ili hauhitaji kufikiwa kupitia miunganisho ya TLS kwenye Seva ya Vault katika siku zijazo. Ifuatayo, hebu tuangalie ni habari gani iliyopo kwenye duka la ufunguo.
Habari kuu ina mambo yafuatayo:
- kitambulisho muhimu - kitambulisho muhimu, kwa mfano:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - aina muhimu β aina ya ufunguo kulingana na algoriti ya usimbaji iliyotumiwa, thamani zinazowezekana: "AES", "RSA" au "DSA".
- urefu muhimu β urefu wa ufunguo katika baiti, AES: 16, 24 au 32, RSA 128, 256, 512 na DSA 128, 256 au 384.
- user - mmiliki wa ufunguo. Ikiwa ufunguo ni mfumo, kwa mfano, Ufunguo Mkuu, basi uwanja huu hauna tupu. Ikiwa ufunguo umeundwa kwa kutumia keyring_udf, basi sehemu hii itatambua mmiliki wa ufunguo.
- ufunguo wenyewe
Ufunguo unatambuliwa kipekee na jozi: key_id, mtumiaji.
Pia kuna tofauti katika kuhifadhi na kufuta funguo.
Hifadhi ya faili ni haraka zaidi. Unaweza kufikiria kuwa duka kuu linaandika tu ufunguo wa faili mara moja, lakini hapana, kuna mengi zaidi yanayoendelea hapa. Wakati wowote urekebishaji wa uhifadhi wa faili unapofanywa, nakala rudufu ya maudhui yote huundwa kwanza. Hebu tuseme faili inaitwa my_biggest_secrets, basi nakala ya chelezo itakuwa my_biggest_secrets.backup. Ifuatayo, cache inabadilishwa (funguo zinaongezwa au kufutwa) na, ikiwa kila kitu kinafanikiwa, cache imewekwa upya kwenye faili. Katika hali nadra, kama vile kushindwa kwa seva, unaweza kuona faili hii ya chelezo. Faili ya chelezo inafutwa wakati funguo zitakapopakiwa (kwa kawaida baada ya seva kuwashwa tena).
Wakati wa kuhifadhi au kufuta ufunguo kwenye hifadhi ya seva, hifadhi lazima iunganishwe na seva ya MySQL na amri "tuma ufunguo" / "omba ufutaji wa ufunguo".
Hebu turudi kwenye kasi ya kuanzisha seva. Mbali na ukweli kwamba kasi ya uzinduzi inathiriwa na vault yenyewe, pia kuna suala la funguo ngapi kutoka kwa vault zinahitajika kurejeshwa wakati wa kuanza. Bila shaka, hii ni muhimu hasa kwa hifadhi ya seva. Wakati wa kuanza, seva hukagua ni ufunguo gani unaohitajika kwa jedwali/nafasi zilizosimbwa kwa njia fiche na kuomba ufunguo kutoka kwa hifadhi. Kwenye seva "safi" iliyo na usimbaji fiche wa Ufunguo Mkuu, lazima kuwe na Ufunguo Mkuu mmoja, ambao lazima urejeshwe kutoka kwa hifadhi. Hata hivyo, idadi kubwa ya funguo inaweza kuhitajika, kwa mfano, wakati seva ya chelezo inarejesha nakala rudufu kutoka kwa seva ya msingi. Katika hali kama hizi, mzunguko wa Ufunguo Mkuu unapaswa kutolewa. Hili litashughulikiwa kwa undani zaidi katika makala zijazo, ingawa hapa ningependa kutambua kwamba seva inayotumia Vifunguo Vikuu vingi inaweza kuchukua muda mrefu zaidi kuanza, haswa inapotumia duka la vitufe vya upande wa seva.
Sasa hebu tuzungumze zaidi kuhusu keyring_file. Nilipokuwa nikitengeneza keyring_file, nilikuwa na wasiwasi pia kuhusu jinsi ya kuangalia mabadiliko ya keyring_file wakati seva inafanya kazi. Mnamo 5.7, hundi ilifanyika kulingana na takwimu za faili, ambayo haikuwa suluhisho bora, na katika 8.0 ilibadilishwa na checksum ya SHA256.
Mara ya kwanza unapoendesha keyring_file, takwimu za faili na cheki huhesabiwa, ambazo hukumbukwa na seva, na mabadiliko yanatumika tu ikiwa yanalingana. Wakati faili inabadilika, cheki inasasishwa.
Tayari tumeshughulikia maswali mengi kuhusu vaults muhimu. Hata hivyo, kuna mada nyingine muhimu ambayo mara nyingi husahauliwa au kutoeleweka: kushiriki funguo kwenye seva.
Ninamaanisha nini? Kila seva (kwa mfano, Seva ya Percona) katika kundi lazima iwe na eneo tofauti kwenye Seva ya Vault ambayo Seva ya Percona lazima ihifadhi funguo zake. Kila Ufunguo Mkuu uliohifadhiwa kwenye hifadhi una GUID ya Seva ya Percona ndani ya kitambulisho chake. Kwa nini ni muhimu? Fikiria kuwa una Seva moja tu ya Vault na Seva zote za Percona kwenye nguzo zinatumia Seva hiyo ya Vault. Tatizo linaonekana wazi. Ikiwa Seva zote za Percona zingetumia Ufunguo Mkuu bila vitambulishi vya kipekee, kama vile id = 1, id = 2, n.k., basi seva zote kwenye nguzo zingetumia Ufunguo Mkuu sawa. Kile ambacho GUID hutoa ni tofauti kati ya seva. Kwa nini basi uzungumze juu ya kushiriki funguo kati ya seva ikiwa GUID ya kipekee tayari iko? Kuna programu-jalizi nyingine - keyring_udf. Kwa programu-jalizi hii, mtumiaji wa seva yako anaweza kuhifadhi funguo zao kwenye seva ya Vault. Shida hutokea wakati mtumiaji anaunda ufunguo kwenye seva1, kwa mfano, na kisha anajaribu kuunda ufunguo na kitambulisho sawa kwenye seva2, kwa mfano:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 Π·Π½Π°ΡΠΈΡ ΡΡΠΏΠ΅ΡΠ½ΠΎΠ΅ Π·Π°Π²Π΅ΡΡΠ΅Π½ΠΈΠ΅
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Subiri. Seva zote mbili zinatumia Seva ya Vault sawa, je, utendakazi wa keyring_key_store haupaswi kushindwa kwenye server2? Inafurahisha, ukijaribu kufanya vivyo hivyo kwenye seva moja, utapokea hitilafu:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Hiyo ni kweli, ROB_1 tayari ipo.
Hebu tujadili mfano wa pili kwanza. Kama tulivyosema hapo awali, keyring_vault au programu-jalizi nyingine yoyote ya ufunguo huhifadhi vitambulisho vyote kwenye kumbukumbu. Kwa hivyo, baada ya kuunda ufunguo mpya, ROB_1 huongezwa kwa seva1, na pamoja na kutuma ufunguo huu kwa Vault, ufunguo pia huongezwa kwenye kashe. Sasa, tunapojaribu kuongeza ufunguo huo kwa mara ya pili, keyring_vault hukagua ikiwa ufunguo upo kwenye kashe na kutupa hitilafu.
Katika kesi ya kwanza, hali ni tofauti. Server1 na server2 zina kache tofauti. Baada ya kuongeza ROB_1 kwenye kashe ya ufunguo kwenye seva1 na seva ya Vault, kashe ya ufunguo kwenye seva2 haijasawazishwa. Hakuna ufunguo wa ROB_2 kwenye kashe kwenye seva1. Kwa hivyo, ufunguo wa ROB_1 umeandikwa kwa keyring_key_store na kwa seva ya Vault, ambayo kwa kweli hubatilisha (!) thamani ya awali. Sasa ufunguo wa ROB_1 kwenye seva ya Vault ni 543210987654321. Inashangaza, seva ya Vault haizuii vitendo kama hivyo na hubadilisha thamani ya zamani kwa urahisi.
Sasa tunaweza kuona ni kwa nini ugawaji wa seva katika Vault unaweza kuwa muhimu - unapotumia keyring_udf na unataka kuhifadhi funguo katika Vault. Jinsi ya kufikia utengano huu kwenye seva ya Vault?
Kuna njia mbili za kugawanya katika Vault. Unaweza kuunda sehemu tofauti za kupachika kwa kila seva, au kutumia njia tofauti ndani ya sehemu moja ya kupachika. Hii inaonyeshwa vyema na mifano. Kwa hivyo, wacha tuangalie alama za mtu binafsi kwanza:
--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 = (...)Hapa unaweza kuona kwamba server1 na server2 hutumia sehemu tofauti za mlima. Wakati wa kugawanya njia, usanidi utaonekana kama hii:
--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 = (...)Katika kesi hii, seva zote mbili hutumia sehemu sawa ya mlima "mount_point", lakini njia tofauti. Unapounda siri ya kwanza kwenye seva1 kwa kutumia njia hii, seva ya Vault huunda kiotomati saraka ya "server1". Kwa seva2 kila kitu ni sawa. Unapofuta siri ya mwisho katika mount_point/server1 au mount_point/server2, seva ya Vault pia hufuta saraka hizo. Iwapo utatumia mgawanyo wa njia, lazima uunde sehemu moja tu ya kupachika na ubadilishe faili za usanidi ili seva zitumie njia tofauti. Sehemu ya kupachika inaweza kuundwa kwa kutumia ombi la HTTP. Kwa kutumia CURL hii inaweza kufanywa kama hii:
curl -L -H "X-Vault-Token: TOKEN" βcacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTSehemu zote (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) zinalingana na vigezo vya faili ya usanidi. Kwa kweli, unaweza kutumia huduma za Vault kufanya vivyo hivyo. Lakini ni rahisi kusanidi uundaji wa sehemu ya mlima. Natumaini utapata habari hii kuwa muhimu na tutakuona katika makala zinazofuata katika mfululizo huu.
Soma zaidi:
Chanzo: mapenzi.com