Editar

Partilhar via

Mapear solicitações para locatários em uma solução multilocatária

Azure

Sempre que uma solicitação chega ao seu aplicativo, você precisa determinar o locatário ao qual a solicitação se destina. Quando você tem uma infraestrutura específica do locatário que pode até ser hospedada em regiões geográficas diferentes, você precisa corresponder a solicitação de entrada a um locatário. Em seguida, você deve encaminhar a solicitação para a infraestrutura física que hospeda os recursos desse locatário, conforme ilustrado abaixo:

Diagrama mostrando o mapeamento de uma solicitação de locatários para implantações.

Nesta página, fornecemos orientação para os tomadores de decisão técnica sobre as abordagens que você pode considerar para mapear solicitações para o locatário apropriado e as compensações envolvidas nas abordagens.

Nota

Esta página discute principalmente aplicativos baseados em HTTP, como sites e APIs. No entanto, muitos dos mesmos princípios subjacentes se aplicam a aplicativos multilocatários que usam outros protocolos de comunicação.

Abordagens para identificar inquilinos

Há várias maneiras de identificar o locatário para uma solicitação de entrada.

Nomes de domínio

Se você usar nomes de domínio ou subdomínio específicos do locatário, é provável que as solicitações possam ser facilmente mapeadas para locatários usando o Host cabeçalho ou outro cabeçalho HTTP que inclua o nome de host original para cada solicitação.

No entanto, considere as seguintes perguntas:

  • Como os usuários saberão qual nome de domínio usar para acessar o serviço?
  • Você tem um ponto de entrada central, como uma página de destino ou página de login, que todos os locatários usam? Se você fizer isso, como os usuários identificarão o locatário que precisam acessar?
  • Que outras informações você está usando para verificar o acesso ao locatário, como tokens de autorização? Os tokens de autorização incluem os nomes de domínio específicos do locatário?

Propriedades de solicitação HTTP

Se você não usar nomes de domínio específicos do locatário, ainda poderá usar aspetos da solicitação HTTP para identificar o locatário para o qual uma solicitação específica se destina. Por exemplo, considere uma solicitação HTTP que identifique o nome do locatário como tailwindtraders. Isso pode ser comunicado usando o seguinte:

  • A estrutura do caminho da URL, como https://app.contoso.com/tailwindtraders/.
  • Uma cadeia de caracteres de consulta na URL, como https://contoso.com/app?tenant=tailwindtraders.
  • Um cabeçalho de solicitação HTTP personalizado, como Tenant-Id: tailwindtraders.

Importante

Os cabeçalhos de solicitação HTTP personalizados não são úteis quando as solicitações HTTP GET são emitidas a partir de um navegador da Web ou quando as solicitações são tratadas por alguns tipos de proxy da Web. Você só deve usar cabeçalhos HTTP personalizados para operações GET quando estiver criando uma API ou se controlar o cliente que emite a solicitação e não houver nenhum proxy da Web incluído na cadeia de processamento da solicitação.

Ao usar essa abordagem, você deve considerar as seguintes perguntas:

  • Os utilizadores saberão como aceder ao serviço? Por exemplo, se você usar uma cadeia de caracteres de consulta para identificar locatários, uma página de destino central precisará direcionar os usuários para o locatário correto, adicionando a cadeia de caracteres de consulta?
  • Você tem um ponto de entrada central, como uma página de destino ou página de login, que todos os locatários usam? Se você fizer isso, como os usuários identificarão o locatário que precisam acessar?
  • Seu aplicativo fornece APIs? Por exemplo, seu aplicativo Web é um aplicativo de página única (SPA) ou um aplicativo móvel com um back-end de API? Se estiver, você poderá usar um gateway de API ou proxy reverso para executar o mapeamento de locatário.

Declarações de token

Muitos aplicativos usam autenticação baseada em declarações e protocolos de autorização, como OAuth 2.0 ou SAML. Esses protocolos fornecem tokens de autorização para o cliente. Um token contém um conjunto de declarações, que são partes de informações sobre o aplicativo cliente ou usuário. As declarações podem ser usadas para comunicar informações como o endereço de e-mail de um usuário. Seu sistema pode então incluir o endereço de e-mail do usuário, procurar o mapeamento de usuário para locatário e, em seguida, encaminhar a solicitação para a implantação apropriada. Ou, você pode até incluir o mapeamento de locatário em seu sistema de identidade e adicionar uma declaração de ID de locatário ao token.

