Informazioni sulle chiavi di disponibilità per Customer Key

La chiave di disponibilità è una chiave radice generata e sottoposta a provisioning automaticamente quando si creano criteri di crittografia dei dati. Microsoft 365 archivia e protegge la chiave di disponibilità. La chiave di disponibilità è funzionalmente simile alle due chiavi radice disponibili per Customer Key. La chiave di disponibilità esegue il wrapping delle chiavi di un livello inferiore nella gerarchia delle chiavi. A differenza delle chiavi fornite e gestite in Azure Key Vault, non è possibile accedere direttamente alla chiave di disponibilità. I servizi automatizzati di Microsoft 365 gestiscono la chiave di disponibilità a livello di codice. Questi servizi avviano operazioni automatizzate che non implicano mai l'accesso diretto alla chiave di disponibilità.

Lo scopo principale della chiave di disponibilità è fornire la funzionalità di ripristino dalla perdita imprevista delle chiavi radice gestite. La perdita potrebbe essere il risultato di una cattiva gestione o di un'azione dannosa. Se si perde il controllo delle chiavi radice, contattare supporto tecnico Microsoft per ottenere assistenza per il processo di ripristino usando la chiave di disponibilità. Usare la chiave di disponibilità per eseguire la migrazione a un nuovo criterio di crittografia dei dati con le nuove chiavi radice di cui si esegue il provisioning.

L'archiviazione e il controllo della chiave di disponibilità sono deliberatamente diversi dalle chiavi di Key Vault di Azure per tre motivi:

  • La chiave di disponibilità fornisce una funzionalità di ripristino"break-glass" se il controllo su entrambe le chiavi di Azure Key Vault viene perso.
  • La separazione dei controlli logici e delle posizioni di archiviazione sicure offre una difesa approfondita e protegge dalla perdita di tutte le chiavi e dei dati da un singolo attacco o punto di errore.
  • La chiave di disponibilità offre una funzionalità a disponibilità elevata se i servizi di Microsoft 365 non riescono a raggiungere le chiavi ospitate in Azure Key Vault a causa di errori temporanei. Questa regola si applica solo alla crittografia del servizio Exchange Online. I file di Microsoft SharePoint, Microsoft OneDrive e Teams non usano mai la chiave di disponibilità a meno che non si invii esplicitamente a Microsoft l'avvio del processo di ripristino.

La condivisione della responsabilità di proteggere i dati usando varie protezioni e processi per la gestione delle chiavi riduce in definitiva il rischio che tutte le chiavi (e quindi i dati) vengano perse o distrutte definitivamente. Microsoft fornisce all'utente l'autorità esclusiva per la disabilitazione o la distruzione della chiave di disponibilità quando si lascia il servizio. Per impostazione predefinita, nessuno in Microsoft ha accesso alla chiave di disponibilità: è accessibile solo dal codice del servizio Microsoft 365.

Per altre informazioni sulla protezione delle chiavi, visitare il Centro protezione Microsoft.

Consiglio

Se non si è un cliente E5, usare la versione di valutazione delle soluzioni Microsoft Purview di 90 giorni per esplorare in che modo funzionalità aggiuntive di Purview possono aiutare l'organizzazione a gestire le esigenze di sicurezza e conformità dei dati. Iniziare ora dall'hub delle versioni di valutazione Portale di conformità di Microsoft Purview. Informazioni dettagliate sull'iscrizione e le condizioni di valutazione.

Windows 365 supporto per Microsoft Purview Customer Key è disponibile in anteprima pubblica ed è soggetto a modifiche.

Usi della chiave di disponibilità

La chiave di disponibilità offre funzionalità di ripristino per scenari in cui un malefattore esterno o un insider dannoso ruba il controllo dell'insieme di credenziali delle chiavi o quando una cattiva gestione accidentale comporta la perdita delle chiavi radice. Questa funzionalità di ripristino si applica a tutti i servizi di Microsoft 365 compatibili con la chiave del cliente. I singoli servizi usano la chiave di disponibilità in modo diverso. Microsoft 365 usa la chiave di disponibilità solo nei modi descritti nelle sezioni successive.

