Visão geral da terminação TLS e TLS de ponta a ponta com o Application Gateway

Transport Layer Security (TLS), anteriormente conhecido como Secure Sockets Layer (SSL), é a tecnologia de segurança padrão para estabelecer um link criptografado entre um servidor web e um navegador. Este link garante que todos os dados passados entre o servidor Web e os navegadores permaneçam privados e criptografados. O gateway de aplicação suporta terminação TLS no gateway e criptografia TLS de ponta a ponta.

Terminação TLS

O Application Gateway suporta terminação TLS no gateway, após o qual o tráfego normalmente flui sem criptografia para os servidores back-end. Há uma série de vantagens de fazer o encerramento TLS no gateway de aplicação.

• Desempenho melhorado – O maior impacto no desempenho ao fazer a descriptografia TLS ocorre durante o handshake inicial. Para melhorar o desempenho, o servidor que faz a descriptografia armazena em cache IDs de sessão TLS e gerencia tíquetes de sessão TLS. Se isso for feito no gateway de aplicativo, todas as solicitações do mesmo cliente poderão usar os valores armazenados em cache. Se isso for feito nos servidores de back-end, cada vez que as solicitações do cliente forem para um servidor diferente, o cliente deverá se autenticar novamente. O uso de tíquetes TLS pode ajudar a mitigar esse problema, mas eles não são suportados por todos os clientes e podem ser difíceis de configurar e gerenciar.
• Melhor utilização dos servidores back-end – o processamento SSL/TLS é muito exigente em termos de CPU e está a tornar-se ainda mais exigente à medida que aumenta o tamanho das chaves. Remover esse trabalho dos servidores back-end permite que eles se concentrem no que eles são mais eficientes, fornecendo conteúdo.
• Roteamento inteligente – Ao descriptografar o tráfego, o gateway de aplicativo tem acesso ao conteúdo da solicitação, como cabeçalhos, URI e assim por diante, e pode usar esses dados para rotear solicitações.
• Gerenciamento de certificados – Os certificados só precisam ser comprados e instalados no gateway de aplicativos e não em todos os servidores back-end. Isso economiza tempo e dinheiro.

Para configurar a terminação TLS, um certificado TLS/SSL deve ser adicionado ao ouvinte. Isso permite que o Application Gateway descriptografe o tráfego de entrada e criptografe o tráfego de resposta para o cliente. O certificado fornecido ao Application Gateway deve estar no formato PFX (Personal Information Exchange), que contém as chaves privada e pública. Os algoritmos PFX suportados estão listados na função PFXImportCertStore.

Para que a conexão TLS funcione, você precisa garantir que o certificado TLS/SSL atenda às seguintes condições:

• Que a data e hora atuais estão dentro do intervalo de datas "Válido de" e "Válido até" no certificado.
• O "Nome Comum" (NC) do certificado corresponde ao cabeçalho do servidor na requisição. Por exemplo, se o cliente estiver a realizar um pedido para https://www.contoso.com/, o NC tem de ser www.contoso.com.

Se você tiver erros com o nome comum (CN) do certificado de back-end, consulte nosso guia de solução de problemas.

Certificados suportados para encerramento TLS

O gateway de aplicativo oferece suporte aos seguintes tipos de certificados:

• Certificado de autoridade de certificação (CA): um certificado de autoridade de certificação é um certificado digital emitido por uma CA
• Certificado EV (Extended Validation): Um certificado EV é um certificado que cumpre as diretrizes estabelecidas pela indústria. Isso tornará a barra do localizador do navegador verde e publicará o nome da empresa também.
• Certificado Wildcard: Este certificado suporta qualquer número de subdomínios com base em *.site.com, onde o seu subdomínio substitui o *. No entanto, ele não suporta site.com, portanto, caso os utilizadores estejam a aceder o seu website sem digitar o "www" inicial, o certificado curinga não cobrirá isso.
• Certificados autoassinados: os navegadores clientes não confiam nesses certificados e avisarão o usuário de que o certificado do serviço virtual não faz parte de uma cadeia de confiança. Os certificados autoassinados são bons para testes ou ambientes em que os administradores controlam os clientes e podem ignorar com segurança os alertas de segurança do navegador. As cargas de trabalho de produção nunca devem usar certificados autoassinados.

