CCSP: Information Rights Management (IRM) in the Cloud

Information Rights Management (IRM) is a data-centric control that encrypts a file or message and attaches a usage policy to it, so that who may open it and what they may do with it are enforced wherever the object goes. The object can be emailed to a partner, copied to a USB drive or uploaded to someone else's cloud storage; it stays encrypted, and only an IRM-aware application that obtains a license from the rights service can open it, and then only with the rights the policy grants. IRM is sometimes called enterprise digital rights management (E-DRM); consumer DRM, which protects media sold to the public, uses similar mechanics for a different purpose.

Why encryption at rest, DLP and CASB are not enough

Most data controls act at a location or a boundary. Storage encryption protects data while it sits in a service, and access checks in that service decide who may read it there. Data loss prevention (DLP) inspects content as it tries to leave a network, endpoint or application. A cloud access security broker (CASB) governs use of cloud applications and uploads to them. Once an authorized user has a decrypted copy outside that location, none of these controls applies any more. IRM is the one control in this group that persists with the object after a legitimate share.

These controls are complementary. A common design keeps DLP and CASB at the boundaries and applies IRM automatically from a file's classification label when it is shared externally, so staff share files the way they always have while protection travels with each file. The aim is to control legitimate sharing, not to prevent it.

IRM is the protection step that acts on classification (sub-domain 2.5): labels decide which IRM policy applies. Encryption algorithms and general key management belong to data security technologies (2.3); this lesson covers how IRM uses them.

IRM works by separating the protected content from the decision to open it: the file carries encrypted content and a reference to its policy, and a rights service decides, each time a user asks, whether to issue a use license that lets that user's client decrypt it with specific rights.

1. Protection. When a file is protected (by its author, or automatically from a label), the client generates a content key, encrypts the content with it, and wraps the content key and the policy so that only the rights service can unwrap them.
2. Request. A recipient opens the file in an IRM-aware application. The client authenticates the user (through the directory or a federated identity provider) and sends the request to the rights service.
3. Decision. The rights service evaluates the current policy for that identity, and any conditions such as device or location.
4. License. If the user is allowed, the service returns a use license containing the content key and the granted rights, encrypted to the requesting user's or device's key, so only that holder can use it.
5. Enforcement. The IRM-aware client decrypts the content and enforces the rights: it shows view-only content, disables print, copy or save-as, applies watermarks, and stops opening the file after its expiry.

Three consequences follow, and much of the topic rests on them:

• A copied file is still useless to an outsider. Wherever a protected file ends up, anyone outside the policy who obtains it cannot get a license from the rights service, so the file will not open for them.
• Licenses are per document and per user (or device). Holding a license for one document does not open another.
• The client is the enforcement point. Rights are only as strong as the application that enforces them, which is why IRM needs a compatible client on every platform (see the challenges section).

The rights service may be hosted on premises or, as is now common, offered by a cloud provider as part of its productivity or collaboration suite. The concepts are the same either way; what changes is who holds the keys (see key custody below).

IRM grants granular usage rights: instead of a single read permission, the policy lists which actions each user or group may perform on the content once it is open. Folder permissions, DLP and encryption keys decide who can reach or decrypt a file; only IRM decides what an authorized reader can do with it.

Each right governs one action, so design by mapping each requirement to the right that controls it and granting the narrowest set that lets the work happen. Rights such as export/save-as, change rights and full control are different in kind: they let the holder produce an unprotected copy or alter the protection itself, so they are withheld from anyone who should only work within the protection.

What IRM cannot stop

IRM controls what the software lets a user do. It cannot control the analogue world: an authorized viewer can photograph the screen with a phone, retype the content or read it aloud. That photograph is a new object outside the IRM system. Moving the protected file itself is a different case: whatever the channel, the file travels encrypted with its policy, so nobody outside the policy gains a readable copy. Organizations therefore pair IRM with visible watermarks that name the viewer and time (a deterrent and an attribution aid), with care over who receives view rights at all, and with legal agreements such as NDAs.

What are replication restrictions

Replication restrictions are the IRM rights that stop an authorized viewer from creating a new, unprotected copy of the content: blocking copy and paste, screen capture, printing, and save-as or export. They exist because persistent protection only covers the original object. A viewer who copies text into a new document, exports the file to PDF or takes a screenshot creates a new object that carries no protection at all.

• Copy/paste blocking stops text and images moving to the clipboard.
• Screen-capture blocking stops the operating system's or a tool's capture from recording the protected window.
• Print blocking stops paper and print-to-file copies.
• Save-as / export blocking stops conversion to another, unprotected format.

