bonnes pratiques relatives aux enclaves Azure

Cet article décrit les concepts clés et les meilleures pratiques pour Azure Enclave.

Azure Enclave accélère et simplifie le déploiement et la gestion des environnements cloud sécurisés, isolés et conformes. Ces environnements sont conçus pour prendre en charge les missions et les charges de travail les plus sensibles dans les environnements commerciaux et isolés du réseau.

La création et l’exécution de charges de travail dans Azure Enclave nécessitent la compréhension et l’implémentation de certains concepts clés, notamment :

Le groupe de produits Azure Enclave, les équipes d’ingénierie et les équipes de terrain ont développé les meilleures pratiques et articles conceptuels suivants. Les articles ont été créés pour aider les propriétaires et développeurs de la communauté et des enclaves à mieux comprendre les concepts importants et à implémenter les fonctionnalités appropriées.

Configuration Azure

Lisez ces étapes de configuration pour déterminer si ces étapes de configuration correspondent à vos cas d’utilisation de l’enclave Azure.

Configurer des groupes de ressources Network Watcher

Pour éviter d’éventuels problèmes liés à la création de journaux de flux réseau virtuels , assurez-vous de suivre les instructions de démarrage pour configurer NetworkWatcherRG l’accès.

Réseaux et modèles de conception organisationnelle pour Azure Enclave

Mutualisation

Conception réseau

Azure Enclave regroupe les fonctionnalités et la flexibilité de plusieurs produits de mise en réseau Azure dans une interface utilisateur simplifiée, notamment :

  • Azure Virtual WAN
  • Pare-feu Azure
  • Réseau virtuel Azure
  • Groupes de sécurité réseau

Azure Enclave effectue les recommandations globales suivantes :

  • Les communautés doivent être déployées lorsque vous avez des exigences de mise en réseau pour fournir un Pare-feu Azure, qui est la sécurité intelligente du pare-feu de Azure platform-as-a-service.
  • Les communautés doivent être déployées lorsque vous avez des exigences organisationnelles ou de sensibilité des données nécessitant de séparer un Virtual WAN en architecture hub-and-spoke d'un autre Virtual WAN en architecture hub-and-spoke.
  • Les communautés doivent être déployées lorsque vous avez des exigences de mise en réseau pour prendre en charge les systèmes couvrant plusieurs régions Azure, dans lesquelles chaque région nécessite son propre Pare-feu Azure. En savoir plus sur les cas d’utilisation de plusieurs hubs Pare-feu Azure.
  • Les communautés doivent être déployées lorsque vous avez des exigences réseau afin de prendre en charge un grand nombre de systèmes sur un réseau étendu distribué de type hub-and-spoke. En savoir plus sur Azure Virtual WAN.
  • Les enclaves doivent être déployées lorsque vous avez des exigences de mise en réseau pour déployer des charges de travail similaires dans le cadre du même réseau privé.
  • Les enclaves doivent être déployées lorsque vous avez des exigences de charge de travail qui nécessitent un réseau virtuel et qui se trouvent dans la même Virtual WAN qu’une communauté existante.

Considérations relatives à la conception du réseau communautaire

Vous devez suivre, dans la mesure du possible, la documentation relative aux meilleures pratiques de Azure service sous-jacentes lors de la planification de vos réseaux communautaires. Y compris les meilleures pratiques suivantes :

Considérations relatives à la conception du réseau d’enclaves

Vous devez suivre, dans la mesure du possible, la documentation relative aux meilleures pratiques de service Azure sous-jacentes lors de la planification de vos réseaux d’enclave. Y compris les meilleures pratiques suivantes :

En savoir plus sur les meilleures pratiques générales de mise en réseau Azure.

Déploiement de charge de travail

  • Les charges de travail sont liées à un groupe de ressources managé où les contributeurs d’enclaves peuvent déployer des ressources Azure.
  • Par défaut, toutes les charges de travail d’enclave Azure sont régies par le biais d’initiatives de Azure Policy intégrées
  • Les charges de travail associées à une communauté disposant d’une configuration de gouvernance personnalisée, utilisez cette configuration unique au lieu de la configuration de gouvernance des enclaves par défaut Azure.
  • Considérations relatives au nommage des ressources Azure

Compliance

Il vous incombe d‘assurer votre conformité à toutes les lois et réglementations applicables. Les informations fournies dans la documentation en ligne de Microsoft ne constituent pas des conseils légaux et vous devez consulter votre conseiller juridique pour toute question relative à la conformité réglementaire.

Pour plus d’informations, consultez Offres de conformité Azure.

Modèles de conception de sécurité pour Azure Enclave

Tenez compte de ces modèles de conception de sécurité lors de la conception de vos environnements Azure Enclave.

Limites de sécurité

Azure Enclave utilise une approche de défense en profondeur lorsqu’il s’agit de cybersécurité. Lorsque vous déployez une communauté et des enclaves, Azure Enclave établit plusieurs couches d’isolation réseau, de sécurité, de contrôles d’accès et de journalisation et de surveillance.

Responsabilités de sécurité partagées

En tant que service sur Azure, Azure Enclave est également engagée à respecter le modèle de responsabilité partagée dans le cloud. Pour Azure Enclave spécifiquement, les charges de travail sont votre responsabilité. La responsabilité partagée d’Azure s’applique à vos charges de travail si vous y avez déployé des services PaaS.

Vos communautés et enclaves représentent une responsabilité partagée. Les communautés et enclaves utilisent un modèle de responsabilité partagée où le fournisseur de ressources d’enclave Azure crée votre environnement réseau hub-and-spoke sécurisé et préconfiguré. Vous gérez cet environnement réseau en créant des points de terminaison d’enclave, des points de terminaison de communauté, des hubs de transit ou desconnexions d’enclave. Certaines versions préliminaires de Azure Enclave vous permettent également d’apporter manuellement des modifications au réseau via des contrôles sous-jacents fournis par Azure Virtual WAN, Réseau virtuel Azure et d’autres services de mise en réseau sous-jacents Azure.

La gouvernance des enclaves Azure est également une responsabilité partagée. Le fournisseur de ressources Azure enclave crée une liste sécurisée et préconfigurée d’initiatives de Azure Policy par déploiement de charge de travail. Toutefois, les communautés ont désormais la possibilité de personnaliser la communauté Azure Policy Initiatives, qui remplace la liste préconfigurée de la charge de travail. Malgré les exigences de stratégie, vous conservez la possibilité d’effectuer des exemptions manuelles à ces affectations Azure Policy Initiative en fonction de leurs exigences de conformité ou de gouvernance.

bonnes pratiques en matière de sécurité Azure

Azure Enclave recommande de suivre Microsoft Azure meilleures pratiques et modèles de sécurité pour le déploiement de ressources Azure et l’implémentation de charges de travail.

Vous devez suivre les bonnes pratiques de sécurité Azure : Cloud Adoption Framework pour organiser vos systèmes, votre infrastructure cloud, vos structures de personnel informatique et d’équipe, ainsi que les formations de sensibilisation à la cybersécurité de l’entreprise.

Exfiltration de données via le système de noms de domaine

L’exfiltration de données par le biais du système DNS (Domain Name System) représente un problème de sécurité important pour les organisations, car il utilise un protocole généralement autorisé par le biais de pare-feu et rarement surveillé pour une activité malveillante. Les attaquants peuvent exploiter des requêtes DNS pour extraire secrètement des données sensibles à partir de systèmes compromis en encodant des informations au sein des noms de domaine ou en utilisant des techniques de tunneling DNS. Cette méthode est insidieux, car le trafic DNS apparaît légitime et contourne souvent les outils de surveillance de sécurité traditionnels.

