Como o Gateway de Aplicativo do Azure funciona
O Gateway de Aplicativo do Azure tem uma série de componentes que se combinam a fim de rotear de modo seguro e balancear a carga de solicitações para um pool de servidores Web. O Gateway de Aplicativo inclui os seguintes componentes:
- Endereço IP de front-end: as solicitações do cliente são recebidas por meio de um endereço IP de front-end. Você pode configurar o Gateway de Aplicativo para ter um endereço IP público, um endereço IP privado ou ambos. O Gateway de Aplicativo não pode ter mais de um endereço IP público e um endereço IP privado.
- Ouvintes: o Gateway de Aplicativo usa um ou mais ouvintes para receber as 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 de back-end de servidores, seguindo as regras de roteamento especificadas. Um ouvinte pode ser Básico ou Multissite. Um ouvinte Básico só roteia uma solicitação com base no caminho na URL. Um ouvinte Multissite também pode rotear as solicitações usando o elemento de nome de 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 associa um ouvinte aos pools de back-end. Uma regra especifica como interpretar os elementos de nome de host e caminho na URL de uma solicitação e como direcionar 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.
Balanceamento de carga no Gateway de Aplicativo
O Gateway de Aplicativo fará automaticamente o balanceamento de carga das solicitações enviadas para os servidores em cada pool de back-end usando um mecanismo de round robin. O balanceamento de carga funciona com o roteamento de OSI de Camada 7 implementado pelo roteamento do Gateway de Aplicativo, o que significa que ele faz o balanceamento de carga das solicitações de acordo com os parâmetros de roteamento (caminhos e nomes de host) usados pelas regras do Gateway de Aplicativo. Em comparação, outros balanceadores de carga, como o Azure Load Balancer, funcionam no nível do OSI de Camada 4 e distribuem o tráfego com base no endereço IP do destino de uma solicitação.
Você poderá configurar a adesão da sessão se precisar garantir que todas as solicitações de um cliente na mesma sessão sejam roteadas para o mesmo servidor em um pool de back-end.
Firewall do aplicativo Web
O WAF (firewall do aplicativo Web) é um componente opcional que manipula as solicitações de entrada antes que elas cheguem ao ouvinte. O firewall do aplicativo Web verifica cada solicitação para ver se há ameaças comuns, com base no OWASP (Open Web Application Security Project). As ameaças comuns incluem: injeção de SQL, cross-site scripting, injeção de comando, solicitação HTTP indesejada, separação de respostas HTTP, inclusão de arquivo remoto, bots, rastreadores e scanners, bem como violações e anomalias de 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 WAF dá suporte a quatro conjuntos de regras: CRS 3.2, 3.1, 3.0 e 2.2.9. O CRS 3.1 é o padrão. Se necessário, você pode optar por selecionar apenas regras específicas de um conjunto de regras, tendo em vista ameaças específicas. 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.
Pools de back-end
Um pool de back-end é uma coleção de servidores Web que pode ser composto 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 forma, incluindo as configurações de segurança.
Se você estiver usando TLS/SSL, o pool de back-end terá uma configuração de HTTP que referencia um certificado usado para autenticar os servidores de back-end. O gateway criptografa novamente o tráfego usando esse certificado antes de enviá-lo para um dos servidores no pool de back-end.
Se você estiver usando o Serviço de Aplicativo do Azure para hospedar o aplicativo de 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 criptografadas automaticamente. O Gateway de Aplicativo confia nos servidores porque o Azure os gerencia.
O Gateway de Aplicativo usa uma regra para especificar como direcionar as mensagens que ele recebe na 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 os seus servidores esperam tráfego por meio do protocolo HTTPS.
- Que certificado usar para criptografar o tráfego e autenticar a conexão a um servidor.
O roteamento do Gateway de Aplicativo
Quando o gateway roteia uma solicitação de cliente para um servidor Web no pool de back-end, ele usa um conjunto de regras configurado para o gateway para determinar para onde a solicitação deve ir. Há dois métodos principais para rotear o tráfego dessa 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 diferentes caminhos de URL para diversos pools de servidores de back-end. Por exemplo, é possível direcionar solicitações com o caminho /video/* para um pool de back-end contendo servidores otimizados para lidar com um streaming de vídeo, bem como direcionar solicitações de /images/* para um pool de servidores que lidam com a recuperação de imagem.
Roteamento de vários sites
O roteamento de vários sites configura mais de um aplicativo Web na mesma instância do Gateway de Aplicativo. Em uma configuração com vários sites, você pode registrar vários nomes DNS (CNAMEs) para o endereço IP do gateway de aplicativo, especificando o nome de cada site. O Gateway de Aplicativo usa ouvintes separados para aguardar solicitações para cada site. Cada ouvinte transmite a solicitação para uma regra diferente, o que pode rotear as solicitações para servidores em um pool de back-end diferente. Por exemplo, é possível 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 seguinte diagrama mostra essa configuração:
As configurações de vários sites são úteis para dar suporte a aplicativos multilocatário, em que cada locatário tem o próprio conjunto de máquinas virtuais ou outros recursos que hospedam um aplicativo Web.
O roteamento do Gateway de Aplicativo também inclui estes recursos:
- Redirecionamento. O redirecionamento pode ser usado em outro site ou de HTTP para HTTPS.
- Reescrever cabeçalhos HTTP. Os cabeçalhos HTTP permitem que o cliente e o servidor enviem informações de parâmetros com a solicitação ou a resposta.
- Páginas de erro personalizadas. O Gateway de Aplicativo 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 identidade visual e layout em uma página de erro personalizada.
Terminação TLS/SSL
Quando você encerra a conexão TLS/SSL no gateway de aplicativo, ele descarrega de seus servidores a carga de trabalho de terminação TLS/SSL que faz uso intenso de CPU. Além disso, você não precisa instalar certificados nem configurar TLS/SSL em seus servidores.
Se você precisar obter a criptografia de ponta a ponta, o Gateway de Aplicativo poderá descriptografar o tráfego no gateway usando sua chave privada e criptografá-lo novamente com a chave pública do serviço em execução no pool de back-end.
O tráfego entra no gateway por uma porta de front-end. Você pode abrir várias portas e o Gateway de Aplicativo pode receber mensagens em qualquer uma delas. Um ouvinte é o primeiro elemento que seu tráfego encontra ao entrar no gateway por uma porta. O ouvinte é configurado para escutar um nome do 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 as solicitações de entrada 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 os servidores à Web. Você está expondo apenas a porta 80 ou a porta 443 no gateway de aplicativo, que é encaminhado para o servidor do pool de back-end. Nesta configuração, os servidores Web não estão diretamente acessíveis pela Internet, o que reduz a superfície de ataque de sua infraestrutura.
Investigações de integridade
As investigações de integridade determinam quais servidores estão disponíveis para executar o balanceamento de carga em um pool de back-end. O Gateway de Aplicativo usa uma investigação de integridade para enviar uma solicitação a 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 aguarda 30 segundos antes de decidir que um servidor não está disponível. As investigações de integridade garantem que o tráfego não seja direcionado para um ponto de extremidade da Web que não está respondendo ou que falhou no pool de back-end.
Dimensionamento automático
O Gateway de Aplicativo dá suporte ao dimensionamento automático e pode ser expandido ou reduzido de acordo com a mudança dos padrões da carga de tráfego. O escalonamento automático também remove o requisito de escolher um tamanho de implantação ou contagem de instâncias durante o provisionamento.
Tráfego do WebSocket e HTTP/2
O Gateway de Aplicativo fornece suporte nativo para os protocolos WebSocket e HTTP/2. Os protocolos WebSocket e HTTP/2 permitem uma comunicação full duplex entre um servidor e um cliente em uma conexão TCP de execução longa. Esse tipo de comunicação é mais interativo entre o servidor Web e o cliente e pode ser bidirecional sem a necessidade de sondagem conforme necessário 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 mais eficiente de recursos. Esses protocolos foram projetados para funcionar em portas HTTP tradicionais de 80 e 443.