Señales de exposición verificadas para decisiones sobre riesgos de identidad

Antes de comenzar

• Acceso como propietario de la cuenta de LeakData, con acceso a las integraciones SIEM del plan Enterprise. Las cuentas de usuarios adicionales no pueden configurar la conexión.
• Un administrador de Okta que pueda instalar y autorizar integraciones de servicios de API, y una organización compatible con el receptor de Shared Signals. Identity Threat Protection es necesario para las funciones correspondientes de las políticas de riesgo.
• Un monitor activo de correo electrónico personal cuya dirección tenga la titularidad verificada o pertenezca a uno de sus dominios verificados. Para probar una señal firmada, use un usuario de ejemplo controlado con el mismo correo electrónico en una organización de prueba de Okta.

1. Instale y autorice en Okta

La publicación en el catálogo público está pendiente. Si LeakData no está disponible en su catálogo, contacte con soporte para conocer el procedimiento de configuración actual antes de continuar.

1. Abra Aplicaciones y recursos > Integraciones de servicios de API en la consola de administración de Okta e instale LeakData Shared Signals cuando esté disponible en su catálogo.
2. Autorice únicamente okta.securityEventsProviders.manage. Copie de inmediato el secreto de cliente, que se muestra una sola vez, y anote el ID de cliente y el dominio de Okta de esa misma instancia.
3. Use el origen de la organización sin personalizar, como https://integrator-1234567.okta.com. Elimine -admin, las rutas, las cadenas de consulta y los números de puerto.

Estas credenciales proceden de una integración de servicio de API de OIN instalada. Un token de API o una aplicación genérica de servicio OAuth creada mediante Crear integración de aplicación no proporciona la misma configuración de ID y secreto de cliente de OIN.

2. Establezca la conexión en LeakData

1. Inicie sesión como propietario de la cuenta y abra Panel > Integraciones > Okta Shared Signals.
2. Introduzca la URL de la organización, el ID de cliente y el secreto de cliente de la misma instancia autorizada. Elija Alta y crítica o Solo crítica.
3. Lea y confirme la limitación a direcciones verificadas y el efecto de sus políticas de riesgo de Okta; después, seleccione Conectar Okta. LeakData verifica las credenciales y crea o reutiliza su proveedor de eventos de seguridad.
4. Tras la configuración, el proveedor queda activo. LeakData cifra el secreto y no vuelve a mostrarlo.

3. Verifique la conexión

1. Seleccione Comprobar conexión para verificar las credenciales y el estado del proveedor sin enviar una señal de riesgo. Confirme que el proveedor esté activo y que aparezca un ID de proveedor en Detalles de la conexión.
2. Revise los monitores de correo electrónico que cumplan los requisitos. Solo cumplen los requisitos las direcciones de correo electrónico exactas cuya titularidad se haya verificado o que pertenezcan a uno de sus dominios verificados; el monitor de dominio en sí nunca se envía.
3. En una cuenta dedicada de pruebas/QA y una organización controlada de Okta Integrator, revise el correo electrónico de ejemplo y la confirmación de las políticas antes de usar Probar una señal firmada. Esta prueba puede activar las políticas de riesgo configuradas.
4. HTTP 202 solo confirma la aceptación. Busque security.events.provider.receive_event y user.risk.detect para su usuario de ejemplo en el registro del sistema de Okta. Un correo electrónico desconocido puede ignorarse sin notificación.

4. Sustituya las credenciales o cambie de organización

1. Para la misma organización, seleccione Sustituir credenciales e introduzca un nuevo par de ID y secreto de cliente de una instancia autorizada del servicio de API de LeakData en esa organización. Al guardar, se verifica y activa la conexión.
2. Pausar entrega mantiene la vinculación con la organización y las credenciales guardadas. No prepara la cuenta para otra organización.
3. Para reanudar la entrega a la misma organización, seleccione Iniciar entrega, después Comprobar conexión y confirme que el proveedor esté activo.
4. Para usar una organización diferente, revise primero Eliminar conexión. Al confirmar la eliminación, se eliminan el proveedor, las credenciales cifradas y el historial local de entregas. Después, configure la nueva organización. Si la eliminación falla, contacte con soporte; no dé por hecho que se ha eliminado el proveedor anterior.

Solución de problemas

Credenciales rechazadas

Compruebe que los tres valores procedan de la misma instancia instalada y autorizada del servicio de API de OIN. Durante la revisión, use una instancia de la versión presentada actualmente. Los tokens de API y las credenciales de aplicaciones genéricas de servicio OAuth no son intercambiables con las de esta configuración.

Permiso o acceso al receptor denegado

Confirme que se haya autorizado okta.securityEventsProviders.manage y que su organización de Okta sea compatible con el receptor SSF. Revise el acceso de administrador y las políticas de la organización.

Ya existe una conexión con otra organización

Sustituya las credenciales únicamente para la organización que se muestra. Pausar no elimina la conexión. Revise los pasos de eliminación anteriores antes de cambiar de organización.

No hay señal o no hay evento de riesgo del usuario

Compruebe que la dirección tenga la titularidad verificada o pertenezca a un dominio verificado, que el monitor personal esté activo y que el hallazgo esté verificado y tenga gravedad alta o crítica. Revise también el umbral de gravedad seleccionado. La aceptación del receptor por sí sola no demuestra que haya una coincidencia con un usuario ni que se haya aplicado una política.

¿Necesita ayuda?

Contacte con el soporte de LeakData e indique la operación que ha fallado y el código de error. No incluya contraseñas, secretos de cliente ni tokens de acceso.