Dans les attaques d’exfiltration de données basées sur DNS, les acteurs malveillants encodent les données volées dans des requêtes DNS, souvent à l’aide de techniques telles que l’étiquetage de sous-domaine ou les requêtes d’enregistrement TXT. Par exemple, un attaquant peut décomposer les données sensibles en blocs et incorporer chaque segment en tant que sous-domaine dans les requêtes DNS aux domaines contrôlés par l’attaquant. Les données peuvent être extraites des journaux DNS sur le serveur DNS de l’attaquant. Cette approche permet l’exfiltration progressive des jeux de données volumineux tout en conservant un profil faible, car les requêtes DNS apparaissent comme des requêtes de résolution de noms normales.

Lutter contre l’exfiltration de données avec la stratégie de sécurité DNS d’Azure

Azure DNS stratégie de sécurité offre une protection complète contre les attaques d’exfiltration de données basées sur DNS en offrant un contrôle granulaire sur le trafic DNS dans Azure réseaux virtuels. Ce service permet aux organisations d’implémenter des mesures de sécurité proactives qui peuvent détecter, alerter et bloquer l’activité DNS suspecte avant que les données puissent être exfiltrées.

Azure DNS stratégie de sécurité traite l’exfiltration des données DNS par le biais de plusieurs mécanismes clés. Tout d’abord, il permet de créer des règles de trafic DNS qui peuvent bloquer les requêtes sur des domaines malveillants connus ou des modèles de domaine suspects couramment utilisés dans les tentatives d’exfiltration. Les organisations peuvent gérer des listes de blocs de domaines associés aux services d’infrastructure de commande et de contrôle ou d’exfiltration de données. Deuxièmement, le service offre des fonctionnalités de journalisation DNS complètes qui capturent toutes les requêtes et réponses DNS au sein de réseaux virtuels protégés. Cette journalisation permet aux équipes de sécurité d’analyser les modèles de trafic DNS et d’identifier les tentatives potentielles d’exfiltration. Troisièmement, le moteur de stratégie prend en charge le filtrage de domaine générique, ce qui permet aux organisations de bloquer des catégories entières de domaines suspects ou d’implémenter des listes d’autorisation pour les destinations DNS approuvées.

L’implémentation de Azure DNS stratégie de sécurité crée plusieurs couches de défense contre l’exfiltration des données DNS. Les règles de trafic peuvent être configurées avec différents niveaux de priorité, ce qui permet des stratégies de sécurité complexes qui équilibrent la sécurité avec les exigences opérationnelles. Le service prend en charge le blocage en temps réel des requêtes malveillantes tout en fournissant des journaux détaillés pour l’analyse légale et la chasse aux menaces. En outre, les liens de réseau virtuel garantissent que les stratégies de sécurité DNS sont appliquées de manière cohérente sur toutes les ressources au sein de segments de réseau protégés, créant un périmètre de sécurité complet difficile pour les attaquants à contourner.

Pour les déploiements d’enclaves Azure, Azure DNS stratégie de sécurité doit être intégrée dans le cadre de l’architecture de sécurité globale. Les organisations doivent configurer des stratégies de sécurité DNS pour surveiller et contrôler le trafic DNS à partir des charges de travail d’enclave, ce qui garantit que les données sensibles restent protégées même si des charges de travail individuelles deviennent compromises. La révision et la mise à jour régulières des listes de domaines DNS, combinées à la surveillance continue des journaux DNS, offrent une protection continue contre les menaces dns en constante évolution et aident à maintenir l’intégrité de la sécurité de l’environnement d’enclave Azure.

Pour plus d’informations, consultez la documentation de la stratégie de sécurité DNS.

Mise en œuvre de politiques de sécurité DNS à refus par défaut

