Merge pull request #229492 from inward-eye/main

ttorble · web-flow · commit d12460def189 · 2023-03-05T09:25:08.000Z
updates to concept guide
diff --git a/articles/purview/concept-policies-devops.md b/articles/purview/concept-policies-devops.md
@@ -6,50 +6,82 @@ ms.author: vlrodrig
 ms.service: purview
 ms.subservice: purview-data-policies
 ms.topic: conceptual
-ms.date: 11/16/2022
+ms.date: 03/03/2023
 ---
 
-# Concepts for Microsoft Purview DevOps policies
+# What can I accomplish with Microsoft Purview DevOps policies?
 
-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.
+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.
 
 > [!Note]
-> This capability is different from access control for Microsoft Purview itself, which is described in [Access control in Microsoft Purview](./catalog-permissions.md).
+> 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).
 
 ## Overview
-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.
+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.
 
 ### Microsoft Purview access policies vs. DevOps policies
-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.
+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.
 
-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.
+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.
 
 ## Elements of a DevOps policy
-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*.
+A DevOps policy is defined by three elements: The *subject*, the *data resource* and the *role*. In essence, the DevOps policy assigns the *role*'s related permissions to the *subject* and gets enforced in the scope of the *data resource*'s path.
     
 #### The subject
-Is a set of Azure AD users, groups or service principals.
-
-#### The role
-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.
+This is a list of Azure AD users, groups or service principals that are granted access.
 
 #### The data resource
-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.
+This is the scope where the policy gets enforced. The data resource path is the composition of subscription > resource group > data source. Microsoft Purview DevOps policies currently support SQL-type data sources and can be configured on individual data sources, but also entire resource groups and subscriptions. DevOps policies can only be created after the data resource is registered in Microsoft Purview with the option *Data use management* enabled.
+
+#### The role
+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 popular 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.
 
-#### Hierarchical enforcement of policies
+## Hierarchical enforcement of policies
 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.
 
 ## A sample scenario to demonstrate the concept and the benefits
-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.
+Bob and Alice are involved with the DevOps process at their company. Given their role, they need to log in to dozens of SQL servers on-premises and Azure SQL logical servers to monitor their performance so that critical DevOps processes don’t break. Their manager, Mateo, puts all these SQL data sources into Resource Group 1. He then creates an Azure AD group and includes Alice and Bob. Next, he 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.
 
 ![Diagram shows an example of DevOps policy on resource group.](./media/concept-policies-devops/devops-policy-on-resource-group.png).
 
 #### These are the benefits:
-- Mateo doesn't have to create local logins in each logical server
-- 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.
-- 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.
-- 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.
-- At any point in time, Mateo or the company’s auditor can see what access has been granted directly in Microsoft Purview Studio.
+- Mateo doesn't have to create local logins in each SQL server.
+- The policies from Microsoft Purview improve security by limiting local privileged access. They support the Principle of Least Privilege (PoLP). 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.
+- When new 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 SQL servers.
+- If Alice or Bob leaves 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.
+- At any point in time, Mateo or the company’s auditor can see all the permissions that were granted directly in Microsoft Purview Studio.
+
+| **Principle** | **Benefit** |
+|-|-|
+|*Simplify*        |The role definitions SQL Performance Monitor and SQL Security AuditorData capture the permissions that typical IT/DevOps personas need to execute their job.|
+|                  |Reduce the need of permission expertise for each data source type.|
+|||
+|*Reduce effort*   |Graphical interface lets you navigate the data object hierarchy quickly.|
+|                  |Supports policies on entire Azure resource groups and subscriptions.|
+|||
+|*Enhance security*|Access is granted centrally and can be easily reviewed and revoked.|
+|                  |Reduces the need for privileged accounts to configure access directly at the data source.|
+|                  |Supports the Principle of Least Privilege via data resource scopes and the role definitions.|
+|||
+
+## Mapping of popular DMVs/DMFs
+SQL 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, along with their description.
+
+| **Accessible by DevOps role** | **Popular DMV / DMF** | **Description**|
+|-|-|-|
+||||
+| *SQL Performance Monitor* | [sys.dm_exec_requests](/sql/relational-databases/system-dynamic-management-views/sys-dm-exec-requests-transact-sql)|Monitors the current activity and performance of the server|
+||[sys.dm_os_wait_stats](/sql/relational-databases/system-dynamic-management-views/sys-dm-os-wait-stats-transact-sql)|Identifies performance bottlenecks to enable system tuning|
+|| [sys.dm_exec_query_stats](/sql/relational-databases/system-dynamic-management-views/sys-dm-exec-query-stats-transact-sql)|Identifies queries that are consuming a lot of resources or taking a long time to execute|
+|| [sys.dm_exec_sessions](/sql/relational-databases/system-dynamic-management-views/sys-dm-exec-sessions-transact-sql)|Shows information about all active user connections and internal tasks|
+|| [sys.dm_os_waiting_tasks](/sql/relational-databases/system-dynamic-management-views/sys-dm-os-waiting-tasks-transact-sql)|Helps identify and troubleshoot blocking issues within SQL Server|
+|| [sys.dm_exec_procedure_stats](/sql/relational-databases/system-dynamic-management-views/sys-dm-exec-procedure-stats-transact-sql)|Returns how many times a procedure was executed, the total duration, reads, writes and more|
+||||
+| *SQL Security Auditor* |[sys.dm_server_audit_status](/sql/relational-databases/system-dynamic-management-views/sys-dm-server-audit-status-transact-sql)|Returns audit details such as the location of the target, size and status of the audit itself|
+||||
+| Both *SQL Performance Monitor* and *SQL Security Auditor*|[sys.dm_audit_actions](/sql/relational-databases/system-dynamic-management-views/sys-dm-audit-actions-transact-sql)|Returns a row for every audit action that can be reported in the audit log and every audit action group that can be configured as part of SQL Server Audit|
+||[sys.dm_audit_class_type_map](/sql/relational-databases/system-dynamic-management-views/sys-dm-audit-class-type-map-transact-sql)|When events are fired, they record the object type, not the securable class. This DMV maps the class_type field in the audit log to the class_desc field in sys.dm_audit_actions|
+||||
 
 ## More info
 - DevOps policies can be created, updated and deleted by any user holding *Policy Author* role at root collection level in Microsoft Purview.
diff --git a/articles/purview/how-to-policies-devops-arc-sql-server.md b/articles/purview/how-to-policies-devops-arc-sql-server.md
@@ -6,7 +6,7 @@ ms.author: vlrodrig
 ms.service: purview
 ms.subservice: purview-data-policies
 ms.topic: how-to
-ms.date: 02/10/2023
+ms.date: 03/03/2023
 ms.custom:
 ---
 # Provision access to system metadata in Azure Arc-enabled SQL Server 2022
@@ -105,7 +105,7 @@ SELECT * FROM sys.dm_server_external_policy_principal_assigned_actions
 
 This section contains a reference of how actions in Microsoft Purview data policies map to specific actions in Azure Arc-enabled SQL Server.
 
-| **Microsoft Purview policy action** | **Data source specific actions**     |
+| **DevOps role definition** | **Data source specific actions**     |
 |-------------------------------------|--------------------------------------|
 |                                     |                                      |
 | *SQL Performance Monitor* |Microsoft.Sql/sqlservers/Connect |
diff --git a/articles/purview/how-to-policies-devops-azure-sql-db.md b/articles/purview/how-to-policies-devops-azure-sql-db.md
@@ -6,7 +6,7 @@ ms.author: vlrodrig
 ms.service: purview
 ms.subservice: purview-data-policies
 ms.topic: how-to
-ms.date: 02/10/2023
+ms.date: 03/03/2023
 ms.custom:
 ---
 # Provision access to system metadata in Azure SQL Database (preview)
diff --git a/articles/purview/overview.md b/articles/purview/overview.md
@@ -6,7 +6,7 @@ ms.author: whhender
 ms.service: purview
 ms.custom: event-tier1-build-2022
 ms.topic: overview
-ms.date: 11/23/2022
+ms.date: 03/04/2023
 ---
 
 # What's available in the Microsoft Purview governance portal?
@@ -35,9 +35,10 @@ Atop the Data Map, there are purpose-built apps that create environments for dat
 |App  |Description  |
 |----------|-----------|
 |[Data Catalog](#data-catalog-app)  | Finds trusted data sources by browsing and searching your data assets. The data catalog aligns your assets with friendly business terms and data classification to identify data sources.      |
-|[Data Estate Insights](#data-estate-insights-app) | Gives you an overview of your data estate to help you discover what kinds of data you have and where. |
+|[Data Estate Insights](#data-estate-insights-app) | Gives you an overview of your data estate to help you discover what kinds of data you have and where it is. |
 |[Data Sharing](#data-sharing-app) | Allows you to securely share data internally or cross organizations with business partners and customers. |
 |[Data Policy](#data-policy-app) | A set of central, cloud-based experiences that help you provision access to data securely and at scale. |
+|||
 
 ## Data Catalog app
 
@@ -59,18 +60,33 @@ For more information, see our [introduction to Data Sharing](concept-data-share.
 ## Data Policy app
 Microsoft Purview Data Policy is a set of central, cloud-based experiences that help you manage access to data sources and datasets securely and at scale.
 - Manage access to data sources from a single-pane of glass, cloud-based experience
-- At-scale access provisioning
+- Enables at-scale access provisioning
 - Introduces a new data-plane permission model that is external to data sources
-- Seamless integration with Microsoft Purview Data Map and Catalog:
+- It is seamlessly integrated with Microsoft Purview Data Map and Catalog:
     - Search for data assets and grant access only to what is required via fine-grained policies.
-    - Path to support SaaS, on-premises, and multicloud data sources
-    - Path to leverage all associated metadata for policies
+    - Path to support SaaS, on-premises, and multicloud data sources.
+    - Path to create policies that leverage any metadata associated to the data objects.
 - Based on role definitions that are simple and abstracted (for example: Read, Modify)
 
 For more information, see our introductory guides:
 * [Data owner access policies](concept-policies-data-owner.md) (preview): Provision fine-grained to broad access to users and groups via intuitive authoring experience.
 * [Self-service access policies](concept-self-service-data-access-policy.md) (preview): Self-Service: Workflow approval and automatic provisioning of access requests initiated by business analysts that discover data assets in Microsoft Purview’s catalog.
-* [DevOps policies](concept-policies-devops.md): Provision access for IT operations and other DevOps users from Microsoft Purview Studio, enabling them to monitor SQL database system health and security, while limiting insider threat.
+* [DevOps policies](concept-policies-devops.md): Provision IT operations personnel access to SQL system metadata, so that they can monitor performance, health and audit security, while limiting the insider threat.
+
+Here are the benefits of the Data Policy app:
+
+| **Principle** | **Benefit** |
+|-|-|
+|*Simplify*        |Permissions are bundled into role definitions that are abstracted and consistent across data source types, like Read and Modify.|
+|                  |Reduce the need of permission expertise for each data source type.|
+|||
+|*Reduce effort*   |Graphical interface lets you navigate the data object hierarchy quickly.|
+|                  |Supports policies on entire Azure resource groups and subscriptions.|
+|||
+|*Enhance security*|Access is granted centrally and can be easily reviewed and revoked.|
+|                  |Reduces the need for privileged accounts to configure access directly at the data source.|
+|                  |Supports the Principle of Least Privilege via data resource scopes and common role definitions.|
+|||
 
 ## Traditional challenges that Microsoft Purview seeks to address
 
@@ -115,14 +131,7 @@ Discovering and understanding data sources and their use is the primary purpose
 
 At the same time, users can contribute to the catalog by tagging, documenting, and annotating data sources that have already been registered. They can also register new data sources, which are then discovered, understood, and consumed by the community of catalog users.
 
-Lastly, Microsoft Purview Data Policy app applies the metadata in the Data Map, providing a superior solution to keep your data secure.
-* Structure and simplify the process of granting/revoking access.
-* Reduce the effort of access provisioning.
-* Access decision in Microsoft data systems has negligible latency penalty.
-* Enhanced security:
-   - Easier to review access/revoke it in a central vs. distributed access provisioning model.
-   - Reduced need for privileged accounts to configure access.
-   - Support Principle of Least Privilege (give people the appropriate level of access, limiting to the minimum permissions and the least data objects).
+Lastly, Microsoft Purview Data Policy app provides a superior solution to keep your data secure.
 
 ## In-region data residency
 
