Data policy features: resource group-level governance can significantly reduce effort
Published Feb 02 2022 02:54 PM 3,999 Views
Microsoft

We are excited to share a new and powerful Data Policy feature in Azure Purview. In a nutshell, access to all data sources belonging to a resource group or a subscription can be centrally controlled from Azure Purview. This significantly reduces the effort needed compared to the alternative, which is to independently configure access in each data source. Azure 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 Azure 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 Azure 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, …).

 

innereye_0-1643677396169.png

 

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 Azure Purview to cover all data sources that belong to this resource group.

 

innereye_1-1643677423606.png

 

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 Azure Purview to craft a very simple resource-based access policy:

Allow Modify on Data contained in finance-rg to security group Sg-Finance

 

innereye_2-1643677423614.png

 

Diego then publishes this policy, which means that it binds to finance-rg and the underlying data lakes.

 

innereye_3-1643677423624.png

 

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.

 

innereye_4-1643677423636.png

 

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.

 

Get started:

This article described how broad access policies can be provisioned from Azure Purview. It is easy to get started with these new Data Policy features in Azure Purview by going through our documentation.

 

 

 

4 Comments
Version history
Last update:
‎Sep 21 2022 03:25 PM
Updated by: