La criptarea odihnei

La criptare de odihnă

1) De ce este necesar și ce anume protejăm

Definiție. Criptarea în repaus este protecția datelor scrise pe suporturi (discuri, instantanee, copii de rezervă, obiecte, jurnale, halde de memorie), astfel încât accesul neautorizat la suporturile fizice sau la stocarea „brută” să nu dezvăluie conținut.

• Bloc/volume de fișiere, depozite de obiecte, baze de date, cozi/cavele, halde de cache, busteni/trasee, backup-uri, export/import, instantanee VM/container, sâmburi de nucleu/proces, swap/swap.
• Scenarii multi-leasing: izolare intre clienti/proiecte/medii.

Ceea ce nu acoperim pe deplin: furtul sesiunilor în memorie, atacurile asupra unui proces live, vulnerabilitățile aplicației, compromiterea acreditărilor. Acest lucru necesită criptare în timpul zborului, autentificare/autorizare puternică, minimizarea drepturilor și monitorizare (vezi articolele conexe: „Autentificare și autorizare”, „Semnarea și verificarea cererilor”).

2) Modelul amenințării și obiectivele de control

• Pierderea/furtul de medii (disc, bandă, USB, dispozitiv dezvoltator).
• Acces neautorizat la copii de rezervă/instantanee/jurnale.
• Abuz de privilegii la nivelul platformei/hipervizorului/nodului de stocare.
• Încrucișarea chiriașilor pentru erori de configurare.
• Fișiere temporare și gropi care se încadrează în artefacte și imagini.

1. Confidențialitatea datelor pe suport.

2. Izolarea criptografică a chiriașilor/mediilor.

3. Capacitatea de administrare a cheilor (creare, stocare, rotație, revocare).

4. Auditabilitatea (cine a folosit cheia și când).

5. Minimizarea riscurilor operaționale în caz de incidente.

3) Fundamentele arhitecturii

Criptăm totul în mod implicit. Renunțarea nu este permisă fără excepții la nivelul riscului.
Ierarhia cheie (criptarea plicului). Root/KEK → DEK (chei de criptare a datelor) → obiecte/fișiere/pagini de baze de date.
KMS/HSM ca sursă de încredere. Generarea și stocarea KEK în KMS/HSM, operațiunile de ambalare/implementare a cheilor sunt efectuate acolo.
Chei per chiriaș/per set de date. Granularitate pentru cerințele de izolare și rotație.
Separarea sarcinilor. Platforma comenzi ≠ proprietarii cheie chiriaș; privilegii minime (PoLP).
Cripto-agilitate. Abilitatea de a migra în siguranță algoritmi/lungimi cheie.
Rotaţia ca proces, nu ca eveniment. Cheile și datele trebuie să accepte înlocuirea „rulare”.

4) Algoritmi și moduri de criptare

Pentru obiecte/fișiere/înregistrări: AES-256-GCM sau AES-256-SIV (AEAD cu autentificare).
Pentru dispozitive/volume de bloc: AES-XTS-256/512 (protecție împotriva permutărilor de bloc; nu AEAD - utilizați peste formate de fișiere cu MAC în cazul în care integritatea este importantă).

• TDE (Transparent Data Encryption) движка: Oracle TDE, SQL Server TDE, MySQL/InnoDB TDE и пр.
• Criptografie câmp/linie (FPE/criptare deterministă) - pentru capacități de căutare/joynes pe câmpuri criptate; se aplică prudent.
• Generare și stocare cheie: KEK - în KMS/HSM; DEK - în memoria aplicațiilor de scurtă durată, în timpul stocării - numai înfășurat.

5) Ierarhia cheie și KMS/HSM

1. Root key (statutar, în HSM/KMS). Nu părăsește perimetrul HSM/KMS.

2. KEK (Cheie de criptare a cheii). Pentru proiect/mediu/chiriaș. Gestionează ciclul de viață DEK.

3. DEK (Cheia de criptare a datelor). Per obiect/fișier/tabel/segment. De scurtă durată, rotativ non-stop.

• Toate operațiunile de împachetare/implementare sunt prin KMS API cu audit.
• Politicienii: care pot „folosi” cheia ≠ care pot „controla” cheia.
• Key geo-distribution: pin-to-region + dual-control pentru inter-regiune.
• Un model „cu două verificări” (doi operatori) este posibil pentru operațiuni cu risc ridicat.
• Pentru a izola un nivel puternic - separate chei-inele pe chiriaș.

