Kursusele uue registreerimise ootuses jätkame MySQL-i krüptimist käsitlevate artiklite seeria avaldamist.
Selle sarja eelmises artiklis () rääkisime võtmehoidjatest. Selles artiklis vaatleme, kuidas põhivõtit kasutatakse, ning arutame ümbriku krüptimise eeliseid ja puudusi.
Ümbriku krüptimise idee seisneb selles, et krüptimiseks kasutatavad võtmed (tabeliruumi võtmed) krüpteeritakse teise võtmega (peavõti). Tabeliruumi võtmeid kasutatakse tegelikult andmete krüptimiseks. Graafiliselt saab seda kujutada järgmiselt:
Peavõti asub võtmehoidlas ja tabeliruumi võtmed on krüptitud tabeliruumide päistes (tabeliruumi leheküljel 0).
Ülaloleval pildil:
-
Tabel A on krüptitud võtmega 1 (Võti 1). Võti 1 krüpteeritakse põhivõtmega ja salvestatakse krüpteeritult tabeli A päisesse.
-
Tabel B on krüptitud võtmega 2 (võti 2). Võti 2 krüpteeritakse maskeerimisvõtmega ja salvestatakse krüpteeritult tabeli B päisesse.
-
Ja nii edasi.
Kui server peab tabelit A dekrüpteerima, saab ta poest põhivõtme, loeb tabeli A päisest krüptitud võtme 1 ja dekrüpteerib võtme 1. Dekrüpteeritud võti 1 salvestatakse vahemällu serveri mällu ja seda kasutatakse tabeli A dekrüpteerimiseks. .
InnoDB
InnoDB-s toimub tegelik krüptimine ja dekrüpteerimine I/O tasemel. See tähendab, et leht krüpteeritakse vahetult enne selle kettale viimist ja dekrüpteeritakse kohe pärast kettalt lugemist.
InnoDB-s töötab krüptimine ainult tabeliruumi tasemel. Ja vaikimisi luuakse kõik tabelid eraldi tabeliruumides (). Teisisõnu luuakse tabeliruum, mis võib sisaldada ainult ühte tabelit. Kuigi saate luua tabeleid ka põhitabeliruumis (). Aga igal juhul on laud alati mingis lauaruumis. Ja kuna krüpteerimine toimub tabeliruumi tasemel, on see kas täielikult krüptitud või mitte. See tähendab, et te ei saa krüptida ainult osa põhitabeli ruumis olevatest tabelitest.
Kui olete mingil põhjusel fail-per-table keelanud, luuakse kõik tabelid süsteemi tabeliruumis. IN saate süsteemi tabeliruumi krüptida muutuja innodb abilsyslauaruumkrüptida või kasutada krüpteerimislõime, kuid see on siiski eksperimentaalne funktsioon. MySQL-il seda pole.
Enne edasiliikumist peame kaaluma põhivõtme ID struktuuri. See koosneb UUID-st, KEY-stID ja eesliide "INNODBKey". See näeb välja selline: INNODBKey-UUID-KEYID.
UUID on krüptitud tabeliruumiga serveri uuid. võtiID on lihtsalt aina kasvav väärtus. Kui loote esmakordselt peavõtme KEYID on 1. Võtme pööramise ajal, kui luuakse uus peavõti, KEYID = 2 ja nii edasi. Peavõtme pööramisest räägime lähemalt selle sarja hilisemates artiklites.
Nüüd, kui teame, kuidas põhivõtme identifikaator välja näeb, vaatame krüptitud tabeliruumi päist. Kui tabeliruum on krüptitud, lisatakse krüptimisteave päisesse. See näeb välja selline:
KEYID on KEYPeavõtme ID ID, mida oleme juba arutanud. UUID on serveri uuid ja seda kasutatakse ka põhivõtme identifikaatoris. TABLESPACE KEY – tabeliruumi võti, mis koosneb 256 bitist, mis on serveri poolt juhuslikult genereeritud. Initsialiseerimisvektor (IV, initsialiseerimisvektor) koosneb samuti 256 juhuslikult genereeritud bitist (kuigi see peaks olema 128 bitti). IV kasutatakse AES-i krüptimise ja dekrüpteerimise lähtestamiseks (256 bitist kasutatakse ainult 128). Lõpus on TABLESPACE KEY ja IV CRC32 kontrollsumma.
Kogu selle aja olen ma veidi lihtsustanud, öeldes, et päises on krüpteeritud tabeliruumi võti. Tegelikult salvestatakse ja krüpteeritakse tabeliruumi võti ja lähtestamisvektor koos põhivõtme abil. Pidage meeles, et enne tabeliruumi võtme ja lähtestamisvektori krüptimist arvutatakse nende jaoks CRC32.
Miks on CRC32 vaja?
Lühidalt, et veenduda põhivõtme kehtivuses. Pärast tabeliruumi võtme ja lähtestamisvektori dekrüpteerimist arvutatakse kontrollsumma ja võrreldakse päisesse salvestatud CRC32-ga. Kui kontrollsummad ühtivad, on meil õige peavõti ja tabeliruumi võti. Vastasel juhul märgitakse tabeliruum puuduvaks (me ei saa seda ikka dekrüpteerida).
Võite küsida: mis hetkel toimub võtmete kontrollimine? Vastus on siis, kui server käivitub. Krüptitud tabelite/tabeliruumidega server loeb käivitamisel UUID-d, KEY-dID päisest ja genereerib peavõtme ID. Seejärel hangib see võtmerõngast vajaliku peavõtme, dekrüpteerib tabeliruumi võtme ja kontrollib kontrollsummat. Veel kord, kui kontrollsumma klapib, siis on kõik korras, ei - tabeliruum on märgitud puuduvaks.
Kui loete selle sarja viimast artiklit (), siis pidage ehk meeles, et serveri võtmehoidla kasutamisel saab server käivitamisel ainult võtmeidentifikaatorite loendi, täpsemalt võtme ID ja kasutaja ID, kuna see paar tuvastab võtme kordumatult. Ma ütlen praegu, et server saab käivitamisel kõik võtmed, mida ta vajab, et kontrollida, kas tabeliruumi võtmeid saab dekrüpteerida. Miks siis initsialiseerimisel serveri salvestusruumi puhul laaditakse ainult võtiID ja kasutajaID ja mitte kõik võtmed? Sest kõiki võtmeid ei pruugi vaja minna. See on peamiselt tingitud peavõtme pöörlemisest. Kui peavõtit hoidlas pööratakse, luuakse uus peavõti, kuid vanu võtmeid ei kustutata. Seega võib teil serveri võtmehoidlas olla palju võtmeid, mida server ei vaja ja seetõttu ei leita neid serveri käivitumisel.
On aeg rääkida veidi põhivõtmega krüptimise eelistest ja puudustest. Suurim eelis on see, et vajate ainult ühte krüpteerimisvõtit (peavõtit), mida hoitakse teie krüptitud andmetest eraldi. See muudab serveri käivitamise kiireks ja salvestusruumi väikeseks, muutes selle haldamise lihtsaks. Ja ka ainsat peavõtit on lihtne taastada.
Põhivõtme krüptimisel on aga üks suur puudus: kui tabeliruum on krüpteeritud atribuudiga tablespace_key, jääb see alati sama võtmega krüpteerituks. Peavõtme pööramine siin ei aita. Miks on see puudus? Teame, et MySQL-is on vigu, mis võivad põhjustada selle kokkujooksmise ja põhifaili loomise. Kuna põhifail sisaldab serveri mälutõmmist, võib juhtuda, et see sisaldab dekrüpteeritud tabeliruumi võtit. Veelgi hullem on see, et dekrüpteeritud tabeliruumi võtmed salvestatakse mällu, mille saab kettale vahetada. Võite öelda, et see pole puudus, kuna vajate nendele failidele ja vahetuspartitsioonile juurdepääsuks juurõigusi. Jah. Kuid juuri on vaja ainult mõnda aega. Kui kellelgi on juurdepääs dekrüptitud tabeliruumi võtmele, saab ta seda andmete dekrüpteerimiseks jätkata, isegi ilma juurjuurdepääsuta. Lisaks saab ketta varastada ja vahetus- / põhifaile saab lugeda kolmandate osapoolte tööriistade abil. TDE eesmärk on muuta see loetamatuks isegi siis, kui ketas on varastatud. IN tabeliruumi on võimalik uuesti krüpteerida äsja genereeritud võtmetega. Seda funktsiooni nimetatakse krüpteerimislõimedeks ja see on selle kirjutamise ajal veel eksperimentaalne.
Loe rohkem:
Allikas: www.habr.com