Un equipo dice: «la base de datos está cifrada en reposo, así que estamos seguros». Como arquitecto, ¿cuál es la brecha?
Respuesta breve
El cifrado en reposo defiende exactamente una amenaza — el robo físico o de disco — y no hace nada frente a una aplicación comprometida, credenciales robadas o tráfico interceptado, porque la base de datos descifra de forma transparente para cualquier consulta autorizada. Un diseño sólido también exige TLS en tránsito, autenticación y autorización fuertes, y una gestión de claves adecuada con separación de funciones. Duplicar el cifrado en reposo añade coste sin cambiar el modelo de amenazas, y cifrar solo las copias de seguridad deja expuestos los datos en producción y sus rutas de acceso.
Cuando un equipo equipara «cifrado en reposo» con «seguro», ha confundido un único control con una postura de seguridad completa. La tarea del arquitecto es asociar el control a las amenazas que realmente mitiga y exponer lo que deja abierto.
Qué hace realmente el cifrado en reposo
El cifrado en reposo —a nivel de disco, de sistema de archivos o mediante cifrado transparente (TDE)— protege los datos en medios robados o dados de baja. Si alguien se lleva un disco o una cinta de copia de seguridad, los bytes son ilegibles. Es un valor real, pero un valor estrecho.
La idea clave: la base de datos descifra los datos de forma transparente para cualquier conexión autorizada. Una consulta SQL de la aplicación ve texto en claro. Por tanto, el cifrado en reposo no hace nada frente a las amenazas que dominan las brechas reales.
Las brechas que quedan
- Compromisión de la capa de aplicación. Una inyección SQL, una API vulnerable o una cuenta de servicio comprometida consulta la base de datos y recibe texto en claro. El cifrado nunca se activa.
- Credenciales robadas. Credenciales de base de datos obtenidas por phishing o filtradas permiten a un atacante autenticarse y leerlo todo en claro.
- Datos en tránsito. Sin TLS, el tráfico entre la aplicación y la base de datos puede ser interceptado o manipulado en la red.
- Gestión de claves. Si las claves se almacenan mal o se ubican junto a los datos, el cifrado es puro teatro.
Por qué las respuestas incorrectas lo son
«Nada — el cifrado en reposo es suficiente» es la trampa en la que cae un candidato más débil: acepta un único control como respuesta completa. «Añadir una segunda capa de cifrado en reposo» duplica coste y complejidad mientras defiende exactamente la misma amenaza — movimiento sin avance. «Cifrar solo las copias de seguridad» es aún más limitado, dejando los datos de producción y cada ruta de acceso sin protección.
Qué evalúa el entrevistador
Quiere ver razonamiento por modelo de amenazas: qué amenaza aborda cada control y dónde están los riesgos residuales. Un buen arquitecto responde con defensa en profundidad —TLS en tránsito, control de acceso de mínimo privilegio, consultas parametrizadas contra la inyección y claves gestionadas en un KMS/HSM separadas de los datos— en lugar de tratar una sola casilla marcada como la línea de meta.
Posibles preguntas de seguimiento
- Si la aplicación se ve comprometida, ¿ayuda en algo el cifrado en reposo? ¿Por qué?
- ¿Dónde almacenarías y rotarías las claves de esta base de datos, y quién debería tener acceso?
- ¿Cómo protegerías esos mismos datos en tránsito entre la aplicación y la base de datos?