Seguridad de bases de datos: amenazas, controles y buenas prácticas

¿Qué es la seguridad de bases de datos?

La seguridad de bases de datos es el conjunto de controles que protegen una base de datos y sus datos frente a accesos no autorizados, modificación, borrado y robo. Combina medidas técnicas (autenticación, cifrado, aislamiento de red), hábitos operativos (parches, auditoría, copias de seguridad probadas) y políticas (quién puede ver qué datos y durante cuánto tiempo se conservan).

Las bases de datos son un objetivo prioritario porque reúnen en un solo sitio lo que buscan los atacantes: registros de clientes, credenciales y datos relacionados con pagos. Los mismos controles protegen también de errores honestos, como un desarrollador que ejecuta un borrado contra producción.

Amenazas habituales

Los controles básicos

Autenticación

Da a cada persona y a cada servicio su propia cuenta, sin accesos compartidos. Si tu plataforma lo permite, prefiere credenciales de corta duración basadas en identidad frente a contraseñas duraderas. Es la misma disciplina que la gestión de identidades y accesos (IAM) en el resto de tu infraestructura.

Autorización y mínimo privilegio

Cada cuenta recibe solo los permisos que necesita. La cuenta de la aplicación no debería ser propietaria del esquema ni ejecutar comandos administrativos, y los administradores usan cuentas aparte. Una lista de permisos por roles es una forma de lista de control de acceso (ACL).

Cifrado en tránsito y en reposo

Exige TLS en todas las conexiones y rechaza las que no lo usen. Cifra el almacenamiento y las copias para que un disco o una instantánea robados no sirvan por sí solos. Cifra aparte los campos especialmente sensibles si el operador de la base de datos no debe verlos.

Aislamiento de red

Mantén la base de datos en una red privada. Las aplicaciones llegan a ella por rutas privadas y los administradores por VPN o un bastión. Limita qué orígenes acepta el firewall o el grupo de seguridad.

Auditoría, parches y copias de seguridad

Registra los cambios de privilegios, de esquema y las exportaciones masivas, y alerta cuando sean inusuales. Aplica los parches de la base de datos y del sistema operativo con regularidad. Haz copias cifradas, guarda una en otra cuenta o región y prueba la restauración, porque una copia que nunca has restaurado es solo una suposición.

Inyección SQL: el fallo clásico

La inyección SQL ocurre cuando la entrada del usuario se incorpora a la cadena de una consulta. La guía OWASP SQL Injection Prevention Cheat Sheet señala las sentencias preparadas (consultas parametrizadas) como defensa principal, con validación por lista de permitidos para las partes que no se pueden enlazar, como nombres de tabla u orden, y advierte de que el escapado es frágil. También indica que las cuentas de la aplicación nunca deben tener acceso de DBA o administrador.

# Vulnerable: la entrada se concatena en la consulta
query = f"SELECT * FROM users WHERE email = '{user_input}'"
cursor.execute(query)

# Seguro: el controlador envía el valor separado del SQL
cursor.execute("SELECT * FROM users WHERE email = %s", (user_input,))

Los ORM parametrizan por defecto, pero sus vías para consultas en bruto son una forma habitual de que la inyección vuelva. Consulta la guía de OWASP (en inglés) para la lista completa. La inyección llega a la base de datos a través de tu API, así que la seguridad de la API es también seguridad de la base de datos.

Tratamiento de datos sensibles

• Contraseñas: guarda un hash lento con sal (bcrypt, scrypt o Argon2), nunca la contraseña ni un cifrado reversible.
• Datos personales y de pago: cífralos a nivel de columna o de aplicación, o tokenízalos para que el valor real viva en una bóveda dedicada.
• Datos de prueba y desarrollo: enmascáralos o genéralos sintéticamente en lugar de copiar producción.
• Datos multiinquilino: usa seguridad a nivel de fila donde el motor la ofrezca. En PostgreSQL, una tabla con seguridad de filas activada y sin política no muestra filas a los usuarios normales, pero los propietarios de la tabla y los superusuarios la eluden salvo que lo fuerces.

Cumplimiento normativo en un párrafo

Normas como RGPD, HIPAA, PCI DSS y SOC 2 piden, cada una, control de acceso, cifrado, registro y respuesta a incidentes para los datos que cubren. Según el artículo 33 del RGPD, una violación de la seguridad de los datos personales debe notificarse a la autoridad de control sin dilación indebida y, de ser posible, en un plazo de 72 horas desde que se tenga constancia. Confirma con tus asesores de cumplimiento qué normas te afectan.

Errores comunes

• Conectar la aplicación como administrador porque simplifica la puesta en marcha.
• Copiar datos de producción a staging y dejarlos sin enmascarar.
• No probar nunca una restauración.
• Dejar credenciales en el código, en logs de CI o en imágenes de contenedor en lugar de un gestor de secretos.
• Creer que el cifrado lo resuelve todo. No detiene la inyección ni una contraseña de aplicación robada.

Seguridad de bases de datos, pruebas de carga y monitorización

LoadFocus no busca vulnerabilidades, pero el trabajo de rendimiento toca los mismos sistemas. Una prueba de carga muestra cómo se comporta tu base de datos al subir los usuarios concurrentes, por ejemplo cuando se acumulan consultas lentas o se agota el pool de conexiones (consulta how to optimize database connection pools, en inglés). Si la ejecutas contra un entorno de staging, usa datos enmascarados o sintéticos, como explica cloud testing security best practices (en inglés). La monitorización de APIs comprueba tus endpoints respaldados por base de datos de forma programada, de modo que un endpoint lento o caído genera una alerta en lugar de esperar el aviso de un cliente.

Preguntas frecuentes sobre seguridad de bases de datos

¿Cómo evito la inyección SQL?

Usa consultas parametrizadas o sentencias preparadas en toda consulta con entrada del usuario, valida con una lista de permitidos los identificadores que no se pueden enlazar y conéctate con una cuenta que tenga solo los permisos necesarios.

¿Debo cifrar en la aplicación o en la base de datos?

El cifrado en la base de datos es más sencillo de operar, pero la base puede leer los datos en claro. El cifrado en la aplicación mantiene las claves lejos de la base, aunque complica buscar y ordenar. Los campos muy sensibles suelen justificar ambos.

¿Qué diferencia hay entre cifrado en reposo y en tránsito?

En reposo protege los datos almacenados, como discos y copias. En tránsito protege los datos en la red entre la aplicación y la base de datos. Hacen falta los dos.

¿Puedo exponer mi base de datos a internet?

Casi nunca. Mantenla en una red privada y permite acceso solo a tus servidores de aplicación y a una vía de administración controlada.

¿Qué es la seguridad a nivel de fila?

Una función de la base de datos que filtra qué filas puede leer o cambiar un usuario según las políticas que definas. Sirve en aplicaciones multiinquilino como segunda línea de defensa tras las comprobaciones de la aplicación.

¿Cómo detecto una brecha en la base de datos?

Con registros de auditoría y alertas ante comportamientos raros: exportaciones masivas, consultas a horas inusuales, nuevas cuentas con privilegios y cambios de esquema fuera de una ventana de cambios planificada.