Domande frequenti per il client classico di Azure Information Protection
Quando è il momento giusto per eseguire la migrazione delle etichette all'etichettatura unificata?
È consigliabile eseguire la migrazione delle etichette di Azure Information Protection alla piattaforma di etichettatura unificata in modo da poterli usare come etichette di riservatezza con altri client e servizi che supportano l'etichettatura unificata.
Per altre informazioni e istruzioni, vedere Come eseguire la migrazione delle etichette di Azure Information Protection alle etichette di riservatezza unificata.
È necessario ricrittografare i file dopo aver spostato le etichette di riservatezza e la piattaforma di etichettatura unificata?
No, non è necessario crittografare nuovamente i file dopo aver spostato le etichette di riservatezza e la piattaforma di etichettatura unificata dopo la migrazione dal client classico AIP e le etichette gestite nel portale di Azure.
Dopo la migrazione, gestire le etichette e i criteri di etichettatura dal centro conformità Microsoft 365.
Per altre informazioni, vedere Informazioni sulle etichette di riservatezza nella documentazione di Microsoft 365 e nel blog Informazioni sulla migrazione dell'etichettatura unificata.
Qual è la differenza tra le etichette in Microsoft 365 e le etichette in Azure Information Protection?
Originariamente, Microsoft 365 aveva solo etichette di conservazione, che consentono di classificare documenti e messaggi di posta elettronica per il controllo e la conservazione quando il contenuto è stato archiviato nei servizi di Microsoft 365.
Al contrario, le etichette di Information Protection di Azure, configurate al momento usando il client classico AIP nel portale di Azure, consentono di applicare criteri di classificazione e protezione coerenti per documenti e messaggi di posta elettronica che siano stati archiviati in locale o nel cloud.
Microsoft 365 supporta etichette di riservatezza oltre alle etichette di conservazione. Le etichette di riservatezza possono essere create e configurate nel centro conformità Microsoft 365.
Se le etichette AIP legacy sono configurate nella portale di Azure, è consigliabile eseguirne la migrazione alle etichette di riservatezza e al client di etichettatura unificata. Per altre informazioni, vedere Esercitazione: Migrazione dal client classico al client di etichettatura unificata di Azure Information Protection (AIP).
Per altre informazioni, vedere Announcing availability of information protection capabilities to help protect your sensitive data (Annuncio della disponibilità di funzionalità di protezione delle informazioni per proteggere i dati sensibili).
Il client Azure Information Protection è disponibile solo per le sottoscrizioni che includono la classificazione e l'assegnazione di etichette?
No. Il client AIP classico può essere usato anche con le sottoscrizioni che includono solo il servizio azure Rights Management, solo per la protezione dei dati.
Quando il client classico viene installato senza un criterio di Information Protection di Azure, il client opera automaticamente in modalità di sola protezione, che consente agli utenti di applicare modelli di Rights Management e autorizzazioni personalizzate.
Se successivamente si acquista una sottoscrizione che include la classificazione e l'assegnazione di etichette, il client passa automaticamente alla modalità standard durante il download dei criteri di Azure Information Protection.
Impostazione dei proprietari di Rights Management
Per impostazione predefinita, sia per l'istanza del server di Windows che per lo scanner di Azure Information Protection, il proprietario del Rights Management è impostato sull'account che protegge il file.
Eseguire l'override delle impostazioni predefinite come indicato di seguito:
Windows Server FCI: impostare il proprietario del Rights Management come singolo account per tutti i file o impostare dinamicamente il proprietario Rights Management per ogni file.
Per impostare in modo dinamico il proprietario di Rights Management, usare il parametro -OwnerMail [posta elettronica proprietario file di origine] e relativo valore. Questa configurazione recupera l'indirizzo di posta elettronica dell'utente da Active Directory usando il nome dell'account utente specificato nella proprietà del proprietario del file.
Scanner di Azure Information Protection: per i file appena protetti, impostare il proprietario di Rights Management come singolo account per tutti i file in un archivio dati specificato, specificando l'impostazione del proprietario -Default nel profilo dello scanner.
L'impostazione dinamica del proprietario Rights Management per ogni file non è supportata e il proprietario del Rights Management non viene modificato per i file protetti in precedenza.
Nota
Quando lo scanner protegge i file inclusi in siti e librerie di SharePoint, il proprietario di Rights Management viene impostato in modo dinamico per ogni file usando il valore Editor di SharePoint.
Un file può avere più di una classificazione?
Poiché gli utenti possono selezionare una sola etichetta alla volta per ogni documento o messaggio di posta elettronica, la classificazione è spesso una sola. Tuttavia, se gli utenti selezionano un'etichetta secondaria, vengono effettivamente applicate due etichette contemporaneamente, ovvero un'etichetta primaria e un'etichetta secondaria. Se si usano etichette secondarie, il file può avere due classificazioni che indicano una relazione padre/figlio per un ulteriore livello di controllo.
Ad esempio, l'etichetta Confidential potrebbe contenere sottolabels, ad esempio Legal and Finance. È possibile applicare contrassegni visivi di classificazione e modelli di Rights Management diversi alle etichette secondarie. Un utente non può selezionare l'etichetta Riservato per se stessa; solo uno dei suoi sottolabelli, ad esempio Legal. Di conseguenza, l'etichetta impostata visualizzata dall'utente sarà Confidential \ Legal (Riservato \ Legale). I metadati di tale file includono una sola proprietà di testo personalizzato per Confidential (Riservato), una proprietà di testo personalizzato per Legal (Legale) e un'altra proprietà che contiene entrambi i valori, Confidential Legal (Riservato Legale).
Quando si usano etichette secondarie, non configurare contrassegni visivi, protezione e condizioni nell'etichetta principale. Quando si usano etichette secondarie, configurare queste impostazioni solo nell'etichetta secondaria. Se si configurano le impostazioni nell'etichetta principale e nella relativa etichetta secondaria, le impostazioni dell'etichetta secondaria hanno priorità.
Come si può impedire a un utente di rimuovere o modificare un'etichetta?
Anche se è presente un'impostazione di criteri che richiede agli utenti di specificare il motivo per cui stanno riducendo un'etichetta di classificazione, rimuovendo un'etichetta o rimuovendo la protezione, questa impostazione non impedisce queste azioni. Per impedire agli utenti di rimuovere o modificare un'etichetta, il contenuto deve essere già protetto e le autorizzazioni di protezione non concedere all'utente il diritto di utilizzo Esporta o Controllo completo
Come è possibile integrare soluzioni DLP e altre applicazioni con Azure Information Protection?
Per la classificazione, Azure Information Protection usa metadati persistenti che includono un'etichetta di testo non crittografata. Queste informazioni possono essere lette da soluzioni DLP e da altre applicazioni.
Per altre informazioni su questi metadati, vedere Etichettare le informazioni archiviate in documenti e messaggi di posta elettronica.
Per esempi dell'uso di questi metadati con le regole del flusso di posta di Exchange Online, vedere Configurazione delle regole del flusso di posta per le etichette di Exchange Online.
È possibile creare un modello di documento che include automaticamente la classificazione?
Sì. È possibile configurare un'etichetta per applicare un'intestazione o un piè di pagina che include il nome dell'etichetta. Tuttavia, se non soddisfa i requisiti, solo per il client classico di Azure Information Protection è possibile creare un modello di documento con la formattazione desiderata e aggiungere la classificazione come codice di campo.
Ad esempio, si potrebbe usare una tabella nell'intestazione del documento che visualizza la classificazione. Oppure usare una formulazione specifica per un'introduzione che fa riferimento alla classificazione del documento.
Per aggiungere questo codice di campo nel documento:
Etichettare il documento e salvarlo. Questa azione consente di creare nuovi campi di metadati che è ora possibile usare per il codice di campo.
Nel documento, posizionare il cursore dove si vuole aggiungere la classificazione dell'etichetta e quindi nella scheda Inserisci selezionare Testo>Parti rapide>Campo.
Nella finestra di dialogo Campo selezionare Informazioni documento nell'elenco a discesa Categorie. Nell'elenco a discesa Nome campi selezionare quindi DOCPROPERTY.
Nell'elenco a discesa Proprietà selezionare Riservatezza e selezionare OK.
La classificazione dell'etichetta corrente viene visualizzata nel documento e questo valore verrà aggiornato automaticamente ogni volta che si apre il documento o si usa il modello. Pertanto, se l'etichetta cambia, la classificazione visualizzata per questo codice di campo viene aggiornata automaticamente nel documento.
In che modo la classificazione per i messaggi di posta elettronica tramite Azure Information Protection diversa dalla classificazione dei messaggi Exchange?
Exchange classificazione dei messaggi è una funzionalità precedente che può classificare i messaggi di posta elettronica e viene implementata in modo indipendente dalle etichette di Azure Information Protection o etichette di riservatezza che applicano la classificazione.
Tuttavia, è possibile integrare questa funzionalità precedente con le etichette, in modo che quando gli utenti classificano un messaggio di posta elettronica usando Outlook sul web e usando alcune applicazioni di posta mobile, la classificazione delle etichette e i contrassegni di etichette corrispondenti vengono aggiunti automaticamente.
È possibile applicare la stessa tecnica per usare le etichette con Outlook sul web e le applicazioni di posta elettronica per dispositivi mobili.
Si noti che non è necessario eseguire questa operazione se si usa Outlook sul web con Exchange Online, perché questa combinazione supporta l'etichettatura predefinita quando si pubblicano etichette di riservatezza dal centro conformità Microsoft 365.
Se non è possibile usare l'etichettatura predefinita con Outlook sul web, vedere i passaggi di configurazione per questa soluzione alternativa: Integrazione con la classificazione dei messaggi di Exchange legacy
Come si configura un computer Mac per proteggere e rilevare i documenti?
Prima di tutto, assicurarsi di avere installato Office per Mac usando il collegamento di installazione software da https://admin.microsoft.com. Per istruzioni complete, vedere Scaricare e installare o reinstallare Microsoft 365 o Office 2019 in un PC o Mac.
Aprire Outlook e creare un profilo usando l'account aziendale o dell'istituto di istruzione Microsoft 365. Creare un nuovo messaggio, quindi eseguire le operazioni seguenti per configurare Office in modo che possa proteggere documenti e messaggi di posta elettronica usando il servizio Azure Rights Management:
Nel nuovo messaggio, nella scheda Opzioni fare clic su Autorizzazioni, quindi fare clic su Verifica credenziali.
Quando richiesto, specificare di nuovo i dettagli dell'account aziendale o dell'istituto di istruzione Microsoft 365 e selezionare Accedi.
Vengono scaricati i modelli di Azure Rights Management e Verifica credenziali viene sostituito da opzioni che includono Nessuna restrizione, Non inoltrare, nonché tutti i modelli di Azure Rights Management pubblicati per il tenant. Ora è possibile annullare questo nuovo messaggio.
Per proteggere un messaggio di posta elettronica o un documento: nella scheda Opzioni fare clic su Autorizzazioni e scegliere un'opzione o un modello che protegga il messaggio di posta elettronica o il documento.
Per tenere traccia di un documento dopo averla protetta: da un computer Windows con il client di Azure Information Protection classico installato, registrare il documento con il sito di rilevamento dei documenti usando un'applicazione Office o Esplora file. Per le istruzioni, vedere Rilevare e revocare i documenti. Dal computer Mac è ora possibile usare il Web browser per passare al sito di rilevamento dei documenti (https://track.azurerms.com) per tenere traccia e revocare questo documento.
Quando si esegue il test delle revoche nel sito di rilevamento dei documenti, viene visualizzato un messaggio che informa che gli utenti possono continuare ad accedere al documento fino a 30 giorni: è possibile configurare questo periodo di tempo?
Sì. Questo messaggio riflette la licenza d'uso per quel file specifico.
Se si revoca un file, tale azione può essere applicata solo quando l'utente viene autenticato per il servizio Azure Rights Management. Pertanto, se un file ha un periodo di validità della licenza d'uso di 30 giorni e l'utente ha già aperto il documento, l'utente continua ad avere accesso al documento per la durata della licenza d'uso. Quando la licenza scade, l'utente deve ripetere l'autenticazione e a quel punto gli viene negato l'accesso perché il documento ormai è revocato.
L'utente che ha protetto il documento, l'autorità di certificazione di Rights Management, è esente da questa revoca e può sempre accedere ai propri documenti.
Il valore predefinito per il periodo di validità della licenza d'uso per un tenant è di 30 giorni e questa impostazione può essere modificata da un'impostazione più restrittiva in un'etichetta o un modello. Per altre informazioni sulla licenza d'uso e su come configurarla, vedere la documentazione sulla licenza d'uso di Rights Management.
Qual è la differenza tra BYOK e HYOK e quando usarli?
Bring your own key (BYOK) nel contesto di Azure Information Protection è il caso in cui si crea la propria chiave locale per la protezione di Azure Rights Management, quindi si trasferisce la chiave a un modulo di protezione hardware (HSM) in Azure Key Vault dove si continua a essere proprietari della chiave e a gestirla. Se non si esegue questa operazione, la protezione di Azure Rights Management userà una chiave che viene creata e gestita automaticamente in Azure. Questa configurazione predefinita è detta "gestita da Microsoft" anziché "gestita dal cliente" (opzione BYOK).
Per altre informazioni sulla modalità BYOK e se sia consigliabile scegliere questa topologia di chiave per l'organizzazione, vedere Pianificazione e implementazione della chiave del tenant di Azure Information Protection.
Hold your own key (HYOK) nel contesto di Azure Information Protection serve alle poche organizzazioni che hanno un subset di documenti o messaggi di posta elettronica che non possono essere protetti da una chiave archiviata nel cloud. Per queste organizzazioni si applica tale restrizione anche se hanno creato e gestito la chiave usando la modalità BYOK. La restrizione è spesso dovuta a ragioni normative o di conformità e la configurazione HYOK deve essere applicata solo alle informazioni "top secret" che non saranno mai condivise all'esterno dell'organizzazione, ma usate solo nella rete interna, e non devono essere accessibili da dispositivi mobili.
Per queste eccezioni (in genere inferiori al 10% di tutti i contenuti che devono essere protetti), le organizzazioni possono usare una soluzione locale, Active Directory Rights Management Services, per creare la chiave che rimane locale. Con questa soluzione i computer ottengono i criteri di Azure Information Protection dal cloud, ma questo contenuto identificato può essere protetto usando la chiave locale.
Per altre informazioni su HYOK e per assicurarsi di aver compreso le relative linee guida, limitazioni e restrizioni di utilizzo, vedere Requisiti e restrizioni HYOK per la protezione di AD RMS.
Cosa faccio se la mia domanda non è qui?
Prima di tutto, esaminare le domande frequenti elencate di seguito, specifiche per la classificazione e l'etichettatura o specifiche per la protezione dei dati. Il servizio Azure Rights Management (Azure RMS) offre la tecnologia di protezione dei dati per Azure Information Protection. Azure RMS può essere usato con la classificazione e l'assegnazione di etichette o in modo indipendente.
Se la domanda non viene risposta, vedere i collegamenti e le risorse elencati in Informazioni e supporto per Azure Information Protection.
Esistono anche Domande frequenti progettate per gli utenti finali: