Secretos dinámicos en BBDD con Vault

Introducción

La gestión de credenciales es crítica en cualquier aplicación, y ahí es donde los secretos dinámicos en BBDD marcan la diferencia. Muchas organizaciones siguen usando contraseñas estáticas: se crean una vez, se almacenan en archivos o variables de entorno y rara vez se actualizan.

Este enfoque, aunque práctico, representa un riesgo enorme. Una contraseña filtrada en un repositorio o la falta de rotación periódica puede abrir la puerta a incidentes graves, como lo destacan los principales reportes de seguridad. Precisamente, de esto mismo hablaba en un artículo anterior.

HashiCorp Vault ofrece una solución clara: generar credenciales efímeras bajo demanda, con vencimiento automático y revocación inmediata. En este artículo veremos cómo aplicar esta capacidad en Bases de datos, sus beneficios frente a credenciales estáticas y cómo empezar a integrarla en tus aplicaciones.

1. El problema de las credenciales estáticas en BBDD

• Qué son.
• Ejemplos de fallas comunes.
• Por qué son peligrosas (no rotan, se comparten, se filtran).

Las credenciales estáticas de bases de datos son aquellas que se crean una sola vez y permanecen sin cambios durante largos periodos. Generalmente se almacenan en archivos de configuración (Ejm: appsettings.json, archivos .env o .properties), variables de entorno o incluso en repositorios de código. Aunque este enfoque es común por su simplicidad, trae consigo varios riesgos críticos:

1. Exposición accidental
   Un archivo con contraseñas puede filtrarse en un repositorio público o compartirse por error en un canal interno, quedando accesible para terceros.
2. Falta de rotación
   Las credenciales estáticas rara vez se actualizan. Una vez comprometidas, un atacante puede usarlas indefinidamente sin ser detectado.
3. Acceso excesivo
   Suelen otorgar permisos amplios (ej. acceso total a la base), lo que multiplica el impacto de un robo o abuso.
4. Riesgo con ex-empleados o terceros
   Si alguien deja la organización y conserva credenciales, puede mantener acceso no autorizado a información sensible.

En resumen, las credenciales estáticas representan una superficie de ataque amplia y difícil de controlar. Cuanto más tiempo existen y más personas tienen acceso a ellas, mayor es la probabilidad de que terminen expuestas o mal utilizadas.

2. ¿Qué son los secretos dinámicos en Vault?

Los secretos dinámicos en Vault son credenciales que no existen hasta que una aplicación o un usuario las solicita. En lugar de tener contraseñas fijas y reutilizadas, Vault genera credenciales únicas, efímeras y con un tiempo de vida limitado (TTL). Una vez vencidas, se revocan automáticamente y dejan de ser válidas.

Este enfoque transforma la seguridad en las BBDD y aplicaciones porque:

• Rotación automática: cada acceso obtiene credenciales nuevas sin intervención manual.
• Tiempo de vida corto: si un atacante las roba, pronto quedarán inservibles.
• Menor exposición: no es necesario guardar contraseñas en archivos ni variables.
• Trazabilidad: cada credencial emitida queda registrada, lo que facilita auditorías.

Ejemplo práctico:

Imagina una aplicación que necesita conectarse a una base de datos PostgreSQL.

• Con credenciales estáticas: usa el mismo usuario y contraseña durante meses o años, expuestos en archivos de configuración.
• Con secretos dinámicos en Vault: la app solicita acceso y recibe un usuario/contraseña válidos solo por unos minutos. Al expirar, Vault los revoca y el ciclo vuelve a empezar.

De esta forma, incluso si alguien intercepta las credenciales, el tiempo de ventana para explotarlas es mínimo.

3. Arquitectura de Vault para secretos dinámicos en BBDD

Para entender cómo funcionan los secretos dinámicos en BBDD con Vault, es clave visualizar la arquitectura que hace posible esta integración. El componente principal es el Motor de Secretos database, que se conecta a la base de datos y se encarga de generar, entregar y revocar credenciales bajo demanda.

El flujo general funciona así:

1. Aplicación / Usuario → solicita credenciales a Vault.
2. Vault → verifica permisos del solicitante mediante políticas.
3. Motor de Secretos database → crea dinámicamente un usuario en la base de datos con permisos definidos y un TTL asociado.
4. Base de Datos → acepta la conexión con esas credenciales temporales.
5. Vault → al expirar el TTL, revoca automáticamente las credenciales.

4. Configuración básica en Vault

Implementar secretos dinámicos en BBDD con Vault requiere habilitar y configurar el Motor de Secretos database. A continuación, un ejemplo sencillo usando PostgreSQL como base de datos.

