Sécurité dans la recherche d'IA d'Azure

Azure AI Search fournit des contrôles de sécurité complets sur l’accès réseau, l’accès aux données et la protection des données pour répondre aux exigences de l’entreprise. En tant qu’architecte de solution, vous devez comprendre trois domaines de sécurité clés :

• Modèles de trafic réseau et sécurité réseau : trafic entrant, sortant et interne.
• Mécanismes de contrôle d’accès : clés API ou ID Microsoft Entra avec des rôles.
• Résidence et protection des données : chiffrement en transit, en cours d’utilisation avec l’informatique confidentielle facultative et au repos avec un double chiffrement facultatif.

Un service de recherche prend en charge plusieurs topologies de sécurité réseau, des restrictions de pare-feu IP pour la protection de base aux points de terminaison privés pour une isolation réseau complète. Si vous le souhaitez, utilisez un périmètre de sécurité réseau pour créer une limite logique autour de vos ressources PaaS Azure. Pour les scénarios d’entreprise nécessitant des autorisations granulaires, vous pouvez implémenter des contrôles d’accès au niveau du document. Toutes les fonctionnalités de sécurité s’intègrent à l’infrastructure de conformité d’Azure et prennent en charge les modèles d’entreprise courants tels que l’authentification multilocataire et l’authentification interservices à l’aide d’identités managées.

Cet article détaille les options d’implémentation de chaque couche de sécurité pour vous aider à concevoir des architectures de sécurité appropriées pour les environnements de développement et de production.

Modèles de trafic réseau

Un service Recherche d’IA Azure peut être hébergé dans le cloud public Azure, dans un cloud privé Azure ou dans un cloud souverain (par exemple, Azure Government). Par défaut, pour tous les hôtes cloud, le service de recherche est généralement accessible par les applications clientes via des connexions réseau publiques. Bien que ce modèle soit prédominant, il ne s’agit pas du seul modèle de trafic auquel vous devez faire attention. Vous devez bien comprendre tous les points d’entrée ainsi que le trafic sortant pour sécuriser vos environnements de développement et de production.

La recherche Azure AI a trois modèles de trafic réseau de base :

• Demandes entrantes effectuées par un utilisateur ou un client au service de recherche (modèle prédominant)
• Demandes sortantes émises par le service de recherche pour d’autres services sur Azure et ailleurs
• Demandes de service à service internes sur le réseau principal Microsoft sécurisé

Trafic entrant

Les demandes entrantes ciblant un point de terminaison de service de recherche sont les suivantes :

• Créer, lire, mettre à jour ou supprimer des index et d’autres objets sur le service de recherche
• Charger un index avec des documents de recherche
• Interroger un index
• Exécuter des tâches d'indexation ou de compétences

Les API REST décrivent la plage complète de requêtes entrantes gérées par un service de recherche.

Au minimum, toutes les demandes entrantes doivent être authentifiées à l’aide de l’une des options suivantes :

• Authentification basée sur la clé (par défaut). Les demandes entrantes fournissent une clé API valide.
• Contrôle d'accès basé sur les rôles. L’autorisation est effectuée via les identités Microsoft Entra et les attributions de rôles sur votre service de recherche.

En outre, vous pouvez ajouter des fonctionnalités de sécurité réseau pour restreindre davantage l’accès au point de terminaison. Vous pouvez créer des règles de trafic entrant dans un pare-feu IP ou des points de terminaison privés qui protègent entièrement votre service de recherche de l’Internet public.

Trafic sortant

Les requêtes sortantes peuvent être sécurisées et gérées par vous. Les requêtes sortantes proviennent d’un service de recherche vers d’autres applications. Ces requêtes sont généralement effectuées par des indexeurs pour l’indexation textuelle et modale, l’enrichissement par IA basé sur des compétences personnalisées et les vectorisations au moment de la requête. Les demandes sortantes incluent des opérations de lecture et d’écriture.

La liste suivante est une énumération complète des demandes sortantes pour lesquelles vous pouvez configurer des connexions sécurisées. Un service de recherche effectue des requêtes en son propre nom et au nom d’un indexeur ou d’une compétence personnalisée.

Les connexions sortantes peuvent généralement être établies à l'aide de la chaîne de connexion d'accès complet d'une ressource qui inclut une clé ou une connexion à la base de données, ou une identité gérée si vous utilisez Microsoft Entra ID et un accès basé sur les rôles.

