Az új kurzus indítása előtt Folytatjuk a MySQL titkosítással foglalkozó cikkek sorozatát.
A sorozat előző cikkében () a kulcs tárolókról beszéltünk. Ebben a cikkben a fő kulcs (master key) használatát nézzük meg, és megvitatjuk a burkoló titkosítás (envelope encryption) előnyeit és hátrányait.
A burkoló titkosítás ötlete abban rejlik, hogy a titkosításhoz használt kulcsok (tároló kulcsok) egy másik kulccsal (fő kulcs, master key) vannak titkosítva. Az adatok titkosítására valójában a tároló kulcsokat használják. Grafikus ábrázolásban ez így néz ki:
A fő kulcs (master key) a kulcstárolóban (keyring) található, míg a tároló kulcsok a titkosított tárolók fejlécében helyezkednek el (a tároló 0. oldalán).
A fent látható ábrán:
Az A táblázat az 1-es kulccsal (Key 1) van titkosítva. Az 1-es kulcsot a fő kulcs (master key) segítségével titkosítják, és titkosítva tárolják az A táblázat fejlécében.
A B táblázat a 2-es kulccsal (Key 2) van titkosítva. A 2-es kulcsot a fő kulcs (master key) segítségével titkosítják, és titkosítva tárolják a B táblázat fejlécében.
Mindezek mellett.
Amikor a szervernek meg kell dekódolnia az A táblázatot, megszerzi a fő kulcsot a kulcstárolóból, elolvassa az 1-es kulcsot a titkosított A táblázat fejlécéből, és dekódolja az 1-es kulcsot. A dekódolt 1-es kulcs a szerver memóriájában van tárolva, és az A táblázat dekódolásához használják.
InnoDB
Az InnoDB rendszerben a tényleges titkosítás és dekódolás a be- és kiolvasás (I/O) szintjén történik. Tehát az oldal közvetlenül azelőtt van titkosítva, hogy a lemezre írnák, és azonnal dekódolják, miután a lemezről olvasják.
Az InnoDB titkosítása csak a tároló szintjén működik. Alapértelmezés szerint az összes táblázat külön tárolókban jön létre (). Más szavakkal, egy olyan tároló jön létre, amely csak egy táblázatot tartalmazhat. Bár táblázatokat létrehozhat az alap tárolóban is (). De bárhogy is van, a táblázat mindig egy tárolóban van. Mivel a titkosítás a tároló szintjén történik, ezért az teljesen titkosítva van, vagy egyáltalán nem. Tehát nem lehet az alap tárolóban csak a táblázatok egy részét titkosítani.
Ha bármilyen okból a file-per-table ki van kapcsolva, akkor az összes tábla a rendszer táblázati térben (system tablespace) jön létre. A rendszer táblázati teret titkosíthatjuk az innodb változó használatával.systablespaceencrypt vagy titkosítási szálak (encryption threads) segítségével, de ez még mindig kísérleti funkció. A MySQL-ben ez nem elérhető.
Mielőtt tovább lépnénk, meg kell vizsgálnunk a mester kulcs azonosító (master key ID) szerkezetét. Ez UUID-ból, KEYID-ből és az "INNODBKey" előtagból áll. Így néz ki: INNODBKey-UUID-KEYID.
Az UUID az a szerver UUID, amely titkosított táblázati térrel rendelkezik. A KEYID csupán egy folyamatosan növekvő érték. A fő kulcs első létrehozásakor a KEYID 1. A kulcs rotálásakor, amikor új mester kulcsot hoznak létre, a KEYID = 2 és így tovább. A fő kulcsok rotációjáról a következő cikkekben fogunk beszélni.
Most, hogy tudjuk, hogyan néz ki a mester kulcs azonosítója, nézzük meg a titkosított táblázati tér fejlécét. Amikor a táblázati tér titkosítva van, a titkosítással kapcsolatos információt a fejléchez adják. Így néz ki:
A KEY ID a már megvitatott mester kulcs azonosító KEYID-ja. Az UUID a szerver uuid, amelyet szintén használnak a mester kulcs azonosítójában. A TABLESPACE KEY egy 256 bites kulcs, amelyet a szerver véletlenszerűen generál. Az inicializálási vektor (IV, initialization vector) szintén 256 véletlenszerűen generált bitből áll (bár 128 bitnek kellene lennie). Az IV-t a titkosítás és visszafejtés AES inicializálására használják (a 256 bitből csak 128 használható). A végén egy CRC32 ellenőrzőösszeg található a TABLESPACE KEY és az IV számára.
Mindeközben kicsit leegyszerűsítettem azzal, hogy azt mondtam, a fejlécben titkosított táblázati tér kulcsa található. Valójában a táblázati tér kulcsa és az inicializálási vektor együtt tárolódik és titkosítódik a fő kulcs segítségével. Ne feledje, hogy a táblázati tér kulcsának és az inicializálási vektor titkosítása előtt CRC32-t számítanak ki számukra.
Miért van szükség CRC32-re?
Röviden, a fő kulcs érvényességének ellenőrzéséhez szükséges. A táblatér és az inicializáló vektor kulcsának visszafejtése után ellenőrző összeg számítódik, amelyet összehasonlítunk a fejlécben tárolt CRC32-vel. Ha az ellenőrző összegek megegyeznek, akkor a fő kulcs és a táblatér kulcsa helyes. Ellenkező esetben a táblatér hiányzóként van megjelölve (akkor sem tudjuk visszafejteni).
Megkérdezheti: mikor történik a kulcsok ellenőrzése? A válasz: a szerver indításakor. A titkosított táblák / táblaterek szerver indításkor beolvassa az UUID-t, a KEY-ta fejlécből, és generálja a fő kulcs azonosítóját. Ezután megszerzi a szükséges fő kulcsot a tárolóból (keyring), visszafejti a táblatér kulcsát, és ellenőrzi az ellenőrző összeget. Ismét, ha az ellenőrző összeg egyezik, akkor minden rendben van, ha nem – a táblatér hiányzóként van megjelölve.
Ha olvasta a sorozat előző részét (), akkor talán emlékszik rá, hogy a szerver kulcstárolójának használatakor a szerver indításkor csak a kulcsazonosítók listáját kapja meg, pontosabban a key id-t és a user id-t, mivel ez a pár egyértelműen azonosítja a kulcsot. Most azt mondom, hogy a szerver indításakor minden olyan kulcsot megkap, amely szükséges a táblatér kulcsainak visszafejtésének ellenőrzéséhez. De miért van az, hogy a szerver tárolójában, a kulcsok ellenőrzésekor, csak a keyid és userid jelenik meg, nem pedig minden kulcs? Mert nem szükséges az összes kulcs. Ez főleg a fő kulcs forgatásával kapcsolatos. A fő kulcs forgatásakor a tárolóban új fő kulcs kerül létrehozásra, de a régi kulcsok nem törölhetők. Így a szerver kulcstárolójában sok olyan kulcs lehet, amelyekre a szervernek nincs szüksége, ezért indításkor nem is kerülnek lekérdezésre.
Itt az ideje, hogy egy kicsit beszéljünk a főkulcsos titkosítás előnyeiről és hátrányairól. A legnagyobb előny, hogy csak egy titkosítási kulcsra (főkulcsra) van szükséged, amelyet külön tárolsz a titkosított adataidtól. Ez gyorsabbá teszi a szerverindítást és csökkenti a tárolási igényeket, ami megkönnyíti a kezelését. Továbbá, mivel csak egy főkulcs van, azt könnyen újragenerálhatod.
Azonban a főkulcsos titkosításnak van egy jelentős hátránya: miután a táblázat tér adott táblázat_key segítségével titkosításra került, folyamatosan ugyanazzal a kulccsal marad titkosítva. A főkulcs rotációja itt nem segít. Miért ez hátrány? Tudjuk, hogy a MySQL-ben vannak hibák, amelyek hirtelen leállásokhoz és core-fájlok létrehozásához vezethetnek. Mivel a core-fájlok tartalmazzák a szerver memória dumpját, előfordulhat, hogy a dumpban a táblázat tér dekódolt kulcsa található. Mi még rosszabb, hogy a dekódolt táblázat tér kulcsok a memóriában tárolódnak, ami lecsuszatható a lemezre. Mondhatod, hogy ez nem hátrány, mivel root-jogok szükségesek ezekhez a fájlokhoz és a swap területhez való hozzáféréshez. Igen. De a root-jogokra csak egy időre van szükséged. Amint valaki hozzáfér a dekódolt táblázat tér kulcshoz, ő/ő azt tovább tudja használni az adatok dekódolására, még root-jogok nélkül is. Ezenkívül a lemez ellopható, és a swap terület/core-fájlok harmadik féltől származó eszközökkel olvashatók. A TDE célja, hogy olvashatatlanná tegye, még ha a lemez ellopásra kerül is. lehetőséged van a táblázat tér újonnan generált kulcsokkal való újratitkosítására. Ezt a funkciót titkosítási szálaknak (encryption threads) hívják, és a cikk írásakor még mindig kísérleti fázisban van.
Tovább olvasva:
Forrás: habr.com
