En previsió de l'inici d'una nova matrícula per al curs preparat una traducció d'un article útil per a tu.
Va aparèixer el xifratge transparent de dades (TDE). i MySQL des de fa força temps. Però heu pensat mai com funciona sota el capó i quin impacte pot tenir TDE al vostre servidor? En aquesta sèrie d'articles, donarem una ullada a com funciona TDE internament. Comencem amb l'emmagatzematge de claus, ja que és necessari perquè funcioni qualsevol xifratge. A continuació, analitzarem com funciona el xifratge a Percona Server per a MySQL/MySQL i quines funcions addicionals hi ha disponibles a Percona Server per a MySQL.
Anell de claus MySQL
Els clauers són connectors que permeten al servidor consultar, crear i suprimir claus en un fitxer local (keyring_file) o en un servidor remot (per exemple, a HashiCorp Vault). Les claus sempre s'emmagatzemen a la memòria cau localment per accelerar la recuperació.
Els connectors es poden dividir en dues categories:
- Emmagatzematge local. Per exemple, un fitxer local (l'anomenem anell de claus basat en fitxers).
- emmagatzematge remot. Per exemple, Vault Server (l'anomenem clauer basat en servidor).
Aquesta separació és important perquè els diferents tipus d'emmagatzematge es comporten de manera lleugerament diferent no només quan s'emmagatzemen i es recuperen les claus, sinó també quan s'inicien.
Quan s'utilitza l'emmagatzematge de fitxers, tot el contingut de l'emmagatzematge es carrega a la memòria cau a l'inici: identificador de clau, usuari de clau, tipus de clau i la pròpia clau.
En el cas d'una botiga de fons (per exemple, el servidor Vault), només es carreguen l'identificador de la clau i l'usuari de la clau a l'inici, de manera que obtenir totes les claus no retarda l'inici. Les claus es carreguen amb mandra. És a dir, la clau en si es carrega des de Vault només quan realment es necessita. Després de la descàrrega, la clau s'emmagatzema a la memòria cau de manera que en el futur no calgui accedir-hi mitjançant connexions TLS al servidor Vault. A continuació, tingueu en compte quina informació hi ha al magatzem de claus.
La informació clau conté el següent:
- identificador de clau - identificador de clau, per exemple:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - tipus de clau - tipus de clau en funció de l'algorisme de xifratge utilitzat, valors possibles: "AES", "RSA" o "DSA".
- longitud de la clau - Longitud de la clau en bytes, AES: 16, 24 o 32, RSA 128, 256, 512 i DSA 128, 256 o 384.
- user és el propietari de la clau. Si la clau és una clau del sistema, com ara la clau mestra, aquest camp està buit. Si la clau es crea amb keyring_udf, aquest camp indica el propietari de la clau.
- la clau en si
La clau s'identifica de manera única per la parella: key_id, user.
També hi ha diferències en l'emmagatzematge i la supressió de claus.
L'emmagatzematge de fitxers és més ràpid. Podríeu pensar que el magatzem de claus és només una escriptura única de la clau en un fitxer, però no ho és, aquí hi ha més coses. Sempre que es modifica un emmagatzematge de fitxers, primer es fa una còpia de seguretat de tot el contingut. Suposem que el fitxer s'anomena my_biggest_secrets, llavors la còpia de seguretat serà my_biggest_secrets.backup. A continuació, es canvia la memòria cau (s'afegeixen o s'eliminen les claus) i, si tot té èxit, la memòria cau s'aboca a un fitxer. En casos rars, com ara un error del servidor, és possible que vegeu aquest fitxer de còpia de seguretat. El fitxer de còpia de seguretat s'elimina la propera vegada que es carreguin les claus (normalment després d'un reinici del servidor).
Quan deseu o suprimiu una clau a la botiga del servidor, la botiga s'ha de connectar al servidor MySQL amb les ordres "enviar la clau" / "sol·licitar supressió de clau".
Tornem a la velocitat d'inici del servidor. A més del fet que la pròpia caixa de seguretat afecta la velocitat d'inici, també hi ha la qüestió de quantes claus de la caixa de seguretat s'han d'obtenir a l'inici. Per descomptat, això és especialment important per als emmagatzematges del servidor. A l'inici, el servidor comprova quina clau és necessària per a les taules/espais de taula xifrats i demana la clau a l'emmagatzematge. En un servidor "net" amb una clau mestra: hi ha d'haver una clau mestra per a l'encriptació, que s'ha de recuperar de l'emmagatzematge. Tanmateix, es poden requerir més claus, per exemple, quan es restaura una còpia de seguretat del servidor principal a un servidor d'espera. En aquests casos, s'ha de proporcionar la rotació de la clau mestra. Això es discutirà amb més detall en articles futurs, tot i que aquí m'agradaria assenyalar que un servidor que utilitza diverses claus mestres pot trigar una mica més a començar, especialment quan s'utilitza un magatzem de claus de servidor.
Ara parlem una mica més sobre keyring_file. Quan estava dissenyant el keyring_file, també em preocupava com comprovar els canvis keyring_file mentre el servidor s'està executant. A la 5.7, la comprovació es va realitzar en funció de les estadístiques de fitxers, que no era l'ideal, i a la 8.0 es va substituir per una suma de verificació SHA256.
La primera vegada que s'executa keyring_file, el servidor calcula i recorda les estadístiques del fitxer i la suma de comprovació, i els canvis només s'apliquen si coincideixen. Quan el fitxer canvia, la suma de comprovació s'actualitza.
Ja hem cobert moltes preguntes sobre les botigues de claus. Tanmateix, hi ha un altre tema important que sovint s'oblida o s'entén malament: compartir claus entre servidors.
El que vull dir? Cada servidor (per exemple, Percona Server) del clúster ha de tenir una ubicació independent al Vault Server on el Percona Server ha d'emmagatzemar les seves claus. Cada clau mestra emmagatzemada a la volta conté el GUID del servidor Percona dins del seu ID. Per què és important? Imagineu que només teniu un servidor Vault i tots els servidors Percona del clúster utilitzen aquest únic servidor Vault. El problema sembla evident. Si tots els servidors de Percona feien servir una clau mestra sense identificadors únics, com ara id = 1, id = 2, etc., tots els servidors del clúster utilitzarien la mateixa clau mestra. Això és el que proporciona el GUID: la distinció entre servidors. Aleshores, per què parlar de compartir claus entre servidors si ja hi ha un GUID únic? Hi ha un altre connector: keyring_udf. Amb aquest connector, un usuari del vostre servidor pot emmagatzemar les seves claus al servidor Vault. El problema es produeix quan un usuari crea una clau, per exemple, al servidor1, i després intenta crear una clau amb el mateix ID al servidor2, per exemple:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Espera. Els dos servidors utilitzen el mateix servidor Vault, no hauria de fallar la funció keyring_key_store al server2? Curiosament, si intenteu fer el mateix al mateix servidor, obtindreu un error:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0És cert, ROB_1 ja existeix.
Parlem primer del segon exemple. Com hem dit anteriorment, keyring_vault o qualsevol altre connector de volta (keyring) guarda a la memòria cau tots els ID de clau a la memòria. Per tant, després de crear una nova clau, ROB_1 s'afegeix al servidor1 i, a més d'enviar aquesta clau a Vault, la clau també s'afegeix a la memòria cau. Ara, quan intentem afegir la mateixa clau una segona vegada, keyring_vault comprova si la clau existeix a la memòria cau i genera un error.
En el primer cas, la situació és diferent. El servidor1 i el servidor2 tenen memòria cau separades. Després d'afegir ROB_1 a la memòria cau de claus del servidor1 i al servidor de Vault, la memòria cau de claus del servidor2 està fora de sincronització. La memòria cau del servidor2 no conté la clau ROB_1. Així, la clau ROB_1 s'escriu al keyring_key_store i al servidor Vault, que en realitat sobreescriu (!) el valor anterior. Ara, la clau ROB_1 del servidor Vault és 543210987654321. Curiosament, el servidor Vault no bloqueja aquestes accions i sobreescriu fàcilment el valor antic.
Ara veiem per què la segregació per servidor a Vault pot ser important quan utilitzeu keyring_udf i voleu emmagatzemar claus a Vault. Com proporcionar aquesta separació al servidor Vault?
Hi ha dues maneres de particionar a Vault. Podeu crear diferents punts de muntatge per a cada servidor o utilitzar diferents camins dins del mateix punt de muntatge. La millor manera de mostrar-ho és amb exemples. Per tant, primer mirem els punts de muntatge individuals:
--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 = (...)Aquí podeu veure que el servidor1 i el servidor2 utilitzen diferents punts de muntatge. Amb la separació de camins, la configuració es veurà així:
--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 = (...)En aquest cas, ambdós servidors utilitzen el mateix punt de muntatge "mount_point" però diferents camins. Quan creeu el primer secret al servidor1 mitjançant aquest camí, el servidor Vault crea automàticament un directori "servidor1". Per al servidor2, tot és igual. Quan suprimiu l'últim secret a punt_muntatge/servidor1 o punt_muntatge/servidor2, el servidor Vault també suprimirà aquests directoris. En cas que utilitzeu camins dividits, només heu de crear un punt de muntatge i canviar els fitxers de configuració perquè els servidors utilitzin camins separats. Es pot crear un punt de muntatge amb una sol·licitud HTTP. Amb CURL això es pot fer així:
curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTTots els camps (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) corresponen als paràmetres del fitxer de configuració. Per descomptat, podeu utilitzar les utilitats Vault per fer el mateix. Però és més fàcil automatitzar la creació d'un punt de muntatge. Espero que aquesta informació us sigui útil i ens veiem als propers articles d'aquesta sèrie.
Llegeix més:
Font: www.habr.com