Pour atteindre les ressources Azure derrière un pare-feu, créez des règles de trafic entrant sur d’autres ressources Azure qui acceptent les demandes de service de recherche.

Pour accéder aux ressources protégées par Azure Private Link, créez une liaison privée partagée qu’un indexeur utilise pour établir sa connexion.

Exception pour les services de recherche et de stockage dans la même région

Si Stockage Azure et Recherche Azure AI se trouvent dans la même région, le trafic réseau est routé via une adresse IP privée sur le réseau principal de Microsoft. Étant donné que des adresses IP privées sont utilisées, vous ne pouvez pas configurer de pare-feu IP ou de point de terminaison privé pour la sécurité réseau.

Configurez les connexions de même région à l’aide de l’une des approches suivantes :

• Exception de service approuvé
• Règles d’instance de ressource

Trafic interne

Les demandes internes sont sécurisées et gérées par Microsoft. Vous ne pouvez pas configurer ou contrôler ces connexions. Si vous verrouillez l’accès réseau, aucune action n’est nécessaire, car le trafic interne n’est pas configurable par le client.

Le trafic interne est constitué :

• Les appels de service à service pour des tâches comme l’authentification et l’autorisation à travers Microsoft Entra ID, la journalisation des diagnostics envoyée à Azure Monitor et les connexions de point de terminaison privé qui utilisent Azure Private Link.
• Demandes de traitement des compétences intégrées, avec des requêtes de même région dirigées vers une ressource Microsoft Foundry hébergée en interne utilisée exclusivement pour le traitement des compétences intégrées par Azure AI Search.
• Requêtes adressées aux différents modèles qui prennent en charge le classement sémantique.

Sécurité réseau

La sécurité réseau protège les ressources contre l’accès non autorisé ou les attaques en appliquant des contrôles au trafic réseau. La recherche Azure AI prend en charge des fonctionnalités réseau qui peuvent constituer votre première ligne de défense contre l’accès non autorisé.

Connexion entrante via des pare-feu IP

Un service de recherche est provisionné avec un point de terminaison public qui autorise l’accès en utilisant une adresse IP publique. Pour limiter le trafic qui transite par le point de terminaison public, créez une règle de pare-feu entrante qui accepte les demandes d’une adresse IP spécifique ou d’une plage d’adresses IP. Toutes les connexions clientes doivent être effectuées via une adresse IP autorisée, sans quoi la connexion est refusée.

Vous pouvez utiliser le portail Azure pour configurer l’accès du pare-feu.

Vous pouvez aussi utiliser les API REST de gestion. À compter de la version 13-03-2020 de l’API avec le paramètre IpRule, vous pouvez limiter l’accès à votre service en identifiant les adresses IP, individuellement ou dans une plage, qui doivent pouvoir accéder à votre service de recherche.

Connexion entrante à un point de terminaison privé (isolement réseau, aucun trafic Internet)

Pour une sécurité plus rigoureuse, vous pouvez établir un point de terminaison privé pour que la recherche Azure AI autorise un client sur un réseau virtuel à accéder de façon sécurisée aux données d’un index de recherche sur une liaison privée.

Le points de terminaison privé utilise une adresse IP de l’espace d’adressage du réseau virtuel pour les connexions à votre service de recherche. Le trafic entre le client et le service Search traverse le réseau virtuel et une liaison privée sur le réseau principal de Microsoft, ce qui élimine l’exposition sur l’Internet public. Un réseau virtuel permet une communication sécurisée entre ressources, avec votre réseau local, ainsi qu’avec Internet.

Bien que cette solution soit la plus sécurisée, l’utilisation de services supplémentaires représente un coût supplémentaire : veillez donc à avoir une compréhension claire des avantages avant de la mettre en place. Pour plus d’informations sur les coûts, consultez la page Tarification. Pour plus d’informations sur la façon dont ces composants fonctionnent ensemble, regardez cette vidéo. L’option du point de terminaison privé est présentée à partir de 5:48 dans la vidéo. Pour obtenir des instructions sur la configuration du point de terminaison, consultez Créer un point de terminaison privé pour la recherche Azure AI.

Périmètre de sécurité réseau

Un périmètre de sécurité réseau est une limite de réseau logique autour de vos ressources PaaS (platform-as-a-service) déployées en dehors d’un réseau virtuel. Il établit un périmètre pour contrôler l’accès au réseau public aux ressources telles qu’Azure AI Search, Stockage Azure et Azure OpenAI. Vous pouvez accorder des exceptions via des règles d’accès explicites pour le trafic entrant et sortant. Cette approche permet d’empêcher l’exfiltration des données tout en conservant la connectivité nécessaire pour vos applications.

