Šifriranje u MySQL: korištenje glavnog ključa

U iščekivanju početka novog upisa za kurs "baza podataka" nastavljamo da objavljujemo seriju članaka o enkripciji u MySQL-u.

U prethodnom članku iz ove serije (Šifriranje u MySQL: Keystore) razgovarali smo o spremištima ključeva. U ovom članku ćemo pogledati kako se koristi glavni ključ i razmotriti prednosti i nedostatke enkripcije omotnice. 

Ideja koja stoji iza enkripcije omotnice je da su ključevi koji se koriste za šifriranje (ključevi prostora tablice) šifrirani drugim ključem (master ključem). Ključevi tabličnog prostora se zapravo koriste za šifriranje podataka. Grafički, ovo se može predstaviti na sljedeći način:

Glavni ključ je u skladištu ključeva, a ključevi prostora tablice su u šifriranim zaglavljima prostora tablice (na stranici 0 tabličnog prostora). 

Na gornjoj slici:

• Tabela A je šifrirana ključem 1 (Ključ 1). Ključ 1 je šifriran pomoću glavnog ključa i pohranjen je šifriran u zaglavlju tabele A.

• Tabela B je šifrirana ključem 2 (Ključ 2). Ključ 2 je šifriran pomoću maskirnog ključa i pohranjen je šifriran u zaglavlju tabele B.

• I tako dalje.

Kada server treba da dešifruje tabelu A, dobija glavni ključ iz prodavnice, čita šifrovani ključ 1 iz zaglavlja tabele A i dešifruje ključ 1. Dešifrovani ključ 1 se sprema u memoriju servera i koristi se za dešifrovanje tabele A .

InnoDB

U InnoDB-u, stvarno šifriranje i dešifriranje se vrši na I/O nivou. Odnosno, stranica se šifrira neposredno prije nego što se izbaci na disk i dešifruje odmah nakon čitanja s diska.

U InnoDB-u, enkripcija radi samo na razini tabličnog prostora. I prema zadanim postavkama sve tabele se kreiraju u odvojenim prostorima (file-per-table tablespace). Drugim riječima, kreira se prostor tablice koji može sadržavati samo jednu tablicu. Iako možete kreirati tabele i u glavnom prostoru tablica (opći prostor tablice). Ali u svakom slučaju, tabela je uvijek u nekom prostoru tablice. A pošto se šifriranje vrši na nivou tabličnog prostora, ono je ili u potpunosti šifrirano ili ne. To jest, ne možete šifrirati samo dio tabela u glavnom prostoru tablice. 

Ako ste iz nekog razloga onemogućili datoteku po tablici, tada se sve tabele kreiraju unutar sistemskog prostora tablica. IN Percona server za MySQL možete šifrirati sistemski prostor tablice koristeći innodb varijablusystablespacešifriranje ili korištenje niti šifriranja, ali ovo je još uvijek eksperimentalna karakteristika. MySQL nema ovo.

Prije nego što krenemo dalje, moramo razmotriti strukturu ID-a glavnog ključa. Sastoji se od UUID, KLJUČID i prefiks "INNODBKey". To izgleda ovako: INNODBKey-UUID-KEYID.

UUID je uuid servera sa šifriranim prostorom tablice. ključID je samo vrijednost koja se stalno povećava. Kada prvi put kreirate glavni ključID je 1. Tokom rotacije ključa, kada se kreira novi glavni ključ, KEYID = 2 i tako dalje. Više ćemo govoriti o rotaciji glavnog ključa u kasnijim člancima u ovoj seriji.

Sada kada znamo kako izgleda identifikator glavnog ključa, pogledajmo zaglavlje šifriranog prostora tablice. Kada je prostor tablice šifriran, informacije o šifriranju se dodaju u zaglavlje. izgleda ovako:

KEYID je KEYID iz ID-a glavnog ključa o kojem smo već razgovarali. UUID je uuid servera i također se koristi u identifikatoru glavnog ključa. TABLESPACE KEY - ključ prostora tabele, koji se sastoji od 256 bita, nasumično generisan od strane servera. Inicijalizacijski vektor (IV, inicijalizacijski vektor) se također sastoji od 256 nasumično generiranih bitova (iako bi trebao biti 128 bitova). IV se koristi za inicijalizaciju AES enkripcije i dešifriranja (od 256 bita, koristi se samo 128). Na kraju se nalazi kontrolni zbroj CRC32 za TABLESPACE KEY i IV.

