Considerações ao usar nomes de domínio em uma solução multilocatário

Em muitos aplicativos da Web multilocatário, um nome de domínio pode ser usado como uma forma de identificar um locatário, a fim de ajudar no roteamento de solicitações para a infraestrutura correta e fornecer uma experiência de marca a seus clientes. Duas abordagens comuns são usar subdomínios e nomes de domínio personalizados. Nesta página, fornecemos orientação para tomadores de decisão técnicos sobre as abordagens que você pode considerar e suas compensações.

Subdomínios

Cada locatário pode obter um subdomínio exclusivo em um nome de domínio compartilhado comum, usando um formato como tenant.provider.com.

Vamos considerar 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. Todos os locatários da Contoso podem receber seu próprio subdomínio, sob o nome de domínio contoso.com. Alternativamente, se a Contoso usar implantações regionais, poderá atribuir subdomínios nos domínios us.contoso.com e eu.contoso.com. Neste artigo, nos referimos a eles como domínios-tronco. Cada cliente obtém seu próprio subdomínio em seu domínio de tronco. Por exemplo, Tailwind Toys pode ser atribuído a tailwind.contoso.com e, em um modelo de implantação regional, Adventure Works pode ser atribuído a adventureworks.us.contoso.com.

Gerenciar seu namespace de domínio

Ao criar subdomínios com seu próprio nome de domínio, você precisa estar ciente de que pode ter vários clientes com nomes semelhantes. Como eles compartilham um único domínio-tronco, o primeiro cliente a obter um domínio específico receberá seu nome preferencial. Em seguida, os clientes subsequentes terão que usar nomes de subdomínio alternativos, pois os nomes de domínio completos devem ser globalmente exclusivos.

DNS curinga

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

Subdomínios com domínios-tronco de várias partes

Muitas soluções multilocatários estão espalhadas por várias implantações físicas. Essa é uma abordagem comum quando você precisa cumprir os requisitos de residência de dados ou quando deseja fornecer melhor desempenho implantando recursos geograficamente mais próximos dos usuários.

Mesmo dentro de uma única região, você também pode precisar distribuir seus locatários em implantações independentes, para dar suporte a 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.

Veja aqui um exemplo: a Contoso publicou 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.

Se a Contoso optar por usar um único domínio de raiz, como contoso.com, para todos os seus clientes, veja qual será sua aparência:

As entradas DNS (necessárias para dar suporte a essa configuração) podem ter esta aparência:

Cada novo cliente integrado requer um novo subdomínio e o número de subdomínios cresce com cada cliente.

Como alternativa, a Contoso pode usar domínios de haste específicos de implantação ou região, como este:

Em seguida, usando DNS curinga, as entradas de DNS para essa implantação podem ter a seguinte aparência:

A Contoso não precisa criar registros de subdomínio para cada cliente. Em vez disso, eles têm um único registro DNS curinga para a implantação de cada geografia, e todos os novos clientes que forem adicionados a essa raiz herdarão automaticamente o registro CNAME.

Existem vantagens e desvantagens em cada abordagem. Ao usar um único domínio-tronco, cada locatário integrado exigirá a criação de um novo registro DNS, o que imporá mais sobrecarga operacional. No entanto, você tem mais flexibilidade para mover locatários entre implantações, pois pode alterar o registro CNAME para direcionar seu tráfego para outra implantação. Essa alteração não afetará nenhum outro locatário. Ao usar vários domínios-tronco, há uma menor sobrecarga de gerenciamento. Além disso, você pode reutilizar nomes de clientes em vários domínios-tronco regionais, porque cada domínio-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 isso como um aspecto importante de sua marca. Nomes de domínio personalizados também podem ser necessários para atender aos requisitos de segurança dos clientes, especialmente se eles precisarem fornecer os próprios certificados TLS. Embora possa parecer trivial permitir que os clientes tragam seus próprios nomes de domínio, existem algumas complexidades ocultas nessa abordagem e isso requer uma consideração cuidadosa.

Resolução de nomes

Em última análise, cada nome de domínio precisa ser resolvido para um endereço IP. Como você viu, a abordagem pela qual a resolução de nomes acontece pode depender da implantação de uma única instância ou de várias instâncias de sua solução.

Voltemos ao nosso exemplo. Um dos clientes da Contoso, a Fabrikam, pediu para usar invoices.fabrikam.com como o nome de domínio personalizado para acessar o serviço da Contoso. Como a Contoso tem várias implantações de sua plataforma multilocatário, eles decidem usar subdomínios e registros CNAME para atender aos requisitos de roteamento. A Contoso e a Fabrikam configuram os seguintes registros DNS:

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 metade do problema. Todos os componentes da Web na implantação europeia da Contoso precisam estar cientes de como lidar com solicitações que chegam com o nome de domínio da Fabrikam em seu cabeçalho de solicitação Host. Dependendo das tecnologias da Web específicas que a Contoso usar, isso poderá exigir configuração adicional para o nome de domínio de cada locatário, o que adiciona uma sobrecarga operacional extra à integração de locatários.

Você também pode considerar reescrever cabeçalhos de host, para que, independentemente do cabeçalho de Host da solicitação recebida, seu servidor da Web veja um valor de cabeçalho consistente. Por exemplo, o Azure Front Door permite reescrever cabeçalhos de Host para que, independentemente da solicitação, o servidor de aplicativos receba um único cabeçalho de Host. O Azure Front Door propaga o cabeçalho do host original no cabeçalho de X-Forwarded-Host, para que seu aplicativo possa inspecioná-lo para pesquisar o locatário. 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

É importante validar a propriedade de domínios personalizados antes de integrá-los. Caso contrário, você corre o risco de um cliente estacionar um nome de domínio de maneira acidental ou mal-intencionada.

Vamos considerar o processo de integração da Contoso para a Adventure Works, que pediu para usar 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. Portanto, a configuração ficou como invoices.adventurework.com. Não só o tráfego não fluirá corretamente para a Adventure Works, mas quando outra empresa chamada Adventure Work tentar adicionar seu domínio personalizado à plataforma da Contoso, ela será informada de que o nome de domínio já está em uso.

Ao trabalhar com domínios personalizados, especialmente em um processo de autoatendimento ou automatizado, é comum exigir uma etapa de verificação de domínio. Isso pode exigir que os registros CNAME sejam configurados antes que o domínio possa ser adicionado. Como alternativa, a Contoso pode gerar uma cadeia de caracteres aleatória e pedir à Adventure Works para adicionar um registro DNS TXT com o valor da cadeia de caracteres. Isso impediria que o nome de domínio fosse adicionado até que a verificação fosse concluída.

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

Ao trabalhar com nomes de domínio personalizados, você fica potencialmente vulnerável a uma classe de ataque chamada DNS pendente ou tomada de controle de subdomínio. Esse ataque ocorre 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 um controle.

Vamos considerar como o relacionamento da Fabrikam com a Contoso pode mudar:

1. A Fabrikam decidiu não trabalhar mais com a Contoso e, portanto, encerrou o relacionamento comercial.
2. A Contoso removeu o locatário da Fabrikam e eles pediram para interromper o funcionamento do fabrikam.contoso.com. No entanto, a Fabrikam esqueceu de excluir o registro CNAME de invoices.fabrikam.com.
3. Um ator mal-intencionado cria uma nova conta da Contoso e lhe dá o nome fabrikam.
4. O invasor integra o nome de domínio personalizado invoices.fabrikam.com ao novo locatário. Como a Contoso realiza a validação de domínio baseada em CNAME, ela confirma o servidor DNS da Fabrikam. Eles veem que o servidor DNS retorna um registro CNAME para invoices.fabrikam.com, que aponta para fabrikam.contoso.com. A Contoso considera que a validação de domínio personalizado foi bem-sucedida.
5. Se algum funcionário da Fabrikam tentasse acessar o site, as solicitações pareciam 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.

As estratégias comuns para se proteger contra ataques de DNS pendentes são:

• Exigir 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 também exigir que o locatário crie um registro TXT com um nome correspondente ao nome de domínio e um valor gerado aleatoriamente, que é alterado para cada tentativa de integração.

Certificados TLS/SSL

O protocolo TLS (Transport Layer Security) é um componente essencial ao trabalhar com aplicativos modernos. Ele fornece confiança e segurança para seus aplicativos Web. A propriedade e o gerenciamento de certificados TLS é algo que precisa de consideração cuidadosa para aplicativos multilocatários.

Normalmente, o proprietário de um nome de domínio é responsável por emitir e renovar seus certificados. Por exemplo, a Contoso é responsável por emitir e renovar certificados TLS para us.contoso.com, bem como um certificado curinga para *.contoso.com. Da mesma forma, a Fabrikam geralmente seria responsável por gerenciar todos os registros para o domínio fabrikam.com, incluindo invoices.fabrikam.com.

O tipo de registro DNS CAA (autorização de autoridade de certificação) pode ser usado por um proprietário de domínio. Os registros CAA garantem que apenas autoridades específicas possam criar certificados para o domínio.

Para permitir que os clientes tragam seus próprios domínios, considere se planeja emitir o certificado em nome do cliente ou se os clientes devem trazer seus próprios certificados. Cada opção tem vantagens e desvantagens:

• Se emitir um certificado para um cliente, você poderá lidar com a renovação do certificado para que o cliente não precise se lembrar de mantê-lo atualizado. 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 você espera que os clientes emitam e forneçam seus próprios certificados, você é responsável por receber e gerenciar as chaves privadas de maneira segura e talvez precise lembrar seus clientes de renovar o certificado antes que ele expire, para evitar uma interrupção no seu serviço.

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. Isso remove a carga de gerenciamento de certificados da sua equipe de operações. No entanto, você ainda precisa considerar a questão de propriedade e autoridade, como se os registros CAA estão em vigor e configurados corretamente. Adicionalmente, você precisa garantir que os domínios de seus clientes estejam configurados para permitir os certificados gerenciados pela plataforma.

Colaboradores

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

Autor principal:

• John Downs | Engenheiro de software principal

Outros colaboradores:

• Daniel Scott-Raynsford | Estrategista de Tecnologia Do Parceiro
• Arsen Vladimirskiy | Engenheiro de Cliente Principal, FastTrack for Azure

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

Próximas etapas

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