Para obter mais informações, consulte configurar a terminação TLS com o gateway de aplicação.

Tamanho do certificado

Verifique a seção Limites do Application Gateway para saber o tamanho máximo do certificado TLS/SSL suportado.

Encriptação TLS ponto a ponto

Talvez você não queira comunicação não criptografada para os servidores de back-end. Você pode ter requisitos de segurança, requisitos de conformidade ou o aplicativo só pode aceitar uma conexão segura. O Gateway de Aplicativo do Azure tem criptografia TLS de ponta a ponta para dar suporte a esses requisitos.

O TLS de ponta a ponta permite criptografar e transmitir com segurança dados confidenciais para o back-end enquanto usa os recursos de balanceamento de carga Layer-7 do Application Gateway. Esses recursos incluem afinidade de sessão baseada em cookies, roteamento baseado em URL, suporte para roteamento baseado em sites, a capacidade de reescrever ou injetar cabeçalhos X-Forwarded-* e assim por diante.

Quando configurado com o modo de comunicação TLS de ponta a ponta, o Application Gateway encerra as sessões TLS no gateway e descriptografa o tráfego do usuário. Em seguida, aplica as regras configuradas para selecionar uma instância de conjunto de back-end adequada para encaminhar o tráfego. Em seguida, o Application Gateway inicia uma nova conexão TLS com o servidor back-end e criptografa novamente os dados usando o certificado de chave pública do servidor back-end antes de transmitir a solicitação para o back-end. Qualquer resposta do servidor Web atravessa o mesmo processo para o utilizador final. O TLS de ponta a ponta é ativado ao definir a configuração do protocolo em Definições HTTP do Backend para HTTPS, que é então aplicada a um pool de backend.

Nos gateways do SKU do Application Gateway v1, a política TLS aplica a versão TLS apenas ao tráfego de frontend e aplica as cifras definidas tanto aos alvos de frontend quanto aos de backend. Nos gateways SKU do Application Gateway v2, a política TLS só se aplica ao tráfego frontend, as conexões TLS de back-end sempre serão negociadas por meio das versões TLS 1.0 a TLS 1.2.

O Application Gateway só se comunica com os servidores back-end que têm permissão para listar seu certificado com o Application Gateway ou cujos certificados são assinados por autoridades de CA conhecidas e o CN do certificado corresponde ao nome do host nas configurações de back-end HTTP. Estes incluem os serviços fidedignos do Azure, como o Serviço de Aplicações Web/Aplicações Web do Azure e a Gestão de API do Azure.

Se os certificados dos membros no pool de back-end não forem assinados por autoridades de CA conhecidas, cada instância no pool de back-end com TLS de ponta a ponta habilitado deverá ser configurada com um certificado para permitir uma comunicação segura. Adicionar o certificado garante que o gateway de aplicativo se comunique apenas com instâncias de back-end conhecidas. Isso garante ainda mais a comunicação de ponta a ponta.

Neste exemplo, as solicitações usando TLS1.2 são roteadas para servidores back-end no Pool1 usando TLS de ponta a ponta.

TLS de ponta a ponta e permitir a listagem de certificados

O Application Gateway só se comunica com os servidores back-end que têm permissão para listar seu certificado com o Application Gateway ou cujos certificados são assinados por autoridades de CA conhecidas e o CN do certificado corresponde ao nome do host nas configurações de back-end HTTP. Há algumas diferenças no processo de configuração de TLS de ponta a ponta em relação à versão do Application Gateway usada. A seção a seguir explica as versões individualmente.

TLS de ponta a ponta com o SKU v1

Para habilitar o TLS de ponta a ponta com os servidores back-end e para que o Application Gateway roteie solicitações para eles, as sondas de integridade devem ter êxito e retornar uma resposta saudável.

