InvGate Asset Management ahora gobierna las bases de datos como activos. Descubre instancias en cinco motores, marca las que usan versiones que su proveedor ya no soporta, mapea lo que depende de ellas y registra evidencia antes de que se guarde un cambio crítico en el registro de una base de datos.
En la mayoría de las organizaciones, las bases de datos quedaron fuera del registro de activos: las administra quien sea su responsable y se redescubren durante una auditoría. A continuación se explica qué descubre InvGate Asset Management, cómo aparecen el estado de soporte y las dependencias en ese registro, y qué deja asentado el paso de evidencia cuando algo cambia.
Qué descubre InvGate Asset Management
El descubrimiento se hace desde el Agent que ya está instalado en el host, que detecta los servicios de bases de datos que corren ahí e informa qué es cada instancia y cómo está configurada. La forma de conexión varía según el motor: PostgreSQL y SQL Server se configuran como Discovery Sources, mientras que MySQL, Oracle y MariaDB se relevan sin necesidad de credenciales de base de datos. Cada instancia descubierta se registra como un elemento de configuración (CI) con:
- Motor y versión.
- Dirección IP y puerto.
- Tiempo de actividad y arquitectura.
- El servidor host en el que corre.
- Las bases de datos que aloja.
Los registros se actualizan con el ciclo de inventario habitual del Agent, así las instancias aparecen, se mueven y desaparecen del inventario sin que nadie tenga que cargarlas a mano. Un equipo de IT del sector salud que ejecuta el descubrimiento antes de una auditoría puede encontrar una instancia de MySQL 5.7 de cuatro años que nadie tenía registrada, ya fuera del soporte del proveedor, a tiempo para darla de baja antes de que llegue el auditor.
Visibilidad del ciclo de vida con Atlas
Atlas completa el estado de fin de vida (EoL) y de fin de soporte (EoS) de cada versión de motor directamente en el CI, así nadie tiene que revisar la documentación del proveedor instancia por instancia. La cobertura depende de lo que publica cada proveedor, por eso varía según el motor y la versión.
El beneficio es poder planificar con anticipación. Un equipo universitario que administra 47 instancias en tres entornos puede ordenarlas por fecha de fin de soporte y ver exactamente qué hay que actualizar en los próximos doce meses, lo que convierte una recopilación de varias semanas en un filtro.
Mapeo de dependencias con CI connections
Las bases de datos forman parte de la misma capa de CI connections que el resto del inventario, junto con activos, personas, activos en la nube y Business Applications. Hay cinco tipos nativos listos para usar:
- Technical Owner.
- Commercial Owner.
- Security Auditor.
- Runs on.
- Stored In.
Dos de ellos concentran la mayor parte del trabajo en una base de datos: "Runs on" la vincula con el activo o el activo en la nube que la aloja, y "Stored In" la vincula con el lugar donde se almacena. Cada conexión registra un nivel de criticidad (bajo, medio o alto) y aparece en la pestaña Related CIs de ambos perfiles en cuanto se crea, así se carga una vez y se consulta desde cualquiera de los dos extremos. Las organizaciones que usan su propia nomenclatura pueden agregar tipos propios desde Settings.
Las conexiones las declara una persona: alguien registra que esta base de datos sostiene tal aplicación, y esa declaración es lo que muestra el mapa. Mantenerlas al día tiene apoyo automático, porque un cambio puede disparar una automatización y una conexión cuyo otro extremo desaparece se limpia o se marca para revisión. El criterio sigue en manos de una persona.
Registro de evidencia en los cambios gobernados
Cada cambio en un CI ya queda registrado en "Activities", que muestra qué cambió. La gobernanza suma lo que "Activities" no cubre: cuando está habilitada, un cambio en una propiedad crítica de un CI de base de datos dispara un paso de registro de evidencia, en el que la persona que hace el cambio deja constancia del autor real, la fecha efectiva y el motivo. Las propiedades críticas incluyen el estado, el responsable, otras propiedades nativas y los campos personalizados.
Lo que suma es concreto. "Activities" no puede decir por qué se hizo un cambio, quién lo autorizó ni si la persona que editó el registro es la misma que hizo el cambio en el mundo real, y esas son las preguntas que hace una revisión de seguridad meses después. Un DBA que reasigna el responsable de una instancia de producción aporta ese contexto en el momento, y la revisión encuentra el relato completo en el historial de cambios.
Conclusión
Una base de datos tiene versión, responsable, host, ciclo de vida y una fecha a partir de la cual nadie la parchea. Gobernarla como un activo significa que el descubrimiento la incorpora al registro, Atlas marca su estado de soporte, CI connections muestra qué sostiene y el paso de evidencia registra quién la cambió y por qué.
Las cuatro funciones trabajan sobre el mismo registro que el resto del inventario, así que ninguna corre como un ejercicio aparte de la gestión de activos. Puedes ejecutar el descubrimiento en tu propio entorno con una prueba gratuita de 30 días, o hablar con Ventas para revisar qué motores y entornos están a tu alcance.
