Pred spustením nového kurzu pripravili sme pre vás preklad užitočného článku.
Transparentné šifrovanie údajov (Transparent Data Encryption, TDE) sa objavilo v a MySQL už dosť dávno. Ale zamysleli ste sa niekedy nad tým, ako funguje pod pokrievkou a aký vplyv môže mať TDE na váš server? V tejto sérii článkov si podrobne rozoberieme, ako TDE funguje vo vnútri. Začneme so skladovaním kľúčov, pretože je potrebné na akékoľvek šifrovanie. Následne sa podrobne pozrieme na to, ako funguje šifrovanie v Percona Server for MySQL/MySQL a aké ďalšie možnosti ponúka Percona Server for MySQL.
MySQL Keyring
Keyring — to sú pluginy, ktoré umožňujú serveru žiadať, vytvárať a odstraňovať kľúče v lokálnom súbore (keyring_file) alebo na vzdialenom serveri (napríklad v HashiCorp Vault). Kľúče sa vždy ukladajú do cache lokálne, aby sa urýchlil ich prístup.
Pluginy môžeme rozdeliť do dvoch kategórií:
- Lokálne úložisko. Napríklad lokálny súbor (nazývame to súborové úložisko kľúčov, file-based keyring).
- Vzdialené úložisko. Napríklad Vault Server (nazývame to serverové úložisko kľúčov, server-based keyring).
Toto rozdelenie je dôležité, pretože rôzne typy úložísk sa správajú trochu inak nielen pri ukladaní a získavaní kľúčov, ale aj pri spustení.
Pri použití súborového úložiska sa pri spustení do cache načíta celý obsah úložiska: key id, key user, key type a samotný kľúč.
V prípade serverového úložiska (napríklad server Vault) sa pri spustení načíta len key id a key user, preto získanie všetkých kľúčov nezdržuje spustenie. Kľúče sa načítavajú len vtedy, keď sú skutočne potrebné. Po načítaní sa kľúč ukladá do cache v pamäti, aby v budúcnosti nebolo potrebné požiadať oň cez TLS pripojenia na Vault Server. Teraz si pozrieme, aké informácie sú k dispozícii v úložisku kľúčov.
Informácie o kľúči obsahujú nasledujúce:
- key id — identifikátor kľúča, napríklad:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - key type — typ kľúča, ktorý je založený na použitom algoritme šifrovania, možné hodnoty: „AES“, „RSA“ alebo „DSA“.
- key length — dĺžka kľúča v bajtoch, AES: 16, 24 alebo 32, RSA 128, 256, 512 a DSA 128, 256 alebo 384.
- user — vlastník kľúča. Ak je kľúč systémový, napríklad Master Key, toto pole zostáva prázdne. Ak je kľúč vytvorený pomocou keyring_udf, toto pole označuje vlastníka kľúča.
- samotný kľúč
Kľúč sa jednoznačne identifikuje dvojicou: key_id, user.
Existujú aj rozdiely v uložení a odstraňovaní kľúčov.
Súborové úložisko funguje rýchlejšie. Je možné predpokladať, že úložisko kľúčov je len jednoduché jednorazové zapísanie kľúča do súboru, ale nie — tu prebieha viac operácií. Pri akejkoľvek modifikácii súborového úložiska sa najskôr vytvorí záloha celého obsahu. Predpokladajme, že súbor sa nazýva my_biggest_secrets, záloha teda bude my_biggest_secrets.backup. Potom sa zmení cache (pridajú alebo odstránia kľúče) a ak je všetko úspešne vykonané, cache sa vymaže do súboru. V zriedkavých prípadoch, ako je zlyhanie servera, môžete vidieť tento záložný súbor. Súbor zálohy sa odstraňuje pri nasledujúcom načítaní kľúčov (zvyčajne po reštarte servera).
Pri uložení alebo odstránení kľúča v serverovom úložisku sa úložisko musí pripojiť k serveru MySQL s príkazmi „odošli kľúč“ / „požiadanie o odstránenie kľúča“ („send the key“ / „request key deletion“).
Teraz sa vráťme k rýchlosti spustenia servera. Okrem toho, že na rýchlosť spustenia vplýva samotné úložisko, je tu aj otázka, koľko kľúčov z úložiska je potrebné získať pri spustení. Samozrejme, to je obzvlášť dôležité pre serverové úložiská. Pri spustení server kontroluje, ktorý kľúč je potrebný pre šifrované tabuľky / tabuľkové priestory a požaduje kľúč z úložiska. Na „čistom“ serveri so šifrovaním Master Key by mal byť iba jeden Master Key, ktorý je potrebné vytiahnuť z úložiska. Môže však byť potrebné aj viac kľúčov, napríklad pri obnove zálohy na záložnom serveri z hlavného servera. V takýchto prípadoch by sa mal predpokladať cyklus rotácie Master Key. Podrobnejšie sa tým budeme zaoberať v budúcich článkoch, hoci tu by som rád poznamenal, že server používajúci niekoľko Master Key môže spúšťať o niečo dlhšie, najmä pri použití serverového úložiska kľúčov.
Teraz sa ešte trochu porozprávajme o keyring_file. Keď som vyvíjal keyring_file, tiež ma zaujímalo, ako kontrolovať zmeny v keyring_file počas prevádzky servera. V 5.7 sa kontrola vykonávala na základe štatistiky súboru, čo nebolo ideálne riešenie, a v 8.0 bolo nahradené kontrolným súčtom SHA256.
Pri prvom spustení sa vypočíta štatistika súboru a kontrolná suma pre keyring_file, ktoré server uloží, a zmeny sa aplikujú iba v prípade, že sa zhodujú. Pri zmene súboru sa kontrolná suma aktualizuje.
Už sme prebrali mnohé otázky týkajúce sa úložísk kľúčov. Existuje však ešte jedna dôležitá téma, na ktorú sa často zabúda alebo sa nesprávne chápe – rozdelenie kľúčov podľa serverov.
Čo mám na mysli? Každý server (napríklad Percona Server) v klastri musí mať samostatné miesto na serveri Vault, kde musí Percona Server uchovávať svoje kľúče. Každý Master Key uložený v úložisku obsahuje GUID servera Percona Server vo svojom identifikátore. Prečo je to dôležité? Predstavte si, že máte iba jeden Vault Server a všetky Percona Servery v klastri používajú tento jediný Vault Server. Problém sa zdá byť očividný. Keby všetky Percona Servery používali Master Key bez jedinečných identifikátorov, napríklad id = 1, id = 2 a pod., všetky servery v klastri by používali ten istý Master Key. GUID zabezpečuje rozdelenie medzi servermi. Prečo teda hovoriť o rozdelení kľúčov medzi servermi, ak už existuje jedinečný GUID? Existuje ešte jeden plugin – keyring_udf. S pomocou tohto pluginu môže používateľ vášho servera uchovávať svoje kľúče na serveri Vault. Problém nastáva, keď používateľ vytvorí kľúč napríklad na serveri server1 a potom sa pokúsi vytvoriť kľúč s tým istým identifikátorom na serveri server2, napríklad:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 znamená úspešné dokončenie
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Počkajte. Oba servery používajú rovnaký Vault Server, nemala by funkcia keyring_key_store skončiť s chybou na serveri server2? Zaujímavé je, že ak sa pokúsite urobiť to isté na jednom serveri, dostanete chybu:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Správne, ROB_1 už existuje.
Poďme sa najskôr podrobne zaoberať druhým príkladom. Ako sme už spomenuli, keyring_vault, alebo akýkoľvek iný plugin úložiska (keyring), cache všetky identifikátory kľúčov v pamäti. Takže, po vytvorení nového kľúča, ROB_1 sa pridáva na server1, a okrem odoslania tohto kľúča do Vault sa kľúč tiež pridáva do cache. Teraz, keď sa pokúšame pridať rovnaký kľúč po druhý raz, keyring_vault kontroluje, či tento kľúč existuje v cache a vráti chybu.
V prvom prípade je situácia iná. Na serveroch server1 a server2 sú samostatné cache. Po pridaní ROB_1 do cache kľúčov na serveri server1 a server Vault, cache kľúčov na serveri server2 nie je synchronizovaná. V cache na serveri server2 nie je kľúč ROB_1. Takže, kľúč ROB_1 je zapísaný do keyring_key_store a na server Vault, ktorý vlastne prepíše (!) predchádzajúcu hodnotu. Teraz je kľúč ROB_1 na serveri Vault rovný 543210987654321. Zaujímavé je, že server Vault takéto akcie neblokuje a bez problémov prepíše starú hodnotu.
Teraz vidíme, prečo môže byť dôležité rozdelenie podľa serverov na Vault — keď používate keyring_udf a chcete ukladať kľúče v Vault. Ako zabezpečiť takéto rozdelenie na serveri Vault?
Existujú dva spôsoby, ako vykonať rozdelenie na Vault. Môžete vytvoriť rôzne montažné body pre každý server alebo použiť rôzne cesty v rámci jedného montažného bodu. Najlepšie to ukázať na príkladoch. Takže, pozrime sa najprv na samostatné montažné body:
--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 = server2_mount
token = (...)
vault_ca = (...)Tu je zrejmé, že server1 a server2 používajú rôzne montažné body. Pri delení ciest bude konfigurácia vyzerať nasledovne:
--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/server2
token = (...)
vault_ca = (...)V tomto prípade oba servery používajú rovnaký bod pripojenia „mount_point“, ale rôzne cesty. Pri vytváraní prvého tajného kľúča na serveri server1 na tejto ceste server Vault automaticky vytvára adresár „server1“. Pre server2 platí to isté. Keď odstránite posledný tajný kľúč v mount_point/server1 alebo mount_point/server2, server Vault tiež odstráni tieto adresáre. V prípade, že používate oddelenie ciest, musíte vytvoriť iba jeden bod pripojenia a zmeniť konfiguračné súbory, aby servery používali samostatné cesty. Bod pripojenia možno vytvoriť prostredníctvom HTTP požiadavky. Pomocou CURL to možno urobiť nasledujúcim spôsobom:
curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTVšetky polia (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) zodpovedajú parametroch konfiguračného súboru. Samozrejme, môžete využiť utilitky Vault, aby ste dosiahli to isté. Ale takto je jednoduchšie automatizovať vytvorenie bodu pripojenia. Dúfam, že tieto informácie budú pre vás užitočné a stretneme sa v nasledujúcich článkoch tejto série.
Čítať ďalej:
Zdroj: habr.com
