Protecting your data in Office 365

Having a hard time understand data protection technologies in Office 365? This post addresses service keys, BYOK, and HYOK.

secureThe old adage “If you are confused about something, then someone else probably is too” applies to this post.  I am working with several customers who want to understand their options when it comes to securing their data in Office 365.

There are multiple technologies available and its important to understand the scenarios and risks you are trying to protect to apply the right controls.  To better understand how Office 365 protect customers data in a multi-tenant (shared) platform take a look at Scott Schnoll’s post that makes it easy to view material in the risk assurance library.  This site has links to an interactive PowerPoint that if you select Encryption, links to a whitepaper.  There is a section titles ‘Office 365 Service Encryption’  that explains how data at rest and in transit is protected for the various workloads (e.g. SharePoint Online, Skype for Business Online, Exchange Online).  The data at rest protection acts as a security boundary and is analogous to ‘drive encryption’ (like BitLocker).  Alternatively, Azure RMS addresses data at rest and in transit. In summary, the protection features I’m discussing are:

The FAQ ‘Customer Key for Office 365 FAQ‘ summarizes the difference between the two very well:

Both options enable you to provide and control your own encryption keys; however, service encryption with Customer Key encrypts your data at rest, residing in Office 365 servers at-rest, while BYOK with Azure Information Protection for Exchange Online encrypts your data in-transit and provides persistent online and offline protection for email messages and attachments for Office 365. Customer Key and BYOK with Azure Information Protection for Exchange Online are complementary, and whether you choose to use Microsoft’s service-managed keys or your own keys, encrypting your data at-rest and in-transit can provide added protection from malicious attacks.

Each of these features have the options around key management.  Either Microsoft manages your keys (the default) or the customer can manage the keys.  It is best to not share a key across service encryption and Azure RMS, but to use distinct separate keys.

99% of the time, I highly recommend customers leave the default and have Microsoft do the key management.  Managing your own keys is not trivial, and if done incorrectly risks losing access to all your tenant data – and Microsoft will not be able to fix this.

HYOK vs BYOK

Now that we are clear on the difference between service keys (customer keys) and RMS – there are multiple options for RMS.  (I call these *YOK – star your own key).

BYOK is simply using the Azure RMS (AIP) service with customer managed keys.  HYOK is an architecture that integrates your on premises AD RMS with Azure RMS.  The benefit of HYOK is that for some data, you keep it out of the cloud and use your OWN AD, your OWN RMS server, and your OWN HSM.  Sounds great, but there are some important considerations.  These are well documented here Azure Information Protection with HYOK (Hold Your Own Key).

To summarize, 99% of the time customers should use the default – Microsoft managed RMS keys.  If you need your own keys, 99% of the time you should go with the BYOK architecture.

Why?

When I go down this path with a customer who wants to do their own keys, I ask what is it they are trying to achieve.  The main reason for managing your own keys if should you ever leave the service – you can ensure that no one has any access to your data (by revoking the key).  While in the service, Microsoft still needs and has access to the data – otherwise features like search and indexing would not work.  Given the added complexity and potential catastrophic loss of data, this is a decision that needs careful consideration and understanding on why a customer should go down this path.

 

note:edited to remove link to outdated whitepaper