Adopter des garde-fous pilotés par les stratégies

  • Article

Avant d’utiliser des stratégies, vous devez comprendre où elles sont utilisées dans les implémentations de référence des zones d’atterrissage Azure et pourquoi. Cet article vous aidera à comprendre ce qu’il en est si vous voulez empêcher les stratégies DeployIfNotExists (DINE) ou Modify d’apporter des modifications dans votre environnement Azure.

Pourquoi utiliser les stratégies DINE et Modify ?

Les stratégies DINE et Modify font partie des implémentations de référence des zones d’atterrissage Azure. Elles vous aident, ainsi que votre organisation, à vérifier la conformité de vos zones d’atterrissage (ou abonnements) et des ressources qu’elles contiennent. Ces stratégies suppriment également la charge opérationnelle pour les équipes responsables de la plateforme et des zones d’atterrissage à mesure que votre environnement Azure évolue.

Par exemple, envisagez un scénario dans lequel un nouvel abonnement de zone d’atterrissage est provisionné et placé dans le groupe d’administration « corp ». Les stratégies DINE et Modify effectuent ensuite les actions suivantes pour l’abonnement de la zone d’atterrissage :

  • Activez Microsoft Defender pour le cloud. Configurer des exportations de Microsoft Defender pour le cloud vers l’espace de travail central Log Analytics dans l’abonnement de gestion.
  • Activer Defender pour le cloud pour les différentes offres prises en charge en fonction des paramètres de stratégie configurés sur l’affection de stratégie.
  • Configurer l’envoi des journaux d’activité Azure à l’espace de travail central Log Analytics dans l’abonnement de gestion.
  • Configurer l’envoi des paramètres de diagnostic pour toutes les ressources à l’espace de travail central Log Analytics dans l’abonnement de gestion.
  • Déployer les agents Azure Monitor requis pour les machines virtuelles et Azure Virtual Machine Scale Sets, y compris les serveurs connectés à Azure Arc. Les connecter à l’espace de travail central Log Analytics dans l’abonnement de gestion.

Notes

Vous pouvez désactiver les options précédentes à tout moment ou lors du déploiement des implémentations de référence des zones d’atterrissage Azure.

La liste précédente montre seulement un sous-ensemble de toutes les stratégies qui sont affectées dans le cadre de l’accélérateur de zone d’atterrissage Azure. Pour obtenir la liste complète des stratégies qui peuvent être affectées par l’implémentation de référence des zones d’atterrissage Azure, consultez Stratégies incluses dans les implémentations de référence des zones d’atterrissage Azure.

Le référentiel Bicep des zones d’atterrissage Azure est modulaire. Les stratégies par défaut ci-dessus peuvent être déployées avec le module AlZ Default Policy Assignments.

Toutes les stratégies affectées vous aident, ainsi que les propriétaires de la zone d’atterrissage, à maintenir la conformité. Aucune ressource de charge de travail réelle n’est déployée via les stratégies DINE ou Modify. Nous ne recommandons pas cette méthode non plus. Pour plus d’informations, consultez Devons-nous utiliser Azure Policy pour déployer des charges de travail ?. Seuls les ressources ou paramètres auxiliaires ou de prise en charge sont déployés ou configurés par ces stratégies DINE.

Les implémentations de référence des zones d’atterrissage Azure utilisent les stratégies Azure DINE pour vous aider à atteindre la gouvernance pilotée par les stratégies dans votre environnement Azure. Toutefois, vous ne pouvez peut-être pas utiliser les stratégies DINE ou Modifiy, ou vous n’êtes pas prêt à activer ce type d’effet de stratégie Azure pour les raisons suivantes :

  • stratégies de conformité réglementaire, normes ou restrictions légales ;
  • processus stricts de contrôle des modifications qui nécessitent une approbation humaine pour chaque action effectuée dans votre environnement Azure ;
  • manque d’expertise, d’expérience et de compréhension de la gestion et de l’utilisation des stratégies DINE.
  • Les exigences organisationnelles que toutes les configurations des ressources de charge de travail, y compris les ressources auxiliaires, les ressources de soutien et les paramètres, sont définies dans l’infrastructure en tant que code (IaC) par les équipes d’application de charge de travail.