Exchange Online

Oltre alla funzionalità di ripristino, Exchange Online usa la chiave di disponibilità per garantire la disponibilità dei dati durante i problemi operativi temporanei o intermittenti correlati al servizio che accede alle chiavi radice. Quando il servizio non riesce a raggiungere una delle chiavi del cliente in Azure Key Vault a causa di errori temporanei, il servizio usa automaticamente la chiave di disponibilità. Il servizio non passa MAI direttamente alla chiave di disponibilità.

I sistemi automatizzati in Exchange Online potrebbero usare la chiave di disponibilità durante gli errori temporanei. L'uso della chiave di disponibilità supporta servizi back-end automatizzati, ad esempio antivirus, individuazione elettronica, Prevenzione della perdita dei dati Microsoft Purview, spostamenti delle cassette postali e indicizzazione dei dati.

I file di SharePoint, OneDrive e Teams usano

Per i file di SharePoint, OneDrive e Teams, la chiave di disponibilità non viene MAI usata all'esterno della funzionalità di ripristino. È necessario indicare in modo esplicito a Microsoft di usare la chiave di disponibilità durante uno scenario di ripristino. Le operazioni di servizio automatizzate si basano esclusivamente sulle chiavi del cliente nell'insieme di credenziali delle chiavi di Azure. Per informazioni approfondite sul funzionamento della gerarchia delle chiavi per questi servizi, vedere Come i file di SharePoint, OneDrive e Teams usano la chiave di disponibilità.

Sicurezza della chiave di disponibilità

Microsoft condivide con l'utente la responsabilità della protezione dei dati creando un'istanza della chiave di disponibilità e adottando misure estese per proteggerla. Microsoft non espone ai clienti il controllo diretto della chiave di disponibilità. Ad esempio, è possibile eseguire il rollback (rotazione) solo delle chiavi di cui si è proprietari in Azure Key Vault. Per altre informazioni, vedere Roll or rotate a Customer Key o a availability key(Roll or rotate a Customer Key o a availability key).

Archivi segreti chiave di disponibilità

Microsoft protegge le chiavi di disponibilità negli archivi segreti interni controllati dall'accesso, ad esempio il Key Vault di Azure rivolto ai clienti. Implementiamo controlli di accesso per impedire agli amministratori Microsoft di accedere direttamente ai segreti contenuti in . Le operazioni dell'archivio segreto, inclusa la rotazione e l'eliminazione delle chiavi, vengono eseguite tramite comandi automatizzati che non implicano mai l'accesso diretto alla chiave di disponibilità. Le operazioni di gestione dell'archivio segreto sono limitate a tecnici specifici e richiedono l'escalation dei privilegi tramite uno strumento interno, Lockbox. L'escalation dei privilegi richiede l'approvazione e la giustificazione del manager prima di essere concessa. Lockbox assicura che l'accesso sia associato al tempo con revoca automatica dell'accesso alla scadenza del tempo o alla disconnessione del tecnico.

Exchange Online chiavi di disponibilità vengono archiviate in un archivio segreto di Active Directory Exchange Online. Le chiavi di disponibilità vengono archiviate in modo sicuro all'interno di contenitori specifici del tenant all'interno del controller Dominio di Active Directory. Questo percorso di archiviazione sicuro è separato e isolato dall'archivio segreto dei file di SharePoint, OneDrive e Teams.

Le chiavi di disponibilità dei file di SharePoint, OneDrive e Teams vengono archiviate in un archivio segreto interno gestito dal team del servizio. Questo servizio di archiviazione segreti protetto include server front-end con endpoint dell'applicazione e un database SQL come back-end. Le chiavi di disponibilità vengono archiviate nel database SQL. Le chiavi di crittografia dell'archivio segreto eseguono il wrapping (crittografia) delle chiavi di disponibilità. Le chiavi dell'archivio segreto usano una combinazione di AES-256 e HMAC per crittografare la chiave di disponibilità inattivi. Le chiavi di crittografia dell'archivio segreto vengono archiviate in un componente isolato logicamente dello stesso database SQL e vengono ulteriormente crittografate con le chiavi RSA-2048 contenute nei certificati gestiti dall'autorità di certificazione (CA) Microsoft. Questi certificati vengono archiviati nei server front-end dell'archivio segreto che eseguono operazioni sul database.

