• Activer la purge protection de vos keyvaults
• Activer la soft delete de vos keyvaults
• Enforcer les Networks rules sur vos keyvaults
• Interdire la création de keyvaults dans certaines régions
• Enforcer l’utilisation des private endpoints sur vos keyvaults

Vous êtes généralement très content de ces policies. Mais maintenant prenons le use case suivant : vous avez un KeyVault qui a été supprimé par erreur et vous souhaitez le restaurer.

Il est fort possible que lorsque vous voulez le restaurer vous ayez une erreur de ce type :

➜  $removeKeyvault | Undo-AzKeyVaultRemoval
Undo-AzKeyVaultRemoval: Resource 'kvipbd7f00' was disallowed by policy. Policy identifiers: '[{"policyAssignment":{"name":"Deny Key Vaults without IP rules","id":"/subscriptions/subId/resourcegroups/rg-kv-iprules-lab-20260624/providers/Microsoft.Authorization/policyAssignments/assign-keyvault-ip-rule-deny"},"policyDefinition":{"name":"Key Vaults must define at least one IP rule","id":"/subscriptions/subId/providers/Microsoft.Authorization/policyDefinitions/deny-keyvault-without-ip-rules","version":"1.0.0"}}]'.

Vous avez donc suivez la documentation de Microsoft pour restaurer votre Keyvault et rien n’y fait à cause d’une policy. Ici dans ce cas elle vérifie qu’il y a au moins une IP configurée dans les network rule du Keyvault.

Pour contourner ce problème, la solution la plus simple est de désactiver la policy qui bloque la restauration du KeyVault, de restaurer le KeyVault et de réactiver la policy. Mais bien entendu cela fonctionne si vous avez les droits pour désactiver la policy, et la désactivation d’une policy peut avoir des impacts sur votre gouvernance surtout si elle impacte un grande nombre de ressources et une plateforme fortement utilisée.

Il y a une autre solution beaucoup moins simple, mais plus élégante et qui ne nécessite pas de désactiver la policy. Il s’agit de recréer le Keyvault via un template ARM ou bicep. Ici je vais le faire en ARM, mais vous pouvez le convertir en bicep si vous le souhaitez.

Commençons par voir à quoi ressemble un keyvault supprimé en json.

{
  "Id": "/subscriptions/subId/providers/Microsoft.KeyVault/locations/westeurope/deletedVaults/kvipbd7f00",
  "DeletionDate": "2026-06-24T12:07:06Z",
  "ScheduledPurgeDate": "2026-09-22T12:07:06Z",
  "PublicNetworkAccess": null,
  "VaultUri": null,
  "TenantId": "00000000-0000-0000-0000-000000000000",
  "TenantName": null,
  "Sku": null,
  "EnabledForDeployment": false,
  "EnabledForTemplateDeployment": null,
  "EnabledForDiskEncryption": null,
  "EnableSoftDelete": null,
  "EnablePurgeProtection": true,
  "EnableRbacAuthorization": null,
  "SoftDeleteRetentionInDays": null,
  "AccessPolicies": null,
  "AccessPoliciesText": "",
  "NetworkAcls": null,
  "NetworkAclsText": "",
  "OriginalVault": null,
  "ResourceId": "/subscriptions/subId/resourceGroups/rg-kv-iprules-lab-20260624/providers/Microsoft.KeyVault/vaults/kvipbd7f00",
  "VaultName": "kvipbd7f00",
  "ResourceGroupName": null,
  "Location": "westeurope",
  "Tags": {},
  "TagsTable": null
}

Comme on peut le voir, il n’y a pas beaucoup d’informations sur le KeyVault supprimé. Il n’y a pas de networkAcls, pas de networkrules. Et clairement beaucoup d’informations sont manquantes pour recréer le Keyvault.

On comprend mieux pourquoi il créé le keyvault en mode public lors d’une restauration, cat il a tout perdu. Maintenant, si on creuse un peu la doc API, on trouve l’option createMode qui permet de créer un KeyVault en mode “Recover”.

On va donc pouvoir créer un keyvault via l’ARM suivant :

{
	"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
	"contentVersion": "1.0.0.0",
	"parameters": {
		"keyVaultName": {
			"type": "string",
			"metadata": {
				"description": "Name of the Azure Key Vault to create or recover."
			}
		},
		"location": {
			"type": "string",
			"defaultValue": "[resourceGroup().location]",
			"metadata": {
				"description": "Location for the Key Vault resource."
			}
		},
		"tenantId": {
			"type": "string",
			"defaultValue": "[subscription().tenantId]",
			"metadata": {
				"description": "Azure AD tenant ID for the Key Vault."
			}
		},
		"skuName": {
			"type": "string",
			"defaultValue": "standard",
			"allowedValues": [
				"standard",
				"premium"
			],
			"metadata": {
				"description": "SKU for the Key Vault."
			}
		},
		"ipRules": {
			"type": "array",
			"defaultValue": [],
			"metadata": {
				"description": "Array of public IPv4 CIDR strings allowed to access the Key Vault (for example: 203.0.113.10/32)."
			}
		},
		"defaultAction": {
			"type": "string",
			"defaultValue": "Deny",
			"allowedValues": [
				"Allow",
				"Deny"
			],
			"metadata": {
				"description": "Default network ACL action."
			}
		},
		"bypass": {
			"type": "string",
			"defaultValue": "AzureServices",
			"allowedValues": [
				"AzureServices",
				"None"
			],
			"metadata": {
				"description": "Traffic that can bypass network ACLs."
			}
		}
	},
	"variables": {
		"ipRuleObjects": "[map(parameters('ipRules'), lambda('ip', createObject('value', lambdaVariables('ip'))))]"
	},
	"resources": [
		{
			"type": "Microsoft.KeyVault/vaults",
			"apiVersion": "2023-07-01",
			"name": "[parameters('keyVaultName')]",
			"location": "[parameters('location')]",
			"properties": {
                "createMode": "recover",
				"tenantId": "[parameters('tenantId')]",
				"sku": {
					"family": "A",
					"name": "[parameters('skuName')]"
				},
				"enabledForDeployment": false,
				"enabledForDiskEncryption": false,
				"enabledForTemplateDeployment": false,
				"publicNetworkAccess": "Enabled",
				"networkAcls": {
					"bypass": "[parameters('bypass')]",
					"defaultAction": "[parameters('defaultAction')]",
					"ipRules": "[variables('ipRuleObjects')]",
				}
			}
		}
	],
	"outputs": {
		"keyVaultResourceId": {
			"type": "string",
			"value": "[resourceId('Microsoft.KeyVault/vaults', parameters('keyVaultName'))]"
		}
	}
}

Ce template on va pourvoir l’appeler comme cela :

New-AzResourceGroupDeployment -name "recover-keyvault" -ResourceGroupName $removekeyvault.ResourceId.split('/')[4] -TemplateFile .\recover-keyvault.json -keyvaultName $removeKeyVault.VaultName  -ipRules @("1.1.1.1/32")

De manière un peu magique, votre keyvault est correctement restauré sans changer les policies. Bien entendu, ce template est à adapter selon les policies que vous utilisez.

Voilà plus d’excuse pour désactiver la gouvernance de vos environnements en production. Bien entendu, je vous conseille de tester ce template dans un environnement de test avant de l’utiliser en production, et encore moins en urgence en pleine nuit.

Bien entendu, tout ce qui est inventaire classique pour répondre à des questions simples de types :

• Combien de VM sont actuellement utilisées selon l’OS et le SKU ?
• Combien de bases de données sont actuellement en production ?
• Combien de comptes de stockages sont disponibles ?

Toutes ses questions d’inventaires sont très simplement disponible via Azure Resource Graph.

Maintenant prenons la question suivante :

• Quel est la capacité globale de stockage dans tous les Azure Storages ?

Et bien là ça devient un peu plus compliqué, car bien que la métrique soit disponible, elle est présente par Storage et par défaut non agrégée.

Il est possible de trouver cette réponse en regardant chaque stockage et en faisant la somme des résultats de la métrique “Used Capacity”

Sinon il y a un autre moyen via Azure Workbook que je vais vous montrer.

On va donc commencer par en créer un nouveau (celui par défaut ne me convient dans ce contexte précis). Donc via le portail car la construction d’un workbook via de l’infrastructure as code relève plus d’une épopée que d’une promenade de santé.

On va commencez par ajouter 2 filtres pour les souscriptions et pour les ressources comme ci-dessous:

