El cifrado de secretos en una base de datos es una capa de protección, no una arquitectura completa de seguridad. Una aplicación PHP, Laravel, Python o Java que conoce la clave maestra puede descifrar; si su proceso se compromete, también se compromete la capacidad de utilizarla. Esta guía explica cómo diseñar separaciones de confianza reales con gestores de secretos, identidades de máquina y políticas de mínimo privilegio.

1. No todos los secretos ni todas las claves hacen lo mismo

Una credencial puede ser una contraseña, un token OAuth, una clave de API, un certificado privado o un usuario de base de datos. La clave de cifrado es otro objeto: sirve para convertir información legible en datos cifrados y, cuando corresponda, recuperarla. Un permiso define qué acciones puede realizar una identidad; una firma y el cifrado proporcionan propiedades diferentes. Tener los valores cifrados no significa que los permisos sean mínimos.

Al diseñar un sistema conviene clasificar cada elemento por su propietario, sus consumidores, sus permisos, su vencimiento y su procedimiento de revocación. Los secretos de usuarios no deberían reutilizarse entre clientes, entornos o servicios sin una razón clara.

2. ¿Es incorrecto guardar credenciales cifradas en PostgreSQL?

No. Guardar texto cifrado en PostgreSQL puede proteger frente a una filtración que afecte únicamente a las tablas o a una copia de seguridad de la base de datos. Es importante utilizar cifrado autenticado, claves fuertes, separación de accesos, controles sobre copias y un mecanismo claro de rotación. La pregunta decisiva es dónde reside la capacidad para descifrar.

Si una aplicación web guarda el cifrado en la base de datos y mantiene a su alcance la clave maestra que lo descifra, quien ejecute código con los privilegios de esa aplicación podría descifrar secretos o pedir al sistema que los utilice. Este es un escenario de amenaza, no una afirmación de que haya sucedido una intrusión. El cifrado protege determinados límites de confianza; no convierte un servidor comprometido en fiable.

3. El riesgo de compartir servidor y clave maestra

En un despliegue sencillo pueden convivir aplicación, base de datos, copia de configuración y archivo de entorno. Si un atacante consigue lectura de ficheros de la aplicación, una copia de base de datos y acceso a la clave de cifrado, se pierde la separación que protegía los secretos. Incluso cuando la clave está en otra máquina, si el servidor comprometido tiene autorización para solicitar un descifrado arbitrario, podrá abusar de ella dentro del alcance de sus permisos.

Por eso conviene separar las funciones: el servidor de aplicación ejecuta la lógica de negocio; un almacén de secretos controla quién puede acceder a las credenciales; un servicio de claves realiza operaciones criptográficas según políticas estrictas. No hay una topología universal: una instalación pequeña quizá necesite un gestor administrado, mientras que una organización grande puede justificar operar Vault en infraestructura separada.

4. ¿Qué es HashiCorp Vault?

Vault es una plataforma de gestión de secretos e identidades de máquina. Sus motores permiten almacenar secretos estáticos, emitir determinadas credenciales dinámicas o realizar operaciones criptográficas. No se limita a ser una caja fuerte de contraseñas. Vault KV guarda valores protegidos; un motor de bases de datos puede generar credenciales con duración limitada cuando el destino lo soporta; Vault Transit cifra y descifra datos sin que la aplicación deba almacenar la clave criptográfica maestra.

En Transit la aplicación envía los datos para cifrar o el texto cifrado para descifrar mediante una API autenticada. Vault mantiene el material de clave y devuelve la operación solicitada; no conserva por defecto los datos de negocio enviados. Esto reduce la exposición de claves, pero no impide que un atacante que robe la identidad de la aplicación pueda pedir descifrados autorizados. Las políticas, la autenticación y la supervisión siguen siendo indispensables.

5. Diagrama conceptual de separación

Usuario / navegador
        |
Aplicación web (PHP, Laravel, Python, Java...)
        |
        +---- Base de datos: texto cifrado
        |
        +---- Identidad de máquina de corta duración
                       |
                 Gestor de secretos
                  /           \
          Secreto temporal   Cifrado / descifrado
                  |                |
               Servicio       Clave protegida
               de destino      fuera de la app

La red entre aplicación y gestor de secretos debe autenticarse y cifrarse. Un gestor en un servidor independiente reduce ciertos escenarios de compromiso conjunto, pero también introduce disponibilidad, copias, desbloqueo, recuperación y mantenimiento propios. No conviene desplegar Vault «por seguridad» y dejarlo con una única credencial permanente y permisos de administrador para todas las aplicaciones.

6. Claves maestras, cifrado envolvente y rotación

El envelope encryption separa una clave de cifrado de datos (DEK) de una clave que protege esa DEK (KEK). La DEK cifra cada valor o conjunto de datos; la KEK la envuelve y se conserva bajo controles de un KMS/HSM o gestor compatible. Rotar una KEK y volver a envolver claves de datos puede ser diferente de descifrar y volver a cifrar toda la base. Hay que diseñar de antemano cómo leer registros cifrados con claves antiguas.

En Laravel, APP_KEY participa en el cifrado de aplicación; cambiarla sin plan puede invalidar sesiones y dejar valores anteriormente cifrados sin posibilidad de descifrado. La documentación contempla rotación gradual con claves anteriores para lectura, pero eso no exime de planear acceso, retirada y pruebas. No copies claves reales a scripts, documentación o incidencias.

7. Credenciales estáticas frente a dinámicas

Una clave permanente puede seguir funcionando hasta su revocación. Una credencial temporal tiene un vencimiento y, a menudo, un conjunto acotado de permisos. Algunas plataformas emiten automáticamente nuevas credenciales para la aplicación antes de que caduquen; no hace falta rotarlas a mano cada hora si se integra correctamente un proveedor de identidad y renovación. El software debe detectar vencimientos, errores, revocaciones y reintentar de forma controlada.

La preferencia operativa suele ser evitar claves de acceso de larga duración cuando existen roles de carga de trabajo, identidades federadas, cuentas de servicio o credenciales efímeras. Un gestor no convierte automáticamente una credencial estática en dinámica: el servicio de destino debe permitir emisión, expiración o revocación efectiva.

8. Autenticación de máquina: el secreto de arranque

Surge una pregunta inevitable: ¿cómo se autentica la aplicación ante Vault si no queremos guardar otra clave permanente en el mismo servidor? El patrón se denomina bootstrap trust. Puede apoyarse en identidades de infraestructura, certificados de máquina, Kubernetes o federación OIDC, según el despliegue. Lo ideal es que el proceso obtenga una identidad de duración limitada y permisos mínimos. Si se entrega un token inicial, hay que protegerlo, limitar su vida útil y prever su renovación o reemplazo.

9. ¿Qué ocurre si cae el servidor de Vault?

Separar servicios introduce una dependencia nueva: si el gestor de secretos no responde, una aplicación puede quedarse sin credenciales. Diseña alta disponibilidad, almacenamiento duradero, copias cifradas, procedimientos de recuperación y monitorización. Define cuándo se permiten cachés en memoria, cuánto duran, cómo se borran y si es aceptable seguir sirviendo solicitudes durante una interrupción.

Un gestor de secretos central puede concentrar riesgos. Evita desplegarlo sin TLS, sin auditoría, sin copias o sin un procedimiento probado de recuperación. Proteger las claves de desbloqueo y las credenciales de emergencia es tan importante como proteger los secretos normales.

10. Permisos mínimos, auditoría y revocación

Una aplicación que solo necesita enviar un mensaje no debería poder administrar todas las cuentas del proveedor. Divide permisos por servicio, cliente y entorno. Registra quién leyó, creó, rotó o revocó un secreto —sin guardar el secreto en el log— y alerta ante lecturas inusuales. Si hay sospecha de filtración, revoca en el proveedor de destino, emite reemplazos, actualiza consumidores y examina la actividad previa. Reiniciar un proceso no revoca credenciales robadas.

11. Plan de adopción sin cortes

  1. Inventariar secretos y consumidores, con clasificación por impacto.
  2. Identificar la clave que cifra cada dato, dónde se encuentra y quién puede usarla.
  3. Escoger entre un gestor administrado, Vault autogestionado u otro servicio compatible con el modelo de amenazas.
  4. Crear políticas mínimas por aplicación y una identidad de máquina que no dependa de una clave permanente compartida.
  5. Probar en desarrollo lectura, renovación, fallo de red, revocación y restauración.
  6. Migrar primero un secreto de bajo impacto; mantener compatibilidad controlada con el formato antiguo mientras se completa el cambio.
  7. Rotar las credenciales antiguas una vez confirmado el funcionamiento y eliminar accesos anteriores.
  8. Documentar auditoría, copias, recuperación y responsabilidades.

12. Errores habituales que hay que evitar

  • Dar por protegido un secreto porque aparece cifrado en PostgreSQL cuando el mismo proceso puede descifrarlo sin restricciones.
  • Guardar un token de administrador permanente de Vault en el mismo .env de producción.
  • Trasladar secretos a otra máquina sin configurar permisos mínimos o aislamiento de red.
  • Confundir rotación de la clave de cifrado con revocación de la credencial que autoriza una API.
  • Guardar secretos en logs, volcados de errores, repositorios o tickets.
  • Migrar todos los secretos de golpe sin plan de reversión ni copias.
  • Suponer que las credenciales temporales se renuevan solas sin implementar correctamente su ciclo de vida.

13. ¿Cuándo merece la pena un servidor separado?

Resulta razonable cuando existen numerosos servicios, requisitos de segregación, auditoría o credenciales de alto impacto, y personal capaz de mantener la plataforma. Para una aplicación pequeña, operar un clúster Vault puede ser más complejo que utilizar un servicio gestionado de secretos y una identidad de máquina bien configurada. Lo importante es que los controles sean proporcionales al riesgo, probados y mantenibles.

Fuentes y lecturas recomendadas