Feedback Edit

Access provisioning by data owner to Azure Storage datasets (Preview)

  • Article
  • 8 minutes to read

Important

This feature is currently in PREVIEW. The Supplemental Terms of Use for Microsoft Azure Previews include additional legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

Access policies allow you to manage access from Microsoft Purview to data sources that have been registered for Data Use Management.

This article describes how a data owner can delegate in Microsoft Purview management of access to Azure Storage datasets. Currently, these two Azure Storage sources are supported:

  • Blob storage
  • Azure Data Lake Storage (ADLS) Gen2

Prerequisites

Enable access policy enforcement for the Azure Storage account

To enable Microsoft Purview to manage policies for one or more Azure Storage accounts, execute the following PowerShell commands in the subscription where you'll deploy your Azure Storage account. These PowerShell commands will enable Microsoft Purview to manage policies on all newly created Azure Storage accounts in that subscription.

If you’re executing these commands locally, be sure to run PowerShell as an administrator. Alternatively, you can use the Azure Cloud Shell in the Azure portal: https://shell.azure.com.

# Install the Az module
Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force
# Login into the subscription
Connect-AzAccount -Subscription <SubscriptionID>
# Register the feature
Register-AzProviderFeature -FeatureName AllowPurviewPolicyEnforcement -ProviderNamespace Microsoft.Storage

If the output of the last command shows RegistrationState as Registered, then your subscription is enabled for access policies. If the output is Registering, wait at least 10 minutes, and then retry the command. Do not continue unless the RegistrationState shows as Registered.

Important

The access policy feature is only available on new Azure Storage accounts. Storage accounts must meet the following requirements to enforce access policies published from Microsoft Purview.

  • Storage account versions >= 81.x.x.
  • Created in the subscription after the feature AllowPurviewPolicyEnforcement is Registered.

Create a new Azure Storage account

After you’ve enabled the access policy above, create new Azure Storage account(s) in one of the regions listed below. You can follow this guide to create one.

Currently, Microsoft Purview access policies can only be enforced in the following Azure Storage regions:

  • East US
  • East US2
  • South Central US
  • West US
  • West US2
  • West US3
  • West Central US
  • Canada Central
  • Brazil South
  • North Europe
  • West Europe
  • France Central
  • UK South
  • Central India
  • East Asia
  • Southeast Asia
  • Japan East
  • Japan West
  • Australia East

Configuration

Register Microsoft Purview as a resource provider in other subscriptions

Execute this step only if the data sources and the Microsoft Purview account are in different subscriptions. Register Microsoft Purview as a resource provider in each subscription where data sources reside by following this guide: Register resource provider.

The Microsoft Purview resource provider is:

Microsoft.Purview

Configure permissions for policy management actions

This section discusses the permissions needed to:

  • Make a data resource available for Data Use Management. This step is needed before a policy can be created in Microsoft Purview for that resource.
  • Author and publish policies in Microsoft Purview.

Important

Currently, Microsoft Purview roles related to policy operations must be configured at root collection level.

Permissions to make a data resource available for Data Use Management

To enable the Data Use Management (DUM) toggle for a data source, resource group, or subscription, the same user needs to have both certain IAM privileges on the resource and certain Microsoft Purview privileges.

  1. User needs to have either one of the following IAM role combinations on the resource's ARM path or any parent of it (using inheritance).

    • IAM Owner
    • Both IAM Contributor + IAM User Access Administrator

    Follow this guide to configure Azure RBAC role permissions. The following screenshot shows how to access the Access Control section in Azure portal experience for the data resource to add a role assignment:

Screenshot shows how to access Access Control in Azure Portal to add a role assignment

  1. In addition, the same user needs to have Microsoft Purview Data source administrator (DSA) role at the root collection level. See the guide on managing Microsoft Purview role assignments. The following screenshot shows how to assign Data Source Admin at root collection level:

Screenshot shows how to assign Data Source Admin at root collection level

Permissions for policy authoring and publishing

The following permissions are needed in Microsoft Purview at the root collection level:

  • Policy authors role can create or edit policies.
  • Data source administrator role can publish a policy.

Check the section on managing Microsoft Purview role assignments in this guide.

Note

Known issues related to permissions

  • In addition to Microsoft Purview Policy authors role, user may need Directory Reader permission in Azure Active Directory to create data owner policy. This is a common permission for users in an Azure tenant. You can check permissions for Azure AD Directory Reader