Pour une sécurité maximale dans les environnements d’enclave Azure, les organisations doivent implémenter une approche « refuser par défaut, autoriser par exception » le filtrage DNS. Ce modèle de sécurité garantit que toutes les requêtes DNS sont bloquées, sauf autorisation explicite, offrant la protection la plus forte contre l’exfiltration de données basée sur DNS et les communications de commande et de contrôle.

L’approche de refus par défaut est mise en œuvre à l’aide d’une structure de règles DNS à deux niveaux au sein d’Azure DNS Security Policy :

Étape 1 : Créer la règle de refus par défaut Créez une liste de domaines DNS contenant uniquement le domaine . racine (point). Ce domaine générique correspond à toutes les requêtes DNS possibles. Associez cette liste de domaines à une règle de trafic DNS configurée avec :

  • Priorité : 65000 (priorité la plus basse)
  • Action : Bloquer
  • Liste de domaines : Domaine racine (.)

Cette règle sert de catch-all qui bloque toute requête DNS non explicitement autorisée par les règles de priorité supérieure.

Étape 2 : Créer des règles de liste d’autorisation Créez des listes de domaines DNS distinctes contenant des domaines spécifiques nécessaires aux activités professionnelles légitimes. Il peut s’agir des éléments suivants :

  • Services de Azure essentiels (par exemple, *.azure.com, *.microsoft.com)
  • Domaines d’entreprise et services non-Microsoft approuvés
  • Services de mise à jour du système d’exploitation
  • Domaines d’autorité de certification

Associez les listes autorisées aux règles de trafic DNS configurées avec :

  • Priorité : 500-1000 (priorité supérieure au refus par défaut)
  • Action : Autoriser
  • Listes de domaines : domaines approuvés spécifiques

Le traitement des règles basées sur la priorité Azure DNS stratégie de sécurité traite les règles dans l’ordre de priorité (nombres inférieurs = priorité supérieure). Lorsqu’une requête DNS est effectuée :

  1. Le système évalue d’abord les règles d’autorisation à priorité élevée (priorité 500-1000)
  2. Si le domaine correspond à une liste d’autorisation, la requête est autorisée
  3. Si aucune règle ne correspond allow, la requête est alors soumise à la règle de refus par défaut (priorité 65000), et le trafic est bloqué.

Cette approche offre plusieurs avantages de sécurité :

  • Modèle de confiance zéro : aucune requête DNS n’est autorisée, sauf autorisation explicite
  • Contrôle granulaire : les organisations peuvent contrôler précisément quels domaines sont accessibles
  • Piste d’audit : toutes les requêtes bloquées sont journalisées, ce qui offre une visibilité sur les menaces potentielles
  • Mises à jour incrémentielles : les nouveaux domaines approuvés peuvent être ajoutés pour autoriser les listes sans modifier la règle de refus par défaut

Exemple d’implémentation :

Priority 500: Allow rule for Azure services
- Domain List: azure-services (contains azure.com., microsoft.com.)
- Action: Allow

Priority 600: Allow rule for business applications
- Domain List: business-domains (contains company.com., partner1.com., partner2.com.)
- Action: Allow

Priority 65000: Default deny rule
- Domain List: deny-all (contains .)
- Action: Block

Les organisations qui implémentent cette approche doivent commencer par un inventaire complet des domaines requis et affiner progressivement la liste des domaines autorisés en fonction des besoins opérationnels et des journaux de sécurité. L’examen régulier des requêtes bloquées permet d’identifier les domaines légitimes susceptibles d’être ajoutés aux listes d’autorisation tout en conservant une posture de sécurité forte.

Implémentation de stratégies DNS de refus par défaut avec Windows serveur DNS

Pour les environnements qui ne peuvent pas utiliser Azure DNS stratégie de sécurité ou exiger un contrôle DNS local, une sécurité de refus par défaut similaire peut être implémentée à l'aide d'Windows serveur DNS avec des fonctionnalités de stratégie DNS. Cette approche offre une protection comparable contre l’exfiltration de données basée sur DNS tout en conservant la compatibilité avec l’infrastructure Windows existante.

Windows serveur DNS (Windows Server 2016 et versions ultérieures) prend en charge les fonctionnalités de stratégie DNS qui permettent aux organisations d’implémenter des règles de filtrage DNS sophistiquées. Le modèle de refus par défaut peut être obtenu par le biais d’une combinaison de règles de stratégie DNS et de configurations de zone.

Groupes de ressources managés dans Azure Enclave

Groupes de ressources qui contiennent des ressources gérées par Azure Enclave.

Groupe de ressources géré par la communauté

Le groupe de ressources géré par la communauté contient les ressources d’infrastructure décrites dans Qu’est-ce qu’une communauté ?

Le nom du groupe de ressources géré par la communauté suit cette convention d’affectation de noms : myCommunityName-HostedResources-<GUID>. Chaque déploiement de la communauté crée ce groupe de ressources et place l’infrastructure de la communauté à l’intérieur. Lorsque vous supprimez votre communauté, le fournisseur de ressources Azure Enclave supprime automatiquement le groupe de ressources géré par la communauté.

Capture d’écran montrant un exemple des ressources de la communauté gérées par Azure Enclave.

Le groupe de ressources géré par la communauté présente les limitations suivantes :

  • Vous ne pouvez pas spécifier de groupe de ressources existant pour le groupe de ressources géré par la communauté.
  • Vous ne pouvez pas spécifier d’abonnement différent pour le groupe de ressources géré par la communauté.
  • Vous ne pouvez pas modifier le nom du groupe de ressources géré par la communauté une fois la communauté créée.
  • Vous ne pouvez pas spécifier de noms pour les ressources gérées au sein du groupe de ressources géré par la communauté.
  • Vous ne pouvez pas modifier ou supprimer des balises créées par Azure des ressources gérées au sein du groupe de ressources managées de la communauté.

Si vous modifiez ou supprimez des balises, des ressources et d’autres propriétés de ressources créées par Azure dans le groupe de ressources géré par la communauté, vous pouvez voir des résultats inattendus. Comme Azure Enclave gère le cycle de vie de l’infrastructure dans le groupe de ressources géré par la communauté, toutes les modifications peuvent potentiellement déplacer votre enclave dans un état non pris en charge.

Un scénario courant où vous souhaitez modifier des ressources consiste à utiliser des balises. Azure Enclave vous permet de créer et de modifier des balises propagées aux ressources du groupe de ressources géré par la communauté. Vous souhaiterez peut-être créer ou modifier des balises personnalisées, par exemple, pour affecter une unité commerciale ou un centre de coûts. Cela peut également être obtenu en créant des stratégies Azure avec une étendue sur le groupe de ressources géré par la communauté.

Note

Si le verrouillage du groupe de ressources géré par la communauté n’est pas activé, vous pouvez modifier directement n’importe quelle ressource dans le groupe de ressources géré par la communauté. Modifier directement des ressources dans le groupe de ressources géré par la communauté peut rendre votre enclave instable ou ne plus répondre.

Groupe de ressources géré par une enclave

Le groupe de ressources géré de l’enclave contient les ressources d’infrastructure décrites dans Qu’est-ce qu’une enclave ?.

Le nom du groupe de ressources géré pour l’enclave suit cette convention de nommage : myEnclaveName-HostedResources-<GUID>. Chaque déploiement d’enclave crée ce groupe de ressources et place l’infrastructure d’enclave à l’intérieur. Lorsque vous supprimez votre enclave, le fournisseur de ressources Azure Enclave supprime automatiquement le groupe de ressources géré par enclave.

Capture d’écran montrant un exemple des ressources d’enclave gérées par Azure Enclave.

Le groupe de ressources managé de l’enclave présente les limitations suivantes :

  • Vous ne pouvez pas spécifier un groupe de ressources existant pour le groupe de ressources géré de l’enclave.
  • Vous ne pouvez pas spécifier d’abonnement différent pour le groupe de ressources managé de l’enclave.
  • Vous ne pouvez pas modifier le nom du groupe de ressources géré de l’enclave une fois l’enclave créée.
  • Vous ne pouvez pas spécifier de noms pour les ressources managées dans le groupe de ressources managées de l’enclave.
  • Vous ne pouvez pas modifier ou supprimer des balises créées par Azure des ressources gérées au sein du groupe de ressources managées de l'enclave.

Si vous modifiez ou supprimez des balises, des ressources et d’autres propriétés de ressources créées par Azure dans le groupe de ressources managés de l’enclave, vous pouvez obtenir des résultats inattendus, tels que les erreurs de réseau, d’accès et de surveillance. Comme Azure Enclave gère le cycle de vie de l’infrastructure dans le groupe de ressources managé de l’enclave, toutes les modifications peuvent potentiellement déplacer votre enclave dans un état non pris en charge.

Un scénario courant où vous souhaitez modifier des ressources consiste à utiliser des balises. Azure Enclave vous permet de créer et de modifier des étiquettes propagées aux ressources dans le groupe de ressources managé de l’enclave. Vous souhaiterez peut-être créer ou modifier des balises personnalisées, par exemple, pour affecter une unité commerciale ou un centre de coûts. Le balisage des ressources peut également être obtenu en créant des stratégies Azure avec une étendue sur le groupe de ressources géré par enclave.

Warning

La modification des ressources dans le groupe de ressources managé de l’enclave peut entraîner l’instabilité ou la non-réponse de votre enclave.

Groupe de ressources pour les charges de travail

La charge de travail est liée à un ou plusieurs groupes de ressources dans lesquels vous pouvez créer et organiser vos ressources Azure.

Ajouter un groupe de ressources à une charge de travail

L’ajout d’un nouveau groupe de ressources nécessite normalement que l’utilisateur dispose des autorisations nécessaires pour créer un groupe de ressources. Les rôles d'abonnement Owner ou Contributor disposent de cette autorisation, mais la personne qui crée le groupe de ressources de charge de travail ne possède pas nécessairement cette autorisation privilégiée et n'en a peut-être pas besoin. Azure Enclave tente de créer le groupe de ressources de trois façons allant des exigences d’autorisation utilisateur les plus élevées aux plus faibles, offrant une flexibilité pour l’utilisateur :

  • Option 1 : Nécessite les autorisations les plus privilégiées pour la création ou la mise à jour de la charge de travail individuelle, en fournissant un contrôle total, mais nécessitant un accès élevé.
  • Option 2 : Implique la configuration manuelle par l’utilisateur pour accorder à notre Mission Enclave application la propriété au niveau de l’abonnement, ce qui peut ne pas s’aligner sur vos préférences.
  • Option 3 : Ne nécessite aucune autorisation pour l’utilisateur ou l’application Mission Enclave , ce qui en fait la méthode la plus simple, mais impose une relation stricte 1:1 entre le groupe de ressources et la charge de travail.

Chaque option présente des avantages et des limitations, un contrôle d’équilibrage, une commodité et une flexibilité pour répondre à différents besoins. Ces options sont évaluées à partir de l’option 1 et la première option à réussir est utilisée pour créer le nouveau groupe de ressources.

Après avoir créé un groupe de ressources de charge de travail à l’aide de l’option 3, vous voyez un avertissement indiquant que l’option 3 ne peut pas être utilisée pour les groupes de ressources de charge de travail suivants sur cette charge de travail. Vous pouvez également créer une charge de travail, puis créer un groupe de ressources de charge de travail à l’aide de l’option 3.

Ajoutez un groupe de ressources à votre enclave :

  1. Ouvrez la page du portail Azure pour la charge de travail.
  2. Sélectionnez Manage , puis Resource Groups.
  3. Sélectionnez Add a resource group.
  4. Dans la fenêtre latérale qui s’ouvre, sélectionnez Create new le nom du nouveau groupe de ressources vide ou sélectionnez la Resource Group liste déroulante pour choisir un groupe de ressources existant.
  5. Sélectionnez OK , puis Save.

Comment un groupe de ressources de charge de travail diffère-t-il d’autres groupes de ressources Azure ?

Un groupe de ressources de charge de travail est un composant essentiel de la sécurité et de la conformité des enclaves Azure, car c'est là que vos ressources importantes sont créées. Étant donné que ces groupes de ressources de charge de travail sont liés à une charge de travail et que la charge de travail est liée à une enclave, Azure Enclave gère la suppression des groupes de ressources managés de charge de travail.

En outre, la stratégie est appliquée aux groupes de ressources de charge de travail. De la même manière que les stratégies de communauté s’appliquent à l’enclave, les stratégies d’enclave s’appliquent également aux ressources de charge de travail et aux groupes de ressources de charge de travail. Lorsque vous créez un nouveau groupe de ressources de charge de travail, les rôles sont définis au niveau de l'enclave et hérités de l'abonnement. Certaines de ces stratégies sont héritées de la communauté. Vous pouvez également créer des stratégies au niveau de l'enclave qui sont propagées aux charges de travail et aux groupes de ressources de charge de travail.

Organisation des ressources au sein de groupes de ressources de charge de travail

Si vous souhaitez fractionner vos ressources en deux groupes de ressources, vous pouvez choisir l’une des options suivantes :

  • fractionner ces ressources entre deux groupes de ressources liés à une charge de travail
  • fractionner ces ressources entre deux charges de travail ayant chacune un ou plusieurs groupes de ressources

Suppression de la charge de travail

Lorsqu’une suppression de charge de travail est demandée, les groupes de ressources de charge de travail sont vérifiés pour s’assurer qu’ils sont vides. Si les groupes de ressources de charge de travail contiennent des ressources, la suppression de la charge de travail demandée échoue et affiche une erreur. Pour supprimer la charge de travail et les groupes de ressources de la charge de travail, commencez par vider les groupes de ressources de la charge de travail. Les groupes de ressources de charge de travail vides permettent d’éviter la suppression accidentelle de ressources importantes.

La suppression d’une ressource liée à la charge de travail suit le même comportement. Par exemple, si une suppression de la communauté est demandée, mais que tous les groupes de ressources de charge de travail ne sont pas vides, l’opération affiche une erreur. Videz les groupes de ressources de charge de travail, puis réessayez.

Le groupe de ressources managées de la charge de travail présente les limitations suivantes :

  • Vous ne pouvez pas spécifier un groupe de ressources existant pour le groupe de ressources managées de la charge de travail.
  • Vous ne pouvez pas spécifier un autre abonnement pour le groupe de ressources managées de la charge de travail.
  • Vous ne pouvez pas modifier le nom du groupe de ressources managé de la charge de travail une fois la charge de travail créée.
  • Vous ne pouvez pas modifier ou supprimer des balises Azure créées de ressources managées au sein du groupe de ressources managées de charge de travail.

Un scénario courant où vous souhaitez modifier des ressources consiste à utiliser des balises. Azure Enclave vous permet de créer et de modifier des étiquettes propagées aux ressources dans le groupe de ressources géré par la charge de travail. Vous souhaiterez peut-être créer ou modifier des balises personnalisées, par exemple, pour affecter une unité commerciale ou un centre de coûts. Le balisage peut également être réalisé en créant des stratégies Azure avec une étendue sur le groupe de ressources managées de la charge de travail.

Autres meilleures pratiques Azure

Lorsque vous créez vos communautés, enclaves et charges de travail dans Azure, il est important de garder à l'esprit les principes de conception universels suivants :

  • Last updated on