¿Cómo se deben gestionar realmente los secretos — variables de entorno vs. un vault (HashiCorp Vault/AWS KMS/Secrets Manager)?

#La línea base: variables de entorno

Sacar los secretos del código fuente y ponerlos en variables de entorno es el primer paso, necesario — y para una enorme cantidad de aplicaciones, también es donde termina la historia de gestión de secretos. Un archivo .env (excluido de git), cargado en el entorno del proceso al iniciar, es muchísimo mejor que una clave de API hardcodeada. Es simple, todo framework lo soporta de forma nativa, y detiene el peor de los fallos posibles: un secreto commiteado a un repositorio público.

Pero las variables de entorno tienen límites reales que solo se notan cuando los buscas:

• Sin rotación sin un deploy. Cambiar la contraseña de una base de datos significa editar la variable y reiniciar cada proceso que la lee — no hay forma de empujar un valor nuevo sin un redeploy o un reinicio manual.
• Sin registro de auditoría. No puedes responder "quién leyó este secreto y cuándo" — la variable simplemente vive en el espacio de memoria del proceso, legible por cualquier cosa con acceso a ese proceso (incluyendo, en muchos sistemas, cualquiera que pueda inspeccionar el entorno de ese proceso en el host).
• Radio de impacto amplio. Un proceso comprometido típicamente tiene acceso a todos los secretos que necesita el servicio, no solo al que está usando activamente — no hay una política de acceso granular.
• Dispersión. La misma contraseña de base de datos a menudo termina copiada y pegada en una docena de archivos .env a través de servicios, pipelines de CI y laptops de desarrolladores, sin un lugar único desde el cual revocarla.
• Filtración accidental. Las variables de entorno terminan volcadas en reportes de crash, registradas por manejadores de error demasiado verbosos, o impresas por un comando de depuración que alguien corrió investigando un problema no relacionado.

#Qué agrega realmente un vault

Un gestor de secretos (HashiCorp Vault, AWS Secrets Manager, AWS KMS específicamente para el caso de claves de cifrado, GCP Secret Manager, Azure Key Vault) es un servicio diseñado para almacenar secretos de forma centralizada y entregarlos bajo política, en lugar de incrustarlos en cada entorno que los necesita. Las capacidades concretas que las variables de entorno no pueden replicar:

• Credenciales dinámicas y de corta duración. En lugar de una contraseña de base de datos estática compartida por cada instancia del servicio, Vault puede generar un usuario de base de datos único con un TTL de 15 minutos por solicitud de un secreto — si se filtra, ya expiró para cuando un atacante pueda usarlo.
• Rotación centralizada. Rota el secreto subyacente una vez, en un solo lugar, y cada consumidor que lo obtiene fresco (en lugar de cachearlo para siempre) recibe el nuevo valor — sin un redeploy coordinado a través de una docena de servicios.
• Política de acceso granular. Un servicio de pagos puede tener acceso concedido solo a la credencial de la base de datos de pagos y nada más, aplicado por el propio vault en lugar de por convención.
• Un registro de auditoría real. Cada acceso a un secreto queda registrado con una identidad, una marca de tiempo y un lease (concesión) — lo cual convierte un "creemos que pudimos haber sido vulnerados" en un "esto exactamente es lo que el servicio comprometido pudo haber leído, y cuándo".
• Expiración automática. Un lease que no se renueva simplemente deja de ser válido, así que el acceso de un servicio dado de baja no persiste como sí lo hace un archivo .env olvidado en un servidor viejo que nadie volvió a desplegar.

#Cómo se conecta realmente a una aplicación

El punto de diseño importante en este diagrama: la aplicación nunca se autentica ante el vault con un secreto estático embebido — se autentica usando una identidad que la plataforma ya avala (un rol IAM de la nube adjunto a la instancia, un token de service account de Kubernetes?, una credencial AppRole pre-aprovisionada e inyectada al momento del deploy). Eso es lo que rompe la circularidad de "necesitas un secreto para obtener tus secretos" — la credencial de arranque está acotada estrechamente (solo puede pedirle a Vault una cosa) y es de por sí de corta duración, ligada al propio sistema de identidad de la plataforma, el cual ya estás confiando para ejecutar la carga de trabajo en primer lugar.

#Cuándo vale la pena la complejidad adicional

Para un equipo pequeño que corre un solo servicio con un puñado de secretos, un .env bien gestionado (o el parameter store básico de tu proveedor de nube, cifrado en reposo, controlado por IAM) es una elección razonable y honesta — correr un clúster de Vault agrega una sobrecarga operativa real (otro sistema con estado que mantener altamente disponible, desellar y respaldar). La ecuación cambia cuando tienes: múltiples servicios compartiendo credenciales, un requisito de cumplimiento que exige rotación y registros de auditoría (PCI-DSS, SOC 2), secretos cuyo compromiso tiene un radio de impacto desproporcionado (la credencial de administrador de una base de datos de producción, la clave de API de un procesador de pagos), o suficientes servicios como para que "redesplegar todo para rotar una contraseña" se haya vuelto una operación genuinamente dolorosa.