Dettagli bring your own key (BYOK) per Azure Information Protection

  • Articolo

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 nuovo client Microsoft Information Protection (senza il componente aggiuntivo) è attualmente in anteprima e pianificato per la disponibilità generale.

Le organizzazioni con una sottoscrizione di Azure Information Protection possono scegliere di configurare il tenant con la propria chiave, anziché una chiave predefinita generata da Microsoft. Questo scenario viene spesso definito con il termine "Bring Your Own Key" (BYOK).

La registrazione byok e l'utilizzo funzionano perfettamente con le applicazioni che si integrano con il servizio Azure Rights Management usato da Azure Information Protection.

Le applicazioni supportate includono:

  • Servizi cloud, ad esempio Microsoft SharePoint o Microsoft 365

  • Servizi locali che eseguono applicazioni Exchange e SharePoint che usano il servizio Azure Rights Management tramite il connettore RMS

  • Applicazioni client, ad esempio Office 2019, Office 2016 e Office 2013

Suggerimento

Se necessario, applicare sicurezza aggiuntiva a documenti specifici usando una chiave locale aggiuntiva. Per altre informazioni, vedere Protezione DKE (Double Key Encryption) (solo client di etichettatura unificata).

Archiviazione delle chiavi di Azure Key Vault

Le chiavi generate dal cliente devono essere archiviate in Azure Key Vault per la protezione BYOK.

Nota

L'uso di chiavi protette dal modulo di protezione hardware in Azure Key Vault richiede un livello di servizio Azure Key Vault Premium, che comporta una tariffa mensile aggiuntiva per la sottoscrizione.

Condivisione di insiemi di credenziali delle chiavi e sottoscrizioni

È consigliabile usare un insieme di credenziali delle chiavi dedicato per la chiave del tenant. Gli insiemi di credenziali delle chiavi dedicati consentono di garantire che le chiamate da altri servizi non causino il superamento dei limiti del servizio. Il superamento dei limiti del servizio nell'insieme di credenziali delle chiavi in cui è archiviata la chiave del tenant può causare la limitazione del tempo di risposta per il servizio Azure Rights Management.

Poiché i diversi servizi hanno requisiti di gestione delle chiavi diversi, Microsoft consiglia anche di usare una sottoscrizione di Azure dedicata per l'insieme di credenziali delle chiavi. Sottoscrizioni di Azure dedicate:

  • Proteggere da errori di configurazione

  • Sono più sicuri quando diversi servizi hanno amministratori diversi

Per condividere una sottoscrizione di Azure con altri servizi che usano Azure Key Vault, assicurarsi che la sottoscrizione condivide un set comune di amministratori. Confermando che tutti gli amministratori che usano la sottoscrizione hanno una conoscenza approfondita di ogni chiave a cui possono accedere, significa che è meno probabile che le chiavi non siano configurate correttamente.

Esempio: l'uso di una sottoscrizione di Azure condivisa quando gli amministratori per la chiave del tenant di Azure Information Protection sono gli stessi che amministrano le chiavi per Office 365 Customer Key e CRM online. Se gli amministratori chiave per questi servizi sono diversi, è consigliabile usare sottoscrizioni dedicate.

Vantaggi dell'uso di Azure Key Vault

Azure Key Vault offre una soluzione di gestione delle chiavi centralizzata e coerente per molti servizi locali e basati sul cloud che usano la crittografia.

Oltre a gestire le chiavi, Azure Key Vault offre agli amministratori della sicurezza la stessa esperienza di gestione per archiviare, accedere e gestire certificati e segreti (ad esempio password) per altri servizi e applicazioni che usano la crittografia.

L'archiviazione della chiave del tenant in Azure Key Vault offre i vantaggi seguenti:

Vantaggio Descrizione
Interfacce predefinite Azure Key Vault supporta diverse interfacce predefinite per la gestione delle chiavi, tra cui PowerShell, interfaccia della riga di comando, API REST e portale di Azure.

Altri servizi e strumenti sono integrati con Key Vault per funzionalità ottimizzate per attività specifiche, ad esempio il monitoraggio.

Ad esempio, analizzare i log di utilizzo delle chiavi con Operations Management Suite Log Analytics, impostare avvisi quando vengono soddisfatti i criteri specificati e così via.
Separazione dei ruoli Azure Key Vault offre la separazione dei ruoli come procedura consigliata per la sicurezza riconosciuta.

La separazione dei ruoli garantisce che gli amministratori di Azure Information Protection possano concentrarsi sulle priorità più elevate, inclusa la gestione della classificazione e della protezione dei dati, nonché le chiavi di crittografia e i criteri per requisiti di sicurezza o conformità specifici.
Percorso della chiave master Azure Key Vault è disponibile in un'ampia gamma di posizioni e supporta le organizzazioni con restrizioni in cui le chiavi master possono essere attive.

Per altre informazioni, vedere la pagina Prodotti disponibili per area nel sito di Azure.
Domini di sicurezza separati Azure Key Vault usa domini di sicurezza separati per i data center in aree quali America del Nord, EMEA (Europa, Medio Oriente e Africa) e Asia.

Azure Key Vault usa anche istanze diverse di Azure, ad esempio Microsoft Azure Germania e Azure per enti pubblici.
Esperienza unificata Azure Key Vault consente anche agli amministratori della sicurezza di archiviare, accedere e gestire certificati e segreti, ad esempio password, per altri servizi che usano la crittografia.

L'uso di Azure Key Vault per le chiavi del tenant offre un'esperienza utente semplice per gli amministratori che gestiscono tutti questi elementi.

Per gli aggiornamenti più recenti e per informazioni su come altri servizi usano Azure Key Vault, visitare il blog del team di Azure Key Vault.

Registrazione dell'utilizzo per BYOK

I log di utilizzo vengono generati da ogni applicazione che effettua richieste al servizio Azure Rights Management.

Anche se la registrazione dell'utilizzo è facoltativa, è consigliabile usare i log di utilizzo quasi in tempo reale di Azure Information Protection per vedere esattamente come e quando viene usata la chiave del tenant.

Per altre informazioni sulla registrazione dell'utilizzo delle chiavi per BYOK, vedere Registrazione e analisi dell'utilizzo della protezione da Azure Information Protection.

Suggerimento

Per maggiore garanzia, è possibile fare riferimento incrociato alla registrazione dell'utilizzo di Azure Information Protection con la registrazione di Azure Key Vault. I log di Key Vault forniscono un metodo affidabile per monitorare in modo indipendente che la chiave venga usata solo dal servizio Azure Rights Management.

Se necessario, revocare immediatamente l'accesso alla chiave rimuovendo le autorizzazioni per l'insieme di credenziali delle chiavi.

Opzioni per la creazione e l'archiviazione della chiave

Nota

Per altre informazioni sull'offerta HSM gestita e su come configurare un insieme di credenziali e una chiave, vedere la documentazione di Azure Key Vault.

Le istruzioni aggiuntive sulla concessione dell'autorizzazione della chiave sono descritte di seguito.

BYOK supporta le chiavi create in Azure Key Vault o in locale.

Se si crea la chiave in locale, è necessario trasferirla o importarla nell'insieme di credenziali delle chiavi e configurare Azure Information Protection per l'uso della chiave. Eseguire qualsiasi gestione delle chiavi aggiuntiva dall'insieme di credenziali delle chiavi di Azure.

Opzioni per creare e archiviare la propria chiave:

  • Creato in Azure Key Vault. Creare e archiviare la chiave in Azure Key Vault come chiave protetta da modulo di protezione hardware o come chiave protetta da software.

  • Creato in locale. Creare la chiave in locale e trasferirla in Azure Key Vault usando una delle opzioni seguenti:

    • Chiave protetta da HSM, trasferita come chiave protetta da HSM. Metodo più tipico scelto.

      Anche se questo metodo presenta il sovraccarico amministrativo più alto, potrebbe essere necessario che l'organizzazione segua normative specifiche. I moduli di protezione hardware usati da Azure Key Vault hanno la convalida FIPS 140.

    • Chiave protetta da software che viene convertita e trasferita in Azure Key Vault come chiave protetta dal modulo di protezione hardware. Questo metodo è supportato solo quando si esegue la migrazione da Active Directory Rights Management Services (AD RMS).

    • Creato in locale come chiave protetta da software e trasferito ad Azure Key Vault come chiave protetta da software. Questo metodo richiede un oggetto . File di certificato PFX.

Ad esempio, eseguire le operazioni seguenti per usare una chiave creata in locale:

  1. Generare la chiave del tenant in locale, in linea con i criteri IT e di sicurezza dell'organizzazione. Questa chiave è la copia master. Rimane in locale ed è necessario per il relativo backup.

  2. Creare una copia della chiave master e trasferirla in modo sicuro dal modulo di protezione hardware ad Azure Key Vault. Durante questo processo, la copia master della chiave non lascia mai il limite di protezione hardware.

Dopo il trasferimento, la copia della chiave è protetta da Azure Key Vault.

Esportazione del dominio di pubblicazione attendibile

Se si decide di interrompere l'uso di Azure Information Protection, è necessario un dominio di pubblicazione attendibile (TPD) per decrittografare il contenuto protetto da Azure Information Protection.

Tuttavia, l'esportazione del tpd non è supportata se si usa BYOK per la chiave di Azure Information Protection.

Per prepararsi a questo scenario, assicurarsi di creare un TPD appropriato in anticipo. Per altre informazioni, vedere Come preparare un piano di "Uscita cloud" di Azure Information Protection.

Implementazione di BYOK per la chiave del tenant di Azure Information Protection

Per implementare BYOK, seguire questa procedura:

  1. Esaminare i prerequisiti BYOK
  2. Scegliere un percorso dell'insieme di credenziali delle chiavi
  3. Creare e configurare la chiave

Prerequisiti per BYOK

I prerequisiti BYOK variano a seconda della configurazione del sistema. Verificare che il sistema sia conforme ai prerequisiti seguenti in base alle esigenze:

Requisito Descrizione
Sottoscrizione di Azure Obbligatorio per tutte le configurazioni.
Per altre informazioni, vedere Verifica di avere una sottoscrizione di Azure compatibile con BYOK.
Modulo PowerShell AIPService per Azure Information Protection Obbligatorio per tutte le configurazioni.
Per altre informazioni, vedere Installazione del modulo PowerShell AIPService.
Prerequisiti di Azure Key Vault per BYOK Se si usa una chiave protetta da HSM creata in locale, assicurarsi di rispettare anche i prerequisiti per BYOK elencati nella documentazione di Azure Key Vault.
Firmware Thales versione 11.62 È necessario avere una versione del firmware Thales 11.62 se si esegue la migrazione da AD RMS ad Azure Information Protection usando la chiave software alla chiave hardware e si usa il firmware Thales per il modulo di protezione hardware.
Bypass del firewall per servizi Microsoft attendibili Se l'insieme di credenziali delle chiavi che contiene la chiave del tenant usa Rete virtuale endpoint di servizio per Azure Key Vault, è necessario consentire ai servizi Microsoft attendibili di ignorare questo firewall.
Per altre informazioni, vedere Rete virtuale endpoint di servizio per Azure Key Vault.

Verifica di avere una sottoscrizione di Azure compatibile con BYOK

Il tenant di Azure Information Protection deve avere una sottoscrizione di Azure. Se non ne hai ancora uno, puoi iscriverti per ottenere un account gratuito. Tuttavia, per usare una chiave protetta da modulo di protezione hardware, è necessario disporre del livello di servizio Azure Key Vault Premium.

La sottoscrizione gratuita di Azure che fornisce l'accesso alla configurazione di Microsoft Entra e alla configurazione del modello personalizzato di Azure Rights Management non è sufficiente per l'uso di Azure Key Vault.

Per verificare se si dispone di una sottoscrizione di Azure compatibile con BYOK, eseguire le operazioni seguenti per verificare usando i cmdlet di Azure PowerShell :

  1. Avviare una sessione di Azure PowerShell come amministratore.

  2. Accedere come amministratore globale per il tenant di Azure Information Protection usando Connect-AzAccount.

  3. Copiare il token visualizzato negli Appunti. Quindi, in un browser, passare a https://microsoft.com/devicelogin e immettere il token copiato.

    Per altre informazioni, vedere Accedere con Azure PowerShell.

  4. Nella sessione di PowerShell immettere Get-AzSubscriptione verificare che siano visualizzati i valori seguenti:

    • Nome e ID della sottoscrizione
    • ID tenant di Azure Information Protection
    • Conferma dell'abilitazione dello stato

    Se non vengono visualizzati valori e viene restituito il prompt, non è disponibile una sottoscrizione di Azure che può essere usata per BYOK.

Scelta del percorso dell'insieme di credenziali delle chiavi

Quando si crea un insieme di credenziali delle chiavi per contenere la chiave da usare come chiave del tenant per Azure Information, è necessario specificare una posizione. Questa località è un'area di Azure o un'istanza di Azure.

