Entrevista de diseño de sistemas: ¿cómo diseñarías un servicio multi-tenant de rotación de secretos?

Pregunta

Diseña un servicio multi-tenant de rotación de secretos. Un tenant puede configurar una contraseña de base de datos, una clave de API de terceros o un certificado, junto con su período de rotación. El servicio genera un nuevo valor, actualiza el sistema externo, almacena una versión, notifica gradualmente a las cargas de trabajo y retira el valor antiguo. Cubre la recuperación, la concurrencia, la auditabilidad, la autorización y el rollback.

Qué evalúa el entrevistador

• Si modelas la rotación como una máquina de estados reintentable en lugar de un script de cron no recuperable.
• Si manejas mensajes duplicados, trabajos concurrentes para un mismo secreto y el aislamiento de tenants.
• Si puedes preparar dos versiones y desplegar gradualmente en lugar de provocar un fallo inmediato en toda la flota.
• Si puedes explicar el retiro, la respuesta ante incidentes de seguridad, la evidencia de auditoría y el principio de mínimo privilegio.

Respuesta modelo

Los objetos centrales son Secret, Version inmutables, RotationPolicy, Job y Lease. Un programador (scheduler) emite un trabajo para la siguiente hora de rotación; una cola se particiona mediante secret_id, y un worker adquiere un lease con expiración. Una restricción de unicidad en la base de datos sobre (secret_id, idempotency_key) hace que los reintentos sean seguros.

Utiliza una máquina de estados como scheduled → generating → external_updated → staged → rolling_out → verified → retired. Persiste el identificador de solicitud externa, la versión y la próxima hora de reintento en cada paso. Crea primero la credencial en el proveedor externo y luego almacena una versión pendiente. Las cargas de trabajo cambian gradualmente mediante una referencia de versión inmutable o un mecanismo de actualización (refresh). Promueve la versión a actual solo después de que pasen las comprobaciones de estado de salud (health checks), las tasas de error y las pruebas de autorización.

Mantén los metadatos de control separados de las cargas útiles de secretos cifrados. Las aplicaciones reciben permisos de lectura de corta duración. Cada transición de estado se envía a un registro de auditoría de solo anexado (append-only) sin texto plano del secreto. El rollback selecciona una versión antigua que aún sea válida; no debe revocar automáticamente esa versión antes de que se complete la recuperación.

Esquema de arquitectura

Scheduler -> Durable Queue -> Rotation Workers
     |              |              |
 Policy DB     Lease/Idempotency  External Provider
     |                             |
 Version Store + KMS        Rollout Controller -> Workloads
     |
 Audit Log / Metrics / Alerts

Los workers renuevan los leases; tras la expiración, otro worker puede tomar el control. Los mensajes de la cola contienen únicamente identificadores de secretos y trabajos. Un worker lee los valores de un almacén de versiones restringido, manteniendo el texto plano fuera de los mensajes, registros y etiquetas de métricas.

Flujo crítico

1. El programador crea un trabajo idempotente y aplica las cuotas del tenant.
2. Un worker adquiere el lease y lee la versión y la política actuales; un trabajo completado retorna de forma segura.
3. Genera un valor y llama al proveedor con una clave de idempotencia del lado del proveedor.
4. Escribe una versión pendiente y ejecuta comprobaciones de compatibilidad y un despliegue reducido.
5. Observa la tasa de errores, el éxito de la autenticación y los sondeos de salud; solo entonces promueve a actual.
6. Una vez que todos los consumidores han confirmado, deshabilita y destruye la versión antigua; los fallos se reintentan o ejecutan un rollback.

Persiste el estado y las respuestas externas en cada paso. Al reiniciar, continúa desde el último estado en lugar de adivinar si el proveedor ya fue modificado.

Errores comunes

