Todo equipo llega tarde o temprano al punto en que las credenciales
están en demasiados sitios: un .env en cada dispositivo, un mensaje fijado en
Slack, una hoja de cálculo llamada «accesos», una variable de CI que
alguien configuró hace dos años. Un gestor de secretos en la nube sirve
para reunir todo eso en un único lugar cifrado, con control de acceso y
auditado.
Esta guía explica qué hace un gestor de secretos en la nube, cómo elegir entre las opciones principales, cómo implantarlo sin una migración larga y la única tarea que no cubre: hacer llegar un secreto a una persona que no está dentro de tu cuenta en la nube.
Qué hace un gestor de secretos en la nube
Un gestor de secretos guarda valores confidenciales y se los entrega a las identidades autorizadas cuando los piden. Las funciones básicas son las mismas en todos los proveedores:
- Almacenamiento cifrado en reposo, con claves guardadas en el servicio de gestión de claves del proveedor, y TLS en tránsito.
- Acceso basado en identidades: cada secreto tiene una política que indica qué usuarios, roles o cargas de trabajo pueden leerlo, escribirlo o rotarlo. Una aplicación se autentica con su propia identidad, no con una contraseña maestra.
- Registro de auditoría de cada lectura, escritura y rotación, con quién, qué y cuándo.
- Versiones y rotación: se puede preparar un valor nuevo, pasar las aplicaciones a él y retirar la versión antigua. Muchos gestores rotan las credenciales de bases de datos de forma automática.
- Obtención en tiempo de ejecución: la aplicación pide el secreto al arrancar o cuando lo necesita, así que el valor nunca se escribe en el código, en las imágenes ni en los archivos de configuración.
Un secreto es cualquier cosa que da acceso. La configuración que solo describe un comportamiento, como un número de puerto o un feature flag, va en la configuración normal. Mezclar ambas cosas llena de ruido el almacén de secretos y vuelve peligrosa la configuración.
Cómo elegir uno
La decisión suele depender de dónde se ejecutan tus cargas de trabajo y de en cuántas nubes estás.
| Opción | Encaja mejor con | Ojo con |
|---|---|---|
| AWS Secrets Manager / Parameter Store | Cargas de trabajo que ya están en AWS, identidades IAM en todas partes | Precio por secreto en Secrets Manager; Parameter Store es más barato para valores simples |
| Google Secret Manager | Proyectos de GCP, cargas de trabajo en Cloud Run y GKE | Las opciones de replicación regional |
| Azure Key Vault | Cargas de trabajo en Azure, gestión del ciclo de vida de certificados | Usar bóvedas separadas por entorno para que las políticas sigan siendo simples |
| HashiCorp Vault | Multinube o en local, credenciales dinámicas de corta duración | Tener que operarlo tú, salvo que uses la versión alojada |
| Doppler, Infisical, 1Password Secrets Automation | Equipos pequeños que quieren sincronizar con muchas plataformas de forma cómoda para desarrolladores | Un proveedor más en la cadena de confianza |
Cuatro preguntas resuelven la mayoría de las elecciones. ¿Se integra con tus herramientas de despliegue y tu entorno de ejecución sin escribir código de integración a medida? ¿Pueden las cargas de trabajo autenticarse con la identidad que ya tienen? ¿Rota los tipos de credenciales que de verdad usas? ¿Y llegan sus registros de auditoría adonde tu equipo de seguridad ya mira? El precio, las regiones y las certificaciones de cumplimiento vienen después de esas cuatro.
Cómo implantarlo sin un proyecto de seis meses
- Haz inventario y asigna responsables. Anota cada secreto, dónde está, qué lo usa y quién responde de él. El responsable decide la política de rotación y la lista de acceso.
- Configura primero las identidades. Crea los roles o las cuentas de servicio de cada carga de trabajo y entorno antes de mover un solo valor. Las políticas de acceso del tipo «este servicio, este entorno, solo lectura» son el objetivo de todo esto.
- Migra por orden de riesgo. Primero las contraseñas de bases de datos de producción y las claves de pago, después las claves de API de terceros y luego todo lo demás. Quita cada valor del código, de las variables de CI y de los archivos de configuración a medida que lo migras, y rótalo al migrarlo, porque el valor antiguo ya se ha copiado por ahí.
- Cambia cómo leen los secretos las aplicaciones. Sustituye los valores escritos en el código y los archivos de entorno por una llamada al SDK del gestor al arrancar, o inyéctalos con la integración nativa de la plataforma.
- Activa la rotación de todo lo que el gestor pueda rotar por sí mismo, y escribe una función de rotación o un procedimiento para el resto.
- Configura alertas para lo inusual. Una lectura de un secreto desde una identidad nueva, un pico de lecturas o una lectura desde una región en la que no despliegas merecen un aviso a quien esté de guardia.
Los errores habituales son previsibles: dejar las copias antiguas en su sitio tras la migración, dar a una carga de trabajo acceso de lectura a todo el almacén en lugar de solo a sus secretos y escribir el valor obtenido en los registros de la aplicación.
El hueco que no cubre un gestor de secretos
Un gestor de secretos está hecho para máquinas y para las personas que están dentro de tu sistema de identidades. No está hecho para el momento en que una credencial tiene que llegar a alguien de fuera: un colaborador externo que necesita una contraseña temporal de base de datos, un cliente que recibe su primer acceso de administrador, un ingeniero de un proveedor que necesita un token durante una tarde, una persona recién contratada en su primer día, antes de que exista su cuenta de SSO.
Esas entregas ocurren igualmente y, sin una vía autorizada, ocurren por correo y por chat, justo de donde los gestores de secretos debían sacar las credenciales. La vía autorizada es un enlace secreto de un solo uso. El valor se cifra en tu navegador antes de guardarse, el mensaje solo lleva un enlace, la copia almacenada se destruye la primera vez que se abre el enlace y el enlace expira pasado un tiempo si nadie lo abre.
El patrón que funciona: el gestor de secretos es el sistema de referencia, y el enlace de un solo uso es el medio de entrega cuando una persona de fuera del sistema necesita un valor una vez. Genera la credencial, guárdala en el gestor, envíasela a la persona con un enlace de un solo uso y rótala cuando termine su acceso. Enlaces secretos frente a gestores de contraseñas aplica el mismo razonamiento al gestor de contraseñas del equipo, y la guía sobre credenciales entre equipos explica la rutina.
Una lista de comprobación breve
- Cada secreto tiene un responsable, una política de acceso y una regla de rotación.
- Las cargas de trabajo se autentican con su propia identidad, nunca con una clave compartida.
- Tras la migración, no queda ningún secreto en el código, las imágenes, las variables de CI ni el chat.
- Las lecturas se registran en un sitio que alguien mira de verdad.
- Las personas de fuera del sistema de identidades reciben los secretos con un enlace de un solo uso, no en un mensaje.
Haz esas cinco cosas y el gestor de secretos dejará de ser un producto que compraste para convertirse en la razón por la que las credenciales dejaron de filtrarse.