Preparazione di utenti e gruppi per Azure Information Protection

Nota

Si sta cercando Microsoft Purview Information Protection, in precedenza Microsoft Information Protection (MIP)?

Il componente aggiuntivo Azure Information Protection viene ritirato e sostituito con le etichette integrate nelle app e nei servizi di Microsoft 365. Altre informazioni sullo stato di supporto di altri componenti di Azure Information Protection.

Il client Microsoft Purview Information Protection (senza il componente aggiuntivo) è disponibile a livello generale.

Prima di distribuire Azure Information Protection per l'organizzazione, assicurarsi di disporre di account per utenti e gruppi in Microsoft Entra ID per il tenant dell'organizzazione.

È possibile creare gli account per utenti e gruppi in modi diversi:

• Gli utenti vengono creati nella interfaccia di amministrazione di Microsoft 365 e i gruppi nell'interfaccia di amministrazione di Exchange Online.

• Creando gli utenti e i gruppi nel portale di Azure.

• Creando gli utenti e i gruppi tramite cmdlet di Azure AD PowerShell e di Exchange Online.

• Gli utenti e i gruppi vengono creati nel Active Directory locale e sincronizzati con Microsoft Entra ID.

• Gli utenti e i gruppi vengono creati in un'altra directory e sincronizzati con Microsoft Entra ID.

Quando si creano utenti e gruppi usando i primi tre metodi di questo elenco, con un'eccezione, vengono creati automaticamente in Microsoft Entra ID e Azure Information Protection può usare direttamente questi account. Molte reti aziendali, tuttavia, creano e gestiscono utenti e gruppi all'interno di una directory locale. Azure Information Protection non può usare questi account direttamente; è necessario sincronizzarli con Microsoft Entra ID.

L'eccezione a cui si fa riferimento nel paragrafo precedente è costituito da liste di distribuzione dinamiche che è possibile creare per Exchange Online. A differenza delle liste di distribuzione statiche, questi gruppi non vengono replicati in MICROSOFT Entra ID e quindi non possono essere usati da Azure Information Protection.

Uso di utenti e gruppi con Azure Information Protection

Sono possibili tre scenari di uso di utenti e gruppi con Azure Information Protection:

Per l'assegnazione di etichette agli utenti quando si configurano i criteri di Azure Information Protection in modo tale da consentire l'applicazione di etichette a documenti e messaggi di posta elettronica. Solo gli amministratori possono selezionare questi utenti e gruppi:

• I criteri predefiniti di Azure Information Protection vengono assegnati automaticamente a tutti gli utenti nell'ID Microsoft Entra del tenant. È anche possibile, tuttavia, assegnare etichette aggiuntive a utenti o gruppi specifici tramite criteri con ambito.

Per l'assegnazione di diritti di utilizzo e controlli di accesso quando si usa il servizio Azure Rights Management per proteggere documenti e messaggi di posta elettronica. Gli amministratori e gli utenti possono selezionare questi utenti e gruppi:

• I diritti di utilizzo determinano se un utente può aprire un documento o un messaggio di posta elettronica e come può usarlo, ad esempio se può solo leggerlo, leggerlo e stamparlo o leggerlo e modificarlo.

• I controlli di accesso includono una data di scadenza e se è necessaria una connessione a Internet per l'accesso.

Per la configurazione del servizio Azure Rights Management per il supporto di scenari specifici e pertanto solo gli amministratori possono selezionare questi gruppi. Di seguito sono riportati alcuni esempi di elementi configurabili:

• Utenti con privilegi avanzati, in modo che i servizi o gli utenti designati possano aprire il contenuto crittografato se necessario per eDiscovery o il recupero dei dati.

• Amministrazione delegata del servizio Azure Rights Management.

• Controlli di onboarding per supportare una distribuzione a più fasi.

Requisiti di Azure Information Protection per gli account utente

Per l'assegnazione di etichette:

• Tutti gli account utente in Microsoft Entra ID possono essere usati per configurare criteri con ambito che assegnano etichette aggiuntive agli utenti.

Per l'assegnazione di diritti di utilizzo e controlli di accesso e per la configurazione del servizio Azure Rights Management:

• Per autorizzare gli utenti, vengono usati due attributi in Microsoft Entra ID: proxyAddresses e userPrincipalName.

• L'attributo ProxyAddresses di Microsoft Entra archivia tutti gli indirizzi di posta elettronica per un account e può essere popolato in modi diversi. Ad esempio, un utente di Microsoft 365 con una cassetta postale di Exchange Online ha automaticamente un indirizzo di posta elettronica archiviato in questo attributo. Se si assegna un indirizzo di posta elettronica alternativo per un utente di Microsoft 365, viene salvato anche in questo attributo. L'attributo può essere popolato anche con indirizzi di posta elettronica sincronizzati con gli account locali.

  Azure Information Protection può usare qualsiasi valore in questo attributo proxyAddresses di Microsoft Entra, specificando che il dominio è stato aggiunto al tenant (un "dominio verificato"). Per altre informazioni sulla verifica di domini:

  • Per Microsoft Entra ID: aggiungere un nome di dominio personalizzato a Microsoft Entra ID

  • Per Office 365: Aggiungere un dominio a Office 365

• L'attributo Microsoft Entra userPrincipalName viene usato solo quando un account nel tenant non ha valori nell'attributo proxyAddresses di Microsoft Entra. Ad esempio, si crea un utente nel portale di Azure o si crea un utente per Microsoft 365 che non dispone di una cassetta postale.

Assegnazione di diritti di utilizzo e controlli di accesso a utenti esterni

Oltre a usare Microsoft Entra proxyAddresses e Microsoft Entra userPrincipalName per gli utenti nel tenant, Azure Information Protection usa questi attributi nello stesso modo per autorizzare gli utenti da un altro tenant.

Altri metodi di autorizzazione:

• Per gli indirizzi di posta elettronica non inclusi nell'ID Microsoft Entra, Azure Information Protection può autorizzare questi indirizzi quando vengono autenticati con un account Microsoft. Tuttavia, non tutte le applicazioni possono aprire contenuto protetto quando viene usato un account Microsoft per l'autenticazione. Ulteriori informazioni

• Quando un messaggio di posta elettronica viene inviato tramite Crittografia messaggi di Office 365 con nuove funzionalità a un utente che non ha un account in Microsoft Entra ID, l'utente viene prima autenticato tramite la federazione con un provider di identità social o usando un passcode monouso. L'indirizzo di posta elettronica specificato nel messaggio protetto viene quindi usato per l'autorizzazione dell'utente.

Requisiti di Azure Information Protection per gli account di gruppo

Per l'assegnazione di etichette:

• Per configurare i criteri con ambito che assegnano etichette aggiuntive ai membri del gruppo, è possibile usare qualsiasi tipo di gruppo in Microsoft Entra ID con un indirizzo di posta elettronica contenente un dominio verificato per il tenant dell'utente. Un gruppo dotato di un indirizzo di posta elettronica è spesso detto gruppo abilitato alla posta elettronica.

  Ad esempio, è possibile usare un gruppo di sicurezza abilitato alla posta elettronica, un gruppo di distribuzione statico e un gruppo di Microsoft 365. Non è possibile usare un gruppo di sicurezza (statico o dinamico), perché questo tipo di gruppo non ha un indirizzo di posta elettronica. Non è inoltre possibile utilizzare una lista di distribuzione dinamica da Exchange Online perché questo gruppo non viene replicato in Microsoft Entra ID.

Per l'assegnazione di diritti di utilizzo e controlli di accesso:

• È possibile usare qualsiasi tipo di gruppo nell'ID Microsoft Entra con un indirizzo di posta elettronica che contiene un dominio verificato per il tenant dell'utente. Un gruppo dotato di un indirizzo di posta elettronica è spesso detto gruppo abilitato alla posta elettronica.

Per la configurazione del servizio Rights Management di Azure:

• È possibile usare qualsiasi tipo di gruppo nell'ID Microsoft Entra con un indirizzo di posta elettronica da un dominio verificato nel tenant, con un'eccezione. Questa eccezione si verifica quando si configurano i controlli di onboarding per l'uso di un gruppo, che deve essere un gruppo di sicurezza in Microsoft Entra ID per il tenant.

• È possibile usare qualsiasi gruppo in Microsoft Entra ID (con o senza un indirizzo di posta elettronica) da un dominio verificato nel tenant per l'amministrazione delegata del servizio Azure Rights Management.

Assegnazione di diritti di utilizzo e controlli di accesso a gruppi esterni

Oltre a usare microsoft Entra proxyAddresses per i gruppi nel tenant, Azure Information Protection usa questo attributo nello stesso modo per autorizzare i gruppi da un altro tenant.

Uso di account di Active Directory locale per Azure Information Protection

Se si dispone di account gestiti in locale da usare con Azure Information Protection, è necessario sincronizzare questi account con Microsoft Entra ID. Per semplificare la distribuzione, è consigliabile usare Microsoft Entra Connessione. È tuttavia possibile usare qualsiasi metodo di sincronizzazione di directory che consenta di ottenere lo stesso risultato.

Quando si sincronizzano gli account, non è necessario sincronizzare tutti gli attributi. Per un elenco degli attributi che devono essere sincronizzati, vedere la sezione Azure RMS della documentazione di Microsoft Entra.

Dall'elenco degli attributi per Azure Rights Management risulta che per gli utenti gli attributi di AD locale richiesti per la sincronizzazione sono mail, proxyAddresses e userPrincipalName. I valori per posta elettronica e proxyAddresses vengono sincronizzati con l'attributo proxyAddresses di Microsoft Entra. Per altre informazioni, vedere Come viene popolato l'attributo proxyAddresses in Microsoft Entra ID

Verifica della preparazione di utenti e gruppi per Azure Information Protection

È possibile usare Azure AD PowerShell per verificare che utenti e gruppi possano essere usati con Azure Information Protection. È possibile usare PowerShell anche per verificare i valori utilizzabili per autorizzare gli utenti e i gruppi.

Nota

I moduli Azure AD e MSOnline PowerShell sono deprecati a partire dal 30 marzo 2024. Per maggiori informazioni, leggere l'aggiornamento sulla deprecazione. Dopo questa data, il supporto per questi moduli è limitato all'assistenza alla migrazione a Microsoft Graph PowerShell SDK e alle correzioni di sicurezza. I moduli deprecati continueranno a funzionare fino al 30 marzo 2025.

È consigliabile eseguire la migrazione a Microsoft Graph PowerShell per interagire con Microsoft Entra ID (in precedenza Azure AD). Per domande comuni sulla migrazione, consultare le Domande frequenti sulla migrazione. Nota: le versioni 1.0.x di MSOnline potrebbero subire interruzioni dopo il 30 giugno 2024.

Ad esempio, usando il modulo PowerShell V1 per Microsoft Entra ID, MSOnline, in una sessione di PowerShell, connettersi prima al servizio e specificare le credenziali di amministratore globale:

Connect-MsolService

Nota: se questo comando non funziona, è possibile eseguire Install-Module MSOnline per installare il modulo MSOnline.

Configurare quindi la sessione di PowerShell in modo che non consenta il troncamento dei valori:

$Formatenumerationlimit =-1

Verificare se gli account utente sono pronti per Azure Information Protection

Per verificare gli account utente, eseguire il comando seguente:

Get-Msoluser | select DisplayName, UserPrincipalName, ProxyAddresses

Assicurarsi prima di tutto che siano visualizzati gli utenti che si vogliono usare con Azure Information Protection.

Controllare quindi se la colonna ProxyAddresses è popolata. In caso affermativo, gli indirizzi di posta elettronica di questa colonna possono essere usati per autorizzare l'utente per Azure Information Protection.

