Partilhar via

Liga clientes com segurança TLS à tua base de dados

As ligações entre as suas aplicações clientes e o servidor de base de dados utilizam sempre encriptação com o padrão industrial Transport Layer Security (TLS), anteriormente conhecido como Secure Sockets Layer (SSL).

Observação

O PostgreSQL de código aberto utiliza o nome legado SSL nos seus comandos, variáveis e documentação para evitar quebrar implementações existentes. Este artigo utiliza o acrónimo TLS ao usar SSL nos nomes e variáveis dos comandos.

Azure Database for PostgreSQL suporta ligações encriptadas utilizando TLS 1.2 e 1.3. O servidor nega todas as ligações de entrada que tentem encriptar o tráfego usando TLS 1.0 e TLS 1.1.

Por defeito, o servidor impõe a conectividade segura entre o cliente e o servidor. Para desativar esta imposição e permitir as comunicações encriptadas e não encriptadas de clientes, altere o parâmetro require_secure_transport do servidor para OFF. Também podes definir a versão TLS definindo o ssl_max_protocol_version parâmetro do servidor. Não desatives TLS.

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.

Configuração do cliente TLS

Por defeito, o PostgreSQL não verifica o certificado do servidor. Devido a este comportamento padrão, o cliente não consegue detetar se a identidade do servidor está suplantada (por exemplo, se alguém modificar um registo DNS ou assumir o endereço IP do servidor). Para evitar este tipo de falsificação, ative a verificação do certificado TLS no cliente.

Podes configurar muitos parâmetros de ligação para a configuração TLS do cliente. Alguns importantes incluem:

  • ssl: Liga-te usando TLS. Esta propriedade não precisa de valor. A sua presença especifica uma ligação TLS. Para compatibilidade com versões futuras, use o valor true. Neste modo, quando estabeleces uma ligação TLS, o driver do cliente valida a identidade do servidor para evitar ataques man-in-the-middle.

  • sslmode: Defina este parâmetro para require se precisar de encriptação e quiser que a ligação falhe se não puder ser encriptada. Esta configuração garante que o servidor está configurado para aceitar ligações TLS para este host ou endereço IP e que o servidor reconhece o certificado do cliente. Se o servidor não aceitar ligações TLS ou o certificado do cliente não for reconhecido, a ligação falha. A tabela a seguir lista valores para essa configuração:

    sslmode Explanation
    disable A encriptação não é utilizada. O Azure Database para PostgreSQL requer ligações TLS, por isso não uses esta configuração.
    allow A criptografia é usada se as configurações do servidor exigirem ou a impuserem. O Azure Database para PostgreSQL requer ligações TLS, por isso esta configuração é equivalente a prefer.
    prefer A criptografia é usada se as configurações do servidor permitirem. O Azure Database para PostgreSQL requer ligações TLS.
    require A encriptação é usada. Garante que o servidor está configurado para aceitar ligações TLS.
    verify-ca A encriptação é usada. Verifique o certificado do servidor em relação aos certificados raiz de confiança armazenados no cliente.
    verify-full A encriptação é usada. Verifica o certificado do servidor com o certificado armazenado no cliente. Também valida que os certificados do servidor usam o mesmo nome de host que a ligação. Use esta definição, a menos que resolvers DNS privados usem um nome diferente para referenciar a Azure Database para o servidor PostgreSQL.

O modo por defeito sslmode difere entre os clientes baseados em libpq (como PSQL e JDBC). O padrão dos clientes baseados em libpq é .prefer JDBC os clientes utilizam por padrão verify-full.

  • sslcert, sslkey, e sslrootcert: Estes parâmetros sobrepõem a localização padrão do certificado cliente, a chave cliente PKCS-8 e o certificado raiz. Eles têm como padrão /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8 e /defaultdir/root.crt, respectivamente, sendo que defaultdir é ${user.home}/.postgresql/ em sistemas Linux e %appdata%/postgresql/ em sistemas Windows.

Importante

Algumas bibliotecas clientes Postgres podem falhar ao ligar-se ao usar a sslmode=verify-full configuração com certificados de CA raiz que assinam de forma cruzada certificados intermédios. Esta configuração resulta em caminhos de confiança alternativos. Neste caso, especifique explicitamente o sslrootcert parâmetro. Ou defina a PGSSLROOTCERT variável de ambiente como um caminho local onde o certificado de autoridade de certificação raiz Microsoft RSA 2017 é colocado, a partir do valor padrão de %APPDATA%\postgresql\root.crt.

