Come funziona Azure RMS? Sotto il cappuccio

Una cosa importante da capire sul funzionamento di Azure RMS è che questo servizio di protezione dei dati di Azure Information Protection, non visualizza o archivia i dati nell'ambito del processo di protezione. Le informazioni che si proteggono non vengono mai inviate o archiviate in Azure, a meno che non vengano archiviate esplicitamente in Azure o non si usi un altro servizio cloud che lo archivia in Azure. Azure RMS rende i dati in un documento illeggibili per chiunque non sia utenti e servizi autorizzati:

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

  • Quando un documento protetto viene usato da un utente legittimo o elaborato da un servizio autorizzato, i dati contenuti nel documento vengono decrittografati e vengono applicati i diritti definiti nei criteri.

In generale, è possibile vedere come funziona questo processo nell'immagine seguente. Un documento che contiene la formula segreta è protetto e quindi aperto correttamente da un utente o un servizio autorizzato. Il documento è protetto da una chiave di contenuto (la chiave verde nell'immagine). È univoco per ogni documento e viene inserito nell'intestazione del file, dove è protetto dalla chiave radice del tenant di 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 tenant.

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

How Azure RMS protects a file

Per una descrizione dettagliata di ciò che accade, vedere la sezione Procedura dettagliata sul funzionamento di Azure RMS: primo utilizzo, protezione del contenuto e utilizzo del contenuto in questo articolo.

Per informazioni tecniche sugli algoritmi e sulle lunghezze dei tasti usati da Azure RMS, vedere la sezione successiva.

Controlli crittografici usati da Azure RMS: algoritmi e lunghezze di chiave

Anche se non è necessario conoscere in dettaglio il funzionamento di questa tecnologia, è possibile che venga chiesto di conoscere i controlli di crittografia usati. Ad esempio, per confermare che la protezione della sicurezza è standard del settore.

Controlli crittografici Usare in Azure RMS
Algoritmo: AES

Lunghezza chiave: 128 bit e 256 bit [1]
Protezione del contenuto
Algoritmo: RSA

Lunghezza chiave: 2048 bit [2]
Protezione chiave
SHA-256 Firma del certificato
Nota a piè di pagina 1

I 256 bit vengono usati dal client azure Information Protection nei seguenti scenari:

  • Protezione generica (pfile).

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

  • Protezione nativa per i file di testo o di immagine (ad esempio .ptxt o .pjpg).

Nota a piè di pagina 2

2048 bit è la lunghezza chiave quando viene attivato il servizio Azure Rights Management. 1024 bit è supportato per i seguenti scenari facoltativi:

  • Durante una migrazione da locale se il cluster AD RMS è in esecuzione in modalità di crittografia 1.

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

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

Per ogni documento o messaggio di posta elettronica protetto da Azure RMS, Azure RMS crea una singola chiave AES (la "chiave contenuto") e tale chiave viene incorporata nel documento e viene mantenuta tramite le edizioni del documento.

La chiave contenuto è protetta con la chiave RSA dell'organizzazione (la "chiave tenant di Azure Information Protection") nell'ambito dei criteri nel documento e il criterio è firmato anche dall'autore del documento. Questa chiave tenant è comune in tutti i documenti e i messaggi di posta elettronica protetti dal servizio Azure Rights Management per l'organizzazione e questa chiave può essere modificata da un amministratore di Azure Information Protection solo se l'organizzazione usa una chiave tenant gestita dal cliente (nota come "Bring Your Own Key" o BYOK).

Questa chiave tenant è protetta nel Servizi online Microsoft, in un ambiente altamente controllato e sotto stretto monitoraggio. Quando si usa una chiave di tenant gestita dal cliente (BYOK), questa sicurezza viene migliorata dall'uso di una matrice di moduli di sicurezza hardware di fascia alta in ogni area geografica di Azure, senza la possibilità di estrarre, esportare o condividere le chiavi in qualsiasi circostanza. Per altre informazioni sulla chiave tenant e BYOK, vedere Pianificazione e implementazione della chiave tenant di Azure Information Protection.

Le licenze e i certificati inviati a un dispositivo Windows sono protetti con la chiave privata del dispositivo del client, che viene creata la prima volta che un utente nel dispositivo usa Azure RMS. 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 una sola volta, quindi, poiché non sono archiviate nei client, non devono essere protette nel dispositivo.

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

