Compartilhar via

TLS ponta a ponta com Azure Front Door

  • Artigo

O protocolo TLS, conhecido anteriormente como protocolo SSL, é a tecnologia de segurança padrão para estabelecer um link criptografado entre um servidor Web e um cliente, como um navegador Web. Esse link garante que todos os dados passados entre o servidor e o cliente permaneçam privados e criptografados.

Para cumprir requisitos de segurança ou conformidade, o Azure Front Door dá suporte à criptografia TLS de ponta a ponta. O descarregamento TLS/SSL do Front Door encerra a conexão TLS, descriptografa o tráfego no Azure Front Door e o criptografa novamente antes de encaminhá-lo para a origem. Quando as conexões com a origem usam o endereço IP público da origem, é uma boa prática de segurança configurar o HTTPS como o protocolo de encaminhamento no Azure Front Door. Usando HTTPS como o protocolo de encaminhamento, você pode impor a criptografia TLS de ponta a ponta para todo o processamento da solicitação do cliente para a origem. O descarregamento TLS/SSL também terá suporte se você implantar uma origem privada com o Azure Front Door Premium usando o recurso Link Privado.

Este artigo explica como o Azure Front Door funciona com conexões TLS. Para obter mais informações sobre como usar certificados TLS com seus domínios personalizados, consulte HTTPS para domínios personalizados. Para saber como configurar um certificado TLS em seu domínio personalizado, consulte Configurar um domínio personalizado no Azure Front Door usando o portal do Azure.

Criptografia TLS de ponta a ponta

O TLS de ponta a ponta permite que você proteja dados confidenciais em trânsito para a origem enquanto aproveita recursos do Azure Front Door como balanceamento de carga global e cache. Alguns dos recursos também incluem roteamento baseado em URL, divisão de TCP, cache no local de borda mais próximo dos clientes e personalização de solicitações HTTP na borda.

O Azure Front Door descarrega as sessões TLS na borda e descriptografa as solicitações do cliente. Ele aplica as regras de roteamento configuradas para rotear as solicitações para a origem apropriada no grupo de origem. O Azure Front Door inicia uma nova conexão TLS com a origem e criptografa novamente todos os dados usando o certificado da origem antes de transmitir a solicitação para a origem. Qualquer resposta da origem é criptografada pelo mesmo processo de volta para o usuário final. Você pode configurar o Azure Front Door para usar HTTPS como o protocolo de encaminhamento para habilitar o TLS ponta a ponta.

Versões do TLS com suporte

O Azure Front Door dá suporte a quatro versões do protocolo TLS: TLS versões 1.0, 1.1, 1.2 e 1.3. Todos os perfis do Azure Front Door criados após setembro de 2019 usam o TLS 1.2 como o mínimo padrão com o TLS 1.3 habilitado, mas o TLS 1.0 e o TLS 1.1 ainda têm suporte para compatibilidade com versões anteriores.

Embora o Azure Front Door dê suporte ao TLS 1.2, que introduziu a autenticação de cliente/autenticação mútua no RFC 5246, atualmente, o Azure Front Door ainda não dá suporte à autenticação de cliente/autenticação mútua (mTLS).

Você pode configurar uma versão mínima do TLS no Azure Front Door nas configurações de HTTPS do domínio personalizado usando o portal do Azure ou aAPI REST do Azure. No momento, você pode escolher entre 1.0 e 1.2. Dessa forma, a especificação do TLS 1.2 como a versão mínima controla a versão mínima aceitável do TLS que o Azure Front Door aceitará de um cliente. Para TLS na versão mínima 1.2, a negociação tentará estabelecer o TLS 1.3 e, em seguida, o TLS 1.2, enquanto para TLS na versão mínima 1.0 haverá tentativas para todas as quatro versões. Quando o Azure Front Door iniciar o tráfego TLS para a origem, ele tentará negociar a melhor versão do TLS que a origem puder aceitar de modo confiável e consistente. As versões do TLS com suporte para conexões de origem são TLS 1.0, TLS 1.1, TLS 1.2 e TLS 1.3.

Observação

  • Os clientes com TLS 1.3 habilitado devem dar suporte uma das Curvas EC compatíveis com o SDL da Microsoft, incluindo Secp384r1, Secp256r1 e Secp521, para fazer solicitações com êxito com o Azure Front Door usando TLS 1.3.
  • É recomendado que os clientes usem uma dessas curvas como sua curva preferida durante as solicitações para evitar o aumento da latência do handshake do TLS, que pode resultar em várias viagem de ida e volta para negociar a curva EC com suporte.

Certificados com suporte

Ao criar seu certificado TLS/SSL, você precisa criar uma cadeia de certificados completa com uma AC (autoridade de certificação) permitida que faz parte da Lista de ACs Confiáveis da Microsoft. Se você usar uma autoridade de certificação sem permissão, sua solicitação será rejeitada.

Certificados de ACs internas ou certificados autoassinados não são permitidos.

Associação do OCSP (Protocolo de Status de Certificado Online)

Por padrão, há suporte para a associação do OCSP no Azure Front Door, e nenhuma configuração é necessária.

Conexão TLS de origem (Azure Front Door para a origem)