Para testes de integridade HTTPS, a SKU do Application Gateway v1 usa uma correspondência exata do certificado de autenticação (chave pública do certificado do servidor back-end e não do certificado raiz) a ser carregado nas configurações HTTP.

Somente conexões com back-ends conhecidos e permitidos são permitidas. Os restantes backends são considerados não saudáveis pelas verificações de saúde. Os certificados autoassinados são apenas para fins de teste e não são recomendados para cargas de trabalho de produção. Esses certificados devem ser autorizados no gateway de aplicação, conforme descrito nas etapas anteriores, antes de poderem ser utilizados.

TLS de ponta a ponta com o SKU v2

Os Certificados de Autenticação foram preteridos e substituídos por Certificados Raiz Confiáveis na SKU do Application Gateway v2. Eles funcionam de forma semelhante aos Certificados de Autenticação com algumas diferenças importantes:

• Os certificados assinados por autoridades de autoridade de certificação conhecidas cujo CN corresponde ao nome do host nas configurações de back-end HTTP não exigem nenhuma etapa adicional para que o TLS de ponta a ponta funcione.

  Por exemplo, se os certificados de back-end forem emitidos por uma autoridade de certificação conhecida e tiverem um CN de contoso.com, e o campo de host da configuração http de back-end também estiver definido como contoso.com, nenhuma etapa adicional será necessária. Você pode definir o protocolo de configuração http de back-end como HTTPS e tanto a sonda de integridade quanto o caminho de dados seriam TLS habilitados. Se você estiver usando o Serviço de Aplicativo do Azure ou outros serviços Web do Azure como seu back-end, eles também serão implicitamente confiáveis e nenhuma etapa adicional será necessária para TLS de ponta a ponta.

• Para ativar o TLS de ponta a ponta no Application Gateway v2, é necessário carregar um certificado raiz confiável se o certificado do servidor back-end for autoassinado ou assinado por uma Autoridade de Certificação (CA) ou intermediários desconhecidos. O Application Gateway só se comunicará com back-ends cujo certificado raiz do certificado do servidor corresponda a um da lista de certificados raiz confiáveis na configuração http de back-end associada ao pool.

• Além da correspondência do certificado raiz, o Application Gateway v2 também valida se a definição de Host especificada nas configurações HTTP do back-end corresponde ao Common Name (CN) apresentado pelo certificado TLS/SSL do servidor de back-end. Ao tentar estabelecer uma conexão TLS com o back-end, o Application Gateway v2 define a extensão SNI (Server Name Indication) para o Host especificado na configuração http de back-end.

• Se for selecionado nome do host do alvo de back-end em vez do campo Host na configuração de http do back-end, o cabeçalho SNI será sempre definido como o FQDN do pool de back-end, e o CN no certificado TLS/SSL do servidor de back-end deve corresponder ao seu FQDN. Os membros do pool de back-end com endereços IP não são suportados neste cenário.

• O certificado raiz é um certificado raiz codificado em base64 proveniente dos certificados do servidor backend.

Diferenças de SNI no SKU v1 e v2

Como mencionado anteriormente, o Application Gateway encerra o tráfego TLS do cliente no Application Gateway Listener (vamos chamá-lo de conexão frontend), descriptografa o tráfego, aplica as regras necessárias para determinar o servidor back-end para o qual a solicitação deve ser encaminhada e estabelece uma nova sessão TLS com o servidor back-end (vamos chamá-lo de conexão back-end).

As tabelas a seguir descrevem as diferenças no SNI entre o SKU v1 e v2 em termos de conexões frontend e backend.

Conexão TLS frontend (cliente para gateway de aplicativo)

Conexão TLS de back-end (gateway de aplicativo para o servidor back-end)

Para tráfego de sonda

Para trânsito em direto

Próximos passos

Depois de aprender sobre TLS de ponta a ponta, vá para Configurar TLS de ponta a ponta usando o Application Gateway com PowerShell para criar um gateway de aplicativo usando TLS de ponta a ponta.