Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
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
A Microsoft iniciou uma rotação de certificados TLS para o Azure Database for PostgreSQL , para atualizar os certificados intermédios da CA e a cadeia de certificados resultante. Os CAs de raiz mantêm-se os mesmos.
Se a configuração do teu cliente usar as configurações Recomendadas para TLS, não precisas de tomar qualquer ação.
Calendário de rotação de certificados
- As regiões Azure Oeste Central dos EUA, Este Asiático e Reino Unido Sul iniciaram a rotação de certificados TLS a 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 para PostgreSQL utiliza certificados de assinatura dupla emitidos por uma CA intermédia (ICA) ancorada pelas seguintes CAs raiz:
As regiões da China utilizam atualmente as seguintes Autoridades Certificadoras:
- Microsoft RSA Raiz CA 2017
- DigiCert Global Root CA
- Após o Festival da Primavera (Ano Novo Chinês) 2026: Digicert Global Root G2. Para se preparar antecipadamente para esta alteração, adicione a nova CA raiz ao seu repositório de raízes confiáveis.
CAs Intermédios
O Azure Database for PostgreSQL utiliza CAs intermédias (ICAs) para emitir certificados de servidor. Para manter a segurança, a Microsoft roda periodicamente estes ICAs e os certificados de servidor que emitem. Estas rotações são rotineiras e não são anunciadas antecipadamente.
"A rotação atual de Autoridades Certificadoras Intermediárias para DigiCert Global Root CA (consultar Rotação de Certificados) começou em Novembro de 2023 e está prevista para ser concluída no primeiro trimestre de 2024." Se seguiu as práticas recomendadas, então esta mudança não exige alterações no seu ambiente.
Antiga cadeia CA
Não uses CAs intermédias ou certificados de servidor na tua loja raiz de confiança.
DigiCert Global Root G2Microsoft Azure RSA TLS Issuing CA 03 / 04 / 07 / 08- Certificado do servidor
A nova cadeia CA
Não uses CAs intermédias ou certificados de servidor na tua loja raiz de confiança.
DigiCert Global Root G2Microsoft TLS RSA Root G2Microsoft 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. Assim, é possível que réplicas de leitura recém-criadas utilizem um certificado de CA raiz mais recente do que o servidor principal. Deves adicionar DigiCert Global Root CA à loja confiável de 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. A cadeia começa na CA raiz, que emite certificados CA intermédios (ICA). Os ICAs podem emitir certificados para ICAs inferiores. O ICA mais baixo da cadeia emite certificados individuais de servidor. Estabeleces a cadeia de confiança verificando cada certificado da cadeia até ao certificado da CA raiz.
Redução de falhas de ligação
A utilização de 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 em certificados individuais de servidores. Estas práticas podem levar a problemas inesperados de ligação quando a Microsoft atualiza a cadeia de certificados.
Importante
A Microsoft anuncia as alterações nas CAs raiz com antecedência para o ajudar a preparar as suas aplicações cliente. No entanto, as rotações de certificados do servidor e as alterações nas CAs intermédias são rotineiras e não são anunciadas.
Atenção
O uso de configurações não suportadas (cliente) causa falhas inesperadas na ligação.
Configurações recomendadas para TLS
Melhor configuração
- Aplicar a versão TLS mais recente e mais segura definindo o
ssl_min_protocol_versionparâmetro do servidor paraTLSv1.3. - Use
sslmode=verify-allpara ligações PostgreSQL para garantir a verificação completa de certificados e nomes de host. Dependendo da sua configuração DNS com Pontos Finais Privados ou integração de rede virtual,verify-allpode não ser possível. Por isso, pode usarverify-caem 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_versionparâmetro do servidor paraTLSv1.3. Se tens mesmo de suportar TLS 1.2, não definas a versão mínima. - Use
sslmode=verify-allousslmode=verify-capara 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:
Suportado, mas não recomendado
Não use as seguintes configurações:
- Desative o TLS definindo
require_secure_transportparaOFFe definindo o lado do cliente parasslmode=disable. - Use definições do lado do cliente
sslmode,disable,allow,preferourequireque podem tornar a sua aplicação vulnerável a ataques man-in-the-middle.
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. Portanto, as seguintes configurações não são suportadas ao usar sslmode definições verify-ca ou verify-all:
- Usar certificados CA intermédios na sua loja de confiança.
- Usar 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
As rotações de certificados não os afetam se não utilizarem as definições sslmode=verify-full ou sslmode=verify-ca na cadeia de ligação da aplicação cliente. Portanto, você não precisa seguir as etapas nesta seção.
Nunca use a pinagem de certificados nas suas aplicações, pois isso interrompe a rotação de certificados, como a alteração atual de certificado das Intermediate CAs. 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.
- Combinar e atualizar certificados de CA raiz para aplicações Java.
- Abra o repositório raiz de confiança na máquina cliente e exporte a lista de certificados.
- 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 tiver problemas devido ao certificado intermédio mesmo após seguir estes passos, contacte o suporte da Microsoft. Inclua ICA Rotation 2026 no título.
Outras considerações para o TLS
Para além da configuração central do TLS e da gestão de certificados, vários outros fatores influenciam a segurança e o comportamento das ligações encriptadas ao Azure Database para PostgreSQL. Compreender estas considerações ajuda-o a tomar decisões informadas sobre a implementação do TLS no 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 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 as versões TLS 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
Use a versão mais recente 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 cifragem
Um conjunto de cifras é um conjunto de algoritmos que inclui uma cifra, um algoritmo de troca de chaves e um algoritmo de hash. Use-os juntamente 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, ocorrem os seguintes passos:
- O cliente envia uma lista de conjuntos de cifras aceitáveis.
- O servidor seleciona o melhor 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).