Compartilhar via

Implementar comunicação entre locatários usando aplicativos multilocatários

  • Artigo

Este guia fornece uma solução para obter comunicações bidirecionais e seguras entre serviços hospedados em assinaturas do Azure gerenciadas por diferentes locatários do Microsoft Entra.

Proteger as comunicações multilocatários no Azure pode ser um desafio devido às limitações inerentes a muitos serviços. Você pode eliminar a necessidade de gerenciar credenciais diretamente usando identidades gerenciadas do Azure para obter tokens da ID do Microsoft Entra. No entanto, as identidades gerenciadas do Azure não funcionam entre os limites do locatário, e a alternativa típica é usar segredos compartilhados, como URLs de assinatura de acesso compartilhado. Lembre-se de que, se você usar segredos compartilhados, precisará distribuir e girar os segredos com segurança entre os limites de locatário do Microsoft Entra.

Uma opção que evita essa sobrecarga é criar um aplicativo multilocatário para representar a identidade da sua carga de trabalho. Por meio de um processo de consentimento, você pode tornar essa identidade de carga de trabalho conhecida por um locatário externo e, finalmente, permitir que ele autentique serviços no locatário externo.

Este artigo apresenta um exemplo de implementação desse padrão que usa código de exemplo.

Esse padrão pode ser reutilizado para qualquer cenário de multilocatário que tenha vários serviços que precisam se comunicar entre os limites de locatário do Microsoft Entra.

Arquitetura

Um diagrama da arquitetura de comunicação entre locatários.

Baixe um arquivo do PowerPoint dessa arquitetura.

Workflow

O fluxo de dados a seguir corresponde ao diagrama anterior:

  1. Um administrador no lado do provedor cria um registro de aplicativo multilocatário e configura um segredo de cliente para ele.

  2. Um administrador do lado do cliente provisiona uma entidade de serviço em seu locatário. Essa entidade de serviço é baseada no aplicativo multilocatário que o provedor criou. Você pode fazer essa etapa de várias maneiras. No exemplo, optamos por criar uma URL para fornecer ao administrador do locatário do cliente, mas você pode usar a API do Microsoft Graph.

  3. O cliente aplica funções de controle de acesso baseado em função (RBAC) a essa nova entidade de serviço para que ela seja autorizada a acessar o Barramento de Serviço do Azure.

  4. O aplicativo de função do provedor usa a ID do cliente e o segredo do cliente do registro do aplicativo para enviar uma mensagem autenticada para a fila do Barramento de Serviço do cliente.

  5. O aplicativo de função do cliente usa uma identidade gerenciada para ler a mensagem do provedor da fila por meio de um gatilho do Barramento de Serviço.

  6. Depois de receber a mensagem, o aplicativo de função do cliente normalmente faz algum trabalho antes de enviar uma mensagem de status de volta ao provedor. Nesse caso, para fins de demonstração, o aplicativo de função envia imediatamente uma mensagem de status para o provedor em uma fila separada no mesmo Barramento de Serviço.

  7. Esse aplicativo de função lê da fila de status do locatário do cliente por meio de um temporizador acionado pelo Azure Functions.

Detalhes do cenário

Um provedor tem vários clientes. O provedor e cada cliente têm seu próprio locatário individual do Microsoft Entra ID e recursos do Azure. O provedor e cada cliente precisam de um método de comunicação seguro e bidirecional para que possam trocar mensagens por meio de filas do Barramento de Serviço. A solução deve ter uma história de identidade convincente que evite a introdução de credenciais ou segredos desnecessários.

O que saber sobre aplicativos multilocatários

  • Um objeto de aplicativo é uma instância globalmente exclusiva do aplicativo.

  • Quando um aplicativo é registrado no Microsoft Entra, serão criados automaticamente um objeto de aplicativo e um objeto de entidade de serviço no locatário.

  • Um objeto de entidade de serviço é criado em cada locatário que usa o aplicativo e faz referência ao objeto de aplicativo. Um objeto de aplicativo tem um relacionamento um-para-muitos com seu objeto principal de serviço correspondente.

  • O objeto do aplicativo é a representação global do seu aplicativo e é usado entre todos os locatários. O objeto principal de serviço é a representação local usada em um locatário específico.

  • Um objeto principal de serviço deve ser criado em cada locatário onde o aplicativo é usado para que ele possa estabelecer uma identidade para acessar recursos que o locatário protege. Um aplicativo de locatário único tem apenas um objeto principal de serviço em seu locatário doméstico. Esse objeto principal de serviço é criado e permitido para uso durante o registro do aplicativo. Um aplicativo multilocatário também tem um objeto principal de serviço criado em cada locatário e um usuário desse locatário consentiu com seu uso.

  • Para acessar recursos protegidos por um locatário do Microsoft Entra, uma entidade de segurança deve representar a entidade que requer acesso.

  • Quando um aplicativo recebe permissão para acessar os recursos em um locatário (após o registro ou o consentimento), um objeto principal de serviço é criado. Essa arquitetura é implementada com o fluxo de consentimento.