Instalar Autoridades Certificadoras Raiz (CAs) confiáveis

Descarregue e converta certificados de CA raiz

Para os clientes Windows que utilizam a loja de certificados do sistema para certificados raiz de confiança, não é necessária qualquer ação, pois o Windows implementa novos certificados de CA raiz através do Windows Update.

Para clientes Java, a extensão VS Code, e outros clientes (por exemplo, PSQLPerl) que não usam a loja do sistema, e para clientes em Linux: é necessário descarregar e combinar os certificados de CA raiz num ficheiro PEM. No mínimo, inclua os seguintes certificados de CA raiz:

Observação

Para regiões da China e para clientes com extensões de rotação: o Digicert Global Root CA (ficheiro pem) continua válido; inclua-o no ficheiro PEM combinado.

Inclua todos os certificados de CA raiz do Azure para reduzir a necessidade de futuras atualizações do ficheiro combinado caso haja alterações nas CAs raiz usadas pelo Azure Database para PostgreSQL. Pode encontrar a lista de certificados de CA raiz do Azure em detalhes da Azure Certificate Authority.

Para importar certificados para os repositórios de certificados dos clientes, pode ser necessário converter quaisquer certificados em formato CRT para formato PEM e concatenar os ficheiros PEM num único ficheiro. Podes usar a utilidade OpenSSL X509 para converter os ficheiros CRT em PEM.

openssl x509 -inform DER -in certificate-filename.crt -out certificate-filename.pem -outform PEM

Combinar certificados de CA raiz num único ficheiro PEM

Para alguns clientes, concatenas todos os ficheiros PEM num único ficheiro usando qualquer editor de texto ou ferramenta de linha de comandos.

-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----

Para regiões da China e para clientes com extensões de rotação:

-----BEGIN CERTIFICATE-----
(Root CA0 content: DigiCertGlobalRootCA.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----

Combinar e atualizar certificados de CA raiz para aplicações Java

Aplicações Java personalizadas utilizam um keystore predefinido chamado cacerts, que contém certificados de autoridade certificadora (CA) de confiança. O ficheiro de certificados cacerts reside no diretório de propriedades de segurança em java.home\lib\security, onde java.home é o diretório do ambiente de execução (o diretório jre no SDK ou o diretório principal do Ambiente de Execução Java™ 2). Para atualizar os certificados raiz da CA do cliente para cenários de fixação de certificados do cliente com PostgreSQL, use as seguintes direções:

  1. Verifica a cacerts loja de chaves Java para ver se já contém os certificados necessários. Pode listar certificados na loja de chaves Java usando o seguinte comando:

    keytool -list -v -keystore ..\lib\security\cacerts > outputfile.txt

    Se os certificados necessários não estiverem presentes na loja de chaves Java do cliente, como pode verificar na saída, siga as seguintes instruções:

  2. Faça uma cópia de backup do seu keystore personalizado.

  3. Descarregue os ficheiros de certificados e guarde-os localmente onde possa consultá-los.

  4. Gerar um armazenamento combinado de certificados de CA que inclua todos os certificados de CA raiz necessários. O exemplo seguinte mostra o uso do DefaultJavaSSLFactory para utilizadores de Java PostgreSQL.

    keytool -importcert -alias PostgreSQLServerCACert  -file "DigiCertGlobalRootG2.crt.pem" -keystore truststore -storepass password -noprompt

keytool -importcert -alias PostgreSQLServerCACert2  -file "Microsoft ECC Root Certificate Authority 2017.crt.pem" -keystore truststore -storepass password  -noprompt

...

Atualizar os certificados root CA no Azure App Services

Para os Azure App Services que se ligam a uma base de dados Azure para uma instância de servidor flexível PostgreSQL, existem dois cenários possíveis para atualizar certificados de cliente. Os cenários dependem de como está a usar SSL com a sua aplicação implementada no Azure App Services.

  • Adicione novos certificados ao App Service ao nível da plataforma antes de ocorrerem alterações na sua Base de Dados Azure para a instância de servidor flexível PostgreSQL. Se você estiver usando os certificados SSL incluídos na plataforma do Serviço de Aplicativo em seu aplicativo, nenhuma ação será necessária. Para mais informações, consulte Adicionar e gerir certificados TLS/SSL no Azure App Service na documentação do Azure App Service.
  • Se estiveres a incluir explicitamente o caminho para um ficheiro de certificado SSL no teu código, precisas de descarregar o novo certificado e atualizar o código para o usares.

Atualize os certificados de CA raiz ao utilizar clientes no Azure Kubernetes Service (AKS)

Se está a tentar ligar-se à base de dados Azure para PostgreSQL usando aplicações alojadas no Azure Kubernetes Services (AKS), é semelhante ao acesso a partir do ambiente host dedicado de um cliente. Consulte as instruções detalhadas na documentação do AKS.

Atualizar certificados de CA raiz para utilizadores .NET (Npgsql) no Windows

Para utilizadores .NET (Npgsql) no Windows que se ligam à Azure Database para instâncias flexíveis de servidor PostgreSQL, certifique-se de que todos os certificados de CA raiz estão incluídos na Loja de Certificados do Windows em Autoridades de Certificação Raiz Confiáveis. O Windows Update mantém a lista padrão de CA raiz do Azure. Se algum certificado listado na configuração recomendada não estiver incluído, importe os certificados em falta.

Como usar TLS com validação de certificados

Algumas estruturas de aplicativos que usam PostgreSQL para seus serviços de banco de dados não habilitam o TLS por padrão durante a instalação. A tua base de dados Azure para a instância PostgreSQL impõe ligações TLS, mas se a aplicação não estiver configurada para TLS, pode falhar. Consulte a documentação do seu aplicativo para saber como habilitar conexões TLS.

Liga-te usando PSQL

O exemplo seguinte mostra como se ligar ao seu servidor usando a PSQL interface de linha de comandos. Utilize a definição de cadeia de conexão sslmode=verify-full ou sslmode=verify-ca para impor a verificação do certificado TLS. Passe o caminho do arquivo de certificado local para o sslrootcert parâmetro.

 psql "sslmode=verify-full sslrootcert=<path-of-pem-file> host=mydemoserver.postgres.database.azure.com dbname=postgres user=myadmin"

Testar conectividade TLS

Antes de tentar aceder ao seu servidor com TLS a partir de uma aplicação cliente, certifique-se de que pode aceder-lhe através de PSQL. Se estabeleceu uma ligação TLS, deverá ver uma saída semelhante ao seguinte exemplo:

psql (14.5)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

Também podes carregar a extensão sslinfo e depois chamar a ssl_is_used() função para determinar se o TLS está a ser usado. A função retorna t se a ligação estiver a usar TLS. Caso contrário, ele retornará f.

Obtenha uma lista de certificados confiáveis no Java Key Store programaticamente

Por defeito, o Java armazena os certificados de confiança num ficheiro especial chamado cacerts que está localizado dentro da pasta de instalação Java no cliente. O exemplo seguinte faz a leitura de cacerts e carrega-o num objeto KeyStore:

private KeyStore loadKeyStore() {
    String relativeCacertsPath = "/lib/security/cacerts".replace("/", File.separator);
    String filename = System.getProperty("java.home") + relativeCacertsPath;
    FileInputStream is = new FileInputStream(filename);
    KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
    String password = "changeit";
    keystore.load(is, password.toCharArray());

    return keystore;
}

A palavra-passe padrão para cacerts é changeit, mas deveria ser diferente num cliente real. Os administradores recomendam alterar a palavra-passe imediatamente após a instalação do Java. Depois de carregar o objeto KeyStore , pode usar a classe PKIXParameters para ler os certificados presentes.

public void whenLoadingCacertsKeyStore_thenCertificatesArePresent() {
    KeyStore keyStore = loadKeyStore();
    PKIXParameters params = new PKIXParameters(keyStore);
    Set<TrustAnchor> trustAnchors = params.getTrustAnchors();
    List<Certificate> certificates = trustAnchors.stream()
      .map(TrustAnchor::getTrustedCert)
      .collect(Collectors.toList());

    assertFalse(certificates.isEmpty());
}

Conteúdo relacionado

  • Last updated on