Automatisation de la réponse aux menaces avec des règles dans Microsoft Sentinel

  • Article
  • S’applique à:
    Microsoft Sentinel in the Azure portal, Microsoft Sentinel in the Microsoft Defender portal

Cet article explique ce que sont les playbooks Microsoft Sentinel, et comment les utiliser pour implémenter vos opérations d’orchestration, d’automatisation et de réponse aux problèmes de sécurité (SOAR), en obtenant de meilleurs résultats tout en économisant du temps et des ressources.

Important

Microsoft Sentinel est disponible dans le cadre de la préversion publique de la plateforme d’opérations de sécurité unifiée dans le portail Microsoft Defender. Pour en savoir plus, consultez Microsoft Sentinel sur le portail Microsoft Defender.

Qu’est-ce qu’un playbook ?

En général, les analystes SOC (centre des opérations de sécurité) sont submergés d’alertes de sécurité et d’incidents régulièrement, avec des volumes si conséquents que le personnel disponible est surchargé. Il en résulte trop souvent des situations où de nombreuses alertes sont ignorées et où les incidents ne peuvent pas être examinés. L’organisation reste donc vulnérable aux attaques qui passent inaperçues.

Beaucoup, voire la plupart, de ces alertes et incidents sont conformes à des modèles récurrents qui peuvent être traités par des ensembles d’actions de correction spécifiques et définies. Les analystes sont également chargés de prendre des mesures de correction de base et d’examiner les incidents qu’ils sont en mesure de traiter. Plus ces activités peuvent être automatisées, plus un centre SOC devient productif et efficace, ce qui permet aux analystes de consacrer plus de temps et d’énergie aux activités d’examen des incidents.

Un playbook est un ensemble de ces actions de correction que vous exécutez à partir de Microsoft Sentinel en tant que routine, afin d’automatiser et d’orchestrer votre réponse aux menaces. Il peut être exécuté de deux manières :

  • Manuellement à la demande, sur une entité ou une alerte particulière
  • Automatiquement en réponse à des alertes ou des incidents spécifiques, lorsqu’ils sont déclenchés par une règle d’automatisation.

Par exemple, si un compte et un ordinateur sont compromis, un playbook peut isoler l’ordinateur du réseau et bloquer le compte au moment où l’équipe SOC est informée de l’incident.

Bien que l’onglet Playbooks actifs de la page Automatisation affiche tous les playbooks actifs disponibles dans tous les abonnements sélectionnés, par défaut, un playbook peut être utilisé uniquement dans l’abonnement auquel il appartient, sauf si vous accordez spécifiquement des autorisations Microsoft Sentinel au groupe de ressources du playbook.

Après l’intégration à la plateforme d’opérations de sécurité unifiée, l’onglet Playbooks actifs affiche un filtre prédéfini avec l’abonnement de l’espace de travail intégré. Dans le portail Azure, ajoutez des données pour d’autres abonnements à l’aide du filtre d’abonnement Azure.

Modèles de playbook

Un modèle de playbook est un workflow prédéfini, testé et prêt à l’emploi qui peut être personnalisé pour répondre à vos besoins. Les modèles peuvent également servir de référence dans les bonnes pratiques pour le développement de règles à partir de zéro ou d’inspiration pour les nouveaux scénarios d’automatisation.

Les modèles de playbooks ne sont pas utilisables en tant que playbooks eux-mêmes. Vous devez créer un playbook (une copie modifiable du modèle) à partir de ces modèles.

Vous pouvez obtenir des modèles de playbook à partir des sources suivantes :

  • Sur la page Automatisation, l’onglet Modèles de playbook répertorie les modèles de playbook installés. Vous pouvez créer plusieurs playbooks actifs à partir du même modèle.

    Quand une nouvelle version du modèle est publiée, les playbooks actifs créés à partir de ce modèle apparaissent dans l’onglet Playbooks avec une étiquette indiquant qu’une mise à jour est disponible.

  • Les modèles de guide opérationnel sont disponibles dans le cadre de solutions de produits ou de contenu autonome que vous installez à partir de la page Hub de contenu dans Microsoft Sentinel. Pour plus d’informations, consultez les rubriques Contenu et solutions Microsoft Sentinel et Découvrir et gérer le contenu prêt à l’emploi de Microsoft Sentinel.

  • Le référentiel GitHub Microsoft Sentinel contient de nombreux modèles de playbook. Vous pouvez les déployer dans un abonnement Azure en sélectionnant le bouton Déployer sur Azure.

Techniquement, un modèle de playbook est un modèle ARM composé de plusieurs ressources : un workflow Azure Logic Apps et des connexions d’API pour chaque connexion impliquée.

Important

Les modèles de playbook sont actuellement en PRÉVERSION. Consultez l’Avenant aux conditions d’utilisation pour les préversions de Microsoft Azure pour connaître les conditions juridiques supplémentaires s’appliquant aux fonctionnalités Azure sont en version bêta, en préversion ou non encore en disponibilité générale.

Concepts de base d’Azure Logic Apps

Les playbooks dans Microsoft Sentinel sont basés sur des workflows intégrés à Azure Logic Apps, service cloud qui vous permet de planifier, d’automatiser et d’orchestrer des tâches et des workflows à travers l’entreprise. Cela signifie que les playbooks peuvent tirer parti de toute la puissance et des capacités des modèles intégrés dans Azure Logic Apps.

Notes

Azure Logic Apps crée des ressources distinctes, de sorte que des frais supplémentaires peuvent s’appliquer. Consultez la page sur la tarification d’Azure Logic Apps pour en savoir plus.

Azure Logic Apps communique avec d’autres systèmes et services à l’aide de connecteurs. Voici une brève explication des connecteurs et de certains de leurs attributs importants :

  • Connecteur géré : Ensemble d’actions et de déclencheurs qui encapsulent les appels d’API pour un produit ou service particulier. Azure Logic Apps propose des centaines de connecteurs pour communiquer avec des services Microsoft et non Microsoft. Pour plus d’informations, consultez Connecteurs Azure Logic Apps et leur documentation

  • Connecteur personnalisé : Vous pourriez souhaiter communiquer avec des services qui ne sont pas disponibles en tant que connecteurs prédéfinis. Les connecteurs personnalisés répondent à ce cas de figure en vous permettant de créer (et même de partager) un connecteur et de définir ses propres déclencheurs et actions. Pour plus d’informations, consultez Créer vos propres connecteurs Azure Logic Apps personnalisés.

  • Connecteur Microsoft Sentinel : pour créer des playbooks qui interagissent avec Microsoft Sentinel, utilisez le connecteur Microsoft Sentinel. Pour plus d’informations, consultez la documentation de connecteur Microsoft Sentinel.

  • Déclencheur : composant de connecteur qui démarre un flux de travail, dans ce cas, un playbook. Le déclencheur Microsoft Sentinel définit le schéma que le playbook s’attend à recevoir lorsqu’il est déclenché. Le connecteur Microsoft Sentinel dispose actuellement de trois déclencheurs :

  • Actions : les actions sont toutes les étapes qui se produisent après le déclencheur. Elles peuvent être réorganisées de façon séquentielle, en parallèle ou dans une matrice de conditions complexes.

  • Champs dynamiques : Les champs temporaires, déterminés par le schéma de sortie des déclencheurs et des actions, et remplis par leur sortie réelle, qui peuvent être utilisés dans les actions qui suivent.

Type d’application logique

Microsoft Sentinel prend désormais en charge les types de ressources d’application logique suivants :

  • Consommation, qui s’exécute dans Azure Logic Apps multi-locataire et utilise le moteur Azure Logic Apps classique d’origine.
  • Standard, qui s’exécute dans Azure Logic Apps à locataire unique et utilise un moteur Azure Logic Apps repensé.

Le type d’application logique Standard offre des performances plus élevées, une tarification fixe, une fonctionnalité de flux de travail multiple, une gestion des connexions d’API plus facile, des fonctionnalités réseau natives telles que la prise en charge des réseaux virtuels et des points de terminaison privés (voir la note ci-dessous), les fonctionnalités CI/CD intégrées, une meilleure intégration de Visual Studio Code, un concepteur de flux de travail mis à jour, etc.

Pour utiliser cette version de l’application logique, créez des playbooks Standard dans Microsoft Sentinel (voir la note ci-dessous). Vous pouvez utiliser ces playbooks de la même manière que les playbooks Consommation :

  • Joignez-les aux règles d’automatisation et/ou aux règles d’analytique.
  • Exécutez-les à la demande, à partir d’incidents et d’alertes.
  • Gérez-les sous l’onglet Playbooks actifs.

Notes

  • Actuellement, les flux de travail standard ne prennent pas en charge les modèles Playbook, ce qui signifie que vous ne pouvez pas créer un playbook standard basé sur des flux de travail directement dans Microsoft Sentinel. Au lieu de cela, vous devez créer le flux de travail dans Azure Logic Apps. Une fois que vous avez créé le flux de travail, il apparaît en tant que playbook dans Microsoft Sentinel.

  • Les workflows Standard des applications logiques prennent en charge les points de terminaison privés, comme mentionné ci-dessus, mais Microsoft Sentinel nécessite la définition d’une stratégie de restriction d’accès dans les applications logiques pour prendre en charge l’utilisation de points de terminaison privés dans les playbooks basés sur des workflows Standard.

    Si une stratégie de restriction d’accès n’est pas définie, les workflows avec des points de terminaison privés peuvent toujours être visibles et sélectionnables quand vous choisissez un playbook dans une liste dans Microsoft Sentinel (que ce soit pour une exécution manuelle, un ajout à une règle d’automatisation ou dans la galerie de playbooks). Vous pouvez alors les sélectionner, mais leur exécution échoue.

  • Un indicateur identifie les flux de travail Standard comme avec état ou sans état. Microsoft Sentinel ne prend pas en charge les flux de travail sans état à ce stade. En savoir plus sur les différences entre les workflows avec état et sans état.

Il existe de nombreuses différences entre ces deux types de ressources, dont certaines affectent certaines des façons dont elles peuvent être utilisées dans les playbooks dans Microsoft Sentinel. Dans ce cas, la documentation indique ce que vous devez savoir. Pour plus d’informations, consultez Les différences entre le type de ressource et l’environnement hôte dans la documentation Azure Logic Apps.

Autorisations requises

Afin de donner à votre équipe SecOps la possibilité d’utiliser Azure Logic Apps pour créer et exécuter des playbooks dans Microsoft Sentinel, attribuez des rôles Azure à l’équipe ou à des utilisateurs spécifiques de l’équipe. Ce qui suit décrit les différents rôles disponibles et les tâches pour lesquelles ils doivent être attribués :

Rôles Azure pour Azure Logic Apps

  • Le contributeur d’application logique vous permet de gérer des applications logiques et d’exécuter des playbooks, mais vous ne pouvez pas modifier l’accès à ceux-ci (pour cela, vous avez besoin du rôle de propriétaire).
  • L’opérateur d’application logique vous permet de lire, d’activer et de désactiver des applications logiques, mais pas de les modifier ni de les mettre à jour.

Rôles Azure pour Microsoft Sentinel

  • Le rôle Contributeur Microsoft Sentinel permet de joindre un playbook à une règle d’analytique ou d’automatisation.

  • Le rôle Répondeur Microsoft Sentinel permet d’accéder à un incident afin d’exécuter un playbook manuellement. Cependant, pour exécuter réellement le playbook, vous avez également besoin des éléments suivants :

    • Le rôle Opérateur de playbook Microsoft Sentinel permet d’exécuter un playbook manuellement.
    • Le contributeur d’automatisation Microsoft Sentinel permet aux règles d’automatisation d’exécuter des playbooks. Il n’est pas utilisé à d’autres fins.

En savoir plus

Étapes de création d’un playbook

Cas d’usage pour les playbooks

La plateforme Azure Logic Apps offre des centaines d’actions et de déclencheurs, de sorte que presque tout scénario d’automatisation peut être créé. Microsoft Sentinel recommande de commencer par les scénarios SOC suivants, pour lesquels des modèles de playbooks prêts à l’emploi sont disponibles :

Enrichissement

Collectez des données et attachez-les à l’incident afin de prendre des décisions plus intelligentes.

Par exemple :

Un incident Microsoft Sentinel a été créé à partir d’une alerte par une règle d’analyse qui génère des entités d’adresse IP.

L’incident déclenche une règle d’automatisation qui exécute un playbook avec les étapes suivantes :

  • Démarrez quand un nouvel incident Microsoft Sentinel est créé. Les entités représentées dans l’incident sont stockées dans les champs dynamiques du déclencheur d’incident.

  • Pour chaque adresse IP, interrogez un fournisseur d’informations sur les menaces externes, tel que le Virus Total, pour récupérer plus de données.

  • Ajoutez les données et insights renvoyés en tant que commentaires de l’incident.

Synchronisation bidirectionnelle

Les playbooks peuvent être utilisés pour synchroniser vos incidents Microsoft Sentinel avec d’autres systèmes de tickets.

Par exemple :

Créez une règle d’automatisation pour tous les cas de création d’incident, et joignez un playbook qui ouvre un ticket dans ServiceNow :

Orchestration

Utilisez la plateforme de conversation SOC pour mieux contrôler la file d’attente d’incidents.

Par exemple :

Un incident Microsoft Sentinel a été créé à partir d’une alerte par une règle d’analyse qui génère des entités de nom d’utilisateur et d’adresse IP.

L’incident déclenche une règle d’automatisation qui exécute un playbook avec les étapes suivantes :

  • Démarrez quand un nouvel incident Microsoft Sentinel est créé.

  • Envoyez un message à votre canal d’opérations de sécurité dans Microsoft Teams ou Slack pour vous assurer que vos analystes de sécurité sont conscients de l’incident.

  • Envoyez toutes les informations de l’alerte par e-mail à vos administrateur réseau et administrateur de sécurité supérieurs. L’e-mail comprendra les boutons d’option utilisateur Bloquer et Ignorer.

  • Attendez qu’une réponse soit reçue des administrateurs, puis continuez à exécuter.

  • Si les administrateurs ont choisi Bloquer, envoyez une commande au pare-feu pour bloquer l’adresse IP dans l’alerte, et une autre à Microsoft Entra ID pour désactiver l’utilisateur.

Response

Répondez immédiatement aux menaces, avec des dépendances humaines minimales.

Deux exemples :

Exemple 1 : Répondez à une règle d’analyse qui indique un utilisateur compromis, tel qu’il est découvert par Microsoft Entra ID Protection :

  • Démarrez quand un nouvel incident Microsoft Sentinel est créé.

  • Pour chaque entité d’utilisateur dans l’incident soupçonné d’être compromis :

    • Envoyez un message Teams à l’utilisateur, en demandant confirmation que l’utilisateur a effectué l’action suspecte.

    • Vérifiez avec Microsoft Entra ID Protection pour confirmer que l’état de l’utilisateur est compromis. Microsoft Entra ID Protection marque l’utilisateur comme étant à risque et applique une stratégie déjà configurée (par exemple, pour demander à l’utilisateur d’utiliser l’authentification multifacteur lors de la prochaine connexion).

      Remarque

      Cette action Microsoft Entra en particulier ne lance aucune activité d’application sur l’utilisateur, ni ne lance de configuration de stratégie d’application. Il demande uniquement à Microsoft Entra ID Protection d’appliquer les stratégies déjà définies, le cas échéant. Toute application dépend entièrement des stratégies appropriées définies dans Microsoft Entra ID Protection.

Exemple 2 : Répondre à une règle d’analyse qui indique un ordinateur compromis, tel qu’il est détecté par Microsoft Defender pour point de terminaison :

  • Démarrez quand un nouvel incident Microsoft Sentinel est créé.

  • Utilisez l’action Entités - Récupérer les hôtes dans Microsoft Sentinel pour analyser les ordinateurs suspects qui sont inclus dans les entités de l’incident.

  • Émettez une commande à Microsoft Defender pour point de terminaison pour isoler les machines dans l’alerte.

Réponse manuelle pendant l’examen des incidents ou pendant la chasse

Répondre aux menaces dans le cadre d’une activité d’examen des incidents active sans quitter le contexte.

Grâce au nouveau déclencheur d’entité (actuellement en préversion), vous pouvez prendre des mesures immédiates sur les acteurs de menace que vous découvrez au cours de l’examen d’un incident, en les traitant un par un directement au sein de l’examen. Cette option est également disponible dans le contexte de la chasse aux menaces, sans être liée à un incident particulier. Vous pouvez sélectionner une entité en contexte et effectuer des actions sur celle-ci, ce qui permet de gagner du temps et de réduire la complexité.

Voici les actions que vous pouvez effectuer sur les entités à l’aide de ce type de playbook :

  • Blocage d’un utilisateur compromis.
  • Blocage du trafic provenant d’une adresse IP malveillante dans votre pare-feu.
  • Isolement d’un hôte compromis sur votre réseau.
  • Ajout d’une adresse IP à une Watchlist d’adresses sécurisées/non sécurisées ou à votre CMDB externe.
  • Obtention d’un rapport de hachage de fichier à partir d’une source externe de renseignement sur les menaces et ajout à un incident en tant que commentaire.

Comment exécuter un playbook

Les playbooks peuvent être exécutés manuellement ou automatiquement.

Ils sont conçus pour être exécutés automatiquement, et idéalement c’est la façon dont ils doivent être exécutés dans le cours normal des opérations. Vous exécutez un playbook automatiquement en le définissant en tant que réponse automatisée dans une règle d’analyse (pour les alertes) ou en tant qu’action dans une règle d’automatisation (pour les incidents).

Toutefois, il existe des circonstances qui appellent à exécuter manuellement des playbooks. Par exemple :

  • Quand vous créez un playbook, vous devez le tester avant la mise en production.

  • Dans certaines situations, vous pourrez souhaiter avoir davantage de contrôle et qu’une intervention humaine soit nécessaire pour déterminer si un playbook donné doit s’exécuter et à quel moment.

    Vous exécutez un playbook manuellement en ouvrant un incident, une alerte ou une entité, puis en sélectionnant et en exécutant le playbook associé affiché ici. Actuellement, cette fonctionnalité est en disponibilité générale pour les alertes et en préversion pour les incidents et les entités.

Définir une réponse automatisée

Les équipes d’opérations de sécurité peuvent réduire considérablement leur charge de travail, ce qui leur permet de se concentrer sur des incidents et alertes uniques, d’analyser des modèles et de repérer les menaces, entre autres.

La définition de la réponse automatisée signifie que chaque fois qu’une règle d’analyse est déclenchée, en plus de créer une alerte, la règle exécute un playbook, qui reçoit comme entrée l’alerte créée par la règle.

Si l’alerte crée un incident, l’incident déclenchera une règle d’automatisation qui peut à son tour exécuter un playbook, qui recevra en tant qu’entrée l’incident créé par l’alerte.

Réponse automatisée de création d’alerte

Pour les règles qui sont déclenchées par la création d’une alerte et qui reçoivent des alertes comme entrées (la première étape est « Alerte Microsoft Sentinel »), attachez le playbook à une règle d’analyse :

  1. Modifiez la règle d’analyse qui génère l’alerte pour laquelle vous souhaitez définir une réponse automatisée.

  2. Sous Automatisation des alertes dans l’onglet Réponse automatisée, sélectionnez le ou les playbooks que cette règle d’analyse déclenchera lors de la création d’une alerte.

Réponse automatisée de création d’incident

Pour les playbooks qui sont déclenchés par la création d’un incident et qui reçoivent des incidents en tant qu’entrées (la première étape est « incident Microsoft Sentinel »), créez une règle d’automatisation et définissez une action d’Exécuter le playbook dans celle-ci. Cette opération peut être réalisée de 2 manières :

  • Modifiez la règle d’analyse qui génère l’incident pour lequel vous souhaitez définir une réponse automatisée. Sous Automatisation des incidents, dans l’onglet Réponse automatisée, créez une règle d’automatisation. Cela permet de créer une réponse automatisée uniquement pour cette règle d’analyse.

  • À partir de l’onglet Règles d’automatisation de la page Automatisation, créez une nouvelle règle d’automatisation et spécifiez les conditions appropriées et les actions souhaitées. Cette règle d’automatisation sera appliquée à toutes les règles d’analyse qui remplissent les conditions spécifiées.

    Notes

    Microsoft Sentinel nécessite des autorisations pour exécuter des playbooks de déclencheur d’incident.

    Pour exécuter un playbook basé sur le déclencheur d’incident, manuellement ou avec une règle d’automatisation, Microsoft Sentinel utilise un compte de service spécifiquement autorisé à le faire. L’utilisation de ce compte (par opposition à votre compte d’utilisateur) augmente le niveau de sécurité du service et permet à l’API de règles d’automatisation de prendre en charge les cas d’utilisation CI/CD.

    Ce compte doit disposer d’autorisations explicites (sous la forme du rôle Contributeur Automatisation Microsoft Sentinel) sur le groupe de ressources où se trouve le playbook. À ce stade, vous pouvez exécuter n’importe quel playbook dans ce groupe de ressources, manuellement ou avec une règle d’automatisation.

    Lorsque vous ajoutez l’action Exécuter le playbook à une règle d’automatisation, une liste déroulante de playbooks s’affiche pour votre sélection. Les playbooks sur lesquels Microsoft Sentinel n’a pas d’autorisation apparaissent indisponibles (« grisés »). Vous pouvez accorder l’autorisation à Microsoft Sentinel immédiatement en sélectionnant le lien Gérer les autorisations des playbooks.

    Dans un scénario à plusieurs locataires (Lighthouse), vous devez définir les autorisations sur le locataire dans lequel le playbook se trouve, même si la règle d’automatisation qui appelle le playbook est dans un locataire différent. Pour ce faire, vous devez disposer des autorisations de propriétaire sur le groupe de ressources du playbook.

    Il existe un seul scénario concernant un fournisseur MSSP (Managed Security Service Provider) , dans lequel un fournisseur de services, alors qu’il est connecté à son propre locataire, crée une règle d’automatisation sur l’espace de travail d’un client à l’aide d’Azure Lighthouse. Cette règle d’automatisation appelle ensuite un playbook appartenant au locataire du client. Dans ce cas, Microsoft Sentinel doit recevoir des autorisations sur les deux locataires. Dans le locataire du client, vous pouvez octroyer ces autorisations depuis le panneau Gérer les autorisations du playbook, comme dans le scénario multilocataire classique. Pour accorder les autorisations appropriées dans le locataire du fournisseur de services, vous devez ajouter une délégation Azure Lighthouse supplémentaire qui accorde des droits d’accès à l’application Azure Security Insights avec le rôle Contributeur Automatisation Microsoft Sentinel sur le groupe de ressources où se trouve le playbook. Découvrez comment ajouter cette délégation.

Consultez les instructions complètes pour la création de règles d’automatisation.

Exécuter un playbook manuellement

L’automatisation complète constitue la meilleure solution pour toutes les tâches de gestion, d’examen et d’atténuation des incidents que vous êtes en mesure d’automatiser en étant à l’aise. Néanmoins, il peut exister de bonnes raisons d’opter pour une sorte d’automatisation hybride : utilisation de playbooks en vue de consolider une chaîne d’activités sur une gamme de systèmes en une seule commande, mais exécution des playbooks uniquement quand et où vous le souhaitez. Par exemple :

  • Vous préférez peut-être que les analystes de votre centre des opérations de sécurité (SOC) aient plus de contrôle et de possibilités d’intervention humaine dans certaines situations.

  • Vous pouvez également souhaiter qu’ils soient en mesure d’agir contre des acteurs de menace (entités) spécifiques à la demande, dans le cadre d’un examen ou d’une chasse aux menaces, en contexte sans avoir à pivoter vers un autre écran. (Cette fonctionnalité est désormais disponible en préversion.)

  • Vous pouvez souhaiter que les ingénieurs de votre centre des opérations de sécurité (SOC) écrivent des playbooks qui agissent sur des entités spécifiques (actuellement en préversion) et qui ne peuvent être exécutés que manuellement.

  • Vous souhaitez probablement que vos ingénieurs SOC puissent tester les playbooks qu’ils écrivent avant de les déployer entièrement dans des règles d’automatisation.

Pour toutes ces raisons, entre autres, Microsoft Sentinel vous permet d’exécuter des playbooks manuellement à la demande pour les entités et les incidents (actuellement en préversion), ainsi que pour les alertes.

  • Pour exécuter un playbook en cas d’incident spécifique, sélectionnez l’incident dans la grille de la page Incidents. Sur le portail Azure, sélectionnez Actions dans le volet Incident, puis choisissez Exécuter le playbook (préversion) dans le menu contextuel. Dans le portail Defender, sélectionnez Exécuter le playbook (préversion) directement depuis la page détaillée de l’incident.

    Le panneau Exécuter le playbook en cas d’incident s’ouvre.

  • Pour exécuter un playbook en cas d’alerte, sélectionnez un incident, entrez les détails de l’incident et, sous l’onglet Alertes, choisissez une alerte et sélectionnez Voir les playbooks.

    Le panneau Playbooks d’alerte s’ouvre.

  • Pour exécuter un playbook sur une entité, sélectionnez une entité de l’une des manières suivantes :

    • Sous l’onglet Entités d’un incident, choisissez une entité dans la liste. Sélectionnez le lien Exécuter le playbook (préversion) à la fin de la ligne dans la liste.
    • Dans le graphique des examens, sélectionnez une entité et sélectionnez le bouton Exécuter le playbook (préversion) dans le panneau latéral de l’entité.
    • Dans Comportement de l’entité, sélectionnez une entité. Dans la page de l’entité, sélectionnez le bouton Exécuter le playbook (préversion) dans le panneau gauche.

    Chacune de ces actions permet d’ouvrir le panneau Exécuter le playbook sur le <type d’entité>.

Deux onglets sont affichés dans ces panneaux : Playbooks et Exécutions.

  • Dans l’onglet Playbooks, la liste de tous les playbooks auxquels vous avez accès et qui utilisent le déclencheur approprié s’affiche, qu’il s’agisse du déclencheur Incident Microsoft Sentinel, Alerte Microsoft Sentinel ou Entité Microsoft Sentinel. Chaque playbook de la liste a un bouton Exécuter que vous sélectionnez pour exécuter immédiatement le playbook.
    Pour exécuter un playbook de déclencheur d’incident que vous ne voyez pas dans la liste, consultez la note sur les autorisations Microsoft Sentinel ci-dessus.

  • Sous l’onglet Exécutions, vous voyez la liste de toutes les fois où un playbook a été exécuté à partir d’un incident ou d’une alerte que vous avez sélectionné. L’affichage des exécutions qui viennent d’être terminées dans cette liste peut prendre quelques secondes. Sélectionner une exécution spécifique permet d’ouvrir le journal complet des exécutions dans Azure Logic Apps.

Gérer vos playbooks

L’onglet Playbooks actifs affiche une liste de tous les playbooks auxquels vous avez accès, filtrés par les abonnements qui sont actuellement affichés dans Azure. Le filtre d’abonnement est disponible dans le menu Répertoire + abonnement de l’en-tête global de la page.

En cliquant sur un nom de playbook, vous êtes dirigé vers la page principale du playbook dans Azure Logic Apps. La colonne État indique s’il est activé ou désactivé.

La colonne Plan indique si le playbook utilise le type de ressource Standard ou Consommation dans Azure Logic Apps. Vous pouvez filtrer la liste par type de plan pour afficher un seul type de playbook. Vous remarquerez que les playbooks du type Standard utilisent la convention d’affectation de noms LogicApp/Workflow. Cette convention reflète le fait qu’un playbook standard représente un flux de travail qui existe avec d’autres flux de travail dans une application logique unique.

Le Type de déclencheur représente le déclencheur Azure Logic Apps qui démarre ce playbook.

Type de déclencheur Indique les types de composants dans le playbook
Incident/alerte/entité Microsoft Sentinel Le playbook est démarré avec l’un des déclencheurs Sentinel (alerte, incident, entité)
Utilisation de l’action Microsoft Sentinel Le playbook est démarré avec un déclencheur non Sentinel, mais utilise une action Microsoft Sentinel
Autres Le playbook n’inclut aucun composant Sentinel
Non initialisé Le playbook a été créé, mais il ne contient aucun composant (déclencheurs ou actions).

Dans la page Azure Logic Apps du playbook, vous pouvez obtenir plus d’informations sur le playbook, y compris un journal de toutes les heures d’exécution et le résultat (réussite ou échec, ainsi que d’autres détails). Vous pouvez également ouvrir le concepteur de flux de travail dans Azure Logic Apps et modifier le playbook directement, si vous disposez des autorisations appropriées.

Connexions d’API

Les connexions d’API sont utilisées pour connecter Azure Logic Apps à d’autres services. Chaque fois qu’une nouvelle authentification à un connecteur dans Azure Logic Apps, une nouvelle ressource de type Connexion d’API est créée et contient les informations fournies lors de la configuration de l’accès au service.

Pour afficher toutes les connexions d’API, entrez Connexions d’API dans la zone de recherche d’en-tête du portail Azure. Notez les colonnes suivantes :

  • Nom d’affichage : le nom « convivial » que vous attribuez à la connexion chaque fois que vous en créez une.
  • État : indique l’état de la connexion : erreur, connecté.
  • Groupe de ressources : les connexions d’API sont créées dans le groupe de ressources de la ressource du playbook (Azure Logic Apps).

Pour afficher les connexions d’API, vous pouvez également accéder à la page Toutes les ressources et les filtrer par type de connexion d’API. Ainsi, vous pouvez sélectionner, marquer et supprimer plusieurs connexions à la fois.

Pour modifier l’autorisation d’une connexion existante, entrez la ressource de connexion, puis sélectionnez Modifier la connexion d’API.

Les playbooks recommandés suivants et d’autres playbooks similaires sont disponibles dans le hub de contenu ou dans le dépôt Github Microsoft Sentinel :

Étapes suivantes