¿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 Microsoft Entra entidades de seguridad, como usuarios y grupos, 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 Microsoft Entra usuarios, grupos o entidades de servicio 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 Cumplimiento de directivas 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. Luego crea un grupo de Microsoft Entra e incluye a Alice y Bob. A continuación, usa directivas de Microsoft Purview DevOps (directiva 1 en el diagrama siguiente) para conceder a este Microsoft Entra grupo 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 Microsoft Entra. 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
Pasos siguientes
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.