Microsoft 365 includes tools to classify and discover unstructured data, including Microsoft Information Protection (MIP) sensitivity labels. Applying sensitivity labels, either manually or automatically, provides context to end users and IT about what type of data is in a file. As you gain visibility into your data, a natural next question is how to protect that data based on factors such as sensitivity and risk. Answering these questions is an important component of a zero-trust security strategy. Microsoft 365 provides controls to do this. Through a combination of MIP sensitivity labels, Entra (formerly Azure Active Directory) Conditional Access, and Microsoft Cloud App Security (MCAS), you can make access decisions based on the type of data being accessed, rather than solely based on who is accessing the data or what application the data is stored in.
Adding Authentication Context to Conditional Access
Traditionally, Entra conditional access policies have operated at the application level. If your policy requires multi-factor authentication (MFA) or a trusted device, that requirement has applied to all access to the application. Many applications have data that has a wide-ranging impact. For example, this week’s cafeteria menu in SharePoint has vastly different sensitivity than proprietary intellectual property about your product or service. With the varying sensitivity or impact of information, your security controls need to adapt accordingly.
To help this problem, conditional access has evolved to include a feature called authentication context. Authentication context is a framework that applications can use to tell Entra ID about an action a user is taking and where they are taking it. Based on this data, Entra ID can apply a conditional access policy even though the user has already authenticated to the application. You might have an authentication context that simply requires MFA and a second one that requires the user to come from a trusted device. External access to the cafeteria menu simply requires MFA, but access to proprietary information also requires the user to be using a trusted device.
Applying Authentication Context to Data
The authentication contexts that an application can use are published via the Graph API. Applications can use one of the available authentication contexts to indicate to Entra ID when a user takes an action that is controlled by an authentication context through standard OAuth protocol flows. This extensibility is great for custom or third-party applications, but what about Microsoft 365? Authentication contexts are integrated with MIP sensitivity labels and MCAS. You can apply a sensitivity label to an Office 365 group that carries down to the corresponding Teams and SharePoint experiences.
MIP sensitivity labels are more than just a label for data. They can also be used to label what Microsoft calls containers. Containers are Microsoft 365 groups, Teams, and SharePoint sites. When you apply a label to the container (as opposed to an individual file), you are also able to apply and enforce metadata about access to the container, such as the attachment of an authentication context.
By attaching an authentication context to a container, as Figure 1 shows, you’re telling Office 365 that it needs to check in with Entra ID when a user accesses data and apply any additional conditional access policies that might pertain to this context. This is how, for example, you can differentiate access to controls for the cafeteria menu and proprietary information in SharePoint Online.
Beyond Microsoft 365 with Cloud App Security
MCAS takes the power of authentication contexts beyond containers you can label with sensitivity labels. With MCAS, you can apply an authentication context using session policies. Any session that is proxied through Conditional Access App Control (CAAC) can be managed with a session policy. This lets you use authentication context with virtually any SaaS application—such as Salesforce or Workday—or an on-premises application published with the Entra Application Proxy.
This capability is especially powerful when you combine it with the MCAS ability to inspect data in real time and make decisions based on content. For example, although an employee accessing their paystub in Workday isn’t a high-risk operation, a manager downloading a report about their organization that contains dozens or hundreds of elements of personally identifiable information (PII) is. To use conditional access alone, Workday is one application that requires a one-size-fits-all approach. With an MCAS session policy that injects authentication context, we can make real-time decisions based on individual file downloads.
In the example in Figure 2, MCAS will search file downloads for U.S. Social Security Numbers or Canadian Social Insurance Numbers. If MCAS finds at least two of either in the file, it will inject an authentication context called Require MFA and Hybrid Joined Device. When this happens, the user will be redirected to Entra ID to ensure their authentication passes a conditional access policy attached to this context. Assuming the user passes, they will be allowed to download the file. If not, their download will be blocked.
Zero Trust and Your Data
Making decisions about the specific data being accessed is an important component of zero trust. With Entra ID authentication contexts, MIP sensitivity labels, and MCAS session policies, you can do exactly this whether you are governing data in Microsoft 365, a SaaS application, or a traditional on-premises application. If these tools aren’t yet part of your toolkit, we can help advance your data protection and governance. Contact the experts at Ravenswood Technology Group today.