Scegliere prima di tutto per la conformità e quindi ridurre al minimo la latenza di rete:

  • Se è stato scelto il metodo di chiave BYOK per motivi di conformità, questi requisiti di conformità potrebbero anche imporre l'area o l'istanza di Azure che può essere usata per archiviare la chiave del tenant di Azure Information Protection.

  • Tutte le chiamate crittografiche per la catena di protezione alla chiave di Azure Information Protection. È quindi consigliabile ridurre al minimo la latenza di rete necessaria creando l'insieme di credenziali delle chiavi nella stessa area o istanza di Azure del tenant di Azure Information Protection.

Per identificare la posizione del tenant di Azure Information Protection, usare il cmdlet PowerShell Get-AipServiceConfiguration e identificare l'area dagli URL. Ad esempio:

LicensingIntranetDistributionPointUrl : https://5c6bb73b-1038-4eec-863d-49bded473437.rms.na.aadrm.com/_wmcs/licensing

L'area è identificabile da rms.na.aadrm.com e, per questo esempio, si trova in America del Nord.

La tabella seguente elenca le aree e le istanze di Azure consigliate per ridurre al minimo la latenza di rete:

Area o istanza di Azure Percorso consigliato per l'insieme di credenziali delle chiavi
Rms.na.aadrm.com Stati Uniti centro-settentrionali o Stati Uniti orientali
Rms.eu.aadrm.com Europa settentrionale o Europa occidentale
Rms.ap.aadrm.com Asia orientale o Asia sud-orientale
Rms.sa.aadrm.com Stati Uniti occidentali o Stati Uniti orientali
Rms.govus.aadrm.com Stati Uniti centrali o Stati Uniti orientali 2
Rms.aadrm.us US Gov Virginia o US Gov Arizona
Rms.aadrm.cn Cina orientale 2 o Cina settentrionale 2

Creare e configurare la chiave

Importante

Per informazioni specifiche per i moduli di protezione hardware gestiti, vedere Abilitazione dell'autorizzazione della chiave per le chiavi del modulo di protezione hardware gestito tramite l'interfaccia della riga di comando di Azure.

Creare un insieme di credenziali delle chiavi di Azure e la chiave da usare per Azure Information Protection. Per altre informazioni, vedere la documentazione di Azure Key Vault.

Per configurare Azure Key Vault e la chiave per BYOK, tenere presente quanto segue:

Requisiti di lunghezza chiave

Quando si crea la chiave, assicurarsi che la lunghezza della chiave sia di 2048 bit (scelta consigliata) o di 1024 bit. Altre lunghezze di chiave non sono supportate da Azure Information Protection.

Nota

Le chiavi a 1024 bit non sono considerate un livello di protezione adeguato per le chiavi tenant attive.

Microsoft non approva l'uso di lunghezze di chiave inferiori, ad esempio chiavi RSA a 1024 bit e l'uso associato di protocolli che offrono livelli di protezione inadeguati, ad esempio SHA-1.

Creazione di una chiave protetta da HSM in locale e trasferimento nell'insieme di credenziali delle chiavi

Per creare una chiave protetta da HSM in locale e trasferirla nell'insieme di credenziali delle chiavi come chiave protetta da HSM, seguire le procedure descritte nella documentazione di Azure Key Vault: Come generare e trasferire chiavi protette da HSM per Azure Key Vault.

Affinché Azure Information Protection usi la chiave trasferita, tutte le operazioni di Key Vault devono essere consentite per la chiave, tra cui:

  • crittografare
  • decrypt
  • wrapKey
  • unwrapKey
  • sign
  • verify

Per impostazione predefinita, tutte le operazioni di Key Vault sono consentite.

Per controllare le operazioni consentite per una chiave specifica, eseguire il comando di PowerShell seguente:

(Get-AzKeyVaultKey -VaultName <key vault name> -Name <key name>).Attributes.KeyOps

Se necessario, aggiungere le operazioni consentite usando Update-AzKeyVaultKey e il parametro KeyOps .

Configurazione di Azure Information Protection con l'ID chiave

Le chiavi archiviate nell'insieme di credenziali delle chiavi di Azure dispongono di un ID chiave.

L'ID chiave è un URL che contiene il nome dell'insieme di credenziali delle chiavi, il contenitore delle chiavi, il nome della chiave e la versione della chiave. Ad esempio: https://contosorms-kv.vault.azure.net/keys/contosorms-byok/aaaabbbbcccc111122223333

Configurare Azure Information Protection per l'uso della chiave specificando l'URL dell'insieme di credenziali delle chiavi.

Autorizzazione del servizio Azure Rights Management per l'uso della chiave

