Ikastarorako matrikula berri baten hasieraren esperoan Artikulu erabilgarria baten itzulpena prestatu dugu zuretzat.
Transparent Data Encryption (TDE) agertu zen eta MySQL denbora luzez. Baina pentsatu al duzu inoiz nola funtzionatzen duen kanpaiaren azpian eta zer eragin izan dezakeen TDEk zure zerbitzarian? Artikulu sorta honetan TDEk barnean nola funtzionatzen duen ikusiko dugu. Has gaitezen gakoen biltegiratzetik, hau beharrezkoa baita edozein enkriptazio funtziona dezan. Ondoren, enkriptatzea MySQL/MySQL-en Percona Server-en nola funtzionatzen duen eta zer ezaugarri osagarri dituen Percona Server MySQL-en ikusiko dugu.
MySQL giltza-ertza
Giltza-zerbitzariak tokiko fitxategi batean (keyring_file) edo urruneko zerbitzari batean (hashiCorp Vault adibidez) gakoak kontsultatu, sortu eta ezabatzeko aukera ematen dioten pluginak dira. Gakoak beti lokalean gordetzen dira, berreskuratzea bizkortzeko.
Pluginak bi kategoriatan bana daitezke:
- Tokiko biltegiratzea. Adibidez, fitxategi lokal bat (fitxategietan oinarritutako giltza-erraza deitzen diogu honi).
- Urruneko biltegiratzea. Adibidez, Vault Server (zerbitzarian oinarritutako giltza-errantzia deitzen diogu honi).
Bereizketa hori garrantzitsua da biltegiratze-mota ezberdinek portaera apur bat desberdina dutelako, ez bakarrik giltzak gordetzean eta berreskuratzean, baita haiek exekutatzen direnean ere.
Fitxategi-biltegiratzea erabiltzen denean, abiaraztean, biltegiratze-eduki osoa cachean kargatzen da: gako-identifikazioa, gako-erabiltzailea, gako-mota eta gakoa bera.
Zerbitzarian oinarritutako denda baten kasuan (adibidez, Vault Server), gakoaren IDa eta gakoaren erabiltzailea bakarrik kargatzen dira abiaraztean, beraz, gako guztiak eskuratzeak ez du abiaraztea moteltzen. Giltzak nagi kargatzen dira. Hau da, gakoa bera Vault-etik kargatzen da benetan behar denean bakarrik. Deskargatu ondoren, gakoa memorian gordetzen da, etorkizunean Vault zerbitzarirako TLS konexioen bidez atzitu beharrik izan ez dadin. Jarraian, ikus dezagun zer informazio dagoen gakoen biltegian.
Funtsezko informazioak honako hauek ditu:
- gako ID β gako-identifikatzailea, adibidez:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - gako mota β Erabilitako enkriptazio-algoritmoan oinarritutako gako-mota, balio posibleak: βAESβ, βRSAβ edo βDSAβ.
- teklaren luzera β gakoen luzera bytetan, AES: 16, 24 edo 32, RSA 128, 256, 512 eta DSA 128, 256 edo 384.
- erabiltzaile - giltzaren jabea. Gakoa sistema bada, adibidez, gako nagusia, eremu hau hutsik dago. Gako bat keyring_udf erabiliz sortzen bada, eremu honek gakoaren jabea identifikatzen du.
- giltza bera
Gakoa bakarrean identifikatzen da bikoteak: key_id, user.
Gakoak gordetzean eta ezabatzean ere aldeak daude.
Fitxategiak biltegiratzea azkarragoa da. Pentsa dezakezu gako-biltegi bat fitxategi batean gakoa behin idazten ari dela, baina ez, hemen gehiago dago. Fitxategiak biltegiratzeko aldaketa bat egiten den bakoitzean, eduki guztien babeskopia bat sortzen da lehenik. Demagun fitxategia my_biggest_secrets deitzen dela, orduan babeskopia my_biggest_secrets.backup izango dela. Ondoren, cachea aldatzen da (gakoak gehitzen edo ezabatzen dira) eta, dena arrakastatsua bada, cachea fitxategi batera berrezartzen da. Kasu bakanetan, esate baterako, zerbitzariaren hutsegite batean, babeskopia fitxategi hau ikus dezakezu. Babeskopia fitxategia gakoak kargatzen diren hurrengo aldian ezabatzen da (normalean zerbitzaria berrabiarazi ondoren).
Zerbitzari batean gako bat gordetzean edo ezabatzean, biltegiratzea MySQL zerbitzariarekin konektatu behar da "bidali gakoa" / "eskatu gakoa ezabatzea" komandoekin.
Itzuli gaitezen zerbitzariaren hasierako abiadurara. Abiaraztearen abiadura gangak berak eragina izateaz gain, abiaraztean gangako zenbat gako berreskuratu behar diren ere badago. Jakina, hau bereziki garrantzitsua da zerbitzariaren biltegiratzeko. Abiaraztean, zerbitzariak enkriptatutako taula/taula-espazioetarako zein gako behar den egiaztatzen du eta biltegiratze gakoa eskatzen du. Gako nagusi enkriptatzea duen zerbitzari "garbi" batean, gako nagusi bat egon behar da, biltegiratzetik atera behar dena. Hala ere, baliteke gako kopuru handiagoa behar izatea, adibidez, babeskopia zerbitzaria zerbitzari nagusitik babeskopia bat leheneratzen ari denean. Kasu horietan, giltza nagusiaren biraketa eman behar da. Etorkizuneko artikuluetan zehatzago azalduko da hori, nahiz eta hemen gako nagusi bat baino gehiago erabiltzen dituen zerbitzariak pixka bat gehiago behar duela abiarazteko, batez ere zerbitzariaren aldeko gako-biltegia erabiltzen denean.
Orain hitz egin dezagun pixka bat gehiago keyring_file-ri buruz. Keyring_file garatzen ari nintzela, zerbitzaria exekutatzen ari den bitartean keyring_file aldaketak nola egiaztatzeko ere kezkatzen nintzen. 5.7-n, egiaztapena fitxategien estatistiketan oinarrituta egin zen, hori ez zen irtenbide aproposa, eta 8.0-n SHA256 checksum batekin ordezkatu zen.
Keyring_file exekutatzen duzun lehen aldian, fitxategien estatistikak eta checksum bat kalkulatzen dira, zerbitzariak gogoratzen dituena, eta aldaketak bat datozenean bakarrik aplikatzen dira. Fitxategia aldatzen denean, checksum-a eguneratzen da.
Dagoeneko gako-gangelei buruzko galdera asko landu ditugu. Hala ere, bada askotan ahaztu edo gaizki ulertzen den beste gai garrantzitsu bat: zerbitzarietan gakoak partekatzea.
Zer esan nahi dut? Klusterreko zerbitzari bakoitzak (adibidez, Percona Server) kokapen bereizia izan behar du Vault Zerbitzarian eta bertan Percona zerbitzariak bere gakoak gorde behar ditu. Biltegian gordetako gako nagusi bakoitzak Percona zerbitzariaren GUID-a dauka bere identifikatzailearen barruan. Zergatik da garrantzitsua? Imajinatu Vault zerbitzari bakarra duzula eta klusterreko Percona zerbitzari guztiek Vault zerbitzari bakarra erabiltzen dutela. Arazoa begi bistakoa dirudi. Percona zerbitzari guztiek gako nagusi bat erabiliko balute identifikatzaile esklusiborik gabe, hala nola id = 1, id = 2, etab., orduan klusterreko zerbitzari guztiek gako nagusi bera erabiliko lukete. GUID-ak zerbitzarien arteko bereizketa da. Orduan, zergatik hitz egin zerbitzarien artean gakoak partekatzeaz GUID esklusibo bat existitzen bada? Bada beste plugin bat - keyring_udf. Plugin honekin, zure zerbitzariaren erabiltzaileak bere gakoak gorde ditzake Vault zerbitzarian. Arazoa gertatzen da erabiltzaile batek zerbitzaria 1 gako bat sortzen duenean, adibidez, eta ondoren zerbitzaria 2an ID berdina duen gako bat sortzen saiatzen denean, adibidez:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 Π·Π½Π°ΡΠΈΡ ΡΡΠΏΠ΅ΡΠ½ΠΎΠ΅ Π·Π°Π²Π΅ΡΡΠ΅Π½ΠΈΠ΅
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Itxaron. Bi zerbitzariak Vault zerbitzari bera erabiltzen ari dira. Interesgarria da zerbitzari batean gauza bera egiten saiatzen bazara, errore bat jasoko duzu:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Hori da, ROB_1 dagoeneko existitzen da.
Azter dezagun lehenik bigarren adibidea. Lehen esan dugun bezala, keyring_vault-ek edo beste edozein giltza-eraztunaren pluginak gako ID guztiak gordetzen ditu memorian. Beraz, gako berri bat sortu ondoren, ROB_1 zerbitzaria1 gehitzen da, eta gako hau Vault-era bidaltzeaz gain, gakoa cachean ere gehitzen da. Orain, gako bera bigarren aldiz gehitzen saiatzen garenean, keyring_vault-ek gakoa cachean dagoen egiaztatzen du eta errore bat botatzen du.
Lehenengo kasuan egoera ezberdina da. Server1 eta server2 cache bereiziak dituzte. ROB_1 zerbitzariko 1 gako-cachean eta Vault-eko zerbitzarian gehitu ondoren, zerbitzariaren gako-cachea ez dago sinkronizatuta. Server2ko cachean ez dago ROB_2 gakorik. Horrela, ROB_1 gakoa keyring_key_store-n eta Vault zerbitzarian idazten da, eta horrek (!) aurreko balioa gainidazten du. Orain Vault zerbitzariko ROB_1 gakoa 1 da. Interesgarria da, Vault zerbitzariak ez ditu horrelako ekintzak blokeatzen eta balio zaharra erraz gainidazten du.
Orain ikus dezakegu zergatik izan daitekeen garrantzitsua Vault-en zerbitzariaren partizioa - keyring_udf erabiltzen ari zarenean eta gakoak Vault-en gorde nahi dituzunean. Nola lortu bereizketa hori Vault zerbitzari batean?
Vault-en zatitzeko bi modu daude. Zerbitzari bakoitzeko muntaketa-puntu desberdinak sor ditzakezu edo bide desberdinak erabil ditzakezu muntatze-puntu berean. Hau adibideekin hobeto ilustratzen da. Beraz, ikus ditzagun lehenik muntaketa puntu indibidualak:
--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 = (...)Hemen zerbitzaria1 eta zerbitzaria2 muntaketa puntu desberdinak erabiltzen ari direla ikus dezakezu. Bideak zatitzean, konfigurazioa honela izango da:
--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 = (...)Kasu honetan, bi zerbitzariek muntatze-puntu bera erabiltzen dute "mount_point", baina bide desberdinak. Bide hau erabiliz zerbitzariaren lehen sekretua sortzen duzunean, Vault zerbitzariak automatikoki sortzen du "zerbitzaria1" direktorio bat. Server1rentzat dena antzekoa da. Mount_point/server2 edo mount_point/server1-en azken sekretua ezabatzen duzunean, Vault zerbitzariak direktorio horiek ere ezabatzen ditu. Bideen bereizketa erabiltzen baduzu, muntaketa-puntu bakarra sortu behar duzu eta konfigurazio fitxategiak aldatu, zerbitzariek bide bereiziak erabil ditzaten. Muntatze puntu bat sor daiteke HTTP eskaera erabiliz. CURL erabiliz hau honela egin daiteke:
curl -L -H "X-Vault-Token: TOKEN" βcacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTEremu guztiak (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) konfigurazio fitxategiaren parametroei dagozkie. Jakina, Vault utilitateak erabil ditzakezu gauza bera egiteko. Baina errazagoa da muntatze-puntu baten sorrera automatizatzea. Informazio hau erabilgarria izatea espero dut eta serie honetako hurrengo artikuluetan ikusiko zaitugu.
Irakurri gehiago:
Iturria: www.habr.com