Pour les différents resources picker, n’oubliez pas de sélectionner “Required” et “Allow multiple selection” pour les deux filtres et d’inclure le champ “All”.

Ensuite il est possible de faire une requête Kusto pour faire le lien entre les ressources et les métriques.

On va donc commencez par générer une liste avec toutes les valeurs pour chaque storage:

Pour que ce soit lisible, allez dans les paramètres avancées et modifier la valeur Value pour changer le format vers Bytes

Et pour avoir un aggrégat de la capacité utilisée, il suffit de faire une somme de toutes les valeurs via la visualisation Stat et de sélectionner “Sum” dans les options d’agrégation.

Voilà si vous voulez que je vous fasse d’autres articles liés aux workbooks, n’hésitez pas à me le faire savoir en commentaire.

Et bien entendu, voici un lien vers le workbook que j’ai créé pour ce cas d’usage : Github link

Pourquoi me direz-vous ? Et bien pour des raisons de conformité, de performance ou de latence, il peut être crucial de savoir où se trouvent physiquement vos ressources Azure. Mais aussi pour des problèmes de capacités, il peut être nécessaire de savoir si les zones concernées ont assez de ressources pour héberger vos infrastructures.

Et cela vous permet aussi de gérer vos paramètres pour votre CI/CD pour s’assurer que les ressources se déploient dans les zones où les ressources sont disponibles.

Par exemple sur le firewall Azure, il y a en ce moment des contraintes sur les capacités comme le montre ce lien : Azure Documentation

Vous pouvez donc savoir quelle est la zone que vous utilisez pour votre souscription en utilisant la commande suivante :

az account list-locations --query "[?availabilityZoneMappings].{availabilityZoneMappings: availabilityZoneMappings, displayName: displayName, name: name}"

Cette commande vous donnera une liste de toutes les zones disponibles pour votre souscription, ainsi que les zones de disponibilité associées à chaque zone. Vous pourrez ainsi identifier la zone physique qui correspond à la zone logique que vous utilisez pour vos ressources Azure.

Et si vous préférez une interface graphique je vous recommande le site App Scout qui vous permettra de visualiser les différentes zones et leurs capacités en temps réel. C’est un outil très pratique pour gérer vos ressources Azure de manière efficace. Voici ce que cela donne pour la zone West Europe :

Il y a quelques années j’avais créé un système de Sandbox Azure qui me permet simplement de créer des resources group éphémères. Avec un simple script, je pouvais créer un resource group, faire mes tests, et ensuite la suppression est automatique en fonction de la date ajouté dans un tag. Rien de plus simple.

Maintenant pour faire cela, j’utilise principalement une fonction dans mon profil Powershell pour créer des resources groups. La fameuse fonction New-AzTestResourceGroup que certains d’entre vous l’ont peut être déja aperçu dans des démos que je fais.

Maintenant avec l’IA, c’est tellement plus rapide de dire à copilot “Créer moi un resource group demo-rg en France Central et ajoute moi un compte de stockage. Top au niveau de gain de temps, car en plus il va vous générer votre fichier de déploiement qui va bien. Cependant le resource group n’a pas toujours les bons tags.

Il y a une manière très simple de rajouter cela, il suffit de demander à Copilot de rajouter les différents tags que vous souhaitez à chaque fois que vous créer un resource group. Vous pouvez lui demander de scoper ce rajout à votre workspace. Mais aussi en global en ajoutant un fichier dans votre répertoire utilisateur.

Voici un exemple de fichier que vous pouvez ajouter dans votre répertoire utilisateur pour que Copilot puisse ajouter les tags automatiquement à chaque fois que vous créer un resource group.

# Azure Resource Group Tagging Convention

## Mandatory Tags for Resource Groups
When creating Azure resource groups, always add the following tags:

- **AutoDelete**: `true`
- **ExpirationDate**: Current date in format `YYYY-MM-DD` (e.g., 2026-03-05)

## Implementation
- Apply these tags when using Bicep, Terraform, ARM templates, or Azure CLI
- Use `resourceGroup()` function in Bicep or equivalent in other IaC tools
- Set tags at resource group creation time, not as an afterthought

