Skip to main content

​
Ce que cette intégration apporte

Microsoft Entra ID peut fournir une activité normalisée relative aux identités, aux connexions, aux risques, aux appareils et aux simulations d’attaque. Voici quelques exemples examinés :
  • account.compromised — compte signalé comme compromis
  • auth.login.unusual — connexions depuis des contextes inhabituels
  • phishing.simulation.clicked — a cliqué sur une simulation sans la signaler
Il s’agit d’exemples représentatifs, et non d’une garantie que chaque événement est disponible dans chaque locataire. Consultez comment les données d’intégration deviennent des signaux.

​
Ce dont Living Security a besoin

Étendues (autorisations d’application) :

​
Vous décidez de ce que cette connexion peut faire

Cette connexion lit des données. Elle peut également effectuer des actions dans votre annuaire, mais uniquement si vous choisissez de l’autoriser. Toutes les autorisations ci-dessus, à l’exception de la dernière, sont en lecture seule. Si vous n’accordez que celles-ci, la connexion ne pourra jamais modifier quoi que ce soit dans votre locataire — la plateforme le détecte et ne propose alors aucune action de groupe. Ajoutez GroupMember.ReadWrite.All et les actions d’appartenance à un groupe deviennent disponibles dans les Playbooks. Rien ne se déclenche de lui-même : vous devez encore choisir les groupes que la plateforme peut modifier (voir ci-dessous) et créer un Playbook qui les utilise. Vous pouvez revenir sur votre décision à tout moment. Il suffit d’ajouter ou de retirer une autorisation dans Microsoft Entra ID et d’accorder à nouveau le consentement de l’administrateur — il n’est pas nécessaire de saisir à nouveau les identifiants dans la plateforme, et vos synchronisations de données continuent de fonctionner pendant ce temps. La modification prend effet en une heure environ.
Les actions d’appartenance à un groupe sont en outre limitées aux groupes que vous désignez. Après la connexion, un administrateur définit sur la connexion une liste d’autorisation explicite de groupes. Tant que cette liste n’existe pas, les actions de groupe sont indisponibles, même si l’autorisation est accordée — ainsi GroupMember.ReadWrite.All ne signifie jamais « n’importe quel groupe du locataire ».Choisissez ces groupes avec soin : évitez tout groupe qui confère des rôles d’administration, un accès privilégié ou des droits de licence.
Rôle requis : Administrateur d’application ou Administrateur général dans Microsoft Entra ID
Deux de ces autorisations ont été ajoutées récemment. Si vous avez connecté Microsoft Entra ID avant qu’elles n’apparaissent dans cette liste, ajoutez-les à l’enregistrement de votre application existante et accordez à nouveau le consentement de l’administrateur — Microsoft exige que le consentement soit accordé à nouveau chaque fois que les autorisations changent. Tous les autres flux de données continuent de fonctionner normalement dans l’intervalle.Policy.Read.ConditionalAccess — sans cette autorisation, Microsoft supprime le détail de l’accès conditionnel de chaque enregistrement de connexion. L’enregistrement indique toujours qu’une stratégie d’accès conditionnel a été satisfaite, mais la liste des stratégies est renvoyée vide. Rien n’échoue et rien ne vous avertit : les données de connexion continuent d’arriver et la connexion reste saine. La plateforme ne peut simplement pas déterminer quelles connexions ont été satisfaites par l’authentification multifacteur ; l’activité MFA issue de cette connexion reste donc vide.IdentityRiskEvent.Read.All — la lecture des détections de risques nécessite également une licence Microsoft Entra ID P1 ou P2. La détection des identifiants divulgués est disponible à tous les niveaux, y compris P1 ; les détections premium sont signalées comme generic en dessous de P2.

​
Prérequis

  • Vous devez disposer d’un accès Administrateur d’application ou Administrateur général dans Microsoft Entra ID pour enregistrer des applications et accorder le consentement de l’administrateur.