Difesa approfondita

Microsoft usa una strategia di difesa avanzata per evitare che gli attori malintenzionati influivano sulla riservatezza, l'integrità o la disponibilità dei dati dei clienti archiviati nel cloud Microsoft. I controlli specifici di prevenzione e detective vengono implementati per proteggere l'archivio segreto e la chiave di disponibilità come parte della strategia di sicurezza generale.

Microsoft 365 è stato creato per impedire l'uso improprio della chiave di disponibilità. Il livello applicazione è l'unico metodo tramite il quale le chiavi, inclusa la chiave di disponibilità, possono essere usate per crittografare e decrittografare i dati. Solo il codice del servizio Microsoft 365 ha la possibilità di interpretare e attraversare la gerarchia delle chiavi per le attività di crittografia e decrittografia. L'isolamento logico esiste tra i percorsi di archiviazione delle chiavi cliente, delle chiavi di disponibilità, di altre chiavi gerarchiche e dei dati dei clienti. Questo isolamento riduce il rischio di esposizione dei dati nel caso in cui una o più posizioni vengano compromesse. Ogni livello della gerarchia dispone di funzionalità predefinite di rilevamento delle intrusioni 24x7 per proteggere i dati e i segreti archiviati.

I controlli di accesso vengono implementati per impedire l'accesso non autorizzato ai sistemi interni, inclusi gli archivi segreti delle chiavi di disponibilità. I tecnici Microsoft non hanno accesso diretto agli archivi segreti delle chiavi di disponibilità. Per altre informazioni sui controlli di accesso, vedere Controlli di accesso amministrativi in Microsoft 365.

I controlli tecnici impediscono al personale Microsoft di accedere agli account di servizio con privilegi elevati, che altrimenti potrebbero essere usati dagli utenti malintenzionati per rappresentare i servizi Microsoft. Ad esempio, questi controlli impediscono l'accesso interattivo.

I controlli di monitoraggio e registrazione della sicurezza sono un'altra protezione avanzata implementata che attenua i rischi per i servizi Microsoft e i dati. I team dei servizi Microsoft distribuiscono soluzioni di monitoraggio attivo che generano avvisi e log di controllo. Tutti i team del servizio caricano i log in un repository centrale in cui i log vengono aggregati ed elaborati. Gli strumenti interni esaminano automaticamente i record per verificare che i servizi funzionino in uno stato ottimale, resiliente e sicuro. L'attività insolita è contrassegnata per un'ulteriore revisione.

Qualsiasi evento di log che indica una potenziale violazione dei criteri di sicurezza Microsoft viene immediatamente portato all'attenzione dei team di sicurezza Microsoft. La sicurezza di Microsoft 365 ha configurato gli avvisi per rilevare il tentativo di accesso agli archivi segreti delle chiavi di disponibilità. Gli avvisi vengono generati anche se il personale Microsoft tenta l'accesso interattivo agli account del servizio, che è vietato e protetto dai controlli di accesso. La sicurezza di Microsoft 365 rileva e segnala anche le deviazioni del servizio Microsoft 365 dalle normali operazioni di base. I malfattori che tentano di usare in modo improprio i servizi di Microsoft 365 attivano avvisi che comportano lo sfratto del trasgressore dall'ambiente cloud Microsoft.

Usare la chiave di disponibilità per recuperare da una perdita di chiave

Se si perde il controllo delle chiavi del cliente, la chiave di disponibilità consente di recuperare e crittografare nuovamente i dati.

Procedura di ripristino per Exchange Online

