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.
Azure Active Directory (AAD) Configuration
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.
Enable MIP labels for AAD
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.
Create Default DirectorySettings
Create an Authentication Context
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.
Create an AAD conditional access policy
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.
- Open the Azure AD blade and Navigate to Security > Conditional Access > New Policy.
- Provide a name and then select a test user or group from users or workload identities.
- From Cloud apps or actions change the drop down to authentication context (preview) then pick the authentication context which was created in the last step.
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.
Purview Configuration
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.
Create a label for groups & sites
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.
- Open a browser and navigate to the Purview portal at compliance.microsoft.com, click Information Protection and then the labels tab. From here click Create a label and provide the requested information on the first screen.
- From Scope select Groups & sites (remember that MIP labels need to be enabled in AAD for this to be available).
- Select External sharing and Conditional Access Settings then click Next
- Check the option to Use Azure AD Conditional Access to protect labeled SharePoint sites and then click choose an existing authentication context and pick the authentication context created previously in AAD. In this case, we will use the label to further harden the site and prevent external sharing by checking the Control external sharing from labeled SharePoint sites and set this only to people within the organization (this is also optional and not required).
- Click next and then finish to complete creation of the label.
Publish the label
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.
- Open a browser and navigate to the Purview portal at compliance.microsoft.com, click Information Protection and then the Label policies tab.
- From here click Publish labels and select the label created in the last step.
- Within Users and groups select the user or group to publish the label to which will make it visible. Click next through the remaining settings to accept the defaults then click submit to publish the label.
Defender for Cloud Apps Configuration (1 step)
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.
Create a session policy
- Navigate to the MDA portal and click control > Policies > Conditional Access > Create policy
- Change the session control type drop down to Control file download (with inspection).
- Configure the filter for the app Microsoft SharePoint Online and select DCS for the content inspection type.
- Under Actions make sure Block is selected and enter a message that will be displayed to the user.
SharePoint Online Configuration
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.
- Navigate to the SharePoint admin portal for your specific instance (ex. https://contoso-admin.sharepoint.com) then click active sites on the left menu.
- Highlight the site you want to mark as sensitive then click edit
- Click the policies tab, then click sensitivity. Once here you can select the label which was created in Purview and then save the changes.
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.
Validation
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.
Thanks!