Controlling Access to Sensitive Content
A recent Microsoft Technical Community article covers how to use Azure AD Privileged Identity Management to control access to the super-user permission for Azure Information Protection. An account holding super-user permission can access any content protected (encrypted) by an Azure Information Protection or Office 365 sensitivity label.
I don’t intend to replicate the information presented in the article, which is largely focused on accessing encrypted documents stored outside Office 365. Instead, I report my experience of using the solution inside Office 365. Given the increase in protected content stored in Exchange Online, SharePoint Online, and OneDrive for Business through the use of sensitivity labels, it seemed like a good thing to do!
Super User Permission
Super-user permission isn’t intended for daily use. It’s designed for scenarios when access is needed to sensitive content by people who don’t normally have access. For instance, if protected files are retrieved by a content search and are then turned over for review by eDiscovery investigators, the investigators cannot open the files unless rights defined in the labels applied to the files allow access. It’s possible to define rights in labels for eDiscovery access, but you’d have to do this for every label used in the tenant and that’s sometimes inappropriate. Assigning super-user permission solves the problem, but because the permission is so powerful it’s important that it is strictly controlled.
Super-user permission can only be assigned via PowerShell by a tenant administrator using the Add-AipServiceSuperUser cmdlet in the AIPService module. Once assigned, the permission remains with an account until it is revoked.
Azure AD Privileged Access Management (PIM) is a service designed to help tenants reduce the amount of permissioned access to cloud resources held for extended periods. The article outlines how to use PIM to assign time-limited access to super-user permission. Tenant administrators aren’t needed because everything is managed through the Azure AD portal, including the ability for individual users (in a defined group) to request super-user permission.
The basic steps are:
- Use the Azure AD portal to create new Microsoft 365 or Security group. The group must be mail-enabled (automatic for Microsoft 365 groups). Ensure that Azure AD roles can be assigned to the group. This is a preview feature.
- Group members can be added at this point. If they are, these members are permanent (see discussion below). You might prefer to add members as the need arises. If so, leave the membership empty.
- Optionally, delegate ownership of the group to a non-administrator so that the owners can manage group membership.
- Enable Privileged Access for the new group. This can only be done after the group is created.
- Use PowerShell to configure the Information Protection service with the email address of the new group to assign it super-user permission.
- When the need arises for a member of the group to be able to access encrypted content, use the Privileged Identity Management blade of the Azure AD portal. Alternatively, the user can activate their access through the same page (access might require approval).
Create a New Group
The first step is to create a group. This must be done through the Azure AD portal because an administrator has to create any groups used to delegate administrative roles. Assigning roles is an immutable change that can’t be made to existing groups: you must start with a new group (Figure 1).
Image 1 Expand
You can see that I added an owner and some members, which is normal for a Microsoft 365 group. Members added like this receive permanent assignments, which might not be what you want for a group that’s going to control access to some sensitive resources. The issue is easily resolved by opening the group in the PIM blade and editing the assignments to change the permanent assignments to be time-limited (Figure 2).
Image 2 Expand
Permanent assignment is supported if the group settings permit. Permanent assignment is turned off by default, but even so I was able to create permanent assignments by adding users when creating the group. This isn’t a serious glitch and it’s one that Microsoft will likely fix before the feature is made generally available.
The maximum length for an active assignment is six months unless you update the group settings. After the period elapses, the assignment is expired. Assignment information is cached, so it can take up to 15 minutes before super-user permission becomes available. This should be borne in mind when limiting the time that an assignment lasts.
Eventually, you’ll end up with a set of assignments like those shown in Figure 3. You can see three tabs. Eligible lists the users in the group who can receive an active assignment. Active lists those who currently have access to the resource managed by the group, while Expired shows users whose active assignments have expired.
Image 3 Expand
Update Information Protection
With assignments in place, the next step is to update the Information Protection service with details of the group. This is done with PowerShell. The commands are straightforward:
Connect-AipService Set-AipServiceSuperUserGroup -GroupEmailAddress [email protected] [email protected] was set as super user group for the Azure Information Protection service. Get-AipServiceSuperUserGroup [email protected]
Testing Things Out
To test how super-user permission assignment through PIM works in a common Office 365 scenario, I created a new sensitivity label called Eyes Only with rights limited to document owners. In other words, once the label is applied to an Office document, only its author can open the file, even if it’s stored in a SharePoint Online document library owned by a team where usually documents are accessible to any team member.
Attempts to access a document with the Eyes Only label fail for anyone but the author (Figure 4). The Word viewer reports “Unknown error” when invoked by Teams to display a file. The PowerPoint and Excel viewers have their own variants on the error message, none of which are particularly informative (for example, PowerPoint says “Sorry, we could not contact the server”). Better text to report why the problem exists would be appreciated, but the point is that the user can’t access protected content.
Image 4 Expand
To gain access, the user can activate their access through the PIM blade (Figure 5) and request access for the maximum time allowed in group settings.
Image 5 Expand
Alternatively, an administrator can update the user’s assignment to make it active. In either case, once the change is effective, super-user permission is effective (Figure 6) after a short delay to allow for caching. Even better, the permission is revoked once the activation period elapses.
Image 6 Expand
In practice, super-user permission is probably more likely used in circumstances where multiple protected files, possibly drawn from multiple storage locations and assembled for review in a single place, need to be decrypted. This is easily done with by removing the label with the Set-AipFileLabel cmdlet.
Azure AD Premium P1 licenses are required to manage role assignments through Groups. This shouldn’t be an issue for large Office 365 tenants. In their FY20 Q4 results, Microsoft said that the Enterprise Mobility and Security (EMS) suite now has 147 million users, which includes Azure AD Premium P1. There’s a huge crossover between companies who buy EMS and the enterprise segment within the 258 million Office 365 seats.
PIM Makes Control Easier
Being able to manage resources like super-user permission through PIM makes it easier to ensure that people get the access they need to do their job for as long as needed instead of indefinitely. Everything discussed here could be accomplished with some PowerShell scripting, but it’s better when Microsoft has an off-the-shelf solution. Group assignments are in preview now. I shall look forward to see if the generally available version of the software introduces some refinements to make the solution even better.
The post Use a Super User Group for Privileged Access to Encrypted Office 365 Content appeared first on Petri.