Protezione dei dati

La protezione dei dati protegge le informazioni riservate da accessi non autorizzati, esfiltrazione e uso improprio nel ciclo di vita completo dei dati. Implementare l'individuazione e la classificazione per stabilire l'inventario dei dati, la crittografia per proteggere i dati in transito e inattivi e la gestione disciplinata delle chiavi e dei certificati per mantenere l'integrità crittografica. Questo approccio a più livelli è allineato ai principi Zero Trust e alle strategie di difesa avanzata.

Senza una protezione completa dei dati, le organizzazioni devono affrontare violazioni dei dati, sanzioni normative e danni alla reputazione derivanti dall'esfiltrazione di informazioni riservate.

Ecco i tre pilastri fondamentali del dominio di sicurezza della protezione dei dati.

Conoscere e classificare i dati: Individuare le informazioni riservate e applicare etichette coerenti per abilitare i controlli basati sui rischi.

Controlli correlati:

• DP-1: individuare, classificare ed etichettare i dati sensibili
• DP-2: Monitorare le anomalie e le minacce destinate ai dati sensibili

Proteggere i dati con la crittografia: Implementare la crittografia completa per i dati in transito e inattivi usando standard crittografici moderni.

Controlli correlati:

• DP-3: Crittografare i dati sensibili in transito
• DP-4: Abilitare la crittografia dei dati inattivi per impostazione predefinita
• DP-5: usare l'opzione chiave gestita dal cliente nella crittografia dei dati inattivi quando necessario

Gestire l'infrastruttura crittografica: Stabilire una gestione disciplinata del ciclo di vita per chiavi crittografiche e certificati con rotazione automatica e registrazione di controllo completa.

Controlli correlati:

• DP-6: Usare un processo di gestione delle chiavi sicuro
• DP-7: Usare un processo di gestione dei certificati sicuro
• DP-8: Garantire la sicurezza della chiave e del repository di certificati

DP-1: individuare, classificare ed etichettare i dati sensibili

Criteri di Azure: Vedere Azure definizioni di criteri predefinite: DP-1.

Principio di sicurezza

Stabilire e gestire un inventario completo dei dati sensibili individuando, classificando ed etichettando i dati in tutti i repository. In questo modo, i controlli degli accessi in base al rischio, i criteri di crittografia e il monitoraggio consentono di proteggersi da accessi non autorizzati ed esfiltrazioni.

Rischio da mitigare

Gli attori delle minacce sfruttano la mancanza di visibilità e la gestione incoerente dei dati sensibili per esfiltrare o abusare di informazioni di alto valore. Quando i dati sensibili non vengono individuati, classificati o etichettati:

• Dati regolamentati non registrati: (PCI, PHI, PII) archiviati in posizioni non gestite (shadow IT) ignora i controlli di crittografia, conservazione o monitoraggio necessari.
• Accesso privilegiato in eccesso: L'accesso utente/servizio generale persiste perché la sensibilità e l'impatto aziendale non vengono riconosciuti.
• Proliferazione delle repliche: La replica dei dati in pipeline di analisi, test o esportazione distribuisce contenuto sensibile in ambienti con attendibilità inferiore.
• Punti ciechi forensi: I risponditori agli incidenti non possono definire rapidamente l'estensione del raggio d'azione a causa di metadati di sensibilità assenti o non corretti.
• Errore di automazione: La governance (DLP, accesso condizionale, flussi di lavoro di crittografia) non riesce a essere attivata senza etichettatura coerente.

La mancanza di classificazione di base aumenta il tempo di attesa, amplia le opportunità di spostamento laterale e eleva l'esposizione normativa e reputazione.

MITRE ATT&CK

• Ricognizione (TA0043): raccolta delle identità delle vittime e dei dati (T1596) enumerando account di archiviazione, cataloghi dello schema e metadati di classificazione per identificare repository di alto valore.
• Individuazione (TA0007): enumerazione di account e permessi (T1087, T1069) per rivelare binding di ruoli eccessivi che consentono un'escalation orizzontale o verticale dell'accesso ai dati.
• Raccolta (TA0009): dati dall'archiviazione cloud (T1530) estraendo contenitori BLOB non etichettati o esportazioni non gestite senza tag di rilevamento.
• Esfiltrazione (TA0010): esfiltrazione su servizi Web (T1567) tramite endpoint di esportazione ad hoc in cui i controlli di etichettatura/criteri sono assenti.
• Esfiltrazione (TA0010): esfiltrazione automatizzata (T1020) utilizzando scripting per la paginazione e l'iterazione silenziosa di set di dati classificati erroneamente.

DP-1.1: individuare, classificare ed etichettare i dati sensibili

Usare Microsoft Purview per creare una mappa dei dati completa che individua, classifica e etichetta automaticamente le informazioni riservate nell'intero patrimonio di dati. Estendere la protezione oltre la crittografia a livello di infrastruttura implementando Microsoft Purview Information Protection per applicare i diritti di utilizzo e crittografia persistenti a livello di documento che seguono i dati ovunque si trovino. Questa funzionalità fondamentale consente ai controlli di sicurezza downstream, ad esempio la prevenzione della perdita dei dati, l'accesso condizionale e i criteri di crittografia, in base alla riservatezza dei dati anziché alla sola posizione.

Individuazione e classificazione dei dati:

• Distribuire Microsoft Purview per individuare, classificare ed etichettare i dati sensibili in ambienti Azure, locali, Microsoft 365 e multi-cloud.
• Usare Microsoft Purview Mappa dati per analizzare e catalogare automaticamente le origini dati, tra cui Archiviazione di Azure, database SQL di Azure, Azure Synapse Analytics e altri servizi supportati.
• Abilitare le etichette di riservatezza in Purview Data Map per applicare automaticamente etichette di classificazione (ad esempio, Riservato, Estremamente riservato, PII, PHI) in base ai modelli di contenuto dei dati e ai criteri dell'organizzazione.

Crittografia e protezione a livello di documento:

• Distribuire Microsoft Purview Information Protection per applicare i diritti di utilizzo e crittografia persistenti ai documenti e ai messaggi di posta elettronica in base alle etichette di riservatezza. Configurare le etichette per crittografare automaticamente i file, applicare filigrane, limitare l'inoltro, impostare le date di scadenza e revocare l'accesso anche dopo che i dati lasciano l'organizzazione.
• Abilitare Azure Rights Management Service (Azure RMS) come tecnologia di protezione sottostante che crittografa documenti e messaggi di posta elettronica con criteri di utilizzo (solo visualizzazione, nessuna copia, nessuna stampa) che vengono mantenuti indipendentemente dalla posizione in cui vengono archiviati o condivisi i dati.

Classificazione e integrazione del database:

• Per i database Azure SQL, abilitare SQL Data Discovery & Classificazione per identificare, classificare ed etichettare colonne contenenti dati sensibili, ad esempio numeri di carta di credito, numeri di previdenza sociale o record sanitari.
• Integrare i metadati di classificazione con i controlli downstream: configurare i criteri di prevenzione della perdita dei dati (DLP) in Microsoft Purview, applicare regole di accesso condizionale in Entra ID e applicare i criteri di crittografia in base alle etichette di riservatezza.
• Stabilire una pianificazione di analisi regolare per individuare continuamente gli asset di dati sensibili appena creati o modificati man mano che si evolve il patrimonio di dati.

Esempio di implementazione

Un'organizzazione globale di servizi finanziari ha distribuito Microsoft Purview Mappa dati per individuare e classificare automaticamente i dati sensibili in più di 200 account Archiviazione di Azure, 50 database SQL e aree di lavoro di Synapse Analytics.

Challenge: L'organizzazione non ha visibilità sulla posizione in cui risiedono i dati sensibili nel proprio patrimonio di dati in rapida crescita Azure. La classificazione manuale dei dati è incoerente, ritardata nell'applicazione della governance e ha creato lacune nella conformità. Senza l'individuazione automatizzata, i dati regolamentati (PHI, PII, PCI) sono rimasti non protetti in posizioni non gestite e i criteri di prevenzione della perdita dei dati non potevano essere attivati in modo appropriato.

Approccio alla soluzione:

