Editar

Compartilhar via

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

Azure

Sempre que o aplicativo recebe uma solicitação, é necessário identificar o locatário para o qual ela se destina. Quando você tem uma infraestrutura específica para um locatário que pode até ser hospedada em diferentes regiões geográficas, é preciso relacionar a solicitação recebida 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:

Diagram showing mapping a request from tenants to deployments.

Nesta página, há diretrizes para os responsáveis por decisões técnicas sobre as abordagens que você pode considerar para mapear solicitações para o locatário correto, bem como as vantagens e desvantagens dessas abordagens.

Observação

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

Abordagens para a identificação de locatários

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

Nomes de domínios

Se você usa nomes de domínio ou subdomínio específicos para o locatário, fica mais fácil mapear com o cabeçalho Host ou outro cabeçalho HTTP que inclua o nome do host original de cada solicitação.

No entanto, pense no seguinte:

  • 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 aterrissagem ou página de logon, que todos os locatários usam? Em caso positivo, como os usuários identificarão o locatário que precisam acessar?
  • Quais outras informações você usa 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 da solicitação HTTP

Se você não usa nomes de domínio específicos para o locatário, ainda pode aproveitar aspectos da solicitação HTTP para identificar o locatário destinatário de uma determinada solicitação. Por exemplo, imagine uma solicitação HTTP que identifica o nome do locatário como tailwindtraders. Essa informação pode ser comunicada das seguintes maneiras:

  • 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 X-Tenant-Id: tailwindtraders.

Importante

Cabeçalhos de solicitação HTTP personalizados não são úteis quando as solicitações HTTP GET são emitidas de um navegador da Web ou quando as solicitações são processadas por alguns tipos de proxy 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 Web incluído na cadeia de processamento de solicitações.

Ao seguir essa abordagem, você deve se perguntar:

  • Os usuários saberão como acessar o serviço? Por exemplo, se você usar uma cadeia de caracteres de consulta para identificar locatários, uma página de aterrissagem 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 aterrissagem ou página de logon, que todos os locatários usam? Em caso positivo, como os usuários identificarão o locatário que precisam acessar?
  • Seu aplicativo fornece APIs? Por exemplo, seu aplicativo Web é um SPA (aplicativo de página única) ou um aplicativo móvel com um back-end de API? Em caso positivo, você poderá usar um gateway de API ou proxy reverso para realizar o mapeamento de locatário.

Declarações de token

Muitos aplicativos usam protocolos de autenticação e autorização baseados em declarações, 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 informações sobre o aplicativo cliente ou o usuário. As declarações podem ser usadas para comunicar informações como o endereço de email de um usuário. Assim, seu sistema pode incluir o endereço de email do usuário, pesquisar o mapeamento de usuário para locatário e encaminhar a solicitação para implantação correta. Ou você pode 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ê usa declarações para mapear solicitações para locatários, faça estas perguntas:

  • Você usará uma declaração para identificar um locatário? Qual declaração você usará?
  • 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 os quais gostariam de trabalhar?
  • Há um sistema central de autenticação e autorização para todos os locatários? Caso contrário, como você garantirá que todas as autoridades de token emitam tokens e declarações consistentes?

Chaves de API

Muitos aplicativos expõem APIs, para uso interno na organização ou externo por parceiros ou clientes. Um método comum de autenticação para APIs é a chave de API. As chaves de API são fornecidas com cada solicitação, podem ser usadas para pesquisar o locatário

e podem ser geradas de várias maneiras. Uma abordagem comum é gerar um valor aleatório criptograficamente e armazená-lo em uma tabela de pesquisa, juntamente com a ID do locatário. Quando uma solicitação é recebida, o sistema localiza a chave de API na tabela de pesquisa e a combina com uma ID de locatário. Outra abordagem é criar uma cadeia de caracteres significativa com uma ID de locatário incluída e, em seguida, assinar digitalmente a chave seguindo uma abordagem como HMAC. Ao processar cada solicitação, você verifica a assinatura e, em seguida, extrai a ID do locatário.

Observação

As chaves de API não fornecem um alto nível de segurança porque precisam ser criadas e gerenciadas manualmente e 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 seguintes perguntas:

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

Observação

As chaves de API não são iguais às senhas, devem ser geradas pelo sistema e serem únicas em todos os locatários, para que cada uma 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 do cliente

A autenticação de certificado do cliente, às vezes chamada de TLS mútua (mTLS), é comumente usada para comunicação entre serviços. Os certificados do cliente são um jeito seguro de autenticar clientes. Semelhantes a tokens e declarações, os certificados do cliente incluem atributos que podem ser usados para identificar o locatário. Por exemplo, o assunto do certificado pode conter o endereço de email do usuário, que pode ser usado para pesquisar o locatário.

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

  • Como você emitirá e renovará com segurança os certificados de cliente confiáveis no serviço? Os certificados do cliente podem ser complexos, pois exigem infraestrutura especial para gerenciar e emitir certificados.
  • Os certificados do cliente serão usados somente para solicitações de logon inicial ou anexados a todas as solicitações ao serviço?
  • O processo de emissão e gerenciamento de certificados se tornará incontrolável quando você 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 encaminhá-la para um dos muitos pontos de extremidade de back-end. Proxies reversos são úteis para aplicativos multilocatários, pois podem executar o mapeamento com algumas informações da solicitação, eliminando essa tarefa na infraestrutura do aplicativo.

Muitos proxies reversos podem usar as propriedades de uma solicitação para tomar uma decisão sobre o roteamento de 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 dos tokens.

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

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

Validação da solicitação

É importante que seu aplicativo valide que todas as solicitações recebidas são autorizadas para o locatário. Por exemplo, se o aplicativo usa um nome de domínio personalizado para mapear solicitações para o locatário, ainda deve verificar se cada solicitação recebida está 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ê deve conceder acesso automaticamente. Ao usar o OAuth 2.0, você executa a validação inspecionando o público-alvo e as declarações de escopo .

Observação

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

Ao implementar a validação de solicitação, considere:

  • Como você autorizará todas as solicitações ao aplicativo? Você precisa autorizar solicitações, independentemente da abordagem usada para mapeá-las na infraestrutura física.
  • Use frameworks e middleware de autenticação e autorização confiáveis, amplamente usados e bem mantidos, em vez de implementar toda a lógica de validação por conta própria. Por exemplo, não crie uma lógica de validação de assinatura de token nem bibliotecas de criptografia de certificado do cliente. Em vez disso, use recursos da 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 cada solicitação ao aplicativo. Considere o desempenho de escala do processo de mapeamento de locatário conforme a 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 será compatível com uma grande quantidade de carga? Se o mapeamento de locatário exigir a descriptografação de um token, os requisitos de computação ficarão muito altos ao longo do tempo? Se o tráfego for bastante modesto, isso provavelmente não afetará o desempenho geral. No entanto, quando você tem um aplicativo de alta escala, 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 a 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, seu aplicativo fornece um cookie de sessão para o cliente. O cliente passa o cookie de sessão de volta para seu serviço com todas as solicitações de cliente subsequentes nessa sessão.

Observação

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 seguintes perguntas:

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

Migração de locatário

Muitas vezes, é necessário mover os locatários para uma nova infraestrutura como parte do ciclo de vida dessas organizações. Quando isso acontece, os pontos de extremidade HTTP acessados por esses locatários podem mudar. Assim, talvez seja necessário atualizar o processo de mapeamento de locatário. Considere os seguintes fatores:

  • Se o aplicativo usa nomes de domínio para mapear solicitações, também será necessário alterar o DNS na hora da migração. Essa mudança pode levar tempo para ser propagada aos clientes, dependendo do tempo de vida das entradas DNS no serviço correspondente.
  • Se o processo de migração alterar os endereços dos pontos de extremidade, redirecione temporariamente as solicitações para o locatário à página de manutenção que é atualizada de modo automático.

Colaboradores

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

Autor principal:

Outros colaboradores:

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

Próximas etapas

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