Des signaux d’exposition vérifiés pour vos décisions sur les risques liés aux identités

Avant de commencer

• Un accès en tant que propriétaire du compte LeakData, avec accès à l’intégration SIEM Enterprise. Les comptes utilisateurs rattachés ne peuvent pas configurer la connexion.
• Un administrateur Okta autorisé à installer et à autoriser les intégrations de service API, ainsi qu’une organisation prenant en charge la réception Shared Signals. Identity Threat Protection est requis pour les fonctionnalités de politique de risque correspondantes.
• Une surveillance active d’une adresse e-mail personnelle dont la propriété a été vérifiée ou qui appartient à l’un de vos domaines vérifiés. Pour tester un signal signé, utilisez un utilisateur de test sous votre contrôle, avec la même adresse e-mail, dans une organisation Okta de test.

1. Installer et autoriser dans Okta

La publication dans le catalogue public est en attente. Si LeakData n’est pas disponible dans votre catalogue, contactez l’assistance pour connaître la procédure de configuration actuelle avant de continuer.

1. Ouvrez Applications et ressources > Intégrations de service API dans la console d’administration Okta et installez LeakData Shared Signals lorsque l’intégration est disponible dans votre catalogue.
2. Autorisez uniquement okta.securityEventsProviders.manage. Copiez immédiatement le secret client, qui ne s’affiche qu’une seule fois, puis notez l’ID client et le domaine Okta de cette même instance.
3. Utilisez l’URL d’origine non personnalisée de l’organisation, par exemple https://integrator-1234567.okta.com. Supprimez -admin, les chemins, les chaînes de requête et les numéros de port.

Ces identifiants proviennent d’une intégration de service API OIN installée. Un jeton API ou une application de service OAuth générique créée via Créer une intégration d’application ne fournit pas la même configuration d’ID client et de secret client OIN.

2. Connecter dans LeakData

1. Connectez-vous en tant que propriétaire du compte et ouvrez Tableau de bord > Intégrations > Okta Shared Signals.
2. Saisissez l’URL de l’organisation, l’ID client et le secret client de la même instance autorisée. Choisissez Élevée et critique ou Critique uniquement.
3. Lisez et confirmez la restriction aux adresses vérifiées et les effets de vos politiques de risque Okta, puis sélectionnez Connecter Okta. LeakData vérifie les identifiants et crée ou réutilise son fournisseur d’événements de sécurité.
4. Après la configuration, le fournisseur est actif. LeakData chiffre le secret et ne l’affiche plus.

3. Vérifier la connexion

1. Sélectionnez Vérifier la connexion pour vérifier les identifiants et l’état du fournisseur sans envoyer de signal de risque. Confirmez que le fournisseur est actif et qu’un ID de fournisseur figure dans Détails de la connexion.
2. Vérifiez les adresses e-mail surveillées admissibles. Seules les adresses e-mail exactes dont la propriété a été vérifiée ou qui appartiennent à l’un de vos domaines vérifiés sont admissibles ; un domaine surveillé n’est jamais envoyé en tant que tel.
3. Dans un compte dédié aux tests et à l’assurance qualité et une organisation Okta Integrator sous votre contrôle, vérifiez l’adresse e-mail de test et la confirmation des effets des politiques avant d’utiliser Tester un signal signé. Ce test peut déclencher les politiques de risque configurées.
4. HTTP 202 confirme uniquement l’acceptation. Dans Okta System Log, recherchez security.events.provider.receive_event et user.risk.detect pour votre utilisateur de test. Une adresse e-mail inconnue peut être ignorée sans notification.

4. Remplacer les identifiants ou changer d’organisation

1. Pour la même organisation, sélectionnez Remplacer les identifiants et saisissez une nouvelle paire d’ID client et de secret client provenant d’une instance autorisée du service API LeakData dans cette organisation. L’enregistrement vérifie et active la connexion.
2. Mettre l’envoi en pause conserve le lien avec l’organisation et les identifiants enregistrés. Cette action ne prépare pas le compte à être connecté à une autre organisation.
3. Pour reprendre l’envoi vers la même organisation, sélectionnez Démarrer l’envoi, puis Vérifier la connexion, et confirmez que le fournisseur est actif.
4. Pour utiliser une autre organisation, examinez d’abord l’option Supprimer la connexion. La confirmation de la suppression efface le fournisseur, les identifiants chiffrés et l’historique local des envois. Configurez ensuite la nouvelle organisation. Si la suppression échoue, contactez l’assistance ; ne considérez pas que l’ancien fournisseur a été supprimé.

Dépannage

Identifiants refusés

Vérifiez que les trois valeurs proviennent de la même instance de service API OIN installée et autorisée. Lors de l’examen, utilisez une instance de la version actuellement soumise. Les jetons API et les identifiants d’applications de service OAuth génériques ne sont pas interchangeables avec les identifiants de cette configuration.

Autorisation ou accès au récepteur refusé

Confirmez que okta.securityEventsProviders.manage a été autorisé et que votre organisation Okta prend en charge le récepteur SSF. Vérifiez les droits d’accès administrateur et les politiques de l’organisation.

Déjà connecté à une autre organisation

Remplacez les identifiants uniquement pour l’organisation affichée. La mise en pause ne supprime pas la connexion. Consultez les étapes de suppression ci-dessus avant de changer d’organisation.

Aucun signal ou aucun événement de risque utilisateur

Vérifiez que la propriété de l’adresse a été vérifiée ou qu’elle appartient à un domaine vérifié, que la surveillance de l’adresse personnelle est active et que le constat de sécurité est vérifié et de gravité élevée ou critique. Vérifiez également le seuil de gravité sélectionné. L’acceptation par le récepteur ne prouve à elle seule ni la correspondance avec un utilisateur ni l’exécution d’une action liée à une politique.

Besoin d’aide ?

Contactez l’assistance LeakData en indiquant l’opération qui a échoué et le code d’erreur. N’incluez aucun mot de passe, secret client ou jeton d’accès.