Abordagem de teste para zonas de aterrissagem 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 talvez queiram testar a implantação da plataforma de zonas de aterrissagem do Azure para definições e atribuições da Política 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 Gerenciador de Recursos do Azure (modelos ARM), AzOps, Terraform, Biceps ou manualmente por meio do portal do Azure. Esta orientação fornece uma abordagem que pode ser usada para testar as 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 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 considere apropriado para seu ambiente de zonas de aterrissagem canárias do Azure.
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).
Esta orientação destina-se apenas a testes e alterações ao nível da plataforma no contexto das zonas de aterragem 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íticas | 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 aterrissagem 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 aterrissagem do Azure é duplicada Tenant Root Groupno . 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 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 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.
- De acordo com as práticas recomendadas do Azure Cloud Adoption Framework, padronizar em um único diretório e orientação de identidade, locatários únicos do Microsoft Entra são práticas recomendadas para a maioria.
- 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 aterrissagem canárias do Azure, com os mesmos usuários, atribuídos à hierarquia de grupo de gerenciamento relevante dentro do mesmo locatário do Microsoft Entra.
- Custos de licenciamento do Microsoft Entra ID 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 do Microsoft Entra ID.
- As alterações do RBAC serão mais complexas em ambientes canários 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 por serem globalmente exclusivas.
- Reduz a complexidade e a sobrecarga de gerenciamento causada 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 de zonas de aterrissagem do Azure.
Diretrizes de implementação
Veja abaixo orientações sobre como implementar e usar a hierarquia do grupo de gerenciamento canário para zonas de aterrissagem do Azure ao lado de uma hierarquia de grupo de gerenciamento de ambiente de produção.
Aviso
Se você estiver usando o portal para implantar e gerenciar seu ambiente de zonas de aterrissagem do Azure hoje, pode ser difícil adotar e usar a abordagem canary de forma eficiente 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 semelhante a uma réplica e um ambiente de produção.
Considere mudar para uma abordagem de implantação de Infraestrutura como Código para zonas de aterrissagem do Azure, conforme listado acima, se você estiver nesse cenário. Ou esteja ciente dos riscos potenciais de deriva de configuração entre canário e produção e proceda com cuidado.
- Use SPNs (entidades de serviço) ou MSIs (Identidades de Serviço Gerenciado) separadas do Microsoft Entra que recebem permissões sobre o ambiente de produção relevante ou a 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, ramificações ou repositórios para manter a Infraestrutura como Código para o ambiente de produção e as implantações de zonas de aterrissagem do Azure do ambiente canário.
- Usando as entidades de serviço (SPNs) ou MSIs (Managed Service Identities) 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 atividade do Azure para todas as assinaturas do Azure, incluindo qualquer assinatura de ambiente canário, para o espaço de trabalho do Azure Log Analytics do ambiente de produção de acordo com as recomendações de design de zonas de aterrissagem do Azure.
Dica
Se você já tem zonas de aterrissagem do Azure implantadas em produção e agora está procurando adicionar um ambiente canário. Considere clonar sua implantação atual da hierarquia do ambiente de produção e altere 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 Infrastructure-as-Code ao lado de um repositório git.
Próximas etapas
Saiba como implementar ambientes de área restrita de zona de aterrissagem.