Secure external collaboration using sensitivity labels

In this article we are going to clarify a topic which has been causing a lot of confusion and questions among our customers: “How do we  securely share emails and documents with someone outside of our organization using sensitivity labels?”

 

Disclaimer: Considering diversity of operating systems and productivity applications used these days and vast amount 
of possible combinations of identities and software used, we will not be able to cover all possible scenarios in this 
article but will focus on the most common ones instead.

We assume that the reader has some basic knowledge about sensitivity labels, their purpose, how to create, apply, and manage them. If you are new to this field, a good place to start is here. We also highly recommend to spend fair amount of time reviewing documentation on Azure Right Management Service (RMS), which is a critical component of all our Information Protection solutions, responsible for encryption and access control management.

 

Before we jump into it, let’s  set the stage by clarifying a few things first. Everything we are going to cover in this article is applicable to both the client-based solution a.k.a. Azure Information Protection (AIP) as well as the modern built-in labeling capability in Office 365 applications which is part of a broader Microsoft Information Protection (MIP) framework. Both solutions use the same unified sensitivity labels.

 

Note: If you for some reason have not migrated your existing sensitivity labels to the Unified Labeling yet, it is 
about time to do that as the AIP classic client and label management in the Azure portal will be deprecated on 
March 31, 2021. Please find more info on deprecation notice here.

 

We are also going to be focusing on Microsoft Office and Adobe PDF as the most used file types and that have full classification and protection support.

 

Alright, let’s say you need to implement a solution that will allow your users to securely share emails and documents with people outside of your organization (consumers, partners, auditors, etc.). In other words, share it with someone whose identity and device is out of your control.

 

When you create a sensitivity label, you can either determine which users get which permissions to content that has the label applied, or you can allow your users make this decision when they apply the label (also commonly known as user-defined permissions or UDPs).

 

Figure 1: Creating a new sensitivity label in the Microsoft 365 Compliance center.

When it comes to the predefined permissions (Assign permissions now), we have four options as shown below.

 

Figure 2: Assign permissions dialog.

“Add all users and groups in you organization” is pretty much self-explanatory, all existing and future users and groups from your Azure Active Directory (AAD) tenant will be able to access and consume the protected content (emails and documents). This is a great option for secure internal collaboration, therefore, we are not going to spend a lot of time here.

 

“Add any authenticated users”, with this option we can encrypt content and limit what users can do with protected emails or documents, but can’t limit those who should be able to access this protected content – any authenticated user will be able to do so.

 

An example scenario might be when you need to share certain information (e.g. financial reports) with your customers or partners. Even if it’s overshared, it won’t cause any issues to your business, but you want prevent this information from being copied and re-used outside of your documents. In addition to that, it is possible to make the protected content time-bound as well as control whether users can access it offline and for how long. In this case your label may look like this:

 

Figure 3: A sensitivity label granting Authenticated users view-only access.

 

“Add users and groups”, this option allows you to provide a list of AAD users and groups and specify what permissions that user or group will have for the protected content.

Note: There are several identity and software requirements and limitations that we are going to cover in detail 
later in this article.

 

For example, you can create a label for a team working on a specific project and allow them to use that label to securely collaborate with an approved list of external partners.

 

Figure 4: Assigning permissions to AAD groups.

 

You can invite anyone to collaborate with your organization by adding them to your directory as a guest user. Guest users can sign in with their own work, school, or social identities. 

 

Note: Please take a moment to review current Azure Active Directory limitation and restrictions.

 

 Figure 5: Group membership containing guests accounts from different providers.

 

Figure 6: Adding a new guest user.

 

This is a very granular and flexible way of managing who will be able to access your protected content but it does add additional work to your AAD administrators.

 

“Add specific email addresses or domains”, with this option you can specify a list of specific emails or the whole domains.

 

For instance, if you are a group of companies, each one with its own AAD tenant, you can list all domain names so that every user of those orgs will be able to access content protected by this label.

 

Figure 7: Permissions assigned to multiple domains.

 

If you have very complex requirements for your label you can mix and match any of those four options.

 

Last option that we have is “Let users assign permissions when they apply the label” a.k.a. the user-defined permissions, that lets users specify who should be granted permissions and what those permissions are.

 

Figure 8: Creating a label with the user-defined permissions.

 

This is a good option when you do not know upfront who your users will be sharing the protected content with and you feel comfortable with transferring responsibility of making an appropriate security decision to the end users.

 

Note: As of this writing (9/15/2020) not all platforms support the user-defined permissions yet. Please keep an eye 
on our documentation to track our progress.

 

Now, let’s switch sides and talk about what kind of identity and software your partners/recipients would need to have in order to successfully consume the protected content (emails and documents) you would like to share with them.

 

When it comes to identity, we can determine five main categories: Work or school accounts (AAD), Microsoft Accounts, Federated social providers, Public email providers, and everything else.

 

Protected emails.

 

 

Here are a few examples of what user experience depending on a platform and type of identity used would be.

 

Figure 9: Seamless access to a protected email in Mail and Calendar App on Windows 10.

 

Figure 10: Seamless access to a protected email in Outlook for Mac.

 

Figure 11: Accessing a protected email using Outlook, Samsung Email App and Gmail App on Android.

 

Figure 12: Protected email sent to a mail.com user.

 

Figure 13: OME authentication page for different types of identity.

 

Figure 14: One-time passcode sent to a mail.com user.

 

Figure 15: Accessing a protected email using the OME portal.

 

Figure 16: Unintended recipient trying to access a protected email.

 

Protected documents.

 

 

Here are a few examples of what user experience of accessing a protected document depending on a platform and type of identity used would be.

 

Figure 17: Accessing a protected document shared by a user from a different AAD tenant using Office 365 for Mac.

 

Figure 18: Accessing a protected document using a Microsoft Account associated with a mail.com email address in Office 365 on Windows.

 

Figure 19: Accessing a protected document using a Microsoft Account associated with a mail.com email address in Office 365 on Windows.

 

Figure 20: Accessing a protected PDF file using AIP Viewer App on Android.

 

Now you are probably wondering what’s about SharePoint Online, OneDrive and Teams? There is a lot of work is being done to enable different B2B and B2C scenarios for secure information sharing there and it is a subject for its own blog post. So, stay tuned…

 

References:

Configuring usage rights for Azure Information Protection

Applications that support Azure Rights Management data protection

Message Encryption

Revoke email encrypted by Advanced Message Encryption

Automatically encrypt PDF documents with Exchange Online

Configuring secure document collaboration by using Azure Information Protection

Can Rights Management prevent screen captures?

Sharing encrypted documents with external users

RMS for individuals and Azure Information Protection

Which PDF readers are supported for protected PDFs?

Update history for Microsoft 365 Apps

Known issues with sensitivity labels in Office

Sharing external doc types across tenants

 

 

P.S. Consider joining our Yammer community where you can be one of the first to learn about MIP news, announcements, preview programs, meet information protection experts from around the world, and get your questions answered.