Microsoft Purview DevOps policies enable at scale access provisioning for IT operations

Microsoft Purview access policies enable customers to manage access to different data systems across their entire data estate, all from a central location in the cloud. These policies are access grants that can be created through Microsoft Purview Studio, avoiding the need for code. They dictate whether a set of AAD principals (users, groups, etc.) should be allowed or denied a specific type of access (e.g., Read, Modify) to a data source or a data asset within it. These policies get communicated to and get natively enforced by the data source.

DevOps policies are a special type of Microsoft Purview access policies. They leverage Microsoft Purview’s understanding of the customer’s data estate to simplify access provisioning for IT operations and security auditing functions. Access to system metadata is crucial for DBAs and other DevOps users to perform their job. That access can be granted and revoked efficiently and at-scale from Microsoft Purview. Microsoft Purview DevOps policies support a couple of permissions for SQL-type data sources: Microsoft Purview DevOps policies can be configured on individual data sources, resource groups and subscriptions. Beyond the UI, they also support an API which can be called from other DevOps tools.

A sample scenario of how this works
Bob and Alice are DevOps users at their company. Given their role, they need to login to dozens of Azure SQL logical servers to monitor their performance so that critical DevOps processes don’t break. Their manager, Mateo, creates an AAD group and includes Alice and Bob. He then uses Microsoft Purview DevOps policies (Policy 1 in the diagram below) to grant this AAD group access to the Resource Group (Resource Group 1) that hosts the Azure SQL servers.

Here are the benefits:

1. Mateo does not have to create local logins in each logical server
2. The policies from Microsoft Purview improve security by helping limit local privileged access. In the scenario, Mateo only grants the minimum access necessary that Bob and Alice need to perform the task of monitoring performance.
3. When new Azure SQL servers are added to the Resource Group, Mateo does not need to update the policies in Microsoft Purview for them to be effective on the new logical servers.
4. If Alice or Bob leave their job and get backfilled, Mateo just updates the AAD group, without having to make any changes to the servers or to the policies he created in Microsoft Purview.
5. At any point in time, Mateo or the company’s auditor can see what access has been granted directly in Microsoft Purview Studio.

Access provisioning for SQL Performance Monitoring and SQL Security Auditing is already supported from Microsoft Purview in public preview. We are now adding a new simplified UX and API for these types of policies. If you are interested in test-driving, you can sign-up for the private preview of this new feature through this link https://forms.office.com/r/fycGz59PU9