Seguridad de bases de datos: cifrado, accesos, respaldos y auditoría

1. Red: que nadie la vea desde internet

• La base de datos vive en una red privada y sólo acepta conexiones de los servidores de la aplicación.
• Para administración, acceso por VPN o túnel con autenticación de dos factores, nunca con el puerto abierto.
• Reglas de firewall revisadas cada vez que cambia la infraestructura.

2. Accesos con mínimo privilegio

• La aplicación usa una cuenta que sólo puede leer y escribir sus tablas; no puede borrar la base de datos ni crear usuarios.
• Cuentas separadas para reportes (sólo lectura), migraciones y administración.
• Cuentas personales para cada administrador: nada de contraseñas compartidas.
• Seguridad a nivel de fila cuando varias empresas o sucursales comparten la misma base de datos.
• Revisión trimestral de quién tiene acceso, y baja inmediata al salir alguien del equipo.

3. Cifrado en tránsito y en reposo

• En tránsito: conexiones TLS obligatorias entre la aplicación y la base de datos.
• En reposo: discos y respaldos cifrados; las nubes administradas lo ofrecen por defecto.
• Por campo: datos especialmente sensibles (cuentas bancarias, datos de salud, identificaciones) cifrados por la aplicación, con llaves administradas fuera de la base de datos.
• Contraseñas de usuarios: nunca se guardan; se guarda su hash con un algoritmo diseñado para ello (Argon2 o bcrypt).

4. Respaldos que sí se pueden restaurar

Un respaldo que nunca se ha restaurado es una suposición. La regla 3-2-1: tres copias, en dos medios distintos, una fuera del sitio.

• Respaldos automáticos diarios y recuperación a un punto en el tiempo para errores humanos.
• Copias inmutables o en una cuenta separada, para que un atacante no pueda borrarlas.
• Restauración de prueba al menos cada trimestre, midiendo cuánto tarda.
• Objetivos claros: cuánta información puedes perder (RPO) y cuánto tiempo puedes estar sin sistema (RTO).

5. Bitácoras y alertas

• Registro de inicios de sesión, cambios de permisos y consultas administrativas.
• Bitácora de negocio dentro de la aplicación: quién modificó un pago, un precio o un expediente.
• Alertas ante patrones raros: exportaciones masivas, accesos fuera de horario, muchos intentos fallidos.
• Bitácoras guardadas fuera del servidor que registran, para que no se puedan alterar.

6. La aplicación también protege

• Consultas parametrizadas u ORM: la inyección SQL sigue en la lista OWASP Top 10.
• Validación de permisos en el servidor en cada petición, no sólo ocultando botones.
• Paginación y límites para que nadie descargue toda la tabla de clientes con un clic.
• Dependencias actualizadas y revisadas automáticamente.

7. Datos de prueba

Copiar producción a desarrollo «para probar con datos reales» es una de las fugas más comunes. Usa datos ficticios generados o una copia anonimizada: nombres, teléfonos, correos y montos sustituidos de forma irreversible.

8. Plan de respuesta a incidentes

1. Quién decide y a quién se llama en la primera hora.
2. Cómo se aísla el sistema sin destruir evidencia.
3. Cómo se restaura desde respaldos limpios.
4. Cómo y cuándo se informa a clientes y titulares de datos, conforme a la ley de protección de datos personales.
5. Revisión posterior: qué falló y qué control se agrega.

Para el panorama de normas (ISO 27001, SOC 2, PCI DSS, LFPDPPP), consulta la guía de certificaciones de seguridad. Si quieres una revisión de tu base de datos actual, escríbenos.