🥇Kryptering i MySQL: rotasjon av Master Key

I forkant av oppstarten av det nye kurset «Databaser» vi fortsetter å publisere en serie artikler om kryptering i MySQL.

I den forrige artikkelen i denne serien diskuterte vi, hvordan kryptering med hovednøkkelen (Master Key) fungerer.I dag, basert på tidligere ervervet kunnskap, skal vi se på rotasjon av hovednøkler.

Rotasjonen av hovednøkler innebærer at det genereres en ny hovednøkkel, og denne nye nøkkelen brukes til å kryptere nøklene til tabellområdene på nytt (som lagres i overskriftene til tabellområdene).

La oss huske hvordan overskriften til et kryptert tabellområde ser ut:

Fra den forrige artikkelen vet vi at serveren ved oppstart leser overskriftene til alle krypterte tabellområder og husker den største KEY ID. For eksempel, hvis vi har tre tabeller med KEYID = 3 og en tabell med KEYID = 4, så vil den maksimale nøkkelidentifikatoren være 4. La oss kalle denne KEY ID — MAX KEY ID.

Hvordan rotasjonen av hovednøkkelen fungerer

1. Brukeren utfører ALTER INNODB MASTER KEY.

2. Serveren ber om generering av en ny hovednøkkel fra nøkkelring-lagringen (keyring) med serverens UUID og KEYID, lik økt med én MAXKEYID. Dermed får vi identifikatoren til hovednøkkelen lik INNODBKEY-UUID-(MAXKEYID + 1). Ved vellykket generering av hovednøkkelen økes MAX KEY ID med én (dvs. MAXKEYID = MAXKEYID + 1).

3. Serveren gjennomgår alle tabellområder som er kryptert med hovednøkkelen, og for hvert tabellområde:

krypterer nøkkelen til tabellområdet med den nye hovednøkkelen;
oppdaterer nøkkelidentifikatoren til den nye MAXKEYID;
hvis UUID er forskjellig fra serverens UUID, oppdaterer serverens UUID.

Som vi vet, består identifikatoren for hovednøkkelen (Master Key ID) som brukes til å dekryptere tabellen, av UUID og KEY ID, lest fra overskriften til tabellområdet. Det vi gjør nå er å oppdatere denne informasjonen i overskriften for krypteringen av tabellområdet, slik at serveren mottar den riktige hovednøkkelen.

Hvis vi har tablespace som er hentet fra forskjellige steder, for eksempel fra ulike sikkerhetskopier, kan de bruke forskjellige master-nøkkelene. Alle disse master-nøklene må hentes fra depotet ved oppstart av serveren. Dette kan forsinke oppstarten av serveren, spesielt hvis det brukes et server-database for nøklene. Med hjelp av master-nøkkelrotasjon gjør vi en ny kryptering av nøklene til tablespaces med én master-nøkkel som er identisk for alle tablespaces. Nå, ved oppstart, trenger serveren bare å hente én master-nøkkel.

Dette er selvsagt bare en hyggelig bieffekt. Hovedmålet med rotasjon av master-nøkler er å gjøre serveren vår sikrere. Hvis master-nøkkelen på noen måte blir stjålet fra depotet (for eksempel fra Vault Server), kan vi generere en ny master-nøkkel og kryptere nøklene til tablespaces på nytt, noe som gjør den stjålne nøkkelen ugyldig. Vi er trygge… nesten.

I den forrige artikkelen snakket jeg om at etter at en tablespace-nøkkel stjeles, kan en tredjepart bruke den til å dekryptere data. Forutsatt at de har tilgang til disken vår. I tilfelle av tyveri av master-nøkkelen og tilgang til de krypterte dataene, kan den stjålne master-nøkkelen brukes til å dekryptere tablespace-nøkkelen og få tilgang til dekrypterte data. Som vi ser, hjelper ikke rotasjonen av master-nøkkelen i dette tilfellet. Vi krypterer tablespace-nøkkelen med en ny master-nøkkel, men den faktiske nøkkelen som brukes til kryptering/dekryptering av data forblir den samme. Derfor kan «hackeren» fortsatt bruke den til å dekryptere dataene. Tidligere antydet jeg at Percona Server for MySQL det kan utføre ekte re-kryptering av tablespaces, og ikke bare en enkel re-kryptering av tablespace-nøkkelen. Denne funksjonen kalles krypteringstråder (encryption threads). Men for øyeblikket er denne funksjonaliteten fortsatt eksperimentell.

Rotasjon av master-nøkkelen er nyttig når master-nøkkelen er stjålet, men angriperen har ikke mulighet til å bruke den og dekryptere tablespace-nøklene.

Registrer deg for en gratis demo-leksjon.

Les mer:

Kilde: habr.com