6) Rotație, rechemare și conformitate

Rotație DEK: transparentă și constantă (re-criptare de rulare la nivelul obiectului/paginii).
Rotația KEK: periodic (de exemplu, la fiecare 6-12 luni) + rechemare imediată dacă se suspectează că a fost compromisă.
Revocarea accesului: prin politici KMS; blocarea operațiunilor de despachetare = „cripto-distrugere” instantanee a datelor.
Jurnalele de audit: cine, când, cu ce drepturi a folosit cheile; stoca separat și, de asemenea, cripta.
Reglementări și standarde: ne concentrăm pe cerințele industriei (de exemplu, permisele GDPR/PCI/autoritățile locale de reglementare), folosim module criptografice certificate (de exemplu, conformitatea cu nivelurile de certificare).

7) Modele după tipul de stocare

7. 1 Volume bloc/fișier și VM/containere

Criptarea completă a discului (XTS) + gestionarea cheilor prin KMS (inițializarea volumului în timpul montării).
Protejați schimburile, gropile de avarie, directoarele tmp, straturile de suprapunere a containerelor/imaginile AMI.
Instantanee/instantanee - întotdeauna criptate cu DEK-uri separate.

7. 2 Stocarea obiectelor

Criptare plic: unic DEK pe obiect; anteturi/metadate - fără scurgeri PII.
Controlul accesului la cheia KMS de către chiriași și medii.
Criptare server-side (SSE cu propriul KMS) sau client-side (CSE) - alege în funcție de modelul de încredere.

7. 3 Baze de date

Activați TDE acolo unde este disponibil; legați cheile bazei de date la KMS prin plugin/extensie.
Pentru domenii deosebit de sensibile - criptarea aplicațiilor (AEAD) înainte de a intra în baza de date.
Redo jurnalele/jurnalele de tranzacții, jurnalele de arhivă, haldele - criptați separat, cheile - separate.

7. 4 Busteni/Trasee/Metrica

Format jurnal - fără date sensibile în mod implicit (salubritate).
Arhive jurnal - chei separate și de stocare TTL scurt.
Acces la jurnalele de lectură - printr-un serviciu proxy cu A&A și audit.

7. 5 Backup-uri şi suporturi offline

Criptați întotdeauna la client înainte de a scrie în bandă/nor.
Stocați cheile separat (out-of-band), escrow cu control separat.
Pentru cazurile de urgență, împărțirea secretului (de exemplu, m-of-n) pentru a restabili accesul maestru.

8) Multi-chiriaș

Cheie pentru chiriaș: KEK-per-chiriaș + DEK-per-set de date.
Izolarea politicilor: spații de nume KMS, limite IAM, roluri individuale IDP.
Eliminarea la cererea clientului: „cripto-șterge” - retrageți KEK chiriașului și distrugeți DEK.
Raportarea clienților: artefacte de conformitate, jurnale de acces cheie, confirmare de rotație.

9) Performanță și funcționare

Accelerări hardware (AES-NI/x86, ARMv8 extensii cripto).
Profilarea căilor fierbinți: criptați la limitele I/O, evitați inutil criptarea dublă.
KMS piscine sesiune, cache înfășurat DEKs în memorie (cu TTL și protecție dump).
SLO/metrics: despachetați latența, proporția obiectelor „re-criptate”, erorile KMS, viteza de criptare de rezervă.

10) Runbook de referință

Pasul 0 - Inventarul datelor. Catalog toate depozitele și căile de scurgere (tmp, halde, export, găleți de analiză).
Etapa 1 - proiectarea ierarhiei cheie. Determinăm nivelurile KEK/DEK, granularitatea, regiunile, rolurile.
Etapa 2 - selectați moduri/biblioteci. Algoritmi aprobați, biblioteci cripto, politici de versiune.
Pasul 3 - integrarea cu KMS/HSM. Generare/împachetare/audit, politici IAM, geo-pinning.
Pasul 4 - criptare per scriere. Activați în mod implicit, migrarea datelor existente prin recriptarea de fundal.
Pasul 5 - scenarii de rotație și de urgență. Reglementări, teste „compromis cheie”, „KMS nu este disponibil”.
Pasul 6 - monitorizare și audit. Tablouri de bord, alerte, rapoarte regulate de conformitate.
Pasul 7 - antrenament și "codificare sigură. "Ghiduri pentru ingineri, interzicerea afișării secretelor în bușteni/halde.