​
Partie A — Dans Microsoft Entra ID

Votre administrateur Microsoft Entra ID effectue ces étapes.
1

Enregistrer une nouvelle application

  1. Connectez-vous au centre d’administration Microsoft Entra.
  2. Dans la navigation de gauche, accédez à Entra ID → App registrations.
  3. Cliquez sur New registration.
  4. Saisissez un nom explicite pour l’application, par exemple Living Security Platform.
  5. Sous Supported account types, sélectionnez Accounts in this organizational directory only.
  6. Laissez Redirect URI vide — cette intégration utilise le flux d’informations d’identification du client.
  7. Cliquez sur Register.
Après l’enregistrement, notez les valeurs suivantes sur la page Overview :
  • Application (client) ID
  • Directory (tenant) ID
2

Ajouter les autorisations d'application Microsoft Graph

  1. Sur la page Overview de votre application, cliquez sur API permissions dans le menu de gauche.
  2. Cliquez sur Add a permission.
  3. Sélectionnez Microsoft Graph.
  4. Sélectionnez Application permissions.
  5. Recherchez et sélectionnez chacune des autorisations ci-dessous, puis cliquez sur Add permissions :
    • User.Read.All
    • SecurityAlert.Read.All
    • AuditLog.Read.All
    • Policy.Read.ConditionalAccess
    • AttackSimulation.Read.All
    • Device.Read.All
    • DeviceManagementManagedDevices.Read.All
    • IdentityRiskEvent.Read.All
  6. Ajoutez GroupMember.ReadWrite.All uniquement si vous souhaitez que les Playbooks puissent modifier l’appartenance à un groupe. Ignorez cette étape pour que cette connexion reste en lecture seule.
Il s’agit des autorisations minimales pour tous les flux de données. Si vous ne prévoyez d’activer qu’une partie des flux, vous pouvez omettre les autorisations correspondant aux flux que vous n’utiliserez pas.
3

Accorder le consentement de l'administrateur

Les autorisations d’application nécessitent un consentement explicite de l’administrateur.
  1. Sur la page API permissions, cliquez sur Grant admin consent for <your tenant name>.
  2. Dans la boîte de dialogue de confirmation, cliquez sur Yes.
  3. Vérifiez que chaque autorisation affiche Granted dans la colonne Status.
Si le bouton Grant admin consent est grisé, vous devez disposer des privilèges Privileged Role Administrator ou Global Administrator. Le consentement de l’administrateur doit être accordé à nouveau chaque fois que vous ajoutez de nouvelles autorisations.
4

Créer un secret client

  1. Sur la page Overview de votre application, cliquez sur Certificates & secrets dans le menu de gauche.
  2. Cliquez sur l’onglet Client secrets, puis sur New client secret.
  3. Saisissez une description (par exemple Living Security Platform).
  4. Choisissez une durée d’expiration conforme à votre politique de rotation.
  5. Cliquez sur Add.
Copiez immédiatement la valeur du secret. Microsoft Entra ID n’affiche le secret client complet qu’une seule fois. Si vous quittez la page avant de l’avoir copié, vous devrez supprimer le secret et en créer un nouveau.
Conservez le secret en lieu sûr. Définissez un rappel dans votre calendrier pour le renouveler avant son expiration — un secret expiré entraîne l’échec des synchronisations avec 401 Unauthorized.
5

Déterminer l'hôte de l'API Graph et l'hôte d'autorité

Pour la plupart des organisations utilisant le cloud commercial, utilisez les valeurs par défaut :Pour les clouds gouvernementaux ou souverains, utilisez les points de terminaison appropriés à votre environnement.
L’hôte de l’API Graph et l’hôte d’autorité doivent correspondre — les jetons émis par l’autorité d’un cloud ne sont pas valides pour le point de terminaison Graph d’un autre cloud.

​
Partie B — Dans Living Security Platform

