Planificador de rotación de claves
Elige los tipos de credenciales de tu stack y obtén un runbook de rotación por tipo que impone el orden seguro: generar, verificar, desplegar, monitorizar y solo después revocar.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
Eliges los tipos de credenciales de tu stack y obtienes un runbook de rotación por tipo que impone el único orden seguro, más una cadencia recomendada y notas de solapamiento sin tiempo de inactividad. El orden seguro son siempre los mismos cinco pasos: (1) generar la nueva credencial, (2) verificarla con una llamada autenticada real, (3) desplegarla en todos los consumidores, (4) monitorizar los errores y (5) solo entonces revocar la antigua. Nunca generes y revoques en un mismo paso: una rotación que no puedes verificar antes de que muera la credencial antigua es un bloqueo, y recuperarse de uno puede costar un día entero. Cubre claves de acceso de AWS, contraseñas de bases de datos, claves de API de terceros, certificados TLS/SSL, claves SSH, secretos de cliente OAuth, claves de firma de JWT y tokens, y claves de cuentas de servicio en la nube, con notas de solapamiento donde la plataforma admite dos credenciales activas. El resultado es un checklist con seguimiento que puedes ir marcando y un runbook en texto plano que puedes copiar o descargar. Todo se ejecuta en el lado del cliente y no se envía nada. Es una herramienta Pro.
- Selecciona los tipos de credenciales de tu stack.
- Revisa el runbook de cada tipo, con los cinco pasos en el orden seguro, la cadencia recomendada y las notas de solapamiento.
- Ve marcando el checklist a medida que rotas.
- Copia o descarga el runbook en texto plano y contrástalo con la documentación actual de tu proveedor.
Preguntas frecuentes
¿Cuál es el orden seguro para rotar una credencial?
Siempre: (1) generar la nueva credencial, (2) verificar que funciona haciendo una llamada autenticada real con ella, (3) desplegarla o actualizar todos los consumidores para que la usen, (4) monitorizar los errores para confirmar que nada sigue usando la antigua y (5) solo entonces revocar o borrar la credencial antigua. La regla crítica es no generar la nueva y revocar la antigua en el mismo paso. Si revocas antes de haber demostrado que la sustituta funciona y está en uso en todas partes, un solo error (una errata en un secreto, un servicio que olvidaste, una copia en caché) se convierte en un bloqueo sin vuelta atrás. Una rotación que no puedes verificar antes de que muera la credencial antigua es solo una caída con pasos extra.
¿Cada cuánto debo rotar claves y secretos?
La cadencia depende de la credencial y de tu riesgo, y debes seguir la orientación actual de tu proveedor, pero puntos de partida habituales son: claves de acceso en la nube de larga duración y claves de cuentas de servicio, más o menos cada 90 días; contraseñas de bases de datos, cada 90 días o de inmediato ante la salida de una persona o una sospecha de exposición; claves de API de terceros, cada 90 días o según la política del proveedor; secretos de cliente OAuth, cada 6 a 12 meses; claves de firma de JWT, alrededor de cada 90 días con identificadores de clave solapados; claves SSH, al menos una vez al año y de inmediato cuando se va un operador; y certificados TLS, bastante antes de que caduquen (los emitidos por ACME se renuevan solos, a menudo en ciclos de 60 a 90 días). Las rotaciones más importantes no se programan: se hacen de inmediato ante cualquier sospecha de compromiso.
¿Cómo roto credenciales sin tiempo de inactividad?
Usa la capacidad de la plataforma de tener más de una credencial activa para que la antigua y la nueva se solapen. AWS IAM permite dos claves de acceso activas por usuario, así que creas la segunda, cambias todo a ella y borras la primera. El authorized_keys de SSH admite muchas claves a la vez, así que añades la nueva clave pública en todas partes y compruebas el acceso antes de quitar la antigua. Un JWKS puede publicar la clave pública antigua y la nueva, para que los tokens ya firmados con la antigua sigan validando hasta que caduquen. Muchos proveedores de identidad permiten dos secretos de cliente, y la mayoría de las cuentas de servicio en la nube admiten varias claves. En TLS, el certificado nuevo y su cadena completa deben ser de confianza y estar sirviéndose antes de retirar el antiguo: nunca dejes caducar el antiguo antes de que el nuevo esté activo.
¿Por qué no generar una clave nueva y borrar la antigua a la vez?
Porque pierdes tu única red de seguridad. Entre generar y borrar hay varias formas de quedarte bloqueado: la nueva credencial puede tener alcances o permisos erróneos, un consumidor puede no haberla recogido aún, un almacén de secretos o una variable de CI pueden seguir guardando el valor antiguo, o el valor nuevo puede haberse copiado con un error. Si la credencial antigua ya no existe cuando aparece cualquiera de esos fallos, no tienes ninguna credencial que funcione y a menudo ninguna forma de autenticar la acción que necesitarías para arreglarlo. Mantener viva la antigua hasta que la nueva esté verificada y desplegada del todo hace que todo modo de fallo sea recuperable: sigues usando la antigua mientras investigas.
¿Se envía a un servidor algo de lo que introduzco?
No. El planificador se ejecuta por completo en tu navegador. Solo lee qué tipos de credenciales seleccionas y arma un runbook a partir de plantillas integradas; no hace llamadas de red, así que nada de lo que eliges o escribes sale de tu máquina. El runbook generado es una orientación general para planificar una rotación segura, no asesoramiento profesional; sigue siempre la documentación de rotación actual y oficial de tu proveedor para los comandos y opciones exactos.
¿Es gratis?
No, es una herramienta Pro. Con una cuenta gratuita tienes 3 usos de prueba de herramientas Pro en total; después necesitas Pro.