Titkosítás a MySQL-ben: Keystore

A tanfolyamra való új beiratkozás kezdetére számítva "Adatbázis" Elkészítettünk Önnek egy hasznos cikk fordítását.

Az átlátszó adattitkosítás (TDE) ben jelent meg Percona Server MySQL-hez és a MySQL-t jó ideig. De gondoltál már arra, hogyan működik a motorháztető alatt, és milyen hatással lehet a TDE a szerveredre? Ebben a cikksorozatban megvizsgáljuk a TDE belső működését. Kezdjük a kulcstárral, mivel ez szükséges minden titkosítás működéséhez. Ezután közelebbről megvizsgáljuk, hogyan működik a titkosítás a Percona Server for MySQL/MySQL-ben, és milyen további funkciókkal rendelkezik a Percona Server for MySQL.

MySQL kulcstartó

A kulcstartó beépülő modulok, amelyek lehetővé teszik a szerver számára kulcsok lekérdezését, létrehozását és törlését egy helyi fájlban (keyring_file) vagy egy távoli kiszolgálón (például a HashiCorp Vault). A kulcsok mindig helyi gyorsítótárban vannak, hogy felgyorsítsák visszakeresésüket.

A bővítmények két kategóriába sorolhatók:

• Helyi raktár. Például egy helyi fájl (ezt fájl alapú kulcstartónak nevezzük).
• Távoli tárolás. Például a Vault Server (ezt szerver alapú kulcstartónak hívjuk).

Ez a szétválasztás azért fontos, mert a különböző típusú tárolók kissé eltérően viselkednek, nem csak a kulcsok tárolása és lekérése során, hanem azok futtatásakor is.

Fájltároló használatakor indításkor a tároló teljes tartalma betöltődik a gyorsítótárba: kulcsazonosító, kulcsfelhasználó, kulcstípus és maga a kulcs.

Szerveroldali tároló esetén (például Vault Server) induláskor csak a kulcsazonosító és a kulcsfelhasználó töltődik be, így az összes kulcs megszerzése nem lassítja le az indítást. A kulcsokat lustán töltik be. Vagyis maga a kulcs csak akkor töltődik be a Vaultból, amikor valóban szükség van rá. A letöltést követően a kulcs gyorsítótárba kerül a memóriában, így a jövőben nem kell TLS-kapcsolaton keresztül elérni a Vault-kiszolgálóval. Ezután nézzük meg, milyen információk vannak a kulcstárolóban.

A legfontosabb információk a következőket tartalmazzák:

• kulcs id — kulcsazonosító, például:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• kulcs típusa — kulcstípus a használt titkosítási algoritmus alapján, lehetséges értékek: „AES”, „RSA” vagy „DSA”.
• kulcs hossza — a kulcs hossza bájtokban, AES: 16, 24 vagy 32, RSA 128, 256, 512 és DSA 128, 256 vagy 384.
• használó - a kulcs tulajdonosa. Ha a kulcs rendszer, például mesterkulcs, akkor ez a mező üres. Ha a kulcs a keyring_udf használatával jön létre, akkor ez a mező azonosítja a kulcs tulajdonosát.
• maga a kulcs

A kulcsot a következő pár egyedileg azonosítja: key_id, user.

A kulcsok tárolása és törlése terén is vannak különbségek.

A fájltárolás gyorsabb. Azt gondolhatnánk, hogy egy kulcstároló egyszerűen csak egyszer írja be a kulcsot egy fájlba, de nem, itt többről van szó. A fájltároló módosításakor először minden tartalomról biztonsági másolat készül. Tegyük fel, hogy a fájl neve my_biggest_secrets, akkor a biztonsági másolat a my_leglegest_secrets.backup lesz. Ezután a gyorsítótár módosul (kulcsok hozzáadása vagy törlése), és ha minden sikeres, a gyorsítótár visszaáll egy fájlba. Ritka esetekben, például szerverhiba esetén, láthatja ezt a biztonsági mentési fájlt. A biztonsági másolat fájl törlődik a kulcsok következő betöltésekor (általában a szerver újraindítása után).

Amikor egy kulcsot mentünk vagy törölünk egy szerver tárolóban, a tárolónak csatlakoznia kell a MySQL szerverhez a „kulcs küldése” / „kulcs törlésének kérése” parancsokkal.

Térjünk vissza a szerver indítási sebességéhez. Amellett, hogy az indítási sebességet maga a trezor befolyásolja, felmerül az is, hogy indításkor hány kulcsot kell lekérni a tárolóból. Természetesen ez különösen a szerverek tárolásánál fontos. Indításkor a szerver ellenőrzi, hogy melyik kulcsra van szükség a titkosított táblákhoz/táblaterületekhez, és lekéri a kulcsot a tárolótól. Egy „tiszta” mesterkulcs-titkosítással rendelkező szerveren egy mesterkulcsnak kell lennie, amelyet le kell kérni a tárhelyről. Azonban nagyobb számú kulcsra lehet szükség, például amikor a biztonsági mentési szerver biztonsági másolatot állít vissza az elsődleges kiszolgálóról. Ilyen esetekben biztosítani kell a főkulcs elforgatását. Erről a későbbi cikkekben részletesebben lesz szó, bár itt szeretném megjegyezni, hogy egy több mesterkulcsot használó szerver indítása kissé tovább tarthat, különösen szerveroldali kulcstároló használata esetén.

Most beszéljünk egy kicsit többet a keyring_file-ról. Amikor a keyring_file fájlt fejlesztettem, azon is aggódtam, hogy miként ellenőrizhetem a keyring_file változásait, miközben a szerver fut. Az 5.7-ben fájlstatisztika alapján történt az ellenőrzés, ami nem volt ideális megoldás, a 8.0-ban pedig SHA256 ellenőrzőösszegre cserélték.

