Zero Trust ayuda a las empresas a reducir su superficie de ataque y responder a las amenazas más rápido. Sin embargo, a muchos todavía les resulta difícil implementarlo porque sus herramientas de seguridad no transmiten señales de manera confiable. Según Accenture, el 88% de las empresas admiten haber enfrentado desafíos importantes al implementar estos enfoques.. Cuando los productos no pueden comunicarse, las decisiones de acceso en tiempo real fallan.
El Marco de Señales Compartidas (SSF) tiene como objetivo abordar este problema a través de un método estandarizado de intercambio de eventos de seguridad. Sin embargo, la aceptación es inconsistente. Por ejemplo, Kolide Device Trust actualmente no admite SSF.
Scott Bean, ingeniero sénior de IAM e seguridad de MongoDB, sugirió una forma de resolver el problema y brindar a los equipos una forma sencilla e intuitiva de implementar SSF en su entorno.
En esta guía proporcionamos una descripción general del flujo de trabajo, así como instrucciones paso a paso para la puesta en servicio.
El problema: las herramientas IAM no son compatibles con SSF
Un requisito fundamental de Zero Trust son las señales continuas y confiables sobre el estado del usuario y del dispositivo. Sin embargo, muchas herramientas no son compatibles con SSF para el Protocolo de evaluación de acceso continuo (CAEP), lo que dificulta compartir o responder a estas señales.
Los equipos suelen enfrentar tres desafíos:
- Las herramientas carecen de soporte nativo para SSF.
- Las señales requieren enriquecimiento o correlación.
- La gestión de puntos finales y de tokens de SSF genera una sobrecarga adicional
Sin esta interoperabilidad, a las organizaciones les resulta difícil 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
Dado que SSF se basa en solicitudes HTTPS, el estándar OpenID funciona con la acción HTTP de Tines.
Scott ha desarrollado un nuevo flujo de trabajo que integra Kolide Device Trust con Tines y le permite 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, garantiza 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 garantiza 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 si un dispositivo ya no es compatible
- Enriquecer estas señales y correlacionarlas (por ejemplo, asignar 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
- Alojar los puntos finales de metadatos SSF necesarios Los prefijos de ruta API brindan a los sistemas consumidores un lugar compatible con los estándares para recuperar claves y descifrar tokens.
Todo esto hace que la aplicación de Zero Trust sea más rápida, más confiable y mucho más fácil de implementar. Los equipos de TI obtienen una evaluación continua de los riesgos de los dispositivos en tiempo real, una respuesta más rápida a las amenazas y una orquestación de políticas más flexible. Y los usuarios finales se benefician de la corrección automatizada que ayuda a optimizar la productividad y minimizar las intervenciones de TI.
Si quieres profundizar en la modernización de la identidad, aquí lo tienes. La guía IAM de Tines explora cómo los equipos equilibran 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 del mundo real que existen.
Descripción general del flujo de trabajo
Herramientas necesarias:
- puntas – Orquestación del flujo de trabajo y plataforma de IA.
- kolide – Monitoreo de postura y confianza del dispositivo
- Okta – Plataforma de identidad que recibe eventos del CAEP
Credenciales requeridas:
- Clave API de Tines: “Equipo” con el rol de “Editor”.
- Clave API de Kolide: solo lectura
- Secreto de firma del webhook de Kolide
Recursos necesarios:
Dominio Okta como ejemplo.okta.com, ejemplo.oktapreview.com o un dominio de marca.
Así es como funciona:
El flujo de trabajo crea un transmisor SSF de prueba de concepto que se puede registrar con Okta y envía eventos CAEP para cambios de cumplimiento del dispositivo (enviados como SET) en función de los problemas generados en Kolide. Hay tres elementos:
1. Genere y guarde la clave 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 destinatarios de SSF validen las firmas SET.
- Almacena la clave privada JWK configurada como un secreto de Tines.
2. Exponer la API del remitente SSF
Los receptores SSF (como Okta) requieren:
- un punto final .well-known/sse-configuration que describe al remitente
- un punto final JWK que expone la clave pública utilizada para verificar las firmas SET
- Un activador de webhook actúa como una superficie API de SSF
- La lógica devuelve la configuración conocida.
- La lógica devuelve los JWK.
Una vez en vivo, los equipos podrán registrar un nuevo destinatario de SSF en Okta en:
- Seguridad → Integraciones de dispositivos → Recibir señales compartidas
Y cree una nueva secuencia con la URL de la API y el nuevo punto final “.well-known”
3. Cree, firme y envíe SET de eventos Kolide
- Recibe Kolide producción Eventos a través de webhook y los valida utilizando el secreto de firma.
- Obtiene metadatos de dispositivo y usuario de Kolide.
- Crea un SET para un Cambio en el 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 del evento 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 Tines Community Edition.
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 (equipo relacionado con el rol de editor)
- Clave API de Kolide (solo lectura)
- Secreto de firma del webhook de Kolide
Estos garantizan llamadas autenticadas a Kolide y una validación segura del webhook.
4. Reúna los recursos necesarios
Necesita un dominio de inquilino de Okta, como por ejemplo:
- ejemplo.oktapreview.com
- ejemplo.okta.com
- o su dominio personalizado con la marca Okta
Este dominio se utiliza al enviar SET firmados al punto final del evento de seguridad de Okta.
Nota: En el ejemplo proporcionado, Scott se configuró como un proveedor de “empuje” en lugar de “encuesta” porque los tokens se envían en función de los webhooks entrantes, por lo que no se requiere almacenamiento estatal..
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).
- Guarde el conjunto de claves resultante con un secreto de Tines
Esto es necesario antes de que Okta acepte y verifique sus SET.
6. Publicar la API del remitente SSF
El webhook de la API de SSF contiene dos ramas:
- .punto final conocido
- Desencadenante: conocido
- Transformación de eventos: Devuelve la configuración SSF que indica las capacidades del remitente
- Punto final JWKS
- Desencadenante: JWK
- Transformación de eventos: devuelve los JWK públicos para que Okta pueda verificar las firmas
Una vez en línea, Okta puede registrar esa estación como una estación 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 sobre problemas abiertos/resueltos
- Obtener detalles del dispositivo: obtiene metadatos para el dispositivo afectado
- El dispositivo tiene lógica de ramificación de usuarios para confirmar que un usuario está asignado
- Recuperar detalles de usuario: buscar metadatos de usuario para la carga útil CAEP
Dependiendo de si el problema es nuevo o está resuelto:
- Compilación SET: crea el evento CAEP device_compliance_change.
- Firmar SET: utilice la clave privada RSA previamente guardada para crear un SET compatible con SSF
- Enviar SET: envía el token firmado final al punto final de eventos de seguridad de Okta
Una vez que Okta reciba y revise el SET, se actualizará el nivel de riesgo del usuario asociado.
Reuniendo todo
SSF está diseñado para ayudar a que las herramientas de seguridad hablen el mismo idioma y proporcionen información continua sobre el riesgo y el estado del dispositivo. Pero cuando las herramientas clave no respaldan el estándar, surgen brechas y las políticas de acceso van a la zaga de los cambios reales.
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 si la herramienta fuente no fue diseñada para ello.
Si desea probar este flujo de trabajo usted mismo, puede configurarlo en minutos con una cuenta gratuita de Tines. Y si desea ver cómo el estado del dispositivo encaja en una estrategia de identidad más amplia, esta guía de flujos de trabajo de IAM modernos proporciona patrones prácticos y flujos de trabajo del mundo real como el de Scott que puede aprovechar hoy.
About The Author