Les connexions clientes entrantes et les connexions de service à service se produisent dans la limite, ce qui simplifie et renforce vos défenses contre l’accès non autorisé. Il est courant dans les solutions Azure AI Search d’utiliser plusieurs ressources Azure. Les ressources suivantes peuvent toutes être jointes à un périmètre de sécurité réseau existant :

• Recherche d’IA Azure
• Azure OpenAI
• Stockage Azure
• Azure Monitor.

Pour obtenir la liste complète des services éligibles, consultez les ressources de liaison privée intégrées.

Authentication

Une fois qu’une requête est acceptée dans le service de recherche, elle doit toujours se soumettre à l’authentification et à une autorisation qui détermine si la requête est autorisée. La recherche Azure AI prend en charge deux approches :

• L’authentification Microsoft Entra établit l’appelant (et non la requête) en tant qu’identité authentifiée. Une attribution de rôle Azure détermine l’autorisation.

• L’authentification basée sur une clé s’effectue sur la demande (et non sur l’utilisateur ou l’application qui appelle) par le biais d’une clé API, où la clé est une chaîne composée de chiffres et de lettres générés de manière aléatoire qui prouvent que la demande émane d’une source digne de confiance. Ces clés sont nécessaires pour chaque requête. La soumission d’une clé valide est considérée comme la preuve que la requête provient d’une entité approuvée.

  Le recours à une authentification basée sur des clés API signifie que vous devez disposer d’un plan pour la régénération de la clé d’administration à intervalles réguliers, conformément aux meilleures pratiques de sécurité Azure. Il y a, au maximum, deux clés d’administration par service de recherche. Pour plus d’informations sur la sécurisation et la gestion des clés API, consultez Créer et gérer des clés API.

L’authentification par clé est la valeur par défaut pour les opérations de plan de données (création et utilisation d’objets sur le service de recherche). Vous pouvez utiliser les deux méthodes d’authentification ou désactiver une approche que vous ne souhaitez pas disponible sur votre service de recherche.

Authorization

La recherche Azure AI fournit des modèles d’autorisation pour le management des services et du contenu.

Accès privilégié

Sur un nouveau service de recherche, les attributions de rôles existantes au niveau de l’abonnement sont héritées par le service de recherche, et seuls les propriétaires et les administrateurs d’accès utilisateur peuvent accorder l’accès.

Les opérations de plan de contrôle (service ou création et gestion des ressources) sont exclusivement autorisées par le biais d’attributions de rôles, sans possibilité d’utiliser l’authentification basée sur des clés pour l’administration de service.

Les opérations du plan de contrôle incluent la création, la configuration ou la suppression du service et la gestion de la sécurité. Ainsi, les attributions de rôles Azure déterminent qui peut effectuer ces tâches, qu’elles utilisent le portail, PowerShell ou les API REST de gestion.

Trois rôles de base (Propriétaire, Contributeur, Lecteur) s’appliquent à l’administration du service de recherche.

Autoriser l’accès au contenu

Les opérations de plan de données font référence aux objets créés et utilisés sur un service de recherche.

• Pour l’autorisation basée sur les rôles, utilisez les attributions de rôles Azure pour établir un accès en lecture-écriture aux opérations.

• Pour l’autorisation basée sur des clés, une clé API et un point de terminaison qualifié déterminent l’accès. Un point de terminaison peut être le service proprement dit, la collection d’index, un index spécifique, une collection de documents ou un document spécifique. En cas de chaînage, le point de terminaison, l’opération (par exemple, une requête de création) et le type de clé (administrateur ou requête) autorisent l’accès au contenu et aux opérations.

Restriction de l’accès aux index

Si vous utilisez des rôles Azure, vous pouvez définir des autorisations sur des index individuels, à condition de le faire par programmation.

Toute personne disposant d’une clé d’administration pour votre service peut lire, modifier ou supprimer un index de ce service. En ce qui concerne la protection contre la suppression accidentelle ou malveillante des index, votre contrôle de code source en interne pour les ressources de code est la solution appropriée pour annuler des suppressions ou des modifications d’index indésirables. La recherche Azure AI dispose d’un système de basculement dans le cluster pour garantir sa disponibilité, mais il ne stocke pas et n’exécute pas le code propriétaire que vous avez utilisé pour créer ou charger des index.

