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 per Office è ora in modalità di manutenzione e verrà ritirato aprile 2024. È invece consigliabile usare le etichette predefinite per le app e i servizi Office 365. Altre informazioni sullo stato di supporto di altri componenti di Azure Information Protection.

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 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 ulteriore sicurezza 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 nel Key Vault di Azure 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 variabili, 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 i 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 riconfigurino correttamente le chiavi.

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 Insieme di credenziali delle chiavi di Azure

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 alla gestione delle chiavi, Insieme di credenziali delle chiavi di Azure offre agli amministratori della protezione la stessa esperienza di gestione per archiviare, accedere e gestire i certificati e i segreti, ad esempio le 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 Insieme di credenziali delle chiavi di Azure supporta un numero di interfacce predefinite per la gestione delle chiavi, tra cui PowerShell, l'interfaccia della riga di comando, API REST e il 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 fornisce 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, tra cui la gestione della classificazione e della protezione dei dati, nonché le chiavi di crittografia e i criteri per requisiti specifici di sicurezza o conformità.
Posizione 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 risiedere.

Per altre informazioni, vedere la pagina Prodotti disponibili in base all'area nel sito di Azure.
Domini di sicurezza separati Azure Key Vault usa domini di sicurezza separati per i data center in aree come 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 da 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 una maggiore garanzia, è possibile fare riferimento incrociato alla registrazione dell'utilizzo di Azure Information Protection con la registrazione Key Vault di Azure. Key Vault log 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 del modulo di protezione hardware gestito e su come configurare un insieme di credenziali e una chiave, vedere la documentazione di Azure Key Vault.

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

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

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

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 dal 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 dal modulo di protezione hardware, trasferita come chiave protetta dal modulo di protezione hardware. Metodo più tipico scelto.

      Sebbene questo metodo abbia il maggior sovraccarico amministrativo, potrebbe essere necessario che l'organizzazione segua normative specifiche. I moduli di protezione hardware usati da Azure Key Vault sono convalidati fips 140-2 livello 2.

    • 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 Information Protection di Azure.

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

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 Key Vault
  3. Creare e configurare la chiave

Prerequisiti per la modalità 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 Verificare 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 i 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 si ha ancora un account, è possibile iscriversi per ottenere un account gratuito. Tuttavia, per usare una chiave protetta dal modulo di protezione hardware, è necessario avere il livello di servizio Azure Key Vault Premium.

La sottoscrizione di Azure gratuita che fornisce l'accesso alla configurazione di Azure Active Directory 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 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 vengano 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 al 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 che dovrà contenere la chiave da usare come chiave del tenant per Azure Information Protection è necessario specificare un percorso. Il percorso di trova in un'area di Azure o un'istanza di Azure.

Scegliere un'opzione innanzitutto per ragioni di conformità e quindi per ridurre al minimo la latenza di rete:

  • Se si è scelto il metodo di chiave BYOK per motivi di conformità, tali requisiti di conformità possono 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 Information Protection di Azure. È pertanto consigliabile ridurre al minimo la latenza di rete richiesta 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, nell'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 dell'insieme di credenziali delle chiavi consigliato
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 HSM gestite tramite l'interfaccia della riga di comando di Azure.

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

Si noti quanto segue per la configurazione della chiave e della Key Vault di Azure per BYOK:

Requisiti di lunghezza chiave

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

Nota

Le chiavi a 1024 bit non vengono considerate per offrire 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 dal modulo di protezione hardware 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 dal modulo di protezione hardware, seguire le procedure descritte nella documentazione di Azure Key Vault: Come generare e trasferire chiavi protette dal modulo di protezione hardware per Azure Key Vault.

Per consentire ad Azure Information Protection di usare la chiave trasferita, tutte le operazioni di Key Vault devono essere consentite per la chiave, tra cui:

  • encrypt
  • decrypt
  • wrapKey
  • unwrapKey
  • segno
  • 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 in Azure Key Vault hanno 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 usare la 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 il Azure PowerShell.

Abilitazione dell'autorizzazione della chiave tramite il portale di Azure

  1. Accedere al portale di Azure e passare a KeyVaults your< key vault name >> Access > policiesAdd new.>

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

    Il modello selezionato ha la configurazione seguente:

    • Il valore dell'entità Select è impostato su Microsoft Rights Management Services.
    • Le autorizzazioni chiave selezionate includono Get, Decrypt e Sign.
Abilitazione dell'autorizzazione della chiave con PowerShell

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

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 HSM gestite tramite l'interfaccia della riga di comando di Azure

Per concedere le autorizzazioni utente dell'entità servizio Azure Rights Management come utente di Crittografia HSM gestita , 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 HSM.

Il ruolo utente dell'utente di Crittografia hardware gestito consente all'utente di decrittografare, firmare e ottenere le autorizzazioni per la chiave, che sono tutte necessarie per la funzionalità Gestita HSM.

Configurare l'Information Protection di Azure per usare la chiave

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

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

  1. Connettersi al servizio Azure Rights Management e accedere:

    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 che si vuole usare. Se non si specifica la versione, la versione corrente della chiave viene usata per impostazione predefinita e il comando potrebbe risultare 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-AipServiceKeyKeyKey .

    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-AzKeyVaultKeyKey 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 tenant attiva per il servizio Azure Rights Management.

Azure Information Protection è ora configurato per usare la chiave anziché la chiave creata automaticamente da Microsoft.

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.