Se si perde il controllo delle chiavi cliente, la chiave di disponibilità offre la possibilità di recuperare i dati e riportare online le risorse di Microsoft 365 interessate. La chiave di disponibilità continua a proteggere i dati durante il ripristino. A livello generale, per eseguire il ripristino completo dalla perdita di chiavi, creare un nuovo DEP e spostare le risorse interessate nel nuovo criterio.

Per crittografare i dati con le nuove chiavi del cliente, creare nuove chiavi in Azure Key Vault, creare una nuova protezione protezione dati usando le nuove chiavi del cliente, quindi assegnare la nuova protezione protezione dati alle cassette postali attualmente crittografate con la dep precedente per cui le chiavi vengono perse o compromesse.

Questo processo di crittografia può richiedere fino a 72 ore ed è la durata standard quando si modifica un DEP.

Procedura di ripristino per i file di SharePoint, OneDrive e Teams

Per i file di SharePoint, OneDrive e Teams, la chiave di disponibilità non viene MAI usata all'esterno della funzionalità di ripristino. È necessario indicare in modo esplicito a Microsoft di avviare l'uso della chiave di disponibilità durante uno scenario di ripristino. Per avviare il processo di ripristino, contattare Microsoft per attivare la chiave di disponibilità. Una volta attivata, la chiave di disponibilità viene usata automaticamente per decrittografare i dati consentendo di crittografare i dati con un DEP appena creato associato alle nuove chiavi del cliente.

Questa operazione è proporzionale al numero di siti nell'organizzazione. Dopo aver chiamato Microsoft per usare la chiave di disponibilità, si dovrebbe essere completamente online entro circa quattro ore.

Come Exchange Online usare la chiave di disponibilità

Quando si crea un DEP con chiave del cliente, Microsoft 365 genera una chiave dei criteri di crittografia dei dati associata a tale DEP. Il servizio crittografa la chiave DEP tre volte: una volta con ognuna delle chiavi del cliente e una volta con la chiave di disponibilità. Vengono archiviate solo le versioni crittografate della chiave DEP e una chiave DEP può essere decrittografata solo con le chiavi del cliente o la chiave di disponibilità. La chiave DEP viene quindi usata per crittografare le chiavi delle cassette postali, che crittografa le singole cassette postali.

Microsoft 365 segue questo processo per decrittografare e fornire dati quando i clienti usano il servizio:

  1. Decrittografare la chiave DEP usando la chiave del cliente.

  2. Usare la chiave DEP decrittografata per decrittografare una chiave della cassetta postale.

  3. Usare la chiave della cassetta postale decrittografata per decrittografare la cassetta postale stessa, consentendo di accedere ai dati all'interno della cassetta postale.

Come i file di SharePoint, OneDrive e Teams usano la chiave di disponibilità

L'architettura e l'implementazione di SharePoint e OneDrive per la chiave del cliente e la chiave di disponibilità sono diverse da Exchange Online.

Quando un'organizzazione passa a chiavi gestite dal cliente, Microsoft 365 crea una chiave intermedia (TIK) specifica dell'organizzazione. Microsoft 365 crittografa il TIK due volte, una volta con ognuna delle chiavi del cliente, e archivia le due versioni crittografate del TIK. Vengono archiviate solo le versioni crittografate del TIK e un TIK può essere decrittografato solo con le chiavi del cliente. Il TIK viene quindi usato per crittografare le chiavi del sito, che vengono quindi usate per crittografare le chiavi BLOB (dette anche chiavi in blocchi di file). A seconda delle dimensioni del file, il servizio potrebbe suddividere un file in più blocchi di file ognuno con una chiave univoca. I BLOB stessi (blocchi di file) vengono crittografati con le chiavi BLOB e archiviati nel servizio di archiviazione BLOB di Microsoft Azure.

Microsoft 365 segue questo processo per decrittografare e fornire i file dei clienti quando i clienti usano il servizio:

  1. Decrittografare il TIK usando la chiave del cliente.

  2. Usare il TIK decrittografato per decrittografare una chiave del sito.

  3. Usare la chiave del sito decrittografata per decrittografare una chiave BLOB.

  4. Usare la chiave BLOB decrittografata per decrittografare il BLOB.

