¿Qué puedo lograr con las directivas de DevOps de Microsoft Purview?

En este artículo se describe cómo administrar el acceso a orígenes de datos en el patrimonio de datos mediante el portal de gobernanza de Microsoft Purview. Se centra en los conceptos básicos de las directivas de DevOps. Es decir, proporciona información general sobre las directivas de DevOps que debe conocer antes de seguir otros artículos para obtener los pasos de configuración.

Nota:

Esta funcionalidad es diferente del control de acceso interno en el portal de gobernanza de Microsoft Purview.

El acceso a los metadatos del sistema es fundamental para que el personal de TI y DevOps garantice que los sistemas de base de datos críticos están en buen estado, cumplen las expectativas y son seguros. Puede conceder y revocar ese acceso de forma eficaz y a escala a través de las directivas de Microsoft Purview DevOps.

Cualquier usuario que tenga el rol Autor de directivas en el nivel de colección raíz de Microsoft Purview puede crear, actualizar y eliminar directivas de DevOps. Una vez guardadas las directivas de DevOps, se publican automáticamente.

Directivas de acceso frente a directivas de DevOps

Las directivas de acceso de Microsoft Purview permiten a los clientes administrar el acceso a los sistemas de datos en todo su patrimonio de datos, todo desde una ubicación central en la nube. Puede considerar estas directivas como concesiones de acceso que se pueden crear a través de Microsoft Purview Studio, lo que evita la necesidad de código. Dictan si se debe permitir o denegar una lista de entidades de seguridad de Azure Active Directory (Azure AD), como usuarios y grupos, o se debe denegar un tipo específico de acceso a un origen de datos o a un recurso dentro de él. Microsoft Purview comunica estas directivas a los orígenes de datos, donde se aplican de forma nativa.

Las directivas de DevOps son un tipo especial de directivas de acceso de Microsoft Purview. Conceden acceso a los metadatos del sistema de base de datos en lugar de a los datos de usuario. Simplifican el aprovisionamiento de acceso para las operaciones de TI y el personal de auditoría de seguridad. Las directivas de DevOps solo conceden acceso. No deniegan el acceso.

Elementos de una directiva de DevOps

Tres elementos definen una directiva de DevOps:

• Asunto

  Esta es una lista de usuarios, grupos o entidades de servicio de Azure AD a los que se concede acceso.

• Recurso de datos

  Este es el ámbito donde se aplica la directiva. La ruta de acceso del recurso de datos es la composición del origen de datos del grupo > de recursos de suscripción>.

  Las directivas de DevOps de Microsoft Purview admiten actualmente orígenes de datos de tipo SQL. Puede configurarlos en orígenes de datos individuales y en grupos de recursos y suscripciones completos. Solo puede crear directivas de DevOps después de registrar el recurso de datos en Microsoft Purview con la opción Administración de uso de datos activada.

• Rol

  Un rol se asigna a un conjunto de acciones que la directiva permite en el recurso de datos. Las directivas de DevOps admiten los roles sql Monitor de rendimiento y auditor de seguridad de SQL. Ambos roles proporcionan acceso a los metadatos del sistema SQL y, más específicamente, a las vistas de administración dinámica (DMV) y las funciones de administración dinámica (DMF). Pero el conjunto de DMV y DMF que conceden estos roles es diferente. Más adelante en este artículo se proporcionan algunos ejemplos populares.

  En el artículo Crear, enumerar, actualizar y eliminar directivas de Microsoft Purview DevOps se detalla la definición de roles para cada tipo de origen de datos. Es decir, proporciona una asignación de roles en Microsoft Purview a las acciones permitidas en ese tipo de origen de datos. Por ejemplo, la definición de roles para SQL Monitor de rendimiento y SQL Security Auditor incluye acciones Connect en el nivel de servidor y base de datos en el lado del origen de datos.

En esencia, la directiva de DevOps asigna los permisos relacionados del rol al sujeto y se aplica en el ámbito de la ruta de acceso del recurso de datos.

Aplicación jerárquica de directivas

Se aplica una directiva de DevOps en un recurso de datos en el propio recurso de datos y en todos los recursos secundarios que contiene. Por ejemplo, una directiva de DevOps en una suscripción de Azure se aplica a todos los grupos de recursos, a todos los orígenes de datos habilitados para directivas dentro de cada grupo de recursos y a todas las bases de datos de cada origen de datos.

Escenario de ejemplo para demostrar el concepto y las ventajas

Bob y Alice están involucrados con el proceso de DevOps en su empresa. Deben iniciar sesión en docenas de instancias de SQL Server locales y Azure SQL servidores lógicos para supervisar su rendimiento para que los procesos críticos de DevOps no se interrumpan. Su administrador, Mateo, coloca todos estos orígenes de datos SQL en el grupo de recursos 1. A continuación, crea un grupo de Azure AD e incluye Alice y Bob. A continuación, usa directivas de DevOps de Microsoft Purview (directiva 1 en el diagrama siguiente) para conceder a este grupo de Azure AD acceso al grupo de recursos 1, que hospeda los servidores lógicos.

