Partager via


Tutoriel : Créer une définition de stratégie personnalisée

Une définition de stratégie personnalisée permet aux clients de définir leurs propres règles d’utilisation d’Azure. Ces règles appliquent souvent :

  • Pratiques de sécurité.
  • Gestion des coûts.
  • Des règles propres à l’organisation (par exemple, de nommage ou d’emplacements).

Quel que soit l’objectif de la création d’une stratégie personnalisée, les étapes de définition de la nouvelle stratégie personnalisée sont les mêmes.

Avant de créer une stratégie personnalisée, consultez les exemples de stratégie pour voir si une stratégie correspond déjà à vos besoins.

Voici les étapes de création d’une stratégie personnalisée :

  • Identifier vos exigences métier
  • Associer chaque exigence à une propriété de ressource Azure
  • Associer la propriété à un alias
  • Déterminer l’effet à utiliser
  • Composer la définition de stratégie

Prérequis

Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.

Identifier les exigences

Avant de créer la définition de stratégie, vous devez bien définir l’intention de la stratégie. Dans ce tutoriel, utilisez une exigence de sécurité d’entreprise courante pour illustrer les étapes impliquées :

  • Chaque compte de stockage doit être activé pour HTTPS.
  • Chaque compte de stockage doit être désactivé pour HTTP.

Vos exigences doivent identifier clairement les deux états de ressource « être » et « ne pas être ».

Nous avons défini l’état attendu de la ressource, mais nous n’avons pas défini ce que nous voulons faire avec les ressources non conformes. Azure Policy prend en charge de nombreux effets. Dans ce tutoriel, nous définissons l’exigence métier de manière à empêcher la création de ressources si celles-ci ne sont pas conformes aux règles métier. Pour atteindre cet objectif, nous utilisons l’effet deny. Nous voulons aussi pouvoir suspendre la stratégie pour des attributions spécifiques. Utilisez l’effet disabled et définissez-le en tant que paramètre dans la définition de stratégie.

Déterminer les propriétés de ressource

D’après les besoins métier, la ressource Azure à auditer avec Azure Policy est un compte de stockage. Toutefois, nous ne savons pas quelles sont les propriétés à utiliser dans la définition de stratégie. Azure Policy effectuant l’évaluation par rapport à la représentation JSON de la ressource, nous devons comprendre les propriétés disponibles sur cette ressource.

Il existe de nombreuses façons de déterminer les propriétés d’une ressource Azure. Dans ce tutoriel, nous examinons chacune d’elles :

  • Extension Azure Policy pour VS Code.
  • Modèles Azure Resource Manager (modèles ARM).
    • Exporter une ressource existante.
    • Expérience de création.
    • Modèles de démarrage rapide (GitHub).
    • Documentation de référence sur les modèles.
  • Azure Resource Explorer.

Afficher des ressources dans l’extension VS Code

L’extension VS Code peut être utilisée pour parcourir des ressources dans votre environnement et voir les propriétés Resource Manager sur chaque ressource.

Modèles ARM

Il existe plusieurs façons d’examiner un modèle ARM qui inclut la propriété à gérer.

Ressource existante dans le portail

Pour rechercher des propriétés, le plus simple est d’examiner une ressource existante du même type. Vous pouvez aussi comparer les ressources déjà configurées avec le paramètre que vous voulez appliquer. Consultez la page Exporter le modèle, dans Paramètres, dans le Portail Azure pour cette ressource spécifique.

Avertissement

Le modèle ARM exporté par le portail Azure ne peut pas être directement relié à la propriété deployment pour un modèle ARM dans une définition de stratégie deployIfNotExists.

Capture d’écran de la page Exporter le modèle sur une ressource existante dans le portail Azure.

Si la ressource est un compte de stockage, vous voyez un modèle semblable à cet exemple :

