Partilhar via

Considerações sobre nomes de domínio em soluções multilocatárias

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

  • Distinguir um inquilino de outro

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

  • Para proporcionar uma experiência de marca aos seus clientes

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

Subdomínios

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

Considere um exemplo de solução multilocatária criada pela Contoso. Os clientes compram o produto da Contoso para ajudar a gerenciar a geraçã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, podem atribuir subdomínios sob os domínios us.contoso.com e eu.contoso.com.

Este artigo refere-se a estes domínios regionais como domínios estaminais. Cada cliente obtém seu próprio subdomínio sob seu domínio stem. Por exemplo, 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

Quando cria subdomínios com o seu próprio nome de domínio, pode ter vários clientes com nomes semelhantes. Eles compartilham um único domínio tronco, de modo que o primeiro cliente a reivindicar um domínio específico recebe seu nome preferido. Os clientes subsequentes têm de utilizar nomes de subdomínio alternativos porque os nomes de domínio completos têm de permanecer globalmente exclusivos.

DNS curinga

Use entradas curinga do 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 para um nome canônico usando um registro CNAME. Se você usar domínios tronco regionais, talvez 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 suportam DNS curinga se você planeja usar esse recurso. Muitos serviços do Azure, incluindo o Azure Front Door e o Serviço de Aplicativo do Azure, oferecem suporte a entradas DNS curinga.

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

Muitas soluções multilocatárias 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 dentro de uma única região, você pode distribuir seus locatários por 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 uma aplicação multilocatária para 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. A Fabrikam e a Worldwide Importers estão na Europa e os seus dados são armazenados numa instância europeia.

O diagrama a seguir mostra um exemplo de Contoso usando o domínio de raiz única contoso.com para todos os seus clientes.

Diagrama que mostra implantações nos EUA e na Europa de um aplicativo Web, com um único domínio tronco para cada subdomínio do 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 pode usar domínios raiz específicos da implantação ou da região.

Diagrama que mostra implantações nos EUA e na UE de um aplicativo Web, com domínios de tronco múltiplo.

Usando DNS curinga (wildcard), as entradas DNS para esta implantação podem assemelhar-se às seguintes.

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 a implantação de cada região geográfica permite que novos clientes abaixo dessa haste herdem automaticamente o registro CNAME.

Cada abordagem tem vantagens e inconvenientes. Ao usar um domínio de tronco único, você deve criar um registro DNS para cada locatário integrado, o que aumenta a sobrecarga operacional. No entanto, você tem mais flexibilidade para mover locatários entre implantações. Você pode alterar o registro CNAME para direcionar seu tráfego para outra implantação. Esta alteração não afeta nenhum outro inquilino.

Os domínios de tronco múltiplo 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

Talvez você queira permitir que seus clientes tragam seus próprios nomes de domínio. Alguns clientes veem esse recurso como um aspeto importante de sua marca. Os clientes também podem precisar de nomes de domínio personalizados para atender aos requisitos de segurança, especialmente se precisarem fornecer seus próprios certificados TLS (Transport Layer Security). Esta abordagem pode parecer simples, mas algumas complexidades ocultas requerem uma consideração ponderada.

Resolução de nomes

Em última análise, cada nome de domínio deve ser associado a um endereço IP. Como mostrado anteriormente, o processo de resolução de nomes depende se você implanta uma única instância ou várias instâncias da sua solução.

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

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

Do ponto de vista da resolução de nomes, essa cadeia de registros resolve com precisão as solicitações para invoices.fabrikam.com o endereço IP da implantação europeia da Contoso.

Resolução do cabeçalho do host

A resolução de nomes é apenas parte do problema. Todos os componentes 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 web específicas que a Contoso utiliza, o nome de domínio de cada inquilino pode exigir configuração adicional, o que adiciona uma sobrecarga operacional extra à adesão do inquilino.

Você também pode reescrever os cabeçalhos de host Host para que, independentemente do cabeçalho da solicitação de entrada, o seu servidor web veja um valor de cabeçalho consistente. Por exemplo, o Azure Front Door permite reescrever Host cabeçalhos para que, independentemente da solicitação, seu 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 a sua aplicação possa inspecioná-lo e, em seguida, procurar o inquilino. No entanto, reescrever um Host cabeçalho pode causar outros problemas. Para obter mais informações, consulte Preservação do nome do host.

Validação de domínio

Você deve validar a propriedade de domínios personalizados antes de integrá-los. Caso contrário, um cliente pode reivindicar acidentalmente ou maliciosamente um nome de domínio, algo que às vezes é conhecido como parquear um domínio.

Considere o processo de integração da Contoso para a Adventure Works, que solicitou o uso de invoices.adventureworks.com como seu nome de domínio personalizado. Infelizmente, alguém cometeu um erro de digitação quando tentou integrar o nome de domínio personalizado, e eles perderam o s. Então eles 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 de autoatendimento ou automatizado, 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.

Dangling DNS e ataques de aquisição 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 aquisição de subdomínio. Esses ataques ocorrem quando os clientes desassociam o nome de domínio personalizado do seu 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 o relacionamento da Fabrikam com a Contoso pode mudar se ocorrer o seguinte cenário:

  1. A Fabrikam decide não trabalhar mais com a Contoso, portanto, encerra seu relacionamento comercial.

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

  3. A Fabrikam esquece de excluir o registro CNAME do 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 invoices.fabrikam.com de domínio personalizado 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 personalizado 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 induzidos a acessar o site e fornecer dados confidenciais, que o invasor poderá acessar.

Use as seguintes estratégias para se 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 inquilino. E exija que cada locatário crie um registro TXT com um nome que corresponda ao nome de domínio e um valor gerado aleatoriamente que muda para cada tentativa de integração.

Certificados TLS

TLS é um componente essencial de aplicações modernas. Proporciona confiança e segurança às suas aplicações Web. Considere cuidadosamente a propriedade e o gerenciamento de certificados TLS para aplicativos multilocatário.

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 registo DNS CAA (Certificate Authority Authorization). 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 planeja emitir certificados em seu nome ou exigir que eles tragam os seus. 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 CAA em seus nomes de domínio, talvez seja necessário autorizá-lo a emitir certificados em seu nome.

  • Se os clientes emitirem e fornecerem seus próprios certificados, você receberá e gerenciará as chaves privadas com segurança. 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 lidam automaticamente com o processo de renovação. Esse recurso elimina a carga de gerenciar certificados de sua equipe de operações. No entanto, você ainda precisa considerar a propriedade e a autoridade. Confirme se os registros CAA estão instalados e configurados corretamente. Certifique-se também de que os domínios dos seus clientes permitem os certificados que a plataforma gere.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

Outros contribuidores:

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximos passos

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.

Volte à visão geral das considerações arquitetônicas. Ou revise o Azure Well-Architected Framework.