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 a implantação da plataforma de zonas de destino do Azure para definições e atribuições do Azure Policy, funções e atribuições personalizadas de RBAC (controle de acesso baseado em função) e assim por diante. 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. Essas diretrizes fornecem uma abordagem que pode ser usada para testar alterações e seu impacto em uma implantação de plataforma de zonas de destino do Azure.
Este artigo também pode ser usado com a diretriz Automação da plataforma e área de design crítico de DevOps, pois ele se relaciona às equipes e tarefas de funções Centrais e de PlatformOps.
Essas diretrizes são mais adequadas para organizações com processos robustos de gerenciamento de alterações que regem as alterações na hierarquia do grupo de gerenciamento do ambiente de produção. A hierarquia do grupo 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 julgar apropriado para o ambiente de zonas de destino do Azure canário.
Da mesma forma, o termo ambiente de produção é usado em todo este guia para se referir à hierarquia do grupo de gerenciamento 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 aplicativos ou proprietários de serviço conhecidos como zonas de destino, cargas de trabalho, aplicativos ou serviços. Eles são colocados e manipulados na hierarquia do grupo de gerenciamento do ambiente de produção e governança associada (RBAC e Azure Policy).
Essas diretrizes são apenas para testes no nível da plataforma e alterações no contexto das zonas de destino do Azure.
A escala empresarial ajuda a projetar e implantar os componentes necessários da plataforma do Azure para permitir que você construa e operacionalize as 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 assinatura de 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 RBAC do Azure e nas associações de grupo 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 de implantação comum ou padrão para a maioria dos clientes. Não é obrigatório para implantações de zonas de destino do Azure.
Figura 1: Hierarquia do grupo de gerenciamento canário.
Como mostra o diagrama, toda a hierarquia do grupo de gerenciamento do ambiente de produção das zonas de destino do Azure é duplicada no Tenant Root Group. O nome do canário é 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 do grupo de gerenciamento do ambiente canário podem ser iguais aos nomes de exibição do grupo de gerenciamento do ambiente de produção. Isso poderá causar confusão aos usuários. Por isso, é recomendável acrescentar o nome "canário" aos nomes de exibição, bem como às suas IDs.
A hierarquia do grupo de gerenciamento do ambiente canário é usada para simplificar o teste dos seguintes tipos de recursos:
- Grupos de gestão
- Posicionamento 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 toda a hierarquia do grupo de gerenciamento do ambiente canário?
Se você não quiser implantar toda a hierarquia do grupo de gerenciamento do ambiente canário, poderá testar os recursos da plataforma na hierarquia do ambiente de produção usando assinaturas de área restrita, conforme mostrado no diagrama.
Figura 2: Hierarquia do grupo de gerenciamento de escala empresarial realçando as áreas restritas.
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 permitirá que você crie, atribua e corrija as definições e atribuições do Azure Policy somente dentro do escopo da assinatura de área restrita.
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. Esse teste pode ser feito na assinatura de área restrita e testado antes de criar e atribuir funções acima na hierarquia.
Uma vantagem dessa abordagem é que as assinaturas de área restrita podem ser usadas para o momento em que são necessárias e, em seguida, excluídas do ambiente.
No entanto, essa abordagem não permite que você teste com a herança de RBAC e políticas do Azure da hierarquia do grupo de gerenciamento.
Usando um único locatário do Microsoft Entra
As considerações a serem levadas em conta ao usar um único locatário do Microsoft Entra são:
- Segue as recomendações de design em escala empresarial para locatários do Microsoft Entra.
- Em um único locatário do Microsoft Entra, você pode usar os diferentes grupos do Microsoft Entra para ambientes de produção e ambientes de zonas de destino canários do Azure, com os mesmos usuários, atribuídos à hierarquia de grupo de gerenciamento relevante no mesmo locatário do Microsoft Entra.
- Custos de licenciamento de ID do Microsoft Entra aumentados ou duplicados devido a várias identidades em diferentes locatários do Microsoft Entra.
- Esse ponto é especialmente relevante para clientes que usam os recursos P1 ou P2 da ID do Microsoft Entra.
- As alterações do RBAC serão mais complexas em ambientes canário e ambientes 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.
- Além disso, as IDs de usuários e grupos não serão as mesmas entre os locatários do Microsoft Entra porque são globalmente exclusivas.
- Reduz a complexidade e a sobrecarga de gerenciamento causadas pelo gerenciamento de vários locatários do Microsoft Entra.
- Os usuários privilegiados que devem manter o acesso e entrar em locatários separados para executar testes podem fazer alterações no ambiente de produção acidentalmente, em vez de fazer alterações no ambiente canário e vice-versa.
- Reduz a probabilidade de falhas de implantação e descompasso de configuração.
- Não exige a criação de processos de segurança extra e de interrupção ou de 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.
Diretrizes de implementação
Abaixo estão as diretrizes sobre como implementar e usar a hierarquia do grupo de gerenciamento canário para zonas de destino do Azure junto com uma hierarquia de grupo de gerenciamento do 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 com eficiência devido a um alto risco de os ambientes de produção e canário ficarem fora de sincronia com frequência e, portanto, não fornecerem uma hierarquia e um ambiente de produção semelhantes a réplicas.
Considere mudar para uma abordagem de implantação de 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 desvio de configuração entre o canário e a produção e prossiga com cuidado.
- Use SPNs (entidades de serviço) ou MSIs (Identidades de Serviço Gerenciado) separadas do Microsoft Entra que recebem permissões no ambiente de produção relevante ou na hierarquia do grupo de gerenciamento do ambiente canário.
- Essas diretrizes seguem o princípio de privilégios mínimos (PoLP)
- Use pastas separadas em um repositório Git, branches ou repositórios para manter a infraestrutura como código para o ambiente de produção e as implantações de zonas de destino do Azure do ambiente canário.
- Usando as entidades de serviço (SPNs) ou MSIs (Identidades de Serviço Gerenciado) relevantes do Microsoft Entra como parte dos pipelines de CI/CD, dependendo de qual hierarquia está sendo implantada.
- Implemente políticas ou segurança da ramificação Git para o ambiente canário como você tem implementadas para o ambiente de produção.
- Considere a possibilidade de reduzir o número de aprovadores e verificar se o ambiente canário foi reprovado rapidamente.
- 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.
- Usar os modelos de DevOps do Azure Pipelines ou os modelos de fluxo de trabalho do GitHub Actions ajudará você a aderir ao princípio de não repetição (DRY).
- Tenha um conjunto de assinaturas do canário em um departamento do EA e uma conta separados que possam ser movidos na hierarquia do grupo de gerenciamento do canário conforme necessário.
- Pode ser benéfico ter um conjunto de recursos sempre implantados nas assinaturas do ambiente canário.
- Poderá ser útil ter modelos de infraestrutura como código, como modelos ARM, Bicep ou Terraform, que criem um conjunto de recursos que habilitam a validação de alterações no ambiente canário.
- Envie todos os logs de atividades do Azure para todas as assinaturas do Azure, incluindo quaisquer assinaturas de ambiente canário, para o workspace do Azure Log Analytics do ambiente de produção de acordo com as recomendações de design das zonas de destino do Azure.
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 é para 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 alcançado ao usar uma ferramenta de infraestrutura como código junto com um repositório git.
Próximas etapas
Saiba como implementar ambientes de área restrita da zona de destino.