Evaluación continua del acceso ante cambios de postura del dispositivo

La brecha de sesión después del inicio de sesión

Muchos entornos SSO evalúan la postura al autenticar y después confían en la sesión o el token hasta su vencimiento o renovación. Durante ese intervalo pueden cambiar el cifrado, el heartbeat del agente, la gestión o la atestación sin que la aplicación modifique automáticamente su decisión.

La evaluación continua transmite cambios antes del vencimiento normal, pero no garantiza detección, entrega o aplicación instantáneas.

Por qué los tokens más cortos solo son una salvaguarda

Una vida útil menor limita cuánto tiempo se acepta un bearer token sin cambios, pero no vuelve continua la evaluación. Sin revocación, introspección o una señal actual, el token sigue siendo válido hasta vencer.

Mantenga duraciones acotadas como defensa adicional y use evaluación por eventos cuando un cambio de postura deba afectar una sesión activa.

SSF y CAEP: la capa de estándares

OpenID Shared Signals Framework 1.0 define streams y el intercambio de Security Event Tokens. Un SET de RFC 8417 es un JWT firmado que transporta un evento, no una assertion de autenticación ni un permiso de API.

Continuous Access Evaluation Profile 1.0 define eventos que pueden afectar al acceso vigente. SSF y CAEP son especificaciones finales de OpenID desde 2025, aunque la cobertura varía.

CAEP es descriptivo: el transmisor informa y la política del receptor decide si deniega, revoca, exige reautenticación, reduce permisos o solo registra.

Eventos CAEP relevantes

• Device compliance change. Comunica un cambio de cumplimiento; el receptor debe correlacionar dispositivo, usuario, sesiones y recursos.
• Session revoked. Indica una sesión revocada; cada punto de aplicación debe poder rechazarla.
• Credential change. Comunica un cambio de credencial que puede exigir revisión o reautenticación.
• Token claims change. Comunica que cambiaron claims asociados a tokens emitidos.
• Assurance level change. Comunica un cambio de garantía que puede exigir step-up o acceso limitado.

Un flujo de aplicación defendible

• 1. Detectar. Una fuente de postura observa el cambio y distingue estados no conforme, desconocido, obsoleto y error.
• 2. Normalizar. La evidencia se asigna a una transición y un subject estable, conservando fuente, hora y versión de política.
• 3. Transmitir. Se envía un SET firmado por push o poll con el contexto mínimo necesario.
• 4. Validar y correlacionar. El receptor verifica el evento y resuelve dispositivo, usuario, sesiones y recursos sin ambigüedad.
• 5. Decidir. La política evalúa evento, sensibilidad, vigencia, excepciones y sesión.
• 6. Aplicar. La decisión llega a gateway, aplicación, resource server o servicio de sesiones y se verifica.
• 7. Explicar y auditar. El usuario recibe motivo y recuperación; detección, decisión y resultado quedan registrados.

Validar más que la firma JWT

• Aceptar solo emisores y relaciones de stream configurados; validar algoritmo y clave.
• Validar audiencia, tipo de evento, claims obligatorios, formato de subject y tiempos.
• Usar jti para impedir replay y procesar de forma idempotente.
• Gestionar rotación de claves y actualización de metadatos.
• Proteger la correlación entre tenants, dispositivos y sesiones; tratar la ambigüedad como error.

Diseñar para señales tardías, duplicadas y desordenadas

Push y poll pueden fallar, reintentar o entregar eventos fuera de orden. Se necesitan reintentos acotados, acuses, deduplicación, supervisión de cola, dead letters y una regla de orden basada en datos temporales confiables.

Una recuperación antigua no debe sustituir un bloqueo más reciente. Defina fuentes autoritativas, vigencia y respuesta cuando los transmisores discrepan o están fuera de servicio.

Elegir un patrón acorde con la arquitectura de sesión

• Estado central. Un servicio compartido marca sesiones bloqueadas o limitadas.
• Caché de revocación o política. Gateways consumen una versión de estado, fecha revoked-after o entrada de denegación.
• Introspección. La aplicación consulta si el token sigue activo, creando una dependencia que debe ser resiliente.
• Invalidación directa. Un procesador distribuye cambios con confirmación y conciliación.
• Salvaguarda por tiempo. Tokens y sesiones acotados evitan acceso indefinido si falla la ruta de señales.

Qué demuestra el soporte actual

• Microsoft Entra. Microsoft documenta CAE para servicios, clientes, eventos críticos y ubicación compatibles. No cubre todo CAEP; puede haber hasta 15 minutos de propagación y límites adicionales.
• Jamf Security Cloud. Jamf documenta un transmisor SSF de device-compliance-change para gestión Apple. El receptor sigue siendo responsable de correlación y aplicación.
• Keycloak. En julio de 2026 el transmisor SSF es experimental, está desactivado por defecto y no se recomienda para producción; Keycloak no actúa como receptor general de postura.

Preguntas para proveedores

• ¿Qué cambios generan señal, cómo se detectan y cuál es la latencia completa?
• ¿Qué versiones, eventos, formatos de subject y entregas SSF/CAEP se admiten?
• ¿Qué acción provoca cada evento por tipo de recurso?
• ¿Cómo se autentican, deduplican, ordenan, reintentan, supervisan y concilian los eventos?
• ¿Cómo se correlacionan dispositivo, usuario, tenant y sesión sin cruces?
• ¿Qué ocurre con postura obsoleta, ausente, contradictoria o restaurada?
• ¿Qué aplicaciones, APIs y canales aplican el cambio antes del vencimiento?

Aplicación en una evaluación de Gideon

Evalúe Gideon Identity y Endpoint Management como una ruta completa de señal a aplicación. Verifique condiciones, vigencia, correlación, decisión, aplicación y recuperación. Exija mediciones por plataforma y señal, no una promesa universal de tiempo real.

Lecturas relacionadas

• Separe controles de credencial, dispositivo y sesión con Autenticación vinculada al dispositivo frente a MFA convencional.
• Revise vigencia y ciclo de vida en Gestión zero-touch de endpoints para equipos de seguridad.
• Descubra Gideon Identity.

Fuentes primarias

• OpenID Foundation define streams, transmisores y receptores en OpenID Shared Signals Framework 1.0 Final.
• Los eventos están en OpenID CAEP 1.0 Final.
• IETF define los SET en RFC 8417.
• Microsoft documenta la evaluación continua en Entra.
• Jamf documenta SSF y CAEP.
• Keycloak documenta su soporte SSF experimental.

Cómo usar este recurso

Mapee un cambio de postura de alto impacto desde detección hasta recuperación. Mida cada entrega, pruebe duplicados y desorden, verifique bloqueo y recuperación en aplicaciones representativas y conserve la evidencia como criterio de aceptación.