Se você estiver usando declarações para mapear solicitações para locatários, considere as seguintes perguntas:

  • Você usará uma reivindicação para identificar um inquilino? Que alegação irá utilizar?
  • Um usuário pode ser membro de vários locatários? Se isso for possível, como os usuários selecionarão os locatários com quem gostariam de trabalhar?
  • Existe um sistema central de autenticação e autorização para todos os inquilinos? Se não, como você garantirá que todas as autoridades de token emitam tokens e declarações consistentes?

Chaves de API

Muitos aplicativos expõem APIs. Estes podem ser para uso interno dentro da sua organização ou para uso externo por parceiros ou clientes. Um método comum de autenticação para APIs é usar uma chave de API. As chaves de API são fornecidas com cada solicitação e podem ser usadas para procurar o locatário.

As chaves de API podem ser geradas de várias maneiras. Uma abordagem comum é gerar um valor criptograficamente aleatório e armazená-lo em uma tabela de pesquisa, juntamente com o ID do locatário. Quando uma solicitação é recebida, seu sistema encontra a chave de API na tabela de pesquisa e, em seguida, ela faz a correspondência com uma ID de locatário. Outra abordagem é criar uma cadeia de caracteres significativa com um ID de locatário incluído dentro dela e, em seguida, você assinaria digitalmente a chave, usando uma abordagem como HMAC. Ao processar cada solicitação, você verifica a assinatura e, em seguida, extrai a ID do locatário.

Nota

As chaves de API não fornecem um alto nível de segurança porque precisam ser criadas e gerenciadas manualmente e porque não contêm declarações. Uma abordagem mais moderna e segura é usar um mecanismo de autorização baseado em declarações com tokens de curta duração, como OAuth 2.0 ou OpenID Connect.

Considere as perguntas seguintes:

  • Como você vai gerar e emitir chaves de API?
  • Como seus clientes de API receberão e armazenarão a chave de API com segurança?
  • Você precisa que suas chaves de API expirem após um período de tempo? Como você vai girar as chaves de API de seus clientes, sem causar tempo de inatividade?
  • Depender apenas de chaves de API roladas pelo cliente fornece um nível adequado de segurança para suas APIs?

Nota

As chaves de API não são o mesmo que senhas. As chaves de API devem ser geradas pelo sistema e devem ser exclusivas em todos os locatários, para que cada chave de API possa ser mapeada exclusivamente para um único locatário. Os gateways de API, como o Gerenciamento de API do Azure, podem gerar e gerenciar chaves de API, validar chaves em solicitações de entrada e mapear chaves para assinantes de API individuais.

Certificados de cliente

A autenticação de certificado de cliente, às vezes chamada de TLS mútuo (mTLS), é comumente usada para comunicação de serviço a serviço. Os certificados de cliente fornecem uma maneira segura de autenticar clientes. Da mesma forma que tokens e declarações, os certificados de cliente fornecem atributos que podem ser usados para determinar o locatário. Por exemplo, o assunto do certificado pode conter o endereço de e-mail do usuário, que pode ser usado para procurar o locatário.

Ao planejar o uso de certificados de cliente para mapeamento de locatário, considere o seguinte:

  • Como você emitirá e renovará com segurança os certificados de cliente confiáveis pelo seu serviço? Os certificados de cliente podem ser complexos de trabalhar, uma vez que requerem uma infraestrutura especial para gerenciar e emitir certificados.
  • Os certificados de cliente serão usados apenas para solicitações iniciais de login ou anexados a todas as solicitações ao seu serviço?
  • O processo de emissão e gestão de certificados tornar-se-á incontrolável quando tiver um grande número de clientes?
  • Como você implementará o mapeamento entre o certificado do cliente e o locatário?

Proxies reversos

Um proxy reverso, também conhecido como proxy de aplicativo, pode ser usado para rotear solicitações HTTP. Um proxy reverso aceita uma solicitação de um ponto de extremidade de entrada e pode encaminhar a solicitação para um dos muitos pontos de extremidade de back-end. Os proxies reversos são úteis para aplicativos multilocatário, pois podem executar o mapeamento entre algumas informações de solicitação, descarregando a tarefa da infraestrutura do aplicativo.

Muitos proxies reversos podem usar as propriedades de uma solicitação para tomar uma decisão sobre o roteamento do locatário. Eles podem inspecionar o nome de domínio de destino, o caminho da URL, a cadeia de caracteres de consulta, os cabeçalhos HTTP e até mesmo as declarações dentro de tokens.

