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 tous les événements sont disponibles 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 répertoire, mais uniquement si vous choisissez de l’autoriser. Toutes les autorisations ci-dessus, sauf la dernière, sont en lecture seule. Si vous n’accordez que celles-ci, la connexion ne pourra jamais rien modifier dans votre locataire — la plateforme le détecte et n’offre alors aucune action sur les groupes. Ajoutez GroupMember.ReadWrite.All et les actions d’appartenance aux groupes deviennent disponibles dans les guides d’intervention. 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 guide d’intervention qui les utilise. Vous pouvez changer d’avis à tout moment. Il suffit d’ajouter ou de retirer une autorisation dans Microsoft Entra ID et d’accorder de nouveau le consentement de l’administrateur — il n’est pas nécessaire de saisir de nouveau les identifiants dans la plateforme, et vos synchronisations de données continuent de fonctionner pendant ce temps. Le changement prend effet en environ une heure.
Les actions d’appartenance aux groupes sont en outre limitées aux groupes que vous désignez. Après la connexion, un administrateur choisit une liste d’autorisation explicite de groupes pour la connexion. Tant que cette liste n’existe pas, les actions sur les groupes ne sont pas disponibles, même si l’autorisation est accordée — par conséquent, 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’applications 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 figurent dans cette liste, ajoutez-les à votre enregistrement d’application existant et accordez de nouveau le consentement de l’administrateur — Microsoft exige que le consentement soit accordé de nouveau chaque fois que des autorisations changent. Tous les autres flux de données continuent de fonctionner normalement entre-temps.Policy.Read.ConditionalAccess — sans cette autorisation, Microsoft retire les détails de l’accès conditionnel de chaque enregistrement de connexion. L’enregistrement indique toujours qu’une politique d’accès conditionnel a été respectée, mais la liste des politiques est vide. Rien n’échoue et aucun avertissement n’est émis : les données de connexion continuent d’arriver et la connexion reste saine. La plateforme ne peut tout simplement pas déterminer quelles connexions ont été satisfaites par l’authentification multifacteur; l’activité d’AMF provenant de cette connexion reste donc vide.IdentityRiskEvent.Read.All — la lecture des détections de risques exige é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’applications 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 des informations d’identification du client.
  7. Cliquez sur Register.
Après l’enregistrement, notez les valeurs suivantes à partir de 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 guides d’intervention puissent modifier l’appartenance aux groupes. Omettez-la pour que cette connexion reste en lecture seule.
Il s’agit des autorisations minimales pour tous les flux de données. Si vous prévoyez d’activer seulement certains flux, vous pouvez omettre les autorisations des flux que vous n’utiliserez pas.
3

Accorder le consentement de l'administrateur

Les autorisations d’application exigent le consentement explicite d’un 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é de nouveau chaque fois que vous ajoutez de nouvelles autorisations.
4

Créer une clé secrète 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 (p. ex. Living Security Platform).
  4. Choisissez une date d’expiration conforme à votre politique de rotation.
  5. Cliquez sur Add.
Copiez immédiatement la valeur de la clé secrète. Microsoft Entra ID n’affiche la clé secrète client complète qu’une seule fois. Si vous quittez la page avant de la copier, vous devrez supprimer la clé secrète et en créer une nouvelle.
Conservez la clé secrète en lieu sûr. Définissez un rappel dans votre calendrier pour la renouveler avant son expiration — une clé secrète expirée 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 expirés. Vérifiez les points suivants :
  1. La clé secrète 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 sous 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 de nouveau le consentement de l’administrateur.
Il est possible que l’application n’ait pas l’autorisation propre à ce flux :
  • Aucun utilisateur → User.Read.All manquante
  • Aucune alerte de sécurité → SecurityAlert.Read.All manquante
  • Aucun journal de connexion → AuditLog.Read.All manquante
  • Aucun résultat de simulation d’attaque → AttackSimulation.Read.All manquante
  • Aucun appareil Entra ID → Device.Read.All manquante
  • Aucun appareil géré par Intune → DeviceManagementManagedDevices.Read.All manquante
  • Aucune détection de risque → IdentityRiskEvent.Read.All manquante, consentement de l’administrateur non accordé de nouveau après son ajout, ou le locataire est en dessous du niveau de licence 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 aux groupes ne sont offertes que si ces trois conditions sont réunies :
  1. GroupMember.ReadWrite.All figure dans l’enregistrement de l’application, avec le consentement de l’administrateur accordé. Si vous l’avez ajoutée récemment, prévoyez jusqu’à une heure.
  2. Un administrateur a désigné une liste d’autorisation de groupes pour la connexion.
  3. La connexion est active et saine.
Si vous avez accordé l’autorisation et que les actions demeurent indisponibles, accordez de nouveau le consentement de l’administrateur — Microsoft l’exige chaque fois que des autorisations changent.
Si votre locataire applique une politique d’accès conditionnel limitée par adresse IP, elle peut bloquer les requêtes qui portent l’identifiant de cette connexion. La plupart des locataires ne sont pas touchés — Microsoft Graph ne restreint pas par adresse IP par défaut. Si vous appliquez une politique limitée par adresse IP aux principaux de service, cette intégration exige que deux ensembles d’adresses soient autorisés, car la configuration et la synchronisation des données proviennent 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 proviennent donc des adresses propres à la plateforme, et non des adresses utilisées par vos synchronisations de données.Les actions sur les groupes sont distinctes. Par défaut, elles sont acheminées de la même manière que vos synchronisations de données et proviennent des adresses de synchronisation. Elles ne passent aux adresses de la plateforme que si un administrateur configure la connexion pour une sortie directe.Ajoutez les deux ensembles à l’emplacement nommé que votre politique 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 être autorisées.Si seules les adresses de synchronisation sont autorisées, la configuration échoue lors de l’obtention du 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.