Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
As Configurações de Back-end permitem que você gerencie as configurações de conexões de back-end estabelecidas de um recurso de gateway de aplicativo 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 gateway de aplicações
Embora os usuários do Portal vejam 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 de HTTP de back-end – é para configurações de proxy de camada 7 que dão suporte a protocolos HTTP e HTTPS.
- Configurações de back-end – é para configurações de proxy de camada 4 (versão prévia) que dão suporte a protocolos TLS e TCP.
Afinidade baseada em cookie
O Gateway de Aplicativo do Azure usa cookies gerenciados pelo gateway para manter as sessões de usuário. Quando um usuário envia a primeira solicitação para o Gateway de Aplicativo, 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 as solicitações subsequentes que carregam o cookie de afinidade sejam roteada para o mesmo servidor de back-end, mantendo assim a consistência.
Esse recurso é útil para manter uma sessão de usuário no mesmo servidor e quando o estado de sessão é salvo localmente no servidor para uma sessão de usuário. Esse recurso não poderá ser usado se o aplicativo não puder lidar com a afinidade baseada em cookie. Para usá-lo, certifique-se de que os clientes dão suporte a cookies.
Observação
Algumas verificações de vulnerabilidade podem sinalizar o cookie de afinidade do Gateway de Aplicativo 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 puramente para roteamento.
A atualização do navegador Chromiumv80 introduziu a exigência de que os cookies de HTTP sem o atributo SameSite sejam tratados como SameSite=Lax. Para solicitações de CORS (Compartilhamento de Recursos entre Origens), se o cookie tiver que ser enviado em um contexto de terceiros, ele precisa usar os atributos SameSite = None; Secure e deve ser enviado somente por HTTPS. Em um cenário somente HTTP, o navegador não vai enviar os cookies no contexto de terceiros. O objetivo dessa atualização do Chrome é aprimorar a segurança e evitar ataques CSRF (Solicitação Intersite Forjada).
Para dar suporte a essa alteração, a partir de 17 de fevereiro de 2020, o Gateway de Aplicativo (todos os tipos de SKU) vai injetar outro cookie chamado ApplicationGatewayAffinityCORS além do cookie ApplicationGatewayAffinity existente. O cookie ApplicationGatewayAffinityCORS tem mais dois atributos adicionados (“SameSite=None; Secure”), para que as sessões temporárias também sejam mantidas para as solicitações entre origens.
O nome do cookie de afinidade padrão é ApplicationGatewayAffinity e você pode alterá-lo. Se na sua topologia de rede, você implantar vários gateways de aplicativo em linha, você deverá definir nomes únicos de cookie para cada recurso. Se você estiver usando um nome de cookie de afinidade personalizado, um cookie adicional será adicionado com CORS como sufixo. Por exemplo: CustomCookieNameCORS.
Observação
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 em CORS, você deve migrar sua carga de trabalho para HTTPS. Consulte a documentação sobre descarregamento de TLS e TLS de ponta a ponta para o Gateway de Aplicativo. Confira a visão geral do SSL, configure um gateway de aplicativo com terminação TLS e configure o TLS de ponta a ponta.
Descarregamento de conexão
O esvaziamento de conexões ajuda a remover membros de um pool de back-end durante as atualizações de serviço planejadas. Ele se aplica a instâncias de back-end que são explicitamente removidas do pool de back-end.
É possível aplicar essa configuração a todos os membros de um pool de back-end habilitando o esvaziamento 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, mantendo 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 padrão quando o esvaziamento de conexões não está habilitado na configuração de back-end | Um a 3600 segundos |
A única exceção a esse processo são as solicitações destinadas ao cancelamento de registro de instâncias devido à afinidade de sessão gerenciada pelo gateway. Essas solicitações continuam a ser encaminhadas para as instâncias de cancelamento de registro.
Observação
Há uma limitação em que uma atualização de configuração encerrará as conexões em andamento após o tempo limite de esgotamento da conexão. Para resolver essa limitação, você deve aumentar o tempo limite de esgotamento da conexão nas configurações de back-end para um valor maior do que o tempo máximo de download do cliente esperado.
Protocolo
O Gateway de Aplicativo dá suporte a HTTP e a HTTPS para solicitações de roteamento para os servidores de back-end. Se você escolher HTTP, o tráfego para os servidores de back-end não é criptografado. Se não for possível usar a comunicação não criptografada, escolha HTTPS.
Essa configuração combinada com HTTPS no ouvinte dá suporte ao TLS de ponta a ponta. Isso permite que você transmita os dados confidenciais criptografados com segurança para o back-end. Cada servidor no pool de back-end com TLS de ponta a ponta habilitado deve ser configurado com um certificado para permitir uma comunicação segura.
Porta
Essa configuração especifica a porta em que os servidores de back-end escutam o tráfego do gateway de aplicativo. Você pode configurar portas que variam entre 1 e 65535.
Certificado raiz confiável
Ao selecionar o protocolo HTTPS nas configurações de back-end, o recurso de gateway de aplicativo utiliza seu repositório de certificados de AC raiz confiável padrão para verificar a cadeia e a autenticidade do certificado fornecido pelo servidor de back-end.
Por padrão, o recurso Gateway de Aplicativo inclui certificados de CA populares, permitindo conexões TLS de back-end sem interrupções quando o certificado do servidor de back-end é emitido por uma CA pública. No entanto, se você pretende usar uma AC privada ou um certificado autogerido com validação TLS completa, deverá fornecer o certificado de AC raiz correspondente (.cer) na configuração de Configurações de Back-end.
Configurações de validação HTTPS de backend
Quando HTTPS é selecionado nas Configurações de Back-end do Gateway de Aplicativo do Azure, o gateway executa a validação completa do handshake do TLS ao estabelecer uma conexão segura com servidores de back-end. Essas validações incluem:
- Verificando a cadeia de certificados para garantir que o certificado seja confiável.
- Verificar o Nome da Entidade do certificado em relação à SNI (Indicação de Nome de Servidor) enviada pelo Gateway do Aplicativo.
- Verificando 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 os serviços de gateway e 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 Gateway de Aplicativo oferece as seguintes opções configuráveis. Você pode usar uma ou ambas as opções, conforme necessário.
| Propriedades | Valores |
|---|---|
| validateCertChainAndExpiry | Tipo: booliano (verdadeiro ou falso). A configuração padrão é verdadeira. Isso verifica ou ignora as verificações de cadeia de certificados e expiração. |
| validateSNI | Tipo: booliano (verdadeiro ou falso). A configuração padrão é verdadeira. Ele verifica se o Nome Comum do certificado fornecido pelo servidor de back-end corresponde ao valor da Indicação de Nome do Servidor (SNI) que foi enviado pelo Gateway de Aplicativo. |
| sniName | Tipo: cadeia de caracteres. 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 o SNI. |
Observação
- É recomendável manter todas as validações habilitadas para ambientes de produção. A desabilitação de algumas ou 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 da investigação de teste ao adicionar uma investigação de integridade personalizada. Como resultado, você poderá ver diferenças nos resultados ao comparar com as verificações de integridade periódicas.
- Atualmente, sem suporte para proxy TLS.
- O PowerShell e a CLI serão compatíveis em breve.
Tempo limite da solicitação
Essa configuração é o número de segundos que o gateway de aplicativo aguarda para receber uma resposta do servidor de back-end. O valor padrão é 20 segundos. No entanto, talvez você queira 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 a configuração de um caminho de encaminhamento personalizado opcional para ser usado quando a solicitação for encaminhada para o back-end. Qualquer parte do caminho de entrada que corresponda ao caminho personalizado no campo substituir caminho de back-end é copiada para o caminho encaminhado. A seguinte tabela mostra como esse recurso funciona:
Quando a configuração de HTTP é anexada a uma regra básica de roteamento de solicitação:
Solicitação original Substituir caminho de back-end Solicitação encaminhada para o back-end /Casa/ /override/ /override/home/ /home/secondhome/ /override/ /override/home/secondhome/ Quando a configuração de HTTP é anexada a uma regra de roteamento de solicitação baseada no caminho:
Solicitação original Regra do caminho Substituir caminho de back-end Solicitação encaminhada para o back-end /pathrule/home/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /Casa/ /pathrule* /override/ /override/home/ /home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /override/ /override/ /pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/ /pathrule/ /pathrule/ /override/ /override/
Usar investigação personalizada
Essa configuração associa a investigação personalizada a uma configuração de HTTP. Somente uma investigação personalizada pode ser associada a uma configuração de HTTP. Se você não associar explicitamente uma investigação personalizada, a investigação padrão vai ser usada para monitorar a integridade do back-end. Recomendamos a criação de uma investigação personalizada para um maior controle do monitoramento de integridade dos back-ends.
Observação
A investigação personalizada não vai monitorar a integridade do pool de back-end, a menos que a configuração de HTTP correspondente esteja explicitamente associada a um ouvinte.
Configurando o nome do host
Gateway de Aplicativo permite que a conexão estabelecida com o back-end use um nome de host diferente daquele usado pelo cliente para se conectar ao Gateway de Aplicativo. Embora essa configuração possa ser útil em alguns casos, tenha cuidado ao substituir o nome do host caso 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 melhor prática usar o mesmo nome do host tanto para a conexão do cliente com o Gateway de Aplicativo quanto para a conexão do Gateway de Aplicativo com o destino do back-end. Essa prática evita possíveis problemas com URLs absolutas, URLs de redirecionamento e cookies associados ao host.
Antes de configurar o Application Gateway que se desvia disso, reveja as implicações dessa configuração, conforme discutido em mais detalhes no Centro de Arquitetura: Preservar o nome original do host HTTP entre um proxy reverso e seu aplicativo Web de back-end
Há dois aspectos de uma configuração HTTP que influenciam o cabeçalho HTTP Host usado pelo Gateway de Aplicativo para se conectar ao back-end:
- "Escolher o nome de host do endereço de back-end"
- "Substituição de nome do host"
Escolher o nome de host a partir do endereço de back-end
Essa funcionalidade define dinamicamente o cabeçalho de host na solicitação para o nome do host do pool de back-end. Ele usa um endereço IP ou um FQDN.
Esse recurso ajuda quando o nome de domínio do back-end é diferente do nome DNS do gateway de aplicativo e o back-end depende de um cabeçalho de host específico para resolver para o ponto de extremidade correto.
Um exemplo são os serviços de vários locatários como o back-end. Um serviço de aplicativo é um serviço multilocatário que usa um espaço compartilhado com um único endereço IP. Portanto, um serviço de aplicativo só pode ser acessado por meio dos nomes de host que são definidos nas configurações do domínio personalizado.
Por padrão, o nome de domínio personalizado é example.azurewebsites.net. Para acessar o serviço de aplicativo usando um gateway de aplicativo por meio do nome do host que não está explicitamente registrado no serviço de aplicativo ou por meio do FQDN do gateway de aplicativo, substitua o nome do host na solicitação original pelo nome do host do serviço de aplicativo. Para fazer isso, habilite a configuração escolher 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 aplicativo, a configuração recomendada não é habilitar a opção escolher nome do host do endereço de back-end.
Observação
Essa configuração não é necessária para o Ambiente do Serviço de Aplicativo, que é uma implantação dedicada.
Substituir o nome do host
Essa funcionalidade substitui o cabeçalho de host na solicitação de entrada no gateway de aplicativo pelo nome do host que você deseja especificar.
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 de 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 de back-end.
Essa funcionalidade estabelece um mapeamento direto, um para um entre conexões de front-end e back-end, garantindo conectividade persistente para cada cliente individual.
Observação
Para habilitar a autenticação de passagem NTLM ou Kerberos, verifique se a configuração Conexão de Back-end Dedicada está ativada. Essa configuração mantém um mapeamento um-para-um entre conexões de front-end e back-end, o 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 das conexões simultâneas no Application Gateway e nos servidores de back-end. No Gateway de Aplicações, é necessário considerar aumentar o número de instâncias ou habilitar a escala automática.
Quando o back-end é um servidor remoto, as instâncias do Gateway de Aplicativo 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 considerar o esgotamento potencial da porta SNAT. Visite as práticas recomendadas de arquitetura para obter diretrizes.
Não há suporte para a conexão de back-end dedicada com HTTP/2.