This week is a continuation of my previous blog post about working with personal Windows devices. That post was focussed on the different options available for providing secure access to corporate data on personal Windows devices. This post is focussed on providing more details around using those different options actually as different layers in a single solution. All with the focus on providing secure access to corporate data on personal Windows devices, while still providing the user with as much flexibility and options to be productive. Besides that, using different layers of data security also enables the IT administrators to add more granularity to the solution. That makes the total solution less black-and-white. So, for example, not just block the ability of the user to copy-and-paste data, but only block that action when it contains specific information. This post will focus on those different layers, and how to configure those layers.
Introducing the different layers of data security
When looking at the different layers of data security on personal Windows devices, the options have been discussed before. And should be known by now. This post will focus on showing how to use those layers together, mainly to provide more granularity. The granularity in this post will focus on differentiating on data and SharePoint site level, followed with a less stringent copy-paste restriction. Only when it actually matters. So, from a high-level perspective, these are the layers that are being used:
- The first layer is based on the app enforced restrictions in Conditional Access, and is mainly focussed on SharePoint data. When using that in combination with labels and label policies that enables the ability to differentiate between data and even between complete SharePoint sites. So, that provides the first layer to initially already differentiate which sites and which data is even accessible on personal (Windows) devices.
- The second layer is based on the app control options in Conditional Access, and is mainly focussed on controlling the data itself. When adding Defender for Cloud Apps to the mix that brings a lot of flexibility to the solution. Both to the apps that can be connected, as well as to the data that can be controlled. So, in this case, that provides the second layer to actually add more granularity for blocking specific actions like copying and pasting specific types of data.
- The third layer is based on the app protection policies in Conditional Access, and is mainly focussed on protecting any data locally on the personal Windows device within the app. When using Windows MAM that enables the ability to protect the data within the app locally on the device, as well as the ability to always wipe the app data remotely. So, that provides the third layer to always have a fallback to remove anything locally related to the corporate data.
Note: It’s also possible to leave out the second layer to simplify the solution, with less granularity.
Configuring the different layers of data security
After being familiar with the different layers of data security, it’s time to have a closer look at the configuration of those layers and how to make sure that those layers are well connected. That of course starts with a company policy around data security and a good story about what users are allowed to do on their personal (Window) devices. So, it’s important to have a mapping of what data requires what type of protection. That should always be the starting point for building the technical solution. In this case, the focus is mainly on showing the different layers in action and how they could be used together.
Configuring the first layer of app enforced restrictions
For the sake of simplicity, let’s start with that there is always data that is isn’t allowed to available on unmanaged devices in any circumstance. That can be easily achieved by using app enforced restrictions. Not just to only allow limited access on unmanaged devices, but even more to differentiate between the classification of the data. For this, it’s the easiest to rely on sensitivity labels. Those label can be attached to the data and to SharePoint sites, and determine the level of access for the user on unmanaged.
That can be achieved by going to the Microsoft Purview portal and navigating to Solutions > Information Protection > Labels. Create a new label and make sure to configure at least External sharing and Conditional Access in the Groups & sites page. That enables the Externals sharing & conditional access page that can be used to configure the actual access to SharePoint sites configured with this specific label (as shown below in Figure 1).
Once the label is created, it must be published with a label policy to make it available for use. Now attach that label to the SharePoint sites that should be limited available, or not available at all. To finalize that configuration, use Conditional Access to actually enforce it. That can be achieved by going to the Microsoft Entra admin center portal and navigating to Protection > Conditional Access. Create a new policy and make sure to configure at least Use app enforced restrictions in the Session access control (as shown below in Figure 2).
Note: Keep in mind that before being able to apply labels to SharePoint site, it must be enabled for containers and synchronized with Entra ID, as documented here.
Configuring the second layer of app control
Next on the list is to keep it as user friendly as possible. So, not just prevent copy-paste actions in general within Microsoft Edge, but only in specific cases when it really matters. That can be achieved by using session policies in Defender for Cloud Apps, to actually control the data in detail. All with the goal to only intervene when it really matters.
That can be achieved by going to the Microsoft Defender portal and navigating to Cloud apps > Policies > Policy management. Create a new session policy, apply the Block cut/copy and paste based on real-time content inspection template and make sure to configure at least Use content inspection, to configure the actual type of text that it will look for to prevent copy-paste actions (as shown below in Figure 3). That makes it much more granular and more user friendly.
To finalize that configuration, use Conditional Access to actually enforce it. That can be achieved by going to the Microsoft Entra admin center portal and navigating to Protection > Conditional Access. Create a new policy and make sure to configure at least Use Use Conditional Access App Control > Use custom policy in the Session access control (as shown below in Figure 4).
Configuring the third layer of app protection policies
Lastly it’s important to stay in control of the data, especially when it’s been available on personal Windows devices. That can be achieved by using app protection policies. Not to prevent specific actions – like copy-paste – in general, but just to make sure that there is always an ability to wipe the data from that personal device. Besides that, Defender for Cloud Apps is already used for preventing copy-paste for specific content. So, the app protection policy must be aligned with that.
That can be achieved by going to the Microsoft Intune admin center portal and navigating to Apps > App protection policies. Create a new policy for Windows and make sure to configure at least Allow, cut, copy, and paste for in the Data protection page, to make sure that the copy-paste actions are aligned with the other configurations (as shown below in Figure 5).
To finalize that configuration, use Conditional Access to actually enforce it. That can be achieved by going to the Microsoft Entra admin center portal and navigating to Protection > Conditional Access. Create a new policy and make sure to configure at least Require app protection policy in the Grant access control (as shown below in Figure 6).
Experiencing the different layers of data security
Experiencing the applied configuration, can also be done in different layers on personal Windows devices. Below in Figure 7 is an overview of the user navigating to a SharePoint site that is labeled with a label that prevents access from unmanaged devices. That is the first layer of data protection, to prevent complete access to specific sites that contains important information and data that is only accessible on fully managed and protected devices. Besides that, the URL in the browser also clearly shows that Defender for Cloud Apps is also part of the data protection flow.
When the user now navigates to a SharePoint site that is accessible on unmanaged devices, the remaining layers can be seen in action. As shown below in Figure 8, the user can now actually access documents that are available. Those documents can be edited in Microsoft Edge that is managed by Microsoft Intune, as shown in the menu of the browser. What makes it even more interesting, is that the copy-paste action is blocked by Defender for Cloud Apps, as shown in the browser. That provides a lot more usability to the user, as not every copy-paste action, within the managed browser, is blocked. Only when it really matters and when specific content is detected (in this case an email address).
More information
For more information about the different layers of data security, refer to the following docs.
- App protection policy settings for Windows – Microsoft Intune | Microsoft Learn
- SharePoint and OneDrive unmanaged device access controls – SharePoint in Microsoft 365 | Microsoft Learn
- Secure email recommended policies – Microsoft Defender for Office 365 | Microsoft Learn
- Deploy conditional access app control for catalog apps with Microsoft Entra ID – Microsoft Defender for Cloud Apps | Microsoft Learn
- Session controls in Conditional Access policy – Microsoft Entra ID | Microsoft Learn
2 thoughts on “Combining the different layers of data security on personal Windows devices”