4.1. Habilitar el engine de base de datos

vault secrets enable database

4.2. Configurar la conexión a la BBDD

Se define cómo Vault se conectará a la base de datos para crear usuarios dinámicos.

vault write database/config/my-postgresql-database \
    plugin_name=postgresql-database-plugin \
    allowed_roles="readonly-role" \
    connection_url="postgresql://{{username}}:{{password}}@db.example.com:5432/postgres?sslmode=disable" \
    username="admin" \
    password="admin_password"

4.3. Crear un rol para generar credenciales dinámicas

Aquí definimos qué permisos tendrán los usuarios efímeros.

vault write database/roles/readonly-role \
    db_name=my-postgresql-database \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
                         GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

4.4. Solicitar credenciales dinámicas desde Vault

Una aplicación o usuario puede pedir credenciales en cualquier momento:

vault read database/creds/readonly-role

Vault devolverá un usuario y contraseña temporales, válidos solo por el tiempo definido en el TTL. Una vez expirado, las credenciales serán revocadas automáticamente.

4.5. Resumen

Este ejemplo básico muestra cómo habilitar el flujo de credenciales dinámicas. En un entorno real, se recomienda integrar con aplicaciones mediante Vault Agent o librerías específicas, evitando exponer secretos directamente en código.

5. Integración con aplicaciones

Configurar secretos dinámicos en BBDD con Vault es útil, pero la clave está en integrarlos sin que los desarrolladores tengan que manejar manualmente credenciales. Existen dos enfoques principales:

5.1. Vault Agent o Vault Secrets Operator

Ya sea el Vault Agent o el Vault Secrets Operator, estos se ejecutan junto a la aplicación y gestionan automáticamente la autenticación y la entrega de credenciales. Puede inyectarlas en archivos temporales o variables de entorno, renovarlas cuando se acerque el vencimiento y revocarlas al finalizar.

• Ideal para aplicaciones o entornos donde no se desea modificar el código fuente de la aplicación.
• Ejemplo: un pod en Kubernetes monta un archivo JSON con un usuario y contraseña que el Agent o el Operator refrescan de forma transparente.

5.2. Librerías

HashiCorp y la comunidad mantienen librerías oficiales para distintos lenguajes (Go, Python, Java, Node.js). Con ellas, la aplicación puede conectarse directamente a Vault, solicitar credenciales dinámicas y usarlas en tiempo de ejecución.

• Útil cuando se quiere un control fino desde el código de la aplicación y hay recursos disponibles para hacerlo.
• Se requiere integrar dependencias y lógica de manejo de tokens.

5.3. Integración en pipelines CI/CD

Vault también puede inyectar credenciales dinámicas en procesos de CI/CD. Por ejemplo, durante la ejecución de tests, el pipeline obtiene un usuario temporal de la base y lo elimina automáticamente al terminar.

• Reduce riesgos en entornos de prueba.
• Evita exponer contraseñas en repositorios o variables permanentes.

6. Buenas prácticas para gestión de secretos dinámicos en BBDD

Para aprovechar al máximo los secretos dinámicos en BBDD, conviene aplicar estas prácticas:

1. Definir TTL cortos
   Credenciales válidas solo por minutos u horas. Cuanto menor sea la ventana de uso, menor es el riesgo en caso de fuga.
2. Usar roles granulares
   Evita otorgar permisos excesivos. Un rol de “solo lectura” debe poder leer, no modificar datos.
3. Automatizar la integración
   Implementa Vault Agent o pipelines que eliminen la gestión manual de credenciales por parte de los equipos.
4. Auditoría y monitoreo
   Aprovecha el registro que ofrece Vault: cada emisión y revocación de credenciales queda registrada, lo que ayuda en incidentes de seguridad y cumplimiento.
5. Revisar periódicamente configuraciones
   La seguridad no es estática. Ajusta roles, TTLs y políticas según evolucionen las necesidades de tus aplicaciones.

7. Conclusión y próximos pasos

Las credenciales estáticas en BBDD son uno de los eslabones más débiles en la seguridad de las aplicaciones. HashiCorp Vault, a través de los secretos dinámicos, elimina este riesgo generando credenciales efímeras, revocadas automáticamente y trazables en todo momento.

Adoptar esta práctica no solo mejora la seguridad, sino que también reduce la carga operativa en la gestión manual de usuarios y contraseñas.

En próximos artículos exploraremos cómo extender esta misma lógica a otros sistemas críticos, como LDAP, APIs y servicios en la nube, reforzando aún más la seguridad de tus aplicaciones con un enfoque cloud-agnostic.