Versleuteling in MySQL: rotatie van de Master Key

In de aanloop naar de start van een nieuwe groep voor de cursus Database We blijven een serie artikelen over encryptie in MySQL publiceren.

In het vorige artikel van deze serie hebben we besproken, hoe encryptie werkt met de hoofd sleutel (Master Key). Vandaag kijken we, gebaseerd op de eerder verworven kennis, naar de rotatie van de hoofdsleutels.

Rotatie van hoofdsleutels houdt in dat er een nieuwe hoofdsleutel wordt gegenereerd en deze nieuwe sleutel wordt gebruikt om de sleutels van de tabellenruimten opnieuw te versleutelen (die in de headers van de tabellenruimten worden opgeslagen).

Laten we herinneren hoe de header van een versleutelde tabellenruimte eruit ziet:

Versleuteling in MySQL: rotatie van de Master Key

Uit het vorige artikel weten we dat de server bij opstarten de headers van alle versleutelde tabellenruimten leest en de grootste KEY ID onthoudt. Bijvoorbeeld, als we drie tabellen hebben met KEYID = 3 en één tabel met KEYID = 4, dan is de maximale sleutelidentificatie gelijk aan 4. Laten we deze KEY ID MAX KEY ID noemen.

Hoe werkt de rotatie van de hoofdsleutel

1. De gebruiker voert ALTER INNODB MASTER KEY uit.

2. De server vraagt in de sleutelopslag (keyring) om een nieuwe hoofdsleutel te genereren met de UUID van de server en een KEYID, gelijk aan de verhoogde MAXKEYID met één. Zo krijgen we een hoofd sleutelidentificatie gelijk aan INNODBKEY-UUID- (MAXKEYID + 1). Bij een succesvolle generatie van de hoofdsleutel wordt MAX KEY ID met één verhoogd (d.w.z. MAXKEYID = MAXKEYID + 1).

3. De server doorloopt alle tabellenruimten die zijn versleuteld met de hoofdsleutel en voor elke tabellenruimte:

  • versleutelt de sleutel van de tabellenruimte met de nieuwe hoofdsleutel;

  • werkt het sleutelidentificatienummer bij naar de nieuwe MAXKEYID;

  • als de UUID verschilt van de UUID van de server, wordt de UUID van de server bijgewerkt.

Zoals we weten, bestaat de identificatie van de hoofdsleutel (Master Key ID), gebruikt voor het ontsleutelen van de tabel, uit de UUID en KEY ID, gelezen uit de header van de tabellenruimte. Wat we nu doen, is deze informatie bijwerken in de header van de encryptie van de tabellenruimte, zodat de server de juiste hoofdsleutel ontvangt.

Als we tabellenruimten hebben die uit verschillende bronnen zijn verkregen, bijvoorbeeld uit verschillende back-ups, kunnen ze verschillende hoofdsleutels gebruiken. Al deze hoofdsleutels moeten bij het opstarten van de server uit de opslag worden opgehaald. Dit kan het opstarten van de server vertragen, vooral als er gebruik wordt gemaakt van een serveropslag voor sleutels. Met behulp van de rotatie van de hoofdsleutel herversleutelen we de sleutels van de tabellenruimten met één hoofdsleutel, die voor alle tabellenruimten hetzelfde is. Nu hoeft de server bij het opstarten alleen één hoofdsleutel op te halen.

Dit is natuurlijk slechts een aangenaam bijeffect. Het hoofddoel van het rotatieproces van de hoofdsleutels is om onze server veiliger te maken. Als de hoofdsleutel op enige manier uit de opslag is gestolen (bijvoorbeeld uit Vault Server), kan er een nieuwe hoofdsleutel worden gegenereerd en kunnen de sleutels van de tabellenruimten opnieuw worden versleuteld, waardoor de gestolen sleutel ongeldig wordt. We zijn veilig... bijna.

In het vorige artikel heb ik gesproken over het feit dat na de diefstal van de sleutel van de tabellenruimte een derde partij deze kan gebruiken om gegevens te ontsleutelen. Op voorwaarde dat er toegang is tot onze schijf. In het geval van diefstal van de hoofdsleutel en toegang tot de versleutelde gegevens, kan de gestolen hoofdsleutel worden gebruikt om de sleutel van de tabellenruimte te ontsleutelen en de ontsleutelde gegevens te verkrijgen. Zoals we zien, helpt de rotatie van de hoofdsleutel in dit geval niet. We herversleutelen de sleutel van de tabellenruimte met een nieuwe hoofdsleutel, maar de feitelijke sleutel die voor de versleuteling/ontsleuteling van gegevens wordt gebruikt, blijft hetzelfde. Daarom kan de 'hacker' deze blijven gebruiken om gegevens te ontsleutelen. Eerder heb ik gesuggereerd dat Percona Server for MySQL het echte herversleutelen van tabellenruimten kan uitvoeren, en niet alleen eenvoudige herversleuteling van de sleutel van de tabellenruimte. Deze functie wordt encryptiedraden (encryption threads) genoemd. Deze functionaliteit is echter op dit moment nog experimenteel.

De rotatie van de hoofdsleutel is nuttig wanneer de hoofdsleutel is gestolen, maar de aanvaller geen mogelijkheid heeft om deze te gebruiken en de sleutels van de tabellenruimten te ontsleutelen.

Aanmelden voor een gratis demonstratieles.

Lees meer:

Bron: habr.com

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers 🔥 Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster