Hola a todos!
A principios de este año, se presentaron las nuevas políticas de Microsoft Purview DevOps. Esto traía una experiencia simple basada en la nube para proporcionar acceso a escala para las operaciones de TI y el personal de auditoría de seguridad.
Tras esto ya ha llegado el momento de tener disponibilidad para todo el público para esta capacidad.
Los datos son el núcleo de cualquier proceso moderno.
Para continuar operando, las organizaciones deben asegurar la integridad y alta disponibilidad de sus bases de datos.
Al mismo tiempo, la información crítica de IP, clientes y empleados debe protegerse asegurando una visibilidad adecuada y preservando la privacidad del usuario.
A medida que los requisitos se vuelven más desafiantes, se necesitan nuevas soluciones.
Las políticas de Microsoft Purview DevOps estructuran el proceso de concesión y revocación del acceso a las vistas de metadatos del sistema, como DMV y DMF.
Estas son consultas SQL que devuelven información sobre los objetos del modelo, el rendimiento del servidor y la base de datos, así como el estado del servidor.
Las políticas de DevOps brindan al personal de operaciones de TI y a otros usuarios de DevOps acceso a la información que necesitan para mantener las bases de datos en funcionamiento y seguras.
El acceso se proporciona desde el portal de Microsoft Purview, reemplazando la necesidad de que los administradores con cuentas privilegiadas configuren ese acceso localmente, es decir, en cada SQL Server.
Limitar el uso de cuentas privilegiadas es clave para reducir la amenaza interna, posiblemente una de las amenazas de seguridad actuales más desafiantes.
Dado que el acceso se otorga de forma centralizada, los auditores pueden revisarlo fácilmente.
El acceso que ya no se necesita se puede identificar y eliminar fácilmente.
Las políticas de DevOps siguen el Principio de Mínimo Privilegio (PoLP), que en esencia significa «otorgar a los usuarios el acceso mínimo requerido para realizar su trabajo».
Las políticas de DevOps se han estructurado en función de un par de personas típicas de TI: el «Monitor de rendimiento de SQL» y el «Auditor de seguridad de SQL».
El primero se ocupa de la supervisión del estado del sistema para garantizar la integridad de la base de datos y la alta disponibilidad, es decir, el «estado de rendimiento del servidor/base de datos».
El segundo se ocupa de revisar el «estado de seguridad del servidor/base de datos», que incluye vistas sobre permisos, principales, puntos finales, tokens, claves de cifrado de base de datos y reglas de firewall.
La capacidad de las políticas de DevOps asigna estos dos roles a un conjunto mínimo de permisos necesarios para ejecutar estas funciones de TI.
Ninguno de estos dos roles obtiene acceso a los datos del usuario.
Más allá de los beneficios de seguridad descritos anteriormente, las políticas de DevOps:
- Reduzca el esfuerzo necesario para crear inicios de sesión y otorgar o revocar varios permisos de SQL.
- Se requiere menos experiencia sin comprometer la seguridad.
- Las políticas de DevOps ayudan a reducir la posibilidad de errores, ya que los humanos pueden pasar por alto los permisos necesarios o agregar otros que no son necesarios.
- Admite políticas en suscripciones y grupos de recursos completos, lo que significa que todos los servidores SQL dentro de ese grupo de recursos o suscripción pueden aplicarlas de manera uniforme.
- Además, los nuevos servidores lógicos agregados al grupo de recursos o la suscripción comienzan a aplicar la política.
- Las políticas de DevOps admiten grupos de Azure AD. Si un operador de TI deja su trabajo y se vuelve a llenar, el grupo de Azure AD debe actualizarse, pero no se necesitan actualizaciones para los servidores SQL o las políticas de Microsoft Purview.
Actualmente, las políticas de DevOps son compatibles con SQL Server (GA) habilitado para Arc y Azure SQL Database (versión preliminar pública).
Aquí dejamos un video con una demo.
Y el enlace a la documentación.
Y el artículo original.
Espero que os resulte útil.
Un saludo