Enforcement depends on the client. A full IRM desktop client on a managed device can usually block screen capture; a browser-based viewer or a client on an unmanaged mobile platform often cannot. When policy demands a restriction that some clients cannot enforce, the answer is an access condition on the policy: allow the sensitive content to open only on managed devices running a client that enforces it, and leave the lighter viewer available for less sensitive content. A restriction is only as real as the client that enforces it.

Dynamic policy control means that rights are evaluated by the rights service when the content is opened, not frozen into the file when it is sent, so the owner can change rights centrally after distribution without resending anything. When content already shared with many outside parties is reclassified, the owner changes the policy once, and every copy opens with the new rights the next time its client checks with the service.

Dynamic policy control is often confused with its neighbours:

• Persistent protection keeps the file encrypted and policy-bound wherever it goes, but says nothing about changing that policy.
• Remote revocation is a specific dynamic change: removing a user's rights entirely.
• Automatic expiration is decided in advance and needs no later change at all.

Because each recipient's rights are looked up separately, different recipients can be changed in different ways at the same time: one party can lose access entirely while others keep reduced rights, and nothing new has to be distributed.

How do automatic expiration and remote revocation differ

Automatic expiration ends access at a time decided when the content is protected, with nobody needing to act; remote revocation ends access when someone decides to, by changing the policy at the rights service. They behave very differently when the client is offline.

Use licenses, offline access and revocation delay

To let people work without a connection, IRM clients cache use licenses for a configured offline period. That is a deliberate trade-off. A cached license lets the client open the document without asking the service, so the service has no chance to refuse it: revocation takes effect only when the cached license lapses or the client reconnects. The offline license period is therefore the worst-case delay before a revocation bites.

• A user whose rights are revoked while their laptop is offline can keep opening the documents already licensed on that device until those licenses lapse. Documents never licensed on that device cannot be opened, because each needs its own license, and an offline client cannot get one.
• Expiration is part of the policy delivered with the license, so a cached license cannot extend access past the content's expiry. Content stops opening on its expiry date even on a device that has been offline for weeks, whereas revoked content with no expiry keeps opening on that device until the cached license lapses or the device reconnects.
• Where copies already distributed must stop opening quickly after an unplanned event, set a short use-license validity, so clients must recheck rights often.

Choose expiration whenever the end date is known in advance. It is enforced by the client from the license itself, so it takes effect on the date with no further action by anyone.

IRM's continuous audit trail is the rights service's record of every attempt to open protected content and the actions attempted on it, including by recipients outside the organization. Because opening requires a license or rights check from the service, the owner keeps visibility after a file has been emailed out, which ordinary file sharing loses the moment a file leaves.

Typical records show the identity, time, document, the result (granted or denied) and rights-controlled actions such as denied print attempts. Because they are kept by the service rather than by the recipient, they are a reliable record of who had access and when.

Their limits matter in an investigation:

• They do not show what a permitted viewer did with what was on the screen: a photograph or retyped copy leaves no IRM record.
• So they establish access, not conduct: they narrow an investigation to the identities that opened the content, and other evidence has to do the rest.
• Opens served from a cached offline license may reach the service only later, or not at all, depending on the product.

Auditing reports on access; it never removes access. Collecting, protecting and analysing these events alongside other logs is covered by sub-domain 2.8 (auditability, traceability and accountability of data events).

IRM rights are provisioned by granting them to identities and groups in the directory or identity provider (IdP) that the rights service trusts, so the identity lifecycle is the IRM lifecycle. Rights granted to individual names in each document do not scale and are never cleaned up.

• Leavers. Disabling a leaver's account in the directory stops them authenticating to obtain or renew licenses for every document at once, including copies on a personal laptop. Licenses already cached on a device still work until they lapse, which is why the offline license period matters.
• Access reviews. When people who should no longer have access can still open protected content because they are still in an authorized group, IRM is enforcing the policy exactly as written. The failure is in provisioning, so the remedy is in provisioning too: periodic owner reviews of group membership, with removals made in the directory. Settings on licenses or documents cannot change who belongs to a group.
• Partners. For an external team whose membership changes often, federate with the partner's IdP and grant rights to a partner-asserted group. The partner, who knows when its people join and leave, maintains membership, and the scope stays limited to that team.

Any design for external access can be judged on two questions: is the grant scoped to the people who actually need the content, and is membership maintained by the party that first learns when someone joins or leaves? Federation answers both questions, at the price of trusting the partner's identity provider and its joiner-leaver process.

IRM supports three ways of deciding rights, and real deployments combine them: central templates defined by the organization, discretionary rights set by each author, and attribute conditions evaluated at open time.

In classic access-control vocabulary, templates whose rights follow directory roles are role-based access control (RBAC); author-set rights are discretionary access control (DAC); conditions on device, location or time are attribute-based access control (ABAC); and a policy the system enforces from a classification label and the user's clearance, which neither the author nor the recipient can override, is the IRM form of mandatory access control (MAC).

• Templates and roles. Binding a template to a label means any document classified that way gets the same rights automatically; mapping the template's rights to directory roles (for example, one role may edit and another only view) keeps it right as people change jobs. If authors must not choose different rights, the template must not allow an author override.
• Mixing models. One IRM service can serve teams with different needs. Apply central templates, with author override disabled, to the classifications that require fixed rights, and leave author-set rights available for everything else. The scope of each model follows the classification, not the team.
• Attributes. Some requirements depend on the context of an open, not on the person: whether the device is managed, which network it is on, where the user is, or the time of day. Group membership cannot express these. An attribute-based model evaluates such conditions at open time, alongside identity.

Certificates are the tools that tie IRM's licenses to identities: a user or device certificate binds an authenticated identity to a key pair, and the rights service encrypts each use license to that public key so that only the holder's private key can use it. Issuing and revoking these certificates is how an IRM system admits and removes users and devices. (General PKI and TLS certificate lifecycle belongs to sub-domain 2.3.)

Issuing

• A client is typically enrolled before first use: the service or its certificate authority issues a certificate for that user and device.
• The control that matters most before issuance is identity proofing to the level the content requires, especially with self-service enrollment for external people. If an impostor obtains a certificate in someone else's name, every later rights decision is made for the wrong person, however good the policies.
• In IRM the certificate's job is to let a holder receive licenses. It does not by itself open any content: each document still needs its own license from the service.

Revoking

• Lost or stolen device. Revoke that device's certificate so it cannot obtain new licenses, and enroll the user's replacement device. In the worst case, where the attacker can also unlock the device and its private key, licenses already cached on it remain usable until they lapse; disk encryption and a hardware-protected key reduce that risk.
• Revocation freshness. A revocation only works when the service checks it. If the service relies on a revocation list that is published periodically, a revoked certificate keeps working until the next list appears. Checking revocation status online at license time closes that window.
• The licensor key. The rights service has its own key (often called the server licensor certificate or tenant key) that protects every content key and signs every license. Exposure of one user's key exposes what that user can open; exposure of the licensor key lets an attacker issue licenses with any rights, or decrypt content keys, for every document protected under it. Recovery means revoking and replacing the key and re-protecting content, so the licensor key belongs in an HSM with tightly controlled access.

With a provider-hosted IRM service, whoever can use the tenant key can open the protected content, so key custody decides whether the provider itself can read it. There are three common arrangements.

• BYOK changes the key's origin and gives the customer lifecycle control, so it can make all protected content unreadable by destroying the key if it leaves the provider (crypto-shredding), while the provider's features keep working. It does not make the provider technically unable to read content.
• When a requirement says the provider must be technically unable to open content, only an arrangement in which opening also needs a key the customer holds outside the provider meets it. Assurance reports such as a SOC 2 Type II report attest to the design and operating effectiveness of controls over the provider's behaviour; they do not remove its capability.
• The cost is that anything the provider does by reading content (indexing for search, rendering previews, content inspection) stops for that content. The rights service typically still records license requests, but products differ in which policy features they support for this content (some allow only fixed, label-defined permissions).
• Because of that cost, the stronger arrangement is usually applied to the most sensitive tier only, with BYOK or the standard key for the rest.

IRM's main challenges come from its strength: because rights are enforced by the client, every recipient needs a compatible IRM-aware application on every platform they use, and every party must be able to interoperate with the rights service.

• Client and platform coverage. Where a recipient's device has no compatible viewer (some mobile, Linux or third-party tools), the file stays encrypted and simply cannot be opened, turning protection into a service failure. Plan external IRM by first finding out which platforms, applications and formats recipients use.
• Interoperability. Partners may run a different IRM product or an identity system the rights service cannot federate with. Formats that the IRM client does not support cannot be protected natively.
• Uneven enforcement. Lighter clients may not enforce every restriction (screen capture especially), so policies may need device or client conditions.
• Offline and revocation trade-offs. Longer offline licenses help field users and slow revocation.
• Identity dependency. IRM is only as good as the directory, federation and certificate processes behind it.
• The analogue hole. No client can stop a photograph of the screen.

When IRM-protected files are the wrong tool

IRM protects files that are opened in IRM-aware applications. When a recipient's work requires data to be loaded into tools that cannot open protected files, any copy those tools can read is outside IRM, and once data has been decrypted into someone else's system no key or policy can withdraw it. If the owner must keep the ability to end access, the answer is to bring the users to the data: keep it in a governed shared environment (for example, a controlled analysis workspace) where the owner grants and removes access and nothing leaves.