Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
As Definições de Back-end permitem gerir as configurações de conexões de back-end estabelecidas a partir de um recurso de gateway da aplicação para um servidor no pool de back-end. Uma configuração de Configurações de Back-End pode ser associada a uma ou mais regras de roteamento.
Tipos de configurações de back-end no Application Gateway
Enquanto os usuários do Portal verão apenas a opção "Configurações de back-end", os usuários da API terão acesso a dois tipos de configurações. Você deve utilizar a configuração correta, de acordo com o protocolo.
- Configurações HTTP de back-end - É para configurações de proxy de Camada 7 que suportam protocolos HTTP e HTTPS.
- Configurações de back-end - É para configurações de proxy de camada 4 (visualização) que suportam protocolos TLS e TCP.
Afinidade com base no cookie
O Gateway de Aplicativo do Azure usa cookies gerenciados por gateway para manter sessões de usuário. Quando um usuário envia a primeira solicitação para o Application Gateway, ele define um cookie de afinidade na resposta com um valor de hash que contém os detalhes da sessão. Esse processo permite que solicitações subsequentes que carregam o cookie de afinidade sejam roteadas para o mesmo servidor de back-end, mantendo assim a aderência.
Esse recurso é útil quando você deseja manter uma sessão de usuário no mesmo servidor e quando o estado da sessão é salvo localmente no servidor para uma sessão de usuário. Se o aplicativo não puder lidar com a afinidade baseada em cookies, você não poderá usar esse recurso. Para usá-lo, certifique-se de que os clientes suportam cookies.
Nota
Algumas verificações de vulnerabilidade podem sinalizar o cookie de afinidade do Application Gateway porque os sinalizadores Secure ou HttpOnly não estão definidos. Essas verificações não levam em conta que os dados no cookie são gerados usando um hash unidirecional. O cookie não contém nenhuma informação do usuário e é usado exclusivamente para roteamento.
A atualização do navegador Chromium v80 trouxe um mandato onde os cookies HTTP sem o atributo SameSite devem ser tratados como SameSite=Lax. Para solicitações CORS (Cross-Origin Resource Sharing), se o cookie tiver que ser enviado em um contexto de terceiros, ele terá que usar SameSite=None; Atributos seguros e deve ser enviado apenas por HTTPS. Caso contrário, em um cenário somente HTTP, o navegador não envia os cookies no contexto de terceiros. O objetivo desta atualização do Chrome é melhorar a segurança e evitar ataques CSRF (Cross-Site Request Forgery).
Para suportar essa alteração, a partir de 17 de fevereiro de 2020, o Application Gateway (todos os tipos de SKU) injetará outro cookie chamado ApplicationGatewayAffinityCORS além do cookie ApplicationGatewayAffinity existente. O cookie ApplicationGatewayAffinityCORS tem mais dois atributos adicionados a ele ("SameSite=None; Secure") para que as sessões adesivas sejam mantidas mesmo para pedidos de origem cruzada.
O nome padrão do cookie de afinidade é ApplicationGatewayAffinity e você pode alterá-lo. Se em sua topologia de rede, você implantar vários gateways de aplicativos em linha, deverá definir nomes de cookie exclusivos para cada recurso. Se estiveres a usar um nome de cookie de afinidade personalizado, um cookie adicional será adicionado com CORS como sufixo. Por exemplo: CustomCookieNameCORS.
Nota
Se o atributo SameSite=None estiver definido, é obrigatório que o cookie também contenha o sinalizador Secure e deve ser enviado por HTTPS. Se a afinidade de sessão for necessária sobre CORS, você deverá migrar sua carga de trabalho para HTTPS. Consulte o descarregamento de TLS e a documentação de TLS de ponta a ponta para o Application Gateway. Consulte a visão geral do SSL, Configurar um gateway de aplicativo com terminação TLS e Configurar TLS de ponta a ponta.
Drenagem de ligação
O esgotamento de conexão ajuda a remover de forma eficiente os membros do grupo de servidores back-end durante atualizações de serviço planeadas. Aplica-se a instâncias de back-end que são explicitamente removidas do pool de back-end.
Você pode aplicar essa configuração a todos os membros do pool de back-end habilitando a Drenagem de Conexões na Configuração de Back-end. Ele garante que todas as instâncias de cancelamento de registro em um pool de back-end não recebam novas solicitações/conexões enquanto mantém as conexões existentes até o valor de tempo limite configurado. Esse processo também é verdadeiro para conexões WebSocket.
| Tipo de Configuração | Valor |
|---|---|
| Valor padrão quando a Drenagem de Conexão não está habilitada na Configuração de Back-end | 30 segundos |
| Valor definido pelo usuário quando a Drenagem de Conexão está habilitada na Configuração de Back-end | 1 a 3600 segundos |
A única exceção a esse processo são solicitações destinadas a cancelar o registro de instâncias devido à afinidade de sessão gerenciada pelo gateway. Estes pedidos continuam a ser encaminhados para as instâncias de cancelamento de registo.
Nota
Há uma limitação em que uma atualização de configuração encerrará as conexões contínuas após o tempo limite de drenagem da conexão. Para resolver essa limitação, você deve aumentar o tempo limite de drenagem da conexão nas configurações de back-end para um valor maior do que o tempo máximo esperado de download do cliente.
Protocolo
O Application Gateway suporta HTTP e HTTPS para rotear solicitações para os servidores back-end. Se você escolher HTTP, o tráfego para os servidores back-end não será criptografado. Se a comunicação não criptografada não for aceitável, escolha HTTPS.
Essa configuração combinada com HTTPS no ouvinte oferece suporte a TLS de ponta a ponta. Isso permite que você transmita com segurança dados confidenciais criptografados para o back-end. Cada servidor de backend no pool de backend com TLS de ponta a ponta habilitado deve ser configurado com um certificado para garantir comunicação segura.
Porto
Essa configuração especifica a porta onde os servidores back-end escutam o tráfego do gateway de aplicativo. Você pode configurar portas que variam de 1 a 65535.
Certificado raiz confiável
Ao selecionar o protocolo HTTPS nas configurações de back-end, o recurso de gateway de aplicações utiliza seu repositório de certificados raiz CA confiável padrão para verificar a cadeia e a autenticidade do certificado fornecido pelo servidor de back-end.
Por padrão, o recurso do Application Gateway inclui certificados de CA populares, permitindo conexões TLS de back-end contínuas quando o certificado do servidor de back-end é emitido por uma CA pública. No entanto, se você pretende usar uma CA privada ou um certificado autogerado com validação TLS completa, deverá fornecer o certificado de CA raiz (.cer) correspondente na configuração Configurações de back-end.
Configurações de validação de HTTPS do back-end
Quando HTTPS é selecionado nas Configurações de back-end do Gateway de Aplicativo do Azure, o gateway executa a validação completa do handshake TLS enquanto estabelece uma conexão segura com servidores back-end. Essas validações incluem:
- Verificar a cadeia de certificados para garantir que o certificado é confiável.
- Verificando o Nome do Assunto do certificado em relação à Indicação de Nome do Servidor (SNI) que foi enviada pelo Application Gateway.
- Verificar a expiração do certificado para confirmar se o certificado ainda é válido.
As configurações de validação padrão garantem uma comunicação TLS segura entre o gateway e os serviços de back-end. Em determinados cenários, pode ser necessário ajustar uma ou mais dessas configurações de validação. Para acomodar diversos requisitos do cliente, o Application Gateway oferece as seguintes opções configuráveis. Você pode usar uma ou ambas as opções, conforme necessário.
| Propriedades | Valores |
|---|---|
| validateCertChainAndExpiry | Tipo: Booleano (verdadeiro ou falso). A configuração padrão é true. Isto verifica ou ignora tanto as verificações da cadeia de certificados quanto as de expiração. |
| validarSNI | Tipo: Booleano (verdadeiro ou falso). A configuração padrão é true. Ele verifica se o Nome Comum do certificado fornecido pelo servidor back-end corresponde ao valor SNI (Indicação de Nome do Servidor) que foi enviado pelo Gateway de Aplicativo. |
| sniNome | Tipo: String. Essa propriedade é necessária somente quando validateSNI é definido como true. Você pode especificar um valor SNI para corresponder ao nome comum do certificado no back-end. Por padrão, o gateway de aplicativo usa o cabeçalho de host da solicitação de entrada como SNI. |
Nota
- Recomendamos manter todas as validações habilitadas para ambientes de produção. A desativação de algumas ou de todas as validações é sugerida apenas para fins de teste e desenvolvimento, como quando certificados autoassinados são usados.
- Essas configurações não se aplicam à funcionalidade de teste do probe quando se adiciona um probe de integridade personalizado. Como resultado, você pode ver diferenças nos resultados quando comparado com sondas periódicas de saúde.
- Atualmente, não há suporte para proxy TLS.
- PowerShell e CLI serão suportados em breve.
Tempo limite da requisição
Essa configuração é o número de segundos que o gateway de aplicativo aguarda para receber uma resposta do servidor back-end. O valor padrão é 20 segundos. No entanto, você pode querer ajustar essa configuração às necessidades do seu aplicativo. Os valores aceitáveis são de 1 segundo a 86400 segundos (24 horas).
Substituir caminho de back-end
Essa configuração permite configurar um caminho de encaminhamento personalizado opcional para usar quando a solicitação for encaminhada para o back-end. Qualquer parte do caminho de entrada que corresponda ao caminho personalizado no campo de caminho de back-end de substituição é copiada para o caminho encaminhado. A tabela a seguir mostra como esse recurso funciona:
Quando a configuração HTTP é anexada a uma regra básica de roteamento de solicitação:
Pedido original Substituir caminho de back-end Solicitação encaminhada para back-end /Casa/ /substituição/ /substituição/home/ /home/secondhome/ /substituição/ /substituição/home/secondhome/ Quando a configuração HTTP é anexada a uma regra de roteamento de solicitação baseada em caminho:
Pedido original Regra de caminho Substituir caminho de back-end Solicitação encaminhada para back-end /pathrule/home/ /pathrule* /substituição/ /substituição/home/ /pathrule/home/secondhome/ /pathrule* /substituição/ /substituição/home/secondhome/ /Casa/ /pathrule* /substituição/ /substituição/home/ /home/secondhome/ /pathrule* /substituição/ /substituição/home/secondhome/ /pathrule/home/ /pathrule/início* /substituição/ /substituição/ /pathrule/home/secondhome/ /pathrule/início* /substituição/ /anulação/secondhome/ /pathrule/ /pathrule/ /substituição/ /substituição/
Usar sonda personalizada
Essa configuração associa uma sonda personalizada a uma configuração HTTP. Você pode associar apenas um teste personalizado a uma configuração HTTP. Se você não associar explicitamente uma sonda personalizada, a sonda padrão será usada para monitorar a integridade do back-end. Recomendamos criar uma sonda personalizada para ter um maior controlo sobre o monitoramento da saúde dos seus back-ends.
Nota
A sonda personalizada não monitora o estado de saúde do pool de back-end, a menos que a configuração HTTP correspondente esteja explicitamente associada a um ouvinte.
Configurando o nome do host
O Application Gateway permite que a conexão estabelecida com o back-end use um nome de host diferente daquele usado pelo cliente para se conectar ao Application Gateway. Embora essa configuração possa ser útil em alguns casos, tenha cuidado ao substituir o nome do host, de modo que ele seja diferente entre o gateway de aplicativo e o cliente em comparação com o destino de back-end.
Em ambientes de produção, é uma prática recomendada usar o mesmo nome de host para a conexão do cliente para o gateway de aplicação e do gateway de aplicação para a conexão de destino no back-end. Essa prática evita possíveis problemas com URLs absolutos, URLs de redirecionamento e cookies vinculados ao host.
Antes de configurar o Application Gateway que se desvia disso, examine as implicações de tal configuração, conforme discutido com mais detalhes no Centro de Arquitetura: Preservar o nome de host HTTP original entre um proxy reverso e a sua aplicação web de back-end
Há dois aspetos de uma configuração HTTP que influenciam o Host cabeçalho HTTP usado pelo Application Gateway para se conectar ao back-end:
- Obtenha o nome do host a partir do endereço de back-end.
- "Substituição do nome do anfitrião"
Selecione o nome do host do endereço de backend
Esse recurso define dinamicamente o cabeçalho do host na solicitação como o nome do host do pool de back-end. Ele usa um endereço IP ou FQDN.
Esse recurso ajuda quando o nome de domínio do back-end é diferente do nome DNS do gateway de aplicações, e o back-end depende de um cabeçalho de host específico para resolver o ponto de extremidade correto.
Um exemplo de caso são os serviços multilocatários como sistema de back-end. Um serviço de aplicativo é um serviço multilocatário que usa um espaço compartilhado com um único endereço IP. Assim, um serviço de aplicativo só pode ser acessado por meio dos nomes de host configurados nas configurações de domínio personalizadas.
Por padrão, o nome de domínio personalizado é example.azurewebsites.net. Para aceder ao seu serviço de aplicações através de um gateway de aplicações por meio de um nome de anfitrião que não esteja explicitamente registado no serviço de aplicações ou através do FQDN do gateway de aplicações, pode substituir o nome de anfitrião na solicitação original pelo nome de anfitrião do serviço de aplicações. Para fazer isso, ative a configuração "escolher o nome do host do endereço de back-end".
Para um domínio personalizado cujo nome DNS personalizado existente está mapeado para o serviço de aplicações, a configuração recomendada não é habilitar o escolher nome do host a partir do endereço de back-end.
Nota
Essa configuração não é necessária para o Ambiente do Serviço de Aplicativo, que é uma implantação dedicada.
Substituição do nome do host
Esse recurso substitui o cabeçalho do host na solicitação de entrada no gateway de aplicação pelo nome do host especificado.
Por exemplo, se www.contoso.com for especificado na configuração Nome do host , a solicitação original *https://appgw.eastus.cloudapp.azure.com/path1 será alterada para *https://www.contoso.com/path1 quando a solicitação for encaminhada para o servidor back-end.
Conexão de back-end dedicada
O Gateway de Aplicativo do Azure, por padrão, reutiliza conexões de back-end ociosas para otimizar a utilização de recursos de conexões TCP para o Gateway de Aplicativo e o servidor de back-end. Para dar suporte a funções de segurança em caminhos de dados do cliente que exigem conexões de back-end exclusivas por cliente, o Gateway de Aplicativo do Azure V2 fornece conexões dedicadas a servidores back-end.
Esse recurso estabelece um mapeamento direto e um-para-um entre conexões front-end e back-end, garantindo conectividade persistente para cada cliente individual.
Nota
Para ativar a autenticação de passagem NTLM ou Kerberos, assegure-se de que a opção Ligação de Backend Dedicada está ativada. Essa configuração mantém um mapeamento um-para-um entre conexões frontend e back-end, que é essencial para preservar a integridade da sessão exigida por esses protocolos de autenticação.
Importante
A conexão de back-end dedicada leva a um aumento no número de conexões de back-end e, portanto, pode exigir mais recursos para suportar o aumento de conexões simultâneas no Application Gateway e nos servidores de back-end. No Application Gateway, você deve considerar aumentar o número de instâncias ou habilitar o dimensionamento automático.
Quando o back-end é um servidor remoto, as instâncias do Application Gateway utilizam portas SNAT para cada conexão. À medida que cada conexão de cliente estabelece uma conexão de back-end dedicada, o consumo de porta SNAT aumenta correspondentemente. Portanto, é importante levar em conta o potencial esgotamento da porta SNAT. Visite as práticas recomendadas de arquitetura para obter orientação.
A conexão de back-end dedicada não é suportada com HTTP/2.