How to prepare an Azure Information Protection “Cloud Exit” plan

[Martin_Sieber]

Microsoft is confident its cloud services can meet the needs of the vast majority of our customers and there should seldom be a need to discontinue their use. But some organizations require a clearly defined process to discontinue the usage and any dependency on a cloud service without losing access to their data before adopting it - to be prepared in case the need arose.
Azure Information Protection (AIP) provides such ability for both customers using Bring your own Key (BYOK) and customers using a Microsoft-managed key (MMK).
In both cases, accessing previously protected content after a cloud exit is limited to users on Windows machines in the Intranet - irrespective on which platform the content was protected originally with AIP.
Please observe that the procedures described here are not meant for labeling/protecting content after a cloud exit.

Cloud Exit for an organization with a Microsoft Managed Key

A Microsoft Managed Key (MMK) is created automatically when provisioning an AIP tenant. This key is software-based, and Microsoft maintains responsibility for the whole key life cycle. See our documentation for more details on this key option.

Cloud Exit for AIP with Microsoft Managed Key

Customers using an MMK may execute the process reactively at any point after they start using the service without any special preparation. When the time comes to execute a cloud exit, they ask Microsoft technical support to export the organization’s MMK and all associated artifacts in the form of a Trusted Publishing Domain (TPD). This can be done proactively before the Cloud Exit is needed, but the TPD provided by Microsoft needs to be stored in a very secure form after it's received since it contains the keys to decrypt all the organization's protected content. (Be aware that labels created in AIP after the TPD export aren't reflected in the stored TPD; content protected with these new labels may only be accessible with AD RMS super user rights.)
Such TPD file can be then imported in a clean installation of Active Directory Rights Management Services. Afterwards this (on-premises) AD RMS cluster can be used to license content protected with the MMK through the AIP service from any Windows client that is configured with special redirections in the registry.
This setup allows administrators with AD RMS super user privilege to access and optionally unprotect any content. Regular end users are capable of consuming content protected explicitly for them as well as content labeled with predefined permissions granting them access.

The following end to end process provides a cloud exit solution for organizations using MMK:

1. Provision the AIP service, configure it as desired and start using it normally.
2. If the need to discontinue using the service is identified, request the export of the Microsoft Managed Key as part of a TPD file.
3. Install a new AD RMS cluster, with default configurations and register the Service Connection Point in Active Directory, following our guidance.
4. Import the TPD file provided by Microsoft into AD RMS either using the AD RMS Management Console or the equivalent PowerShell functionality.
5. Configure clients to use Licensing redirections pointing the AIP URL to the AD RMS cluster URL. You can apply the same settings in the scripts used for a migration from AD RMS to AIP, reversing the position of the redirection URLs in the registry.
6. Configure the super user feature in AD RMS, using a suitable AD group that will contain administrators with super user privilege.
7. Use AD RMS normally to consume content protected before the execution of the cloud exit.

Cloud Exit for organizations using Bring your own Key

A Bring Your Own Key (BYOK) is created by the customer in a nCipher HSM and securely transferred to an HSM-based Azure Key Vault where it will be used by AIP. As a BYOK cannot be exported by Microsoft, the customer is fully responsible for this key in their own nCipher HSM. Customers choose this option to satisfy their requirement of an HSM-based key - considering a higher effort to manage their key than with the MMK option. This is discussed in our documentation.

Cloud Exit for AIP with Bring your own Key

Customers using AIP with the BYOK option need to execute a preparation process prior to the deployment of AIP (in particular, prior to the switch from MMK to BYOK).

Assuming correct preparation, a later Cloud Exit will provide the following capabilities:

• Administrators with AD RMS super user privilege may access and optionally unprotect any content.
• Normal end users are also capable to consume content protected explicitly for them, they are also capable to open content protected with labels/templates that were created during the initial preparation and provisioning.
• The end user isn’t capable to access any content labelled/protected with predefined permissions that were created afterwards, so they will need to escalate such requests to the super user.

The following preparation steps are mandatory to allow a later cloud exit for a BYOK customer:

1. Before provisioning the AIP service, install a clean AD RMS cluster, using a nCipher HSM to host the key for the cluster and *without* registering the Service Connection Point (SCP) in Active Directory. You may follow our published guidance.  The key used for this cluster will be the one you will later use in AIP, so it’s suggested to provision it according to your security and operational requirements.
2. Create AD RMS templates for all the labels you intend to create in AIP. Using the same names, descriptions and rights as in the future AIP labels is ideal, but not required.
3. It’s also suggested to create more templates in AD RMS which can later be used for additional AIP labels.
   The rationale of all templates in AD RMS is to ensure the GUIDs of these AD RMS templates will be consistent with the GUIDs of AIP labels - this is a prerequisite for AD RMS later identifying content protected with AIP labels after a cloud exit.
4. Execute Phase 2 of the AD RMS to AIP migration process using the Bring your own Key option. This will bring the key and the templates you provisioned on-premises to the cloud service.
5. Convert the newly imported templates into AIP labels as needed. Keep the remaining imported templates archived. Configure other AIP settings as needed and start using AIP as per your desired scenarios.
   To convert templates to labels, use the following command, making sure you use the appropriate value for the "EncryptionTemplateId" parameter:

   New-Label -Name TestLabel -EncryptionTemplateId 514a86b6-67ac-43e7-8682-f7e9d00bb7e7 -DisplayName TestLabel -ToolTip "This is a TestLabel" -EncryptionEnabled $true -EncryptionProtectionType Template

6. Decommission AD RMS.
   a) Make a backup of the AD RMS databases and keep it in a safe place.
   b) Make a copy of the AD RMS TPD and keep it in a safe place, including the password used for encrypted the TPD.
   c) Keep the nCipher HSM and the admin/operator cards secured as well.
   d) Turn off AD RMS and (optionally) deprovision all servers used, given the backups and keys are safeguarded.

Once the need to perform a Cloud Exit is identified, execute the following steps:

1. Configure AIP to use Onboarding Controls to put all the organization users in “read only” status (e.g. use an empty group for onboarding).
2. Bring the original AD RMS cluster back up:
   a) Restore the AD RMS database backups into a SQL Server Instance of the same name originally used and install new AD RMS cluster nodes to the database.
   b) If you don’t succeed, or if the original AD RMS cluster you installed during the preparation phase doesn't meet your production scalability or supportability needs you may also install a new AD RMS cluster and import the TPD file exported before.
   c) Bring the nCipher HSM back to operation and connect it to the AD RMS cluster nodes. Depending on requirements, a more scalable nCipher HSM may be used (assuming compatibility with the nCipher Security World and the key file generated for BYOK).
3. Adjust the AD RMS template permissions, ensuring they match the corresponding label permissions on AIP. Additional steps are needed if rights in AIP labels were granted through modern groups (i.e. groups not synchronized from the local AD): In this case, corresponding on-premises groups will have to be provisioned with equivalent membership to their cloud equivalents. Afterwards, assign those groups to the templates. This will allow users to consume content that was protected with those labels/templates that were created during the initial provisioning.
4. Configure clients to use Licensing redirections pointing the AIP URL to the AD RMS cluster URL. You apply the same settings used for a migration from AD RMS to AIP, reversing the position of the redirection URLs in the registry. Please observe that as of May 2020, applications based on the MIP SDK do not support these registry overrides. This affects e.g. the PowerShell cmdlets installed with the AIP unified labeling client or the MIP plug-in for Acrobat Reader DC.
5. Use super user rights in AD RMS to consume content protected with labels/templates that were created after the provisioning process.

If any documents have already been protected with the MMK in use until the BYOK has been uploaded and made the active key, additional steps are needed. In this case, the procedure for an MMK cloud exit (see last section) needs to be implemented on top of the cloud exit discussed in this section. This ensures documents protected before the BYOK was uploaded can still be opened after a cloud exit.

Bulk Decryption as alternative to cloud exit
Some organizations choose to decrypt their content rather than implementing a cloud exit with an on-premises AD RMS cluster as described above. This option is only applicable with enough time for preparation and if all documents and mails can be unprotected in time.
To choose this approach, an organization would remove protection in bulk with the PowerShell tools on all documents and mails in PST stores they can locate. To allow users to unprotect emails and documents in other repositories (e.g. local drives), customers may also want to grant super user rights to all users.
Customers would use the PowerShell command Unprotect-RMSFile to unprotect folders, zip archives and PST files. The same PowerShell command can also be used with an AD RMS Server after a cloud exit - the super user feature is available on AD RMS as well.

Considerations for a Temporary Cloud Exit

Customers may face a temporary need to exit the service due to commercial, network or geopolitical issues. In this case a temporary cloud exit might be followed by a re-enablement of the cloud service and removal of all client-side redirections. Afterwards, users may continue to protect and consume content with AIP.
Additional steps are needed if a customer decides to return to AIP, but the cloud service has been completely deprovisioned after a cloud exit. In this case, the MMK or BYOK needs to be transferred to a new AIP tenant and clients need redirection to the new tenant.

Conclusion

We do not expect you to ever need to use the cloud exit with on-premises services. But with this blog post we intend to provide our customers with all the options - ensuring you are with us because you appreciate our service and not because you see no way out of our cloud-based offering given most of your important data is protected.