Conformité Cloud Microsoft Azure : quelle approche pour remédier efficacement vos ressources ?

Avec la forte tendance Move to Cloud, les entreprises doivent faire face à des enjeux et des risques intrinsèques au Cloud : manque de visibilité et de contrôle, mauvaises configurations, expansion de la surface d’attaque, exposition ou perte des données, etc.

Tous ces enjeux ont un pilier commun : la conformité. La conformité est l’ensemble des processus et outils qui permettent le respect des règles de sécurité. Dans le Cloud, ces règles peuvent être définies par des Benchmarks (CIS, SOC, …), et/ou en interne par la cybersécurité. Les outils peuvent appliquer des contrôles bloquants, modificatifs ou d’audit (qui référencent mais n’agissent pas).

Quelle est la meilleure approche pour assurer efficacement la conformité dans le Cloud Azure ? Dans cet article, nous allons vous partager notre expérience sur les outils permettant de bloquer ou de remédier des ressources non sécurisées dans Azure, et sur les avantages et limites de chaque approche.

Sur Azure, une ressource non sécurisée (une non-conformité) peut être :

• Des permissions ou des rôles trop permissifs,
• Une exposition réseau,
• Des données ou secrets non-chiffrés,
• L’utilisation de protocoles non-sécurisés,
• L’absence de logs, etc.

Pour être efficace, la conformité doit être la plus automatisée possible. Plusieurs outils nativement intégrés à Azure le permettent :

1. Azure Policy, la solution la plus simple et efficace, est intégrée nativement à la Conformité dans Azure. Elle permet le blocage, la remédiation ou l’audit des non-conformités.
2. Azure Deployment Script combine policy et script. Il ne permet pas de bloquer mais peut remédier instantanément des non-conformités plus complexes grâce à l’exécution d’un script.
3. Azure Automation Account crée et automatise l’exécution de scripts. Malgré un manque de réactivité pour remédier, il favorise la centralisation, l’adaptabilité et la scalabilité.

‍

Azure Policy : l’outil de base de la conformité Azure

Azure Policy permet une gestion simple et efficace des contrôles les plus courants dans Azure.

Chaque policy décrit une condition de non-conformité et un effet qui s’applique si cette condition est vérifiée. Les ressources Azure sont évaluées régulièrement ou quand elles sont modifiées. Azure Policy peut, si besoin, bloquer ou remédier les ressources non sécurisées.

Azure Policy est l'outil de conformité intégré nativement dans Azure :

• Intégré au portail Azure et facilement requêtable (API, Graph Explorer),
• Facilité de la gestion et de l’affectation des policies,
• Visibilité, suivi des non-conformités et dashboards,
• Built-in policies (crées et maintenues pas Microsoft).

> Comment construire et utiliser une policy Azure ?

Le cœur de la policy est la condition de non-conformité. C’est une combinaison logique de comparaisons entre :

• L’état actuel ou demandé d’un champ de la ressource,
• Les valeurs acceptables pour que la ressource soit conforme.

Microsoft crée et tient à jour des alias : des paramètres propres à chaque type de ressources qui sont requêtables. Seuls les alias et certaines informations (Subscription, tags, localisation, …) peuvent être contrôlés par les policies.

L’effet est l’action qui est déclenchée quand une ressource est évaluée comme non-conforme par une policy. Cinq effets sont particulièrement utiles : Audit, AuditIfNotExists, Deny, Modify et DeployIfNotExists.

Pour bien comprendre les policies, il faut s’intéresser au fonctionnement de la gestion des ressources sur Azure. Azure Resource Manager (ARM) est le service de déploiement et de gestion des ressources Azure. Toute manipulation d’une ressource au niveau du plan de contrôle (i.e. de sa configuration) est traduite en appel API vers ARM (GET, PUT, PATCH, DELETE, …) ; et ce, quel que soit l’initiateur (Portail, IaC, PowerShell, policy…).

Le schéma ci-dessous résume le fonctionnement des policies Azure pour chaque effet :

• Déclenchement de l’évaluation d’une ressource,
• Interactions avec ARM,
• Evaluation de la conformité et actions engendrées.

‍

‍

Quelques commentaires additionnels sur Azure Policy :

‍

‍

> Remédier avec Azure Policy, avantages et limites.

Quels contrôles sont réalisables avec Azure Policy ?

