Crittografia At Rest

Crittografia At Rest

1) Perché è necessario e cosa stiamo proteggendo esattamente

Definizione. La crittografia at rested è la protezione dei dati scritti sul supporto (dischi, snap, bacap, oggetti, logi, dampi di memoria) in modo che l'accesso non autorizzato al supporto fisico o allo storage grezzo non riveli i contenuti.

• Block/file volumi, archivi di oggetti, database, code/keyville, cache-dump, logi/trailer, backup, esportazione/importazione, istantanee VM/contenitori, dump-core/processi, paging/swap.
• Script multiarending: isolamento tra client/progetti/ambienti.

Ciò che non copriamo completamente è il furto di sessioni in memoria, attacchi a un processo vivo, vulnerabilità dell'applicazione, compromissione delle credenziali. Ciò richiede la crittografia in volo, l'autenticazione/autorizzazione rigorosa, la riduzione dei diritti e il monitoraggio (vedere gli articoli correlati: Autenticazione e autorizzazione, Firma e convalida query).

2) Modello di minacce e obiettivi di controllo

• Perdita/furto del supporto (disco, nastro, USB, dispositivo di sviluppo).
• Accesso non autorizzato a backap/slot/logi.
• Abuso di privilegi a livello di piattaforma/ipervisore/storage nod.
• Intersezione degli affittuari in caso di errore di configurazione.
• File temporanei e dampi che finiscono nei manufatti e nelle immagini.

1. Riservatezza dei dati sul supporto.

2. Isolamento crittografico degli affittuari/ambienti.

3. Gestione delle chiavi (creazione, archiviazione, rotazione, revoca).

4. Verificabile (chi e quando ha usato la chiave).

5. Riduzione dei rischi operativi in caso di incidenti.

3) Principi di base dell'architettura

Crittografiamo tutto per impostazione predefinita. Opt-out è vietato senza esclusioni a livello di rischio.
Gerarchia chiavi (encryption). Root/KEK → DEK (data encryption keys) → gli oggetti/i file/le pagine del database.
KMS/HSM come fonte di fiducia. La generazione e l'archiviazione di KEK in KMS/HSM, le operazioni di avvolgimento/distribuzione delle chiavi, vengono eseguite anche lì.
Chiavi per-tenant/per-dataset. Granularità per i requisiti di isolamento e rotazione.
Separazione dei compiti. I comandi della piattaforma ≠ i proprietari delle chiavi dell'inquilino; Minimo privilegi (PoLP).
Crypto-agility. Possibilità di migrare in modo sicuro algoritmi/lunghezze delle chiavi.
Rotazione come processo, non come evento. Le chiavi e i dati devono supportare la sostituzione «scorrevole».

4) Algoritmi e modalità di crittografia

Per gli oggetti/file/record: AES-256-GCM o AES-256-SIV (AEAD con autenticazione).
Per dispositivi/volumi a blocchi: AES-XTS-256/512 (protezione contro i cambi di blocco; non AEAD - Utilizzare sopra i formati di file con MAC dove l'integrità è importante).

• TDE (Transparent Data Encryption) движка: Oracle TDE, SQL Server TDE, MySQL/InnoDB TDE и пр.
• Crittografia in campo/minuscolo (FPE/Determined Crittografia) - per la ricerca/ricarica nei campi crittografati Usare con cautela.
• Generazione e conservazione delle chiavi: KEK in KMS/HSM; DEK - la memoria delle applicazioni è a breve vita, la memorizzazione è solo avvolta.

5) Gerarchia delle chiavi e KMS/HSM

1. Root key (statutario, HSM/KMS). Non esce dal perimetro HSM/KMS.

2. KEK (Key Encryption Key). Al progetto/ambiente/affittuario. Controlla il ciclo di vita DEK.

3. DEK (Data Encryption Key). Per l'oggetto/file/tabella/segmento. Breve, rotazione senza sosta.

• Tutte le operazioni di avvolgimento/distribuzione sono tramite l'API KMS con l'udienza.
• Policy: chi può «usare» la chiave di chi può «controllare» la chiave.
• La distribuzione geografica delle chiavi è pin-to-region + dual-control per l'interregionale.
• È possibile utilizzare un modello dual-core (due operatori) per operazioni ad alto rischio.
• Per l'isolamento di livello forte, i singoli key-rings sull'inquilino.

6) Rotazione, recensione e compilazione

Rotazione DEK: trasparente e costante (rolling re-encryption a livello di oggetti/pagine).
Rotazione KEK: periodica (ad esempio, ogni 6-12 mesi) + immediata recensione in caso di sospetto compromissione.
Revoca accesso tramite criteri KMS; blocco delle operazioni unwrap = «crittografia-distruzione» immediata dei dati.
Registri di verifica: chi, quando, con quali diritti ha usato le chiavi; Conservare separatamente e cifrarlo.
Normative e standard: focalizziamo i requisiti del settore (ad esempio, tolleranze GDPR/PCI/regolatori locali) e utilizziamo crittomoduli certificati (ad esempio, conformità ai livelli di certificazione).

7) Pattern per tipo di storage

7. 1 Blocchi/file volumi e VM/contenitori

Crittografia a tutto campo (XTS) + gestione delle chiavi tramite KMS (inizializzazione del volume durante il montaggio).
Proteggi swap, crash-damp, directory tmp, livelli overlay contenitori, immagini/AMI.
Le snapshot/snashot sono sempre in forma criptata con i singoli DEK.

7. 2 Archivio oggetti

Envelope encryption: un DEK univoco per oggetto; intestazioni/metadati - Nessuna fuoriuscita PII.
Controlla l'accesso alla chiave KMS per gli affittuari e gli ambienti.
Server-side crittografia (SSE con KMS personalizzato) o client-side (CSE) - Seleziona in base al modello di affidamento.

7. 3 Database

Abilita TDE dove disponibile; chiavi di database da associare a KMS tramite plugin/estensioni.
Per i campi particolarmente sensibili, crittografia applicativa (AEAD) prima di entrare nel database.
Registri di login rado/transazioni, archivi, dump, crittografare separatamente, chiavi separate.

7. 4 Loghi/trailer/metriche

Formato dei fogli - Nessun dato sensibile predefinito (igiene).
Gli archivi dei logi sono chiavi separate e TTL brevi.
Accesso alla lettura dei fogli tramite proxy con A&A e audio.

7. 5 Backup e supporti offline

Crittografa sempre sul lato client prima di scrivere sul nastro/cloud.
Memorizza le chiavi separatamente (out-of-band), escrow con controllo separato.
Per i casi di emergenza, separare il segreto (ad esempio, m-of-n) per ripristinare l'accesso master.

8) Multi-tenant

La chiave per l'inquilino è KEK-per-tenant + DEK-per-dataset.
Isolamento delle regole: spazio dei nomi KMS, limiti IAM, singoli ruoli IDP.
Cancellazione su richiesta del cliente: «crypto-cancellare» - ritirare KEK dell'inquilino e distruggere DEK.
Report client: artefatti di corrispondenza, login di accesso alle chiavi, conferma di rotazione.

9) Prestazioni e utilizzo

Accelerazioni hardware (AES-NI/x86, ARMv8 Crypto Extensions).
Profilazione dei percorsi hot: crittografia ai confini I/O, evitare la doppia crittografia senza necessità.
Pool di sessione KMS, cache dei DEK avvolti nella memoria (con TTL e protezione dai dump).
SLO/metriche - Latitudine unwrap, percentuale di oggetti crittografati, errori di KMS, velocità di crittografia becap.

10) Processo di implementazione (reference runbook)

Passo 0 - Inventario dei dati. Cataloga tutti gli archivi e i percorsi di fuga (tmp, damp, export, analytics-baquet).
Passo 1 - Progettazione gerarchia chiave. Definiamo i livelli KEK/DEK, granularità, regioni, ruoli.
Passo 2 - Seleziona le modalità/librerie. Algoritmi approvati, cryptobiblioteche, criteri di versione.
Fase 3 - Integrazione con KMS/HSM. Generazione/avvolgimento/controllo, criteri IAM, geo-pinning.
Passo 4 - crittografia per scrittura. Attiva per impostazione predefinita la migrazione dei dati esistenti tramite background reencript.
Passo 5 - rotazione e script di emergenza. Regolamento, test key compromise, KMS non disponibile.
Fase 6 - Monitoraggio e verifica. Dashboard, alert, rapporti regolari di conformità.
Fase 7 - Formazione e secure coding. Guidi per gli ingegneri, divieto di portare segreti nei loghi/dampi.

11) Test e verifica

Crypto-unit test: correttezza AEAD (convalida dei tag), convalida del guasto durante la modifica del byte.
Failure-test: disattivazione di KMS, versioni delle chiavi obsolete, revoca KEK forzata.
Test Red/Blue - Tentativi di leggere disco crude/snapshot/backap.
Verifica compatibilità: migrazione algoritmi/lunghezze delle chiavi (crypto-agility).
Certificazione libreria: utilizzare solo crittomoduli convalidati Fissa le versioni.

12) Errori frequenti e come evitarli

Doppia crittografia senza senso. La latitanza e la complessità in eccesso. Mantenere lo strato che dà la granolarità e l'isolamento desiderati.
Memorizzare le chiavi accanto ai dati. Le chiavi sono sempre separate, sotto un altro modello di accesso.
Manufatti dimenticati. File temporanei non cifrati, esportazione CSV, dump di supporto. Attivare il controllo in CI/CD e Data Loss Prevention.
Nessuna rotazione. Fare rotazione con pipeline/cron, anziché con una procedura manuale.
Loghi con dati sensibili. Immettere il contratto per il formato dei fogli e per l'assistenza sanitaria automatica.

13) Mini-ricette (pseudocode)

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) Assegno fogli

• Crittografia predefinita attivata su tutti i tipi di storage.
• La gerarchia delle chiavi è descritta e implementata; ruoli e criteri IAM configurati.
• KMS/HSM è integrato e il controllo delle operazioni chiave è abilitato.
• La rotazione DEK/KEK è automatizzata; gli script di compromissione sono stati usati.
• Bacapi, snapshot, loghi e dampi sono criptati; le chiavi sono conservate separatamente.
• Gli alert sono configurati per gli errori di KMS, le deviazioni di tag AEAD, la percentuale di artefatti non cifrati.
• Test di non disponibilità di KMS e revoca delle chiavi completati.

• Report mensile sull'utilizzo delle chiavi e sui tentativi di accesso.
• Piano di crypto-agility e finestra per la migrazione indolore degli algoritmi.
• Red team periodico per il recupero dei dati dai supporti crudi.

15) Domande e risposte (FAQ)

C'è abbastanza crittografia a tutto campo?
O: Per i rischi fisici sì, ma per l'isolamento degli affittuari e la rotazione flessibile è meglio un invelope con DEK-a-oggetto/set.

C: Cosa fare quando KEK viene compromesso?
O: Richiamare immediatamente KEK in KMS, reindirizzarne uno nuovo, rewrap tutti i DEK, controllare i registri e eseguire RCA.

B: Come cifrare i campi che cerchiamo?
O: Utilizzare diagrammi determinati o FPE solo per una valutazione rigorosa dei rischi (pattern). È meglio progettare le query in modo che i campi sensibili non richiedano una vista aperta indicizzata.

C'è bisogno di una squadra separata per le chiavi?
L'operatore Crypto/KMS è consigliato come ruolo con diritti e procedure separati.

• Gestione e rotazione delle chiavi
• Autenticazione S2S
• Firma e verifica query
• OAuth2/OpenID Connect nel kernel
• Garanzia di spedizione Web Hook