Yn ôfwachting fan it begjin fan in nije ynskriuwing foar de kursus Wy hawwe in oersetting fan in nuttich artikel foar jo taret.
Transparent Data Encryption (TDE) ferskynde yn en MySQL foar in skoft. Mar hawwe jo oait tocht oer hoe't it wurket ûnder de motorkap en hokker ynfloed TDE kin hawwe op jo server? Yn dizze searje artikels sille wy sjen hoe't TDE yntern wurket. Litte wy begjinne mei opslach fan kaaien, om't dit nedich is foar elke fersifering om te wurkjen. Dan sille wy in tichterby besjen hoe't fersifering wurket yn Percona Server foar MySQL / MySQL en hokker ekstra funksjes Percona Server foar MySQL hat.
MySQL Keyring
Keyring binne plugins dy't tastean de tsjinner te freegjen, oanmeitsje en wiskje kaaien yn in lokale triem (keyring_file) of op in ôfstân tsjinner (lykas HashiCorp Vault). Kaaien wurde altyd lokaal yn it cache bewarre om har opheljen te rapperjen.
Plugins kinne wurde ferdield yn twa kategoryen:
- Lokale opslach. Bygelyks, in lokale triem (wy neame dit in triem-basearre keyring).
- Opslach op ôfstân. Bygelyks, Vault Server (wy neame dit in server-basearre keyring).
Dizze skieding is wichtich om't ferskate soarten opslach wat oars gedrage, net allinich by it opslaan en opheljen fan kaaien, mar ek by it útfieren fan se.
By it brûken fan in bestân opslach, by it opstarten, wurdt de folsleine ynhâld fan 'e opslach yn' e cache laden: kaai id, kaai brûker, kaai type, en de kaai sels.
Yn it gefal fan in winkel oan 'e tsjinner (lykas Vault Server), wurde allinich de kaai-id en de kaai-brûker by it opstarten laden, sadat it opstarten fan alle kaaien net fertrage. Kaaien wurde loai laden. Dat is, de kaai sels wurdt laden út Vault allinne as it is eins nedich. Ienris ynladen, wurdt de kaai yn it ûnthâld bewarre, sadat it yn 'e takomst net nedich is fia TLS-ferbiningen mei de Vault-tsjinner. Litte wy dêrnei sjen hokker ynformaasje oanwêzich is yn 'e kaaiwinkel.
De kaaiynformaasje befettet de folgjende:
- kaai id - kaai identifier, bygelyks:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - kaai type - kaaitype basearre op it brûkte fersiferingsalgoritme, mooglike wearden: "AES", "RSA" of "DSA".
- kaai lingte - kaailange yn bytes, AES: 16, 24 of 32, RSA 128, 256, 512 en DSA 128, 256 of 384.
- brûker - eigner fan de kaai. As de kaai is systeem, bygelyks, Master Key, dan is dit fjild leech. As in kaai wurdt makke mei keyring_udf, dan identifisearret dit fjild de eigner fan de kaai.
- de kaai sels
De kaai wurdt unyk identifisearre troch it pear: key_id, brûker.
D'r binne ek ferskillen yn it opslaan en wiskjen fan kaaien.
Bestâns opslach is rapper. Jo kinne tinke dat in kaaiwinkel gewoan ien kear de kaai foar in bestân skriuwt, mar nee, d'r is hjir mear oan de hân. Elke kear as in wiziging fan bestân opslach wurdt makke, wurdt earst in reservekopy fan alle ynhâld makke. Litte wy sizze dat it bestân my_biggest_secrets hjit, dan sil de reservekopy my_biggest_secrets.backup wêze. Dêrnei wurdt de cache feroare (kaaien wurde tafoege of wiske) en, as alles suksesfol is, wurdt de cache weromset nei in bestân. Yn seldsume gefallen, lykas in tsjinnerfout, kinne jo dit reservekopybestân sjen. De reservekopy triem wurdt wiske de folgjende kear de kaaien wurde laden (meastentiids neidat de tsjinner is opnij starte).
By it bewarjen of wiskjen fan in kaai yn in tsjinner opslach, moat de opslach ferbine mei de MySQL-tsjinner mei de kommando's "ferstjoere de kaai" / "fersyk wiskjen fan kaaien".
Litte wy weromgean nei opstartsnelheid fan tsjinner. Neist it feit dat de startsnelheid wurdt beynfloede troch it ferwulft sels, is d'r ek de kwestje fan hoefolle kaaien fan 'e ferwulft moatte wurde ophelle by it opstarten. Fansels is dit foaral wichtich foar tsjinner opslach. By it opstarten kontrolearret de tsjinner hokker kaai nedich is foar fersifere tabellen / tabelromten en freget de kaai fan 'e opslach. Op in "skjinne" tsjinner mei Master Key fersifering, moat der ien Master Key, dy't moat wurde ophelle út opslach. In grutter oantal kaaien kin lykwols nedich wêze, bygelyks as de reservekopytsjinner in reservekopy fan 'e primêre tsjinner herstelt. Yn sokke gefallen moat rotaasje fan 'e Master Key wurde levere. Dit sil mear detaillearre wurde yn takomstige artikels, hoewol ik hjir wol opmerke dat in tsjinner mei meardere Master Keys in bytsje langer duorje kin om op te starten, foaral by it brûken fan in tsjinner-side-kaaiwinkel.
Litte wy no wat mear prate oer keyring_file. Doe't ik wie it ûntwikkeljen fan keyring_file, Ik wie ek soargen oer hoe te kontrolearjen op keyring_file feroarings wylst de tsjinner rint. Yn 5.7 waard de kontrôle útfierd op basis fan bestânstatistiken, wat gjin ideale oplossing wie, en yn 8.0 waard it ferfongen troch in SHA256-kontrôlesum.
De earste kear dat jo keyring_file útfiere, wurde triemstatistiken en in kontrôlesum berekkene, dy't wurde ûnthâlden troch de tsjinner, en feroarings wurde allinich tapast as se oerienkomme. As de triem feroaret, wurdt de kontrôlesum bywurke.
Wy hawwe al in protte fragen behannele oer kaaiferwulften. D'r is lykwols in oar wichtich ûnderwerp dat faaks fergetten of ferkeard begrepen wurdt: kaaien dielen oer servers.
Wat ik bedoel? Eltse tsjinner (Bygelyks, Percona Server) yn it kluster moat hawwe in aparte lokaasje op de Vault Server dêr't Percona Server moat opslaan syn kaaien. Elke masterkaai opslein yn 'e opslach befettet de GUID fan' e Percona-tsjinner binnen syn identifier. Wêrom is it wichtich? Stel jo foar dat jo mar ien Vault Server hawwe en alle Percona Servers yn it kluster brûke dy inkele Vault Server. It probleem liket dúdlik. As alle Percona-tsjinners in Master-kaai brûkten sûnder unike identifiers, lykas id = 1, id = 2, ensfh., dan soene alle servers yn it kluster deselde Master-kaai brûke. Wat de GUID leveret is it ûnderskied tusken servers. Wêrom dan prate oer it dielen fan kaaien tusken servers as in unike GUID al bestiet? D'r is in oare plugin - keyring_udf. Mei dizze plugin kin jo serverbrûker har kaaien opslaan op 'e Vault-tsjinner. It probleem komt foar as in brûker in kaai oanmakket op server1, bygelyks, en dan besiket in kaai te meitsjen mei deselde ID op server2, bygelyks:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Wachtsje. Beide tsjinners brûke deselde Vault Server, soe de keyring_key_store funksje net mislearje op server2? Ynteressant, as jo besykje itselde te dwaan op ien server, krije jo in flater:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Dat is krekt, ROB_1 bestiet al.
Litte wy earst it twadde foarbyld besprekke. Lykas wy earder sein hawwe, cache keyring_vault of in oar keyring-plugin alle kaai-ID's yn it ûnthâld. Dus, nei it meitsjen fan in nije kaai, wurdt ROB_1 tafoege oan server1, en neist it ferstjoeren fan dizze kaai nei Vault, wurdt de kaai ek tafoege oan it cache. No, as wy besykje deselde kaai in twadde kear ta te foegjen, kontrolearret keyring_vault oft de kaai bestiet yn 'e cache en smyt in flater.
Yn it earste gefal is de situaasje oars. Server1 en server2 hawwe aparte caches. Nei it tafoegjen fan ROB_1 oan de kaai-cache op server1 en de Vault-tsjinner, is de kaai-cache op server2 net syngronisearre. D'r is gjin ROB_2-kaai yn 'e cache op server1. Sa wurdt de ROB_1-kaai skreaun nei de keyring_key_store en nei de Vault-tsjinner, dy't eins de foarige wearde oerskriuwt (!). No is de ROB_1-kaai op 'e Vault-tsjinner 543210987654321. Nijsgjirrich is dat de Vault-tsjinner sokke aksjes net blokkeart en de âlde wearde maklik oerskriuwt.
No kinne wy sjen wêrom't tsjinner partitioning yn Vault wichtich kin wêze - as jo brûke keyring_udf en wolle opslaan kaaien yn Vault. Hoe kinne jo dizze skieding berikke op in Vault-tsjinner?
D'r binne twa manieren om te dielen yn Vault. Jo kinne meitsje ferskillende berch punten foar eltse tsjinner, of brûk ferskillende paden binnen itselde berch punt. Dit wurdt it bêste yllustrearre mei foarbylden. Litte wy dus earst nei de yndividuele berchpunten sjen:
--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 = (...)Hjir kinne jo sjen dat server1 en server2 ferskillende berchpunten brûke. By it splitsen fan de paden sil de konfiguraasje der sa útsjen:
--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 = (...)Yn dit gefal brûke beide tsjinners itselde berchpunt "mount_point", mar ferskillende paden. As jo it earste geheim op server1 meitsje mei dit paad, makket de Vault-tsjinner automatysk in map "server1". Foar server2 is alles fergelykber. As jo it lêste geheim yn mount_point/server1 of mount_point/server2 wiskje, wisket de Vault-tsjinner ek dy mappen. As jo paadskieding brûke, moatte jo mar ien berchpunt oanmeitsje en de konfiguraasjebestannen feroarje sadat de tsjinners aparte paden brûke. In berchpunt kin makke wurde mei in HTTP-fersyk. Mei CURL kin dit sa dien wurde:
curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTAlle fjilden (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) oerienkomme mei de parameters fan it konfiguraasjetriem. Fansels kinne jo Vault-hulpprogramma's brûke om itselde te dwaan. Mar it is makliker om it meitsjen fan in berchpunt te automatisearjen. Ik hoopje dat jo dizze ynformaasje nuttich fine en wy sille jo sjen yn 'e folgjende artikels yn dizze searje.
Lês mear:
Boarne: www.habr.com