A keyring_file első futtatásakor a rendszer kiszámítja a fájlstatisztikát és az ellenőrző összeget, amelyeket a szerver megjegyzik, és a változtatások csak akkor érvényesek, ha megegyeznek. Amikor a fájl megváltozik, az ellenőrző összeg frissül.

Már sok kérdést megválaszoltunk a kulcstárolókkal kapcsolatban. Van azonban egy másik fontos téma is, amelyet gyakran elfelejtenek vagy félreértenek: a kulcsok szerverek közötti megosztása.

Mire gondolok? A fürt minden kiszolgálójának (például Percona Server) külön helyen kell lennie a Vault kiszolgálón, ahol a Percona Servernek tárolnia kell a kulcsait. Minden tárhelyen elmentett mesterkulcs tartalmazza a Percona Server GUID-jét az azonosítójában. Miért fontos? Képzelje el, hogy csak egy Vault-kiszolgálója van, és a fürt összes Percona-kiszolgálója ezt az egyetlen Vault-kiszolgálót használja. A probléma nyilvánvalónak tűnik. Ha az összes Percona szerver egyedi azonosítók (például id = 1, id = 2 stb.) nélküli mesterkulcsot használna, akkor a fürt összes kiszolgálója ugyanazt a mesterkulcsot használná. A GUID különbséget tesz a kiszolgálók között. Miért beszélnénk a kulcsok szerverek közötti megosztásáról, ha már létezik egyedi GUID? Van egy másik bővítmény - keyring_udf. Ezzel a beépülő modullal a szerver felhasználója tárolhatja kulcsait a Vault szerveren. A probléma akkor jelentkezik, ha a felhasználó létrehoz egy kulcsot például a szerver1-en, majd megpróbál létrehozni egy kulcsot ugyanazzal az azonosítóval a szerver2-n, például:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

Várjon. Mindkét szerver ugyanazt a Vault-kiszolgálót használja. Nem kellene a keyring_key_store függvénynek meghibásodnia a szerver2-n? Érdekes módon, ha ugyanazt egy szerveren próbálja megtenni, hibaüzenetet fog kapni:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

Így van, a ROB_1 már létezik.

Először beszéljük meg a második példát. Ahogy korábban említettük, a keyring_vault vagy bármely más kulcstartó beépülő modul a memóriában tárolja az összes kulcsazonosítót. Tehát egy új kulcs létrehozása után a ROB_1 hozzáadásra kerül a szerver1-hez, és amellett, hogy ezt a kulcsot elküldi a Vaultnak, a kulcs a gyorsítótárba is bekerül. Most, amikor megpróbáljuk másodszor hozzáadni ugyanazt a kulcsot, a keyring_vault ellenőrzi, hogy a kulcs létezik-e a gyorsítótárban, és hibát jelez.

Az első esetben a helyzet más. A Server1 és a Server2 külön gyorsítótárral rendelkezik. Miután hozzáadta a ROB_1 kulcsgyorsítótárat a szerver1-en és a Vault-kiszolgálón, a kiszolgáló2-es kulcsgyorsítótára nincs szinkronban. A szerver2 gyorsítótárában nincs ROB_1 kulcs. Így a ROB_1 kulcs a keyring_key_store-ba és a Vault kiszolgálóra íródik, amely valójában felülírja (!) az előző értéket. Most a Vault kiszolgálón a ROB_1 kulcs 543210987654321. Érdekes módon a Vault szerver nem blokkolja az ilyen műveleteket, és könnyen felülírja a régi értéket.

Most már láthatjuk, miért lehet fontos a szerverparticionálás a Vaultban – amikor a keyring_udf-ot használja, és a kulcsokat a Vaultban szeretné tárolni. Hogyan érhető el ez a szétválasztás a Vault szerveren?

Kétféleképpen particionálhat a Vaultba. Létrehozhat különböző csatolási pontokat minden kiszolgálóhoz, vagy különböző útvonalakat használhat ugyanazon a csatlakozási ponton belül. Ezt példákkal lehet a legjobban illusztrálni. Tehát először nézzük meg az egyes rögzítési pontokat:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)

--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)

Itt láthatja, hogy a szerver1 és a szerver2 különböző csatolási pontokat használ. Az útvonalak felosztásakor a konfiguráció így fog kinézni:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)

Ebben az esetben mindkét kiszolgáló ugyanazt a „csatolási_pont” csatolási pontot használja, de eltérő elérési utat. Amikor létrehozza az első titkot a szerver1-en ezen az útvonalon, a Vault-kiszolgáló automatikusan létrehoz egy „server1” könyvtárat. A szerver2 esetében minden hasonló. Amikor törli az utolsó titkos adatot a beillesztési_pont/kiszolgáló1 vagy beillesztési_pont/szerver2-ben, a Vault-kiszolgáló ezeket a könyvtárakat is törli. Útvonal-leválasztás használata esetén csak egy csatolási pontot kell létrehoznia, és módosítania kell a konfigurációs fájlokat úgy, hogy a kiszolgálók külön útvonalakat használjanak. Csatlakozási pont HTTP-kéréssel hozható létre. A CURL használatával ezt a következőképpen lehet megtenni:

curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINT

Minden mező (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) megfelel a konfigurációs fájl paramétereinek. Természetesen használhatja a Vault segédprogramokat is erre. De egyszerűbb automatizálni a csatolási pont létrehozását. Remélem, hasznosnak találja ezeket az információkat, és találkozunk a sorozat következő cikkeiben.

Olvass tovább:

• Sysbench és a valószínűségi változók eloszlása

Forrás: will.com