Uue kursuse alguse eelõhtul jätkame MySQL-i šifreerimist käsitleva artiklisarjaga.
Eelnevas artiklis arutasime, Täna vaatame, tuginedes varasematele teadmistele, peavõtmete rotatsiooni.
Peavõtmete rotatsioon tähendab, et genereeritakse uus peavõti ja selle uue võtmega krüpteeritakse tablettide ruumide võtmed uuesti (mis on salvestatud tablettide ruumide päistes).
Meenutame, millega näeb välja krüpteeritud tablettide ruumi päis:
Eelmisest artiklist teame, et server loeb käivitamisel kõigi krüpteeritud tablettide ruumide päiseid ja mäletab suurimat KEY ID-d. Näiteks, kui meil on kolm tabelit KEYID = 3 ja üks tabel KEYID = 4, siis maksimaalne võtme identifikaator on 4. Kuid nimetame seda KEY ID-d - MAX KEY ID.
Kuidas toimib peavõtme rotatsioon
1. Kasutaja teostab ALTER INNODB MASTER KEY.
2. Server palub võtmeringist (keyring) genereerida uus peavõti serveri UUID-ga ja KEYID, mis on suurendatud MAXKEYID. Nii saame peavõtme identifikaatori, mis on INNODBKEY-UUID- (MAXKEYID + 1). Kui peavõti on edukalt genereeritud, suureneb MAX KEY ID ühe võrra (st MAXKEYID = MAXKEYID + 1).
3. Server vaatab alla kõik tablettide ruumid, mis on krüpteeritud peavõtmega, ja iga tablettide ruumi jaoks:
krüpteerib tablettide ruumi võtme uue peavõtmega;
uuendab võtme identifikaatori uue MAXKEYID-ga;
kui UUID erineb serveri UUID-st, siis uuendab serveri UUID-d.
Kuidas me teame, et peavõtme identifikaator (Master Key ID), mida kasutatakse tabeli dekrüpteerimiseks, koosneb UUID-st ja KEY ID-st, mis on loetud tablettide ruumi päisest. Mida me nüüd teeme, on see, et värskendame seda teavet tablettide ruumi krüptimise päises, et server saaks õige peavõtme.
Kui meil on tabeliruumid, mis on saadud erinevatest kohtadest, näiteks erinevatest varukoopiatest, võivad neil olla erinevad peavõtmed. Kõik need peavõtmed tuleb serveri käivitamisel salvestusest hankida. See võib serveri käivitamist aeglustada, eriti kui kasutatakse serveripõhist võtmehoidjat. Peavekta rikkujate roplacerimisega krüpteerime tabeliruumi võtmed uuesti ühe peavõtmega, mis on kõigile tabeliruumidele sama. Nüüd peab server käivitamisel saama ainult ühe peavõtme.
See on muidugi vaid meeldiv kõrvalmõju. Peamine eesmärk peavekta roplacerimise on muuta meie server rohkem turvaliseks. Kui peavõti on mingil moel salvestusest varastatud (näiteks Vault Serverist), saab genereerida uue peavõtme ja krüpteerida tabeliruumi võtmed uuesti, muutes varastatud võtme kehtetuks. Me oleme turvalised... peaaegu.
Eelmisel artiklis rääkisin sellest, et pärast tabeliruumi võtme varastamist võib kolmas osapool seda kasutada andmete dekrüpteerimiseks, tingimusel et tal on juurdepääs meie kettale. Peavõtme varastamise korral ja kui juurdepääs on krüpteeritud andmetele, saab varastatud peavõtit kasutada tabeliruumi võtme dekrüpteerimiseks ja dekrüpteeritud andmete saamiseks. Nagu näeme, ei aita sel juhul peavekta roplacerimine. Krüpteerime tabeliruumi võtme uuesti uue peavõtmega, kuid andmete krüpteerimiseks/dekrüpteerimiseks kasutatav tegelik võti jääb samaks. Seega võib " häkker " seda jätkuvalt andmete dekrüpteerimiseks kasutada. Varem vihjasin, et võib tegelikult teostada tõelist tabeliruumi uuesti krüpteerimist, mitte ainult tabeliruumi võtme lihtsat uuesti krüpteerimist. Seda funktsiooni nimetatakse krüpteerimise niitideks (encryption threads). Kuid praegu on see funktsioon endiselt eksperimentalne.
Peavekta roplacerimine on kasulik, kui peavõti on varastatud, kuid kurjategijal ei ole võimalust seda kasutada ja tabeliruumi võtmeid dekrüpteerida.
Loe edasi:
Allikas: habr.com
