Dulkóðun í MySQL: Master Key Rotation

Í aðdraganda nýrrar innritunar á námskeiðið "gagnagrunnur" við höldum áfram að birta röð greina um dulkóðun í MySQL.

Í fyrri greininni í þessari röð ræddum við hvernig dulkóðun aðallykla virkar. Í dag, byggt á þekkingunni sem aflað var áðan, skulum við líta á snúning aðallykla.

Snúningur aðallykils felur í sér að búa til nýjan aðallykil og endurdulkóða borðrýmislyklana (sem eru geymdir í borðrýmishausunum) með þessum nýja lykli.

Við skulum muna hvernig hausinn á dulkóðuðu borðrými lítur út:

Dulkóðun í MySQL: Master Key Rotation

Frá fyrri grein vitum við að þjónninn les hausa allra dulkóðaðra borðrýma við ræsingu og man stærsta KEY ID. Til dæmis ef við höfum þrjú borð með KEYID = 3 og eitt borð með LYKILID = 4, þá verður hámarks lykilauðkenni 4. Köllum þetta KEY ID - MAX KEY ID.

Hvernig snúningur aðallykla virkar

1. Notandinn keyrir ALTER INNODB MASTER KEY.

2. Miðlarinn biður um að lyklakippan búi til nýjan aðallykil með þjóninum UUID og KEYID jafnt og einum plús MAXKEYauðkenni. Þannig að við fáum aðallykilauðkenni sem jafngildir INNODBLYKILL-UUID-(MAXKEYID + 1). Þegar búið er að búa til aðallykilinn er MAX KEY ID hækkað um eitt (þ.e.a.s. MAXKEYID=MAXKEYauðkenni + 1).

3. Miðlarinn skannar öll borðrými sem eru dulkóðuð með aðallyklinum og fyrir hvert borðrými:

  • dulkóðar borðrýmislykilinn með nýja aðallyklinum;

  • uppfærir lykilauðkennið í nýja MAXKEYauðkenni;

  • ef UUID er frábrugðið UUID miðlarans, uppfærðu þá UUID miðlarans.

Eins og við vitum samanstendur aðallykilauðkennið sem notað er til að afkóða töflu af UUID og LYKILkenni sem lesið er úr borðrýmishausnum. Það sem við erum að gera núna er að uppfæra þessar upplýsingar í dulkóðunarhausnum fyrir borðrýmið þannig að þjónninn fái réttan aðallykil.

Ef við höfum borðrými frá mismunandi stöðum, eins og mismunandi afrit, þá gætu þeir notað mismunandi aðallykla. Það þarf að sækja alla þessa aðallykla úr geymslunni þegar þjónninn er ræstur. Þetta getur hægt á ræsingu netþjónsins, sérstaklega ef lykilverslun á miðlara er notuð. Með snúningi aðallykla, endurdulkóðum við borðrýmislykla með einum aðallykli sem er eins fyrir öll borðrými. Miðlarinn ætti nú að fá aðeins einn aðallykil við ræsingu.

Þetta er auðvitað bara skemmtileg aukaverkun. Megintilgangur snúnings aðallykla er að gera netþjóninn okkar öruggari. Ef aðallyklinum var einhvern veginn stolið úr hvelfingunni (til dæmis frá Vault Server), er hægt að búa til nýjan aðallykil og dulkóða borðrýmislyklana aftur, sem gerir stolna lykilinn ógildan. Við erum örugg... næstum því.

Í fyrri grein talaði ég um hvernig þegar borðrýmislykli er stolið getur þriðji aðili notað hann til að afkóða gögn. Að því gefnu að það sé aðgangur að disknum okkar. Ef aðallyklinum er stolið og þú hefur aðgang að dulkóðuðu gögnunum geturðu notað stolna aðallykilinn til að afkóða borðrýmislykilinn og fá afkóðuðu gögnin. Eins og þú sérð hjálpar snúningur aðallykilsins ekki í þessu tilfelli. Við dulkóðum borðrýmislykilinn aftur með nýja aðallyklinum, en raunverulegur lykill sem notaður er til að dulkóða/afkóða gögnin er óbreytt. Þess vegna getur "hakkarinn" haldið áfram að nota það til að afkóða gögnin. Ég gaf það í skyn áðan Percona Server fyrir MySQL getur framkvæmt sanna dulkóðun borðrýmis, ekki bara einfalda endurdulkóðun borðrýmislykils. Þessi eiginleiki er kallaður dulkóðunarþræðir. Hins vegar er þessi virkni enn tilraunastarfsemi í augnablikinu.

Snúningur aðallykla er gagnlegur þegar aðallyklinum er stolið, en það er engin leið fyrir árásarmann að nota hann og afkóða borðrýmislyklana.

Skráðu þig í ókeypis kynningartíma.

Lestu meira:

Heimild: www.habr.com