Un test runtime peut prouver qu’un endpoint rejette un appel anonyme. Il ne dira pas nécessairement que le compte de stockage autorise encore l’accès public, qu’un cluster AKS conserve ses comptes locaux ou qu’une base de données critique n’a pas de mécanisme de haute disponibilité. La décision de production a donc besoin de deux regards complémentaires : le comportement observé et la baseline du control plane Azure.
Commencer par un inventaire orienté risque
Un inventaire utile ne se limite pas au nombre de ressources. Il relie chaque ressource à un environnement, une exposition, une identité, un niveau de criticité et un responsable. Les signaux deviennent alors actionnables : application de production accessible publiquement, base utilisant encore une authentification locale, coffre sans protection de purge, ressource hors région autorisée ou composant sans diagnostic.
Couvrir les dépendances réelles du système IA
Une application ou un agent IA Azure dépend rarement du seul modèle. La baseline doit suivre la chaîne complète :
- App Service, Functions, machines virtuelles, AKS ou Azure Container Apps qui hébergent le code ;
- Azure OpenAI ou Foundry, Azure AI Search et les composants RAG ;
- bases de données, stockage, Key Vault et registre de conteneurs ;
- réseau, endpoints privés, pare-feu applicatifs, DNS et sauvegarde ;
- Log Analytics, Application Insights, paramètres de diagnostic et signaux de sécurité ;
- budgets, tags de propriété, exports de coûts et ressources orphelines.
Produire un score sans masquer la gravité
Un score facilite la comparaison avant/après, mais il ne doit pas noyer un écart critique dans une moyenne. Une exposition publique non attendue ou une identité excessivement privilégiée nécessite une lecture individuelle. Le score sert à piloter la progression ; la décision repose sur les preuves et sur les conditions explicites de fermeture.
Conserver l’état initial
Avant toute correction, le snapshot doit être conservé avec le périmètre, l’horodatage et les règles utilisées. Après approbation et changement, un nouveau scan produit le delta. Cette paire avant/après empêche de transformer la remédiation en simple affirmation et permet de distinguer une amélioration réelle d’un changement de règle.
Relier control plane et runtime
La baseline répond à « dans quel environnement le système fonctionne-t-il ? ». Les sondes runtime répondent à « comment se comporte-t-il réellement ? ». Une décision défendable associe les deux : inventaire, résultats de test, écarts, changements approuvés et revalidation.