Se la colonna ProxyAddresses non è popolata, l'autorizzazione dell'utente per il servizio Azure Rights Management viene effettuata con il valore presente in UserPrincipalName.

Ad esempio:

Nome visualizzato	UserPrincipalName	ProxyAddresses
Jagannath Reddy	jagannathreddy@contoso.com	{}
Ankur Roy	ankurroy@contoso.com	{SMTP:ankur.roy@contoso.com, smtp: ankur.roy@onmicrosoft.contoso.com}

In questo esempio:

• Per l'autorizzazione dell'account utente di Jagannath Reddy verrà usato l'indirizzo jagannathreddy@contoso.com.

• L'autorizzazione dell'account utente di Ankur Roy può essere effettuata tramite ankur.roy@contoso.com e ankur.roy@onmicrosoft.contoso.com, ma non tramite ankurroy@contoso.com.

Nella maggior parte dei casi il valore di UserPrincipalName corrisponde a uno dei valori presenti nel campo ProxyAddresses. Questa è la configurazione consigliata, ma se non è possibile modificare il nome UPN in modo che corrisponda all'indirizzo di posta elettronica, è necessario eseguire la procedura seguente:

1. Se il nome di dominio nel valore UPN è un dominio verificato per il tenant di Microsoft Entra, aggiungere il valore UPN come un altro indirizzo di posta elettronica in Microsoft Entra ID in modo che il valore UPN possa ora essere usato per autorizzare l'account utente per Azure Information Protection.

   Se il nome di dominio nel valore UPN non è un dominio verificato per il tenant, non può essere usato con Azure Information Protection. È tuttavia ancora possibile autorizzare l'utente come membro di un gruppo se l'indirizzo di posta elettronica del gruppo usa un nome di dominio verificato.

2. Se il nome UPN non è indirizzabile (come, ad esempio, ankurroy@contoso.local), configurare un ID di accesso alternativo per gli utenti, fornendo a questi ultimi le istruzioni necessarie per l'accesso a Office tramite questo ID. È anche necessario impostare una chiave del Registro di sistema per Office.

   Con le modifiche UPN per gli utenti, si verifica una perdita di continuità aziendale per almeno 24 ore o fino a quando le modifiche UPN non vengono riflesse correttamente nel sistema.

   Per altre informazioni, vedere Configurazione dell'ID di accesso alternativo e app Office licazioni richiedono periodicamente le credenziali a SharePoint, OneDrive e Lync Online.

Suggerimento

Per una gestione più semplice, ad esempio per eseguire ricerche e modifiche in blocco per l'importazione, è possibile usare il cmdlet Export-Csv per esportare i risultati in un foglio di calcolo.

Ad esempio: Get-MsolGroup | select DisplayName, ProxyAddresses | Export-Csv -Path UserAccounts.csv

Nota

Con le modifiche UPN per gli utenti, si verifica una perdita di continuità aziendale per almeno 24 ore o fino a quando le modifiche UPN non vengono riflesse correttamente nel sistema.

Verificare se gli account di gruppo sono pronti per Azure Information Protection

Per verificare gli account di gruppo, usare il comando seguente:

Get-MsolGroup | select DisplayName, ProxyAddresses

Assicurarsi che siano visualizzati i gruppi che si vogliono usare con Azure Information Protection. Per l'autorizzazione dei membri dei gruppi visualizzati per il servizio Azure Rights Management è possibile usare gli indirizzi di posta elettronica nella colonna ProxyAddresses.

Controllare quindi che i gruppi contengano gli utenti (o gli altri gruppi) che si vogliono usare per Azure Information Protection. A tale scopo è possibile usare un cmdlet di PowerShell (ad esempio, Get-MsolGroupMember) o il portale di gestione.

Per i due scenari di configurazione del servizio Azure Rights Management che usano gruppi di sicurezza, è possibile trovare l'ID oggetto e il nome visualizzato che consentono di identificare questi gruppi tramite il comando PowerShell seguente. Per trovare questi gruppi e copiare i valori relativi all'ID oggetto e al nome visualizzato, è anche possibile usare il portale di Azure:

