Condividi tramite

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

Attenzione

Eseguire il rollback di una chiave di crittografia usata con la chiave del cliente solo se richiesto dai criteri di sicurezza o conformità dell'organizzazione.

Non eliminare o disabilitare chiavi, incluse le versioni precedenti, associate o associate ai criteri di crittografia. Quando si esegue il rollback delle chiavi, alcuni contenuti potrebbero comunque essere crittografati con le chiavi precedenti.

Ad esempio:

  • Le cassette postali attive vengono crittografate di frequente, ma le cassette postali inattive, disconnesse o disabilitate potrebbero comunque usare chiavi meno recenti.
  • SharePoint mantiene il contenuto di backup per il ripristino e il ripristino, che potrebbe anche basarsi su chiavi meno recenti.

Informazioni sull'implementazione della chiave di disponibilità

Microsoft non fornisce ai clienti il controllo diretto sulla chiave di disponibilità. Ad esempio, è possibile eseguire solo il rollback delle chiavi gestite in Azure Key Vault.

Microsoft 365 esegue il rollback della chiave di disponibilità in base a una pianificazione interna. Non esiste alcun contratto di servizio (SLA) rivolto al cliente per queste rotazioni delle chiavi. Microsoft 365 usa il codice del servizio per ruotare automaticamente la chiave di disponibilità. In alcuni casi, gli amministratori Microsoft possono avviare il processo, ma la chiave viene implementata tramite meccanismi automatizzati che non consentono l'accesso diretto all'archivio chiavi.

Agli amministratori Microsoft non è stato effettuato il provisioning dell'accesso all'archivio segreto della chiave di disponibilità. Il processo in sequenza usa lo stesso meccanismo che genera la chiave durante il provisioning iniziale.

Per altre informazioni, vedere Informazioni sulla chiave di disponibilità.

Importante

Per Exchange, è possibile eseguire il rollback efficace della chiave di disponibilità creando un nuovo criterio di crittografia dei dati (DEP). Ogni nuovo DEP genera una chiave di disponibilità univoca.

Al contrario, le chiavi di disponibilità per La chiave del cliente in SharePoint e OneDrive vengono create a livello di foresta e condivise tra gli indirizzi DEP e i clienti. Queste chiavi vengono sottoposte a rollback solo in base a una pianificazione interna definita da Microsoft.

Per ridurre il rischio di non distribuire la chiave di disponibilità con ogni nuovo DEP, SharePoint, OneDrive e Teams, implementare la chiave intermedia del tenant ogni volta che si crea un nuovo DEP. Il TIK è la chiave di cui è stato eseguito il wrapping sia dalle chiavi radice del cliente che dalla chiave di disponibilità.

Informazioni sull'implementazione delle chiavi radice gestite dal cliente

Esistono due modi per eseguire il rollback delle chiavi radice gestite dal cliente:

  • Aggiornare la chiave esistente richiedendo una nuova versione e aggiornando i criteri di crittografia dei dati associati.Update the existing key by requesting a new version and refreshing the associated data encryption policy (DEP).
  • Creare e usare una chiave appena generata insieme a un nuovo DEP.

Le istruzioni per entrambi i metodi sono disponibili nella sezione seguente.

Importante

Microsoft consiglia di usare i ruoli con il minor numero di autorizzazioni. Ridurre al minimo il numero di utenti con il ruolo Amministratore globale consente di migliorare la sicurezza per l'organizzazione. Altre informazioni sui ruoli e le autorizzazioni di Microsoft Purview.

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 durante la creazione della chiave originale.

Dopo aver completato l'implementazione di una chiave associata a un criterio di crittografia dei dati (DEP), eseguire un cmdlet separato per aggiornare dep e assicurarsi che la chiave del cliente usi la nuova versione. Ripetere questo processo in ogni Key Vault di Azure (AKV).

