Azure RMS Security
Evaluation Guide
Azure RMS Security Evaluation Guide
Abstract
Microsoft® is committed to ensuring that your data stays your data, without exception. In addition, sideby-side or with other protection technologies, Microsoft offers data protection with Azure Rights
Management (Azure RMS), so your organization can benefit from multiple layers of security and governance
technologies, operational practices, and compliance policies that combine to enforce data privacy and
integrity at a very granular level. This white paper concentrates on describing the security capabilities of
Azure RMS, including mechanisms for encryption, management, and access control that you can use to
manage and protect your sensitive data at any time, in any place, and on your favorite device.
Purpose
Use this document to assist your organization in reviewing Azure RMS. The information is believed to be
accurate but no warranties are implied. We do not assert the suitability of our product for your particular
uses. Should criteria be missing or issues found, please contact us using this email address. Updates will be
made as appropriate.
If you want to learn more about Azure RMS, please follow us on Twitter @TheRMSGuy, grow with others in
our customer facing user group, and influence our product investments via our Customer Advisory Board.
Audience
This document focuses on security claims and mechanisms in Azure Rights Management, and is intended
for Information Technology (IT) professionals and IT implementers who deal with information asset
management and protection on a daily basis, either as their main duties or as part of a broader IT
management role. This document will be most useful to individuals who are already familiar with Azure
RMS, and are looking to increase their knowledge of tools and technologies for encryption, access control,
and other aspects of security in Azure RMS and related services.
AskIPteam@microsoft.com
Version 1, Published May 2015
(c) 2015 Microsoft Corporation. All rights reserved. This document is provided "as-is." Information and views expressed in this
document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. Some
examples are for illustration only and are fictitious. No real association is intended or inferred.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and
use this document for your internal, reference purposes.
P A G E | 02
Azure RMS Security Evaluation Guide
Table of Contents
1
INTRODUCTION ......................................................................................................................................... 4
2
AZURE RMS OVERVIEW ............................................................................................................................ 5
3
AZURE RMS SECURITY .............................................................................................................................. 7
4
3.1
TOP FIVE SECURITY STATEMENTS ........................................................................................................................................ 7
3.2
OTHER IMPORTANT SECURITY STATEMENTS ...................................................................................................................... 9
3.3
SECURITY RECOMMENDATIONS ........................................................................................................................................ 11
AZURE RMS SECURITY TECHNICAL INSIGHTS ....................................................................................13
4.1
AZURE RMS INTEGRATION ARCHITECTURE AND COMPONENTS ................................................................................. 13
4.2
POLICIES AND SECURITY MANAGEMENT ......................................................................................................................... 15
4.3
SERVICE AUTHENTICATION, AUTHORIZATION, AND AUDIT ........................................................................................... 16
4.4
KEY MANAGEMENT ............................................................................................................................................................ 19
4.5
SERVICES LOGICAL SECURITY............................................................................................................................................. 26
4.6
NETWORK AND PHYSICAL SECURITY ................................................................................................................................ 27
APPENDIX: IMPORTANT ROADMAP ITEMS ................................................................................................28
APPENDIX: CONSULTANTS AND SOLUTION PROVIDERS .........................................................................30
REFERENCES ......................................................................................................................................................31
FURTHER READING ............................................................................................................................................................................ 31
P A G E | 03
Azure RMS Security Evaluation Guide
1 Introduction
Microsoft Azure Rights Management (RMS) provides greater protection than what is available for
documents in the typical IT environment – usually perimeter protection only – by protecting the files
themselves instead of protection the location there those files are stored. This protection results in the file
being encrypted and having usage rights enforced by the RMS-enlightened applications in a transparent
way. The business user does not have to take care of encryption key management, so he or she can focus
on the classification based on the business value of protected information. Usage rights vary from ‘View
only’ through enabling print of forward capabilities to full rights including the ability to unprotect content.
Why RMS? Why now? Every organization has sensitive information saved in different formats of
documents. It is our view that having a policy that is in effect across all storage types, even if only a broad
policy such as ‘All employees, All rights’, is a huge improvement over having no protection at all. Having
RMS policies in place results in your well-managed authentication system being used for authorization
instead of weaker per-file passwords, bulk storage-level encryption, and limited strength device PINs. For
most organizations, this is a massive leap forward.
Work with us. Now, we know the reviewers of this document will be looking for the system that addresses
all your information protection issues. We expect nothing less as it is your job as senior IT leaders and risk
managers to assess and choose the solution. And enabling our customers to managing and reducing risks
is one of the first priorities we have. We will help by being very open about our system design and intent.
However, we do ask that you use the opportunity of this review to measure our security claims against those
of your current practices. We assume that RMS (or any other solution or offering available on the market)
will fall short against over-engineered benchmark. But we also know that RMS will earn a far higher score
than the practices currently in place at more than 450 enterprises we have spoken with. The reality is that
very few organizations protect data-in-motion, yet the reality is that most permit a lot of sensitive data to
travel. And applied security features to protect data are losing their value if users could transfer the data to
an unmanaged environment.
We like to earn the right to secure your sensitive travelling data which is most often lacking adequate
protection. We want to help you quickly get your effective protected to a ‘7 out of 10’ and then continue to
work with you on improving from there to an even higher level of protection without scarifying usability.
Our team, in partnership with many of our solutions providers and consultants, are ready to tell you the
whole story about data protection at rest and in motion using RMS. Get involved with @TheRMSGuy, our
user group1, and our Customer Advisory Board2.
New to RMS? We encourage everyone to read the introductory What is Azure Rights Management?3 article.
Also, if you need help with some of the terms, phrases, and abbreviations, please reference Terminology for
Azure Rights Management4.
Let’s now review what we can do, together!
Customer-facing RMS group on Yammer - https://www.yammer.com/askipteam
RMS customer advisory board - http://eepurl.com/034NT
3
What is Azure Rights Management? TechNet article- https://aka.ms/rmsgetstarted
4
Terminology for Azure Rights Management – https://aka.ms/rmsterms
1
2
P A G E | 04
Azure RMS Security Evaluation Guide
2 Azure RMS Overview
Almost every organization is Internet-connected these days, with users bringing personal devices to work,
accessing company data on the road and home, and sharing sensitive information with important business
partners and co-workers. As part of their daily work, users share information by using email, file-sharing
sites, and cloud services. In these scenarios, traditional security controls (such as access control lists and file
server permissions), data loss prevention tools, and firewalls have limited effectiveness if you want to protect
your company data while still empowering your users to work efficiently.
In comparison, Azure RMS can protect your company’s sensitive information in all these scenarios. RMS
uses encryption, identity, and authorization policies to help secure your files and email, and it works across
multiple devices — phones, tablets, and PCs. Information can be protected both within your organization
and outside your organization because the protection remains with the data, even when it leaves your
organization’s boundaries. The persistent protection that Azure RMS provides not only helps to secure your
company data, but might also be legally mandated for compliance, legal e-discovery requirements, or
simply for good information sharing and management practices.
Nevertheless, if intended and applicable, authorized people and services (such as content scanning and
archival) can continue to read and inspect the data that Azure RMS protects, which is not easily
accomplished with other information protection solutions that use peer-to-peer encryption. This ability is
sometimes referred to as “reasoning over data” and is a crucial element in maintaining control of your
organization’s data with e-discovery.
The following picture shows how Azure RMS works as a Rights Management solution for Office 365 as well
as for on-premises servers and services. Note that Azure RMS supports the popular end user device
platforms like Windows, MacOS X, iOS, Android, and Windows Phone:
P A G E | 05
Azure RMS Security Evaluation Guide
Azure RMS is a comprehensive platform that includes ready-to-use applications for information workers, an
SDK for developers, and management tools for IT administrators. RMS enables your organization to:

Protect all file types and protect files anywhere5 - when a file is saved to a location, the protection
stays with the file, even if it is copied to storage that is not under the control of IT, such as a cloud
storage service, privately owned devices, or web email.

Audit and monitor usage of your protected files, even after these files leave your organization’s
boundaries.

Support for all commonly used devices6, not just Microsoft Windows computers.

Support for business-to-business collaboration - because Azure RMS is a cloud service, there is no
need to explicitly configure trusts with other organizations or individual users before you can share
protected content with them. If they already have an Office 365 or an Azure AD directory,
collaboration across organizations is automatically supported. If they do not, users can sign up for
the free RMS for individuals service.

Support for on-premises services, as well as Office 365 - in addition to working seamlessly with
Office 365, when you deploy the RMS connector on-premises you can also use Azure RMS with
Exchange Server, SharePoint Server, and Windows Server running File Classification Infrastructure
in your own datacenter.

Create simple and flexible policies to enforce protection - customized rights policy templates
provide a quick and easy solution for you to apply policies, and for users to apply the correct level
of protection for each document easily, while restricting access to people inside your organization.

Support broad set of applications7, mobile devices8 and custom applications - Azure RMS has tight
integration with Microsoft Office applications and services, and extends support for other
applications by using the RMS sharing application or Siemens JT RMS SDK. RMS SDK9 provides your
developers and software vendors with APIs to write custom applications that support Azure RMS.

Maintain control of data - you can choose to manage your own tenant key and use the “Bring Your
Own Key” (BYOK)10 solution while storing your tenant key in Hardware Security Modules (HSMs).
Azure RMS supports auditing and usage logging so you can analyze for business insights, monitor
for abuse, and (if you have an information leak) perform forensic analysis.

Migrate from AD RMS11 on-premises to Azure RMS while maintaining access to previously
protected documents.

Adhere to compliance and regulatory requirements – Azure RMS uses industry-standard
cryptography in FIPS 140-2 validated modules. Azure RMS services are certified for ISO/IEC
27001:2013 (including ISO/IEC 27018), has FedRAMP attestation, and is compliant with EU Model
Clause. For more information about these external certifications, see the Azure Trust Center12.
5
File types supported by RMS - https://technet.microsoft.com/en-us/library/jj585026.aspx#BKMK_HowRMSworks
Devices supported by RMS - https://technet.microsoft.com/en-us/library/dn655136.aspx#BKMK_SupportedDevice
7 Applications supported by RMS - https://technet.microsoft.com/en-us/library/dn655136.aspx#BKMK_SupportedApplications
8
Devices supported by RMS - https://technet.microsoft.com/en-us/library/dn655136.aspx#BKMK_ClientCapabilities
9
Microsoft RMS SDKs - https://msdn.microsoft.com/en-us/library/hh552972(v=vs.85).aspx
10
Choosing your tenant key topology - https://technet.microsoft.com/library/dn440580.aspx#BKMK_ChooseTenantKey
11
Migrating from AD RMS to Azure Rights Management - https://technet.microsoft.com/en-us/library/dn858447.aspx
12
Microsoft Azure Trust Center - https://azure.microsoft.com/support/trust-center/compliance/
6
P A G E | 06
Azure RMS Security Evaluation Guide
3 Azure RMS Security
These security-related claims about Azure RMS answer the most common questions posed by Chief
Information Security Officers (CISOs), their teams, or risk departments.
3.1 Top Five Security Statements
This section describes top five security statements of Azure RMS.
1.
Your sensitive data is not transmitted to Azure RMS.
Data that your company wants to protect with rights management carries some sensitivity. Some IT
professionals and managers are worried about using a cloud service to protect it. The good news is that
Azure RMS will never see or have access to the content of the files to be protected. Documents, emails and
other protected files are not sent to the Azure service when being protected or opened by the recipient.
Regardless of where the files are stored – on-premises or in a cloud provider’s storage or application –
Azure RMS does not access the data. The RMS service only handles the encryption mechanism and key
management, not the actual data.
2.
If your data is hosted in the cloud, Microsoft takes a strong stance on data disclosure.
If a government approaches us with the request to get access to customer data, we redirect the inquiry to
you, the customer, whenever possible. We continue to challenge in court any invalid legal demand that
prohibits disclosure of a government request for customer data. See Azure Trust Center/Privacy, Office 365
Privacy in the Public Cloud: The Office 365 Approach document, and Brad Smith’s blog posts (Microsoft’s
General Counsel) for more details. The following is an excerpt from our commercial services contract. Being
an excerpt, this is not legally binding text so please refer to your service contract(s).
P A G E | 07
Azure RMS Security Evaluation Guide
“Microsoft will not disclose Customer Data to law enforcement unless required by law. Should law
enforcement contact Microsoft with a demand for Customer Data, Microsoft will attempt to redirect the
law enforcement agency to request that data directly from Customer. If compelled to disclose Customer
Data to law enforcement, then Microsoft will promptly notify Customer and provide a copy of the demand
unless legally prohibited from doing so.”
“Upon receipt of any other third party request for Customer Data (such as requests from Customer’s end
users), Microsoft will promptly notify Customer unless prohibited by law. If Microsoft is not required by law
to disclose the Customer Data, Microsoft will reject the request. If the request is valid and Microsoft could
be compelled to disclose the requested information, Microsoft will attempt to redirect the third party to
request the Customer Data from Customer.”
“Except as Customer directs, Microsoft will not provide any third party: (1) direct, indirect, blanket or
unfettered access to Customer Data; (2) the platform encryption keys used to secure Customer Data or the
ability to break such encryption; or (3) any kind of access to Customer Data if Microsoft is aware that such
data is used for purposes other than those stated in the request.”
This last paragraph, section (2) includes Azure RMS because we make use of ‘platform encryption keys’.
Learn more at out Transparency site13.
3. Cloud service security is a partnership between Microsoft and our customers.
Azure RMS provides security controls and capabilities for protecting your data and securing collaboration
with your partners. However, you need to consider that Microsoft cannot estimate if a valid user access to
the data might be a breach in your infrastructure. RMS relies on authentication to authorize access to the
protected documents. You are responsible for the validity security of your on-premises resources such as,
for example, administrative accounts you use to manage Azure RMS and RMS-integrated workloads.
Microsoft operates and secures the infrastructure, host operating system, and application layers for Azure
RMS. Data is secured in transit between datacenters and in motion between Microsoft and the customers.
You control and secure your identities, including configuring the set of application controls available in
Azure AD.
4. Azure RMS only authorizes data access – without knowing user passwords.
During RMS operation, only the RMS certificate/licenses and policy information are sent to Azure RMS.
Most business users authenticate to a federation service provided by their organization – afterwards they
present only a token to Azure RMS. This way, Microsoft doesn’t need to know user passwords and yet Azure
RMS can still perform authorization for authenticated users. You retain control over your organization’s
authentication policy.
For each organization that subscribes to Azure RMS, the service holds an important associated key called
the tenant key. The Azure RMS service utilizes this key at the root of trust of its trust model. Azure RMS
offers multiple levels of control over this high-value key so that you can balance the level of control you
want versus cost and simplicity. By default, the Azure RMS service generates your tenant key in software
and manages the key lifecycle. With this simple option the key is managed by Microsoft. You have the
option to protect this RMS root key with a Hardware Security Module (HSM), a physical computing device
that safeguards private keys and provides cryptographic processing. Azure RMS enables the use of HSMs
13
http://www.microsoft.com/about/corporatecitizenship/en-us/reporting/transparency/
P A G E | 08
Azure RMS Security Evaluation Guide
via its BYOK (bring your own key) option. The European company, Thales e-Security, supplies the FIPS 1402 validated HSMs that are used for Azure RMS. And you can review all operations on the key by examining
the audit logs produced by Azure RMS.
5.
Azure RMS is compliant with your regulatory requirements.
Many international, industry, and regional certification bodies independently certify that Microsoft cloud
services and platforms meet rigorous security standards and are compliant to the set of requirements. By
providing customers with compliant, trustworthy, and independently verified cloud services, Microsoft
makes it easier for you to achieve compliance for your infrastructure and applications. Azure RMS and the
Azure platform that it runs on are compliant with stringent standards and have achieved multiple
certifications:
a.
ISO/IEC 27001:2013 certification (including ISO/IEC 27018),
b. SOC 2 SSAE 16/ISAE 3402 attestations,
c.
HIPAA BAA,
d. FedRAMP certification as part of Azure Active Directory in Office 365 certification, issued FedRAMP
agency Authority to Operate (ATO) by the Department of Health and Human Services Office of the
Inspector General (HHS OIG),
e.
PCI DSS Level 1.
The cryptographic Hardware Security Modules (HSMs) used in Azure RMS are FIPS 140-2 Level 2 validated.
Microsoft also offers customers E.U. Standard Contractual Clauses that provide additional contractual
guarantees around transfers of personal data for Azure RMS. The EU Model Clauses allow customers to
comply with the EU’s Data Protection Directive relating to cross-border transfers of personal data. The EU’s
data protection laws restrict exporting personal data from the European Economic Area and the Model
Clauses, standard contractual clauses approved by the European Commission, are a preferred way to
legitimize the transfer of personal data outside the European Economic Area. The Article 29 Working Party
(which is the group made up of the 28 data protection regulators from each of the EU member states)
approved Microsoft’s implementation of the EU Model Clauses as being compliant with the EU’s rigorous
legal requirements regarding the international transfer of customer data, requirements beyond the U.S.E.U. Safe Harbor self-certification. More information can be found in this joint letter.
For more information about these external certifications, see Azure Trust Center/Compliance.
3.2 Other Important Security Statements
This section describes other important Azure RMS security statements.
1.
RMS offers the strongest possible protection before a user has authenticated. The most common
and well-understood attack vector is via an authorized user’s identity (email address) and their
password. Azure RMS uses industry-standard cryptographic algorithms (RSA 2048, AES, and SHA 256),
so we believe that a brute force attack on the symmetric key for content encryption and RMS
asymmetric keys (that are tightly connected with authorized user identity) is highly improbable.
Other frequently asked attack examples are:
P A G E | 09
Azure RMS Security Evaluation Guide
a.
Copying protected data and the related licenses and certificates by an authorized user to
another machine is not possible14.
b. Setting the time back does not work with RMS-enlightened applications such as Office 2010
and Office 2013.
2.
RMS helps to protect against misuse of content by authenticated users. While RMS protection is
very robust against an attacker trying to break the encryption, it is more challenging to prevent misuse
of this content by an authenticated user. Even sophisticated technology cannot prevent the user from
taking a screenshot with his smart phone camera or from retyping text. Though you may choose to
implement a custom water-marking technologies in conjunction with RMS to make it harder.
Similarly, applications that are capable of opening protected content are ultimately responsible of
honoring the usage rights of a particular user.
3.
RMS increases user awareness for the expectations of the (sensitive) document. When opening a
protected document, the user interface of an application changes, which makes the user aware of the
sensitivity of the document. RMS-enlightened applications apply visual additions in the user interface
that clearly identify the existence of sensitive and RMS-protected information. This encourages
awareness and best practices handling of sensitive information for compliance and helps to reduce the
likelihood of inadvertent information leakage. Although it is a subjective statement, we feel strongly
that this ‘education’ changes user habits.
RMS has two different levels of protection:

Native protection for email, Microsoft Office (Word, Excel, PowerPoint) files, text, image, .pdf files,
and other application file types that support RMS, where RMS provides a strong level of protection
that includes both encryption and enforcement of rights (permissions) in the application.

Generic protection that includes both file encapsulation using the .pfile file type and authentication
to verify if a user is authorized to open the file. With generic protection, a document is encrypted,
but no policy is enforced in the application. In other words, a user with access to the document
cannot be prevented from printing or forwarding the document. However, even in this case, the
user has to give consent before gaining access to the document. This way the user learns what use
policy is expected – and also that use of this document is audited by the sender and their
organization which further deters the user from unauthorized sharing of information.
4.
RMS-enlightened applications need to contact the organization's RMS service that protected the
content. Every time a RMS-enlightened application renders data/information for protection or
consumption for an internal or external user, the Azure RMS service of your organization needs to be
available. For example, if your organization deployed Azure RMS in European geography then your
partners in other geographies will reach this service to open protected data. After this is done for
consumption, a license with a configurable validity period ensures offline accessibility for RMSprotected content. This applies to your users and users in other organizations, regardless of where the
document is being opened.
14
Based on a binding between encryption and hardware, the RMS user has to re-authenticate to Azure RMS each
time the content is accessed from new hardware
P A G E | 010
Azure RMS Security Evaluation Guide
5.
Keys created for BYOK are limited to one specific region. There are four geographies for Azure RMS
at the moment: Europe, US, Asia Pacific, and South America. When your organization decides to use the
BYOK feature for Azure RMS, your organization needs to define a specific geography when creating the
key on-premises. A key created for one geography (for example, in Europe) has technical controls that
prevent it from being imported into the RMS infrastructure of another geographic region (for example,
into the US).
6.
Azure RMS supports monitoring of the lifecycle of RMS-protected data. Based on the Azure RMS
logging information, Azure RMS optionally offers a premium service called Document Tracking.
Document tracking enables you to create reports and drive insights such as: who is accessing your
sensitive data, which locations are your recipients accessing data from, and report on which users have
read a given document or which users tried to open protected data unsuccessfully.
You can use this information to help identify misusage of RMS-protected data. For example, you might
discover if there is a sudden increase of people reading RMS-protected data outside standard working
hours, which could, for example, indicate that a malicious user is collecting information to sell to
competitors. Or, if the same user apparently accesses data from two different IP addresses within a
short time frame, which could indicate that a user account has been compromised.
And if you feel that the document is misused, you may go to the Document Tracking site and revoke
access to the document.
3.3 Security Recommendations
As mentioned above security of information protection solution is a partnership between you and
Microsoft. This section describes some security recommendations.
1.
The Azure RMS service relies on your identity system to authenticate users. RMS requests the
user’s security token via your organization’s identity system. This will result in a transparent
authentication using single-sign-on (SSO) or a prompt for login when no SSO is in place. For larger
organizations, this step is commonly performed by using your company’s on-premises federation
service (for example, AD FS). Given this, our RMS service, the SDK clients, and RMS enlightenedapplications do not see your user’s password; the password is entered into your own, or chosen, identity
provider (for example, Azure AD).
With Azure RMS, your organization is in control of authentication. Most organizations choose to
integrate their own authentication service with Azure RMS. This way, you define the rules regarding
password length, complexity, lifespan, and whether multifactor authentication is required. But if you
choose to use Microsoft-managed accounts in Office365/Azure AD, you can rest assured that your data
is isolated from other organizations. See Customer Content Isolation in Microsoft Office 365.
2. Group membership is defined by the customer organization. Your organization may allow individual
external users to access protected content. For easier management, you can put these external users
into a group in your organization’s Azure AD group (that can also contain on-premises security groups),
and grant this group access to protected content (that will expire after specified time period). However,
you cannot use groups from another organization to grant access to protected content.
3.
With the Bring Your Own Key option, you have responsibility for the key. When you choose the
Bring Your Own Key (BYOK) option, you effectively provide Microsoft only a limited power of disposition
P A G E | 011
Azure RMS Security Evaluation Guide
over the root key used by Azure RMS. In this case, Microsoft is technically blocked from backing up and
restoring the key. Consequently, the customer is strongly advised to back up the root key to prevent a
situation where protected data can’t be accessed any more due to a missing key. In other words, BYOK
puts you in control of you own key, but this goes along with responsibility over the key. It is therefore
advised that CSO, CIO, and the risk management teams should oversee the suitable steps in backing
up the root tenant key.
Azure RMS supports your company’s key rollover processes and allows maintaining several generations
of keys. Therefore new content can be protected with a new key while maintaining access to previously
protected content using older (archived) RMS keys.
4.
RMS can be used with your data loss prevention solution. Your organization can use data loss
prevention (DLP) solutions to prevent sensitive information from leaving your environment and use
defined processes to track and remove data if there is a leak. RMS is integrated with DLP in Exchange,
SharePoint Server, OneDrive for Business, and multiple solutions from our partners.
5.
Your organization designates the storage where Azure RMS will write its logs. Your organization
owns the storage used by Azure RMS to store its log files, therefore you're in charge of the data
retention policies. By design, Azure RMS doesn't need to read the log data again; your organization
may delete the data immediately after download. You are in full control of this storage, including
management.
P A G E | 012
Azure RMS Security Evaluation Guide
4 Azure RMS Security Technical Insights
4.1 Azure RMS Integration Architecture and Components
The following picture shows how Azure RMS works as a Rights Management solution in Azure as well as for
on-premises servers and services. The solution supports the popular end user devices that run Windows,
Mac OS, iOS, Android, and Windows Phone:
Contoso Intranet
Microsoft cloud
Federation Server
BYOK -Hardware
Security Module
Contoso.com
Directory
Synchronization
Azure RMS
File Server
Tenant
Administrator
Exchange Server
RMS Connector
SharePoint Server
Internal Client
Mobile Devices &
External Clients
The following components are typically deployed in organizations that choose to control their
authentication (that is, use federation) and have on-premises workloads integrated with RMS.
4.1.1
RMS Connector
The Microsoft Rights Management Services (RMS) connector is an application that can be used to quickly
enable existing on-premises workloads such as Microsoft Exchange, Microsoft SharePoint, or Microsoft based File Servers to use their Information Rights Management functionality with the cloud-based Microsoft
Rights Management Services (Azure RMS).
Learn more about the RMS connector and supported Exchange/SharePoint versions at
https://technet.microsoft.com/en-us/library/dn375964.aspx.
P A G E | 013
Azure RMS Security Evaluation Guide
4.1.2
Federation Service (optional)
To provide a single sign on to the Azure RMS service for users who are already logged on to the on-premises
AD, a federation service needs to be in place. Azure RMS uses this federation service to authenticate users.
Microsoft offers Active Directory Federation Service (AD FS) as a solution for federating the on-premises
Active Directory with the Azure Active Directory (Azure AD). You can also use your own federation service
that works with Office 365 identity (for example, Ping Federate or CA SiteMinder).
Because federation provides single sign on for users from within the intranet, Federation Service Publishing
is required to publish that service to make it also available for users from external public networks. Learn
more about AD FS.
4.1.3
Directory Synchronization Service
Azure RMS requires certain information from the customer’s users and groups to be synchronized to
Azure Active Directory. This lets Azure RMS access this user and group information to grant access to
protected content (read more about required attributes in 4.3.6). To help make this synchronization easier,
Microsoft offers the free of charge tool, Azure AD Synchronization Services (AAD Sync) or the new Azure
AD Connect that can simplify configuring federation and directory synchronization services.
4.1.4
Exchange Server
Information Rights Management (IRM)15 in Exchange helps you to protect against leakage of sensitive
information by providing persistent online and offline protection of email messages and attachments.
Exchange Server in your on-premises organization, and Exchange Online, in Office 365 for Enterprises,
support IRM. However, you must configure IRM in the Exchange before users can use it.
IRM in Exchange can use Azure RMS. This allows users to create rights-protected content, such as email
messages and attachments, and then control how that content is used, and to whom it’s distributed. Users
can select templates that determine how content can be used. For example, a user may specify that an email
message can't be forwarded to other recipients or that information in the message can't be copied. Learn
more about IRM in Exchange Server.
4.1.5
SharePoint Server
With Office SharePoint Server, IRM protection is available for files that are located in document libraries and
stored as attachments to list items. SharePoint site administrators can protect downloads from a document
library or document list with IRM. When a user attempts to download a file from the library, SharePoint
Server verifies that the user has permissions to the given file and issues a use license that allows access to
the file with the appropriate permissions. SharePoint Server then downloads the file to the user's computer
in an encrypted, rights-managed file format. Learn more about IRM in SharePoint.
4.1.6
File Classification Infrastructure and Work Folders
File Classification Infrastructure (FCI) provides a built-in solution for file classification allowing administrators
to automate manual processes with predefined policies based on the data’s business value. This is a
15
IRM is the name of the Office feature that uses RMS technology in Microsoft Office services and applications
P A G E | 014
Azure RMS Security Evaluation Guide
capability in Windows Server-based file servers that enables the server to scan local files and assess their
content to determine if they contain sensitive data, and if they do - classify them accordingly by tagging
them with classification properties. After files are classified, FCI can also automatically take action on these
files, such as applying RMS protection to the files to prevent them from leaking beyond their intended
audience. All this happens automatically without the users having to take action. The classification policies
are fully configurable and highly extensible so you can create policies that match your organization’s needs.
In addition to preventing potential data leakage from unauthorized and authorized users. Learn more about
FCI and Automatic RMS Protection of non-MS Office files using FCI and the Rights Management Cmdlets.
With Work Folders users can store and access work files on personal computers and devices, often referred
to as bring-your-own device (BYOD), in addition to corporate PCs. You can maintain control over corporate
data by storing the files on centrally managed file servers, and optionally specifying user device policies
such as encryption with RMS. Learn more about Work Folders in Windows Server.
4.2 Policies and Security Management
4.2.1
Azure RMS does not require content – documents or email – be hosted in the cloud in order
to use it.
The RMS connector is an application that can be used to quickly enable existing on-premises servers such
as Microsoft Exchange, Microsoft SharePoint or File Classification Infrastructure (FCI) to use their
Information Rights Management functionality with the cloud-based Azure RMS services. The RMS connector
is a small-footprint service that you install on-premises, on servers that run Windows Server 2012 R2,
Windows Server 2012, or Windows Server 2008 R2. After you install and configure the connector, it acts as
a communications interface (a relay) between the on-premises servers and the cloud service.
To learn more about how Azure RMS does this, see Deploying the Azure Rights Management Connector.
4.2.2
Protection against misuse of content by authenticated users
If an authenticated user is entitled to consume a particular document or email, an RMS enlightened
application is capable of decrypting this protected content by contacting Azure RMS. The RMS SDK provides
this functionality; it is used by applications such as Office, the RMS sharing application, Exchange,
SharePoint, FoxIt Reader, Siemens JT2Go, and many more. Enforcing the policies lies entirely in the
responsibility of the individual application; for instance, the application has to ensure that a user without
print rights effectively cannot print the document. A legal agreement between Microsoft and the application
vendor stipulates this responsibility in the Rights Management License Agreement.
This post-authorization policy enforcement can only be a best effort attempt to protect the document – for
example, the user can’t be prevented from taking a picture of the screen showing a protected document
with his or her smart phone.
4.2.3
Secure operations and monitoring
Microsoft implements Operational Security for Online Services (OSA) controls to secure datacenter
infrastructure and networking security behind Azure RMS and the Azure platform. OSA is a framework that
P A G E | 015
Azure RMS Security Evaluation Guide
focuses on infrastructure issues to help ensure secure operations throughout the lifecycle of cloud-based
services.
In addition to threat modeling, code reviews, and security testing (breach prevention), Microsoft takes an
“assume breach” approach to protecting services and data: simulate real-world breaches, live site
penetration testing, centralized security logging and monitoring, and practice security incident response.
4.2.4
Document tracking and revocation
Tracking and Revocation features are currently available in preview to customers in North America.
The RMS-enlightened apps can now take advantage of the document tracking and revocation features by
setting tracking metadata at the time of document protection. This will ensure that document owners can
track activities on their documents by using the document tracking site and if needed, can also revoke
access to the documents.
Note that the use license validity time set by the RMS administrator determines how long a user can
continue to use a revoked document. This is described in detail here.
4.3 Service Authentication, Authorization, and Audit
4.3.1
The Azure RMS service is not responsible for authenticating users.
You control and secure your identities, including configuring the set of application controls available in
Azure RMS and Azure AD. RMS requests the user’s security token via your organization’s identity system.
This will result in a transparent authentication leveraging single-sign-on (SSO) or a prompt for sign in when
no SSO was possible. For larger organizations, this step is commonly performed by leveraging your
company’s on-premises federation service (AD FS or other supported third party identity provider). Given
this, our RMS service and RMS client components do not see your user’s password; the password is entered
into your own, or chosen, identity provider (for example, Azure AD).
This means that your IT administrators have control over the identity management services, making them a
dependency for security of your Azure RMS tenant. The privileged accounts, credentials, and workstations
where the accounts are used must be protected and monitored as identity services you operate provide the
foundation of security systems. Most enterprise organizations use existing identities for cloud services and
these identities need to be secured at or above the level of cloud services to operate and manage Azure
RMS securely. Modern RMS applications rely on Azure AD authentication libraries (ADAL) for implementing
client authentication. Read more about Azure AD solutions for identity and access management.
P A G E | 016
Azure RMS Security Evaluation Guide
You can use the Azure AD Connect Health service to monitor and gain insights into your on-premises
identity infrastructure. This service offers you the ability to view alerts, performance, usage patterns,
configuration settings, and enables you to maintain a reliable connection to Microsoft cloud services.
4.3.2
With Azure RMS, the organization can stay fully in charge of authentication.
With federated authentication to Azure AD, the authentication is fully handled by an your on-premises
service. This means that you are in charge of the federation service (for example, AD FS) hosted locally;
furthermore you define the authentication rules such as password length, how long passwords are valid,
whether they need to be complex. Similarly, demanding a multi-factor authentication is entirely at the
discretion of the organization. When you use this configuration, Azure RMS honors the signed token that
is issued by the on-premises federation service and forwarded to Azure RMS, and it accepts the client
identity defined in the token.
4.3.3
Azure RMS only authorizes data access – without having the data nor knowing user
passwords.
No data related to content is sent to Azure RMS when protecting documents or emails. When a user tries
to open protected content, a small “publishing license” (with a size of a few KB) is extracted from the
protected document/email by the RMS enlightened application. This license contains only the enveloped
symmetric key the content was encrypted with, and some policy information. The client hands this
publishing license to the Azure RMS service – and if the user has permission to open this content, Azure
RMS returns a similarly sized “use license” back to the client. This license allows the RMS client to decrypt
the protected content. During the whole process, data itself is never divulged to the Azure RMS service.
In general, enterprise customers with on premises Active Directory use federated authentication to Azure
AD. This way, users are authenticated first against a federation service (for example, AD FS) that is fully in
control of the customer. The AD FS server issues a signed token which the user forwards to Azure AD, which
in turn grants access to Azure RMS.
4.3.4
Group membership is defined by the customer organization
Azure RMS allows protecting content for internal users, located in the organization’s Active Directory, as
well as for external users, located in the Active Directory of a different organization, by using an implicit
Azure Active Directory trust. For example, Contoso users may protect some content for an external auditor
Jane Doe by referencing her by email address jane.doe@fabrikam.com.
Contoso may create a group "ExternalAuditors" in their AD, which would include external users such as Jane
Doe. Afterwards, Contoso may allow access to protected content for the group "ExternalAuditors", thereby
automatically allowing access to protected content for Jane Doe. However, it's not possible today to trust
groups contained in the AD of another organization. For example, if Fabrikam has a group "Auditors",
Contoso may not give this group permission to protected content.
4.3.5
RMS-enlightened applications need to contact the organization's RMS service that
protected the content
When users of your organization protect documents or emails, the content is encrypted with the key of the
Azure RMS service belonging to your organization. Consequently, applications will need to contact your
P A G E | 017
Azure RMS Security Evaluation Guide
Azure RMS service to consume these protected documents and emails. This applies also if the documents
have been edited by external users, or if external users have replied to emails. In other words, a protected
document that your organization owns may travel to external users residing in other geographic locations,
but the Azure RMS service that your organization uses will always need to be contacted for opening the
document. Therefore the logs of your Azure RMS service will contain successful and failed attempts to open
this document by internal and external users. Bear in mind that external users will likely authenticate against
the federation service (AD FS or other supported third party identity provider) of their organization using
federation as explained previously; but your Azure RMS service will duly log the access to protected content.
4.3.6
RMS needs only a limited set of synchronized attributes from Active Directory
With the updated Azure AD Sync or Azure AD Connect, you can limit the groups and users you want to
synchronize to Azure AD by using organizational unit (OU)-based filtering or attribute-based filtering, which
allows you to specify the exact set of users in your on-premises directory to synchronize. You can also
choose the attributes you want to synchronize, for example only the following attributes are required for
Azure RMS to operate:
Attribute Name
User
accountEnabled
X
Contact
cn
displayName
X
X
X
mail
member
objectSID
X
X
X
X
X
proxyAddresses
X
X
X
pwdLastSet
X
X
securityEnabled
X
usageLocation
X
userPrincipalName
X
more
about
X
the
X
X
X
Azure
Comment
Defines if an account is enabled, derived from
userAccountControl
Common name or alias
A string that represents the user’s name and often shown as
the friendly name (first name last name)
Full email address, primary “identity” for RMS
Used to expand groups membership
Mechanical property that serves as an AD user identifier to
maintain sync between Azure AD and AD
Contains all secondary email addresses for the user and serves
as a secondary “identity” for RMS – e.g. users/groups with
multiple emails
Mechanical property required by Azure AD, used to identify
when to invalidate already issued tokens and ask the client to
re-validate
Derived from groupType, RMS uses security mail-enabled
groups
Mechanical property, serves as an immutable identifier to
maintain relationship between AD and Azure AD
Mechanical property that sets the user’s country and used for
license assignment, derived from msExchUsageLocation in AD
The login ID for the user. Most often the same as [mail] value,
but in some rare cases RMS uses upn as the last option to
resolve the user’s identity
X
sourceAnchor
Read
Group
AD
sync
tool
from
https://msdn.microsoft.com/en-
us/library/azure/dn790204.aspx.
4.3.7
Your organization designates the storage where Azure RMS will write its logs.
Azure RMS writes its log entries to a storage account of a Microsoft Azure subscription. The RMS service is
designed to write log entries to this storage; it does not rely on the ability to read back this data. Therefore
the contents may be deleted immediately after download. Learn more here: Logging and Analyzing Azure
P A G E | 018
Azure RMS Security Evaluation Guide
Rights Management Usage. You can keep the logs in the cloud and let services like PowerBI or Splunk
reason over them for value-added reporting. Some (more advanced) organizations may want to merge their
Azure RMS logs with the on premises identity infrastructure (for example, AD/ADFS) log in a security
information and event management (SIEM) console such as ArcSight in order to gain additional insights.
4.3.8
Audit access to your Azure RMS tenant
You can use access and usage reports in Azure AD to gain visibility into the integrity and security of your
organization’s Azure RMS tenant. With this information, a tenant administrator can better determine where
possible security risks may lie so that the organization can adequately plan to mitigate those risks.
When you use the Azure Management Portal, reports are categorized in the following ways:





Anomaly reports - Contain sign in events that Azure RMS/Microsoft found to be anomalous. Our
goal is to make you aware of such activity and enable you to be able to make a determination about
whether an event is suspicious.
Integrated Application report – Provides insights into how cloud applications are being used in your
organization. AD offers integration with thousands of cloud applications.
Error reports – Indicate errors that may occur when provisioning accounts to external applications.
User-specific reports – Display device/sign in activity data for a specific user.
Activity logs - Contain a record of all audited events within the last 24 hours, last 7 days, or last 30
days, as well as group activity changes, and password reset and registration activity.
For more information, see View your access and usage reports and Use Azure Active Directory sign-in and
audit reports.
You may also want to enable auditing for your on premises federation service (for example, the AD FS
server). This might be beneficial for situations where you place a high value on the security of your identity
deployment and prefer to monitor it closely for suspicious or unintended activity. Balance the value of
auditing with the increased time that you spend reviewing or managing the additional event log detail that
auditing can generate in your deployment. See Configure auditing for AD FS or use the Azure AD Connect
Health service for monitoring.
4.4 Key Management
4.4.1
RMS certificates and licenses
For each organization that subscribes to Azure RMS, the service holds a tenant key. The Azure RMS service
utilizes this key at the root of trust of its trust model: all service artifacts in the organization (per-user keys,
per-document encryption keys) are cryptographically chained to that tenant key. In RMS, every entity that
interacts with the services is represented by a certificate.
Each Azure RMS tenant is represented by one active certificate, the Server Licensor Certificate, or SLC, which
is a self-signed certificate. The private key corresponding to this certificate is used by the service to sign
many other identity certificates used in the service, and it is also used by the clients to encrypt other
materials for the server to decrypt, as will be discussed later.
Windows desktop client machines have a Security Processor Certificate (SPC), which identifies each machine
and allows the machine to encrypt other elements stored locally in the computer. Users are identified by
P A G E | 019
Azure RMS Security Evaluation Guide
two certificates. One which is utilized to identify users against the RMS service, and another one which is
used to identify a user that has protected a piece of content.
The first one is called the Rights Account Certificate (RAC). When a user first authenticates against the
certification URL of an Azure RMS service, the user is issued a RAC, and then it uses this certificate for any
future identification needs to the service. The RAC is also used by the Azure RMS tenant to encrypt licenses
being sent to the user, and by the client to sign the other user certificate mentioned above, the CLC or
Client Licensor Certificate. This one is obtained from the RMS licensing pipeline during client activation, and
it is used to sign the Publishing Licenses embedded into any encrypted document.
Which brings us to the Publishing Licenses: these are encrypted and signed objects that are used to express
rights over a document. A Publishing License is basically a list of rights, like an Access Control List, that
expresses a list of subjects (normally identified by their email addresses) and their rights (View, Edit, Print,
Copy, etc.). The PL is stamped into a protected document and it is encrypted with the Server Licensor
Certificate’s public key (so only the server can decrypt it) and signed with the user’s Client Licensor
Certificate (so everyone can view who wrote it).
Finally, there’s one more commonly used license: the Use License. This is a signed object expressing the
rights one user (the one requesting a license) has over one document. It also contains the encrypted
symmetric key used to encrypt the content of the document, but more on this later.
The following picture describes certificates and licenses used by RMS-enabled rich client applications and
automatically managed by RMS:
RMS uses XrML certificates internally, and not X.509v3 certificates (these are used only to protect TLS
communications with service components). Note that you, as the user of RMS or developer of RMSenlightened application, do not need to request or manage these certificates and licenses as this is
automatically done by the RMS client installed on your machine or device.
P A G E | 020
Azure RMS Security Evaluation Guide
On Windows desktop RAC, CLC, and EUL keys are additionally protected with DPAPI.
On mobile devices that use REST APIs and OAuth2 authentication protocol, the principal cryptographic
components are similar, but RAC and CLC are not used and EUL keys are saved on the device keychain. The
detailed explanation of mobile data flows is provided in Leverage the Mobile Device Extension for AD RMS
on your premises white paper.
4.4.2
RMS cryptographic algorithms and key lengths
RMS-enlightened clients uses AES symmetric keys in CBC mode with PKCS#7 padding to encrypt the
content and uses RSA asymmetric cryptography to encrypt the symmetric content key. This is how RMS
works:
1.
Azure RMS protects files (or email, blog data, etc.) by encrypting the payload with an AES symmetric
key. This symmetric key is different for each protected file. The symmetric key is placed into a newly
formed encrypted header in the file, which is signed with user’s RSA key. This ‘Rights Policy’ contains
use entitlements (email addresses for user), their rights (e.g. View only), other restrictions such as
document expiration date, and the document-specific AES symmetric key.
2.
The RMS-enlightened clients only send the relevant ‘rights policy’ extracted from the document to the
RMS service; the core document content never leaves the client. This is an important fact for securityconscious administrators. Even the most cloud-reluctant organizations can be assured that our RMS
cloud service (or its operators) do not see their sensitive data.
The current file protection and key protection methods are described in Cryptographic controls used by
Azure RMS: Algorithms and key lengths:

Azure RMS uses a 2048 bit RSA asymmetric key with SHA-256 hash algorithm for integrity.

The symmetric key for Office documents and email is AES 128. AES 256 is being evaluated against the
need to maintain compatibility with currently supported Office versions (2010, 2013).

The symmetric key for PFILEs and derivatives, such a PPDF, PTXT, PJPG, etc. is AES 128 or AES 256. The
support for AES 256 is recently released and transition to it will be automatic and transparent.
4.4.3
Larger organization can protect their RMS root key in a Hardware Security Module
Azure RMS offers multiple levels of control over this high-value key so that you can balance the level of
control you want with cost and simplicity. By default, the Azure RMS service generates your tenant key in
software and manages the key lifecycle. With this simple option the key is managed by Microsoft. As an
alternative, Azure RMS offers the Bring Your Own Key (BYOK) capability that let you provide your own key,
generated and stored on your HSM on-premises and used in Microsoft HSMs in the cloud. Organizations
often need to use a key that is generated by, archived, and under the control of your security officers. This
requirement may be due to compliance reasons, sometimes because the organization is migrating from
their on-premises AD RMS infrastructure, or as best practices in key custody. BYOK is designed so that
Microsoft operators do not see or leak the key during the import as well as during the running steady state.
Optionally, you can sign up to the near-realtime logging service and thus receive usage logs from Azure
RMS. You can use this in addition to BYOK to see exactly how and when your key is being used by the Azure
RMS service.
The BYOK lifecycle:
P A G E | 021
Azure RMS Security Evaluation Guide
a.
Thales e-Security, a European company, is the supplier of hardware security modules in Azure RMS.
The Thales HSMs used by Azure RMS are FIPS 140-2 Level 2 validated. Learn more from Thales
themselves from https://www.thales-esecurity.com/msrms/cloud.
b. Azure RMS’ BYOK feature is designed so that Microsoft does not extract your keys.
c.
The BYOK feature is designed so that keys transferred from your HSM to HSM in Azure RMS stay
within the HSM security boundary.
d. The Azure RMS service is granted the right to use your root key to perform the cryptographic
operations necessary to deliver the RMS service. Azure RMS calls the HSMs for all root key
cryptographic and critical signing tasks only in the context of an authenticated request initiated by
customer and logs all operations with the key.
Learn more about BYOK from the Planning and Implementing Your Azure Rights Management Tenant Key
article, which guides you in choosing your Azure RMS tenant key topology between managed by Microsoft
(default) and managed by you (BYOK).
The Hardware Key management in the RMS Cloud white paper by Thales e-Security provides detailed
explanation of HSM deployment strategy, securing RMS keys in the cloud with help of Thales HSMs, and
providing key encryption key authenticity.
4.4.4
With the Bring Your Own Key option, you have responsibility over the key
With the option “Bring Your Own Key” (BYOK), you generate the key on your Thales HSM – an encrypted
copy of the key with scoped down ACL will be used in FIPS 140-2 validated Thales HSMs hosted in a
Microsoft datacenter within the geographic region you specified. While the key can be used by Azure RMS
for decryption operations, it cannot be exported or backed up from there. With BYOK the full control and
the responsibility to back up the key is entirely left to you. Microsoft suggest that CSO, CIO, and risk
management team set up suitable escrow procedures and practices. More information about your
responsibilities is in the Operations for Your Azure Rights Management Tenant Key article.
P A G E | 022
Azure RMS Security Evaluation Guide
4.4.5
Keys created for BYOK are limited to one specific region
The Azure RMS infrastructures at Europe, US, Asia Pacific, and South America geographic regions are
configured with different HSM Security Worlds. When you create the BYOK key on-premises, the CSO uses
BYOK tooling to encode your organization’s keys to the geographic region of your choosing. Afterwards,
it's cryptographically impossible to import a key created for one geography in another one.
You can find more information about ‘Security World’ concepts and secure key management architecture
for the Thales Family of HSMs in Thales Security World white paper.
4.4.6
How RMS client protects files
Let’s say that you are a user who wants to protect a file with RMS. The first thing you have to do is to get
your client bootstrapped and initialized. For the purposes of this document let’s assume the client is already
bootstrapped at this point, and that the user already has a RAC (Rights Account Certificate), a CLC (Client
Licensor Certificate), and a copy of the Server Licensor Certificate (SLC).
The user who wants to protect a file has to initiate protection and the RMS client on behalf of RMSenlightened application will automatically perform a series of steps in order to get the file transformed into
a protected file. The series of steps are as follows:
1.
The client generates a random symmetric key using system PRNG. Let’s call that the Content Key.
2.
The client takes the body of the file it wants to protect and encrypts it with the Content Key by
using the AES symmetric encryption in CBC mode. It ends up with an encrypted object with an AESencrypted version of the original content, and it still has the Content Key used to encrypt it.
P A G E | 023
Azure RMS Security Evaluation Guide
3.
The client has a local copy of the Server Licensor Certificate with its public key. It uses this public
key to encrypt the Content Key. Which means that this encrypted Content Key will only be readable
by the service whose SLC was used.
4.
The client then creates a list of rights expressing who can do what on the document. This list
depends on the action the user performed to protect the file. For example if the user clicked on the
Do Not Forward button in Outlook, the list will include all the intended recipients of the email, and
for each the rights will include View but not Copy or Print. The logic is slightly different if the file is
protected with a Rights Policy Template as the list of rights will be replaced with a reference to a
predefined list in the Azure RMS service, but the process is similar.
5.
After creating a list of rights, the client will take this list and express it in XrML. Then the client takes
the encrypted Content Key (encrypted with the SLC), the public part of its own CLC and the list of
rights created before, encrypts them with the Server Licensor Certificate's public key along with
some other information (such as the URL of the Licensing URL that should be used to acquire a
license to consume the document) and builds what we call the Publishing License with them. This
PL is then encrypted with the Server Licensor Certificate's public key, so only the Azure RMS service
will be able to decrypt it. The client also takes the private key from the user’s Client Licensor
Certificate and signs the encrypted object.
6.
Finally, all this is embedded to the original content encrypted with the Content Key to create a
protected file. The content key is also stored encrypted with the CLC’s public key, so the author can
also decrypt the content without having to acquire a license.
The client also grants Owner rights to the author, and issues itself a license to consume the document
without contacting the service.
4.4.7
RMS offers strong protection before a user has authenticated
We believe that a brute force attack on the AES symmetric key and RMS asymmetric RSA keys is highly
improbable. There are two cryptographic modes that are available to RMS:
a.
Cryptographic Mode 2 is an updated RMS cryptographic implementation used by default in Azure
RMS operations. It supports RSA 2048 bit keys and SHA-256 (256 bits) hash.
b. Cryptographic Mode 1 is the original AD RMS cryptographic implementation. It supports RSA 1024
bit keys for signature and encryption, and SHA-1 (128 bits) hash for signature. This mode continues
to be supported by all current versions of AD RMS in support.
The value of this updated cryptography in RMS is that it can be part of enabling your organization to satisfy
regulatory compliance with current security standards that are set by the National Institute of Standards
and Technology (NIST) in Special Publication 800-57 Recommendation for Key Management Part 1
(Revision 3) or ENISA’s Algorithms, Key Sizes and Parameters Report – 2013 Recommendations. Starting
January 1, 2011, NIST issued SP 800-57 that recommends the use of 2048-bit RSA keys. United States Federal
agencies are required to comply with NIST recommendations and many private enterprises and other
countries may choose to implement this recommendation.
To learn more, see NIST Special Publications. To find out more about how to approach updating your
deployments to support mode 2 operation, see AD RMS Cryptographic Modes.
P A G E | 024
Azure RMS Security Evaluation Guide
4.4.8
How RMS user opens protected file
In this flow the author sent the protected file to an authorized recipient via whatever means they want to
use. Let’s say the protected content was an email which the author sent to the intended recipients. Again
let’s assume that the recipient was previously activated and initialized in the RMS environment so the user
already has a RAC and all the other necessary elements configured.
Now that the recipient has a copy of the protected document or email, he or she clicks on it and it opens
on screen with some restrictions enforced. But before that happens, the client has to work with the Azure
RMS service to consume the document. Let’s see what they do to get that done:
1.
It all starts with the RMS client taking the encrypted file and extracting the signed and encrypted
Publishing License, the encrypted content key and the author’s CLC and sending it to the RMS
service indicated in the document as part of a request for a Use License. Notice how the content of
the document is NOT sent to the server, even in encrypted form.
2.
As part of the request for a license the client also sends to the server the public part of its own RAC,
the user’s identifier.
3.
We mentioned before that the author had encrypted the document with a symmetric content key,
and that it encrypted that content key with the server’s SLC public key. Since the Azure RMS service
has the private key corresponding to that SLC, the service can use that to decrypt the encrypted
content key and obtain the original, unencrypted version of the content key. This content key is
good to decrypt the body of the encrypted file, but since the service does not have the body of the
document, nor it cares about it, that’s not where it all ends.
P A G E | 025
Azure RMS Security Evaluation Guide
4.
The Azure RMS service then extracts the Publishing License from the client’s request and evaluates
it against the requesting user’s identity. If the service decides that the user doesn’t have rights to
the document, then it declines the request at this point. If the user does indeed have rights to
consume this protected file, then the service proceeds with the next step.
5.
After determining that the user does have rights to the file, the service takes the information from
the Publishing License (the list of rights) to create a specific list of the rights the requesting user has
on the protected file. The list will look like “user X has Read rights”. The service also takes the
decrypted content key and encrypts it with the users RAC public key. The requesting user will now
be the only one that will be able to decrypt this content key. The service takes these two things
together (the re-encrypted content key and the list of rights for the user) and uses them to build a
Use License, which is sent to the user as a response to the users request.
6.
At the client, the encrypted content key is extracted from the Use License and decrypted by using
the users RAC private key. It must be noted that the user never sees the decrypted content key, and
it is only the client application, under the protected environment of the RMS Client’s lockbox, that
ever gets a copy of the key.
7.
The RMG-enlightened client application, with the decrypted content key decrypts the body of the
file and uses the rights information from the Use License to display the content on the user’s screen
while enforcing restrictions according to the policy that has been defined.
The authorized recipient of the protected file can now consume the content in a controlled way. Again, this
is slightly simplified and all the steps to get the client activated left out, plus concepts like content prelicensing are omitted, but the main logic is described here.
4.4.9
Azure RMS supports rolling over the tenant key
Azure RMS has an Active key as the primary key in use, which can protect and unprotect current documents.
Older keys are set as Archived keys and can be used to consume content that was protected when they
were the Active key. If you think there is the slightest chance that you have not been handled correctly your
copy of the keys and there is a chance of key compromise then you can roll your key, that is, establish a
new Active key. Then, administrative tooling can be used to unprotect and re-protect old content. Learn
more in Operations for Your Azure Rights Management Tenant Key article.
4.5 Services Logical Security
4.5.1
Azure platform security capabilities
Azure RMS services are hosted on the Azure platform. Microsoft Azure is a cloud computing platform and
infrastructure for building, deploying and managing applications and services through a global network of
Microsoft-managed datacenters. Azure consists of services that facilitate the development, hosting and
management of scalable cloud services like Azure RMS. Since Azure hosts customer data and services,
Microsoft must address information security challenges above and beyond traditional on- or off-premises
IT scenarios. The Windows Azure: Technical Insights white paper describes how Azure platform helps protect
your Azure RMS tenant. These security controls include:

Federated identity and access management based on Microsoft accounts or Azure AD
organizational accounts.
P A G E | 026
Azure RMS Security Evaluation Guide





Use of mutual TLS authentication.
Component isolation through a layered environment.
Virtual Machine state maintenance and configuration integrity.
Storage redundancy to minimize the impact of hardware failures.
Monitoring, logging, and reporting on administrative actions.
4.6 Network and Physical Security
4.6.1
RMS clients use specific URLs to communicate with Azure RMS services
If you have a firewall or similar intervening network devices that must be configured to allow specific
connections, see Office 356 URLs and IP address ranges (specifically for Azure RMS, you must allow
*.aadrm.com and *.azurerms.com, that are used exclusively by Azure RMS). The list of URLs and IP
addresses in this article apply to Office 365, Azure Active Directory, and Azure Rights Management services.
In addition to the information in the Office article, specific to Azure RMS:

Do not terminate the TLS client-to-service connection (for example, to do packet-level inspection).
Doing so breaks the certificate pinning that RMS clients use.

Do not use a proxy configuration that authenticates on behalf of a user.
See more in Azure RMS requirements for infrastructure that supports connectivity to the Internet and
dependent cloud services.
4.6.2
RMS clients use TLS channel to communicate with Azure RMS services
TLS secure channel is used to help secure requests in transit between Azure RMS datacenters and you, and
best-in-class encryption is used to help secure data between Microsoft datacenters. In TLS negotiation we
prefer cipher suites that support Perfect Forward Secrecy (PFS). PFS uses a different encryption key for every
connection, making it more difficult for attackers to decrypt connections. Modern RMS clients also use
certificate pinning with Microsoft-managed CAs to help secure their communication with Azure RMS
services.
4.6.3
Azure RMS relies on Azure platform for network security
Azure RMS is a hosted service on Microsoft Azure platform and relies on Azure network security for multiple
layers of network security protection (network access, DDoS defense, IDS/IPS, and load balancing) and
isolation. You can read more about deployed mechanisms in the Azure Network Security Whitepaper.
4.6.4
Physical datacenter security
All datacenters where Azure RMS services are operated has 24-hour monitored physical security.
Datacenters are physically constructed, managed, and monitored to protect data and services from
unauthorized access as well as environmental threats. Access to customer data by Microsoft operations and
support personnel is denied by default. When granted, access is carefully managed and logged. Datacenter
access to the systems that store customer data is strictly controlled via lock box processes. See more at
Microsoft Global Datacenters site.
P A G E | 027
Azure RMS Security Evaluation Guide
Appendix: Important Roadmap Items
This section expresses the more commonly discussed asks and issues related to Azure RMS. Please note
that this section does not provide guarantees or commitments on the release dates.
Office (Word, Excel, PowerPoint and Outlook) does not support RMS on <platform X>
Gap: Not all of the core Office clients and services fully support RMS today on all platforms. This
prevents the consumption of RMS content on all platforms.
Roadmap: This is understandable as in many cases Azure RMS shipped after the prior generation of
products (for example, Mac Office 2011). The Office team plans to support RMS on all Office platforms.
Guidance: The Office team will disclose more on their timelines (for example, see here). Many of our
solutions partners support RMS on all important platforms. We recommend that you look at their
offerings to compliment the available Office solutions in the meantime.
Azure RMS application is lacking X, Y, Z capabilities
Gap: The RMS sharing application currently has several core gaps: eliminate the need for administrative
permissions to install the application, add templates support to the Windows application, and enable
the switching of user identities.
Guidance: All 3 of these issues and more are being addressed. Expect them soon.
Document tracking and access revocation
Gap: Many customers want rich tracking facilities as well as the ability to ‘remotely kill’ a document.
Guidance: The preview is released for North American customers. Please find more at
https://aka.ms/rmstrack.
RMS support for OneDrive for Business
Gap: Many customers want OneDrive for Business support for RMS.
Guidance: See the Office team blog at this link http://blogs.office.com/2014/11/19/secure-syncinformation-rights-management-onedrive-business.
Office 365 Exchange Online (EXO) and HSM-backed Azure RMS BYOK
Gap: Today, in order to use the RMS-enlightened Exchange Online capabilities, an organization must
provide a non-HSM protected RMS root key to the EXO service team. This is often a concern for some
customers.
Roadmap: Addressing this gap is on the EXO product roadmap. The current Office 365 Exchange Online
(EXO) service shipped before Azure RMS shipped and so it does not leverage the Azure RMS service
directly. Design work is underway to have EXO use Azure RMS directly. When this work is complete,
Exchange Online will directly integrate with Azure RMS and will be able to leverage all Azure RMS
capabilities, including HSM-protected BYOK.
Primary Guidance: If you are using EXO before then, we recommend you pilot and deploy Azure RMS
with a Microsoft-managed tenant key. In 99% of the customer deployments, using RMS dramatically
reduces the security risk of a data loss given all of data goes unprotected today. The key management
standard operating procedures (SOPs) of the EXO team are extremely stringent despite the key not
being in an HSM. Then, at the time when EXO supports HSM-protected BYOK, your organization would
roll the RMS root key. This process would create a new Active key (the one used to protect all content)
P A G E | 028
Azure RMS Security Evaluation Guide
that will have only ever existed in an HSM. The old key would become an Archived key (only used to
access previously protected content). This flow creates a seamless transition while raising your existing
document protection standard.
Secondary guidance: If your security policy prevents considering the above guidance, your
organization can simply decide to not provide the EXO service with the RMS root key. Use of the EXO
RMS-enabled services is not required as you can continue to use RMS protection in Outlook client. EXO
will function correctly, but cannot support IRM features (e.g., preview in OWA). This result in the loss of
several EXO capabilities on RMS protected files but this is no different than using other more basic and
opaque encryption schemes such as PGP.
RMS support for social identities
Gap: Today, we rely on Azure AD for authentication and it did not support social identity providers for
pass-through authentication until recently.
Roadmap: We are working with the Azure AD team to support social identities (for example, Google
account, Facebook account). Expect them later this year.
RMS support for multi-factor authentication (MFA)
Gap: Today, multi-factor authentication may work in some RMS enlightened applications, but may not
work in other applications.
Roadmap: We are working with our partners in Azure AD to update service authentication data flows
and with our partners in Office team to use Azure AD authentication library (ADAL) across applications.
Expect support for MFA required for the tenant in a summer release.
“I want to maintain my <product> key on premises”
This is not supported at this time. Generally, the request takes one of two forms:

“I want to maintain my authorization service on premises”: We advise against that (and do not
support it at this time) for many reasons. In this scenario, you would be operating an RMS service
in the public network (DMZ). That carries most / worse risks than letting us operate it: Your
organization is likely not prepared to detect problems, patch the service as quickly (hours versus
several days) or, otherwise deliver true 24x7x365 servicing. We built the service. This is what we do;
it is our expertise.

“I want to maintain the Azure RMS root key in my HSM on premises. Call my HSM”: We also
advise against this scenario (and do not support it at this time). HSMs are not Policy Decision Point
(PDP) or Policy Enforcement Point (PEP). They are always accessed using ‘service accounts’. The
HSM logs would show 1,000,000 operations per day saying ‘Azure RMS used the root key’. This
does not permit your organization to make relevant access control decisions as you would clearly
trust Azure RMS. See the previous point about the importance of user authentication. It is
Microsoft’s belief that our customers should focus their efforts on strong user authentication and
account controls.
P A G E | 029
Azure RMS Security Evaluation Guide
Appendix: Consultants and Solution Providers
While Azure RMS is much simpler to deploy than its on-premises equivalent of AD RMS, we still advocate
using specialized consultants for the more complex deployments. This will ensure the most efficient rollout
and best possible overall experience. At this time, we suggest the following:
Microsoft Consulting Services (MCS) is a part of Microsoft specializing in all aspects of consulting services.
Please contact your Microsoft account manager to engage MCS.
Synergy Advisors at http://www.synergyadvisors.biz and AskIPTeam@synergyadvisors.biz
Thales (HSM consultants) at https://www.thales-esecurity.com/msrms.
Additionally we work with the following partners – they make RMS better in a variety of different ways.
Presented here in alphabetical order:
FOXIT software (PDF) at http://www.foxitsoftware.com
Gigatrust (Several RMS offerings) at http://www.gigatrust.com
Glück & Kanja (Several RMS offerings) at http://glueckkanja.com and AskIPTeam@glueckkanja.com
Nitro (PDF) at https://www.gonitro.com
Secude (SAP data protection) at http://secude.com and AskIPTeam@secude.com
Secure Islands (Several RMS offerings) at http://www.secureislands.com
TITUS (Several RMS offerings) at http://www.titus.com and AskIPTeam@titus.com
Watchful Software (Several RMS offerings) at https://www.watchfulsoftware.com
Synergy Advisors published multiple videos at https://www.youtube.com/user/SynergyAdvisors/videos
P A G E | 030
Azure RMS Security Evaluation Guide
References
Thank you for reading our reviewers guide. We hope that it was informative. The following resources are
available to provide more information about Microsoft Azure RMS and related Microsoft services, as well
as specific items referenced in the main text:

Microsoft Azure Rights Management
o

https://aka.ms/rmshome
What is Azure Rights Management?
o
https://aka.ms/rmsgetstarted

RMS news

RMS blog
o
o

https://aka.ms/rmsnews
https://aka.ms/rmsblog
Azure RMS presentation
o
https://aka.ms/rmsdeck

Azure RMS video presentation

Azure RMS user and service demonstration slides
o
o

https://aka.ms/rmsdemodeck
Microsoft Azure Home – general information about Microsoft Azure
o

https://aka.ms/rmsvideo
http://azure.microsoft.com/
Microsoft Azure Trust Center
o
https://azure.microsoft.com/support/trust-center/
If you want to learn more about Azure RMS, please follow us @TheRMSGuy, grow with others in our
customer facing user group, and influence our product investments via our Customer Advisory Board.
Further Reading

Azure Rights Management topics
o

Terminology for Azure Rights Management
o

http://technet.microsoft.com/en-us/library/dn655136.aspx
10 Things to know about Azure Security
o

http://technet.microsoft.com/en-us/library/dn595132.aspx
Requirements for Azure Rights Management
o

http://technet.microsoft.com/en-us/library/jj585024.aspx
http://technet.microsoft.com/en-us/cloud/gg663906.aspx
RMS Boot Camp
o
http://curah.microsoft.com/56313/boot-camp-for-windows-azure-rights-managementrms

Licenses and Certificates, and how AD RMS protects and consumes documents
o
http://blogs.technet.com/b/rms/archive/2012/04/16/licenses-and-certificates-and-howad-rms-protects-and-consumes-documents.aspx
P A G E | 031