Encryption for Skype for Business, OneDrive for Business, SharePoint Online, Microsoft Teams, and Exchange Online
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.
Skype for Business
Skype for Business customer data may be stored at rest in the form of files or presentations that are uploaded by meeting participants. The Web Conferencing server encrypts customer data using AES with a 256-bit key. The encrypted customer data is stored on a file share. Each piece of customer data is encrypted using a different randomly generated 256-bit key. When a piece of customer data is shared in a conference, the Web Conferencing server instructs the conferencing clients to download the encrypted customer data via HTTPS. It sends the corresponding key to clients so that the customer data can be decrypted. The Web Conferencing server also authenticates conferencing clients before it allows the clients access to conference customer data. When joining a Web conference, each conferencing client establishes a SIP dialog with the conferencing focus component running inside the front-end server over TLS first. The conferencing focus passes to the conference client an authentication cookie generated by the Web Conferencing server. The conferencing client then connects to the Web Conferencing server presenting the authentication cookie to be authenticated by the server.
SharePoint Online and OneDrive for Business
All customer files in SharePoint Online 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 Online service, or when Customer Key is used, created and managed by customers. When a file is uploaded, encryption is performed by SharePoint Online within the context of the upload request, before being sent to Azure storage. When a file is downloaded, SharePoint Online 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 Online.
Several workloads in Microsoft 365 store data in SharePoint Online, including Microsoft Teams, which stores all files in SharePoint Online, and OneDrive for Business, which uses SharePoint Online for its storage. All customer data stored in SharePoint Online 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 Online 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 Online, 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 as well as 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 is 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 Online 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 Online secret store and delegated to each SharePoint Online 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 Online farms are not 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 Online 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 Online key store that is used for encrypting data blobs.
For more information about data encryption in SharePoint Online and OneDrive for Business, see Data Encryption in OneDrive for Business and SharePoint Online.
List Items in SharePoint Online
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 Online blog, or entries within a SharePoint Online wiki page. List items are stored in the Content Database (Azure SQL Database) and protected with TDE.
Encryption of data in transit
In OneDrive for Business and SharePoint Online, there are two scenarios in which data enters and exits the datacenters.
- Client communication with the server - Communication to SharePoint Online and OneDrive for Business 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 is further protected with best-in-class encryption.
Exchange Online
Exchange Online 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 Online 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 Online service encryption is customer data that is stored at rest within Exchange Online. (Skype for Business stores nearly all user-generated content within the user's Exchange Online mailbox and therefore inherits the service encryption feature of Exchange Online.)
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, please see Federal Information Processing Standard (FIPS) Publication 140-2.
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla