Fase di migrazione 2 - configurazione lato server per AD RMS

Usare le informazioni seguenti per la fase 2 della migrazione da AD RMS ad Azure Information Protection. Queste procedure illustrano i passaggi da 4 a 6 dalla migrazione da AD RMS ad Azure Information Protection.

Passaggio 4. Esportare i dati di configurazione da AD RMS e importarli in Azure Information Protection

Questo passaggio è un processo in due parti:

  1. Esportare i dati di configurazione da AD RMS esportando i domini di pubblicazione attendibili in un file di .xml. Questo processo è lo stesso per tutte le migrazioni.

  2. Importare i dati di configurazione in Azure Information Protection. Esistono diversi processi per questo passaggio, a seconda della configurazione corrente della distribuzione AD RMS e della topologia preferita per la chiave tenant di Azure RMS.

Esportare i dati di configurazione da AD RMS

Eseguire la procedura seguente in tutti i cluster AD RMS per tutti i domini di pubblicazione attendibili con contenuto protetto per l'organizzazione. Non è necessario eseguire questa procedura nei cluster solo delle licenze.

Per esportare i dati di configurazione (informazioni sul dominio di pubblicazione attendibile)

  1. Accedere al cluster AD RMS come utente con autorizzazioni di amministrazione di AD RMS.

  2. Dalla console di gestione AD RMS (Active Directory Rights Management Services), espandere il nome del cluster AD RMS, espandere Criteri di attendibilità e quindi fare clic su Domini di pubblicazione attendibili.

  3. Nel riquadro dei risultati selezionare il dominio di pubblicazione attendibile e quindi, nel riquadro Azioni, fare clic su Esporta dominio di pubblicazione attendibile.

  4. Nella finestra di dialogo Esporta dominio di pubblicazione attendibile :

    • Fare clic su Salva con nome e salvare il percorso e il nome file desiderato. Assicurarsi di specificare .xml come estensione del nome file (questa estensione non viene aggiunta automaticamente).

    • Specificare e confermare una password complessa. Ricordare questa password, perché sarà necessaria in un secondo momento, quando si importano i dati di configurazione in Azure Information Protection.

    • Non selezionare la casella di controllo per salvare il file di dominio attendibile in RMS versione 1.0.

Dopo aver esportato tutti i domini di pubblicazione attendibili, è possibile avviare la procedura per importare questi dati in Azure Information Protection.

Si noti che i domini di pubblicazione attendibili includono le chiavi del certificato del licenziante del server (SLC) per decrittografare i file protetti in precedenza, quindi è importante esportare (e in seguito importare in Azure) tutti i domini di pubblicazione attendibili e non solo quello attualmente attivo.

Ad esempio, si avranno più domini di pubblicazione attendibili se i server AD RMS sono stati aggiornati dalla modalità di crittografia 1 alla modalità di crittografia 2. Se non si esporta e non si importa il dominio di pubblicazione attendibile che contiene la chiave archiviata che usava la modalità di crittografia 1, al termine della migrazione gli utenti non saranno in grado di aprire il contenuto protetto con la chiave della modalità di crittografia 1.

Importare i dati di configurazione in Azure Information Protection

Le procedure esatte per questo passaggio dipendono dalla configurazione corrente della distribuzione di AD RMS e dalla topologia preferita per la chiave tenant di Azure Information Protection.

L'attuale distribuzione di AD RMS usa una delle configurazioni seguenti per la chiave del certificato del licenziante del server:

  • Password di protezione nel database AD RMS. Questa è la configurazione predefinita.

  • Protezione HSM utilizzando un modulo di sicurezza hardware (HSM) aggiuntivo.

  • Protezione HSM utilizzando un modulo di sicurezza hardware (HSM) da un fornitore diverso da nCipher.

  • Password protetta tramite un provider di crittografia esterno.

Nota

Per ulteriori informazioni sull'uso dei moduli di sicurezza hardware con AD RMS, vedi Uso di AD RMS con i moduli di sicurezza hardware.

Le due opzioni di topologia della chiave tenant di Azure Information Protection sono: Microsoft gestisce la chiave tenant (gestita da Microsoft) o la chiave tenant (gestita dal cliente) in Azure Key Vault. Quando si gestisce la propria chiave tenant di Azure Information Protection, a volte viene definita BYOK (Bring Your Own Key). Per altre informazioni, vedere l'articolo Pianificazione e implementazione della chiave del tenant di Azure Information Protection.

Usare la tabella seguente per identificare la procedura da usare per la migrazione.

Distribuzione corrente di AD RMS Topologia della chiave del tenant di Azure Information Protection scelta Istruzioni per la migrazione
Password di protezione nel database AD RMS Gestito da Microsoft Vedere la procedura di migrazione della chiave protetta da software per la chiave protetta da software dopo questa tabella.

Questo è il percorso di migrazione più semplice e richiede solo il trasferimento dei dati di configurazione ad Azure Information Protection.
Protezione HSM tramite un modulo di sicurezza hardware nCipher nShield (HSM) BYOK (Customer-Managed) Vedere la procedura di migrazione della chiave protetta da HSM alla chiave protetta da HSM dopo questa tabella.

Ciò richiede il set di strumenti AZURE Key Vault BYOK e tre set di passaggi per trasferire prima la chiave da HSM locale ad Azure Key Vault HSMs, quindi autorizzare il servizio Azure Rights Management da Azure Information Protection di usare la chiave tenant e infine trasferire i dati di configurazione ad Azure Information Protection.
Password di protezione nel database AD RMS BYOK (Customer-Managed) Vedere la procedura di migrazione della chiave protetta da software per la migrazione della chiave protetta da HSM dopo questa tabella.

A questo scopo, è necessario che il set di strumenti di Azure Key Vault BYOK e quattro set di passaggi estraggano la chiave software e la importino in un sistema HSM locale, quindi trasferire la chiave da HSM locale ad Azure Information Protection HSMs, quindi trasferire i dati di Key Vault in Azure Information Protection e infine trasferire i dati di configurazione ad Azure Information Protection.
Protezione HSM utilizzando un modulo di sicurezza hardware (HSM) da un fornitore diverso da nCipher BYOK (Customer-Managed) Contatta il fornitore di HSM per istruzioni su come trasferire la chiave da HSM a un modulo di sicurezza hardware nCipher nShield (HSM). Seguire quindi le istruzioni per la chiave protetta da HSM per la procedura di migrazione della chiave protetta da HSM dopo questa tabella.
Password protetta da un provider di crittografia esterno BYOK (Customer-Managed) Contattare il fornitore del provider di crittografia per istruzioni su come trasferire la chiave in un modulo di sicurezza hardware nCipher nShield (HSM). Seguire quindi le istruzioni per la chiave protetta da HSM per la procedura di migrazione della chiave protetta da HSM dopo questa tabella.

Se si ha una chiave protetta da HSM che non è possibile esportare, è comunque possibile eseguire la migrazione ad Azure Information Protection configurando il cluster AD RMS per una modalità di sola lettura. In questa modalità, il contenuto protetto in precedenza può comunque essere aperto, ma il contenuto appena protetto usa una nuova chiave tenant gestita dall'utente (BYOK) o gestita da Microsoft. Per altre informazioni, vedere È disponibile un aggiornamento per Office per supportare le migrazioni da AD RMS ad Azure RMS.

Prima di avviare queste procedure di migrazione principali, assicurarsi di poter accedere ai file .xml creati in precedenza quando sono stati esportati i domini di pubblicazione attendibili. È ad esempio possibile che vengano salvate in una chiavetta USB spostata dal server AD RMS alla workstation connessa a Internet.

Nota

Tuttavia, è possibile archiviare questi file, usare le procedure consigliate di sicurezza per proteggerli perché questi dati includono la chiave privata.

Per completare il passaggio 4, scegliere e selezionare le istruzioni per il percorso di migrazione:

Passaggio 5. Attivare il servizio Azure Rights Management

Aprire una sessione di PowerShell ed eseguire i comandi seguenti:

  1. Connessione al servizio Azure Rights Management e, quando richiesto, specificare le credenziali di amministratore globale:

    Connect-AipService
    
  2. Attivare il servizio Azure Rights Management:

    Enable-AipService
    

Cosa succede se il tenant di Azure Information Protection è già attivato? Se il servizio Azure Rights Management è già attivato per l'organizzazione e sono stati creati modelli personalizzati da usare dopo la migrazione, è necessario esportare e importare questi modelli. Questa procedura è illustrata nel passaggio successivo.

Passaggio 6. Configurare i modelli importati

Poiché lo stato predefinito dei modelli importati è Archiviato, è necessario impostare questo stato su Pubblicato se si vuole consentire agli utenti di usare questi modelli con il servizio Azure Rights Management.

I modelli importati da AD RMS hanno un aspetto e un comportamento simili a modelli personalizzati che è possibile creare nel portale di Azure. Per modificare i modelli importati da pubblicare in modo che gli utenti possano vederli e selezionarli dalle applicazioni, vedere Configurazione e gestione dei modelli per Azure Information Protection.

Oltre a pubblicare i modelli appena importati, potrebbero essere necessarie solo due modifiche importanti per i modelli prima di continuare la migrazione. Per un'esperienza più coerente per gli utenti durante il processo di migrazione, non apportare ulteriori modifiche ai modelli importati e non pubblicare i due modelli predefiniti inclusi in Azure Information Protection o creare nuovi modelli al momento. Attendere il completamento del processo di migrazione ed eseguire il deprovisioning dei server AD RMS.

Modifiche al modello che potrebbe essere necessario apportare per questo passaggio:

  • Se è stato creato Azure Information Protection modelli personalizzati prima della migrazione, è necessario esportarli e importarli manualmente.

  • Se i modelli in AD RMS usavano il gruppo CHIUNQUE , potrebbe essere necessario aggiungere manualmente utenti o gruppi.

    In AD RMS il gruppo CHIUNQUE ha concesso i diritti a tutti gli utenti autenticati dal Active Directory locale e questo gruppo non è supportato da Azure Information Protection. L'equivalente dell'armadio è un gruppo creato automaticamente per tutti gli utenti nel tenant di Azure AD. Se si usava il gruppo CHIUNQUE per i modelli di AD RMS, potrebbe essere necessario aggiungere utenti e i diritti che si vogliono concedere.

Procedura se sono stati creati modelli personalizzati prima della migrazione

Se sono stati creati modelli personalizzati prima della migrazione, prima o dopo l'attivazione del servizio Azure Rights Management, i modelli non saranno disponibili per gli utenti dopo la migrazione, anche se sono stati impostati su Pubblicati. Per renderle disponibili agli utenti, è necessario eseguire le operazioni seguenti:

  1. Identificare questi modelli e prendere nota dell'ID del modello eseguendo Get-AipServiceTemplate.

  2. Esportare i modelli usando il cmdlet PowerShell di Azure RMS, Export-AipServiceTemplate.

  3. Importare i modelli usando il cmdlet PowerShell di Azure RMS, Import-AipServiceTemplate.

È quindi possibile pubblicare o archiviare questi modelli come qualsiasi altro modello creato dopo la migrazione.

Procedura se i modelli in AD RMS hanno usato il gruppo CHIUNQUE

Se i modelli in AD RMS usavano il gruppo CHIUNQUE, il gruppo equivalente più vicino in Azure Information Protection è denominato AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@<tenant_name.onmicrosoft.com>. Ad esempio, questo gruppo potrebbe essere simile al seguente per Contoso: AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@contoso.onmicrosoft.com. Questo gruppo contiene tutti gli utenti del tenant di Azure AD.

Quando si gestiscono modelli ed etichette nel portale di Azure, questo gruppo viene visualizzato come nome di dominio del tenant in Azure AD. Ad esempio, questo gruppo potrebbe essere simile al seguente per Contoso: contoso.onmicrosoft.com. Per aggiungere questo gruppo, l'opzione visualizza Aggiungi <nome> organizzazione - Tutti i membri.

Se non si è certi che i modelli di AD RMS includano il gruppo CHIUNQUE, è possibile usare lo script di Windows PowerShell di esempio seguente per identificare questi modelli. Per altre informazioni sull'uso di Windows PowerShell con AD RMS, vedere Uso di Windows PowerShell per amministrare AD RMS.

È possibile aggiungere facilmente utenti esterni ai modelli quando questi modelli vengono convertiti in etichette nella portale di Azure. Quindi, nel riquadro Aggiungi autorizzazioni scegliere Immetti dettagli per specificare manualmente gli indirizzi di posta elettronica per questi utenti.

Per altre informazioni su questa configurazione, vedere Come configurare un'etichetta per la protezione Rights Management.

Esempio di script Windows PowerShell per identificare i modelli AD RMS che includono il gruppo CHIUNQUE

Questa sezione contiene lo script di esempio che consente di identificare i modelli AD RMS per cui è definito il gruppo CHIUNQUE, come descritto nella sezione precedente.

Dichiarazione di non responsabilità: questo script di esempio non è supportato in alcun programma o servizio di supporto standard Microsoft. Questo script di esempio viene fornito COSÌ COME È senza garanzie di alcun tipo.

import-module adrmsadmin

New-PSDrive -Name MyRmsAdmin -PsProvider AdRmsAdmin -Root https://localhost -Force

$ListofTemplates=dir MyRmsAdmin:\RightsPolicyTemplate

foreach($Template in $ListofTemplates)
{
                $templateID=$Template.id

                $rights = dir MyRmsAdmin:\RightsPolicyTemplate\$Templateid\userright

     $templateName=$Template.DefaultDisplayName

        if ($rights.usergroupname -eq "anyone")

                         {
                           $templateName = $Template.defaultdisplayname

                           write-host "Template " -NoNewline

                           write-host -NoNewline $templateName -ForegroundColor Red

                           write-host " contains rights for " -NoNewline

                           write-host ANYONE  -ForegroundColor Red
                         }
 }
Remove-PSDrive MyRmsAdmin -force

Passaggi successivi

Passare alla fase 3 - configurazione lato client.