Í aðdraganda nýrrar innritunar á námskeiðið Við höfum útbúið þýðingu á gagnlegri grein fyrir þig.
Transparent Data Encryption (TDE) birtist í og MySQL í nokkurn tíma. En hefurðu einhvern tíma hugsað um hvernig það virkar undir hettunni og hvaða áhrif TDE getur haft á netþjóninn þinn? Í þessari greinaröð munum við skoða hvernig TDE virkar innbyrðis. Byrjum á lyklageymslu þar sem þetta er nauðsynlegt til að hvaða dulkóðun virki. Síðan munum við skoða nánar hvernig dulkóðun virkar í Percona Server fyrir MySQL/MySQL og hvaða viðbótareiginleika Percona Server fyrir MySQL hefur.
MySQL lyklakippa
Lyklahringur eru viðbætur sem gera þjóninum kleift að spyrjast fyrir um, búa til og eyða lyklum í staðbundinni skrá (keyring_file) eða á ytri netþjóni (eins og HashiCorp Vault). Lyklar eru alltaf í skyndiminni á staðnum til að flýta fyrir endurheimt þeirra.
Viðbótum má skipta í tvo flokka:
- Staðbundin geymsla. Til dæmis, staðbundin skrá (við köllum þetta skráabundinn lyklakippu).
- Fjargeymsla. Til dæmis, Vault Server (við köllum þetta miðlara-undirstaða lyklakippu).
Þessi aðskilnaður er mikilvægur vegna þess að mismunandi gerðir geymslu hegða sér aðeins öðruvísi, ekki aðeins þegar lyklar eru geymdir og sóttir, heldur einnig þegar þeir keyra þá.
Þegar skráageymsla er notuð, við ræsingu, er allt innihald geymslunnar hlaðið inn í skyndiminni: lykilauðkenni, lykilnotanda, lyklategund og lykillinn sjálfur.
Þegar um er að ræða verslun sem byggir á netþjóni (eins og Vault Server) er aðeins lykilauðkenni og lykilnotandi hlaðið við ræsingu, þannig að það hægir ekki á ræsingu að fá alla lyklana. Lyklar eru hlaðnir í leti. Það er, lykillinn sjálfur er aðeins hlaðinn úr Vault þegar þess er raunverulega þörf. Þegar honum hefur verið hlaðið niður er lykillinn í skyndiminni í minni þannig að ekki þarf að nálgast hann í gegnum TLS tengingar við Vault Server í framtíðinni. Næst skulum við skoða hvaða upplýsingar eru til staðar í lyklageymslunni.
Lykilupplýsingarnar innihalda eftirfarandi:
- lykilauðkenni — lykilauðkenni, til dæmis:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - lykilgerð — gerð lykla byggt á dulkóðunaralgríminu sem notað er, möguleg gildi: „AES“, „RSA“ eða „DSA“.
- lykil lengd — lyklalengd í bætum, AES: 16, 24 eða 32, RSA 128, 256, 512 og DSA 128, 256 eða 384.
- notandi - eigandi lykilsins. Ef lykillinn er kerfi, til dæmis Master Key, þá er þessi reitur tómur. Ef lykill er búinn til með því að nota keyring_udf, þá auðkennir þessi reitur eiganda lykilsins.
- lykilinn sjálfur
Lykillinn er auðkenndur einstaklega af parinu: key_id, user.
Það er líka munur á því að geyma og eyða lyklum.
Skráargeymsla er hraðari. Þú gætir haldið að lyklaverslun sé einfaldlega að skrifa lykilinn að skrá einu sinni, en nei, það er meira í gangi hér. Alltaf þegar breyting á skráargeymslu er gerð er fyrst búið til öryggisafrit af öllu efni. Segjum að skráin heiti my_biggest_secrets, þá verður öryggisafritið my_biggest_secrets.backup. Næst er skyndiminni breytt (lykla er bætt við eða eytt) og ef allt gengur vel er skyndiminni endurstillt í skrá. Í mjög sjaldgæfum tilvikum, svo sem bilun á netþjóni, gætirðu séð þessa öryggisafritsskrá. Afritaskránni er eytt næst þegar lyklarnir eru hlaðnir (venjulega eftir að þjónninn er endurræstur).
Þegar lykill er vistað eða eytt í geymslu miðlara verður geymslan að tengjast MySQL þjóninum með skipunum „senda lykilinn“ / „beiðja um eyðingu lykla“.
Snúum okkur aftur að ræsingarhraða netþjónsins. Auk þess að sjósetningarhraðinn er fyrir áhrifum af hvelfingunni sjálfri, þá er líka spurning um hversu marga lykla úr hvelfingunni þarf að sækja við ræsingu. Auðvitað er þetta sérstaklega mikilvægt fyrir geymslu netþjóna. Við ræsingu athugar þjónninn hvaða lykil er nauðsynlegur fyrir dulkóðuð töflur/borðrými og biður um lykilinn úr geymslunni. Á „hreinum“ netþjóni með Master Key dulkóðun verður að vera einn Master Key, sem verður að sækja úr geymslu. Hins vegar gæti þurft fleiri lykla, til dæmis þegar varaþjónninn er að endurheimta öryggisafrit frá aðalþjóninum. Í slíkum tilfellum ætti að snúa aðallyklinum. Nánar verður fjallað um þetta í framtíðargreinum, þó að hér vil ég taka fram að netþjónn sem notar marga aðallykla gæti tekið aðeins lengri tíma að ræsa sig, sérstaklega þegar lyklaverslun á netþjóni er notuð.
Nú skulum við tala aðeins meira um keyring_file. Þegar ég var að þróa keyring_file hafði ég líka áhyggjur af því hvernig ætti að athuga hvort breytingar á keyring_file væru á meðan þjónninn er í gangi. Í 5.7 var athugunin framkvæmd á grundvelli skráatölfræði, sem var ekki tilvalin lausn, og í 8.0 var henni skipt út fyrir SHA256 eftirlitssummu.
Í fyrsta skipti sem þú keyrir keyring_file er reiknað út tölfræði skráa og eftirlitssumma, sem þjónninn man eftir, og breytingar eru aðeins notaðar ef þær passa saman. Þegar skráin breytist er eftirlitssumman uppfærð.
Við höfum þegar fjallað um margar spurningar um lykilhólf. Hins vegar er annað mikilvægt efni sem oft gleymist eða er misskilið: að deila lyklum á milli netþjóna.
Hvað ég meina? Hver þjónn (til dæmis Percona Server) í þyrpingunni verður að hafa sérstaka staðsetningu á Vault Server þar sem Percona Server verður að geyma lykla sína. Hver aðallykill sem er vistaður í geymslunni inniheldur GUID Percona þjónsins innan auðkennis þess. Hvers vegna er það mikilvægt? Ímyndaðu þér að þú hafir aðeins einn Vault Server og allir Percona Servers í þyrpingunni noti þennan eina Vault Server. Vandamálið virðist augljóst. Ef allir Percona Servers notuðu Master Key án einstakra auðkenna, eins og id = 1, id = 2, osfrv., þá myndu allir netþjónar í klasanum nota sama Master Key. Það sem GUID veitir er greinarmunurinn á netþjónum. Af hverju þá að tala um að deila lyklum á milli netþjóna ef einstakt GUID er þegar til? Það er önnur viðbót - keyring_udf. Með þessari viðbót getur notandi netþjónsins geymt lyklana sína á Vault netþjóninum. Vandamálið kemur upp þegar notandi býr til lykil á server1, til dæmis, og reynir síðan að búa til lykil með sama auðkenni á server2, til dæmis:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Bíddu. Báðir netþjónarnir eru að nota sama Vault Server, ætti keyring_key_store aðgerðin ekki að mistakast á server2? Athyglisvert er að ef þú reynir að gera það sama á einum netþjóni færðu villu:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Það er rétt, ROB_1 er þegar til.
Við skulum ræða annað dæmið fyrst. Eins og við sögðum áðan, geymir keyring_vault eða önnur lyklakippuforrit öll lykilauðkenni í minni. Svo, eftir að hafa búið til nýjan lykil, er ROB_1 bætt við server1, og auk þess að senda þennan lykil til Vault, er lyklinum einnig bætt við skyndiminni. Nú, þegar við reynum að bæta við sama lyklinum í annað sinn, athugar keyring_vault hvort lykillinn sé til í skyndiminni og varpar upp villu.
Í fyrra tilvikinu er staðan önnur. Server1 og server2 hafa aðskilin skyndiminni. Eftir að ROB_1 hefur verið bætt við lyklaskyndiminni á server1 og Vault miðlara er lyklaskyndiminni á server2 ekki samstillt. Það er enginn ROB_2 lykill í skyndiminni á server1. Þannig er ROB_1 lykillinn skrifaður í keyring_key_store og á Vault þjóninn, sem skrifar í raun yfir (!) fyrra gildið. Nú er ROB_1 lykillinn á Vault þjóninum 543210987654321. Athyglisvert er að Vault þjónninn lokar ekki á slíkar aðgerðir og skrifar auðveldlega yfir gamla gildið.
Nú getum við séð hvers vegna skipting miðlara í Vault getur verið mikilvæg - þegar þú ert að nota keyring_udf og vilt geyma lykla í Vault. Hvernig á að ná þessum aðskilnaði á Vault netþjóni?
Það eru tvær leiðir til að skiptast í Vault. Þú getur búið til mismunandi tengipunkta fyrir hvern netþjón eða notað mismunandi slóðir innan sama tengipunkts. Þetta er best útskýrt með dæmum. Svo skulum við líta á einstaka festingarpunkta fyrst:
--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 = (...)Hér geturðu séð að server1 og server2 nota mismunandi tengipunkta. Þegar slóðum er skipt upp mun uppsetningin líta svona út:
--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 = (...)Í þessu tilviki nota báðir netþjónarnir sama tengipunkt „mount_point“ en mismunandi slóðir. Þegar þú býrð til fyrsta leyndarmálið á þjóni1 með þessari slóð, býr Vault þjónninn sjálfkrafa til „þjónn1“ möppu. Fyrir server2 er allt svipað. Þegar þú eyðir síðasta leyndarmálinu í mount_point/server1 eða mount_point/server2 eyðir Vault-þjónninn einnig þessum möppum. Ef þú notar aðskilnað slóða þarftu aðeins að búa til einn tengipunkt og breyta stillingarskránum þannig að netþjónarnir noti aðskildar slóðir. Hægt er að búa til tengipunkt með HTTP beiðni. Með því að nota CURL er þetta hægt að gera svona:
curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTAllir reitir (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) samsvara breytum stillingaskráarinnar. Auðvitað geturðu notað Vault tól til að gera það sama. En það er auðveldara að gera sjálfvirkan stofnun tengipunkts. Ég vona að þér finnist þessar upplýsingar gagnlegar og við sjáum þig í næstu greinum í þessari röð.
Lestu meira:
Heimild: www.habr.com