Crittografia per SharePoint e OneDrive, Microsoft Teams ed Exchange

Microsoft 365 è un ambiente altamente sicuro che offre protezione estesa a più livelli: sicurezza dei data center fisici, sicurezza di rete, sicurezza degli accessi, sicurezza delle applicazioni e sicurezza dei dati.

SharePoint e OneDrive

Tutti i file dei clienti in SharePoint sono protetti da chiavi univoche per ogni file che sono sempre esclusive per un singolo tenant. Le chiavi vengono create e gestite dal servizio SharePoint oppure quando la chiave del cliente viene usata, creata e gestita dai clienti. Quando un file viene caricato, la crittografia viene eseguita da SharePoint nel contesto della richiesta di caricamento, prima di essere inviata all'archiviazione di Azure. Quando un file viene scaricato, SharePoint recupera i dati dei clienti crittografati dall'archiviazione di Azure in base all'identificatore univoco del documento e decrittografa i dati del cliente prima di inviarli all'utente. Archiviazione di Azure non è in grado di decrittografare, né di identificare o comprendere i dati dei clienti. Tutta la crittografia e la decrittografia avvengono negli stessi sistemi che applicano l'isolamento del tenant, che sono Microsoft Entra ID e SharePoint.

Diversi carichi di lavoro in Microsoft 365 archiviano i dati in SharePoint, tra cui Microsoft Teams, che archivia tutti i file in SharePoint e OneDrive, che usa SharePoint per l'archiviazione. Tutti i dati dei clienti archiviati in SharePoint vengono crittografati (con una o più chiavi AES a 256 bit) e distribuiti nel data center come indicato di seguito. Ogni passaggio di questo processo di crittografia è convalidato da FIPS 140-2 Livello 2. Per altre informazioni sulla conformità FIPS 140-2, vedere Conformità FIPS 140-2.

• Ogni file viene suddiviso in uno o più blocchi, a seconda delle dimensioni del file. Ogni blocco viene crittografato usando la propria chiave univoca AES a 256 bit.

• Quando un file viene aggiornato, l'aggiornamento viene gestito nello stesso modo: la modifica viene suddivisa in uno o più blocchi e ogni blocco viene crittografato con una chiave univoca separata.

• Questi blocchi, ovvero file, parti di file e delta degli aggiornamenti, vengono archiviati come BLOB nell'archiviazione di Azure distribuiti in modo casuale tra più account di archiviazione di Azure.

• Il set di chiavi di crittografia per questi blocchi di dati dei clienti viene crittografato.

  • Le chiavi usate per crittografare i BLOB vengono archiviate nel database del contenuto di SharePoint.
  • Il database del contenuto è protetto dai controlli di accesso al database e dalla crittografia inattivi. La crittografia viene eseguita usando Transparent Data Encryption (TDE) nel database Azure SQL. Azure SQL Database è un servizio di database relazionale generico in Microsoft Azure che supporta strutture quali dati relazionali, JSON, spaziali e XML. Questi segreti sono a livello di servizio per SharePoint, non a livello di tenant. Questi segreti (a volte definiti chiavi master) vengono archiviati in un repository protetto separato denominato Archivio chiavi. TDE offre sicurezza inattivi sia per il database attivo che per i backup del database e i log delle transazioni.
  • Quando i clienti forniscono la chiave facoltativa, la chiave del cliente viene archiviata in Azure Key Vault e il servizio usa la chiave per crittografare una chiave tenant, che viene usata per crittografare una chiave del sito, che viene quindi usata per crittografare le chiavi a livello di file. In sostanza, viene introdotta una nuova gerarchia di chiavi quando il cliente fornisce una chiave.

• La mappa usata per assemblare nuovamente il file viene archiviata nel database del contenuto insieme alle chiavi crittografate, separatamente dalla chiave master necessaria per decrittografarle.

• Ogni account di archiviazione di Azure ha le proprie credenziali univoche per tipo di accesso (lettura, scrittura, enumerazione ed eliminazione). Ogni set di credenziali è conservato nell'archivio chiavi protetto e viene regolarmente aggiornato. Come descritto in precedenza, esistono tre diversi tipi di negozi, ognuno con una funzione distinta:

  • I dati dei clienti vengono archiviati come BLOB crittografati nell'archiviazione di Azure. La chiave per ogni blocco di dati dei clienti viene crittografata e archiviata separatamente nel database del contenuto. I dati del cliente stesso non hanno idea di come possono essere decrittografati.
  • Il database del contenuto è un database SQL Server. Contiene la mappa necessaria per individuare e riassemblare i BLOB di dati dei clienti contenuti nell'archiviazione di Azure e le chiavi necessarie per crittografare tali BLOB. Tuttavia, il set di chiavi è a sua volta crittografato (come spiegato in precedenza) e conservato in un archivio chiavi separato.
  • L'archivio chiavi è fisicamente separato dal database del contenuto e dall'archiviazione di Azure. Contiene le credenziali per ogni contenitore di archiviazione di Azure e la chiave master per il set di chiavi crittografate contenute nel database del contenuto.

