Práticas recomendadas do enclave Azure

Este artigo descreve os principais conceitos e as práticas recomendadas para Azure Enclave.

Azure Enclave acelera e simplifica a implantação e o gerenciamento de ambientes de nuvem seguros, isolados e compatíveis. Esses ambientes são projetados para lidar com as missões e cargas de trabalho mais sensíveis em ambientes comerciais e isolados da internet.

A criação e execução de cargas de trabalho com êxito no enclave Azure requer a compreensão e a implementação de alguns conceitos importantes, incluindo:

O grupo de produtos do Azure Enclave, as equipes de engenharia e as equipes de campo desenvolveram as práticas recomendadas e os artigos conceituais a seguir. Os artigos foram criados para ajudar os proprietários e desenvolvedores da comunidade e do enclave a entender melhor os conceitos importantes e implementar os recursos apropriados.

Configuração do Azure

Leia estas etapas de configuração para determinar se essas etapas de configuração se ajustam aos casos de uso do enclave Azure.

Configurar grupos de recursos Observador de Rede

Para evitar possíveis problemas com a criação do log de fluxo da rede virtual, configure manualmente com antecedência o grupo de recursos NetworkWatcherRG e atribua ao aplicativo Mission Enclave a função Owner nesse grupo de recursos, ou verifique se essa configuração e essa atribuição de função ocorreram automaticamente antes de criar seu primeiro enclave na assinatura.

Para atenuar esse possível problema, para cada assinatura, crie manualmente o grupo de recursos NetworkWatcher chamado NetworkWatcherRG em novas assinaturas e conceda o Mission Enclave aplicativo Owner enclave Azure no NetworkWatcherRG:

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

Captura de tela mostrando a seleção para adicionar função ao grupo de recursos no portal.

  1. Selecione Privileged administrator roles, selecione ownere, em seguida, selecione Next.

Captura de tela mostrando a tela de seleção para adicionar a função de proprietário no portal.

  1. Selecione Select members, digite Mission Enclave na pesquisa e selecione o aplicativo Mission Enclave, selecione Select e, em seguida, Next.

Captura de tela mostrando como selecionar o aplicativo Enclave de Missão no portal.

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

Captura de tela mostrando a tela de adicionar condição, se sua assinatura exigir isso.

  1. Depois que a atualização for concluída, você poderá começar a implantar recursos do Azure Enclave.

Quando uma comunidade ou enclave é criado, Azure Enclave tenta as seguintes etapas:

  1. Verifique se NetworkWatcherRG existe. Caso contrário, tente criar esse grupo de recursos.
  2. Verifique se o aplicativo Mission Enclave tem uma atribuição permanente Owner em NetworkWatcherRG. Caso contrário, tente atribuir o Mission Enclave Aplicativo como uma atribuição permanente Owner em NetworkWatcherRG. Mesmo que exista uma permissão herdada Owner, será feita uma tentativa de criar uma atribuição permanente Owner.
  3. Se qualquer etapa falhar, as implantações de enclave poderão falhar ao tentar criar logs de fluxo de rede virtual.

Padrões de design organizacional e de rede para o enclave de Azure

Multitenância

Design de rede

Azure Enclave reúne os recursos e a flexibilidade de vários produtos de rede Azure em uma interface de usuário simplificada, incluindo:

  • WAN Virtual do Azure
  • Firewall do Azure
  • Rede Virtual do Azure
  • Grupos de segurança de rede

Azure Enclave faz as seguintes recomendações gerais:

  • As comunidades devem ser implantadas quando você tiver requisitos de rede para fornecer um Firewall do Azure, que é a plataforma como serviço de segurança de firewall inteligente do Azure.
  • As comunidades devem ser implementadas quando você tiver requisitos organizacionais ou de confidencialidade de dados para separar uma WAN Virtual em topologia hub-and-spoke de outra WAN Virtual em topologia hub-and-spoke.
  • As comunidades devem ser implantadas quando você tiver requisitos de rede para dar suporte a sistemas que abrangem várias regiões de Azure, nas quais cada região requer sua própria Firewall do Azure. Saiba mais sobre casos de uso do Firewall do Azure com múltiplos hubs.
  • Comunidades devem ser implantadas quando houver requisitos de rede para suportar um grande número de sistemas em uma rede WAN distribuída em topologia hub-and-spoke. Saiba mais sobre WAN Virtual do Azure.
  • Os enclaves devem ser implantados quando você tiver requisitos de rede para implantar cargas de trabalho semelhantes como parte da mesma rede privada.
  • Os enclaves devem ser implantados quando houver requisitos da carga de trabalho que exijam uma rede virtual e que estejam na mesma WAN Virtual que uma comunidade existente.

Considerações de design de rede da comunidade

Você deve seguir, sempre que possível, a documentação de práticas recomendadas do serviço Azure subjacente ao planejar suas redes de comunidade. Incluindo estas práticas recomendadas:

Considerações sobre o design de rede do enclave

Você deve seguir, sempre que possível, a documentação de práticas recomendadas do serviço Azure subjacente ao planejar suas redes de enclave. Incluindo estas práticas recomendadas:

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

Implantação da carga de trabalho

  • As cargas de trabalho estão vinculadas a um grupo de recursos gerenciado em que os colaboradores do enclave podem implantar recursos Azure.
  • Por padrão, todas as cargas de trabalho do Enclave Azure são governadas por meio de iniciativas internas de Azure Policy
  • Cargas de trabalho associadas a uma comunidade que tem uma configuração de governança personalizada, usam essa configuração exclusiva em vez da configuração de governança padrão Azure Enclave.
  • Considerações sobre como nomear recursos Azure

Padrões de design de segurança para Azure Enclave

Considere esses padrões de design de segurança ao projetar seus ambientes do Enclave Azure.

Limites de segurança

Azure Enclave emprega uma abordagem de defesa detalhada quando se trata de segurança cibernética. Quando você implanta uma comunidade e enclaves, Azure Enclave estabelece várias camadas de isolamento de rede, segurança, controles de acesso e registro em log e monitoramento.

Responsabilidades de segurança partilhadas

Como um serviço no Azure, Azure Enclave também está comprometido em manter o modelo de responsabilidade compartilhada na nuvem. Para Azure Enclave especificamente, as cargas de trabalho são de sua responsabilidade. A responsabilidade compartilhada da Azure é herdada pelas cargas de trabalho se você implantou serviços PaaS nelas.

Suas comunidades e enclaves representam uma responsabilidade compartilhada. Comunidades e enclaves usam um modelo de responsabilidade compartilhada no qual o Azure Enclave Resource Provider cria seu ambiente de rede seguro e pré-configurado em topologia hub-and-spoke. Você gerencia este ambiente de rede criando endpoints de enclave, endpoints da comunidade, hubs de trânsito ou conexões de enclave. Determinadas versões prévias do Azure Enclave também permitem que você faça alterações manualmente na rede por meio de controles subjacentes fornecidos por WAN Virtual do Azure, Rede Virtual do Azure e outros serviços de rede Azure subjacentes.

A governança do Azure Enclave também é uma responsabilidade compartilhada. O provedor de recursos do Azure Enclave cria uma lista segura e pré-configurada de iniciativas do Azure Policy para cada implantação de carga de trabalho. No entanto, as comunidades agora podem personalizar as iniciativas de Política do Azure da comunidade, o que substitui a lista pré-configurada para a carga de trabalho. Apesar dos requisitos de política, você mantém a capacidade de fazer isenções manuais para essas atribuições de iniciativa Azure Policy, dependendo de seus requisitos de conformidade ou governança.

Práticas recomendadas de segurança do Azure

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

Você deve seguir as práticas recomendadas de segurança Azure - Cloud Adoption Framework para organizar seus sistemas, infraestrutura de nuvem, pessoal de TI e estruturas de equipe e treinamentos corporativos de conscientização sobre segurança cibernética.

Exfiltração de dados por meio do Sistema de Nomes de Domínio

A exfiltração de dados por meio do DNS (Sistema de Nomes de Domínio) representa uma preocupação significativa de segurança para as organizações, pois usa um protocolo que normalmente é permitido por meio de firewalls e raramente monitorado para atividades mal-intencionadas. Os invasores podem explorar consultas DNS para extrair secretamente dados confidenciais de sistemas comprometidos codificando informações em nomes de domínio ou usando técnicas de túnel DNS. Esse método é insidioso porque o tráfego DNS parece legítimo e geralmente ignora as ferramentas tradicionais de monitoramento de segurança.

