Planteamiento y contexto
El receptor verifica solicitudes de webhooks firmadas mientras un proveedor cambia el secreto. La rotación debe tolerar reintentos en tránsito y múltiples réplicas del emisor sin exponer el secreto ni crear una brecha de verificación.
Qué evalúa el entrevistador
- Preservar la verificación de firmas sobre el cuerpo en crudo y la comparación en tiempo constante.
- Diseñar una superposición acotada entre los secretos activos y los que están en proceso de retiro.
- Separar el estado de rotación, la protección contra repetición, la observabilidad y la reversión.
Preguntas aclaratorias antes de responder
- ¿Quién controla la rotación y puede el emisor exponer un identificador de clave o versión?
- ¿Cuánto pueden durar los reintentos de entrega y el desfase de reloj?
- ¿Puede el emisor coordinar una ventana de firma dual o debe el receptor aceptar dos secretos?
- ¿Qué ID de evento, marca de tiempo y payload en crudo están disponibles para las comprobaciones de repetición?
Estructura de respuesta en 30 segundos
Aprovisionaría un nuevo secreto, lo distribuiría a cada receptor e iniciaría una ventana de superposición corta. Durante la superposición, verificaría una firma seleccionada por ID de clave o probaría el secreto actual y el saliente con comprobaciones en tiempo constante, mientras aplico una tolerancia de marca de tiempo y deduplicación por ID de evento. Las métricas deben mostrar qué versión verifica, y la rotación se completa solo después de que el tráfico de la versión antigua permanezca en cero durante el horizonte de reintentos. La reversión mantiene el secreto saliente hasta que se cierre la ventana.
Análisis detallado paso a paso
1. Preservar los bytes firmados
Lee el cuerpo de la solicitud una sola vez como bytes en crudo antes del parseo de JSON. Construye la entrada de la firma exactamente como especifica el proveedor, incluyendo las reglas de delimitadores y marcas de tiempo. Compara los MAC en tiempo constante y rechaza temprano los payloads mal formados o de tamaño excesivo.
2. Modelar las versiones de los secretos
Almacena las versiones activas y salientes con hora de creación, expiración, alcance del proveedor y un estado como PENDING, OVERLAP o RETIRED. Es preferible un identificador de clave porque evita la verificación por prueba y error; si no está disponible, acota el mecanismo de respaldo de dos secretos y registra qué secreto tuvo éxito.
3. Desplegar de forma segura
Distribuye el nuevo secreto a través del gestor de secretos, recarga los receptores de forma atómica y ejecuta un canary firmado. Solicita al emisor firmar de forma dual o cambiar solo después de observar la preparación del sistema. Mantén disponible el secreto antiguo durante la duración máxima de reintentos más el margen de desfase de reloj.
4. Bloquear repeticiones
Exige una marca de tiempo firmada dentro de una tolerancia acotada y almacena un ID de evento o resumen con un período de retención que cubra los reintentos. La verificación debe realizarse antes de encolar; las entregas válidas duplicadas pueden confirmar la recepción con éxito sin repetir los efectos de negocio.
5. Observar y retirar
Cuenta los éxitos de verificación por versión de clave, marcas de tiempo obsoletas, ID duplicados, firmas mal formadas y resultados en cola sin registrar secretos ni payloads sensibles completos en los logs. Retira la versión antigua solo después de que transcurran los horizontes de superposición y reintentos; si la nueva versión falla, restaura la anterior y genera una alerta.
Respuesta de ejemplo de alta calidad
«Prepararía una nueva versión en el gestor de secretos, recargaría cada receptor y verificaría un canary antes de cambiar el emisor. Para una superposición acotada, aceptaría firmas de las versiones actual y saliente, preferiblemente seleccionadas por un ID de clave, mientras verifico una marca de tiempo firmada y deduplico los ID de eventos. Haría seguimiento de la verificación por versión y esperaría a que concluyera el horizonte de reintentos del emisor más el desfase de reloj antes de retirarla. Si la nueva versión falla, la reversión mantiene válido el secreto antiguo; los logs contienen contadores e ID, nunca secretos ni payloads en crudo».
Errores comunes
- Reemplazar el secreto en todas partes a la vez → fallan los reintentos con la firma antigua → usar una ventana de superposición.
- Parsear JSON antes de la verificación → los bytes canónicos pueden cambiar → verificar primero el cuerpo en crudo.
- Aceptar cualquiera de los dos secretos para siempre → las credenciales obsoletas permanecen válidas → establecer una expiración vinculada a los límites de reintento y desfase.
- Registrar en logs la firma o el secreto → la observabilidad se convierte en fuga de credenciales → registrar contadores versionados e identificadores seguros.
Preguntas de seguimiento y respuestas
¿Qué pasa si el emisor no puede firmar de forma dual?
Precarga el nuevo secreto y acepta ambas versiones en el receptor durante una ventana acotada. Coordina el cambio en el emisor, monitorea la verificación específica por versión y conserva la versión antigua durante el período máximo de reintentos.
¿Cómo eliges la duración de la superposición?
Utiliza el límite máximo de reintentos documentado por el emisor, los retrasos de encolamiento, la tolerancia al desfase de reloj y un margen de incidentes. Haz que la fecha límite sea explícita y genera alertas sobre el tráfico de la versión antigua cerca de su expiración en lugar de estimarla a partir de la latencia promedio.
¿Qué pasa si un atacante repite un evento válido antiguo?
Rechaza las marcas de tiempo fuera de la tolerancia y deduplica los ID de eventos o los resúmenes de payloads firmados. Mantén los registros de repetición al menos durante la ventana de marca de tiempo aceptada y el horizonte de reintentos del negocio.