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

Em muitos aplicativos Web multilocatário, um nome de domínio pode ser usado como uma maneira de identificar um locatário, ajudar com solicitações de roteamento para a infraestrutura correta e fornecer uma experiência de marca aos 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écnica sobre as abordagens que você pode considerar e suas compensações.

Subdomínios

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

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

Gerenciar seu namespace de domínio

Quando você cria subdomínios sob seu próprio nome de domínio, você precisa estar ciente de que você 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 preferido. Em seguida, os clientes subsequentes têm que usar nomes de subdomínio alternativos, porque os nomes de domínio completos devem ser globalmente exclusivos.

DNS curinga

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

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

Muitas soluções multilocatárias 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 um 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 por implantações independentes, para dar suporte à sua estratégia de dimensionamento. Se você planeja usar subdomínios para cada locatário, pode considerar uma estrutura de subdomínio com várias partes.

Aqui está um 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. A Fabrikam e a Worldwide Importers estão na Europa e os seus dados são armazenados numa instância europeia.

Se a Contoso optar por usar um domínio de tronco único, contoso.com, para todos os seus clientes, veja como isso pode parecer:

As entradas DNS (que são necessárias para suportar esta configuração) podem ter esta aparência:

Cada novo cliente que é 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 tronco específicos de implantação ou região, como este:

Em seguida, usando DNS curinga, as entradas DNS para esta implantação podem ter esta 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 são adicionados abaixo dessa haste herdam automaticamente o registro CNAME.

Há vantagens e inconvenientes em cada abordagem. Ao usar um único domínio de tronco, cada locatário integrado requer a criação de um novo registro DNS, o que introduz mais sobrecarga operacional. No entanto, você tem mais flexibilidade para mover locatários entre implantações, porque pode alterar o registro CNAME para direcionar seu tráfego para outra implantação. Esta alteração não afetará nenhum outro inquilino. Ao usar vários domínios de tronco, há uma sobrecarga de gerenciamento menor. Além disso, 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 isso como um aspeto 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 seus próprios certificados TLS. Embora possa parecer trivial permitir que os clientes tragam seus próprios nomes de domínio, há 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 se você implanta uma única instância ou várias instâncias da sua solução.

Voltemos ao nosso exemplo. Um dos clientes da Contoso, a Fabrikam, pediu para usar invoices.fabrikam.com como 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 seus requisitos de roteamento. A Contoso e a Fabrikam configuram os seguintes registros DNS:

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 metade do problema. Todos os componentes 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 Host cabeçalho de solicitação. Dependendo das tecnologias Web específicas que a Contoso usa, isso pode exigir configuração adicional para o nome de domínio de cada locatário, o que adiciona sobrecarga operacional extra à integração de locatários.

Você também pode considerar reescrever cabeçalhos Host de host, para que, independentemente do cabeçalho da solicitação de entrada, seu servidor Web veja um valor de cabeçalho consistente. Por exemplo, o Azure Front Door permite que você reescreva Host cabeçalhos, de modo 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, para X-Forwarded-Host que seu aplicativo possa inspecioná-lo e, em seguida, procurar o locatário. 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

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

Vamos considerar o processo de integração da Contoso para a Adventure Works, que pediu para usar 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 o configuraram como invoices.adventurework.com. Não só 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, ela é 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 TXT DNS com o valor da cadeia de caracteres. Isso impediria que o nome de domínio fosse adicionado, até que a verificação seja concluída.

Dangling DNS e ataques de aquisição de subdomínio

Quando você trabalha com nomes de domínio personalizados, fica potencialmente vulnerável a uma classe de ataque chamada DNS pendente ou aquisição de subdomínio. Esse ataque acontece quando os clientes desassociam o nome de domínio personalizado do seu serviço, mas não excluem o registro do servidor DNS. Esta entrada DNS aponta então para um recurso inexistente e é vulnerável a uma aquisição.

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

1. A Fabrikam decidiu não trabalhar mais com a Contoso e, por isso, encerrou seu relacionamento comercial.
2. A Contoso desintegrou o locatário da Fabrikam e eles solicitaram fabrikam.contoso.com que não funcionassem mais. No entanto, a Fabrikam esqueceu de excluir o registro CNAME para 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 invoices.fabrikam.com de domínio personalizado ao novo locatário. Como a Contoso executa a validação de domínio baseada em CNAME, ela verifica 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 pareceriam 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.

As estratégias comuns de proteção contra ataques DNS pendentes são:

• 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 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 muda a cada tentativa de integração.

Certificados TLS/SSL

Transport Layer Security (TLS) é um componente essencial ao trabalhar com aplicativos modernos. Proporciona confiança e segurança às suas aplicações Web. A propriedade e o gerenciamento de certificados TLS é algo que precisa ser cuidadosamente considerado para aplicativos multilocatário.

Normalmente, o proprietário de um nome de domínio é responsável pela emissão e renovação de 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 pelo gerenciamento de quaisquer registros para o fabrikam.com domínio, incluindo invoices.fabrikam.com.

O tipo de registro DNS CAA (Certificate Authority Authorization) 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.

Se você planeja 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 você emitir um certificado para um cliente, 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 CAA em seus nomes de domínio, talvez seja necessário autorizá-lo a emitir certificados em seu nome.
• 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 forma segura, e talvez seja necessário lembrar seus clientes de renovar o certificado antes que ele expire, para evitar uma interrupção no 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 lidam automaticamente com o processo de renovação. Isso elimina a carga de gerenciar certificados da sua equipe de operações. No entanto, você ainda precisa considerar a questão da propriedade e da autoridade, como se os registros CAA estão em vigor e configurados corretamente. Além disso, você precisa garantir que os domínios de seus clientes estejam configurados para permitir os certificados gerenciados pela plataforma.

Contribuidores

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

Autor principal:

• John Downs - Brasil | Engenheiro de Software Principal

Outros contribuidores:

• Daniel Scott-Raynsford - Brasil | Estrategista de Tecnologia de Parceiros
• 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

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