🥇Kryptering i MySQL: rotation av Master Key

Inför starten av det nya kursutbudet Databaser Vi fortsätter att publicera en serie artiklar om kryptering i MySQL.

I den föregående artikeln i denna serie diskuterade vi, hur kryptering fungerar med huvudnyckeln (Master Key). I dag, baserat på tidigare kunskaper, ska vi titta på rotationen av huvudnycklar.

Rotation av huvudnycklar innebär att en ny huvudnyckel genereras och att dessa nya nycklar används för att kryptera tabellrumnycklarna (som lagras i rubrikerna för tabellrummen).

Låt oss påminna oss om hur rubriken för ett krypterat tabellrum ser ut:

Från den tidigare artikeln vet vi att servern vid start läser rubrikerna för alla krypterade tabellrum och kommer ihåg det största KEY ID. Om vi till exempel har tre tabeller med KEYID = 3 och en tabell med KEYID = 4, då kommer det maximala nyckelidentifieraren att vara 4. Låt oss kalla detta KEY ID — MAX KEY ID.

Hur fungerar rotationen av huvudnyckeln

1. Användaren utför ALTER INNODB MASTER KEY.

2. Servern begär nyckelhanteraren att generera en ny huvudnyckel med serverns UUID och KEYID, som är MAXKEYID ökat med ett. På så sätt får vi identifieraren för huvudnyckeln som är INNODBKEY-UUID- (MAXKEYID + 1). Vid en lyckad generation av huvudnyckeln ökar MAX KEY ID med ett (dvs. MAXKEYID = MAXKEYID + 1).

3. Servern granskar alla tabellrum som är krypterade med huvudnyckeln och för varje tabellrum:

krypterar nyckeln för tabellrummet med den nya huvudnyckeln;
uppdaterar nyckelidentifieraren till den nya MAXKEYID;
om UUID skiljer sig från serverns UUID, uppdaterar den serverns UUID.

Som vi vet består huvudnyckelidentifieraren (Master Key ID) som används för att dekryptera tabeller av UUID och KEY ID, som läses från rubriken på tabellrummet. Det vi gör nu är att uppdatera denna information i rubriken för krypteringen av tabellrummet, så att servern får rätt huvudnyckel.

Om vi har tabellutrymmen som kommer från olika källor, till exempel från olika säkerhetskopior, kan de använda olika huvudnycklar. Alla dessa huvudnycklar måste hämtas från lagringen vid serverstart. Detta kan försena serverstarten, särskilt om en serverlagring av nycklar används. Genom rotation av huvudnyckeln återkrypterar vi nycklarna för tabellutrymmen med en huvudnyckel som är densamma för alla tabellutrymmen. Nu behöver servern endast hämta en huvudnyckel vid start.

Detta är naturligtvis bara en trevlig biprodukt. Huvudsyftet med rotationen av huvudnycklar är att göra vår server mer säker. Om huvudnyckeln på något sätt har stulits från lagringen (till exempel från Vault Server), kan en ny huvudnyckel genereras och nycklarna för tabellutrymmen kan återkrypteras, vilket gör den stulna nyckeln ogiltig. Vi är säkra… nästan.

I den tidigare artikeln nämnde jag att en tredje part kan använda nyckeln för tabellutrymmet för att dekryptera data, förutsatt att det finns åtkomst till vår disk. I händelse av att huvudnyckeln stjäls och det finns åtkomst till de krypterade uppgifterna, kan den stulna huvudnyckeln användas för att dekryptera nyckeln för tabellutrymmet och få de dekrypterade uppgifterna. Som vi ser hjälper inte huvudnyckelsrotation i detta fall. Vi återkrypterar nyckeln för tabellutrymmet med den nya huvudnyckeln, men den faktiska nyckeln som används för kryptering/dekryptering av data förblir densamma. Därför kan en "hackare" fortsatt använda den för att dekryptera data. Tidigare antydde jag att Percona Server for MySQL det kan utföra riktig återkryptering av tabellutrymmen, snarare än bara enkel återkryptering av nyckeln för tabellutrymmet. Denna funktion kallas krypteringstrådar (encryption threads). Men för tillfället är denna funktionalitet fortfarande experimentell.

Rotation av huvudnyckeln är användbar när huvudnyckeln har stulits, men angriparen har inte möjlighet att använda den och dekryptera nycklarna för tabellutrymmena.

Anmäl dig till en kostnadsfri demo.

Läs mer:

Källa: habr.com