Three Considerations for Azure Information Protection Deployments

Azure Information Protection (AIP) – more accurately exposed to Microsoft 365 now as sensitivity labels – is close to the top of my favourite wins for securing your data in a Microsoft ecosystem.  While designing a detailed labelling and classification system is far from quick, it is quick to get up and running with baseline policies that protect your confidential company data from getting read outside the company.  Simply by applying a sensitivity label that limits access to confidential data to users in your domain, you’ve covered a massive chunk of data loss scenarios.

But… not so fast.  While AIP is fantastic, there are some often overlooked elements you need to consider before rushing in and deploying to your users.  None of them are dealbreakers, but probably things you’ll have wished you knew.

1. OneDrive and SharePoint Support

Historically, you could not access any protected files in the web Word, Excel, and PowerPoint apps.  The services could not decrypt the content to present it in the web app, and you would get an error message that the content would only be readable in the full client app.  What this also meant is that other services reliant on reading content weren’t supported, such as coauthoring.

Now, you can enable Office online support for encrypted files from either the Compliance Centre or PowerShell.  When turned on, uploaded files are actually decrypted as they enter the cloud storage, to enable that content indexing and retrieval, then downloaded if it ever leaves the web.  It’s opt-in, for now (and note that coauthoring is only in preview for lab tenants).

This is such an improvement, but there are still some important things you need to know about it.

• If you save a file directly to OneDrive for Business or SharePoint Online from a full client app or get one into there syncing with OneDrive.exe, you’ll hit problems when opening that file in the web app.  Microsoft describes this as a “limitation”, noting “if the service is still processing the encryption, the user sees a message that the document must be opened in their desktop app. If they try again in a couple of minutes, the document successfully opens in Office for the web.”  My experience is that the minutes really go on forever: I have uploaded files that have never been readable in Office online, despite the functionally being enabled.

• Some label settings matter and will render the file unsuitable for Office online.  Labels that protect content and have an expiration, use a double key/hold your own key, or user-specified permissions are not compatible with Office online.  They cannot be viewed in the web apps, and cannot be indexed by services such as eDiscovery.
• Similarly, how a label is applied matters.  If a label is applied using Microsoft Cloud App Security, rather than by a user or automatic labelling in an app, Office online will have the same problem as above.
• Earlier, I mentioned how Office online support for sensitivity labels actually works: by removing the encryption as it enters the platform, and reapplying it as it exits.  The big risk?  If a label is deleted, it cannot be reapplied, and the file exists with no encryption.  While this is a significant risk, best practice has been for some time to not delete labels: only remove them from policies.

2. Super User

A common concern around the process of encrypting company files is losing access to it.  The encryption’s strength means you can’t just mess around with the file and get in some way like a password protected Excel worksheet: you must explicitly have access rights.

There is always a “backdoor” to your AIP protected files if there’s a super user available.  Described as a feature rather than a role, the ability for someone to be an AIP super user isn’t even on by default, and you must enable it with PowerShell AIPService module.  When it’s enabled, it can be assigned to users or groups with PowerShell.  It’s not enabled by default as a security precaution: a super user can open all your AIP protected files without limitation, as they get Full Control rights over any files protected with sensitivity labels.  While this is useful in moments of disaster and you just need access (or even scenarios like tenant migrations), you obviously better protect this privilege.

Two things worth considering with regards to protecting super user rights are:

• Monitor activities.  This can be done in the Compliance Center under Data Classification > Activity Explorer.  Alternatively, use Get-AipServiceAdminLog.  It doesn’t explicitly tell you if a user is super user while accessing the content, but you can marry these logs up with auditing making someone a super user with Add-AipServiceSuperUser cmdlet or Set-AipServiceSuperUserGroup.  All of this should make its way to your SIEM, making it easier to recognise super users being created, then accessing files.
• Protect elevation using Privileged Identity Management (PIM).  You can assign roles to Microsoft 365 groups created since August 2020; a feature we can use to make elevations to super user rights protected by PIM and therefore things like MFA, approval, and justifications.  Enable PIM for the group, then set its members to be a super users with Set-AipServiceSuperUserGroup.  The users will not get these rights, however, until they activate them using PIM, which controls if membership to the group is active or not.

3. Track and Revoke

Protecting documents with AIP went under a facelift a few years ago with the introduction of sensitivity labels in 2018.  These still use AIP, but the application is different; a change mostly for the better.

The updates have seen the migration of label management from the Azure portal to Microsoft 365 admin portals, with labels now mostly managed at compliance.microsoft.com.  The change has also seen the introduction of labelling built into the Office apps – across all platforms – which was a welcomed feature.  Previously, labelling was done with the deployment of a client: the Azure Information Protection client.  The client also underwent a facelift and is differentiated from the old one (which you can no longer download) with the branding of Azure Information Protection unified labeling client.

Regretfully, as part of all this, a feature called track and revoke was lost until very recently.  To the horror of many, it was also described as not being planned for reintroduction.  We now, fortunately, are starting to see it make an appearance again, with client version 2.9.111.0.  You can read more about that in my blog here.

What’s important to know about the ‘new’ track and revoke is its poor feature parity with the classic labelling track and revoke system.  That classic system was managed with a web portal at track.azurerms.com, and end-users could “see exactly who has opened, used, and attempted to view your documents” and “revoke access when you need to.”

The kind of features available in this web portal included:

• Complete list of documents you have protected
• Data on the number of document views and denied access attempts
• Time since last activity
• A map of geo-IP access (!!!)
• Email notifications whenever the file was opened or denied (your choice)
• A revoke access button

Now, there is no web portal, and revocation is handled in the app itself if you open the file.  The kind of features available include:

• A revoke access button

You get the picture…

While this is a welcomed step forward compared to no ability, consider a few areas things will get difficult.  Previously, the end user could revoke access to any of their files; but now, what if they delete a file then need to revoke it?  As covered in this blog, they will need an administrator to track the file using PowerShell.  Ultimately, track and revoke has gone from being a popular user feature to an administrator-dependent option of last resort.  Please remember to manage expectations if you have previously deployed classic labelling and start preaching the benefits of tracking or revocation for a new deployment.

Conclusion

The benefits of sensitivity labels vastly outweigh any shortcomings or problems highlighted above.  Do not use these as reasons to delay your deployment, but rather as only constraints you will need to factor into your adoption and communication plans.  None of the shortcomings will be with us forever: track and revoke can get better, and the OneDrive/SharePoint issues definitely are.  As for the super user function, that’s far from a shortcoming: it a break-glass, a get-out-of-dodge feature that you simply have to treat as Tier 1, so protect and monitor it as such.