11) Testarea și verificarea

Teste de unitate cripto: corectitudinea AEAD (verificarea etichetelor), validarea eșecului atunci când un octet este schimbat.
Teste de eșec: dezactivarea KMS, versiuni cheie învechite, revocarea forțată a KEK.
Teste roșu/albastru: încearcă să citească discul „brut ”/instantaneu/backup.
Verificarea compatibilității: migrarea algoritmilor/lungimilor cheii (cripto-agilitate).
Atestarea bibliotecii: utilizați numai module cripto verificate; comite versiuni.

12) Greșeli frecvente și cum să le evitați

Criptare dublă fără sens. Latență și complexitate suplimentare. Țineți un strat care oferă granularitatea și izolarea dorită.
Stocați cheile lângă date. Cheile sunt întotdeauna separate, sub un model de acces diferit.
Artefacte uitate. Fișiere temporare necriptate, export CSV, dumps de sprijin. Activați monitorizarea în CI/CD și prevenirea pierderilor de date.
Lipsa de rotaţie. Faceți partea de rotație a conductei/cron, nu o procedură manuală.
Jurnale cu date sensibile. Introduceți un contract pentru formatul jurnalului și dezinfectanții automați.

13) Mini rețete (pseudocod)

1) Request unwrap DEK from KMS by tenant KEK id dek = kms. unwrap(kek_id, wrapped_dek)

2) Generate fresh nonce/iv, encrypt payload (AEAD)
ciphertext, tag = aead_encrypt(dek, iv=random(), aad=metadata, plaintext=data)

3) Delete DEK from memory (zeroize), save {ciphertext, iv, tag, wrapped_dek}

For each object:
new_wrapped_dek = kms. rewrap(old_wrapped_dek, old_kek_id -> new_kek_id)
store(new_wrapped_dek)
We do not touch the data: we turn over only DEK

kms. disable_key (tenant_kek_id) # Deny unwrap kms. schedule_destroy (tenant_kek_id, hold_period_days=7) # Optional hold

14) Liste de verificare

• Criptarea implicită este activată pe toate tipurile de stocare.
• Ierarhia cheie este descrisă și implementată; rolurile și politicile IAM sunt configurate.
• KMS/HSM integrat, operațiuni cheie de audit activat.
• Rotația DEK/KEK este automatizată; scenarii de compromis elaborate.
• Backup-uri, instantanee, busteni si halde - criptate; cheile sunt stocate separat.
• Alerte configurate pentru erori KMS, abateri ale etichetelor AEAD, proporția de artefacte necriptate.
• KMS indisponibilitatea și testele cheie de revocare a trecut.

• Raport lunar privind utilizarea cheilor și încercările de acces.
• Planul de cripto-agilitate și fereastra pentru migrarea algoritmilor nedureroși.
• Echipa roșie periodică pentru a extrage date din mediile brute.

15) ÎNTREBĂRI ȘI RĂSPUNSURI (FAQ)

Î: Este suficientă criptarea completă a discului?
R: Pentru riscuri fizice - da, dar pentru izolarea chiriașilor și rotație flexibilă mai bine plic cu DEK-pe-obiect/set.

Î: Ce trebuie să faceți atunci când KEK este compromis?
R: Rechemați imediat KEK la KMS, relansați nou, reprelucrați toate DEK-urile, verificați jurnalele și rulați RCA.

Î: Cum criptăm câmpurile pe care le căutăm?
R: Utilizați scheme deterministe sau EIP numai în evaluarea riguroasă a riscurilor (model leks). Este mai bine să proiectați interogări, astfel încât câmpurile sensibile să nu necesite o vizualizare deschisă indexată.

Î: Am nevoie de o comandă separată pentru chei?
R: Operatorul Crypto/KMS este recomandat ca rol cu drepturi și proceduri separate.

• „Managementul și rotația cheilor”
• „Autentificare S2S”
• „Semnează și verifică cererile”
• „Conectați OAuth2/OpenID în Kernel”
• „Garanții de livrare prin broșură web”