Rotación de secretos sin una página a las 3 AM
La rotación que exige una ventana de mantenimiento no es rotación — es riesgo diferido que todos evitan hasta que las credenciales filtran. Los periodos de gracia con doble clave permiten que producción acepte secretos viejos y nuevos durante el rollover para que nadie reciba una página a las 3 AM.
La API key tenía dieciocho meses. La política de seguridad decía rotar trimestralmente. Nadie rotó porque rotar significaba: generar clave nueva, actualizar el vault, redesplegar todos los servicios simultáneamente, rezar para que nada cachee la clave vieja, hacer rollback si algo fallaba. La rotación se convirtió en una negociación trimestral que siempre perdía contra el trabajo de features — hasta que una clave apareció en una exportación de logs. La rotación de secretos sin caída no es un checkbox de feature del vault. Es una decisión de arquitectura: los sistemas aceptan dos credenciales válidas durante una ventana de gracia, los deploys avanzan gradualmente, y las claves viejas se retiran solo después de que el tráfico demuestre uso cero.
Los secretos que no pueden rotarse sin downtime no rotan. Envejecen. Los secretos envejecidos son impacto de brecha predecible. El objetivo es una rotación lo bastante aburrida para ejecutarse en schedule — automatizada, reversible e invisible para los usuarios.
Why rotation breaks production
| Failure mode | Cause |
|---|---|
| Validación de clave única | El servicio acepta solo un secreto activo |
| Deploy simultáneo requerido | Todos los consumidores deben actualizar en la misma ventana |
| Credenciales cacheadas | El SDK o el pool de conexiones retiene el secreto viejo tras la actualización |
| Variables de entorno hardcodeadas | La rotación exige redeploy por instancia |
| Sin telemetría de uso | No se puede confirmar que la clave vieja está inactiva antes de revocar |
| God-key compartida | Doce servicios, una rotación coordina doce deploys |
Los sistemas de clave única fuerzan rotación big-bang — el mismo modo de falla que las migraciones de schema big-bang. Los periodos de gracia con doble clave aplican lógica expand/contract a las credenciales: expand (agregar clave nueva como válida), migrate (consumidores toman la clave nueva), contract (revocar clave vieja tras la prueba).
Un runbook de rotación que empieza con "programar mantenimiento" es un documento que no se ejecutará trimestralmente.
Dual-key grace period pattern
Durante el periodo de gracia, los validadores aceptan ambas key_current y key_next:
Phase 1 — Expand
Vault: key_v1 (active), key_v2 (issued, not yet deployed)
Validators: accept v1 only
Phase 2 — Migrate
Deploy services with key_v2 in config (v1 still works)
Validators: accept v1 OR v2
Monitor: log which key ID signed each request
Phase 3 — Contract
All traffic on v2 (metrics confirm)
Validators: accept v2 only
Revoke v1
Duración del periodo de gracia: lo suficiente para que todos los consumidores desplieguen al menos una vez — típicamente 24–72 horas con cadencia de deploy diaria, más para equipos con deploy semanal o partners externos.
Para claves de firma JWT y secretos de cliente OAuth, el mismo patrón aplica con kid (key ID) en los headers del token — los validadores buscan la clave pública o el secreto correcto por ID. OAuth scopes and authorization design cubre el scoping de credenciales; la rotación es más fácil cuando cada servicio tiene secretos acotados en lugar de una god-key compartida.
Rotation by secret type
| Secret type | Rotation approach | Grace period notes |
|---|---|---|
| API keys (internal) | Validación dual-key en gateway | Log key ID por request |
| Database passwords | Usuario con dos passwords o dos usuarios DB | Drain del connection pool en deploy |
| TLS certificates | Periodos de validez superpuestos | Práctica estándar — aplicar la misma disciplina a API keys |
| JWT signing keys | JWKS con múltiples entradas kid | Publicar clave nueva antes del switch de firma |
| Third-party API keys | Depende del proveedor; a menudo manual | Escalonar: clave nueva activa antes de revocar la vieja |
| CI/CD tokens | Tokens duales válidos en config del pipeline | Patrones de CI/CD secrets in production |
Rotación de base de datos sin caída: crear app_user_v2 con password nueva, otorgar privilegios idénticos, desplegar apps apuntando conexiones nuevas a credenciales v2, drenar pools de conexión viejos, eliminar usuario v1 cuando el conteo de conexiones sea cero.
Automation and observability for boring rotation
La rotación debería ser programable y alertable:
- Automated issuance — el vault genera
key_nexten schedule. - Deployment hooks — el pipeline CD inyecta la última versión del secreto; sin actualizaciones manuales por SSH.
- Key usage metrics — contar autenticaciones por key ID; el dashboard muestra progreso de migración v1 → v2.
- Revoke gate — check automatizado: uso de v1 = 0 por N horas antes de revocar; ack humano para producción.
- Rollback — si v2 causa errores, los validadores siguen aceptando v1 durante el periodo de gracia.
Alertar sobre: rotación vencida, periodo de gracia terminando con tráfico v1 restante, deploy fallido de nueva versión del secreto.
Zero trust for internal APIs asume que las credenciales rotan y tienen scope acotado — claves internas estáticas de larga duración sin rotación socavan el modelo.
Organizational habits that make rotation stick
Rotation owner per secret class. No "equipo de seguridad" en abstracto — owner nombrado para creds de base de datos, claves de API gateway, tokens CI.
Rotation in deploy path. Los servicios obtienen secretos del vault al startup y en intervalo — no solo en build time. La rotación sin redeploy es posible cuando las apps refrescan credenciales.
No secrets in git. Obvio pero bloquea automatización. Rotar secretos commiteados exige reescritura de historial — no es rotación.
Partner lead time. Las integraciones externas pueden necesitar semanas de aviso. Los periodos de gracia se extienden al SLA del partner, no solo a la cadencia de deploy interna.
Game day. Drill trimestral de rotación en staging — ciclo dual-key completo cronometrado y documentado. La rotación en producción debería ser mecánica ensayada, no cirugía novedosa.
How should teams implement outage-free secret rotation?
Estas decisiones evitan programas de rotación que mueren tras el primer intento fallido.
How long should dual-key grace periods last?
Como mínimo: dos ciclos completos de deploy de cada consumidor más el TTL del connection pool. Para deploys diarios, 48 horas es un piso razonable. Consumidores externos pueden necesitar 30 días — documentar en acuerdos con partners.
Can all secrets use dual-key validation?
No. Algunas APIs de terceros emiten una sola clave activa. Mitigación: solicitar segunda clave con anticipación, superponer manualmente, aceptar ventana breve de riesgo. Secretos internos — control total — siempre deberían soportar dual-key.
When should old keys revoke automatically vs manually?
Automatizar revocación cuando las métricas muestran uso cero por periodo definido Y tasa de error estable en clave nueva. Ack manual para secretos tier-0 (pago, claves raíz de auth). Nunca auto-revocar sin telemetría de uso — revocar en silencio causa caídas peores que secretos envejecidos.
A common argument runs the other way
La visión opuesta sostiene que la rotación frecuente incrementa el riesgo — que cambiar credenciales a menudo crea más fallos inducidos por deploy de los que previene por robo de credenciales.
La frecuencia de rotación debería coincidir con el tier de riesgo. Claves internas de baja sensibilidad pueden rotar anualmente con soporte dual-key. Claves de alta sensibilidad rotan trimestralmente o ante cambio de personal. La alternativa a la rotación no es estabilidad — es duración de exposición desconocida cuando las claves filtran. La rotación dual-key reduce el riesgo de deploy a casi cero cuando se respetan los periodos de gracia.
NIST y los marcos de compliance esperan cada vez más capacidad de rotación — no teatro de rotación, sino capacidad probada de cambiar credenciales sin caída.
Key takeaways
- La rotación que exige ventanas de mantenimiento no ocurre — los secretos envejecen hasta la brecha.
- Periodos de gracia dual-key: validadores aceptan credenciales viejas y nuevas durante el rollover.
- Log key ID por autenticación para confirmar uso cero de clave vieja antes de revocar.
- La rotación de base de datos usa usuarios o passwords duales con drain del connection pool.
- Automatizar emisión, inyección en deploy, métricas de uso y gates de revocación.
- Ensayar ciclo completo de rotación en staging trimestralmente.
Conclusion
La rotación de secretos sin una página a las 3 AM es una propiedad de diseño, no un recordatorio de calendario. Los sistemas que aceptan dos claves durante ventanas de gracia rotan un martes a las 2 PM como cualquier otro deploy. Los sistemas que aceptan una clave rotan en postmortems de incidentes.
El paso de inventario: listar cada secreto de producción, marcar si la rotación dual-key está soportada hoy, marcar fecha de última rotación. Las brechas en soporte dual-key son trabajo de ingeniería; las brechas en fechas de rotación son riesgo acumulándose a la vista.