Personalizar a arquitetura da zona de destino do Azure para atender aos 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 aterrissagem do Azure com Azure Virtual WAN
- Zona de destino do Azure com hub e spoke tradicional
- Fundação de zona de aterrissagem do Azure
- Zona de destino 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 destino do Azure e as práticas recomendadas nas áreas de design.
As implementações de referência são baseadas nas melhores práticas e aprendizados das equipes da Microsoft a partir de compromissos com clientes e parceiros. Esse 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 design de arquitetura.
Como nem todos os casos de uso são iguais, nem todas as organizações podem usar uma abordagem de implementação exatamente da maneira que se pretendia. Você precisa entender as considerações quando um requisito de personalização é identificado.
O que é um arquétipo de zona de destino nas zonas de destino do 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 rede.
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. Pense no que é aplicado nos níveis superiores na hierarquia de recursos quando você projeta os níveis inferiores.
Há uma relação estreita entre grupos de gerenciamento e arquétipos de zona de destino, mas um grupo de gerenciamento sozinho não é um arquétipo de zona de destino. Em vez disso, ele faz parte da estrutura usada para implementar cada um dos arquétipos de zona de destino no ambiente.
Você pode ver essa relação na arquitetura conceitual da 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 inferiores 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 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 para Nuvem.
- Rede virtual com espaços de endereço IP gerenciados para cargas de trabalho de aplicativo.
- Vinculação de redes virtuais a uma Proteção de Rede de DDoS (negação de serviço distribuído).
Nota
Nas implementações de referência da zona de aterrissagem do Azure, as políticas do Azure com os efeitos DeployIfNotExists e Modify são usadas para obter a implantação de alguns dos recursos mencionados anteriormente. 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 integrados para a arquitetura conceitual da zona de aterrissagem 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 se aplicar à sua organização e atender às suas necessidades. Talvez você queira fazer alterações nesses arquétipos 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.
Talvez você também queira criar alterações em outro lugar na hierarquia de recursos. Ao planejar a hierarquia para a implementação de zonas de destino do Azure para sua organização, siga as diretrizes nas áreas de design .
Os seguintes exemplos de arquétipo de zona de destino da arquitetura conceitual ajudam você a entender sua finalidade e o uso pretendido:
| 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 destina-se a 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 destina-se a 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. |
| Caixa de areia | O grupo de gestão dedicado exclusivamente 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 arquétipos de zona de destino permitidos para cargas de trabalho de aplicativo. Talvez seja necessário adaptar os arquétipos da zona de destino para atender às suas necessidades e requisitos.
Antes de adaptar os arquétipos da zona de destino, é 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 destino do Azure.
Duas áreas da hierarquia são realçadas. Uma está abaixo das Zonas de Pouso, e a outra está abaixo da Plataforma.
Adaptar os arquétipos da zona de destino do aplicativo
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, você pode ter um novo requisito para hospedar um conjunto de cargas de trabalho de aplicativo que precisam atender aos requisitos de conformidade da PCI (indústria de cartões de pagamento). Mas esse novo 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 você pode colocar novas assinaturas ou mover assinaturas existentes do Azure para o novo grupo de gerenciamento PCI para que ele herde as políticas necessárias e forme o novo arquétipo.
Outro exemplo é Microsoft Cloud for Sovereignty, que adiciona grupos de gerenciamento para computação confidencial e é alinhado para uso em setores regulamentados. Microsoft Cloud for Sovereignty fornece ferramentas, diretrizes e guardrails para a adoção da nuvem pública com controles de soberania apropriados.
Dica
Você precisa saber o que considerar e o que acontece ao mover assinaturas do Azure entre grupos de gerenciamento em relação ao RBAC e ao Azure Policy. Para obter mais informações, consulte Transição de ambientes existentes do Azure para a arquitetura conceitual da zona de destino do Azure.
Personalizar arquétipos de zona de aterrissagem 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 da 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 dos do grupo de gerenciamento Management.
Crie um grupo de gerenciamento Segurança abaixo do grupo de gerenciamento Plataforma na hierarquia. Você pode atribuir as atribuições necessárias do Azure Policy e do RBAC a ele.
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 personalizada
O diagrama a seguir mostra uma hierarquia de zona de destino do Azure personalizada. Ele usa exemplos do diagrama anterior.
Pontos a serem considerados
Considere os seguintes pontos ao pensar em adaptar sua implementação de arquétipos de zona de destino do Azure na hierarquia:
Personalizar 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 crie novamente sua hierarquia organizacional, equipes ou departamentos em arquétipos.
Sempre tente criar os arquétipos e a hierarquia existentes para atender aos novos requisitos.
Crie apenas novos arquétipos quando realmente forem necessários.
Por exemplo, um novo requisito de conformidade, como pci, é necessário apenas para um subconjunto de cargas de trabalho de aplicativo e não precisa se aplicar a todas as cargas de trabalho.
Crie apenas novos arquétipos nas áreas realçadas 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 obter mais informações, consulte Como lidamos com zonas de destino de carga de trabalho de desenvolvimento/teste/produção na arquitetura conceitual das zonas de destino do Azure?
Se você é proveniente de um ambiente brownfield ou está procurando uma abordagem para hospedar assinaturas no Grupo de Gerenciamento de Zonas de Destino com políticas em modo de imposição "apenas para auditoria", examine Cenário: fazer a transição de um ambiente duplicando um grupo de gerenciamento de zona de destino