Microsoft 365 decrittografa un TIK emettendo due richieste di decrittografia ad Azure Key Vault con un leggero offset. Il primo a completare fornisce il risultato, annullando l'altra richiesta.

Se si perde l'accesso alle chiavi, Microsoft 365 crittografa anche il TIK con una chiave di disponibilità e archivia queste informazioni insieme ai TIK crittografati con ogni chiave del cliente. Il TIK crittografato con la chiave di disponibilità viene usato solo quando si chiama Microsoft per integrare il percorso di ripristino quando si perde l'accesso alle chiavi, in modo dannoso o accidentale.

Per motivi di disponibilità e scalabilità, i TIK decrittografati vengono memorizzati nella cache in una cache di memoria limitata nel tempo. Due ore prima della scadenza di una cache TIK, Microsoft 365 tenta di decrittografare ogni TIK. La decrittografia dei TIK estende la durata della cache. Se la decrittografia TIK non riesce per un periodo di tempo significativo, Microsoft 365 genera un avviso per notificare la progettazione prima della scadenza della cache. Microsoft 365 avvia l'operazione di ripristino solo se si chiama, il che comporta la decrittografia del TIK con la chiave di disponibilità archiviata nell'archivio segreto di Microsoft e l'onboarding del tenant usando il TIK decrittografato e un nuovo set di chiavi di Azure Key Vault fornite dal cliente.

A partire da oggi, la chiave del cliente è coinvolta nella catena di crittografia e decrittografia dei dati dei file di SharePoint archiviati nell'archivio BLOB di Azure, ma non negli elementi dell'elenco o nei metadati di SharePoint archiviati nel database SQL. Microsoft 365 non usa la chiave di disponibilità per i file di Exchange Online, SharePoint, OneDrive e Teams diversi dal caso descritto, avviato dal cliente. L'accesso umano ai dati dei clienti è protetto da Customer Lockbox.

Trigger della chiave di disponibilità

Microsoft 365 attiva la chiave di disponibilità solo in circostanze specifiche. Queste circostanze differiscono in base al servizio.

Trigger per Exchange Online

  1. Microsoft 365 legge il DEP a cui è assegnata la cassetta postale per determinare la posizione delle due chiavi del cliente in Azure Key Vault.

  2. Microsoft 365 sceglie in modo casuale una delle due chiavi del cliente dal DEP e invia una richiesta ad Azure Key Vault di annullare il wrapping della chiave DEP usando la chiave del cliente.

  3. Se la richiesta di annullare il wrapping della chiave DEP usando la chiave del cliente ha esito negativo, Microsoft 365 invia una seconda richiesta ad Azure Key Vault, questa volta richiedendo all'utente di usare la chiave del cliente alternativa (seconda).

  4. Se la seconda richiesta di annullare il wrapping della chiave DEP usando la chiave del cliente ha esito negativo, Microsoft 365 esamina i risultati di entrambe le richieste.

    • Se l'esame determina che le richieste non sono riuscite a restituire un ERRORE di sistema:

      • Microsoft 365 attiva la chiave di disponibilità per decrittografare la chiave DEP.

      • Microsoft 365 usa quindi la chiave DEP per decrittografare la chiave della cassetta postale e completare la richiesta dell'utente.

      • In questo caso, Azure Key Vault non è in grado di rispondere o non è raggiungibile a causa di un ERRORE temporaneo.

    • Se l'esame determina che le richieste non sono riuscite a restituire ACCESS DENIED:

      • Questo ritorno significa che è stata eseguita un'azione intenzionale, involontaria o dannosa per rendere non disponibili le chiavi del cliente, ad esempio durante il processo di eliminazione dei dati come parte dell'uscita dal servizio.

      • In questo caso, la chiave di disponibilità è solo per le azioni di sistema e non per le azioni dell'utente, la richiesta utente ha esito negativo e l'utente riceve un messaggio di errore.

