Compartilhar via

Considerações de nome de domínio em soluções multilocatários

Em muitos aplicativos Web multilocatários, você pode usar um nome de domínio para fornecer os seguintes recursos:

  • Para distinguir um locatário de outro

  • Para ajudar com o roteamento de solicitações para a infraestrutura correta

  • Para fornecer uma experiência de marca para seus clientes

Você pode usar subdomínios ou nomes de domínio personalizados. Este artigo fornece diretrizes para tomadores de decisão técnicos sobre abordagens de nome de domínio e suas compensações.

Subdomínios

Você pode atribuir a cada locatário um subdomínio exclusivo em um nome de domínio compartilhado comum usando um formato como tenant.provider.com.

Considere um exemplo de solução multilocatário criada pela Contoso. Os clientes compram o produto da Contoso para ajudar a gerenciar a criação de faturas. A Contoso atribui a todos os locatários seu próprio subdomínio sob o nome de contoso.com domínio. Se a Contoso usar implantações regionais, eles podem atribuir subdomínios sob os domínios us.contoso.com e eu.contoso.com.

Este artigo refere-se a esses domínios regionais como domínios de tronco. Cada cliente obtém seu próprio subdomínio em seu domínio de tronco. Por exemplo, a Tailwind Toys pode receber tailwind.contoso.com. Se você usar um modelo de implantação regional, a Adventure Works poderá receber adventureworks.us.contoso.com.

Observação

Muitos serviços do Azure usam essa abordagem. Por exemplo, quando você cria uma conta de armazenamento do Azure, o Azure atribui um conjunto de subdomínios, como <your account name>.blob.core.windows.net.

Gerenciar seu namespace de domínio

Ao criar subdomínios em seu próprio nome de domínio, você pode ter vários clientes com nomes semelhantes. Eles compartilham um único domínio de haste, de modo que o primeiro cliente a reivindicar um domínio específico recebe seu nome preferencial. Os clientes subsequentes precisam usar nomes de subdomínio alternativos porque os nomes de domínio completos devem permanecer globalmente exclusivos.

DNS curinga

Utilize entradas curinga no Sistema de Nomes de Domínio (DNS) para simplificar o gerenciamento de subdomínios. Em vez de criar entradas DNS para tailwind.contoso.com ou adventureworks.contoso.com, você pode criar uma entrada curinga para *.contoso.com. Direcione todos os subdomínios para um único endereço IP usando um registro A ou um nome canônico usando um registro CNAME. Se usar domínios-tronco regionais, talvez você precise de várias entradas curinga, como *.us.contoso.com e *.eu.contoso.com.

Observação

Certifique-se de que seus serviços de camada da Web suportem DNS curinga se você planeja usar esse recurso. Muitos serviços do Azure, incluindo Azure Front Door e Serviço de Aplicativo do Azure, dão suporte a entradas DNS curinga.

Subdomínios baseados em domínios raiz de várias partes

Muitas soluções multilocatário abrangem várias implantações físicas. Essa abordagem é comum quando você precisa cumprir os requisitos de residência de dados ou melhorar o desempenho implantando recursos geograficamente mais próximos dos usuários.

Mesmo em uma única região, você pode espalhar seus locatários entre implantações independentes para dar suporte à sua estratégia de dimensionamento. Se você planeja usar subdomínios para cada locatário, considere uma estrutura de subdomínio de várias partes.

Por exemplo, a Contoso publica um aplicativo multilocatário para seus quatro clientes. A Adventure Works e a Tailwind Traders estão nos Estados Unidos e seus dados são armazenados em uma instância compartilhada dos EUA da plataforma Contoso. Os importadores globais e da Fabrikam têm sede na Europa, e seus dados são armazenados em uma instância europeia.

O diagrama a seguir mostra um exemplo de uso do domínio único contoso.com pela Contoso para todos os seus clientes.

Diagrama que mostra as implantações dos EUA e da Europa de um aplicativo Web, com um único domínio de tronco para o subdomínio de cada cliente.

A Contoso pode usar as seguintes entradas DNS para dar suporte a essa configuração.

Subdomínio CNAME para
adventureworks.contoso.com us.contoso.com
tailwind.contoso.com us.contoso.com
fabrikam.contoso.com eu.contoso.com
worldwideimporters.contoso.com eu.contoso.com

Cada novo cliente integrado requer um novo subdomínio. O número de subdomínios aumenta com cada cliente.

Como alternativa, a Contoso poderia usar domínios stem específicos para implantação ou região.

Diagrama que mostra implantações dos EUA e da UE de um aplicativo web, com múltiplos subdomínios.

Ao usar o DNS curinga, as entradas de DNS para essa implantação podem se parecer com as seguintes entradas.

