Azure Enclave best practices

Este artigo descreve conceitos-chave e boas práticas para o Azure Enclave.

O Azure Enclave acelera e simplifica a implementação e gestão de ambientes cloud seguros, isolados e compatíveis. Estes ambientes são concebidos para lidar com as missões e cargas de trabalho mais sensíveis em ambientes comerciais e isolados.

Construir e executar cargas de trabalho com sucesso no Azure Enclave requer compreensão e implementação de alguns conceitos-chave, incluindo:

O grupo de produtos Azure Enclave, as equipas de engenharia e as equipas de campo desenvolveram as seguintes melhores práticas e artigos conceptuais. Os artigos foram criados para ajudar os proprietários e desenvolvedores de comunidades e enclaves a compreender melhor conceitos importantes e a implementar as funcionalidades adequadas.

Configuração do Azure

Leia estes passos de configuração para determinar se se adequam aos seus casos de uso do Azure Enclave.

Configurar grupos de recursos do Observador de Rede

Para evitar potenciais problemas com a criação de registos de fluxo de rede virtual , configure o NetworkWatcherRG grupo de recursos manualmente com antecedência e atribua à Mission Enclave aplicação o Owner papel nesse grupo de recursos, ou verifique se a configuração e atribuição de funções foram feitas automaticamente antes de criar o seu primeiro enclave na subscrição.

Para mitigar este potencial problema, para cada subscrição, crie manualmente o grupo de recursos NetworkWatcher chamado NetworkWatcherRG para novas subscrições e depois conceda a Mission Enclave aplicação Owner Azure Enclave no NetworkWatcherRG:

  1. Selecione o NetworkWatcherRG grupo de recursos, selecione Access control (IAM), depois selecione Add e Add role assignment.

Captura de ecrã que mostra a seleção de adição de função no grupo de recursos no portal.

  1. Selecione Privileged administrator roles, selecione owner, depois selecione Next.

Captura de ecrã que mostra o ecrã de seleção da função Proprietário no portal.

  1. Selecione Select members, escreva Mission Enclave na pesquisa e selecione a Mission Enclave aplicação, selecione Select, depois Next.

Captura de ecrã a mostrar como selecionar a aplicação Mission Enclave no portal.

  1. Se a sua subscrição exigir uma condição, selecione Allow user to assign all roles except privileged administrator roles Owner, UAA, RBAC (Recommended), depois selecione Review + assign.

Captura de ecrã que mostra a visualização de adicionar condição se a tua subscrição assim o exigir.

  1. Quando a atualização estiver concluída, pode começar a implementar os recursos do Azure Enclave.

Quando uma comunidade ou enclave é criada, o Azure Enclave tenta os seguintes passos:

  1. Verifique se NetworkWatcherRG existe. Caso contrário, tente criar esse grupo de recursos.
  2. Verifique se a Mission Enclave App tem uma atribuição Owner permanente em NetworkWatcherRG. Caso contrário, tente atribuir a aplicação Mission Enclave como atribuição permanente Owner em NetworkWatcherRG. Mesmo que exista uma permissão herdada Owner, é tentada a criação de uma atribuição permanente Owner.
  3. Se algum passo falhar, as implementações do enclave podem falhar ao tentar criar registos de fluxo de rede virtual.

Padrões de Design Organizacional e de Rede para Azure Enclave

Arquitetura de multi-alojamento

Design de redes

O Azure Enclave reúne as capacidades e flexibilidade de vários produtos de rede Azure numa interface de utilizador simplificada, incluindo:

  • WAN Virtual do Azure
  • Azure Firewall
  • Rede Virtual do Azure
  • Grupos de Segurança de Rede

O Azure Enclave faz as seguintes recomendações gerais:

  • Comunidades devem ser implementadas quando existirem requisitos de rede que exijam o fornecimento de um Azure Firewall, que é a plataforma como serviço (PaaS) de segurança de firewall inteligente da Azure.
  • As comunidades devem ser implementadas quando existirem requisitos de organização ou de sensibilidade dos dados para separar uma WAN Virtual em arquitetura hub-and-spoke de outra WAN Virtual em arquitetura hub-and-spoke.
  • As comunidades devem ser implementadas quando houver requisitos de rede para suportar sistemas que abrangem múltiplas regiões do Azure, em que cada região necessita do seu próprio Azure Firewall. Saiba mais sobre os casos de uso do Azure Firewall multi-hub.
  • As comunidades devem ser implementadas quando existirem requisitos de rede para suportar um grande número de sistemas numa rede alargada distribuída com arquitetura hub-and-spoke. Saiba mais sobre WAN Virtual do Azure.
  • Os enclaves devem ser implementados quando houver requisitos de rede para implementar cargas de trabalho semelhantes como parte da mesma rede privada.
  • Os enclaves devem ser implementados quando houver requisitos de carga de trabalho que necessitam de uma rede virtual e que estejam dentro da mesma WAN Virtual que uma comunidade existente.

Considerações sobre o design de redes comunitárias

Deve seguir, sempre que possível, a documentação subjacente das melhores práticas de serviço do Azure ao planear as suas redes comunitárias. Incluindo estas melhores práticas:

Considerações sobre o design da rede de enclaves

Deve seguir, sempre que possível, a documentação subjacente das melhores práticas de serviços do Azure ao planear as suas redes enclave. Incluindo estas melhores práticas:

Saiba mais sobre as melhores práticas gerais de rede do Azure.

Implantação da carga de trabalho

  • As cargas de trabalho estão ligadas a um grupo de recursos geridos onde os colaboradores do enclave podem implementar recursos do Azure.
  • Por defeito, todas as cargas de trabalho do Azure Enclave são governadas por iniciativas incorporadas do Azure Policy
  • Cargas de trabalho associadas a uma comunidade que tem uma configuração de governação personalizada, utilizam esta configuração única em vez da configuração padrão de governação do Azure Enclave.
  • Considerações para nomear recursos do Azure

Padrões de conceção de segurança para Azure Enclave

Considere estes padrões de design de segurança ao desenhar os seus ambientes Azure Enclave.

Limites de segurança

O Azure Enclave adota uma abordagem de defesa em profundidade no que diz respeito à cibersegurança. Quando implementa uma comunidade e enclaves, o Azure Enclave estabelece várias camadas de isolamento de rede, segurança, controlos de acesso e registo e monitorização.

Responsabilidades partilhadas de segurança

Como serviço no Azure, o Azure Enclave também está comprometido em manter o modelo de responsabilidade partilhada na cloud. Para o Azure Enclave especificamente, as cargas de trabalho são da tua responsabilidade. A responsabilidade partilhada no Azure aplica-se às cargas de trabalho se tiver implementado serviços PaaS nas suas cargas de trabalho.

As vossas comunidades e enclaves representam uma responsabilidade partilhada. Comunidades e enclaves utilizam um modelo de responsabilidade partilhada onde o Azure Enclave Resource Provider cria o seu ambiente de rede hub pré-configurado e seguro. Gere este ambiente de rede criando pontos finais de enclave, pontos finais da comunidade, hubs de trânsito ou ligações de enclave. Certas versões de pré-visualização do Azure Enclave também permitem fazer alterações manualmente à rede através de controlos subjacentes fornecidos pelo WAN Virtual do Azure, Rede Virtual do Azure e outros serviços de rede Azure subjacentes.

A governação do Azure Enclave também é uma responsabilidade partilhada. O Azure Enclave Resource Provider cria uma lista segura e pré-configurada de iniciativas Azure Policy por implementação de carga de trabalho. No entanto, as comunidades podem agora personalizar as iniciativas do Azure Policy da comunidade, o que substitui a lista pré-configurada para a carga de trabalho. Apesar dos requisitos da política, mantém a possibilidade de fazer isenções manuais a estas atribuições da Azure Policy Initiative, dependendo dos requisitos de conformidade ou governação.

Melhores práticas do Azure Security

O Azure Enclave recomenda seguir as melhores práticas e padrões de segurança do Microsoft Azure para implementar recursos Azure e implementar cargas de trabalho.

Deve seguir as melhores práticas de segurança do Azure - Cloud Adoption Framework para organizar os seus sistemas, infraestrutura cloud, pessoal de TI e estruturas de equipa, e formações de sensibilização corporativa para cibersegurança.

Exfiltração de dados através do Sistema de Nomes de Domínio

A exfiltração de dados através do Sistema de Nomes de Domínio (DNS) representa uma preocupação significativa de segurança para as organizações, pois utiliza um protocolo normalmente permitido através de firewalls e raramente monitorizado para atividades maliciosas. Os atacantes podem explorar consultas DNS para extrair secretamente dados sensíveis de sistemas comprometidos, codificando informações dentro de nomes de domínio ou utilizando técnicas de tunelamento DNS. Este método é insidioso porque o tráfego DNS parece legítimo e muitas vezes contorna as ferramentas tradicionais de monitorização de segurança.

Em ataques de exfiltração de dados baseados em DNS, atores maliciosos codificam dados roubados em consultas DNS, frequentemente usando técnicas como rotulagem de subdomínios ou consultas de registo TXT. Por exemplo, um atacante pode fragmentar dados sensíveis em blocos e incorporar cada bloco como um subdomínio em consultas DNS para domínios controlados pelo atacante. Os dados podem ser extraídos dos registos DNS no servidor DNS do atacante. Esta abordagem permite a exfiltração gradual de grandes conjuntos de dados, mantendo um perfil baixo, já que as consultas DNS aparecem como pedidos normais de resolução de nomes.

Endereçar a exfiltração de dados com DNS do Azure Security Policy

A Política de Segurança DNS do Azure oferece proteção abrangente contra ataques de exfiltração de dados baseados em DNS, proporcionando controlo granular sobre o tráfego DNS dentro das Redes Virtuais Azure. Este serviço permite às organizações implementar medidas de segurança proativas que podem detetar, alertar e bloquear atividades DNS suspeitas antes que os dados possam ser exfiltrados com sucesso.

A Política de Segurança do DNS do Azure aborda a exfiltração de dados DNS através de vários mecanismos-chave. Primeiro, oferece a capacidade de criar regras de tráfego DNS que podem bloquear consultas a domínios maliciosos conhecidos ou padrões de domínio suspeitos comumente usados em tentativas de exfiltração. As organizações podem manter listas de bloco de domínios associados à infraestrutura de comando e controlo ou a serviços de exfiltração de dados. Em segundo lugar, o serviço oferece capacidades abrangentes de registo DNS que capturam todas as consultas e respostas DNS dentro de redes virtuais protegidas. Este registo permite às equipas de segurança analisar padrões de tráfego DNS e identificar potenciais tentativas de exfiltração. Em terceiro lugar, o motor de políticas suporta filtragem de domínios coringa, permitindo às organizações bloquear categorias inteiras de domínios suspeitos ou implementar listas de autorização para destinos DNS aprovados.

A implementação da Política de Segurança DNS do Azure cria múltiplas camadas de defesa contra a exfiltração de dados DNS. As regras de trânsito podem ser configuradas com diferentes níveis de prioridade, permitindo políticas de segurança complexas que equilibram a segurança com os requisitos operacionais. O serviço suporta o bloqueio em tempo real de consultas maliciosas, ao mesmo tempo que fornece registos detalhados para análise forense e caça a ameaças. Além disso, as ligações virtuais de rede garantem que as políticas de segurança DNS são aplicadas de forma consistente em todos os recursos dentro dos segmentos protegidos, criando um perímetro de segurança abrangente que é difícil de contornar para atacantes.

Para implementações do Azure Enclave, a Política de Segurança do DNS do Azure deve ser integrada como parte da arquitetura de segurança global. As organizações devem configurar políticas de segurança DNS para monitorizar e controlar o tráfego DNS proveniente das cargas de trabalho do enclave, garantindo que os dados sensíveis permaneçam protegidos mesmo que cargas de trabalho individuais sejam comprometidas. A revisão e atualização regular das listas de domínios DNS, combinadas com monitorização contínua dos registos DNS, proporciona proteção contínua contra ameaças baseadas em DNS em evolução e ajuda a manter a integridade de segurança do ambiente Azure Enclave.

Mais informações estão disponíveis na documentação da Política de Segurança do DNS.

Implementar políticas de segurança DNS de negação por omissão

Para máxima segurança em ambientes Azure Enclave, as organizações devem implementar uma abordagem de "negar por defeito, permitir por exceção" para a filtragem DNS. Este modelo de segurança garante que todas as consultas DNS são bloqueadas, salvo autorização explícita, proporcionando a proteção mais forte contra a exfiltração de dados baseada em DNS e comunicações de comando e controlo.

A abordagem de recusa por predefinição é implementada através de uma estrutura de regras DNS em dois níveis na Política de Segurança de DNS do Azure:

Passo 1: Criar a regra de recusa padrão Crie uma Lista de Domínios DNS contendo apenas o domínio . raiz (dot). Este domínio coringa corresponde a todas as possíveis consultas DNS. Associe esta lista de domínios a uma regra de tráfego DNS configurada com:

  • Prioridade: 65000 (prioridade mais baixa)
  • Ação: Bloqueio
  • Lista de domínios: Domínio raiz (.)

Esta regra serve como o termo genérico que bloqueia qualquer consulta DNS que não seja explicitamente permitida pelas regras de prioridade superior.

Passo 2: Criar regras de lista de permitir Crie Listas de Domínios DNS separadas contendo domínios específicos necessários para operações empresariais legítimas. Estas podem incluir:

  • Essential Azure services (por exemplo, *.azure.com, *.microsoft.com)
  • Domínios corporativos e serviços fidedignos que não são da Microsoft
  • Serviços de atualização do sistema operativo
  • Domínios de autoridade certificadora

Associe as listas de permissão às regras de tráfego DNS configuradas com:

  • Prioridade: 500-1000 (prioridade superior à negação padrão)
  • Ação: Permitir
  • Listas de Domínios: Domínios aprovados específicos

Processamento de regras baseado em prioridades DNS do Azure Security Policy processa regras por ordem de prioridade (números inferiores = prioridade superior). Quando é feita uma consulta DNS:

  1. O sistema avalia primeiro regras de permissão de alta prioridade (prioridade 500-1000)
  2. Se o domínio corresponder a uma lista de permitidos, a consulta é permitida
  3. Se nenhuma allow regra corresponde, a consulta passa para a regra de negação por defeito (prioridade 65000) e o tráfego é bloqueado

Esta abordagem oferece várias vantagens de segurança:

  • Modelo de confiança zero: Não são permitidas consultas DNS a menos que seja explicitamente autorizado
  • Controlo granular: As organizações podem controlar com precisão quais os domínios acessíveis
  • Registo de auditoria: Todas as consultas bloqueadas são registadas, proporcionando visibilidade sobre potenciais ameaças
  • Atualizações incrementais: Novos domínios aprovados podem ser adicionados para permitir listas sem modificar a regra padrão de recusa

Exemplo de implementação:

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

As organizações que implementam esta abordagem devem começar com um inventário abrangente dos domínios necessários e refinar gradualmente a lista de domínios permitidos com base nas necessidades operacionais e nos registos de segurança. A revisão regular das consultas bloqueadas ajuda a identificar domínios legítimos que possam precisar de ser adicionados às listas de autorizações, mantendo uma postura de segurança forte.

Implementar políticas DNS de negação por predefinição no Windows DNS Server

Para ambientes que não podem utilizar a Política de Segurança do DNS do Azure ou que exigem controlo de DNS no local, é possível implementar uma segurança semelhante de negação por predefinição com o Windows DNS Server, através das funcionalidades de Política de DNS. Esta abordagem oferece proteção comparável contra a exfiltração de dados baseada em DNS, mantendo a compatibilidade com a infraestrutura Windows existente.

O Windows DNS Server (Windows Server 2016 e posteriores) suporta funcionalidades de Política DNS que permitem às organizações implementar regras sofisticadas de filtragem DNS. O modelo de negação por defeito pode ser alcançado através de uma combinação de regras de Política DNS e configurações de zonas.

Grupos de recursos geridos no Azure Enclave

Os grupos de recursos que contêm recursos geridos pelo Azure Enclave.

Grupo de recursos geridos pela comunidade

O grupo de recursos geridos pela comunidade contém os recursos de infraestrutura descritos em O que é uma comunidade?.

O nome do grupo de recursos geridos pela comunidade segue esta convenção de nomenclatura: myCommunityName-HostedResources-<GUID>. Cada implantação comunitária cria este grupo de recursos e coloca infraestruturas comunitárias dentro dele. Quando elimina a sua comunidade, o fornecedor de recursos do Azure Enclave elimina automaticamente o grupo de recursos gerido pela comunidade.

Captura de ecrã que mostra um exemplo dos recursos comunitários geridos pelo Azure Enclave.

O grupo de recursos gerido pela comunidade tem as seguintes limitações:

  • Não pode especificar um grupo de recursos existente para o grupo de recursos gerido pela comunidade.
  • Não podes especificar uma subscrição diferente para o grupo de recursos gerido pela comunidade.
  • Não podes mudar o nome do grupo de recursos gerido pela comunidade depois de a comunidade ser criada.
  • Não podes especificar nomes para os recursos geridos dentro do grupo de recursos geridos pela comunidade.
  • Não pode modificar ou eliminar etiquetas criadas pelo Azure de recursos geridos dentro do grupo de recursos geridos pela comunidade.

Se modificar ou eliminar etiquetas, recursos e outras propriedades de recursos criadas pelo Azure no grupo de recursos geridos pela comunidade, poderá ver resultados inesperados. Como o Azure Enclave gere o ciclo de vida da infraestrutura no grupo de recursos gerido pela comunidade, quaisquer alterações podem potencialmente colocar o seu enclave num estado não suportado.

Um cenário comum em que se quer modificar recursos é através de tags. O Azure Enclave permite-lhe criar e modificar etiquetas que são propagadas para recursos no grupo de recursos geridos pela comunidade. Talvez você queira criar ou modificar tags personalizadas, por exemplo, para atribuir uma unidade de negócios ou um centro de custo. Isto também pode ser conseguido criando Políticas do Azure com um âmbito no grupo de recursos gerido pela comunidade.

Note

Se não tiver ativado o bloqueio de grupos de recursos geridos pela comunidade, pode modificar diretamente qualquer recurso no grupo de recursos gerido pela comunidade. Modificar diretamente os recursos no grupo de recursos geridos pela comunidade pode fazer com que o seu enclave fique instável ou pouco responsivo.

Grupo de recursos geridos pelo Enclave

O grupo de recursos geridos do Enclave contém os recursos de infraestrutura descritos em O que é um enclave?.

O nome do grupo de recursos geridos do enclave segue esta convenção de nomenclatura: myEnclaveName-HostedResources-<GUID>. Cada implementação de enclave cria este grupo de recursos e coloca a infraestrutura do enclave dentro dele. Quando elimina o seu enclave, o fornecedor de recursos do Azure Enclave elimina automaticamente o grupo de recursos gerido do enclave.

Captura de ecrã que mostra um exemplo dos recursos do enclave geridos pelo Azure Enclave.

O grupo de recursos geridos pelo enclave apresenta as seguintes limitações:

  • Não podes especificar um grupo de recursos existente para o grupo de recursos geridos pelo enclave.
  • Não podes especificar uma subscrição diferente para o grupo de recursos geridos pelo enclave.
  • Não podes mudar o nome do grupo de recursos geridos do enclave depois de o enclave ser criado.
  • Não podes especificar nomes para os recursos geridos dentro do grupo de recursos geridos do enclave.
  • Não pode modificar ou eliminar etiquetas criadas pelo Azure de recursos geridos dentro do grupo de recursos geridos do enclave.

Se modificar ou eliminar etiquetas, recursos e outras propriedades de recursos criadas pelo Azure no grupo de recursos geridos do enclave, pode obter resultados inesperados, como erros de rede, acesso e monitorização. Como o Azure Enclave gere o ciclo de vida da infraestrutura no grupo de recursos geridos pelo enclave, quaisquer alterações podem potencialmente mover o seu enclave para um estado não suportado.

Um cenário comum em que se quer modificar recursos é através de tags. O Azure Enclave permite-lhe criar e modificar etiquetas que são propagadas para recursos no grupo de recursos geridos do enclave. Talvez você queira criar ou modificar tags personalizadas, por exemplo, para atribuir uma unidade de negócios ou um centro de custo. A marcação de recursos também pode ser obtida através da criação de políticas do Azure com âmbito no grupo de recursos gerido do enclave.

Warning

Modificar recursos no grupo de recursos geridos do enclave pode fazer com que o seu enclave fique instável ou pouco responsivo.

Grupo de recursos de carga de trabalho

A carga de trabalho está ligada a um ou mais grupos de recursos onde pode criar e organizar os seus recursos no Azure.

Adicionar um grupo de recursos a uma carga de trabalho

Adicionar um novo grupo de recursos normalmente exige que o utilizador tenha permissões para criar um novo grupo de recursos. As funções Owner ou Contributor da subscrição têm esta permissão, mas a pessoa que cria o grupo de recursos da carga de trabalho pode não ter nem precisar desta permissão privilegiada. O Azure Enclave tenta três formas de criar o novo grupo de recursos, desde os requisitos de permissão mais elevados até aos mais baixos, oferecendo flexibilidade ao utilizador:

  • Opção 1: Requer o maior número de permissões privilegiadas para o indivíduo que cria ou atualiza a carga de trabalho, proporcionando controlo total mas exigindo acesso elevado.
  • Opção 2: Envolve a configuração manual pelo utilizador para conceder a propriedade da nossa Mission Enclave aplicação ao nível da subscrição, o que pode não estar alinhado com as suas preferências.
  • Opção 3: Não requer permissões nem para o utilizador nem para a Mission Enclave aplicação, tornando-o o método mais fácil, mas impondo uma relação estrita 1:1 entre o grupo de recursos e a carga de trabalho.

Cada opção tem vantagens e limitações, equilibrando controlo, conveniência e flexibilidade para se adequar a diferentes necessidades. Estas opções são avaliadas a partir da opção 1 e a primeira opção a ter sucesso é usada para criar o novo grupo de recursos.

Depois de criares um grupo de recursos de carga de trabalho usando a opção 3, vês um aviso de que a opção 3 não pode ser usada para os próximos grupos de recursos dessa carga. Também podes criar uma nova carga de trabalho e depois criar um novo grupo de recursos de carga de trabalho usando novamente a opção 3.

Adicione um grupo de recursos ao seu enclave:

  1. Abra a página do portal do Azure para a carga de trabalho.
  2. Selecione Manage e depois Resource Groups.
  3. Selecione Add a resource group.
  4. Na janela lateral que se abre, selecione Create new para introduzir o nome do novo grupo de recursos vazio, ou selecione o menu pendente Resource Group para escolher um grupo de recursos existente.
  5. Selecione OK e depois Save.

Em que é que um grupo de recursos de carga de trabalho difere de outros grupos de recursos do Azure?

Um grupo de recursos de carga de trabalho é um componente crítico da segurança e conformidade do Azure Enclave porque é aí que os seus recursos importantes são criados. Como estes grupos de recursos de carga de trabalho estão ligados a uma carga de trabalho, e a carga de trabalho está ligada a um enclave, o Azure Enclave gere a eliminação dos grupos de recursos geridos por carga de trabalho.

Adicionalmente, a política é aplicada aos grupos de recursos de carga de trabalho. À semelhança da forma como as políticas da comunidade são propagadas para o enclave, as políticas do enclave são propagadas para os recursos de workload e para os grupos de recursos de workload. Quando crias um novo grupo de recursos de carga de trabalho, os papéis são definidos ao nível do enclave e herdados da subscrição. Algumas destas políticas são herdadas da comunidade e também pode criar políticas no enclave que fluem para cargas de trabalho e grupos de recursos de carga de trabalho.

Organização de recursos em grupos de recursos de carga de trabalho

Se quiser dividir os seus recursos em dois grupos de recursos, pode escolher qualquer uma destas opções:

  • Dividir esses recursos entre dois grupos de recursos ligados a uma única carga de trabalho
  • Dividir esses recursos entre duas cargas de trabalho, cada uma com um ou mais grupos de recursos

Eliminação de carga de trabalho

Quando se solicita a eliminação de uma carga de trabalho, os grupos de recursos da carga de trabalho são verificados para garantir que estão vazios. Se os grupos de recursos da carga de trabalho conterem recursos, a eliminação da carga de trabalho solicitada falha e apresenta um erro. Para eliminar a carga de trabalho e os grupos de recursos da carga de trabalho, esvazie primeiro os grupos de recursos da carga de trabalho. Grupos de recursos de carga de trabalho vazios ajudam a evitar a eliminação acidental de recursos importantes.

A eliminação de um recurso ligado à carga de trabalho segue o mesmo comportamento. Por exemplo, se for solicitada a eliminação da comunidade mas todos os grupos de recursos de carga de trabalho não estiverem vazios, a operação mostra um erro. Esvazie os grupos de recursos da carga de trabalho e tente novamente.

O grupo de recursos geridos por carga de trabalho apresenta as seguintes limitações:

  • Não podes especificar um grupo de recursos existente para o grupo de recursos geridos por carga de trabalho.
  • Não podes especificar uma subscrição diferente para o grupo de recursos geridos da carga de trabalho.
  • Não podes alterar o nome do grupo de recursos geridos da carga de trabalho depois de a carga de trabalho ser criada.
  • Não pode modificar ou eliminar etiquetas criadas pelo Azure dos recursos geridos dentro do grupo de recursos geridos da carga de trabalho.

Um cenário comum em que se quer modificar recursos é através de tags. O Azure Enclave permite-lhe criar e modificar etiquetas que são propagadas para recursos no grupo de recursos geridos por carga de trabalho. Talvez você queira criar ou modificar tags personalizadas, por exemplo, para atribuir uma unidade de negócios ou um centro de custo. A etiquetagem também pode ser obtida através da criação de Políticas Azure com âmbito no grupo de recursos geridos associado à carga de trabalho.

Outras melhores práticas do Azure

À medida que constróis as tuas comunidades, enclaves e cargas de trabalho no Azure, é importante ter em conta os seguintes princípios universais de design:

  • Last updated on