Como funciona o Gateway de Aplicativo do Azure
O Gateway de Aplicativo do Azure tem uma série de componentes que se combinam para rotear e balancear a carga com segurança as solicitações em um pool de servidores Web. O Application Gateway inclui os seguintes componentes:
- Endereço IP front-end: As solicitações do cliente são recebidas por meio de um endereço IP front-end. Você pode configurar o Application Gateway para ter um endereço IP público, um endereço IP privado ou ambos. O Application Gateway não pode ter mais de um endereço IP público e um endereço IP privado.
- Listeners: O Application Gateway usa um ou mais ouvintes para receber solicitações de entrada. Um ouvinte aceita o tráfego que chega em uma combinação especificada de protocolo, porta, host e endereço IP. Cada ouvinte roteia solicitações para um pool back-end de servidores seguindo as regras de roteamento especificadas por você. Um ouvinte pode ser Basic ou Multi-site. Um ouvinte do Basic apenas encaminha uma solicitação com base no caminho na URL. Um listener de vários sites também pode encaminhar solicitações usando o elemento nome de host da URL. Os ouvintes também lidam com certificados TLS/SSL para proteger seu aplicativo entre o usuário e o Application Gateway.
- Regras de roteamento: uma regra de roteamento vincula um ouvinte aos pools de back-end. Uma regra especifica como interpretar os elementos hostname e path na URL de uma solicitação e direcionar a solicitação para o pool de back-end apropriado. Uma regra de roteamento também tem um conjunto associado de configurações HTTP. Essas configurações HTTP indicam se (e como) o tráfego é criptografado entre o Application Gateway e os servidores back-end. Outras informações de configuração incluem protocolo, persistência de sessão, esvaziamento de conexão, tempo limite de solicitação e sondas de integridade.
Balanceamento de carga no Application Gateway
O Application Gateway equilibra automaticamente a carga das solicitações enviadas aos servidores em cada pool de back-end usando um mecanismo round-robin. O balanceamento de carga funciona com o roteamento OSI Layer 7 implementado pelo roteamento do Application Gateway, o que significa que ele balanceia a carga das solicitações com base nos parâmetros de roteamento (nomes de host e caminhos) usados pelas regras do Application Gateway. Em comparação, outros balanceadores de carga, como o Azure Load Balancer, funcionam no nível OSI Layer 4 e distribuem o tráfego com base no endereço IP do destino de uma solicitação.
Você pode configurar a aderência da sessão se precisar garantir que todas as solicitações para um cliente na mesma sessão sejam roteadas para o mesmo servidor em um pool de back-end.
Firewall de aplicativos Web
O firewall de aplicativo Web (WAF) é um componente opcional que lida com solicitações de entrada antes que elas cheguem a um ouvinte. O firewall do aplicativo Web verifica cada solicitação em busca de muitas ameaças comuns com base no Open Web Application Security Project (OWASP). As ameaças comuns incluem: injeção de SQL, scripts entre sites, injeção de comando, contrabando de solicitações HTTP, divisão de resposta HTTP, inclusão remota de arquivos, Bots, rastreadores e scanners e violações e anomalias do protocolo HTTP.
O OWASP define um conjunto de regras genéricas para detetar ataques. Essas regras são chamadas de Conjunto de Regras Básicas (CRS). Os conjuntos de regras estão sob revisão contínua à medida que os ataques evoluem em sofisticação. O WAF suporta quatro conjuntos de regras: CRS 3.2, 3.1, 3.0 e 2.2.9. CRS 3.1 é o padrão. Se necessário, você pode optar por selecionar apenas regras específicas em um conjunto de regras, visando determinadas ameaças. Além disso, você pode personalizar o firewall para especificar quais elementos em uma solicitação examinar e limitar o tamanho das mensagens para evitar que carregamentos massivos sobrecarreguem seus servidores.
Agrupamentos de back-end
Um pool de back-end é uma coleção de servidores Web que pode ser composta por: um conjunto fixo de máquinas virtuais, um conjunto de dimensionamento de máquina virtual, um aplicativo hospedado pelos Serviços de Aplicativo do Azure ou uma coleção de servidores locais.
Cada pool de back-end tem um balanceador de carga associado que distribui o trabalho pelo pool. Ao configurar o pool, você fornece o endereço IP ou o nome de cada servidor Web. Todos os servidores no pool de back-end devem ser configurados da mesma maneira, incluindo suas configurações de segurança.
Se você estiver usando TLS/SSL, o pool de back-end terá uma configuração HTTP que faz referência a um certificado usado para autenticar os servidores back-end. O gateway criptografa novamente o tráfego usando esse certificado antes de enviá-lo para um de seus servidores no pool de back-end.
Se você estiver usando o Serviço de Aplicativo do Azure para hospedar o aplicativo back-end, não precisará instalar nenhum certificado no Gateway de Aplicativo para se conectar ao pool de back-end. Todas as comunicações são automaticamente encriptadas. O Gateway de Aplicativo confia nos servidores porque o Azure os gerencia.
O Application Gateway usa uma regra para especificar como direcionar as mensagens que recebe em sua porta de entrada para os servidores no pool de back-end. Se os servidores estiverem usando TLS/SSL, você deverá configurar a regra para indicar:
- Que seus servidores esperam tráfego através do protocolo HTTPS.
- Qual certificado usar para criptografar o tráfego e autenticar a conexão com um servidor.
Roteamento do Application Gateway
Quando o gateway roteia uma solicitação de cliente para um servidor Web no pool de back-end, ele usa um conjunto de regras configuradas para o gateway para determinar para onde a solicitação deve ir. Há dois métodos principais de roteamento desse tráfego de solicitação de cliente: roteamento baseado em caminho e roteamento de vários sites.
Roteamento baseado em caminho
O roteamento baseado em caminho envia solicitações com caminhos de URL diferentes para diferentes pools de servidores back-end. Por exemplo, você pode direcionar solicitações com o caminho /video/* para um pool de back-end contendo servidores otimizados para lidar com streaming de vídeo e direcionar solicitações /images/* para um pool de servidores que lidam com a recuperação de imagens.
Roteamento em vários locais
O roteamento de vários sites configura mais de um aplicativo Web na mesma instância do Application Gateway. Em uma configuração multissite, você registra vários nomes DNS (CNAMEs) para o endereço IP do gateway de aplicativo, especificando o nome de cada site. O Application Gateway usa ouvintes separados para aguardar solicitações para cada site. Cada ouvinte passa a solicitação para uma regra diferente, que pode rotear as solicitações para servidores em um pool de back-end diferente. Por exemplo, você pode direcionar todas as solicitações de http://contoso.com para servidores em um pool de back-end e solicitações de http://fabrikam.com para outro pool de back-end. O diagrama a seguir mostra essa configuração:
As configurações multissite são úteis para dar suporte a aplicativos multilocatário, onde cada locatário tem seu próprio conjunto de máquinas virtuais ou outros recursos que hospedam um aplicativo Web.
O roteamento do Application Gateway também inclui esses recursos:
- Redirecionamento. O redirecionamento pode ser usado para outro site ou de HTTP para HTTPS.
- Reescreva cabeçalhos HTTP. Os cabeçalhos HTTP permitem que o cliente e o servidor passem informações de parâmetros com a solicitação ou a resposta.
- Páginas de erro personalizadas. O Application Gateway permite que você crie páginas de erro personalizadas em vez de exibir páginas de erro padrão. Você pode usar sua própria marca e layout usando uma página de erro personalizada.
Encerramento TLS/SSL
Quando você encerra a conexão TLS/SSL no gateway de aplicativo, ela descarrega a carga de trabalho de terminação TLS/SSL com uso intensivo de CPU de seus servidores. Além disso, você não precisa instalar certificados e configurar TLS/SSL em seus servidores.
Se você precisar de criptografia de ponta a ponta, o Application Gateway poderá descriptografar o tráfego no gateway usando sua chave privada e, em seguida, criptografar novamente com a chave pública do serviço em execução no pool de back-end.
O tráfego entra no gateway através de uma porta de entrada. Você pode abrir muitas portas e o Application Gateway pode receber mensagens em qualquer uma dessas portas. Um ouvinte é a primeira coisa que o seu tráfego encontra ao entrar no gateway através de uma porta. O ouvinte está configurado para ouvir um nome de host específico e uma porta específica em um endereço IP específico. O ouvinte pode usar um certificado TLS/SSL para descriptografar o tráfego que entra no gateway. Em seguida, o ouvinte usa uma regra que você define para direcionar os pedidos recebidos para um pool de back-end.
Expor seu site ou aplicativo Web por meio do gateway de aplicativo também significa que você não conecta diretamente seus servidores à Web. Você está expondo apenas a porta 80 ou a porta 443 no gateway de aplicativo, que é encaminhado para o servidor de pool de back-end. Nesta configuração, os seus servidores Web não são diretamente acessíveis a partir da Internet, o que reduz a superfície de ataque da sua infraestrutura.
Sondas de saúde
As verificações de integridade determinam quais servidores estão disponíveis para o balanceamento de carga num pool de servidores de back-end. O Application Gateway usa uma investigação de integridade para enviar uma solicitação a um servidor. Quando o servidor retorna uma resposta HTTP com um código de status entre 200 e 399, o servidor é considerado íntegro. Se não configurares uma sonda de integridade, o Application Gateway criará uma sonda padrão que aguardará 30 segundos antes de decidir que um servidor não está disponível. As sondas de saúde garantem que o tráfego não seja direcionado para um ponto de extremidade da Web que esteja inativo ou com problemas no conjunto de back-end.
Dimensionamento automático
O Application Gateway oferece suporte ao dimensionamento automático e pode ser dimensionado para cima ou para baixo com base na alteração dos padrões de carga de tráfego. O dimensionamento automático também elimina a necessidade de escolher um tamanho de implantação ou contagem de instâncias durante o provisionamento.
Tráfego WebSocket e HTTP/2
O Application Gateway fornece suporte nativo para os protocolos WebSocket e HTTP/2. Os protocolos WebSocket e HTTP/2 permitem a comunicação full duplex entre um servidor e um cliente através de uma ligação TCP de longa duração. Este tipo de comunicação é mais interativo entre o servidor web e o cliente, e pode ser bidirecional sem a necessidade de sondagem, conforme exigido em implementações baseadas em HTTP. Esses protocolos têm baixa sobrecarga (ao contrário do HTTP) e podem reutilizar a mesma conexão TCP para várias solicitações/respostas, resultando em uma utilização de recursos mais eficiente. Esses protocolos são projetados para funcionar em portas HTTP tradicionais de 80 e 443.