Ognuno di questi tre componenti di archiviazione, ovvero l'archivio BLOB di Azure, il database del contenuto e l'archivio chiavi, è fisicamente separato. Le informazioni contenute in uno dei componenti sono inutilizzabili da sole. Senza l'accesso a tutti e tre, è impossibile recuperare le chiavi ai blocchi, decrittografare le chiavi per renderle utilizzabili, associare le chiavi ai blocchi corrispondenti, decrittografare ogni blocco o ricostruire un documento dai blocchi costitutivi.

I certificati BitLocker, che proteggono i volumi di dischi fisici nei computer del data center, vengono archiviati in un repository sicuro (l'archivio segreto di SharePoint) protetto dalla chiave della farm.

Le chiavi TDE che proteggono le chiavi per BLOB vengono archiviate in due posizioni:

• Il repository sicuro, che ospita i certificati BitLocker ed è protetto dalla chiave della farm; E
• In un repository sicuro gestito da Azure SQL Database.

Le credenziali usate per accedere ai contenitori di archiviazione di Azure sono contenute anche nell'archivio segreto di SharePoint e delegate a ogni farm di SharePoint in base alle esigenze. Queste credenziali sono firme sas di archiviazione di Azure, con credenziali separate usate per leggere o scrivere dati e con criteri applicati in modo che scadano automaticamente ogni 60 giorni. Credenziali diverse vengono usate per leggere o scrivere dati (non entrambi) e alle farm di SharePoint non vengono concesse le autorizzazioni per l'enumerazione.

Per altre informazioni sulla crittografia dei dati in SharePoint e OneDrive, vedere Crittografia dei dati in SharePoint e OneDrive.

Elencare elementi in SharePoint

Gli elementi elenco sono blocchi più piccoli di dati dei clienti creati ad hoc o che possono vivere in modo più dinamico all'interno di un sito, ad esempio righe in un elenco creato dall'utente, singoli post in un blog di SharePoint o voci all'interno di una pagina wiki di SharePoint. Gli elementi dell'elenco vengono archiviati nel database del contenuto (Azure SQL database) e protetti con TDE.

Crittografia dei dati in transito

In OneDrive e SharePoint sono disponibili due scenari in cui i dati entrano ed escono dai data center.

• Comunicazione client con il server: la comunicazione con SharePoint e OneDrive su Internet usa connessioni TLS.
• Spostamento dei dati tra data center : il motivo principale per spostare i dati tra i data center è la replica geografica per abilitare il ripristino di emergenza. Ad esempio, i registri transazioni di SQL Server e le differenze dell'archiviazione BLOB viaggiano lungo questa pipe. Anche se questi dati sono già trasmessi tramite una rete privata, sono ulteriormente protetti con la crittografia migliore della classe.

Exchange

Exchange usa BitLocker per tutti i dati delle cassette postali e la configurazione di BitLocker è descritta in BitLocker per la crittografia. La crittografia a livello di servizio crittografa tutti i dati delle cassette postali a livello di cassetta postale.

Oltre alla crittografia del servizio, Microsoft 365 supporta la chiave del cliente, basata sulla crittografia del servizio. La chiave del cliente è un'opzione di chiave gestita da Microsoft per la crittografia del servizio Exchange, disponibile anche nella Roadmap di Microsoft. Questo metodo di crittografia offre una maggiore protezione non offerta da BitLocker perché consente la separazione degli amministratori del server e delle chiavi crittografiche necessarie per la decrittografia dei dati e poiché la crittografia viene applicata direttamente ai dati (a differenza di BitLocker, che applica la crittografia al volume del disco logico), tutti i dati dei clienti copiati da un server exchange rimangono crittografati.

L'ambito per la crittografia del servizio Exchange è costituito dai dati dei clienti archiviati inattivi all'interno di Exchange.

Microsoft Teams

Teams usa TLS e MTLS per crittografare i messaggi istantanei. Tutto il traffico da server a server richiede MTLS, indipendentemente dal fatto che il traffico sia limitato alla rete interna o attraversi il perimetro di rete interno.

Questa tabella riepiloga i protocolli usati da Teams.

Crittografia multimediale

Il traffico multimediale viene crittografato tramite SRTP (Secure RTP), un profilo del protocollo RTP (Real-Time Transport Protocol) che garantisce riservatezza, autenticazione e protezione da attacchi di tipo replay per il traffico RTP. SRTP usa una chiave di sessione generata tramite un generatore di numeri casuali sicuro e viene scambiata tramite il canale TLS di segnalazione. Il traffico multimediale da client a client viene negoziato tramite una segnalazione di connessione da client a server, ma viene crittografato tramite SRTP quando si passa direttamente da client a client.

Teams usa un token basato su credenziali per l'accesso sicuro agli inoltri multimediali tramite TURN. Gli inoltri multimediali scambiano il token su un canale protetto da TLS.

FIPS

Teams usa algoritmi conformi a FIPS (Federal Information Processing Standard) per gli scambi di chiavi di crittografia. Per altre informazioni sull'implementazione di FIPS, vedere Federal Information Processing Standard (FIPS) Publication 140-2.For more information on the implementation of FIPS, see Federal Information Processing Standard (FIPS) Publication 140-2.