Che cos'è la crittografia a doppia chiave (DKE)?

Descrizione del servizio Microsoft Purview

Si applica a: Crittografia a chiave doppia Microsoft Purview, Microsoft Purview, Microsoft Purview Information Protection

Descrizione del servizio per: Microsoft Purview

La crittografia a doppia chiave (DKE) consente di proteggere i dati altamente sensibili per soddisfare requisiti specifici. DKE ti consente di mantenere il controllo delle tue chiavi di crittografia. Usa due chiavi per proteggere i dati; una chiave sotto il controllo dell'utente e una seconda chiave archiviata in modo sicuro in Microsoft Azure. L'utente mantiene il controllo di una delle chiavi usando il servizio Crittografia a doppia chiave. La visualizzazione dei dati protetti con crittografia a doppia chiave richiede l'accesso a entrambe le chiavi.

DKE consente di soddisfare i requisiti normativi in base a diversi regolamenti e standard, come il Regolamento generale sulla protezione dei dati (GDPR), l'Health Insurance Portability and Accountability Act (HIPAA), il Gramm-Leach-Bliley Act (GLBA), la legge russa sulla localizzazione dei dati - Legge federale n. 242-FZ, il Federal Privacy Act australiano del 1988 e il Privacy Act della Nuova Zelanda del 1993.

Dopo aver configurato il servizio DKE e le chiavi, è possibile applicare la protezione ai contenuti altamente sensibili usando le etichette di riservatezza.

Scenari di distribuzione supportati

DKE supporta diverse configurazioni, tra cui distribuzioni cloud e on-premise. Queste distribuzioni assicurano che i dati crittografati rimangano opachi ovunque vengano archiviati.

È possibile ospitare il servizio Crittografia a doppia chiave usato per richiedere la chiave in una posizione a scelta (server di gestione delle chiavi locale o nel cloud). Il servizio viene gestito come qualsiasi altra applicazione. La crittografia a doppia chiave consente di controllare l'accesso al servizio Crittografia a doppia chiave. È possibile archiviare i dati altamente sensibili in locale o spostarli nel cloud. La crittografia a doppia chiave consente di controllare l'archiviazione dei dati e della chiave nella stessa posizione geografica.

Per altre informazioni sulle chiavi radice del tenant basate sul cloud predefinite, vedere Gestione della chiave radice per il servizio Azure Rights Management.

Quando la tua organizzazione dovrebbe adottare DKE

DKE non è per tutte le organizzazioni, né per tutti i tuoi dati. Supponiamo che un tipico panorama dei dati dell'organizzazione abbia la struttura seguente:

• Dati non sensibili (circa l'80% dei dati): la maggior parte dei dati di un'organizzazione rientra in questa categoria. Oggi non ci sono problemi o preoccupazioni con lo spostamento di questi dati nel cloud. Lo spostamento di tali dati nel cloud può essere vantaggioso e l'organizzazione può utilizzare la sicurezza integrata nel cloud.

• Sensibili (circa il 15% dei dati): i dati sensibili devono essere protetti. L'organizzazione si aspetta che il provider di servizi cloud fornisca sicurezza migliorando al contempo la produttività per questa categoria di dati, in modo da poter soddisfare le normative di conformità. Si desidera assicurarsi che questi dati siano etichettati correttamente con Microsoft Purview Information Protection e siano protetti con criteri di controllo e conservazione e controllo di accesso.

• Altamente sensibile (circa il 5% dei dati): questo set è il fiore all'occhiello dell'organizzazione e deve essere fortemente protetto. L'organizzazione non vuole che nessuno abbia accesso a tali dati. Questa categoria di dati può anche essere soggetta a requisiti normativi per avere le chiavi nella stessa area geografica dei dati. Potrebbe anche essere necessario che le chiavi siano sotto la stretta custodia dell'organizzazione. Questo contenuto ha la classificazione più alta nell'organizzazione ("Top Secret") e l'accesso è limitato a poche persone. I dati altamente sensibili sono ciò che gli utenti malintenzionati cercano. La perdita di questi dati può danneggiare la reputazione dell'organizzazione e rompere la fiducia con i clienti.

Come accennato, la crittografia a doppia chiave è destinata ai dati più sensibili soggetti ai requisiti di protezione più rigorosi. È necessario fare la dovuta diligenza nell'identificare i dati giusti da coprire con questa soluzione prima di distribuirla. In alcuni casi, potrebbe essere necessario limitare l'ambito e usare altre soluzioni. Ad esempio, per la maggior parte dei dati, considera Microsoft Purview Information Protection con chiavi gestite da Microsoft o BYOK (bring your own key). Queste soluzioni sono sufficienti per i documenti che non sono soggetti a protezioni avanzate e requisiti normativi. Inoltre, queste soluzioni consentono di utilizzare i più potenti servizi di Microsoft 365; servizi che non possono essere usati con contenuto crittografato DKE. Ad esempio:

• Regole del flusso di posta, tra cui antimalware e posta indesiderata, che richiedono visibilità sull'allegato
• Microsoft Delve
• eDiscovery
• Ricerca e indicizzazione dei contenuti
• Office Web App Web, inclusa la funzionalità di creazione condivisa
• Copilot

I dati crittografati DKE non sono accessibili inattivi per i servizi Microsoft 365, incluso Copilot. Mentre usi i dati crittografati DKE in Office, i dati non sono ancora accessibili a Copilot e non puoi usare Copilot nelle app mentre usi i dati crittografati DKE.

Le applicazioni o i servizi esterni che non sono integrati con DKE tramite Microsoft Information Protection SDK non sono in grado di eseguire azioni sui dati crittografati. Microsoft Information Protection SDK 1.7+ supporta la crittografia a doppia chiave. Le applicazioni che si integrano con il nostro SDK possono ragionare su questi dati con autorizzazioni e integrazioni sufficienti.

Quando i dati crittografati DKE sono in uso in un'app di Office, potrebbero essere accessibili ad altri servizi di Microsoft 365, a seconda della versione di Office:

• Nelle versioni più recenti di Office, i dati crittografati DKE in uso non sono accessibili nemmeno ai servizi di Microsoft 365. Poiché questa modifica è stata implementata contemporaneamente al controllo di privacy separato per le etichette di riservatezza che impedisce l'invio di contenuto etichettato a esperienze connesse per l'analisi, è possibile identificare le versioni minime di Office usando la tabella delle funzionalità e la riga Impedisci esperienze connesse che analizzano il contenuto.

• Nelle versioni precedenti di Office, i dati crittografati DKE in uso sono accessibili ai servizi di Microsoft 365, a meno che non si usi un'impostazione di criterio per disattivare le esperienze connesse che analizzano il contenuto. Per maggiori informazioni, vedere Usare le impostazioni dei criteri per gestire i controlli della privacy per Microsoft 365 Apps for enterprise.

Usare le funzionalità di Microsoft Purview Information Protection (classificazione ed etichettatura) per proteggere la maggior parte dei dati sensibili e usare DKE solo per i dati cruciali. La crittografia a doppia chiave è rilevante per i dati sensibili in settori altamente regolamentati, come i servizi finanziari e l'assistenza sanitaria.

Funzionalità delle etichette di riservatezza che non supportano DKE

Poiché DKE non usa una chiave basata sul cloud gestita dal servizio Azure Rights Management, diverse funzionalità delle etichette di riservatezza non possono funzionare con il contenuto crittografato con DKE:

• Creazione condivisa e salvataggio automatico

  • La creazione condivisa e il salvataggio automatico non sono supportati per i documenti di Office crittografati con DKE. Le etichette con DKE continuano a essere visualizzate nelle app di Office, ma le funzionalità di creazione condivisa e di salvataggio automatico sono disabilitate quando viene applicata l'etichetta. Per altre informazioni, vedere Creazione condivisa per i file crittografati con etichette di riservatezza.

• Files in SharePoint e OneDrive

  • SharePoint e OneDrive non possono elaborare i file crittografati con DKE. Questi file non possono essere aperti in Office per il web e le funzionalità di collaborazione come la creazione condivisa, eDiscovery, prevenzione della perdita di dati e ricerca non funzionano per i file crittografati DKE in queste posizioni. Per altre informazioni, vedere Abilitare le etichette di riservatezza per i file in SharePoint e OneDrive.

• Etichetta predefinita per una raccolta documenti di SharePoint

  • Un'etichetta di riservatezza che usa DKE non può essere impostata come etichetta di riservatezza predefinita per una raccolta documenti di SharePoint. Per altre informazioni, vedere Configurare un'etichetta di riservatezza predefinita per una raccolta documenti di SharePoint.

• Componenti e pagine Loop

  • Le etichette di riservatezza configurate con DKE non sono supportate per i componenti e le pagine Loop. Per altre informazioni, vedi Etichette di riservatezza per i componenti e le pagine Loop.

• Riunioni e chat di Teams

  • Non è possibile utilizzare le etichette DKE per proteggere elementi del calendario, riunioni e chat di Teams. Le riunioni e le chat richiedono la crittografia che usa il servizio Azure Rights Management. Per altre informazioni, vedi Usare le etichette di riservatezza per proteggere gli elementi del calendario, le riunioni e le chat di Teams.

Se la tua organizzazione ha uno dei seguenti requisiti, puoi utilizzare DKE per proteggere i tuoi contenuti:

• Hai requisiti normativi per conservare le chiavi all'interno di un confine geografico.
• Tutte le chiavi in tuo possesso per la crittografia e la decrittografia dei dati vengono mantenute nel tuo data center.

Flusso di lavoro di crittografia DKE

Questa sezione suddivide il flusso di lavoro in passaggi separati per illustrare come vengono utilizzate due chiavi per proteggere un documento di Office.

Passaggio 1: avvio di avvio

Il client Microsoft Office esegue attività di configurazione all'avvio e invia richieste e informazioni al servizio di crittografia Azure Rights Management. Questo processo è detto anche bootstrapping. Le attività includono l'autorizzazione dell'utente tramite Microsoft Entra ID, il download di certificati e modelli e così via. Le attività di bootstrapping sono attività di connessione e avvio iniziali che consentono all'utente di accedere ai criteri di crittografia di Azure Rights Management.

Passaggio 2: Raccogliere e memorizzare nella cache la chiave pubblica per il servizio Azure Rights Management

L'app di Office recupera la chiave pubblica dall'Azure Key Vault nel servizio di crittografia in base all'utente autorizzato che usa Microsoft Entra ID. Una volta raccolta, il client memorizza nella cache la chiave per 30 giorni per impostazione predefinita. Una volta memorizzato nella cache, il client non deve eseguire nuovamente il bootstrap al servizio Azure Rights Management fino alla scadenza della chiave. L'amministratore può configurare un periodo di memorizzazione nella cache diverso per il servizio Azure Rights Management. È necessario impostare un periodo di cache per questa chiave o accettare il valore predefinito di 30 giorni. Senza un periodo di cache, la pubblicazione offline non funziona.

Passaggio 3: richiedere la chiave pubblica DKE

Il client di Office richiede l'altra chiave pubblica dal servizio Double Key Encryption in base all'utente autorizzato che utilizza Microsoft Entra ID.

Passaggio 4: raccogliere e memorizzare nella cache la chiave DKE

Il servizio Crittografia a doppia chiave invia questa chiave pubblica al client di Office. Il client memorizza nella cache la chiave nel dispositivo per tutto il tempo di configurazione. A differenza della chiave di Azure,

• Non è necessario configurare un periodo di cache per la chiave ospitata dal servizio Crittografia a doppia chiave.

• Se si vuole configurare un periodo di cache, è possibile farlo quando si distribuisce il servizio Crittografia a doppia chiave o dopo la distribuzione.

Passaggio 5: Proteggere il documento con la chiave DKE

Il client di Microsoft Office crittografa la parte dei metadati che controlla l'accesso al contenuto tramite la chiave pubblica recuperata dal servizio Crittografia a chiave doppia.

Passaggio 6: Proteggere il documento con la chiave di Azure

Il client di Microsoft Office crittografa la parte già crittografata dei metadati del documento con la chiave pubblica di Azure.

I dati sono ora protetti con entrambe le chiavi.

Sistema e requisiti di licenza per DKE

Questa sezione descrive in dettaglio i requisiti di sistema e configurazione del server e del client che devono essere soddisfatti prima di poter distribuire correttamente DKE nel proprio ambiente.

requisiti di licenza per DKE

Per le opzioni di licenza per Double Key Encryption, vedere Microsoft Purview Information Protection Double Key Encryption nella descrizione del servizio Microsoft Purview.

Il servizio Azure Rights Management è necessario per DKE

DKE funziona con etichette di riservatezza e richiede la crittografia con la gestione dei diritti da Microsoft Purview Information Protection.

Requisiti di etichettatura DKE per le app di Office

Usare le etichette di riservatezza incorporate nelle app di Office per supportare DKE in Word, Excel, PowerPoint e Outlook. Per le versioni supportate, vedere le tabelle delle funzionalità e la riga Crittografia a doppia chiave (DKE).

DKE nei computer client

Gli utenti applicano le etichette di riservatezza DKE attraverso queste interfacce.

• Etichette di riservatezza nelle app di Windows Office

• Microsoft Purview Information Protection etichettatore di file in Windows Esplora file

• Microsoft Purview Information Protection PowerShell

• Scanner Microsoft Purview Information Protection

Installare i prerequisiti in ogni computer client in cui si desidera proteggere e utilizzare i documenti protetti.

Ambienti supportati per l'archiviazione e la visualizzazione di contenuti protetti da DKE

Applicazioni supportate. Client di Microsoft 365 Apps for enterprise in Windows, tra cui Word, Excel, PowerPoint e Outlook.

Supporto del contenuto online. È possibile archiviare documenti e file protetti con crittografia a doppia chiave online sia in SharePoint che in OneDrive. È necessario etichettare e proteggere i documenti e i file con DKE dalle applicazioni supportate prima di caricarli in queste posizioni. È possibile condividere contenuti crittografati tramite posta elettronica, ma non è possibile visualizzare documenti e file crittografati online. È invece necessario visualizzare il contenuto protetto usando le applicazioni desktop e i client supportati nel computer locale.

Scenari di etichettatura all'esterno delle app di Office. Applicare etichette DKE all'esterno delle app di Office usando l'etichettatrice di file di Microsoft Purview Information Protection nelle opzioni di scelta rapida di Esplora file, i cmdlet di etichettatura di PowerShell di Microsoft Purview Information Protection o il Scanner Microsoft Purview Information Protection.

Visualizzazione di contenuto protetto da DKE all'esterno delle app di Office. È possibile usare il visualizzatore di Microsoft Purview Information Protection per utilizzare messaggi di posta elettronica e documenti protetti da DKE, ad esempio PDF.

Scenari solo crittografia e non inoltrare. Solo crittografia e Non inoltrare non sono supportati con DKE in Outlook. Tutte le altre applicazioni di Office supportano le etichette di autorizzazione definite dall'utente con DKE.

Contenuto correlato

• Configurare la crittografia a chiave doppia

• Domande frequenti sulla crittografia a chiave doppia