Kryptering i MySQL: användning 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 (Kryptering i MySQL: nyckellagring) diskuterade vi nyckel förvar. I denna artikel kommer vi att titta på hur huvudnyckeln (master key) används samt diskutera fördelar och nackdelar med konvolutkryptering (envelope encryption). 

Idén med konvolutkryptering är att de nycklar som används för att kryptera datan (tablespace-nycklar) krypteras med en annan nyckel (huvudnyckel, master key). För att kryptera data används i själva verket tablespace-nycklar. Grafiskt kan detta framställas som:

Huvudnyckeln (master key) finns i nyckelförvaringen (keyring), medan tablespace-nycklarna finns i rubrikerna för de krypterade tablespaces (på sida 0 av tablespace). 

I bilden ovan:

• Tabell A är krypterad med nyckel 1 (Key 1). Nyckel 1 krypteras med huvudnyckeln (master key) och lagras krypterad i rubriken för tabell A.

• Tabell B är krypterad med nyckel 2 (Key 2). Nyckel 2 krypteras med huvudnyckeln (master key) och lagras krypterad i rubriken för tabell B.

• Och så vidare.

När servern behöver avkryptera tabell A får den huvudnyckeln från förvaringen, läser den krypterade nyckel 1 från rubriken för tabell A och avkrypterar nyckel 1. Den avkrypterade nyckel 1 cachas i serverns minne och används för att avkryptera tabell A.

InnoDB

I InnoDB utförs den faktiska krypteringen och avkrypteringen på in- och utmatningsnivå. Det vill säga att sidan krypteras precis innan den skrivs till disk och avkrypteras direkt efter att den lästs från disk.

I InnoDB fungerar kryptering endast på nivå av tabeller. Som standard skapas alla tabeller i separata tabellerum (file-per-table tablespace). Med andra ord skapas ett tabellerum som endast kan innehålla en tabell. Även om du också kan skapa tabeller i det primära tabellerummet (general tablespace). Men i alla fall finns tabellen alltid i något tabellerum. Och eftersom krypteringen sker på nivå av tabellerum, så är den antingen helt krypterad eller inte. Det går alltså inte att kryptera endast en del av tabeller i det primära tabellerummet. 

Om av någon anledning filsystemet file-per-table är avstängt, skapas alla tabeller inom det systemtabellutrymme (system tablespace). I Percona Server for MySQL kan det systemtabellutrymmet krypteras med hjälp av variabeln innodbsystablespaceencrypt eller genom att använda krypteringsströmmar (encryption threads), men detta är fortfarande en experimentell funktion. Det finns ingen sådan i MySQL.

Innan vi går vidare behöver vi titta på strukturen för identifieraren för huvudnyckeln (master key ID). Den består av UUID, KEYID och prefixet "INNODBKey". Det ser ut så här: INNODBKey-UUID-KEYID.

UUID är uuid för servern med det krypterade tabellutrymmet. KEYID är helt enkelt ett konstant ökande värde. Vid den ursprungliga skapelsen av huvudnyckeln är KEYID lika med 1. Vid nyckelrotation, när en ny huvudnyckel skapas, är KEYID = 2 och så vidare. Mer detaljer om rotation av huvudnycklar kommer vi att diskutera i de kommande artiklarna i denna serie.

Nu när vi vet hur identifieraren för huvudnyckeln ser ut, låt oss se på rubriken för det krypterade tabellutrymmet. När tabellutrymmet krypteras, läggs krypteringsinformation till rubriken. Det ser ut som följande:

KEY ID är KEYID från identifieraren för huvudnyckeln som vi redan har diskuterat. UUID är uuid för servern, som också används i identifieraren för huvudnyckeln. TABLESPACE KEY är tabellutrymmet nyckel som består av 256 bitar, slumpmässigt genererade av servern. Initieringsvektorn (IV, initialization vector) består också av 256 slumpmässigt genererade bitar (även om det borde vara 128 bitar). IV används för att initiiera AES-kryptering och avkryptering (från 256 bitar används endast 128). I slutet finns en CRC32-kontrollsumma för TABLESPACE KEY och IV.

