Practical Protection: Document Encryption in Microsoft 365

In general, people tend to think that having no choice is bad. In his seminal 2009 book Paradox of Choice, Barry Schwartz argued that having too many choices is also bad. Somewhere in between “none” and “too many,” then, there must be an optimal number of choices for most things, including potential solutions to a problem. With that in mind, let’s take a look at how Microsoft helps its customers solve the problem of document confidentiality. It’s hard to think of a better example of how the “defense in depth” model works in the service.

Encryption at Rest and in Transit

Let’s start with the acknowledgment that Microsoft encrypts data both at rest and in transit. For example, Microsoft uses BitLocker in its own data centers to protect stored data, and every connection between servers (or between client and server) is protected with TLS. These encryption methods are intended to guard against two specific scenarios. TLS protects against eavesdropping or man-in-the-middle scenarios, where an attacker grabs network traffic. At-rest encryption protects against the scenario where an attacker steals a physical disk volume from a data center. Of course, BitLocker (and FileVault, the macOS equivalent) can also protect individual volumes on your laptop or desktop from theft, so you should be using them too on your endpoints.

“No Trespassing” isn’t Enough

If we have encryption applied to protect against eavesdroppers and blatant disk theft, the next obvious way to protect document confidentiality is to use permissions. In fairness, this is good enough for the majority of applications; documents held in a user’s OneDrive, in a SharePoint site, or in a mailbox will only be accessible to people who have permission to see them or with whom the objects have been shared. It’s reasonable to ask why you need document encryption if you are diligent about assigning and auditing permissions. The short answer is that permissions work to protect against access by unauthorized users—there’s also the case where someone who has privileged access to a document but isn’t supposed to read it uses their privileges to do so. Imagine a “global admin gone bad” scenario, and you’re not too far off. Access controls and robust auditing can help you catch cases where a privileged user goes rooting around in things they’re not supposed to see, but it doesn’t necessarily prevent it. (one way you can help prevent it is to require just-in-time privilege escalation through Azure AD Privileged Identity Management, something we’ll talk about in a future column).

Adding Another Layer of Encryption

Suppose that you want to apply an additional layer of protection to your documents. You might do this because you want to prevent your own administrators from snooping or because you want an additional safeguard against Microsoft’s staff. Microsoft already applies what they call service encryption, where they generate and manage cryptographic keys that are used to protect your data. Service encryption is automatic and forms part of the baseline service protection that Microsoft delivers to all tenants. Most organizations are happy enough with basic service encryption. In fact, the majority of tenant admins probably don’t know it exists. If you need additional protection, there are two ways you can get it: you can use customer key encryption (sometimes known as “bring your own key” or “hold your own key”), or you can use double-key encryption.

Bringing your own Key with Purview Customer Key

Understanding Customer Key, and what it’s useful for, will take a little effort. Let’s start with the concept that there’s a root cryptographic key that is used to derive other keys that protect your specific data. With regular service encryption, Microsoft holds this key, and you don’t have any access to it. With Customer Key, you generate the key and provide it to Microsoft. That raises a whole host of interesting questions, such as how you generate the key securely, where it is stored, and what Microsoft does with it. The short answer is that you generate two root keys yourself, storing each of them in Azure Key Vault (AKV) in a separate Azure subscription. If you wish, you can deploy hardware key-storage modules with AKV. Once you’ve generated these two keys, you enable Customer Key (by asking Microsoft to do it; you can’t enable it yourself) and create data encryption policies (DEPs) that tell the service what keys to use for the specific workloads you want to protect.

Keep in mind: that was the short version. The full setup documentation is quite a bit more involved.

Because losing your Customer Key root keys means you’d lose all access to your stored data in the service, Microsoft also uses the keys you generate to create an availability key, which they use in a variety of automated systems to ensure that operations such as search and retention policy application work OK. The key thing to remember here is that Microsoft’s systems can’t do anything with your data unless they have your key… and if you’ve given them your key, you have to consider whether using Customer Key is actually providing you with additional protection. Most of the customers I’ve spoken to who are interested in Customer Key want it because they have specific compliance requirements that demand it.

Double-Key Trouble

If you really, really don’t want Microsoft to be able to see your data, you’re in luck: you can use Double-Key Encryption (DKE). In a DKE deployment, you create an Azure Information Protection sensitivity label that applies DKE only to selected items—Microsoft warns that it “is intended for your most sensitive data that is subject to the strictest protection requirements. DKE isn’t intended for all data.” When you deploy DKE (a much more complicated process than you might first imagine), you actually create a key that only you hold, then publish it in AKV and create an Azure service to catch encryption requests. Then you configure Microsoft 365 to know about that service.

To use DKE, users will manually apply the sensitivity label associated with DKE on the most business-critical items, at which point they’ll be encrypted on the client device using the service you published. After the client-side encryption is complete, the encrypted blob is stored as a file in the user’s OneDrive, in a SharePoint site, in an email attachment, or whatever. Here’s the problem with that approach: because the content is encrypted in a way the service can’t read, lots of stuff won’t work. For example, eDiscovery searches can’t read DKE-protected items, nor can Exchange transport rules. That’s because the key you created is never made available to the Microsoft 365 service.

DKE is still somewhat of a science-project feature- it works, but there are lots of practical limitations that mean you will have to be prepared to do some master-level tinkering and troubleshooting to use it.

Both DKE and BYOK require the users to be licensed with one of the E5 family of licenses.

What if I Just Want to Encrypt Email?

In this column, I didn’t bring up email-specific encryption features such as Purview message encryption or S/MIME. These solutions don’t protect documents unless they happen to be attached to a mail message, so I left them out, but expect to see them discussed in a future column.

Where to Go From Here

Before you spend any time implementing BYOK or DKE, you really should step back and take a dispassionate look at what specific security benefits you think these technologies will bring you. Every security feature is a tradeoff between security on one hand and convenience (or maintainability, performance, or other aspects of the overall system) on the other. The additional administrative burden, the risk of data loss if your key management is poor, and the reduced functionality available when DKE is deployed means that these technologies should only be applied when you can identify clear and significant benefits for doing so.