In de aanloop naar de start van een nieuwe groep voor de cursus We blijven een serie artikelen over encryptie in MySQL publiceren.
In het vorige artikel van deze serie () hebben we het gehad over sleutelloketten. In dit artikel bekijken we hoe de hoofdschakel (master key) wordt gebruikt en bespreken we de voor- en nadelen van envelopversleuteling (envelope encryption).
Het idee achter envelopversleuteling is dat de sleutels die worden gebruikt voor versleuteling (tablespace-sleutels) worden versleuteld met een andere sleutel (de hoofdschakel, master key). Voor de versleuteling van gegevens worden feitelijk de tablespace-sleutels gebruikt. Grafisch kan dit als volgt worden weergegeven:
De hoofdschakel (master key) bevindt zich in de sleutelloket (keyring), terwijl de tablespace-sleutels zich in de koptekst van de versleutelde tablespaces bevinden (op pagina 0 van de tablespace).
In de afbeelding hierboven:
Tabel A is versleuteld met sleutel 1 (Key 1). Sleutel 1 wordt versleuteld met de hoofdschakel (master key) en wordt versleuteld opgeslagen in de koptekst van tabel A.
Tabel B is versleuteld met sleutel 2 (Key 2). Sleutel 2 wordt versleuteld met de hoofdschakel (master key) en wordt versleuteld opgeslagen in de koptekst van tabel B.
En ga zo maar door.
Wanneer de server tabel A moet ontsleutelen, haalt hij de hoofdschakel uit het sleutelloket, leest de versleutelde sleutel 1 uit de koptekst van tabel A en ontsleutelt sleutel 1. De ontsleutelde sleutel 1 wordt in het geheugen van de server gecached en wordt gebruikt om tabel A te ontsleutelen.
InnoDB
In InnoDB wordt de feitelijke versleuteling en ontsleuteling uitgevoerd op het niveau van input-output. Dat wil zeggen, de pagina wordt versleuteld vlak voordat deze op schijf wordt weggeschreven en wordt onmiddellijk na lezen van schijf weer ontsleuteld.
In InnoDB werkt versleuteling alleen op het niveau van tablespaces. En standaard worden alle tabellen aangemaakt in afzonderlijke tablespaces (). Met andere woorden, er wordt een tablespace aangemaakt die slechts één tabel kan bevatten. Hoewel je tabellen ook kunt aanmaken in de standaard tablespace (). Maar in elk geval bevindt een tabel zich altijd in een bepaalde tablespace. En aangezien versleuteling op tablespace-niveau plaatsvindt, is deze ofwel volledig versleuteld of niet. Dat wil zeggen dat je niet alleen een deel van de tabellen in de hoofdtablespace kunt versleutelen.
Als om welke reden dan ook file-per-table is uitgeschakeld, worden alle tabellen binnen de systeem tabellenspace (system tablespace) aangemaakt. In kan de systeem tabellenspace worden versleuteld met behulp van de variabele innodbsystablespaceencrypt of door gebruik te maken van versleutelingsstromen (encryption threads), maar dit is nog steeds een experimentele functie. Dit is niet beschikbaar in MySQL.
Voordat we verder gaan, moeten we de structuur van de hoofd sleutel identificatie (master key ID) bekijken. Deze bestaat uit een UUID, KEYID en het prefix «INNODBKey». Dit ziet er als volgt uit: INNODBKey-UUID-KEYID.
UUID is de uuid van de server met de versleutelde tabellenspace. KEYID is gewoon een constant toenemend aantal. Bij de eerste aanmaak van de hoofd sleutel is KEYID gelijk aan 1. Bij het roteren van de sleutel, wanneer er een nieuwe hoofd sleutel wordt aangemaakt, is KEYID = 2 en zo verder. Meer gedetailleerd over het roteren van hoofd sleutels zullen we in de volgende artikelen van deze serie bespreken.
Nu we weten hoe de identificatie van de hoofd sleutel eruit ziet, laten we eens kijken naar de koptekst van de versleutelde tabellenspace. Wanneer de tabellenspace wordt versleuteld, worden de versleutelingsinformatie toegevoegd aan de koptekst. Dit ziet er als volgt uit:
KEY ID is de KEYID van de hoofd sleutel identificatie die we al besproken hebben. UUID is de uuid van de server die ook wordt gebruikt in de hoofd sleutel identificatie. TABLESPACE KEY is de sleutel van de tabellenspace die bestaat uit 256 bits, willekeurig gegenereerd door de server. De initialisatievector (IV, initialization vector) bestaat ook uit 256 willekeurig gegenereerde bits (hoewel dit 128 bits zou moeten zijn). IV wordt gebruikt voor de initialisatie van AES encryptie en decryptie (van de 256 bits wordt slechts 128 gebruikt). Aan het einde bevindt zich een CRC32 controlegetal voor de TABLESPACE KEY en IV.
Gedurende deze tijd heb ik het een beetje vereenvoudigd door te zeggen dat er een versleutelde sleutel van de tabellenspace in de koptekst is. Eigenlijk worden de sleutel van de tabellenspace en de initialisatievector samen met de hoofd sleutel opgeslagen en versleuteld. Vergeet niet dat alvorens de sleutel van de tabellenspace en de initialisatievector te versleutelen, er een CRC32 voor hen wordt berekend.
Waarom is CRC32 nodig?
Kort gezegd, om de geldigheid van de hoofd sleutel te verifiëren. Na het ontcijferen van de tabelruimte sleutel en de initialisatievector, wordt er een controlegetal berekend en vergeleken met de CRC32 die in de header is opgeslagen. Als de controlegetallen overeenkomen, hebben we de juiste hoofd sleutel en tabelruimte sleutel. Anders wordt de tabelruimte gemarkeerd als ontbrekend (we kunnen het toch niet ontcijferen).
Je vraagt je misschien af: op welk moment worden de sleutels gecontroleerd? Het antwoord is: bij het opstarten van de server. Een server met versleutelde tabellen / tabelruimtes leest bij het opstarten de UUID, KEY.De ID uit de header en genereert de identifier van de hoofd sleutel. Vervolgens haalt hij de benodigde hoofd sleutel op uit de opslag (keyring), ontcijfert de tabelruimte sleutel en controleert het controlegetal. Nogmaals, als het controlegetal overeenkomt, is alles in orde. Zo niet, wordt de tabelruimte gemarkeerd als ontbrekend.
Als je het vorige artikel in deze serie hebt gelezen (), dan herinner je je misschien dat bij het gebruik van de server key storage, de server bij het opstarten alleen een lijst van sleutel identificaties ontvangt, namelijk key id en user id, aangezien dit paar de sleutel ondubbelzinnig identificeert. En nu zeg ik dat de server bij het opstarten alle sleutels ontvangt die nodig zijn voor de verificatie van de ontcijferbaarheid van de tabelruimte sleutels. Waarom worden er bij de initialisatie, in het geval van server key storage, alleen de key id en user id geladen, en niet alle sleutels?Omdat je misschien niet alle sleutels nodig hebt. Dit heeft in wezen te maken met de rotatie van de hoofd sleutel. Bij het roteren van de hoofd sleutel wordt er een nieuwe hoofd sleutel in de opslag aangemaakt, maar de oude sleutels worden niet verwijderd. Zo kan je in de server key storage veel sleutels hebben die niet nodig zijn voor de server en die daarom niet worden opgehaald bij het opstarten van de server.ID, en niet alle sleutels? Omdat je misschien niet alle sleutels nodig hebt. Dit heeft vooral te maken met de rotatie van de hoofdslot. Bij de rotatie van de hoofdslot wordt er een nieuwe hoofdslot in de opslag aangemaakt, maar de oude sleutels worden niet verwijderd. Hierdoor kunnen er veel sleutels in de serversleutelopslag zitten die de server niet nodig heeft en, bijgevolg, niet worden opgehaald bij het opstarten van de server.
Het is tijd om even te praten over de voor- en nadelen van encryptie met behulp van een masterkey. Het grootste voordeel is dat je slechts één encryptiesleutel nodig hebt (de masterkey), die apart van je versleutelde gegevens moet worden opgeslagen. Dit maakt het opzetten van de server snel en de opslag klein, wat het beheer vergemakkelijkt. Bovendien kan de enige masterkey eenvoudig worden opnieuw gegenereerd.
Echter, encryptie met de masterkey heeft één groot nadeel: zodra de tablespace is versleuteld met behulp van tablespace_key, blijft deze altijd versleuteld met dezelfde sleutel. Rotatie van de masterkey helpt hier niet. Waarom is dit een nadeel? We weten dat er bugs in MySQL zijn die kunnen leiden tot plotselinge crashes en het creëren van core-bestanden. Aangezien het core-bestand een dump van het servergeheugen bevat, kan het gebeuren dat de gedumpte gegevens de versleutelde key van de tablespace bevatten. Nog erger, de gedecodeerde sleutels van de tablespace worden in het geheugen opgeslagen, dat op de schijf kan worden gewisseld. Je zou kunnen zeggen dat dit geen nadeel is, omdat je root-rechten nodig hebt om toegang te krijgen tot deze bestanden en het swapgedeelte. Dat klopt. Maar root is alleen tijdelijk nodig. Zodra iemand toegang krijgt tot de gedecodeerde sleutels van de tablespace, kan hij/zij deze blijven gebruiken om gegevens te ontsleutelen, zelfs zonder root-rechten. Bovendien kan de schijf worden gestolen, en kunnen swap-/core-bestanden worden gelezen met behulp van externe middelen. Het doel van TDE is om deze onleesbaar te maken, zelfs als de schijf wordt gestolen. In is er de mogelijkheid om de tablespace opnieuw te versleutelen met nieuw gegenereerde sleutels. Deze functie wordt encryptiedraden (encryption threads) genoemd en is op het moment van schrijven nog steeds experimenteel.
Lees meer:
Bron: habr.com