• Distribuire Microsoft Purview Mappa dati per l'individuazione dei dati: Creare un account Purview e registrare origini dati (account Archiviazione di Azure, database SQL, aree di lavoro Microsoft Synapse Analytics), configurare Mappa dati per analizzare le origini usando l'autenticazione dell'identità gestita, concedere autorizzazioni di lettura delle identità (ruolo db_datareader) agli schemi e individuare colonne sensibili.
• Configurare la classificazione e il rilevamento della riservatezza: Configurare le regole di analisi per rilevare modelli sensibili (SSN, numeri di carta di credito, numeri di record medici, codici SWIFT), definire regole di classificazione personalizzate allineate ai criteri di classificazione dei dati ("Riservato - Interno" per i dati sensibili alle aziende, "Altamente riservati - Regolamentati" per i dati PHI/PCI/PII), configurare soglie di etichettatura automatica (applicare "Estremamente riservato" quando ≥3 modelli piI rilevati in un singolo asset), stabilire pianificazioni di analisi in base alla criticità dei dati (settimanale per la produzione, mensile per gli archivi), configurare gli avvisi per notificare ai team di sicurezza quando vengono individuati nuovi dati ad alta sensibilità.
• Deploy Microsoft Purview Information Protection per la crittografia a livello di documento: Creare etichette di riservatezza nel portale di conformità di Purview con le impostazioni di protezione (pubblico: nessuna crittografia, contrassegni visivi solo; Interno: filigrana, nessuna restrizione di inoltro; Riservato: crittografare con Azure RMS, consentire la visualizzazione/modifica solo per i dipendenti, bloccare l'inoltro/stampa; Estremamente riservato - Regolamentato: crittografare con Azure RMS, accesso in sola visualizzazione, nessuna copia/stampa/inoltro, scadenza di 90 giorni, accesso revocabile, pubblicare etichette di riservatezza agli utenti tramite criteri di etichetta (ambito: Finanza, Legale, Reparti esecutivi), configurare criteri di etichettatura automatica per applicare automaticamente etichette (≥10 SSN → "Riservatezza elevata - Regolamentata", ≥5 numeri di carta di credito → "Altamente riservato - Regolamentato"), abilitare Azure Protezione RMS per i documenti etichettati archiviati in account SharePoint, OneDrive e Archiviazione di Azure, configurare l'etichettatura lato client per le applicazioni di Office per richiedere agli utenti di classificare i documenti prima di salvare o inviare.

Risultato: L'analisi automatica della mappa dei dati di Purview ha identificato oltre 15.000 asset di dati contenenti dati regolamentati entro la prima settimana, riducendo il tempo di individuazione da mesi a giorni. Protezione delle informazioni tramite etichettatura automatica ha applicato la crittografia a 8.500 documenti entro 72 ore. Le etichette di riservatezza hanno abilitato la visibilità continua del patrimonio di dati e la protezione permanente anche quando i dati vengono spostati in dispositivi non gestiti.

Livello di criticità

Indispensabile.

Mappatura dei controlli

• Controlli CIS v8.1: 3.2, 3.7, 3.13
• NIST SP 800-53 Rev.5: RA-2, SC-28
• PCI-DSS v4: 3.2.1, 12.3.1
• NIST CSF v2.0: PR.DS-1, PR.DS-5
• ISO 27001:2022: A.8.11
• SOC 2: CC6.1

DP-2: Monitorare le anomalie e le minacce destinate ai dati sensibili

Criteri di Azure: Vedere definizioni di criteri predefiniti di Azure: DP-2.

Principio di sicurezza

Monitorare l'accesso ai dati sensibili e le attività di trasferimento per rilevare anomalie che indicano l'esfiltrazione non autorizzata, le minacce interne o gli account compromessi. Usare le baseline comportamentali e il contesto di riservatezza dei dati per rilevare modelli insoliti, ad esempio trasferimenti di grandi dimensioni, tempi di accesso anomali o spostamento imprevisto dei dati.

Rischio da mitigare

Gli antagonisti e gli utenti malintenzionati tentano di esfiltrare, preparare o analizzare i dati sensibili usando comportamenti furtivi o a basso segnale. Senza monitoraggio continuo delle anomalie sensibile al contesto legato alla sensibilità dei dati:

• Esfiltrazione silenziosa: Le esportazioni massive, i set di risultati di grandi dimensioni o il sifonamento incrementale procedono senza essere rilevati a causa della mancanza di parametri di base.
• Uso improprio da parte di insider: Le credenziali legittime eseguono sequenze insolite (ora del giorno, volume, località) che ignorano il monitoraggio superficiale.
• Preparazione ed enumerazione: Gli attaccanti eseguono la mappatura di schemi/etichette per dare la priorità agli obiettivi di alto valore prima dell'estrazione di massa.
• Query living-off-the-land: Gli strumenti di amministrazione standard mascherano la ricognizione nel normale rumore operativo.
• Evasione tra negozi: L'accesso distribuito tra più servizi evita soglie e correlazioni a archivio singolo.

Il rilevamento delle anomalie inadeguato erode l'efficacia della risposta agli incidenti e consente l'escalation dalla ricognizione all'esfiltrazione su larga scala con attrito minimo.

MITRE ATT&CK

• Raccolta (TA0009): dati dall'archiviazione cloud (T1530) tramite letture di massa anomale o ampi fan-out tra contenitori sensibili.
• Accesso alle credenziali (TA0006): account validi (T1078) che abusano di credenziali compromesse o interne per fondersi con baseline di traffico legittime.
• Esfiltrazione (TA0010): esfiltrazione automatizzata (T1020) utilizzando query scriptate e regimentate progettate per evitare le soglie di allerta.
• Esfiltrazione (TA0010): esfiltrazione nell'archiviazione cloud (T1567.002) di dati preparati in regioni o account controllati dagli attaccanti per un recupero successivo.
• Command & Control / Esfiltrazione (TA0011/TA0010): protocollo a livello di applicazione (T1071) per il tunneling di righe sensibili attraverso normali chiamate DB/API.
• Individuazione (TA0007): rilevamento di sistema/servizio (T1082, T1046) che enumera gli endpoint per tracciare percorsi di movimento laterale verso archivi di valore superiore.

DP-2.1: Abilitare il rilevamento delle minacce per i servizi dati

Distribuire i servizi di Microsoft Defender per fornire il rilevamento delle minacce in tempo reale e il monitoraggio delle anomalie sulle piattaforme di archiviazione e sui database dei dati. Questi servizi usano l'analisi comportamentale e l'intelligence sulle minacce per identificare attività sospette, ad esempio tentativi di inserimento SQL, modelli di query anomale, volumi di accesso ai dati insoliti e potenziali indicatori di esfiltrazione che i controlli di accesso tradizionali non possono rilevare.

Abilitare il rilevamento delle minacce per i servizi dati:

• Abilitare Microsoft Defender per Archiviazione con l'analisi malware e il rilevamento delle minacce ai dati sensibili per monitorare modelli di accesso anomali, volumi di caricamento/download insoliti e potenziali tentativi di esfiltrazione dei dati tra account Archiviazione di Azure.
• Abilitare Microsoft Defender per SQL per rilevare attività sospette del database, tra cui tentativi di inserimento SQL, modelli di query anomale, operazioni insolite di esportazione dei dati e accesso da posizioni non note.
• Abilitare Microsoft Defender per Azure Cosmos DB per rilevare modelli di accesso anomali al database, potenziali esfiltrazioni di dati e attività operative sospette.
• Per i database open source (PostgreSQL, MySQL), abilitare Microsoft Defender per i database relazionali open source per rilevare attacchi di forza bruta, modelli di accesso sospetti e operazioni amministrative anomale.

DP-2.2: Monitorare e impedire l'esfiltrazione dei dati

Implementare controlli proattivi per la prevenzione della perdita dei dati e il monitoraggio comportamentale per rilevare e bloccare i trasferimenti di dati non autorizzati prima che abbiano esito positivo. Combinare la prevenzione della perdita dei dati basata su criteri con la gestione dei rischi interni, la correlazione SIEM e la risposta automatizzata per creare un approccio di difesa in profondità che contrasta i tentativi di esfiltrazione su più canali, fornendo al tempo stesso prove forensi per l'indagine sugli incidenti.

Distribuire controlli per la prevenzione della perdita dei dati e dei rischi interni:

• Usare i criteri Prevenzione della perdita dei dati Microsoft Purview (DLP) per impedire l'esfiltrazione di dati sensibili monitorando e bloccando trasferimenti non autorizzati di dati classificati tra servizi Azure, Microsoft 365 ed endpoint.
• Distribuire Gestione dei rischi Insider Microsoft Purview per rilevare i comportamenti degli utenti rischiosi usando l'apprendimento automatico e l'analisi comportamentale. Monitorare gli indicatori, inclusi i download insoliti dei dati, la copia di file nell'archiviazione cloud USB/personale, l'accesso a risorse sensibili al di fuori delle normali ore lavorative o picchi di accesso ai dati prima delle date di dimissioni. La gestione dei rischi Insider correla i segnali provenienti da Microsoft 365, Azure, sistemi HR e strumenti di sicurezza per identificare potenziali furti di dati o violazioni dei criteri.

Configurare il monitoraggio e la risposta:

• Configurare i log diagnostic logs per i servizi dati e indirizzarli a Monitoraggio di Azure o Microsoft Sentinel per stabilire linee di base comportamentali e rilevare deviazioni dai modelli di accesso normali.
• Integrare i log del servizio dati con Microsoft Sentinel per creare regole di analisi per rilevare modelli di accesso ai dati anomali, ad esempio download in blocco, accessi in orari non lavorativi o comportamenti di query sospetti.
• Implementare flussi di lavoro automatizzati di risposta agli eventi imprevisti usando App per la logica di Azure o Microsoft Sentinel playbook per isolare identità compromesse, revocare l'accesso e notificare ai team di sicurezza quando vengono rilevati tentativi di esfiltrazione dei dati.

Note: Per i requisiti DLP basati su host, distribuire Microsoft Purview Endpoint DLP funzionalità o soluzioni di terze parti da Azure Marketplace per applicare controlli di protezione dei dati a livello di endpoint.

Esempio di implementazione

Un provider di servizi sanitari ha abilitato Microsoft Defender per archiviazione e Defender per SQL per monitorare le anomalie e le minacce destinate ai dati dei pazienti in Archiviazione di Azure account e database SQL.

Sfida: L'organizzazione ha riscontrato punti ciechi nel rilevare tentativi di accesso ai dati non autorizzati ed esfiltrazione. Le difese perimetrali tradizionali non sono riuscite a rilevare minacce interne e principali di servizio compromessi che eseguono download massivi. Senza l'analisi comportamentale e il rilevamento anomalie, i modelli di accesso sospetti non sono stati rilevati per periodi prolungati, aumentando il rischio di violazione e il tempo di attesa.

Approccio alla soluzione:

• Enable Microsoft Defender for Storage: Abilitare Defender per l'archiviazione a livello di sottoscrizione per gli account di archiviazione contenenti dati sensibili, configurare l'analisi malware per rilevare e mettere in quarantena i file dannosi nell'archiviazione BLOB, abilitare il rilevamento delle minacce ai dati sensibili usando i tipi di informazioni sensibili purview per identificare i modelli PHI/PII, impostare limiti di analisi per transazione o limiti mensili su controllare i costi, applicare la protezione ai gruppi di risorse contenenti account di archiviazione di produzione che ospitano esportazioni di immagini mediche ed EHR.
• Enable Microsoft Defender per SQL: Abilitare Defender per SQL a livello di sottoscrizione per database SQL di Azure e Istanza gestita di SQL, configurare la Valutazione delle vulnerabilità con analisi ricorrenti e designare un account di archiviazione per i risultati delle analisi; configurare le notifiche e-mail per avvisare il team di sicurezza sulle vulnerabilità identificate; abilitare Advanced Threat Protection per rilevare tentativi di injection SQL, modelli di interrogazione insoliti, accessi anomali da aree non familiari e potenziali esfiltrazioni di dati.
• Integrate con Microsoft Sentinel: Connettere Microsoft Defender per il cloud a Microsoft Sentinel usando il connettore dati, configurare le impostazioni di diagnostica (abilitare i log di diagnostica per le operazioni di archiviazione e i log di controllo SQL, indirizzare a Log Analytics workspace), creare regole di Sentinel Analytics per rilevare anomalie (avvisi di download in blocco per i download >10 GB entro 1 ora, accesso al database fuori orario, modelli di query sospetti), configurare playbook di risposta automatizzati per isolare le identità compromesse, revocare l'accesso all'archiviazione e inviare notifiche ai team di sicurezza.
• Deploy Gestione dei rischi Insider Microsoft Purview per il rilevamento delle minacce comportamentali: Abilitare la gestione dei rischi Insider e configurare i modelli di criteri (furto di dati da parte di utenti in uscita rilevando download insoliti di file da 30 a 90 giorni prima delle dimissioni, monitoraggio delle perdite di dati generali con copia su USB/cloud, monitoraggio avanzato per le perdite di dati da parte di utenti prioritari con monitoraggio avanzato per ruoli con privilegi elevati), configurare indicatori di rischio e soglie (avvisi sui volumi cumulativi di download dei file, picchi di accesso fuori orario, rilevamento sequenza che combina più segnali rischiosi), integrare origini dati (log attività Azure, log di controllo Microsoft 365, Defender for Cloud Apps, sistemi HR, eventi di prevenzione della perdita dei dati degli endpoint), configurare il flusso di lavoro per il routing degli avvisi di gravità media/alta verso una coda di investigazione dedicata.

Outcome: Defender per Archiviazione ha rilevato un'attività di download bulk anomalo da un'entità servizio compromessa entro 48 ore. La risposta automatizzata ha isolato l'identità e ha informato il SOC entro pochi minuti, riducendo il tempo di rilevamento da giorni a meno di 15 minuti. La Gestione dei rischi interni ha segnalato un dipendente in partenza che ha scaricato dati di ricerca notevolmente al di sopra del suo livello personale su un archivio cloud personale, consentendo un intervento rapido.

Livello di criticità

Indispensabile.

Mappatura dei controlli

• Controlli CIS v8.1: 3.13
• NIST SP 800-53 Rev.5: AC-4, SI-4
• PCI-DSS v4: 3.2.1, 10.4.1
• NIST CSF v2.0: DE.CM-1, PR.DS-5
• ISO 27001:2022: A.8.11, A.8.16
• SOC 2: CC6.1, CC7.2

DP-3: Crittografare i dati sensibili in transito

Criteri di Azure: Vedere Azure definizioni di criteri predefinite: DP-3.

Principio di sicurezza

Proteggere i dati in transito usando la crittografia avanzata (ad esempio TLS 1.2 o versione successiva) per impedire l'intercettazione, la manomissione e l'accesso non autorizzato. Definire i limiti di rete e gli ambiti di servizio in cui la crittografia è obbligatoria, assegnando priorità al traffico di rete esterno e pubblico, considerando al tempo stesso la protezione della rete interna in base alla riservatezza dei dati.

Rischio da mitigare

I canali di rete non crittografati o protetti in modo insufficiente espongono dati sensibili all'intercettazione, alla manipolazione e all'abuso di downgrade. Assenza di crittografia moderna del trasporto imposta (TLS 1.2+):

• Intercettazione passiva: Gli osservatori di rete acquisisce credenziali, token, payload API o dati regolamentati in testo non crittografato.
• Man-in-the-middle: Gli aggressori modificano le query, inseriscono i payload o raccolgono materiale di sessione.
• Downgrade del protocollo: Il fallback legacy (SSL/TLS < 1.2, HTTP/FTP in testo non crittografato) consente lo sfruttamento di suite di crittografia deprecate.
• Hijack della sessione: La mancanza di integrità del canale consente la riproduzione dei token o il furto di cookie per lo spostamento laterale.
• Manipolazione dell'integrità: La manomissione danneggia l'analisi o attiva transazioni fraudolente.
• Percorsi laterali opachi: Il traffico in testo non crittografato interno diventa il punto di appoggio del materiale di ricognizione.

L'impossibilità di applicare la crittografia avanzata in transito amplifica il raggio di esplosione della violazione, accelera la compromissione delle credenziali e compromette i presupposti di zero trust.

MITRE ATT&CK

• Accesso alle credenziali (TA0006): credenziali non protette (T1552) intercettate durante sessioni in testo non crittografato o sessioni TLS sottoposte a downgrade che espongono token/materiale della sessione.
• Raccolta (TA0009): analisi di rete (T1040) raccolta di payload e segreti dell'API che attraversano percorsi crittografati o non crittografati deboli.
• Esfiltrazione (TA0010): esfiltrazione attraverso servizi web (T1567) tramite streaming di dati strutturati mediante endpoint API legittimi.
• Evasione della difesa (TA0005): attacco in-the-middle (T1557) forzando il downgrade TLS o inserendo proxy di intercettazione per visualizzare/modificare il traffico.
• Command & Control (TA0011): protocollo di livello non applicativo (T1095) ripristinando i trasporti legacy o meno controllati per bypassare il monitoraggio.

DP-3.1: Applicare la crittografia TLS per servizi dati e applicazioni

Stabilire standard di sicurezza moderni a livello di trasporto in tutti i servizi e le piattaforme dati rivolte ai clienti per proteggersi da intercettazioni, manomissioni e attacchi man-in-the-middle. Applicare almeno TLS 1.2 o 1.3 tra archiviazione, applicazioni Web, database e gateway API durante la disabilitazione di protocolli legacy e pacchetti di crittografia deboli che espongono i dati agli attacchi di downgrade crittografico.

Applicare TLS per servizi dati e applicazioni:

• Imporre il trasferimento sicuro (solo HTTPS) per gli account di archiviazione Azure per garantire che tutte le connessioni client utilizzino TLS 1.2 o versioni successive per le operazioni blob, file, code e tabelle.
• Per le applicazioni Web ospitate in Servizio app di Azure, abilitare l'impostazione "Solo HTTPS" e configurare minimum TLS versione 1.2 o 1.3 per impedire attacchi di downgrade e garantire standard di crittografia moderni.
• Configurare gateway applicazione di Azure per applicare la versione minima di TLS 1.2/1.3 sia per i listener front-end che per la crittografia della connessione back-end (TLS end-to-end).
• Per database SQL di Azure e altri servizi dati PaaS, verificare che le impostazioni "Richiedi connessioni sicure" o equivalenti applichino connessioni crittografate; rifiuta le connessioni in testo non crittografato.
• Per Gestione API, Frontdoor di Azure e altri servizi gateway, configurare i criteri di versione minima di TLS per applicare TLS 1.2 o versione successiva e disabilitare suite di crittografia vulnerabili.

Note: Azure crittografa automaticamente tutto il traffico tra data center Azure usando MACsec (livello 2) e TLS (livello 7). La maggior parte dei servizi PaaS Azure abilita TLS 1.2+ per impostazione predefinita, ma verifica le impostazioni minime della versione TLS per i servizi con criteri configurabili dal cliente (archiviazione, servizio app, gateway applicazione, Gestione API, Frontdoor).

DP-3.2: Proteggere l'accesso remoto e i protocolli di trasferimento dei file

Eliminare l'accesso amministrativo in testo non crittografato e i protocolli di trasferimento di file legacy che espongono credenziali e dati sensibili durante le attività operative. Sostituire i protocolli non sicuri (FTP, RDP/SSH non crittografati) con alternative moderne e crittografate e instradare l'accesso con privilegi tramite bastioni centralizzati per eliminare l'esposizione diretta a Internet delle interfacce di gestione.

Proteggere i protocolli di gestione remota:

• Per la gestione remota delle macchine virtuali di Azure, usare esclusivamente protocolli sicuri:
  • Macchine virtuali Linux: Usare SSH (porta 22) con l'autenticazione basata su chiave; disabilitare l'autenticazione della password.
  • Windows VM: Usare RDP su TLS (porta 3389) con l'autenticazione a livello di rete abilitata.
  • Accesso privilegiato: Instradare le connessioni amministrative tramite Azure Bastion per eliminare l'esposizione ip pubblica e fornire l'accesso client nativo o basato su browser tramite TLS.

Protocolli di trasferimento file sicuri:

• Per le operazioni di trasferimento di file, usare protocolli sicuri e disabilitare le alternative legacy:
  • Usare il supporto SFTP in Archiviazione BLOB di Azure (richiede uno spazio dei nomi gerarchico).
  • Usare FTPS in Servizio app di Azure e Funzioni di Azure.
  • Disabilitare il protocollo FTP legacy (testo non crittografato).
• Usare Criteri di Azure per applicare criteri di trasferimento sicuri nell'ambiente e monitorare la conformità per i requisiti di versione TLS.

Esempio di implementazione

Una piattaforma di e-commerce ha imposto la versione minima di TLS 1.3 in tutti i servizi rivolti ai clienti per soddisfare i requisiti PCI-DSS 4.0.

Sfida: I protocolli TLS 1.0/1.1 legacy e i pacchetti di crittografia deboli esponevano i dati di pagamento dei clienti agli attacchi di intercettazione. L'implementazione incoerente di TLS nei livelli dell'applicazione ha creato lacune di sicurezza in cui gli attaccanti potrebbero degradare le connessioni. Senza l'applicazione centralizzata dei criteri TLS, la deviazione manuale della configurazione consentiva la persistenza dei protocolli non sicuri nell'ambiente di produzione.

Approccio alla soluzione:

• Configurare Servizio app di Azure per TLS 1.3: Impostare la versione minima di TLS su 1.3 per le api e le applicazioni Web rivolte ai clienti, abilitare la modalità solo HTTPS per reindirizzare automaticamente tutto il traffico HTTP a HTTPS, verificare che i certificati gestiti o i certificati personalizzati usino pacchetti di crittografia sicuri.
• Configurare gateway applicazione di Azure per un TLS end-to-end completo: Configurare il listener HTTPS front-end con criteri SSL AppGwSslPolicy20220101 (TLS 1.3 minimo con criteri CustomV2), caricare il certificato TLS o integrarlo con Key Vault per la gestione dei certificati, configurare le impostazioni back-end per le connessioni HTTPS (impostare il protocollo back-end su HTTPS sulla porta 443, abilitare "Usare un certificato CA noto" se i servizi app back-end utilizzano certificati gestiti da Azure, impostare la versione minima di TLS su 1.2 per le connessioni back-end), creare regole di routing che collegano listener HTTPS a pool back-end con impostazioni TLS abilitate.
• Enforce secure transfer for Archiviazione di Azure: Abilita l'impostazione "trasferimento sicuro obbligatorio" per applicare l'uso esclusivo di HTTPS nelle operazioni su blob, file, code e tabelle, imposta la versione minima di TLS su 1.2 per tutte le connessioni ai servizi di archiviazione e verifica che tutti i token SAS e le chiavi condivise funzionino esclusivamente su connessioni HTTPS.
• Configurare Azure Bastion per l'accesso remoto sicuro: Distribuire Azure Bastion nella rete virtuale dell'hub per fornire l'accesso RDP/SSH basato su browser tramite TLS 1.2, rimuovere indirizzi IP pubblici dalle macchine virtuali e instradare tutti gli accessi amministrativi esclusivamente tramite Bastion.

Outcome: Gli account di Archiviazione di Azure rifiutano le connessioni HTTP al limite del servizio, il Gateway Applicazioni applica TLS 1.3 per le connessioni front-end con la crittografia nel backend TLS 1.2 e Azure Bastion elimina l'esposizione dell'IP pubblico per la gestione delle macchine virtuali.

Livello di criticità

Indispensabile.

Mappatura dei controlli

• Controlli CIS v8.1: 3.10
• NIST SP 800-53 Rev.5: SC-8
• PCI-DSS v4: 4.2.1, 4.2.2
• NIST CSF v2.0: PR. DS-2
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1, CC6.7

DP-4: Abilitare la crittografia dei dati inattivi per impostazione predefinita

Criteri di Azure: Vedere Azure definizioni di criteri predefinite: DP-4.

Principio di sicurezza

Abilitare la crittografia a riposo per impostazione predefinita per proteggere i dati da accessi non autorizzati tramite la memoria sottostante, il furto di supporti fisici, l'esposizione degli snapshot o l'accesso compromesso all'infrastruttura. La crittografia integra i controlli di accesso assicurando che i dati rimangano protetti anche quando la sicurezza a livello di archiviazione viene ignorata.

Rischio da mitigare

I livelli di archiviazione non crittografati o crittografati in modo selettivo consentono agli utenti malintenzionati di accedere fuori banda (compromissione dell'infrastruttura, supporti rubati, abusi di snapshot) per raccogliere dati sensibili su larga scala. Senza crittografia predefinita:

• Raccolta di dati da supporti non elaborati: I dischi rubati, i backup o gli snapshot non gestiti espongono set di dati in testo non crittografato completi.
• Erosione dei limiti dei privilegi: Gli amministratori della piattaforma o gli agenti host compromessi possono leggere i dati del tenant senza segregazione crittografica.
• Copia silenziosa e esfiltrazione: Le repliche non crittografate (test, analisi, esportazione) diventano canali di esfiltrazione a basso attrito.
• Manomissione dell'integrità: Gli attaccanti modificano i dati inattivi (DLL dannose, configurazione o dati di riferimento) per attivare una compromissione in una fase successiva.
• Non conformità alle normative: La mancanza di crittografia sistemica compromette le garanzie necessarie per molte certificazioni del settore.
• Esposizione al recupero senza chiave: Le immagini di ripristino di emergenza e gli archivi ad accesso sporadico mantengono il contenuto sensibile a tempo indeterminato in testo non crittografato recuperabile.

La mancata applicazione della crittografia universale a riposo aumenta la portata delle violazioni, complica la portata dell'indagine forense e accresce il rischio operativo e legale a valle.

MITRE ATT&CK

• Raccolta (TA0009): dati dei sistemi di archiviazione cloud (T1530) estraendo snapshot, repliche o dischi scollegati non crittografati.
• Evasione della difesa (TA0005): rimozione dell'indicatore (T1070), modifica o eliminazione dei registri in seguito all'accesso tramite supporto offline o snapshot.
• Impatto (TA0040): distruzione dei dati (T1485) che corrompe gli asset non crittografati dormienti per interrompere i processi a valle.
• Impatto (TA0040): inibire il ripristino del sistema (T1490) eliminando o modificando i backup non crittografati e i cataloghi di ripristino.
• Impatto (TA0040): manipolazione dei dati (T1565) modificando sottilmente i dati di riferimento o di configurazione archiviati per causare errori logici nella fase successiva.

DP-4.1: abilitare la crittografia dei dati inattivi per impostazione predefinita

Assicurarsi che tutti i dati archiviati in Azure siano crittografati a riposo per proteggersi da accessi non autorizzati a causa della compromissione dell'infrastruttura, media rubati o snapshot non autorizzati. Anche se la maggior parte dei servizi di Azure abilita la crittografia per impostazione predefinita, verificare la copertura tra macchine virtuali, account di archiviazione e database e abilitare livelli di crittografia aggiuntivi (crittografia at-host, crittografia dell'infrastruttura, confidential computing e crittografia a livello di colonna) per i carichi di lavoro altamente sensibili per soddisfare i requisiti normativi e di sovranità dei dati.

Abilitare la crittografia per le macchine virtuali e l'archiviazione:

• Abilitare encryption-at-host per Macchine virtuali di Azure crittografare dischi temporanei, cache del disco del sistema operativo, cache del disco dati e dischi temporanei del sistema operativo prima che i dati raggiungano Archiviazione di Azure. Registrare la funzionalità EncryptionAtHost a livello di sottoscrizione e distribuire le macchine virtuali usando le dimensioni delle macchine virtuali supportate, ad esempio DSv3, Easv4, Serie Dadsv5.
• Abilitare la crittografia infrastructure (crittografia doppia) per gli account Archiviazione di Azure che richiedono livelli di crittografia aggiuntivi. In questo modo sono disponibili due livelli di crittografia AES-256 con chiavi diverse a livello di servizio e infrastruttura, configurate durante la creazione dell'account di archiviazione perché non possono essere abilitate dopo la creazione.

Distribuire l'elaborazione riservata e la crittografia a livello di colonna:

• Distribuire le macchine virtuali riservate di Azure con crittografia dei dischi riservati per elaborare carichi di lavoro altamente regolamentati e dati sensibili o controllati dall'esportazione. Usare serie DCasv5/DCadsv5 (AMD SEV-SNP) o ECasv5/ECadsv5 (Intel TDX) con chiavi di crittografia del disco associate a vTPM per garantire che i dati rimangano crittografati durante l'elaborazione.
• Per database SQL di Azure, implementare Always Encrypted per fornire la crittografia a livello di colonna lato client per dati altamente sensibili (SSN, numeri di carta di credito, record medici) in cui i dati rimangono crittografati anche da amministratori di database, operatori cloud e utenti con privilegi elevati ma non autorizzati. Usare Always Encrypted con enclave sicuri (Intel SGX) per abilitare query più avanzate sulle colonne crittografate.

Monitorare e applicare la conformità della crittografia:

• Applicare la conformità della crittografia usando Criteri di Azure assegnando criteri predefiniti, ad esempio "Le macchine virtuali devono abilitare la crittografia nell'host", "Gli account di archiviazione devono avere la crittografia dell'infrastruttura" e "Transparent Data Encryption nei database SQL devono essere abilitati" nell'ambito della sottoscrizione o del gruppo di gestione.
• Usare Azure Resource Graph per eseguire query e inventariare le configurazioni di crittografia nell'ambiente, identificando le macchine virtuali senza crittografia in host, account di archiviazione senza crittografia dell'infrastruttura o database senza TDE abilitato.

Note: Molti servizi di Azure (Archiviazione di Azure, database SQL di Azure, Azure Cosmos DB) hanno la crittografia dei dati inattivi abilitata per impostazione predefinita a livello di infrastruttura mediante chiavi gestite dal servizio che vengono ruotate automaticamente ogni due anni. Se la crittografia non è abilitata per impostazione predefinita, abilitarla a livello di archiviazione, file o database in base ai requisiti tecnici di fattibilità e carico di lavoro.

Esempio di implementazione

Un'azienda di produzione multinazionale ha standardizzato la crittografia dei dati inattivi nell'ambiente Azure per proteggere i dati ERP, le applicazioni della supply chain e i segreti commerciali di progettazione.

Sfida: La copertura di crittografia incoerente ha lasciato i dati sensibili vulnerabili alla compromissione dell'infrastruttura e al furto di snapshot. I dati del disco temporaneo e l'archiviazione temporanea sono rimasti non crittografati, creando gap di conformità. Senza applicazione sistematica della crittografia, i segreti commerciali di progettazione e i dati della supply chain potrebbero essere esposti tramite dischi rubati, snapshot non autorizzati o agenti host compromessi.

Approccio alla soluzione:

• Abilita crittografia at-host per Macchine virtuali di Azure: Registrare la funzionalità EncryptionAtHost a livello di sottoscrizione, abilitare la crittografia at-host per le macchine virtuali usando dimensioni di vm supportate (DSv3, Easv4, Serie Dadsv5), la crittografia copre i dischi temporanei, la cache del disco del sistema operativo del sistema operativo, la cache dei dischi dati e i dischi temporanei del sistema operativo.
• Abilita crittografia dell'infrastruttura (crittografia doppia) per Archiviazione di Azure: Verificare che la crittografia del servizio di Archiviazione di Azure (SSE) sia abilitata (per impostazione predefinita, crittografia AES-256), per gli account di archiviazione sensibili abilitare la crittografia dell'infrastruttura durante la creazione dell'account di archiviazione (non può essere abilitata dopo la creazione), risultato: due livelli di crittografia AES-256 con chiavi diverse.
• Distribuire le macchine virtuali Azure Confidential per carichi di lavoro altamente regolamentati: Selezionare la serie di macchine virtuali Confidential appropriate (serie DCasv5/DCadsv5 per AMD SEV-SNP o serie ECasv5/ECadsv5 per Intel TDX), abilitare la crittografia dei dischi confidenziali con la chiave gestita dalla piattaforma (associa le chiavi di crittografia del disco al TPM virtuale della macchina virtuale), abilitare l'avvio protetto e vTPM per l'attestazione, distribuire per i carichi di lavoro che elaborano dati tecnici controllati all'esportazione o informazioni personali altamente regolamentate in cui i dati devono rimanere crittografati durante l'elaborazione.
• Implementare Always Encrypted per i campi sensibili nelle colonne del database: Identificare colonne altamente sensibili in database SQL di Azure che richiedono la crittografia a livello di colonna (SSN, CreditCardNumber, MedicalRecordNumber), generare chiavi di crittografia delle colonne (CEK) e chiavi master delle colonne (CMK) archiviando il CMK in Azure Key Vault; il CEK crittografa le colonne di dati e il CMK crittografa il CEK, abilitare Always Encrypted con enclave sicure (Intel SGX) per consentire query più avanzate sui dati crittografati, crittografare colonne sensibili usando la crittografia deterministica (per confronti di uguaglianza) o la crittografia casuale (massima sicurezza), configurare le stringhe di connessione delle applicazioni con impostazione per l'Encryptione delle Colonne=Abilitata per la crittografia/decrittografia trasparente.
• Configurazioni di crittografia Inventory con Azure Resource Graph: Eseguire query sullo stato di crittografia per le macchine virtuali senza crittografia all'host e agli account di archiviazione senza crittografia dell'infrastruttura, esportare i risultati in CSV e assegnare attività di correzione ai proprietari delle risorse.

Risultato: La crittografia all'host ha risolto le lacune di conformità in cui i dati del disco temporaneo erano precedentemente non crittografati. File di progettazione protetti dalla crittografia dell'infrastruttura con due livelli di crittografia. Le macchine virtuali confidenziali hanno garantito che i dati soggetti a controllo delle esportazioni rimanessero crittografati anche per gli amministratori cloud. Colonne di database sensibili protette Always Encrypted: gli amministratori del database hanno confermato l'impossibilità di leggere testo in chiaro dalle colonne crittografate, soddisfando i requisiti di conformità.

Livello di criticità

Indispensabile.

Mappatura dei controlli

• Controlli CIS v8.1: 3.11
• NIST SP 800-53 Rev.5: SC-28
• PCI-DSS v4: 3.5.1, 3.6.1
• NIST CSF v2.0: PR. DS-1
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1

DP-5: usare l'opzione chiave gestita dal cliente nella crittografia dei dati inattivi quando necessario

Criteri di Azure: Consultare definizioni predefinite dei criteri di Azure: DP-5.

Principio di sicurezza

Usare le chiavi gestite dal cliente quando la conformità alle normative, i requisiti contrattuali o la riservatezza dei dati richiedono il controllo diretto sul ciclo di vita delle chiavi di crittografia, tra cui generazione, rotazione e autorità di revoca delle chiavi. Assicurarsi che siano presenti processi di gestione delle chiavi appropriati per gestire il sovraccarico operativo.

Rischio da mitigare

Affidarsi esclusivamente alle chiavi gestite dal servizio, quando le normative, i contratti o le garanzie di segregazione richiedono il controllo del tenant, introduce rischi di conformità e concentrazione. Senza chiavi gestite dal cliente correttamente gestite (CMK):

• Garanzia normativa inadeguata: I revisori possono rifiutare la prova del controllo crittografico se non è possibile dimostrare la custodia delle chiavi, la frequenza di rotazione o l'autorità di revoca.
• Latenza di revoca: L'impossibilità di revocare o ruotare rapidamente le chiavi della piattaforma compromesse estende la finestra di esposizione dopo eventi di compromesso delle credenziali o della catena di fornitura.
• Esposizione giurisdizionale: I mandati di sovranità dei dati possono richiedere chiavi gestite dal tenant o supportate da HSM; la loro assenza compromette la fattibilità della distribuzione regionale.
• Raggio di esplosione tra tenant: La compromissione della chiave della piattaforma multi-tenant può influire sui set di dati generali quando l'isolamento crittografico non è sufficiente.
• Proliferazione delle chiavi: Le distribuzioni CMK ad hoc senza governance del ciclo di vita portano a chiavi obsolete, orfane o deboli.
• Fragilità operativa: Un'automazione della rotazione insufficiente o un mapping delle dipendenze mancante causa malfunzionamenti dell'applicazione durante la rotazione delle chiavi.

L'uso improprio o omesso del CMK indebolisce la garanzia crittografica e compromette il posizionamento strategico di conformità per i carichi di lavoro sensibili.

MITRE ATT&CK

• Accesso alle credenziali (TA0006): credenziali non protette (T1552) esposte da chiavi della piattaforma debolmente protette o segmentate in modo improprio.
• Impatto (TA0040): dati crittografati per l'impatto (T1486) abusando della rotazione o della revoca CMK per rendere i dati inaccessibili.
• Impatto (TA0040): manipolazione dei dati (T1565) modifica dei metadati dello stato di crittografia per desynchronizzare i livelli di protezione.
• Esfiltrazione (TA0010): trasferimento dei dati, con nuova crittografia, verso un account cloud (T1537) ed esportazione dei set di dati in uno storage controllato dall'attaccante.
• Esfiltrazione (TA0010): esfiltrazione tramite servizi Web (T1567) che orchestra esportazioni bulk ad alto volume abilitate tramite chiavi secondo i normali modelli di servizio.

DP-5.1: usare l'opzione chiave gestita dal cliente nella crittografia dei dati inattivi quando necessario

Implementare chiavi gestite dal cliente quando la conformità alle normative, la sovranità dei dati o gli obblighi contrattuali richiedono un controllo diretto sulla custodia delle chiavi di crittografia, pianificazioni di rotazione e autorità di revoca. Per i carichi di lavoro che richiedono il controllo finale in cui anche Microsoft non è in grado di decrittografare i dati, implementare La crittografia a chiave doppia (DKE) in cui l'organizzazione gestisce una seconda chiave di crittografia al di fuori del Azure. Usare Azure Key Vault o HSM gestito per mantenere il controllo crittografico, bilanciando al contempo la complessità operativa della gestione del ciclo di vita delle chiavi, la pianificazione del ripristino di emergenza e potenziali impatti sulla disponibilità del servizio dagli errori di gestione delle chiavi.

Valutare i requisiti del CMK e fornire l'infrastruttura chiave:

• Valutare i requisiti normativi, di conformità o aziendali per determinare quali carichi di lavoro necessitano di chiavi gestite dal cliente anziché chiavi gestite dalla piattaforma. I driver comuni includono sovranità dei dati, requisiti di controllo o obblighi contrattuali per la custodia diretta delle chiavi.
• Effettuare il provisioning di Azure Key Vault (Standard o Premium) o Managed HSM di Azure Key Vault per archiviare e gestire chiavi di crittografia gestite dal cliente. Utilizzare Managed HSM per i carichi di lavoro che richiedono la protezione hardware convalidata FIPS 140-3 Livello 3.
• Generare chiavi di crittografia all'interno di Azure Key Vault usando funzionalità di generazione chiavi o importare chiavi da HSM locali usando porta la tua chiave (BYOK) per la massima portabilità e controllo.

Configurare il CMK e stabilire la gerarchia delle chiavi:

• Per i requisiti di controllo estremi, implementare Double Key Encryption (DKE) in cui i documenti sensibili richiedono due chiavi per la decrittografia: una gestita da Microsoft (Azure RMS) e una seconda chiave gestita esclusivamente dall'organizzazione in locale o nel proprio servizio di gestione delle chiavi esterne. Con DKE, Microsoft non è in grado di decrittografare i tuoi dati, anche se costretta da procedimenti legali, poiché voi controllate la seconda chiave necessaria per la decrittografia.
• Configurare i servizi di Azure (Archiviazione di Azure, database SQL di Azure, Azure Cosmos DB, Crittografia dischi di Azure e così via) per l'uso della chiave cmk facendo riferimento all'URI della chiave Key Vault. Abilitare i criteri di rotazione automatica delle chiavi per ridurre il carico operativo manuale.
• Stabilire una gerarchia della chiave di crittografia della chiave di crittografia (KEK) < 0 in cui la chiave di crittografia della chiave (archiviata in Key Vault) crittografa la chiave DEK (usata dai servizi), riducendo al minimo l'impatto della rotazione delle chiavi sulla disponibilità del servizio.
• Documentare le procedure chiave del ciclo di vita, incluse le pianificazioni di rotazione delle chiavi, i processi di revoca per le chiavi compromesse, i flussi di lavoro di ritiro chiave e le procedure di ripristino di emergenza. Integrare la gestione delle chiavi nei processi di gestione delle modifiche dell'organizzazione.

Nota: Le chiavi gestite dal cliente richiedono investimenti operativi continui, tra cui la gestione del ciclo di vita chiave, l'amministrazione del controllo di accesso, il monitoraggio e la pianificazione del ripristino di emergenza. Assicurarsi della prontezza operativa prima dell'adozione di una chiave gestita dal cliente (CMK), poiché una gestione delle chiavi non corretta può comportare la mancata disponibilità o la perdita di dati.

Esempio di implementazione

Un istituto finanziario regolamentato ha distribuito chiavi gestite dal cliente tra i servizi Azure per soddisfare i requisiti normativi per il controllo crittografico diretto sui dati di trading e sui record finanziari dei clienti.

Sfida: I revisori normativi hanno richiesto un controllo crittografico dimostrato, tra cui la custodia delle chiavi, l'autorità di rotazione e la funzionalità di revoca. Le chiavi gestite dal servizio non possono fornire prove del ciclo di vita delle chiavi controllate dal tenant. Senza chiavi gestite dal cliente, l'organizzazione non ha la possibilità di revocare rapidamente l'accesso durante gli eventi imprevisti di sicurezza e non è riuscito a soddisfare i requisiti di sovranità dei dati per le distribuzioni a livello di area.

Approccio alla soluzione:

• Provisioning Azure Key Vault HSM gestito: Creare un modulo di protezione hardware gestito (FIPS 140-3 livello 3 convalidato) con almeno 3 partizioni HSM per la disponibilità elevata, attivare il modulo di protezione hardware gestito esportando il dominio di sicurezza con chiavi quorum (suddivise in frammenti di chiave archiviati in insiemi di credenziali offline geograficamente distribuiti), generare chiavi di crittografia (RSA-4096 denominate KEK-Prod-2024) con operazioni chiave: Wrap Key, Annulla il wrapping della chiave, Crittografa, Decrittografia.
• Configurare le chiavi gestite dal cliente per i servizi di Azure: Per Archiviazione di Azure, configurare l'account di archiviazione per l'uso del tipo di crittografia CMK, selezionare Managed HSM come origine chiave, abilitare l'identità gestita assegnata dall'utente con il ruolo di utente di crittografia del servizio Crypto Service Encryption User di Managed HSM; per database SQL di Azure, configurare il database SQL per l'uso della chiave gestita dal cliente come protezione TDE, selezionare la chiave da Managed HSM, abilitare la rotazione automatica; per Azure Cosmos DB, abilitare le chiavi gestite dal cliente per l'account Cosmos DB, selezionare la chiave da Managed HSM e concedere l'accesso all'identità gestita di Cosmos DB.
• Implement automated key rotation: Configurare i criteri di rotazione con frequenza di rotazione di 90 giorni, abilitare la rotazione automatica, configurare la notifica di scadenza (avviso 7 giorni prima della scadenza), creare Monitoraggio di Azure avviso per la metrica Key Near Expiry per notificare al team di sicurezza.
• Abilita la registrazione degli audit per la conformità: Abilita la registrazione diagnostica per Managed HSM (log AuditEvent), invia i log allo spazio di lavoro di Log Analytics con archiviazione immutabile (conservazione di 90 giorni per tracciabilità a prova di manomissione), interroga i log di accesso alle chiavi per monitorare le operazioni di Encrypt, Decrypt, WrapKey e UnwrapKey.
• Procedure del ciclo di vita chiave del documento: Creare runbook di revoca di emergenza (passaggi di revoca delle chiavi, contatti di risposta agli eventi imprevisti, procedure di ripristino che usano chiavi quorum del dominio di sicurezza), testare i runbook trimestrali tramite esercizi tabletop, integrare le operazioni cmk nel flusso di lavoro di approvazione delle modifiche di Gestione dei servizi IT.

Outcome: RSA-4096 KEKs nel modulo HSM gestito criptano le chiavi DEK a livello di servizio per Archiviazione di Azure, SQL Database e Cosmos DB. La rotazione automatica trimestrale riduce al minimo i tempi di inattività crittografando nuovamente solo i DEK. Il quorum del dominio di sicurezza garantisce il ripristino di emergenza anche in caso di guasto regionale completo.

Livello di criticità

Dovrebbe avere.

Mappatura dei controlli

• Controlli CIS v8.1: 3.11
• NIST SP 800-53 Rev.5: SC-12, SC-28
• PCI-DSS v4: 3.5.1, 3.6.1, 12.3.2
• NIST CSF v2.0: PR. DS-1, ID.AM-3
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1

DP-6: Usare un processo di gestione delle chiavi sicuro

Criteri di Azure: Vedere definizioni di criteri integrati di Azure: DP-6.

Principio di sicurezza

Implementare processi di gestione delle chiavi sicuri che regolano il ciclo di vita completo delle chiavi: generazione, distribuzione, archiviazione, rotazione e revoca. Usare servizi di archivio chiavi dedicati con controlli di accesso sicuri, mantenere gli standard crittografici, applicare la separazione delle mansioni e assicurarsi che le chiavi vengano ruotate regolarmente e revocate tempestivamente in caso di compromissione.

Rischio da mitigare

I cicli di vita della chiave crittografica debole o non gestita riducono la garanzia fornita dalla crittografia e possono consentire la compromissione sistemica. Senza generazione di chiavi strutturate, rotazione, protezione e revoca:

• Sprawl delle chiavi e chiavi orfane: Le chiavi non tracciate persistono oltre il tempo necessario per gli affari, mantenendo un'autorità di decrittazione non voluta.
• Crittografia obsoleta: La rara rotazione delle chiavi aumenta l'esposizione a riduzioni delle misure di sicurezza, attacchi a forza bruta o nuovi metodi di attacco laterale.
• Eccesso di privilegi: La mancanza di separazione dei ruoli permette agli amministratori di gestire e utilizzare le chiavi, favorendo l'uso improprio da parte di insider.
• Compromissione non rilevata: Nessun monitoraggio dell'integrità o derivazione della versione nasconde se le chiavi sono state sostituite in modo dannoso.
• Revoca non riuscita: La risposta agli eventi imprevisti non può contenere in modo crittografico l'accesso ai dati dopo una sospetta violazione.
• Gerarchia incoerente: La stratificazione KEK/DEK mancante moltiplica il raggio d'azione dell'esplosione di rotazione e aumenta il tempo di inattività delle operazioni.

La gestione delle chiavi carente trasforma la crittografia in un controllo temporizzato anziché una mitigazione sostenuta dalle minacce in continua evoluzione.

MITRE ATT&CK

• Accesso alle credenziali (TA0006): accesso alle credenziali dai depositi di password (T1555) attraverso l'estrazione impropria del materiale delle chiavi archiviate o memorizzate nella cache, o agli account validi (T1078) sfruttando le funzioni RBAC di gestione delle chiavi per accedere o modificare illegittimamente le chiavi.
• Evasione della difesa (TA0005): indebolire la crittografia (T1600) mantenendo algoritmi deprecati/dimensioni di chiave insufficienti per ridurre la forza crittografica.
• Impatto (TA0040): distruzione dei dati (T1485) a seguito di eventi di purga distruttiva o revoca gestiti in modo scorretto.
• Impatto (TA0040): manipolazione dei dati (T1565) sostituzione o modifica delle versioni delle chiavi per reindirizzare o disabilitare i flussi di crittografia.

DP-6.1: Stabilire criteri di gestione delle chiavi e infrastruttura

Creare una base di governance per la gestione delle chiavi crittografiche stabilendo l'archiviazione centralizzata delle chiavi, definendo gli standard di crittografia e selezionando i livelli di protezione appropriati in base alla riservatezza del carico di lavoro. Distribuire Azure Key Vault come fonte unica di verità per le operazioni relative alle chiavi, implementando una registrazione di controllo completa per tenere traccia di tutte le modalità di accesso alle chiavi e delle modifiche amministrative per scopi di conformità e forense.

Stabiliscere un'infrastruttura centralizzata di gestione delle chiavi:

• Usare Azure Key Vault come servizio centralizzato di gestione delle chiavi crittografiche per controllare il ciclo di vita completo della chiave: generazione, distribuzione, archiviazione, rotazione e revoca.
• Definire e applicare criteri di chiave che specificano gli standard di crittografia minimi:
  • Tipo di chiave: RSA (consigliata: 4096-bit o minimo 3072-bit) o EC (curve P-256, P-384, P-521).
  • Operazioni chiave: Limitare le operazioni consentite (crittografare, decrittografare, firmare, verificare, eseguire il wrapping, annullare il wrapping) in base ai principi con privilegi minimi.
  • Periodo di validità: Impostare le date di attivazione e scadenza per applicare l'utilizzo delle chiavi associato al tempo.

Scegliere il livello di Key Vault appropriato:

• Scegliere il livello di Key Vault appropriato in base ai requisiti di sicurezza e conformità del carico di lavoro:
  • Chiavi protette da software (SKU Standard e Premium): Validato FIPS 140-2 Livello 1
  • Chiavi protette dal modulo di protezione hardware (SKU Premium): Convalidato FIPS 140-2 Livello 2 (back-end HSM multi-tenant condiviso)
  • HSM gestito: Convalidato FIPS 140-3 Livello 3 (pool HSM dedicato a tenant unico)
• Per una maggiore sicurezza, utilizzare Azure Key Vault Managed HSM per una protezione HSM conforme a FIPS 140-3 Livello 3. HSM gestito supporta il dominio di crittografia per il backup e il ripristino di emergenza.
• Configurare Azure Key Vault log e indirizzare i log ad Monitoraggio di Azure o Microsoft Sentinel per tenere traccia di tutti gli eventi di accesso, rotazione e operazioni amministrative per scopi di controllo e conformità.

DP-6.2: Implementare l'automazione del ciclo di vita chiave

Automatizzare la rotazione delle chiavi e stabilire gerarchie chiave per ridurre il carico operativo, ridurre al minimo l'errore umano e abilitare la sostituzione rapida delle chiavi senza interruzioni del servizio. Implementare modelli KEK/DEK che consentono una rotazione efficiente crittografando di nuovo bundle di chiavi di piccole dimensioni anziché interi set di dati e integrare le procedure di ripristino di emergenza per mantenere la disponibilità delle chiavi in caso di errori a livello di area o eventi irreversibili.

Implementare la rotazione automatica delle chiavi:

• Implementare i criteri di rotazione automatica delle chiavi in Azure Key Vault.
  • Configurare la frequenza di rotazione in base ai requisiti di conformità (intervalli comuni: 90 giorni, 180 giorni o annualmente).
  • Abilitare le notifiche di rotazione per avvisare i team operativi prima della scadenza della chiave.
  • Configurare la rotazione automatica per generare nuove versioni chiave senza intervento manuale.

Stabilire la gerarchia delle chiavi e BYOK:

• Stabilire una gerarchia di chiavi che separa le chiavi di crittografia delle chiavi (KEK) e le chiavi di crittografia dei dati (DEK):
  • Archiviare kek in Azure Key Vault con controlli di accesso limitati.
  • Generare DEK a livello di servizio, crittografati da KEK, riducendo al minimo il raggio di esplosione della rotazione delle chiavi.
  • La rotazione della chiave KEK richiede solo la ricrittografazione dei DEK (non interi set di dati), consentendo una rotazione efficiente delle chiavi con tempi di inattività zero.
• Per gli scenari Bring Your Own Key (BYOK), generare chiavi in HSM locali conformi a FIPS 140-2 Livello 2+ e usare il meccanismo di trasferimento BYOK per importare in modo sicuro le chiavi in Azure Key Vault o HSM gestiti, mantenendo la custodia e la prova crittografica dell'origine della chiave.

Implementare le procedure di ripristino di emergenza:

• Creare Key Vault con replica geografica nelle aree secondarie.
• Eseguire il backup e il ripristino delle chiavi per mantenere la disponibilità delle chiavi tra aree.
• Documentare e testare le procedure di ripristino di emergenza con destinazioni RTO/RPO definite.

DP-6.3: Applicare la separazione dei compiti per l'accesso alle chiavi

Evitare minacce interne e abusi dei privilegi separando i ruoli di gestione delle chiavi dai ruoli delle operazioni di crittografia, assicurando che nessuna singola identità possa creare chiavi e usarle per la crittografia o la decrittografia dei dati. Implementare il monitoraggio continuo per rilevare modelli di accesso chiave anomali e mantenere inventari chiave completi che consentono una valutazione rapida dell'impatto durante gli incidenti di sicurezza o i controlli di conformità.

Applicare la separazione dei compiti:

• Implementare il controllo degli accessi in base al ruolo o i criteri di accesso per applicare la separazione dei compiti:
  • Ruoli separati per gli amministratori delle chiavi (che possono creare/ruotare/eliminare chiavi, ma non possono eseguire operazioni di crittografia).
  • Ruoli separati per gli utenti chiave (che possono eseguire operazioni di crittografia/decrittografia, ma non possono gestire le chiavi).
  • Ruoli di esempio: Key Vault Crypto Officer (amministratori), Key Vault Utente crypto (applicazioni/utenti).
• Verificare che nessuna singola identità abbia accesso sia amministrativo che operativo per evitare abusi sui privilegi.

Monitorare l'accesso alle chiavi e gestire l'inventario:

• Integrare il monitoraggio dell'accesso chiave con Microsoft Sentinel per rilevare le anomalie:
  • Modelli di accesso a chiavi insoliti (accesso da indirizzi IP o aree non familiari).
  • Operazioni di chiavi all'ingrosso (operazioni eccessive entro brevi periodi di tempo).
  • Modifiche amministrative non lavorative (eliminazione delle chiavi o rotazione al di fuori dell'orario di ufficio).
• Mantenere un inventario chiave con il nome della chiave, lo scopo, il programma di rotazione e i servizi dipendenti. Esaminare regolarmente l'inventario durante le verifiche di sicurezza.

Esempio di implementazione

Un provider SaaS sanitario ha centralizzato la gestione delle chiavi crittografiche usando Azure Key Vault SKU Premium con chiavi protette con HSM per la crittografia PHI nella piattaforma multi-tenant.

Sfida: La gestione delle chiavi frammentata tra i team di sviluppo ha portato a procedure di rotazione incoerenti e difficoltà a tenere traccia dell'utilizzo delle chiavi durante gli eventi imprevisti della sicurezza. Autorizzazioni di controllo degli accessi in base al ruolo troppo ampie consentono agli amministratori di gestire e usare chiavi, creando rischi interni. Senza rotazione automatizzata e separazione dei compiti, l'organizzazione ha dovuto affrontare finestre estese di compromissione delle chiavi e inadempienze di conformità agli audit.

Approccio alla soluzione:

• Eseguire il provisioning di Azure Key Vault Premium con chiavi protette da HSM: Creare Azure Key Vault con il livello Premium a supporto delle chiavi protette da HSM, abilitare la protezione dall'eliminazione definitiva per impedire l'eliminazione permanente durante il periodo di conservazione, abilitare la cancellazione temporanea con conservazione di 90 giorni per consentire il ripristino di chiavi eliminate accidentalmente, generare chiavi di crittografia protette da HSM RSA-3072 (KEK-PHI-Prod) con tipo di chiave supportata dall'hardware.
• Implementare politiche di rotazione automatizzata delle chiavi: Configurare la politica di rotazione con una frequenza di rotazione di 180 giorni, abilitare la rotazione automatica e impostare una notifica per avvisare 30 giorni prima della scadenza. Creare gruppi di azione di Monitoraggio di Azure per notificare al team di operazioni di sicurezza quando le chiavi si avvicinano alla scadenza, configurare l'azione di rotazione per generare automaticamente nuove versioni delle chiavi.
• Configurare la separazione dei compiti usando il controllo degli accessi in base al ruolo: assegnare il ruolo di Crypto Officer di Key Vault ai membri del team di sicurezza (autorizzazioni: gestire il ciclo di vita delle chiavi, ma non è possibile eseguire operazioni di crittografia/decrittografia), assegnare il ruolo di Crypto User di Key Vault alle identità gestite dall'applicazione (autorizzazioni: eseguire operazioni di crittografia/decrittografia solo senza autorizzazioni di gestione delle chiavi), verificare la separazione dei compiti assicurando che nessuna identità abbia contemporaneamente i ruoli di Crypto Officer e Crypto User.
• Stabilire una gerarchia KEK/DEK per una rapida rotazione delle chiavi: Generare chiavi di crittografia dei dati (DEK) a livello di applicazione nel codice dell'applicazione (chiavi AES-256) per crittografare i dati dei pazienti, archiviare i DEK crittografati insieme ai dati crittografati, utilizzare una KEK del Key Vault per eseguire il wrapping e crittografare i DEK tramite l'operazione WrapKey, recuperare e annullare il wrapping del DEK usando l'operazione UnwrapKey durante la decrittografia dei dati dei pazienti, vantaggio principale: la rotazione della KEK richiede solo la ricrittografia dei DEK anziché l'intero database dei pazienti.
• Integrate Key Vault log con Microsoft Sentinel: Abilitare le impostazioni di diagnostica per Key Vault e inviare log all'area di lavoro Log Analytics, creare regole di analisi di Sentinel per rilevare modelli di accesso a chiavi insoliti, operazioni in blocco, modifiche amministrative non lavorative.
• Trasferimento Bring Your Own Key (BYOK) da HSM locali: Scarica la chiave di trasferimento BYOK dal Key Vault, esporta la chiave dal HSM locale avvolta con la chiave pubblica di trasferimento BYOK di Key Vault, mantieni la prova crittografica dell'origine della chiave, importa la chiave avvolta nel Key Vault dove arriva protetta da HSM senza esposizione del testo in chiaro.

Risultato: Le chiavi RSA-3072 ruotano ogni 180 giorni con notifiche automatiche. La separazione del controllo degli accessi in base al ruolo impedisce l'uso abusivo dei privilegi. La gerarchia KEK/DEK consente una rotazione rapida ri-crittografando solo i DEK. Il "soft delete" permette di recuperare le chiavi eliminate accidentalmente. Microsoft Sentinel rileva anomalie come l'accesso IP non familiare o le modifiche alle ore di minore attività.

Livello di criticità

Indispensabile.

Mappatura dei controlli

• Controlli CIS v8.1: N/D
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-28
• PCI-DSS v4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR.AC-1, PR.DS-1
• ISO 27001:2022: A.8.24, A.8.3
• SOC 2: CC6.1, CC6.2

DP-7: Usare un processo di gestione dei certificati sicuro

Criteri di Azure: Vedere definizioni di criteri predefiniti di Azure: DP-7.

Principio di sicurezza

Gestire i cicli di vita dei certificati tramite processi centralizzati che includono inventario, rinnovo automatizzato, standard crittografici sicuri e revoca tempestiva. Assicurarsi che i certificati per i servizi critici vengano monitorati, monitorati e rinnovati prima della scadenza per evitare interruzioni del servizio e mantenere comunicazioni crittografate sicure.

Rischio da mitigare

I cicli di vita dei certificati gestiti inadeguatamente causano interruzioni del servizio, indeboliscono i canali crittografati e consentono l'impersonificazione. Senza inventario centralizzato, applicazione dei criteri e rinnovo automatico:

• Scadenze impreviste: I certificati scaduti causano interruzioni della produzione, interrompendo le API, la federazione delle identità o i percorsi di attendibilità client.
• Persistenza della crittografia debole: Le dimensioni delle chiavi legacy/algoritmi di firma (ad esempio, SHA-1, RSA < 2048) rimangono in uso oltre la deprecazione.
• Wildcard e abuso di certificati autofirmati: I certificati autofirmati con ambito ampio o non gestiti consentono l'impersonificazione laterale e il rischio di downgrade del TLS.
• Compromissione non rilevata: Le chiavi private rubate consentono la decrittografia trasparente man-in-the-middle o traffico fino alla rotazione.
• Certificati ombra: Il rilascio non autorizzato al di fuori delle Autorità di Certificazione approvate frammenta la governance e aumenta i punti ciechi nel processo di revoca.
• Errori di rinnovo manuale: Il sequenziamento incoerente delle sostituzioni provoca disallineamenti della catena di attendibilità e deriva parziale dell'ambiente.

La gestione dei certificati carente degrada la garanzia crittografata e introduce sia l'affidabilità che l'instabilità della sicurezza nei servizi critici.

MITRE ATT&CK

• Evasione della difesa (TA0005): sovverte i controlli di attendibilità (T1553) che emettono o introducono certificati fraudolenti/non autorizzati per ignorare la convalida.
• Sviluppo di risorse (TA0042): sviluppare funzionalità (T1587) per la creazione di certificati o strumenti per le fasi future di intrusione.
• Evasione della difesa (TA0005): indebolire la crittografia (T1600) continuando a usare algoritmi di firma obsoleti riducendo la garanzia di verifica.
• Accesso alle credenziali (TA0006): credenziali non protette (T1552) che estraggono chiavi private da archivi file non sicuri o da memoria di processo.
• Persistenza (TA0003): modificare il processo di autenticazione (T1556) riscrivendo i flussi di autenticazione basati su certificati per incorporare l'accesso di lunga durata.

DP-7.1: Stabilire i criteri dei certificati e l'integrazione della CA

Definire gli standard di governance dei certificati e integrare autorità di certificazione attendibili per garantire una qualità crittografica coerente e il rilascio automatizzato nell'infrastruttura. Stabilire criteri che applicano dimensioni delle chiavi moderne, algoritmi di firma e periodi di validità, eliminando al tempo stesso procedure rischiose come certificati autofirmati e certificati con caratteri jolly che espandono le superfici di attacco quando le chiavi private vengono compromesse.

Stabilire un'infrastruttura di gestione dei certificati:

• Usare Azure Key Vault per gestire centralmente il ciclo di vita completo del certificato: creazione, importazione, rinnovo, rotazione, revoca ed eliminazione sicura.
• Definire certificate policies in Azure Key Vault per applicare gli standard di sicurezza dell'organizzazione:
  • Tipo di chiave e dimensioni: RSA 2048 bit minima (scelta consigliata: 3072 bit o 4096 bit per i certificati di lunga durata); EC P-256 o superiore per i certificati a curva ellittica.
  • Algoritmo di firma: SHA-256 o più forte (proibire SHA-1 e MD5).
  • Periodo di validità: Massimo 397 giorni per i certificati TLS pubblici (per requisiti di base ca/browser); durata più breve (90 giorni) consigliata per ridurre l'esposizione.
  • Autorità di certificazione: Usare solo ca private approvate e integrate (DigiCert, GlobalSign) o l'autorità di certificazione privata dell'organizzazione.

Integrare le autorità di certificazione:

• Usare le autorità di certificazione partner integrate con Azure Key Vault per i certificati TLS/SSL pubblici:
  • DigiCert: Certificati TLS/SSL convalidati dall'organizzazione
  • GlobalSign: Certificati TLS/SSL convalidati dall'organizzazione
• Per i servizi privati/interni, integrare l'autorità di certificazione interna dell'organizzazione (ad esempio, Active Directory Servizi certificati - ADCS) con Azure Key Vault per il rilascio automatico dei certificati.
• Evitare certificati autofirmati e certificati wildcard negli ambienti di produzione.
  • Certificati autofirmati: Mancano di convalida di terze parti, non possono essere revocati tramite CRL/OCSP pubblico e vengono rifiutati da browser/client moderni.
  • Certificati con caratteri jolly: Un ambito ampio aumenta il rischio se compromesso; utilizzare invece certificati SAN con FQDN espliciti.

Note: Per scenari semplici, è possibile usare certificati gestiti Servizio app di Azure (certificati gratuiti e rinnovati automaticamente per domini personalizzati).

DP-7.2: Implementare il rinnovo automatico dei certificati

Eliminare le interruzioni del servizio causate dai certificati scaduti automatizzando i flussi di lavoro di rinnovo che si attivano ben prima della scadenza e aggiornano facilmente i certificati tra i servizi dipendenti senza intervento manuale. Configurare Azure servizi per recuperare automaticamente i certificati rinnovati da Key Vault usando identità gestite, riducendo il lavoro operativo ed eliminando il rischio di rinnovi manuali dimenticati durante le transizioni di festività o di personale.

Configurare il rinnovo automatico:

• Abilitare rinnovo automatico del certificato in Azure Key Vault configurando le azioni di durata per attivare il rinnovo a una percentuale specificata di durata del certificato:
  • Trigger consigliato: 80-90% di periodo di validità (ad esempio circa 318 giorni per il certificato di 397 giorni).
  • Azione: rinnovo automatico (Key Vault richiede il rinnovo dalla CA senza intervento manuale).
• Configurare i contatti di notifica per avvisare gli amministratori delle scadenze imminenti dei certificati prima dei trigger di rinnovo automatico.

Abilitare l'associazione automatica dei certificati:

• Per i servizi di Azure che supportano la rotazione automatica dei certificati (Servizio app di Azure, gateway applicazione di Azure, Frontdoor di Azure), configurare questi servizi per recuperare automaticamente i certificati aggiornati da Key Vault con l'uso di identità gestite o di entità di servizio con i criteri di accesso appropriati di Key Vault.
  • Azure servizi associa automaticamente le nuove versioni dei certificati quando vengono rinnovate (in genere entro 24 ore, non è necessario riavviare il servizio).
• Per le applicazioni che non possono utilizzare automaticamente certificati Key Vault, implementare flussi di lavoro di rotazione dei certificati manual certificate rotation workflow con runbook operativi e avvisi di monitoraggio per evitare interruzioni correlate alla scadenza.
• Mantenere un inventario di tutti i certificati in Azure Key Vault il nome del certificato, lo scopo, la data di scadenza, i servizi dipendenti e lo stato di rinnovo.

DP-7.3: Monitorare il ciclo di vita dei certificati e gestire la revoca

Mantenere una visibilità continua sull'integrità dei certificati tramite il monitoraggio automatizzato, le query di inventario e i dashboard che mettono in evidenza i certificati che si avvicinano alla scadenza, utilizzano crittografia deprecata o mancano di una corretta governance. Stabilire procedure di revoca rapide per i certificati compromessi e integrarsi con l'intelligence sulle minacce del settore per bloccare in modo proattivo i certificati rilasciati dalle autorità di certificazione compromesse prima di abilitare gli attacchi man-in-the-middle.

Configurare il monitoraggio e gli avvisi:

• Configurare gli avvisi Monitoraggio di Azure per gli eventi di scadenza del certificato:
  • Creare avvisi a 30 giorni prima della scadenza (notifica di avviso).
  • Creare avvisi 7 giorni prima della scadenza (avviso critico con escalation verso il team di sicurezza).

Gestire l'inventario dei certificati e i dashboard:

• Usare Azure Resource Graph per eseguire query su inventario certificati:
  • Interrogare i certificati vicini alla scadenza (entro 30/60/90 giorni).
  • Interrogare certificati autofirmati.
  • Eseguire query sui certificati usando algoritmi deprecati ,ad esempio SHA-1.
• Creare dashboard di controllo certificati (ad esempio, Power BI) con visualizzazioni:
  • Sequenza temporale delle scadenze dei certificati per intervalli di tempo.
  • Numero di certificati autofirmati per gruppo di risorse.
  • Certificati che usano standard crittografici deprecati.
• Esaminare regolarmente i dashboard di controllo dei certificati durante le riunioni di revisione della sicurezza (consigliato: trimestrale).

Stabilire le procedure di revoca:

• Stabilire procedure di revoca dei certificati per i certificati compromessi o ritirati:
  • Processo di revoca dei documenti (disabilitare il certificato in Key Vault, notificare i servizi dipendenti).
  • Gestire i runbook di risposta agli eventi imprevisti per gli scenari di compromissione dei certificati.
  • Monitorare le avvertenze del settore sui certificati CA radice o intermedi compromessi e bloccarli tempestivamente.

Esempio di implementazione

Un'azienda con oltre 200 applicazioni Web pubbliche centralizzate per la gestione centralizzata del ciclo di vita dei certificati usando Azure Key Vault integrato con DigiCert come autorità di certificazione.

Sfida: I processi di rinnovo manuale dei certificati hanno causato più interruzioni di produzione quando i certificati sono scaduti in modo imprevisto. I certificati wildcard hanno amplificato l'impatto di compromissione quando le chiavi private sono state compromesse. La gestione frammentata dei certificati tra i team ha causato certificati shadow, standard crittografici incoerenti e revoca posticipata durante gli eventi imprevisti di sicurezza. Senza rinnovo automatizzato e inventario centralizzato, l'organizzazione ha dovuto affrontare errori di conformità e interruzioni del servizio.

Approccio alla soluzione:

• Configurare l'integrazione dell'autorità di certificazione con Azure Key Vault: Aggiungere DigiCert (o un'altra autorità di certificazione partner) a Key Vault con credenziali API per le richieste di certificato automatizzate.
• Creare le politiche di certificato che applicano gli standard di sicurezza: Definire le politiche di certificato con nome certificato (www-contoso-com-2024), emittente (DigiCert), subject (CN=www.contoso.com), nomi DNS (SAN: www.contoso.com, api.contoso.com, portal.contoso.com - evitare certificati con caratteri jolly), tipo di chiave (RSA 4096 bit), algoritmo di firma (SHA-256), periodo di validità (397 giorni per le linee guida del CA/Browser Forum), configurare l'azione di durata per il rinnovo automatico (impostare il trigger all'80% della durata del certificato, circa 318 giorni per il certificato di 397 giorni), azione: rinnovo automatico (Key Vault richiede il rinnovo da DigiCert senza intervento manuale).
• Configurare l'associazione automatica dei certificati per i servizi Azure: Per Servizio app di Azure, importare il certificato da Key Vault, assegnare un'identità gestita assegnata dall'utente con il ruolo Utente segreti di Key Vault, abilitare gli aggiornamenti automatici dei certificati (Servizio app di Azure associa la nuova versione del certificato entro 24 ore dal rinnovo, non è necessario riavviare); per gateway applicazione di Azure, configurare il listener per recuperare il certificato da Key Vault, assegnare un'identità gestita assegnata dall'utente con i ruoli Utente segreti di Key Vault e Utente certificati di Key Vault. Il gateway applicazioni recupera automaticamente il certificato aggiornato quando Key Vault lo rinnova.
• Configurare gli avvisi di scadenza dei certificati: Creare due regole di avviso in Monitoraggio di Azure: avviso di scadenza di 30 giorni (inviare una notifica al canale Slack di progettazione della piattaforma), avviso critico di scadenza di 7 giorni (aprire il ticket Jira per la revisione manuale e inviare un messaggio di posta elettronica al team di sicurezza).
• Eliminare i certificati con caratteri jolly a favore dei certificati SAN: Controllare i certificati jolly esistenti (*.contoso.com) in Key Vault, sostituire con i certificati SAN contenenti nomi DNS espliciti (www.contoso.com, api.contoso.com), vantaggio: se la chiave privata è compromessa, sono interessati solo i nomi FQDN elencati (non tutti i sottodomini).
• Monitorare la scadenza del certificato: Usare Azure Resource Graph per eseguire query sull'inventario dei certificati e identificare i certificati che si avvicinano alla scadenza (entro 30 giorni), certificati autofirmati o certificati che usano l'algoritmo di firma SHA-1 deprecato, esaminare il dashboard trimestrale durante le riunioni di revisione della sicurezza.

Risultato: Il rinnovo automatico dei certificati si attiva all'80% della durata. Servizio app di Azure e il gateway applicazione recuperano i certificati aggiornati entro 24 ore tramite identità gestite (nessun riavvio necessario). Monitoraggio di Azure avvisi notificano la progettazione della piattaforma prima della scadenza. I certificati SAN sostituiscono i certificati wildcard, limitando il raggio di compromissione.

Livello di criticità

Indispensabile.

Mappatura dei controlli

• Controlli CIS v8.1: N/D
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-17
• PCI-DSS v4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR. AC-1, ID.AM-3
• ISO 27001:2022: A.8.3
• SOC 2: CC6.1, CC6.2

DP-8: Garantire la sicurezza della chiave e del repository di certificati

Criteri di Azure: Vedere Azure definizioni di criteri predefinite: DP-8.

Principio di sicurezza

Proteggere i servizi di gestione delle chiavi tramite controlli di difesa in profondità: accesso con privilegi minimi, isolamento della rete, registrazione e monitoraggio dettagliati, funzionalità di backup e ripristino e protezione basata su HSM, se necessario. I key vault sono un'infrastruttura critica che protegge le chiavi crittografiche e i certificati utilizzati per la crittazione e l'autenticazione.

Rischio da mitigare

La compromissione della chiave e del repository di certificati consente di annullare la crittografia upstream, la firma e le garanzie di identità. Senza accesso, monitoraggio e isolamento dell'archivio protetto:

• Esfiltrazione della chiave: Il materiale rubato KEK/HSM consente l'intercettazione del traffico e la decrittografia massiva dei dati archiviati.
• Accesso amministrativo nascosto: Un controllo degli accessi in base al ruolo troppo esteso o una configurazione errata delle politiche consentono l'esportazione, l'eliminazione o la purga delle chiavi illecite.
• Manomissione invisibile all'utente: La sostituzione di chiavi dannose abilita codice/firme man-in-the-middle trasparenti o contraffatte.
• Esposizione alla rete: L'uso improprio dell'endpoint pubblico (stuffing delle credenziali, probe api) aumenta la superficie di attacco per la riproduzione di forza bruta o token.
• Azioni distruttive accidentali: La protezione di eliminazione temporanea/eliminazione mancante comporta una perdita irreversibile dei dati crittografici.
• Derivazione di controllo insufficiente: La mancanza di log non modificabili compromette la risposta agli eventi imprevisti e le esigenze di evidenza normativa.
• Tenancy non segmentata: Le chiavi di applicazione mescolate ampliano il raggio d'azione del movimento laterale dopo una singola compromissione dell'identità.

I punti deboli del repository si propagano rapidamente in fallimenti di riservatezza, integrità e disponibilità sistemici attraverso carichi di lavoro dipendenti.

MITRE ATT&CK

• Accesso alle credenziali (TA0006): credenziali non protette/archivi di credenziali (T1552/T1555) ottenuti tramite ruolo del vault o policy di rete non configurati correttamente.
• Evasione della difesa (TA0005): avversario in-the-middle (T1557) che acquisisce il traffico diretto al vault per l'intercettazione di chiavi/certificati o indebolire la crittografia (T1600) sostituendo chiavi robuste con materiale controllato dall'attaccante.
• Escalation dei privilegi (TA0004): account validi (T1078) che sfruttano ruoli troppo estesi degli operatori del vault per elencare e modificare i segreti.
• Impatto (TA0040): distruzione dei dati/inibizione del ripristino (T1485/T1490) mediante l'esecuzione di sequenze di eliminazione distruttive che impediscono il ripristino.

DP-8.1: Implementare i controlli di accesso per Key Vault

Proteggere la base crittografica dell'infrastruttura applicando controlli di accesso rigorosi basati sull'identità che impediscono l'accesso non autorizzato alle chiavi, limitano i privilegi amministrativi alle finestre temporali giustificate ed eliminano l'archiviazione delle credenziali tramite identità gestite. Implementare la separazione dei compiti tra gli amministratori chiave e gli utenti chiave per impedire a qualsiasi singola identità compromessa di gestire e sfruttare il materiale crittografico.

Implementare il controllo accessi basato sui ruoli e la separazione dei compiti:

• Implementare Azure Controllo degli Accessi Basato sui Ruoli per Key Vault per applicare il controllo di accesso con privilegi minimi.
  • Per Azure Key Vault Managed HSM: Usare RBAC locale a livello di chiave, segreto e certificato individuale con ruoli predefiniti (Managed HSM Crypto Officer, Crypto User, Crypto Auditor).
  • Per Azure Key Vault Standard/Premium: Creare insiemi di credenziali dedicati per ogni applicazione o ambiente per applicare la separazione logica e assegnare ruoli controllo degli accessi in base al ruolo (amministratore Key Vault, responsabile dei segreti, responsabile dei certificati) con ambito specifico dell'applicazione.
• Applicare la separazione dei compiti: separare i ruoli per la gestione delle chiavi (che possono creare/ruotare chiavi) dalle operazioni di crittografia (che possono usare chiavi per crittografare/decrittografare).

Usare identità gestite e accesso JIT:

• Usare identità gestite per le risorse Azure (Servizi app, macchine virtuali, Funzioni di Azure e così via) per accedere alle Key Vault anziché archiviare le credenziali nei file di configurazione o nel codice dell'applicazione. Le identità gestite eliminano la complessità di archiviazione e rotazione delle credenziali.
• Implementa Azure AD Privileged Identity Management (PIM) per l'accesso amministrativo just-in-time a Key Vault.
  • Configurare le assegnazioni idonee per il ruolo di Amministratore di Key Vault (assegnazioni non permanenti).
  • Richiedere giustificazione, autenticazione a più fattori e approvazione per l'attivazione.
  • Impostare la durata massima dell'attivazione (ad esempio, 8 ore).
  • Eseguire verifiche di accesso regolari per revocare privilegi permanenti non necessari.

DP-8.2: Rafforzamento della sicurezza di rete per Key Vault

Eliminare le superfici di attacco rivolte a Internet instradando tutto l'accesso a Key Vault tramite endpoint privati all'interno delle reti virtuali, impedendo l'inserimento automatico di credenziali, gli attacchi di forza bruta e la ricognizione da parte di minacce esterne. Se l'accesso pubblico è inevitabile per gli scenari CI/CD, implementare regole rigorose per l'elenco di indirizzi IP e le regole del firewall per creare la finestra di esposizione più piccola possibile.

Distribuire collegamento privato e configurare il firewall:

• Proteggere l'accesso alla rete per Azure Key Vault usando collegamento privato di Azure per stabilire la connettività privata dalle reti virtuali senza esporre Key Vault alla rete Internet pubblica.
• Configurare Key Vault firewall per limitare l'accesso a intervalli IP o reti virtuali specifici per scenari in cui collegamento privato non è fattibile:
  • Disabilitare l'accesso pubblico laddove possibile (Key Vault accessibile solo tramite endpoint privato).
  • Se è necessario l'accesso pubblico (ad esempio, per le pipeline CI/CD), consentire l'accesso dalle reti selezionate solo con elenchi di indirizzi IP limitati.
• Creare e collegare zone DNS private (ad esempio, privatelink.vaultcore.azure.net) alle reti virtuali per garantire una risoluzione DNS appropriata per gli endpoint privati.

Abilitare la protezione e il monitoraggio di Key Vault

Implementare una protezione a più livelli per la difesa che impedisca la perdita irreversibile dei dati crittografici tramite eliminazione temporanea e protezione dalla cancellazione definitiva, utilizzando chiavi supportate da un modulo di sicurezza hardware (HSM) per i carichi di lavoro di produzione che richiedono sicurezza convalidata secondo FIPS. Distribuire il monitoraggio completo con Microsoft Defender per Key Vault e Microsoft Sentinel per rilevare modelli di accesso anomali, operazioni chiave insolite e anomalie amministrative che indicano compromissione, minacce interne o attività di ricognizione destinate all'infrastruttura di crittografia.

Abilitare l'eliminazione reversibile e la protezione dalla cancellazione:

• Abilitare soft delete e purge protection in tutti gli Azure Key Vault per impedire l'eliminazione accidentale o malevola di chiavi, segreti e certificati.
  • L'eliminazione temporanea consente il ripristino entro un periodo di conservazione (impostazione predefinita: 90 giorni).
  • La protezione dall'eliminazione impedisce l'eliminazione permanente durante il periodo di conservazione.
  • Applicare queste impostazioni con Criteri di Azure usando criteri predefiniti: "Gli insiemi di credenziali di chiavi devono avere l'eliminazione temporanea abilitata" e "Gli insiemi di credenziali di chiavi devono avere la protezione dalla rimozione definitiva abilitata" (effetto deployIfNotExists).
• Implementare i criteri del ciclo di vita delle chiavi per evitare la cancellazione crittografica dei dati:
  • Prima di eliminare i dati crittografati, verificare che le chiavi di crittografia vengano mantenute per il periodo di conservazione dei dati richiesto.
  • Quando si dismettono le chiavi, usare l'operazione di disabilitazione anziché l'eliminazione per evitare perdite accidentali di dati mantenendo i metadati delle chiavi per scopi di audit.
  • Creare e testare le procedure di backup di Key Vault per gli scenari di ripristino di emergenza.

Utilizza le chiavi protette da HSM e il BYOK:

• Usare chiavi basate su HSM per carichi di lavoro di produzione che richiedono una forte protezione crittografica:
  • Azure Key Vault Premium: Chiavi RSA-HSM e EC-HSM protette da moduli di sicurezza hardware convalidati FIPS 140-2 livello 2 (multi-tenant).
  • Azure Key Vault Managed HSM: chiavi RSA-HSM e EC-HSM protette da HSM convalidati FIPS 140-3 Livello 3 (pool dedicati a tenant singolo).
• Per gli scenari Bring Your Own Key (BYOK), generare chiavi nei moduli di protezione hardware FIPS 140-2 di livello 2+ locali e usare il meccanismo di trasferimento BYOK per importare in modo sicuro le chiavi in Azure Key Vault, mantenendo la prova crittografica dell'origine e della custodia delle chiavi.

Abilitare il monitoraggio e il rilevamento delle minacce:

• Abilitare diagnostic logging per Azure Key Vault e instradare i log a Monitoraggio di Azure, Log Analytics o Microsoft Sentinel per acquisire tutte le operazioni del piano di gestione e del piano dati. Monitorare le attività sospette, inclusi modelli di accesso a chiavi insoliti, tentativi di autenticazione non riusciti e modifiche amministrative.
• Abilitare Microsoft Defender per Key Vault per rilevare modelli di accesso anomali, operazioni chiave insolite e potenziali minacce, ad esempio abusi delle credenziali, recupero di chiavi sospette o anomalie amministrative. Integrare Defender per gli avvisi di Key Vault con flussi di lavoro di risposta agli eventi imprevisti.
• Integrare Key Vault log con Microsoft Sentinel per creare regole di analisi per rilevare anomalie come l'accesso a livello di area insolito, potenziali tentativi di forza bruta o operazioni amministrative sospette. Implementare playbook di risposta automatizzati per isolare le identità compromesse e inviare notifiche ai team di sicurezza.

Note: Tutti gli SKU Key Vault impediscono l'esportazione delle chiavi in base alla progettazione; le operazioni di crittografia vengono eseguite entro il limite sicuro del modulo di protezione hardware. Non esportare o archiviare mai chiavi in testo non crittografato all'esterno di Azure Key Vault.

Esempio di implementazione

Una società tecnologica multinazionale ha implementato la sicurezza avanzata della difesa per l'infrastruttura Azure Key Vault che protegge le chiavi di crittografia, i segreti API e i certificati TLS per 500 microservizi.

Sfida: Autorizzazioni di controllo degli accessi in base al ruolo troppo ampie consentivano agli sviluppatori un accesso diretto agli archivi delle chiavi di produzione, creando rischi interni e violazioni della conformità. L'esposizione a Internet pubblica ha abilitato attacchi di inserimento delle credenziali e tentativi di ricognizione. Senza monitoraggio completo e risposta automatizzata, i modelli di accesso alle chiavi sospetti non sono stati rilevati. La mancanza di eliminazione logica e protezione contro la cancellazione definitiva ha rischiato la perdita permanente dei dati crittografici durante gli eventi imprevisti.

Approccio alla soluzione:

• Distribuire Key Vault dedicati per la segmentazione logica: Creare un Key Vault per ogni ambiente e un'unità aziendale con una convenzione di denominazione kv-{businessunit}-{environment}-{region} (ad esempio, kv-finance-prod-eastus2, kv-finance-dev-eastus2), distribuire in gruppi di risorse separati per ogni ambiente per applicare l'isolamento (un service principal di sviluppo compromesso non può accedere alle chiavi di produzione).
• Configurare il controllo degli accessi in base al ruolo per l'accesso con privilegi minimi: Per gli insiemi di credenziali delle chiavi non di produzione (sviluppo/staging) assegnare Utente segreti Key Vault (sola lettura) ai gruppi di sicurezza per sviluppatori. Gli sviluppatori possono leggere i segreti in fase di sviluppo/staging ma non hanno nessun accesso agli insiemi di credenziali delle chiavi di produzione; per gli insiemi di credenziali delle chiavi di produzione assegnare Utente segreti Key Vault alle entità servizio CI/CD (Azure DevOps identità gestite dalla pipeline), limitare l'ambito a specifici segreti denominati, senza accesso interattivo degli sviluppatori alle chiavi di produzione.
• Migliorare la sicurezza della rete con collegamento privato di Azure: Distribuire endpoint privati per Key Vault (selezionare la rete virtuale (VNet) e la subnet, creare la zona DNS privata privatelink.vaultcore.azure.net e collegarla alla rete virtuale), configurare il firewall di Key Vault (disabilitare l'accesso pubblico rendendo Key Vault accessibile solo tramite endpoint privati; se l'accesso pubblico è necessario per CI/CD, consentire l'accesso solo da reti selezionate con subnet della rete virtuale Azure approvate e intervalli di indirizzi IP degli agenti CI/CD approvati).
• Enable Microsoft Defender per Key Vault: Abilitare Microsoft Defender per Key Vault a livello di sottoscrizione, Defender monitora le anomalie, tra cui accesso geografico insolito, enumerazione sospetta (operazioni di elenco rapide che indicano la ricognizione), operazioni amministrative anomale (eliminazioni di segreti in blocco).
• Integrate con Microsoft Sentinel per risposta automatica: Aggiungere connettore dati Microsoft Defender per il cloud a Sentinel, creare regole di Analisi di Sentinel per l'accesso a livello di area insolito, forza bruta, operazioni amministrative sospette, configurare playbook di risposta automatizzati per disabilitare le identità sospette e inviare notifiche ai team di sicurezza.
• Stream log di diagnostica per Log Analytics: Abilitare il log diagnostico per Key Vault con AuditEvent (di tutte le operazioni chiave/segreto/certificato), AllMetrics (frequenza di utilizzo, latenza), inviati all'area di lavoro Log Analytics con 2 anni di conservazione, creare query KQL personalizzate per il rilevamento anomalie, incluso il rilevamento di potenziali attacchi brute force (superiori a 10 tentativi non autorizzati in 5 minuti), le operazioni di eliminazione temporanea sono disabilitate (indicatore di sabotaggio).
• Implementare l'accesso amministratore Just-In-Time con Azure AD PIM: Configurare le assegnazioni idonee per il ruolo di amministratore Key Vault (aggiungere i membri del team di sicurezza come idonei e non come assegnazioni permanenti, richiedere una giustificazione e l'MFA per l'attivazione, impostare la durata massima di attivazione a 8 ore, richiedere l'approvazione da parte dell'architetto senior della sicurezza), eseguire revisioni periodiche trimestrali per tutte le assegnazioni di ruolo amministratore per Key Vault; revocare l'accesso non necessario.

Risultato: I Key Vault dedicati per ogni ambiente applicano la segmentazione. Il controllo degli accessi in base al ruolo limita gli sviluppatori all'accesso di sola lettura negli ambienti di non produzione. collegamento privato elimina l'esposizione a Internet pubblico. Microsoft Defender rileva anomalie. I playbook di Sentinel disabilitano automaticamente le identità sospette. PIM consente l'accesso amministratore just-in-time, riducendo significativamente i diritti permanenti.

Livello di criticità

Indispensabile.

Mappatura dei controlli

• Controlli CIS v8.1: N/D
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-17
• PCI-DSS v4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR.AC-1, PR.DS-1
• ISO 27001:2022: A.8.3, A.8.24
• SOC 2: CC6.1, CC6.2