Zero Trust puede ayudar a las organizaciones a reducir su superficie de ataque y responder rápidamente a las amenazas, pero muchas empresas todavía tienen dificultades para implementar Zero Trust porque las herramientas de seguridad no comparten señales de manera confiable. Según Accenture, el 88% de las organizaciones admiten que enfrentaron desafíos importantes al implementar este enfoque. Si los productos no pueden comunicarse, las decisiones de acceso en tiempo real no funcionarán.
El Shared Signals Framework (SSF) tiene como objetivo resolver este problema con una forma estandarizada de intercambiar eventos de seguridad. Sin embargo, el reclutamiento varía. Por ejemplo, Kolide Device Trust actualmente no es compatible con SSF.
Scott Bean, ingeniero sénior de IAM e seguridad de MongoDB, propuso una solución al problema que proporciona una forma fácil e intuitiva para que los equipos operen SSF en sus entornos.
Esta guía proporciona una descripción general del flujo de trabajo e instrucciones paso a paso para ponerlo en funcionamiento.
Problema: las herramientas de 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 el SSF del Protocolo de evaluación de acceso continuo (CAEP), lo que dificulta compartir estas señales y actuar en consecuencia.
Los equipos suelen enfrentar tres desafíos:
Las herramientas carecen de soporte nativo para SSF. Se requiere enriquecimiento o correlación de señales. La gestión de puntos finales SSF y el procesamiento de tokens aumenta la sobrecarga.
Sin esta interoperabilidad, las organizaciones luchan por hacer cumplir políticas consistentes. Y en casos como el de Kolide Device Trust, los eventos importantes del dispositivo nunca llegan a sistemas como Okta.
Solución: transmisor SSF que convierte los problemas de Kolide en eventos CAEP
SSF se basa en solicitudes HTTPS, por lo que el estándar OpenID funciona con acciones HTTP en Tines.
Scott desarrolló un nuevo flujo de trabajo que integra Kolide Device Trust con Tines, lo que les permite enviar señales SSF a Okta. Si el dispositivo no es compatible, Kolide envía un mensaje al flujo de trabajo a través de un webhook. Tines fortalece la señal, verifica que se pueda vincular al usuario, crea un token de evento de seguridad (SET) y lo envía a Okta.
De esta manera, Tines actúa como tejido conectivo que hace que SSF funcione en entornos de TI distribuidos, incluso cuando 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 webhooks cuando un dispositivo deje de ser compatible. Enriquecer y correlacionar esas señales (por ejemplo, asignar dispositivos a los usuarios). Generar y firmar un SET que cumpla con las especificaciones SSF. Entregar a Okta (y otros proveedores de identidad) para aplicar los puntos finales de metadatos SSF requeridos en hosts Zero Trust utilizando prefijos de ruta API, proporcionando a los sistemas consumidores una ubicación compatible con los estándares para recuperar claves y descifrar tokens.
Todo esto hace que la aplicación de la confianza cero sea más rápida, más confiable y mucho más fácil de operar. Los equipos de TI pueden realizar evaluaciones continuas de riesgos de los dispositivos en tiempo real, responder rápidamente a las amenazas y ajustar las políticas de manera más flexible. Los usuarios finales también se benefician de la corrección automatizada para optimizar la productividad y minimizar la intervención de TI.
Si desea obtener más información sobre la modernización de identidades, consulte la guía de Tines IAM para saber cómo el equipo está unificando la confianza en los dispositivos, las decisiones de acceso y la aplicación de privilegios mínimos a través de la automatización. El flujo de trabajo de Scott es uno de varios patrones del mundo real bajo el capó.
Descripción general del flujo de trabajo
Herramientas necesarias:
Tines – Plataforma de IA y orquestación del flujo de trabajo Kolide – Monitoreo de postura y confiabilidad del dispositivo Okta – Plataforma de identidad que recibe eventos CAEP
Credenciales requeridas:
Clave API de Tines: «Equipo» con alcance para la función «Editor» Clave API de Kolide: secreto de firma de Kolide Webhook de solo lectura
Recursos necesarios:
Un dominio Okta (como ejemplo.okta.com o ejemplo.oktapreview.com) o un dominio de marca.
estructura:
Este 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 por Kolide. Hay tres elementos:
1. Genere y guarde una clave de firma SET (SET es un token web JSON firmado).
Cree un par de claves RSA y conviértalo al formato JWK. Publique la clave pública para que los destinatarios de SSF verifiquen la firma SET. Guarde su conjunto de claves JWK privado como un secreto de Tines.
2. Exponer la API del transmisor SSF
Los receptores SSF (como Okta) requieren:
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 la firma SET Un webhook que sirve como API SSF Se devuelve una lógica de superficie de activación Una lógica de configuración .well-known devuelve el JWK
Una vez que esto se publique, los equipos pueden registrar nuevos receptores SSF con Okta en:
Seguridad → Integración de dispositivos → Recibir señales compartidas
Luego cree una nueva secuencia utilizando la URL de la API y el nuevo punto final «.well-known».
3. Cree, firme y envíe SET desde eventos de Kolide
Reciba eventos de publicación de Kolide a través de un webhook y valídelos utilizando un secreto de firma. Obtenga metadatos de dispositivo y usuario de Kolide. Construye un SET para eventos CAEP de cambio de cumplimiento del dispositivo. Firme el SET con la clave privada almacenada utilizando la expresión JWT_SIGN. Envíe el token firmado al punto final del evento de seguridad de Okta.
Esto ofrece actualizaciones de cumplimiento de dispositivos en tiempo real a Okta, lo que permite que las políticas de acceso tomen medidas inmediatas.
Configurar un flujo de trabajo: 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 mostrará inmediatamente su nuevo flujo de trabajo prediseñado.
3. Reúna las credenciales requeridas
Clave API de Tines (ámbito de equipo con rol de editor) Clave API de Kolide (solo lectura) Secreto de firma del webhook de Kolide
Estos garantizan que las llamadas a Kolide estén autenticadas y los webhooks se verifiquen de forma segura.
4. Reúna los recursos necesarios
Necesitará un dominio de inquilino de Okta similar a este:
ejemplo.oktapreview.com ejemplo.okta.com o un 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 está configurado como un proveedor «push» en lugar de un proveedor «sondeo», ya que el token se envía en función del webhook entrante, por lo que no es necesario guardar el estado.
5. Genere una clave de firma SET
Cree una clave RSA mediante la acción Generar conjunto de claves JWK. Convierta claves públicas y privadas al formato JWK (dos transformaciones de eventos). Guarde el conjunto de claves resultante utilizando un secreto de Tines.
Esto es necesario antes de que Okta pueda aceptar y validar el SET.
6. Exponer la API del transmisor SSF
Los webhooks de la API de SSF incluyen dos ramas.
.disparador de punto final conocido: transformación de evento conocido: devuelve la configuración SSF que declara las capacidades del transmisor. desencadenador de punto final JWKS: transformación de evento JWK: devuelve un JWK público para que Okta pueda verificar la firma
Una vez en vivo, Okta puede registrar este transmisor como remitente de señal compartida.
7. Conecte Kolide y solucione los problemas del dispositivo
El flujo de integración de Kolide sigue estos pasos:
Webhooks: Kolide Webhook: recibe eventos de problemas abiertos/resueltos. Obtener detalles del dispositivo: obtener metadatos del dispositivo asociado. El dispositivo tiene usuario: lógica de bifurcación para comprobar que el usuario está asociado. Obtener detalles del usuario: buscar metadatos del usuario en la carga útil de CAEP.
Dependiendo de si el problema es nuevo o está resuelto:
Build SET: crea el evento CAEP device_compliance_change. Firme el SET: genere un SET compatible con SSF utilizando la clave privada RSA que guardó previamente. Enviar SET: envía el token final firmado al punto final del evento de seguridad de Okta.
Tan pronto como Okta recibe y valida el SET, actualiza el nivel de riesgo del usuario asociado.
reunir todo
SSF existe para permitir 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 los estándares, existen 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. Esto garantiza que las herramientas que no son compatibles con SSF aún puedan enviar información de la misma manera estandarizada. Al utilizar Tines para generar, firmar y distribuir señales de cumplimiento en tiempo real, puede aprovechar los beneficios de SSF incluso si sus herramientas fuente no están diseñadas para SSF.
Si desea probar este flujo de trabajo usted mismo, puede hacerlo en minutos usando su cuenta gratuita de Tines. Y si desea ver cómo el estado del dispositivo encaja en su estrategia de identidad más amplia, esta guía de flujos de trabajo de IAM modernos presenta patrones prácticos y flujos de trabajo del mundo real como el de Scott que puede comenzar a crear hoy.
Source link