• Bloquer ou remédier avant tout déploiement ou modification.
• Auditer régulièrement ou à la demande l’état des ressources.
• Plus concrètement :
  • La configuration d’une ressource (sku, options, protocoles utilisés, chiffrement, etc.),
  • L’IAM et les rôles (Azure, pas Entra),
  • L’exposition réseau (partiellement),
  • Les conventions simples (nom, tags, etc.),
  • Les logs et les backups, etc.

Quels contrôles ne sont pas compatibles avec Azure Policy ?

• La suppression d’une ressource déjà créée.
• Les données (Data Plane).
• La sécurité à l’intérieur des Machines Virtuelles (OS, applications, malwares, etc.). Pour ces contrôles, l’utilisation d’agents est recommandée. La présence des agents sur les VMs peut être contrôlée avec une policy.
• Un contrôle basé sur l’évaluation de :
  • Plus de deux ressources,
  • Ressources dans des Subscriptions différentes,
  • Ressources à l’extérieur d’Azure.

Exemple de cas d’usage : Comment contrôler le tag d’une ressource ?

• Pour uniquement contrôler le respect d’une convention de nommage, une policy est suffisante.
• Pour corréler la valeur du tag dans Azure avec une source externe (AppDB, CMDB, DataLake) il faut utiliser une autre solution : les scripts.

Nous allons donc nous intéresser à Azure Deployment Script, la solution proposée par Azure pour déclencher l’exécution d’un script avec une policy.

‍

Azure Deployment Script : Remédier des non-conformités plus complexes

Azure Deployment Script est un type particulier de policy DeployIfNotExists qui permet de créer temporairement les ressources nécessaires à l’exécution d’un script :

• Un Deployment Script pour superviser l’exécution du script et stocker des informations (sorties, logs, erreurs, etc.).
• Un Storage Account (Compte de stockage) pour stocker les logs et sorties du script.
• Un Container Instance pour exécuter le script :
  • Utilise obligatoirement une IP publique,
  • Temps d’exécution limité à 3h.

Le script peut être codé en PowerShell ou Azure CLI. Il est possible d’inclure le script dans le corps de la policy, mais il doit être écrit sur une seule ligne. Le stockage du script à l’extérieur de la policy est possible avec :

• Un répertoire GitHub (non-recommandé)
  • Public – fonctionne mais pas sécurisé,
  • Privé – ‘Raw URL’ expire toutes les semaines.

• Un Storage Account - Blob (recommandé)
  • En cas de manipulation de secrets dans un script, une ressource additionnelle pour gérer les secrets (Key Vault) est fortement recommandée.

Le Storage Account et le Key Vault doivent être créés et configurés en amont. L’autorisation pour accéder au Blob se fait avec un SAS Token (Shared Access Signature), à inclure dans le corps de la policy. De plus, le Storage Account doit avoir un accès public ouvert pour être accessible depuis le Container Instance. Ainsi, il est d'autant plus important de ne pas stocker les secrets en clair dans les scripts mais plutôt de les stocker et les récupérer dans un Key Vault !

De plus, le script peut interagir avec la policy à travers ses entrées/sorties :

• Adapter les entrées du script (localisation, Sub, etc.),
• Utiliser les sorties du script pour configurer et déployer des ressources.

Le schéma ci-dessous présente une architecture possible pour utiliser un Deployment Script. Avec les permissions adaptées, le script permet de créer des contrôles plus poussés que les policies. Par exemple, il peut requêter une API externe afin de comparer la valeur d’un tag d’une ressource Azure avec une base de données on-premise.

‍

‍

‍Qu’apporte Azure Deployment Script ?

• Contrôles et remédiations plus poussés grâce à l’exécution d’un script,
• Lancement du script quasi-immédiatement après l’apparition d’une non-conformité,
• C’est une policy, il bénéficie des avantages de la gouvernance Azure (cf. partie 1).

Quelles sont les conséquences de son utilisation ?

• Déploie des ressources dans les Subscriptions à contrôler (potentiellement un environnement de Production),
• Permissions à hauts privilèges (déploiement) sur le périmètre à contrôler,
• Mauvaise scalabilité (temps, coût).

Le Deployment Script permet de dépasser les limites des policies avec l’exécution d’un script. Cependant, pour y parvenir, il est nécessaire de déployer des ressources dans les Subscriptions à contrôler, et de donner des permissions élevées sur un périmètre large. Nous souhaitons donc étudier une alternative, potentiellement moins réactive, mais aussi moins intrusive : Azure Automation Account.

‍

Azure Automation Account : Remédier en privilégiant l’adaptabilité à la réactivité

Azure Automation Account est un service PaaS qui permet le codage et le test des scripts (Python ou PowerShell). Il facilite aussi la planification de l’exécution des scripts.

