Inventario de datos multi-cloud: el test de los 10 segundos

En pocas palabras: Tu equipo necesita un inventario multi-cloud porque las organizaciones gestionan en promedio 3,9 nubes según Flexera 2024, y sin ese registro único no sabés dónde corren tus datos: desde Azure SQL hasta MongoDB Atlas, cada instancia sin mapear es un riesgo de seguridad, costos y cumplimiento.

Preguntale a tu equipo cuántas bases de datos corre la empresa hoy, en todas las nubes, todas las cuentas y todas las regiones. Si la respuesta tarda más de diez segundos, no tenés un inventario de datos. Y un análisis publicado en dev.to explica por qué ese vacío sale caro.

Un inventario de bases de datos multi-cloud es un registro único y siempre actualizado de cada instancia que opera una organización, sin importar el proveedor: AWS, Google Cloud, MongoDB Atlas o servidores propios. Sirve para responder en cualquier momento qué bases existen, dónde corren, quién responde por cada una, qué motor y versión usan y qué datos almacenan. Sin ese mapa completo, los equipos operan a ciegas.

Hace diez años la respuesta era trivial: unas pocas instancias de MySQL o PostgreSQL en un data center, una réplica, y una persona que sabía dónde estaba todo. Hoy ese mapa se rompió.

¿Qué es un inventario de bases de datos multi-cloud?

Es la lista única y vigente de cada instancia de base de datos de la organización, en AWS, GCP, MongoDB Atlas y on-premises. La fuente lo plantea como un test simple: si podés responder cuántas instancias tenés en menos de diez segundos sin abrir una consola, tenés inventario. Si no, estás navegando sin mapa.

Ojo con confundirlo con otras dos cosas parecidas. El monitoreo te avisa si una base que ya conocés se cayó, pero no te dice qué bases existen. El catálogo de datos documenta el contenido para analistas, no la infraestructura. El inventario es el mapa de lo que corre, y sin él las otras dos capas quedan incompletas.

¿Por qué hoy es tan difícil saber dónde están todas las bases de datos?

Porque la infraestructura se fragmentó en cuatro dimensiones al mismo tiempo: AWS para la carga principal, GCP para analítica porque BigQuery es difícil de reemplazar, quizás Azure por alguna integración heredada, MongoDB Atlas por flexibilidad, cuentas separadas para producción, staging, desarrollo y cada equipo de producto, regiones múltiples por latencia, residencia de datos o disaster recovery, y motores de todo tipo, del relacional al grafo, a veces dentro del mismo producto.

Fijate que esto no es un caso borde: es exactamente el panorama que describe la fuente para cualquier organización que creció en la última década. La pregunta “¿dónde están nuestras bases?” dejó de tener respuesta obvia hace rato.

¿Qué riesgos corrés si no tenés inventario de tus bases de datos?

Cuatro, y todos concretos. Ponele que un desarrollador crea una instancia para un proyecto que después se cancela, o una réplica se promueve y la original nunca se borra. Sin inventario, esas bases se acumulan en silencio.

• Bases fantasma con riesgo acumulado: una instancia que no está en el inventario queda fuera del ciclo de parches y de las auditorías de acceso. Puede ser accesible públicamente o tener una contraseña root que nadie rotó jamás.
• Onboarding lento: cada ingeniero nuevo aprende el mapa de boca de quien tiene el conocimiento tribal. Tarda semanas, queda incompleto, y ese saber se va de la empresa cuando la persona renuncia.
• Incidentes más largos: cuando algo se rompe a las 2 AM, el mapeo entre bases y servicios debería existir ya. Sin inventario, lo reconstruís bajo presión (sí, a esa hora).
• Cumplimiento como excavación: GDPR, SOC 2 e HIPAA exigen saber dónde está cada dato. Sin inventario, cada auditoría se convierte en un proyecto de arqueología de semanas.

¿Qué información debe contener un inventario de bases de datos?

Como mínimo, cada instancia tiene que responder estas preguntas:

• Motor, versión y ubicación: define qué herramientas y APIs aplican, y alimenta el ciclo de parches y la planificación de fin de vida.
• Propietario responsable: quién responde por la base, clave para el ownership y la facturación.
• Región o host: afecta latencia, residencia de datos y disaster recovery.
• Estado: corriendo, detenida o reiniciando; determina el radio de impacto en un incidente.
• Prioridad y nivel de protección: qué tan crítica es la base y qué controles exige.
• Accesos: quién entra hoy y cómo solicitar acceso.
• Backups y retención: qué política aplica y dónde viven las copias.
• Qué datos guarda: tablas, columnas, tipos e índices.

Según la fuente, los dos campos más difíciles de completar, estado y datos almacenados, son también los más valiosos. Tiene lógica: son los que separan una lista de instancias de un mapa real de dónde vive tu información.

¿Por qué las herramientas nativas de cada cloud no alcanzan?

Porque cada una solo ve su propio reino. AWS Resource Explorer no te muestra las instancias de GCP. GCP Asset Inventory no conoce tus clústeres de MongoDB Atlas ni tu PostgreSQL on-premises. Con un solo proveedor y una cuenta, las herramientas nativas zafan. En cuanto cruzás la frontera, quedás sin nada.

Y ahí aparecen las tres salidas malas que describe la fuente: planillas manuales que se actualizan cuando alguien se acuerda, tooling casero que se come semanas de ingeniería resolviendo un problema que no es tu negocio principal, o ignorar el tema y aceptar el riesgo. En la práctica, el parche casero termina dominando: scripts propios y herramientas construidas a mano que raspan las APIs de cada proveedor, sin una vista unificada de nada. Más contexto en el caso de malware Miasma en GitHub.

Enfoque	Cómo funciona	Dónde falla
Planilla manual	Alguien la actualiza cuando se acuerda	Siempre desactualizada; no escala con múltiples cuentas y regiones
Herramientas nativas (AWS Resource Explorer, GCP Asset Inventory)	Inventarían dentro de su propia nube	No cruzan proveedores ni ven bases on-premises
Scripts y tooling propio	Raspan las APIs de cada proveedor y agregan resultados	Semanas de ingeniería en un problema que no es tu negocio
Descubrimiento automatizado por API	Se conecta con credenciales existentes y descubre en continuo	Exige dar acceso de lectura a un tercero; hay que evaluar la confianza

¿Cómo automatizar el descubrimiento de bases de datos en multi-cloud?

Conectando credenciales que ya tenés a las APIs de gestión de cada proveedor, sin instalar nada en los nodos. Es el enfoque que describe la fuente: roles IAM de AWS, service accounts de GCP, API keys de Atlas y connection strings para on-premises, todo de solo lectura. El descubrimiento es continuo, así que una base nueva aparece en el inventario sin que nadie la cargue a mano.

El alcance que la fuente declara hoy: en AWS, RDS (MySQL, PostgreSQL, MariaDB, Oracle y SQL Server), Aurora, Redshift, DynamoDB, ElastiCache, DocumentDB y Neptune; en GCP, Cloud SQL, Spanner, BigQuery, Firestore y Bigtable; en MongoDB Atlas, clústeres de todos los proyectos; y on-premises, MySQL, PostgreSQL y MariaDB. El soporte de Azure (SQL Database, Cosmos DB, Azure PostgreSQL) figura como “coming soon”, ojo, porque eso todavía no está confirmado.

La herramienta que impulsa el artículo fuente, 1DataCloud, arranca gratis con hasta 3 instancias y sin tarjeta de crédito, con planes pagos para instancias ilimitadas (dato del propio fabricante, tomalo con pinzas). El punto del enfoque va más allá de la marca: si el descubrimiento es por API y de solo lectura, el costo de mantener el inventario tiende a cero.

¿Cómo mantener actualizado el inventario de datos en el tiempo?

Combinando actualización en tiempo real con dueños claros por base. Si el descubrimiento es automatizado por API, cada alta, baja o cambio se refleja en el inventario sin que nadie lo cargue a mano.

• Propietario con nombre y apellido: quién responde por cada base queda documentado en el inventario, no en la memoria de una sola persona.
• Descubrimiento continuo: las instancias nuevas y las eliminadas aparecen y desaparecen del listado sin carga manual.
• Esquema incluido: tablas, columnas, tipos e índices se consultan desde el mismo inventario.
• Visibilidad compartida: desarrolladores, seguridad, analistas y dirección ven el mismo mapa completo.

¿Qué beneficios aporta un inventario de bases de datos a la organización?

Cambia la relación de cada rol con la infraestructura, y cada uno gana algo distinto según la fuente: Cubrimos ese tema en detalle en nuestro benchmark de Windows 11 frente a Ubuntu.

• Desarrolladores: dejan de quemar tiempo en “qué corre dónde” y lo gastan en lo que importa.
• Seguridad: obtiene la superficie completa a auditar, sin un descubrimiento de meses antes de cada revisión.
• Analistas: encuentran los datos que necesitan sin abrir tickets.
• Dirección: decide capacidad, costo y riesgo con foto completa en lugar de una suposición.

Y hay un puente interesante al final: con inventario más metadatos de esquema, se abre la puerta a consultar tu infraestructura en lenguaje natural. “¿Cuántos usuarios activos tenemos en todas nuestras bases regionales?” deja de ser el inicio de una búsqueda de días y pasa a ser una pregunta. Pero primero hace falta el mapa.

Qué significa para equipos en Latinoamérica

En la región la mezcla es todavía más común: una nube global para la carga principal y un proveedor local para cargas de negocio, facturación en pesos o soporte en tu zona horaria. Si parte de tus bases vive en hosting tradicional (en Argentina, proveedores como Donweb son habituales para ese rol), esas instancias también tienen que entrar al inventario, vía connection string o con el export que te dé el proveedor. Y ojo con la residencia de datos: las leyes locales de protección de datos personales exigen saber dónde está cada registro, que es justamente lo que el inventario resuelve.

¿Qué está confirmado y qué no?

Confirmado según las fuentes: el enfoque de descubrimiento por API sin agentes, la lista de motores soportados y el plan gratuito de hasta 3 instancias.

Pendiente o sin verificación independiente: el soporte de Azure figura como “coming soon” en la propia fuente, así que trátalo como promesa. Las consultas en lenguaje natural se presentan como posibilidad futura, no como producto lanzado. Y los beneficios operativos son afirmaciones del fabricante. ¿Alguien los midió de forma independiente? Todavía no.

Errores comunes al armar un inventario de bases de datos

Después de años viendo estos proyectos, los tropiezos se repiten:

• Hacerlo una vez y guardarlo en una planilla: el inventario muere el día que lo terminás. Corrección: descubrimiento continuo por API.
• Inventariar solo producción: las bases olvidadas que generan riesgo son justamente las de test, las réplicas promovidas y los proyectos cancelados. Corrección: todos los ambientes entran, sin excepciones.
• Delegarlo en la persona que “sabe todo”: ¿y qué pasa cuando renuncia? Que el mapa se va con ella. Corrección: propietarios definidos por base y documentación viva.
• Confundir inventario con monitoreo: el monitoreo avisa si una base conocida se cae; no te dice qué bases existen. Necesitás las dos capas.

Preguntas Frecuentes

¿Qué es un inventario de bases de datos?

Es un registro único y actualizado de todas las instancias de bases de datos de una organización. Para cada instancia documenta motor, versión, ubicación, propietario, estado y qué datos almacena. Su objetivo es que cualquier persona del equipo pueda responder qué bases existen y dónde corren sin investigar nada.

¿Cómo hacer un inventario de bases de datos en la nube?

Lo más eficiente es conectar las credenciales que ya tenés (roles IAM en AWS, service accounts en Google Cloud, API keys en MongoDB Atlas) a una herramienta que consulte las APIs de gestión de cada proveedor. Así el descubrimiento es automático, continuo, de solo lectura y sin instalar agentes en los nodos. La alternativa manual, la planilla, queda desactualizada en cuestión de semanas. Complementá con cómo evitar caídas con DNS autoritativos.

¿Qué información debe contener un inventario de sistemas de datos?

Como mínimo: motor y versión, propietario responsable, ubicación o host, región, estado (corriendo o detenida), quién accede y cómo solicitar acceso, políticas de backup y retención, y qué datos guarda (tablas, columnas, índices). Según las fuentes, los campos más difíciles de completar, estado y datos almacenados, son también los más valiosos.

¿Por qué es importante saber dónde están todas las bases de datos de la empresa?

Porque cada base fuera del inventario escapa al ciclo de parches, a las auditorías de acceso y a la rotación de credenciales, y puede quedar expuesta públicamente sin que nadie lo sepa. Además, GDPR, SOC 2 e HIPAA exigen documentar dónde se almacenan los datos: sin inventario, cada auditoría se convierte en un proyecto de semanas.

¿Cómo mantener actualizado un inventario de bases de datos?

Combinando actualización en tiempo real (el descubrimiento automatizado por API refleja cada alta, baja o cambio sin carga manual) con propietarios definidos por base y documentación viva del inventario.

Conclusión

La fragmentación ya ganó la primera mitad: las organizaciones operan varias plataformas de bases de datos a la vez y las herramientas nativas de cada nube no se hablan entre sí. En ese escenario, no saber qué bases tenés dejó de ser un problema documental y pasó a ser un riesgo de seguridad y de cumplimiento con fecha de vencimiento.

El test es gratis y lo podés hacer ahora: preguntale a tu equipo cuántas instancias tiene, en todas las nubes y cuentas. Si la respuesta tarda más de diez segundos, empezá por el descubrimiento automatizado vía API, porque la planilla manual es un cementerio de buenas intenciones (spoiler: nadie la actualiza). Si preferís el camino formal, arrancá asignando un propietario a cada base y dejando que el descubrimiento automatizado haga el trabajo repetitivo. Lo que no podés hacer es seguir volando a ciegas y esperar que la próxima auditoría o el próximo incidente a las 2 AM te salga bien.

Fuentes

• dev.to – Por qué tu equipo necesita un inventario de bases de datos multi-cloud