Стр. 1 из 3
How to prepare an Azure Information Protection “Cloud Exit” plan
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 labelling/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 lifecycle. 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 (onpremises) 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
Стр. 2 из 3
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.
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:
Стр. 3 из 3
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.