Partilhar via

Segurança da Camada de Transporte (TLS) no Azure Base de Dados para PostgreSQL

Introdução

O Azure Database para PostgreSQL exige que todas as ligações do cliente utilizem o Transport Layer Security (TLS), um protocolo padrão da indústria que encripta as comunicações entre o seu servidor de base de dados e as aplicações do cliente. O TLS substitui o antigo protocolo SSL, sendo apenas as versões 1.2 e 1.3 reconhecidas como seguras. A integridade da segurança TLS assenta em três pilares:

  • Usando apenas as versões TLS 1.2 ou 1.3.
  • O cliente valida o certificado TLS do servidor emitido por uma Autoridade Certificadora (CA) numa cadeia de CAs iniciada por uma CA raiz de confiança.
  • Negociar um conjunto de cifras seguras entre servidor e cliente.

Certificados raiz confiáveis e rotação de certificados

Importante

Iniciámos uma rotação de certificados TLS para a Azure Database for PostgreSQL , para atualizar novos certificados intermédios de CA e a cadeia de certificados resultante. As CAs raiz mantêm-se as mesmas.

Não é necessária qualquer ação se a configuração do cliente implementar as configurações Recomendadas para TLS.

Calendário de rotação de certificados

  • Regiões Azure West Central US, East Asia e UK South iniciaram a rotação dos certificados TLS em 11 de novembro de 2025.
  • A partir de 19 de janeiro de 2026, esta rotação de certificados está planeada para se estender às restantes regiões (exceto 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 a alteração de uma das CAs raízes.

CAs Root usadas pelo Azure Database de PostgreSQL

As Root CAs são as autoridades de topo na cadeia de certificação. Atualmente, a Azure Database for PostgreSQL utiliza certificados de assinatura dupla emitidos por um ICA ancorado pelas seguintes CAs raiz:

As regiões da China utilizam atualmente as seguintes Autoridades Certificadoras:

Sobre os CAs Intermédios

O Azure Database for PostgreSQL utiliza CAs intermédias (ICAs) para emitir certificados de servidor. A Microsoft alterna periodicamente estes ICAs e os certificados de servidor que emite para garantir a segurança. Estas rotações são rotineiras e não são anunciadas antecipadamente.

A rotação atual dos CAs intermédios para DigiCert Global Root CA (ver rotação de certificados), que começou em novembro de 2025 e está prevista para ser concluída no primeiro trimestre de 2026, substitui os CAs intermédios da seguinte forma. Se seguiu as práticas recomendadas, então esta mudança não exige alterações no seu ambiente.

Antiga cadeia CA

Esta informação é fornecida apenas para referência. Não uses CAs intermédias ou certificados de servidor na tua loja raiz de confiança.

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

A nova cadeia CA

Esta informação é fornecida apenas para referência. Não utilize CAs intermédias ou certificados de servidor no seu armazém raiz de confiança.

  • 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 root CA da DigiCert Global Root CA para a 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 estejam num certificado de CA raiz mais recente do que o servidor principal. Por isso, 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 Certificadoras (CAs) de confiança, começando na CA raiz, que emite certificados de CA intermédia (ICA). Os ICAs podem emitir certificados para ICAs inferiores. O ICA mais baixo da cadeia emite certificados individuais de servidor. A cadeia de confiança é estabelecida verificando cada certificado da cadeia até ao certificado da CA raiz.

Redução de falhas de ligação

Utilizar configurações TLS recomendadas ajuda a reduzir o risco de falhas de ligação devido a rotações de certificados ou alterações em CAs intermédias. Especificamente, evite confiar em CAs intermédias ou certificados individuais de servidores, pois estas práticas podem levar a problemas inesperados de ligação quando a Microsoft atualiza a cadeia de certificados.

Importante

As alterações nas CAs raiz são anunciadas antecipadamente para ajudar a preparar as suas aplicações para clientes; no entanto, as rotações de certificados do servidor e as alterações nas CAs intermédias são rotineiras e, por isso, não anunciadas.

Atenção

O uso de configurações não suportadas (cliente) causa falhas inesperadas na ligação.

Melhor configuração

  • Aplicar a versão TLS mais recente e mais segura definindo o ssl_min_protocol_version parâmetro do servidor para TLSv1.3.
  • Use sslmode=verify-all para ligações PostgreSQL para garantir a verificação completa de certificados e nomes de host. Dependendo da sua configuração DNS com Endpoints Privados ou integração com VNET, verify-all pode não ser possível; por isso, pode usar verify-ca em vez disso.
  • Mantenha sempre o conjunto completo de certificados raiz do Azure na sua loja raiz de confiança.

Boa configuração

  • Defina o ssl_min_protocol_version parâmetro do servidor para TLSv1.3. Se tens mesmo de suportar TLS 1.2, não definas a versão mínima.
  • Use sslmode=verify-all ou sslmode=verify-ca para ligações PostgreSQL para garantir a verificação total ou parcial dos certificados.
  • Certifique-se de que o armazenamento raiz de confiança contém o certificado de CA raiz atualmente utilizado pelo Azure Database para PostgreSQL:

Desaconselhamos fortemente as seguintes configurações:

  • Desative completamente o TLS definindo require_secure_transport para OFF e definindo o lado do cliente para sslmode=disable.
  • Previna ataques man-in-the-middle evitando definições no lado do cliente sslmode, disable, allow ou prefer.require

Configurações não suportadas; Não usar

O Azure PostgreSQL não anuncia alterações sobre alterações intermédias de CA ou rotações individuais de certificados de servidor; Por isso, as seguintes configurações não são suportadas ao utilizar sslmode definições verify-ca ou verify-all:

  • Utilizas certificados CA intermédios na tua loja de confiança.
  • Utiliza fixação de certificados, como usar certificados individuais de servidor na sua loja de confiança.

Atenção

As suas aplicações falham em ligar-se aos servidores de base de dados sem aviso prévio sempre que a Microsoft altera as CAs intermédias da cadeia de certificados ou roda o certificado do servidor.

Problemas de fixação de certificados

Observação

Se não estiveres a usar as definições sslmode=verify-full ou sslmode=verify-ca na cadeia de ligação da tua aplicação cliente, então as rotações de certificados não te afetam. Portanto, você não precisa seguir as etapas nesta seção.

Nunca use pinagem de certificados nas suas aplicações, pois isso interrompe a rotação de certificados, como a atual mudança de certificado das CAs intermediárias. Se não souber o que é fixar certificado, é pouco provável que esteja a usá-lo. Para verificar a fixação do certificado:

  • Crie a sua lista de certificados que estão no seu repositório raiz de certificados confiáveis.
  • Estás a usar pinagem de certificados se tiveres certificados CA intermédios ou certificados individuais do servidor PostgreSQL no teu repositório raiz de confiança.
  • Para remover a fixação de certificados, remova todos os certificados da sua loja raiz de confiança e adicione os certificados de CA raiz recomendados.

Se estiver a ter problemas devido ao certificado intermédio, mesmo depois de seguir estes passos, contacte o suporte da Microsoft. Adicione ao título: ICA Rotation 2026.

Outras considerações para o 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 da rede. Nos Estados Unidos, essas organizações incluem o Departamento de Saúde e Serviços Humanos e o Instituto Nacional de Padrões e Tecnologia. O nível de segurança que o TLS fornece é mais afetado pela versão do protocolo TLS e pelos pacotes de codificação suportados.

Azure Database for PostgreSQL suporta TLS versões 1.2 e 1.3. No RFC 8996, a Força-Tarefa de Engenharia da Internet (IETF) afirma explicitamente que o TLS 1.0 e o TLS 1.1 não devem ser utilizados. Ambos os protocolos foram preteridos no final de 2019. Todas as ligações de entrada que utilizam versões anteriores e inseguras do protocolo TLS, como TLS 1.0 e TLS 1.1, são negadas por defeito.

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 do que o TLS 1.2.

Embora não o recomendemos, se necessário, pode desativar o TLS para ligações à sua base de dados Azure para PostgreSQL. Você pode atualizar o require_secure_transport parâmetro server para OFF.

Importante

Recomendamos vivamente que utilize as versões mais recentes do TLS 1.3 para encriptar as suas ligações à base de dados. Pode especificar a versão mínima do TLS definindo o ssl_min_protocol_version parâmetro do servidor para TLSv1.3. Não definas o ssl_max_protocol_version parâmetro do servidor.

Pacotes de cifra

Um conjunto de cifras é um conjunto de algoritmos que inclui uma cifra, um algoritmo de troca de chaves e um algoritmo de hash. São usados em conjunto com o certificado TLS e a versão TLS para estabelecer uma ligação TLS segura. A maioria dos clientes e servidores TLS suporta múltiplos conjuntos de cifras e, por vezes, múltiplas versões TLS. Durante o estabelecimento da ligação, o cliente e o servidor negociam a versão TLS e a suíte de cifras para usar através de um handshake. Durante este aperto de mão, ocorre o seguinte:

  • O cliente envia uma lista de conjuntos de cifras aceitáveis.
  • O servidor seleciona a melhor (pela sua própria definição) conjunto de cifras da lista e informa o cliente da escolha.

Funcionalidades TLS não disponíveis no Azure Database para PostgreSQL

Neste momento, o Azure Database para PostgreSQL não implementa as seguintes funcionalidades TLS:

  • Autenticação cliente baseada em certificado TLS através de TLS com autenticação mútua (mTLS).
  • Certificados de servidor personalizados (tragam os vossos próprios certificados TLS).

Conteúdo relacionado

  • Last updated on