Protección de bases de datos: los datos de tus clientes merecen más que una contraseña

Introducción al Problema#

La base de datos es el activo más valioso de casi cualquier empresa digital. Ahí están los datos de clientes, transacciones, información financiera, registros médicos, credenciales. Si hay un objetivo que un atacante prioriza sobre todos los demás, es la base de datos.

Paradójicamente, las bases de datos suelen ser el eslabón menos protegido de la cadena. Se las configura una vez para que "funcionen", y la seguridad queda en segundo plano: la aplicación se conecta como root, no hay cifrado en tránsito porque "es una red interna", no hay auditoría de consultas porque "ralentiza el sistema", y los backups están sin cifrar porque "nadie va a llegar hasta ahí".

Ese razonamiento es exactamente el que aprovechan los atacantes. Y cuando la brecha ocurre — filtración de datos, inyección SQL, acceso no autorizado — las consecuencias son legales, económicas y reputacionales.

Caso Real o Ejemplo Cotidiano#

En 2023, una clínica médica argentina con múltiples sucursales sufrió una filtración de datos que afectó a más de 50.000 pacientes. La investigación de la Agencia de Acceso a la Información Pública determinó que la violación ocurrió a través de una vulnerabilidad de inyección SQL en el portal web de turnos.

Lo que convirtió un bug de software en una catástrofe de datos fue la configuración de la base de datos:

• La aplicación web se conectaba a MySQL como usuario root — con acceso completo a todas las tablas de todos los sistemas
• La conexión no usaba cifrado TLS (las credenciales y los datos viajaban en texto plano en la red interna)
• No había auditoría de consultas activa — cuando ocurrió la filtración, no había registros de qué datos fueron accedidos

El atacante, explotando la inyección SQL, no solo leyó la tabla de turnos que la app debía mostrar — ejecutó queries arbitrarias como root y extrajo historia clínica, CUIL, datos de contacto, y diagnósticos de 50.000 pacientes.

La clínica fue sancionada con una multa significativa por la AAIP y tuvo que notificar a todos los pacientes afectados.

Riesgos para la Empresa#

Explicación Técnica Sencilla#

La seguridad de bases de datos tiene cuatro dimensiones que se complementan:

1. Permisos granulares — el principio de mínimo privilegio:

Una aplicación web que muestra el catálogo de productos no necesita permisos para DROP TABLE, CREATE USER, o acceder a la tabla de contraseñas. Con permisos granulares, cada usuario de base de datos tiene exactamente los permisos que necesita y nada más.

-- Mal: la app como superusuario
GRANT ALL PRIVILEGES ON *.* TO 'appuser'@'%';

-- Bien: solo los permisos necesarios, solo en la base que corresponde
GRANT SELECT, INSERT, UPDATE ON tienda.productos TO 'app_tienda'@'10.0.1.5';
GRANT SELECT ON tienda.categorias TO 'app_tienda'@'10.0.1.5';
-- Nada más. NUNCA acceso a otras bases de datos.

2. Cifrado en tránsito — TLS para conexiones a DB:

El tráfico entre la aplicación y la base de datos debe ir cifrado, aunque estén en la misma red. La red "interna" puede ser comprometida (ARP spoofing, VLAN hopping, acceso físico a switches). Todos los motores modernos soportan TLS: MySQL, PostgreSQL, SQL Server.

3. Cifrado en reposo — Transparent Data Encryption (TDE):

TDE cifra los archivos de datos del motor de base de datos automáticamente, de forma transparente para las aplicaciones. Si alguien roba el disco, los archivos de backup, o accede físicamente al servidor, los datos están cifrados sin la clave que solo el motor conoce. SQL Server, PostgreSQL (con pgcrypto), y MySQL Enterprise lo soportan.

4. Auditoría de consultas:

Registrar qué usuario ejecutó qué consulta, cuándo, y contra qué tabla. No todas las consultas — eso es demasiado ruido — sino las acciones sensibles: accesos a tablas con datos personales, consultas SELECT masivas (posible exfiltración), cambios de esquema, intentos fallidos de autenticación.

Cómo Prevenirlo#

1. Crear usuarios de DB específicos por aplicación con mínimos privilegios: Nunca conectar aplicaciones como root, postgres, sa, o cualquier superusuario. Cada aplicación tiene su propio usuario de DB con acceso solo a la base de datos que necesita, solo en las tablas que necesita, y solo desde la IP del servidor de aplicaciones.

2. Habilitar TLS para todas las conexiones a la base de datos: En MySQL: require_secure_transport=ON en my.cnf. En PostgreSQL: ssl=on en postgresql.conf con certificado. En SQL Server: habilitar "Forzar cifrado" en el SQL Server Configuration Manager.

3. Restringir las IPs que pueden conectarse a la DB: El puerto de la base de datos (3306/MySQL, 5432/PostgreSQL, 1433/SQL Server) no debe estar accesible desde toda la red. Solo los servidores de aplicaciones específicos deben poder conectarse. En MySQL: el host del usuario restringe desde qué IP puede conectarse. En el firewall: regla explícita que bloquea conexiones al puerto de DB desde cualquier IP salvo las autorizadas.

4. No guardar credenciales de DB en texto plano en el código fuente: Usar variables de entorno, gestores de secretos (HashiCorp Vault, AWS Secrets Manager), o archivos de configuración fuera del repositorio de código. Una credencial en un archivo .env commiteado a Git es una brecha esperando ser encontrada.

5. Activar la auditoría de consultas para operaciones sensibles: En MySQL: MySQL Audit Plugin (Enterprise) o MariaDB Audit Plugin (gratuito). En PostgreSQL: pgAudit. Configurar para registrar: autenticaciones fallidas, accesos a tablas con datos sensibles (PII, datos de salud, financieros), consultas SELECT que retornan más de N registros, y todos los DDL (CREATE, DROP, ALTER).

6. Implementar backup cifrado y verificar restauración: Los backups deben estar cifrados (con la clave guardada separadamente del backup). Y los backups deben probarse periódicamente — un backup nunca restaurado es un backup potencialmente roto.

Herramientas Recomendadas#

MySQL Audit Plugin / MariaDB Audit Plugin: El plugin de auditoría nativo para MySQL y MariaDB. La versión de MariaDB es open source y gratuita. Registra en un archivo de log configurable cada autenticación, query, y cambio de objeto. Puede filtrarse por usuario, base de datos, tabla, o tipo de operación para evitar generar volúmenes de log inmanejables.

pgAudit (pgaudit.org): Extensión de auditoría para PostgreSQL que se integra con el sistema de logging nativo del motor. Permite auditoría a nivel de objeto (tabla específica) o a nivel de sesión completa. Open source, bien mantenida, y el estándar para compliance en instalaciones PostgreSQL.

Transparent Data Encryption (TDE) para SQL Server: Funcionalidad incorporada en SQL Server (desde la versión 2008) que cifra los archivos de datos, logs, y backups automáticamente. La configuración se hace completamente desde T-SQL y es transparente para las aplicaciones. No requiere cambios en el código de las aplicaciones que usan la base de datos.

Percona Monitoring and Management (PMM): Herramienta open source de monitoreo para MySQL y PostgreSQL. Además de métricas de performance, incluye dashboards de seguridad: consultas lentas (posible exfiltración masiva), patrones de acceso inusuales, y alertas sobre configuraciones de seguridad. Ideal para tener visibilidad continua del comportamiento de la base de datos.

Checklist Final#

• Ninguna aplicación se conecta a la base de datos como root o superusuario
• Cada aplicación tiene un usuario de DB dedicado con solo los permisos necesarios
• Las conexiones a la base de datos usan TLS (cifrado en tránsito activo)
• El puerto de la DB solo acepta conexiones desde las IPs de los servidores de aplicaciones
• Las credenciales de DB no están en el código fuente ni en repositorios Git
• La auditoría de consultas está activa para tablas con datos sensibles
• Los backups están cifrados y la clave se guarda separada del backup
• Los backups se prueban periódicamente (restauración de prueba)
• Está implementado TDE o cifrado equivalente en reposo
• Hay alertas configuradas para consultas SELECT masivas (posible exfiltración)
• El acceso directo a la DB desde internet está completamente bloqueado
• Los usuarios de DB desactivados o sin uso están eliminados

CVE / Vulnerabilidades Relacionadas#

El vector de ataque más frecuente contra bases de datos no es una vulnerabilidad del motor en sí, sino una debilidad en la aplicación que lo usa: la Inyección SQL, clasificada como OWASP A03:2021 — Injection.

La inyección SQL ocurre cuando una aplicación construye queries dinámicamente con datos no sanitizados del usuario. Un atacante ingresa código SQL en un campo de formulario, y ese código se ejecuta directamente en la base de datos con los permisos de la cuenta de aplicación.

-- Query vulnerable: construye SQL concatenando input del usuario
SELECT * FROM usuarios WHERE email = '" + email_input + "'

-- Si email_input = "' OR '1'='1"
-- Resulta en: SELECT * FROM usuarios WHERE email = '' OR '1'='1'
-- Retorna TODOS los usuarios de la tabla

Si la aplicación se conecta como root, una inyección SQL puede DROP TABLE, LOAD_FILE, o exfiltrar toda la base de datos. Si se conecta con un usuario con permisos mínimos, el impacto se limita a los datos accesibles por ese usuario.

La prevención combina dos capas: sanitización de inputs en la aplicación (queries parametrizadas, ORMs modernos), y permisos granulares en la base de datos como defensa en profundidad.

Conclusión y CTA#

Los datos de tus clientes son un activo de confianza que tu empresa custodia. Una filtración no es solo un problema técnico — es una falla de responsabilidad con consecuencias legales bajo la Ley 25.326 de Protección de Datos Personales y el GDPR si tenés clientes europeos.

Las medidas descritas en este artículo no son complejas de implementar. Crear usuarios de DB con permisos mínimos, habilitar TLS, activar pgAudit o el plugin de auditoría de MySQL — son configuraciones de horas, no de meses. El costo de no hacerlo, como lo demostró el caso de la clínica, puede ser significativamente mayor.

¿Querés auditar la seguridad de las bases de datos de tu empresa? Contactanos o continuá con el siguiente artículo: Monitoreo de logs: cómo detectar un atacante antes de que cause daño.