Visão geral do encerramento de TLS e TLS de ponta a ponta com um Gateway de Aplicativo
O protocolo TLS, anteriormente conhecido como protocolo SSL (SSL), é a tecnologia de segurança padrão para estabelecer um vínculo criptografado entre um servidor Web e um navegador. Esse link garante que todos os dados passados entre o servidor Web e os navegadores permaneçam privados e criptografados. O gateway de aplicativo dá suporte ao encerramento de TLS no gateway, bem como à criptografia TLS de ponta a ponta.
Encerramento de TLS
O Gateway de Aplicativo dá suporte ao encerramento de TLS no gateway, pelo qual o tráfego flui geralmente descriptografado até os servidores de back-end. Há várias vantagens de fazer o término do TLS no gateway de aplicativo:
- Desempenho aprimorado – o maior impacto de desempenho ao fazer a descriptografia de TLS é o handshake inicial. Para melhorar o desempenho, o servidor que faz a descriptografia armazena em cache as IDs da sessão TLS e gerencia os tíquetes da 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, sempre que as solicitações do cliente passarem para um servidor diferente, o cliente deverá se autenticar novamente. O uso de tíquetes TLS pode ajudar a atenuar esse problema, mas eles não têm suporte em todos os clientes e podem ser difíceis de configurar e gerenciar.
- Melhor utilização dos servidores de back-end – o processamento de SSL/TLS consome muita CPU e está consumindo mais à medida que os tamanhos de chave aumentam. A remoção desse trabalho dos servidores de back-end permite que eles se concentrem no que são mais eficientes: no fornecimento de conteúdo.
- Roteamento inteligente – descriptografando 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 aplicativo e não em todos os servidores de 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 Gateway de Aplicativo descriptografe o tráfego de entrada e criptografe o tráfego de resposta para o cliente. O certificado fornecido para o Gateway de Aplicativo deve estar no formato PFX (Troca de Informações Pessoais), que contém as chaves pública e privada. Os algoritmos PFX com suporte estão listados na função PFXImportCertStore.
Importante
O certificado no ouvinte exige que toda a cadeia de certificados seja carregada (o certificado raiz da autoridade de certificação, os intermediários e o certificado de folha) para estabelecer a cadeia de confiança.
Observação
O gateway de aplicativo não fornece nenhum recurso para criar um novo certificado ou enviar uma solicitação de certificado a uma autoridade de certificação.
Para que a conexão TLS funcione, você precisa garantir que o certificado TLS/SSL atenda às seguintes condições:
- A data e hora atuais estão dentro do intervalo de datas "Válido de" e "Válido até" no certificado.
- o "Common Name" (CN) do certificado corresponde ao cabeçalho de host na solicitação. Por exemplo, se o cliente estiver fazendo uma solicitação para
https://www.contoso.com/, o CN deverá serwww.contoso.com.
Se você tiver erros com o nome comum do certificado de back-end (CN), consulte nosso guia de solução de problemas.
Certificados compatíveis para encerramento de TLS
O gateway de aplicativo dá suporte aos seguintes tipos de certificados:
- Certificado de AC (Autoridade de Certificação): um certificado de AC é um certificado digital emitido por uma autoridade de certificação (AC)
- Certificado EV (Validação Estendida): um certificado EV é um certificado que está em conformidade com as diretrizes de certificado padrão do setor. Isso tornará a barra de localizador do navegador verde e publicará o nome da empresa também.
- Certificado Coringa: esse certificado dá suporte a qualquer número de subdomínios com base no *.site.com, em que o subdomínio substituiria o *. No entanto, ele não dá suporte a site.com; por isso, caso os usuários estejam acessando seu site sem digitar o "www" inicial, o certificado curinga não abordará isso.
- Certificados autoassinados: os navegadores cliente não confiam nesses certificados e avisam 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 ideais 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 o encerramento de TLS com o gateway de aplicativo.
Tamanho do certificado
Verifique a seção Limites do Gateway de Aplicativo para saber o tamanho máximo do certificado TLS/SSL compatível.
Criptografia TLS de ponta a ponta
Talvez você não queira uma 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 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 você usa os recursos de balanceamento de carga da camada 7 do Gateway de Aplicativo. Esses recursos incluem afinidade de sessão baseada em cookie, roteamento baseado em URL, suporte para roteamento com base 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 Gateway de Aplicativo encerra as sessões de TLS no gateway e descriptografa o tráfego do usuário. Ele aplica as regras configuradas para selecionar uma instância de pool de back-end apropriada para rotear o tráfego. Depois, o Gateway de Aplicativo inicia uma nova conexão TLS com o servidor de back-end e criptografa novamente os dados usando o certificado de chave pública do servidor de back-end antes de transmitir a solicitação ao back-end. Qualquer resposta do servidor Web passa pelo mesmo processo de volta para o usuário final. O TLS de ponta a ponta é habilitado definindo a configuração de protocolo em Configuração de HTTP de back-end para HTTPS, que é então aplicado a um pool de back-end.
Nos gateways de SKU do Gateway de Aplicativo v1, a política TLS aplica a versão do TLS somente ao tráfego de front-end e às criptografias definidas para destinos de front-end e back-end. Nos gateways de SKU do Gateway de Aplicativo v2, a política TLS só se aplica ao tráfego de front-end, as conexões TLS de back-end sempre serão negociadas pelaas versões TLS 1.0 para TLS 1.2.
O Gateway de Aplicativo só se comunica com os servidores back-end que colocaram os certificados na lista de permitidos ou cujos certificados são assinados por autoridades de certificação conhecidas e se o CN do certificado corresponde ao nome de host nas configurações de back-end HTTP. Isso inclui os serviços confiáveis do Azure, como Serviço de Aplicativo/Aplicativos Web do Azure e o Gerenciamento de API do Azure.
Se os certificados dos membros no pool de back-end não forem assinados por autoridades de certificação conhecidas, cada instância no pool de back-end com TLS de ponta a ponta habilitado deverá ser configurada com um certificado para permitir a comunicação segura. A adição do certificado garante que o gateway de aplicativo se comunique somente com instâncias de back-end conhecidas. Isso protege ainda mais a comunicação de ponta a ponta.
Observação
O certificado adicionado à Configuração de HTTP de back-end para autenticar os servidores de back-end pode ser o mesmo que o certificado adicionado ao ouvinte para encerramento de TLS no gateway de aplicativo ou diferente para aumentar a segurança.
Neste exemplo, as solicitações que usam o TLS1.2 são roteadas para os servidores de back-end no Pool1 usando o TLS de ponta a ponta.
TLS de ponta a ponta e lista de certificados permitidos
O Gateway de Aplicativo só se comunica com os servidores back-end que colocaram os certificados na lista de permitidos ou cujos certificados são assinados por autoridades de certificação conhecidas e se o CN do certificado corresponde ao nome de 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 Gateway de Aplicativo usada. A seção a seguir explica as versões individualmente.
TLS de ponta a ponta com a SKU v1
Para habilitar o TLS de ponta a ponta com os servidores de back-end e para o Gateway de Aplicativo rotear solicitações para eles, as investigações de integridade devem ter sucesso e retornar a resposta íntegra.
Para investigações de integridade HTTPS, a SKU v1 do Gateway de Aplicativo 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 carregada nas configurações de HTTP.
Somente é possível estabelecer conexões com os back-ends conhecidos e permitidos. Os back-ends restantes são considerados não íntegros pelas investigações de integridade. Os certificados autoassinados servem somente para teste e não são recomendados para cargas de trabalho de produção. Esses certificados devem estar na lista de permitidos do gateway de aplicativo, conforme descrito nas etapas acima, para que sejam usados.
Observação
A autenticação e a configuração de certificado raiz confiável não são necessárias para serviços confiáveis do Azure, como o Serviço de Aplicativo do Azure. Eles são considerados confiáveis por padrão.
TLS de ponta a ponta com a SKU v2
Os Certificados de Autenticação foram reprovados e substituídos por Certificados raiz confiáveis no SKU do Gateway de Aplicativo v2. Eles funcionam da mesma forma para Certificados de Autenticação com algumas diferenças importantes:
Os certificados assinados por autoridades de certificação conhecidas cujo CN corresponde ao nome do host nas configurações de back-end de HTTP não exigem etapas adicionais 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 bem conhecida e tiverem um CN da 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 a investigação de integridade e o caminho de dados seriam habilitados para TLS. Se você estiver usando o Serviço de Aplicativo do Azure ou outros serviços Web do Azure como seu back-end, eles serão implicitamente confiáveis e nenhuma outra etapa será necessária para o TLS de ponta a ponta.
Observação
Para que um certificado TLS/SSL seja confiável, esse certificado do servidor back-end deve ter sido emitido por uma autoridade de certificação conhecida. Se o certificado não foi emitido por uma autoridade de certificação confiável, o gateway de aplicativo verificará se o certificado da AC emissora foi emitido por uma autoridade de certificação confiável e assim por diante até que uma AC confiável seja encontrada (ponto em que uma conexão confiável e segura será estabelecida) ou nenhuma AC confiável possa ser encontrada (nesse ponto, o gateway de aplicativo marcará o back-end como não íntegro). Portanto, é recomendável que o certificado do servidor back-end contenha as ACs raiz e intermediária.
Se o certificado do servidor back-end for autoassinado ou assinado por AC/intermediários desconhecidos, será necessário carregar um certificado raiz confiável para habilitar o TLS de ponta a ponta no Gateway de Aplicativo v2. O Gateway de Aplicativo só se comunicará com back-ends cujo certificado raiz do certificado do servidor corresponda a um que está na lista de certificados raiz confiáveis na configuração http de back-end associada ao pool.
Além da correspondência de certificado raiz, o Gateway de Aplicativo V2 também valida se a configuração de host especificada na configuração de http de back-end corresponde à do nome comum (CN) apresentado pelo certificado TLS/SSL do servidor de back-end. Ao tentar estabelecer uma conexão TLS com o back-end, o Gateway de Aplicativo v2 define a extensão SNI (Indicação de Nome de Servidor) para o host especificado na configuração http de back-end.
Se a opção Escolher o nome do host no destino de back-end for selecionada em vez do campo Host na configuração de HTTP de back-end, o cabeçalho SNI sempre será definido como o FQDN do pool de back-end e o CN no certificado TLS/SSL do servidor back-end precisará corresponder ao FQDN. Não há suporte para membros do pool de back-end com IPs neste cenário.
O certificado raiz é um certificado raiz codificado em base64 a partir dos certificados do servidor de back-end.
Diferenças de SNI na SKU v1 e v2
Conforme mencionado anteriormente, o Gateway de Aplicativo encerra o tráfego TLS do cliente no ouvinte do Gateway de Aplicativo (vamos chamá-lo de conexão de front-end), descriptografa o tráfego, aplica as regras necessárias para determinar o servidor de back-end ao qual a solicitação deve ser encaminhada e estabelece uma nova sessão TLS com o servidor de back-end (vamos chamá-lo de conexão de back-end).
As tabelas a seguir descrevem as diferenças no SNI entre a SKU v1 e v2 em termos de conexões de front-end e back-end.
Conexão TLS de front-end (gateway de cliente para aplicativo)
| Cenário | v1 | v2 |
|---|---|---|
| Se o cliente especificar o cabeçalho SNI e todos os ouvintes de vários sites estiverem habilitados com o sinalizador "Exigir SNI" | Retorna o certificado apropriado e, se o site não existir (de acordo com o server_name), a conexão será redefinida. | Retorna o certificado apropriado, se disponível; caso contrário, retorna o certificado do primeiro ouvinte HTTPS de acordo com a ordem especificada pelas regras de roteamento de solicitação associadas aos ouvintes HTTPS |
| Se o cliente não especificar um cabeçalho SNI e se todos os cabeçalhos de vários sites estiverem habilitados com "Exigir SNI" | Redefine a conexão | Retorna o certificado do primeiro ouvinte HTTPS de acordo com a ordem especificada pelas regras de roteamento de solicitação associadas aos ouvintes HTTPS |
| Se o cliente não especificar o cabeçalho SNI e se houver um ouvinte básico configurado com um certificado | Retorna o certificado configurado no ouvinte básico para o cliente (certificado de fallback ou padrão) | Retorna o certificado configurado no ouvinte básico |
Observação
Quando o cliente não especifica um cabeçalho SNI, é recomendável que o usuário adicione um ouvinte básico e uma regra para apresentar um certificado SSL/TLS padrão.
Dica
O sinalizador SNI pode ser configurado com o PowerShell ou usando um modelo do ARM. Para obter mais informações, consulte RequireServerNameIndication e Início Rápido: tráfego direto da Web com o Gateway de Aplicativo do Azure – modelo do ARM.
Conexão TLS de back-end (gateway de aplicativo para o servidor de back-end)
Para o tráfego de investigação
| Cenário | v1 | v2 |
|---|---|---|
| Cabeçalho SNI (server_name) durante o handshake de TLS como FQDN | Defina como FQDN do pool de back-end. De acordo com RFC 6066, os endereços IPv4 e IPv6 literais não são permitidos no nome do host SNI. Observação: o FQDN no pool de back-end deve ser resolvido no endereço de IP do servidor de back-end (público ou privado) |
O cabeçalho SNI (server_name) é definido como o nome do host na investigação personalizada anexada às configurações de HTTP (se configurado), caso contrário, no nome do host mencionado nas configurações de HTTP ou no FQDN mencionado no pool de back-end. A ordem de precedência é investigação personalizada > configurações HTTP > pool de back-end. Observação: se os nomes de host configurados nas configurações HTTP e na investigação personalizada forem diferentes, de acordo com a precedência, o SNI será definido como o nome do host da investigação personalizada. |
| Se o endereço do pool de back-end for um endereço IP (v1) ou se o nome de host da investigação personalizada estiver configurado como endereço IP (v2) | SNI (server_name) não será definido. Observação: nesse caso, o servidor back-end deve ser capaz de retornar um certificado padrão/fallback e este deve ser incluído na lista de permissões da configuração de HTTP no certificado de autenticação. Se não houver um certificado padrão/fallback configurado no servidor back-end e o SNI for esperado, o servidor poderá redefinir a conexão e levará a falhas de investigação |
Na ordem de precedência mencionada anteriormente, se eles tiverem o endereço IP como nome do host, o SNI não será definido de acordo com RFC 6066. Observação: o SNI também não será definido em investigações v2 se nenhuma investigação personalizada estiver configurada e nenhum nome de host estiver definido nas configurações http ou no pool de back-end |
Observação
Se uma investigação personalizada não estiver configurada, o Gateway de Aplicativo enviará uma investigação padrão neste formato - <protocolo>://127.0.0.1:<porta>/. Por exemplo, para uma investigação HTTPS padrão, ele será enviada como https://127.0.0.1:443/. Observe que o 127.0.0.1 mencionado aqui é usado apenas como cabeçalho de host HTTP e, de acordo com RFC 6066, não será usado como cabeçalho SNI. Para obter mais informações sobre erros de investigação de integridade, consulte o guia de solução de problemas de integridade de back-end.
Para tráfego em tempo real
| Cenário | v1 | v2 |
|---|---|---|
| Cabeçalho SNI (server_name) durante o handshake de TLS como FQDN | Defina como FQDN do pool de back-end. De acordo com RFC 6066, os endereços IPv4 e IPv6 literais não são permitidos no nome do host SNI. Observação: o FQDN no pool de back-end deve ser resolvido no endereço de IP do servidor de back-end (público ou privado) |
O cabeçalho SNI (server_name) é definido como o nome do host nas configurações de HTTP; caso contrário, se a opção PickHostnameFromBackendAddress for escolhida ou se nenhum nome de host for mencionado, ele será definido como o FQDN na configuração do pool de back-end |
| Se o endereço do pool de back-end for um endereço IP ou o nome do host não estiver definido nas configurações de HTTP | O SNI não será definido de acordo com RFC 6066 se a entrada do pool de back-end não for um FQDN | O SNI será definido como o nome do host do FQDN de entrada do cliente e o CN do certificado de back-end deverá corresponder a esse nome do host. |
| O nome do host não é fornecido nas Configurações de HTTP, mas um FQDN é especificado como o destino de um membro do pool de back-end | O SNI será definido como o nome do host do FQDN de entrada do cliente e o CN do certificado de back-end deverá corresponder a esse nome do host. | O SNI será definido como o nome do host do FQDN de entrada do cliente e o CN do certificado de back-end deverá corresponder a esse nome do host. |
Próximas etapas
Depois de aprender sobre o TLS de ponta a ponta, acesse Configurar o TLS de ponta a ponta usando o Gateway de Aplicativo com o PowerShell para criar um gateway de aplicativo usando o TLS de ponta a ponta.