Get-MsolGroup | where {$_.GroupType -eq "Security"}

Considerazioni su Azure Information Protection in caso di modifica di indirizzi di posta elettronica

Se si modifica l'indirizzo di posta elettronica di un utente o di un gruppo, è consigliabile aggiungere l'indirizzo di posta elettronica precedente come secondo indirizzo di posta elettronica (detto anche indirizzo proxy, alias o indirizzo di posta elettronica alternativo) per l'utente o il gruppo. Quando si esegue questa operazione, l'indirizzo di posta elettronica precedente viene aggiunto all'attributo proxyAddresses di Microsoft Entra. Questo tipo di amministrazione degli account garantisce la continuità aziendale per i diritti di utilizzo e per le altre configurazioni salvate quando era in uso l'indirizzo di posta elettronica precedente.

Se non è possibile eseguire questa operazione, all'utente o al gruppo con il nuovo indirizzo di posta elettronica potrebbe essere negato l'accesso a documenti e messaggi di posta elettronica protetti in precedenza con l'indirizzo di posta elettronica precedente. In questo caso, è necessario ripetere la configurazione di protezione per salvare il nuovo indirizzo di posta elettronica. Ad esempio, se all'utente o al gruppo sono stati concessi i diritti di utilizzo nei modelli o nelle etichette, modificare i modelli o le etichette e specificare il nuovo indirizzo di posta elettronica con gli stessi diritti di utilizzo concessi all'indirizzo di posta elettronica precedente.

Si noti che è raro che per un gruppo venga modificato l'indirizzo di posta elettronica. Se si assegnano diritti di utilizzo a un gruppo anziché a utenti singoli e l'indirizzo di posta elettronica di uno o più utenti cambia, non si verificano problemi. In questo scenario, i diritti di utilizzo vengono assegnati all'indirizzo di posta elettronica del gruppo e non agli indirizzi di posta elettronica dei singoli utenti. Questo è il metodo usato dagli amministratori con maggiore frequenza, oltre che il metodo consigliato, per la configurazione dei diritti di utilizzo che proteggono documenti e messaggi di posta elettronica. In genere, tuttavia, gli utenti assegnano autorizzazioni personalizzate a utenti singoli. Poiché non è sempre possibile sapere se per concedere l'accesso è stato usato un account utente o di gruppo, il metodo più sicuro è aggiungere sempre l'indirizzo di posta elettronica precedente come secondo indirizzo di posta elettronica.

Caching dell'appartenenza a gruppi da parte di Azure Rights Management

Per motivi di prestazioni, l'appartenenza ai gruppi viene memorizzata nella cache dal servizio Azure Rights Management. Ciò significa che le modifiche apportate all'appartenenza al gruppo in Microsoft Entra ID possono richiedere fino a tre ore per rendere effettive tali gruppi quando questi gruppi vengono usati da Azure Information Protection e questo periodo di tempo è soggetto a modifiche.

Se si usano gruppi in Azure Rights Management, si ricordi di tenere conto di questo ritardo in caso di modifiche o esecuzione di test, ad esempio in caso di assegnazione di diritti di utilizzo o di configurazione del servizio Azure Rights Management.

Passaggi successivi

Dopo aver verificato che gli utenti e i gruppi possono essere usati con Azure Information Protection e si è pronti per iniziare a proteggere documenti e messaggi di posta elettronica, verificare se è necessario attivare il servizio Azure Rights Management. Questo servizio deve essere attivato prima di poter proteggere i documenti e i messaggi di posta elettronica dell'organizzazione:

• A partire da febbraio 2018: se la sottoscrizione che include Azure Rights Management o Azure Information Protection è stata ottenuta durante o dopo questo mese, il servizio viene attivato automaticamente.

• Se la sottoscrizione è stata ottenuta prima di febbraio 2018: è necessario attivare il servizio manualmente.

Per altre informazioni, che include il controllo dello stato di attivazione, vedere Attivazione del servizio di protezione da Azure Information Protection.