Esempio:

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

  2. Eseguire il Add-AzKeyVaultKey cmdlet :

    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 esiste già una chiave denominata Contoso-CK-EX-NA-VaultA1-Key001 nell'insieme di credenziali Contoso-CK-EX-NA-VaultA1. Il cmdlet crea una nuova versione della chiave. Le versioni precedenti vengono mantenute nella cronologia delle versioni della chiave.

    È necessario accedere alla versione precedente per decrittografare qualsiasi contenuto ancora crittografato.

    Dopo aver completato l'implementazione di una chiave associata a un dep, eseguire un altro cmdlet per assicurarsi che La chiave del cliente inizi a usare la nuova versione. Le sezioni seguenti descrivono questi 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 Key Vault di Azure associate a un criterio di crittografia dei dati (DEP) usato in più carichi di lavoro, è necessario aggiornare dep per fare riferimento alla nuova versione della chiave. Questa azione non ruota la chiave di disponibilità.

    La DataEncryptionPolicyID proprietà rimane la stessa quando si aggiorna dep con una nuova versione della stessa chiave.

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

    1. Nel computer locale usare un account aziendale o dell'istituto di istruzione con le autorizzazioni appropriate e connettersi a Exchange PowerShell.

    2. Eseguire il Set-M365DataAtRestEncryptionPolicy cmdlet :

    Set-M365DataAtRestEncryptionPolicy -Identity <Policy> -Refresh
    Parametro Descrizione
    -Identity Nome univoco o GUID dei criteri di crittografia dei dati

    Aggiornare le chiavi per i provider di servizi di distribuzione exchange

    Quando si esegue il rollback di una delle chiavi Key Vault di Azure associate a un criterio di crittografia dei dati (DEP) usato con Exchange, è necessario aggiornare dep per fare riferimento alla nuova versione della chiave. Questo passaggio non ruota la chiave di disponibilità.

    La DataEncryptionPolicyID proprietà per la cassetta postale rimane la stessa quando si aggiornano i criteri con una nuova versione della stessa chiave.

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

    1. Nel computer locale usare un account aziendale o dell'istituto di istruzione con le autorizzazioni appropriate e connettersi a Exchange PowerShell.

    2. Eseguire il Set-DataEncryptionPolicy cmdlet :

    Set-DataEncryptionPolicy -Identity <Policy> -Refresh
    Parametro Descrizione
    -Identity Nome univoco o GUID dei criteri di crittografia dei dati

Usare una chiave appena generata per dep

Se si sceglie di usare le chiavi appena generate anziché aggiornare quelle esistenti, il processo di aggiornamento dei criteri di crittografia dei dati è diverso. Anziché aggiornare un criterio esistente, è necessario creare e assegnare un nuovo criterio di crittografia dei dati che faccia riferimento alla nuova chiave.

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

  2. Dopo aver aggiunto la chiave all'insieme di credenziali delle chiavi, creare un nuovo criterio di crittografia dei dati usando l'URI della chiave della chiave appena generata. Per istruzioni dettagliate, vedere Gestire la chiave del cliente per Microsoft 365.

Aggiornare le chiavi per SharePoint e OneDrive

SharePoint supporta il rollback di una sola chiave alla volta. Se si prevede di eseguire il rollback di entrambe le chiavi in un insieme di credenziali delle chiavi, attendere il completamento della prima operazione prima di iniziare il secondo. Per evitare conflitti, Microsoft consiglia di sconcertare le operazioni.

Quando si esegue il rollback di una delle chiavi Key Vault di Azure associate a un criterio di crittografia dei dati (DEP) usato con SharePoint e OneDrive, è necessario aggiornare dep per fare riferimento alla nuova chiave. Questo processo non ruota la chiave di disponibilità.

  1. Per eseguire il rollback di una chiave per SharePoint e OneDrive, eseguire il Update-SPODataEncryptionPolicy cmdlet :

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

    Questo cmdlet avvia l'operazione di roll delle chiavi, ma la modifica non ha effetto immediatamente.

  2. Per aggiornare un criterio di SharePoint e OneDrive usando le chiavi archiviate in un modulo di protezione hardware gestito, eseguire il comando seguente:

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

  3. Per controllare lo stato dell'operazione di roll delle chiavi, eseguire:

    Get-SPODataEncryptionPolicy <SPOAdminSiteUrl>
  • Last updated on