Recursos de rede do Serviço de Aplicativo

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 são acessíveis diretamente pela Internet e podem alcançar apenas pontos de extremidade hospedados na Internet. Mas, 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. Este artigo irá ajudá-lo a determinar qual recurso usar, com base em alguns exemplos de casos de uso.

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

• O serviço público multilocatário hospeda planos do Serviço de Aplicativo nos SKUs de preços Gratuito, Compartilhado, Básico, Standard, Premium, PremiumV2 e PremiumV3.
• O ASE (Ambiente do Serviço de Aplicativo) de locatário único hospeda planos do Serviço de Aplicativo SKU Isolado diretamente em sua rede virtual do Azure.

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

Nota

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 lidam com 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 trabalhadores. Todas as funções em uma implantação do Serviço de Aplicativo existem 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, você precisa de recursos para lidar com os vários aspetos 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ê está fazendo chamadas de seu aplicativo. Da mesma forma, os recursos que resolvem problemas para chamadas do seu aplicativo não podem ser usados para resolver problemas do seu aplicativo.

Recursos de entrada	Recursos de saída
Endereço atribuído à aplicação	Ligações Híbridas
Restrições de acesso	Integração de rede virtual necessária pelo gateway
Pontos finais de serviço	Integração da rede virtual
Pontos finais privados

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

Casos de uso e recursos

Para qualquer caso de uso, pode haver algumas maneiras de resolver o problema. Escolher o melhor recurso às vezes vai além do caso de uso em si. Os seguintes casos de uso de entrada sugerem como usar os recursos de rede do Serviço de Aplicativo para resolver problemas com o controle do tráfego que vai para seu aplicativo:

Caso de uso de entrada	Caraterística
Suporte às necessidades de SSL baseadas em IP para seu aplicativo	Endereço atribuído à aplicação
Ofereça suporte a endereços de entrada dedicados não compartilhados para seu aplicativo	Endereço atribuído à aplicação
Restrinja o acesso ao seu aplicativo a partir de um conjunto de endereços bem definidos	Restrições de acesso
Restringir o acesso ao seu aplicativo a partir de recursos em uma rede virtual	Pontos de extremidade de serviço Pontos de extremidade privados do balanceador de carga interno (ILB) ASE
Exponha seu aplicativo em um IP privado em sua rede virtual	Pontos de extremidade privados ILB ASE IP privado para tráfego de entrada em uma instância do Application Gateway com pontos de extremidade de serviço
Proteja seu aplicativo com um firewall de aplicativo Web (WAF)	Application Gateway e ILB ASE Application Gateway com pontos de extremidade privados Application Gateway com pontos de extremidade de serviço Azure Front Door com restrições de acesso
Balancear a carga do tráfego para seus aplicativos em diferentes regiões	Azure Front Door com restrições de acesso
Tráfego de balanceamento de carga na mesma região	Application Gateway 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 seu aplicativo:

Caso de uso de saída	Caraterística
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 necessária pelo gateway ASE e emparelhamento de rede virtual
Acesse recursos protegidos com pontos de extremidade de serviço	ASE de integração de rede virtual
Acessar recursos em uma rede privada que não está conectada ao Azure	Ligações Híbridas
Acessar recursos nos circuitos do Azure ExpressRoute	ASE de integração de rede virtual
Proteja o tráfego de saída a partir da sua aplicação Web	integração de rede virtual e grupos de segurança de rede ASE
Encaminhar o tráfego de saída do seu 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 dão suporte a muitos clientes em cada implantação. Os planos de SKU Gratuito e Compartilhado hospedam cargas de trabalho de clientes em trabalhadores multilocatário. Os planos Básico e Superior hospedam cargas de trabalho de clientes dedicadas a apenas um plano do Serviço de Aplicativo. Se você tiver um plano do Serviço de Aplicativo Padrão, todos os aplicativos desse plano serão executados no mesmo trabalhador. Se você dimensionar o trabalhador, todos os aplicativos desse plano do Serviço de Aplicativo serão replicados em um novo trabalhador para cada instância do seu plano do Serviço de Aplicativo.

Endereços de saída

As VMs 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 VM de trabalhador. O plano PremiumV2 usa outro tipo de VM. O PremiumV3 usa ainda outro tipo de VM. Ao alterar a família VM, você obtém um conjunto diferente de endereços de saída. Se você escalar de Standard para PremiumV2, seus endereços de saída serão alterados. Se você escalar de PremiumV2 para PremiumV3, seus endereços de saída serão alterados. Em algumas unidades de escala mais antigas, os endereços de entrada e saída serão alterados quando você dimensionar 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 seu aplicativo para fazer chamadas de saída são listados nas propriedades do seu aplicativo. Esses endereços são compartilhados por todos os aplicativos executados na mesma família de VMs de trabalho na implantação do Serviço de Aplicativo. 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 listará.

O Serviço de Aplicativo tem muitos pontos de extremidade que são usados para gerenciar o serviço. Esses endereços são publicados em um documento separado e também estão na AppServiceManagement etiqueta de serviço IP. A AppServiceManagement tag é usada somente em ambientes do Serviço de Aplicativo em que você precisa permitir esse tráfego. Os endereços de entrada do AppService Serviço de Aplicativo são rastreados na tag de serviço IP. Não há nenhuma marca de serviço IP que contenha os endereços de saída usados pelo Serviço de Aplicativo.

Endereço atribuído à aplicação

O recurso de endereço atribuído ao aplicativo é um desdobramento do recurso SSL baseado em IP. Você acessá-lo configurando SSL com seu aplicativo. Você pode usar esse recurso para chamadas SSL baseadas em IP. Você também pode usá-lo para dar ao seu aplicativo um endereço que só ele tem.

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

• Suporta as necessidades de SSL baseadas em IP para a sua aplicação.
• Defina um endereço dedicado para seu aplicativo que não seja compartilhado.

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

Restrições de acesso

As restrições de acesso permitem-lhe filtrar pedidos de entrada. A ação de filtragem ocorre nas funções front-end que estão a montante das funções de trabalho em que seus aplicativos estão sendo executados. Como as funções front-end estão a montante dos trabalhadores, você pode pensar em restrições de acesso como proteção no nível da rede para seus aplicativos. Para obter mais informações sobre restrições de acesso, consulte Visão geral das restrições de acesso.

Esse recurso permite que você crie uma lista de regras de permissão e negação que são avaliadas em ordem de prioridade. É 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, você pode restringir o acesso de blocos de endereços privados. Para saber como habilitar esse recurso, consulte Configurando restrições de acesso.

Nota

Até 512 regras de restrição de acesso podem ser configuradas por aplicativo.

Ponto final privado

Ponto de extremidade privado é uma interface de rede que conecta você de forma privada e segura ao seu link privado do Aplicativo Web pelo Azure. O ponto de extremidade privado usa um endereço IP privado de sua rede virtual, trazendo efetivamente o aplicativo Web para sua rede virtual. Esse recurso é apenas para fluxos de entrada para seu aplicativo Web. Para obter mais informações, consulte Usando pontos de extremidade privados para o Azure Web App.

Alguns casos de uso para esse recurso:

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

Os pontos de extremidade privados impedem a exfiltração de dados porque a única coisa que você pode alcançar através do ponto de extremidade privado é o aplicativo com o qual ele está configurado.

Perímetro de Segurança de Rede

O Azure Network Security Perimeter (NSP) é um serviço que fornece um perímetro seguro para a comunicação de serviços de plataforma como serviço (PaaS). Esses serviços PaaS podem se comunicar entre si dentro do perímetro e 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 está usando principalmente a segurança baseada em identidade, que não pode ser totalmente aplicada 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 PaaS que fazem parte de um NSP, precisará adicionar integração de rede virtual às suas instâncias do Serviço de Aplicativo ou Funções e se comunicar com os recursos de PaaS usando pontos de extremidade privados.

Ligações Híbridas

As Conexões Híbridas do Serviço de Aplicativo permitem que seus 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 Windows Server 2012 ou mais recente. O Gerenciador de Conexões Híbridas precisa ser capaz de alcançar o Azure Relay na porta 443. Você pode baixar o Gerenciador de Conexões Híbridas da interface do usuário de Conexões Híbridas do Serviço de Aplicativo no portal.

As Conexões Híbridas do Serviço de Aplicativo são criadas no recurso Conexões Híbridas de Retransmissão do Azure. O Serviço de Aplicativo usa uma forma especializada do recurso que oferece suporte apenas a fazer chamadas de saída do seu aplicativo para um host e uma porta TCP. Esse host e essa porta só precisam ser resolvidos no host onde o Hybrid Connection Manager está instalado.

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

Este recurso é comumente usado para:

• Acesse recursos em redes privadas que não estão conectadas ao Azure com uma VPN ou Rota Expressa.
• Ofereça suporte à migração de aplicativos locais para o Serviço de Aplicativo sem a necessidade de mover bancos de dados de suporte.
• Forneça acesso com segurança aprimorada a um único host e porta por conexão híbrida. A maioria das funcionalidades de rede apresenta acesso aberto a uma rede. Com as Conexões Híbridas, você só pode acessar o host e a porta únicos.
• Cubra cenários não cobertos por outros métodos de conectividade de saída.
• Execute o desenvolvimento no Serviço de Aplicativo de uma forma que permita que os aplicativos usem facilmente recursos locais.

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

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

O Hybrid Connections é popular para desenvolvimento, mas também é usado em aplicações de produção. É ótimo para acessar um serviço Web ou banco de dados, mas não é apropriado para situações que envolvem a criação de muitas conexões.

Integração da rede virtual

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

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

• Acesse recursos em redes virtuais do Resource Manager na mesma região.
• Acesse recursos em redes virtuais emparelhadas, incluindo conexões entre regiões.
• Acesse recursos protegidos com pontos de extremidade de serviço.
• Aceda a recursos acessíveis através de ligações 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.
• Forçar túnel todo o tráfego de saída.

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

Integração de rede virtual necessária pelo 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 funciona conectando o host em que seu aplicativo está sendo executado a um gateway de Rede Virtual em sua rede virtual usando uma VPN ponto a site. Quando você configura o recurso, seu aplicativo obtém um dos endereços atribuídos ponto a site atribuídos a cada instância.

A integração necessária do 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 aos planos do Serviço de Aplicativo do Windows e não funciona com redes virtuais conectadas à Rota Expressa. Recomenda-se o uso da integração de rede virtual regional. Para obter mais informações sobre esse recurso, consulte Integração de rede virtual do Serviço de Aplicativo.

Ambiente do Serviço de Aplicações

Um Ambiente do Serviço de Aplicativo (ASE) é uma implantação de locatário único do Serviço de Aplicativo do Azure que é executado em sua rede virtual. Alguns casos como esse para esse recurso:

• Aceda a recursos na sua rede virtual.
• Aceda a recursos através da Rota Expressa.
• Exponha seus aplicativos com um endereço privado em sua rede virtual.
• Acesse recursos entre pontos de extremidade de serviço.
• Aceda a recursos através de terminais privados.

Com um ASE, você não precisa usar a integração de rede virtual porque o ASE já está em sua rede virtual. Se você quiser acessar recursos como SQL ou Armazenamento do Azure em pontos de extremidade de serviço, habilite pontos de extremidade de serviço na sub-rede ASE. Se você quiser acessar recursos na rede virtual ou pontos de extremidade privados na rede virtual, não precisará fazer nenhuma configuração extra. Se quiser acessar recursos na Rota Expressa, você já está na rede virtual e não precisa configurar nada no ASE ou nos aplicativos nele.

Como os aplicativos em um ILB ASE podem ser expostos em um endereço IP privado, você pode facilmente adicionar dispositivos WAF para expor apenas os aplicativos que deseja à Internet e ajudar a manter o resto seguro. Esse recurso pode ajudar a facilitar o desenvolvimento de aplicativos multicamadas.

Algumas coisas não são atualmente possíveis a partir do serviço multilocatário, mas são possíveis a partir de um ASE. Seguem-se alguns exemplos:

• Hospede seus aplicativos em um serviço de locatário único.
• Dimensione para muito mais instâncias do que é possível no serviço multilocatário.
• Carregue certificados de cliente de CA privada para uso por seus aplicativos com pontos de extremidade privados protegidos por CA.
• Força o TLS 1.2 em todos os aplicativos hospedados no sistema sem qualquer capacidade de desativá-lo no nível do aplicativo.

O ASE fornece a melhor história sobre hospedagem de aplicativos isolados e dedicados, mas envolve alguns desafios de gerenciamento. Alguns aspetos a ter em conta antes de utilizar um ASE operacional:

• Um ASE é executado dentro da sua rede virtual, mas tem dependências fora da rede virtual. Essas dependências devem ser permitidas. Para obter mais informações, consulte Considerações de rede para um ambiente do Serviço de Aplicativo.
• Um ASE não é dimensionado imediatamente como o serviço multilocatário. Você precisa antecipar as necessidades de dimensionamento em vez de dimensionar reativamente.
• Um ASE tem um custo inicial mais elevado. Para tirar o máximo proveito do seu ASE, você deve planejar colocar muitas 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 no ASE e não a outros.
• Um ASE está em uma sub-rede, e 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 restrições de acesso.

Combinação de funcionalidades

Os recursos observados para o serviço multilocatário podem ser usados juntos para resolver casos de uso mais elaborados. Dois dos casos de uso mais comuns são descritos aqui, mas isso são apenas exemplos. Ao entender o que os vários recursos fazem, você pode atender a quase todas as suas necessidades de arquitetura de sistema.

Colocar uma aplicação numa rede virtual

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

• Criação de um gateway de aplicativo com endereços privados de entrada e saída.
• Protegendo o tráfego de entrada para seu aplicativo com pontos de extremidade de serviço.
• Usando o recurso de integração de rede virtual para que o back-end do seu aplicativo esteja em sua rede virtual.

Esse estilo de implantação não fornecerá 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. Proporcionar-lhe-á muito do que de outra forma só obteria com um ASE.

Criar aplicativos de várias camadas

Um aplicativo multicamadas é um aplicativo no qual os aplicativos back-end da API podem ser acessados somente a partir da camada front-end. Há duas maneiras de criar um aplicativo de várias camadas. Ambos começam usando a integração de rede virtual para conectar seu aplicativo Web front-end a uma sub-rede em uma rede virtual. Isso permitirá que seu aplicativo Web faça chamadas em sua rede virtual. Depois que seu aplicativo front-end estiver conectado à rede virtual, você precisará decidir como bloquear o acesso ao seu aplicativo de API. Pode:

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

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

• Exponha seu aplicativo de API usando pontos de extremidade privados em sua rede virtual:

  

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

  

Aqui estão 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 seu aplicativo de API para a 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 de dados do seu aplicativo front-end para outros aplicativos no serviço de aplicativo.
• Quando você usa pontos de extremidade privados, você tem duas sub-redes em jogo, o que adiciona complexidade. Além disso, o ponto de extremidade privado é um recurso de nível superior e adiciona sobrecarga de gerenciamento. A vantagem de usar endpoints privados é que você não tem a possibilidade de exfiltração de dados.

Qualquer um dos métodos funcionará com vários front-ends. Em pequena escala, os pontos de extremidade de serviço são mais fáceis de usar porque você simplesmente habilita os pontos de extremidade de serviço para o aplicativo de API na sub-rede de integração front-end. À medida que você adiciona mais aplicativos front-end, precisa ajustar cada aplicativo de API para incluir pontos de extremidade de serviço com a sub-rede de integração. Quando você usa pontos de extremidade privados, há mais complexidade, mas você não precisa alterar nada em seus aplicativos de API depois de definir um ponto de extremidade privado.

Aplicações de linha de negócio

Os aplicativos de linha de negócios (LOB) são aplicativos internos que normalmente não são expostos para acesso pela Internet. Estas aplicações são chamadas a partir de dentro de redes corporativas onde o acesso pode ser estritamente controlado. Se você usa um ILB ASE, é fácil hospedar seus aplicativos de linha de negócios. Se você usar o serviço multilocatário, poderá usar pontos de extremidade privados ou pontos de extremidade 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 usar pontos de extremidade privados:

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

Se nenhuma dessas necessidades se aplicar, é melhor usar endpoints privados. Com pontos de extremidade privados disponíveis no Serviço de Aplicativo, você pode expor seus aplicativos em endereços privados em sua rede virtual. O ponto de extremidade privado que você coloca em sua rede virtual pode ser acessado através de conexões ExpressRoute e VPN.

A configuração de pontos de extremidade privados exporá seus aplicativos em um endereço privado, mas você precisará configurar o DNS para alcançar esse endereço localmente. Para que essa configuração funcione, você precisará encaminhar a zona privada do DNS do Azure que contém seus pontos de extremidade privados para seus servidores DNS locais. As zonas privadas do DNS do Azure não dão suporte ao encaminhamento de zona, mas você pode dar suporte ao encaminhamento de zona usando o resolvedor privado do DNS do Azure.

Portas do Serviço de Aplicativo

Se analisar o Serviço de Aplicações, encontrará várias portas expostas para ligações de entrada. Não há como bloquear ou controlar o acesso a essas portas no serviço multilocatário. Aqui está a lista de portas expostas:

Utilizar	Porta ou portos
HTTP/HTTPS	80, 443
Gestão	454, 455
FTP/FTPS	21, 990, 10001-10300
Depuração remota do Visual Studio	4020, 4022, 4024
Serviço de implantação da Web	8172
Utilização da infraestrutura	7654, 1221