.

Estas son las ventajas:

• Mateo no tiene que crear inicios de sesión locales en cada servidor.
• Las directivas de Microsoft Purview mejoran la seguridad limitando el acceso con privilegios locales. Admiten el principio de privilegios mínimos. En el escenario, Mateo concede solo el acceso mínimo que Bob y Alice necesitan para realizar la tarea de supervisión del estado y el rendimiento del sistema.
• Cuando se agregan nuevos servidores al grupo de recursos, Mateo no necesita actualizar la directiva en Microsoft Purview para que se aplique en los nuevos servidores.
• Si Alice o Bob abandonan la organización y el trabajo se rellena, Mateo simplemente actualiza el grupo de Azure AD. No tiene que realizar ningún cambio en los servidores ni en las directivas que creó en Microsoft Purview.
• En cualquier momento, Mateo o el auditor de la empresa pueden ver todos los permisos concedidos directamente en Microsoft Purview Studio.

Principio	Ventajas
Simplificar	Las definiciones de roles SQL Monitor de rendimiento y SQL Security Auditor capturan los permisos que las personas típicas de TI y DevOps necesitan para ejecutar su trabajo.
	Hay menos necesidad de experiencia en permisos en cada tipo de origen de datos.
Reducir el esfuerzo	Una interfaz gráfica le permite desplazarse por la jerarquía de objetos de datos rápidamente.
	Microsoft Purview admite directivas en grupos de recursos y suscripciones de Azure completos.
Mejore la seguridad	El acceso se concede de forma centralizada y se puede revisar y revocar fácilmente.
	Hay menos necesidad de que las cuentas con privilegios configuren el acceso directamente en el origen de datos.
	Las directivas de DevOps admiten el principio de privilegios mínimos a través de ámbitos de recursos de datos y definiciones de roles.

API de directivas de DevOps

Muchos clientes sofisticados prefieren interactuar con Microsoft Purview a través de scripts en lugar de a través de la interfaz de usuario. Las directivas de DevOps de Microsoft Purview ahora admiten una API REST que ofrece funcionalidad completa de creación, lectura, actualización y eliminación (CRUD). Esta funcionalidad incluye listas, directivas para sql Monitor de rendimiento y directivas para el auditor de seguridad de SQL. Para obtener más información, consulte la especificación de API.

.

Asignación de DMV y DMF populares

Los metadatos dinámicos de SQL incluyen una lista de más de 700 DMV y DMF. En la tabla siguiente se muestran algunos de los más populares. La tabla asigna las DMV y las DMF a sus definiciones de roles en las directivas de DevOps de Microsoft Purview. También proporciona vínculos a contenido de referencia.

Rol de DevOps	Categoría	DMV o DMF de ejemplo
SQL Monitor de rendimiento	Consulta de parámetros del sistema para comprender el sistema	sys.configurations
		sys.dm_os_sys_info
	Identificación de cuellos de botella de rendimiento	sys.dm_os_wait_stats
	Análisis de consultas en ejecución	sys.dm_exec_query_stats
	Análisis de problemas de bloqueo	sys.dm_tran_locks
		sys.dm_exec_requests
		sys.dm_os_waiting_tasks
	Análisis del uso de memoria	sys.dm_os_memory_clerks
	Análisis del uso y el rendimiento de los archivos	sys.master_files
		sys.dm_io_virtual_file_stats
	Análisis del uso y la fragmentación de índices	sys.indexes
		sys.dm_db_index_usage_stats
		sys.dm_db_index_physical_stats
	Administración de conexiones de usuario activas y tareas internas	sys.dm_exec_sessions
	Obtención de estadísticas de ejecución de procedimientos	sys.dm_exec_procedure_stats
	Use el Almacén de consultas	sys.query_store_plan
		sys.query_store_query
		sys.query_store_query_text
	Obtención del registro de errores (aún no compatible)	sys.sp_readerrorlog
Auditor de seguridad de SQL	Obtener detalles de auditoría	sys.dm_server_audit_status
Sql Monitor de rendimiento y el auditor de seguridad de SQL		sys.dm_audit_actions
		sys.dm_audit_class_type_map

Para obtener más información sobre lo que puede hacer el personal de soporte técnico de TI al concederles acceso a través de los roles de Microsoft Purview, consulte los siguientes recursos:

• SQL Monitor de rendimiento: use Microsoft Purview para proporcionar acceso a escala a los datos de rendimiento en Azure SQL y SQL Server
• Auditor de seguridad de SQL: funciones y vistas de administración dinámica relacionadas con la seguridad

Siguientes pasos

Para empezar a trabajar con las directivas de DevOps, consulte los siguientes recursos:

• Pruebe las directivas de DevOps para Azure SQL Database: Guía de inicio rápido.
• Consulte otros vídeos, blogs y artículos.