Sécuriser l'IA de Microsoft

Isolation réseau et Private Endpoints

Pour sécuriser un service d’IA dans Azure, l’isoler du réseau public est la première étape cruciale. En effet, par défaut, une ressource PaaS est exposée sur Internet via une adresse IP publique et un nom de domaine public, ce qui induit des risques d’accès non autorisé.

La solution recommandée est de la déployer en désactivant l’accès public et en utilisant des points de terminaison privés (Private Endpoints) pour y accéder.

1. Accès depuis le réseau public

La première étape consiste donc à désactiver l’accès depuis Internet à une ressource, ce qui ne supprimera pas son adresse IP publique, mais refusera simplement toute connexion à celle-ci via le pare-feu de la ressource. Imaginez qu’un compte de stockage contienne les données critiques à indexer pour faire du RAG, cette ressource n’a aucune raison d’être accessible depuis Internet.

Azure fournit le paramètre Public network access dans la section Mise en réseau d’une ressource :

 Depuis le portail Azure, créez ou sélectionnez un compte de stockage existant, puis dans le menu de gauche, développez Sécurité + réseau et cliquez sur Mise en réseau.

 Depuis l’onglet Accès public, dans la section Public network access, cliquez sur le bouton Manage. Sélectionnez la case Disable puis cliquez sur le bouton Save.

La ressource n’étant plus disponible depuis Internet, il est nécessaire qu’elle soit a minima accessible via une adresse IP privée. Problème, un service PaaS n’a, dans la plupart des cas, pas d’adresse IP privée dans Azure, au contraire d’un service IaaS, comme une machine virtuelle. C’est ici qu’un point de terminaison privé (ou private endpoint) va être utile.

Gestion des accès et identités

Sécuriser l’IA passe par un contrôle strict des accès. Microsoft préconise d’appliquer les mêmes standards d’identité que pour toute ressource critique : authentification Entra ID, rôles RBAC et identités gérées. Microsoft Foundry, tout comme les services IA sous-jacents, s’intègrent nativement à Microsoft Entra ID et au modèle d’accès conditionnel. Sur Azure, l’authentification des appels aux services Azure AI se fait via l’Entra ID. En fait, Foundry n’accepte pas de méthodes d’authentification locales (clés d’API, token non-AAD). Cette authentification unifiée est activée par défaut et ne nécessite pas de configuration additionnelle. Concrètement, chaque application ou utilisateur qui communique avec l’IA doit présenter un jeton OAuth 2.0 valide émis par l’Entra ID, avec les droits appropriés. Cela garantit que l’identité de l’appelant est vérifiée, que l’appel est traçable et permet d’appliquer les stratégies conditionnelles d’Entra ID (par exemple exiger une authentification forte MFA ou un appareil conforme au standard de l’entreprise, avant d’autoriser l’accès au service d’IA).

Exposition sécurisée des services d’IA

Lorsque vos services d’IA sont confinés dans un réseau privé, comment permettre à des applications externes de les consommer de façon sécurisée ? C’est un défi courant : par exemple, une application hébergée sur site ou dans un autre cloud doit appeler votre point de terminaison Azure OpenAI sécurisé via Private Endpoint. La solution recommandée par Microsoft est d’utiliser une architecture en couches avec Azure API Management (APIM) et éventuellement une passerelle applicative (Application Gateway avec pare-feu WAF).

Le schéma d’architecture ci-dessous montre une solution d’accès sécurisée à une API Azure OpenAI :

En déployant Azure API Management (APIM) en mode Internal VNet, on obtient une passerelle API privée qui réside dans le même VNet que le service Azure OpenAI. APIM peut ainsi appeler le point de terminaison privé de l’IA en restant dans le réseau interne. Depuis l’extérieur, au lieu d’appeler directement l’URL d’Azure OpenAI (qui n’est pas joignable publiquement), les clients vont appeler l’URL d’APIM (par exemple, https://monAPIM.azure-api.net/mon-endpoint), qui, elle, peut être exposée de manière contrôlée....

Audit et supervision continue

Pour toute solution d’IA en production, la surveillance proactive est indispensable. Microsoft propose plusieurs outils pour y parvenir :

Sécurité et gouvernance dans Microsoft 365 Copilot

Microsoft 365 Copilot, l’assistant IA intégré à la suite Office 365, mérite une attention particulière car il combine de facto des capacités IA avec l’accès aux données d’entreprise. Copilot hérite ainsi de toutes les protections de Microsoft 365 tout en s’intégrant nativement à l’Entra ID de votre organisation.

Son activation est pilotée par la licence utilisateur et les rôles administratifs habituels de Microsoft 365. Lorsqu’un utilisateur interagit avec Copilot, l’IA agit en son nom : elle obtient via Graph uniquement le contenu que cet utilisateur peut normalement voir ou éditer. Par exemple, si vous demandez « Copilot, résume-moi ce document », Copilot va récupérer le document via votre identité. S’il s’agit d’un fichier SharePoint auquel vous n’aviez pas accès, Copilot ne pourra pas l’obtenir.

Cela signifie que Copilot n’introduit pas de nouveaux droits : il ne fait que rendre plus facile l’accès aux informations auxquelles vous avez déjà accès (et uniquement celles-ci). Cette utilisation de l’identité et des permissions existantes garantit qu’aucune donnée n’est divulguée...