Como o provedor envia mensagens ao cliente?

Idealmente, o provedor é capaz de atribuir uma identidade gerenciada ao recurso de computação do Azure responsável por enviar mensagens para a fila de um cliente. O locatário do cliente é configurado para confiar em identidades gerenciadas do locatário do provedor. No entanto, uma verdadeira federação entre dois locatários do Microsoft Entra, que essencialmente permitiria o "compartilhamento" de identidades de um locatário para outro, não é possível no momento. Portanto, o provedor precisa se autenticar usando uma identidade que o cliente reconheça. O provedor precisa se autenticar no locatário do Microsoft Entra do cliente como uma entidade de serviço que o cliente conhece.

Recomendamos que o provedor registre um aplicativo multilocatário em seu próprio locatário e, em seguida, faça com que cada cliente provisione uma entidade de serviço associada em seu locatário. O provedor pode então autenticar no locatário do cliente e nas APIs hospedadas pelo cliente usando essa entidade de serviço. O provedor nunca precisa compartilhar um segredo do cliente nessa abordagem. O gerenciamento de credenciais é de responsabilidade exclusiva do provedor.

Como o cliente envia mensagens ao provedor?

Recomendamos que o cliente crie ou hospede uma fila a partir da qual o provedor possa ler. O cliente grava uma mensagem na fila. O provedor sonda repetidamente cada fila de clientes em busca de mensagens usando um objeto de entidade de serviço. A desvantagem dessa abordagem é que ela introduz latência de sondagem quando o provedor recebe uma mensagem. O código também precisa ser executado com mais frequência no provedor porque ele deve ser ativado e executar a lógica de sondagem em vez de esperar que um evento o acione. No entanto, o gerenciamento de credenciais continua sendo de responsabilidade exclusiva do provedor, o que reforça a segurança.

Outra solução possível é fazer com que o provedor crie ou hospede uma fila para cada um de seus clientes. Cada cliente cria seu próprio aplicativo multilocatário e solicita que o provedor o provisione em seu locatário como um objeto principal de serviço. Em seguida, o cliente usa esse objeto principal de serviço para enviar mensagens para uma fila específica do cliente no lado do provedor. A gestão de credenciais continua a ser da exclusiva responsabilidade do cliente. Uma desvantagem dessa abordagem é que o provedor deve provisionar entidades de serviço associadas a aplicativos do cliente em seu locatário. Esse processo é manual e os provedores provavelmente não querem que as etapas manuais façam parte do fluxo de integração de um novo cliente.

Configuração do código de exemplo

As etapas a seguir orientam você pelo processo de configuração da comunicação entre locatários entre um provedor e um cliente.

Configuração do provedor

A configuração do provedor inclui as etapas para gerar e provisionar uma entidade de serviço de aplicativo multilocatário e as etapas para provisionar o locatário do cliente.

  1. Crie um aplicativo de função acionado por HTTP para enviar uma mensagem para gravar na fila de comandos do Barramento de Serviço do cliente dentro do locatário do cliente.

  2. Crie um aplicativo de função acionado por tempo para verificar periodicamente uma fila de status dentro do Barramento de Serviço do cliente dentro do locatário do cliente.

Criar um aplicativo multilocatário no locatário do provedor

Primeiro, crie um aplicativo multilocatário no locatário do provedor e provisione essa identidade no locatário do cliente. Nesse cenário, a identidade é uma entidade de serviço. A arquitetura anterior neste artigo mostra como configurar e provisionar uma entidade de serviço do locatário do provedor para o locatário do cliente. A arquitetura também descreve como provisionar com vários locatários do Microsoft Entra.

  1. Escolha a opção de organização multilocatário.

  2. Adicione o seguinte site como o URL de redirecionamento: https://entra.microsoft.com. Você pode alterar esse URL para atender às suas necessidades comerciais.

  3. Registre e anote o valor do ID do aplicativo (cliente).

Criar um novo segredo do cliente

  1. Depois de criar o aplicativo multilocatário, crie um segredo do cliente para essa entidade de serviço.

  2. Salve o segredo gerado em um local seguro. O segredo e a ID do cliente são as credenciais do cliente necessárias para trocar o código, no fluxo de código de autorização e para um token de ID na próxima etapa.

Azure Functions - Acionado por HTTP

Use a função HTTP para iniciar a implantação a partir do locatário do provedor enviando uma mensagem para a fila de implantação do Barramento de Serviço do cliente. Escolhemos a função acionada por HTTP como método de entrega para iniciar essa prova de conceito. A entidade de serviço gerada anteriormente atua como a credencial para acessar o locatário do cliente e gravar em uma fila específica dentro do Barramento de Serviço. Você também precisa concluir a configuração do cliente para que essa etapa funcione corretamente.

Azure Functions - Acionado por temporizador

Use a função acionada por temporizador para sondar a fila de status de implantação de dentro do locatário do cliente. Pesquisamos a fila de status de implantação a cada 10 segundos para fins de demonstração nesta prova de conceito. Essa abordagem elimina a necessidade de o cliente ter uma entidade de serviço para acessar o locatário do provedor.

Configuração do cliente

  1. Provisione a entidade de serviço modificando e usando a URL fornecida.

  2. Defina o escopo da entidade de serviço do provedor para usar os controles RBAC apropriados.

  3. Crie uma função acionada pelo Barramento de Serviço para ler uma mensagem de uma fila de mensagens do Barramento de Serviço e colocar uma mensagem em outra fila. Para fins de demonstração, esse fluxo é ideal para testar a funcionalidade.

  4. Crie uma identidade gerenciada atribuída pelo sistema para a função acionada do Barramento de Serviço.

  5. Atribua o escopo do Barramento de Serviço de identidade gerenciada atribuído pelo sistema.

Provisionar a entidade de serviço do locatário do provedor para o locatário do cliente

  1. Visite a seguinte URL depois de substituir o client_id parâmetro de cadeia de caracteres de consulta por sua própria ID de cliente: https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?response_type=code&response_mode=query&scope=openid&client_id=<your_client_ID>.

    Você também pode provisionar a entidade de serviço em outro locatário do Microsoft Entra com uma chamada de administrador da API do Microsoft Graph, um comando do PowerShell do Azure ou um comando da CLI do Azure.

  2. Faça login com uma conta do locatário do cliente.

  3. Na tela de consentimento, selecione Aceitar para provisionar o aplicativo do provedor no locatário do cliente. A URL eventualmente redireciona para microsoft.com, que ainda tem o efeito desejado de provisionar a identidade no locatário do cliente.

  4. Verifique a identidade no locatário do Microsoft Entra do cliente acessando Aplicativos Corporativos para ver a entidade de serviço recém-provisionada.

Configurar o RBAC para a entidade de serviço provisionada

Defina o escopo da entidade de serviço do provedor a partir da configuração da entidade de serviço do provedor para ter funções de "Proprietário de Dados do Barramento de Serviço" no Barramento de Serviço. Essa entidade de serviço é usada tanto na gravação em uma fila com uma função acionada por HTTP quanto na leitura de uma fila de uma função acionada por temporizador. Certifique-se de adicionar a função "Proprietário de Dados do Barramento de Serviço do Azure" à entidade de serviço.

Azure Functions - Gatilho do Barramento de Serviço

Siga as etapas no tutorial de funções baseadas em identidade para definir o gatilho de função da fila do Barramento de Serviço e aprender a configurar uma identidade gerenciada. Esta orientação ajuda a acionar o aplicativo de função da fila do Barramento de Serviço quando uma mensagem é adicionada à fila. Você também usa a identidade gerenciada ao colocar uma mensagem em uma fila diferente. Para fins de demonstração, usamos a mesma função para enviar a mensagem.

No namespace do Barramento de Serviço recém-criado, selecione Controle de Acesso (IAM). Você pode exibir e configurar quem tem acesso ao recurso no plano de controle.

Conceda ao aplicativo de função acesso ao namespace do Barramento de Serviço usando identidades gerenciadas

  1. Certifique-se de adicionar a função "Receptor de Dados do Barramento de Serviço do Azure" à identidade gerenciada.

  2. No seletor de identidade gerenciada, escolha Aplicativo de Função na categoria de Identidade gerenciada atribuída pelo sistema. O rótulo Aplicativo de Função pode ter um número entre parênteses ao lado dele. Esse número indica quantos aplicativos que têm identidades atribuídas pelo sistema estão na assinatura.

Conectar-se ao Barramento de Serviço em seu aplicativo de funções

  1. No portal, procure seu aplicativo de função ou vá até ele na página Aplicativo de função .

  2. Em Configurações de aplicativo, selecione + Novo para criar uma nova configuração de aplicativo na tabela. Service BusConnection__fullyQualifiedNamespace <SERVICE_BUS_NAMESPACE>.Service Bus.windows.net.

Gerenciamento do ciclo de vida do segredo do cliente principal de serviço

Se você introduzir segredos em sua arquitetura entre locatários, precisará gerenciar o ciclo de vida desses segredos de cliente gerados. Consulte Práticas recomendadas para gerenciamento de segredos para saber como armazenar, girar e monitorar segredos do cliente com segurança.

Configurações locais

Cada subdiretório contém uma versão resumida dos local.settings.json arquivos, que pode ser modificada para executar as funções do Azure localmente. Para definir configurações no Azure, atualize as Configurações do Aplicativo.

O DefaultAzureCredential comando enumera várias configurações antes de atingir a credencial da CLI do Azure. Para evitar confusão, recomendamos executar o az login -t <tenant ID> comando para selecionar as credenciais corretas ao desenvolver funções locais.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Próximas etapas