Share via

Encryption for SharePoint and OneDrive, Microsoft Teams, and Exchange

  • Article

Microsoft 365 is a highly secure environment that offers extensive protection in 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 keys are either created and managed by the SharePoint service, or when Customer Key is used, created, and managed by customers. When a file is uploaded, encryption is performed by SharePoint within the context of the upload request, before being sent to Azure storage. When a file is downloaded, 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 has no ability to decrypt, or even identify or understand the customer data. All encryption and decryption happen in the same systems that enforce tenant isolation, which are 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 additional 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 using its own unique AES 256-bit key.

  • When a file is updated, the update is handled in the same way: the change is split into one or more chunks, and each chunk is encrypted with a separate unique key.

  • These chunks – files, pieces of files, and update deltas – are stored 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 keys used to encrypt the blobs are stored in the SharePoint Content Database.
    • The Content Database is protected by database access controls and encryption at rest. Encryption is performed using 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 map used to re-assemble the file is stored in the Content Database 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). Each set of credentials is held in the secure Key Store and is regularly refreshed. 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 key to each chunk of customer data is encrypted and stored separately in the Content Database. 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 credentials used to access the Azure storage containers are also held in the SharePoint secret store and delegated 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.

Note

For Office 365 U.S. Government customers, data blobs are stored in Azure U.S. Government Storage. In addition, access to SharePoint keys in Office 365 U.S. Government is limited to Office 365 staff that have been specifically screened. Azure U.S. Government operations staff do not have access to the SharePoint key store that is used for encrypting data blobs.

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 are created ad-hoc or that can live more dynamically within a site, such as rows in a user-created list, individual posts in a SharePoint blog, or entries within a SharePoint wiki page. List items are stored in the Content Database (Azure SQL Database) and protected with TDE.

Encryption of data in transit

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

  • 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, and 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 is confined to the internal network or crosses the internal network perimeter.

This table summarizes the protocols used by Teams.

Traffic type Encrypted by
Server-to-server MTLS
Client-to-server (ex. instant messaging and presence) TLS
Media flows (ex. audio and video sharing of media) TLS
Audio and video sharing of media SRTP/TLS
Signaling TLS

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 using a secure random number generator and is exchanged using the signaling TLS channel. Client-to-client media traffic is negotiated through a client-to-server connection signaling but is encrypted using SRTP when going client-to-client directly.

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.