Uue kursuse alguse eelõhtul jätkame MySQL-i krüptimist käsitleva artiklite seeria avaldamist.
Eelmises selle seeria artiklis () rääkisime võtmehoidlatest. Selles artiklis käsitleme peamise võti (master key) kasutamist ning arutame ümbervõtmise šifreerimise (envelope encryption) eeliseid ja puudusi.
Ümbervõtmise šifreerimise idee seisneb selles, et šifreerimiseks kasutatavad võtmed (tabeliruumi võtmed) šifreeritakse teise võtmega (peamine võti, master key). Andmete šifreerimiseks kasutatakse tegelikult tabeliruumi võtmeid. Graafiliselt on see kujutatav järgmiselt:
Peamine võti (master key) asub võtmehoidjas (keyring), ja tabeliruumi võtmed – krüpteeritud tabeliruumi pealkirjades (tabeliruumi leht 0).
Ülaltoodud joonisel:
Tabel A on šifreeritud võtmega 1 (Key 1). Võti 1 šifreeritakse peamise võtmega (master key) ja hoitakse krüpteeritud kujul tabel A pealkirjas.
Tabel B on šifreeritud võtmega 2 (Key 2). Võti 2 šifreeritakse peamise võti (master key) abil ja hoitakse krüpteeritud kujul tabel B pealkirjas.
Ja nii edasi.
Kui server peab tabeli A dekrüpteerima, saab ta peamise võtme ladustatud kohast, loeb tabeli A pealkirjas asuvat krüptitud võtit 1 ja dekodeerib võti 1. Dekodeeritud võti 1 vahetatakse serveri mällu ja kasutatakse tabeli A dekrüpteerimiseks.
InnoDB
InnoDB-s toimub tegelik krüpteerimine ja dekrüpteerimine sisend-väljunditasemel. See tähendab, et leht krüpteeritakse vahetult enne selle salvestamist kettale ja dekrüpteeritakse kohe pärast selle lugemist kettalt.
InnoDB-s töötab krüpteerimine ainult tabeliruumide tasemel. Ja vaikimisi luuakse kõik tabelid eraldi tabeliruumides (). Teisisõnu, luuakse tabeliruumi, mis võib sisaldada ainult ühte tabelit. Kuigi saate luua tabeleid ka üldises tabeliruumis (). Kuid igal juhul asub tabel alati mingis tabeli ruumis. Kuna krüpteerimine toimub tabeli ruumi tasandil, siis see kas on täielikult krüpteeritud või mitte. See tähendab, et ei saa peamises tabeliruumi ainult osa tabelitest krüpteerida.
Kui mingil põhjusel on teil file-per-table välja lülitatud, siis kõik tabelid luuakse süsteemi tabeli ruumis (system tablespace). süsteemi tabeli ruumi saab krüpteerida muutuja innodbsystablespacekrüptimise või krüpteerimise niitide (encryption threads) kasutamisega, kuid see on endiselt eksperimentaalne funktsioon. MySQL-is seda ei ole.
Enne kui liigume edasi, peame vaatama peamise võtme identifikaatori (master key ID) struktuuri. See koosneb UUID-st, võtmeID-st ja eeldivost 'INNODBKey'. See näeb välja järgmiselt: INNODBKey-UUID-KEYID.
UUID on serveri uuid, millel on krüpteeritud tabeli ruum. KEYID on lihtsalt pidevalt kasvav väärtus. Peamise võtme esmakordsel loomisel on KEYID võrdne 1. Võtme vahetamisel, kui luuakse uus peamine võti, on KEYID = 2 ja edasi. Peamiste võtmete rotatsiooni kohta räägime järgmistel artikkelidel selles seerias.
Nüüd, kui me teame, kuidas peamise võtme identifikaator välja näeb, vaatame paroolitud tabeliruumi pealkirja. Kui tabeliruumi krüptitakse, lisatakse teave krüpteerimise kohta pealkirjale. See näeb välja järgmine:
KEY ID — see on KEYID peamise võtme identifikaatorist, millest oleme juba rääkinud. UUID — see on serveri uuid, mida kasutatakse samuti peamise võtme identifikaatoris. TABLESPACE KEY — tabeliruumi võti, mis koosneb 256 bitist, mis on serveri poolt juhuslikult genereeritud. Initsialiseerimisvektor (IV, initialization vector) koosneb samuti 256 juhuslikult genereeritud bitist (kuigi peaks olema 128 bitti). IV kasutatakse AES-i krüpteerimise ja dekrüpteerimise initsialiseerimiseks (256 bitist kasutatakse vaid 128). Lõpus on tabeliruumi võtme ja IV jaoks CRC32 kontrollsumma.
Kogu selle aja olen ma natuke lihtsustanud, öeldes, et pealkirjas on tabeliruumi krüpteeritud võti. Tegelikult hoitakse ja krüpteeritakse tabeliruumi võti ja initsialiseerimise vektor koos põhi võtmega. Pea meeles, et enne tabeliruumi võti ja initsialiseerimise vektori krüpteerimist arvutatakse nende jaoks CRC32.
Miks on vaja CRC32?
Lihtsalt, selleks et veenduda põhi võtme kehtivuses. Pärast tabeliruumi võtme ja initsialiseerimise vektori krüpteerimist arvutatakse kontrollsummari ja võrreldakse seda pealkirjas hoitava CRC32-ga. Kui kontrollsummad kattuvad, siis on meil õige põhi võti ja tabeliruumi võti. Vastupidisel juhul märgistatakse tabeliruum puuduvaks (me ei saa seda siiski krüpteerida).
Sa võid küsida: millal toimub võtmete kontrollimine? Vastus — serveri käivitamisel. Server, millel on krüpteeritud tabelid / tabeliruumid, loeb käivitamisel UUID, KEYID päisest ja genereerib peamise võtme identifikaatori. Seejärel saadakse vajalik peamine võti võtmehoidlast (keyring), dekodeeritakse tabeliruumivõti ja kontrollitakse kontrollsummat. Kui kontrollsumma klapib, siis on kõik korras, kui ei – tabeliruumi märgitakse puuduolevaks.
Kui olete lugenud selle seeria eelmist artiklit (), siis võite meenutada, et serveri võtmehoidlat kasutades saab server käivitamisel ainult võtme identifikaatorite nimekirja, täpsemalt key id ja user id, kuna see paar määratleb võtme üheselt. Ja nüüd ütlen, et server käivitamisel saab kõik võtmed, mis on vajalikud tabeliruumide võtmete dekrüpteerimise võimaluse kontrollimiseks. Miks siis initsialiseerimise korral, serveri võtmehoidla puhul, laaditakse ainult keyid ja userid, mitte kõik võtmed? Sest sul ei pruugi olla vaja kõiki võtmeid. See on peamiselt seotud peavarju võtme pööramisega. Peate võtme pööramisel luuakse uus peavõti, kuid vanad võtmed ei kustutata. Seega võib teie serveri võtmehoidlas olla palju võtmeid, mis ei ole serverile vajalikud ja seega ei tuuakse serveri käivitamisel üles.
On aeg rääkida peavarju võtmega krüpteerimise plussidest ja miinustest. Suurim eelis on see, et teil on vaid üks krüpteerimisvõti (peavõti), mis hoitakse eraldi teie krüptitud andmetest. See muudab serveri käivitamise kiireks ja hoidlana väiksemaks, hõlbustades haldamist. Lisaks on ainus peavõti kergesti uuesti genereeritav.
Kuid peamise võtmega krüpteerimisel on üks suur puudus: pärast seda, kui tabeliruumi krüptitakse tablespace_key abil, jääb see alati sama võtmega krüptituks. Peamise võtme vahetamine ei aita siin. Miks see on puudus? Me teame, et MySQL-is on vigu, mis võivad põhjustada ootamatuid krahhe ja luua core-faili. Kuna core-fail sisaldab serveri mälu dumpi, võib juhtuda, et dumpis on dekrüpteeritud tabeliruumi võti. Veel hullem on see, et dekrüpteeritud tabeliruumi võtmed talletatakse mälus, mis võib kettale vahetuda. Võite öelda, et see ei ole puudus, kuna teil on nende failide ja vahetusruumi juurde pääsemiseks vaja root-õigusi. Jah. Kuid root on vajalik vaid hetkeks. Kui keegi pääseb juurde dekrüpteeritud tabeliruumi võtmele, saab ta / ta jätkata selle kasutamist andmete dekrüpteerimiseks, isegi ilma root-õigusteta. Lisaks võib kettast varastada ja vahetusruumi / core-faile saab kolmandate osapoolte tööriistadega lugeda. TDE eesmärk on muuta see loetamatuks, isegi kui kettast varastatakse. on võimalus uuesti krüpteerida tabeliruumi uute genereeritud võtmetega. Seda funktsiooni nimetatakse krüptimise niitideks (encryption threads) ja artikli kirjutamise ajal on see endiselt eksperimentaalne.
Loe edasi:
Allikas: habr.com
