Impedir aquisições de subdomínio no Serviço de Aplicativo do Azure

As tomadas de controle de subdomínio são uma ameaça comum para as organizações que criam e excluem muitos recursos regularmente. Uma tomada de controle do subdomínio pode ocorrer quando um registro DNS indicar um recurso desprovisionado do Azure. Esses registros DNS também são conhecidos como entradas “DNS pendentes”. As aquisições de subdomínio permitem que atores mal-intencionados redirecionem o tráfego destinado ao domínio de uma organização para um site que executa atividades mal-intencionadas.

Os riscos da tomada de controle de subdomínio incluem:

Perda de controle sobre o conteúdo do subdomínio
Coleta de cookies de visitantes desavisados
Campanhas de phishing
Riscos adicionais de ataques clássicos, como XSS, CSRF ou evasão de CORS

Para saber mais sobre a aquisição de subdomínio, consulte Impedir entradas DNS pendentes e evitar a aquisição de subdomínio.

Serviço de Aplicativo do Azure fornece reserva de nomes, tokens de verificação de domínio e nomes de host padrão exclusivos e seguros para evitar o sequestro de subdomínios.

Proteger nomes de host padrão exclusivos (recomendado)

A maneira mais eficaz de proteger os recursos do Serviço de Aplicativo contra a aquisição do subdomínio é usar nomes de host padrão exclusivos seguros. Esse recurso geralmente está disponível para Aplicativos Web, Aplicativos de Funções e Aplicativos Lógicos (Standard).

Quando você habilita nomes de host padrão exclusivos seguros, seu aplicativo recebe um nome de host padrão que inclui um hash aleatório e um identificador de região, tornando-o exclusivo para sua organização. Esse formato garante que ninguém fora da sua organização possa criar um recurso com o mesmo nome de host padrão, o que elimina o risco de aquisição de subdomínio por meio de entradas DNS pendentes.

Como funciona

Os recursos tradicionais do Serviço de Aplicativo usam um formato de nome de host padrão que é globalmente previsível:

	Global (original)	Exclusivo (novo)
Nome do host padrão	`<AppName>.azurewebsites.net`	`<AppName>-<Hash>.<Region>.azurewebsites.net`
Ponto de extremidade do SCM	`<AppName>.scm.azurewebsites.net`	`<AppName>-<Hash>.scm.<Region>.azurewebsites.net`

Por exemplo, um aplicativo Web chamado contoso implantado no Leste dos EUA pode receber:

contoso-a6gqaeashthkhkeu.eastus-01.azurewebsites.net

O hash de 16 caracteres é determinístico dentro de um escopo configurável, para que você possa garantir nomes de host consistentes entre ambientes quando necessário.

Opções de escopo do hash

Ao criar um recurso com um nome de host padrão exclusivo, você escolhe um escopo que determina como o hash é gerado:

Scope	Description
Reutilização de locatário	O mesmo hash para o mesmo nome do aplicativo em todas as assinaturas no seu locatário do Microsoft Entra. Use isto ao reimplantar recursos entre assinaturas no mesmo locatário.
Reutilização de assinatura	Mesmo hash para o mesmo nome de aplicativo na mesma assinatura.
Reutilização do Grupo de Recursos	Mesmo hash para o mesmo nome de aplicativo no mesmo grupo de recursos.
Sem reutilização	Hash único a cada vez. Isolamento máximo.

Tip

Se você reimplanta regularmente recursos em diferentes ambientes (por exemplo, de uma assinatura de teste para uma assinatura de produção no mesmo tenant), use Tenant Reuse para garantir que seus nomes de host permaneçam consistentes em diferentes assinaturas.

Slots de implantação

Os slots de implantação seguem o mesmo formato do site de produção, mas cada slot recebe seu próprio hash distinto:

	Nome do host padrão	Nome de host do slot
Formato	`<AppName>-<Hash>.<Region>.azurewebsites.net`	`<AppName>-<SlotName>-<Hash>.<Region>.azurewebsites.net`

Os slots são sempre criados com o mesmo escopo do site de produção.

Como habilitar

Você pode habilitar nomes de host padrão exclusivos seguros ao criar um novo recurso por meio do portal Azure, CLI do Azure, modelos do ARM ou API REST. O recurso só pode ser habilitado durante a criação de recursos. Ele não pode ser aplicado a recursos existentes retroativamente.

Use o --domain-name-scope parâmetro ao criar um novo recurso para habilitar nomes de host padrão exclusivos seguros.

Tipo de recurso	Command	Reference
aplicativos Web	`az webapp create --name <AppName> --resource-group <ResourceGroup> --plan <AppServicePlan> --domain-name-scope TenantReuse`	az webapp create - comando para criar um aplicativo web.
Aplicativos de funções	`az functionapp create --name <AppName> --resource-group <ResourceGroup> --storage-account <StorageAccount> --consumption-plan-location <Region> --domain-name-scope TenantReuse`	az functionapp create
Aplicativos Lógicos (Standard)	`az logicapp create --name <AppName> --resource-group <ResourceGroup> --storage-account <StorageAccount> --domain-name-scope TenantReuse`	az logicapp create

O --domain-name-scope parâmetro aceita os seguintes valores: NoReuse, , ResourceGroupReuse, SubscriptionReuse, TenantReuse.

Adicione a propriedade AutoGeneratedDomainNameLabelScope às propriedades do site no seu modelo ARM ou na sua solicitação à API:

{
    "location": "Central US",
    "kind": "app",
    "properties": {
        "serverFarmId": "<AppServicePlanResourceId>",
        "AutoGeneratedDomainNameLabelScope": "TenantReuse"
    }
}

A AutoGeneratedDomainNameLabelScope propriedade aceita os seguintes valores: TenantReuse, , SubscriptionReuse, ResourceGroupReuse, NoReuse.

Migrando recursos existentes

Como esse recurso só pode ser habilitado no momento da criação, você tem duas opções para recursos existentes:

Clone um aplicativo preexistente para um novo aplicativo com nomes de host padrão exclusivos e seguros habilitados.
Restaurar a partir de um backup para um novo app com nomes de host padrão seguros e exclusivos habilitados.

Ambas as opções estão disponíveis no portal Azure.

Por que adotar isso agora

Os nomes de host padrão exclusivos seguros fornecem proteção por padrão. Ao contrário de outras estratégias de mitigação que exigem higiene DNS contínua e intervenção manual, essa abordagem cria segurança diretamente na estrutura do nome do host. Quando ativado:

Nenhum ator externo pode recriar seu nome de host padrão.
As entradas DNS pendentes não podem ser exploradas para a aquisição de subdomínio.
Nenhuma etapa de configuração adicional é necessária além de habilitar o recurso no momento da criação.

É altamente recomendável habilitar nomes de host padrão exclusivos seguros para todas as novas implantações do Serviço de Aplicativo.

Note

O identificador de região no nome do host (por exemplo, eastus-01) pode usar sufixos de número diferentes para implantações futuras. Não crie dependências fortes na combinação exata de região e número.

Como o Serviço de Aplicativo impede tomadas de controle do subdomínio

Após a exclusão de um aplicativo do App Service ou do Ambiente do Serviço de Aplicativo (ASE), o DNS correspondente é proibido de ser reutilizado, exceto por assinaturas pertencentes ao inquilino da assinatura que originalmente possuía o DNS. Assim, o cliente tem algum tempo para limpar as associações ou ponteiros para o DNS dito ou recuperar o DNS no Azure recriando o recurso com o mesmo nome. Esse comportamento é habilitado por padrão no Serviço de Aplicativo do Azure para *.azurewebsites.net recursos *.appserviceenvironment.net e, portanto, não requer nenhuma configuração do cliente.

Cenário de exemplo

A assinatura A e a assinatura B são as únicas assinaturas que pertencem ao locatário AB. A assinatura A contém um aplicativo web do App Service teste com o nome DNS test.azurewebsites.net. Após a exclusão do aplicativo, somente as assinaturas A ou B poderão reutilizar imediatamente o nome test.azurewebsites.net DNS criando um aplicativo Web chamado teste. Nenhuma outra assinatura tem permissão para reivindicar o nome logo após a exclusão do recurso.

Como é possível impedir tomadas de controle do subdomínio

Ao criar entradas DNS para o Serviço de Aplicativo do Azure, crie um registro TXT asuid.{subdomínio} com a ID de verificação de domínio. Quando esse registro TXT existe, nenhuma outra assinatura do Azure pode validar o domínio personalizado ou assumi-lo, a menos que eles adicionem sua ID de verificação de token às entradas DNS.

Esses registros impedem a criação de outro aplicativo do Serviço de Aplicativo usando o mesmo nome da sua entrada CNAME. Sem conseguir provar a propriedade do nome de domínio, os atores de ameaças não podem receber o tráfego nem controlar o conteúdo.

Os registros DNS devem ser atualizados antes da exclusão do site, para garantir que os atores mal-intencionados não possam assumir o domínio entre o período de exclusão e a recriação.

Para obter uma ID de verificação de domínio, consulte Configurar um domínio personalizado existente no Serviço de Aplicativo do Azure.

Comentários

Esta página foi útil?

Last updated on 2026-06-03