Si votre situation correspond aux exemples précédents ou à des scénarios similaires, cet article vous aidera à comprendre comment adopter l’Architecture conceptuelle de la zone d’atterrissage Azure et adhérer à ses principes de conception. Bien que vous n’utiliserez pas certaines stratégies au départ, vous pouvez choisir de les activer progressivement à l’avenir. L’objectif est de vous aider à atteindre la gouvernance pilotée par les stratégies.

Important

Deux valeurs possibles sont utilisées tout au long de cet article pour les termes du mode d’application :

  • Disabled ou DoNotEnforce
  • Enabled ou Default

Le Portail Azure utilise Disabled et Enabled pour le mode d’application. Les modèles ARM (Azure Resource Manager) et les interfaces des autres API utilisent DoNotEnforce et Default pour les mêmes options.

Pour plus d’informations, consultez Mode d’application.

Si vous êtes toujours certain que votre organisation ne peut pas utiliser les stratégies DINE ou Modify, cet article explique comment empêcher celles-ci d’apporter des modifications automatiques à votre environnement Azure (ou désactiver celles-ci).

Notes

Cette opération n’est pas définitive. Les stratégies peuvent être réactivées à tout moment par un membre de votre équipe de plateforme si vous décidez ultérieurement d’utiliser les stratégies DINE ou Modify.

Pour plus d’informations, consultez les phases 2 et 3.

La prise en charge des sélecteurs de ressources s’applique également à la gouvernance axée sur les politiques, afin de garantir le respect des pratiques de déploiement sécurisé (SDP). Les sélecteurs de ressources apportent la fonctionnalité de déploiement progressif des affectations de politiques en fonction de facteurs tels que l’emplacement de la ressource, le type de ressource ou le fait que la ressource ait un emplacement. Pour en savoir plus, consultez le document suivant.

Vue d’ensemble de l’approche

Le diagramme suivant résume l’approche par phases suggérée :

Graphic that shows a DINE phases overview.

  1. Définissez le mode d’application sur DoNotEnforce dans les affectations de stratégie :
    • En utilisant cette fonctionnalité, vous pouvez modifier le comportement de l’affectation pour qu’elles devienne une stratégie d’audit uniquement, sans modifier la définition de stratégie sous-jacente.
    • Cette approche vous permet également d’effectuer si vous le souhaitez des tâches de correction manuelles sur des ressources non conformes en utilisant des tâches de correction.
  2. Définissez le mode d’application sur Default dans les affectations de stratégie pour réactiver la correction automatique des affectations de stratégie DINE sur une étendue réduite :
    • Vous pouvez choisir d’utiliser un environnement entier (par exemple, le groupe d’administration de bac à sable).
    • Vous pouvez aussi utiliser un abonnement de charge de travail non critique.
  3. Définissez le Mode d’application sur Default dans les affectations de stratégie pour les stratégies DINE restantes sur la totalité de l’environnement Azure.

En raison des restrictions liées à la conformité réglementaire, certains clients ne peuvent jamais dépasser la phase 1. Ce n’est pas un problème : il est possible de conserver cet état si c’est nécessaire. D’autres clients peuvent progresser au fil du temps jusqu’aux phases 2 et 3 pour adopter pleinement les stratégies DINE et Modify et faciliter la mise en place de la gouvernance pilotée par les stratégies pour leur environnement Azure.

Notes

Le scénario et l’approche décrits dans cet article ne sont pas destinés ni recommandés pour la majorité des clients. Consultez la section Pourquoi utiliser les stratégies DINE et Modify ? avant de décider si ces stratégies sont adaptées et nécessaires à votre environnement.

Phase 1 : désactiver les actions automatisées des stratégies DINE et Modify

Lorsque vous affectez une stratégie, l’effet défini dans la définition de stratégie est appliqué par défaut. Nous vous recommandons de conserver la définition de stratégie telle quelle. Par exemple, laissez l’effet d’affectation de stratégie défini sur DeployIfNotExists.

Au lieu de modifier la définition de stratégie ou son effet, vous pouvez au lieu de cela influencer ce comportement très facilement en utilisant la fonctionnalité sur les affectations de stratégie.

Utiliser le Portail Azure pour définir le mode d’application sur Disabled

Cette capture d’écran montre comment utiliser le Portail Azure pour définir le mode d’application sur Disabled dans une affectation de stratégie. Disabled est également appelé DoNotEnforce.

Set the enforcement mode to Disabled in the Azure portal.

Utiliser le modèle ARM pour définir le mode d’application sur DoNotEnforce

Cet exemple de code montre comment utiliser un modèle ARM pour définir enforcementMode sur DoNotEnforce dans une affectation de stratégie. DoNotEnforce est également appelé Disabled.

{
  "type": "Microsoft.Authorization/policyAssignments",
  "apiVersion": "2019-09-01",
  "name": "PolicyAssignmentName",
  "location": "[deployment().location]",
  "properties": {
    "description": "PolicyAssignmentDescription",
    "policyDefinitionId": "[parameters('policyDefinitionId')]",
    "enforcementMode": "DoNotEnforce"
    … // other properties removed for display purposes
  }
}

Le mode d’application vous permet de voir l’effet d’une stratégie sur des ressources existantes sans la lancer et sans déclencher des entrées dans le journal d’activité Azure. Ce scénario est de type « What If » et suit des pratiques de déploiement sécurisées.

Même lorsque le mode d’application est défini sur DoNotEnforce, les tâches de correction peuvent être déclenchées manuellement. Vous pouvez corriger des ressources non conformes spécifiques. Vous pouvez également observer l’effet de la stratégie DINE ou Modify si le mode d’application avait été défini sur Default.

Important

Quand le mode d’application est défini sur DoNotEnforce, aucune entrée n’est générée dans le journal d’activité Azure. Vous devez tenir compte de ce facteur si vous souhaitez être averti lorsqu’une ressource non conforme est créée.

Rester à l’état de la phase 1 de façon définitive

Comme mentionné dans la section Vue d’ensemble de l’approche, certains clients peuvent être amenés à rester en phase 1 pendant une longue période, voire de façon permanente, en raison de leurs exigences. Cet état est valide et les clients peuvent le conserver durablement.

Vous devrez peut-être rester dans cet état de façon permanente ou durable (par exemple, plusieurs années). Si c’est le cas, il peut être préférable d’adopter l’effet de stratégie AuditIfNotExists (AINE) et ses définitions associées, et de rétablir le mode d’application sur Default.

Notes

En passant à l’utilisation d’une stratégie AINE et en définissant le mode d’application sur Default, vous atteignez néanmoins le même objectif de désactivation de DINE.

Lorsque vous passez de DINE à AINE et que vous rétablissez le mode d’application sur Default dans le cadre d’une approche durable ou permanente pour la phase 1, vous récupérez les entrées du journal d’activité Azure pour les états de conformité aux stratégies. Vous pouvez créer des flux de travail d’automation à partir de ces entrées de journal dans vos opérations globales de gestion de plateforme.

Vous perdez la possibilité d’effectuer des tâches de correction manuelles. Contrairement aux stratégies DINE, les stratégies AINE n’effectuent aucun déploiement, qu’il soit automatisé ou manuel.

Veillez à mettre à jour la définition de stratégie pour accepter et autoriser l’effet d’affectation de stratégie AuditIfNotExists.

Le tableau suivant résume les options et implications pour les combinaisons des différents types d’effets de stratégie et du mode d’application :

Effet de la stratégie Mode d’application Entrée du journal d’activité Action corrective
DINE Enabled ou Default Oui Correction déclenchée par la plateforme à grande échelle après la création ou mise à jour des ressources. Création manuelle d’une tâche de correction nécessaire si la ressource dépendante est modifiée ou existait avant l’affectation de stratégie.
DINE Disabled ou DoNotEnforce Non Création manuelle d’une tâche de correction nécessaire.
Modifier Enabled ou Default Oui Correction automatique lors de la création ou mise à jour.
Modifier Disabled ou DoNotEnforce Non Création manuelle d’une tâche de correction nécessaire.
Deny Enabled ou Default Oui Création ou mise à jour refusée.
Deny Disabled ou DoNotEnforce Non Création ou mise à jour autorisée. Correction manuelle nécessaire.
Audit/AINE Enabled ou Default Oui Correction manuelle nécessaire.
Audit/AINE Disabled ou DoNotEnforce Non Correction manuelle nécessaire.

Notes

Consultez les instructions de Réaction aux événements de changement d’état d’Azure Policy pour comprendre si l’utilisation de l’intégration d’Azure Event Grid à Azure Policy offre une approche appropriée si vous envisagez de créer votre propre automatisation en fonction des événements d’état de la stratégie.

Phase 2 : activer les stratégies DINE et Modify sur une stratégie spécifique ou une étendue réduite

Au cours de cette phase, vous allez découvrir comment définir le mode d’application sur Default dans les affectations de stratégie.

Une fois que vous avez terminé la phase 1, vous décidez que vous souhaitez tester et essayer les fonctionnalités d’automation complètes des stratégies DINE et Modify sur une stratégie spécifique ou une étendue réduite. Vous souhaitez utiliser le groupe d’administration de bac à sable ou un abonnement à une charge de travail hors production.

Pour effectuer cette procédure, vous devez d’abord identifier la stratégie ou l’étendue réduite qui sera utilisée pour tester et essayer les fonctionnalités d’automation complètes des stratégies DINE et Modify.

Notes

Vous souhaiterez peut-être examiner et implémenter une approche de test pour une plateforme à l’échelle de l’entreprise. De cette façon, vous pouvez tester des stratégies et d’autres modifications de plateforme dans une hiérarchie de groupes d’administration distincte au sein du même locataire.

Cette approche est également appelée déploiement de « contrôle de validité ».

Voici quelques exemples d’étendues et de stratégies suggérées dans le tableau suivant :

Si vous souhaitez... ...choisissez parmi ces étendues Exemples de stratégies à utiliser
- Tester les fonctionnalités de correction automatisée de DINE/Modify.
- Vérifier comment vos processus de déploiement complets et vos pipelines CI/CD (y compris les tests) peuvent être affectés.
- Vérifier comment votre charge de travail peut être affectée.		 - Abonnement de bac à sable
- Groupe d’administration de bac à sable
- Abonnement de zone d’atterrissage des charges de travail hors production
- Environnement de « contrôle de validité » à l’échelle de l’entreprise		 - Configurer les journaux d’activité Azure de sorte qu’ils soient transmis en continu à un espace de travail Log Analytics spécifié.
- Déployer la configuration de Defender pour le cloud.
- Activer Azure Monitor pour machines virtuelles ou Virtual Machine Scale Sets.
- Déployer les paramètres de diagnostic sur les services Azure.
- Potentiellement activer seulement pour des services spécifiques au sein de l’initiative.

Vous pouvez aussi décider d’utiliser une tâche de correction manuelle sur une étendue limitée ou un ensemble de ressources limité pour tester l’impact de ces stratégies sur votre environnement. Pour plus d’informations sur la création d’une tâche de correction, consultez la rubrique Créer une tâche de correction de la documentation Azure Policy.

