I väntan på start av ny anmälan till kursen vi fortsätter att publicera en serie artiklar om kryptering i MySQL.
I den tidigare artikeln i den här serien diskuterade vi . Idag, baserat på den kunskap som vunnits tidigare, låt oss titta på rotationen av huvudnycklarna.
Huvudnyckelrotation innebär att generera en ny huvudnyckel och omkryptera tabellutrymmesnycklarna (som lagras i tabellutrymmeshuvudena) med denna nya nyckel.
Låt oss komma ihåg hur rubriken på ett krypterad tabellutrymme ser ut:
Från den tidigare artikeln vet vi att servern läser rubrikerna för alla krypterade tabellutrymmen vid start och kommer ihåg det största KEY-ID:t. Till exempel om vi har tre tabeller med KEYID = 3 och en tabell med KEYID = 4, då blir det maximala nyckel-ID:t 4. Låt oss kalla detta KEY ID - MAX KEY ID.
Hur huvudnyckelrotation fungerar
1. Användaren kör ALTER INNODB MASTER KEY.
2. Servern begär att nyckelringen genererar en ny huvudnyckel med serverns UUID och KEYID lika med ett plus MAXNYCKELID. Så vi får huvudnyckel-id lika med INNODBKEY-UUID-(MAXNYCKELID + 1). Efter framgångsrik generering av huvudnyckeln, ökas MAX KEY ID med ett (dvs. MAXNYCKELID=MAXNYCKELID + 1).
3. Servern skannar alla tabellutrymmen krypterade med huvudnyckeln och för varje tabellutrymme:
-
krypterar tabellutrymmesnyckeln med den nya huvudnyckeln;
-
uppdaterar nyckel-id till nya MAXNYCKELID;
-
om UUID skiljer sig från serverns UUID, uppdatera sedan serverns UUID.
Som vi vet består Master Key ID som används för att dekryptera en tabell av ett UUID och ett KEY ID som läses från tabellutrymmeshuvudet. Det vi gör nu är att uppdatera denna information i tabellutrymmets krypteringshuvud så att servern får rätt huvudnyckel.
Om vi har tabellutrymmen från olika platser, till exempel olika säkerhetskopior, kan de använda olika huvudnycklar. Alla dessa huvudnycklar kommer att behöva hämtas från förvaret när servern startas. Detta kan sakta ner serverstarten, särskilt om ett nyckellager på serversidan används. Med huvudnyckelrotation krypterar vi om tabellutrymmesnycklar med en enda huvudnyckel som är samma för alla tabellutrymmen. Servern bör nu bara få en huvudnyckel vid uppstart.
Detta är naturligtvis bara en trevlig bieffekt. Huvudsyftet med huvudnyckelrotation är att göra vår server säkrare. I händelse av att huvudnyckeln på något sätt stals från valvet (till exempel från Vault Server), är det möjligt att generera en ny huvudnyckel och kryptera om tabellutrymmesnycklarna, vilket gör den stulna nyckeln ogiltig. Vi är säkra... nästan.
I en tidigare artikel pratade jag om hur en tredje part kan använda den för att dekryptera data när en tabellutrymmesnyckel är stulen. Förutsatt att det finns tillgång till vår disk. Om huvudnyckeln är stulen och du har tillgång till den krypterade datan, kan du använda den stulna huvudnyckeln för att dekryptera tabellutrymmesnyckeln och få den dekrypterade datan. Som du kan se hjälper inte rotationen av huvudnyckeln i det här fallet. Vi krypterar om tabellutrymmesnyckeln med den nya huvudnyckeln, men den faktiska nyckeln som används för att kryptera/dekryptera data förblir densamma. Därför kan "hackern" fortsätta använda den för att dekryptera data. Jag antydde det tidigare kan utföra äkta omkryptering av tabellutrymme, inte bara enkel omkryptering av tabellutrymmesnyckel. Denna funktion kallas krypteringstrådar. Denna funktionalitet är dock fortfarande experimentell för tillfället.
Huvudnyckelrotation är användbart när huvudnyckeln är stulen, men det finns inget sätt för en angripare att använda den och dekryptera tabellutrymmesnycklarna.
Läs mer:
Källa: will.com