Cet article explique comment automatiser les opérations de déploiement et d’intégration de Microsoft Sentinel avec Azure DevOps. Vous implémentez Azure DevOps avec des fonctionnalités Microsoft Sentinel pour sécuriser votre déploiement. Ensuite, vous utilisez un framework DevSecOps pour gérer et déployer les artefacts Microsoft Sentinel à grande échelle.
Architecture
Le diagramme suivant illustre une configuration Azure DevOps et Microsoft Sentinel IaC.
Téléchargez un fichier Visio de cette architecture.
Dataflow
- Le Scrum Master et les responsables produit utilisent Azure DevOps pour définir des narrations, des récits utilisateur et des éléments de backlog de produit dans le cadre du backlog du projet.
- Le Scrum Master et les responsables produit utilisent Azure Boards pour créer le backlog, planifier le travail dans les sprints, passer en revue le tableau de bord du projet, créer la structure du dépôt et définir des règles de sécurité telles que les workflows d’approbation et les branches.
- Le dépôt Azure Git stocke les scripts et les autorisations pour gérer les artefacts Microsoft Sentinel dans l’infrastructure en tant que code.
- Les artefacts et le contrôle de code source gèrent les extensions et mettent à jour les packages ou les composants du workflow DevSecOps utilisés dans la solution, tels que la boîte à outils de modèles Azure Resource Manager et PowerShell Pester.
- Artefacts Microsoft Sentinel :
- Stratégies : Les ingénieurs SIEM utilisent des stratégies Azure dans l’architecture de référence pour configurer et mettre à l’échelle les paramètres de diagnostic des services Azure. Les stratégies aident à automatiser le déploiement des connecteurs de données Microsoft Sentinel, tels qu’Azure Key Vault. Les stratégies dépendent de l’API OMSIntegration.
- Connecteurs. Microsoft Sentinel utilise des connecteurs logiques, les connecteurs de données Azure, pour ingérer des données de sécurité, comme dans les audits ou les métriques, à partir de sources de données prises en charge, telles que Microsoft Entra ID, les ressources Azure, Microsoft Defender ou des solutions tierces. La liste principale des connecteurs de données est gérée par l’API SecurityInsights. D’autres s’appuient sur l’API OMSIntegration et sont gérés avec les paramètres de diagnostic Azure Policy.
- Identité managée. Microsoft Sentinel utilise l’identité managée pour agir au nom de l’identité MSI (Managed Service Identity) tout en interagissant avec les playbooks, les applications logiques ou les runbooks d’automatisation et le coffre de clés.
- Automatisation. Les équipes SOC utilisent l’automatisation lors des investigations. Les équipes SOC exécutent des procédures d’acquisition de données d’investigation numérique avec Azure Automation, telles que la chaîne de responsabilité des machines virtuelles Azure ou eDiscovery (Premium) pour Microsoft defender.
- Analytique. Les analystes SOC ou les chasseurs de menaces utilisent des règles analytiques intégrées ou personnalisées pour analyser et mettre en corrélation des données dans Microsoft Sentinel, ou pour déclencher des playbooks si une menace et un incident sont identifiés.
- Playbooks. Les applications logiques exécutent les actions SecOps reproductibles, comme l’attribution d’un incident, la mise à jour d’un incident ou l’exécution d’actions correctives, comme l’isolement ou le confinement d’une machine virtuelle, la révocation d’un jeton ou la réinitialisation d’un mot de passe utilisateur.
- Repérer les menaces. Les chasseurs de menaces utilisent des fonctionnalités proactives de chasse aux menaces qui peuvent être associées à des notebooks Jupyter pour des cas d’usage avancés, comme le traitement des données, la manipulation des données, la visualisation des données, le machine learning ou le deep learning.
- Classeurs. Les ingénieurs SIEM utilisent des tableaux de bord de workbooks pour visualiser les tendances et les statistiques, et pour voir l’état d’une instance Microsoft Sentinel et de ses sous-composants.
- Informations sur les menaces. Un connecteur de données spécifique qui fusionne les flux des plateformes de renseignement sur les menaces dans Microsoft Sentinel. Deux méthodes de connectivité sont prises en charge : TAXII et API Graph. Les deux méthodes sont utilisées comme tiIndicators, ou indicateurs de renseignement sur les menaces, dans les API de sécurité.
- Microsoft Entra ID. Des fonctionnalités de gestion des identités et des accès sont fournies aux composants utilisés dans l’architecture de référence, comme les identités managées, les principaux de service, les contrôles d’accès en fonction du rôle Azure (RBAC) pour Microsoft Sentinel, les applications logiques et les runbooks d’automatisation.
- Azure Pipelines. Les ingénieurs DevOps utilisent des pipelines pour créer des connexions de service afin de gérer les différents abonnements Azure, comme les environnements de bac à sable et de production, avec des pipelines CI/CD (intégration continue et livraison continue). Nous vous recommandons d’utiliser des workflows d’approbation pour empêcher les déploiements inattendus et les principaux de service séparés si vous ciblez plusieurs abonnements par environnement Azure.
- Azure Key Vault. Les ingénieurs SOC utilisent le coffre de clés pour stocker les secrets et certificats des principaux de service de manière sécurisée. Ce composant de l’architecture aide à appliquer le principe DevSecOps d’aucun secret dans le code quand il est utilisé par les connexions de service de pipeline Azure.
- Abonnement Azure. Les équipes SOC utilisent deux instances de Microsoft Sentinel dans cette architecture de référence, séparées dans deux abonnements Azure logiques pour simuler des environnements de production et de bac à sable. Vous pouvez effectuer une mise à l’échelle en fonction de vos besoins avec d’autres environnements, tels que le test, le développement, la préproduction, etc.
Exemple de flux de données
- Un administrateur ajoute, met à jour ou supprime une entrée dans sa fourche du fichier config de Microsoft 365.
- L’administrateur commite et synchronise les modifications apportées à son dépôt dupliqué.
- L’administrateur crée ensuite une demande de tirage (pull request) pour fusionner les modifications dans le dépôt principal.
- Le pipeline de build s’exécute sur la demande de tirage (pull request).
Composants
- Microsoft Entra ID est un service cloud pour gérer vos contrôles d’identité et d’accès.
- Azure DevOps est un service cloud qui vous permet de collaborer sur du code, de créer et de déployer des applications ou de planifier et de suivre votre travail.
- Azure Key Vault est un service cloud permettant de stocker les secrets et d’y accéder en toute sécurité. Un secret est un élément pour lequel vous voulez contrôler étroitement l’accès. Il peut s’agir de clés d’API, de mots de passe, de certificats ou de clés de chiffrement.
- Azure Policy est un service qui vous permet de créer, d’affecter et de gérer les définitions de stratégie dans votre environnement Azure.
- Microsoft Sentinel est une solution native cloud et scalable de type SIEM et SOAR (Security Orchestrated Automated Response).
- Azure Automation est un service destiné à simplifier la gestion du cloud via l’automatisation des processus. Utilisez Azure Automation pour automatiser les tâches répétitives, manuelles, de longue durée et susceptibles d’engendrer des erreurs. Automation aide à améliorer la fiabilité, l’efficacité et le retour sur investissement de votre entreprise.
Détails du scénario
Les équipes du centre des opérations de sécurité (SOC) rencontrent parfois des difficultés lors de l’intégration de Microsoft Sentinel avec Azure DevOps. Le processus implique de nombreuses étapes, et la configuration peut prendre des jours et impliquer des répétitions. Vous pouvez automatiser cette partie du développement.
Pour s’adapter au cloud, les ingénieurs doivent constamment apprendre de nouvelles compétences et techniques afin de sécuriser et protéger les ressources stratégiques de l’entreprise. Les ingénieurs doivent créer des solutions robustes et scalables qui s’adaptent aux besoins métier et au paysage de la sécurité en perpétuelle évolution. La solution de sécurité doit être flexible, agile et soigneusement planifiée dès les premières phases de développement. Cette méthodologie de planification anticipée est appelée shift-left.
Cet article explique comment automatiser les opérations de déploiement et d’intégration de Microsoft Sentinel avec Azure DevOps. Vous pouvez étendre la solution aux organisations complexes qui ont plusieurs entités, abonnements et divers modèles d’exploitation. Parmi les modèles d’exploitation pris en charge par cette solution, citons le SOC local, le SOC international, le CSP (fournisseur de services cloud) et le MSSP (fournisseur de services de sécurité managés).
Cet article s’adresse aux audiences suivantes :
- Spécialistes SOC, comme les analystes et les chasseurs de menaces
- Ingénieurs SIEM (Security Information and Event Management)
- Architectes de cybersécurité
- Développeurs
Cas d’usage potentiels
Voici les cas d’usage classiques pour cette architecture :
- Prototypage rapide et preuve de concept. Cette solution est idéale pour les organisations de sécurité et les équipes SOC qui souhaitent améliorer la couverture des menaces dans le cloud, ou moderniser leur infrastructure SIEM avec une Infrastructure en tant que code (IaC) et Microsoft Sentinel.
- Microsoft Sentinel en tant que service. Ce framework de développement intègre des principes de gestion du cycle de vie des services. Ces principes conviennent aux équipes simples ou complexes, telles que les MSSP qui exécutent des actions standardisées et reproductibles sur plusieurs locataires client tout en combinant la puissance d’Azure DevOps et d’Azure Lighthouse. Par exemple, une équipe qui doit publier des cas d’usage Microsoft Sentinel pour un nouvel acteur de menace ou une campagne en cours peut utiliser cette solution.
- Création de cas d’usage SOC pour la détection des menaces. De nombreux groupes et plateformes de renseignement sur les menaces s’appuient sur le contenu et la taxonomie MITRE Att&ck pour analyser leur posture de sécurité par rapport aux techniques avancées, ou aux procédures tactiques et techniques. La solution définit une approche structurée pour le développement des pratiques d’ingénierie de détection des menaces, en incorporant la terminologie MITRE Att&ck dans le développement des artefacts Microsoft Sentinel.
L’illustration suivante montre un scénario de cloud MITRE Att&ck.
Téléchargez un fichier Visio de cette architecture.
Scénarios d’attaque par définition de menace basés sur MITRE
Ce tableau présente les termes, définitions et détails des aspects importants des scénarios d’attaque.
| Élément de données | Description | Artefacts Microsoft Sentinel |
|---|---|---|
| Titre | Nom descriptif du scénario d’attaque, en fonction des caractéristiques du vecteur d’attaque ou des descriptions des techniques. | Manifeste MITRE |
| Tactiques MITRE ATTA&CK | Tactiques MITRE ATT&CK liées au scénario d’attaque | Manifeste MITRE |
| Techniques MITRE ATT&CK | Techniques MITRE ATT&CK, y compris l’ID de technique ou sous-technique, associées au scénario d’attaque. | Manifeste MITRE |
| Sources de connecteur de données | Source d’informations collectées par un capteur ou un système de journalisation qui peut être utilisé pour collecter des informations relatives à l’identification de l’action en cours d’exécution, à l’ordre des actions ou aux résultats de ces actions par une personne mal intentionnée. | Connecteur de données Microsoft Sentinel ou source de journal personnalisée |
| Description | Informations sur la technique, sa nature, sa finalité, la manière dont une personne mal intentionnée peut en tirer parti et les variantes de son utilisation. Contient des références à des articles faisant autorité décrivant des informations techniques relatives à la technique ainsi que des informations de référence sur des utilisations réelles, le cas échéant. | |
| Détection | Processus d’analytique général, capteurs, données et stratégies de détection utiles pour identifier une technique qui a été utilisée par un adversaire. Cette section informe les responsables de la détection du comportement de la personne mal intentionnée, tels que les défenseurs de réseau, afin qu’ils puissent prendre une mesure telle que l’écriture d’une analytique ou le déploiement d’un capteur. Il doit y avoir suffisamment d’informations et de références pour pointer vers des méthodologies défensives utiles. La détection peut ne pas être toujours possible pour une technique donnée et doit être documentée comme telle. | Chasse aux menaces avec des analytiques |
| Limitation des risques | Configurations, outils ou processus qui empêchent une technique de fonctionner ou d’avoir le résultat souhaité pour une personne mal intentionnée. Cette section informe les responsables de l’atténuation vis-à-vis des personnes mal intentionnées, tels que les défenseurs de réseau ou les décideurs, pour leur permettre de prendre une mesure telle que la modification d’une stratégie ou le déploiement d’un outil. L’atténuation peut ne pas être toujours possible pour une technique donnée et doit être documentée comme telle. | |
| Limitation des risques | Configurations, outils ou processus qui empêchent une technique de fonctionner ou d’avoir le résultat souhaité pour une personne mal intentionnée. Cette section décrit comment réduire les effets des attaques d’une personne mal intentionnée pour les défenseurs du réseau ou les décideurs. Elle décrit les étapes de modification d’une stratégie ou de déploiement d’un outil. L’atténuation peut ne pas être toujours possible pour une technique donnée et doit être documentée comme telle. | Playbooks, runbooks d’automatisation |
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.
Avec la sécurité, en général, l’automatisation augmente l’efficacité des opérations tout en économisant du temps pour des cas d’usage plus complexes, tels que l’ingénierie de détection des menaces, le renseignement sur les menaces ainsi que les cas d’usage SOC et SOAR. Les équipes DevOps doivent savoir où elles peuvent utiliser l’infrastructure IaC de manière sécurisée dans le contexte des pratiques CI/CD Microsoft Sentinel. Ce processus introduit l'utilisation d'identités spécifiques utilisées par des comptes non humains dans Microsoft Entra ID, appelées principaux de service et identités gérées.
Le tableau suivant récapitule les considérations relatives à la sécurité pour les principaux de service et les principaux cas d’usage couverts par les pipelines de mise en production Azure DevOps et Microsoft Sentinel.
| Cas d’utilisation | Exigences (privilèges minimum) | Durée de l’attribution de rôle | Étendue d’autorisation | Tiers de confiance | Considérations relatives à la sécurité |
|---|---|---|---|---|---|
| Activer les connecteurs Microsoft Sentinel | Administrateur de la sécurité** Propriétaire* Contributeur Microsoft Sentinel Lecteur |
JIT (activation unique) À l’usage (chaque fois qu’un nouvel abonnement et un nouveau connecteur sont déployés) |
Locataire | SPN | Utilisez le coffre de clés pour stocker les secrets et le certificat du nom de principal du service (SPN). Activez l’audit du SPN. Vérifiez régulièrement l’attribution d’autorisations (Azure Privileged Identity Management pour le SPN) ou l’activité suspecte pour le SPN. Utilisez les autorités de certification Microsoft Entra et l'authentification multifacteur (si prise en charge) pour les comptes privilégiés. Utilisez les rôles personnalisés Microsoft Entra pour plus de granularité. |
| Déployer des artefacts Microsoft Sentinel, tels que des workbooks, des analytiques, des règles, des requêtes de chasse aux menaces, des notebooks et des playbooks | Contributeur Microsoft Sentinel Contributeur Logic Apps |
Permanent | Espace de travail ou groupe de ressources de Microsoft Sentinel | SPN | Utilisez l’approbation de workflow Azure DevOps (ADO) et les vérifications pour sécuriser le déploiement de pipeline avec ce SPN. |
| Affecter une stratégie pour configurer les fonctionnalités de streaming de journaux vers Microsoft Sentinel | Contributeur de stratégie de ressource ** | À l’usage (chaque fois qu’un nouvel abonnement et un nouveau connecteur sont déployés) | Tous les abonnements à superviser | SPN | Utilisez Microsoft Entra ID, CA et MFA, lorsqu'ils sont pris en charge, pour les comptes privilégiés. |
* Concerne uniquement les paramètres de diagnostic de Microsoft Entra.
** Les connecteurs spécifiques nécessitent des autorisations supplémentaires telles que « administrateur de sécurité » ou « contributeur de stratégie de ressources » pour permettre la diffusion de données en continu vers l'espace de travail Microsoft Sentinel, Microsoft Entra ID, Microsoft 365 ou Microsoft Defender et les ressources de plateforme en tant que service (PaaS) comme Azure Key Vault. .
Modèle de l’accès privilégié
Nous vous recommandons d’adopter une stratégie de modèle d’accès privilégié pour réduire rapidement les risques que font peser sur votre entreprise les attaques d’accès privilégié, attaques à fort impact présentant une probabilité élevée. Dans le cas de processus automatiques dans un modèle DevOps, basez l’identité sur les identités du principal de service.
L’accès privilégié doit être une priorité majeure de toute entreprise en termes de sécurité. Toute compromission de ces identités crée des impacts très négatifs. Les identités privilégiées ont accès aux ressources vitales pour l’entreprise, ce qui entraîne presque toujours un impact majeur quand des attaquants compromettent ces comptes.
La sécurité de l’accès privilégié est primordiale, car elle est au cœur de toutes les autres garanties de sécurité. Un attaquant prenant le contrôle vos comptes privilégiés peut affaiblir toutes les autres garanties de sécurité.
Pour cette raison, nous vous recommandons de répartir logiquement les principaux de service dans différents niveaux ou couches en suivant un principe de privilège minimal. L’illustration suivante montre comment classifier les principaux de service, en fonction du type d’accès et de l’emplacement où l’accès est requis.
Principaux de service de niveau 0
Les principaux de service de niveau 0 disposent du niveau d’autorisation le plus élevé. Ces principaux de service habilitent quelqu’un à effectuer des tâches d’administration de groupe d’administration racine ou à l’échelle du locataire en tant qu’administrateur général.
Pour des raisons de sécurité et de facilité de gestion, nous vous recommandons de n’avoir qu’un seul principal de service pour ce niveau. Les autorisations pour ce principal de service étant conservées, nous vous recommandons d’accorder uniquement les autorisations minimales requises et de maintenir le compte supervisé et sécurisé.
Stockez le secret ou le certificat pour ce compte de manière sécurisée dans Azure Key Vault. Nous vous recommandons vivement de placer le coffre de clés dans un abonnement administratif dédié, si possible.
Principaux de service de niveau 1
Les principaux de service de niveau 1 sont des autorisations élevées limitées et étendues à des groupes d’administration au niveau de l’organisation. Ces principaux de service habilitent quelqu’un à créer des abonnements dans le cadre du groupe d’administration qui se trouve dans l’étendue.
Pour des raisons de sécurité et de facilité de gestion, nous vous recommandons de n’avoir qu’un seul principal de service pour ce niveau. Les autorisations pour ce principal de service étant conservées, nous vous recommandons vivement d’accorder uniquement les autorisations minimales requises et de maintenir le compte supervisé et sécurisé.
Stockez le secret ou le certificat pour ce compte de manière sécurisée dans Azure Key Vault. Nous vous recommandons vivement de placer le coffre de clés dans un abonnement administratif dédié, si possible.
Principaux de service de niveau 2
Les principaux de service de niveau 2 sont limités au niveau d’abonnement. Ces principaux de service habilitent quelqu’un à effectuer des tâches d’administration dans le cadre d’un abonnement, faisant ainsi office de propriétaire de l’abonnement.
Pour des raisons de sécurité et de facilité de gestion, nous vous recommandons de n’avoir qu’un seul principal de service pour ce niveau. Les autorisations pour ce principal de service étant conservées, nous vous recommandons vivement d’accorder uniquement les autorisations minimales requises et de maintenir le compte supervisé et sécurisé.
Stockez le secret ou le certificat pour ce compte de manière sécurisée dans Azure Key Vault. Nous vous recommandons vivement de placer le coffre de clés dans un groupe de ressources administratif dédié.
Principaux de service de niveau 3
Les principaux de service de niveau 3 sont limités à l’administrateur de charge de travail. Dans un scénario classique, chaque charge de travail est contenue dans le même groupe de ressources. Cette structure limite les autorisations du principal de service uniquement à ce groupe de ressources.
Pour des raisons de sécurité et de facilité de gestion, nous vous recommandons de n’avoir qu’un seul principal de service par charge de travail. Les autorisations pour ce principal de service étant conservées, nous vous recommandons vivement d’accorder uniquement les autorisations minimales requises et de maintenir le compte supervisé et sécurisé.
Stockez le secret ou le certificat pour ce compte de manière sécurisée dans Azure Key Vault. Nous vous recommandons vivement de placer le coffre de clés dans un groupe de ressources administratif dédié.
Principaux de service de niveau 4
Les principaux de service de niveau 4 disposent des autorisations les plus limitées. Ces principaux de service habilitent quelqu’un à effectuer des tâches d’administration limitées à une seule ressource.
Nous vous recommandons d’utiliser des identités managées dans la mesure du possible. Dans le cas d’identités non managées, stockez le secret ou le certificat de manière sécurisée dans Azure Key Vault où sont stockés les secrets de niveau 3.
Excellence opérationnelle
L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.
Les solutions Microsoft Sentinel sont composées de trois blocs, qui garantissent des opérations complètes et réussies.
Le premier bloc est la définition de l’environnement, qui constitue les éléments essentiels de l’architecture. Dans le cadre de ce bloc, vous vous attachez essentiellement à évaluer le nombre d’environnements de production et de non-production à déployer, puis à vérifier que la configuration est homogène dans tous les cas.
Le deuxième bloc est le déploiement des connecteurs Microsoft Sentinel, où vous envisagez les types de connecteurs requis par votre équipe et les exigences de sécurité pour les activer.
Le troisième bloc est la gestion du cycle de vie des artefacts Microsoft Sentinel, qui couvre le développement, le déploiement, l’utilisation ou la destruction des composants. Par exemple, ce bloc contient les règles analytiques, les playbooks, les workbooks, la chasse aux menaces, etc.
Tenez compte des dépendances entre les artefacts :
- Règles d’automatisation définies dans une règle d’analytique
- Workbooks ou analytiques qui nécessitent une nouvelle source de données ou un nouveau connecteur
- Gestion des mises à jour des composants existants
- Comment gérer les versions de vos artefacts
- Comment identifier, tester et déployer une règle d’analytique mise à jour ou entièrement nouvelle
Générer, tester et déployer l’infrastructure
Quand vous gérez les solutions Microsoft Sentinel et DevOps, vous devez prendre en compte les aspects de la connectivité et de la sécurité de l’architecture de votre entreprise.
Azure DevOps pouvez utiliser des agents hébergés par Microsoft ou des agents autohébergés pour des activités de génération, de test et de déploiement. En fonction des exigences de votre entreprise, vous pouvez utiliser l’autohébergement, l’hébergement par Microsoft ou une combinaison des deux modèles.
- Agents hébergés par Microsoft. Cette option est le moyen le plus rapide d’utiliser des agents Azure DevOps, car il s’agit d’une infrastructure partagée pour l’ensemble de votre organisation. Pour plus d’informations sur l’utilisation d’agents hébergés par Microsoft dans votre pipeline, consultez Agents hébergés par Microsoft. Les agents hébergés par Microsoft peuvent fonctionner dans des environnements de réseau hybride, en accordant l’accès aux plages d’adresses IP. Pour télécharger les plages d’adresses IP auxquelles ces agents accordent l’accès, consultez Plages d’adresses IP et étiquettes des services Azure - Cloud public.
- Agents auto-hébergés. Cette option vous offre des ressources dédiées et davantage de contrôle quand vous installez des logiciels dépendants pour vos builds et vos déploiements. Les agents autohébergés peuvent fonctionner sur des machines virtuelles, des groupes identiques et des conteneurs sur Azure. Pour plus d’informations sur les agents autohébergés, consultez Agents Azure Pipelines.
Exécuteurs GitHub
GitHub peut utiliser des exécuteurs hébergés par GitHub ou autohébergés pour les activités liées à la génération, au test et au déploiement. En fonction des besoins de votre entreprise, vous pouvez utiliser l’autohébergement, l’hébergement par GitHub ou une combinaison des deux modèles.
Exécuteurs hébergés par GitHub
Cette option est la méthode la plus rapide pour utiliser des workflows GitHub, car il s’agit d’une infrastructure partagée pour une organisation entière. Pour plus d’informations, consultez « À propos des exécuteurs hébergés par GitHub ». Les agents hébergés par GitHub fonctionnent dans des environnements réseau hybrides, en fonction de certaines exigences réseau. Pour plus d’informations sur les exigences réseau, consultez Exécuteurs et ressources matérielles pris en charge.
Exécuteurs auto-hébergés
Cette option offre à votre entreprise une infrastructure de ressources dédiées. Les exécuteurs autohébergés fonctionnent sur les machines virtuelles et les conteneurs sur Azure et prennent en charge la mise à l’échelle automatique.
Considérations relatives au choix des exécuteurs
Quand vous choisissez des options pour les agents et les exécuteurs dabs votre solution Microsoft Sentinel, tenez compte des besoins suivants :
- Votre entreprise a-t-elle besoin de ressources dédiées pour exécuter des processus sur vos environnements Microsoft Sentinel ?
- Voulez-vous isoler les ressources pour les activités DevOps de l’environnement de production du reste des environnements ?
- Avez-vous besoin de tester certains cas qui nécessitent l’accès à des ressources critiques ou à des ressources qui sont disponibles uniquement sur un réseau interne ?
Orchestration et automatisation des processus de mise en production
Vous pouvez configurer le processus de déploiement avec Azure DevOps ou GitHub. Azure DevOps prend en charge l’utilisation d’un pipeline YAML ou d’un pipeline de mise en production. Pour plus d’informations sur l’utilisation d’un pipeline YAML dans Azure DevOps, consultez Utiliser Azure Pipelines. Pour plus d’informations sur l’utilisation d’un pipeline de mise en production dans Azure DevOps, consultez Pipelines de mise en production. Pour plus d’informations sur l’utilisation de GitHub avec GitHub Actions, consultez Fonctionnement de GitHub Actions.
Azure DevOps
Vous pouvez effectuer les activités de déploiement suivantes dans un déploiement Azure DevOps.
- Utiliser un pipeline YAML pour déclencher des approbations de demande de tirage ou effectuer une exécution à la demande automatiquement.
- Gérer les connexions de service pour différents environnements avec des groupes Azure DevOps.
- Dans vos environnements critiques, configurer des approbations de déploiement en utilisant la fonctionnalité de connexion de service et des groupes Azure DevOps pour attribuer des autorisations utilisateur spécifiques dans votre équipe.
GitHub
Vous pouvez effectuer les activités de déploiement suivantes dans un déploiement GitHub.
- Utiliser GitHub pour créer des demandes de tirage ou des activités de déploiement.
- Gérer les informations d’identification des principaux de service avec des secrets GitHub.
- Intégrer l’approbation du déploiement par le biais du workflow associé à GitHub.
Déploiement automatique avec l’infrastructure Microsoft Sentinel
Vous pouvez déployer un ou plusieurs environnements Microsoft Sentinel, en fonction de l’architecture de votre entreprise :
- Les organisations qui ont besoin de plusieurs instances dans leur environnement de production peuvent configurer différents abonnements sur le même locataire pour chaque emplacement géographique.
- Une instance centralisée sur l’environnement de production donne accès à une ou plusieurs organisations du même locataire.
- Les groupes qui ont besoin de plusieurs environnements tels que production, préproduction, intégration, etc. peuvent les créer et les détruire en fonction des besoins.
Définition d’environnement physique et définition d’environnement logique
Vous avez deux possibilités pour configurer vos définitions d’environnement : définition physique ou définition logique. Les deux offrent des options et des avantages différents :
- Définition physique : les éléments de l’architecture Microsoft Sentinel sont définis avec les options suivantes d’Infrastructure en tant que code (IaC) :
- Modèles Bicep
- Modèles Azure Resource Manager (modèles ARM)
- Terraform
- Définition logique : couche d’abstraction pour la configuration de différentes équipes dans le groupe et la définition de leurs environnements. La définition est définie dans le pipeline de déploiement et les workflows en tant qu’entrée pour l’environnement de génération en utilisant la couche d’infrastructure physique.
Tenez compte des points suivants quand vous définissez vos environnements logiques :
- Conventions d’affectation de noms
- Identifications des environnements
- Connecteurs et configurations
Dépôt de code
Étant donné les approches d’environnement qui sont présentées dans la section précédente, envisagez l’organisation du dépôt de code GitHub suivante.
Définition physique : en fonction des options IaC, pensez à une approche qui utilise des définitions de module individuelles liées dans la définition de déploiement principale.
L’exemple suivant montre comment votre code peut être organisé.
Limitez l’accès à ce dépôt à l’équipe qui définit l’architecture au niveau physique, garantissant ainsi une définition homogène dans l’architecture d’entreprise.
Vous pouvez adapter la stratégie de branchement et de fusion à la stratégie de déploiement pour chaque organisation. Si votre équipe doit commencer par la définition, consultez Adopter une stratégie de branchement Git.
Pour plus d’informations sur les modèles ARM, consultez Utilisation de modèles liés et imbriqués durant le déploiement de ressources Azure.
Pour plus d’informations sur la configuration d’environnements Bicep, consultez Installer les outils Bicep. Pour plus d’informations sur GitHub, consultez Flux GitHub.
Les définitions logiques définissent les environnements d’une entreprise. Le dépôt Git recueille les différentes définitions d’une entreprise.
L’exemple suivant montre comment votre code peut être organisé.
Le dépôt reflète les actions de demande de tirage effectuées par différentes équipes. Plusieurs environnements sont définis par différentes équipes et approuvés par les propriétaires ou les approbateurs de l’entreprise.
Le niveau de privilège pour l’exécution d’un déploiement d’environnement est le niveau 2. Ce niveau garantit que le groupe de ressources et les ressources sont créés pour l’environnement avec la sécurité et la confidentialité nécessaires. Ce niveau définit également les autorisations utilisateur sur les actions autorisées dans les environnements de production, la production et la préproduction.
Les organisations qui veulent des environnements à la demande pour le test et le développement et la possibilité de détruire les environnements après avoir terminé leur test peuvent implémenter un pipeline Azure DevOps ou des actions GitHub. Elles peuvent définir des déclencheurs planifiés pour détruire les environnements en fonction des besoins en utilisant des événements Azure DevOps ou des actions GitHub.
Configuration automatique des connecteurs Microsoft Sentinel
Les connecteurs Microsoft Sentinel constituent un élément essentiel de la solution qui prend en charge la connexion avec différents éléments du paysage de l'architecture d'entreprise, tels que Microsoft Entra ID, Microsoft 365, Microsoft Defender, les solutions de plateforme de renseignement sur les menaces, etc.
Quand vous définissez un environnement, vous pouvez utiliser la configuration des connecteurs pour configurer des environnements avec des configurations homogènes.
L’activation de connecteurs dans le cadre du modèle DevOps doit être prise en charge par le modèle de niveau de service principal. Ainsi, le niveau d’autorisations approprié est appliqué, comme indiqué dans le tableau suivant.
| Scénario de connecteur | Niveau du modèle d’accès avec privilège | Privilège minimum | Nécessite l’approbation du workflow |
|---|---|---|---|
| Microsoft Entra ID | Niveau 0 | Administrateur général ou administrateur de la sécurité | Recommandé |
| Protection de l'identifiant Microsoft Entra | Niveau 0 | Administrateur général ou administrateur de la sécurité | Recommandé |
| Microsoft Defender pour Identity | Niveau 0 | Administrateur général ou administrateur de la sécurité | Recommandé |
| Microsoft Office 365 | Niveau 0 | Administrateur général ou administrateur de la sécurité | Recommandé |
| Microsoft Cloud App Security | Niveau 0 | Administrateur général ou administrateur de la sécurité | Recommandé |
| Microsoft Defender XDR | Niveau 0 | Administrateur général ou administrateur de la sécurité | Recommandé |
| Microsoft Defender pour IOT | Niveau 2 | Contributeur | Recommandé |
| Microsoft Defender pour le cloud | Niveau 2 | Lecteur de sécurité | Facultatif |
| Activité Azure | Niveau 2 | Lecteur de l’abonnement | Facultatif |
| Threat Intelligence Platforms | Niveau 0 | Administrateur général ou administrateur de la sécurité | Recommandé |
| Événements de sécurité | Niveau 4 | Aucun | Facultatif |
| syslog | Niveau 4 | Aucun | Facultatif |
| DNS (préversion) | Niveau 4 | Aucun | Facultatif |
| Pare-feu Windows | Niveau 4 | Aucun | Facultatif |
| Événements de sécurité Windows via AMA | Niveau 4 | Aucun | Facultatif |
Déploiement d’artefacts Microsoft Sentinel
Dans l’implémentation des artefacts Microsoft Sentinel, DevOps gagne en pertinence, car chaque entreprise crée plusieurs artefacts pour empêcher et corriger les attaques.
L’implémentation des artefacts peut être la responsabilité d’une équipe ou de plusieurs équipes. Le déploiement automatique des builds et des artefacts est souvent l’exigence la plus courante en matière de processus et détermine l’approche et les conditions de vos agents et exécuteurs.
Le déploiement et la gestion des artefacts Microsoft Sentinel nécessitent l’utilisation de l’API REST Microsoft Sentinel. Pour plus d’informations, consultez API REST Microsoft Sentinel. Le diagramme suivant montre un pipeline Azure DevOps sur une pile d’API REST Azure.
Vous pouvez également implémenter votre dépôt avec PowerShell.
Si votre équipe utilise MITRE, pensez à classifier les différents artefacts et à spécifier les tactiques et les techniques pour chacun d’entre eux. Veillez à inclure un fichier de métadonnées correspondant pour chaque type d’artefact.
Par exemple, si vous créez un playbook en utilisant un modèle ARM Azure et que le nom de fichier est Playbook.arm.json, vous ajoutez un fichier JSON nommé Playbook.arm.mitre.json. Les métadonnées de ce fichier incluent ensuite les formats CSV, JSON ou YAML qui correspondent aux tactiques ou techniques MITRE que vous utilisez.
En suivant cette pratique, votre équipe peut évaluer votre couverture MITRE en fonction des travaux qui sont effectués au cours de la configuration pour les différents types d’artefacts que vous utilisez.
Artefacts de build
L’objectif de votre processus de génération est de vous assurer que les artefacts que vous générez soient de qualité maximale. Le diagramme suivant montre quelques-unes des actions de processus de génération que vous pouvez effectuer.
Téléchargez un fichier Visio de cette architecture.
- Vous pouvez baser votre définition d’artefact sur un schéma descriptif au format JSON ou YAML, puis valider le schéma pour éviter les erreurs de syntaxe.
- Validez vos modèles ARM en utilisant le kit de ressources de test de modèle ARM.
- Validez vos fichiers YAML et JSON pour les modèles personnalisés avec PowerShell.
- Validez vos paramètres Watchlist et assurez-vous que les enregistrements CIDR (Classless Inter-Domain Routing) que vous définissez suivent le schéma correct, par exemple, 10.1.0.0/16.
- Utilisez des requêtes KQL (Keyword Query Language), que vous pouvez valider au niveau de la syntaxe, pour les règles d’analytique, les règles de chasse et les règles de stream en direct, que vous pouvez valider au niveau de la syntaxe.
- Faites de la validation locale KQL une option.
- Intégrez l’outil de validation inline KQL au pipeline DevOps.
- Si vous implémentez une logique basée sur PowerShell pour Azure Automation, vous pouvez inclure la validation de la syntaxe et les tests unitaires en utilisant les éléments suivants :
- Générez le rapport de métadonnées de manifeste MITRE en fonction des fichiers de métadonnées inclus avec les artefacts.
Exportation des artefacts
En règle générale, plusieurs équipes travaillent sur plusieurs instances de Microsoft Sentinel pour générer les artefacts nécessaires et les valider. Dans le but de réutiliser les artefacts existants, votre entreprise peut configurer des processus automatiques pour obtenir les définitions d’artefact à partir d’environnements existants. L’automatisation peut également fournir des informations sur tous les artefacts créés par différentes équipes de développement au cours de la configuration.
Le diagramme suivant illustre un processus d’extraction d’artefacts.
Téléchargez un fichier Visio de cette architecture.
Déployer des artefacts
Les objectifs de votre processus de déploiement sont les suivants :
- Réduire le délai de commercialisation.
- Améliorer les performances des différentes équipes impliquées dans la configuration et la gestion de votre solution.
- Configurer des tests d’intégration pour évaluer l’intégrité de l’environnement.
Les équipes de développement utilisent le processus pour s’assurer qu’elles peuvent déployer, tester et valider les cas d’utilisation d’artefact en cours de développement. Les équipes architecture et SOC valident la qualité du pipeline sur les environnements AQ et utilisent les tests d’intégration pour les scénarios d’attaque. Dans les cas de test, une équipe combine généralement des artefacts différents en tant que règles analytiques, playbooks correctifs, Watchlists, etc. Une partie de chaque cas d’usage consiste à simuler des attaques dans lesquelles la chaîne entière est évaluée à partir de l’ingestion, de la détection et de la correction.
Le diagramme suivant montre la séquence de processus de déploiement qui garantit que vos artefacts sont déployés dans le bon ordre.
Téléchargez un fichier Visio de cette architecture.
La gestion des artefacts Sentinel en tant que code vous permet de gérer vos opérations et d’automatiser le déploiement dans un pipeline DevOps CI/CD avec souplesse.
Les solutions Microsoft fournissent des workflows d’automatisation pour les artefacts suivants.
| Artefact | Workflows d’automatisation |
|---|---|
| Watchlists | Révision du code Validation de schéma Déploiement Créer, mettre à jour, supprimer des Watchlists et des éléments |
| Fusion des règles d’analytique Sécurité Microsoft Analytique comportementale ML Anomalie Planifié |
Révision du code Validation de la syntaxe KQL Validation du schéma Pester Déploiement Créer, activer, mettre à jour, supprimer, exporter Prise en charge des modèles d’alerte |
| Règles d’automatisation | Révision du code Validation du schéma Déploiement Créer, activer, mettre à jour, supprimer, exporter |
| Connecteurs | Révision du code Validation du schéma Déploiement Actions : activer, supprimer (désactiver), mettre à jour |
| Règles de chasse | Révision du code Validation de la syntaxe KQL Validation du schéma Pester Déploiement Actions : créer, activer, mettre à jour, supprimer, exporter |
| Playbooks | Révision du code TTK Déploiement Actions : créer, activer, mettre à jour, supprimer, exporter |
| Workbooks | Déploiement Actions : créer, mettre à jour, supprimer |
| Runbooks | Révision du code Validation de la syntaxe PowerShell Pester Déploiement Actions : créer, activer, mettre à jour, supprimer, exporter |
Selon le langage d’automatisation que vous choisissez, certaines fonctionnalités d’automatisation peuvent ne pas être prises en charge. Le diagramme suivant illustre les fonctionnalités d’automatisation prises en charge par langage.
* Fonctionnalités en développement qui ne sont pas encore documentées
** Méthodes d’automatisation prises en charge par Microsoft Operational Insights ou les API de fournisseur de ressources Microsoft Insights
Azure Automation
Le diagramme suivant illustre les composants de la simplification de l’accès à Microsoft Sentinel avec l’identité de service managée.
Téléchargez un fichier Visio de cette architecture.
Si vous devez accorder l’accès à d’autres ressources, utilisez l’identité managée, qui garantit une identité unique pour toutes les opérations critiques.
Utilisez Azure Automation pour configurer des playbooks. Utilisez des scripts PowerShell pour les tâches complexes et les fonctionnalités d’automatisation suivantes :
- Intégration à des solutions tierces, où différents niveaux d'informations d'identification sont requis et basés sur l'ID Microsoft Entra ou des informations d'identification personnalisées :
- Informations d'identification de l'utilisateur Microsoft Entra
- Informations d’identification du principal du service Microsoft Entra
- Authentification par certificat
- Informations d’identification personnalisées
- Identité managée
- Implémentation d’une solution qui réutilise des scripts organisationnels ou des solutions qui nécessitent l’utilisation de commandes PowerShell pour éviter une traduction complexe en playbooks :
- Solutions basées sur PowerShell
- Solutions basées sur Python
- Implémentation de solutions dans des scénarios hybrides, où les actions de correction peuvent affecter vos ressources cloud et locales.
Dépôts Microsoft Sentinel
Les équipes DevOps expérimentées peuvent gérer Microsoft Sentinel dans une Infrastructure en tant que code (IaC) avec des pipelines CI/CD intégrés à Azure DevOps. Les groupes produit comprennent les défis que doivent relever les clients et les partenaires lors de la création d’une architecture de sécurité Azure DevOps, de sorte que les deux initiatives suivantes peuvent s’avérer utiles :
- Documentation de l’architecture de référence
- Développement d’une nouvelle solution, annoncée à l’occasion d’Ignite 2021, appelée « Dépôts Microsoft Sentinel »
Pour faciliter le choix de la solution qui répond aux besoins de votre équipe, le tableau suivant compare les critères fonctionnels et techniques.
| Cas d’usage et fonctionnalités | Approche personnalisée Azure DevOps et GitHub | Dépôts Microsoft Sentinel |
|---|---|---|
| Nous souhaitons commencer rapidement à déployer des artefacts Microsoft Sentinel sans consacrer du temps à la définition de composants d’architecture Azure DevOps, tels que des agents, des pipelines, Git, des tableaux de bord, un wiki, des principaux de service, des contrôles d’accès en fonction du rôle, des audits, etc. | Non recommandé | Recommandé |
| Nous avons de petites équipes et peu de compétences pour gérer les pipelines CI/CD. | Non recommandé | Recommandé |
| Nous souhaitons contrôler et gérer tous les aspects de la sécurité des pipelines CI/CD. | Pris en charge | Non prise en charge |
| Nous devons intégrer des portes et des branchements pour la supervision de l’intégration, avant d’autoriser les développeurs à déclencher des pipelines de déploiement, tels que le contrôle de code source, la revue du code, la restauration, l’approbation du workflow, etc. | Prise en charge | Partiellement pris en charge |
| Nous avons une structure de dépôt ou Git personnalisée. | Prise en charge | Pris en charge |
| Nous n’utilisons pas Resource Manager ou de langages IaC Bicep pour créer des artefacts. | Prise en charge | Non prise en charge |
| Nous souhaitons gérer de manière centralisée le déploiement d’artefacts sur plusieurs espaces de travail Microsoft Sentinel dans un seul locataire Microsoft Entra. | Pris en charge | Pris en charge |
| Nous souhaitons intégrer ou étendre les pipelines CI/CD sur plusieurs locataires Microsoft Entra. | Pris en charge | Prise en charge |
| Nous avons des playbooks avec différents paramétrages en fonction de l’abonnement, de la localisation, de l’environnement, etc. | Pris en charge | TBD, indications à documenter |
| Nous souhaitons intégrer différents artefacts sur le même dépôt pour composer des cas d’usage. | Pris en charge | Pris en charge |
| Nous souhaitons pouvoir supprimer en bloc des artefacts. | Prise en charge | Non pris en charge |
Disponibilité, performances et scalabilité
Quand vous choisissez l’architecture pour les agents Azure DevOps de votre entreprise pour les scénarios Microsoft Sentinel, prenez en compte les besoins suivants :
- L’environnement de production peut nécessiter un pool d’agents dédié pour les opérations effectuées sur l’environnement Microsoft Sentinel.
- Les environnements hors production peuvent partager le pool d’agents avec un grand nombre d’instances pour gérer les différentes demandes des équipes, en particulier pour les pratiques CI/CD.
- Les scénarios de simulation d’attaque sont un cas particulier où des agents dédiés peuvent être nécessaires. Déterminez si un pool dédié est nécessaire à vos besoins de test.
- Les organisations qui travaillent sur des scénarios de réseau hybride peuvent envisager d’intégrer les agents au réseau.
Les organisations peuvent créer leurs propres images pour les agents en fonction de conteneurs. Pour plus d’informations, consultez Exécuter un agent autohébergé dans Docker.
Gestion inter-locataires Microsoft Sentinel avec Azure DevOps
En tant que SOC global ou MSSP, vous devrez peut-être gérer plusieurs locataires. Azure Lighthouse prend en charge des opérations à grande échelle sur plusieurs locataires Microsoft Entra en même temps, ce qui rend vos tâches de gestion plus efficaces. Pour plus d’informations, consultez Présentation d’Azure Lighthouse.
La gestion inter-locataires est particulièrement efficace dans les scénarios suivants :
- Gérer les ressources Microsoft Sentinel dans les locataires clients.
- Suivre les attaques et afficher les alertes de sécurité sur plusieurs locataires.
- Afficher les incidents dans plusieurs espaces de travail Microsoft Sentinel qui sont répartis entre les locataires.
Méthodes d’intégration des clients
Vous avez deux options pour intégrer des clients : une offre de service managé et un modèle ARM.
Intégration manuelle avec un modèle ARM
Si vous ne souhaitez pas publier d’offre sur la Place de marché Azure en tant que fournisseur de services, ou si vous ne répondez pas à toutes les exigences, vous pouvez intégrer des clients manuellement en utilisant des modèles ARM. Il s’agit de l’option la plus probable dans un scénario d’entreprise, où une même entreprise a plusieurs locataires.
Le tableau suivant compare les méthodes d’intégration.
| Considération | Offre de service managé | Modèles ARM |
|---|---|---|
| Nécessite un compte Espace partenaires | Oui | Non |
| Nécessite le niveau de compétence de plateforme cloud Silver ou Gold ou le statut Fournisseur de services managés Azure Expert | Oui | Non |
| Disponible pour les nouveaux clients via la Place de marché Azure | Oui | Non |
| Peut limiter l’offre à des clients spécifiques | Oui (uniquement avec des offres privées qui ne peuvent pas être utilisées avec des abonnements souscrits via un revendeur participant au programme CSP) | Oui |
| Nécessite l’acceptation du client dans le portail Azure | Oui | Non |
| Peut utiliser une automatisation pour intégrer plusieurs abonnements, groupes de ressources ou clients | Non | Oui |
| Fournit un accès immédiat aux nouveaux rôles intégrés et aux fonctionnalités d’Azure Lighthouse | Pas toujours (mis à la disposition générale après un certain délai) | Oui |
Pour plus d’informations sur la publication d’offres de services managés, consultez Publier une offre de services managés sur la Place de marché Azure.
Pour plus d’informations sur la création d’un modèle ARM, consultez Créer et déployer des modèles ARM.
Le diagramme suivant illustre l’intégration de l’architecture générale entre un locataire MSSP et les locataires du fournisseur de ressources d’un client avec Azure Lighthouse et Microsoft Sentinel.
Téléchargez un fichier Visio de cette architecture.
- Une offre MSP est intégrée via un modèle ARM ou une offre de service de la Place de marché Azure.
- La gestion des ressources déléguées Azure vérifie que la demande provient d’un locataire partenaire et appelle un fournisseur de ressources de service managé.
- Le fournisseur de ressources de service managé utilise le contrôle d’accès en fonction du rôle pour contrôler l’accès du fournisseur MSP.
- Le fournisseur MSP effectue des actions SecOps sur une ressource client.
- Le processus de facturation traite les dépenses comme des frais de client. La facturation fractionnée est possible si les entités clientes disposent d’espaces de travail distincts dans le même locataire Microsoft Entra.
- La sécurité et la souveraineté des données dépendent de la limite du locataire du client.
Identité entre plusieurs locataires
Pour gérer Microsoft Sentinel avec Azure DevOps, évaluez les décisions de conception suivantes pour les composants.
| Cas d’utilisation | Avantages |
|---|---|
| Identité globale pour la gestion des actions de DevOps, principal de service unique | Ce cas s’applique aux processus de déploiement globaux, qui impliquent tous les locataires. L’utilisation de l’identité unifiée facilite l’accès pour les différents locataires, mais elle peut rendre complexe le processus de gestion des actions d’approbation pour des locataires spécifiques. Le mécanisme de protection et le modèle d’autorisation pour ce type d’identité sont également très importants, afin d’éviter toute utilisation non autorisée qui est due à l’impact global associé. |
| Identité dédiée pour la gestion des actions de DevOps, plusieurs principaux de service | Ce cas s’applique quand les processus de déploiement sont dédiés pour chaque locataire ou que les actions de locataire nécessitent une approbation. Dans ce cas, la recommandation de protection et d’autorisation de cette utilisation d’identité est la même que dans le cas global, même quand l’impact est réduit. |
Organisation du dépôt de code
| Cas d’utilisation | Avantages |
|---|---|
| Dépôt unifié avec une seule version de code pour tous les locataires | Ce cas facilite la présence de versions unifiées pour le code dans le dépôt. Dans ce cas, une version unifiée du code gérant une version spécifique pour les locataires peut nécessiter une prise en charge sur les branches pour chaque cas. |
| Dépôt unifié avec des dossiers de code spécifiques par locataire | Ce cas complète le cas de dépôt unique. Ici, une structure de dossiers peut diviser les artefacts dédiés par locataire. |
| Dépôt dédié par locataire | Cette approche fournit une isolation lors de la gestion des artefacts de code. Elle facilite l’évolution entre les locataires avec différentes équipes ou exigences. Le regroupement des modifications nécessite l’établissement d’un processus entre les dépôts, ce qui peut nécessiter des efforts de maintenance. |
Processus de génération et de déploiement
| Cas d’utilisation | Avantages |
|---|---|
| Processus de génération unique pour tous les locataires | Quand tous les locataires utilisent la même version des artefacts, il s’agit de l’option la plus simple pour implémenter la génération et le package. |
| Processus de génération par locataire | Une version différente du code est déployée sur chaque locataire. |
| Processus de déploiement global pour tous les locataires | Les nouveaux déploiements et les mises à jour des déploiements s’appliquent à tous les locataires. Les étapes des processus de déploiement et de mise à jour sont utilisées pour tous les locataires. |
| Processus de déploiement global locataire par locataire | Les nouveaux déploiements et les mises à jour des déploiements s’appliquent à un ou plusieurs locataires. |
| Processus de déploiement dédié par locataire | Le processus de déploiement est adapté pour chaque locataire. |
Optimisation des coûts
L’optimisation des coûts consiste à réduire les dépenses inutiles et à améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.
Le coût de la solution dépend des facteurs suivants :
- Le volume de données que votre entreprise place dans l’espace de travail Microsoft Sentinel Log Analytics par mois
- Le niveau d’engagement ou la méthode de facturation que vous choisissez, comme le paiement à l’utilisation (PAYG)
- Le taux de conservation des stratégies de données au niveau de la table ou globalement
Pour plus d’informations, consultez Conservation par type de données Azure.
Pour calculer le prix, consultez la Calculatrice de prix Microsoft Sentinel. Pour plus d’informations sur les considérations relatives à la tarification avancée et des exemples, consultez Planifier les coûts pour Microsoft Sentinel.
Des frais supplémentaires peuvent s’appliquer si vous étendez votre solution avec les composants suivants :
- Playbooks : runtimes pour Azure Logic Apps et Azure Functions. Pour plus d’informations, consultez Détails tarifaires.
- Exportation vers un stockage externe comme Azure Data Explorer, Event Hubs ou un compte Stockage Azure.
- Un espace de travail Machine Learning et le calcul qu’un composant Jupyter Notebook utilise.
Déployer ce scénario
La section suivante décrit les étapes de déploiement de ce scénario sous la forme d’un exemple de cas d’usage couvrant les différents processus de DevOps.
Générer et publier le framework Microsoft Sentinel
Tout d’abord, configurez les composants NuGet nécessaires dans un dépôt dédié où les différents processus peuvent consommer les versions que vous générez.
Si vous utilisez Azure DevOps, vous pouvez créer un flux de composant pour héberger les différents packages NuGet à partir du framework Microsoft Sentinel pour PowerShell. Pour plus d’informations, consultez Bien démarrer avec les packages NuGet.
Si votre équipe choisit un registre GitHub, vous pouvez le connecter en tant que dépôt NuGet, car il est compatible avec le protocole de flux. Pour plus d’informations, consultez Présentation des packages GitHub.
Quand vous disposez d’un dépôt NuGet, le pipeline contient une connexion de service pour NuGet. Les captures d’écran ci-dessous montrent la configuration de la nouvelle connexion de service nommée Microsoft Sentinel NuGet Framework Connection.
Après avoir configuré le flux, vous pouvez importer le pipeline pour générer le framework PowerShell directement à partir de GitHub dans une fourche spécifique. Pour plus d’informations, consultez Générer des dépôts GitHub. Dans ce cas, vous créez un pipeline et choisissez GitHub comme source de code.
Une autre option consiste à importer le dépôt Git en tant que dépôt Azure DevOps basé sur Git. Dans les deux cas, pour importer le pipeline, spécifiez le chemin suivant :
src/Build/Framework/ADO/Microsoft.Sentinel.Framework.Build.yml
Vous pouvez maintenant exécuter le pipeline pour la première fois. Ensuite, le framework procède à la génération et à la publication sur le flux NuGet.
Définir votre environnement Microsoft Sentinel
Quand vous démarrez avec Microsoft Sentinel et que vous utilisez ces exemples, définissez l’environnement dans votre entreprise, par Environnement en tant que code ou EaC (Environment as Code). Vous spécifiez les différents éléments qui composent l’environnement dans chaque cas.
L’architecture Microsoft Sentinel comprend les éléments suivants sur Azure :
- Espace de travail Log Analytics : cet espace de travail constitue la base de la solution. Les informations relatives à la sécurité sont stockées dans cet espace de travail et celui-ci est le moteur du langage de requête Kusto (KQL).
- Solution Microsoft Sentinel sur l’espace de travail Log Analytics : cette solution étend les fonctionnalités de l’espace de travail Log Analytics pour inclure des fonctionnalités SIEM et SOAR.
- Key Vault : le coffre de clés conserve les secrets et les clés utilisés pendant les processus de correction.
- Compte Automation : ce compte est facultatif et est utilisé pour les processus de correction. Le processus de correction que vous utilisez est basé sur les runbooks PowerShell et Python. Le processus comprend une identité gérée par le système qui utilise différentes ressources selon les bonnes pratiques.
- Identité gérée par l’utilisateur : cette fonctionnalité fait office de couche d’identité unifiée Microsoft Sentinel qui gère les interactions entre les runbooks et les playbooks Microsoft Sentinel.
- Connexions d’application logique : connexions pour Microsoft Sentinel, le coffre de clés et l’automatisation qui utilisent l’identité gérée par l’utilisateur.
- Connexions à une application logique externe : connexions pour les ressources externes impliquées dans les processus de correction et qui sont basées sur les playbooks.
- Azure Event Hubs : cette fonctionnalité est facultative et gère l’intégration entre Microsoft Sentinel et d’autres solutions, telles que Splunk, Azure Databricks et Machine Learning et Resilient.
- Compte de stockage : cette fonctionnalité est facultative et gère l’intégration entre Microsoft Sentinel et d’autres solutions, telles que Splunk, Azure Databricks et Machine Learning et Resilient.
En utilisant des exemples du dépôt, vous pouvez définir l’environnement avec des fichiers JSON pour spécifier les différents concepts logiques. Les options disponibles pour définir l’environnement peuvent être littérales ou automatiques.
Dans une définition littérale, vous spécifiez le nom et les éléments de chaque ressource dans l’environnement, comme indiqué dans cet exemple.
{
{
"SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
"Name": "<environment-name>",
"NamingConvention": "<naming-convention-template-for-automatic-cases>",
"Location": "<environment-location>",
"ResourceGroup": {
"Type": "Literal",
"ResourceGroupName": "<resource-group-name>"
}
},
"Resources":
{
"Sentinel":
{
"Type": "Literal",
"LogAnalyticsWorkspaceName": "<Log-Analytics-workspace-name>",
"ManagedIdentityName": "<user-managed-identity-name>",
"SentinelConnectionName": "<Sentinel-API-connection-name>",
"KeyVaultName": "<Key-Vault-name>",
"KeyVaultConnectionName": "<Key-Vault-API-connection-name>"
},
"Automation":
{
"Type": "Literal",
"AutomationAccountName": "<automation-account-name>",
"AutomationAccountConnectionName": "<automation-account-API-connection-name>"
},
"Integration":
{
"Type": "Literal",
"EventHubNamespaces": [
"<Event-Hubs-namespace-1-name>",
"<Event-Hubs-namespace-2-name>",
"<Event-Hubs-namespace-3-name>",
"<Event-Hubs-namespace-4-name>",
"<Event-Hubs-namespace-5-name>",
"<Event-Hubs-namespace-6-name>",
"<Event-Hubs-namespace-7-name>",
"<Event-Hubs-namespace-8-name>",
"<Event-Hubs-namespace-9-name>",
"<Event-Hubs-namespace-10-name>",
],
"StorageAccountName": "<storage-account-name>"
}
}
}
Dans une définition automatique, les noms d’éléments sont générés automatiquement en fonction des conventions de nommage, comme illustré dans cet exemple.
{
{
"SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
"Name": "<environment-name>",
"NamingConvention": "<naming-convention-template-for-automatic-cases>",
"Location": "<environment-location>",
"ResourceGroup": {
"Type": "Automatic"
}
},
"Resources":
{
"Sentinel":
{
"Type": "Automatic"
},
"Automation":
{
"Type": "Automatic"
},
"Integration":
{
"Type": "Automatic",
"MaxEventHubNamespaces": 5
}
}
}
Vous trouverez des exemples dans le dépôt GitHub sous le chemin des environnements Microsoft Sentinel et pouvez utiliser les exemples comme référence lors de la préparation de vos cas d’usage.
Déployer votre environnement Microsoft Sentinel
Si vous avez défini au moins un environnement, vous pouvez créer la connexion de service Azure pour l’intégrer à Azure DevOps. Après avoir créé la connexion de service, définissez le principal de service lié sur le rôle propriétaire ou sur un niveau d’autorisations similaire sur l’abonnement cible.
Importez le pipeline pour créer l’environnement tel que défini dans ce fichier.
src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Deployment.ymlEnsuite, entrez le nom de la connexion de service qui représente l’environnement.
Choisissez la branche pour la définition de l’environnement dans le dépôt.
Entrez le nom de la connexion de service Azure DevOps pour votre abonnement dans la zone Connexion à l’environnement Azure.
Entrez le nom de l’environnement qu’une connexion de service peut utiliser pour résoudre plusieurs environnements dans le même abonnement.
Choisissez l’action à appliquer aux connecteurs.
Sélectionnez Utiliser la préversion des artefacts PowerShell si vous souhaitez utiliser les préversions des composants du framework PowerShell.
Le pipeline comprend les étapes suivantes dans le cadre du processus de déploiement :
- Déployer les composants NuGet.
- Connecter les outils NuGet au dépôt d’artefacts.
- Résoudre le flux.
- Installer les modules requis.
- Obtenir la définition de l’environnement.
- Valider les ressources qui existent dans la destination.
- Ajouter Log Analytics et Microsoft Sentinel s’ils ne se trouvent pas dans l’espace de travail.
- Si vous avez déjà Log Analytics, ajouter Microsoft Sentinel sur votre instance de Log Analytics.
- Créer une identité managée pour représenter l’interaction entre Microsoft Sentinel et Logic Apps.
- Créer le coffre Azure Key Vault et définir l’attribution de rôle pour gérer les secrets et les clés sur l’identité managée.
- Le cas échéant, créer un compte Azure Automation et activer l’identité managée affectée par le système.
- Définir l’attribution de rôle sur le coffre de clés pour l’identité managée affectée par le système.
- Créer les définitions Event Hubs si elles n’existent pas et définir si la définition comprend les éléments d’intégration.
- Définir l’attribution de rôle sur le coffre de clés pour l’identité managée affectée par le système.
- Créer les définitions du compte de stockage si elles n’existent pas et définir si la définition comprend les éléments d’intégration.
- Définir l’attribution de rôle sur le coffre de clés pour l’identité managée affectée par le système.
- Déployer les actions du connecteur.
- Déployer le runbook d’intégration sur le compte Automation.
- Déployer les connexions Logic Apps si elles sont définies dans le cadre de l’environnement.
Détruire un environnement Microsoft Sentinel
Quand l’environnement n’est plus nécessaire, comme dans le cas d’un environnement de développement ou de test, vous pouvez le détruire comme défini dans ce fichier.
src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Destroy.yml
Comme lors du déploiement du pipeline d’environnement, vous spécifiez le nom de la connexion de service qui représente l’environnement.
Utilisation de votre environnement Microsoft Sentinel
Une fois que votre environnement est prêt, vous pouvez commencer à créer les artefacts pour configurer les différents cas d’usage.
Exportez les artefacts à partir de l’environnement sur lequel vous travaillez comme défini dans ce fichier.
src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Export.ymlChoisissez la branche pour la définition de l’environnement dans le dépôt.
Entrez le nom de la connexion de service Azure DevOps pour l’environnement exporté dans la zone Connexion à l’environnement Azure.
Sélectionnez Utiliser la préversion des artefacts PowerShell si vous souhaitez utiliser les préversions des composants du framework PowerShell.
Choisissez le format des règles analytiques et de chasse.
Le fichier de sortie des artefacts est disponible dans les résultats. Une fois que vous avez les artefacts, vous pouvez inclure le fichier de sortie dans le dépôt Git.
Générer vos artefacts dans l’environnement Microsoft Sentinel
Placez vos artefacts sous le chemin des cas d’utilisation de Microsoft Sentinel MITRE. Configurez votre structure de dossiers en fonction des différents types d’artefacts.
Démarrez le processus de génération comme défini dans ce fichier.
src/Build/Artifacts/ADO/Microsoft.Sentinel.Artifacts.Build.yamlChoisissez la branche pour la définition de l’environnement dans le dépôt.
Diagramme illustrant comment choisir la branche pour générer les artefacts.](./media/build-artifacts-pipeline.png)
Sélectionnez Utiliser la préversion des artefacts PowerShell si vous souhaitez utiliser les préversions des composants du framework PowerShell.
Le pipeline est constitué des étapes suivantes :
- Déployer les composants NuGet.
- Connecter les outils NuGet au dépôt d’artefacts.
- Résoudre le flux.
- Installer les modules requis.
- Obtenir le framework du kit de ressources de test pour valider les modèles ARM.
- Valider les modèles ARM.
- Valider le code des runbooks PowerShell et valider la syntaxe.
- Exécuter les tests unitaires Pester, le cas échéant.
- Valider la syntaxe KQL dans les règles de chasse et analytiques.
Déployer vos artefacts sur l’environnement Microsoft Sentinel
Lors du déploiement de vos artefacts, vous pouvez utiliser les dépôts Microsoft Sentinel ou les exemples de pipeline de déploiement sur ce dépôt. Pour plus d’informations, consultez Déployer du contenu personnalisé à partir de votre référentiel.
Dépôts Microsoft Sentinel
Si vous utilisez des dépôts Microsoft Sentinel, vous pouvez configurer un processus de mise en production pour inclure les artefacts dans le dépôt qui est connecté à chaque instance de Microsoft Sentinel. Une fois les artefacts commités dans le dépôt, certaines étapes sont effectuées automatiquement dans le cadre de la création du pipeline et de l’activation des dépôts Microsoft Sentinel.
En outre, vous pouvez personnaliser les processus de déploiement que les dépôts Microsoft Sentinel effectuent en fonction des pratiques décrites dans ce document. Un aspect important à prendre en compte est l’approbation de la mise en production, que vous pouvez configurer en suivant ces approches :
- Approbation de la demande de tirage quand les artefacts sont commités. Pour plus d’informations, consultez Créer des demandes de tirage.
- Approbation du pipeline de mise en production lors de l’exécution du déploiement. Pour plus d’informations, consultez Définir des approbations et des vérifications.
Exemples de pipeline de déploiement Microsoft Sentinel
En utilisant les exemples de pipeline de déploiement Microsoft Sentinel, vous pouvez configurer un processus de mise en production.
Configurez votre processus de mise en production comme défini dans ce fichier.
src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Deployment.ymlChoisissez la branche pour la définition de l’environnement dans le dépôt.
Entrez le nom de la connexion de service Azure DevOps pour l’environnement exporté dans la zone Connexion à l’environnement Azure.
Sélectionnez Utiliser la préversion des artefacts PowerShell si vous souhaitez utiliser les préversions des composants du framework PowerShell.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Kevin Kisoka | Architecte associé
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Pour découvrir Microsoft Sentinel avec DevOps dans le cadre d’une architecture monolocataire, consultez Déploiement et gestion de Microsoft Sentinel en tant que code.
- Pour en savoir plus sur la conception d’une architecture MSSP qui fonctionne sur plusieurs répertoires Microsoft Entra, consultez Combinaison d’Azure Lighthouse avec les fonctionnalités DevOps de Microsoft Sentinel.
- Pour plus d’informations sur l’identité managée avec Microsoft Sentinel, consultez What's new: Managed identity for Microsoft Sentinel Logic Apps connector.
- Pour savoir comment déployer du contenu à partir d’un dépôt Microsoft Sentinel, consultez Déployer du contenu personnalisé à partir de votre dépôt.
- Pour en savoir plus sur les considérations de la sécurité Azure DevOps, consultez Aide-mémoire sur les autorisations par défaut.
- Pour savoir comment protéger un dépôt Azure DevOps, consultez Ajouter une protection à une ressource de dépôt.
- Pour plus d’informations sur la gestion de la sécurité des connexions de service Azure DevOps, consultez Connexions de service dans Azure Pipelines.