Abordagem de teste para zonas de destino do Azure

Observação

Este artigo se aplica somente ao Microsoft Azure e não a outras ofertas do Microsoft Cloud, como o Microsoft 365 ou o Microsoft Dynamics 365.

Algumas organizações podem querer testar as definições e atribuições do Azure Policy da sua implantação de plataforma em zonas de destino do Azure, além de funções e atribuições personalizadas de controle de acesso baseado em função (RBAC), entre outros itens. Os testes podem ser concluídos por meio da automação usando modelos do ARM (modelos do Azure Resource Manager), Terraform, Bicepou manualmente por meio do portal do Azure. Essa orientação fornece uma abordagem que pode ser usada para testar alterações e seu impacto em uma implantação da plataforma de zonas de destino do Azure.

Este artigo também pode ser usado com as diretrizes da área crítica de automação de plataforma e DevOps, pois está relacionado às equipes e tarefas das funções PlatformOps e Central. Além disso, pode ser combinado com as diretrizes em Adotar guardrails controlados por políticas para técnicas de implementação de alterações de política em uma implantação de zonas de destino do Azure.

Essa 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 de grupos de gerenciamento do canário pode ser usada de forma independente para criar e testar implantações antes de implantá-las no ambiente de produção.

Observação

O termo canário é usado para evitar confusão com ambientes de desenvolvimento ou ambientes de teste. Esse nome é usado apenas para fins ilustrativos. Você pode definir qualquer nome que considere apropriado para o ambiente de zonas de destino do Azure canário.

Da mesma forma, o termo ambiente/hierarquia de produção é usado em todas essas diretrizes para se referir à hierarquia do grupo de gerenciamento de zonas de destino do Azure que sua organização pode ter em vigor que contém as assinaturas e os recursos do Azure para suas cargas de trabalho.

Definição da plataforma

Importante

Essa orientação não é para ambientes de desenvolvimento ou ambientes de teste que serão usados por proprietários de aplicativos ou serviços conhecidos como zonas de destino, cargas de trabalho, aplicativos ou serviços. Eles são posicionados e manipulados dentro da hierarquia de grupos de gerenciamento de zonas de destino do Azure no ambiente de produção e da governança associada (RBAC e Azure Policy).

Para obter diretrizes sobre desenvolvimento, teste, UAT (teste de aceitação do usuário) e ambientes de produção para cargas de trabalho de aplicativo e equipes, consulte Gerenciar ambientes de desenvolvimento de aplicativos em zonas de destino do Azure.

Essas diretrizes são apenas para testes no nível da plataforma e alterações no contexto das zonas de destino do Azure.

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

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

Produto ou serviço	Provedor de recursos e tipo
Grupos de gerenciamento	Microsoft.Management/managementGroups
Associação de assinaturas a grupos de gerenciamento	Microsoft.Management/managementGroups/subscriptions
Definições de política	Microsoft.Authorization/policyDefinitions
Definições de iniciativa de política ou definições de conjunto de políticas	Microsoft.Authorization/policySetDefinitions
Atribuições de política	Microsoft.Authorization/policyAssignments
Definições de função RBAC	Microsoft.Authorization/roleDefinitions
Atribuições de função do RBAC	Microsoft.Authorization/roleAssignments
Assinaturas	Microsoft.Subscription/aliases

Cenários de exemplo e resultados

Um exemplo desse cenário é uma organização que deseja testar o impacto e o resultado de um novo Azure Policy para controlar os recursos e as configurações em todas as zonas de destino, de acordo com o Princípio de design de governança controlado 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 ele pode ter.

Usar o ambiente canário para testar essa alteração de plataforma permitirá que a organização implemente e revise o impacto e o resultado da alteração do Azure Policy. Esse processo garantirá que ele atenda aos requisitos da organização antes que eles implementem o Azure Policy ao seu ambiente de produção.

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

Importante

Essa não é uma abordagem ou padrão de implantação comum para a maioria dos clientes. Não é obrigatório para implantações de zonas de aterrissagem do Azure.

Figura 1: Hierarquia do grupo de gerenciamento canário.

