Con Customer Key si controllano le chiavi di crittografia dell'organizzazione e quindi si configura Microsoft 365 per usarle per crittografare i dati inattivi nei data center Microsoft. In altre parole, Customer Key consente di aggiungere un livello di crittografia che appartiene all'utente, con le chiavi.
Configurare Azure prima di usare La chiave del cliente. Questo articolo descrive i passaggi da seguire per creare e configurare le risorse di Azure necessarie e quindi fornisce i passaggi per la configurazione della chiave del cliente. Dopo aver configurato Azure, si determinano i criteri e quindi le chiavi da assegnare per crittografare i dati in vari carichi di lavoro di Microsoft 365 nell'organizzazione. Per altre informazioni sulla chiave del cliente o per una panoramica generale, vedere Panoramica della chiave del cliente.
Importante
È consigliabile seguire le procedure consigliate in questo articolo. Questi sono indicati come TIP e IMPORTANT. Customer Key consente di controllare le chiavi di crittografia radice il cui ambito può essere grande quanto l'intera organizzazione. Ciò significa che gli errori commessi con queste chiavi possono avere un impatto generale e possono causare interruzioni del servizio o perdita irrevocabile dei dati.
Il supporto di Windows 365 per Microsoft Purview Customer Key è disponibile in anteprima pubblica ed è soggetto a modifiche.
Prima di configurare la chiave del cliente
Prima di iniziare, assicurarsi di avere le sottoscrizioni di Azure appropriate e le licenze di Microsoft 365, Office 365 e Windows 365 per l'organizzazione. È necessario usare sottoscrizioni di Azure a pagamento. Le sottoscrizioni disponibili tramite il supporto gratuito, la versione di valutazione, le sponsorizzazioni, le sottoscrizioni MSDN e le sottoscrizioni nel supporto legacy non sono idonee.
Importante
Licenze valide di Microsoft 365 e Office 365 che offrono la chiave del cliente di Microsoft 365:
Office 365 E5
Microsoft 365 E5
Conformità Microsoft 365 E5
SKU di governance di Microsoft 365 E5 Information Protection &
Sicurezza e conformità di Microsoft 365 per FLW
Le licenze esistenti di Office 365 Advanced Compliance sono ancora supportate.
Per comprendere i concetti e le procedure in questo articolo, vedere la documentazione di Azure Key Vault . Acquisire familiarità con i termini usati in Azure, ad esempio il tenant di Microsoft Entra.
Se è necessario più supporto oltre alla documentazione, contattare il supporto tecnico Microsoft. Per fornire commenti e suggerimenti sulla chiave del cliente, inclusa la documentazione, inviare idee, suggerimenti e prospettive alla community di Microsoft 365
Panoramica dei passaggi per configurare la chiave del cliente
Per configurare la chiave del cliente, completare queste attività nell'ordine elencato. Il resto di questo articolo fornisce istruzioni dettagliate per ogni attività o collegamenti ad altre informazioni per ogni passaggio del processo.
Completare i prerequisiti seguenti connettendosi in remoto ad Azure PowerShell. Per ottenere risultati ottimali, usare la versione 4.4.0 o successiva di Azure PowerShell:
Completare le attività in Azure Key Vault per la chiave del cliente
Completare queste attività in Azure Key Vault. È necessario completare questi passaggi per tutti i tipi di criteri di crittografia dei dati usati con la chiave del cliente.
Creare due nuove sottoscrizioni di Azure
Customer Key richiede due sottoscrizioni di Azure. Come procedura consigliata, Microsoft consiglia di creare nuove sottoscrizioni di Azure da usare con la chiave del cliente. Le chiavi di Azure Key Vault possono essere autorizzate solo per le applicazioni nello stesso tenant di Microsoft Entra. È necessario creare le nuove sottoscrizioni usando lo stesso tenant di Microsoft Entra usato con l'organizzazione in cui sono assegnati i punti di accesso. Ad esempio, usando l'account aziendale o dell'istituto di istruzione con privilegi di amministratore globale nell'organizzazione. Per i passaggi dettagliati, vedere Iscriversi ad Azure come organizzazione.
Importante
Customer Key richiede due chiavi per ogni criterio di crittografia dei dati (DEP). A tale scopo, è necessario creare due sottoscrizioni di Azure. Come procedura consigliata, Microsoft consiglia di avere membri separati dell'organizzazione per configurare una chiave in ogni sottoscrizione. È consigliabile usare queste sottoscrizioni di Azure solo per amministrare le chiavi di crittografia per Microsoft 365. Ciò protegge l'organizzazione nel caso in cui uno degli operatori elimini accidentalmente, intenzionalmente o malintenzionatamente o in altro modo gestisce in modo errato le chiavi di cui è responsabile.
Non esiste alcun limite pratico al numero di sottoscrizioni di Azure che è possibile creare per l'organizzazione. Seguendo queste procedure consigliate si riduce al minimo l'impatto dell'errore umano, contribuendo al tempo stesso a gestire le risorse usate dalla chiave del cliente.
Registrare le entità servizio necessarie
Per usare la chiave del cliente, il tenant deve avere le entità servizio necessarie registrate nel tenant. Nelle sezioni seguenti vengono fornite istruzioni per verificare se le entità servizio sono già registrate nel tenant. Se non sono registrati, eseguire il cmdlet 'New-AzADServicePrincipal' come illustrato.
Registrare l'entità servizio per l'applicazione di onboarding della chiave del cliente
Per verificare se l'applicazione di onboarding della chiave del cliente è già registrata nel tenant, con privilegi di amministratore globale, eseguire il comando seguente:
Registrare l'entità servizio per l'applicazione M365DataAtRestEncryption
Per verificare se l'applicazione M365DataAtRestEncryption è già registrata nel tenant, con privilegi di amministratore globale, eseguire il comando seguente:
Registrare l'entità servizio per l'applicazione Office 365 Exchange Online
Per verificare se l'applicazione Office 365 Exchange Online è già registrata nel tenant, con privilegi di amministratore globale, eseguire il comando seguente:
Creare un insieme di credenziali delle chiavi di Azure premium in ogni sottoscrizione
I passaggi per creare un insieme di credenziali delle chiavi sono documentati in Introduzione ad Azure Key Vault. Questi passaggi guidano l'installazione e l'avvio di Azure PowerShell, la connessione alla sottoscrizione di Azure, la creazione di un gruppo di risorse e la creazione di un insieme di credenziali delle chiavi in tale gruppo di risorse.
Quando si crea un insieme di credenziali delle chiavi, è necessario scegliere uno SKU: Standard o Premium. Lo SKU Standard consente di proteggere le chiavi di Azure Key Vault con software, senza protezione delle chiavi HSM (Hardware Security Module) e lo SKU Premium consente l'uso di moduli di protezione hardware per la protezione delle chiavi di Key Vault. Customer Key accetta insiemi di credenziali delle chiavi che usano uno SKU, anche se Microsoft consiglia vivamente di usare solo lo SKU Premium. Il costo delle operazioni con chiavi di entrambi i tipi è lo stesso, quindi l'unica differenza nel costo è il costo al mese per ogni chiave protetta da HSM. Per informazioni dettagliate , vedere Prezzi di Key Vault .
Customer Key ha aggiunto di recente il supporto per le chiavi RSA archiviate in un modulo di protezione hardware gestito conforme a FIPS 140-2 Livello 3. Il modulo di protezione hardware gestito di Azure Key Vault è un servizio cloud completamente gestito, a disponibilità elevata, a tenant singolo e conforme agli standard, che consente di proteggere le chiavi crittografiche per le applicazioni cloud usando moduli di protezione hardware convalidati fips 140-2 livello 3. Per altre informazioni sul modulo di protezione hardware gestito, vedere la panoramica.
Importante
Usare gli insiemi di credenziali delle chiavi SKU Premium e le chiavi protette con HSM per i dati di produzione. Usare solo le chiavi e gli insiemi di credenziali delle chiavi SKU Standard a scopo di test e convalida.
Per ogni servizio Microsoft 365 con cui si usa Customer Key, creare un insieme di credenziali delle chiavi o un modulo di protezione hardware gestito in ognuna delle due sottoscrizioni di Azure create.
Ad esempio, per abilitare La chiave del cliente per l'uso di INDIRIZZI DI SERVIZIO per gli scenari di Exchange, SharePoint e multi-carico di lavoro, creare tre coppie di insiemi di credenziali delle chiavi o moduli di protezione hardware gestiti, per un totale di 6. Usare una convenzione di denominazione che rifletta l'uso previsto di DEP a cui si associano gli insiemi di credenziali. La tabella seguente illustra come eseguire il mapping di ogni azure key vault (AKV) o HSM gestito a ogni carico di lavoro.
Nome dell'insieme di credenziali delle chiavi
Autorizzazioni per più carichi di lavoro di Microsoft 365 (M365DataAtRestEncryption)
Autorizzazioni per Exchange
Autorizzazioni per SharePoint e OneDrive
ContosoM365AKV01
Sì
No
No
ContosoM365AKV02
Sì
No
No
ContosoEXOAKV01
No
Sì
No
ContosoEXOAKV02
No
Sì
No
ContosoSPOAKV01
No
No
Sì
ContosoSPOAKV02
No
No
Sì
La creazione di insiemi di credenziali delle chiavi richiede anche la creazione di gruppi di risorse di Azure, poiché gli insiemi di credenziali delle chiavi richiedono capacità di archiviazione (anche se di piccole dimensioni) e la registrazione di Key Vault, se abilitata, genera anche dati archiviati. Come procedura consigliata, Microsoft consiglia di usare amministratori separati per gestire ogni gruppo di risorse, con l'amministrazione allineata al set di amministratori che gestisce tutte le risorse chiave del cliente correlate.
Per Exchange, l'ambito di un criterio di crittografia dei dati viene scelto quando si assegnano i criteri alla cassetta postale. A una cassetta postale può essere assegnato un solo criterio ed è possibile creare fino a 50 criteri. L'ambito di un criterio di SharePoint include tutti i dati all'interno di un'organizzazione in una posizione geografica o geografica. L'ambito per un criterio multi-carico di lavoro include tutti i dati nei carichi di lavoro supportati per tutti gli utenti.
Importante
Se si prevede di usare la chiave del cliente per più carichi di lavoro di Microsoft 365, Exchange e SharePoint & OneDrive, assicurarsi di creare 2 insiemi di credenziali delle chiavi di Azure per ogni carico di lavoro. È necessario creare un totale di 6 insiemi di credenziali.
Assegnare autorizzazioni a ogni insieme di credenziali delle chiavi
Definire le autorizzazioni necessarie per ogni insieme di credenziali delle chiavi usando il controllo degli accessi in base al ruolo di Azure . Le azioni di configurazione di Azure Key Vault vengono eseguite usando il portale di Azure. Questa sezione illustra in dettaglio come applicare le autorizzazioni appropriate usando il controllo degli accessi in base al ruolo.
Assegnazione di autorizzazioni tramite il metodo RBAC
Amministratori dell'insieme di credenziali delle chiavi o amministratori del modulo di protezione hardware gestiti che ese rono la gestione quotidiana dell'insieme di credenziali delle chiavi per l'organizzazione. Queste attività includono backup, creazione, recupero, importazione, elenco e ripristino.
Importante
Il set di autorizzazioni assegnate agli amministratori dell'insieme di credenziali delle chiavi non include l'autorizzazione per eliminare le chiavi. Si tratta di una pratica intenzionale e importante. L'eliminazione delle chiavi di crittografia non viene in genere eseguita, perché in questo modo i dati vengono distrutti definitivamente. Come procedura consigliata, non concedere l'autorizzazione per l'eliminazione delle chiavi di crittografia agli amministratori dell'insieme di credenziali delle chiavi per impostazione predefinita. Riservare invece questa autorizzazione ai collaboratori dell'insieme di credenziali delle chiavi e assegnarla a un amministratore solo a breve termine dopo aver compreso chiaramente le conseguenze.
Collaboratori che possono modificare le autorizzazioni nell'insieme di credenziali delle chiavi di Azure. Modificare queste autorizzazioni quando i dipendenti lasciano o si uniscono al team. Nella rara situazione in cui gli amministratori dell'insieme di credenziali delle chiavi hanno legittimo bisogno dell'autorizzazione per eliminare o ripristinare una chiave, è necessario modificare anche le autorizzazioni. A questo set di collaboratori dell'insieme di credenziali delle chiavi deve essere concesso il ruolo Collaboratore nell'insieme di credenziali delle chiavi. È possibile assegnare questo ruolo usando il controllo degli accessi in base al ruolo. L'amministratore che crea una sottoscrizione ha questo accesso in modo implicito e la possibilità di assegnare altri amministratori al ruolo Collaboratore.
Aggiungere una chiave a ogni insieme di credenziali delle chiavi creando o importando una chiave
Esistono due modi per aggiungere chiavi a un insieme di credenziali delle chiavi di Azure o a un modulo di protezione hardware gestito; è possibile creare una chiave direttamente nella risorsa oppure importare una chiave. La creazione di una chiave direttamente in Key Vault è meno complessa, ma l'importazione di una chiave fornisce il controllo totale sulla modalità di generazione della chiave. Usare le chiavi RSA. Customer Key supporta la lunghezza della chiave RSA fino a 4096. Azure Key Vault non supporta il wrapping e l'annullamento del wrapping con chiavi di curva ellittiche.
Gli HSM gestiti supportano solo chiavi protette da HSM. Quando si crea una chiave per un modulo di protezione hardware gestito, è necessario creare una chiave RSA-HSM, non un altro tipo.
Per istruzioni su come aggiungere una chiave a ogni insieme di credenziali o HSM gestito, vedere Add-AzKeyVaultKey.
Per i passaggi dettagliati per creare una chiave locale e importarla nell'insieme di credenziali delle chiavi, vedere Come generare e trasferire chiavi protette da HSM per Azure Key Vault. Usare le istruzioni di Azure per creare una chiave in ogni insieme di credenziali delle chiavi.
Verificare la data di scadenza delle chiavi
Per verificare che non sia impostata una data di scadenza per le chiavi, eseguire il cmdlet Get-AzKeyVaultKey .
Per Azure Key Vault:
Get-AzKeyVaultKey -VaultName <vault name>
Per HSM gestito:
Get-AzKeyVaultKey -HsmName <HSM name>
La chiave del cliente non può usare una chiave scaduta. Le operazioni tentate con una chiave scaduta hanno esito negativo e potrebbero causare un'interruzione del servizio. È consigliabile che le chiavi usate con la chiave del cliente non abbiano una data di scadenza.
Una data di scadenza, una volta impostata, non può essere rimossa, ma può essere modificata in una data diversa. Se è necessario usare una chiave con una data di scadenza, modificare il valore di scadenza in 31/12/9999 e usare il processo di onboarding legacy. Le chiavi con una data di scadenza impostata su una data diversa dal 31/12/9999 non riescono a convalidare Microsoft 365. Il servizio di onboarding delle chiavi del cliente accetta solo le chiavi senza una data di scadenza.
Per modificare una data di scadenza impostata su qualsiasi valore diverso dal 31/12/9999, eseguire il cmdlet Update-AzKeyVaultKey .
Non impostare le date di scadenza per le chiavi di crittografia usate con la chiave del cliente.
Assicurarsi che l'eliminazione temporanea sia abilitata per gli insiemi di credenziali delle chiavi
Quando è possibile ripristinare rapidamente le chiavi, è meno probabile che si verifichi un'interruzione del servizio estesa a causa di chiavi eliminate accidentalmente o dannosamente. Questa configurazione viene definita eliminazione temporanea. L'abilitazione dell'eliminazione temporanea consente di ripristinare chiavi o insiemi di credenziali entro 90 giorni dall'eliminazione senza dover ripristinarli dal backup. Questa configurazione viene abilitata automaticamente alla creazione di nuovi insiemi di credenziali delle chiavi di Azure. L'eliminazione temporanea non può essere disattivata per le risorse HSM gestite. Se si usano insiemi di credenziali esistenti che non hanno questa impostazione abilitata, è possibile abilitarla.
Per abilitare l'eliminazione temporanea nell'insieme di credenziali delle chiavi, seguire questa procedura:
Eseguire il cmdlet Get-AzKeyVault . In questo esempio, nome dell'insieme di credenziali è il nome dell'insieme di credenziali delle chiavi per cui si abilita l'eliminazione temporanea:
Verificare che l'eliminazione temporanea sia configurata per l'insieme di credenziali delle chiavi eseguendo il cmdlet Get-AzKeyVault . Se l'eliminazione temporanea è configurata correttamente per l'insieme di credenziali delle chiavi, la proprietà Soft Delete Enabled restituisce il valore True:
Get-AzKeyVault -VaultName <vault name> | fl
Prima di continuare, assicurarsi che l'opzione 'Eliminazione temporanea abilitata?' è impostato su 'True' e 'Soft Delete Retention Period (days)' è impostato su '90'.
Eseguire il backup di Azure Key Vault
Subito dopo la creazione o qualsiasi modifica a una chiave, eseguire un backup e archiviare copie del backup, sia online che offline.
Per creare un backup di un insieme di credenziali delle chiavi di Azure o di una chiave HSM gestita, eseguire il cmdlet Backup-AzKeyVaultKey .
Ottenere l'URI per ogni chiave di Azure Key Vault
Dopo aver configurato gli insiemi di credenziali delle chiavi e aver aggiunto le chiavi, eseguire il comando seguente per ottenere l'URI per la chiave in ogni insieme di credenziali delle chiavi. Usare questi URI quando si crea e si assegna ogni DEP in un secondo momento, quindi salvare queste informazioni in un luogo sicuro. Eseguire questo comando una volta per ogni insieme di credenziali delle chiavi.
In Azure PowerShell:
(Get-AzKeyVaultKey -VaultName <vault name>).Id
Per HSM gestito:
(Get-AzKeyVaultKey -HsmName <HSM name>).Id
Eseguire l'onboarding usando il servizio di onboarding della chiave del cliente
Il servizio di onboarding delle chiavi del cliente di Microsoft 365 è un servizio che consente di abilitare la chiave del cliente all'interno del proprio tenant. Questa funzionalità convalida automaticamente le risorse chiave cliente necessarie. Se lo si desidera, è possibile convalidare le risorse separatamente prima di procedere con l'abilitazione della chiave del cliente all'interno del tenant.
Importante
Questo servizio non è ancora disponibile per gli scenari seguenti:
Tenant per enti pubblici: vedere "Onboard to Customer Key for Government tenants" (Eseguire l'onboarding nella chiave del cliente per i tenant per enti pubblici) di seguito.
SharePoint e OneDrive: vedere "Onboard to Customer Key for SharePoint and OneDrive" (Eseguire l'onboarding nella chiave del cliente per SharePoint e OneDrive) di seguito.
Tenant che usano moduli di protezione hardware gestiti: vedere "Eseguire l'onboarding in Customer Key usando il metodo legacy" di seguito.
L'account usato per l'onboarding deve avere i ruoli seguenti che soddisfano le autorizzazioni minime:
Installare la versione più recente del modulo M365CustomerKeyOnboarding disponibile in PowerShell Gallery. Verificare di scaricare la versione più recente visualizzando la scheda "Cronologia versioni" nella parte inferiore della pagina. Avviare una sessione di PowerShell come amministratore. Copiare e incollare il comando in Azure PowerShell ed eseguirlo per installare il pacchetto. Selezionare l'opzione "Sì a tutti" se richiesto. L'installazione richiede alcuni minuti.
Uso delle 3 diverse modalità di onboarding
Nel processo di onboarding sono disponibili 3 diverse modalità di onboarding, ognuna delle quali viene usata per scopi diversi. Queste 3 modalità sono "Validate", "Prepare", "Enable". Quando si esegue il cmdlet in Creare una richiesta di onboarding, indicare la modalità usando il parametro "-OnboardingMode".
Convalida
Usare la modalità "Convalida" per verificare che la configurazione delle risorse usate per la chiave del cliente sia corretta. Nessuna azione verrà eseguita su nessuna delle risorse in questa modalità.
Importante
È possibile eseguire questa modalità tutte le volte che si desidera se si modifica la configurazione di una delle risorse.
Preparazione
La modalità "Prepara" esegue un'azione sulle risorse chiave del cliente registrando le 2 sottoscrizioni di Azure indicate nel cmdlet per usare mandatoryRetentionPeriod. La perdita temporanea o permanente delle chiavi di crittografia radice può causare interruzioni o addirittura catastrofiche del funzionamento del servizio e può causare la perdita di dati. Per questo motivo, le risorse usate con la chiave del cliente richiedono una protezione avanzata. Un periodo di conservazione obbligatorio impedisce l'annullamento immediato e irrevocabile della sottoscrizione di Azure. Dopo aver eseguito il cmdlet, le sottoscrizioni potrebbero richiedere fino a 1 ora per riflettere la modifica. Per controllare lo stato della registrazione MandatoryRetentionPeriod, dopo aver eseguito il cmdlet in modalità di preparazione, passare alla modalità "convalida".
Importante
La registrazione di MandatoryRetentionPeriod per le sottoscrizioni di Azure è obbligatoria. Sarà necessario eseguire questa modalità una sola volta, a meno che non venga richiesto di eseguire di nuovo questa operazione dal cmdlet .
Attivazione
Usare questa modalità quando si è pronti per l'onboarding in Customer Key. "Enable" abiliterà il tenant solo per Customer Key per il carico di lavoro indicato dal parametro -Scenario . Se si vuole abilitare La chiave del cliente sia per Exchange che per M365DataAtRestEncryption, eseguire il cmdlet di onboarding per un totale di 2 volte, una volta per ogni carico di lavoro. Prima di eseguire il cmdlet in modalità "abilita", verificare che le risorse siano configurate correttamente, indicate da "Passato" sotto "ValidationResult".
Importante
Enable eseguirà correttamente l'onboarding del tenant nella chiave del cliente solo se le risorse soddisfano i controlli in modalità "convalida".
Creazione di una richiesta di onboarding
Il primo passaggio di questo processo di automazione consiste nel creare una nuova richiesta. PowerShell consente di compattare i risultati dei cmdlet in variabili. Compattare la nuova richiesta in una variabile. È possibile creare una variabile usando il simbolo "$" seguito dal nome della variabile.
Nell'esempio $request è la variabile che è possibile assegnare a una richiesta di onboarding.
Immettere l'ID tenant nel formato xxxxxxxx-xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
abcd1234-abcd-efgh-hijk-abcdef123456
-Scenario
Immettere il carico di lavoro a cui si vuole eseguire l'onboarding. Le opzioni da immettere sono: 'MDEP' - Chiave del cliente per più carichi di lavoro 'EXO' - Chiave del cliente per Exchange
MDEP or EXO
-Subscription1
Immettere l'ID sottoscrizione di Azure della prima sottoscrizione registrata per un periodo di conservazione obbligatorio.
p12ld534-1234-5678-9876-g3def67j9k12
-VaultName1
Immettere il nome dell'insieme di credenziali del primo insieme di credenziali delle chiavi di Azure configurato per Customer Key.
EXOVault1
-KeyName1
Immettere il nome della prima chiave di Azure Key Vault all'interno del primo insieme di credenziali delle chiavi di Azure configurato per Customer Key.
EXOKey1
-Subscription2
Immettere l'ID sottoscrizione di Azure della seconda sottoscrizione registrata per un periodo di conservazione obbligatorio.
21k9j76f-ed3g-6789-8765-43215dl21pbd
-VaultName2
Immettere il nome dell'insieme di credenziali del secondo insieme di credenziali delle chiavi di Azure configurato per Customer Key.
EXOVault2
-KeyName2
Immettere il nome della seconda chiave di Azure Key Vault all'interno del secondo insieme di credenziali delle chiavi di Azure configurato per Customer Key.
EXOKey2
-Modalità onboarding
"Preparare" - La configurazione necessaria viene eseguita nelle risorse applicando MandatoryRetentionPeriod alle sottoscrizioni. L'applicazione può richiedere fino a 1 ora . "Convalida" - Convalidare solo le risorse dell'insieme di credenziali delle chiavi di Azure e della sottoscrizione di Azure, non eseguire l'onboarding in Chiave cliente. Questa modalità sarebbe utile se si desidera verificare tutte le risorse, ma si sceglie di eseguire ufficialmente l'onboarding in un secondo momento. "Abilita": convalidare le risorse dell'insieme di credenziali delle chiavi di Azure e della sottoscrizione e abilitare la chiave del cliente all'interno del tenant se la convalida ha esito positivo.
Preparazione or Attivazione or Convalida
Accedere con le credenziali di amministratore del tenant
Verrà visualizzata una finestra del browser che richiede di accedere con l'account con privilegi. Accedere usando le credenziali appropriate.
Visualizzare i dettagli di convalida e abilitazione
Dopo aver eseguito correttamente l'accesso, tornare alla finestra di PowerShell. Eseguire la variabile con cui è stato compattato il cmdlet di onboarding per ottenere un output della richiesta di onboarding.
$request
Si riceve un output con ID, CreatedDate, ValidationResult e EnablementResult.
Output
Descrizione
ID
ID associato alla richiesta di onboarding creata.
CreatedDate
Data di creazione della richiesta.
ValidationResult
Indicatore di convalida riuscita/non riuscita.
EnablementResult
Indicatore di abilitazione riuscita/non riuscita.
Un tenant pronto per l'uso della chiave del cliente ha "Esito positivo" sia in 'ValidationResult' che in 'EnablementResult', come illustrato di seguito:
Passare a Passaggi successivi se il tenant ha eseguito correttamente l'onboarding nella chiave del cliente.
Risoluzione dei problemi relativi a convalide non riuscite
Se la convalida non riesce per il tenant, i passaggi seguenti sono una guida per analizzare la causa radice delle risorse non configurate correttamente. Per verificare quali risorse non configurate correttamente causano l'esito negativo della convalida, archiviare il risultato dell'onboarding in una variabile e passare ai relativi risultati di convalida.
Trovare l'ID richiesta della richiesta che si vuole analizzare elencando tutte le richieste.
Il valore previsto di ogni regola viene visualizzato nella colonna "ExpectedValue" mentre il valore effettivo viene visualizzato nella colonna "ActualValue". La colonna "scope" mostra i primi cinque caratteri dell'ID sottoscrizione, consentendo di determinare quale sottoscrizione e l'insieme di credenziali delle chiavi sottostante hanno riscontrato il problema. La sezione "Dettagli" fornisce una descrizione della causa radice dell'errore e di come gestirlo.
Stato del periodo di conservazione obbligatorio non corretto
Se MandatoryRetentionPeriodState è impostato su 'Recoverable' o 'Recoverable+Purgeable' un'ora dopo l'esecuzione del cmdlet di onboarding in modalità "Prepare" e l'eliminazione temporanea è abilitata negli insiemi di credenziali delle chiavi di Azure, seguire questa procedura:
Verificare che entrambe le sottoscrizioni di Azure restituiscano lo stato "Registrato" eseguendo i comandi seguenti:
Eseguire l'onboarding in Customer Key usando il metodo legacy
Usare questo metodo solo se gli scenari non supportati del servizio di onboarding della chiave del cliente si applicano al tenant. Se si vuole eseguire l'onboarding in Customer Key usando il metodo legacy, dopo aver completato tutti i passaggi per configurare gli insiemi di credenziali delle chiavi di Azure e le sottoscrizioni, contattare il supporto tecnico Microsoft che richiede il supporto tecnico della chiave del cliente.
Eseguire l'onboarding nella chiave del cliente per i tenant governativi
Se si ha un tenant che si trova in GCC-H o DoD e si vuole abilitare La chiave del cliente, dopo aver completato tutti i passaggi per configurare azure Key Vault e sottoscrizioni, contattare il supporto tecnico Microsoft che richiede il supporto della chiave del cliente per i tenant governativi.
Eseguire l'onboarding nella chiave del cliente per SharePoint e OneDrive
Sono disponibili due prerequisiti per l'onboarding nella chiave del cliente per SharePoint e OneDrive.
È già stato eseguito l'onboarding del tenant nella chiave del cliente per Exchange o nella chiave del cliente per più carichi di lavoro.
Entrambe le sottoscrizioni vengono registrate per usare un periodo di conservazione obbligatorio.
Dopo aver completato la procedura descritta in questo articolo, si è pronti per creare e assegnare indirizzi DEP. Per istruzioni, vedere Gestire la chiave del cliente.
Pianificare e progettare la metodologia del progetto per implementare correttamente app per la finanza e le operazioni con servizi FastTrack, gestione dei dati e altro ancora.
Pianificare ed eseguire una strategia di distribuzione degli endpoint, usando elementi essenziali della gestione moderna, approcci di co-gestione e l’integrazione di Microsoft Intune.