Automatizar zonas de aterrissagem do Azure em múltiplos locatários
Se sua organização tem vários locatários do Microsoft Entra com zonas de aterrissagem (ALZs) do Azure em cada um deles, uma ou várias vezes, a automação é fundamental. A automação ajuda a operar e manter com êxito a implantação da ALZ em escala para todos os locatários. Há muitas abordagens para automatizar implantações ALZ em vários locatários. A abordagem que você usa 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 os locatários do Microsoft Entra de soluções de SaaS e corporativas separados. O risco de uma operação ou implantação afetar o outro locatário, seja de propósito ou por engano, é reduzido.
As seções a seguir fornecem diagramas e diretrizes 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 destino do Azure ao lidar com vários locatários do Microsoft Entra.
Nota
Examine 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 destino do Azure em vários locatários do Microsoft Entra.
Abordagem 1 – Isolamento completo é a abordagem mais comum em cenários multitenant. 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 – Registro de aplicativo compartilhado (multilocatário) com várias entidades de serviço costuma ser usada em cenários de MSP (provedor de serviços gerenciados). Nessa abordagem, um padrão de selos 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 implementações com base nos requisitos da sua organização.
Importante
Este artigo aborda a automação da implantação e da operação das zonas de aterrissagem do Azure como a plataforma em cada locatário do Microsoft Entra que sua organização tem. As abordagens, recomendações e considerações neste artigo não devem ser usadas por equipes de aplicativo 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 destino, consulte Platform vs. application landing zones.
Abordagem 1 – Isolamento completo
Nessa abordagem, o objetivo principal é manter cada inquilino do Microsoft Entra isolado uns dos outros em todos os componentes de automação, como:
- Um repositório Git.
- GitHub Actions ou Azure Pipelines (incluindo executores auto-hospedados, se 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 locatário do Microsoft Entra. Algumas organizações podem ter controles de conformidade regulatória impostos sobre elas que exigem esse tipo de segregação e isolamento.
Nota
Se sua organização apenas permitir o uso de identidades gerenciadas para automação de plataforma, você deverá usar essa abordagem ou uma abordagem que realize login em cada locatário individualmente. As identidades gerenciadas não dão suporte a cenários entre locatários em um estado de disponibilidade geral. Para mais informações, consulte este FAQ .
No entanto, agora isso está disponível em visualização pública para identidades gerenciadas atribuídas pelo usuário mediante a configuração de uma relação de confiança entre estas e um aplicativo multilocatário do Entra ID. Veja mais informações sobre como configurar isso em Configurar um aplicativo para confiar em uma identidade gerenciada (versão prévia). Isso pode fazer da Abordagem 2 – Registro de aplicativo compartilhado (multilocatário) com várias entidades de serviço uma opção viável para sua implantação.
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 de plataforma ou desenvolvedor requer uma conta de usuário separada em cada locatário para executar operações dentro desse locatário. Essas contas também são usadas para acessar as ferramentas de 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 gerenciado do 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 usuários que executam as tarefas e as etapas de pipeline acessem qualquer locatário do Microsoft Entra utilizando um conjunto único de credenciais.
Dica
Para obter informações sobre a relação entre registros de aplicativos e aplicativos empresariais (entidades de serviço), confira Objetos de aplicativo e entidade de serviço no Microsoft Entra ID.
Importante
Nessa abordagem, o registro de aplicativo único e os aplicativos empresariais associados (entidades de serviço) devem ser monitorados para qualquer atividade anormal em suas ferramentas de SIEM (gerenciamento de eventos e informações de segurança), pois essa é uma conta altamente privilegiada. Ele deve enviar alertas e, potencialmente, tomar medidas automaticamente, dependendo da gravidade do alerta.
No exemplo anterior, um só registro de aplicativo está no locatário do Microsoft Entra contoso.onmicrosoft.com, e existe um aplicativo empresarial em cada locatário do Microsoft Entra que está vinculado ao registro desse aplicativo. Essa configuração permite que um pipeline autentique e autorize o acesso a todos os locatários do Microsoft Entra por meio de um só registro de aplicativo. Para obter mais informações, confira Tornando seu aplicativo multilocatário e Dar consentimento de administrador em todo o locatário a um aplicativo.
Dica
As Identidades Gerenciadas Atribuídas ao Usuário, em versão prévia pública, agora podem dar suporte a cenários multilocatários configurando uma relação de confiança entre si e um aplicativo multilocatário de ID do Entra. Veja mais informações sobre como configurar isso em Configurar um aplicativo para confiar em uma identidade gerenciada (versão prévia).
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 ambiente, assinaturas associadas, nome da organização e ID de 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 Tabelas 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 registros de aplicativos separados, e aplicativos corporativos com pipelines.
Você pode optar por ter pipelines separados para cada locatário do Microsoft Entra ou usar um só pipeline. A escolha é sua com base em seus requisitos.
Nota
O Azure Lighthouse funciona de maneira semelhante a essa abordagem, mas não permite a atribuição das permissões de proprietário do RBAC, administrador de acesso do usuário e funções com DataActions. Para obter mais informações, confira Suporte à função para o Azure Lighthouse.
As funções de acesso do proprietário e do usuário normalmente são necessárias em todos os cenários de implantação da zona de destino do Azure. Esse requisito remove o Azure Lighthouse como uma opção para todo o aspecto de implantação de automação de plataforma das zonas de destino do Azure, mas ainda é útil em alguns cenários. Para obter mais informações, confira Uso do Azure Lighthouse na ALZ multilocatário.
Identidades para administradores e desenvolvedores de plataforma – Abordagem 2
Nessa abordagem, os administradores e desenvolvedores da plataforma geralmente só precisam de acesso ao tenant de gerenciamento do Microsoft Entra. Esse acesso lhes permite utilizar as ferramentas de desenvolvedor, como o GitHub ou o Azure DevOps, em que todos os locatários estão implantados e dos quais são 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 inquilino administrador ou podem ter contas separadas, como no exemplo da primeira abordagem.