Conforme mostrado no diagrama, toda a hierarquia de grupos de gerenciamento de produção das zonas de destino do Azure é duplicada no Tenant Root Group. O nome canary é acrescentado aos nomes de exibição e IDs do grupo de gerenciamento. As IDs devem ser exclusivas em um único locatário do Microsoft Entra.

Observação

Os nomes de exibição dos grupos de gerenciamento canário podem ser iguais aos nomes de exibição dos grupos de gerenciamento de produção. Isso poderá causar confusão aos usuários. Por esse motivo, recomendamos adicionar o nome "canário" aos nomes de exibição e às respectivas IDs.

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

• Grupos de gestão
  • Colocação da assinatura
• RBAC
  • Funções (internas e personalizadas)
  • Atribuições
• Azure Policy
  • Definições (internas e personalizadas)
  • Iniciativas, também conhecidas como definições de conjuntos
  • Atribuições

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

Se você não quiser implantar a hierarquia de grupos 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 sandboxes.

Para testar o Azure Policy 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 você deseja para concluir o teste como, por exemplo, conta de usuário, entidade de serviço ou Identidade de Serviço Gerenciada. Essa configuração permite que você crie, atribua e corrija as definições e atribuições do Azure Policy apenas no escopo da assinatura de sandbox.

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

Uma vantagem dessa abordagem é que as assinaturas sandbox podem ser usadas enquanto são necessárias e, em seguida, excluídas do ambiente.

No entanto, essa abordagem não permite testar com a herança de RBAC e políticas do Azure da hierarquia de grupos de gerenciamento.

Diretrizes de implementação

A seguir estão as diretrizes sobre como implementar e usar a hierarquia de grupos de gerenciamento canário para zonas de destino do Azure juntamente com uma hierarquia de grupos de gerenciamento de zonas de destino do Azure no ambiente de produção.

Aviso

Se você estiver usando o portal para implantar e gerenciar seu ambiente de zonas de destino do Azure hoje, pode ser difícil adotar e usar a abordagem canário de forma eficiente devido ao alto risco de os ambientes de produção e canário ficarem fora de sincronia com frequência e, portanto, não fornecer uma hierarquia e um ambiente semelhantes a réplicas de produção.

Considere mover para uma abordagem de implantação de IaC (Infraestrutura como Código) para zonas de destino do Azure, conforme listado acima, se você estiver nesse cenário. Ou esteja ciente dos riscos potenciais de descompasso de configuração entre canário e produção e prossiga com cuidado. Para obter mais informações, consulte Usar IaC para atualizar as zonas de destino do Azure.

1. Use identidades gerenciadas ou SPNs (entidades de serviço) do Microsoft Entra separadas que tenham permissões concedidas sobre a hierarquia de grupos de gerenciamento de zonas de destino do Azure no ambiente de produção ou no ambiente canário.
   • Essas diretrizes seguem o princípio de privilégios mínimos (PoLP)
2. Use pastas separadas dentro de um repositório Git, branches ou repositórios diferentes para armazenar a IaC das implantações das zonas de destino do Azure nos ambientes de produção e canário.
   • Usar as entidades de serviço (SPNs) ou identidades gerenciadas (MIs) do Microsoft Entra relevantes como parte das pipelines de CI/CD, dependendo da hierarquia que está sendo implantada.
3. Implemente políticas de branch do Git ou de segurança para o ambiente canário, da mesma forma que você já aplica no ambiente de produção.
   • Considere reduzir o número de aprovadores e verificações para o ambiente canário para fail-fast.
4. Use as mesmas ações do Azure Pipelines ou do GitHub que usam variáveis de ambiente para alterar qual hierarquia está sendo implantada. Outra opção é clonar os pipelines e corrigir as configurações embutidas em código para definir qual hierarquia está sendo implantada.
   • O uso de modelos de DevOps do Azure Pipelines ou modelos de fluxo de trabalho do GitHub Actions ajudará você a aderir ao princípio Não Se Repetir (DRY ).
