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, baseret på den viden, der er opnået tidligere, lad os se på rotationen af hovedtasterne.
Hovednøglerotation involverer generering af en ny hovednøgle og genkryptering af tablespace-nøglerne (som er gemt i tablespace-headerne) med denne nye nøgle.
Lad os huske, hvordan overskriften på et krypteret tablespace ser ud:
Fra den forrige artikel ved vi, at serveren læser headerne på alle krypterede tablespaces ved opstart 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.
Sådan fungerer hovednøglerotation
1. Brugeren udfører ALTER INNODB MASTER KEY.
2. Serveren anmoder nøgleringen om at generere en ny hovednøgle med serverens UUID og KEYID lig med én plus MAXKEYID. Så vi får hovednøgle-id svarende til INNODBNØGLE-UUID-(MAXKEYID + 1). Ved vellykket generering af hovednøglen øges MAX NØGLE ID med én (dvs. MAXKEYID=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 er forskellig fra serverens UUID, skal du opdatere serverens UUID.
Som vi ved, består hovednøgle-id'et, der bruges til at dekryptere en tabel, af et UUID og et NØGLE-ID, der læses fra tablespace-headeren. Det, vi gør nu, er at opdatere disse oplysninger i tablespace-krypteringsheaderen, så serveren modtager den korrekte hovednøgle.
Hvis vi har tablespaces fra forskellige lokationer, såsom forskellige sikkerhedskopier, så kan de bruge forskellige hovednøgler. Alle disse hovednøgler skal hentes fra lageret, når serveren startes. Dette kan sinke serverstarten, især hvis der bruges et nøglelager på serversiden. Med masternøglerotation genkrypterer vi tablespace-nøgler med en enkelt masternøgle, der er den samme for alle tablespaces. Serveren skulle nu kun modtage én hovednøgle ved opstart.
Dette er selvfølgelig bare en behagelig bivirkning. Hovedformålet med rotation af hovednøgler er at gøre vores server mere sikker. I tilfælde af at hovednøglen på en eller anden måde blev stjålet fra vaulten (for eksempel fra Vault Server), er det muligt at generere en ny hovednøgle og genkryptere tablespace-nøglerne, hvilket gør den stjålne nøgle ugyldig. Vi er i sikkerhed ... næsten.
I en tidligere artikel talte jeg om, hvordan når en tablespace-nøgle er stjålet, kan en tredjepart bruge den til at dekryptere dataene. 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 få de dekrypterede data. Som du kan se, hjælper rotationen af hovednøglen ikke i dette tilfælde. 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 dataene. 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 i øjeblikket.
Hovednøglerotation er nyttig, når hovednøglen er stjålet, men der er ingen måde for en angriber at bruge den og dekryptere tablespace-nøglerne.
Læs mere:
Kilde: www.habr.com