Azure — Découverte
Connectez votre locataire Azure pour que SecureAI inventorie vos ressources d’IA dans Azure et chaque identité non humaine (NHI) dans Microsoft Entra ID, avec les rôles et les autorisations de chacune.Cette connexion lit uniquement et n’envoie jamais de prompt. Pour faire passer le trafic LLM de SecureAI par votre propre ressource Foundry, consultez Azure AI Foundry — Inference in your account. Ce sont deux connexions indépendantes, avec des principaux de service et des autorisations différents ; vous pouvez utiliser les deux sur le même abonnement.
Ce que SecureAI importe
Pour chaque abonnement que le principal de service peut lire :- Ressources d’IA : chaque compte Azure AI Services, Azure OpenAI et autre Cognitive Services (Content Safety, Speech, Language, Document Intelligence…), avec sa région et son état.
- Déploiements de modèles d’Azure OpenAI et de Foundry, avec leur capacité et l’utilisation des 30 derniers jours (requêtes, jetons d’entrée et de sortie, depuis Azure Monitor).
- Projets et agents Foundry : les agents de Foundry Agent Service et les assistants classiques de chaque projet, avec le modèle utilisé par chacun. Également les hubs et les projets basés sur un hub (Azure Machine Learning), avec leurs points de terminaison en ligne et serverless.
- Azure AI Search et Azure Bot Service.
- Coûts du mois en cours, par service (Cost Management).
- Activité : événements de gestion de Cognitive Services et de Machine Learning des 30 derniers jours (journal d’activité).
- NHI, listées dans l’Inventaire des NHI :
- Principaux de service des applications d’entreprise.
- Identités d’agent de Microsoft Entra, celles que Foundry crée pour chaque agent (classées comme agent).
- Identités managées, affectées par le système et par l’utilisateur.
- Secrets client et certificats des inscriptions d’applications, avec leur date d’expiration.
- Informations d’identification fédérées (fédération d’identité de charge de travail). Par exemple, une relation d’approbation OIDC avec GitHub Actions permet à ce dépôt d’obtenir des jetons au nom de l’application, sans aucun secret.
- La dernière connexion de chaque application, lorsque votre locataire expose ce rapport.
- Autorisations de chaque identité : ses rôles Azure RBAC à tout niveau de l’abonnement (abonnement, groupe de ressources ou ressource), ses autorisations d’application Microsoft Graph et ses rôles d’annuaire Entra.
- Attributions de rôles RBAC : chaque rôle par son nom, avec les utilisateurs, groupes et applications qui le détiennent.
- l’un des rôles Owner, Contributor, User Access Administrator ou Role Based Access Control Administrator ;
- une autorisation d’écriture Graph, par exemple
Application.ReadWrite.All,Directory.ReadWrite.All,Mail.SendouFiles.ReadWrite.All; - un rôle d’administrateur d’annuaire, par exemple Global Administrator ou Application Administrator.
Prérequis
Une inscription d’application Microsoft Entra ID (principal de service) avec un secret client et ces autorisations :
Les autorisations Graph nécessitent le consentement administrateur. Pour lire tous vos abonnements, attribuez Reader sur chacun, ou sur un groupe d’administration qui les contient.
Les agents Foundry se trouvent dans le plan de données du projet, pas dans Azure Resource Manager : Reader ne suffit pas pour les voir. Sans Cognitive Services Data Reader (ou Foundry User) sur la ressource Foundry, la synchronisation fonctionne quand même, mais la liste des agents reste vide et SecureAI le signale comme une lacune. Cognitive Services Data Reader est le rôle le plus restreint qui le permet : lecture seule du plan de données.
Étape 1. Créer le principal de service
Avec Azure CLI
Depuis Azure Cloud Shell ou la CLIaz. Remplacez SUB_ID par votre abonnement et, si vous utilisez Foundry, MY_RESOURCE et MY_RG par votre ressource et votre groupe de ressources :
1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9=Role (Application.ReadWrite.All) à l’étape 3 et accordez de nouveau le consentement.
Avec le portail Azure
- Dans le portail Azure, accédez à Microsoft Entra ID → Inscriptions d’applications → Nouvelle inscription, donnez-lui un nom (par exemple
SecureAI Discovery) et inscrivez-la. - Dans Vue d’ensemble, copiez l’ID de l’annuaire (locataire) et l’ID de l’application (client).
- Dans Certificats et secrets → Secrets client → Nouveau secret client, créez-en un et copiez sa Valeur (elle n’est affichée qu’une seule fois).
- Dans Autorisations d’API → Ajouter une autorisation → Microsoft Graph → Autorisations de l’application, ajoutez
Application.Read.All,Directory.Read.AlletAuditLog.Read.All(etApplication.ReadWrite.Allsi vous voulez révoquer depuis SecureAI). Cliquez ensuite sur Accorder le consentement administrateur. - Dans Abonnements → votre abonnement → Contrôle d’accès (IAM) → Ajouter une attribution de rôle, attribuez Reader et Cost Management Reader à l’application.
- Dans votre ressource Foundry → Contrôle d’accès (IAM), attribuez Cognitive Services Data Reader à l’application.
L’application des rôles Azure peut prendre jusqu’à 5 minutes, et celle du consentement Graph quelques minutes de plus. Si la première synchronisation signale des lacunes pour des autorisations que vous venez d’accorder, attendez et synchronisez de nouveau.
Étape 2. Connecter Azure dans SecureAI
- Accédez à Admin → Intégrations, filtrez par Cloud et, sur la carte Azure — Découverte, cliquez sur Connecter l’Intégration.
-
Remplissez les champs :
- Cliquez sur Connecter. Avant d’enregistrer, SecureAI teste les identifiants par une vraie lecture : si le secret est incorrect ou si le principal ne peut pas lire l’abonnement, rien n’est stocké et le message indique ce qui manque. Si la connexion aboutit mais qu’une autorisation Graph manque, l’avis nomme cette autorisation.
- Synchronisez avec le bouton d’actualisation de la carte. Une synchronisation Azure peut prendre plusieurs minutes (elle parcourt Azure Resource Manager, Microsoft Graph, Azure Monitor et Cost Management). Ensuite, SecureAI se synchronise automatiquement toutes les 6 heures.
Étape 3. Vérifier
- Cloud Sensors liste les déploiements, agents et services découverts. Cliquez sur la carte Azure pour ouvrir ses Insights :
- Usage & Costs : utilisation et coûts ;
- Models & Deployments : déploiements et agents ;
- Identity & Access : identités avec leurs rôles et l’indicateur Privileged ; secrets, certificats et informations d’identification fédérées ; rôles RBAC avec leurs membres ;
- Audit & Logs : l’activité.
- L’Inventaire des NHI affiche les principaux de service, identités d’agent, identités managées, secrets, certificats et informations d’identification fédérées, avec leurs autorisations et leur caractère privilégié ou non.
Lacunes de couverture
Rien de ce que SecureAI n’a pas pu lire n’est ignoré en silence : lors de la connexion ou de la synchronisation, l’avis nomme l’autorisation manquante.
Une lecture partielle (autorisation manquante, page non renvoyée par Azure, limitation de débit) ne retire jamais d’agents ni ne supprime d’identités de l’inventaire : SecureAI ne considère un élément comme supprimé que lorsque la liste où il apparaîtrait a été retournée en entier. Sans attributions de rôles, les autorisations d’une identité restent inconnues, jamais « aucune ».
Révocation
Depuis l’Inventaire des NHI (cadenas), avecApplication.ReadWrite.All :
Garde-fous :
- SecureAI ne propose pas de révoquer le principal de service avec lequel il se connecte, ni ses secrets, car cela interromprait la découverte. Renouvelez-les dans Entra ID.
- Les identités managées affectées par le système ne sont pas révoquées depuis SecureAI : leur cycle de vie est celui de la ressource Azure.
- Les informations d’identification fédérées que Foundry conserve sur le blueprint de l’identité d’un agent ne sont pas non plus révoquées depuis SecureAI : les supprimer arrête l’agent.
- Les politiques NHI automatiques (révocation par ancienneté ou inutilisation) ne s’appliquent pas encore à Azure : la révocation est manuelle.

