You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/purview/concept-policies-devops.md
+35-13Lines changed: 35 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,51 +6,73 @@ ms.author: vlrodrig
6
6
ms.service: purview
7
7
ms.subservice: purview-data-policies
8
8
ms.topic: conceptual
9
-
ms.date: 11/16/2022
9
+
ms.date: 03/03/2023
10
10
---
11
11
12
-
# Concepts for Microsoft Purview DevOps policies
12
+
# What can I accomplish with Microsoft Purview DevOps policies?
13
13
14
-
This article discusses concepts related to managing access to data sources in your data estate from within the Microsoft Purview governance portal. In particular, it focuses on DevOps policies.
14
+
This article discusses concepts related to managing access to data sources in your data estate using the Microsoft Purview governance portal. In particular, it focuses on DevOps policies.
15
15
16
16
> [!Note]
17
-
> This capability is different from access control for Microsoft Purview itself, which is described in [Access control in Microsoft Purview](./catalog-permissions.md).
17
+
> This capability is different from the internal access control for Microsoft Purview itself, which is described in [Access control in Microsoft Purview](./catalog-permissions.md).
18
18
19
19
## Overview
20
-
Access to system metadata is crucial for IT operations and other DevOps personnel to perform their job. That access can be granted and revoked efficiently and at-scale through Microsoft Purview DevOps policies.
20
+
Access to system metadata is crucial for IT/DevOps personnel to ensure that critical database systems are healthy, are performing to expectations and are secure. That access can be granted and revoked efficiently and at-scale through Microsoft Purview DevOps policies.
21
21
22
22
### Microsoft Purview access policies vs. DevOps policies
23
-
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 Azure AD principals (users, groups, etc.) should be allowed or denied a specific type of access to a data source or asset within it. These policies get communicated to the data sources where they get natively enforced.
23
+
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. You can think about these policies as access grants that can be created through Microsoft Purview Studio, avoiding the need for code. They dictate whether a list of Azure AD principals (users, groups, etc.) should be allowed or denied a specific type of access to a data source or asset within it. These policies get communicated by Microsoft Purview to the data sources, where they get natively enforced.
24
24
25
-
DevOps policies are a special type of Microsoft Purview access policies. They grant access to database system metadata instead of user data. They simplify access provisioning for IT operations and security auditing functions. DevOps policies only grant access, that is, they don't deny access.
25
+
DevOps policies are a special type of Microsoft Purview access policies. They grant access to database system metadata instead of user data. They simplify access provisioning for IT operations and security auditing personnel. DevOps policies only grant access, that is, they don't deny access.
26
26
27
27
## Elements of a DevOps policy
28
28
A DevOps policy is defined by three elements: The *data resource path*, the *role* and the *subject*. In essence, the DevOps policy assigns the *subject* to the *role* for the scope of the *data resource path*.
29
29
30
30
#### The subject
31
-
Is a set of Azure AD users, groups or service principals.
31
+
This is a list of Azure AD users, groups or service principals.
32
32
33
33
#### The role
34
-
The role maps to a set of actions that the policy permits on the data resource. DevOps policies support a couple of roles: *SQL Performance Monitor* and *SQL Security Auditor*. The DevOps policy how-to docs detail the role definition for each data source, that is, the mapping between the role in Microsoft Purview and the actions that get permitted in the data source. For example, the role definition for SQL Performance Monitor and SQL Security Auditor includes Connect actions at server and database level on the data source side.
34
+
The role maps to a set of actions that the policy permits on the data resource. DevOps policies support a couple of roles: *SQL Performance Monitor* and *SQL Security Auditor*. Both these roles provide access to SQL's system metadata, and more specifically to Dynamic Management Views (DMFs) and Dynamic Management Functions (DMFs). But the set of DMVs/DMFs granted by these roles is different. We provide some examples at the end of this document. Also, the DevOps policies how-to docs detail the role definition for each data source type, that is, the mapping between the role in Microsoft Purview and the actions that get permitted in that type of data source. For example, the role definition for SQL Performance Monitor and SQL Security Auditor includes Connect actions at server and database level on the data source side.
35
35
36
36
#### The data resource
37
-
Microsoft Purview DevOps policies currently support SQL-type data sources and can be configured on individual data sources, resource groups and subscriptions. DevOps policies can only be created if the data source is first registered in Microsoft Purview with the option *Data use management enabled*. The data resource path is the composition of subscription > resource group > data source.
37
+
Microsoft Purview DevOps policies currently support SQL-type data sources and can be configured on individual data sources, resource groups and subscriptions. The data resource path is the composition of subscription > resource group > data source. DevOps policies can only be created after the data resource is registered in Microsoft Purview with the option *Data use management* enabled.
38
38
39
39
#### Hierarchical enforcement of policies
40
40
A DevOps policy on a data resource is enforced on the data resource itself and all children contained by it. For example, a DevOps policy on an Azure subscription applies to all resource groups, to all policy-enabled data sources within each resource group, and to all databases contained within each data source.
41
41
42
42
## A sample scenario to demonstrate the concept and the benefits
43
-
Bob and Alice are DevOps users at their company. Given their role, they need to log in to dozens of Azure SQL logical servers to monitor their performance so that critical DevOps processes don’t break. Their manager, Mateo, creates an Azure AD group and includes Alice and Bob. He then uses Microsoft Purview DevOps policies (Policy 1 in the diagram below) to grant this Azure AD group access at resource group level, to Resource Group 1, which hosts the Azure SQL servers.
43
+
Bob and Alice are involved with the DevOps process at their company. Given their role, they need to log in to dozens of Azure SQL logical servers to monitor their performance so that critical DevOps processes don’t break. Their manager, Mateo, creates an Azure AD group and includes Alice and Bob. He then uses Microsoft Purview DevOps policies (Policy 1 in the diagram below) to grant this Azure AD group access to Resource Group 1, which hosts the Azure SQL servers.
44
44
45
45
.
46
46
47
47
#### These are the benefits:
48
48
- Mateo doesn't have to create local logins in each logical server
49
-
- The policies from Microsoft Purview improve security by helping limit local privileged access. This is what we call PoLP (Principle of Least Privilege). In the scenario, Mateo only grants the minimum access necessary that Bob and Alice need to perform the task of monitoring performance.
50
-
- When new Azure SQL servers are added to the Resource Group, Mateo doesn't need to update the policies in Microsoft Purview for them to be effective on the new logical servers.
49
+
- The policies from Microsoft Purview improve security by helping limit local privileged access. This is what we call PoLP (Principle of Least Privilege). In the scenario, Mateo only grants the minimum access necessary that Bob and Alice need to perform the task of monitoring system health and performance.
50
+
- When new Azure SQL servers are added to the resource group, Mateo doesn't need to update the policy in Microsoft Purview for it to be enforced on the new logical servers.
51
51
- If Alice or Bob leave their job and get backfilled, Mateo just updates the Azure AD group, without having to make any changes to the servers or to the policies he created in Microsoft Purview.
52
52
- At any point in time, Mateo or the company’s auditor can see what access has been granted directly in Microsoft Purview Studio.
53
53
54
+
## Examples of popular DMVs/DMFs
55
+
Dynamic metadata includes a list of more than 700 DMVs/DMFs. We list here as an illustration some of the most popular ones, mapped to their role definition in Microsoft Purview DevOps policies and linked to the URL with their description.
0 commit comments