Per comprendere in modo più dettagliato il funzionamento di Azure RMS, vediamo 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 computer Windows (processo noto a volte come inizializzazione dell'ambiente utente o di avvio), protegge il contenuto (un documento o un messaggio di posta elettronica) e quindi utilizza (apre e usa) il contenuto che è stato protetto da qualcun altro.

Dopo l'inizializzazione dell'ambiente utente, l'utente può proteggere i documenti o utilizzare i documenti protetti in tale computer.

Nota

Se l'utente passa a un altro computer Windows o un altro utente usa lo stesso Windows computer, il processo di inizializzazione viene ripetuto.

Inizializzazione dell'ambiente utente

Prima che un utente possa proteggere il contenuto o utilizzare contenuto protetto in un computer Windows, è necessario preparare l'ambiente utente nel dispositivo. Si tratta di un processo che viene eseguito una sola volta e viene eseguito automaticamente senza l'intervento dell'utente quando un utente tenta di proteggere o utilizzare contenuto protetto:

RMS Client activation flow - step 1, authenticating the client

Cosa succede nel passaggio 1: il client RMS nel computer si connette prima al servizio Azure Rights Management e autentica l'utente usando il proprio account di Azure Active Directory.

Quando l'account utente è federato con Azure Active Directory, l'autenticazione è automatica e all'utente non vengono richieste le credenziali.

RMS Client activation - step 2, certificates are downloaded to the client

Cosa succede nel passaggio 2: Dopo l'autenticazione dell'utente, la connessione viene reindirizzata automaticamente al tenant azure Information Protection dell'organizzazione, che rilascia certificati che consentono all'utente di eseguire l'autenticazione al servizio Azure Rights Management per usare il contenuto protetto e proteggere il contenuto offline.

Uno di questi certificati è il certificato dell'account di diritti, spesso abbreviato in RAC. Questo certificato autentica l'utente per Azure Active Directory ed è valido per 31 giorni. Il certificato viene rinnovato automaticamente dal client RMS, a condizione che l'account utente sia ancora in Azure Active Directory e che l'account sia abilitato. Questo certificato non è configurabile da un amministratore.

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

Protezione del contenuto

Quando un utente protegge un documento, il client RMS esegue le operazioni seguenti in un documento non protetto:

RMS document protection - step 1, document is encrypted

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

RMS document protection - step 2, policy is created

Cosa succede nel passaggio 2: il client RMS crea quindi un certificato che include un criterio per il documento che include i diritti di utilizzo per utenti o 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 specificato nel momento in cui il contenuto è protetto (a volte definito "criterio ad hoc").

L'attributo Azure AD principale usato per identificare gli utenti e i gruppi selezionati è l'attributo Azure AD ProxyAddresses, che archivia tutti gli indirizzi di posta elettronica per un utente o un gruppo. Tuttavia, se un account utente non ha valori nell'attributo Ad ProxyAddresses, viene usato il valore UserPrincipalName dell'utente.

Il client RMS usa quindi la chiave dell'organizzazione ottenuta quando l'ambiente utente è stato inizializzato e usa questa chiave per crittografare i criteri e la chiave di contenuto simmetrica. Il client RMS firma anche il criterio con il certificato dell'utente ottenuto quando l'ambiente utente è stato inizializzato.

RMS document protection - step 3, policy is embedded in the document

Cosa succede nel passaggio 3: Infine, il client RMS incorpora il criterio 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 con qualsiasi metodo e il criterio rimane sempre con il documento crittografato.

Utilizzo del contenuto

Quando un utente vuole utilizzare un documento protetto, il client RMS inizia richiedendo l'accesso al servizio Azure Rights Management:

RMS document consumption - step 1, user is authenticated and gets the list of rights

Cosa succede nel passaggio 1: l'utente autenticato invia i criteri documento e i certificati dell'utente al servizio Azure Rights Management. Il servizio decrittografa e valuta i criteri e crea un elenco di eventuali diritti di cui dispone l'utente per il documento. Per identificare l'utente, l'attributo Azure AD ProxyAddresses viene usato per l'account e i gruppi dell'utente a cui l'utente è membro. Per motivi di prestazioni, l'appartenenza ai gruppi viene memorizzata nella cache. Se per l'account utente non sono presenti valori per l'attributo Azure AD ProxyAddresses, viene usato il valore nella Azure AD UserPrincipalName.

RMS document consumption - step 2, use license is returned to the client

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

La chiave di contenuto re crittografata viene quindi incorporata in una licenza di utilizzo crittografata con l'elenco dei diritti utente, che viene quindi restituita al client RMS.

RMS document consumption - step 3, document is decrypted and rights are enforced

Cosa succede nel passaggio 3: Infine, il client RMS accetta la licenza di utilizzo crittografata e la decrittografa con la propria chiave privata utente. In questo modo il client RMS può decrittografare il corpo del documento in base alle esigenze ed eseguirne il rendering sullo schermo.

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

Nota

Quando gli utenti esterni all'organizzazione utilizzano contenuto protetto, il flusso di consumo è lo stesso. Ciò che cambia in questo scenario è il modo in cui l'utente viene autenticato. Per altre informazioni, vedere Quando si condivide un documento protetto con utenti esterni all'azienda, in che modo l'utente viene autenticato?

Variazioni

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

  • Protezione della posta elettronica: quando si usa Exchange Online e Office 365 Message Encryption con nuove funzionalità per proteggere i messaggi di posta elettronica, l'autenticazione per l'uso può anche usare la federazione con un provider di identità di social network o un passcode monouso. Quindi, i flussi di processo sono molto simili, con la differenza che il consumo di contenuto avviene sul lato servizio in una sessione del Web browser su una copia memorizzata temporaneamente nella cache della posta elettronica in uscita.

  • Dispositivi mobili: quando i dispositivi mobili proteggono o utilizzano file con il servizio Azure Rights Management, i flussi di processo sono molto più semplici. I dispositivi mobili non passano prima attraverso il processo di inizializzazione dell'utente perché, invece, ogni transazione (per proteggere o utilizzare il contenuto) è indipendente. Come per i computer Windows, i dispositivi mobili si connettono al servizio Azure Rights Management e si autenticano. Per proteggere il contenuto, i dispositivi mobili inviano un criterio e il servizio Azure Rights Management invia loro una licenza di pubblicazione e una chiave simmetrica per proteggere il documento. Per utilizzare il contenuto, quando i dispositivi mobili si connettono al servizio Azure Rights Management e eseguono l'autenticazione, inviano i criteri relativi ai documenti al servizio Azure Rights Management e richiedono una licenza per l'uso del 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 di processo rimangono invariati. L'unica differenza è che il connettore funge da inoltro tra i servizi locali (ad esempio Exchange Server e SharePoint Server) e il servizio Azure Rights Management. Il connettore non esegue alcuna operazione, ad esempio l'inizializzazione dell'ambiente utente, né la crittografia o la decrittografia. Inoltra semplicemente la comunicazione che normalmente sarebbe andata a un server AD RMS, gestendo la traduzione tra i protocolli che vengono utilizzati su ciascun 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 genericamente un file, il flusso è fondamentalmente lo stesso per la protezione del contenuto, con la differenza che il client RMS crea un criterio che concede tutti i diritti. Quando il file viene utilizzato, viene decrittografato prima che venga 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 l'uso di indirizzi e-mail quando vengono autenticati con un account Microsoft. Tuttavia, non tutte le applicazioni possono aprire il contenuto protetto quando viene usato un account Microsoft per l'autenticazione. Altre informazioni.

Passaggi successivi

Per altre informazioni sul servizio Azure Rights Management, usare gli altri articoli della sezione Informazioni & su Esplora , ad esempio Come le applicazioni supportano il servizio Azure Rights Management per informazioni su come integrare le applicazioni esistenti con Azure Rights Management per fornire una soluzione di protezione delle informazioni.

Esaminare la terminologia per Azure Information Protection in modo da avere familiarità con i termini che si potrebbero trovare durante la configurazione e l'uso del servizio Azure Rights Management e verificare anche i requisiti per Azure Information Protection prima di avviare la distribuzione. Se vuoi iniziare subito e provarlo, usa la guida introduttiva e le esercitazioni:

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

Mancia

Per altre informazioni e informazioni, usare le risorse e i collegamenti disponibili in Informazioni e supporto per Azure Information Protection.