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, seja intencional ou por engano, é reduzido.
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
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 – 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 – 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 diferentes abordagens nas suas implementaçõ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 equipas de aplicações que desenvolvem e operam os seus serviços e aplicações nas suas landing zones (assinaturas). Para obter mais informações sobre os diferentes tipos de zonas de pouso, consulte Plataformas versus zonas de aterrissagem de aplicativos.
Abordagem 1 – Isolamento completo
Nessa abordagem, o objetivo principal é manter cada inquilino 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 a ser utilizados).
- Identidades que são usadas para executar tarefas de automação, como identidades geridas atribuídas a runners auto-hospedados, nomes principais de serviço (SPNs), utilizadores ou administradores.
Nesta abordagem, há mais componentes para gerir 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.
Observação
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. Atualmente, as identidades gerenciadas não oferecem suporte a cenários entre locatários em um estado geralmente disponível. Para obter mais informações, consulte este FAQ.
No entanto, isso agora está disponível na visualização pública para User-Assigned Managed Identites configurando uma relação de confiança entre ele e um aplicativo multilocatário Entra ID. Veja mais informações sobre como configurar isso em Configurar um aplicativo para confiar em uma identidade gerenciada (visualização). Isso agora pode tornar 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 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
Nesta abordagem, é criado um registo de aplicação no inquilino de gestão 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 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.
Dica
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 registo de aplicação única e as aplicações corporativas associadas (principais de serviço) devem ser monitorados quanto a qualquer atividade anómala nas suas ferramentas de gerenciamento de eventos e informações de segurança (SIEM), uma vez que se trata de 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 contoso.onmicrosoft.com e um aplicativo corporativo está em cada um dos locatários do Microsoft Entra vinculado ao registro do aplicativo. Essa configuração permite que um pipeline autentique e autorize todos os inquilinos do Microsoft Entra usando um único registo de aplicação. Para obter mais informações, consulte Tornando seu aplicativo multilocatário e Conceder consentimento de administrador de todo o locatário para um aplicativo.
Dica
As Identidades Gerenciadas Atribuídas pelo Usuário, em visualização pública, agora podem oferecer suporte a cenários multilocatários configurando uma relação de confiança entre ela e um aplicativo multilocatário Entra ID. Veja mais informações sobre como configurar isso em Configurar um aplicativo para confiar em uma identidade gerenciada (visualização).
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 se lida com múltiplos ambientes, tais como desenvolvimento, teste ou produção, estes podem ser controlados da mesma forma utilizando os mesmos registos de aplicações e aplicações empresariais com pipelines, ou em separado.
Você pode decidir ter pipelines separados para cada inquilino do Microsoft Entra ou usar um único pipeline. A escolha é sua com base nas suas necessidades.
Observação
O Azure Lighthouse funciona de forma semelhante a esta abordagem; no entanto, o Azure Lighthouse não permite a atribuição do proprietário do RBAC, do administrador de acesso de utilizador e de funções com permissões de 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 no 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. Este acesso concede-lhes acesso às ferramentas de desenvolvimento, como o GitHub ou o Azure DevOps, nas quais todos os inquilinos 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 exemplo na primeira abordagem.