Azure Information Protection with HYOK (Hold Your Own Key)

[Azure Information Protection Team]

First published on CloudBlogs on Aug 10, 2016
Please note, this post has been updated on June 19, 2017 as this feature is now generally available. Hi everyone, Today we’re delighted to announce HYOK, an information protection feature designed to support organizations that need to comply with complex regulation and compliance policies is now generally available.

Overview

Many of you manage highly-regulated organizations, and have asked us how to protect the top few percent of your most sensitive information in a manner that is opaque to anyone but you. The ask is directly linked to your organization’s requirement of maintaining full control over the encryption keys and over the authorization process (for the ‘top-secret’ data). At the same time, you want to leverage Azure Information Protection to protect the bulk of your sensitive data to take advantage of features that require the cloud – features like document tracking and revocation, departmental templates, B2B (and soon B2C) sharing of emails and documents, extensive mobile device support, enjoying a lower overall TCO, and often most importantly, the required deep interoperability with Office 365. Lastly, in environments where these two services coexist, the user experience must remain seamless, regardless of where the keys are. This last point is critical.

Introducing HYOK

The Azure Information Protection HYOK – Hold Your Own Key – feature is about enabling an organization to protect data in a way where, well, you hold the key. Whereas BYOK – Bring Your Own Key – hosts the RMS key in Azure Key Vault HSMs, HYOK has you operating your own AD, your own RMS server, and your own HSMs for key retention. The HYOK concept is quite simple: You deploy multiple RMS services within a singular Azure Information Protection environment. At a top level, here’s what you would do:

1. You deploy Azure Information Protection in your organization as per usual guidance. In effect, the Azure Information Protection services (Azure RMS, Azure Information protection configuration in Azure) are always cloud hosted but they enable you to operate in a cloud-only, hybrid, or on-premises only (via the RMS connector) deployment.
2. Azure RMS is where you define your Azure RMS protection policies for sensitive data.
3. AD RMS is where you define your AD RMS protection policies, for ‘top-secret’ data.
4. Your Azure Information Protection service is where you define all your classification labels. Most of them will be bound to an Azure RMS server but some can now be bound to an AD RMS server.

When an end user makes use of their classification user interface, they see labels not really knowing which RMS server is used… by design! They pick the label and you, as IT, set the policy that gets applied. That’s it! By way of example, in this label taxonomy, My Group could be bound to AD RMS and All Employees bound to Azure RMS. Your users need not care.

A word of caution

HYOK is not for everyone. Some may think the ‘warm blanket’ of HYOK is comforting, but it’s not quite all that. The HYOK offer is meant for cases where opaque data is required and it comes with trade-offs. Let us explain a few aspects of the design point:

1. HYOK works solely with your AD and AD RMS instance. Because it’s targeted at ‘top-secret’ data, we urge you to keep AD RMS out of your DMZ. After all, your DMZ is our cloud… so for those collaboration use cases, just use Azure RMS. We also recommend HYOK be used with fully-managed PCs following the same ‘top-secret’ rationale. This means your users can only access this most sensitive data using a VPN into your org, via an on-premises AD identity, and while on a PC that you carefully manage. The moment you deviate from this, your assurances slide and we strongly urge you to fall back to Azure RMS so as to give your users all the benefits of Azure RMS. If you really have B2B ‘top-secret’ use cases, then you need to create business accounts in your AD for your guests.
2. Office 365 cannot ‘reason over the data’ when it is opaquely encrypted with HYOK. You asked for opaque data that was resistant to the various concerns you have about data protection and privacy. We are offering you control over your service and keys with HYOK. However, with opaque data comes a long list of side effects because Office actively interacts with your data to provide rich, enterprise-grade capabilities (it’s not just plain old ‘blob storage’ or a plain old POP3 mailbox). Office enables many delightful experiences that will cease to work if data is opaque: No search, no web viewers, no pivoted views, no anti-malware, no anti-spam, no eDiscovery, no Delve, and so on. We plead all considering the use of HYOK to use it for that narrow few percent of absolutely toxic data. Overuse of HYOK in templates could turn out to be very similar to what happened when Group Policy was first introduced; the first wave of IT leaders went overboard on restrictive policies and their users revolted.
3. You are now managing two or more separate instances of RMS protection: Azure RMS and AD RMS. We are providing the capability for you to present these as one thing to a user, but the IT infrastructure is isolated from each other. With all this power comes IT burden, more on-premises infrastructure, higher TCO, and so on.
4. While you can use HYOK option for documents, it is not supported for emails.

Net: HYOK is a special tool, for a special purpose: Data opacity at all costs. The large majority of you will be perfectly happy with only using Azure Information Protection backed by Azure RMS and BYOK. The most regulated few will use BYOK for most data and HYOK with restraint.

Configuring HYOK

A critical (deal-breaking) design requirement for HYOK was assurance that there is complete segregation between your private AD RMS servers and the cloud services. We met this requirement, but it has introduced a bit of ‘copy and paste’ in the administration model. Here are the core steps: 1)    You deploy AD RMS per usual or use the AD RMS instances you already have in use. 2)    You associate an AD RMS protection policy with an Azure Information Protection classification label by copying the AD RMS template GUID and cluster licensing URL into our Azure Information Protection admin portal. This manual step is required as you don’t want to let our cloud service ‘reach into’ your on-premises AD RMS. Here’s how you do it… First, fetch the AD RMS template GUID and licensing URL, from the AD RMS admin console as circled in the below three images. These images show AD RMS on Windows Server 2012 R2, but the experience of previous AD RMS versions is very similar. Next, in the Azure Information Protection admin portal, associate an AD RMS template with a label by pasting in the data you just copied. That’s it. Now you simply publish the policy to your test environment, and validate it.

HYOK availability

This capability is available as part of the recently-announced public preview of Azure Information Protection. You need to have Azure Information Protection client version 1.0.233 (available for download today) or higher. Office integration is limited to Office 2013 and 2016. Office 2010 will not be supported for HYOK. Windows support is for Windows 7 or higher. You need to have AD RMS working in your environment, with single sign-on setup, and only use one root cluster of AD RMS servers. There is no need for AD RMS mobile device extension. In fact, we do not recommend enabling RMS in the DMZ or on mobile devices per above. Lastly, this capability will require an Azure Information Protection Premium P2 license (also part of the EMS E5 SKU). For details on licensing, please refer to this blog post.

In closing

We would love to hear back from you with any comment or question you may have.

Please engage with us on Yammer .

Thank you! The Azure Information Protection team