Il servizio Azure Rights Management deve essere autorizzato a usare la chiave. Gli amministratori di Azure Key Vault possono abilitare questa autorizzazione usando il portale di Azure o Azure PowerShell.

Abilitazione dell'autorizzazione della chiave tramite il portale di Azure

  1. Accedere al portale di Azure e passare a Insiemi di credenziali delle><chiavi i criteri>>di accesso Aggiungi>nuovo.

  2. Nel riquadro Aggiungi criteri di accesso selezionare BYOK di Azure Information Protection nella casella di riepilogo Configura da modello (facoltativo) e quindi fare clic su OK.

    Il modello selezionato ha la configurazione seguente:

    • Il valore Select principal è impostato su Microsoft Rights Management Services.
    • Le autorizzazioni per le chiavi selezionate includono Get, Decrypt e Sign.
Abilitazione dell'autorizzazione della chiave tramite PowerShell

Eseguire il cmdlet di PowerShell per Key Vault, Set-AzKeyVaultAccessPolicy e concedere le autorizzazioni all'entità servizio Azure Rights Management usando il GUID 00000012-0000-0000-c000-000000000000000.

Ad esempio:

Set-AzKeyVaultAccessPolicy -VaultName 'ContosoRMS-kv' -ResourceGroupName 'ContosoRMS-byok-rg' -ServicePrincipalName 00000012-0000-0000-c000-000000000000 -PermissionsToKeys decrypt,sign,get
Abilitazione dell'autorizzazione della chiave per le chiavi del modulo di protezione hardware gestito tramite l'interfaccia della riga di comando di Azure

Per concedere all'entità servizio Azure Rights Management le autorizzazioni utente come utente di crittografia del modulo di protezione hardware gestito, eseguire il comando seguente:

az keyvault role assignment create --hsm-name "ContosoMHSM" --role "Managed HSM Crypto User" --assignee-principal-type ServicePrincipal --assignee https://aadrm.com/ --scope /keys/contosomhskey

Dove:

  • ContosoMHSM è un nome HSM di esempio. Quando si esegue questo comando, sostituire questo valore con il proprio nome del modulo di protezione hardware.

Il ruolo utente Crypto User di HSM gestito consente all'utente di decrittografare, firmare e ottenere le autorizzazioni per la chiave, che sono tutte necessarie per la funzionalità HSM gestita.

Configurare Azure Information Protection per l'uso della chiave

Dopo aver completato tutti i passaggi precedenti, è possibile configurare Azure Information Protection per usare questa chiave come chiave del tenant dell'organizzazione.

Usando i cmdlet di Azure RMS, eseguire i comandi seguenti:

  1. Connessione al servizio Azure Rights Management ed eseguire l'accesso:

    Connect-AipService

  2. Eseguire il cmdlet Use-AipServiceKeyVaultKey, specificando l'URL della chiave. Ad esempio:

    Use-AipServiceKeyVaultKey -KeyVaultKeyUrl "https://contosorms-kv.vault.azure.net/keys/contosorms-byok/<key-version>"

    Importante

    In questo esempio è <key-version> la versione della chiave da usare. Se non si specifica la versione, la versione corrente della chiave viene usata per impostazione predefinita e il comando potrebbe sembrare funzionante. Tuttavia, se la chiave viene aggiornata o rinnovata in un secondo momento, il servizio Azure Rights Management smetterà di funzionare per il tenant, anche se si esegue di nuovo il comando Use-AipServiceKeyVaultKey .

    Usare il comando Get-AzKeyVaultKey in base alle esigenze per ottenere il numero di versione della chiave corrente.

    Ad esempio: Get-AzKeyVaultKey -VaultName 'contosorms-kv' -KeyName 'contosorms-byok'

    Per verificare che l'URL della chiave sia impostato correttamente per Azure Information Protection, eseguire il comando Get-AzKeyVaultKey in Azure Key Vault per visualizzare l'URL della chiave.

  3. Se il servizio Azure Rights Management è già attivato, eseguire Set-AipServiceKeyProperties per indicare ad Azure Information Protection di usare questa chiave come chiave del tenant attiva per il servizio Azure Rights Management.

Azure Information Protection è ora configurato per l'uso della chiave invece della chiave predefinita creata da Microsoft creata automaticamente per il tenant.

Passaggi successivi

Dopo aver configurato la protezione BYOK, continuare a Iniziare a usare la chiave radice del tenant per altre informazioni sull'uso e sulla gestione della chiave.