Azure Key Vault en réseau privé : organiser la rotation des secrets sans angle mort

Mettre Azure Key Vault derrière un Private Endpoint réduit l’exposition réseau, mais ne règle pas à lui seul la question de l’exploitation. Les secrets doivent encore être nommés, versionnés, consommés par les applications, renouvelés, validés et retirés proprement. Sans méthode, un coffre privé peut devenir un endroit sûr pour stocker des secrets que personne n’ose remplacer.

Le scénario traité ici est celui d’une application métier hébergée dans Azure, consommant plusieurs secrets : chaîne de connexion, clé d’API interne, certificat ou mot de passe technique. Le Key Vault est accessible uniquement depuis le réseau privé, les applications utilisent des identités managées, et l’équipe veut pouvoir tourner un secret sans couper la production.

Séparer réseau, identité et exploitation

Un Private Endpoint répond à une question : par quel chemin réseau le coffre est-il joignable ? Il ne répond pas à la question des droits. Un Key Vault privé reste fragile si trop d’identités peuvent lire tous les secrets. A l’inverse, des droits bien limités ne suffisent pas si le coffre reste accessible publiquement sans raison ou si le DNS privé n’est pas cohérent.

Controles reseau
Private Endpoint vers le VNet applicatif
Public network access limite ou desactive selon le modele
Zone DNS privee privatelink.vaultcore.azure.net

Controles d'identite
Identite managee par application ou workload
Acces limite aux secrets reellement necessaires
Separation lecture, ecriture et administration

Controles d'exploitation
Convention de nommage
Rotation documentee
Validation applicative
Journalisation des acces

Le point important est de ne pas confondre ces couches. Une erreur DNS peut empêcher l’application de joindre le coffre. Un mauvais rôle peut produire un 403. Une version de secret obsolète peut casser l’application même si le réseau et les droits sont corrects. Le runbook doit permettre de distinguer ces causes sans rouvrir le coffre par réflexe.

Stabiliser le DNS avant de parler de rotation

Avec un Private Endpoint, la résolution DNS devient un prérequis de production. Depuis le réseau applicatif, le nom public du coffre doit résoudre vers l’adresse privée du Private Endpoint. Si une VM de diagnostic, un pod ou un agent de build résout encore vers une adresse publique, la rotation ne sera pas le problème principal : le chemin réseau est incohérent.

VAULT_NAME=kv-app-prod-001
nslookup $VAULT_NAME.vault.azure.net

az network private-endpoint-connection list --name $VAULT_NAME --resource-group rg-security-prod --type Microsoft.KeyVault/vaults --query '[].{name:name,status:privateLinkServiceConnectionState.status}' -o table

Le test DNS doit être exécuté depuis une source représentative : VM d’administration dans le hub, pod applicatif, agent de build privé ou instance qui consomme réellement le coffre. Un poste local connecté en VPN ne suffit pas toujours à valider le chemin de l’application.

Donner à chaque application son identité de lecture

Une rotation propre commence par une surface d’accès lisible. Si plusieurs applications partagent la même identité ou le même secret générique, personne ne sait quel changement impacte quoi. L’identité managée doit refléter le workload, pas l’environnement entier.

Identite app-order-api-prod
Lecture : sql-order-connection-string
Lecture : partner-billing-api-key

Identite app-backoffice-prod
Lecture : sql-backoffice-connection-string
Lecture : smtp-relay-password

Identite pipeline-secret-rotation
Ecriture controlee sur secrets cibles
Pas de lecture large inutile
Pas de droits d'administration du coffre

Cette séparation rend les incidents plus simples. Si une application reçoit un 403, on sait quelle identité vérifier. Si un secret est lu anormalement, on sait quel workload est concerné. Si une rotation échoue, on peut limiter l’analyse au couple application-secret.

Utiliser les versions de secret comme transition

Key Vault versionne les secrets. Cette capacité est utile pour déployer une rotation sans remplacer brutalement la valeur active côté application. Le piège consiste à coder une version précise dans la configuration applicative. Dans ce cas, publier une nouvelle version dans Key Vault ne change rien : l’application continue de demander l’ancienne.

Reference stable recommandee
https://kv-app-prod-001.vault.azure.net/secrets/sql-order-connection-string

Reference figee a utiliser seulement si le cas est volontaire
https://kv-app-prod-001.vault.azure.net/secrets/sql-order-connection-string/<version>

Strategie de transition
Publier une nouvelle version
Valider que l'application relit la reference stable
Redemarrer ou recharger la configuration si necessaire
Surveiller les erreurs applicatives et les lectures Key Vault
Desactiver l'ancienne version apres validation

Le comportement de l’application doit être connu avant la rotation. Certaines applications lisent le secret au démarrage. D’autres le mettent en cache. D’autres encore interrogent Key Vault régulièrement. Le mode de rechargement détermine la fenêtre de risque et la façon de prouver que la nouvelle valeur est réellement consommée.

Préparer un runbook en deux temps

Une rotation fiable évite le changement instantané sans retour. Elle publie d’abord la nouvelle valeur, vérifie que le consommateur peut l’utiliser, puis retire l’ancienne valeur quand l’observation est suffisante. Pour un secret partagé avec un service externe, la coordination est encore plus importante : il faut parfois accepter deux valeurs pendant une période courte.

Avant rotation
Identifier les applications consommatrices
Verifier l'identite utilisee par chaque application
Verifier DNS prive et acces Key Vault
Confirmer le mode de reload des secrets

Pendant rotation
Creer une nouvelle version du secret
Deployer ou recharger l'application si necessaire
Tester le flux metier minimal
Surveiller erreurs 401, 403, 500 et timeouts

Apres rotation
Conserver l'ancienne version pendant la fenetre decidee
Desactiver l'ancienne version
Documenter la version active et l'heure de bascule
Verifier qu'aucune lecture ne cible l'ancienne version

Ce découpage rend la rotation observable. L’objectif n’est pas seulement de changer une valeur, mais de prouver que la nouvelle valeur est disponible, consommée et compatible avec le service cible.

Diagnostiquer les erreurs sans tout mélanger

Lors d’une rotation, plusieurs erreurs se ressemblent côté application. Une erreur d’authentification vers le service cible n’a pas la même cause qu’un refus d’accès Key Vault. Il faut donc vérifier d’abord si l’application atteint le coffre, puis si elle peut lire le secret, puis si la valeur lue fonctionne auprès du service cible.

VAULT_NAME=kv-app-prod-001
SECRET_NAME=sql-order-connection-string

az keyvault secret show --vault-name $VAULT_NAME --name $SECRET_NAME --query '{name:name,enabled:attributes.enabled,created:attributes.created,updated:attributes.updated}' -o json

az keyvault secret list-versions --vault-name $VAULT_NAME --name $SECRET_NAME --query '[].{id:id,enabled:attributes.enabled,updated:attributes.updated}' -o table

Ces commandes valident l’état du secret, mais elles ne prouvent pas que l’application possède les mêmes droits ni qu’elle utilise la même route réseau. Pour cela, il faut corréler les logs de l’application, les journaux Key Vault et, si nécessaire, un test exécuté depuis le même environnement que le workload.

Surveiller les lectures et les refus

Les journaux Key Vault sont utiles pendant une rotation. Ils permettent de voir si l’application lit encore l’ancienne version, si une identité reçoit des refus, ou si un pic d’erreurs apparaît au moment du changement. L’important est de journaliser ce qui aide à décider, pas de produire un volume illisible.

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName in ("SecretGet", "SecretList")
| where TimeGenerated > ago(24h)
| project TimeGenerated, Resource, OperationName, ResultType, ResultSignature, identity_claim_appid_g, CallerIPAddress, requestUri_s
| order by TimeGenerated desc

Pendant la fenêtre de rotation, cette requête aide à répondre à trois questions simples : quelle identité lit le secret, avec quel résultat, et quelle version semble ciblée. Si le champ d’URI complet n’est pas conservé ou si la journalisation est filtrée, il faut adapter l’observation, mais le principe reste le même.

Retirer les secrets quand une identité suffit

La meilleure rotation est parfois celle qu’on n’a plus à faire. Quand un service Azure accepte une identité managée ou une authentification fédérée, il vaut mieux éviter de stocker un secret applicatif. Key Vault reste utile pour les certificats, certains secrets externes ou les cas où l’intégration ne supporte pas encore l’identité, mais il ne doit pas devenir le réflexe pour tout.

Utiliser une identite managee si
Le service cible la supporte
Le workload tourne dans un environnement compatible
Les droits peuvent etre exprimes proprement en RBAC

Utiliser Key Vault pour un secret si
Le service externe exige une cle ou un mot de passe
Un certificat doit etre stocke et distribue
Une phase de migration necessite encore une valeur secrete

Reevaluer regulierement
Secret encore necessaire ?
Consommateurs toujours actifs ?
Anciennes versions desactivees ?
Acces toujours justifies ?

Cette revue évite l’accumulation de secrets historiques. Un coffre privé mais rempli de valeurs inutilisées reste une charge d’exploitation.

Conclusion

Azure Key Vault en réseau privé apporte une base solide, à condition de traiter la rotation comme un processus d’exploitation complet. Le Private Endpoint sécurise le chemin. Les identités managées limitent les accès. Le DNS privé rend le chemin prévisible. Les versions de secret permettent une transition contrôlée. Les journaux donnent la preuve que la nouvelle valeur est consommée.

La discipline consiste à ne jamais réduire la rotation à une commande set secret. Il faut savoir qui consomme quoi, par quel chemin, avec quelle identité, à quel moment l’application recharge la valeur et comment l’ancienne version sera retirée. C’est ce qui transforme Key Vault d’un simple coffre en composant fiable de production.