Uue kursuse alguse eelõhtul jätkame MySQL-i šifreerimist käsitleva artiklisarjaga.
Eelmises artiklis selles sarjas () rääkisime võtmehoidlatest. Selles artiklis käsitleme, kuidas kasutatakse peamist võtit (master key) ning arutame ümbriku šifreerimise (envelope encryption) eeliseid ja puudusi.
Ümbriku šifreerimise idee seisneb selles, et šifreerimiseks kasutatavad võtmed (ruumivõtmed) šifreeritakse teise võtmega (peamine võti, master key). Andmete šifreerimiseks kasutatakse tegelikult ruumivõtmeid. Graafiliselt võib seda kujutada järgmiselt:
Peamine võti (master key) asub võtmehoidlas (keyring), samas kui ruumivõtmed asuvad šifreeritud ruumide pealkirjades (tabular space 0 leht).
Ülaltoodud joonisel:
Tabel A on šifreeritud võtmega 1 (Key 1). Võti 1 on šifreeritud peamise võtmega (master key) ja säilitab šifreeritud kujul tabeli A pealkirjas.
Tabel B on šifreeritud võtmega 2 (Key 2). Võti 2 on šifreeritud peamise võtmega (master key) ja säilitab šifreeritud kujul tabeli B pealkirjas.
Ja nii edasi.
Kui server peab tabel A dešifreerima, siis saab ta võtmehoidlast peamise võtme, loeb šifreeritud võtme 1 tabeli A pealkirjast ja dešifreerib võtme 1. Dešifreeritud võti 1 vahepeetakse serveri mälus ja seda kasutatakse tabeli A dešifreerimiseks.
InnoDB
InnoDB-s toimub tegelik šifreerimine ja dešifreerimine sisend-väljund tasemel. See tähendab, et leht šifreeritakse otse enne, kui see kirjutatakse ketta, ja dešifreeritakse vahetult pärast lugemist kettalt.
InnoDB-s toimub šifreerimine ainult ruumide tasemel. Ja vaikimisi luuakse kõik tabelid eraldi ruumides (). Teisisõnu luuakse ruum, mis võib sisaldada ainult ühte tabelit. Kuigi võite luua tabeleid ka peamises ruumis (). Kuid igal juhul on tabel alati mingis ruumis. Ja kuna šifreerimine toimub ruumide tasemel, siis on see kas täielikult šifreeritud või mitte. See tähendab, et peamises ruumis ei saa ainult osa tabelitest šifreerida.
Kui teil on mingil põhjusel keelatud file-per-table, luuakse kõik tabelid süsteemi tabeliruumi (system tablespace) sisse. võib krüpteerida süsteemi tabeliruumi muutuja innodbsystabeliruumikrüpteerimise (encryption threads) abil, kuid see on endiselt katsetamisfaasis. MySQL-s seda ei ole.
Enne edasi liikumist peame vaatama peamise võtme identifikaatori (master key ID) struktuuri. See koosneb UUID-st, AVAID-st ja prefiksist «INNODBKey». See näeb välja nagu: INNODBKey-UUID-AVAID.
UUID on serveri uuid, kus on krüpteeritud tabeliruum. AVAID on lihtsalt pidevalt kasvav väärtus. Peamise võtme AVAID on alguses 1. Võtme ümberpööramise korral, kui luuakse uus peamine võtme, AVAID = 2 ja nii edasi. Peamise võtme ümberpööramisest räägime järgmistes artiklites selles seerias.
Nüüd, kui me teame, milline näeb välja peamise võtme identifikaator, vaatame krüpteeritud tabeliruumi päist. Kui tabeliruum on krüpteeritud, lisatakse krüpteerimise teave päisele. See näeb välja järgmiselt:
AVA ID on peamise võtme identifikaatorist, millest oleme juba rääkinud. UUID on serveri uuid, mida kasutatakse ka peamise võtme identifikaatoris. TABLESPACE KEY on tabeliruumi võti, mis koosneb 256 bitist, mis on serveri poolt juhuslikult genereeritud. Algväärtuse vektor (IV) koosneb samuti 256 juhuslikult genereeritud bitist (kuigi see peaks olema 128 bitti). IV-d kasutatakse AES-i krüpteerimise ja dekrüpteerimise algatamiseks (256 bitist kasutatakse vaid 128). Lõpus on TABLESPACE KEY ja IV jaoks CRC32 kontrollsumma.Kogu selle aega olen natuke lihtsustanud, öeldes, et päises on krüpteeritud tabeliruumi võti. Tegelikult hoitakse tabeliruumi võti ja algväärtuse vektor ning krüpteeritakse koos peamise võtmega. Pidage meeles, et enne tabeliruumi võtme ja algväärtuse vektori krüpteerimist arvutatakse neile CRC32.
Miks on CRC32 vajalik?
Miks on vajalik CRC32?
Kahes sõnas öeldes, tõendab peamise võtme kehtivust. Pärast ruumivõtme ja initsialiseerimismõõturi dekodeerimist arvutatakse kontrollsummad ja võrreldakse tabeli päises salvestatud CRC32-ga. Kui kontrollsummad ühtivad, siis on meil õige peamine võti ja ruumivõti. Vastasel juhul märgistatakse ruum nagu puuduv (me ei suuda seda ikkagi dekodeerida).
Võite küsida: millal võtmeid kontrollitakse? Vastus — serveri käivitamisel. Server, millel on krüptitud tabelid/tabeliruumi, loeb käivitamisel UUID, KEYID päisest ja genereerib peamise võtme ID. Seejärel hangib see vajalikku peamist võtit keyring’ist, dekodeerib ruumivõtme ja kontrollib kontrollsummat. Taaskord, kui kontrollsumma ühtib, siis on kõik korras, kui ei — ruumi märgitakse puuduvaks.
Kui olete lugenud selle seeria eelmist artiklit (), siis võite ehk meenutada, et serveri võtmehoidla kasutamisel saab server käivitamisel ainult võtme ID-de nimekirja, täpsemalt key id ja user id, kuna see paar tuvastab võtme ühemõtteliselt. Ja nüüd ütlen, et server saab käivitamisel kõik võtmed, mis on vajalikud, et kontrollida tabeli võtmete dekodeerimise võimalust. Nii et miks laaditakse serveri võtmehoidla initsialiseerimisel vaid keyid ja userid, mitte kõik võtmed? Sest kõiki võtmeid ei pruugi vaja minna. Enamasti on see seotud peamise võtme rotatsiooniga. Peamise võtme rotatsiooni korral luuakse hoidlasse uus peamine võti, kuid vanad võtmed ei kõrvaldata. Nii et serveri võtmehoidlas võib olla palju võtmeid, mida server ei vaja ja seega ei laadita neid serveri käivitamisel.
On aeg rääkida peamistest plussidest ja miinustest, mis on seotud peamise võtmega krüpteerimisega. Suurim eelis on see, et teil on vaja vaid ühte krüpteerimisvõtit (peamine võti), mis hoitakse eraldi teie krüpteeritud andmetest. See teeb serveri käivitamise kiireks ja salvestusruumi väheseks, mis lihtsustab haldamist. Samuti on ainus peamine võti kergesti uuesti genereeritav.
Siiski on peamise võtmega krüpteerimisel üks suur puudus: pärast seda, kui tabeliruum on krüpteeritud tablespace_key abil, jääb see alati sama võtmega krüpteerituks. Peamise võtme vahetamine ei aita siin. Miks see on puuduseks? Teame, et MySQL-is on vigu, mis võivad viia ootamatu kokkuvarisemiseni ja core-faili loomise nii. Kuna core-fail sisaldab serveri mälu dumpi, võib juhtuda, et dumpis on krüpteerimata tabeliruumi võtme. Mis veel hullem, dekrüpteeritud tabeliruumi võtmed hoitakse mälu sees, mis võib vahetuda kettale. Võite öelda, et see ei ole puudus, kuna teil on nende failide ja vahetusala juurde pääsemiseks vajalikud root õigused. Jah. Kuid root on vajalik vaid mõneks ajaks. 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 ketas olla varastatud ja vahetusala / core-failid võivad olla kolmandate osapoolte vahenditega loetavad. TDE eesmärk on muuta see loetamatuks, isegi kui ketas on varastatud. on võimalus tabeliruumi uuesti krüpteerida uute genereeritud võtmetega. Seda funktsiooni nimetatakse krüpteerimise voogudeks (encryption threads) ja selle artikli kirjutamise hetkel on see endiselt katsejärgus.
Loe edasi:
Allikas: habr.com
