Gouverner son Cloud Azure, c’est s’assurer que tout est mis en œuvre de manière cohérente et contrôlée. Rien de bien différent par rapport à un environnement On premise si l’on réfléchit bien.
A part peut être une facilité plus importante à déléguer sur Azure. Déléguer, c’est aussi devoir contrôler plus finement.
Pour garantir la sécurité, le bon usage des ressources, le contrôle des coûts ou le respect de la conformité.
Ce ne sont ici que quelques uns des nombreux exemples de gouvernance. Compliqué (Impossible !) sans un bon outillage.
Azure Policy ou stratégie est incontestablement un excellent moyen de répondre à ce besoin. C’est un service simple à utiliser (ou assez simple), mais vraiment puissant.
Bien comprendre la philosophie d’Azure Policy c’est comprendre les 3 piliers pour cette fonctionnalité:
– Un scope ou étendue, groupe de ressources ou subscription par exemple. C’est la limite que va couvrir la stratégie.
– Un ou plusieurs types de cibles pour définir une condition, comme une machine virtuelle ou un compte de stockage. Ce qui doit être mais aussi ce qui ne doit pas être. Voir un peu plus bas la notions de policyRule.
– Puis un effet, une action (Auditer, Corriger, Interdire…etc).
Etendue et type sont différents. Toutes les ressources de type machines virtuelles représentent le type et dans mon groupe de ressources ou dans mon abonnement (subscription) représente l’ Etendue ou limite d’application. Voilà pour une présentation rapide et sommaire.
Pour démarrer cette série en 3 parties, un peu plus de détails sur le menu des stratégies et les sous menus qui sont régulièrement utilisés lors du déploiement.
En rouge, ce qui est utile dans la gestion courante. Tout commence par le sous-menu Définitions. Une définition, c’est le détail de ce qui fait une stratégie. De quoi est-elle constituée ? Dans la liste de sélection de ce menu se trouve un filtre Catégorie. Ici, sélectionnez la catégorie Backup.
Et notons quelques subtilités supplémentaires dans ce sous-menu. En plus de toutes les définitions typées dans la catégorie Backup se trouvent une notion de Type et de Type de définition en jaune. Le Type Builtin indique que cette stratégie est fournie par défaut par Microsoft. Il est possible de créer ses propres stratégies, elles apparaissent en type Personnalisé ou Custom. Et le Type de définition est une notion différente. Pour comprendre cette partie, refaire une sélection de Catégorie et choisir Security Center.
Ici, on trouve un nouveau Type de définition appelé Initiative. Une initiative, c’est un ensemble cohérent de stratégies. Dans l’exemple ci-dessous, l’initiative Benchmark de sécurité Azure est un ensemble de … 205 stratégies. Cette initiative est décrite de la façon suivante : L’initiative Benchmark de sécurité Azure représente les stratégies et les contrôles qui implémentent les recommandations de sécurité définies dans le Benchmark de sécurité Azure v2.
Un seul et même objectif, de la conformité. Mais à une échelle bien différente. Cliquez sur cette initiative pour afficher l’ensemble des stratégies qui la compose. Après avoir consulté ce nouvel écran, revenir dans la catégorie Backup et choisir la première stratégie nommée La sauvegarde Azure doit être activée pour les machines virtuelles. Ici, cette sélection affiche un écran avec ce qui fait vraiment une définition. Un fichier au format Json. Conservez cette fenêtre ouverte.
On retrouve sur le site de l’éditeur la structure d’un fichier vierge de définition à cette adresse : https://docs.microsoft.com/fr-fr/azure/governance/policy/tutorials/create-custom-policy-definition#compose-the-definition/?WT.mc_id=AZ-MVP-5003759
Deux sujets déjà abordés, l’effet (then, effect) et la règle d’application (policyRule, if). Ainsi que quelques paramètres.
Dans la définition existante La sauvegarde Azure doit être activée pour les machines virtuelles, on retrouve cette structure avec des données.
Le bloc then / effect et ses valeurs, ici, AuditIfNotExists ou Disabled
"effect": {
"type": "String",
"metadata": {
"displayName": "Effet",
"description": "Activer ou désactiver l'exécution de la stratégie"
},
"allowedValues": [
"AuditIfNotExists",
"Disabled"
],
"defaultValue": "AuditIfNotExists"
}
Puis plus bas, le bloc PolicyRule / if et son filtre. Ce qu’il faut comprendre ici => Si le type de ressources est Microsoft.Compute/virtualMachines et l’id de la ressource ne contient pas /resourceGroups/databricks-rg- alors la définition de stratégie est dans son périmètre d’application.
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
{
"field": "id",
"notContains": "/resourceGroups/databricks-rg-"
}
]
},
"then": {
"effect": "[parameters('effect')]",
"details": {
"type": "Microsoft.RecoveryServices/backupprotecteditems"
}
}
}
Il n’est pas indispensable de comprendre précisément ces fichiers Json, mais c’est assez intéressant et cela aidera celles et ceux qui souhaitent se créer leurs propres définitions (de type Personnalisé). Les plus curieuses / curieux se plongeront dans la lien éditeur fourni un peu plus haut dans ce sujet.
Dans la partie 2/3 de cet article (mis en ligne le 25 Octobre, https://thierrybtblog.wordpress.com/2021/11/10/conformite-et-gouvernance-avec-azure-policy-2-3/), comment affecter (lier) cette définition sur une étendue. Et comment les ressources sont impactées par l’effet choisit dans les paramètres (AuditIfNotExists, Disabled…etc). Puis comment vérifier Affectation et Conformité pour les ressources ciblées.
Une techno, des infos. 