Encryption for SharePoint and OneDrive, Microsoft Teams, and Exchange

Microsoft 365 is a highly secure environment that offers extensive protection through multiple layers: physical data center security, network security, access security, application security, and data security.

SharePoint and OneDrive

All customer files in SharePoint are protected by unique, per-file keys that are always exclusive to a single tenant. The SharePoint service either creates and manages these keys or, when you use Customer Key, you create and manage them. When you upload a file, SharePoint encrypts the file within the context of the upload request before sending it to Azure storage. When you download a file, SharePoint retrieves the encrypted customer data from Azure storage based on the unique document identifier and decrypts the customer data before sending it to the user. Azure storage can't decrypt, identify, or understand the customer data. All encryption and decryption happen in the same systems that enforce tenant isolation: Microsoft Entra ID and SharePoint.

Several workloads in Microsoft 365 store data in SharePoint, including Microsoft Teams, which stores all files in SharePoint, and OneDrive, which uses SharePoint for its storage. All customer data stored in SharePoint is encrypted with one or more AES 256-bit keys and distributed across the datacenter as follows. Every step of this encryption process is FIPS 140-2 Level 2 validated. For more information about FIPS 140-2 compliance, see FIPS 140-2 Compliance.

• Each file is split into one or more chunks, depending on file size. Each chunk is encrypted with its own unique AES 256-bit key.

• When you update a file, SharePoint handles the update in the same way: it splits the change into one or more chunks, and encrypts each chunk with a separate unique key.

• SharePoint stores these chunks – files, pieces of files, and update deltas – as blobs in Azure storage that are randomly distributed across multiple Azure storage accounts.

• The set of encryption keys for these chunks of customer data is itself encrypted.

  • The SharePoint Content Database stores the keys used to encrypt the blobs.
  • Database access controls and encryption at rest protect the Content Database. Encryption uses Transparent Data Encryption (TDE) in Azure SQL Database. Azure SQL Database is a general-purpose relational database service in Microsoft Azure that supports structures such as relational data, JSON, spatial, and XML. These secrets are at the service level for SharePoint, not at the tenant level. These secrets, sometimes referred to as the master keys, are stored in a separate secure repository called the Key Store. TDE provides security at rest for both the active database and the database backups and transaction logs.
  • When customers provide the optional key, the customer key is stored in Azure Key Vault, and the service uses the key to encrypt a tenant key, which is used to encrypt a site key, which is then used to encrypt the file level keys. Essentially, a new key hierarchy is introduced when the customer provides a key.

• The Content Database stores the map used to re-assemble the file along with the encrypted keys, separately from the master key needed to decrypt them.

• Each Azure storage account has its own unique credentials per access type (read, write, enumerate, and delete). The secure Key Store holds each set of credentials and regularly refreshes them. As described above, there are three different types of stores, each with a distinct function:

  • Customer data is stored as encrypted blobs in Azure storage. The Content Database encrypts and stores the key to each chunk of customer data separately. The customer data itself holds no clue as to how it can be decrypted.
  • The Content Database is a SQL Server database. It holds the map required to locate and reassemble the customer data blobs held in Azure storage and the keys needed to encrypt those blobs. However, the set of keys is itself encrypted (as explained above) and held in a separate Key Store.
  • The Key Store is physically separate from the Content Database and Azure storage. It holds the credentials for each Azure storage container and the master key to the set of encrypted keys held in the Content Database.

Each of these three storage components – the Azure blob store, the Content Database, and the Key Store – is physically separate. The information held in any one of the components is unusable on its own. Without access to all three, it's impossible to retrieve the keys to the chunks, decrypt the keys to make them usable, associate the keys with their corresponding chunks, decrypt each chunk, or reconstruct a document from its constituent chunks.

BitLocker certificates, which protect the physical disk volumes on machines in the datacenter, are stored in a secure repository (the SharePoint secret store) that is protected by the Farm key.

The TDE keys that protect the per-blob keys are stored in two locations:

• The secure repository, which houses the BitLocker certificates and is protected by the Farm Key; and
• In a secure repository managed by Azure SQL Database.

The SharePoint secret store holds the credentials used to access the Azure storage containers and delegates them to each SharePoint farm as needed. These credentials are Azure storage SAS signatures, with separate credentials used to read or write data, and with policy applied so that they auto-expire every 60 days. Different credentials are used to read or write data (not both) and SharePoint farms aren't given permissions to enumerate.

For more information about data encryption in SharePoint and OneDrive, see Data Encryption in SharePoint and OneDrive.

List items in SharePoint

List items are smaller chunks of customer data that you create ad-hoc or that can live more dynamically within a site. Examples include rows in a user-created list, individual posts in a SharePoint blog, or entries within a SharePoint wiki page. The Content Database (Azure SQL Database) stores list items and protects them with TDE.

Encryption of data in transit

In OneDrive and SharePoint, data enters and exits the datacenters in two scenarios.

• Client communication with the server - Communication to SharePoint and OneDrive across the Internet uses TLS connections.
• Data movement between datacenters - The primary reason to move data between datacenters is for geo-replication to enable disaster recovery. For instance, SQL Server transaction logs and blob storage deltas travel along this pipe. While this data is already transmitted by using a private network, it's further protected with best-in-class encryption.

Exchange

Exchange uses BitLocker for all mailbox data. The BitLocker configuration is described in BitLocker for Encryption. Service-level encryption encrypts all mailbox data at the mailbox level.

In addition to service-encryption, Microsoft 365 supports Customer Key, which is built on top of service-encryption. Customer Key is a Microsoft-managed key option for Exchange service encryption that is also on Microsoft's Roadmap. This method of encryption provides increased protection not afforded by BitLocker because it provides separation of server administrators and the cryptographic keys necessary for decryption of data, and because the encryption is applied directly to the data (in contrast with BitLocker, which applies encryption at the logical disk volume) any customer data copied from an Exchange server remains encrypted.

The scope for Exchange service encryption is customer data that is stored at rest within Exchange.

Microsoft Teams

Teams uses TLS and MTLS to encrypt instant messages. All server-to-server traffic requires MTLS, regardless of whether the traffic stays within the internal network or crosses the internal network perimeter.

This table summarizes the protocols used by Teams.

Media encryption

Media traffic is encrypted using Secure RTP (SRTP), a profile of Real-Time Transport Protocol (RTP) that provides confidentiality, authentication, and replay attack protection to RTP traffic. SRTP uses a session key generated by a secure random number generator and exchanges it by using the signaling TLS channel. Client-to-client media traffic is negotiated through a client-to-server connection signaling but is encrypted by using SRTP when it goes directly from client to client.

Teams uses a credentials-based token for secure access to media relays over TURN. Media relays exchange the token over a TLS-secured channel.

FIPS

Teams uses FIPS (Federal Information Processing Standard) compliant algorithms for encryption key exchanges. For more information on the implementation of FIPS, see Federal Information Processing Standard (FIPS) Publication 140-2.