Condividi tramite

Implementare o distribuire una Customer Key o una chiave di disponibilità

  • Articolo

Attenzione

Eseguire il rollback di una chiave di crittografia usata con la chiave del cliente solo quando i requisiti di sicurezza o conformità stabiliscono che è necessario eseguire il rollback della chiave. Non eliminare o disabilitare le chiavi associate o associate ai criteri, incluse le versioni precedenti delle chiavi usate. Quando si esegue il rollback delle chiavi, il contenuto viene crittografato con le chiavi precedenti. Ad esempio, mentre le cassette postali attive vengono crittografate di frequente, le cassette postali inattive, disconnesse e disabilitate possono comunque essere crittografate con le chiavi precedenti. Microsoft SharePoint esegue il backup del contenuto a scopo di ripristino e ripristino, quindi potrebbe essere ancora archiviato il contenuto usando chiavi meno recenti.

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.

Informazioni sull'implementazione della chiave di disponibilità

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. Microsoft 365 esegue il rollback delle chiavi di disponibilità in base a una pianificazione definita internamente. Non esiste alcun contratto di servizio (SLA) rivolto al cliente per questi lanci di chiavi. Microsoft 365 ruota la chiave di disponibilità usando il codice del servizio Microsoft 365 in un processo automatizzato. Gli amministratori Microsoft possono avviare il processo roll. Il rollback della chiave viene eseguito usando meccanismi automatizzati senza accesso diretto all'archivio chiavi. Non viene effettuato il provisioning dell'accesso all'archivio segreto della chiave di disponibilità agli amministratori Microsoft. Il rollback dei tasti di disponibilità applica lo stesso meccanismo usato per generare inizialmente la chiave. Per altre informazioni sulla chiave di disponibilità, vedere Informazioni sulla chiave di disponibilità.

Importante

Le chiavi di disponibilità di Exchange possono essere implementate in modo efficace dai clienti che creano un nuovo DEP, poiché viene generata una chiave di disponibilità univoca per ogni DEP creato. Le chiavi di disponibilità per La chiave del cliente per SharePoint e OneDrive esistono a livello di foresta e vengono condivise tra gli indirizzi DEP e i clienti, il che significa che l'implementazione avviene solo in base a una pianificazione definita internamente da Microsoft. Per ridurre il rischio di non eseguire il rollback della chiave di disponibilità ogni volta che viene creato un nuovo DEP, SharePoint, OneDrive e Teams eseguono il rollback della chiave intermedia del tenant (TIK), la chiave di cui viene eseguito il wrapping dalle chiavi radice del cliente e dalla chiave di disponibilità, ogni volta che viene creato un nuovo DEP.

Informazioni sull'implementazione delle chiavi radice gestite dal cliente

Esistono due modi per eseguire il rollback delle chiavi radice gestite dal cliente: aggiornare le chiavi esistenti richiedendo una nuova versione della chiave e aggiornando il DEP oppure creando e usando una chiave appena generata e DEP. Le istruzioni per ogni metodo di rollback delle chiavi sono disponibili nella sezione seguente.

Richiedere una nuova versione di ogni chiave radice esistente di cui si vuole eseguire il rollback

Per richiedere una nuova versione di una chiave esistente, usare lo stesso cmdlet , Add-AzKeyVaultKey, con la stessa sintassi e lo stesso nome di chiave usati originariamente per creare la chiave. Dopo aver completato l'implementazione di qualsiasi chiave associata a un criterio di crittografia dei dati (DEP), è necessario eseguire un altro cmdlet per aggiornare la dep esistente per assicurarsi che la chiave del cliente usi la nuova chiave. Eseguire questo passaggio in ogni azure Key Vault (AKV).