Sve ovo vrijeme sam malo pojednostavljivao govoreći da u zaglavlju postoji šifrirani ključ prostora tablice. U stvari, ključ prostora tablice i vektor inicijalizacije su pohranjeni i šifrirani zajedno pomoću glavnog ključa. Zapamtite da se prije šifriranja ključ prostora tablice i inicijalizacijski vektor za njih izračunava CRC32.

Zašto je potreban CRC32?

Ukratko, da bi se provjerila valjanost glavnog ključa. Nakon dešifriranja ključa prostora tablice i vektora inicijalizacije, izračunava se kontrolna suma i upoređuje sa CRC32 pohranjenim u zaglavlju. Ako se kontrolni zbroji podudaraju, tada imamo ispravan glavni ključ i ključ prostora tablice. U suprotnom, prostor tablice je označen kao nedostajući (još uvijek ga ne možemo dešifrirati).

Možete pitati: u kom trenutku se vrši verifikacija ključeva? Odgovor je kada se server pokrene. Server sa šifrovanim tabelama/prostorima tablica čita UUID, KEY pri pokretanjuID iz zaglavlja i generira ID glavnog ključa. Zatim dobija potrebni glavni ključ iz prstena ključeva, dešifruje ključ prostora tablice i provjerava kontrolnu sumu. Još jednom, ako se kontrolni zbir poklapa, onda je sve u redu, ne - prostor tablice je označen kao nedostajući.

Ako ste pročitali zadnji članak u ovoj seriji (Šifriranje u MySQL: Keystore), onda možda zapamtite da kada se koristi skladište ključeva servera, server prima samo listu identifikatora ključeva pri pokretanju, tačnije, ID ključa i ID korisnika, budući da ovaj par jedinstveno identificira ključ. Ono što sada govorim je da server, pri pokretanju, dobija sve ključeve koji su mu potrebni da provjeri da li se ključevi prostora tablice mogu dešifrirati. Pa zašto se prilikom inicijalizacije, u slučaju serverske memorije, učitava samo ključid i korisnikid, a ne svi ključevi? Jer vam možda neće trebati svi ključevi. To je uglavnom zbog rotacije glavnog ključa. Kada se glavni ključ rotira u trezoru, kreira se novi glavni ključ, ali se stari ključevi ne brišu. Stoga možete imati mnogo ključeva u skladištu ključeva servera koji serveru nisu potrebni i stoga se ne preuzimaju kada se server pokrene.

Vrijeme je da malo porazgovaramo o prednostima i nedostacima šifriranja pomoću glavnog ključa. Najveća prednost je što vam je potreban samo jedan ključ za šifriranje (master ključ), koji će se čuvati odvojeno od vaših šifriranih podataka. Ovo čini pokretanje servera brzim, a skladištenje malim, što olakšava upravljanje. I jedini glavni ključ se lako regeneriše.

Međutim, šifriranje glavnog ključa ima jedan veliki nedostatak: jednom kada je tablični prostor šifriran pomoću tablespace_key, on uvijek ostaje šifriran istim ključem. Rotacija glavnog ključa ovdje ne pomaže. Zašto je ovo nedostatak? Znamo da MySQL ima greške koje mogu uzrokovati njegov pad i stvaranje osnovne datoteke. Budući da datoteka jezgre sadrži dump serverske memorije, može se dogoditi da dump sadrži dešifrirani ključ prostora tablice. Što je još gore, dešifrirani ključevi prostora tablice su pohranjeni u memoriji, koja se može zamijeniti na disk. Možete reći da ovo nije nedostatak jer su vam potrebne root dozvole za pristup ovim datotekama i swap particiji. Da. Ali root je potreban samo neko vrijeme. Jednom kada neko ima pristup dešifrovanom ključu prostora tablice, on/ona može nastaviti da ga koristi za dešifriranje podataka, čak i bez root pristupa. Osim toga, disk se može ukrasti, a swap / core fajlovi se mogu čitati pomoću alata treće strane. Cilj TDE-a je učiniti ga nečitljivim čak i ako je disk ukraden. IN Percona server za MySQL moguće je ponovo šifrirati prostor tablice s novogeneriranim ključevima. Ova funkcija se naziva niti šifriranja i još uvijek je eksperimentalna u vrijeme pisanja ovog teksta.

Saznajte više o kursu

Čitaj više:

• Šifriranje u MySQL: Keystore

izvor: www.habr.com