Como controlar o tráfego de entrada para um ambiente de serviço de aplicativo

  • Artigo

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 de Serviço de Aplicativo que é mais fácil de usar e é executado na infraestrutura mais avançada. Para saber mais sobre a nova versão, comece com 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.

Desde 29 de janeiro de 2024, você não pode mais criar recursos do Ambiente do Serviço de Aplicativo v1 usando um dos métodos disponíveis, incluindo os modelos do ARM/Bicep, o portal do Azure, a CLI do Azure ou a API REST. Você precisará 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.

Visão geral

Um Ambiente de Serviço de Aplicativo pode ser criado tanto em uma rede virtual do Azure Resource Manager, quanto 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 de Serviço de Aplicativo é criado. Em vez disso, um Ambiente do Serviço de Aplicativo pode ser criado em uma rede virtual e uma sub-rede existentes. Desde junho de 2016, os ASEs podem ser implantados nas redes virtuais que usam intervalos de endereço públicos ou espaços de endereço RFC1918 (endereços privados). Para obter mais informações, confira Criar um ASEv1 usando um modelo.

Sempre crie um Ambiente do Serviço de Aplicativo dentro de uma sub-rede. Uma sub-rede fornece um limite de rede que pode ser usado para bloquear o tráfego de entrada por trás de dispositivos e serviços de upstream. Essa configuração permite que apenas endereços IP de upstream específicos aceitem o 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 o grupo de segurança de rede à sub-rede que contém o Ambiente do Serviço de Aplicativo.

Quando você atribui um grupo de segurança de rede a uma sub-rede, o tráfego de entrada para aplicativos no ambiente de serviço de aplicativo é permitido ou bloqueado com base em regras de permissão e bloqueio que são definidas no grupo de segurança de rede.

Observação

Embora este artigo esteja relacionado a aplicativos Web, ele também serve para aplicativos de API e aplicativos móveis.

Portas de entrada de rede usadas em um Ambiente de Serviço de Aplicativo

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 requeridas e opcionais usadas por um ambiente de serviço de aplicativo. Fechar acidentalmente o tráfego para algumas portas pode resultar em perda de funcionalidade em um ambiente de serviço de aplicativo.

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

  • 454: Porta necessária usada pela infraestrutura do Azure para gerenciamento e manutenção de Ambientes do Serviço de Aplicativo via TLS. Não bloqueie o tráfego para essa porta. Essa porta é sempre associada ao VIP público de um ASE.
  • 455: Porta necessária usada pela infraestrutura do Azure para gerenciamento e manutenção de Ambientes do Serviço de Aplicativo via TLS. Não bloqueie o tráfego para essa porta. Essa porta é sempre associada ao VIP público de um ASE.
  • 80: porta padrão para tráfego HTTP de entrada para aplicativos executados em Planos de Serviço de Aplicativo em um Ambiente de Serviço de Aplicativo. Em um ASE habilitado para ILB, essa porta é associada ao endereço ILB do ASE.
  • 443: porta padrão para tráfego TLS de entrada para aplicativos executados em Planos de Serviço de Aplicativo em um Ambiente do Serviço de Aplicativo. Em um ASE habilitado para ILB, essa porta é associada ao endereço ILB do ASE.
  • 21: canal de controle para FTP. Essa porta pode ser bloqueada com segurança se o FTP não está sendo usado. Em um ASE habilitado para ILB, essa porta pode ser associada 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 está sendo usado. Em um ASE habilitado para ILB, essa porta pode ser associada ao endereço ILB de um ASE.
  • 10001-10020: canais de dados para FTP. Assim como acontece com o canal de controle, essas portas podem ser bloqueadas com segurança se o FTP não estiver sendo usado. Em um ASE habilitado para ILB, essa porta pode ser associada 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 está sendo usado. Em um ASE habilitado para ILB, essa porta é associada 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 está sendo usado. Em um ASE habilitado para ILB, essa porta é associada 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 está sendo usado. Em um ASE habilitado para ILB, essa porta é associada ao endereço ILB do ASE.
  • 4022: usada para depuração remota com o Visual Studio 2017. Essa porta pode ser bloqueada com segurança se o recurso não está sendo usado. Em um ASE habilitado para ILB, essa porta é associada ao endereço ILB do ASE.
  • 4024: usada para depuração remota com o Visual Studio 2019. Essa porta pode ser bloqueada com segurança se o recurso não está sendo usado. Em um ASE habilitado para ILB, essa porta é associada ao endereço ILB do ASE.
  • 4026: usada para depuração remota com o Visual Studio 2022. Essa porta pode ser bloqueada com segurança se o recurso não está sendo usado. Em um ASE habilitado para ILB, essa porta é associada ao endereço ILB do ASE.

Requisitos de DNS e conectividade de saída

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

Ambientes de Serviço de Aplicativo exigem uma infraestrutura DNS válida configurada para a rede virtual. Se a configuração do DNS for alterada após a criação do Ambiente do Serviço de Aplicativo, os desenvolvedores podem forçar um Ambiente do Serviço de Aplicativo a captar a nova configuração de DNS. Se você disparar uma reinicialização do ambiente sem interrupção usando o ícone de Reinicialização, o ambiente selecionará a nova configuração de DNS. (O ícone de Reinicialização está localizado na parte superior da folha gerenciamento de Ambiente do Serviço de Aplicativo, na Portal do Azure.)

Também é recomendável que todos os servidores DNS personalizados na VNet sejam configurados antes da criação de um Ambiente do Serviço de Aplicativo. Se uma configuração do 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 maneira, se houver um servidor DNS personalizado inacessível ou indisponível na outra extremidade de um gateway de VPN, o processo de criação do Ambiente do Serviço de Aplicativo também vai falhará.

Criando um grupo de segurança de rede

Para saber mais sobre como funcionam os grupos de segurança de rede, veja 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.

Grupos de segurança de rede são criados pela primeira vez 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 de serviço de aplicativo.

O comando a seguir demonstra como criar 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 de um grupo de segurança de rede ter sido criado, uma ou mais regras de segurança de rede são adicionadas a ele. Como o conjunto de regras pode mudar com o tempo, você deve espaçar o esquema de numeração usado nas prioridades das regras. Essa prática facilita a inserção de regras adicionais ao longo do tempo.

No exemplo abaixo, uma regra concede explicitamente o acesso às portas de gerenciamento requeridas pela infraestrutura do Azure para gerenciar e manter um ambiente de serviço de aplicativo. Todo o tráfego de gerenciamento flui por TLS e é protegido por certificados de cliente. Embora 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 de serviço de aplicativo por trás de serviços ou dispositivos upstream, lembre-se do endereço IP upstream. Por exemplo, se você estiver usando um WAF (firewall do aplicativo Web), o WAF terá seu próprio endereço ou endereços IP. O WAF os usa ao fazer o proxy do tráfego para um Ambiente do 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 determinado endereço IP upstream é 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 coincidir com o endereço usado pelo serviço ou dispositivo 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 desejar suporte a FTP, use as regras a seguir como um modelo para conceder acesso à porta de controle de FTP e às portas de canal de dados. Como o FTP é um protocolo com monitoramento de estado, você pode ser incapaz de rotear o tráfego FTP por meio de um dispositivo de proxy ou firewall HTTP/HTTPS tradicional. Nesse caso, será necessário definir o SourceAddressPrefix para um valor diferente, como o intervalo de endereços IP de computadores de desenvolvedor ou de implantação, nos quais clientes FTP estão em execução.

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

(Observação: 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 é usada, as regras a seguir demonstram como conceder acesso. Há uma regra separada para cada versão do Visual Studio para a qual há suporte, já que cada versão usa uma porta diferente para a depuração remota. Assim como acontece com acesso ao FTP, o tráfego de depuração remota pode não fluir corretamente por meio de um dispositivo de proxy ou WAF tradicional. O SourceAddressPrefix pode ser definido, em vez disso, como o intervalo de endereços IP dos computadores de desenvolvedor executando 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

Atribuir 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 o 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 é preenchido com regras de segurança, atribua-o à sub-rede que contém o ambiente de serviço de aplicativo. O comando de atribuição referencia dois nomes: o nome da rede virtual onde o ambiente do serviço de aplicativo está, e o nome da sub-rede onde o ambiente do serviço de aplicativo foi criado.

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

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

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

Para fins de exatidão, o exemplo a seguir mostra como remover e dissociar 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 for configurado com um endereço IP-SSL explícito (aplicável somente 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 fluirá para a sub-rede por outras portas além das portas 80 e 443.

Para encontrar o par individual de portas que é usado por cada endereço IP-SSL, acesse o portal e veja a folha de UX de detalhes do Ambiente do Serviço de Aplicativo. Selecione Todas as configurações>Endereços IP. A folha Endereços IP mostra uma tabela de todos os endereços IP-SSL configurados explicitamente no Ambiente do Serviço de Aplicativo. A folha também mostra o par de portas especial que é usado para rotear o tráfego HTTP e HTTPS associado a cada endereço IP-SSL. Use esse 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 ocorrerá internamente de forma automática durante o segmento final do roteamento do tráfego para a sub-rede que contém o ASE.

Introdução

Para começar a usar Ambientes de Serviço de Aplicativo, veja Introdução ao ambiente do Serviço de Aplicativo.

Para mais informações, consulte Conexão segura a recursos de back-end a partir de um Ambiente do Serviço de Aplicativo.

Observação

Se você deseja começar com o Serviço de Aplicativo do Azure antes de se inscrever em uma conta do Azure, acesse Experimentar o Serviço de Aplicativo, em que você pode criar imediatamente um aplicativo Web inicial de curta duração no Serviço de Aplicativo. Nenhum cartão de crédito é exigido, sem compromissos.