Freigeben über

The Saga of Hold Your Own Key (AIP Classification with AD RMS Protection)

  • Artikel

The Situation:

Azure Information Protection (AIP) is a powerful technology for Classifying and Protecting sensitive data which was designed around the cloud based Azure RMS service for protection.  This is great for new users of Microsoft Information Protection technologies as there is less investment in on premises servers that must be maintained and secured.  However, for current AD RMS users that cannot use a cloud-based key for regulatory or technical reasons, this left them without the Classification capabilities provided by AIP and the collaboration features provided when using a cloud key.  Luckily, the amazing AIP product group has come up with a solution that provides customers with a method to allow AIP labels to use AD RMS for protection.  This solution was dubbed Hold Your Own Key (HYOK).  Although there are limitations to HYOK (less external collaboration options, limited application support, continued on-premises server maintenance),  it has opened up the possibility of using AIP classification for customers that must maintain on premises keys for some of their data.

Per the official documentation, Hold Your Own Key protection is designed for documents and emails that require the encryption key to be isolated from the cloud. HYOK protection doesn't provide the same benefits that you get when you use cloud-based key protection, and it often comes at the cost of "data opacity". This phrase means that only on-premises applications and services will be able to open HYOK-protected data; cloud-based services and applications cannot reason over HYOK-protected data.

Even for the organizations that use HYOK protection, it is typically suitable for a small number of documents that need to be protected. As guidance, use it only for documents and when they match all the following criteria:

  • The content has the highest classification in your organization ("Top Secret") and access is restricted to just a few people
  • The content is not shared outside the organization
  • The content is only consumed on the internal network

Because HYOK protection is an administrator configuration option for a label, user workflows remain the same, irrespective of whether the protection uses a cloud-based key or HYOK.

Scoped policies are a good way to ensure that only the users who need to apply HYOK protection see labels that are configured for HYOK protection.

The Solution:

Implementing HYOK is fairly straightforward but can be complicated in situations where there are multiple forests involved.  I recommend reviewing the prerequisite requirements listed at /en-us/azure/information-protection/deploy-use/configure-adrms-restrictions if you have multiple forests where you share AD RMS protected data.  The rest of this post assumes that you have a single forest AD RMS implementation and walks through the configuration of AIP labels for HYOK.  Additionally, HYOK requires an AIP P2 license (included with EMS E5) for all users that will be able to protect documents using an HYOK label (another reason you may want to limit these policies to a smaller subset of scoped users).

The core assumption of HYOK is that you have an AD RMS farm on premises with configured rights management policy templates that you have been using, or that you will configure those prior to creating your HYOK labels in the AIP portal.  I will assume that you are using AIP cloud key or Bring Your Own Key based protection for a majority of your AIP labels, so we will only set up one HYOK label to demonstrate the process necessary to use the solution.  For creation of standard AIP labels, you can see my previous post at https://blogs.technet.microsoft.com/kemckinn/2018/05/17/creating-labels-for-azure-information-protection/.

Creating the "Top Secret" Label and Scoped Policy

To create an HYOK protected label, first create the AIP label per the instructions at /en-us/azure/information-protection/deploy-use/configure-policy-new-label or the blog post I referenced above.  For my demo tenant, I have created a sub-label of Highly Confidential called "Top Secret".

Next, I created a scoped policy named Top Secret and scoped it to the Top Secret group. Instructions for creating a scoped policy can be found at /en-us/azure/information-protection/deploy-use/configure-policy-scope.

After creating the scoped policy, I click on the Add or remove labels link and selected the Top Secret label to add to the policy.

The following image shows what my Highly Confidential label looks like after assigning the TS label to the scoped policy.

Gathering Data from the AD RMS Server

Next, we will go to the AD RMS server and gather the required Policy GUID and licensing URL that we will use for the HYOK label we created above.

Log onto one of the AD RMS servers in your farm and open the AD RMS Admin Console. In the AD RMS console, expand the node and select Rights Policy Templates.

Note the Template file location and the GUID associated with the Top Secret RMS Policy Template.  Next, browse to the share or folder where the templates are located.

Right-click on the template and open it in Notepad.

In Notepad, you can select the GUID associated with the label you will use for HYOK.  Copy this to a new document.

Next, copy the licensing URL from the same template into your new document.  These are the two items needed for an HYOK label.

Adding Protection to the HYOK Label

For the last step in configuring HYOK, return to the Top Secret label we created earlier and click on Protect > Azure (cloud key).

In the Protection blade, under Protection settings, click on HYOK (AD RMS) and enter the copied Rights Policy Template GUID and Licensing URL gathered in the previous section.

Press OK and the Label should look similar to the image below.

Save the label and you have successfully configured a label for Hold Your Own Key. Repeat as needed, but remember that HYOK is designed to be used sparingly for specific data like the Top Secret label, but you should use Bring Your Own Key or Cloud Key for other labels to allow for advanced collaboration capabilities.  If you do not do this, any content that needs to be shared externally, consumed via cloud services, or otherwise used in a way that is not compatible with the protections implemented by HYOK will end up being send as unprotected content.  It is far better to have content protected with a cloud key for collaboration than simply sending items externally in clear text.

Additionally, it would be wise to train your users on the restrictions on your HYOK labels.  If, for instance, you grant specific trusted users Full Control rights on the HYOK template, you can teach your other users that if they need to share something externally they can ask one of these trusted users to reclassify the content with a label that uses a cloud key (e.g. Partner Confidential) prior to sharing. This is the best of both worlds and will ensure encryption for the largest subset of your sensitive data.

Please let me know if I missed anything, and if you find this content useful, please rate it so I know.  Thanks!

Kevin