Compartilhar via

TLS (Transport Layer Security) no Banco de Dados do Azure para PostgreSQL

O Banco de Dados do Azure para PostgreSQL requer que todas as conexões de cliente usem o TLS (Transport Layer Security), um protocolo padrão do setor que criptografa as comunicações entre o servidor de banco de dados e os aplicativos cliente. O TLS substitui o protocolo SSL mais antigo, com apenas as versões TLS 1.2 e 1.3 reconhecidas como seguras. A integridade da segurança do TLS depende de três pilares:

  • Usando apenas as versões 1.2 ou 1.3 do TLS.
  • O cliente valida o certificado TLS do servidor emitido por uma AC (Autoridade de Certificação) em uma cadeia de ACs iniciada por uma AC raiz confiável.
  • Negociando um conjunto de criptografia seguro entre o servidor e o cliente.

Certificados raiz confiáveis e rotações de certificados

Importante

A Microsoft iniciou uma rotação de certificados TLS para o Banco de Dados do Azure para PostgreSQL para atualizar certificados de autoridade certificadora intermediária e a cadeia de certificação resultante. Os CAs raiz permanecem os mesmos.

Se a configuração do cliente usar as configurações recomendadas para TLS, você não precisará executar nenhuma ação.

Programação de rotação de certificado

  • As regiões do Azure Centro-Oeste dos EUA, Leste da Ásia e Sul do Reino Unido iniciaram sua rotação de certificados TLS em 11 de novembro de 2025.
  • A partir de 19 de janeiro de 2026, essa rotação de certificados está prevista para se estender para as regiões restantes (exceto a China), incluindo o Azure Government.
  • Após o Festival da Primavera (Ano Novo Chinês) de 2026, as regiões da China também passarão por uma rotação de certificados que inclui uma mudança em um dos ACs raiz.

CAs raiz usadas pelo Banco de Dados do Azure para PostgreSQL

As ACs raízes são as autoridades de nível superior na cadeia de certificados. Atualmente, o Azure Banco de Dados para PostgreSQL usa certificados com dupla assinatura emitidos por uma autoridade certificadora (AC) intermediária (ICA) ancorada pelas seguintes autoridades certificadoras raiz:

Atualmente, as regiões da China usam as seguintes ACs:

CAs intermediárias

O Banco de Dados do Azure para PostgreSQL usa ICAs (CAs) intermediárias para emitir certificados de servidor. Para manter a segurança, a Microsoft alterna periodicamente essas ICAs e os certificados de servidor que são emitidos por eles. Essas rotações são rotineiras e não são anunciadas com antecedência.

A atual rotação das CAs intermediárias para DigiCert Global Root CA (ver Rotação de Certificados) começou em novembro de 2023 e está programada para ser concluída no primeiro trimestre de 2024. Se você seguiu as práticas recomendadas, essa alteração não exigirá alterações em seu ambiente.

Cadeia de autoridade de certificação antiga

Não use certificados de servidor ou CAs intermediários em seu repositório raiz confiável.

  • DigiCert Global Root G2
    • Microsoft Azure RSA TLS Issuing CA 03 / 04 / 07 / 08
      • Certificado do servidor

Nova cadeia de AC

Não use certificados de servidor ou CAs intermediários em seu repositório raiz confiável.

  • DigiCert Global Root G2
    • Microsoft TLS RSA Root G2
      • Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16
        • Certificado do servidor

Réplicas de leitura

A migração da CA Raiz de DigiCert Global Root CA para DigiCert Global Root G2 não está concluída em todas as regiões. Portanto, é possível que réplicas de leitura recém-criadas usem um certificado de CA raiz mais recente do que o servidor primário. Você deve adicionar DigiCert Global Root CA ao armazenamento confiável de réplicas de leitura.

Cadeias de certificados

Uma cadeia de certificados é uma sequência hierárquica de certificados emitidos por autoridades de certificação confiáveis (CAs). A cadeia começa na AC raiz, que emite certificados de ICA (Autoridade Certificadora Intermediária). As ICAs podem emitir certificados para ICAs de nível inferior. A ICA mais baixa da cadeia emite certificados de servidor individuais. Você estabelece a cadeia de confiança ao verificar cada certificado na cadeia até o certificado da Autoridade Certificadora raiz.

Reduzindo falhas de conexão

O uso de configurações de TLS recomendadas ajuda a reduzir o risco de falhas de conexão devido a rotações de certificado ou alterações em CAs intermediárias. Especificamente, evite confiar em CAs intermediários ou certificados de servidor individuais. Essas práticas podem levar a problemas de conexão inesperados quando a Microsoft atualiza a cadeia de certificados.

Importante

A Microsoft anuncia antecipadamente alterações nos certificados de autoridade raiz (CAs) para ajudá-lo a preparar o seu aplicativo cliente. No entanto, rotações de certificado de servidor e alterações em CAs intermediárias são rotineiras e não são anunciadas.

Cuidado

O uso de configurações sem suporte (cliente) causa falhas de conexão inesperadas.

Melhor configuração

  • Imponha a versão mais recente e segura do TLS definindo o parâmetro do ssl_min_protocol_version servidor como TLSv1.3.
  • Use sslmode=verify-all para conexões PostgreSQL para garantir a verificação completa do certificado e do nome do host. Dependendo da configuração de DNS com pontos de extremidade privados ou integração de rede virtual, verify-all talvez não seja possível. Portanto, você pode usar verify-ca em vez disso.
  • Sempre mantenha o conjunto completo de certificados raiz do Azure em seu repositório raiz confiável.

Boa configuração

  • Defina o parâmetro do ssl_min_protocol_version servidor como TLSv1.3. Se você precisar dar suporte ao TLS 1.2, não defina a versão mínima.
  • Use sslmode=verify-all ou sslmode=verify-ca para conexões PostgreSQL para garantir a verificação completa ou parcial do certificado.
  • Verifique se o repositório raiz confiável contém o certificado da autoridade raiz atualmente usado pelo banco de dados do Azure para PostgreSQL.

Não use as seguintes configurações:

  • Desabilite o TLS definindo require_secure_transportOFF e definindo o lado do cliente como sslmode=disable.
  • Use as configurações sslmode do lado do cliente disable, allow, prefer ou require que podem tornar seu aplicativo vulnerável a ataques man-in-the-middle.

Configurações sem suporte; não use

O PostgreSQL do Azure não anuncia alterações em relação a alterações de AC intermediárias ou rotações de certificados de servidor individuais. Portanto, as seguintes configurações não têm suporte ao usar sslmodeverify-ca ou verify-all:

  • Usando certificados de Autoridade Certificadora intermediários em seu repositório confiável.
  • Usando a fixação de certificado, como, usando certificados de servidor individuais em seu repositório confiável.

Cuidado

Seus aplicativos não conseguem se conectar aos servidores de banco de dados sem aviso sempre que a Microsoft altera os CAs intermediários da cadeia de certificados ou gira o certificado do servidor.

Problemas de fixação de certificado

Observação

As rotações de certificado não afetarão você se você não usar as configurações sslmode=verify-full ou sslmode=verify-ca na cadeia de conexão do seu aplicativo cliente. Portanto, você não precisa seguir as etapas nesta seção.

Nunca use a fixação de certificado em seus aplicativos, pois ele interrompe a rotação de certificados, como a alteração de certificado atual de CAs intermediárias. Se você não sabe o que é a fixação de certificado, é improvável que você esteja usando-a. Para verificar se há a fixação de certificado:

  • Produza sua lista de certificados que estão em seu repositório raiz confiável.
  • Você está usando a pinagem de certificado se tiver certificados de autoridade certificadora intermediária ou certificados de servidor PostgreSQL individuais em seu repositório raiz confiável.
  • Para remover a pinagem de certificado, remova todos os certificados do repositório raiz confiável e adicione os certificados de AC raiz recomendados.

Se você tiver problemas devido ao certificado intermediário mesmo após seguir estas etapas, entre em contato com o suporte da Microsoft. Inclua ICA Rotation 2026 no título.

Outras considerações para TLS

Além da configuração principal do TLS e do gerenciamento de certificados, vários outros fatores influenciam a segurança e o comportamento das conexões criptografadas com o Banco de Dados do Azure para PostgreSQL. Entender essas considerações ajuda você a tomar decisões informadas sobre a implementação do TLS em seu ambiente.

Versões TLS inseguras e seguras

Várias entidades governamentais em todo o mundo mantêm diretrizes para TLS em relação à segurança de rede. Nos Estados Unidos, essas organizações incluem o Ministério da Saúde e Serviços Humanos e o National Institute of Standards and Technology. O nível de segurança que o TLS fornece é mais afetado pela versão do protocolo TLS e pelos pacotes de criptografia com suporte.

O Banco de Dados do Azure para PostgreSQL dá suporte às versões TLS 1.2 e 1.3. No RFC 8996, a IETF (Internet Engineering Task Force) declara explicitamente que o TLS 1.0 e o TLS 1.1 não devem ser usados. Ambos os protocolos foram preteridos no final de 2019. Todas as conexões de entrada que usam versões inseguras anteriores do protocolo TLS, como TLS 1.0 e TLS 1.1, são negadas por padrão.

O IETF lançou a especificação TLS 1.3 no RFC 8446 em agosto de 2018 e o TLS 1.3 é a versão recomendada, pois é mais rápido e seguro que o TLS 1.2.

Embora não o recomendemos, se necessário, você pode desabilitar o TLS para conexões com o Banco de Dados do Azure para PostgreSQL. Você pode atualizar o parâmetro do servidor require_secure_transport para OFF.

Importante

Use a versão mais recente do TLS 1.3 para criptografar suas conexões de banco de dados. Você pode especificar a versão mínima do TLS definindo o parâmetro do ssl_min_protocol_version servidor como TLSv1.3. Não defina o parâmetro do ssl_max_protocol_version servidor.

Conjuntos de criptografia

Um conjunto de criptografias é um conjunto de algoritmos que incluem uma criptografia, um algoritmo de troca de chaves e um algoritmo de hash. Use-os junto com o certificado TLS e a versão do TLS para estabelecer uma conexão TLS segura. A maioria dos clientes e servidores do TLS dá suporte a vários pacotes de criptografia e, às vezes, a várias versões do TLS. Durante o estabelecimento da conexão, o cliente e o servidor negociam a versão do TLS e o conjunto de criptografias a serem usados por meio de um handshake. Durante esse handshake, as seguintes etapas ocorrem:

  • O cliente envia uma lista de conjuntos de criptografia aceitáveis.
  • O servidor seleciona o melhor conjunto de criptografias na lista e informa o cliente da escolha.

Recursos do TLS não disponíveis no Banco de Dados do Azure para PostgreSQL

No momento, o Banco de Dados do Azure para PostgreSQL não implementa os seguintes recursos do TLS:

  • Autenticação de cliente baseada em certificado TLS por meio do TLS com autenticação mútua (mTLS).
  • Certificados de servidor personalizados (traga seus próprios certificados TLS).

Conteúdo relacionado

  • Last updated on