Fiabilité dans Microsoft Defender pour le cloud sécurité DevOps

Article
02/23/2024

Cet article décrit la prise en charge de la fiabilité dans fonctionnalités de sécurité Microsoft Defender pour Cloud DevOps, qui inclut récupération inter-régions et la continuité d’activité. Pour obtenir une vue d’ensemble plus détaillée de la fiabilité dans Azure, consultez Fiabilité Azure.

Cet article est spécifique à la récupération en cas de panne de région. Si vous souhaitez déplacer votre connecteur DevOps existant vers une nouvelle région, consultez Questions courantes sur Defender pour DevOps

Récupération d’urgence et continuité d’activité inter-région

La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, qui entraînent un temps d’arrêt et une perte de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.

En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes responsable de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.

Microsoft Defender pour Cloud DevOps security prend en charge la récupération d’urgence à région unique. Par conséquent, un processus de récupération d’urgence multirégion implémente simplement le processus de récupération d’urgence à région unique décrit dans ce document.

Régions prises en charge

Pour connaître les régions qui prennent en charge la sécurité DevOps dans Defender pour cloud, consultez la prise en charge de la région de sécurité DevOps.

Processus de récupération d’urgence à région unique

Le processus de récupération d’urgence de région unique pour les fonctionnalités de sécurité DevOps est basé sur le modèle de responsabilité partagée , et inclut ainsi les procédures client et Microsoft.

Responsabilité du client

Lorsqu’une région tombe en panne, vos configurations pour le connecteur de cette région sont perdues. Les configurations perdues incluent les jetons client, les configurations de découverte automatique et les configurations d’annotations ADO.

Pour demander la récupération d’un connecteur créé dans une région downed :

Créez un connecteur dans une nouvelle région. Consultez la documentation d’intégration pour Azure DevOps, GitHub et/ou GitLab.

Remarque

Vous pouvez utiliser un connecteur existant dans la nouvelle région, tant qu’il est authentifié pour avoir accès à l’étendue des ressources DevOps dans l’ancien connecteur.
Ouvrez une nouvelle demande de support pour libérer la propriété des ressources DevOps à partir de l’ancien connecteur.
1. Dans le portail Azure, accédez à Aide + Support
2. Remplissez le formulaire :
  1. Type de problème : Technical
  2. Type de service : Microsoft Defender for Cloud
  3. Résumé : « Panne de région - Récupération du connecteur DevOps »
  4. Type de problème : Defender CSPM plan
  5. Sous-type de problème : DevOps security
Copiez l’ID de ressource des nouveaux connecteurs DevOps et anciens. Ces informations sont disponibles dans Azure Resource Graph. Format d’ID de ressource : /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Security/securityConnectors/{connectorName}

Vous pouvez exécuter la requête ci-dessous à l’aide de 'Explorateur Azure Resource Graph pour trouver l’ID de ressource :
```
resources
 | extend connectorType = tostring(parse_json(properties["environmentName"]))
 | where type == "microsoft.security/securityconnectors"
 | where connectorType in ("AzureDevOps", "Github", "GitLab")
 | project connectorResourceId = id, region = location
```
Une fois que les ressources DevOps ont été libérées de l’ancien connecteur et apparaissent pour le nouveau connecteur, reconfigurer les annotations de demande de tirage si nécessaire.
Le nouveau connecteur sera rendu principal. Lorsque la région récupère de la panne, vous pouvez supprimer en toute sécurité l’ancien connecteur.

Responsabilité de Microsoft

Lorsqu’une région tombe en panne et que vous avez établi le nouveau connecteur, Microsoft recrée toutes les alertes, recommandations et entités Cloud Security Graph de l’ancien connecteur dans le nouveau connecteur.

Important

Microsoft ne recrée pas l’historique pour certaines fonctionnalités, telles que les données de mappage de conteneurs provenant des exécutions précédentes, les données d’alerte plus d’une semaine et les données d’historique de mappage IaC (Code as Code).

Tester votre processus de récupération d’urgence

Pour tester votre processus de récupération d’urgence, vous pouvez simuler un connecteur perdu en créant un deuxième connecteur et en suivant les étapes de support ci-dessus.

Étapes suivantes

Pour en savoir plus sur les fonctionnalités présentées dans cet article, voir :

Fiabilité dans Azure

Partage via