I påvente av oppstart av ny påmelding til kurset vi fortsetter å publisere en serie artikler om kryptering i MySQL.
I den forrige artikkelen i denne serien diskuterte vi . I dag, basert på kunnskapen som er oppnådd tidligere, la oss se på rotasjonen av hovednøklene.
Hovednøkkelrotasjon involverer generering av en ny hovednøkkel og re-kryptering av tablespace-nøklene (som er lagret i tablespace-overskriftene) med denne nye nøkkelen.
La oss huske hvordan overskriften til en kryptert tabellplass ser ut:
Fra forrige artikkel vet vi at serveren leser overskriftene til alle krypterte tabellplasser ved oppstart og husker den største KEY ID. For eksempel hvis vi har tre tabeller med KEYID = 3 og ett bord med NØKKELID = 4, da vil maksimal nøkkel-ID være 4. La oss kalle dette NØKKEL-ID - MAKS NØKKEL-ID.
Hvordan hovednøkkelrotasjon fungerer
1. Brukeren utfører ALTER INNODB MASTER KEY.
2. Serveren ber nøkkelringen generere en ny hovednøkkel med serverens UUID og KEYID lik én pluss MAKSKEYID. Så vi får hovednøkkel-ID lik INNODBNØKKEL-UUID-(MAKSKEYID + 1). Ved vellykket generering av hovednøkkelen, økes MAX KEY ID med én (dvs. MAXKEYID=MAXKEYID + 1).
3. Serveren skanner alle tabellplasser kryptert med hovednøkkelen, og for hver tabellplass:
-
krypterer tablespace-nøkkelen med den nye hovednøkkelen;
-
oppdaterer nøkkel-IDen til den nye MAXKEYID;
-
hvis UUID er forskjellig fra server UUID, så oppdater server UUID.
Som vi vet, består hovednøkkel-IDen som brukes til å dekryptere en tabell av en UUID og en nøkkel-ID som leses fra tabelloverskriften. Det vi gjør nå er å oppdatere denne informasjonen i tabellplasskrypteringshodet slik at serveren mottar riktig hovednøkkel.
Hvis vi har tabellplasser fra forskjellige steder, for eksempel forskjellige sikkerhetskopier, kan de bruke forskjellige hovednøkler. Alle disse hovednøklene må hentes fra depotet når serveren startes. Dette kan bremse oppstarten av serveren, spesielt hvis et nøkkellager på serversiden brukes. Med hovednøkkelrotasjon omkrypterer vi tabellplassnøkler med en enkelt hovednøkkel som er lik for alle tabellplasser. Serveren skal nå motta bare én hovednøkkel ved oppstart.
Dette er selvfølgelig bare en hyggelig bivirkning. Hovedformålet med hovednøkkelrotasjon er å gjøre serveren vår sikrere. I tilfelle hovednøkkelen på en eller annen måte ble stjålet fra hvelvet (for eksempel fra Vault Server), er det mulig å generere en ny hovednøkkel og kryptere tabellplassnøklene på nytt, noe som gjør den stjålne nøkkelen ugyldig. Vi er trygge...nesten.
I en tidligere artikkel snakket jeg om hvordan når en tablespace-nøkkel er stjålet, kan en tredjepart bruke den til å dekryptere data. Forutsatt at det er tilgang til disken vår. Hvis hovednøkkelen er stjålet og du har tilgang til de krypterte dataene, kan du bruke den stjålne hovednøkkelen til å dekryptere tablespace-nøkkelen og få de dekrypterte dataene. Som du kan se, hjelper ikke rotasjonen av hovednøkkelen i dette tilfellet. Vi omkrypterer tablespace-nøkkelen med den nye hovednøkkelen, men den faktiske nøkkelen som brukes til å kryptere/dekryptere dataene forblir den samme. Derfor kan "hackeren" fortsette å bruke den til å dekryptere dataene. Jeg antydet det tidligere kan utføre ekte tabellplassrekryptering, ikke bare enkel tabellplassnøkkelkryptering. Denne funksjonen kalles kryptertråder. Imidlertid er denne funksjonaliteten fortsatt eksperimentell for øyeblikket.
Hovednøkkelrotasjon er nyttig når hovednøkkelen blir stjålet, men det er ingen måte for en angriper å bruke den og dekryptere tabellplassnøklene.
Les mer:
Kilde: www.habr.com