Em ataques de exfiltração de dados baseados em DNS, atores mal-intencionados codificam dados roubados em consultas DNS, muitas vezes usando técnicas como rotulagem de subdomínio ou consultas de registro TXT. Por exemplo, um invasor pode dividir dados confidenciais em partes e inserir cada parte como um subdomínio em consultas DNS para domínios controlados por invasores. Os dados podem ser extraídos de logs DNS no servidor DNS do invasor. Essa abordagem permite a exfiltração gradual de grandes conjuntos de dados, mantendo um perfil baixo, já que as consultas DNS aparecem como solicitações normais de resolução de nomes.

Abordando a exfiltração de dados com a Política de Segurança do DNS do Azure

DNS do Azure Política de Segurança fornece proteção abrangente contra ataques de exfiltração de dados baseados em DNS, oferecendo controle granular sobre o tráfego DNS em redes virtuais Azure. Esse serviço permite que as organizações implementem medidas de segurança proativas que podem detectar, alertar e bloquear atividades DNS suspeitas antes que os dados possam ser exfiltrados com êxito.

A Política de Segurança do DNS do Azure trata da exfiltração de dados de DNS por meio de vários mecanismos principais. Primeiro, ele fornece a capacidade de criar regras de tráfego DNS que podem bloquear consultas a domínios mal-intencionados conhecidos ou padrões de domínio suspeitos comumente usados em tentativas de exfiltração. As organizações podem manter listas de blocos de domínios associados à infraestrutura de comando e controle ou serviços de exfiltração de dados. Em segundo lugar, o serviço oferece recursos abrangentes de registro de logs de DNS, capazes de capturar todas as consultas e respostas de DNS em redes virtuais protegidas. Esse registro em log permite que as equipes de segurança analisem padrões de tráfego DNS e identifiquem possíveis tentativas de exfiltração. Em terceiro lugar, o mecanismo de política dá suporte à filtragem de domínio curinga, permitindo que as organizações bloqueiem categorias inteiras de domínios suspeitos ou implementem listas de permissão para destinos DNS aprovados.

A implementação de DNS do Azure Política de Segurança cria várias camadas de defesa contra a exfiltração de dados DNS. As regras de tráfego podem ser configuradas com diferentes níveis de prioridade, permitindo políticas de segurança complexas que equilibram a segurança com requisitos operacionais. O serviço dá suporte ao bloqueio em tempo real de consultas mal-intencionadas, ao mesmo tempo em que fornece logs detalhados para análise forense e busca de ameaças. Além disso, os links de rede virtual garantem que as políticas de segurança DNS sejam aplicadas consistentemente em todos os recursos em segmentos de rede protegidos, criando um perímetro de segurança abrangente que é difícil para os invasores ignorarem.

Para implantações do Azure Enclave, a Política de Segurança do DNS do Azure deve ser integrada como parte da arquitetura geral de segurança. As organizações devem configurar políticas de segurança DNS para monitorar e controlar o tráfego DNS de cargas de trabalho de enclave, garantindo que os dados confidenciais permaneçam protegidos mesmo que cargas de trabalho individuais fiquem comprometidas. A revisão regular e a atualização de listas de domínio DNS, combinadas com o monitoramento contínuo de logs DNS, fornece proteção contínua contra ameaças baseadas em DNS em evolução e ajuda a manter a integridade de segurança do ambiente do Enclave Azure.

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

Implementando políticas de segurança de DNS de negação-padrão

Para segurança máxima em ambientes de enclave Azure, as organizações devem implementar uma abordagem "negar por padrão, permitir por exceção" à filtragem DNS. Esse modelo de segurança garante que todas as consultas DNS sejam bloqueadas, a menos que explicitamente permitidas, fornecendo a proteção mais forte contra exfiltração de dados baseadas em DNS e comunicações de comando e controle.

A abordagem de negação por padrão é implementada usando uma estrutura de regras de DNS em dois níveis na Política de Segurança de DNS do Azure:

Etapa 1: Criar a regra de negação padrão Crie uma Lista de Domínio DNS contendo apenas o domínio . raiz (ponto). Esse domínio curinga corresponde a todas as consultas DNS possíveis. Associe essa lista de domínios a uma regra de tráfego DNS configurada com:

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

Essa regra serve como o catch-all que bloqueia qualquer consulta DNS não explicitamente permitida por regras de prioridade mais alta.

Etapa 2: Criar regras de lista de permissões Crie listas de domínio DNS separadas contendo domínios específicos necessários para operações comerciais legítimas. Eles podem incluir:

  • Serviços de Azure essenciais (por exemplo, *.azure.com, ) *.microsoft.com
  • Domínios corporativos e serviços confiáveis que não são da Microsoft
  • Serviços de atualização do sistema operacional
  • Domínios de autoridade de certificação

Associe as listas de permissões às regras de tráfego DNS configuradas com:

  • Prioridade: 500-1000 (prioridade maior do que a negação padrão)
  • Ação: Permitir
  • Listas de domínios: domínios aprovados específicos

Processamento de regras baseado em prioridade A Política de Segurança do DNS do Azure processa as regras na ordem de prioridade (números mais baixos = prioridade mais alta). Quando uma consulta DNS é feita:

  1. O sistema primeiro avalia as regras de permissão de alta prioridade (prioridade 500-1000)
  2. Se o domínio corresponder a uma lista de permissões, a consulta será permitida
  3. Se nenhuma regra allow corresponder, a consulta passará para a regra padrão de negação (prioridade 65000) e o tráfego será bloqueado

Essa abordagem fornece várias vantagens de segurança:

  • Modelo de confiança zero: nenhuma consulta DNS é permitida, a menos que explicitamente autorizada
  • Controle granular: as organizações podem controlar com precisão quais domínios estão acessíveis
  • Trilha de auditoria: todas as consultas bloqueadas são registradas em log, fornecendo visibilidade sobre possíveis ameaças
  • Atualizações incrementais: novos domínios aprovados podem ser adicionados para permitir listas sem modificar a regra de negação padrão

Implementação de exemplo:

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 essa abordagem devem começar com um inventário abrangente de domínios necessários e refinar gradualmente a lista de domínios permitidos com base nas necessidades operacionais e nos logs de segurança. A revisão regular de consultas bloqueadas ajuda a identificar domínios legítimos que talvez precisem ser adicionados às listas de permissões, mantendo uma postura de segurança forte.

Implementando políticas de DNS de negação por padrão com o Servidor DNS do Windows

Para ambientes que não podem utilizar a Política de Segurança do DNS do Azure ou exigem controle local de DNS, uma segurança semelhante de negação por padrão pode ser implementada usando o Servidor DNS do Windows com recursos de Política de DNS. Essa abordagem fornece proteção comparável contra a exfiltração de dados baseada em DNS, mantendo a compatibilidade com a infraestrutura de Windows existente.

Windows servidor DNS (Windows Server 2016 e posterior) dá suporte à funcionalidade de Política DNS que permite que as organizações implementem regras de filtragem DNS sofisticadas. O modelo de negação por padrão pode ser obtido por meio de uma combinação de regras de política DNS e configurações de zona.

Grupos de recursos gerenciados no enclave Azure

Os grupos de recursos que contêm recursos gerenciados por Azure Enclave.

Grupo de recursos gerenciados pela comunidade

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

O nome do grupo de recursos gerenciados pela comunidade segue esta convenção de nomenclatura: myCommunityName-HostedResources-<GUID>. Cada implantação da comunidade cria esse grupo de recursos e coloca a infraestrutura da comunidade dentro dele. Quando você exclui sua comunidade, o provedor de recursos do enclave Azure exclui automaticamente o grupo de recursos gerenciados pela comunidade.

Captura de tela mostrando um exemplo dos recursos da comunidade gerenciados por Azure Enclave.

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

  • Você não pode especificar um grupo de recursos existente para o grupo de recursos gerenciados pela comunidade.
  • Você não pode especificar uma assinatura diferente para o grupo de recursos gerenciados pela comunidade.
  • Você não pode alterar o nome do grupo de recursos gerenciados pela comunidade depois que a comunidade é criada.
  • Você não pode especificar nomes para os recursos gerenciados dentro do grupo de recursos gerenciados pela comunidade.
  • Você não pode modificar ou excluir tags criadas pelo Azure de recursos gerenciados no grupo de recursos gerenciado pela comunidade.

Se você modificar ou excluir marcas, recursos e outras propriedades de recursos criadas por Azure no grupo de recursos gerenciados pela comunidade, poderá ver resultados inesperados. À medida que Azure Enclave gerencia o ciclo de vida da infraestrutura no grupo de recursos gerenciados pela comunidade, qualquer alteração pode potencialmente mover seu enclave para um estado sem suporte.

Um cenário comum em que você deseja modificar recursos é por meio de marcas. O Azure Enclave permite que você crie e modifique tags que são propagadas aos recursos no grupo de recursos gerenciado pela comunidade. O ideal é criar ou modificar marcas personalizadas, por exemplo, para atribuir uma unidade de negócios ou um centro de custo. Isso também pode ser feito criando políticas de Azure com um escopo no grupo de recursos gerenciados pela comunidade.

Note

Se você não tiver o bloqueio do grupo de recursos gerenciado pela comunidade habilitado, poderá modificar diretamente qualquer recurso no grupo de recursos gerenciados pela comunidade. Modificar diretamente os recursos no grupo de recursos gerenciados da comunidade pode fazer com que o enclave fique instável ou não responda.

Grupo de recursos gerenciados pelo enclave

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

O nome do grupo de recursos gerenciados pelo enclave segue esta convenção de nomenclatura: myEnclaveName-HostedResources-<GUID>. Cada implantação de enclave cria esse grupo de recursos e coloca a infraestrutura de enclave dentro dele. Quando você exclui o enclave, o provedor de recursos do enclave Azure exclui automaticamente o grupo de recursos gerenciados pelo enclave.

Captura de tela mostrando um exemplo dos recursos de enclave gerenciados pelo enclave Azure.

O grupo de recursos gerenciados do enclave tem as seguintes limitações:

  • Você não pode especificar um grupo de recursos existente para o grupo de recursos gerenciados pelo enclave.
  • Você não pode especificar uma assinatura diferente para o grupo de recursos gerenciados pelo enclave.
  • Você não pode alterar o nome do grupo de recursos gerenciados do enclave após a criação do enclave.
  • Você não pode especificar nomes para os recursos gerenciados no grupo de recursos gerenciados do enclave.
  • Você não pode modificar ou excluir tags criadas pelo Azure de recursos gerenciados no grupo de recursos gerenciados do enclave.

Se você modificar ou excluir marcas, recursos e outras propriedades de recursos criadas por Azure no grupo de recursos gerenciados do enclave, poderá obter resultados inesperados, como erros de rede, acesso e monitoramento. À medida que Azure Enclave gerencia o ciclo de vida da infraestrutura no grupo de recursos gerenciados do enclave, qualquer alteração pode potencialmente mover seu enclave para um estado sem suporte.

Um cenário comum em que você deseja modificar recursos é por meio de marcas. O Azure Enclave permite que você crie e modifique tags que são propagadas para os recursos no grupo de recursos gerenciado do enclave. O ideal é criar ou modificar marcas 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 com a criação de políticas do Azure com um escopo no grupo de recursos gerenciado de enclave.

Warning

Modificar recursos no grupo de recursos gerenciados do enclave pode fazer com que o enclave fique instável ou não responda.

Grupo de recursos de carga de trabalho

A carga de trabalho está vinculada a um ou mais grupos de recursos em que você pode criar e organizar seus recursos de Azure.

Adicionar um grupo de recursos a uma carga de trabalho

A adição de um novo grupo de recursos normalmente exige que o usuário tenha permissões para criar um novo grupo de recursos. As funções de assinatura Owner ou Contributor têm essa permissão, mas a pessoa que está criando o grupo de recursos da carga de trabalho pode não ter nem precisar dessa permissão privilegiada. Azure Enclave tenta três maneiras de criar o novo grupo de recursos que vão desde os requisitos de permissão de usuário mais altos até os mais baixos, oferecendo flexibilidade para o usuário:

  • Opção 1: requer as permissões mais privilegiadas para o indivíduo que cria ou atualiza a carga de trabalho, fornecendo controle total, mas necessitando de acesso elevado.
  • Opção 2: envolve configuração manual pelo usuário para conceder ao nosso aplicativo a propriedade no nível da assinatura Mission Enclave, o que talvez não esteja de acordo com suas preferências.
  • Opção 3: não requer permissões para o usuário ou o Mission Enclave aplicativo, tornando-o o método mais fácil, mas impondo uma relação 1:1 estrita entre o grupo de recursos e a carga de trabalho.

Cada opção tem benefícios e limitações, controle de balanceamento, conveniência e flexibilidade para atender a necessidades variadas. Essas opções são avaliadas a partir da opção 1 e a primeira opção a ser bem-sucedida é usada para criar o novo grupo de recursos.

Depois de criar um grupo de recursos de carga de trabalho usando a opção 3, você verá um aviso de que a opção 3 não pode ser usada para os próximos grupos de recursos de carga de trabalho nessa carga de trabalho. Você também pode criar uma nova carga de trabalho e criar um novo grupo de recursos de carga de trabalho usando a opção 3 novamente.

Adicione um grupo de recursos ao enclave:

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

Como um grupo de recursos de carga de trabalho é diferente de outros grupos de recursos Azure?

Um grupo de recursos de carga de trabalho é um componente crítico da segurança e conformidade do enclave Azure porque é aí que seus recursos importantes são criados. Como esses grupos de recursos de carga de trabalho estão vinculados a uma carga de trabalho e a carga de trabalho está vinculada a um enclave, Azure Enclave gerencia a exclusão de grupos de recursos gerenciados por carga de trabalho.

Além disso, a política é aplicada aos grupos de recursos de carga de trabalho. Assim como as políticas da comunidade se aplicam ao enclave, as políticas do enclave se aplicam aos recursos de carga de trabalho e aos grupos de recursos de carga de trabalho. Quando você cria um novo grupo de recursos de carga de trabalho, as funções são definidas no nível do enclave e são herdadas da assinatura. Algumas dessas políticas são herdadas da comunidade, e você também pode criar políticas no enclave que são propagadas para cargas de trabalho e grupos de recursos da carga de trabalho.

Organizando recursos em grupos de recursos de carga de trabalho

Se você quiser dividir seus recursos em dois grupos de recursos, poderá escolher uma destas opções:

  • dividir esses recursos entre dois grupos de recursos vinculados a uma carga de trabalho
  • dividir esses recursos entre duas cargas de trabalho cada uma com um ou mais grupos de recursos

Exclusão de carga de trabalho

Quando uma exclusão de carga de trabalho é solicitada, os grupos de recursos de carga de trabalho são verificados para verificar se eles estão vazios. Se os grupos de recursos de carga de trabalho contiverem recursos, a exclusão da carga de trabalho solicitada falhará e mostrará um erro. Para excluir a carga de trabalho e os grupos de recursos da carga de trabalho, primeiro esvazie os grupos de recursos da carga de trabalho. Grupos de recursos de carga de trabalho vazios ajudam a evitar a exclusão acidental de recursos importantes.

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

O grupo de recursos gerenciados da carga de trabalho tem as seguintes limitações:

  • Você não pode especificar um grupo de recursos existente para o grupo de recursos gerenciados de carga de trabalho.
  • Você não pode especificar uma assinatura diferente para o grupo de recursos gerenciados da carga de trabalho.
  • Você não pode alterar o nome do grupo de recursos gerenciados da carga de trabalho após a criação da carga de trabalho.
  • Você não pode modificar nem excluir tags criadas pelo Azure de recursos gerenciados no grupo de recursos gerenciados da carga de trabalho.

Um cenário comum em que você deseja modificar recursos é por meio de marcas. O Azure Enclave permite criar e modificar tags que são propagadas aos recursos no grupo de recursos gerenciados da carga de trabalho. O ideal é criar ou modificar marcas personalizadas, por exemplo, para atribuir uma unidade de negócios ou um centro de custo. A marcação também pode ser obtido com a criação de políticas do Azure com um escopo no grupo de recursos gerenciado da carga de trabalho.

Outras práticas recomendadas de Azure

À medida que você cria suas comunidades, enclaves e cargas de trabalho em Azure, é importante ter em mente os seguintes princípios universais de design:

  • Last updated on