Ad esempio:

  1. Accedere alla sottoscrizione di Azure con Azure PowerShell. Per istruzioni, vedere Accedere con Azure PowerShell.

  2. Eseguire il cmdlet Add-AzKeyVaultKey come illustrato nell'esempio seguente:

    Add-AzKeyVaultKey -VaultName Contoso-CK-EX-NA-VaultA1 -Name Contoso-CK-EX-NA-VaultA1-Key001 -Destination HSM -KeyOps @('wrapKey','unwrapKey') -NotBefore (Get-Date -Date "12/27/2016 12:01 AM")

    In questo esempio, poiché una chiave denominata Contoso-CK-EX-NA-VaultA1-Key001 esiste nell'insieme di credenziali Contoso-CK-EX-NA-VaultA1 , il cmdlet crea una nuova versione della chiave. Questa operazione mantiene le versioni delle chiavi precedenti nella cronologia delle versioni per la chiave. È necessaria la versione della chiave precedente per decrittografare i dati che crittografa ancora. Dopo aver completato l'implementazione di qualsiasi chiave associata a un DEP, eseguire un cmdlet aggiuntivo per assicurarsi che Customer Key inizi a usare la nuova chiave. Le sezioni seguenti descrivono i cmdlet in modo più dettagliato.

    Aggiornare le chiavi per i criteri DIP con più carichi di lavoro

    Quando si esegue il rollback di una delle chiavi di Key Vault di Azure associate a un dep usato con più carichi di lavoro, è necessario aggiornare dep in modo che punti alla nuova chiave. Questo processo non ruota la chiave di disponibilità. La proprietà DataEncryptionPolicyID non cambia quando viene aggiornata con una nuova versione della stessa chiave.

    Per indicare a Customer Key di usare la nuova chiave per crittografare più carichi di lavoro, seguire questa procedura:

    1. Nel computer locale, usando un account aziendale o dell'istituto di istruzione con autorizzazioni di amministratore globale o amministratore della conformità nell'organizzazione, connettersi a Exchange PowerShell.

    2. Eseguire il cmdlet Set-M365DataAtRestEncryptionPolicy:

      Set-M365DataAtRestEncryptionPolicy -Identity <Policy>  -Refresh

      Dove Criterio è il nome o l'ID univoco del criterio.

    Aggiornare le chiavi per i provider di servizi di distribuzione exchange

    Quando si esegue il rollback di una delle chiavi di Key Vault di Azure associate a un DEP usato con Exchange, è necessario aggiornare dep in modo che punti alla nuova chiave. Questa azione non ruota la chiave di disponibilità. La proprietà DataEncryptionPolicyID per la cassetta postale non cambia quando viene aggiornata con una nuova versione della stessa chiave.

    Per indicare a Customer Key di usare la nuova chiave per crittografare le cassette postali, seguire questa procedura:

    1. Nel computer locale, usando un account aziendale o dell'istituto di istruzione con autorizzazioni di amministratore globale o amministratore della conformità nell'organizzazione, connettersi a Exchange PowerShell.

    2. Eseguire il cmdlet Set-DataEncryptionPolicy:

        Set-DataEncryptionPolicy -Identity <Policy> -Refresh

      Dove Criterio è il nome o l'ID univoco del criterio.

Uso di una chiave appena generata per dep

Quando si sceglie di usare le chiavi appena generate invece di aggiornare quelle esistenti, il processo per l'aggiornamento dei criteri di crittografia dei dati è diverso. Anziché aggiornare un criterio esistente, è necessario creare e assegnare un nuovo criterio di crittografia dei dati personalizzato per la nuova chiave.

  1. Per creare una nuova chiave e aggiungerla all'insieme di credenziali delle chiavi, seguire le istruzioni disponibili in Aggiungere una chiave a ogni insieme di credenziali delle chiavi creando o importando una chiave.

  2. Una volta aggiunto all'insieme di credenziali delle chiavi, è necessario creare un nuovo criterio di crittografia dei dati con l'URI della chiave della chiave appena creata. Le istruzioni per la creazione e l'assegnazione dei criteri di crittografia dei dati sono disponibili in Gestire la chiave del cliente per Microsoft 365.

Aggiornare le chiavi per SharePoint e OneDrive

SharePoint consente solo di eseguire il rolling di una chiave alla volta. Se si desidera eseguire il rollback di entrambe le chiavi in un insieme di credenziali delle chiavi, attendere il completamento della prima operazione. Microsoft consiglia di sfalsare le operazioni per evitare questo problema. Quando si esegue il rollback di una delle chiavi di Key Vault di Azure associate a un dep usato con SharePoint e OneDrive, è necessario aggiornare il dep in modo che punti alla nuova chiave. Questa azione non ruota la chiave di disponibilità.

  1. Eseguire il cmdlet Update-SPODataEncryptionPolicy come indicato di seguito:

    Update-SPODataEncryptionPolicy  <SPOAdminSiteUrl> -KeyVaultName <ReplacementKeyVaultName> -KeyName <ReplacementKeyName> -KeyVersion <ReplacementKeyVersion> -KeyType <Primary | Secondary>

    Mentre questo cmdlet avvia l'operazione di roll delle chiavi per SharePoint e OneDrive, l'azione non viene completata immediatamente.

  2. Per visualizzare lo stato dell'operazione di roll delle chiavi, eseguire il cmdlet Get-SPODataEncryptionPolicy come indicato di seguito:

    Get-SPODataEncryptionPolicy <SPOAdminSiteUrl>