Pour les solutions d’architecture mutualisée qui nécessitent des limites de sécurité au niveau des index, il est courant de gérer l’isolation de l'index au niveau intermédiaire dans le code de votre application. Pour plus d’informations sur les cas d’usage d’architecture mutualisée, consultez Modèles de conception pour les applications SaaS mutualisées et la recherche Azure AI.

Restriction de l’accès aux documents

Les autorisations utilisateur au niveau du document, également appelée sécurité au niveau des lignes, sont disponibles en tant que fonctionnalité d’aperçu et dépendent de la source de données. Si le contenu provient d’Azure Data Lake Storage (ADLS) Gen2 ou d’objets blob Azure, les métadonnées d’autorisation utilisateur provenant du stockage Azure sont conservées dans les indexeurs générés par l’indexeur et appliquées au moment de la requête afin que seul le contenu autorisé soit inclus dans les résultats de recherche.

Pour d’autres sources de données, vous pouvez envoyer (push) une charge utile de document qui inclut des métadonnées d’autorisation d’utilisateur ou de groupe, et ces autorisations sont conservées dans le contenu indexé et appliquées au moment de la requête. Cette fonctionnalité est également en préversion.

Si vous ne pouvez pas utiliser les fonctionnalités d’aperçu et que vous avez besoin d’un accès autorisé sur le contenu dans les résultats de recherche, il existe une technique permettant d’appliquer des filtres qui incluent ou excluent des documents en fonction de l’identité de l’utilisateur. Cette solution de contournement ajoute un champ de chaîne dans la source de données qui représente un groupe ou une identité d’utilisateur, que vous pouvez rendre filtrable dans votre index. Pour plus d’informations sur ce modèle, consultez Filtrage de sécurité basée sur les filtres d’identité. Pour plus d’informations sur l’accès aux documents, consultez contrôle d’accès au niveau du document.

Résidence des données

Lorsque vous configurez un service de recherche, vous choisissez une région qui détermine où les données client sont stockées et traitées. Chaque région se trouve dans une zone géographique (Geo) qui comprend souvent plusieurs régions (par exemple, Suisse est une Geo qui contient Suisse Nord et Suisse Ouest). Recherche Azure AI peut répliquer vos données vers une autre région dans la même Geo à des fins de durabilité et de haute disponibilité. Le service ne stockera pas et ne traitera pas de données client en dehors de votre Geo spécifiée, sauf si vous configurez une fonctionnalité qui a une dépendance sur une autre ressource Azure et que cette ressource est approvisionnée dans une autre région.

Actuellement, la seule ressource externe dans laquelle un service de recherche écrit est Stockage Azure. Le compte de stockage est celui que vous fournissez. Il peut se trouver dans n’importe quelle région. Un service de recherche écrit dans Stockage Azure si vous utilisez l’une des fonctionnalités suivantes :

• cache d’enrichissement
• session de débogage
• base de connaissances

Pour plus d’informations sur la résidence des données, consultez Résidence des données dans Azure.

Exceptions aux engagements de résidence des données

Les noms d’objet apparaissent dans les journaux de télémétrie utilisés par Microsoft pour assurer la prise en charge du service. Les noms d’objet sont stockés et traités en dehors de votre région ou emplacement sélectionnés. Les noms d’objet incluent les noms des index et des champs d’index, des alias, des indexeurs, des sources de données, des ensembles de compétences, des mappages de synonymes, des ressources, des conteneurs et des magasin de coffre de clés. Les clients ne doivent pas saisir de données sensibles dans les champs de nom ni créer d’applications conçues pour stocker des données sensibles dans ces champs.

Les journaux de télémétrie sont conservés pendant un an et demi. Pendant cette période, Microsoft peut accéder aux noms d’objet et les référencer dans les conditions suivantes :

• Diagnostiquer un problème, améliorer une fonctionnalité ou corriger un bogue. Dans ce scénario, l’accès aux données est interne uniquement (pas d’accès tiers).

• Pendant le support, ces informations peuvent être utilisées pour résoudre rapidement les problèmes et faire remonter les informations à l’équipe produit si nécessaire

Protection de données

Au niveau de la couche de stockage, le chiffrement des données est intégré pour l’ensemble du contenu géré par le service enregistré sur le disque, dont les index, les cartes de synonymes et les définitions d’indexeurs, de sources de données et d’ensembles de compétences. Le chiffrement géré par le service s’applique à la fois au stockage de données à long terme et au stockage de données temporaire.