Le responsable du programme effectue cette étape, ou l’administrateur système s’il a été invité dans la plateforme.
Vous êtes maintenant connecté à Microsoft Entra ID (Client Credentials).

​
Dépannage

Les identifiants sont invalides ou ont expiré. Vérifiez les points suivants :
  1. Le code secret client n’a pas expiré et n’a pas fait l’objet d’une rotation
  2. L’ID de locataire et l’ID client sont corrects
  3. L’hôte d’autorité correspond à votre environnement cloud
Il manque des autorisations à l’enregistrement de l’application, ou le consentement de l’administrateur n’a pas été accordé. Vérifiez les points suivants :
  1. Toutes les autorisations requises figurent dans API permissions
  2. Chaque autorisation affiche le statut Granted (coche verte)
  3. Le consentement de l’administrateur a été accordé après l’ajout des autorisations
Si vous avez ajouté de nouvelles autorisations après le consentement initial, vous devez accorder à nouveau le consentement de l’administrateur.
Il se peut que l’application ne dispose pas de l’autorisation propre à ce flux :
  • Aucun utilisateur → User.Read.All manquant
  • Aucune alerte de sécurité → SecurityAlert.Read.All manquant
  • Aucun journal de connexion → AuditLog.Read.All manquant
  • Aucun résultat de simulation d’attaque → AttackSimulation.Read.All manquant
  • Aucun appareil Entra ID → Device.Read.All manquant
  • Aucun appareil géré par Intune → DeviceManagementManagedDevices.Read.All manquant
  • Aucune détection de risque → IdentityRiskEvent.Read.All manquant, consentement de l’administrateur non accordé à nouveau après son ajout, ou locataire dont la licence est inférieure au niveau minimal Microsoft Entra ID P1
L’hôte de l’API Graph et l’hôte d’autorité ne correspondent peut-être pas. Les deux doivent correspondre au même environnement cloud (commercial, gouvernemental, etc.).
Les actions d’appartenance à un groupe ne sont proposées que lorsque ces trois conditions sont réunies :
  1. GroupMember.ReadWrite.All est présent sur l’enregistrement de l’application, avec le consentement de l’administrateur accordé. Si vous l’avez ajouté récemment, patientez jusqu’à une heure.
  2. Un administrateur a désigné une liste d’autorisation de groupes sur la connexion.
  3. La connexion est active et saine.
Si vous avez accordé l’autorisation et que les actions restent indisponibles, accordez à nouveau le consentement de l’administrateur — Microsoft l’exige chaque fois que les autorisations changent.
Si votre locataire applique une stratégie d’accès conditionnel limitée par adresse IP, elle peut bloquer les requêtes qui comportent l’identifiant de cette connexion. La plupart des locataires ne sont pas concernés — Microsoft Graph ne restreint pas l’accès par adresse IP par défaut. Si vous appliquez une stratégie limitée par IP pour les principaux de service, cette intégration exige que deux ensembles d’adresses soient autorisés, car la configuration et la synchronisation des données partent de réseaux différents.Living Security génère lui-même le jeton d’accès de cette connexion et le renouvelle en continu ; les demandes de jeton partent donc des adresses propres à la plateforme, et non des adresses utilisées par vos synchronisations de données.Les actions de groupe sont distinctes. Par défaut, elles suivent le même acheminement que vos synchronisations de données et partent des adresses de synchronisation. Elles ne passent aux adresses de la plateforme que si un administrateur bascule la connexion en sortie directe.Ajoutez les deux ensembles à l’emplacement nommé que votre stratégie d’accès conditionnel approuve ou exclut. Les demandes de jeton atteignent login.microsoftonline.com et les demandes de données atteignent graph.microsoft.com ; les deux doivent aboutir.Si seules les adresses de synchronisation sont autorisées, la configuration échoue lors de l’obtention d’un jeton et aucune connexion n’est créée. Si seules les adresses de la plateforme sont autorisées, la configuration réussit et chaque synchronisation ne renvoie aucun enregistrement.