Como controlar o tráfego de entrada para um ambiente do Serviço de Aplicativo

Artigo
12/06/2023

Importante

Este artigo é sobre o Ambiente do Serviço de Aplicativo v1. O Ambiente do Serviço de Aplicativo v1 será desativado em 31 de agosto de 2024. Há uma nova versão do Ambiente do Serviço de Aplicativo que é mais fácil de usar e é executada em uma infraestrutura mais poderosa. Para saber mais sobre a nova versão, comece com a Introdução ao Ambiente do Serviço de Aplicativo. Se você estiver usando o Ambiente do Serviço de Aplicativo v1, siga as etapas neste artigo para migrar para a nova versão.

A partir de 29 de janeiro de 2024, você não poderá mais criar novos recursos do Ambiente do Serviço de Aplicativo v1 usando qualquer um dos métodos disponíveis, incluindo modelos ARM/Bicep, Portal do Azure, CLI do Azure ou API REST. Você deve migrar para o Ambiente do Serviço de Aplicativo v3 antes de 31 de agosto de 2024 para evitar a exclusão de recursos e a perda de dados.

Descrição geral

Um Ambiente do Serviço de Aplicativo pode ser criado em uma rede virtual do Azure Resource Manager ou em uma rede virtual de modelo de implantação clássico. Uma nova rede virtual e uma nova sub-rede podem ser definidas no momento em que um Ambiente do Serviço de Aplicativo é criado. Em vez disso, um Ambiente do Serviço de Aplicativo pode ser criado em uma rede virtual pré-existente e em uma sub-rede pré-existente. A partir de junho de 2016, os ASEs também podem ser implantados em redes virtuais que usam intervalos de endereços públicos ou espaços de endereços RFC1918 (endereços privados). Para obter mais informações, consulte Como criar um ASEv1 a partir do modelo.

Sempre crie um Ambiente do Serviço de Aplicativo em uma sub-rede. Uma sub-rede fornece um limite de rede que pode ser usado para bloquear o tráfego de entrada atrás de dispositivos e serviços upstream. Esta configuração permite que apenas endereços IP upstream específicos aceitem tráfego HTTP e HTTPS.

O tráfego de rede de entrada e saída em uma sub-rede é controlado usando um grupo de segurança de rede. Para controlar o tráfego de entrada, crie regras de segurança de rede em um grupo de segurança de rede. Em seguida, atribua ao grupo de segurança de rede a sub-rede que contém o Ambiente do Serviço de Aplicativo.

Depois de atribuir um grupo de segurança de rede a uma sub-rede, o tráfego de entrada para aplicativos no Ambiente do Serviço de Aplicativo é permitido ou bloqueado com base nas regras de permissão e negação definidas no grupo de segurança de rede.

Nota

Embora este artigo se refira a aplicações Web, também se aplica a aplicações API e aplicações móveis.

Portas de Rede de Entrada utilizadas num Ambiente do Serviço de Aplicações

Antes de bloquear o tráfego de rede de entrada com um grupo de segurança de rede, conheça o conjunto de portas de rede necessárias e opcionais usadas por um Ambiente do Serviço de Aplicativo. Fechar acidentalmente o tráfego para algumas portas pode resultar em perda de funcionalidade em um Ambiente do Serviço de Aplicativo.

A lista a seguir contém as portas usadas por um Ambiente do Serviço de Aplicativo. Todas as portas são TCP, salvo indicação em contrário:

454: Porta necessária usada pela infraestrutura do Azure para gerenciar e manter Ambientes do Serviço de Aplicativo via TLS. Não bloqueie o tráfego para esta porta. Esta porta está sempre ligada ao VIP público de um ASE.
455: Porta necessária usada pela infraestrutura do Azure para gerenciar e manter Ambientes do Serviço de Aplicativo via TLS. Não bloqueie o tráfego para esta porta. Esta porta está sempre ligada ao VIP público de um ASE.
80: Porta padrão para tráfego HTTP de entrada para aplicativos executados em Planos do Serviço de Aplicativo em um Ambiente do Serviço de Aplicativo. Em um ASE habilitado para ILB, essa porta está vinculada ao endereço ILB do ASE.
443: Porta padrão para tráfego TLS de entrada para aplicativos executados em Planos do Serviço de Aplicativo em um Ambiente do Serviço de Aplicativo. Em um ASE habilitado para ILB, essa porta está vinculada ao endereço ILB do ASE.
21: Canal de controle para FTP. Esta porta pode ser bloqueada com segurança se o FTP não estiver a ser utilizado. Em um ASE habilitado para ILB, essa porta pode ser vinculada ao endereço ILB de um ASE.
990: Canal de controle para FTPS. Essa porta pode ser bloqueada com segurança se o FTPS não estiver sendo usado. Em um ASE habilitado para ILB, essa porta pode ser vinculada ao endereço ILB de um ASE.
10001-10020: Canais de dados para FTP. Tal como acontece com o canal de controlo, estas portas podem ser bloqueadas com segurança se o FTP não estiver a ser utilizado. Em um ASE habilitado para ILB, essa porta pode ser vinculada ao endereço ILB do ASE.
4016: Usado para depuração remota com o Visual Studio 2012. Essa porta pode ser bloqueada com segurança se o recurso não estiver sendo usado. Em um ASE habilitado para ILB, essa porta está vinculada ao endereço ILB do ASE.
4018: Usado para depuração remota com o Visual Studio 2013. Essa porta pode ser bloqueada com segurança se o recurso não estiver sendo usado. Em um ASE habilitado para ILB, essa porta está vinculada ao endereço ILB do ASE.
4020: Usado para depuração remota com o Visual Studio 2015. Essa porta pode ser bloqueada com segurança se o recurso não estiver sendo usado. Em um ASE habilitado para ILB, essa porta está vinculada ao endereço ILB do ASE.
4022: Usado para depuração remota com o Visual Studio 2017. Essa porta pode ser bloqueada com segurança se o recurso não estiver sendo usado. Em um ASE habilitado para ILB, essa porta está vinculada ao endereço ILB do ASE.
4024 Usado para depuração remota com o Visual Studio 2019. Essa porta pode ser bloqueada com segurança se o recurso não estiver sendo usado. Em um ASE habilitado para ILB, essa porta está vinculada ao endereço ILB do ASE.
4026: Usado para depuração remota com o Visual Studio 2022. Essa porta pode ser bloqueada com segurança se o recurso não estiver sendo usado. Em um ASE habilitado para ILB, essa porta está vinculada ao endereço ILB do ASE.

