Share 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 comunicações multilocatárias no Azure pode ser um desafio devido a limitações inerentes a muitos serviços. Você pode eliminar a necessidade de gerenciar credenciais diretamente usando identidades gerenciadas do Azure para obter tokens do Microsoft Entra ID. 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 para 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 multilocatário que tenha vários serviços que precisam se comunicar entre os limites do locatário do Microsoft Entra.

Arquitetura

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

Transfira um ficheiro PowerPoint desta arquitetura.

Fluxo de Trabalho

O fluxo de trabalho a seguir corresponde ao diagrama anterior:

  1. Um administrador do 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 RBAC (controle de acesso baseado em função) a essa nova entidade de serviço para que ele esteja autorizado 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 Service Bus 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 Service Bus.

  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 Service Bus.

  7. Este aplicativo de função lê a 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 Service Bus. 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, um objeto de aplicativo e um objeto de entidade de serviço são criados automaticamente 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 do aplicativo. Um objeto de aplicativo tem uma relação um-para-muitos com seu objeto principal de serviço correspondente.

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

  • Um objeto de entidade 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. Este 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 recursos em um locatário mediante registro ou consentimento, um objeto principal de serviço é criado. Essa arquitetura é implementada com o fluxo de consentimento.

Como é que o fornecedor envia mensagens ao cliente?

Idealmente, o provedor é capaz de atribuir uma identidade gerenciada ao recurso de computação do Azure que é 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 é atualmente possível. Assim, o provedor precisa 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 forneça uma entidade de serviço associada em seu locatário. O provedor pode então autenticar o locatário do cliente e as APIs hospedadas pelo cliente usando essa entidade de serviço. O provedor nunca precisa compartilhar um segredo do cliente nessa abordagem. A gestão de credenciais é da exclusiva responsabilidade do fornecedor.

Como é que o cliente envia mensagens ao fornecedor?

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 principal 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 despertar e executar a lógica de sondagem em vez de esperar que um evento o acione. No entanto, a gestão de credenciais continua a ser da exclusiva responsabilidade do fornecedor, 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 forneça 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.

Exemplo de configuração de código

As etapas a seguir guiam 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 Service Bus 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 Service Bus do cliente dentro do locatário do cliente.

Criar um aplicativo multilocatário dentro do 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 anteriormente 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 URI de redirecionamento: https://entra.microsoft.com. Você pode alterar esse URI para atender às suas necessidades de negócios.

  3. Registe-se e tome nota do valor do ID da aplicação (cliente).

Criar um novo segredo do cliente

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

  2. Salve o segredo gerado em um local seguro. O segredo e o 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 Service Bus do cliente. Escolhemos a função acionada por HTTP como o método de entrega para iniciar esta 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 no Service Bus. Você também precisa concluir a configuração do cliente para que esta etapa funcione corretamente.

Azure Functions - acionado por temporizador

Use a função acionada pelo temporizador para sondar a fila de status da 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. Escopo da entidade de serviço do provedor para usar os controles RBAC apropriados.

  3. Crie uma função acionada do Service Bus para ler uma mensagem de uma fila de mensagens do Service Bus 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 ao sistema para a função acionada do Service Bus.

  5. Atribua o escopo do Service Bus 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 o seguinte URL depois de substituir o parâmetro de cadeia de caracteres de consulta pelo seu próprio ID de client_id 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 API admin do Microsoft Graph, um comando do Azure PowerShell ou um comando da CLI do Azure.

  2. Inicie sessão com uma conta do inquilino 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, o que ainda tem o efeito desejado de provisionar a identidade no locatário do cliente.

  4. Verifique a identidade dentro do locatário do Microsoft Entra do cliente acessando Aplicativos Empresariais 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 Service Bus" no Service Bus. 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 a partir 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 Service Bus

Siga as etapas no tutorial de funções baseadas em identidade para definir o gatilho de função da fila do Service Bus e aprender a configurar uma identidade gerenciada. Esta orientação ajuda você 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 quando coloca uma mensagem em uma fila diferente. Para fins de demonstração, usamos a mesma função para enviar a mensagem.

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

Conceder ao aplicativo função acesso ao namespace do Service Bus usando identidades gerenciadas

  1. Certifique-se de adicionar a função "Recetor 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 com identidades atribuídas ao sistema estão na assinatura.

Conectar-se ao Service Bus em seu aplicativo de função

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

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

Gerenciamento do ciclo de vida do segredo do cliente principal do 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 de clientes com segurança.

Configurações locais

Cada subdiretório contém uma versão fragmentada dos local.settings.json arquivos, que pode ser modificada para executar as funções do Azure localmente. Para definir as 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 conceder as credenciais corretas ao desenvolver funções locais.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

  • Audrey Long - Brasil | Engenheiro de Software de Segurança Sênior
  • Ashton Mickey - Brasil | Engenheiro de Software Principal
  • John Garland - Brasil | Engenheiro de Software Principal

Próximos passos