We are excited to share a new and powerful Data Policy feature in Microsoft Purview. In a nutshell, access to all data sources belonging to a resource group or a subscription can be centrally controlled from Microsoft Purview. This significantly reduces the effort needed compared to the alternative, which is to independently configure access in each data source. Microsoft Purview also provides a single pane of glass that makes it simple to maintain or audit access policies.
This capability is now in Public Preview so you can get started on it today. Currently, access policies are supported only for Blob Storage and ADLS Gen2, but integration with more data sources is in Microsoft Purview’s short-term roadmap. We will quickly go through the scenario, while omitting some configuration steps, but the links to the full tutorials are at the end of this post.
A typical data estate for a company has many different data lakes. These are usually organized in separate subscriptions or resource groups. We will leverage Microsoft Purview’s Data Catalog capability to show a simple data estate for fictitious company Contoso. Now, Contoso is a small company, but very aware that to compete successfully and be profitable, they must leverage cutting-edge technology to reduce effort as much as possible. They have created collections for each function, placing their data lakes under them. They have also registered resource group finance-rg under the Finance collection. This was done for scalability, as they are growing, and want to avoid registering existing and future data lakes individually under this collection (financelake1, financelake2, …).
As can be seen in the image below, finance-rg has been registered with the Data use governance toggle set to enabled, which means that access policies can now be created in Microsoft Purview to cover all data sources that belong to this resource group.
Besides his primary role as HR Manager, Diego is also the de-facto data officer for Contoso, responsible for protecting Contoso’s critical data assets as well as the privacy of employees and customers. Some of these data assets reside in the finance-rg resource group. To perform his secondary role, Diego has been given Azure RBAC Owner role for that resource group, as well as Policy Author and Data source admin roles in Azure Purview. Note, in a bigger company these roles are likely to be performed by different people.
Diego wants to enable only trusted finance analysts to access the finance data lakes. He uses the Data policy features in Microsoft Purview to craft a very simple resource-based access policy:
AllowModify on Data contained in finance-rg to security group Sg-Finance
Diego then publishes this policy, which means that it binds to finance-rg and the underlying data lakes.
Debra is one of the finance analysts that needs to access the finance data lakes to perform her job. Diego asks her to test that she has access after waiting long enough for the policies to propagate and be enforced in the finance data lakes. She signs-in to Azure Portal and navigates to financelake1 under finance-rg. Debra does not have Azure RBAC or Storage ACL access to this data source. She uses the embedded Storage browser to test her access, using authentication method Azure AD User account and successfully lists, and navigates down to the files in this data lake. She is also able to upload new ones.
When Contoso adds financelake2 and financelake3 in the future, Debra will have access to them, without the need for Diego to modify the existing policy or adding additional ones.
This article described how broad access policies can be provisioned from Microsoft Purview. It is easy to get started with these new Data Policy features in Microsoft Purview by going through our documentation.