Recursos de rede do Serviço de Aplicativo do Azure

Você pode implantar aplicativos no Serviço de Aplicativo do Azure de várias maneiras. Por padrão, os aplicativos hospedados no Serviço de Aplicativo podem ser acessados diretamente pela Internet e permitem acessar apenas pontos de extremidade hospedados online. Para muitos aplicativos, você precisa controlar o tráfego de rede de entrada e saída. Há vários recursos no Serviço de Aplicativo para ajudá-lo a atender a essas necessidades. O desafio é saber qual recurso usar para resolver um determinado problema. Use este artigo para ajudá-lo a determinar qual recurso usar, com base em casos de uso de exemplo.

Existem dois tipos de implantação principais para o Serviço de Aplicativo do Azure:

• O serviço público multilocatário hospeda planos do Serviço de Aplicativo nas SKUs Gratuitas, Compartilhadas, Básicas, Standard, Premium, PremiumV2 e PremiumV3.
• O ASE (Ambiente do Serviço de Aplicativo) de locatário único hospeda planos do Serviço do Aplicativo Isolado da SKU diretamente na rede virtual do Azure.

Os recursos que você usa dependem se você está no serviço multilocatário ou em um ASE.

Observação

Os recursos de rede não estão disponíveis para aplicativos implantados no Azure Arc.

Recursos de rede do Serviço de Aplicativo multilocatário

O Serviço de Aplicativo do Azure é um sistema distribuído. As funções que tratam solicitações HTTP ou HTTPS de entrada são chamadas de front-ends. As funções que hospedam a carga de trabalho do cliente são chamadas de Trabalhos. Todas as funções em uma implantação do Serviço de Aplicativo são encontradas em uma rede multilocatário. Como há muitos clientes diferentes na mesma unidade de escala do Serviço de Aplicativo, não é possível conectar a rede do Serviço de Aplicativo diretamente à sua rede.

Em vez de conectar as redes, use recursos para lidar com os vários aspectos da comunicação do aplicativo. Os recursos que lidam com solicitações para seu aplicativo não podem ser usados para resolver problemas quando você faz chamadas do seu aplicativo. Da mesma forma, os recursos que resolvem problemas de chamadas pelo aplicativo não podem ser usados para resolver problemas do aplicativo.

Recursos de entrada	Recursos de saída
Endereço atribuído ao aplicativo	Conexões Híbridas
Restrições de acesso	Integração de rede virtual exigida por gateway
Pontos de extremidade de serviço	Integração de rede virtual
Pontos de extremidade privados

Além das exceções indicadas, você pode usar todos esses recursos juntos. Você pode combinar os recursos para resolver problemas.

Casos de uso e recursos

Para qualquer caso de uso, pode haver algumas maneiras de resolver o problema. A escolha do melhor recurso pode ir além do próprio caso de uso. Os seguintes casos de uso de entrada sugerem como usar os recursos de rede do Serviço de Aplicativo para resolver problemas de controle do tráfego que entra no aplicativo:

Caso de uso de entrada	Recurso
Suporte às necessidades de SSL baseado em IP para o aplicativo	Endereço atribuído ao aplicativo
Suporte ao endereço de entrada dedicado e não compartilhado para o aplicativo	Endereço atribuído ao aplicativo
Restringir o acesso ao aplicativo de um conjunto de endereços bem definidos	Restrições de acesso
Restringir o acesso ao aplicativo de recursos em uma rede virtual	Pontos de extremidade de serviço ASE do ILB (Balanceador de Carga Interno) Pontos de extremidade privados
Mostrar o aplicativo em um IP privado na rede virtual	ASE do ILB Pontos de extremidade privados IP privado para o tráfego de entrada em uma instância do Gateway de Aplicativo com pontos de extremidade de serviço
Proteger o aplicativo com um WAF (Firewall do Aplicativo Web)	Gateway de Aplicativo e ASE do ILB Gateway de Aplicativo com pontos de extremidade privados Gateway de Aplicativo com pontos de extremidade de serviço Azure Front Door com restrições de acesso
Balancear a carga do tráfego para os aplicativos em regiões diferentes	Azure Front Door com restrições de acesso
Balancear a carga do tráfego na mesma região	Gateway de Aplicativo com pontos de extremidade de serviço

Os seguintes casos de uso de saída sugerem como usar os recursos de rede do Serviço de Aplicativo para resolver as necessidades de acesso de saída para o aplicativo:

Caso de uso de saída	Recurso
Acessar recursos em uma rede virtual do Azure na mesma região	Integração de rede virtual ASE
Acessar recursos em uma rede virtual do Azure em uma região diferente	Integração de rede virtual e emparelhamento de rede virtual Integração de rede virtual exigida pelo gateway ASE e emparelhamento de rede virtual
Acessar recursos protegidos com pontos de extremidade de serviço	Integração de rede virtual ASE
Acessar recursos em uma rede privada que não está conectada ao Azure	Conexões Híbridas
Acessar recursos nos circuitos do Azure ExpressRoute	Integração de rede virtual ASE
Proteger o tráfego de saída do aplicativo Web	Integração de rede virtual e grupos de segurança de rede ASE
Encaminhar tráfego de saída do aplicativo Web	Integração de rede virtual e tabelas de rotas ASE

Comportamento de rede padrão

As unidades de escala do Serviço de Aplicativo do Azure suportam muitos clientes em cada implantação. Os planos de SKU Gratuita e Compartilhada hospedam cargas de trabalho do cliente em trabalhos multilocatários. Os planos Básico e superiores hospedam cargas de trabalho do cliente que são dedicadas a apenas um plano do Serviço de Aplicativo. Se você tiver um plano Standard do Serviço de Aplicativo, todos os aplicativos nesse plano serão executados no mesmo trabalho. Se você escalar horizontalmente o trabalho, todos os aplicativos nesse plano do Serviço de Aplicativo serão replicados em um novo trabalho para cada instância existente.

Endereços de saída

As máquinas virtuais de trabalho são divididas em grande parte pelos planos do Serviço de Aplicativo. Os planos Gratuito, Compartilhado, Básico, Standard e Premium usam o mesmo tipo de máquina virtual de trabalho. O plano PremiumV2 usa outro tipo de máquina virtual. O PremiumV3 usa mais um tipo de máquina virtual.

Quando você altera a família de máquinas virtuais, obtém um conjunto diferente de endereços de saída. Se você dimensionar de Standard para PremiumV2, os endereços de saída mudarão. Se você dimensionar de PremiumV2 para PremiumV3, seus endereços de saída mudarão. Em algumas unidades de escala mais antigas, os endereços de entrada e de saída são alterados quando você escala de Standard para PremiumV2.

Há muitos endereços que são usados para chamadas de saída. Os endereços de saída usados pelo aplicativo para fazer chamadas de saída são listados nas propriedades do aplicativo. Todos os aplicativos executados na mesma família de máquinas virtuais de trabalho na implantação do Serviço de Aplicativo compartilham esses endereços. Se você quiser ver todos os endereços que seu aplicativo pode usar em uma unidade de escala, há uma propriedade chamada possibleOutboundAddresses que os lista.

O Serviço de Aplicativo tem vários pontos de extremidade usados para gerenciar o serviço. Esses endereços são publicados em um documento separado e também estão na marca de serviço do IP AppServiceManagement. A marca AppServiceManagement é usada somente em Ambientes do Serviço de Aplicativo onde é necessário permitir esse tráfego. Os endereços de entrada do Serviço de Aplicativo são controlados na marca de serviço do IP AppService. Não há nenhuma marca de serviço do IP que contenha os endereços de saída usados pelo Serviço de Aplicativo.

Endereço atribuído ao aplicativo

O recurso de endereço atribuído ao aplicativo é uma ramificação da capacidade do SSL baseado em IP. Para acessá-lo, configure o SSL com seu aplicativo. Você pode usar esse recurso para chamadas de SSL baseadas em IP. Você também pode usá-lo para dar ao aplicativo um endereço exclusivo.

Quando você usa um endereço atribuído ao aplicativo, o tráfego ainda passa pelas mesmas funções de front-end que tratam todo o tráfego de entrada na unidade de escala do Serviço de Aplicativo. O endereço atribuído ao seu aplicativo é usado apenas pelo seu aplicativo. Casos de uso para esse recurso:

• Suporte às necessidades de SSL baseado em IP para o aplicativo.
• Defina um endereço dedicado para o aplicativo que não seja compartilhado.