"resources": [
  {
    "comments": "Generalized from resource: '/subscriptions/{subscriptionId}/resourceGroups/myResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount'.",
    "type": "Microsoft.Storage/storageAccounts",
    "sku": {
      "name": "Standard_LRS",
      "tier": "Standard"
    },
    "kind": "Storage",
    "name": "[parameters('storageAccounts_mystorageaccount_name')]",
    "apiVersion": "2018-07-01",
    "location": "westus",
    "tags": {
      "ms-resource-usage": "azure-cloud-shell"
    },
    "scale": null,
    "properties": {
      "networkAcls": {
        "bypass": "AzureServices",
        "virtualNetworkRules": [],
        "ipRules": [],
        "defaultAction": "Allow"
      },
      "supportsHttpsTrafficOnly": false,
      "encryption": {
        "services": {
          "file": {
            "enabled": true
          },
          "blob": {
            "enabled": true
          }
        },
        "keySource": "Microsoft.Storage"
      }
    },
    "dependsOn": []
  }
]

Sous properties, une valeur nommée supportsHttpsTrafficOnly est définie sur false. Cette propriété semble être celle que nous recherchons. De plus, le type de la ressource est Microsoft.Storage/storageAccounts. Le type nous permet de limiter la stratégie aux ressources de ce type uniquement.

Créer une ressource dans le portail

Dans le portail, vous pouvez aussi utiliser l’expérience de création de ressource. Quand vous créez un compte de stockage dans le portail, sous l’onglet Avancé, l’option Transfert de sécurité obligatoire est disponible. Cette propriété a des options Désactivé et Activé. L’icône d’informations contient plus de texte qui confirme que cette option est probablement la propriété qui nous intéresse. Toutefois, le portail n’indique pas le nom de la propriété dans cet écran.

Sous l’onglet Examiner + créer, un lien en bas de la page vous permet de Télécharger un modèle pour l’automatisation. Sélectionnez le lien pour ouvrir le modèle qui crée la ressource que nous avons configurée. Dans notre exemple, nous voyons deux informations essentielles :

...
"supportsHttpsTrafficOnly": {
  "type": "bool"
}
...
"properties": {
  "accessTier": "[parameters('accessTier')]",
  "supportsHttpsTrafficOnly": "[parameters('supportsHttpsTrafficOnly')]"
}
...

Ces informations nous indiquent le type de propriété et confirment que supportsHttpsTrafficOnly est la propriété que nous recherchons.

Modèles de démarrage rapide sur GitHub

La page des modèles de démarrage rapide Azure sur GitHub comprend des centaines de modèles ARM destinés à différentes ressources. Ces modèles peuvent être un excellent moyen de trouver la propriété de ressource que vous recherchez. Certaines propriétés peuvent sembler correspondre à ce que vous recherchez, mais contrôler autre chose.

Documentation de référence de la ressource

Pour vérifier que supportsHttpsTrafficOnly est la bonne propriété, consultez la référence du modèle ARM pour la ressource de compte de stockage sur le fournisseur de stockage. L’objet de propriétés a une liste des paramètres valides. La sélection du lien d’objet StorageAccountPropertiesCreateParameters affiche une table des propriétés acceptables. La propriété supportsHttpsTrafficOnly est présente et la description correspond à ce que nous recherchons en ce qui concerne les exigences métier.

Azure Resource Explorer

Un autre moyen d’explorer vos ressources Azure est d’utiliser Azure Resource Explorer (préversion). Comme cet outil utilise le contexte de votre abonnement, vous devez vous authentifier sur le site web avec vos informations d’identification Azure. Une fois authentifié, vous pouvez parcourir les fournisseurs, les abonnements, les groupes de ressources et les ressources.

Recherchez une ressource de compte de stockage et examinez ses propriétés. La propriété supportsHttpsTrafficOnly est également présente ici. Sous l’onglet Documentation, nous voyons que la description de la propriété correspond à ce que nous avons trouvé précédemment dans la documentation de référence.

Rechercher l’alias de propriété

Nous avons identifié la propriété de la ressource, mais nous devons mapper cette propriété à un alias.

Il existe de nombreuses façons de déterminer les alias d’une ressource Azure. Dans ce tutoriel, nous examinons chacune d’elles :

  • Extension Azure Policy pour VS Code.
  • Azure CLI.
  • Azure PowerShell.

Obtenir des alias dans l’extension VS Code

L’extension Azure Policy pour l’extension VS Code facilite la navigation dans vos ressources et la découverte d’alias.

Notes

L’extension VS Code expose uniquement les propriétés du mode Resource Manager, et n’affiche pas les propriétés du mode Fournisseur de ressources.

Azure CLI

Dans Azure CLI, le groupe de commandes az provider est utilisé pour rechercher des alias de ressource. Nous filtrons sur l’espace de noms Microsoft.Storage en fonction des détails obtenus précédemment sur la ressource Azure.

# Login first with az login if not using Cloud Shell

# Get Azure Policy aliases for type Microsoft.Storage
az provider show --namespace Microsoft.Storage --expand "resourceTypes/aliases" --query "resourceTypes[].aliases[].name"

Dans les résultats, nous voyons un alias nommé supportsHttpsTrafficOnly pris en charge par les comptes de stockage. L’existence de cet alias signifie que nous pouvons écrire la stratégie pour appliquer nos exigences métier !

Azure PowerShell

Dans Azure PowerShell, l’applet de commande Get-AzPolicyAlias est utilisé pour rechercher des alias de ressource. Filtrez sur l’espace de noms Microsoft.Storage en fonction des détails obtenus précédemment sur la ressource Azure.

# Login first with Connect-AzAccount if not using Cloud Shell

# Use Get-AzPolicyAlias to list aliases for Microsoft.Storage
(Get-AzPolicyAlias -NamespaceMatch 'Microsoft.Storage').Aliases

Comme avec Azure CLI, les résultats montrent un alias nommé supportsHttpsTrafficOnly pris en charge par les comptes de stockage.

Déterminer l’effet à utiliser

Choisir ce que vous allez faire de vos ressources non conformes est presque aussi important que choisir ce que vous devez évaluer en premier lieu. Chaque réponse possible à une ressource non conforme est appelée un effet. L’effet contrôle si la ressource non conforme est enregistrée, bloquée, a des données ajoutées ou est associée à un déploiement pour la remettre dans un état conforme.

Dans notre exemple, nous voulons l’effet deny pour que les ressources non conformes ne soient pas créées dans notre environnement Azure. Avant de définir l’effet deny, commencez par l’auditer pour déterminer l’effet de la stratégie. Pour simplifier le changement d’effet par attribution, vous pouvez paramétrer l’effet. Pour plus d’informations, consultez Paramètres.

Composer la définition

Nous avons maintenant les détails et l’alias de la propriété correspondant à ce que nous voulons gérer. Ensuite, nous composons la règle de stratégie proprement dite. Si vous ne connaissez pas le langage de stratégie, consultez la structure de définition de stratégie pour savoir comment structurer la définition de stratégie. Voici un modèle vide de ce à quoi ressemble une définition de stratégie :

{
  "properties": {
    "displayName": "<displayName>",
    "description": "<description>",
    "mode": "<mode>",
    "parameters": {
              <parameters>
    },
    "policyRule": {
      "if": {
              <rule>
      },
      "then": {
        "effect": "<effect>"
      }
    }
  }
}

Métadonnées

Les trois premiers composants sont des métadonnées de stratégie. Ces composants sont faciles à définir puisque nous connaissons l’objectif de la règle. Le mode concerne essentiellement les étiquettes et l’emplacement de la ressource. Comme nous n’avons pas besoin de limiter l’évaluation aux ressources qui prennent en charge les étiquettes, utilisez la valeur all pour mode.

