In afwachting van de start van een nieuwe inschrijving voor de opleiding we blijven een reeks artikelen publiceren over encryptie in MySQL.
In het vorige artikel in deze serie hebben we het erover gehad . Laten we vandaag, op basis van de eerder opgedane kennis, kijken naar de rotatie van de hoofdtoetsen.
Hoofdsleutelrotatie omvat het genereren van een nieuwe hoofdsleutel en het opnieuw versleutelen van de tablespace-sleutels (die zijn opgeslagen in de tablespace-headers) met deze nieuwe sleutel.
Laten we ons herinneren hoe de header van een versleutelde tablespace eruit ziet:
Uit het vorige artikel weten we dat de server bij het opstarten de headers van alle versleutelde tablespaces leest en de grootste KEY ID onthoudt. Als we bijvoorbeeld drie tabellen hebben met KEYID = 3 en een tafel met SLEUTELID = 4, dan is de maximale sleutel-ID 4. Laten we dit KEY ID - MAX KEY ID noemen.
Hoe hoofdsleutelrotatie werkt
1. De gebruiker voert ALTER INNODB MASTER KEY uit.
2. De server vraagt de keyring om een nieuwe hoofdsleutel te genereren met de server UUID en KEYID gelijk aan één plus MAXKEYID KAART. Dus we krijgen hoofdsleutel-ID gelijk aan INNODBSLEUTEL-UUID-(MAXKEYID + 1). Na het succesvol genereren van de hoofdsleutel, wordt MAX KEY ID verhoogd met één (d.w.z. MAXKEYID=MAXKEYidentiteitskaart + 1).
3. De server scant alle tablespaces versleuteld met de hoofdsleutel, en voor elke tablespace:
-
versleutelt de tablespace-sleutel met de nieuwe hoofdsleutel;
-
werkt de sleutel-ID bij naar de nieuwe MAXKEYID KAART;
-
als de UUID verschilt van de server-UUID, werk dan de server-UUID bij.
Zoals we weten, bestaat de Master Key ID die wordt gebruikt om een tabel te decoderen uit een UUID en een KEY ID die wordt gelezen uit de tablespace-header. Wat we nu doen is deze informatie bijwerken in de tabelruimtecoderingsheader zodat de server de juiste hoofdsleutel ontvangt.
Als we tablespaces hebben van verschillende locaties, zoals verschillende back-ups, dan kunnen ze verschillende hoofdsleutels gebruiken. Al deze hoofdsleutels moeten worden opgehaald uit de repository wanneer de server wordt gestart. Dit kan het opstarten van de server vertragen, vooral als er een sleutelarchief aan de serverzijde wordt gebruikt. Met hoofdsleutelrotatie versleutelen we de tabelruimtesleutels opnieuw met een enkele hoofdsleutel die voor alle tabelruimten hetzelfde is. De server zou nu bij het opstarten slechts één hoofdsleutel moeten ontvangen.
Dit is natuurlijk slechts een prettig neveneffect. Het belangrijkste doel van hoofdsleutelrotatie is om onze server veiliger te maken. In het geval dat de hoofdsleutel op de een of andere manier uit de kluis is gestolen (bijvoorbeeld van de Vault Server), is het mogelijk om een nieuwe hoofdsleutel te genereren en de tabelruimtesleutels opnieuw te versleutelen, waardoor de gestolen sleutel ongeldig wordt. We zijn veilig...bijna.
In een vorig artikel heb ik het gehad over hoe een derde partij, zodra een tablespace-sleutel is gestolen, deze kan gebruiken om de gegevens te decoderen. Mits er toegang is tot onze schijf. Als de hoofdsleutel is gestolen en u toegang hebt tot de versleutelde gegevens, kunt u de gestolen hoofdsleutel gebruiken om de tabelruimtesleutel te ontsleutelen en de ontsleutelde gegevens op te halen. Zoals u kunt zien, helpt het draaien van de hoofdsleutel in dit geval niet. We versleutelen de tabelruimtesleutel opnieuw met de nieuwe hoofdsleutel, maar de daadwerkelijke sleutel die wordt gebruikt om de gegevens te versleutelen/ontsleutelen, blijft hetzelfde. Daarom kan de "hacker" het blijven gebruiken om de gegevens te decoderen. Eerder hintte ik daar al op kan echte hercodering van de tabelruimte uitvoeren, niet alleen eenvoudige hercodering van de tabelruimtesleutel. Deze functie wordt coderingsthreads genoemd. Deze functionaliteit is momenteel echter nog experimenteel.
Hoofdsleutelrotatie is handig wanneer de hoofdsleutel is gestolen, maar een aanvaller kan deze niet gebruiken om de tabelruimtesleutels te decoderen.
Lees verder:
Bron: www.habr.com