We all share documents and collaborate on them as groups – no big deal, but the challenge arises when those documents contain sensitive information. In the ideal world we want to restrict who can be in the collaborative group and enforce exactly what privileges they might all have, all in an automated, user friendly but tightly audited way. In reality it’s not that easy to build such a system but it is at least possible with an enterprise rights management (ERM) system. ERM has been available as an in-house enterprise solution for a number of years. It enables organisations to protect confidential documents by only allowing specified persons to read or edit them. For example, a car manufacturer can implement an ERM system that will allow designers to send blueprints to one another but will prevent those designers from forwarding the documents to anyone else or printing them off.

ERM systems are heavy users of cryptography; most rely on PKI and certificates as credentials to identify users, digital signatures to prove document integrity and encryption to keep documents confidential, only releasing decryption keys to approved users. And, not surprisingly, just like in a PKI, hardware security modules (HSM) can be used to safeguard and manage the master keys that underpin the entire security framework. No matter how secure they are traditional ERM systems have always had the drawback of complexity, particularly in scenarios where documents need to be sent outside of an organisation. Now, with the arrival of cloud computing, the proliferation of consumer devices (BYOD) and remote working in general the challenges get even harder, impacting usability and creating barriers to adoption.

Microsoft is addressing this issue with its new cloud-based rights management service (Azure RMS). Just as Microsoft is giving customers using its Office suite more choice with cloud-based Office 365, it is now offering an improved version of its existing RMS offering based on its cloud computing platform Microsoft Azure. With Azure RMS, user authentication, authorization and policy enforcement takes place in the cloud giving it almost universal accessibility, a huge advantage when it comes to sharing documents.

Of course the big concern with any cloud service is that you’re sharing the cloud with other customers – maybe your competitors – and you have to have some sort of trust relationship with your cloud provider. The good news is that your documents themselves aren’t stored in the RMS cloud, but you might still be worried about your master keys in the Microsoft cloud (in RMS they are actually called Tenant Keys). These keys are basically the root of trust in your entire system, if they are lost you might not recover your documents and if they are stolen, your secrets might not stay secret for much longer. Microsoft has addressed this potential concern by implementing a ‘Bring Your Own Key’ (BYOK) policy.

Your enterprise can generate its own ‘master’ or ‘tenant’ key () which you can hand over to the RMS service. Microsoft will protect this key in the cloud using HSMs and will be incapable of accessing it themselves. This actually creates a powerful ‘zero knowledge’ environment – the ability to use a key on your behalf but without having direct access to it. Customers can think of the HSM in the cloud as their ‘trusted agent’ protecting their keys from other tenants, from the cloud service provider and from other attackers and enabling user to retain critical control over their data.

Microsoft has chosen to exclusively deploy nShield HSMs to protect the applications and processes in Azure RMS. If you want to Bring Your Own Key to Azure RMS, your organisation can generate its own tenant key using an nShield HSM and simply upload it to the Azure RMS. What’s more, users will soon be able to go one step further and by using a secure validation mechanism users can prove for themselves that their key is inside an authentic HSM within the cloud giving them the reassurance that their keys are sufficiently isolated, and your documents safely protected.