Adaptar a arquitetura de zona de destino do Azure para atender a requisitos
Como parte das diretrizes de zona de destino do Azure, estão disponíveis diversas opções de implementação de referência:
- Zona de destino do Azure com WAN Virtual do Azure
- Zona de destino do Azure com hub e spoke tradicional
- Fundação da zona de destino do Azure
- Zona de destino do Azure para pequenas empresas
Essas opções podem ajudar sua organização a começar rapidamente a jornada, usando configurações que fornecem a arquitetura conceitual de zona de destino do Azure e as melhores práticas nas áreas de design.
As implementações de referência são baseadas nas melhores práticas e nos aprendizados das equipes da Microsoft em compromissos com clientes e parceiros. Esse conhecimento representa o lado "80" da regra 80/20. As diversas implementações atuam com relação a decisões técnicas que fazem parte do processo de design de arquitetura.
Como nem todos os casos de uso são iguais, nem todas as organizações podem adotar uma abordagem de implementação exatamente conforme o planejado. É necessário entender as considerações ao identificar um requisito de adaptação.
O que é um arquétipo de zona de destino no Azure?
Um arquétipo de zona de destino descreve o que precisa ser verdadeiro para garantir que uma zona de destino (assinatura do Azure) atenda aos requisitos de ambiente e conformidade esperados em um escopo específico. Os exemplos incluem:
- Atribuições do Azure Policy.
- Atribuições de RBAC (controle de acesso baseado em função).
- Recursos gerenciados centralmente, como redes.
Entenda que cada grupo de gerenciamento na hierarquia de recursos contribui para a saída final do arquétipo de zona de destino devido à maneira como a herança de política funciona no Azure. Ao projetar os níveis inferiores da hierarquia de recursos, pense no que é aplicado aos níveis superiores.
Há uma relação próxima entre grupos de gerenciamento e arquétipos de zona de destino, mas um grupo de gerenciamento em si não é um arquétipo. Em vez disso, ele faz parte da estrutura usada para implementar cada um dos arquétipos de zona de destino no ambiente.
É possível ver essa relação na arquitetura conceitual de zona de destino 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 mais baixos da hierarquia para requisitos mais específicos.
O posicionamento da assinatura na hierarquia do grupo de gerenciamento determina o conjunto resultante de atribuições de IAM (controle de acesso e política) e do Azure Policy que são herdadas, aplicadas e impostas a essa zona de destino específica (assinatura do Azure).
Mais processos e ferramentas podem ser necessários para garantir que uma zona de destino tenha os recursos gerenciados centralmente que são necessários. Alguns exemplos incluem:
- Configurações de diagnóstico para enviar dados de log de atividades para um workspace do Log Analytics.
- Configurações de exportação contínua para o Microsoft Defender para Nuvem.
- Rede virtual com espaços de endereço IP gerenciados para cargas de trabalho de aplicativos.
- Vinculação de redes virtuais a uma proteção de rede distribuída de negação de serviço (DDoS).
Observação
Nas implementações de referência de zona de destino do Azure, as políticas do Azure com os efeitosDeployIfNotExists e Modify são usadas para a implantação de alguns dos recursos anteriores. Elas seguem o princípio de design de governança controlada por política.
Para saber mais, confira Adotar verificadores de integridade controlados por política.
Arquétipos internos para a arquitetura conceitual de zona de destino do Azure
A arquitetura conceitual inclui arquétipos de zona de destino de exemplo para cargas de trabalho de aplicativos, como corp e online. Esses arquétipos podem ser aplicados à organização e adequados aos seus requisitos. É possível fazer alterações neles ou criar novos. Sua decisão depende das necessidades e dos requisitos da sua organização.
Dica
Para revisar os arquétipos de zona de destino no acelerador de zonas de destino do Azure, confira Grupos de gerenciamento no acelerador de zonas de destino do Azure.
Também é possível realizar alterações em outros lugares da hierarquia de recursos. Ao planejar a hierarquia para a implementação de zonas de destino do Azure em sua organização, siga as diretrizes nas áreas de design.
Os seguintes exemplos de arquétipos de zona de destino da arquitetura conceitual ajudam você a entender a finalidade e o uso pretendido deles:
| Arquétipo de zona de destino (grupo de gerenciamento) | Finalidade ou uso |
|---|---|
| Corp | O grupo de gerenciamento dedicado para zonas de destino corporativas. 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 gerenciamento dedicado para zonas de destino online. Esse grupo é para cargas de trabalho que podem exigir conectividade de entrada/saída direta da Internet ou para cargas de trabalho que podem não exigir uma rede virtual. |
| Área restrita | 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 áreas restritas também têm um conjunto menos restritivo de políticas atribuídas para habilitar 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
Conforme mencionado, arquétipos de zona de destino comuns são fornecidos na arquitetura conceitual de zona de destino do Azure. Eles são corp e online. Esses arquétipos não são fixos e não são os únicos permitidos para cargas de trabalho de aplicativos. Pode ser necessário adaptá-los para atender a necessidades e requisitos.
Antes de adaptar os arquétipos de zona de destino, é importante entender os conceitos e visualizar a recomendação da área da hierarquia a ser personalizada. O diagrama a seguir mostra a hierarquia padrão da arquitetura conceitual de zona de destino do Azure.
Duas áreas da hierarquia são realçadas. Uma está abaixo de Zonas de destino e a outra está abaixo de Plataforma.
Adaptar os arquétipos de zona de destino de aplicativos
Observe a área realçada em azul abaixo do grupo de gerenciamento Zonas de destino. Este é o local mais comum e seguro na hierarquia para adicionar mais arquétipos a fim de atender a requisitos novos ou adicionais que não podem ser adicionados como outras atribuições de política a um arquétipo existente usando a hierarquia existente.
Por exemplo, é possível que haja um novo requisito para hospedar um conjunto de cargas de trabalho de aplicativos que precisam atender aos requisitos de conformidade do PCI (setor de cartões de pagamento). Mas esse requisito não precisa se aplicar a todas as cargas de trabalho em toda a sua propriedade.
Há uma maneira simples e segura de atender a esse novo requisito. Crie um grupo de gerenciamento chamado PCI abaixo do grupo de gerenciamento Zonas de destino na hierarquia. É possível atribuir mais políticas, como a iniciativa de política de conformidade regulamentar do Microsoft Defender para Nuvem para PCI v3.2.1:2018, ao novo grupo de gerenciamento PCI. Essa ação forma um novo arquétipo.
Agora é possível colocar novas assinaturas do Azure ou mover as existentes para o novo grupo de gerenciamento PCI a fim de que ele herde as políticas necessárias e forme o novo arquétipo.
Outro exemplo é o Microsoft Cloud for Sovereignty, que adiciona grupos de gerenciamento para computação confidencial e é alinhado para uso em setores regulamentados. O Microsoft Cloud for Sovereignty fornece ferramentas, orientações e barreiras de proteção para a adoção de nuvem pública com controles de soberania apropriados.
Dica
É necessário saber o que considerar e o que acontece em relação ao RBAC e ao Azure Policy ao mover assinaturas do Azure entre grupos de gerenciamento. Para saber mais, confira Transição de ambientes existentes do Azure para a arquitetura conceitual de zona de destino do Azure.
Adaptar os arquétipos de zona de destino da plataforma
Também é possível adaptar a área realçada em laranja abaixo do grupo de gerenciamento Plataforma. As zonas nessa área são conhecidas como zonas de destino de plataforma.
Por exemplo, é possível ter uma equipe de SOC dedicada que precisa do próprio arquétipo para hospedar cargas de trabalho. Essas cargas de trabalho precisam atender a requisitos de atribuição do Azure Policy e do RBAC diferentes daqueles do grupo de gerenciamento Gerenciamento.
Crie um grupo de gerenciamento Segurança abaixo do grupo de gerenciamento Plataforma na hierarquia. É possível designar a ele as atribuições necessárias do Azure Policy e do RBAC.
Agora é possível colocar novas assinaturas do Azure ou mover as existentes para o novo grupo de gerenciamento Segurança a fim de que ele herde as políticas necessárias e forme o novo arquétipo.
Exemplo de uma hierarquia de zona de destino do Azure adaptada
O diagrama a seguir mostra uma hierarquia de zona de destino do Azure adaptada. Ele usa exemplos do diagrama anterior.
Considere o seguinte
Considere os seguintes pontos ao considerar a adaptação de sua implementação de arquétipos de zona de destino do Azure na hierarquia:
Adaptar a hierarquia não é obrigatório. Os arquétipos e a hierarquia padrão fornecidos são adequados para a maioria dos cenários.
Não recrie sua hierarquia organizacional, suas equipes ou seus departamentos em arquétipos.
Sempre tente se basear nos arquétipos e na hierarquia existentes para atender aos novos requisitos.
Só crie arquétipos quando for realmente necessário.
Por exemplo, um novo requisito de conformidade como PCI é necessário somente para um subconjunto de cargas de trabalho de aplicativos e não precisa ser aplicado a todas elas.
Crie arquétipos apenas nas áreas realçadas que foram mostradas nos diagramas anteriores.
Evite incluir uma hierarquia de mais de quatro camadas para evitar complexidades e exclusões desnecessárias. Expanda os arquétipos horizontalmente, em vez de verticalmente, na hierarquia.
Não crie arquétipos para ambientes como desenvolvimento, teste e produção.
Para saber mais, confira Como as zonas de destino de cargas de trabalho de desenvolvimento/teste/produção são manipuladas na arquitetura conceitual de zona de destino do Azure?
Se vier de um ambiente brownfield ou estiver procurando uma abordagem para hospedar assinaturas no Grupo de Gerenciamento de Zonas de Aterrissagem 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