• Almacenar únicamente la próxima hora en cron, sin dejar un punto de recuperación tras un reinicio o entrega duplicada.
• Revocar el valor antiguo de inmediato, ignorando pools de conexiones, cachés y conexiones de larga duración.
• Poner texto plano en colas, registros, trazas (tracing spans) o mensajes de error.
• Usar un único bloqueo global para todos los tenants, u omitir las cuotas de tenants de modo que uno solo agote los workers.
• Tratar el rollback como escribir el valor antiguo nuevamente sin comprobar que aún sea válido y esté activo.

Compensaciones de consistencia y seguridad

Utiliza una base de datos fuertemente consistente para la máquina de estados y las restricciones de unicidad. Las notificaciones y el despliegue pueden ser at-least-once, por lo que los consumidores deben ser idempotentes. Las lecturas de versiones pueden almacenarse en caché brevemente, pero los cambios en la versión actual y las revocaciones requieren una ruta de invalidación explícita. La autorización de tenants limita el acceso a sus propios secretos, trabajos y registros de auditoría; los workers reciben únicamente los permisos de proveedor requeridos para el paso actual.

Los períodos de rotación deben considerar el tipo de clave, el riesgo de exposición, los límites del proveedor y las ventanas de recuperación, en lugar de basarse únicamente en un temporizador fijo. La guía de gestión de claves de NIST trata el período de uso, el propósito, el nivel de protección y la revocación como una sola decisión de política.

Inyecta fallos cuando un worker se bloquee antes y después de cada transición de estado, cuando los mensajes se dupliquen, los leases expiren, los proveedores agoten el tiempo de espera, falle un despliegue parcial y la base de datos sufra un failover. Verifica que un trabajo no cree credenciales externas duplicadas, que exactamente una versión pase a ser la actual y que el valor antiguo se revoque solo después de la ventana de confirmación. Prueba también el aislamiento de tenants, la ofuscación en auditorías y la latencia de las alertas.

• Flujo de rotación AWSPENDING/AWSCURRENT de AWS Secrets Manager: etiquetas de staging y pasos de finalización.
• Guía de rotación de Google Cloud Secret Manager: reintentos, rotaciones no concurrentes, despliegue gradual y limpieza de versiones antiguas.
• NIST SP 800-57 Parte 1: propósito de la clave, protección, período de uso y principios de revocación.

Preguntas de seguimiento

¿Cómo evitas que dos workers roten un secreto al mismo tiempo?

Utiliza un lease de base de datos o un bloqueo distribuido con un fencing token, y escribe el token en cada actualización de estado. Un worker recuperado sin el token actual no puede sobrescribir un estado más reciente; los leases necesitan renovación y una expiración clara.

¿Qué sucede si el proveedor no tiene una API idempotente?

Persiste una huella digital de la solicitud (request fingerprint) y el identificador de recurso externo en el trabajo, luego consulta al proveedor antes de reintentar. Si el proveedor no se puede consultar, pausa el paso para confirmación humana en lugar de crear a ciegas más credenciales.

¿Por qué no dejar que cada aplicación lea latest?

latest puede enviar un valor no verificado a toda la flota de inmediato. Las versiones inmutables, el despliegue escalonado y las comprobaciones de salud contienen el radio de impacto y preservan un punto de rollback.

¿Cómo proteges el servicio cuando se acumulan los trabajos de rotación?

Establece cuotas de concurrencia por tenant y proveedor, utiliza prioridades y retroceso exponencial (exponential backoff), y expón la antigüedad del trabajo más antiguo, la tasa de fallos y la ventana de recuperación restante. Los secretos próximos a expirar pueden priorizarse sin eludir la autorización o la idempotencia.

¿Qué hace el servicio después de un compromiso de seguridad?

Pausa las programaciones ordinarias para los trabajos afectados, crea una rotación de emergencia de alta prioridad, acorta la ventana de observación del despliegue y retén los registros forenses. Confirma que los consumidores críticos hayan cambiado antes de revocar el valor antiguo y notifica al tenant y al proceso de respuesta de seguridad.