Para conexões HTTPS, o Azure Front Door espera que a origem apresente o certificado de uma CA (autoridade de certificação) válida com um nome da entidade correspondendo ao nome do host da origem. Por exemplo, se o nome do host de origem for definido como myapp-centralus.contosonews.net e o certificado que a origem apresenta durante o handshake TLS não tiver myapp-centralus.contosonews.net nem *.contosonews.net no nome da entidade, o Azure Front Door recusará a conexão e o cliente verá um erro.

Observação

O certificado deve ter uma cadeia de certificado completa com certificados de folha e intermediários. A AC raiz deve fazer parte da Lista de ACs confiáveis da Microsoft. Se um certificado sem cadeia completa é apresentado, não há garantia de que as solicitações que envolvem esse certificado funcionem conforme o esperado.

Em determinados casos de uso, como para teste, como solução alternativa para resolver falhas na conexão HTTPS, você pode desabilitar a verificação do nome da entidade do certificado para o Azure Front Door. Observe que a origem ainda precisa apresentar um certificado com uma cadeia confiável válida, mas não precisa corresponder ao nome do host de origem.

No Azure Front Door Standard e Premium, você pode configurar uma origem para desabilitar a verificação de nome da entidade do certificado.

No Azure Front Door (clássico), você pode desabilitar a verificação do nome da entidade do certificado alterando as configurações do Azure Front Door no portal do Azure. Você também pode configurar a verificação usando as configurações do pool de back-end nas APIs do Azure Front Door.

Observação

Do ponto de vista da segurança, a Microsoft não recomenda desabilitar a verificação de nome da entidade do certificado.

Conexão TLS de front-end (cliente para o Azure Front Door)

Para habilitar o protocolo HTTPS para fornecer conteúdo com segurança em um domínio personalizado do Azure Front Door, você poderá optar por usar um certificado gerenciado pelo Azure Front Door ou usar seu próprio certificado.

Para saber mais, consulte HTTPS para domínios personalizados.

O certificado gerenciado do Azure Front Door fornece um certificado TLS/SSL padrão via DigiCert e é armazenado no Key Vault do Azure Front Door.

Se você optar por usar seu próprio certificado, poderá integrar um certificado de uma AC compatível que pode ser um TLS padrão, um certificado de validação estendido ou até mesmo um certificado curinga. Não há suporte para certificados autoassinados. Saiba Como habilitar HTTPS para um domínio personalizado.

Alternância automática de certificado

Para certificados gerenciados do Azure Front Door, os certificados são gerenciados e automaticamente alternados dentro de 90 dias do tempo de expiração pelo Azure Front Door. Para a opção de certificados gerenciados do Azure Front Door Standard/Premium, os certificados são gerenciados e automaticamente alternados dentro de 45 dias do tempo de expiração pelo Azure Front Door. Se você estiver usando um certificado gerenciado do Azure Front Door e perceber que a data de validade do certificado é inferior a 60 ou 30 dias para o SKU Standard/Premium, crie um tíquete de suporte.

Para seu próprio certificado TLS/SSL personalizado:

  1. Defina a versão secreta para “Última” para que o certificado seja alternado automaticamente para a última versão quando uma versão mais recente do certificado estiver disponível no cofre de chaves. No caso de certificados personalizados, o certificado é rotacionado automaticamente dentro de 3-4 dias com uma versão mais recente, independentemente da data de expiração do certificado.

  2. Se uma versão específica for selecionada, não haverá suporte para alternação automática. Você terá que selecionar a nova versão manualmente para alternar o certificado. Leva até 24 horas para que a nova versão do certificado/do segredo seja implantada.

    Observação

    Os certificados gerenciados do Azure Front Door (Standard e Premium) são girados automaticamente se o registro CNAME de domínio aponta diretamente para um ponto de extremidade do Front Door ou aponta indiretamente para um ponto de extremidade do Gerenciador de Tráfego. Caso contrário, você precisará validar novamente a propriedade do domínio para girar os certificados.

    Você precisa verificar se a entidade de serviço do Front Door ainda tem acesso ao cofre de chaves. Confira como conceder acesso ao seu cofre de chaves. A operação de distribuição de certificado atualizado pelo Azure Front Door não causa nenhum tempo de inatividade de produção desde que o nome da entidade ou o SAN (nome alternativo da entidade) do certificado não mudem.

Conjuntos de criptografia com suporte

Para o TLS 1.2/1.3, há suporte para os seguintes conjuntos de criptografia:

  • TLS_AES_256_GCM_SHA384 (somente TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (somente TLS 1.3)
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Observação

Para o Windows 10 e versões posteriores, recomendamos habilitar um ou ambos os conjuntos de criptografia ECDHE_GCM para maior segurança. Os Windows 8.1, 8 e 7 não são compatíveis com esses conjuntos de criptografias ECDHE_GCM. Os conjuntos de criptografias ECDHE_CBC e DHE foram fornecidos para compatibilidade com esses sistemas operacionais.

Ao usar domínios personalizados com o TLS 1.0 e 1.1 habilitados, há suporte para os seguintes conjuntos de criptografia:

  • TLS_AES_256_GCM_SHA384 (somente TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (somente TLS 1.3)
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

O Azure Front Door não dá suporte à desabilitação ou configuração de conjuntos de criptografia específicos no seu perfil.

Próximas etapas