Os seguintes proxies reversos comuns são usados no Azure:

  • O Azure Front Door é um balanceador de carga global e firewall de aplicativo Web. Ele usa a rede de borda global da Microsoft para criar aplicativos Web rápidos, seguros e altamente escaláveis.
  • O Gateway de Aplicativo do Azure é um balanceador de carga de tráfego da Web gerenciado que você implanta na mesma região física do seu serviço de back-end.
  • O Gerenciamento de API do Azure é otimizado para o tráfego da API.
  • As tecnologias comerciais e de código aberto (que você mesmo hospeda) incluem nginx, Traefik e HAProxy.

Validação do pedido

É importante que seu aplicativo valide se todas as solicitações recebidas são autorizadas para o locatário. Por exemplo, se seu aplicativo usa um nome de domínio personalizado para mapear solicitações para o locatário, seu aplicativo ainda deve verificar se cada solicitação recebida pelo aplicativo é autorizada para esse locatário. Embora a solicitação inclua um nome de domínio ou outro identificador de locatário, isso não significa que você deva conceder acesso automaticamente. Ao usar o OAuth 2.0, você executa a validação inspecionando as declarações de audiência e escopo .

Nota

Isso faz parte do princípio de design de segurança de confiança zero assumido no Microsoft Azure Well-Architected Framework.

Ao implementar a validação de solicitação, você deve considerar o seguinte:

  • Como irá autorizar todos os pedidos à sua candidatura? Você precisa autorizar solicitações, independentemente da abordagem usada para mapeá-las para a infraestrutura física.
  • Use estruturas e middleware de autenticação e autorização confiáveis, amplamente utilizados e bem conservados, em vez de implementar toda a lógica de validação por conta própria. Por exemplo, não crie lógica de validação de assinatura de token ou bibliotecas de criptografia de certificado de cliente. Em vez disso, use recursos da sua plataforma de aplicativo (ou pacotes confiáveis conhecidos) que foram validados e testados.

Desempenho

A lógica de mapeamento de locatário provavelmente é executada em todas as solicitações ao seu aplicativo. Considere o quão bem o processo de mapeamento de locatários será dimensionado à medida que sua solução cresce. Por exemplo, se você consultar uma tabela de banco de dados como parte do mapeamento de locatário, o banco de dados suportará uma grande quantidade de carga? Se o mapeamento do locatário exigir a descriptografia de um token, os requisitos de computação se tornarão muito altos com o tempo? Se o seu tráfego for bastante modesto, isso provavelmente não afetará seu desempenho geral. Quando você tem um aplicativo de alta escala, no entanto, a sobrecarga envolvida nesse mapeamento pode se tornar significativa.

Afinidade de sessão

Uma abordagem para reduzir a sobrecarga de desempenho da lógica de mapeamento de locatário é usar afinidade de sessão. Em vez de executar o mapeamento em cada solicitação, considere calcular as informações apenas na primeira solicitação de cada sessão. Em seguida, a sua aplicação fornece um cookie de sessão ao cliente. O cliente passa o cookie de sessão de volta para o seu serviço com todas as solicitações subsequentes do cliente dentro dessa sessão.

Nota

Muitos serviços de rede e aplicativos no Azure podem emitir cookies de sessão e rotear solicitações nativamente usando afinidade de sessão.

Considere as perguntas seguintes:

  • Você pode usar a afinidade de sessão para reduzir a sobrecarga de solicitações de mapeamento para locatários?
  • Quais serviços você usa para rotear solicitações para as implantações físicas de cada locatário? Estes serviços suportam afinidade de sessão baseada em cookies?

Migração de locatários

Os inquilinos muitas vezes precisam ser movidos para uma nova infraestrutura como parte do ciclo de vida do locatário. Quando um locatário é movido para uma nova implantação, os pontos de extremidade HTTP que eles acessam podem mudar. Quando isso acontecer, considere que seu processo de mapeamento de locatários precisa ser atualizado. Pode ser necessário considerar o seguinte:

  • Se seu aplicativo usa nomes de domínio para mapear solicitações, ele também pode exigir uma alteração de DNS no momento da migração. A alteração de DNS pode levar tempo para se propagar para os clientes, dependendo do tempo de vida útil das entradas DNS no seu serviço DNS.
  • Se a migração alterar os endereços de quaisquer pontos de extremidade durante o processo de migração, considere redirecionar temporariamente as solicitações do locatário para uma página de manutenção que seja atualizada automaticamente.

Contribuidores

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

Autor principal:

Outros contribuidores:

  • John Downs - Brasil | Engenheiro de Software Principal
  • Paolo Salvatori - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
  • Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

Saiba mais sobre as considerações ao trabalhar com nomes de domínio em um aplicativo multilocatário.