Une fois que vous avez identifié une ou plusieurs stratégies et l’étendue réduite à laquelle les affecter, l’étape suivante consiste à affecter la stratégie et à définir le mode d’application sur Default. Laissez l’effet de stratégie (par exemple, DeployIfNotExists ou Modify) tel quel sur l’étendue réduite que vous avez sélectionnée.

Utiliser le Portail Azure pour définir le mode d’application sur Enabled

Cette capture d’écran montre comment utiliser le Portail Azure pour définir le mode d’application sur Enabled dans une affectation de stratégie. Enabled est également appelé Default.

Screenshot that shows setting the enforcement mode to Enabled in the Azure portal.

Utiliser un modèle ARM pour définir le mode d’application sur Default

Cet exemple de code montre comment utiliser un modèle ARM pour définir enforcementMode sur Default dans une affectation de stratégie. Default est également appelé Enabled.

{
  "type": "Microsoft.Authorization/policyAssignments",
  "apiVersion": "2019-09-01",
  "name": "PolicyAssignmentName",
  "location": "[deployment().location]",
  "properties": {
    "description": "PolicyAssignmentDescription",
    "policyDefinitionId": "[parameters('policyDefinitionId')]",
    "enforcementMode": "Default"
    … // other properties removed for display purposes
  }
}

Test

La dernière étape de cette phase consiste à effectuer les tests requis. Vous souhaitez vérifier si et comment les stratégies DINE ou Modify ont affecté et modifié vos charges de travail, votre code, vos outils et vos processus.

Effectuez plusieurs tests pour capturer la totalité du cycle de vie de votre charge de travail. Vous souhaitez vous assurer que vous comprenez parfaitement si et comment les stratégies DINE ou Modify ont apporté des modifications.

Voici quelques exemples de test :

  • Déploiement initial de la charge de travail.
  • Déploiement de code/d’application sur la charge de travail.
  • Opérations et gestion de la charge de travail - Jour 2.
  • Désactivation de la charge de travail.

Phase 3 : activer les stratégies DINE et Modify partout

Au cours de cette phase, vous allez découvrir comment définir le mode d’application sur Default dans les affectations de stratégie.

Nous partons du principe que les tests effectués à la fin de la phase 2 ont aboutis. Ou peut-être êtes-vous satisfait de comprendre à présent comment les stratégies DINE ou Modify interagissent avec votre charge de travail. Vous pouvez désormais étendre l’utilisation des stratégies DINE et Modify au reste de votre environnement Azure.

Pour continuer, vous devez suivre des étapes semblables à celles de la phase 2. Cette fois, vous définissez le mode d’application sur Default dans toutes les affectations de stratégie DINE et Modify dans l’ensemble de votre environnement Azure.

Voici une vue d’ensemble globale des étapes effectuées dans cette phase :

  • Supprimer les affectations utilisées spécifiquement pour les tests effectués pendant la phase 2.
  • Accédez à chaque affectation de stratégie DINE et Modify dans votre environnement Azure et définissez le mode d’application sur Default. Ce processus est illustré dans les exemples de la phase 2.
  • Créez des tâches de correction pour les ressources existantes qui ne sont pas conformes en suivant les instructions dans Créer une tâche de correction. Les nouvelles ressources seront automatiquement corrigées si elles correspondent aux règles de stratégie et aux conditions d’existence.

Bien que nous vous recommandons de définir le mode d’application sur Default pour toutes les stratégies DINE et Modify dans votre environnement Azure lors de la phase 3, ce choix reste facultatif. Vous pouvez l’effectuer sur la base des stratégies individuelles, conformément à vos besoins et exigences.

Gestion avancée des stratégies

Pour une gestion avancée d’Azure Policy à grande échelle, envisagez de mettre en œuvre la Stratégie d’entreprise en tant que code (EPAC) pour gérer la stratégie. EPAC fournit une expérience de gestion avec état qui utilise IaC. Il convient généralement à de grands scénarios de gestion des stratégies avec des exigences complexes.