Zero Trust ayuda a las organizaciones a reducir su superficie de ataque y responder a las amenazas más rápido, pero muchas todavía tienen dificultades para implementarlo porque sus herramientas de seguridad no comparten señales de manera confiable. El 88% de las organizaciones admiten que han sufrido desafíos importantes al intentar implementar tales enfoques, según acento. Cuando los productos no pueden comunicarse, las decisiones de acceso en tiempo real fracasan.
El Shared Signals Framework (SSF) tiene como objetivo solucionar este problema con una forma estandarizada de intercambiar eventos de seguridad. Sin embargo, la adopción es desigual. Por ejemplo, Kolide Device Trust actualmente no admite SSF.
Scott Bean, ingeniero sénior de IAM e seguridad de MongoDB, propuso una manera de resolver el problema, brindando a los equipos una manera fácil e intuitiva de poner en funcionamiento SSF en todo su entorno.
En esta guía, compartiremos una descripción general de flujo de trabajoademás de instrucciones paso a paso para ponerlo en funcionamiento.
El problema: las herramientas IAM no son compatibles con SSF
Un requisito fundamental de Zero Trust son las señales continuas y confiables sobre la postura del usuario y del dispositivo. Pero muchas herramientas no son compatibles con SSF para el Protocolo de evaluación de acceso continuo (CAEP), lo que dificulta compartir o actuar en función de estas señales.
Los equipos suelen enfrentar tres desafíos:
- Las herramientas carecen de soporte SSF nativo
- Las señales requieren enriquecimiento o correlación.
- La gestión de puntos finales SSF y el manejo de tokens añaden gastos generales
Sin esta interoperabilidad, las organizaciones luchan por aplicar políticas coherentes y, en casos como el de Kolide Device Trust, los eventos críticos de dispositivos nunca llegan a sistemas como Okta.
La solución: un transmisor SSF que convierte los problemas de Kolide en eventos CAEP
Debido a que SSF se basa en solicitudes HTTPS, el estándar OpenID funciona con la acción HTTP de Tines.
Scott desarrolló un nuevo flujo de trabajo integración de Kolide Device Trust con Tinespermitiéndole enviar señales SSF a Okta. Si un dispositivo no cumple, Kolide envía un mensaje al flujo de trabajo a través de un webhook. Tines enriquece la señal, se asegura de que pueda vincularse a un usuario, crea un token de evento de seguridad (SET) y luego lo envía a Okta.
De esta manera, Tines actúa como tejido conectivo que hace que SSF funcione en todo el entorno de TI distribuido, incluso si las herramientas individuales no admiten el estándar de forma nativa.
Las púas pueden:
- Reciba señales de Kolide (y herramientas similares) a través de webhook cuando un dispositivo deja de ser compatible
- Enriquecer y correlacionar esas señales. (por ejemplo, asignar el dispositivo al usuario)
- Generar y firmar SET que cumplen con la especificación SSF
- Entréguelos a Okta (y a otros proveedores de identidad) para hacer cumplir la Confianza Cero
- Puntos finales de metadatos SSF requeridos por el host usando prefijos de ruta API, brindando a los sistemas consumidores un lugar compatible con los estándares para recuperar claves y descifrar tokens
Todo lo cual hace que la aplicación de Zero Trust sea más rápida, más confiable y mucho más fácil de poner en práctica. Los equipos de TI cuentan con una evaluación de riesgos continua y en tiempo real de los dispositivos, una respuesta más rápida a las amenazas y una orquestación de políticas más flexible. Y los usuarios finales obtienen el beneficio de la corrección automatizada, que ayuda a optimizar la productividad y minimizar la intervención de TI.
Si quieres profundizar en la modernización de la identidad, el Guía IAM de púas explora cómo los equipos están unificando la confianza en los dispositivos, las decisiones de acceso y la aplicación de privilegios mínimos con la automatización. El flujo de trabajo de Scott es uno de varios patrones internos del mundo real.
Descripción general del flujo de trabajo
Herramientas necesarias:
- Púas – orquestación del flujo de trabajo y plataforma de IA
- kolide – confianza del dispositivo y monitoreo de postura
- Okta – plataforma de identidad que recibe eventos CAEP
Credenciales requeridas:
- Clave API de Tines: `Equipo` con el alcance del rol `Editor`
- Clave API de Kolide: solo lectura
- Secreto de firma de Kolide Webhook
Recursos necesarios:
Dominio Okta, como ejemplo.okta.com, ejemplo.oktapreview.com o un dominio de marca.
Cómo funciona:
El flujo de trabajo crea un transmisor SSF de prueba de concepto que se puede registrar con Okta y envía eventos CAEP de cambio de cumplimiento del dispositivo (enviados como SET), en función de los problemas generados en Kolide. Hay tres elementos:
1. Generar y almacenar claves de firma SET (Los SET son tokens web JSON firmados):
- Crea un par de claves RSA y lo convierte al formato JWK.
- Publica la clave pública para que los receptores SSF validen las firmas SET.
- Almacena el conjunto de claves JWK privado como un secreto de Tines.
2. Exponer la API del transmisor SSF
Los receptores SSF (como Okta) necesitan:
- un punto final de configuración .well-known/sse que describe el transmisor
- un punto final JWK que expone la clave pública utilizada para verificar las firmas SET
- un activador de webhook actúa como superficie API de SSF
- la lógica devuelve la configuración .well-known
- la lógica devuelve los JWK
Una vez que esto esté activo, los equipos pueden registrar un nuevo receptor SSF en Okta en:
- Seguridad → Integraciones de dispositivos → Recibir señales compartidas
Y cree una nueva secuencia utilizando la URL de la API y el nuevo punto final `.well-known`
3. Crear, firmar y enviar SET de eventos Kolide
- Recibe Kolide asunto eventos a través de webhook y los valida utilizando el secreto de firma.
- Obtiene metadatos de dispositivo y usuario de Kolide.
- Construye un SET para un Cambio de cumplimiento del dispositivo Evento CAEP.
- Firma el SET con la clave privada almacenada utilizando la fórmula JWT_SIGN.
- Envía el token firmado al punto final de eventos de seguridad de Okta.
Esto ofrece actualizaciones de cumplimiento de dispositivos en tiempo real a Okta para que las políticas de acceso puedan responder de inmediato.
Configurar el flujo de trabajo: una guía paso a paso
Puede crear y ejecutar todo este flujo de trabajo utilizando Edición comunitaria de Tines.
1. Inicie sesión en Tines o cree una cuenta nueva.
2. Navegue hasta el flujo de trabajo prediseñado en la biblioteca. Seleccione importar. Esto debería llevarlo directamente a su nuevo flujo de trabajo prediseñado.
3. Reúna las credenciales requeridas
- Clave API de Tines (ámbito de equipo con función de editor)
- Clave API de Kolide (solo lectura)
- Secreto de firma de Kolide Webhook
Estos garantizan llamadas autenticadas a Kolide y una validación segura del webhook.
4. Reúna los recursos necesarios
Necesitará un dominio de inquilino de Okta, como por ejemplo:
- ejemplo.oktapreview.com
- ejemplo.okta.com
- o su dominio personalizado de la marca Okta
Este dominio se utiliza al enviar SET firmados al punto final de eventos de seguridad de Okta.
Nota: En el ejemplo proporcionado, Scott se configuró como un proveedor «push» en lugar de «encuesta», ya que los tokens se envían en función de los webhooks entrantes, por lo que no es necesario almacenar el estado..
5. Genere sus claves de firma SET
- Utilice la acción Generar conjunto de claves JWK para crear claves RSA
- Convierta claves públicas y privadas al formato JWK (dos transformaciones de eventos)
- Almacene el conjunto de claves resultante utilizando un secreto de Tines
Esto es necesario antes de que Okta acepte y verifique sus SET.
6. Publicar la API del transmisor SSF
El webhook de la API de SSF contiene dos ramas:
- .punto final conocido
- Desencadenante: conocido
- Transformación de evento: devuelve la configuración de SSF declarando las capacidades del transmisor
- Punto final JWKS
- Desencadenante: JWK
- Transformación de evento: devuelve los JWK públicos para que Okta pueda verificar las firmas
Una vez activo, Okta puede registrar este transmisor como remitente de señales compartidas.
7. Conecte Kolide y procese los problemas del dispositivo
El flujo de integración de Kolide sigue estos pasos:
- Webhook: Kolide webhook: recibe eventos de problemas abiertos/resueltos
- Obtener detalles del dispositivo: recupera metadatos para el dispositivo involucrado
- El dispositivo tiene un usuario: lógica de ramificación para confirmar que un usuario está asociado
- Obtenga detalles del usuario: busque metadatos del usuario para la carga útil CAEP
Dependiendo de si el problema es nuevo o está resuelto:
- Build SET: construye el evento CAEP device_compliance_change
- Firmar SET: utilice la clave privada RSA almacenada anteriormente para producir un SET compatible con SSF
- Enviar SET: envía el token firmado final al punto final de eventos de seguridad de Okta
Tan pronto como Okta recibe y verifica el SET, el nivel de riesgo del usuario asociado se actualiza.
Reuniéndolo todo
SSF existe para ayudar a que las herramientas de seguridad hablen el mismo idioma, brindando información continua sobre el riesgo y la postura del dispositivo. Pero cuando las herramientas clave no respaldan el estándar, se abren brechas y las políticas de acceso van a la zaga de los cambios del mundo real.
Tines cierra estas brechas al permitir nuevos flujos de trabajo inteligentes. Garantizan que incluso las herramientas que no son compatibles con SSF puedan enviar información de la misma forma estandarizada. Al utilizar Tines para generar, firmar y entregar señales de cumplimiento en tiempo real, obtiene los beneficios de SSF incluso cuando la herramienta fuente no fue diseñada para ello.
Si desea probar este flujo de trabajo usted mismo, puede activarlo en minutos con un cuenta gratuita de Tines. Y si desea ver cómo la postura del dispositivo encaja en una estrategia de identidad más amplia, esta guía para flujos de trabajo de IAM modernos ofrece patrones prácticos y flujos de trabajo del mundo real como el de Scott que puede comenzar a desarrollar hoy mismo.