Abordagem de teste para zonas de implementação do Azure

Algumas organizações podem querer testar as definições e atribuições da Política do Azure da implantação da plataforma de zonas de aterrissagem do Azure, funções e atribuições personalizadas de controle de acesso baseado em função (RBAC) e assim por diante. Os testes podem ser concluídos por meio da automação usando modelos do Azure Resource Manager (modelos ARM), Terraform , Bicepou manualmente por meio do portal do Azure. Esta orientação fornece uma abordagem que pode ser usada para testar alterações e seu impacto em uma implantação de plataforma de zonas de aterrissagem do Azure.

Este artigo também pode ser usado com a automação da plataforma e a orientação da área de design crítico de DevOps no que diz respeito às equipes e tarefas das funções PlatformOps e Central. Além disso, isto pode ser combinado com a orientação em Adotar limites orientados por políticas para técnicas de implantação de alterações de políticas em uma implementação de landing zones do Azure.

Esta orientação é mais adequada para organizações com processos robustos de gerenciamento de alterações que regem as alterações na hierarquia do grupo de gerenciamento de produção. A hierarquia do grupo de gestão canário pode ser usada de forma independente para elaborar e testar implantações antes de as colocar no ambiente de produção.

Definição da plataforma

As zonas de aterrissagem do Azure ajudam você a projetar e implantar os componentes necessários da plataforma Azure para permitir que você construa e operacionalize zonas de aterrissagem em escala.

Os recursos da plataforma no escopo deste artigo e desta abordagem de teste são:

Exemplos de cenários e resultados

Um exemplo desse cenário é uma organização que deseja testar o impacto e o resultado de uma nova Política do Azure para governar recursos e configurações em todas as zonas de destino, de acordo com o princípio de design de governança orientado por políticas. Eles não querem fazer essa alteração diretamente no ambiente de produção, pois estão preocupados com o impacto que isso pode ter.

Usar o ambiente canário para testar essa alteração de plataforma permitirá que a organização implemente e analise o impacto e o resultado da alteração da Política do Azure. Esse processo garantirá que ele satisfaça os requisitos da organização antes de implementar a Política do Azure em seu ambiente de produção.

Um cenário semelhante pode ser uma alteração nas atribuições de função RBAC do Azure e nas associações de grupo do Microsoft Entra. Pode exigir uma forma de teste antes que as alterações sejam feitas no ambiente de produção.

Figura 1: Hierarquia dos grupos de gestão das Canárias.

Como mostra o diagrama, toda a hierarquia do grupo de gerenciamento de produção das zonas de aterrissagem do Azure é duplicada sob o Tenant Root Group. O nome canário é anexado aos nomes de exibição e IDs do grupo de gerenciamento. As identificadores devem ser únicos dentro de uma única instância do Microsoft Entra.

A hierarquia do grupo de gerenciamento canário é então usada para simplificar o teste dos seguintes tipos de recursos:

• Grupos de gestão
  • Posicionamento da subscrição
• RBAC
  • Funções (incorporadas e personalizadas)
  • Atribuições
• Política do Azure
  • Definições (incorporadas e personalizadas)
  • Iniciativas, também conhecidas como definições estabelecidas
  • Atribuições

E se você não quiser implantar a hierarquia do grupo de gerenciamento canário?

Se você não quiser implantar a hierarquia de grupo de gerenciamento canário, poderá testar os recursos da plataforma dentro da hierarquia do ambiente de produção usando assinaturas de área restrita , conforme mostrado no diagrama.

Figura 2: Hierarquia do grupo de gerenciamento de zonas de aterrissagem do Azure destacando áreas restritas.

Para testar a Política do Azure e o RBAC nesse cenário, você precisa de uma única assinatura do Azure com a função RBAC do Proprietário atribuída à identidade que deseja concluir o teste como, por exemplo, Conta de Usuário, Entidade de Serviço ou Identidade de Serviço Gerenciado. Essa configuração permite que você crie, atribua e corrija definições e atribuições da Política do Azure somente no escopo da assinatura de área restrita.

Essa abordagem de área restrita também pode ser usada para testes RBAC dentro da assinatura, por exemplo, se você estiver desenvolvendo uma nova função RBAC personalizada para conceder permissões para um caso de uso específico. Todos esses testes podem ser feitos na subscrição de sandbox e testados antes de criar e atribuir funções nos níveis superiores da hierarquia.

Um benefício dessa abordagem é que as assinaturas de área restrita podem ser usadas pelo tempo necessário e, em seguida, excluídas do ambiente.

No entanto, essa abordagem não permite que você teste com a herança de políticas RBAC e Azure da hierarquia do grupo de gerenciamento.

Documentação de orientação para a implementação

Abaixo estão orientações sobre como implementar e utilizar a hierarquia de grupos de gestão canário para zonas de aterragem do Azure, juntamente com uma hierarquia de grupos de gestão de zonas de aterragem do ambiente de produção do Azure.

1. Use entidades de serviço (SPNs) ou Identidades Geridas (MIs) separadas da Microsoft Entra que recebam permissões sobre o ambiente de produção relevante ou a hierarquia de grupos de gestão das zonas de destino no Azure.
   • Esta orientação segue o princípio do menor privilégio (PoLP)
2. Use diretórios separados dentro de um repositório git, ramos ou repositórios para armazenar o IaC para as implementações de zonas de aterragem do Azure no ambiente de produção e no ambiente de teste canário.
   • Usando as entidades de serviço (SPNs) ou identidades gerenciadas (MIs) relevantes do Microsoft Entra como parte dos pipelines de CI/CD, dependendo de qual hierarquia está sendo implantada.
3. Implemente políticas de ramificação git ou segurança para o ambiente canário como você tem em vigor para o ambiente de produção.
   • Considere reduzir o número de aprovadores e verificações para que o ambiente canário rapidamente falhe.
4. Use as mesmas ações do Azure Pipelines ou GitHub que usam variáveis de ambiente para alterar qual hierarquia está sendo implantada. Outra opção é clonar os pipelines e alterar as configurações codificadas para definir qual hierarquia está sendo implantada.
   • Usar modelos de DevOps do Azure Pipelines ou Modelos de Fluxo de Trabalho de Ações do GitHub ajudará você a aderir ao princípio Não se repita (DRY).
5. Tenha um conjunto de assinaturas canárias numa conta de faturação separada, por exemplo, uma seção de fatura de Conta do Enterprise Agreement (EA) ou do Microsoft Customer Agreement (MCA), que possa ser movido dentro da hierarquia do grupo de gestão de canários conforme necessário.
   • Pode ser benéfico ter um conjunto de recursos sempre implantados nas assinaturas do ambiente canário para acelerar o teste e a validação de alterações no ambiente canário.
6. Tenha um conjunto de arquiteturas de carga de trabalho de aplicativo de exemplo que você pode implantar nas assinaturas canary no ambiente canary para testar as alterações da Política do Azure e RBAC. Isso ajuda você a validar as alterações antes de implantar e promover as alterações na produção.
   • Essas cargas de trabalho de exemplo podem ser implantadas usando os mesmos modelos de IaC usados para implantar as cargas de trabalho do aplicativo de produção. Isso ajudará você a garantir que o ambiente canário esteja em sincronia com o ambiente de produção e que as alterações que você está testando sejam válidas e aplicáveis ao ambiente de produção.
   • Você deve revisar e atualizar continuamente as cargas de trabalho de exemplo para garantir que elas sejam relevantes e estejam atualizadas com a arquitetura e os padrões de design mais recentes em sua organização.
   • Se você fornecer arquiteturas de referência para suas equipes de aplicativos, considere implantá-las também no ambiente canário. Isso ajuda a validar as alterações em relação às arquiteturas de referência e garantir que elas sejam aplicáveis ao ambiente de produção.
7. Envie todos os logs de atividade do Azure para todas as assinaturas do Azure, incluindo quaisquer assinaturas de ambiente canário, para o espaço de trabalho do Azure Log Analytics no ambiente de produção, de acordo com as recomendações de design para as zonas de aterrissagem do Azure.
   • Isso ajuda suas equipes de segurança e operações a monitorar o ambiente canário para quaisquer alterações ou problemas que possam surgir do teste da Política do Azure e das alterações do RBAC no ambiente de produção.

Usando um único inquilino de Microsoft Entra

Considerações a ter em conta ao utilizar um único tenant do Microsoft Entra incluem:

• O uso de um único locatário segue as recomendações de design de zonas de aterrissagem do Azure para locatários do Microsoft Entra.
  • Em um único locatário do Microsoft Entra, pode-se usar os diferentes grupos do Microsoft Entra para ambientes de zonas de destino de produção e canárias do Azure com os mesmos utilizadores atribuídos à hierarquia de grupos de gestão relevante.
• Custos de licenciamento do Microsoft Entra ID aumentados ou duplicados devido a várias identidades em diferentes locatários do Microsoft Entra. Isso é particularmente relevante para clientes que usam os recursos do Microsoft Entra ID P1 ou P2.
• As alterações do RBAC são mais complexas em ambientes canary e de produção, pois é provável que os utilizadores e grupos não sejam idênticos em ambos os tenants do Microsoft Entra.
  • Considere que as IDs de usuários e grupos não serão as mesmas entre os locatários do Microsoft Entra, pois são globalmente exclusivas.
• Reduz a complexidade e a sobrecarga de gerenciamento causadas pelo gerenciamento de vários locatários do Microsoft Entra.
  • Usuários privilegiados que devem manter o acesso e entrar em locatários separados para executar testes podem fazer alterações acidentais no ambiente de produção em vez do ambiente canário, por exemplo.
• Reduz a probabilidade de desvio de configuração e falhas de implantação.
• Não requer a criação de segurança extra nem processos de "quebra-vidro" ou acesso de emergência.
• Reduz o atrito e o tempo necessário para implementar alterações na implantação das zonas de aterrissagem do Azure.

Próximos passos

Depois de ter um ambiente canário instalado, você pode começar a testar as alterações da Política do Azure e do RBAC antes de implantá-las na hierarquia do grupo de gerenciamento de zonas de aterrissagem do Azure de produção.

Depois de testar as alterações às Políticas do Azure no ambiente canário, pode promovê-las para o ambiente de produção seguindo a mesma abordagem documentada na orientação Adotar guarda-corpos orientados por políticas . Isso é feito usando o recurso de modo de aplicação das atribuições de política. O uso da abordagem documentada nesta orientação permite que você passe por uma fase de teste extra antes de aplicar a Política do Azure no ambiente de produção no efeito desejado, o que ajudará você a criar confiança nas alterações da Política do Azure que está fazendo.

Você também pode revisar ambientes de área restrita para suas equipes de aplicativos usarem para desenvolvimento e teste de suas cargas de trabalho. Esse é um conceito separado do ambiente canário e é usado para fornecer um ambiente seguro para as equipes de aplicativos desenvolverem e testarem suas cargas de trabalho antes de serem implantadas na produção.