I forventning om start af ny tilmelding til kurset Vi fortsætter med at udgive en række artikler om kryptering i MySQL.
I den forrige artikel i denne serie diskuterede vi, . I dag vil vi, baseret på den viden opnået tidligere, se på rotationen af hovednøglerne.
Hovednøglerotation involverer generering af en ny hovednøgle og genkryptering af tablespace-nøglerne (gemt i tablespace-headerne) med denne nye nøgle.
Lad os huske, hvordan den krypterede tablespace-header ser ud:
Fra den forrige artikel ved vi, at serveren læser headerne på alle krypterede tablespaces, når den starter og husker det største KEY ID. For eksempel hvis vi har tre borde med KEYID = 3 og en tabel med NØGLEID = 4, så vil det maksimale nøgle-ID være 4. Lad os kalde dette NØGLE-ID - MAKS. NØGLE-ID.
Hvordan Master Key Rotation fungerer
1. Brugeren udfører ALTER INNODB MASTER KEY.
2. Serveren anmoder nøgleringen om at generere en ny hovednøgle fra serverens UUID og KEYID lig med MAX plus énKEYID. Således får vi hovednøgleidentifikatoren lig med INNODBNØGLE-UUID-(MAXKEYID + 1). Når hovednøglen er genereret, øges MAKS NØGLE-ID'et med én (dvs. MAKS.KEYID = MAXKEYID + 1).
3. Serveren scanner alle tablespaces krypteret med masternøglen og for hvert tablespace:
krypterer tablespace-nøglen med den nye hovednøgle;
opdaterer nøgle-id'et til den nye MAXKEYID;
hvis UUID'en adskiller sig fra serverens UUID, opdateres serverens UUID.
Som vi ved, består Master Key ID, der bruges til at dekryptere tabellen, af UUID og KEY ID læst fra tablespace headeren. Det, vi gør nu, er at opdatere disse oplysninger i tablespace-krypteringsheaderen, så serveren får den korrekte hovednøgle.
Hvis vi har tablespaces, der kommer fra forskellige steder, såsom forskellige backups, kan de bruge forskellige hovednøgler. Alle disse hovednøgler skal hentes fra lageret, når serveren starter. Dette kan forsinke serverstarten, især hvis du bruger et serverbaseret nøglelager. Med masternøglerotation genkrypterer vi tablespace-nøgler med en enkelt masternøgle, der er den samme for alle tablespaces. Nu, når serveren starter, bør den kun modtage én hovednøgle.
Dette er selvfølgelig bare en behagelig bivirkning. Hovedformålet med at rotere hovednøgler er at gøre vores server mere sikker. Hvis hovednøglen på en eller anden måde blev stjålet fra vaulten (f.eks. fra Vault Server), kan en ny hovednøgle genereres, og tablespace-nøglerne kan genkrypteres, hvilket gør den stjålne nøgle ugyldig. Vi er i sikkerhed... næsten.
I den forrige artikel talte jeg om, hvordan når en tablespace-nøgle er stjålet, kan en tredjepart bruge den til at dekryptere data. Forudsat at der er adgang til vores disk. Hvis hovednøglen er stjålet, og du har adgang til de krypterede data, kan du bruge den stjålne hovednøgle til at dekryptere tablespace-nøglen og hente de dekrypterede data. Som vi kan se, hjælper det ikke i dette tilfælde at dreje hovednøglen. Vi genkrypterer tablespace-nøglen med den nye hovednøgle, men den faktiske nøgle, der bruges til at kryptere/dekryptere dataene, forbliver den samme. Derfor kan "hackeren" fortsætte med at bruge den til at dekryptere data. Det antydede jeg tidligere kan udføre ægte tablespace-genkryptering, ikke bare simpel tablespace-genkryptering. Denne funktion kaldes krypteringstråde. Denne funktionalitet er dog stadig eksperimentel på nuværende tidspunkt.
Hovednøglerotation er nyttig, når hovednøglen er stjålet, men angriberen har ingen mulighed for at bruge den og dekryptere tablespace-nøglerne.
Læs mere:
Kilde: www.habr.com
