Abordagem de teste para zonas de aterrissagem do Azure
Nota
Este artigo aplica-se apenas ao Microsoft Azure e não a quaisquer 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 aterrissagem do Azure para definições e atribuições de 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 Azure Resource Manager (modelos ARM), AzOps, Terraform, Bíceps ou 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.
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 do ambiente de produção. A hierarquia do grupo de gerenciamento canário pode ser usada independentemente para criar e testar implantações antes de implantá-las no ambiente de produção.
Nota
O termo canário é usado para evitar confusão com ambientes de desenvolvimento ou ambientes de teste. Este 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 ao longo desta orientação para se referir à hierarquia de grupo de gerenciamento que sua organização pode ter em vigor que contém as assinaturas e recursos do Azure para suas cargas de trabalho.
Definição da plataforma
Importante
Esta orientação não se destina a ambientes de desenvolvimento ou ambientes de teste que serão usados por proprietários de aplicativos ou serviços, conhecidos como zonas de aterrissagem, cargas de trabalho, aplicativos ou serviços. Eles são colocados e manipulados dentro da hierarquia do grupo de gerenciamento do ambiente de produção e da governança associada (RBAC e Política do Azure).
Esta orientação destina-se apenas a testes ao nível da plataforma e alterações no contexto das zonas de aterragem do Azure.
A escala empresarial ajuda 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:
| Produto ou serviço | Provedor de recursos e tipo |
|---|---|
| Grupos de gestão | Microsoft.Management/managementGroups |
| Associação de subscrição de grupos de gestão | Microsoft.Management/managementGroups/subscriptions |
| Definições de política | Microsoft.Authorization/policyDefinitions |
| Definições de iniciativas políticas ou definições de conjuntos 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ções RBAC | Microsoft.Authorization/roleAssignments |
| Subscrições | Microsoft.Subscription/aliases |
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 aterrissagem, de acordo com o princípio de design de governança orientada 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.
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 dos grupos de gestão das Canárias.
Como mostra o diagrama, toda a hierarquia do grupo de gerenciamento do ambiente 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 IDs devem ser exclusivas dentro de um único locatário do Microsoft Entra.
Nota
Os nomes de exibição do grupo de gerenciamento de ambiente canário podem ser os mesmos que os nomes de exibição do grupo de gerenciamento de ambiente de produção. Isso pode causar confusão para os usuários. Por isso, recomendamos anexar o nome "canário" aos nomes de exibição, bem como aos seus IDs.
A hierarquia do grupo de gerenciamento de ambiente 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 definidas
- Atribuições
E se você não quiser implantar toda a hierarquia do grupo de gerenciamento de ambiente canário?
Se você não quiser implantar toda a hierarquia de grupo de gerenciamento de 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 de grupos de gerenciamento em escala empresarial 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 permitirá que você crie, atribua e corrija definições e atribuições da Política do Azure somente no escopo da assinatura da á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 assinatura de área restrita e testados antes de criar e atribuir funções mais acima na 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.
Usando um único locatário do Microsoft Entra
As considerações a ter em conta quando utiliza um único inquilino 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 do 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ários 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.
- Este ponto é especialmente relevante para clientes que usam os recursos do Microsoft Entra ID P1 ou P2.
- 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, os IDs de usuários e grupos não serão os mesmos entre os locatários do Microsoft Entra por serem globalmente exclusivos.
- 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 desvio de configuração e falhas de implantação.
- Não requer segurança extra e processos de quebra-vidro ou acesso de emergência para ser criado.
- Reduz o atrito e o tempo necessário para implementar alterações na implantação das zonas de aterrissagem do Azure.
Documentação de orientação para a implementação
Abaixo estão orientações sobre como implementar e usar a hierarquia de 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 canária 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 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 desvio de configuração entre canário e produção e proceda com cuidado.
- Use entidades de serviço (SPNs) ou Identidades de Serviço Gerenciado (MSIs) separadas do Microsoft Entra que recebem permissões sobre o ambiente de produção relevante ou a hierarquia de grupo de gerenciamento de ambiente canário.
- Esta orientação segue o princípio do menor privilégio (PoLP)
- Use pastas separadas dentro de um repositório git, ramificações ou repositórios para manter a infraestrutura como código para as implantações de zonas de aterrissagem do Azure do ambiente de produção e do ambiente canário.
- Usando as entidades de serviço (SPNs) ou identidades de serviço gerenciado (MSIs) relevantes do Microsoft Entra como parte dos pipelines de CI/CD, dependendo de qual hierarquia está sendo implantada.
- 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 falhe 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 alterar as configurações codificadas para definir qual hierarquia está sendo implantada.
- Tenha um conjunto de assinaturas canárias em um departamento e conta EA separados que possam ser movidos pela hierarquia do grupo de gerenciamento canário conforme necessário.
- Pode ser benéfico ter um conjunto de recursos sempre implantados nas assinaturas do ambiente canário.
- Pode ser útil ter modelos de infraestrutura como código, como modelos ARM, Bíceps ou Terraform, que criam um conjunto de recursos que permitem 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 quaisquer assinaturas 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 das zonas de aterrissagem do Azure.
Gorjeta
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 de infraestrutura como código ao lado de um repositório git.
Próximos passos
Saiba como implementar ambientes de área restrita de zona de aterrissagem.