Jag har under tiden förenklat något genom att säga att det i rubriken finns en krypterad tabellutrymesnyckel. I verkligheten lagras och krypteras tabellutrymesnyckeln och initieringsvektorn tillsammans med huvudnyckeln. Kom ihåg att CRC32 beräknas för tabellutrymesnyckeln och initieringsvektorn innan de krypteras.

Vad är CRC32 bra för?

Kort sagt, för att säkerställa giltigheten av huvudnyckeln. Efter att ha avkrypterat tabellutrymmesnyckeln och initialiseringsvektorn beräknas en kontrollsumma som jämförs med CRC32 som lagras i huvudet. Om kontrollsummorna matchar har vi rätt huvudnyckel och tabellutrymmesnyckel. Annars markeras tabellutrymmet som otillgängligt (vi kan fortfarande inte avkryptera det).

Du kanske undrar: när utförs nyckelkontrollen? Svaret – vid serverstart. Servern med krypterade tabeller / tabellutrymmen läser vid starten UUID, KEYID från huvudet och genererar en identifikation för huvudnyckeln. Den hämtar sedan den nödvändiga huvudnyckeln från lagringen (keyring), avkrypterar tabellutrymmesnyckeln och kontrollerar kontrollsumman. Återigen, om kontrollsumman matchar är allt i ordning, om inte – tabellutrymmet markeras som otillgängligt.

Om du har läst den tidigare artikeln i denna serie (Kryptering i MySQL: nyckellagring), kanske du kommer ihåg att när serverns nyckellager används, får servern vid start endast en lista över nyckelidentifierare, mer exakt, key id och user id, eftersom detta par entydigt identifierar nyckeln. Och nu säger jag att servern vid start får alla nycklar som behövs för att kontrollera avkryptering av tabellutrymmen. Så varför laddas vid initialisering, i fallet med serverlagret, endast keyid och userid, och inte alla nycklar? För att du kanske inte behöver alla nycklar. Detta är främst kopplat till rotationen av huvudnyckeln. Vid rotation av huvudnyckeln skapas en ny huvudnyckel i lagret, men de gamla nycklarna tas inte bort. Därför kan det finnas många nycklar i serverns nyckellager som servern inte behöver och därför inte extraheras vid serverstart.

Det är dags att diskutera fördelarna och nackdelarna med kryptering med hjälp av en huvudnyckel. Den största fördelen är att du bara behöver en krypteringsnyckel (huvudnyckeln) som lagras separat från dina krypterade data. Detta gör serverstarten snabb och lagringen liten, vilket förenklar förvaltningen. Dessutom är det enkelt att regenerera den enda huvudnyckeln.

Men kryptering med huvudnyckeln har en stor nackdel: när tabellutrymmet har krypterats med hjälp av tablespace_key förblir det alltid krypterat med samma nyckel. Rotation av huvudnyckeln hjälper här inte. Varför är detta en nackdel? Vi vet att det finns buggar i MySQL som kan leda till plötsliga krasch och skapande av en core-fil. Eftersom core-filen innehåller en dump av serverns minne kan det hända att den avkryperade nyckeln för tabellutrymmet finns i dumpen. Ännu värre, avkryperade nycklar för tabellutrymmet lagras i minnet, som kan svappa till disk. Du kanske säger att detta inte är en nackdel, eftersom du behöver root-rättigheter för att få tillgång till dessa filer och swap-partitionen. Ja. Men root behövs bara under en kort tid. När någon väl har fått tillgång till den avkryperade nyckeln för tabellutrymmet kan han/hon fortsätta använda den för att avkryptera data, även utan root-rättigheter. Dessutom kan disken stjälas, och swap-partitionen/core-filer kan läsas med hjälp av tredjepartsverktyg. Syftet med TDE är att göra den oläsbar, även om disken blir stulen. Percona Server for MySQL det finns möjlighet till omkryptering av tabellutrymmet med nya genererade nycklar. Denna funktion kallas krypteringsströmmar (encryption threads) och är, vid tidpunkten för denna artikels skrivande, fortfarande experimentell.

Läs mer om kursen

Läs mer:

• Kryptering i MySQL: nyckellagring

Källa: habr.com