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. 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 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, Padrão, Premium, PremiumV2, PremiumV3 e PremiumV4.
• O Ambiente de Serviço de Aplicações (ASE) de locatário único hospeda planos do Serviço de Aplicações SKU Isolado diretamente na sua rede virtual do Azure.

Os recursos que utiliza dependem se está no serviço multi-inquilino ou num 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 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 numa implementação do Serviço de Aplicações existem numa rede multi-inquilino. 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ê faz 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.

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:

Os seguintes casos de uso externo sugerem como utilizar os recursos de rede do Serviço de Aplicações para resolver as necessidades de acesso externo para a sua aplicação.

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 Partilhado hospedam cargas de trabalho de clientes em processadores multitenant. 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. Ao dimensionar a instância de trabalho, todas as aplicações nesse plano de Serviço de Aplicações são replicadas numa nova instância de trabalho para cada instância do seu plano de Serviço de Aplicações.

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 trabalhador. O plano PremiumV2 usa outro tipo de máquina virtual. O PremiumV3 usa ainda outro tipo de máquina virtual. E o PremiumV4 usa ainda outro tipo de máquina virtual.

Ao alterar a família de máquinas virtuais, 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 mudarão. Em algumas unidades de escala mais antigas, os endereços de entrada e saída mudam 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 seu aplicativo para fazer chamadas de saída são listados nas propriedades do seu 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 App Service tem muitos endpoints que são usados para gerir 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 App Service são monitorizados na etiqueta de serviço IP AppService. 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. Para acessá-lo, configure o 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. O endereço atribuído ao seu aplicativo é usado apenas pelo 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 são 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, consulte Restrições de acesso do Serviço de Aplicativo do Azure.

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 obter mais informações, consulte Configurar restrições de acesso do Serviço de Aplicativo do Azure.

Ponto final privado

O ponto de extremidade privado é uma interface de rede que conecta você de forma privada e segura ao seu App Web por meio do link privado do 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 aplicativos do App Service.

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 endpoints privados impedem a exfiltração de dados. 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 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.

Na imposição de regras NSP, utiliza-se principalmente a segurança baseada em identidade. Essa abordagem 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, adicione integração de rede virtual às suas instâncias do Serviço de Aplicativo ou do Functions. Comunique-se com os recursos de PaaS através de 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 estar no local, numa 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 App Service são construídas sobre a capacidade de Conexões Híbridas do Azure Relay. 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 obter mais informações, 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 melhorada a um único host e porta para cada conexão híbrida. A maioria das funcionalidades de rede apresenta acesso aberto a uma rede. Com as Ligações Híbridas, pode aceder apenas a um único host e porta.
• 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 App Service não sabem o que você está fazendo com ele. 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 faz tunelamento de pacotes TCP.

Hybrid Connections é popular para desenvolvimento. Você também pode usá-lo em aplicativos 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.
• Aceda a recursos protegidos por endpoints 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 o túnel de todo o tráfego de saída.

Para saber mais, consulte a integração de rede virtual do App Service.

Integração de rede virtual que requer 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 configurar a funcionalidade, a sua aplicação recebe um dos endereços ponto-a-site atribuídos a cada instância.

A integração exigida do gateway permite a conexão direta a uma rede virtual noutra região sem emparelhamento e a ligação 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. Recomendamos que você use a integração de rede virtual regional. Para obter mais informações, consulte Configurar a integração de rede virtual com requisito de gateway.

Ambiente do Serviço de Aplicações

Um App Service Environment (ASE) é uma implementação de locatário único do App Service do Azure que é executada na sua rede virtual. Alguns casos para esta funcionalidade:

• 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 através de endpoints de serviço.
• Aceda a recursos através de endpoints 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 quiser aceder a recursos como SQL ou Azure Storage através de pontos de extremidade do serviço, habilite os pontos de extremidade do serviço na sub-rede do 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 adicionar dispositivos WAF para expor apenas alguns aplicativos à Internet. Não expor os outros ajuda a manter os demais seguros. 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 único serviço de locatário.
• Dimensione para muitas mais instâncias do que o possível no serviço multilocatário.
• Carregue certificados de cliente de CA privada para uso nas suas aplicações com endpoints privados protegidos por uma CA privada.
• 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. A abordagem envolve alguns desafios de gestão. 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. Quaisquer regras de rede aplicam-se 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

As funcionalidades mencionadas para o serviço multilocatário podem ser usadas 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 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 a sua aplicação com endpoints 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 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. Oferece-lhe muito do que só obteria de outra forma com um ASE.

Criar aplicativos de várias camadas

Uma aplicação multicamadas é uma aplicação na qual as aplicações back-end da API podem ser acedidas apenas 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 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 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 numa 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 extremidades de serviço para assegurar que o tráfego de entrada para a sua aplicação de API venha apenas da sub-rede utilizada pela sua aplicação Web front-end.

  

Aqui estão algumas considerações para ajudá-lo a decidir qual método usar:

• Quando se utilizam pontos de extremidade de serviço, só é necessário proteger o tráfego da sua aplicação API para a sub-rede de integração. Os endpoints de serviço ajudam a proteger a aplicação de API, mas você ainda pode ter exfiltração de dados da sua aplicação de front-end para outros aplicativos no serviço de aplicações.
• 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 funciona 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 são adicionados mais aplicativos front-end, é necessário ajustar cada aplicativo de API para incluir os endpoints de serviço na 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 utilizar o serviço multilocatário, poderá usar pontos de extremidade privados ou pontos de extremidade de serviço combinados com um gateway de aplicações. Há dois motivos para usar um gateway de aplicação 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 entre várias instâncias das suas aplicações LOB.

Se nenhuma dessas necessidades se aplicar, é preferível usar endpoints privados. Com endpoints privados disponíveis no App Service, pode expor as suas aplicações em endereços privados na 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 expõe as suas aplicações em um endereço privado. Você precisa configurar o DNS para acessar esse endereço localmente. Para fazer essa configuração funcionar, encaminhe 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 App Service

Se você examinar 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. Aqui está a lista de portas expostas: