Personalize a arquitetura da zona de aterrissagem do Azure para atender aos requisitos

Como parte da orientação da zona de aterrissagem do Azure, várias opções de implementação de referência estão disponíveis:

  • Zona de aterrissagem do Azure com a WAN Virtual do Azure
  • Zona de aterrissagem do Azure com hub e spoke tradicionais
  • Fundação da zona de aterrissagem do Azure
  • Zona de aterrissagem do Azure para pequenas empresas

Essas opções podem ajudar sua organização a começar rapidamente usando configurações que fornecem a arquitetura conceitual da zona de aterrissagem do Azure e as práticas recomendadas nas áreas de design.

As implementações de referência são baseadas nas práticas recomendadas e aprendizados das equipes da Microsoft a partir de compromissos com clientes e parceiros. Este conhecimento representa o lado "80" da regra 80/20. As várias implementações tomam posições sobre decisões técnicas que fazem parte do processo de projeto de arquitetura.

Como nem todos os casos de uso são iguais, nem todas as organizações podem usar uma abordagem de implementação da maneira exata pretendida. Você precisa entender as considerações quando um requisito de adaptação é identificado.

O que é um arquétipo de zona de pouso nas zonas de pouso do Azure?

Um arquétipo de zona de aterrissagem descreve o que precisa ser verdadeiro para garantir que uma zona de aterrissagem (assinatura do Azure) atenda aos requisitos esperados de ambiente e conformidade em um escopo específico. Exemplos incluem:

  • Atribuições da Política do Azure.
  • Atribuições de controle de acesso baseado em função (RBAC).
  • Recursos geridos centralmente, como a rede.

Considere cada grupo de gerenciamento na hierarquia de recursos como contribuindo para a saída final do arquétipo da zona de aterrissagem devido à maneira como a herança de política funciona no Azure. Pense no que é aplicado nos níveis superiores na hierarquia de recursos ao projetar os níveis inferiores.

Há uma relação estreita entre grupos de gerenciamento e arquétipos de zona de pouso, mas um grupo de gerenciamento sozinho não é um arquétipo de zona de pouso. Em vez disso, ele faz parte da estrutura usada para implementar cada um dos arquétipos da zona de pouso em seu ambiente.

Você pode ver essa relação na arquitetura conceitual da zona de aterrissagem do Azure. As atribuições de política são criadas no grupo de gerenciamento raiz intermediário, por exemplo , Contoso, para configurações que devem ser aplicadas a todas as cargas de trabalho. Mais atribuições de política são criadas em níveis inferiores da hierarquia para requisitos mais específicos.

O posicionamento da assinatura dentro da hierarquia do grupo de gerenciamento determina o conjunto resultante de atribuições de Política do Azure e controle de acesso (IAM) que são herdadas, aplicadas e impostas a essa zona de aterrissagem específica (assinatura do Azure).

Mais processos e ferramentas podem ser necessários para garantir que uma zona de desembarque tenha os recursos gerenciados centralmente necessários. Alguns exemplos incluem:

  • Configurações de diagnóstico para enviar dados de log de atividades para um espaço de trabalho do Log Analytics.
  • Configurações de exportação contínua para o Microsoft Defender for Cloud.
  • Rede virtual com espaços de endereços IP gerenciados para cargas de trabalho de aplicativos.
  • Ligação de redes virtuais a uma Proteção de Rede de negação de serviço distribuída (DDoS).

Nota

Nas implementações de referência da zona de aterrissagem do Azure, as políticas do Azure com os DeployIfNotExists efeitos e Modifysão usadas para obter a implantação de alguns dos recursos anteriores. Seguem o princípio da conceção da governação orientada por políticas.

Para obter mais informações, consulte Adotar guarda-corpos orientados por políticas.

Arquétipos internos para a arquitetura conceitual da zona de aterrissagem do Azure

A arquitetura conceitual inclui arquétipos de zona de aterrissagem de exemplo para cargas de trabalho de aplicativos, como corp e online. Esses arquétipos podem se aplicar à sua organização e atender às suas necessidades. Você pode querer fazer alterações nesses arquétipos ou criar novos. A sua decisão depende das necessidades e requisitos da sua organização.

Gorjeta

Para rever os arquétipos da zona de aterragem no acelerador de zona de aterragem do Azure, consulte Grupos de gestão no acelerador de zona de aterragem do Azure.

Você também pode querer criar alterações em outro lugar na hierarquia de recursos. Ao planejar a hierarquia para sua implementação de zonas de aterrissagem do Azure para sua organização, siga as diretrizes nas áreas de design.

Os seguintes exemplos de arquétipo de zona de pouso da arquitetura conceitual ajudam você a entender seu propósito e uso pretendido:

Arquétipo da zona de aterragem (grupo de gestão) Finalidade ou utilização
Corp O grupo de gestão dedicado às zonas de desembarque corporativo. Esse grupo é para cargas de trabalho que exigem conectividade ou conectividade híbrida com a rede corporativa por meio do hub na assinatura de conectividade.
Online O grupo de gestão dedicado às zonas de aterragem online. Esse grupo é para cargas de trabalho que podem exigir conectividade direta de entrada/saída da Internet ou para cargas de trabalho que podem não exigir uma rede virtual.
Sandbox O grupo de gerenciamento dedicado para assinaturas que serão usadas apenas para teste e exploração por uma organização. Essas assinaturas serão desconectadas com segurança das zonas de destino corporativas e online. As sandboxes também têm um conjunto menos restritivo de políticas atribuídas para permitir o teste, a exploração e a configuração dos serviços do Azure.

Cenários em que a adaptação pode ser necessária

Como mencionado, fornecemos arquétipos comuns de zona de aterrissagem na arquitetura conceitual da zona de pouso do Azure. Eles são corp e online. Esses arquétipos não são fixos e não são os únicos arquétipos de zona de aterrissagem permitidos para cargas de trabalho de aplicativos. Você pode precisar adaptar os arquétipos da zona de pouso para atender às suas necessidades e requisitos.

Antes de personalizar os arquétipos da zona de pouso, é importante entender os conceitos e também visualizar a área da hierarquia que sugerimos que você personalize. O diagrama a seguir mostra a hierarquia padrão da arquitetura conceitual da zona de aterrissagem do Azure.

Diagram that shows Azure landing zone default hierarchy with tailoring areas highlighted.

Duas áreas da hierarquia são destacadas. Um está abaixo das Zonas de Pouso e o outro está abaixo da Plataforma.

Personalize os arquétipos da zona de aterrissagem de aplicativos

Observe a área destacada em azul abaixo do grupo de gerenciamento de Zonas de Desembarque . É o lugar mais comum e seguro na hierarquia adicionar mais arquétipos para atender a novos ou mais requisitos que não podem ser adicionados como mais atribuições de política a um arquétipo existente usando a hierarquia existente.

Por exemplo, você pode ter um novo requisito para hospedar um conjunto de cargas de trabalho de aplicativos que precisam atender aos requisitos de conformidade do setor de cartões de pagamento (PCI). Mas esse novo requisito não precisa se aplicar a todas as cargas de trabalho em todo o seu patrimônio.

Há uma maneira simples e segura de atender a esse novo requisito. Crie um novo grupo de gerenciamento chamado PCI abaixo do grupo de gerenciamento Landing Zones na hierarquia. Você pode atribuir mais políticas, como a iniciativa de política de conformidade regulatória do Microsoft Defender for Cloud para PCI v3.2.1:2018, ao novo grupo de gerenciamento PCI. Esta ação forma um novo arquétipo.

Agora você pode colocar novas assinaturas do Azure ou mover as existentes para o novo grupo de gerenciamento PCI para fazê-lo herdar as políticas necessárias e formar o novo arquétipo.

Outro exemplo é o Microsoft Cloud for Sovereignty, que adiciona grupos de gerenciamento para computação confidencial e está alinhado para uso em setores regulamentados. O Microsoft Cloud for Sovereignty fornece ferramentas, orientação e guarda-corpos para adoção de nuvem pública com controles de soberania apropriados.

Gorjeta

Você precisa saber o que considerar e o que acontece quando você move assinaturas do Azure entre grupos de gerenciamento em relação ao RBAC e à Política do Azure. Para obter mais informações, consulte Transição de ambientes existentes do Azure para a arquitetura conceitual da zona de aterrissagem do Azure.

Arquétipos personalizados da zona de pouso da plataforma

Você também pode personalizar a área destacada em laranja abaixo do grupo de gerenciamento da plataforma . As zonas nesta área são conhecidas como zonas de pouso de plataforma.

Por exemplo, você pode ter uma equipe SOC dedicada que requer seu próprio arquétipo para hospedar suas cargas de trabalho. Essas cargas de trabalho precisam atender aos requisitos de atribuição da Política do Azure e do RBAC diferentes dos do grupo de gerenciamento de Gerenciamento .

Crie um novo grupo de gerenciamento de segurança abaixo do grupo de gerenciamento de plataforma na hierarquia. Você pode atribuir as atribuições necessárias da Política do Azure e do RBAC a ela.

Agora você pode colocar novas assinaturas do Azure ou mover as existentes para o novo grupo de gerenciamento de Segurança para fazê-lo herdar as políticas necessárias e formar o novo arquétipo.

Exemplo de uma hierarquia de zona de aterrissagem personalizada do Azure

O diagrama a seguir mostra uma hierarquia de zona de aterrissagem personalizada do Azure. Ele usa exemplos do diagrama anterior.

Diagram that shows a tailored Azure landing zone hierarchy.

Pontos a considerar

Considere os seguintes pontos quando pensar em adaptar sua implementação de arquétipos de zona de aterrissagem do Azure na hierarquia:

  • Adaptar a hierarquia não é obrigatório. Os arquétipos padrão e a hierarquia que fornecemos são adequados para a maioria dos cenários.

  • Não recrie sua hierarquia organizacional, equipes ou departamentos em arquétipos.

  • Tente sempre construir sobre os arquétipos e hierarquia existentes para atender a novos requisitos.

  • Só crie novos arquétipos quando eles forem realmente necessários.

    Por exemplo, um novo requisito de conformidade, como PCI, é necessário apenas para um subconjunto de cargas de trabalho de aplicativos e não precisa ser aplicado a todas as cargas de trabalho.

  • Crie apenas novos arquétipos nas áreas destacadas mostradas nos diagramas anteriores.

  • Evite ir além de uma profundidade hierárquica de quatro camadas para evitar complexidade e exclusões desnecessárias. Expanda arquétipos horizontalmente em vez de verticalmente na hierarquia.

  • Não crie arquétipos para ambientes como desenvolvimento, teste e produção.

    Para obter mais informações, consulte Como lidamos com zonas de aterrissagem de carga de trabalho de desenvolvimento/teste/produção na arquitetura conceitual de zonas de aterrissagem do Azure?

  • Se vier de um ambiente brownfield ou estiver procurando uma abordagem para hospedar assinaturas no Grupo de Gerenciamento de Zonas de Desembarque com políticas em um modo de imposição "somente auditoria", revise Cenário: Transição de um ambiente duplicando um grupo de gerenciamento de zona de aterrissagem