Delegation of access control responsibility to Microsoft Purview

Warning

  • IAM Owner role for a data source can be inherited from parent resource group, subscription or subscription Management Group.
  • Once a resource has been enabled for Data Use Management, any Microsoft Purview root-collection policy author will be able to create access policies against it, and any Microsoft Purview root-collection Data source admin will be able to publish those policies at any point afterwards.
  • Any Microsoft Purview root Collection admin can assign new root-collection Data Source Admin and Policy author roles.
  • If the Microsoft Purview account is deleted then any published policies will stop being enforced within an amount of time that is dependent on the specific data source. This can have implications both on security and data access availability.

With these warnings in mind, here are some suggested best practices for permissions:

  • Minimize the number of people that hold Microsoft Purview root Collection admin, root Data Source Admin or root Policy author roles.
  • To ensure check and balances, assign the Microsoft Purview Policy author and Data source admin roles to different people in the organization. With this, before a data policy takes effect, a second person (the Data source admin) must review it and explicitly approve it by publishing it.
  • A Microsoft Purview account can be deleted by Contributor and Owner roles in IAM. You can check these permissions by navigating to the Access control (IAM) section for your Microsoft Purview account and selecting Role Assignments. You can also place a lock to prevent the Microsoft Purview account from being deleted through ARM locks.

Register the data sources in Microsoft Purview for Data Use Management

The Azure Storage resources need to be registered first with Microsoft Purview to later define access policies.

To register your resources, follow the Prerequisites and Register sections of these guides:

After you've registered your resources, you'll need to enable Data Use Management. Data Use Management needs certain permissions and can affect the security of your data, as it delegates to certain Microsoft Purview roles to manage access to the data sources. Go through the secure practices related to Data Use Management in this guide: How to enable Data Use Management

Once your data source has the Data Use Management toggle Enabled, it will look like this picture:

Screenshot that shows how to register a data source for policy by toggling the enable tab in the resource editor.

Create and publish a data owner policy

Execute the steps in the Create a new policy and Publish a policy sections of the data-owner policy authoring tutorial. The result will be a data owner policy similar to the example shown in the image: a policy that provides group Contoso Team read access to Storage account marketinglake1:

Screenshot that shows a sample data owner policy giving access to an Azure Storage account.

Important

  • Publish is a background operation. Azure Storage accounts can take up to 2 hours to reflect the changes.

Data Consumption

  • Data consumer can access the requested dataset using tools such as PowerBI or Azure Synapse Analytics workspace.
  • Sub-container access: Policy statements set below container level on a Storage account are supported. However, users will not be able to browse to the data asset using Azure Portal's Storage Browser or Microsoft Azure Storage Explorer tool if access is granted only at file or folder level of the Azure Storage account. This is because these apps attempt to crawl down the hierarchy starting at container level, and the request fails because no access has been granted at that level. Instead, the App that requests the data must execute a direct access by providing a fully qualified name to the data object. The following documents show examples of how to perform a direct access. See also the blogs in the Next steps section of this how-to-guide.

Additional information

  • Creating a policy at Storage account level will enable the Subjects to access system containers, for example $logs. If this is undesired, first scan the data source(s) and then create finer-grained policies for each (that is, at container or subcontainer level).
  • The root blob in a container will be accessible to the Azure AD principals in a Microsoft Purview allow-type RBAC policy if the scope of such policy is either subscription, resource group, Storage account or container in Storage account.
  • The root container in a Storage account will be accessible to the Azure AD principals in a Microsoft Purview allow-type RBAC policy if the scope of such policy is either subscription, resource group, or Storage account.

Limits

  • The limit for Microsoft Purview policies that can be enforced by Storage accounts is 100 MB per subscription, which roughly equates to 5000 policies.

Known issues

Known issues related to Policy creation

  • Do not create policy statements based on Microsoft Purview resource sets. Even if displayed in Microsoft Purview policy authoring UI, they are not yet enforced. Learn more about resource sets.

Policy action mapping

This section contains a reference of how actions in Microsoft Purview data policies map to specific actions in Azure Storage.

Microsoft Purview policy action Data source specific actions
Read Microsoft.Storage/storageAccounts/blobServices/containers/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Modify Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
Microsoft.Storage/storageAccounts/blobServices/containers/read
Microsoft.Storage/storageAccounts/blobServices/containers/write
Microsoft.Storage/storageAccounts/blobServices/containers/delete

Next steps

Check blog, demo and related tutorials: