Compartilhar via

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

Introdução

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

Iniciamos uma rotação de certificados TLS para o Banco de Dados do Azure para PostgreSQL para atualizar novos certificados de autoridade certificadora intermediária e a cadeia de certificados resultante. As autoridades certificadoras raiz permanecem as mesmas.

Nenhuma ação será necessária se a configuração do cliente implementar as configurações recomendadas para TLS.

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. O Azure Database for PostgreSQL atualmente usa certificados com dupla assinatura emitidos por uma ICA ancorada pelas seguintes autoridades certificadoras raiz:

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

Sobre as Autoridades Certificadoras intermediárias

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

A rotação atual de CAs intermediárias para DigiCert Global Root CA (ver rotação de certificado) que começou em novembro de 2025 e está agendada para ser concluída no primeiro trimestre de 2026 substitui as CAs intermediárias da seguinte maneira. 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

Essas informações são fornecidas somente para referência. 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

Essas informações são fornecidas somente para referência. 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 as réplicas de leitura recém-criadas estejam em um certificado de CA raiz mais recente do que o servidor primário. Portanto, você deve adicionar a DigiCert Global Root CA ao armazenamento confiável das 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), começando na AC raiz, que emite certificados de AC intermediária (ICA). As ICAs podem emitir certificados para ICAs de nível inferior. A ICA mais baixa da cadeia emite certificados de servidor individuais. A cadeia de confiança é estabelecida verificando cada certificado na cadeia até o certificado de AC raiz.

Reduzindo falhas de conexão

Utilizar 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, pois essas práticas podem levar a problemas inesperados de conexão quando a Microsoft atualiza a cadeia de certificados.

Importante

As alterações nos CAs raiz são anunciadas antecipadamente para ajudá-lo a preparar seus aplicativos cliente; no entanto, as rotações de certificado do servidor e as alterações em CAs intermediárias são rotineiras e, portanto, 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 VNET, verify-all talvez não seja possível; portanto, você pode usar verify-ca .
  • 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.

Aconselhamos fortemente contra as seguintes configurações:

  • Desabilite o TLS completamente definindo require_secure_transportOFF e definindo o lado do cliente como sslmode=disable.
  • Previna ataques do tipo man-in-the-middle evitando configurações no lado sslmode do cliente, disable, allow, prefer ou require.

Configurações sem suporte; não usar

O PostgreSQL do Azure não anuncia alterações sobre mudanças de AC intermediários ou rotações de certificados de servidor individuais; portanto, as seguintes configurações não são suportadas ao usar configurações sslmode, verify-ca ou verify-all.

  • Você usa certificados de AC intermediários em seu repositório confiável.
  • Você usa a fixação de certificado, como usar 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 anexação de certificado

Observação

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

Nunca use pinagem de certificado em seus aplicativos, pois isso interrompe a rotação de certificados, como a alteração de certificados atuais de Autoridades Certificadoras 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ê estiver enfrentando problemas devido ao certificado intermediário mesmo após seguir estas etapas, entre em contato com o suporte da Microsoft. Inclua no título ICA Rotation 2026.

Outras considerações para TLS

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 ao TLS versão 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

É altamente recomendável que você use as versões mais recentes 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. Eles são usados 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, ocorre o seguinte:

  • O cliente envia uma lista de conjuntos de criptografia aceitáveis.
  • O servidor seleciona o melhor conjunto de criptografias (por sua própria definição) na lista e informa o cliente de sua 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