5. Tenha um conjunto de assinaturas canário em uma conta de cobrança separada, por exemplo, uma Conta de Contrato Enterprise (EA) ou seção de fatura do Contrato de Cliente da Microsoft (MCA), que pode ser movida pela hierarquia de grupos de gerenciamento canário conforme necessário.
   • Pode ser benéfico ter um conjunto de recursos sempre implantados nas assinaturas do ambiente canário para agilizar o teste e a validação de alterações no ambiente canário.
6. Tenha um conjunto de arquiteturas de carga de trabalho de aplicativos de exemplo que você pode implantar nas assinaturas canário no ambiente canário para testar as alterações do Azure Policy 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á 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 examinar e atualizar continuamente as cargas de trabalho de exemplo para garantir que elas sejam relevantes e atualizadas com os padrões mais recentes de arquitetura e design em sua organização.
   • Se você fornecer arquiteturas de referência para suas equipes de aplicativos, considere implantá-las no ambiente canário também. Isso ajuda você a validar as alterações nas arquiteturas de referência e garantir que elas sejam aplicáveis ao ambiente de produção.
7. Envie todos os logs de atividades do Azure para todas as assinaturas do Azure, incluindo quaisquer assinaturas do ambiente canário, para o workspace do Azure Log Analytics no ambiente de produção, conforme as recomendações de design das zonas de destino 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 das alterações do Azure Policy e do RBAC no ambiente de produção.

Dica

Se você já tiver zonas de destino do Azure implantadas em produção e agora estiver procurando adicionar um ambiente canário. Considere clonar sua implantação atual da hierarquia do ambiente de produção e alterar os nomes dos recursos para prefixá-los com seu esquema de nomenclatura canário.

Isso garantirá que o que você está implantando para habilitar o ambiente canário esteja em sincronia com a produção desde o início. Isso é facilmente obtido ao usar uma ferramenta IaC junto com um repositório git.

Usar um único locatário do Microsoft Entra

As considerações a serem levadas em conta ao usar um único tenant do Microsoft Entra são:

• O uso de um único locatário segue as recomendações de design das zonas de destino do Azure para locatários do Microsoft Entra.
  • Em um único locatário do Microsoft Entra, você pode usar os diferentes grupos do Microsoft Entra para os ambientes de zonas de destino do Azure de produção e canário com os mesmos usuários atribuídos à hierarquia de grupos de gerenciamento 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 recursos do Microsoft Entra ID nas versões P1 ou P2.
• As alterações de RBAC são mais complexas nos ambientes canário e de produção, pois é provável que os usuários e grupos não sejam idênticos em ambos os locatários do Microsoft Entra.
  • Considere que as IDs de usuários e grupos não serão as mesmas em 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 com privilégios que devem manter o acesso e entrar em locatários separados para realizar testes podem fazer alterações acidentais no ambiente de produção em vez do ambiente canário, como exemplo.
• Reduz a probabilidade de falhas de implantação e desvio de configuração.
• Não requer a criação de processos de segurança extra e emergência crítica ou acesso de emergência.
• Reduz o atrito e o tempo necessário para implementar alterações na implantação das zonas de destino do Azure.

Próximas etapas

Depois que você tiver um ambiente canário configurado corretamente, poderá começar a testar as alterações do Azure Policy e RBAC antes de implantá-las na hierarquia de grupos de gerenciamento das zonas de destino do Azure em produção.

Quando você tiver testado as alterações nas Políticas do Azure no ambiente canário, poderá promovê-las ao ambiente de produção seguindo a mesma abordagem documentada nas diretrizes Adotar guardrails controlados por políticas. Isso é feito usando o recurso de modo de imposição de atribuições de política. Usar a abordagem documentada nesta orientação permite que você prossiga em uma fase de teste extra antes de impor o Azure Policy no ambiente de produção em seu efeito desejado, o que ajudará você a criar confiança nas alterações do Azure Policy que você está fazendo.

Você também pode examinar os ambientes de área restrita para que suas equipes de aplicativos usem para desenvolvimento e teste de suas cargas de trabalho. Esse é um conceito separado para o 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 em produção.

Implementar ambientes de área restrita da zona de destino