In afwagting van die begin van 'n nuwe inskrywing vir die kursus ons gaan voort om 'n reeks artikels oor enkripsie in MySQL te publiseer.
In die vorige artikel in hierdie reeks het ons bespreek . Vandag, gebaseer op die kennis wat vroeër opgedoen is, kom ons kyk na die rotasie van die hoofsleutels.
Hoofsleutelrotasie behels die generering van 'n nuwe hoofsleutel en die herenkripteer van die tablespace-sleutels (wat in die tablespace-opskrifte gestoor word) met hierdie nuwe sleutel.
Kom ons onthou hoe die kopskrif van 'n geënkripteerde tafelspasie lyk:
Uit die vorige artikel weet ons dat die bediener die kopskrifte van alle geënkripteerde tabelruimtes lees by opstart en die grootste SLEUTEL-ID onthou. Byvoorbeeld as ons drie tabelle met KEY hetID = 3 en een tabel met SLEUTELID = 4, dan sal die maksimum sleutel ID 4 wees. Kom ons noem hierdie SLEUTEL ID - MAKS SLEUTEL ID.
Hoe meestersleutelrotasie werk
1. Die gebruiker voer ALTER INNODB MASTER KEY uit.
2. Die bediener versoek die sleutelring om 'n nuwe hoofsleutel te genereer met die bediener UUID en SLEUTELID gelyk aan een plus MAXSLEUTELID. So kry ons hoofsleutel-ID gelykstaande aan INNODBSLEUTEL-UUID-(MAXSLEUTELID + 1). By suksesvolle generering van die hoofsleutel, word MAX KEY ID met een verhoog (d.w.s. MAXSLEUTELID=MAXSLEUTELID + 1).
3. Die bediener skandeer alle tafelspasies wat met die hoofsleutel geïnkripteer is, en vir elke tafelspasie:
-
enkripteer die tablespace-sleutel met die nuwe hoofsleutel;
-
dateer die sleutel-ID op na die nuwe MAXSLEUTELID;
-
as die UUID verskil van die bediener UUID, werk dan die bediener UUID op.
Soos ons weet, bestaan die hoofsleutel-ID wat gebruik word om 'n tabel te dekripteer uit 'n UUID en 'n SLEUTEL-ID wat vanaf die tafelspasie-opskrif gelees word. Wat ons nou doen, is om hierdie inligting in die tabelruimte-enkripsie-kop op te dateer sodat die bediener die korrekte hoofsleutel ontvang.
As ons tafelspasies vanaf verskillende liggings het, soos verskillende rugsteune, kan hulle verskillende hoofsleutels gebruik. Al hierdie hoofsleutels sal uit die bewaarplek gehaal moet word wanneer die bediener begin word. Dit kan die opstart van die bediener vertraag, veral as 'n sleutelwinkel aan die bedienerkant gebruik word. Met hoofsleutelrotasie, herenkripteer ons tablespace-sleutels met 'n enkele hoofsleutel wat dieselfde is vir alle tablespaces. Die bediener behoort nou slegs een hoofsleutel by opstart te ontvang.
Dit is natuurlik net 'n aangename newe-effek. Die hoofdoel van hoofsleutelrotasie is om ons bediener veiliger te maak. In die geval dat die hoofsleutel op een of ander manier uit die kluis gesteel is (byvoorbeeld van die Vault Server), is dit moontlik om 'n nuwe hoofsleutel te genereer en die tafelspasiesleutels te herenkripteer, wat die gesteelde sleutel ongeldig maak. Ons is veilig...amper.
In 'n vorige artikel het ek gepraat oor hoe sodra 'n tablespace-sleutel gesteel is, 'n derde party dit kan gebruik om data te dekripteer. Met dien verstande dat daar toegang tot ons skyf is. As die hoofsleutel gesteel word en jy het toegang tot die geënkripteerde data, kan jy die gesteelde hoofsleutel gebruik om die tablespace-sleutel te dekripteer en die ontsleutelde data te kry. Soos u kan sien, help die rotasie van die hoofsleutel nie in hierdie geval nie. Ons herenkripteer die tablespace-sleutel met die nuwe hoofsleutel, maar die werklike sleutel wat gebruik word om die data te enkripteer/dekripteer, bly dieselfde. Daarom kan die "haker" voortgaan om dit te gebruik om die data te dekripteer. Vroeër het ek dit laat deurskemer kan ware tablespace-herenkripsie uitvoer, nie net eenvoudige tablespace-sleutelherenkripsie nie. Hierdie kenmerk word enkripsiedrade genoem. Hierdie funksionaliteit is egter steeds eksperimenteel op die oomblik.
Meestersleutelrotasie is nuttig wanneer die hoofsleutel gesteel word, maar daar is geen manier vir 'n aanvaller om dit te gebruik en die tablespace-sleutels te dekripteer nie.
Lees meer:
Bron: will.com