Para saber como definir um endereço no aplicativo, confira Adicionar um certificado TLS/SSL no Serviço de Aplicativo do Azure.

Restrições de acesso

As restrições de acesso permitem filtrar solicitações de entrada. A ação de filtragem ocorre nas funções front-end que são upstream das funções de trabalho em que seus aplicativos são executados. Como as funções de front-end são upstream dos trabalhos, considere as restrições de acesso como uma proteção de nível de rede para os aplicativos. Para obter mais informações, confira Restrições de acesso do Serviço de Aplicativo do Azure.

Esse recurso permite criar uma lista de regras de permissão e negação que são avaliadas em ordem de prioridade. Ele é semelhante ao recurso NSG (Grupo de Segurança de Rede) na rede do Azure. Você pode usar esse recurso em um ASE ou no serviço multilocatário. Ao usá-lo com um ILB ASE ou um ponto de extremidade privado, você pode restringir o acesso de blocos de endereços privados. Para obter mais informações, consulte Configurar as restrições de acesso do Serviço de Aplicativo do Azure.

Observação

Você pode configurar até 512 regras de restrição de acesso por aplicativo.

Ponto de extremidade privado

O ponto de extremidade privado é uma interface de rede que conecta você de forma privada e segura ao seu aplicativo Web por meio de um link privado do Azure. O ponto de extremidade privado usa um endereço IP privado da rede virtual, colocando efetivamente o aplicativo Web na sua rede virtual. Esse recurso é apenas para fluxos de entrada para o aplicativo Web. Para obter mais informações, veja Uso de pontos de extremidade privados para os aplicativos de Serviço de aplicativo.

Alguns casos de uso para esse recurso:

• Restrinja o acesso ao seu aplicativo de recursos em uma rede virtual.
• Mostre o aplicativo em um IP privado na sua rede virtual.
• Proteja seu aplicativo com um WAF.

Pontos de extremidade privados impedem a exfiltração de dados. A única coisa que você pode alcançar no ponto de extremidade privado é o aplicativo com o qual ele está configurado.

Perímetro de Segurança de Rede

O NSP (Perímetro de Segurança de Rede) do Azure é um serviço que fornece um perímetro seguro para comunicação de serviços de PaaS (Plataforma como Serviço). Esses serviços de PaaS podem se comunicar entre si dentro do perímetro. Eles também podem se comunicar com recursos fora do perímetro usando regras públicas de acesso de entrada e saída.

A imposição de regras NSP usa principalmente a segurança baseada em identidade. Essa abordagem não pode ser totalmente imposta em serviços de plataforma, como Serviços de Aplicativo e Funções, que permitem implantar seu próprio código e usar a identidade para representar a plataforma. Se você precisar se comunicar com serviços de PaaS que fazem parte de um NSP, adicione integração de rede virtual às instâncias do Serviço de Aplicativo ou do Functions. Comunique-se com os recursos de PaaS usando pontos de extremidade privados.

Conexões Híbridas

As Conexões Híbridas do Serviço de Aplicativo permitem que os aplicativos façam chamadas de saída para pontos de extremidade TCP especificados. O ponto de extremidade pode ser local, em uma rede virtual ou em qualquer lugar que permita o tráfego de saída para o Azure na porta 443. Para usar o recurso, você precisa instalar um agente de retransmissão, chamado Gerenciador de Conexões Híbridas, em um host do Windows Server 2012 ou mais recente. O Gerenciador de Conexões Híbridas precisa ser capaz de acessar a Retransmissão do Azure na porta 443. Você pode baixar o Gerenciador de Conexões Híbridas na interface do usuário das Conexões Híbridas do Serviço de Aplicativo do portal.

As Conexões Híbridas do Serviço de Aplicativo são baseadas no recurso de Conexões Híbridas de Retransmissão do Azure. O Serviço de Aplicativo usa uma forma especializada do recurso, compatível apenas para fazer chamadas de saída do aplicativo para um host e uma porta TCP. Esse host e a porta precisam apenas ser resolvidos no host em que o Gerenciador de Conexões Híbridas está instalado.

Quando o aplicativo, no Serviço de Aplicativo, faz uma pesquisa de DNS no host e na porta definidos na conexão híbrida, o tráfego é redirecionado automaticamente para passar pela conexão híbrida e fora do Gerenciador de Conexões Híbridas. Para obter mais informações, consulte Conexões Híbridas do Serviço de Aplicativo.

Este recurso é normalmente usado para:

• Acessar recursos em redes privadas que não estão conectadas ao Azure com uma VPN ou o ExpressRoute.
• Suportar a migração de aplicativos locais para o Serviço de Aplicativo sem a necessidade de mover bancos de dados de suporte.
• Fornecer acesso com segurança aprimorada a um único host e porta por conexão híbrida. A maioria dos recursos de rede abre o acesso a uma rede. Com conexões híbridas, você pode alcançar apenas o host e a porta únicos.
• Englobar cenários não cobertos por outros métodos de conectividade de saída.
• Executar o desenvolvimento no Serviço de Aplicativo para que os aplicativos usem os recursos locais com facilidade.

Como esse recurso permite o acesso a recursos locais sem uma lacuna do firewall de entrada, ele é popular com os desenvolvedores. Os outros recursos de saída de rede do Serviço de Aplicativo estão relacionados à Rede Virtual do Azure. As Conexões Híbridas não precisam passar por uma rede virtual. Elas podem ser usadas para uma variedade maior de necessidades da rede.

As Conexões Híbridas do Serviço de Aplicativo não sabem o que você está fazendo além disso. Você pode usá-lo para acessar um banco de dados, um serviço Web ou um soquete TCP arbitrário em um mainframe. Essencialmente, o recurso encapsula pacotes TCP.

Conexões Híbridas é popular para desenvolvimento. Você também pode usá-lo em aplicativos de produção. São excelentes para acessar um serviço Web ou um banco de dados, mas não são apropriadas para situações que envolvam a criação de várias conexões.

Integração de rede virtual

A integração de rede virtual do Serviço de Aplicativo permite que o aplicativo faça solicitações de saída em uma rede virtual do Azure.

O recurso de integração de rede virtual permite colocar o back-end de seu aplicativo em uma sub-rede de uma rede virtual do Resource Manager. A rede virtual precisa estar na mesma região que seu aplicativo. Esse recurso não está disponível em um Ambiente do Serviço de Aplicativo do Azure, que já está em uma rede virtual. Casos de uso para esse recurso:

• Acesse recursos em redes virtuais do Resource Manager na mesma região.
• Acessar recursos em redes virtuais emparelhadas, incluindo conexões entre regiões.
• Acesse recursos protegidos por pontos de extremidade de serviço.
• Acesse recursos acessíveis em conexões de ExpressRoute ou VPN.
• Acesse recursos em redes privadas sem a necessidade e o custo de um gateway de rede virtual.
• Ajude a proteger todo o tráfego de saída.
• Force o túnel de todo o tráfego de saída.

Para saber mais, confira Integração de rede virtual do Serviço de Aplicativo.

Integração de rede virtual exigida por gateway

A integração de rede virtual exigida pelo gateway foi a primeira edição da integração de rede virtual no Serviço de Aplicativo. O recurso usa uma VPN ponto a site para conectar o host em que seu aplicativo é executado a um gateway de Rede Virtual em sua rede virtual. Quando você configura o recurso, o aplicativo obtém um dos endereços ponto a site atribuídos para cada instância.

A integração exigida pelo gateway permite que você se conecte diretamente a uma rede virtual em outra região sem emparelhamento e se conecte a uma rede virtual clássica. O recurso é limitado a planos do Serviço de Aplicativo do Windows e não funciona com redes virtuais conectadas ao ExpressRoute. Recomendamos que você use a integração de rede virtual regional. Para obter mais informações, consulte Configurar a integração de rede virtual necessária para gateway.

Ambiente do Serviço de Aplicativo

Um ASE é uma implantação de locatário único do Serviço de Aplicativo do Azure, executada na sua rede virtual. Alguns casos para esse recurso:

• Acesse recursos na sua rede virtual.
• Acesse recursos no ExpressRoute.
• Mostre seus aplicativos com um endereço privado na rede virtual.
• Acesse recursos em pontos de extremidade de serviço.
• Acesse recursos em pontos de extremidade privados.

Com um ASE, você não precisa usar a integração de rede virtual, pois o ASE já está na rede virtual. Se você quiser acessar recursos, como o SQL ou o Armazenamento do Microsoft Azure em pontos de extremidade de serviço, habilite os pontos de extremidade de serviço na sub-rede do ASE. Se quiser acessar recursos na rede virtual ou em pontos de extremidade privados da rede virtual, não é necessário fazer nenhuma configuração extra. Se quiser acessar recursos no ExpressRoute, você já está na rede virtual e, portanto, não precisa configurar nada no ASE ou nos aplicativos incluídos nele.

Como os aplicativos em um ASE ILB podem ser expostos em um endereço IP privado, você pode adicionar dispositivos WAF para expor apenas alguns aplicativos à Internet. Não expor outras pessoas ajuda a manter o resto seguro. Esse recurso pode ajudar a facilitar o desenvolvimento de aplicativos multicamadas.

No momento, alguns recursos não são permitidos no serviço multilocatário, mas sim em um ASE. Estes são alguns exemplos:

• Hospede seus aplicativos em um único serviço de locatário.
• Escale verticalmente para muitas outras instâncias além do que é possível no serviço multilocatário.
• Carregue certificados do cliente de autoridade de certificação privada para uso dos aplicativos com pontos de extremidade protegidos por autoridade de certificação privada.
• Force o TLS 1.2 em todos os aplicativos hospedados no sistema, sem nenhuma capacidade de desabilitá-lo no nível do aplicativo.

O ASE fornece a melhor história em torno da hospedagem isolada e dedicada do aplicativo. A abordagem envolve alguns desafios de gerenciamento. Considere o seguinte antes de usar um ASE operacional:

• Um ASE é executado dentro de sua rede virtual, mas tem dependências fora da rede virtual. Essas dependências devem ser permitidas. Para obter mais informações, confira Considerações de rede para um Ambiente do Serviço de Aplicativo.
• Um ASE não é colocado em escala imediatamente, como o serviço multilocatário. Você precisa prever as necessidades de escala, em vez de dimensionar reativamente.
• Um ASE tem um custo inicial mais alto. Para aproveitar ao máximo seu ASE, você deve planejar a colocação de várias cargas de trabalho em um ASE, em vez de usá-lo para pequenos esforços.
• Os aplicativos em um ASE não podem restringir seletivamente o acesso a alguns aplicativos e não a outros.
• Um ASE está em uma sub-rede. Todas as regras de rede se aplicam a todo o tráfego de e para esse ASE. Se você quiser atribuir regras de tráfego de entrada para apenas um aplicativo, use as restrições de acesso.

Combinação de recursos

Os recursos indicados para o serviço multilocatário podem ser usados em conjunto para resolver casos de uso mais elaborados. Dois dos casos de uso mais comuns são descritos aqui como exemplos. Ao entender o que os diversos recursos fazem, você pode atender a quase todas as suas necessidades de arquitetura do sistema.

Colocar um aplicativo em uma rede virtual

Você pode se perguntar como colocar um aplicativo em uma rede virtual. Se colocar seu aplicativo em uma rede virtual, os pontos de extremidade de entrada e saída para o aplicativo estarão dentro da rede virtual. Um ASE é a melhor maneira de resolver esse problema. Entretanto, você pode atender à maioria das suas necessidades no serviço multilocatário, combinando os recursos. Por exemplo, você pode hospedar aplicativos apenas da intranet com endereços de entrada e saída privados:

• Criar um gateway de aplicativo com endereços de entrada e saída privados.
• Proteger o tráfego de entrada para o aplicativo com pontos de extremidade de serviço.
• Usar o recurso de integração de rede virtual para que o back-end do aplicativo esteja na rede virtual.

Esse estilo de implantação não oferece um endereço dedicado para o tráfego de saída para a Internet ou a capacidade de bloquear todo o tráfego de saída do seu aplicativo. Isso lhe dá muito do que você só obteria de outra forma com um ASE.

Criar aplicativos de várias camadas

Em um aplicativo de várias camadas, os aplicativos de back-end da API só podem ser acessados da camada de front-end. Há duas maneiras de criar um aplicativo de várias camadas. Comece usando a integração de rede virtual para conectar o aplicativo Web de front-end a uma sub-rede na rede virtual. Isso permite que seu aplicativo Web faça chamadas em sua rede virtual. Depois que seu aplicativo front-end estiver conectado à rede virtual, decida como bloquear o acesso ao aplicativo de API. Você poderá:

• Hospedar o front-end e o aplicativo de API no mesmo ILB ASE e expor o aplicativo de front-end na Internet usando um gateway de aplicativo.
• Hospedar o front-end no serviço multilocatário e o back-end em um ILB ASE.
• Hospedar o front-end e o aplicativo de API no serviço multilocatário.

Se você estiver hospedando o front-end e o aplicativo de API para um aplicativo de várias camadas, poderá:

• Mostrar o aplicativo de API usando pontos de extremidade privados na rede virtual:

  

• Use pontos de extremidade de serviço para garantir que o tráfego de entrada para o aplicativo de API venha apenas da sub-rede usada pelo aplicativo Web de front-end:

  

Veja algumas considerações para ajudá-lo a decidir qual método usar:

• Ao usar pontos de extremidade de serviço, você só precisa proteger o tráfego para o aplicativo de API na sub-rede de integração. Os pontos de extremidade de serviço ajudam a proteger o aplicativo de API, mas você ainda pode ter exfiltração dos dados do aplicativo de front-end para outros aplicativos no serviço de aplicativo.
• Ao usar pontos de extremidade privados, você tem duas sub-redes, o que aumenta a complexidade. Além disso, o ponto de extremidade privado é um recurso de nível superior e aumenta a sobrecarga de gerenciamento. O benefício de usar pontos de extremidade privados é que você não tem a possibilidade de exfiltração dos dados.

Qualquer um dos métodos funciona com vários front-ends. Em uma pequena escala, os pontos de extremidade de serviço são mais fáceis de usar, pois é possível habilitá-los para o aplicativo de API na sub-rede de integração de front-end. Ao adicionar mais aplicativos de front-end, você precisa ajustar cada aplicativo de API para incluir pontos de extremidade de serviço com a sub-rede de integração. Há mais complexidade em usar pontos de extremidade privados, mas você não precisa alterar nada em seus aplicativos de API depois de definir um ponto de extremidade privado.

Aplicativos de linha de negócios

Os aplicativos de LOB (linha de negócios) são aplicativos internos que normalmente não são expostos para acesso na Internet. Esses aplicativos são chamados de dentro das redes corporativas, onde o acesso pode ser estritamente controlado. Se você usar um ILB ASE, será fácil hospedar seus aplicativos de linha de negócios. Com o serviço multilocatário, você pode usar pontos de extremidade privados ou de serviço combinados com um gateway de aplicativo. Há dois motivos para usar um gateway de aplicativo com pontos de extremidade de serviço, em vez de privados:

• Você precisa de proteção WAF nos aplicativos de LOB.
• Você deseja balancear a carga para várias instâncias dos aplicativos de LOB.

Se nenhuma dessas opções for aplicável, use pontos de extremidade privados. Com pontos de extremidade privados disponíveis no Serviço de Aplicativo, você pode expor seus aplicativos em endereços privados na rede virtual. Você pode acessar o ponto de extremidade privado da rede virtual em conexões do ExpressRoute e da VPN.

A configuração de pontos de extremidade privados expõe seus aplicativos em um endereço privado. Você precisa configurar o DNS para acessar esse endereço no local. Para fazer essa configuração funcionar, encaminhe a zona privada DNS do Azure que contém seus pontos de extremidade privados para seus servidores DNS locais. As zonas privadas de DNS do Azure não dão suporte ao encaminhamento de zona, mas você pode dar suporte a isso usando o resolvedor privado de DNS do Azure.

Portas do Serviço de Aplicativo

Se você verificar o Serviço de Aplicativo, encontrará várias portas expostas para conexões de entrada. Não há como bloquear ou controlar o acesso a essas portas no serviço multilocatário. Veja a lista das portas expostas:

Uso	Porta ou portas
HTTP/HTTPS	80, 443
Gerenciamento	454, 455
FTP/FTPS	21, 990, 10001-10300
Depuração remota no Visual Studio	4020, 4022, 4024
Serviço de Implantação da Web	8172
Uso da infraestrutura	7654, 1221