Seguridad de identidades no humanas: gestión de secretos y accesos máquina
Cómo probar la rotación y revocación de tokens de máquina
Rotar una credencial de máquina requiere saber qué proceso la usa, qué alcance conserva y qué ocurre con el token anterior. Un token para entrar en un gestor de secretos no es necesariamente la contraseña o clave que el servicio obtiene después. Esta guía ordena una prueba controlada y separa autenticación, permisos, revocación y sesiones del sistema destino.
Equipo de El Rankeador · Guía editorial con asistencia de IA · Revisada: 2026-10-12
Un caso ficticio para preparar tu prueba
El servicio ficticio inventario-sync obtiene una credencial de una bóveda para consultar un API interno. El CSV propone seis comprobaciones pendientes en un entorno de ensayo; no contiene tokens reales ni representa una rotación ejecutada. Usa identificadores sintéticos, oculta valores y sigue el procedimiento específico del método de autenticación desplegado.
Descargar plantilla CSV del ejemplo
La plantilla reúne datos ficticios. Adapta campos, formato y referencias al producto y al entorno separado que vas a evaluar.
| caso_id | comprobacion | resultado_esperado | estado | referencia_no_secreta |
|---|---|---|---|---|
| TM-01 | Inventariar servicio, propietario y consumidores del token | Todos los procesos que podrían seguir usando el token anterior están identificados | Pendiente | Usar nombre de servicio ficticio |
| TM-02 | Separar token de acceso, secreto recuperado y sesión de destino | Cada credencial y mecanismo de revocación tiene sistema responsable y prueba propia | Pendiente | No copiar valores secretos |
| TM-03 | Consultar TTL, solapamiento y efecto de emitir un token nuevo | La secuencia coincide con el producto, método y versión configurados | Pendiente | Guardar URL de documentación |
| TM-04 | Cambiar un consumidor de ensayo a la credencial nueva | La autenticación funciona y conserva sólo los permisos esperados | Pendiente | Usar endpoint y datos de prueba |
| TM-05 | Probar el rechazo del token antiguo y el acceso del nuevo | El anterior deja de autenticar en el ámbito probado; el nuevo sigue operando | Pendiente | Anotar código de resultado, nunca el token |
| TM-06 | Comprobar por separado la clave y la sesión del sistema destino | El token del gestor deja de autenticar; la clave expuesta y las sesiones activas se revisan por separado según el procedimiento del destino | Pendiente | Registrar responsable y hora |
Comprobaciones paso a paso
Dibuja el flujo antes de tocar una credencial
Anota el servicio y su propietario, el método que lo autentica en el gestor, los procesos consumidores y el destino al que se conecta. Separa el token de autenticación del gestor de la contraseña, clave API o token que el servicio recupera después; añade sesiones y conexiones activas como elementos distintos. Registra alias e identificadores, nunca los valores secretos.
Qué conservar: Servicio, propietario, consumidores, método, credencial de acceso, credencial del destino y registro que permite observar cada prueba.
Comprueba el procedimiento exacto del método
Revisa en la documentación del producto qué significa emitir, rotar, expirar y revocar ese tipo de credencial. Por ejemplo, 1Password documenta un plazo configurable para que expire el token anterior durante la rotación; Akeyless documenta dos operaciones distintas: rotar un token UID reinicia su TTL y conserva sus funciones y permisos; generar uno desde la consola cuando ya existe restablece el token actual. No son intercambiables. En AppRole de Vault, RoleID, SecretID, políticas y TTL son componentes diferentes. No conviertas un ejemplo de proveedor en una regla universal.
Qué conservar: Versión, método, comportamiento del token anterior, ventana de cambio, políticas y límites aplicables.
Prepara un ensayo aislado y observable
Usa un consumidor de pruebas y un destino no productivo con permisos equivalentes pero datos sintéticos. Verifica qué lectura o acción debe permitirse y cuál debe denegarse. Comprueba que los registros muestran la identidad y la operación sin guardar tokens ni datos sensibles; define cómo restablecer el ensayo si la nueva credencial no autentica.
Qué conservar: Consumidor de ensayo, permiso permitido, permiso denegado, evento esperado y procedimiento de recuperación.
Cambia un solo consumidor a la credencial nueva
Entrega la credencial nueva mediante el canal previsto y actualiza un consumidor canario. Prueba autenticación, acceso permitido, rechazo de una acción fuera de alcance y renovación o caducidad si forman parte del flujo. Comprueba los registros del gestor y del servicio destino. Si falla una comprobación, detén el despliegue y usa el procedimiento de recuperación; no pegues el secreto en tickets o capturas.
Qué conservar: Hora, alias de la nueva credencial, consumidor cambiado, pruebas positivas y negativas y errores sin valores secretos.
Retira la credencial antigua según la ventana real
Antes de revocar, localiza los consumidores pendientes y respeta el solapamiento que el método realmente permite. Confirma que el consumidor canario sigue funcionando con la nueva credencial; después, prueba que la anterior ya no consigue iniciar una autenticación nueva. No supongas que revocar el token del gestor invalida una clave recuperada o termina una sesión abierta en otro sistema: comprueba y, cuando proceda, rota o cierra esos accesos en el destino.
Qué conservar: Consumidores migrados, criterio y hora de revocación, rechazo del token viejo, estado del token nuevo y acciones independientes en el destino.
Cierra la prueba con evidencia útil y segura
Guarda resultados, responsables, versión y referencias documentales con los valores redactados. Comprueba que no quedan consumidores sin propietario, tokens en registros de despliegue ni rutas de recuperación apoyadas en la credencial retirada. Si el token se cambió por una exposición, sigue además el proceso de respuesta a incidentes y revisa las credenciales y sesiones del destino.
Qué conservar: Resultado final, pendientes, alertas, propietario de cada excepción y próxima fecha de revisión.
Resultado esperado del ejercicio
Estos puntos describen la referencia del caso ficticio y lo que debes comprobar. No son resultados medidos en un proveedor.
- Cada servicio y consumidor tiene un propietario y un alias no secreto para la credencial probada.
- El plan distingue el token del gestor, el secreto recuperado y la autenticación o sesión del sistema destino.
- La nueva credencial funciona con el alcance esperado y falla fuera de él en el ensayo definido.
- La credencial anterior deja de autenticar según el comportamiento documentado y probado para ese método.
- Las claves ya recuperadas y las sesiones activas se revisan por separado; no se asume que el token de acceso las retire.
- Los resultados permanecen como pendientes hasta ejecutar las pruebas; la plantilla no acredita una evaluación real.
Documentación que puedes contrastar
Las siguientes afirmaciones proceden de las fichas revisadas. Sirven para identificar capacidades y condiciones del producto; el ejemplo y su protocolo son una propuesta editorial de El Rankeador.
HashiCorp Vault
HashiCorp Vault documenta AppRole como mecanismo para generar tokens destinados a autenticación de máquinas.
El método debe habilitarse y configurarse · Las políticas determinan las acciones autorizadas ✓ Verificado
Akeyless
Akeyless declara que su plataforma gestiona secretos, claves, certificados e identidades de máquina mediante un único motor de políticas, modelo operativo e interfaz.
Cobertura declarada por Akeyless · Los tipos de identidad, conectores, funciones y edición contratada deben confirmarse para cada entorno · La plataforma común no demuestra por sí sola eficacia ni reducción de riesgo ✓ Verificado
Referencias para la metodología
- HashiCorp Vault: autenticación AppRole
Distingue el AppRole y sus políticas, RoleID, SecretID, restricciones de acceso y límites temporales; comprueba la ruta y configuración exactas de tu instalación.
- Akeyless: Universal Identity
Describe por separado generación, asociación a un rol, rotación con reinicio del TTL, revocación y emisión desde la consola; consulta la operación que vayas a probar.
- 1Password: gestionar cuentas de servicio
Explica cómo definir la caducidad del token anterior al rotar y que revocarlo elimina su acceso a las bóvedas del proveedor.
Preguntas frecuentes
¿La rotación del token cambia también sus permisos?
No lo presupongas. 1Password documenta que el token nuevo de una Service Account conserva los mismos permisos; si necesitas otro alcance, revisa el procedimiento para cambiar o recrear la identidad. En Vault, las políticas asociadas al AppRole son un control distinto del cambio del SecretID o del token.
¿El token nuevo siempre puede convivir con el anterior?
No. El periodo de solapamiento depende del producto y del método: 1Password permite definir cuándo expira el token actual al rotarlo, mientras que la documentación de Akeyless diferencia la rotación UID —que conserva funciones y permisos y reinicia el TTL— de generar un token desde la consola, que puede restablecer el UID ya existente. Confirma el comportamiento de tu interfaz y versión en un ensayo aislado antes de programar el cambio.
¿Revocar el token del gestor invalida las claves y sesiones del servicio destino?
No lo des por hecho. La revocación puede limitarse al acceso al gestor; una clave que el proceso ya recuperó y una sesión abierta en la API o base de datos tienen mecanismos propios. Comprueba ambas por separado y rota la credencial del destino o termina sesiones si el procedimiento aplicable lo requiere.
Volver a comparar alternativas · Cómo se revisan las fuentes