Conectar-se com segurança a recursos de back-end em um Ambiente do Serviço de Aplicativo

Importante

Este artigo é sobre o Ambiente do Serviço de Aplicativo v1. O Ambiente do Serviço de Aplicativo v1 e v2 foi 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.

A partir de 31 de agosto de 2024, o Contrato de Nível de Serviço (SLA) e os Créditos de Serviço não se aplicarão mais às cargas de trabalho do Ambiente do Serviço de Aplicativo v1 e v2 que continuarem em produção, pois são produtos desativados. A desativação do hardware do Ambiente do Serviço de Aplicativo v1 e v2 foi iniciada, o que poderá afetar a disponibilidade e o desempenho de seus aplicativos e dados.

Você deve concluir a migração para o Ambiente do Serviço de Aplicativo v3 imediatamente ou seus aplicativos e recursos poderão ser excluídos. Tentaremos migrar automaticamente qualquer Ambiente do Serviço de Aplicativo v1 e v2 restantes com base no melhor esforço usando o recurso de migração in-loco. No enanto, a Microsoft não afirma ou garante a disponibilidade do aplicativo após a migração automática. Talvez seja necessário realizar a configuração manual para concluir a migração e otimizar a escolha de SKU do Plano do Serviço de Aplicativo para atender às suas necessidades. Se a migração automática não for viável, seus recursos e dados de aplicativo associados serão excluídos. Recomendamos fortemente que você tome uma atitude agora para evitar esses cenários extremos.

Se você precisar de mais tempo, podemos oferecer um período de carência único de 30 dias para concluir sua migração. Para mais informações e para solicitar este período de carência, consulte a visão geral sobre o período de carência e, em seguida, acesse o portal do Azure e visite a folha Migração para cada um dos seus Ambientes do Serviço de Aplicativo.

Para obter as informações mais atualizadas sobre a desativação do Ambiente do Serviço de Aplicativo v1/v2, consulte a Atualização de desativação do Ambiente do Serviço de Aplicativo v1 e v2.

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

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 acesso de outros recursos na mesma rede virtual.

Como outro exemplo, pontos de extremidade confidenciais podem ser executados localmente e conectados ao Azure via conexões Site a Site ou do Azure ExpressRoute. Como resultado, apenas os recursos nas redes virtuais conectadas a túneis Site a Site ou do ExpressRoute podem acessar os pontos de extremidade locais.

Para todos esses cenários, os aplicativos em execução em um Ambiente do Serviço de Aplicativo podem se conectar com segurança aos diversos servidores e recursos. Se o tráfego de saída de aplicativos é executado em um Ambiente do Serviço de Aplicativo para pontos de extremidade privados na mesma rede virtual ou está conectado à mesma rede virtual, ele passará apenas pela rede virtual. O tráfego de saída para pontos de extremidade privados não vai passar 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 em uma rede virtual. Os Ambientes do Serviço de Aplicativo não podem acessar os pontos de extremidade de máquinas virtuais que estão localizados na mesma sub-rede que o Ambiente do Serviço de Aplicativo. Essa limitação normalmente não é um problema, se os Ambientes do Serviço de Aplicativo estiverem implantados em uma sub-rede reservada para uso exclusivo do Ambiente do Serviço de Aplicativo.

Observação

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

Requisitos de DNS e conectividade de saída

Para um Ambiente de Serviço de Aplicativo funcionar 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. Na parte superior da folha gerenciamento do Ambiente do Serviço de Aplicativo no portal, selecione o ícone Reiniciar para disparar uma reinicialização do ambiente sem interrupção, o que vai fazer com que o ambiente capture a nova configuração de DNS.

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. A alteração da configuração do DNS de uma rede virtual durante a criação de um Ambiente do Serviço de Aplicativo vai resultar em uma falha do processo de criação do Ambiente do Serviço de Aplicativo. O processo de criação do Ambiente do Serviço de Aplicativo também vai falhar se houver um servidor DNS inacessível ou indisponível na outra extremidade de um gateway de VPN.

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 para esse ponto de extremidade:

• Listas de controle de acesso a redes (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 de rede. O exemplo abaixo adiciona os endereços de cliente que se originam de dentro de uma rede virtual às permissões de atribuição e bloqueia o acesso aos outros clientes.

Todos os aplicativos em execução no Ambiente do Serviço de Aplicativo na mesma rede virtual que o 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 a seguir 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 usando o endereço IP público vão ser rejeitadas devido à ACL de 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. Grupos de segurança de rede podem ser aplicados a máquinas virtuais individuais ou a uma sub-rede que contenha as máquinas virtuais.

Primeiro, você precisa 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 VNet é simples com um grupo de segurança de rede. As regras padrão em um grupo de segurança de rede somente permitem o acesso a partir de outros clientes de rede na mesma rede virtual.

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

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

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

O resultado é um conjunto de regras de segurança que bloqueiam o acesso externo e permitem o acesso interno da VNet:

Introdução

Para se familiarizar com os ambientes de 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, confira Como controlar o tráfego de entrada para 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.