Conectividade de Saída e Requisitos de DNS

Para que um Ambiente do Serviço de Aplicativo funcione corretamente, ele também requer acesso de saída a vários pontos de extremidade. Uma lista completa dos pontos de extremidade externos usados por um ASE está na seção "Conectividade de rede necessária" do artigo Configuração de rede para Rota Expressa .

Os Ambientes do Serviço de Aplicativo exigem uma infraestrutura DNS válida configurada para a rede virtual. Se a configuração de DNS for alterada após a criação de um Ambiente do Serviço de Aplicativo, os desenvolvedores poderão forçar um Ambiente do Serviço de Aplicativo a escolher a nova configuração de DNS. Se você acionar uma reinicialização de ambiente contínuo usando o ícone Reiniciar, o ambiente selecionará a nova configuração de DNS. (O O ícone Reiniciar está localizado na parte superior da folha de gerenciamento do Ambiente do Serviço de Aplicativo, no portal do Azure.)

Também é recomendável que todos os servidores DNS personalizados na rede virtual sejam configurados com antecedência antes de criar um Ambiente do Serviço de Aplicativo. Se a configuração DNS de uma rede virtual for alterada durante a criação de um Ambiente do Serviço de Aplicativo, o processo de criação do Ambiente do Serviço de Aplicativo falhará. Da mesma forma, se houver um servidor DNS personalizado inacessível ou indisponível na outra extremidade de um gateway VPN, o processo de criação do Ambiente do Serviço de Aplicativo também falhará.

Criar um Grupo de Segurança de Rede

Para obter detalhes completos sobre como os grupos de segurança de rede funcionam, consulte as seguintes informações. O exemplo de Gerenciamento de Serviços do Azure abaixo aborda os destaques dos grupos de segurança de rede. O exemplo configura e aplica um grupo de segurança de rede a uma sub-rede que contém um Ambiente do Serviço de Aplicativo.

Observação: os grupos de segurança de rede podem ser configurados graficamente usando o portal do Azure ou por meio do Azure PowerShell.

Os grupos de segurança de rede são criados primeiro como uma entidade autônoma associada a uma assinatura. Como os grupos de segurança de rede são criados em uma região do Azure, crie o grupo de segurança de rede na mesma região que o Ambiente do Serviço de Aplicativo.

O comando a seguir demonstra a criação de um grupo de segurança de rede:

New-AzureNetworkSecurityGroup -Name "testNSGexample" -Location "South Central US" -Label "Example network security group for an app service environment"

Depois que um grupo de segurança de rede é criado, uma ou mais regras de segurança de rede são adicionadas a ele. Como o conjunto de regras pode mudar ao longo do tempo, você deve espaçar o esquema de numeração usado para prioridades de regras. Esta prática facilita a inserção de regras adicionais ao longo do tempo.

No exemplo abaixo, uma regra concede explicitamente acesso às portas de gerenciamento necessárias à infraestrutura do Azure para gerenciar e manter um Ambiente do Serviço de Aplicativo. Todo o tráfego de gerenciamento flui através de TLS e é protegido por certificados de cliente. Mesmo que as portas sejam abertas, elas são inacessíveis por qualquer entidade que não seja a infraestrutura de gerenciamento do Azure.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "ALLOW AzureMngmt" -Type Inbound -Priority 100 -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '454-455' -Protocol TCP

Ao bloquear o acesso às portas 80 e 443 para "ocultar" um Ambiente do Serviço de Aplicativo atrás de dispositivos ou serviços upstream, lembre-se do endereço IP upstream. Por exemplo, se você estiver usando um firewall de aplicativo Web (WAF), o WAF terá seu próprio endereço IP ou endereços. O WAF os usa ao fazer proxy de tráfego para um Ambiente de Serviço de Aplicativo downstream. Você precisará usar esse endereço IP no parâmetro SourceAddressPrefix de uma regra de segurança de rede.

No exemplo abaixo, o tráfego de entrada de um endereço IP upstream específico é explicitamente permitido. O endereço 1.2.3.4 é usado como um espaço reservado para o endereço IP de um WAF upstream. Altere o valor para corresponder ao endereço usado pelo seu dispositivo ou serviço upstream.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT HTTP" -Type Inbound -Priority 200 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT HTTPS" -Type Inbound -Priority 300 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

Se o suporte FTP for desejado, use as seguintes regras como um modelo para conceder acesso à porta de controle FTP e às portas do canal de dados. Como o FTP é um protocolo com monitoração de estado, talvez você não consiga rotear o tráfego FTP através de um firewall HTTP/HTTPS tradicional ou dispositivo proxy. Nesse caso, você precisará definir SourceAddressPrefix para um valor diferente, como o intervalo de endereços IP de máquinas de desenvolvedor ou implantação nas quais os clientes FTP estão sendo executados.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT FTPCtrl" -Type Inbound -Priority 400 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '21' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT FTPDataRange" -Type Inbound -Priority 500 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '10001-10020' -Protocol TCP

(Nota: o intervalo de portas do canal de dados pode mudar durante o período de visualização.)

Se a depuração remota com o Visual Studio for usada, as regras a seguir demonstram como conceder acesso. Há uma regra separada para cada versão com suporte do Visual Studio, já que cada versão usa uma porta diferente para depuração remota. Tal como acontece com o acesso FTP, o tráfego de depuração remota pode não fluir corretamente através de um dispositivo WAF ou proxy tradicional. Em vez disso, SourceAddressPrefix pode ser definido como o intervalo de endereços IP de máquinas de desenvolvedor que executam o Visual Studio.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2012" -Type Inbound -Priority 600 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4016' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2013" -Type Inbound -Priority 700 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4018' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2015" -Type Inbound -Priority 800 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4020' -Protocol TCP

Atribuindo um grupo de segurança de rede a uma sub-rede

Um grupo de segurança de rede tem uma regra de segurança padrão que nega acesso a todo o tráfego externo. Quando você combina essa regra com as regras de segurança de rede acima, somente o tráfego dos intervalos de endereços de origem associados a uma ação Permitir poderá enviar tráfego para aplicativos executados em um Ambiente do Serviço de Aplicativo.

Depois que um grupo de segurança de rede for preenchido com regras de segurança, atribua-o à sub-rede que contém o Ambiente do Serviço de Aplicativo. O comando de atribuição faz referência a dois nomes: o nome da rede virtual onde está o Ambiente do Serviço de Aplicativo e o nome da sub-rede onde o Ambiente do Serviço de Aplicativo foi criado.

O exemplo abaixo mostra um grupo de segurança de rede sendo atribuído a uma sub-rede e rede virtual:

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-test'

A tarefa é uma operação de longa duração e pode levar alguns minutos para ser concluída. Quando a atribuição do grupo de segurança de rede for bem-sucedida, somente o tráfego de entrada que corresponder às regras de Permissão alcançará com êxito os aplicativos no Ambiente do Serviço de Aplicativo.

Para completar, o exemplo a seguir mostra como remover e desassociar o grupo de segurança de rede da sub-rede:

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Remove-AzureNetworkSecurityGroupFromSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-test'

Considerações especiais para IP-SSL explícito

Se um aplicativo estiver configurado com um endereço IP-SSL explícito (aplicável apenas a ASEs que têm um VIP público), em vez de usar o endereço IP padrão do Ambiente do Serviço de Aplicativo, o tráfego HTTP e HTTPS flui para a sub-rede por portas diferentes das portas 80 e 443.

Para encontrar o par individual de portas usado por cada endereço IP-SSL, vá para o portal e visualize a folha UX de detalhes do Ambiente do Serviço de Aplicativo. Selecione Todos os endereços IP de configurações>. A folha Endereços IP mostra uma tabela de todos os endereços IP-SSL explicitamente configurados para o Ambiente do Serviço de Aplicativo. A folha também mostra o par de portas especial usado para rotear o tráfego HTTP e HTTPS associado a cada endereço IP-SSL. Use este par de portas para os parâmetros DestinationPortRange ao configurar regras em um grupo de segurança de rede.

Quando um aplicativo em um ASE é configurado para usar IP-SSL, os clientes externos não verão ou precisarão se preocupar com o mapeamento de par de portas especial. O tráfego para os aplicativos fluirá normalmente para o endereço IP-SSL configurado. A conversão para o par de portas especial acontece automaticamente internamente, durante a etapa final do tráfego de roteamento para a sub-rede que contém o ASE.

Introdução

Para começar a usar os Ambientes do Serviço de Aplicativo, consulte Introdução ao Ambiente do Serviço de Aplicativo.

Para obter mais informações, consulte Conectando-se com segurança a recursos de back-end de um ambiente do Serviço de Aplicativo.