Funzionamento di Azure RMS: Informazioni dettagliate

Riguardo al funzionamento Azure RMS, è importante comprendere che questo servizio di protezione dati di Azure Information Protection, non consente di visualizzare o archiviare i dati come parte del processo di protezione. Le informazioni protette non vengono mai inviate o archiviate in Azure, a meno che non vengano archiviate in modo esplicito in Azure o non venga usato un altro servizio cloud che le archivia in Azure. Azure RMS rende i dati di un documento semplicemente illeggibili a chiunque, eccetto gli utenti e i servizi autorizzati:

• I dati vengono crittografati a livello di applicazione e includono un criterio che definisce l'uso autorizzato per quel documento.

• Quando un documento protetto è usato da un utente valido o è processato da un servizio autorizzato, i dati nei documenti vengono decrittografati e vengono applicati i diritti definiti nei criteri.

A un livello elevato, è possibile visualizzare il funzionamento del processo nell'immagine seguente. Un documento contenente la formula segreta viene protetto e quindi aperto con successo da un utente o da un servizio autorizzato. Il documento è protetto da una chiave simmetrica (la chiave verde in questa immagine). Questa è univoca per ogni documento e posizionata nell'intestazione del file dove è protetto dalla chiave radice del tenant Azure Information Protection (la chiave rossa in questa immagine). La chiave del tenant può essere generata e gestita da Microsoft oppure è possibile generare e gestire la propria chiave del tenant.

Durante il processo di protezione quando Azure RMS crittografa e decrittografa, autorizza e applica restrizioni, la formula segreta non viene mai inviata ad Azure.

Per una descrizione dettagliata delle operazioni eseguite, vedere la sezioneProcedura dettagliata del funzionamento di Azure RMS: primo utilizzo, protezione del contenuto, uso del contenuto in questo articolo.

Per informazioni tecniche sugli algoritmi e lunghezze delle chiavi usate in Azure RMS, vedere la sezione successiva.

Controlli crittografici usati in Azure RMS: algoritmi e lunghezze delle chiavi

Anche se non è necessario conoscere nel dettaglio il funzionamento di questa tecnologia, è possibile che vengano richieste informazioni sui controlli crittografici usati, ad esempio, per verificare che la sicurezza sia conforme agli standard del settore.

Nota 1

I 256 bit vengono usati dal client Azure Information Protection negli scenari seguenti:

• Protezione generica (con estensione pfile).

• Protezione nativa per i documenti PDF quando il documento è stato protetto con lo standard ISO per la crittografia PDF o il documento protetto risultante ha un'estensione con estensione ppdf.

• Protezione nativa per file di testo o immagine, ad esempio .ptxt o pjpg.

Nota 2

2048 bit è la lunghezza della chiave al momento dell'attivazione del servizio Azure Rights Management. La lunghezza di 1024 bit è supportata per gli scenari facoltativi seguenti:

• Durante la migrazione da locale, se il cluster AD RMS è in esecuzione in Modalità crittografia 1.

• Per le chiavi archiviate create in locale prima della migrazione in modo che il contenuto protetto da AD RMS possa continuare a essere aperto dopo la migrazione ad Azure Rights Management.

Modalità di archiviazione e protezione delle chiavi crittografiche di Azure RMS

Per ogni documento o messaggio di posta elettronica protetto da Azure RMS, viene creata una singola chiave AES ("chiave simmetrica") e tale chiave viene incorporata nel documento e viene salvata in modo permanente nelle diverse edizioni del documento.

La chiave simmetrica viene protetta dalla chiave RSA dell'organizzazione ("chiave del tenant di Azure Information Protection") nell'ambito dei criteri del documento e i criteri vengono anche firmati dall'autore del documento. Questa chiave del tenant è comune a tutti i documenti e a tutti i messaggi di posta elettronica protetti dal servizio Azure Rights Management per l'organizzazione e la chiave può essere modificata solo da un amministratore di Azure Information Protection se l'organizzazione usa una chiave del tenant gestita dai clienti, nota come chiave BYOK (Bring Your Own Key).

La chiave del tenant è protetta nei servizi online di Microsoft, in un ambiente a controllo elevato e sotto attento monitoraggio. Quando si usa una chiave del tenant gestita dal cliente (BYOK), la sicurezza è ottimizzata mediante l'uso di una matrice di moduli di protezione hardware di qualità elevata (HSM) in ogni area di Azure. Le chiavi non possono essere estratte, esportate o condivise in alcuna circostanza. Per altre informazioni sulla chiave del tenant e su BYOK, vedere Pianificazione e implementazione della chiave del tenant di Azure Information Protection.

Le licenze e i certificati inviati a un dispositivo Windows sono protetti tramite la chiave privata del dispositivo del client, che viene creata al primo utilizzo di Azure RMS sul dispositivo da parte di un utente. Questa chiave privata è a sua volta protetta con DPAPI nel client che protegge questi segreti usando una chiave derivata dalla password dell'utente. Nei dispositivi mobili le chiavi vengono usate solo una volta. Non essendo archiviate nei client, queste chiavi non devono essere quindi protette nel dispositivo.

Procedura dettagliata del funzionamento di Azure RMS: primo utilizzo, protezione del contenuto, uso del contenuto

Per comprendere in modo più dettagliato il funzionamento di Azure RMS, viene illustrato un flusso tipico dopo l'attivazione del servizio Azure Rights Management e quando un utente usa per la prima volta il servizio Rights Management nel proprio computer Windows (un processo definito a volte inizializzazione dell'ambiente utente o bootstrap), protegge il contenuto (un documento o un messaggio di posta elettronica) e quindi usa (apre e usa) il contenuto protetto da altri.

Dopo aver inizializzato l'ambiente utente, l'utente può quindi proteggere i documenti o utilizzare documenti protetti su quel computer.

Inizializzazione dell'ambiente utente

Prima che un utente sia in grado di proteggere il contenuto o usare contenuto protetto in un computer Windows, è necessario preparare l'ambiente utente sul dispositivo. Questo è un processo unico e si verifica automaticamente senza l'intervento dell'utente quando un utente tenta di proteggere o usare contenuto protetto:

Cosa accade nel passaggio 1: il client RMS nel computer si connette prima al servizio Azure Rights Management e autentica l'utente usando il proprio account Microsoft Entra.

Quando l'account dell'utente è federato con Microsoft Entra ID, questa autenticazione è automatica e all'utente non vengono richieste le credenziali.

Cosa avviene nel passaggio 2: dopo l'autenticazione dell'utente, la connessione viene reindirizzata automaticamente al tenant di Azure Information Protection dell'organizzazione, che emette i certificati per consentire all'utente di autenticarsi al servizio Azure Rights Management in modo da usare il contenuto protetto e proteggere il contenuto offline.

Uno di questi certificati è il certificato dell'account rights, spesso abbreviato in RAC. Questo certificato autentica l'utente in Microsoft Entra ID ed è valido per 31 giorni. Il certificato viene rinnovato automaticamente dal client RMS, specificando che l'account utente è ancora in ID Microsoft Entra e l'account è abilitato. Questo certificato non è configurabile da un amministratore.

Una copia di questo certificato viene archiviata in Azure in modo che, se l'utente passa a un altro dispositivo, i certificati vengono creati usando le stesse chiavi.

Protezione del contenuto

Quando un utente protegge un documento, il client RMS esegue le azioni seguenti su un documento non protetto:

Cosa avviene nel passaggio 1: il client RMS crea una chiave casuale (la chiave simmetrica) e crittografa il documento usando questa chiave con l'algoritmo di crittografia simmetrica AES.

Cosa avviene nel passaggio 2: il client RMS crea quindi un certificato che include i criteri per il documento contenenti i diritti di uso per utenti e gruppi e altre restrizioni, ad esempio una data di scadenza. Queste impostazioni possono essere definite in un modello configurato in precedenza da un amministratore o specificate quando il contenuto viene protetto (sono chiamate anche "criteri ad hoc").

L'attributo principale di Microsoft Entra usato per identificare gli utenti e i gruppi selezionati è l'attributo Microsoft Entra ProxyAddresses, che archivia tutti gli indirizzi di posta elettronica per un utente o un gruppo. Tuttavia, se per un account utente non sono presenti valori in questo attributo, viene usato il valore UserPrincipalName dell'utente.

Il client RMS usa quindi la chiave dell'organizzazione, ottenuta al momento dell'inizializzazione dell'ambiente utente, per crittografare i criteri e la chiave simmetrica. Il client RMS firma anche i criteri con il certificato dell'utente ottenuti al momento dell'inizializzazione dell'ambiente.

Cosa accade nel passaggio 3: Infine, il client RMS incorpora i criteri in un file con il corpo del documento crittografato in precedenza, che insieme costituiscono un documento protetto.

Questo documento può essere archiviato ovunque o condiviso usando qualsiasi metodo. I criteri rimangono sempre incorporati nel documento.

Uso del contenuto

Quando un utente vuole usare un documento protetto, il client RMS avvia la richiesta per l'accesso al servizio Azure Rights Management:

Cosa avviene nel passaggio 1: l'utente autenticato invia i criteri del documento e i certificati dell'utente al servizio Azure Rights Management. Il servizio decrittografa e valuta i criteri e compila un elenco di diritti (se presenti) di cui l'utente dispone per il documento. Per identificare l'utente, l'attributo Microsoft Entra ProxyAddresses viene usato per l'account e i gruppi dell'utente a cui l'utente è membro. Per motivi di prestazioni, l'appartenenza ai gruppi per i criteri di ambito viene memorizzata nella cache. Se l'account utente non ha valori per l'attributo Microsoft Entra ProxyAddresses, viene invece utilizzato il valore in Microsoft Entra UserPrincipalName.

Cosa avviene nel passaggio 2: il servizio estrae quindi la chiave simmetrica AES dai criteri decrittografati. Questa chiave viene quindi crittografata con la chiave pubblica RSA dell'utente ottenuta con la richiesta.

La chiave simmetrica nuovamente crittografata viene quindi incorporata in una licenza d'uso crittografata con l'elenco dei diritti dell'utente, che viene quindi restituito al client RMS.

Cosa avviene nel passaggio 3: infine, il client RMS accetta il la licenza d'uso crittografata e la decrittografa con la propria chiave privata utente. In questo modo il client RMS decrittografa il corpo del documento quando è necessario e ne esegue il rendering sullo schermo.

Il client decrittografa anche l'elenco di diritti e li passa all'applicazione, che li applica nell'interfaccia utente dell'applicazione.

Variazioni

Le procedure dettagliate precedenti riguardano scenari standard, ma esistono alcune varianti:

• Protezione della posta elettronica: quando Exchange Online e Office 365 Message Encryption con nuove funzionalità vengono usati per proteggere i messaggi di posta elettronica, l'autenticazione per l'utilizzo può anche usare la federazione con un provider di identità social o usando un passcode monouso. I flussi di processo sono quindi molto simili, ad eccezione del fatto che l'utilizzo del contenuto avviene sul lato servizio in una sessione del Web browser su una copia memorizzata temporaneamente nella cache del messaggio di posta elettronica in uscita.

• Dispositivi mobili: quando i dispositivi mobili proteggono o usano file con il servizio Azure Rights Management, i flussi del processo sono molto più semplici. I dispositivi mobili non vengono prima sottoposti al processo di inizializzazione utente, perché ogni transazione (di protezione o uso del contenuto) è invece indipendente. Come con i computer Windows, i dispositivi mobili si connettono al servizio Azure Rights Management ed eseguono l'autenticazione. Per proteggere il contenuto, i dispositivi mobili inviano i criteri e il servizio Azure Rights Management invia una licenza di pubblicazione e la chiave simmetrica per proteggere il documento. Per usare il contenuto, quando i dispositivi mobili si connettono al servizio Azure Rights Management ed eseguono l'autenticazione, inviano i criteri del documento al servizio Azure Rights Management e richiedono una licenza d'uso per utilizzare il documento. In risposta, il servizio Azure Rights Management invia le chiavi e le restrizioni necessarie ai dispositivi mobili. Entrambi i processi usano TLS per proteggere lo scambio di chiavi e altre comunicazioni.

• Connettore RMS: quando il servizio Azure Rights Management viene usato con il connettore RMS, i flussi del processo rimangono invariati. L'unica differenza è che il connettore opera come un relè tra i servizi locali, ad esempio Exchange Server e SharePoint Server, e il servizio Azure Rights Management. Il connettore stesso non esegue alcuna operazione, ad esempio l'inizializzazione dell'ambiente utente, né crittografia o decrittografia. Inoltra semplicemente la comunicazione indirizzata solitamente a un server AD RMS, gestendo la conversione tra i protocolli usati su ogni lato. Questo scenario consente di usare il servizio Azure Rights Management con i servizi locali.

• Protezione generica (pfile): quando il servizio Azure Rights Management protegge un file in modo generico, il flusso è fondamentalmente quello della protezione del contenuto, con la differenza che il client RMS crea i criteri che concedono tutti i diritti. Quando si usa il file, questo viene decrittografato prima di essere passato all'applicazione di destinazione. Questo scenario consente di proteggere tutti i file, anche se non supportano RMS in modo nativo.

• Account Microsoft: Azure Information Protection può autorizzare gli indirizzi di posta elettronica per l'utilizzo 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. Altre informazioni.

Passaggi successivi

Per altre informazioni sul servizio Azure Rights Management, vedere gli altri articoli della sezione Comprendere ed esplorare, ad esempio Supporto del servizio Azure Rights Management da parte delle applicazioni, in cui viene spiegato come integrare le applicazioni esistenti in Azure Rights Management per fornire una soluzione di protezione delle informazioni.

Rivedere l'argomento Terminologia di Azure Information Protection per acquisire familiarità con i termini relativi alla configurazione e all'uso del servizio Azure Rights Management. Prima di iniziare la distribuzione, esaminare anche le informazioni riportate in Requisiti per Azure Information Protection. Se vuoi approfondire e provarlo manualmente, usa la guida introduttiva e le esercitazioni:

• Guida introduttiva: Distribuire il client di etichettatura unificata
• Esercitazione: Installazione dello scanner di etichettatura unificata di Azure Information Protection (AIP)
• Esercitazione: Trovare il contenuto sensibile con lo scanner di Azure Information Protection (AIP)
• Esercitazione: Prevenzione dell'oversharing in Outlook con Azure Information Protection (AIP)

Se si è pronti per iniziare a distribuire la protezione dei dati per l'organizzazione, usare la roadmap per la distribuzione di AIP per la classificazione, l'etichettatura e la protezione per i passaggi di distribuzione e i collegamenti per istruzioni sulle procedure.