Et pour le chemin il s’agit de celui ci : C:\Users\YourUserName\AppData\Roaming\Code\User\globalStorage\github.copilot-chat\memory-tool\memories

Et pouv finir voici de lien de l’aricle pour la sandbox : https://woivre.fr/blog/2018/11/sandbox-azure-pour-tout-le-monde

Voilà une petite astuce pour ne pas oublier de clean vos rsources après vos tests.

Si vous avez un environnement Azure que je qualifierais de standardisé et qui s’étend à plusieurs souscriptions. Il peut être tentant de vouloir refuser des recommandations ou du moins les reporter à plus tard.

Vous pouvez le faire rapidement via un script PowerShell ou autre. Pour cela, vous pouvez commencer par lister les différentes recommandations qui sont proposées via la commande suivante :

Get-AzAdvisorRecommendation -SubscriptionId <SubscriptionId>

Ensuite, vous pouvez filtrer les recommandations que vous souhaitez refuser ou reporter à plus tard. Par exemple, si vous souhaitez reporter une recommandation pour 90 jours, vous pouvez utiliser la commande suivante :

Disable-AzAdvisorRecommendation -RecommendationName e33855d4-7579-e4d0-c459-23fad3665bd6 -Day 90

Et si vous voulez simplement reporter un type de recommandation globalement , vous pouvez utiliser la commande suivante :

get-azAdvisorRecommendation | Where { $_.RecommendationTypeId -eq $recommendationId } | % { $_ | Disable-AzAdvisorRecommendation -Day 120 }

Allez objectif 2026, on gère les recommandations à l’échelle ! Et plus aucune active sans action planifiée !

Depuis un moment, Microsoft a mis à jour la configuration du boot diagnostics pour les machines virtuelles Azure. Désormais, il est possible de configurer le boot diagnostics sans avoir besoin de créer un compte de stockage dédié. Ou du moins il est maintenant entièrement managé par Microsoft.

Voici une requête Graph pour détecter toutes vos VMs qui ne sont pas encore passé sur ce nouveau mode de boot diagnostics :

resources
| where type =~ "microsoft.compute/virtualMachines"
| where properties.diagnosticsProfile.bootDiagnostics.enabled == true
| where isnotnull(properties.diagnosticsProfile.bootDiagnostics.storageUri)

Si cela peut vous éviter des storages dédiés au boot diagnostics, c’est toujours une ressource de moins à gérer et à sécuriser, et cela simplifie la configuration de vos machines virtuelles.

Alors concrétement que’est ce que cela change pour vous ? Et bien, si vous êtes en entreprise avec du Zero Trust, du hub & Spoke, cela ne change concrétement rien que pour vous. Car les subnets dans vos spokes sont par nature déjà privés, vu qu’ils passent par votre hub pour accéder à internet.

Par contre, pour les plus petits environnements, il faudra bien penser soit à remettre vos subnets en public, soit expliciter l’accès à internet via une NAT Gateway, un Firewall, ou un Load balancer avec une outbound rule ou une IP statique sur vos VMS.

Concrètement, votre route table que ce soit implicite ou explicite vers Internet est désactivée, il faut donc la remplacer par une route directe. Le plus simple est de mettre en place une NAT Gateway, mais attention au coût de cette dernière car le coût est aussi basé sur les datas qui transitent par celle ci.

Microsoft fourni des exemples pour le private subnet, je vous conseille d’y jeter un oeil : GitHub - Azure Networking Private Subnet Routing

Celle ci est très pratique, j’en conviens et je l’utilise régulièrement, mais elle peut aussi être dangereuse si elle est donnée à des personnes qui ne devraient pas l’avoir.

En effet la permission sur Windows tourne en temps que SYSTEM, et peut donc faire n’importe quoi sur la machine virtuelle, y compris installer des logiciels malveillants ou voler des données sensibles, ou désactiver des services de sécurité. Et sur Linux, ce n’est pas mieux elle tourne en tant que sudo, et peut aussi faire n’importe quoi.

Et pour couronner le tout, une fois que vous avez fait run, il n’est pas possible de stopper la commande, donc ne copiez pas des commandes que vous ne comprenez pas, ou que vous n’avez pas vérifiées, et ne les faites pas tourner sur des machines de production sans les avoir testées au préalable dans un environnement de test.

Donc ne donnez pas cette permission Microsoft.Compute/virtualMachines/runCommand/action à n’importe qui, et assurez vous que les personnes qui l’ont sont de confiance et savent ce qu’elles font. Où alors donnez le sur des machines dans des sandbox qui n’ont pas accès à vos environnements de production.

Précédemment, la réponse était très souvent quelque chose du genre “Désolé, il n’est pas possible d’agrandir un subnet, il faut en créer un nouveau et migrer les ressources ou garder 2 subnets disjoints. Il faudra bien le spécifier à chaque fois que vous faîtes des ouvertures de routes, ou que l’on doit modifier des routes tables”.

Bon maintenant, bonne nouvelle il est possible d’ajouter un deuxième address prefixe à votre subnet comme cela

$vnet = Get-AzVirtualNetwork -ResourceGroupName 'test-rg' -Name 'vnet-1'
Set-AzVirtualNetworkSubnetConfig -Name 'subnet-1' -VirtualNetwork $vnet -AddressPrefix '10.0.0.0/24', '10.0.1.0/24'
$vnet | Set-AzVirtualNetwork

L’avantage ici c’est que si vous avez la chance d’avoir des subnets joints comme dans l’exemple ci-dessus, vos ouvertures de routes passe simplement d’une 10.0.0.0/24 à un 10.0.0.0/23, et cela simplifie grandement vos opérations.

Mais aussi votre scale set à l’intérieur de votre subnet peut maintenant scale à 300 noeuds sans à avoir à déplacer votre workload dans un nouveau subnet. Mais aussi possible pour les GatewaySubnet si vous avez fait l’erreur de la créer en /29 pour mettre un simple Point to Site, et que vous voulez maintenant faire du VPN S2S ou du ExpressRoute.

Alors c’est certes quelque chose de bien connue, mais je vois tellement de personnes qui l’oublie ou qui se disent qu’ils ne seront pas touchés par ces limitations.

Donc commençons par la documentation officielle d’Azure qui liste les différentes limitations : https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits

Ces limites peuvent vous paraître très lointaines par rapport à votre utilisation actuelle, mais vous pouvez les atteindre plus rapidement que vous ne le pensiez.

Par exemple mettre en place des bundles d’Azure Policy pour chaque type de resource et de risques, il y a une limite sur le nombre de définition custom par scope. Cela peut donc être un challenge au niveau de votre architecture de gouvernance, soit vous devez utiliser des initiatives, soit créer plusieurs scopes ou alors utilisez d’avantages de policy built-in.

Les custom role definition ont une limite au tenant aussi. Vous ne pouvez donc pas laisser tous vos utilisateurs créer des rôles personnalisés à tout va, sinon vous risquez d’atteindre cette limite plus rapidement que prévu, et de perdre la gouvernance sur les rôles qui existent.

Pour les gros utilisateurs d’Azure API Management, sachez entre autre qu’il y a des limites sur le nombre d’operations / instance. Et ce nombre comprend entre autre les opérations présente sur les révisions. Et par défaut le service n’offre pas de métrique simple pour vérifier si vous allez atteindre ou non cette limite, c’est donc à vous de la calculer et de bien gérer vos révisions non utilisées, ainsi que les API obsolètes.

De même pour Azure Firewall, il y a des limites sur le nombre de règles que vous pouvez créer. Et le calcul d’une règle correspond à 1 source, 1 destination, 1 port globalement. Donc si vous ajoutez la réglé Allow TCP 9093 from 10.0.0.0/24 and 10.0.1.0/24 to 10.1.0.0/24 cela correspond à 2 règles. Pour limiter cela il est possible de faire des ip groups, ou d’ouvrir en plus large quand cela est possible. Mais cela peut vite devenir un challenge de gérer ces règles, surtout si vous avez plusieurs équipes qui gèrent le firewall.

Mon conseil est donc pour chaque nouveau service que vous ouvrez sur votre plateforme, ou de chaque nouvelle fonctionnalité que vous offrez en self-service à vos utilisateurs, posez vous la question des limites et s’il est possible de les atteindre. Et n’oubliez pas que même si ces limites peuvent évoluer dans le temps, il est nécessaire d’appliquer tous vos processus régaliens autour de ces ressources comme l’inventaire et une gestion rigoureuse du cycle de vie.