Importante

Il codice del servizio Microsoft 365 ha sempre un token di accesso valido per il ragionamento sui dati dei clienti per fornire servizi cloud con aggiunta di valore. Pertanto, fino a quando la chiave di disponibilità non è stata eliminata, può essere usata come fallback per le azioni avviate da o interne a Exchange Online come la creazione dell'indice di ricerca o lo spostamento di cassette postali. Questo vale sia per le richieste temporanee ERRORS che ACCESS DENIED ad Azure Key Vault.

Trigger per i file di SharePoint, OneDrive e Teams

Per i file di SharePoint, OneDrive e Teams, la chiave di disponibilità non viene MAI usata all'esterno della funzionalità di ripristino e i clienti devono indicare esplicitamente a Microsoft di avviare l'uso della chiave di disponibilità durante uno scenario di ripristino.

Log di controllo e chiave di disponibilità

I sistemi automatizzati in Microsoft 365 elaborano tutti i dati durante il flusso attraverso il sistema per fornire servizi cloud, ad esempio antivirus, e-discovery, prevenzione della perdita dei dati e indicizzazione dei dati. Microsoft 365 non genera log visibili ai clienti per questa attività. Inoltre, il personale Microsoft non accede ai dati come parte di queste normali operazioni di sistema.

Exchange Online registrazione delle chiavi di disponibilità

Quando Exchange Online accede alla chiave di disponibilità per fornire il servizio, Microsoft 365 pubblica i log visibili ai clienti accessibili dal portale sicurezza e conformità. Viene generato un record del log di controllo per l'operazione della chiave di disponibilità ogni volta che il servizio usa la chiave di disponibilità. Un nuovo tipo di record denominato "Customer Key Service Encryption" con tipo di attività "Fallback alla chiave di disponibilità" consente agli amministratori di filtrare i risultati della ricerca del log di controllo unificato per visualizzare i record delle chiavi di disponibilità.

I record di log includono attributi come data, ora, attività, ID organizzazione e ID criterio di crittografia dei dati. Il record è disponibile come parte dei log di controllo unificato ed è accessibile dalla scheda Search log di controllo Portale di conformità di Microsoft Purview.

Ricerca log di controllo per gli eventi chiave di disponibilità

Exchange Online record di chiave di disponibilità usano lo schema comune dell'attività di gestione di Microsoft 365 con parametri personalizzati aggiunti: ID criterio, ID versione chiave ambito e ID richiesta.

Parametri personalizzati della chiave di disponibilità

Registrazione delle chiavi di disponibilità dei file di SharePoint, OneDrive e Teams

La registrazione delle chiavi di disponibilità non è ancora disponibile per questi servizi. Per i file di SharePoint, OneDrive e Teams, Microsoft attiva la chiave di disponibilità solo a scopo di ripristino quando richiesto dall'utente. Di conseguenza, si conosce già ogni evento in cui viene usata la chiave di disponibilità per questi servizi.

Chiave di disponibilità nella gerarchia chiave del cliente

Microsoft 365 usa la chiave di disponibilità per eseguire il wrapping del livello di chiavi inferiore nella gerarchia delle chiavi stabilita per la crittografia del servizio customer key. Esistono gerarchie di chiavi diverse tra i servizi. Gli algoritmi di chiave differiscono anche tra le chiavi di disponibilità e altre chiavi nella gerarchia di ogni servizio applicabile. Gli algoritmi della chiave di disponibilità usati dai diversi servizi sono i seguenti:

  • Le chiavi di disponibilità Exchange Online usano AES-256.

  • Le chiavi di disponibilità dei file di SharePoint, OneDrive e Teams usano RSA-2048.

Crittografie di crittografia usate per crittografare le chiavi per Exchange Online

Crittografie di crittografia per Exchange Online nella chiave del cliente

Crittografie usate per crittografare le chiavi per SharePoint

Crittografia delle crittografie per SharePoint nella chiave del cliente