Kryptering i MySQL: nyckellagring

Inför starten av det nya kursutbudet Databaser har vi förberett en översättning av en användbar artikel.

Transparent datakryptering (Transparent Data Encryption, TDE) introducerades i Percona Server for MySQL och MySQL för ganska länge sedan. Men har du någonsin funderat på hur det fungerar under huven och vilken påverkan TDE kan ha på din server? I den här artikelserien kommer vi att titta på hur TDE fungerar internt. Vi börjar med nyckellagring, eftersom det behövs för att allt kryptering ska fungera. Därefter kommer vi att titta mer i detalj på hur kryptering fungerar i Percona Server for MySQL / MySQL och vilka extra funktioner som finns i Percona Server for MySQL.

MySQL Keyring

Keyring är plugins som låter servern begära, skapa och ta bort nycklar i en lokal fil (keyring_file) eller på en fjärrserver (till exempel i HashiCorp Vault). Nycklarna cachas alltid lokalt för att påskynda åtkomsten.

Plugins kan delas in i två kategorier:

• Lokal lagring. Till exempel en lokal fil (vi kallar detta ett filbaserat nyckellager, file-based keyring).
• Fjärrlagring. Till exempel Vault Server (vi kallar detta ett serverbaserat nyckellager, server-based keyring).

Denna uppdelning är viktig eftersom olika typer av lagring beter sig något olika, inte bara vid lagring och hämtning av nycklar, utan också vid start.

Vid användning av filbaserat lager laddas allt innehåll i lagret vid start i cachen: key id, key user, key type och själva nyckeln.

I fallet med serverbaserat lager (till exempel Vault-servern) laddas endast key id och key user vid start, så att hämtning av alla nycklar inte fördröjer starten. Nycklarna laddas latinskt. Det innebär att själva nyckeln endast laddas från Vault när den faktiskt behövs. Efter att ha laddats cachas nyckeln i minnet för att det i framtiden inte ska behöva göras en TLS-koppling till Vault Server för att hämta den. Låt oss nu titta på vilken information som finns i nyckellagret.

Nyckelinformationen innehåller följande:

• key id — nyckelidentifierare, till exempel:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• key type — nyckeltyp, baserad på den använda krypteringsalgoritmen, möjliga värden: "AES", "RSA" eller "DSA".
• key length — nyckellängd i byte, AES: 16, 24 eller 32, RSA 128, 256, 512 och DSA 128, 256 eller 384.
• användare — nyckelns ägare. Om nyckeln är systemnyckel, till exempel Master Key, är detta fält tomt. Om nyckeln skapas med hjälp av keyring_udf, anger detta fält nyckelns ägare.
• nyckeln

Nyckeln identifieras entydigt med ett par: key_id, user.

Det finns också skillnader i lagring och borttagning av nycklar.

Fil lagringen är snabbare. Man kan anta att nyckellagringen är en enkel engångsinmatning av nyckeln i en fil, men så är det inte – här sker fler operationer. Vid varje modifiering av fil lagringen skapas först en säkerhetskopia av allt innehåll. Anta att filen heter my_biggest_secrets, då kommer säkerhetskopian att heta my_biggest_secrets.backup. Därefter ändras cachen (nycklar läggs till eller tas bort) och om allt går bra, återställs cachen till filen. I sällsynta fall, som vid serverfel, kan du se denna säkerhetskopia. Säkerhetskopian tas bort vid nästa laddning av nycklarna (vanligtvis efter omstart av servern).

När en nyckel sparas eller tas bort i serverlagring, måste lagringen ansluta till MySQL-servern med kommandona "skicka nyckel" / "begära borttagning av nyckel" ("send the key" / "request key deletion").

Låt oss återgå till serverns starttid. Förutom att lagringens hastighet påverkar starttiden, finns det också frågan om hur många nycklar som behöver hämtas från lagringen vid start. Detta är särskilt viktigt för serverlagringar. Vid uppstart kontrollerar servern vilken nyckel som krävs för de krypterade tabellerna / tabellutrymmena och begär nyckeln från lagringen. På en "ren" server med Master Key -kryptering ska det finnas en Master Key som måste hämtas från lagringen. Det kan dock krävas fler nycklar, till exempel när en säkerhetskopia återställs från huvudservern till en reservserver. I sådana fall bör rotation av Master Key övervägas. Detta kommer att diskuteras mer i kommande artiklar, men här skulle jag vilja nämna att en server som använder flera Master Keys kan starta lite längre, särskilt vid användning av serverlagring av nycklar.

Låt oss nu prata lite mer om keyring_file. När jag utvecklade keyring_file var jag också bekymrad över hur man kontrollerar ändringar av keyring_file medan servern är i drift. I version 5.7 utfördes kontrollen baserat på filens statistik, vilket inte var en idealisk lösning, och i version 8.0 ersattes det med en SHA256-kontrollsumma.

Vid första körning beräknas statistik för keyring_file och en kontrollsumma, som sparas av servern, och ändringar tillämpas endast om de stämmer överens. Vid ändring av filen uppdateras kontrollsumman.

Vi har redan diskuterat många frågor om nyckellager. Men det finns ett annat viktigt ämne som ofta glöms bort eller missförstås – separation av nycklar mellan servrar.

Vad menar jag med detta? Varje server (till exempel Percona Server) i en kluster måste ha en separat plats på Vault-servern där Percona Server ska lagra sina nycklar. I varje Master Key som sparas i lagret finns en GUID för Percona Server inuti dess identifierare. Varför är detta viktigt? Föreställ dig att du har en enda Vault-server och alla Percona-servrar i klustret använder denna enda Vault-server. Problemet verkar uppenbart. Om alla Percona-servrar använde Master Key utan unika identifierare, till exempel id = 1, id = 2 osv., skulle alla servrar i klustret använda samma Master Key. Vad som säkerställs av GUID — avgränsning mellan servrar. Varför prata då om separation av nycklar mellan servrar när det redan finns en unik GUID? Det finns en annan plugin — keyring_udf. Med denna plugin kan användaren av din server lagra sina nycklar på Vault-servern. Problemet uppstår när användaren skapar en nyckel, till exempel på server server1, och sedan försöker skapa en nyckel med samma identifierare på server2.

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 betyder lyckad avslutning
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

Vänta. Båda servrarna använder samma Vault-server, borde inte funktionen keyring_key_store avslutas med ett fel på server server2? Intressant nog, om du försöker göra samma sak på en och samma server, får du ett fel:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

Rätt, ROB_1 finns redan.

Låt oss först diskutera det andra exemplet. Som vi tidigare nämnt, cache:ar keyring_vault eller vilken annan lagringsplugin (keyring) alla nyckelidentifierare i minnet. Så, efter att en nyckel skapats, läggs ROB_1 till på server1, och förutom att skicka denna nyckel till Vault, läggs nyckeln också till i cachen. Nu, när vi försöker lägga till samma nyckel en andra gång, kontrollerar keyring_vault om denna nyckel redan finns i cachen och ger ett felmeddelande.

I det första fallet är situationen en annan. På servrarna server1 och server2 finns separata cacher. Efter att ha lagt till ROB_1 i cache:en av nycklar på server1 och server Vault, är nyckelcachen på server2 inte synkroniserad. I cachen på server2 finns det ingen nyckel ROB_1. Således skrivs nyckeln ROB_1 in i keyring_key_store och på server Vault, vilket faktiskt skriver över (!) det tidigare värdet. Nu är nyckeln ROB_1 på server Vault lika med 543210987654321. Det är intressant att server Vault inte blockerar sådana åtgärder och enkelt skriver över det gamla värdet.

Nu ser vi varför uppdelningen över servrar på Vault kan vara viktig — när du använder keyring_udf och vill lagra nycklar i Vault. Hur säkerställer man en sådan uppdelning på server Vault?

Det finns två sätt att uppdelning på Vault. Man kan skapa olika monteringspunkter för varje server eller använda olika sökvägar inom en och samma monteringspunkt. Det är bäst att visa detta med exempel. Så, låt oss först titta på separata monteringspunkter:

--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 ser vi att server1 och server2 använder olika monteringspunkter. Vid uppdelning av sökvägar skulle konfigurationen se ut på följande sätt:

--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 = (...)

I det här fallet använder båda servrarna samma monteringspunkt "mount_point", men olika sökvägar. När den första hemligheten skapas på servern server1 på denna väg skapar Vault-servern automatiskt katalogen "server1". För server2 är allt likadant. När du tar bort den sista hemligheten i mount_point/server1 eller mount_point/server2, tar Vault-servern också bort dessa kataloger. Om du använder separering av sökvägar måste du skapa endast en monteringspunkt och ändra konfigurationsfilerna så att servrarna använder separata sökvägar. Monteringspunkten kan skapas med en HTTP-förfrågan. Med CURL kan detta göras på följande sätt:

curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINT

Alla fält (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) motsvarar parametrarna i konfigurationsfilen. Självklart kan du använda Vault-verktyg för att göra samma sak. Men det är lättare att automatisera skapandet av monteringspunkten. Jag hoppas att denna information är användbar för dig, och vi ses i nästa artiklar i den här serien.

Läs mer:

• Sysbench och fördelningen av slumpmässiga variabler

Källa: habr.com