Serviço de Aplicações funcionalidades de rede

Pode implementar aplicações em Serviço de Aplicações do Azure de várias formas. Por predefinição, as aplicações alojadas em Serviço de Aplicações são acessíveis diretamente através da Internet e só podem chegar a pontos finais alojados na Internet. Contudo, para muitas aplicações, tem de controlar o tráfego de rede de entrada e saída. Existem várias funcionalidades no Serviço de Aplicações para o ajudar a satisfazer essas necessidades. O desafio é saber que funcionalidade utilizar para resolver um determinado problema. Este artigo irá ajudá-lo a determinar que funcionalidade utilizar, com base em alguns casos de utilização de exemplo.

Existem dois tipos de implementação principais para Serviço de Aplicações do Azure:

• O serviço público multi-inquilino aloja Serviço de Aplicações planos nos SKUs de preços Gratuito, Partilhado, Básico, Standard, Premium, PremiumV2 e PremiumV3.
• O Ambiente do Serviço de Aplicações de inquilino único (ASE) aloja planos de Serviço de Aplicações SKU isolados diretamente na sua rede virtual do Azure.

As funcionalidades que utilizar dependerão se estiver no serviço multi-inquilino ou num ASE.

Nota

As funcionalidades de rede não estão disponíveis para aplicações implementadas no Azure Arc.

Funcionalidades de rede de Serviço de Aplicações multi-inquilinos

Serviço de Aplicações do Azure é um sistema distribuído. As funções que lidam com pedidos HTTP ou HTTPS recebidos são denominadas front-ends. As funções que alojam a carga de trabalho do cliente chamam-se trabalhadores. Todas as funções numa implementação Serviço de Aplicações existem numa rede multi-inquilino. Uma vez que existem muitos clientes diferentes na mesma unidade de escala Serviço de Aplicações, não pode ligar a rede Serviço de Aplicações diretamente à sua rede.

Em vez de ligar as redes, precisa de funcionalidades para lidar com os vários aspetos da comunicação da aplicação. As funcionalidades que processam pedidos para a sua aplicação não podem ser utilizadas para resolver problemas quando faz chamadas a partir da sua aplicação. Da mesma forma, as funcionalidades que resolvem problemas de chamadas da sua aplicação não podem ser utilizadas para resolver problemas na sua aplicação.

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

Além das exceções anotas, pode utilizar todas estas funcionalidades em conjunto. Pode misturar as funcionalidades para resolver os problemas.

Casos e funcionalidades de utilização

Para qualquer caso de utilização, pode haver algumas formas de resolver o problema. Escolher a melhor funcionalidade, por vezes, vai além do próprio caso de utilização. Os seguintes casos de utilização de entrada sugerem como utilizar Serviço de Aplicações funcionalidades de rede para resolver problemas com o controlo do tráfego que vai para a sua aplicação:

Caso de utilização de entrada	Funcionalidade
Suportar necessidades de SSL baseadas em IP para a sua aplicação	Endereço atribuído à aplicação
Suporte para endereços de entrada dedicados não partilhados para a sua aplicação	Endereço atribuído à aplicação
Restringir o acesso à sua aplicação a partir de um conjunto de endereços bem definidos	Restrições de acesso
Restringir o acesso à sua aplicação a partir de recursos numa rede virtual	Pontos finais de serviço Pontos finais Internos Balanceador de Carga (ILB) Pontos finais privados do ASE
Expor a sua aplicação num IP privado na sua rede virtual	ILB ASE Private endpoints Private IP for inbound traffic on an Gateway de Aplicação instance with service endpoints
Proteger a sua aplicação com uma firewall de aplicações Web (WAF)	Gateway de Aplicação e ILB ASE Gateway de Aplicação com pontos finais privados Gateway de Aplicação com pontos finais de serviço do Azure Front Door com restrições de acesso
Balanceamento de carga do tráfego para as suas aplicações em diferentes regiões	Azure Front Door com restrições de acesso
Tráfego de balanceamento de carga na mesma região	Gateway de Aplicação com pontos finais de serviço

Os seguintes casos de utilização de saída sugerem como utilizar Serviço de Aplicações funcionalidades de rede para resolver as necessidades de acesso de saída para a sua aplicação:

Caso de utilização de saída	Funcionalidade
Aceder a recursos numa rede virtual do Azure na mesma região	Integração de rede virtual ASE
Aceder a recursos numa rede virtual do Azure numa região diferente	integração de rede virtual e peering de rede virtual Integração de rede virtual necessária do Gateway ASE e peering de rede virtual
Aceder a recursos protegidos com pontos finais de serviço	integração da rede virtual ASE
Aceder a recursos numa rede privada que não esteja ligada ao Azure	Ligações Híbridas
Aceder a recursos em circuitos do Azure ExpressRoute	integração da rede virtual ASE
Proteger o tráfego de saída 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 a partir da sua aplicação Web	integração de rede virtual e tabelas de rotas ASE

Comportamento de rede predefinido

Serviço de Aplicações do Azure unidades de dimensionamento suportam muitos clientes em cada implementação. Os planos de SKU Gratuito e Partilhado alojam cargas de trabalho de clientes em trabalhadores multi-inquilinos. Os planos básicos e superiores alojam cargas de trabalho de clientes dedicadas apenas a um plano Serviço de Aplicações. Se tiver um plano de Serviço de Aplicações Standard, todas as aplicações nesse plano serão executadas na mesma função de trabalho. Se aumentar horizontalmente a função de trabalho, todas as aplicações nesse plano de Serviço de Aplicações serão replicadas numa nova função de trabalho para cada instância no seu plano de Serviço de Aplicações.

Endereços de saída

As VMs de trabalho são divididas em grande parte pelos planos de Serviço de Aplicações. Os planos Gratuito, Partilhado, Básico, Standard e Premium utilizam o mesmo tipo de VM de trabalho. O plano PremiumV2 utiliza outro tipo de VM. O PremiumV3 utiliza mais um tipo de VM. Quando altera a família de VMs, obtém um conjunto diferente de endereços de saída. Se dimensionar de Standard para PremiumV2, os seus endereços de saída serão alterados. Se dimensionar de PremiumV2 para PremiumV3, os 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 dimensionar de Standard para PremiumV2.

Existem muitos endereços que são utilizados para chamadas de saída. Os endereços de saída utilizados pela sua aplicação para efetuar chamadas de saída estão listados nas propriedades da sua aplicação. Estes endereços são partilhados por todas as aplicações em execução na mesma família de VMs de trabalho na implementação Serviço de Aplicações. Se quiser ver todos os endereços que a sua aplicação pode utilizar numa unidade de dimensionamento, existe uma propriedade denominada possibleOutboundAddresses que os irá listar.

Serviço de Aplicações tem muitos pontos finais que são utilizados para gerir o serviço. Esses endereços são publicados num documento separado e também estão na etiqueta de AppServiceManagement serviço IP. A AppServiceManagement etiqueta é utilizada apenas em Ambientes de Serviço de Aplicações onde precisa de permitir esse tráfego. Os Serviço de Aplicações endereços de entrada são monitorizados na etiqueta do AppService serviço IP. Não existe nenhuma etiqueta de serviço IP que contenha os endereços de saída utilizados pelo Serviço de Aplicações.

Endereço atribuído pela aplicação

A funcionalidade de endereço atribuído pela aplicação é uma resolução da capacidade SSL baseada em IP. Pode aceder ao mesmo ao configurar o SSL com a sua aplicação. Pode utilizar esta funcionalidade para chamadas SSL baseadas em IP. Também pode utilizá-la para fornecer à sua aplicação um endereço que apenas tenha.

Quando utiliza um endereço atribuído pela aplicação, o tráfego continua a passar pelas mesmas funções de front-end que processam todo o tráfego de entrada na unidade de escala Serviço de Aplicações. Mas o endereço atribuído à sua aplicação é utilizado apenas pela sua aplicação. Casos de utilização para esta funcionalidade:

• Suporte para as necessidades de SSL baseadas em IP para a sua aplicação.
• Defina um endereço dedicado para a sua aplicação que não seja partilhado.

Para saber como definir um endereço na sua aplicação, veja Adicionar um certificado TLS/SSL no Serviço de Aplicações 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 de front-end que estão a montante a partir das funções de trabalho onde as suas aplicações estão a ser executadas. Uma vez que as funções de front-end estão a montante dos trabalhadores, pode considerar as restrições de acesso como proteção ao nível da rede para as suas aplicações. Para obter mais informações sobre restrições de acesso, veja Descrição geral das restrições de acesso.

Esta funcionalidade permite-lhe criar uma lista de regras de permissão e negação que são avaliadas por ordem de prioridade. É semelhante à funcionalidade do grupo de segurança de rede (NSG) na rede do Azure. Pode utilizar esta funcionalidade num ASE ou no serviço multi-inquilino. Ao utilizá-lo com um ASE de ILB, pode restringir o acesso a partir de blocos de endereços privados. Para saber como ativar esta funcionalidade, veja Configurar restrições de acesso.

Nota

Pode configurar até 512 regras de restrição de acesso por aplicação.

Ponto final privado

O ponto final privado é uma interface de rede que o liga de forma privada e segura à sua Aplicação Web através da ligação privada do Azure. O ponto final privado utiliza um endereço IP privado da sua rede virtual, colocando efetivamente a aplicação Web na sua rede virtual. Esta funcionalidade destina-se apenas a fluxos de entrada para a sua aplicação Web. Para obter mais informações, veja Utilizar pontos finais privados para a Aplicação Web do Azure.

Alguns casos de utilização desta funcionalidade:

• Restringir o acesso à sua aplicação a partir de recursos numa rede virtual.
• Exponha a sua aplicação num IP privado na sua rede virtual.
• Proteja a sua aplicação com uma WAF.

Os pontos finais privados impedem a exfiltração de dados porque a única coisa que pode alcançar através do ponto final privado é a aplicação com a qual está configurada.

Ligações Híbridas

Serviço de Aplicações Ligações Híbridas permite que as suas aplicações façam chamadas de saída para pontos finais TCP especificados. O ponto final pode ser no local, numa rede virtual ou em qualquer lugar que permita o tráfego de saída para o Azure na porta 443. Para utilizar a funcionalidade, tem de instalar um agente de reencaminhamento chamado Gestor de Ligações Híbridas num anfitrião Windows Server 2012 ou mais recente. Gestor de Ligações Híbridas tem de conseguir aceder ao Reencaminhamento do Azure na porta 443. Pode transferir Gestor de Ligações Híbridas a partir da IU das Ligações Híbridas do Serviço de Aplicações no portal.

Serviço de Aplicações As Ligações Híbridas são criadas com base na capacidade de Ligações Híbridas do Azure Relay. Serviço de Aplicações utiliza uma forma especializada da funcionalidade que só suporta efetuar chamadas de saída da sua aplicação para um anfitrião E porta TCP. Este anfitrião e porta só precisam de ser resolvidos no anfitrião onde Gestor de Ligações Híbridas está instalada.

Quando a aplicação, no Serviço de Aplicações, faz uma pesquisa DNS no anfitrião e na porta definidas na sua ligação híbrida, o tráfego redireciona automaticamente para passar pela ligação híbrida e fora do Gestor de Ligações Híbridas. Para saber mais, veja Serviço de Aplicações Ligações Híbridas.

Esta funcionalidade é frequentemente utilizada para:

• Aceder a recursos em redes privadas que não estão ligadas ao Azure com uma VPN ou ExpressRoute.
• Suporte a migração de aplicações no local para Serviço de Aplicações sem a necessidade de mover bases de dados de suporte.
• Forneça acesso com segurança melhorada a um único anfitrião e porta por ligação híbrida. A maioria das funcionalidades de rede abre o acesso a uma rede. Com as Ligações Híbridas, só pode aceder ao único anfitrião e porta.
• Abrange cenários não abrangidos por outros métodos de conectividade de saída.
• Realize o desenvolvimento no Serviço de Aplicações de uma forma que permita que as aplicações utilizem facilmente recursos no local.

Uma vez que esta funcionalidade permite o acesso a recursos no local sem um buraco de firewall de entrada, é popular entre os programadores. As outras funcionalidades de rede Serviço de Aplicações de saída estão relacionadas com o Azure Rede Virtual. As Ligações Híbridas não dependem de passar por uma rede virtual. Pode ser utilizado para uma maior variedade de necessidades de rede.

Serviço de Aplicações As Ligações Híbridas desconhecem o que está a fazer. Assim, pode utilizá-la para aceder a uma base de dados, a um serviço Web ou a um socket TCP arbitrário num mainframe. A funcionalidade essencialmente túne os pacotes TCP.

As Ligações Híbridas são populares para desenvolvimento, mas também são utilizadas em aplicações de produção. É ótimo para aceder a um serviço Web ou base de dados, mas não é adequado para situações que envolvam a criação de muitas ligações.

Integração da rede virtual

Serviço de Aplicações integração de rede virtual permite que a sua aplicação faça pedidos de saída numa rede virtual do Azure.

A funcionalidade de integração da rede virtual permite-lhe colocar o back-end da sua aplicação numa sub-rede numa rede virtual Resource Manager. A rede virtual tem de estar na mesma região que a sua aplicação. Esta funcionalidade não está disponível a partir de um Ambiente do Serviço de Aplicações, que já se encontra numa rede virtual. Casos de utilização para esta funcionalidade:

• Aceder a recursos no Resource Manager redes virtuais na mesma região.
• Aceder a recursos em redes virtuais em modo de peering, incluindo ligações entre regiões.
• Aceder a recursos protegidos com pontos finais de serviço.
• Aceder a recursos acessíveis em ligações ExpressRoute ou VPN.
• Aceder a recursos em redes privadas sem a necessidade e o custo de um gateway de Rede Virtual.
• Ajuda para proteger todo o tráfego de saída.
• Forçar o túnel de todo o tráfego de saída.

Para saber mais, veja Serviço de Aplicações integração de rede virtual.

Integração de rede virtual necessária para o gateway

A integração da rede virtual necessária ao gateway foi a primeira edição da integração da rede virtual no Serviço de Aplicações. A funcionalidade funciona ao ligar o anfitrião no qual a sua aplicação está a ser executada num gateway de Rede Virtual na sua rede virtual através de uma VPN ponto a site. Quando configura a funcionalidade, a sua aplicação 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-lhe ligar diretamente a uma rede virtual noutra região sem peering e ligar a uma rede virtual clássica. A funcionalidade está limitada a Serviço de Aplicações planos do Windows e não funciona com redes virtuais ligadas ao ExpressRoute. Recomenda-se a utilização da integração da rede virtual regional. Para obter mais informações sobre esta funcionalidade, veja Serviço de Aplicações integração de rede virtual.

Ambiente do Serviço de Aplicações

Uma Ambiente do Serviço de Aplicações (ASE) é uma implementação de inquilino único do Serviço de Aplicações do Azure que é executada na sua rede virtual. Alguns casos deste tipo para esta funcionalidade:

• Aceder a recursos na sua rede virtual.
• Aceder a recursos no ExpressRoute.
• Exponha as suas aplicações com um endereço privado na sua rede virtual.
• Aceder a recursos entre pontos finais de serviço.
• Aceder a recursos em pontos finais privados.

Com um ASE, não precisa de utilizar a integração de rede virtual porque o ASE já se encontra na sua rede virtual. Se quiser aceder a recursos como o SQL ou o Armazenamento do Azure através de pontos finais de serviço, ative os pontos finais de serviço na sub-rede do ASE. Se quiser aceder a recursos na rede virtual ou pontos finais privados na rede virtual, não precisa de efetuar qualquer configuração adicional. Se quiser aceder aos recursos através do ExpressRoute, já se encontra na rede virtual e não precisa de configurar nada no ASE ou nas aplicações na mesma.

