SEGURIDAD DE
BASES DE DATOS:
LAS FALLAS
SILENCIOSAS QUE
CUESTAN MILLONES.

Falla 1 — Usuarios con privilegios excesivos

El escenario más común: el desarrollador necesitó acceso DBA temporal para resolver un problema. El acceso nunca fue revocado. Seis meses después, esa cuenta todavía tiene permiso de DROP en tablas de producción — y nadie lo sabe.

Los privilegios excesivos son la puerta de entrada más silenciosa. No aparecen en ninguna alerta. No generan log sin monitoreo específico. Y cuando son explotados — sea por un atacante externo que comprometió la credencial, o por un insider — el daño es total.

Falla 2 — Configuraciones por defecto nunca alteradas

MySQL, SQL Server, Oracle, PostgreSQL — todos vienen de fábrica con configuraciones que priorizan facilidad de instalación, no seguridad. Usuarios por defecto habilitados. Puertos conocidos abiertos. Autenticación por contraseña simple. Características activas que nunca serán usadas.

Un ambiente configurado hace tres años y nunca revisado desde entonces probablemente todavía carga vulnerabilidades que el fabricante ya corrigió — pero que dependen de reconfiguración manual para ser cerradas.

Falla 3 — Ausencia de log de auditoría

Sin log de auditoría, no sabes quién accedió a la base, cuándo, qué leyó, qué modificó. En caso de incidente, no hay rastro forense. En caso de auditoría, no hay evidencia de control.

Más grave aún: sin log activo, una exfiltración de datos puede ocurrir durante semanas antes de cualquier alerta. IBM señala que el tiempo promedio para identificar una violación supera los 200 días en ambientes sin monitoreo adecuado.

Falla 4 — SQL Injection no tratado en el código de la aplicación

SQL Injection es la vulnerabilidad más documentada de la historia de la seguridad de aplicaciones. El OWASP Top 10 la clasifica como una de las más recurrentes desde 2003. Y sigue siendo explotada en 2025.

La base de datos en sí no es vulnerable a SQL Injection — la vulnerabilidad está en el código de la aplicación que no valida las entradas antes de pasarlas a la base. Pero es la base la que carga las consecuencias: datos expuestos, tablas corruptas, acceso administrativo no autorizado.

La corrección técnica existe y está bien documentada: prepared statements, validación de entradas, principio del menor privilegio en la cuenta de conexión. El problema es que los ambientes legacy raramente reciben esa revisión de forma sistemática.

Falla 5 — Backups sin cifrado y sin pruebas de restore

Un backup sin cifrar en almacenamiento accesible es una base de datos completa esperando ser robada. No es necesario invadir el servidor de producción — basta con acceder al repositorio de backup.

Peor aún: la mayoría de las empresas nunca probó el restore de sus backups. Un backup corrompido silenciosamente hace seis meses significa que, en caso de desastre, el plan de recuperación no existe — solo existe la ilusión de que existe.

Falla 6 — Versiones desactualizadas con vulnerabilidades conocidas

Cada versión de RDBMS desactualizada tiene una lista pública de CVEs (Common Vulnerabilities and Exposures) — vulnerabilidades documentadas, con exploits conocidos, disponibles para que cualquiera las consulte. Un atacante no necesita descubrir una vulnerabilidad zero-day. Solo necesita consultar la lista y verificar si tu base sigue en la versión afectada.

En 2024, el 60% de las organizaciones reportaron violaciones causadas por componentes con vulnerabilidades conocidas que simplemente no habían sido actualizados.

Falla 7 — Datos sensibles sin cifrado en reposo

RUT, número de tarjeta, datos de salud, contraseñas — almacenados en texto plano en tablas de producción. Quien tenga acceso SELECT a la tabla tiene acceso a los datos reales. Sin cifrado en reposo, no hay segunda capa de protección si el control de acceso falla.

Y bajo las leyes de protección de datos, la ausencia de cifrado de datos personales no es solo riesgo técnico — es evidencia de negligencia en un eventual proceso sancionatorio.

Control de acceso con registro

Quién accede a qué datos, cuándo y con qué finalidad. Sin log de auditoría activo, no hay forma de demostrar control — y sin demostrarlo, no hay forma de defenderse en caso de notificación de la autoridad.

Cifrado de datos personales

Datos de identificación, salud, financieros y otros datos sensibles almacenados en bases de datos necesitan protección adicional más allá del control de acceso. El cifrado en reposo es la medida técnica más directa para esto.

Plan documentado de respuesta a incidentes

En caso de violación, la normativa exige comunicación a la autoridad en plazo razonable. Para eso, necesitas saber que ocurrió un incidente — lo que requiere monitoreo activo — y tener un plan documentado de respuesta.

Capa 1 — Acceso e identidad

Revisión completa de usuarios, roles, privilegios y cuentas de servicio. Identificación de cuentas inactivas, privilegios excesivos y cuentas con contraseñas por defecto. Verificación de acceso externo a la base.

Capa 2 — Configuración y hardening

Comparación de las configuraciones de la base con las best-practices de seguridad del fabricante. Identificación de características activas innecesarias, puertos expuestos y parámetros inseguros.

Capa 3 — Datos y cifrado

Mapeo de tablas con datos personales o sensibles. Verificación de cifrado en reposo y en tránsito. Identificación de datos sensibles sin protección adicional.

Capa 4 — Monitoreo y auditoría

Verificación de logs activos, cobertura del monitoreo y capacidad de detectar accesos anómalos. Evaluación del plan de respuesta a incidentes.