Over the last couple of years, customers have continued to migrate their on-premises resources to the cloud. The ongoing need to protect the sensitive data that lives in those resources is more important than ever. By using SaaS protection solutions such as Microsoft Defender for Cloud Apps, customers can build and configure policies to protect critical collaboration applications such as SharePoint Online, OneDrive, Box, etc.
A frequent question our customers ask is, “How do I selectively enforce controls on my sensitive SharePoint sites while allowing end users to be productive?” The purpose of this blog is to discuss how to harden sensitive SharePoint sites using a capability in Defender for Cloud Apps called Conditional Access App Control. This feature allows customers to protect content in motion by blocking downloads of files containing sensitive content, blocking copy/paste, and blocking upload. When combined with other Microsoft services, customers can protect and harden their sensitive SharePoint sites without the need to proxy all SharePoint traffic.
This solution uses a combination of different integrations across Azure AD, Purview, SharePoint Online and Defender for Cloud Apps using Authentication Context. There are some known limitations and licensing requirements so please review before getting started.
We will walk through the configuration of AAD, Purview, SharePoint Online and MDA to block downloads of a file that has sensitive content. This will also provide an example of how you can configure it in your own environment.
Tip: Customers should test and configure as a proof of concept to validate the use case before applying to their production tenant.
We start by creating a “sensitive” SharePoint Team site and then navigate to dlptest.com to generate a sample spreadsheet with fake names and US Social Security numbers. We will upload the test files to the document library, this will be used to test and confirm the solution is working as expected later in the process. To learn how to create a site, reference the document: here.
AAD is the first location which needs to be configured and there are 3 steps. This includes making sure MIP labels are enabled, creating an authentication context, and then bringing it all together with a conditional access policy.
The guide below provides details on how to accomplish this using PowerShell and the Azure AD preview module. Once complete, this change will light up the Groups & Sites label configuration in the Purview portal which is required to configure the label.
The next step is to create an authentication context which will be assigned via a label. Open the Azure portal. Open the Azure AD blade and Navigate to Security > Conditional Access > Authentication context (preview) then click + to create a new authentication context. Provide a name and description then save it, make sure to take note of the name it can be bound to the label in the Purview configuration.
The last step for AAD is to create a new conditional access policy which is triggered based on authentication context.
While testing keep the user scope as narrow as possible to validate and then expand as needed, you can do this by assigning only a single test user to the policy.
4. Since we know the site will contain sensitive content, we want to apply protection in a few different layers. Identity has become the new security perimeter so we will use the CA policy to require MFA for access. From Access controls select grant access and check the box to Require multifactor authentication. This step is optional but provides an additional layer of security and is an example of how authentication context can be used for granular policy application.
5. Click the last selection for Session and check the box to Use Conditional Access App Control and change the drop down to Use custom policy…. This configuration option will tell Azure AD to hand the session to MDA proxy once authentication has been completed. Once again where this is a sensitive site, we will utilize the sign-in frequency option and force reauthentication to the site every 4 hours. This is also optional and not required for MDA but does provide another layer of protection.
6. After you have finished here go ahead and save the policy and make sure it’s enabled.
The label configuration in Purview is 2 steps and it’s important to know that it can take some time for these changes to propagate through the infrastructure so make sure to allow up to 24 hours.
The first step is to configure the label settings and associate with an authentication context and then publish the label to a user so it can be bound to a SharePoint site later.
In this scenario, we will create a different label specifically for sites and groups. However, we strongly recommend you look over the documentation to understand label ordering and how it could impact your environment before proceeding. More information about policy ordering can be found here. If you have a site that already has a container label, you can edit the existing label to include the authentication context.
Once the label has been created the last step is to publish it. This option makes it visible to the administrator so it can be selected in the SharePoint admin console.
Once conditional access has handled authentication it will hand the session to MDA to find a matching policy, so we need to create a session policy.
There are a few different methods for associating a SharePoint site with an authentication context.
One option is assigning a particular SharePoint site a container label, which is associated with the authentication context. Labels provide a scalable mechanism for configuring sites, they also have the added benefit of being able to assign other controls which we spoke about briefly above. Additionally, you can also choose to have these applied by default or select a label when creating a new site
If you are not using labels, it’s also possible to assign an authentication context directly to a site using PowerShell and Set-SPOSite.
Tip: please allow 24 hours for this to populate and make sure the user accessing SPO to change this setting has the label published to them.
Lastly, to validate the scenario we’ll navigate back to the Sensitive SharePoint site then check to ensure that the Conditional Access policy was applied. This can be validated from the AAD sign in logs and you can confirm the login matched the authentication context we configured previously from the activity details on the sign in. If you do not see the policy apply immediately try to clear the browser cache or test using an InPrivate/incognito session.
Once authentication is passed, we will attempt to download the file from the Sensitive SharePoint and will be presented with the block message as it contains sensitive content.
Authentication context is a great tool to provide more granularity to your policies.
That’s it for today everybody! Let us know what you think in the comments or head over to the Microsoft Defender for Cloud Apps - Microsoft Tech Community discussion if you have other MDA related questions.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.