I forklaringen af den nye optagelse til kurset fortsætter vi med at offentliggøre en serie artikler om kryptering i MySQL.
I den forrige artikel i denne serie diskuterede vi, I dag, baseret på de tidligere indhøstede viden, vil vi se på rotationen af hovednøgler.
Rotation af hovednøgler indebærer, at der genereres en ny hovednøgle, og denne nye nøgle bruges til at kryptere tabellerummets nøgler (som opbevares i tabellerummets overskrifter) igen.
Lad os genkalde os, hvordan overskriften for det krypterede tabellerum ser ud:
Fra den tidligere artikel ved vi, at serveren ved opstart læser overskrifterne for alle krypterede tabellerum og husker den største KEY ID. For eksempel, hvis vi har tre tabeller med KEYID = 3 og én tabel med KEYID = 4, så vil den maksimale nøgleidentifikation være lig med 4. Lad os kalde denne KEY ID — MAX KEY ID.
Hvordan fungerer rotationen af hovednøglen
1. Brugeren udfører ALTER INNODB MASTER KEY.
2. Serveren beder om, at der i nøglelageret (keyring) genereres en ny hovednøgle med serverens UUID og KEYID, lig med den forøgede MAXKEYID. På den måde får vi en hovednøgleidentifikation lig med INNODBKEY-UUID- (MAXKEYID + 1). Ved en vellykket generering af hovednøglen øges MAX KEY ID med én (dvs. MAXKEYID = MAXKEYID + 1).
3. Serveren gennemgår alle tabellerum, der er krypteret med hovednøglen, og for hvert tabellerum:
krypterer tabellerummets nøgle med den nye hovednøgle;
opdaterer nøgleidentifikatoren til ny MAXKEYID;
hvis UUID'en adskiller sig fra serverens UUID, opdateres serverens UUID.
Som vi ved, består hovednøgleidentifikatoren (Master Key ID), der bruges til at dekryptere tabellen, af UUID og KEY ID, der er læst fra tabellerummets overskrift. Hvad vi gør nu, er at opdatere disse informationer i overskriften for krypteringen af tabellerummet, så serveren får den korrekte hovednøgle.
Hvis vi har tabelrum, der er hentet fra forskellige kilder, for eksempel fra forskellige sikkerhedskopier, kan de have forskellige master-nøgler. Alle disse master-nøgler skal hentes fra lageret, når serveren startes. Dette kan forsinke opstarten af serveren, især hvis der bruges en serveralgningsnøglehåndtering. Ved hjælp af rotation af master-nøglen genkrypterer vi nøglerne i tabelrummene med én master-nøgle, der er den samme for alle tabelrum. Nu skal serveren kun hente én master-nøgle under opstart.
Dette er selvfølgelig kun en behagelig bivirkning. Hovedformålet med rotationen af master-nøglerne er at gøre vores server mere sikker. Hvis master-nøglen på nogen måde er blevet stjålet fra lageret (for eksempel fra Vault Server), kan der genereres en ny master-nøgle, og nøglerne i tabelrummene kan genkrypteres, hvilket gør den stjålne nøgle ugyldig. Vi er sikre... næsten.
I den tidligere artikel nævnte jeg, at efter stjælingen af en tabelrumsnøgle kan en tredjepart bruge den til at dekryptere data. Forudsat at der er adgang til vores disk. I tilfælde af stjåling af master-nøglen og hvis der er adgang til de krypterede data, kan den stjålne master-nøgle bruges til at dekryptere tabelrumsnøglen og få adgang til de dekrypterede data. Som vi kan se, hjælper rotationen af master-nøglen ikke i dette tilfælde. Vi genkrypterer tabelrumnøglen med den nye master-nøgle, men den faktiske nøgle, der bruges til kryptering / dekryptering af data, forbliver den samme. Derfor kan „hackeren“ fortsætte med at bruge den til at dekryptere data. Tidligere antydede jeg, at kan udføre ægte genkryptering af tabelrum, og ikke bare simpel genkryptering af tabelrumsnøglen. Denne funktion kaldes krypteringsstrømme (encryption threads). Men på nuværende tidspunkt er denne funktionalitet stadig eksperimentel.
Rotation af master-nøglen er nyttig, når master-nøglen er blevet stjålet, men angriberen ikke har mulighed for at bruge den og dekryptere tabelrumnøglerne.
Læs mere:
Kilde: habr.com