Uma vez que as aplicações num ASE de ILB podem ser expostas num endereço IP privado, pode adicionar facilmente dispositivos WAF para expor apenas as aplicações que pretende para a Internet e ajudar a manter o resto seguro. Esta funcionalidade pode ajudar a facilitar o desenvolvimento de aplicações de várias camadas.

Atualmente, algumas coisas não são possíveis a partir do serviço multi-inquilino, mas são possíveis a partir de um ASE. Eis alguns exemplos:

• Alojar as suas aplicações num serviço de inquilino único.
• Aumente verticalmente para muitas mais instâncias do que as possíveis no serviço multi-inquilino.
• Carregue certificados de cliente de AC privada para utilização pelas suas aplicações com pontos finais privados protegidos por AC.
• Force o TLS 1.2 em todas as aplicações alojadas no sistema sem qualquer capacidade de o desativar ao nível da aplicação.

O ASE fornece a melhor história em torno do alojamento de aplicações isoladas e dedicadas, mas envolve alguns desafios de gestão. Alguns aspetos a considerar antes de utilizar um ASE operacional:

• Um ASE é executado dentro da rede virtual, mas tem dependências fora da rede virtual. Essas dependências têm de ser permitidas. Para obter mais informações, veja Considerações de rede para um Ambiente do Serviço de Aplicações.
• Um ASE não dimensiona imediatamente como o serviço multi-inquilino. Tem de antecipar as necessidades de dimensionamento em vez de dimensionar reativamente.
• Um ASE tem um custo adiantado mais elevado. Para tirar o máximo partido do ASE, deve planear colocar muitas cargas de trabalho num ASE em vez de utilizá-lo para pequenos esforços.
• As aplicações num ASE não podem restringir seletivamente o acesso a algumas aplicações no ASE e não a outras.
• Um ASE está numa sub-rede e quaisquer regras de rede aplicam-se a todo o tráfego de e para esse ASE. Se quiser atribuir regras de tráfego de entrada para apenas uma aplicação, utilize restrições de acesso.

Combinar funcionalidades

As funcionalidades indicadas para o serviço multi-inquilino podem ser utilizadas em conjunto para resolver casos de utilização mais elaborados. Dois dos casos de utilização mais comuns são descritos aqui, mas são apenas exemplos. Ao compreender o que as várias funcionalidades fazem, pode satisfazer quase todas as suas necessidades de arquitetura do sistema.

Colocar uma aplicação numa rede virtual

Poderá perguntar-se como colocar uma aplicação numa rede virtual. Se colocar a aplicação numa rede virtual, os pontos finais de entrada e saída da aplicação estão na rede virtual. Um ASE é a melhor forma de resolver este problema. Mas pode satisfazer a maioria das suas necessidades no serviço multi-inquilino ao combinar funcionalidades. Por exemplo, pode alojar aplicações apenas na intranet com endereços de entrada e saída privados ao:

• Criar um gateway de aplicação com endereços de entrada e saída privados.
• Proteger o tráfego de entrada para a sua aplicação com pontos finais de serviço.
• Utilizar a funcionalidade de integração da rede virtual para que o back-end da sua aplicação esteja na sua rede virtual.

Este estilo de implementação não lhe dará 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 da sua aplicação. Dar-lhe-á muito do que só obteria de outra forma com um ASE.

Criar aplicações de várias camadas

Uma aplicação de várias camadas é uma aplicação na qual as aplicações de back-end da API só podem ser acedidas a partir da camada de front-end. Existem duas formas de criar uma aplicação de várias camadas. Ambos começam por utilizar a integração de rede virtual para ligar a sua aplicação Web de front-end a uma sub-rede numa rede virtual. Ao fazê-lo, a sua aplicação Web irá efetuar chamadas para a sua rede virtual. Depois de a aplicação de front-end estar ligada à rede virtual, tem de decidir como bloquear o acesso à sua aplicação de API. Pode:

• Aloje o front-end e a aplicação API no mesmo ASE de ILB e exponha a aplicação de front-end à Internet através de um gateway de aplicação.
• Aloje o front-end no serviço multi-inquilino e o back-end num ASE de ILB.
• Alojar o front-end e a aplicação API no serviço multi-inquilino.

Se estiver a alojar o front-end e a aplicação API para uma aplicação de várias camadas, pode:

• Exponha a sua aplicação de API com pontos finais privados na sua rede virtual:

  

• Utilize pontos finais de serviço para garantir que o tráfego de entrada para a sua aplicação API provém apenas da sub-rede utilizada pela sua aplicação Web de front-end:

  

Seguem-se algumas considerações para o ajudar a decidir qual o método a utilizar:

• Quando utiliza pontos finais de serviço, só precisa de proteger o tráfego para a sua aplicação API para a sub-rede de integração. Os pontos finais de serviço ajudam a proteger a aplicação API, mas ainda pode ter a transferência de dados exfiltração da sua aplicação de front-end para outras aplicações no serviço de aplicações.
• Quando utiliza pontos finais privados, tem duas sub-redes em jogo, o que adiciona complexidade. Além disso, o ponto final privado é um recurso de nível superior e adiciona uma sobrecarga de gestão. A vantagem de utilizar pontos finais privados é que não tem a possibilidade de transferência de dados não autorizada.

Qualquer um dos métodos funcionará com vários front-ends. Em pequena escala, os pontos finais de serviço são mais fáceis de utilizar porque basta ativar pontos finais de serviço para a aplicação API na sub-rede de integração de front-end. À medida que adiciona mais aplicações de front-end, tem de ajustar todas as aplicações API para incluir pontos finais de serviço com a sub-rede de integração. Quando utiliza pontos finais privados, existe mais complexidade, mas não tem de alterar nada nas suas aplicações de API depois de definir um ponto final privado.

Aplicações de linha de negócio

As aplicações de linha de negócio (LOB) são aplicações internas que normalmente não são expostas para acesso a partir da Internet. Estas aplicações são chamadas a partir de redes empresariais onde o acesso pode ser estritamente controlado. Se utilizar um ASE de ILB, é fácil alojar as suas aplicações de linha de negócio. Se utilizar o serviço multi-inquilino, pode utilizar pontos finais privados ou utilizar pontos finais de serviço combinados com um gateway de aplicação. Existem dois motivos para utilizar um gateway de aplicação com pontos finais de serviço em vez de utilizar pontos finais privados:

• Precisa de proteção WAF nas suas aplicações LOB.
• Quer fazer o balanceamento de carga para várias instâncias das suas aplicações LOB.

Se nenhuma destas necessidades se aplicar, é melhor utilizar pontos finais privados. Com os pontos finais privados disponíveis no Serviço de Aplicações, pode expor as suas aplicações em endereços privados na sua rede virtual. O ponto final privado que coloca na sua rede virtual pode ser alcançado nas ligações expressRoute e VPN.

A configuração de pontos finais privados irá expor as suas aplicações num endereço privado, mas terá de configurar o DNS para aceder a esse endereço a partir do local. Para que esta configuração funcione, terá de reencaminhar a zona privada do DNS do Azure que contém os pontos finais privados para os servidores DNS no local. As zonas privadas do DNS do Azure não suportam o reencaminhamento de zonas, mas pode suportar o reencaminhamento de zonas com a resolução privada do DNS do Azure.

portas de Serviço de Aplicações

Se analisar Serviço de Aplicações, encontrará várias portas expostas para ligações de entrada. Não é possível bloquear ou controlar o acesso a estas portas no serviço multi-inquilino. Eis a lista de portas expostas:

Utilização	Porta ou portas
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 Web Deploy	8172
Utilização da infraestrutura	7654, 1221