This article is contributed. See the original author and article here.

Earlier this week, we kicked off the “March Ahead with Azure Purview” blog series that will be focused on helping you get the most out of your Azure Purview implementation. ICYMI, the first blog post was on Azure Purview support of the Apache Atlas APIs and how you could use this to unify all your data. Leave a comment on what other topics you would like us to cover. 


 


Let’s get started. I want to go through the important topic of access management within Azure Purview today. Depending on your org structure, this can be complex or simple to set up on your own. Here’s how I intend to take you through this topic:


 



  • Overview of Azure roles in control plane and data plane to deploy and manage Azure Purview.

  • What roles and tasks are required in Azure control plane (in Azure Portal) to deploy an Azure Purview Account and prerequisites to be able to scan data sources later in Purview.

  • Required Access Permissions to scan data in Azure Purview.


 


Azure operations can be divided into two categories: control plane and data plane:


 



  1. You can use the control plane to manage resources in your subscription. For Azure Purview, you need to perform some operations at control plane such as deploying an Azure Purview Account or creating secrets in an Azure Key Vault resource.


         The common dashboard for control plane is Azure Portal.


 


         In this post I am going to explain tasks you need to perform in control plane in order to deploy an Azure Purview Account and setup required access.


 



  1. You can use the data plane to use capabilities exposed by your instance of a resource type, for example reading data inside an Azure Storage Account or managing data assets inside a Purview Account.


         The common tool to manage Azure Purview through data plane is Azure Purview Studio.


 


         Review my next blog post to read about Azure Purview roles in data plane!


 


Azure RBAC helps you manage roles and access for both control plane and data plane for Azure Purview. Azure Purview has also built-in roles which are part of Azure Built-in Roles. Assigning roles in Azure Purview can be done in Azure Resource Manager.  It is recommended to use the least privilege model with absolute minimum permissions necessary to complete the task.


 


What roles do you need to deploy Azure Purview and perform initial setups?


 


Register required Resource Providers inside your Azure Subscription.


What roles can perform this task?


Owner at Subscription or Management Group level or /register/action operation for the resource provider in your subscription.


 


Why do you need this?


In the subscription you are planning to deploy an Azure Purview Account, prior to the deployment, the following Resource Providers must be registered:


 



  • Microsoft.Purview

  • Microsoft.Storage

  • Microsoft.EventHub


 


Create an Azure Purview Account inside your Azure Subscription.


What roles can perform this task?


Owner or Contributor in Management Group, Subscription or resource group


 


Why do you need this?


Azure Purview is an Azure resource; therefore, you would need to deploy an Azure Purview Account inside your Subscription in Azure. You can use Azure Portal to perform this operation.


 


Picture1.png



 


As soon as Azure Purview Account is created, a system Managed Identity is created automatically in Azure AD tenant. Use PowerShell command to validate whether the MSI is created:


 


Get-AzADServicePrincipal -DisplayName PurviewCatalog


(Use your own Azure Purview account name instead of PurviewCatalog).


 


 

Picture2.png



 


Setup source authentication in Azure Purview


What roles can perform this task?


Depending on data source type and required authentication method, you may need to work with different teams in your organization such as database owners and Infrastructure admins.


 


Why do you need this?


To scan data sources, Azure Purview requires access registered data sources. This is done by using a Credential. to A credential is an authentication information that Azure Purview can use to authenticate to your registered data sources.


 


There are few options to setup the credentials for Azure Purview:


 



  • Option 1: Managed Identity

  • Option 2: Key Vault Secret

  • Option 3: Service Principal


 


 


Option 1: Use Managed Identity


Configure required role assignment for your Azure Purview Managed Identity. When you create an Azure Purview account a system Managed Identity is created for your Azure Purview Account in your Azure AD tenant. Depending on type of resource, specific RBAC role assignments are required for the Azure Purview MSI to perform the scans.


 


The higher scope you assign the role to Azure Purview MSI, the less administrative task is required when new data sources are added to your subscriptions.


 


If you use this option: Assign Azure Purview Account’s MSI with required RBAC assignment at Data Sources.


 

Picture3.png



 


Note: If you have multiple data sources, for supported sources you can assign the role at higher level (for example at Subscription level) to reduce management overhead)


 


 


Option 2: Use Key Vault


To setup a credential for supported data sources, you can create Secrets inside an Azure Key Vault to store credentials so Azure Purview can reach your data sources securely using the secrets. A Secret can be a storage account key, SQL login password or a password.


 


