Abordagem de testes para landing zone do Azure

Algumas organizações podem querer testar a implantação, pelo acelerador de landing zone da plataforma, de definições e atribuições do Azure Policy, de funções personalizadas e atribuições de RBAC (controle de acesso baseado em função), entre outros. 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. Esta orientação fornece uma abordagem que pode ser usada para testar alterações e seu impacto em uma implantação de acelerador de zona de destino de plataforma.

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, ele pode ser combinado com as diretrizes em Adotar guardrails controlados por políticas para técnicas de implantação de alterações de política em uma implantação de zona de destino da plataforma.

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.

Definição da plataforma

As diretrizes da landing zone do Azure ajudam você a projetar e implantar os componentes necessários da plataforma Azure para que você possa construir e colocar em operação landing zones em escala.

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

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.

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

Como mostra o diagrama, toda a hierarquia do grupo de gerenciamento de produção da zona de destino do Azure é duplicada em Tenant Root Group. O nome canary é acrescentado aos nomes de exibição e IDs do grupo de gerenciamento. As IDs do grupo de gerenciamento devem ser exclusivas dentro de um único locatário do Microsoft Entra. O locatário trata as IDs do grupo de gerenciamento como os identificadores autoritativos, portanto, elas devem ser distintas em todo o locatário. Você pode manter os nomes para exibição dos grupos de gerenciamento alinhados com a hierarquia dos grupos de gerenciamento de produção. Adicione uma distinção de nomenclatura aos nomes de exibição também, logo, os usuários podem distinguir visualmente a hierarquia canária da produção ao navegar na árvore do grupo de gerenciamento.

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 da landing zone do Azure destacando as 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

Veja abaixo as orientações sobre como implementar e usar a hierarquia de grupos de gerenciamento canário para uma zona de destino do Azure, juntamente com a hierarquia de grupos de gerenciamento de uma zona de destino do Azure para ambiente de produção.

1. Use entidades de serviço (SPNs) ou identidades gerenciadas (MIs) separadas do Microsoft Entra que tenham permissões concedidas sobre a hierarquia do grupo de gerenciamento da zona de destino do Azure relevante para o ambiente de produção ou ambiente canary.
   • Essas diretrizes seguem o princípio de privilégios mínimos (PoLP)
2. Use pastas separadas em um repositório Git, branches ou repositórios para armazenar a Infraestrutura como Código (IaC) para as implantações da zona de destino do Azure nos ambientes de produção e canary.
   • 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 disponível um conjunto de arquiteturas de exemplo de cargas de trabalho que você possa implantar nas subscrições canário do ambiente canário para testar as alterações na Azure Policy e no 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 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 carga de trabalho, considere implantá-las também no ambiente canary. 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 atividade do Azure para todas as assinaturas do Azure, incluindo quaisquer assinaturas de ambiente canary, para o workspace do Azure Log Analytics do ambiente de produção, conforme as recomendações de design da zona 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.

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 tenant segue as recomendações de design da zona de destino do Azure para tenants do Microsoft Entra.
  • Em um único locatário do Microsoft Entra, você pode usar diferentes grupos do Microsoft Entra para ambientes de zonas de destino do Azure de produção e de canário, com os mesmos usuários atribuídos à respectiva hierarquia de grupos de gerenciamento.
• 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 da zona de destino Azure.

Próximas etapas

Depois de configurar um ambiente canário, você pode começar a testar as alterações no Azure Policy e no RBAC antes de implantá-las na hierarquia de grupos de gerenciamento da landing zone do Azure de 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 revisar ambientes sandbox para suas equipes de carga de trabalho usarem no desenvolvimento e teste das respectivas cargas de trabalho. Esse é um conceito separado do ambiente canário e é usado para fornecer um ambiente seguro para as equipes responsáveis pelas cargas de trabalho desenvolverem e testarem suas cargas de trabalho antes de serem implantadas no ambiente de produção.