Configurar os componentes do Gateway de Aplicativo do Azure
Um Gateway de Aplicativo do Azure do pool de back-end tem uma série de componentes que se combinam a fim de rotear solicitações para um pool de servidores Web e verificar a integridade deles. Esses componentes incluem o endereço IP de front-end, pools de back-end, regras de roteamento, investigações de integridade e ouvintes. Opcionalmente, o gateway também pode implementar um firewall.
O que você deve saber sobre os componentes do Gateway de Aplicativo
Vamos explorar como os componentes de um gateway de aplicativo funcionam juntos.
O endereço IP de front-end recebe as solicitações do cliente.
Um Firewall de Aplicativo Web opcional verifica o tráfego de entrada em busca de ameaças comuns antes que as solicitações cheguem aos ouvintes.
Um ou mais ouvintes recebem o tráfego e roteiam as solicitações para o pool de back-end.
As regras de roteamento definem como analisar a solicitação para direcionar a solicitação ao pool de back-end apropriado.
Um pool de back-end contém servidores Web para recursos como máquinas virtuais ou Conjuntos de Dimensionamento de Máquinas Virtuais. Cada pool tem um balanceador para distribuir a carga de trabalho entre os recursos.
As investigações de integridade determinam quais servidores de pool de back-end estão disponíveis para balanceamento de carga.
O fluxograma a seguir demonstra como os componentes do Gateway de Aplicativo funcionam juntos para direcionar as solicitações de tráfego entre os pools de front-end e back-end em sua configuração.
Endereço IP de front-end
As solicitações do cliente são recebidas por meio do seu endereço IP de front-end. Seu gateway de aplicativo pode ter um endereço IP público, privado, ou ambos. Você pode ter apenas um endereço IP público e apenas um endereço IP privado.
Firewall de Aplicativo Web (opcional)
Você pode habilitar o Firewall do Aplicativo Web do Azure para o Gateway de Aplicativo do Azure a fim de lidar com as solicitações recebidas antes que elas cheguem ao seu ouvinte. O firewall verifica cada solicitação de ameaças com base no OWASP (Open Web Application Security Project). Ameaças comuns incluem injeção de SQL, script entre sites, injeção de comando, contrabando de solicitação HTTP e divisão de resposta e inclusão remota de arquivo. Outras ameaças podem vir de bots, rastreadores, scanners, violações e anomalias do protocolo HTTP.
O OWASP define um conjunto de regras genéricas para detecção de ataques. Essas regras são conhecidas como CRS (Conjunto de regras principal). Os conjuntos de regras estão sob avaliação contínua, conforme a sofisticação dos ataques aumenta. O firewall do aplicativo Web do Azure dá suporte a dois conjuntos de regras: CRS 2.2.9 e CRS 3.0. O CRS 3.0 é o padrão e é o mais recente desses conjuntos de regras. Se necessário, você pode optar por selecionar apenas regras específicas em um conjunto de regras para direcionar determinadas ameaças. Além disso, você pode personalizar o firewall para especificar quais elementos de uma solicitação devem ser examinados e limitar o tamanho de mensagens para evitar que uploads enormes sobrecarreguem os servidores.
Ouvintes
Os ouvintes aceitam 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 de back-end de servidores de acordo com suas regras de roteamento. Um ouvinte pode ser Básico ou Multissite. Um ouvinte Básico apenas roteia uma solicitação com base no caminho na URL. Um ouvinte de vários sites também pode rotear solicitações usando o elemento nome do host da URL. Os ouvintes também lidam com certificados TLS/SSL para proteger um aplicativo entre o usuário e o Gateway de Aplicativo.
Regras de roteamento
Uma regra de roteamento vincula seus ouvintes aos pools de back-end. Uma regra especifica como interpretar o nome do host e os elementos do caminho na URL de uma solicitação, depois direciona a solicitação para o pool de back-end apropriado. Uma regra de roteamento também tem um conjunto associado de configurações de HTTP. Essas configurações HTTP indicam se (e como) o tráfego é criptografado entre o Gateway de Aplicativo e os servidores de back-end. Outras informações de configuração incluem: protocolo, adesão da sessão, esvaziamento de conexões, período de tempo limite da solicitação e investigações de integridade.
Pools de back-end
Um pool de back-end faz referência a uma coleção de servidores Web. Você fornece o endereço IP de cada servidor Web e a porta na qual ele escuta solicitações ao configurar o pool. Cada pool pode especificar um conjunto fixo de máquinas virtuais, Conjuntos de Dimensionamento de Máquinas Virtuais, um aplicativo hospedado pelos Serviço 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.
Investigações de integridade
As investigações de integridade determinam quais servidores em seu pool de back-end estão disponíveis para balanceamento de carga. O Gateway de Aplicativo usa uma investigação de integridade para enviar uma solicitação para um servidor. O servidor é considerado íntegro quando ele retorna uma resposta HTTP com um código de status entre 200 e 399. Se você não configurar uma investigação de integridade, o Gateway de Aplicativo criará uma investigação padrão que aguardará 30 segundos antes de identificar um servidor como indisponível (não íntegro).