Considerações ao utilizar nomes de domínio numa solução multi-inquilino

Em muitas aplicações Web multi-inquilino, um nome de domínio pode ser utilizado como uma forma de identificar um inquilino, para ajudar no encaminhamento de pedidos para a infraestrutura correta e para fornecer uma experiência de marca aos seus clientes. Duas abordagens comuns consistem em utilizar subdomínios e nomes de domínio personalizados. Nesta página, fornecemos orientações para os decisores técnicos sobre as abordagens que pode considerar e as suas desvantagens.

Subdomínios

Cada inquilino pode obter um subdomínio exclusivo com um nome de domínio partilhado comum, utilizando um formato como tenant.provider.com.

Vamos considerar um exemplo de solução multi-inquilino criada pela Contoso. Os clientes compram o produto da Contoso para ajudar a gerir a geração de faturas. Todos os inquilinos da Contoso podem ter o seu próprio subdomínio, sob o contoso.com nome de domínio. Em alternativa, se a Contoso utilizar implementações regionais, poderá 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 o seu próprio subdomínio no seu domínio stem. Por exemplo, a Tailwind Toys pode ser atribuída tailwind.contoso.come a Adventure Works pode ser atribuída adventureworks.contoso.com.

Gerir o espaço de nomes de domínio

Quando cria subdomínios com o seu próprio nome de domínio, tem de ter em atenção que pode ter vários clientes com nomes semelhantes. Uma vez que partilham um único domínio stem, o primeiro cliente a obter um determinado domínio obterá o nome preferido. Em seguida, os clientes subsequentes têm de utilizar nomes de subdomínio alternativos, porque os nomes de domínio completos têm de ser globalmente exclusivos.

DNS de caráter universal

Considere utilizar entradas DNS universais para simplificar a gestão de subdomínios. Em vez de criar entradas DNS para tailwind.contoso.com, adventureworks.contoso.come assim sucessivamente, pode criar uma entrada de caráter universal para *.contoso.com e direcionar todos os subdomínios para um único endereço IP (registo A) ou nome canónico (registo CNAME).

Subdomínios com domínios estaminais de várias partes

Muitas soluções multi-inquilino estão distribuídas por várias implementações físicas. Esta é uma abordagem comum quando precisa de cumprir os requisitos de residência dos dados ou quando pretende proporcionar um melhor desempenho ao implementar recursos geograficamente mais próximos dos utilizadores.

Mesmo numa única região, também poderá ter de distribuir os inquilinos por implementações independentes, para suportar a sua estratégia de dimensionamento. Se planear utilizar subdomínios para cada inquilino, poderá considerar uma estrutura de subdomínio multipart.

Eis um exemplo: a Contoso publica uma aplicação multi-inquilino para os seus quatro clientes. A Adventure Works e a Tailwind Traders estão no Estados Unidos e os respetivos dados são armazenados numa instância partilhada dos EUA da plataforma Contoso. A Fabrikam e os Importadores Mundiais estão na Europa e os respetivos dados são armazenados numa instância europeia.

Se a Contoso optar por utilizar um único domínio stem, contoso.com, para todos os seus clientes, eis o seguinte aspeto:

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

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

Em alternativa, a Contoso poderia utilizar domínios estaminais específicos de implementação ou região, da seguinte forma:

Em seguida, com o DNS de caráter universal, as entradas DNS para esta implementação poderão ter o seguinte aspeto:

A Contoso não precisa de criar registos de subdomínios para cada cliente. Em vez disso, têm um único registo DNS de caráter universal para a implementação de cada geografia e todos os novos clientes que são adicionados por baixo desse caule herdam automaticamente o registo CNAME.

Existem vantagens e desvantagens para cada abordagem. Ao utilizar um único domínio stem, cada inquilino que integrar requer a criação de um novo registo DNS, o que introduz uma sobrecarga mais operacional. No entanto, tem mais flexibilidade para mover inquilinos entre implementações, uma vez que pode alterar o registo CNAME para direcionar o tráfego para outra implementação. Esta alteração não afetará outros inquilinos. Ao utilizar vários domínios estaminais, existe uma sobrecarga de gestão inferior. Além disso, pode reutilizar os nomes dos clientes em vários domínios estaminais regionais, uma vez que cada domínio stem representa efetivamente o seu próprio espaço de nomes.

Nomes de domínio personalizados

Poderá querer permitir que os seus clientes tragam os seus próprios nomes de domínio. Alguns clientes vêem isto como um aspeto importante da sua imagem corporativa. Os nomes de domínio personalizados também podem ser necessários para cumprir os requisitos de segurança dos clientes, especialmente se precisarem de fornecer os seus próprios certificados TLS. Embora possa parecer trivial permitir que os clientes tragam os seus próprios nomes de domínio, existem algumas complexidades ocultas nesta abordagem e requer consideração ponderada.

Resolução de nomes

Em última análise, cada nome de domínio tem de ser resolvido para um endereço IP. Como já viu, a abordagem através da qual ocorre a resolução de nomes pode depender da implementação de uma única instância ou de várias instâncias da sua solução.

Vamos voltar ao nosso exemplo. Um dos clientes da Contoso, Fabrikam, pediu para utilizar invoices.fabrikam.como , como nome de domínio personalizado para aceder ao serviço da Contoso. Uma vez que a Contoso tem várias implementações da respetiva plataforma, decide utilizar subdomínios e registos CNAME para alcançar os requisitos de encaminhamento. A Contoso e a Fabrikam configuram os seguintes registos DNS:

Do ponto de vista da resolução de nomes, esta cadeia de registos resolve com precisão os pedidos para invoices.fabrikam.com o endereço IP da implementação europeia da Contoso.

Resolução do cabeçalho do anfitrião

A resolução de nomes é apenas metade do problema. Todos os componentes Web na implementação europeia da Contoso têm de estar cientes de como lidar com pedidos recebidos com o nome de domínio da Fabrikam no cabeçalho Host do pedido. Dependendo das tecnologias Web específicas que a Contoso utiliza, isto pode exigir uma configuração adicional para o nome de domínio de cada inquilino, o que adiciona uma sobrecarga operacional adicional à integração de inquilinos.

Também pode considerar reescrever cabeçalhos de anfitrião, para que, independentemente do cabeçalho do Host pedido recebido, o servidor Web veja um valor de cabeçalho consistente. Por exemplo, o Azure Front Door permite-lhe reescrever Host cabeçalhos, para que, independentemente do pedido, o servidor da aplicação receba um único Host cabeçalho. O Azure Front Door propaga o cabeçalho do anfitrião original no cabeçalho, para que a X-Forwarded-Host 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, veja Preservação do nome do anfitrião.

Validação de domínio

É importante validar a propriedade dos domínios personalizados antes de os integrar. Caso contrário, arrisca-se a que um cliente estacione acidentalmente ou maliciosamente um nome de domínio.

Vamos considerar o processo de integração da Contoso para a Adventure Works, que pediu para utilizar invoices.adventureworks.com como nome de domínio personalizado. Infelizmente, alguém fez um erro de digitação quando tentou integrar o nome de domínio personalizado e perdeu o s. Por isso, configuraram-no como invoices.adventurework.com. Não só o tráfego não flui corretamente para a Adventure Works, como quando outra empresa chamada Adventure Work tenta adicionar o seu domínio personalizado à plataforma da Contoso, é-lhes dito que o nome de domínio já está a ser utilizado.

Ao trabalhar com domínios personalizados, especialmente num processo personalizado ou automatizado, é comum exigir um passo de verificação de domínio. Isto pode exigir que os registos CNAME sejam configurados antes de o domínio poder ser adicionado. Em alternativa, a Contoso pode gerar uma cadeia aleatória e pedir à Adventure Works para adicionar um registo TXT DNS com o valor da cadeia. Isto impediria que o nome de domínio fosse adicionado, até que a verificação fosse concluída.

Ataques de aquisição de DNS e subdomínio pendentes

Quando trabalha com nomes de domínio personalizados, está potencialmente vulnerável a uma classe de ataque denominada DNS pendente ou obtenção de subdomínio. Este ataque ocorre quando os clientes desassociam o nome de domínio personalizado do seu serviço, mas não eliminam o registo do respetivo servidor DNS. Esta entrada DNS aponta então para um recurso inexistente e é vulnerável a uma aquisição.

Vamos considerar como a relação da Fabrikam com a Contoso pode mudar:

1. A Fabrikam decidiu deixar de trabalhar com a Contoso e, por isso, terminaram a relação comercial.
2. A Contoso offboarded the Fabrikam tenant, and they requested for to fabrikam.contoso.com no longer work. No entanto, a Fabrikam esqueceu-se de eliminar o registo CNAME para invoices.fabrikam.com.
3. Um ator malicioso cria uma nova conta contoso e dá-lhe o nome fabrikam.
4. O atacante integra o nome invoices.fabrikam.com de domínio personalizado no respetivo novo inquilino. Uma vez que a Contoso executa a validação de domínio baseada em CNAME, verificam o servidor DNS da Fabrikam. Veem que o servidor DNS devolve um registo CNAME para invoices.fabrikam.com, que aponta para fabrikam.contoso.com. A Contoso considera que a validação do domínio personalizado foi bem-sucedida.
5. Se algum funcionário da Fabrikam tentasse aceder ao site, os pedidos parecem funcionar. Se o atacante configurar o inquilino da Contoso com a imagem corporativa da Fabrikam, os funcionários poderão ser enganados a aceder ao site e a fornecer dados confidenciais, aos quais o atacante pode aceder.

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

• Exigir que o registo CNAME seja eliminado antes de o nome de domínio poder ser removido da conta do inquilino.
• Proíba a reutilização de identificadores de inquilinos e exija também que o inquilino crie um registo TXT com um nome que corresponda ao nome de domínio e a um valor gerado aleatoriamente, que é alterado para cada tentativa de inclusão.

Certificados TLS/SSL

O Transport Layer Security (TLS) é um componente essencial ao trabalhar com aplicações modernas. Fornece confiança e segurança às suas aplicações Web. A propriedade e gestão dos certificados TLS é algo que precisa de ter em consideração cuidadosamente as aplicações multi-inquilino.

Normalmente, o proprietário de um nome de domínio será responsável pela emissão e renovação dos respetivos certificados. Por exemplo, a Contoso é responsável por emitir e renovar certificados TLS para us.contoso.com, bem como um certificado universal para *.contoso.com. Da mesma forma, a Fabrikam seria geralmente responsável pela gestão de quaisquer registos do fabrikam.com domínio, incluindo invoices.fabrikam.com. O tipo de registo DNS CAA (Autorização da Autoridade de Certificação) pode ser utilizado por um proprietário de domínio. Os registos CAA garantem que apenas as autoridades específicas podem criar certificados para o domínio.

Se planeia permitir que os clientes tragam os seus próprios domínios, considere se planeia emitir o certificado em nome do cliente ou se os clientes têm de trazer os seus próprios certificados. Cada opção tem benefícios e desvantagens.

• Se emitir um certificado para um cliente, pode processar a renovação do certificado, para que o cliente não tenha de se lembrar de o manter atualizado. No entanto, se os clientes tiverem registos CAA nos respetivos nomes de domínio, poderão ter de o autorizar a emitir certificados em nome deles.
• Se espera que os clientes emitam e lhe forneçam os seus próprios certificados, é responsável por receber e gerir as chaves privadas de forma segura e poderá ter de lembrar os seus clientes para renovarem o certificado antes de expirarem, para evitar uma interrupção no respetivo serviço.

Vários serviços do Azure suportam a gestão automática de certificados para domínios personalizados. Por exemplo, o Azure Front Door e Serviço de Aplicações fornecem certificados para domínios personalizados e processam automaticamente o processo de renovação. Isto elimina o fardo da gestão de certificados da sua equipa de operações. No entanto, ainda tem de considerar a questão da propriedade e da autoridade, como se os registos CAA estão em vigor e configurados corretamente. Além disso, tem de garantir que os domínios dos seus clientes estão configurados para permitir os certificados geridos pela plataforma.

Contribuidores

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

Autor principal:

• John Downs | Engenheiro Principal de Clientes, FastTrack para o Azure

Outros contribuidores:

• Daniel Scott-Raynsford | Estratega de Tecnologia de Parceiro
• Arsen Vladimirskiy | Engenheiro Principal de Clientes, FastTrack para o Azure

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

Passos seguintes

Volte à descrição geral das considerações de arquitetura. Em alternativa, reveja o Microsoft Azure Well-Architected Framework.