L’Automation Account peut contenir plusieurs scripts, sous la forme de Runbooks, qui peuvent être déclenchés :

• Manuellement,
• De manière planifiée ou à intervalles réguliers (jobs),
• Par un évènement (Logic App, Webhook, alerte).

L’Automation Account crée un environnement sandbox pour exécuter les scripts. Il est aussi possible de lancer les scripts dans une Machine Virtuelle (Hybrid Worker). Cela résout les limitations de l’environnement Sandbox (IP publique, 3h max d’exécution) mais nécessite la sécurisation d’une VM.

Le schéma ci-dessous présente une architecture possible d’utilisation d’un Automation Account :

Le Runbook évalue une ressource, récupère les secrets dans le Key Vault et requête la base de données externe. Il peut alors vérifier la conformité et stocker cette information dans un Storage Account (ou une DB).

Dans cet exemple, le Runbook se déclenche à intervalle régulier. Mais nous pouvons aussi imaginer un déclenchement par une alerte (ou un Webhook). Cela complexifie la solution mais permet une action plus immédiate.

En termes de remédiation, deux options sont possibles :

• Remédier immédiatement et automatiquement avec le script. Pour cela, l’identité utilisée peut nécessiter des permissions très élevées (modification, écriture) sur un périmètre large. Il faut donc être vigilant.
• Remédier manuellement à postériori. Le script peut stocker les non-conformités et optionnellement déclencher une communication ou une alerte pour prévenir les parties prenantes. Par exemple, une Logic App peut envoyer des mails demandant une remédiation.

Qu’apporte Azure Automation Account ?

• Bonne scalabilité (temps, coût),
• Toutes les ressources sont centralisées dans la Subscription de management,
• Plus modulable, des actions plus complexes sont envisageables. Par exemple :
  • Utiliser une Logic App pour créer une alerte ou envoyer des mails,
  • Envoyer des données vers une plateforme externe (IaC, CNAPP, Power BI, Teams, etc.).

Quelles sont les conséquences de son utilisation ?

• Délai temporel entre l’apparition d’une non-conformité et le lancement du script,
• Permissions élevées (modification, écriture) OU remédiation manuelle,
• Pas intégré à l’outil de Conformité Azure :
  • Modifications du script plus fréquentes (périmètre à contrôler, etc.),
  • Manque de visibilité sur les non-conformités.

Quels choix pour quelles typologies de remédiations ?

Dans cet article, nous avons introduit trois outils nativement intégrés à Azure qui permettent de remédier les ressources dans le Cloud de Microsoft. Chacun possède des avantages mais fait aussi face à des limites :

• Azure Policy est facile à mettre en place et à utiliser. Le plus souvent, vos contrôles seront implémentés en policies. Malheureusement, certaines non-conformités ne peuvent pas être détectées ou remédiées. Dans ce cas, les scripts permettent des actions plus poussées.
• Azure Deployment Script permet l’exécution d’un script immédiatement après l’apparition d’une non-conformité, tout en bénéficiant de son intégration native à la Conformité dans Azure. Néanmoins, il nécessite le déploiement de ressources dans les environnements de Production et manque de scalabilité.
• Azure Automation Account facilite le développement et l’automatisation des scripts dans Azure. Il est plus centralisé, scalable et modulable (scénarios et actions plus personnalisables). Cependant, l’utiliser pour détecter et/ou remédier immédiatement n’est pas toujours réalisable.

> Comment choisir quelle solution adopter ? Pour quels contrôles ?

‍

‍

Cette prise de décision peut parfois être plus complexe et nécessiter une étude approfondie en fonction de votre environnement et de votre politique de sécurité Cloud. D’autant plus que les actions modificatives automatisées peuvent créer des state drifts avec le IaC. Ainsi, nous recommandons une utilisation réfléchie et testée.

Pour conclure, ne pas oublier que la sécurité est régie par le risque. Il n’est pas pertinent d’utiliser des contrôles bloquants ou modificatifs sur toutes les non-conformités. Le gain apporté par le contrôle doit être supérieur à la perte (temps, coût, risques) engendrée par sa mise en place.

Pour certaines failles de sécurité, aller au-delà de ce qui est possible avec Azure Policy est pourtant nécessaire. Azure Deployment Script et Azure Automation Account sont alors des outils adaptés. Avec une approche projet (environnement dédié, étude de risques, tests, etc.) pour contrôler leur impact, ils permettent la mise en place sécurisée de contrôles complexes et d’actions poussées. Alors n’attendez plus ! Utilisez-les !