Automatizar zonas de aterrissagem do Azure em vários locatários
Se sua organização tiver vários locatários do Microsoft Entra com zonas de aterrissagem do Azure (ALZ) em cada um deles, uma ou várias vezes, a automação será fundamental. A automação ajuda a operar e manter com sucesso a implantação do ALZ em escala em todos os locatários. Há muitas abordagens para automatizar implantações ALZ em vários locatários. A abordagem adotada depende dos motivos pelos quais sua organização tem vários locatários do Microsoft Entra.
Por exemplo, você pode ter vários locatários do Microsoft Entra se for um fornecedor de software independente. É provável que você queira manter seus locatários corporativos e de soluções SaaS do Microsoft Entra separados. O risco de uma operação ou implantação afetar o outro locatário, intencionalmente ou por engano, reduz.
As seções a seguir fornecem diagramas e orientações sobre as abordagens que você pode adotar. Escolha qual abordagem é melhor para você com base em seus requisitos, considerações e recomendações para automatizar suas implantações de zonas de aterrissagem do Azure ao lidar com vários locatários do Microsoft Entra.
Observação
Analise os seguintes artigos primeiro para obter uma visão geral dos locatários do Microsoft Entra:
Abordagens
Há duas abordagens para automatizar a implantação de zonas de aterrissagem do Azure em vários locatários do Microsoft Entra.
Abordagem 1 – O isolamento completo é a abordagem mais comum em cenários multilocatário. Essa abordagem mantém a separação e o isolamento necessários entre os locatários do Microsoft Entra, que é o requisito mais comum ao usar uma abordagem multilocatário.
Abordagem 2 – O registro de aplicativo compartilhado (multilocatário) com várias entidades de serviço é comumente usado em cenários de MSP (Provedor de Serviços Gerenciados). Nessa abordagem, um padrão de carimbos de implantação pode ser usado para automatizar a implantação de uma arquitetura quase idêntica em vários locatários em escala.
Ambas as abordagens são fornecidas como exemplos e inspiração. Você pode combinar as abordagens em suas implantações com base nos requisitos da sua organização.
Importante
Este artigo aborda a automação da implantação e operação de zonas de aterrissagem do Azure como a plataforma em cada locatário do Microsoft Entra que sua organização possui. As abordagens, recomendações e considerações neste artigo não se destinam a ser usadas por equipes de aplicativos que implantam e operam seus serviços e aplicativos em suas zonas de aterrissagem (assinaturas). Para obter mais informações sobre os diferentes tipos de zonas de pouso, consulte Zonas de aterrissagem de plataforma versus aplicativo.
Abordagem 1 – Isolamento completo
Nessa abordagem, o objetivo principal é manter cada locatário do Microsoft Entra isolado um do outro em todos os componentes de automação, como:
- Um repositório Git.
- Ações do GitHub ou Pipelines do Azure (incluindo executores auto-hospedados, se estiverem sendo utilizados).
- Identidades usadas para executar tarefas da automação, como identidades gerenciadas atribuídas a executores auto-hospedados, SPNs (nomes de entidade de serviço), usuários ou administradores.
Nessa abordagem, há mais componentes para gerenciar que são duplicados por um locatário do Microsoft Entra. Algumas organizações podem ter controles de conformidade regulatória impostos a elas que exigem esse tipo de segregação e isolamento.
Observação
Se sua organização só permitir o uso de identidades gerenciadas para automação de plataforma, você deverá usar essa abordagem ou uma abordagem que faça logon em cada locatário individualmente. As identidades gerenciadas não oferecem suporte a cenários entre locatários. Para saber mais, confira estas perguntas frequentes.
Identidades para administradores e desenvolvedores de plataforma - Abordagem 1
Nessa abordagem, as identidades também devem ser isoladas em cada locatário do Microsoft Entra, o que significa que cada administrador ou desenvolvedor de plataforma requer uma conta de usuário separada dentro de cada locatário para executar operações dentro desse locatário. Essas contas também são usadas para acessar as ferramentas do desenvolvedor, como GitHub ou Azure DevOps, para cada um dos locatários. Considere cuidadosamente os efeitos da produtividade do administrador e do desenvolvedor seguindo essa abordagem.
O Microsoft Entra B2B e/ou o Azure Lighthouse podem ser usados, mas essa opção questiona o motivo de ter locatários separados do Microsoft Entra.
Abordagem 2 – Registro de aplicativo compartilhado (multilocatário) com várias entidades de serviço
Nessa abordagem, um registro de aplicativo é criado no locatário do Microsoft Entra de gerenciamento. Em cada locatário do Microsoft Entra que você deseja gerenciar, um SPN (nome da entidade de serviço) é criado nesse locatário, com base no registro do aplicativo. Essa ação permite que os trabalhadores que executam as tarefas e etapas de pipeline entrem em qualquer um dos locatários do Microsoft Entra com um único conjunto de credenciais.
Dica
Para obter informações sobre a relação entre registros de aplicativos e aplicativos corporativos (princípios de serviço), consulte Objetos de entidade de aplicativo e serviço no Microsoft Entra ID.
Importante
Nessa abordagem, o registro de aplicativo único e os aplicativos corporativos associados (entidades de serviço) devem ser monitorados quanto a qualquer atividade anormal em suas ferramentas de gerenciamento de eventos e informações de segurança (SIEM), pois essa é uma conta altamente privilegiada. Ele deve enviar alertas e potencialmente tomar medidas automaticamente, dependendo da gravidade do alerta.
No exemplo anterior, um único registro de aplicativo está no locatário do Microsoft Entra e um aplicativo corporativo está em cada um dos locatários do Microsoft Entra vinculados ao registro do contoso.onmicrosoft.com aplicativo. Essa configuração permite que um pipeline autentique e autorize todos os locatários do Microsoft Entra usando o registro de aplicativo único. Para obter mais informações, confira Como tornar seu aplicativo multilocatário.
Ao usar um pipeline centralizado, talvez seja necessário criar uma pequena tabela de mapeamento que contenha dados correlacionando os locatários do Microsoft Entra e outros metadados, como o ambiente, as assinaturas associadas, o nome da organização e a ID do objeto de identidade usados para autenticação e autorização. Esses dados podem ser chamados durante a execução do pipeline em uma etapa que usa alguma lógica e condições para controlar em qual locatário do Microsoft Entra ele é implantado e com quais identidades. Os dados podem ser armazenados em serviços, como o Azure Cosmos DB ou o armazenamento de tabela do Azure.
Quando você lida com vários ambientes, como desenvolvimento, teste ou produção, eles podem ser controlados da mesma maneira usando os mesmos registros de aplicativos ou separadamente e aplicativos corporativos com pipelines.
Você pode decidir ter pipelines separados para cada locatário do Microsoft Entra ou usar um único pipeline. A escolha é sua com base em suas necessidades.
Observação
O Azure Lighthouse funciona de forma semelhante a essa abordagem, mas o Azure Lighthouse não permite a atribuição do proprietário do RBAC, do administrador de acesso do usuário e das funções com permissões DataActions. Para obter mais informações, confira Suporte à função para o Azure Lighthouse.
As funções de proprietário e acesso de usuário geralmente são necessárias em todos os cenários de implantação da zona de aterrissagem do Azure. Esse requisito remove o Farol do Azure como uma opção para todo o aspecto de implantação de automação de plataforma das zonas de aterrissagem do Azure, mas ainda é útil em alguns cenários. Para obter mais informações, consulte Uso do Farol do Azure em ALZ multilocatário.
Identidades para administradores e desenvolvedores de plataforma - Abordagem 2
Nessa abordagem, os administradores e desenvolvedores de plataforma geralmente só precisam acessar o locatário do Microsoft Entra de gerenciamento. Esse acesso concede a eles acesso às ferramentas do desenvolvedor, como o GitHub ou o Azure DevOps, nas quais todos os locatários são implantados e operados.
Eles podem ter acesso aos outros locatários do Microsoft Entra por meio do Microsoft Entra B2B ou do Azure Lighthouse. Eles usam a mesma conta do locatário de gerenciamento ou podem ter contas separadas, como o exemplo na primeira abordagem.