If you use this option: You need to deploy an Azure Key Vault resource in your subscription and assign Azure Purview Account’s MSI with required access permission to Secrets inside Azure Key Vault.


 


Picture4.png



 

 


Option 3: Use Service Principals


In this method you can create a new or use an existing service principal in your Azure Active Directory tenant. If you need to create a new service principal, it is required to register an application in your Azure AD tenant and provide access to Service Principal in your data sources. Your Azure AD Global Administrator or other roles such as Application Administrator can perform this operation.


 


In summary, currently Azure Purview supports the following authentication methods for data sources:


 






















































































Data Source



Minimum Required Access Level



Supported Authentication Methods



Azure (Multiple sources)


 


·         Azure Blob Storage


·         Azure Data Lake Storage Gen1


·         Azure Data Lake Storage Gen2


·         Azure SQL Database


·         Azure SQL Database Managed Instance


·         Azure Synapse Analytics



As stated below for each data source



·         Managed Identity


·         Service Principal



Azure Blob Storage



Storage Blob Data Reader



·         Managed Identity (Recommended method)


·         Storage Account Key (Azure Storage Account key saved in Azure Key Vault as Secret)


·         Service Principal



Azure Data Lake Gen 1



Read


Execute



·         Managed Identity (Recommended method)


·         Service Principal



Azure Data Lake Gen 2



Storage Blob Data Reader



·         Managed Identity (Recommended Method)


·         Storage Account Key (key saved in Azure Key Vault)


·         Service Principal



Azure SQL Database



db_datareader


 



·         SQL authentication (SQL login password saved in Azure Key Vault)


·         Managed Identity


·         Service Principal



Azure SQL Database Managed Instance



db_datareader



·         SQL authentication (SQL login password saved in Azure Key Vault)


·         Managed Identity


·         Service Principal



Azure Cosmos DB



 N/A



·         Account Key (Cosmos DB Read-only key saved in Azure Key Vault)



Azure Data Explorer



AllDatabasesViewer



·         Service Principal



Azure Synapse Analytics



db_owner



·         Managed Identity (Recommended method)


·         SQL authentication (SQL login password saved in Azure Key Vault)


·         Service Principal



On-premises SQL Server



db_datareader



·         SQL authentication (SQL login password saved in Azure Key Vault)



Power BI tenant – Portal



read-only Power BI admin APIs



·         Managed Identity



Amazon S3



AmazonS3ReadOnlyAccess



·         AWS ARN, bucket name, and AWS account ID.



SAP ECC / S/4HANA



User account with


·         STFC_CONNECTION (check connectivity)


·         RFC_SYSTEM_INFO (check system information)



·         Basic authentication (username with a password stored in Azure Key Vault)



Teradata



Read access to Teradata source



·         Basic authentication (username with a password stored in Azure Key Vault)



Oracle



Full Sys Admin



·         Basic authentication (username with a password stored in Azure Key Vault)



 


Assign Azure Purview Roles to Data and Security team


What roles can perform this task?


Owner at Management Group, Subscription, Resource Group or Purview resource


 


Why do you need this?


Assign RBAC roles to your Data and Security teams across the organization so they can manage and use Azure Purview as data governance solution.


 


You can assign roles based on different data and security personas in your organization. For example, some roles such as Data Engineers may need to setup configuration in Azure Purview, meanwhile other roles such as Data Stewards and Data Officers need to search Data Catalog or review Insights Reports. I will explain what roles exist in Azure Purview and highlight some of the differences of these roles in my next blog.


 


It is recommended to evaluate what access level each team needs and always assign roles based on least privilege model. 


 


 

Picture5.png



 


Note: Currently Role assignment for a role with dataActions are not supported at Management Group level at this moment. If you need to assign roles at higher level, create the Azure Purview role assignments at the subscription scope instead.


 


Summary and next steps:


We discovered what roles and tasks are required to deploy an Azure Purview Account and setup credentials to scan data sources.



  1. Get started now and create your Azure Purview account!

  2. Define roles and responsibilities at control plan to deploy Azure Purview Account. Learn more about Azure RBAC Roles.

  3. We would love you hear your feedback and know how Azure Purview helped your organization Please provide us your feedback.


In my next blog I will explain Azure Purview roles to manage Azure Purview in data plane!

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.

%d bloggers like this: