Ligar de forma segura a recursos de back-end a partir de um ambiente do Serviço de Aplicações

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.

Como um Ambiente do Serviço de Aplicativo é sempre criado em uma rede virtual do Azure Resource Manager ou emuma rede virtual de modelo de implantação clássico, as conexões de saída de um Ambiente do Serviço de Aplicativo para outros recursos de back-end podem fluir exclusivamente pela rede virtual. 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).

Por exemplo, pode haver um SQL Server em execução em um cluster de máquinas virtuais com a porta 1433 bloqueada. O ponto de extremidade pode ser ACLd para permitir apenas o acesso de outros recursos na mesma rede virtual.

Como outro exemplo, pontos de extremidade confidenciais podem ser executados no local e ser conectados ao Azure por meio de conexões Site-to-Site ou Azure ExpressRoute . Como resultado, somente recursos em redes virtuais conectadas aos túneis Site-to-Site ou ExpressRoute podem acessar pontos de extremidade locais.

Para todos esses cenários, os aplicativos executados em um Ambiente do Serviço de Aplicativo podem se conectar com segurança aos vários servidores e recursos. Se o tráfego de saída de aplicativos for executado em um Ambiente do Serviço de Aplicativo para pontos de extremidade privados na mesma rede virtual ou conectados à mesma rede virtual, ele só fluirá pela rede virtual. O tráfego de saída para pontos de extremidade privados não fluirá pela Internet pública.

Um problema se aplica ao tráfego de saída de um Ambiente do Serviço de Aplicativo para pontos de extremidade dentro de uma rede virtual. Os Ambientes do Serviço de Aplicativo não podem alcançar pontos de extremidade de máquinas virtuais localizadas na mesma sub-rede que o Ambiente do Serviço de Aplicativo. Essa limitação normalmente não deve ser um problema, se os Ambientes do Serviço de Aplicativo forem implantados em uma sub-rede reservada para uso exclusivo pelo Ambiente do Serviço de Aplicativo.

Nota

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

Conectividade de Saída e Requisitos de DNS

Para que um Ambiente do 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 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. Na parte superior da folha de gerenciamento do Ambiente do Serviço de Aplicativo no portal, selecione o ícone Reiniciar para acionar uma reinicialização contínua do ambiente, o que faz com que o ambiente pegue a nova configuração de DNS.

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 de DNS de uma rede virtual for alterada durante a criação de um Ambiente do Serviço de Aplicativo, isso resultará na falha do processo de criação do Ambiente do Serviço de Aplicativo. Na outra extremidade de um gateway VPN, se houver um servidor DNS personalizado inacessível ou indisponível, o processo de criação do Ambiente do Serviço de Aplicativo também falhará.

Conectando-se a um SQL Server

Uma configuração comum do SQL Server tem um ponto de extremidade escutando na porta 1433:

Há duas abordagens para restringir o tráfego a esse ponto de extremidade:

• Listas de controle de acesso à rede (ACLs de rede)
• Grupos de Segurança de Rede

Restringindo o acesso com uma ACL de rede

A porta 1433 pode ser protegida usando uma lista de controle de acesso à rede. O exemplo abaixo adiciona às permissões de atribuição os endereços do cliente originados de uma rede virtual e bloqueia o acesso a todos os outros clientes.

Todos os aplicativos executados no Ambiente do Serviço de Aplicativo, na mesma rede virtual do SQL Server, podem se conectar à instância do SQL Server. Use o endereço IP interno da VNet para a máquina virtual do SQL Server.

A cadeia de conexão de exemplo abaixo faz referência ao SQL Server usando seu endereço IP privado.

Server=tcp:10.0.1.6;Database=MyDatabase;User ID=MyUser;Password=PasswordHere;provider=System.Data.SqlClient

Embora a máquina virtual também tenha um ponto de extremidade público, as tentativas de conexão para usar o endereço IP público serão rejeitadas devido à ACL da rede.

Restringindo o acesso com um grupo de segurança de rede

Uma abordagem alternativa para proteger o acesso é com um grupo de segurança de rede. Os grupos de segurança de rede podem ser aplicados a máquinas virtuais individuais ou a uma sub-rede que contenha máquinas virtuais.

Primeiro, você precisará 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"

Restringir o acesso apenas ao tráfego interno da rede virtual é simples com um grupo de segurança de rede. As regras padrão em um grupo de segurança de rede só permitem o acesso de outros clientes de rede na mesma rede virtual.

Como resultado, bloquear o acesso ao SQL Server é simples. Basta aplicar um grupo de segurança de rede com suas regras padrão às máquinas virtuais que executam o SQL Server ou à sub-rede que contém as máquinas virtuais.

O exemplo abaixo aplica um grupo de segurança de rede à sub-rede que contém:

Get-AzureNetworkSecurityGroup -Name "testNSGExample" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-1'

O resultado final é um conjunto de regras de segurança que bloqueiam o acesso externo, permitindo o acesso interno da rede virtual:

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 detalhes sobre como controlar o tráfego de entrada para seu Ambiente do Serviço de Aplicativo, consulte Controlando o tráfego de entrada para um Ambiente do Serviço de Aplicativo

Nota

Se pretender começar a utilizar o App Service do Azure antes de se inscrever numa conta do Azure, aceda a Experimentar o App Service, onde pode criar de imediato uma aplicação Web de arranque de curta duração no App Service. Sem cartões de crédito; sem compromissos.