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. No entanto, 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 ajudará a determinar qual recurso deve ser usado, com base em alguns 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 usados dependerão se você estiver no serviço multilocatário ou em um ASE.

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 tratam as solicitações para o aplicativo não podem ser usados para resolver problemas ao fazer chamadas pelo aplicativo. Da mesma forma, os recursos que resolvem problemas de chamadas pelo aplicativo não podem ser usados para resolver problemas do aplicativo.

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:

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:

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 trabalhado para cada instância existente.

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 trabalho. O plano PremiumV2 usa outro tipo de VM. O PremiumV3 usa um outro tipo de VM. Ao mudar a família de VMs, você obtém um conjunto diferente de endereços de saída. Se você escalar do Standard para o PremiumV2, os endereços de saída serão alterados. Se você dimensionar do PremiumV2 para o PremiumV3, os endereços de saída serão alterados. Em algumas unidades de escala mais antigas, os endereços de entrada e de saída serão alterados quando você escalar do Standard para o 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. Esses endereços são compartilhados por todos os aplicativos em execução na mesma família de VMs de trabalho da implantação do Serviço de Aplicativo. Caso queira ver todos os endereços que o aplicativo pode usar em uma unidade de escala, há uma propriedade chamada possibleOutboundAddresses que os listará.

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. Acesse-o configurando o SSL com o 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. No entanto, o endereço atribuído ao aplicativo é usado somente por ele. 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 de front-end que são upstream das funções de trabalho onde os aplicativos estão em execução. 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 sobre restrições de acesso, confira a Visão geral das restrições de acesso.

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 saber como habilitar esse recurso, confira Configurações de restrições de acesso.

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, confira Uso de pontos de extremidade privados para o aplicativo Web do Azure.

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.

Os pontos de extremidade privados impedem a exfiltração dos dados, pois por meio deles só é possível acessar o aplicativo com o qual estão configurados.

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 saber mais, confira 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 as Conexões Híbridas, você só pode acessar o único host e porta.
• 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. Portanto, você pode usá-las 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.

As Conexões Híbridas são populares para o desenvolvimento, mas também são usadas 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.
• Acessar 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 funciona com a conexão do host no qual o aplicativo está sendo executado a um gateway da Rede Virtual usando uma VPN ponto a site. 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. É recomendável usar a integração de rede virtual regional. Para saber mais sobre o recurso, confira Integração de rede virtual do Serviço de Aplicativo.

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 ILB ASE podem ser expostos em um endereço IP privado, adicione facilmente dispositivos WAF para mostrar apenas os aplicativos que deseja na Internet e ajudar a manter o restante seguro. Esse recurso pode ajudar a facilitar o desenvolvimento de aplicativos multicamadas.

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

• Hospede os aplicativos em um serviço de locatário único.
• Escale verticalmente para muitas outras instâncias 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 o melhor cenário em relação à hospedagem de aplicativos isolados e dedicados, mas envolve alguns desafios de gerenciamento. Considere o seguinte antes de usar um ASE operacional:

• Um ASE é executado dentro da rede virtual, mas tem dependências fora dela. 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 é dimensionado 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 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 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, mas são apenas 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 pela combinação de 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 fornecerá um endereço dedicado para o tráfego de saída para a Internet, nem a capacidade de bloquear todo o tráfego de saída do aplicativo. Ele fornecerá uma grande parte do que você só obteria 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 permitirá que o aplicativo Web faça chamadas na sua rede virtual. Depois que o aplicativo de front-end estiver conectado à rede virtual, você precisará decidir como bloquear o acesso ao aplicativo de API. Você pode:

• 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 funcionará 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.

Configurar os pontos de extremidade privados mostrará os aplicativos em um endereço privado, mas é preciso configurar o DNS para acessar esse endereço local. Para que essa configuração funcione, encaminhe a zona privada do DNS do Azure que contém os 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 que são 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: