Fase di migrazione 2 - Configurazione lato server per AD RMS

Articolo
10/18/2023

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:

Esportare i dati di configurazione da AD RMS esportando i domini di pubblicazione attendibili (TPD) in un file XML. Questo processo è lo stesso per tutte le migrazioni.
Importare i dati di configurazione in Azure Information Protection. Esistono processi diversi per questo passaggio, a seconda della configurazione corrente della distribuzione di AD RMS e della topologia preferita per la chiave del 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 licenze.

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

Accedere al cluster AD RMS come utente con autorizzazioni di amministrazione di AD RMS.
Dalla console di gestione di 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.
Nel riquadro dei risultati selezionare il dominio di pubblicazione attendibile e quindi nel riquadro Azioni fare clic su Esporta dominio pubblicazione attendibile.
Nella finestra di dialogo Esporta dominio pubblicazione attendibile:
- Fare clic su Salva con nome e salvare in percorso e su un nome file di propria scelta. Assicurarsi di specificare .xml come estensione del nome file (questa operazione non viene aggiunta automaticamente).
- Specificare e confermare una password complessa. Tenere presente 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 SLC (Server Certificate) per decrittografare i file protetti in precedenza, quindi è importante esportare (e successivamente 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 si importa il dominio di pubblicazione attendibile contenente la chiave archiviata che usa la modalità crittografia 1, alla fine della migrazione, gli utenti non potranno aprire il contenuto protetto con la chiave della modalità 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 del tenant di Azure Information Protection.

La distribuzione di AD RMS corrente usa una delle configurazioni seguenti per la chiave del certificato concessore di licenze server :Your Current AD RMS deployment is using one of the following configurations for your server certificate (SLC) key:

Protezione password nel database AD RMS. Questa è la configurazione predefinita.
Protezione HSM tramite un modulo di protezione hardware nCipher.
Protezione HSM usando un modulo di protezione hardware (HSM) di un fornitore diverso da nCipher.
Password protetta tramite un provider di crittografia esterno.

Nota

Per altre informazioni sull'uso di moduli di sicurezza hardware con AD RMS, vedere Uso di AD RMS con moduli di sicurezza hardware.

Le due opzioni di topologia della chiave del tenant di Azure Information Protection sono: Microsoft gestisce la chiave del tenant (gestita da Microsoft) o la chiave del tenant (gestita dal cliente) in Azure Key Vault. Quando si gestisce la propria chiave del tenant di Azure Information Protection, viene talvolta definita "Bring Your Own Key" (BYOK). 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 relative alla migrazione
Protezione password nel database AD RMS	Gestito da Microsoft	Vedere la procedura di migrazione da chiave protetta da software a chiave protetta da software dopo questa tabella. Questo è il percorso di migrazione più semplice e richiede solo il trasferimento dei dati di configurazione in Azure Information Protection.
Protezione HSM tramite un modulo di sicurezza hardware nCipher nShield	Gestito dal cliente (BYOK)	Vedere la procedura di migrazione della chiave protetta dal modulo di protezione hardware alla chiave protetta da HSM dopo questa tabella. Questo richiede il set di strumenti BYOK di Azure Key Vault e tre set di passaggi per trasferire prima la chiave dal modulo di protezione hardware locale ai moduli di protezione hardware di Azure Key Vault, quindi autorizzare il servizio Azure Rights Management da Azure Information Protection a usare la chiave del tenant e infine trasferire i dati di configurazione ad Azure Information Protection.
Protezione password nel database AD RMS	Gestito dal cliente (BYOK)	Vedere la procedura di migrazione da chiave protetta da software a chiave protetta da HSM dopo questa tabella. Questo richiede il set di strumenti BYOK di Azure Key Vault e quattro set di passaggi per estrarre prima la chiave software e importarla in un modulo di protezione hardware locale, quindi trasferire la chiave dal modulo di protezione hardware locale ai moduli di protezione hardware di Azure Information Protection, quindi trasferire i dati di Key Vault in Azure Information Protection e infine trasferire i dati di configurazione in Azure Information Protection.
Protezione HSM usando un modulo di protezione hardware (HSM) di un fornitore diverso da nCipher	Gestito dal cliente (BYOK)	Contattare il fornitore del modulo di protezione hardware per istruzioni su come trasferire la chiave da questo modulo di protezione hardware a un modulo di protezione hardware nCipher nShield (HSM). Seguire quindi le istruzioni per la procedura di migrazione della chiave protetta dal modulo di protezione hardware alla chiave protetta da HSM dopo questa tabella.
Password protetta tramite un provider di crittografia esterno	Gestito dal cliente (BYOK)	Per istruzioni su come trasferire la chiave a un modulo di sicurezza hardware nCipher nShield, contattare il fornitore del provider di crittografia. Seguire quindi le istruzioni per la procedura di migrazione della chiave protetta dal modulo di protezione hardware alla chiave protetta da HSM dopo questa tabella.

Se si dispone di 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ò ancora essere aperto, ma il contenuto appena protetto usa una nuova chiave tenant gestita dall'utente (BYOK) o gestita da Microsoft. Per altre informazioni, vedere Aggiornamento disponibile per Office per supportare le migrazioni da AD RMS ad Azure RMS.

Prima di avviare queste procedure di migrazione chiave, assicurarsi di poter accedere ai file con estensione xml creati in precedenza durante l'esportazione dei domini di pubblicazione attendibili. Ad esempio, questi potrebbero essere salvati in un'unità usb che si sposta dal server AD RMS alla workstation connessa a Internet.

Nota

Tuttavia, questi file vengono archiviati, usare le procedure consigliate per la 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:

Connessione al servizio Azure Rights Management e, quando richiesto, specificare le credenziali di amministratore globale:
```
Connect-AipService
```
Attivare il servizio Azure Rights Management:
```
Enable-AipService
```

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

Passaggio 6: Configurare i modelli importati

Poiché i modelli importati hanno lo stato predefinito Archiviato, è necessario modificare questo stato in Modo che venga pubblicato se si vuole che gli utenti possano usare questi modelli con il servizio Azure Rights Management.

I modelli importati da AD RMS sono simili ai modelli personalizzati che è possibile creare nel portale di Azure. Per modificare i modelli importati da pubblicare in modo che gli utenti possano visualizzarli 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 che potrebbero essere necessari prima di continuare con la migrazione. Per un'esperienza più coerente per gli utenti durante il processo di migrazione, non apportare modifiche aggiuntive ai modelli importati e non pubblicare i due modelli predefiniti disponibili con Azure Information Protection o creare nuovi modelli in questo momento. Attendere invece che il processo di migrazione sia stato completato ed è stato eseguito il deprovisioning dei server AD RMS.

Le modifiche al modello che potrebbe essere necessario apportare per questo passaggio:

Se sono stati creati modelli personalizzati di Azure Information Protection prima della migrazione, è necessario esportarli e importarli manualmente.
Se i modelli in AD RMS usano il gruppo ANYONE , potrebbe essere necessario aggiungere manualmente utenti o gruppi.

In AD RMS il gruppo ANYONE ha concesso i diritti a tutti gli utenti autenticati dal Active Directory locale e questo gruppo non è supportato da Azure Information Protection. L'equivalente armadio è un gruppo creato automaticamente per tutti gli utenti nel tenant di Microsoft Entra. Se si usa il gruppo ANYONE per i modelli AD RMS, potrebbe essere necessario aggiungere utenti e i diritti che si desidera 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 Pubblicato. Per renderli disponibili agli utenti, è prima necessario eseguire le operazioni seguenti:

Identificare questi modelli e prendere nota dell'ID modello eseguendo Get-AipServiceTemplate.
Esportare i modelli usando il cmdlet PowerShell di Azure RMS, Export-AipServiceTemplate.
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 ANYONE

Se i modelli in AD RMS usano il gruppo ANYONE, 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 Microsoft Entra.

Quando si gestiscono modelli ed etichette nella portale di Azure, questo gruppo viene visualizzato come nome di dominio del tenant in Microsoft Entra ID. 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 ANYONE, è 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 Amministrazione ister AD RMS.

È possibile aggiungere facilmente utenti esterni ai modelli quando si convertono questi modelli in etichette nel portale di Azure. Quindi, nel riquadro Aggiungi autorizzazioni scegliere Immettere i 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 di Rights Management.

Script di Windows PowerShell di esempio per identificare i modelli di AD RMS che includono il gruppo ANYONE

Questa sezione contiene lo script di esempio che consente di identificare tutti i modelli AD RMS con il gruppo ANYONE definito, 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 "nello stato in cui si trova" senza garanzia 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.