"displayName": "Deny storage accounts not using only HTTPS",
"description": "Deny storage accounts not using only HTTPS. Checks the supportsHttpsTrafficOnly property on StorageAccounts.",
"mode": "all",

Paramètres

Nous n’avons pas utilisé de paramètre pour changer l’évaluation, mais nous souhaitons utiliser un paramètre pour permettre la modification de effect à des fins de dépannage. Définissez un paramètre effectType et limitez-le uniquement à deny et disabled. Ces deux options correspondent à nos exigences métier. Le bloc de paramètres terminé ressemble à cet exemple :

"parameters": {
  "effectType": {
    "type": "string",
    "defaultValue": "Deny",
    "allowedValues": [
      "Deny",
      "Disabled"
    ],
    "metadata": {
      "displayName": "Effect",
      "description": "Enable or disable the execution of the policy"
    }
  }
},

Règle de stratégie

La dernière étape de création de notre définition de stratégie personnalisée est la composition de la règle de stratégie. Nous avons identifié deux instructions à tester :

  • Le compte de stockage type est Microsoft.Storage/storageAccounts.
  • Le compte de stockage supportsHttpsTrafficOnly n’est pas true.

Comme ces instructions doivent avoir la valeur true, utilisez l’opérateur logique allOf. Passez le paramètre effectType à l’effet au lieu de faire une déclaration statique. Notre règle terminée ressemble à cet exemple :

"if": {
  "allOf": [
    {
      "field": "type",
      "equals": "Microsoft.Storage/storageAccounts"
    },
    {
      "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
      "notEquals": "true"
    }
  ]
},
"then": {
  "effect": "[parameters('effectType')]"
}

Définition terminée

Voici notre définition terminée avec les trois parties de la stratégie définies :

{
  "properties": {
    "displayName": "Deny storage accounts not using only HTTPS",
    "description": "Deny storage accounts not using only HTTPS. Checks the supportsHttpsTrafficOnly property on StorageAccounts.",
    "mode": "all",
    "parameters": {
      "effectType": {
        "type": "string",
        "defaultValue": "Deny",
        "allowedValues": [
          "Deny",
          "Disabled"
        ],
        "metadata": {
          "displayName": "Effect",
          "description": "Enable or disable the execution of the policy"
        }
      }
    },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Storage/storageAccounts"
          },
          {
            "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
            "notEquals": "true"
          }
        ]
      },
      "then": {
        "effect": "[parameters('effectType')]"
      }
    }
  }
}

La définition terminée peut être utilisée pour créer une stratégie. Le portail et chaque SDK (Azure CLI, Azure PowerShell et API REST) acceptent la définition de différentes façons, vous devez donc passer en revue les commandes de chacun d’eux pour vérifier comment les utiliser. Attribuez-la ensuite, à l’aide de l’effet paramétré, aux ressources appropriées pour gérer la sécurité de vos comptes de stockage.

Nettoyer les ressources

Si vous avez fini d’utiliser les ressources de ce tutoriel, suivez les étapes ci-dessous pour supprimer les affectations ou définitions que vous avez créées :

  1. Sélectionnez Définitions (ou Affectations si vous essayez de supprimer une affectation) sous Création dans la partie gauche de la page Azure Policy.

  2. Recherchez la nouvelle définition d’initiative ou de stratégie (ou affectation) à supprimer.

  3. Cliquez avec le bouton droit sur la liste ou cliquez sur le bouton de sélection en fin de définition (ou d’affectation), puis sélectionnez Supprimer la définition (ou Supprimer l’affectation).

Révision

Dans ce didacticiel, vous avez effectué avec succès les tâches suivantes :

  • Identifier vos exigences métier
  • Associer chaque exigence à une propriété de ressource Azure
  • Associer la propriété à un alias
  • Déterminer l’effet à utiliser
  • Composer la définition de stratégie

Étapes suivantes

Ensuite, utilisez votre définition de stratégie personnalisée pour créer et attribuer une stratégie :