Automatize as 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 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 independente de software. É provável que você queira manter seus locatários corporativos e de soluções SaaS Microsoft Entra separados. O risco de uma operação ou implantação afetar o outro inquilino, intencionalmente ou por engano, reduz-se.
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.
Nota
Revise 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 e 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 destino (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 uns dos outros em todos os componentes de automação, como:
- Um repositório Git.
- Ações do GitHub ou Pipelines do Azure (incluindo corredores auto-hospedados, se estiverem sendo utilizados).
- Identidades que são usadas para executar tarefas da automação, como identidades gerenciadas atribuídas a corredores auto-hospedados, nomes de entidade de serviço (SPNs), 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 aplicados a elas que exigem esse tipo de segregação e isolamento.
Nota
Se sua organização só permite o uso de identidades gerenciadas para automação de plataforma, você deve usar essa abordagem ou uma abordagem que faça login em cada locatário individualmente. As identidades gerenciadas não oferecem suporte a cenários entre locatários. Para obter mais informações, consulte estas perguntas frequentes.
Identidades para administradores e desenvolvedores de plataformas - 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 o GitHub ou o 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 raciocínio para 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 gerenciando o Microsoft Entra. 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 do pipeline entrem em qualquer um dos locatários do Microsoft Entra com um único conjunto de credenciais.
Gorjeta
Para obter informações sobre a relação entre registros de aplicativos e aplicativos corporativos (princípios de serviço), consulte Objetos principais 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. 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 empresarial está em cada um dos locatários do contoso.onmicrosoft.com Microsoft Entra vinculado ao registro do 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, consulte Tornando 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 usado 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 e aplicativos corporativos com pipelines, ou separados.
Você pode decidir ter pipelines separados para cada locatário do Microsoft Entra ou usar um único pipeline. A escolha é sua com base nas suas necessidades.
Nota
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, administrador de acesso do usuário e funções com permissões DataActions. Para obter mais informações, consulte Suporte de função para o Azure Lighthouse.
As funções de proprietário e acesso de usuário normalmente são necessárias em todos os cenários de implantação da zona de aterrissagem do Azure. Esse requisito remove o Azure Lighthouse como uma opção para todo o aspeto 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 Azure Lighthouse em multilocatário ALZ.
Identidades para administradores e desenvolvedores de plataforma - Abordagem 2
Nessa abordagem, os administradores e desenvolvedores de plataforma geralmente só precisam de acesso ao locatário gerenciando o Microsoft Entra. 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 gerente ou podem ter contas separadas, como o exemplo na primeira abordagem.