Subdomínio CNAME para
*.us.contoso.com us.contoso.com
*.eu.contoso.com eu.contoso.com

A Contoso não precisa criar registros de subdomínio para cada cliente. Em vez disso, um único registro DNS curinga para cada implantação geográfica permite que os novos clientes abaixo desse tronco herdem automaticamente o registro CNAME.

Cada uma delas tem benefícios e desvantagens. Ao usar um domínio raiz único, você deve criar um registro DNS para cada locatário adicionado, o que resulta em maior sobrecarga operacional. No entanto, você tem mais flexibilidade para mover locatários entre implantações. Você pode alterar o registro CNAME para direcionar o tráfego para outra implantação. Essa alteração não afeta nenhum outro locatário.

Os domínios com múltiplos núcleos têm uma sobrecarga de gerenciamento menor. Você pode reutilizar nomes de clientes em vários domínios de tronco regionais porque cada domínio de tronco representa efetivamente seu próprio namespace.

Nomes de domínio personalizados

Convém permitir que seus clientes tragam seus próprios nomes de domínio. Alguns clientes veem esse recurso como um aspecto importante de sua identidade visual. Os clientes também podem exigir nomes de domínio personalizados para atender aos requisitos de segurança, especialmente se precisarem fornecer seus próprios certificados TLS (Transport Layer Security). Essa abordagem pode parecer simples, mas algumas complexidades ocultas exigem consideração atenciosa.

Resolução de nomes

Por fim, cada nome de domínio deve ser resolvido para um endereço IP. Conforme mostrado anteriormente, o processo de resolução de nomes depende de você implantar uma única instância ou várias instâncias da solução.

Para revisitar o exemplo, um dos clientes da Contoso, Fabrikam, solicita usar invoices.fabrikam.com como nome de domínio personalizado para acessar o serviço da Contoso. A Contoso tem várias implantações de sua plataforma multilocatário e, por isso, decide usar subdomínios e registros CNAME para atingir seus requisitos de roteamento. Contoso e Fabrikam configuram os seguintes registros DNS.

Nome Tipo de registro Valor Configurado por
invoices.fabrikam.com CNAME fabrikam.eu.contoso.com Fabrikam
*.eu.contoso.com CNAME eu.contoso.com Contoso
eu.contoso.com A (Endereço IP da Contoso) Contoso

De uma perspectiva de resolução de nomes, essa cadeia de registros resolve com precisão solicitações de invoices.fabrikam.com para o endereço IP da implantação europeia da Contoso.

Resolução de cabeçalho de host

A resolução de nomes é apenas parte do problema. Todos os componentes da Web na implantação europeia da Contoso devem saber como lidar com solicitações que incluem o nome de domínio da Fabrikam em seu Host cabeçalho de solicitação. Dependendo das tecnologias da Web específicas que a Contoso usa, o nome de domínio de cada locatário pode exigir uma configuração adicional, o que acrescenta uma sobrecarga operacional adicional à integração do locatário.

Você também pode reescrever cabeçalhos de host para que, independentemente do cabeçalho de Host da solicitação recebida, o seu servidor web veja um valor de cabeçalho consistente. Por exemplo, o Azure Front Door permite que você reescreva Host cabeçalhos para que, independentemente da solicitação, o servidor de aplicativos receba um único Host cabeçalho. O Azure Front Door propaga o cabeçalho do host original no cabeçalho X-Forwarded-Host para que seu aplicativo possa inspecioná-lo e, em seguida, pesquisar o inquilino. No entanto, reescrever um cabeçalho Host pode causar outros problemas. Para saber mais, confira Preservação do nome do host.

Validação do domínio

Você deve validar a propriedade de domínios personalizados antes de integrá-los. Caso contrário, um cliente pode acidentalmente ou de maneira mal-intencionada reivindicar um nome de domínio, que às vezes é chamado de estacionamento de um nome de domínio.

Considere o processo de integração da Contoso para a Adventure Works, que solicitou o uso de invoices.adventureworks.com como nome de domínio personalizado. Infelizmente, alguém cometeu um erro de digitação ao tentar integrar o nome de domínio personalizado e perdeu o s. Então, eles o configuraram como invoices.adventurework.com. Como resultado, o tráfego não flui corretamente para a Adventure Works. Mas quando outra empresa chamada Adventure Work tenta adicionar seu domínio personalizado à plataforma da Contoso, eles são informados de que o nome de domínio já está em uso.

Para evitar esse problema, especialmente em um processo automatizado ou de autoatendimento, você pode exigir uma etapa de verificação de domínio. Você pode exigir que o cliente crie um registro CNAME antes que o domínio possa ser adicionado. Como alternativa, você pode gerar uma cadeia de caracteres aleatória e pedir ao cliente para adicionar um registro TXT DNS que inclua o valor da cadeia de caracteres. O nome de domínio não pode ser adicionado até que a verificação seja bem-sucedida.

DNS pendente e ataques de tomada de controle de subdomínio

Quando você trabalha com nomes de domínio personalizados, expõe sua plataforma a uma classe de ataques chamada DNS pendente ou tomada de controle de subdomínio. Esses ataques ocorrem quando os clientes desassociam o nome de domínio personalizado do serviço, mas não excluem o registro do servidor DNS. Essa entrada DNS aponta para um recurso inexistente e é vulnerável a uma aquisição.

Considere como a relação da Fabrikam com a Contoso poderá mudar se o seguinte cenário ocorrer:

  1. Fabrikam decide não trabalhar mais com a Contoso, então eles terminam seu relacionamento comercial.

  2. A Contoso desativa o locatário da Fabrikam e desabilita fabrikam.contoso.com.

  3. Fabrikam esquece de excluir o registro CNAME para invoices.fabrikam.com.

  4. Um ator mal-intencionado cria uma nova conta da Contoso e lhe dá o nome fabrikam.

  5. O invasor integra o nome de domínio personalizado invoices.fabrikam.com ao novo locatário.

  6. A Contoso verifica o servidor DNS da Fabrikam durante a validação de domínio baseada em CNAME. Eles veem que o servidor DNS retorna um registro CNAME para invoices.fabrikam.com, que aponta para fabrikam.contoso.com. A Contoso considera a validação de domínio personalizada bem-sucedida.

  7. Se os funcionários da Fabrikam tentarem acessar o site, as solicitações parecerão funcionar. Se o invasor configurar seu locatário da Contoso com a marca da Fabrikam, os funcionários poderão ser enganados ao acessar o site e fornecer dados confidenciais, que o invasor poderá acessar.

Use as seguintes estratégias para proteger contra ataques DNS pendentes:

  • Exija que o registro CNAME seja excluído antes que o nome de domínio possa ser removido da conta do locatário.

  • Proibir a reutilização de identificadores de locatário. E exija que cada locatário crie um registro TXT com um nome que corresponda ao nome do domínio e um valor gerado aleatoriamente que muda a cada tentativa de integração.

Certificados TLS

O TLS é um componente essencial de aplicativos modernos. Ele fornece confiança e segurança para seus aplicativos Web. Considere cuidadosamente a propriedade e o gerenciamento de certificados TLS para aplicativos multilocatários.

Normalmente, o proprietário de um nome de domínio emite e renova seus certificados. Por exemplo, a Contoso emite e renova certificados TLS para us.contoso.com e um certificado curinga para *.contoso.com. Da mesma forma, a Fabrikam gerencia registros para o fabrikam.com domínio, incluindo invoices.fabrikam.com.

Um proprietário de domínio pode usar o tipo de registro DNS de Autorização da Autoridade de Certificação (CAA). Os registros CAA garantem que apenas autoridades específicas possam criar certificados para o domínio.

Se você permitir que os clientes tragam seus próprios domínios, considere se você planeja emitir certificados em seu nome ou exigir que eles tragam seus próprios. Cada opção tem vantagens e desvantagens:

  • Se você emitir um certificado para um cliente, poderá lidar com a renovação do certificado para que o cliente não precise mantê-lo. No entanto, se os clientes tiverem registros de CAA em seus nomes de domínio, talvez eles precisem autorizar que você emita certificados em nome deles.

  • Se os clientes emitirem e fornecerem seus próprios certificados, você receberá e gerenciará com segurança as chaves privadas. Para evitar uma interrupção no serviço, talvez seja necessário lembrar os clientes de renovar o certificado antes que ele expire.

Vários serviços do Azure dão suporte ao gerenciamento automático de certificados para domínios personalizados. Por exemplo, o Azure Front Door e o Serviço de Aplicativo fornecem certificados para domínios personalizados e tratam automaticamente do processo de renovação. Esse recurso remove a carga de gerenciamento de certificados da sua equipe de operações. No entanto, você ainda precisa considerar a propriedade e a autoridade. Confirme se os Registros CAA estão em vigor e configurados corretamente. Verifique também se os domínios dos clientes permitem os certificados que a plataforma gerencia.

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

Outros colaboradores:

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

Próximas etapas

Muitos serviços usam o Azure Front Door para gerenciar nomes de domínio. Para obter mais informações, consulte Usar o Azure Front Door em uma solução multilocatário.

Retorne à visão geral das considerações de arquitetura. Ou examine o Azure Well-Architected Framework.