Si vous le souhaitez, vous pouvez ajouter des clés gérées par le client (CMK) pour un chiffrement supplémentaire du contenu indexé, afin d’obtenir un double chiffrement des données au repos. Pour les services créés après le 1er août 2020, le chiffrement avec clé gérée par le client s’étend aux données à court terme sur les disques temporaires.

Données en transit

Pour les connexions de service de recherche sur l’Internet public, Recherche Azure AI écoute sur le port HTTPS 443.

Recherche Azure AI prend en charge TLS 1.2 et 1.3 pour le chiffrement de canal client à service :

• TLS 1.3 est la valeur par défaut sur les systèmes d’exploitation client et les versions de .NET les plus récents.
• TLS 1.2 est la valeur par défaut sur les systèmes plus anciens, mais vous pouvez définir explicitement TLS 1.3 sur une requête cliente.

Les versions antérieures de TLS (1.0 ou 1.1) ne sont pas prises en charge.

Pour plus d’informations, consultez Prise en charge de TLS dans .NET Framework.

Données en cours d’utilisation

Par défaut, Azure AI Search déploie votre service de recherche sur l’infrastructure Azure standard. Cette infrastructure chiffre les données au repos et en transit, mais elle ne protège pas les données pendant qu’elles sont traitées activement en mémoire.

Si vous le souhaitez, vous pouvez utiliser le portail Azure ou les services - Créer ou mettre à jour (API REST) pour configurer l’informatique confidentielle lors de la création du service. L’informatique confidentielle protège les données en cours d’utilisation contre l’accès non autorisé, notamment à partir de Microsoft, via l’attestation matérielle et le chiffrement. Pour plus d’informations, consultez les cas d’usage de l’informatique confidentielle.

Le tableau suivant compare les deux types de calcul.

¹ Lorsque vous activez ce type de calcul, les indexeurs peuvent uniquement s’exécuter dans l’environnement d’exécution privée, ce qui signifie qu’ils s’exécutent à partir des clusters de recherche hébergés sur l’informatique confidentielle.

Données au repos

Pour les données gérées en interne par le service de recherche, le tableau suivant décrit les modèles de chiffrement de données. Certaines fonctionnalités, telles que la base de connaissances, l’enrichissement incrémentiel et l’indexation basée sur un indexeur, lisent ou écrivent dans des structures de données dans d’autres services Azure. Les services qui dépendent du Stockage Azure peuvent utiliser les fonctionnalités de chiffrement de cette technologie.

Lorsque vous introduisez le chiffrement avec clé gérée par le client, vous chiffrez le contenu deux fois. Pour les objets et les champs indiqués dans la section précédente, le contenu est d’abord chiffré avec votre clé gérée par le client, puis avec la clé gérée par Microsoft. Le contenu est doublement chiffré sur les disques de données pour le stockage à long terme et sur les disques temporaires utilisés pour le stockage à court terme.

Clés gérées par le service

Le chiffrement géré par le service est une opération Microsoft interne qui utilise le chiffrement AES 256 bits. Il se produit automatiquement sur toutes les indexations, y compris sur les mises à jour incrémentielles des index qui ne sont pas entièrement chiffrés (créés avant janvier 2018).

Le chiffrement géré par le service s’applique à tout le contenu sur le stockage à long et à court terme.

Clés gérées par le client (CMK)

Les clients utilisent CMK pour deux raisons : une protection supplémentaire et la possibilité de révoquer des clés, ce qui empêche l’accès au contenu.

Les clés gérées par le client nécessitent un autre service facturable, Azure Key Vault, qui peut se trouver dans une région différente, mais sous le même locataire Azure, qu’Azure AI Search.

La prise en charge des clés gérées par le client a été déployée en deux phases. Si vous avez créé votre service de recherche pendant la première phase, le chiffrement avec clé gérée par le client était limité au stockage à long terme et à des régions spécifiques. Les services créés dans la deuxième phase peuvent utiliser le chiffrement CMK dans n’importe quelle région. Dans le cadre du deuxième déploiement, le contenu est chiffré par clé gérée par le client sur le stockage à long terme et à court terme.

• Le premier lancement était le 1er août 2020 et comprenait les cinq régions suivantes. Les services de recherche créés dans les régions suivantes ont pris en charge la clé gérée par le client pour les disques de données, mais pas les disques temporaires :

  • Ouest des États-Unis 2
  • East US
  • États-Unis - partie centrale méridionale
  • Gouvernement américain - Virginie
  • Gouvernement des États-Unis – Arizona

• Le deuxième déploiement a eu lieu le 13 mai 2021 et a ajouté le chiffrement pour les disques temporaires et le chiffrement avec clé gérée par le client étendu à toutes les régions prises en charge.

  Si vous utilisez la clé CMK d’un service créé lors du premier déploiement et que vous souhaitez également le chiffrement par CMK sur les disques temporaires, vous devez créer un service de recherche dans la région de votre choix et redéployer votre contenu. Pour déterminer la date de création de votre service, consultez Vérifier la date de création ou de mise à niveau de votre service.

L’activation du chiffrement CMK a pour effet d’augmenter la taille de l’index et dégrader les performances des requêtes. Sur la base des observations effectuées à ce jour, vous pouvez vous attendre à une augmentation de 30 à 60 % des temps de requête, même si les performances réelles varient en fonction de la définition d’index et des types de requêtes. En raison de l’incidence négative sur les performances, nous vous recommandons de n’activer cette fonctionnalité que sur les index qui en ont réellement besoin. Pour plus d’informations, consultez Configurer des clés de chiffrement gérées par le client dans la recherche Azure AI.

Enregistrement et surveillance

La Recherche Azure AI ne journalisant pas les identités des utilisateurs, vous ne pouvez pas consulter de journaux pour obtenir des informations sur un utilisateur spécifique. En revanche, le service journalise des opérations de création/lecture/mise à jour/suppression susceptibles de permettre d’établir une corrélation avec d’autres journaux pour comprendre des actions spécifiques.

À l’aide d’alertes et de l’infrastructure de journalisation dans Azure, vous pouvez revenir sur des pics de volume de requête ou d’autres actions qui s’écartent des charges de travail attendues. Pour plus d’informations sur la configuration des journaux, consultez Collecter et analyser des données de journal et Surveiller les demandes de requête.

Gouvernance et conformité

La recherche Azure AI intervient dans des audits réguliers, et a été certifié par rapport à de nombreux standards mondiaux, régionaux et sectoriels pour le cloud public et Azure Government. Pour obtenir la liste complète, téléchargez le livre blanc Microsoft Azure Compliance Offerings depuis la page des rapports d’audit officiels.

Nous vous recommandons de consulter régulièrement les certifications et la documentation de conformité Azure AI Search pour garantir l’alignement avec vos exigences réglementaires.

Utiliser Azure Policy

Pour la conformité, vous pouvez utiliser Azure Policy pour implémenter les bonnes pratiques de haute sécurité du benchmark de sécurité du cloud Microsoft. Le benchmark de sécurité du cloud Microsoft est un ensemble de recommandations de sécurité, codifiées en contrôles de sécurité qui sont associés à des actions clés que vous devez prendre pour atténuer les menaces sur les services et les données. Il existe actuellement 12 contrôles de sécurité, dont Sécurité réseau, Journalisation et surveillance et Protection des données.

Azure Policy est une fonctionnalité intégrée à Azure qui vous permet de gérer la conformité de plusieurs normes, y compris celles du benchmark de sécurité du cloud Microsoft. Pour les critères de référence bien connus, Azure Policy fournit des définitions intégrées qui fournissent à la fois des critères et une réponse actionnable en cas de non-conformité.

Pour la recherche Azure AI, il existe actuellement une seule définition intégrée. Il s’agit de la journalisation des ressources. Vous pouvez attribuer une stratégie qui identifie tout service de recherche auquel il manque la journalisation des ressources, puis l’active. Pour plus d’informations, consultez Contrôles de conformité réglementaire d’Azure Policy pour la recherche Azure AI.

Utiliser des balises

Appliquez des balises de métadonnées pour catégoriser les services de recherche en fonction des exigences de confidentialité et de conformité des données. Cela facilite les contrôles de gouvernance et de sécurité appropriés. Pour plus d’informations, consultez Utiliser des balises pour organiser vos ressources Azure et Conseils généraux – Organiser les ressources Azure à l’aide de balises.

Contenu connexe

• Concepts de base de la sécurité Azure
• Sécurité Azure
• Microsoft Defender pour le Cloud

Nous vous recommandons également la vidéo suivante sur les fonctionnalités de sécurité. Il a plusieurs années et ne couvre pas les fonctionnalités plus récentes, mais il couvre ces fonctionnalités : CMK, pare-feu IP et liaison privée. Si vous utilisez ces fonctionnalités, vous pouvez trouver cette vidéo utile.