Partilhar via

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

Visão geral

As ligações entre as suas aplicações clientes e o servidor de base de dados são sempre encriptadas usando o padrão da indústria 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 documento utiliza o acrónimo TLS enquanto utiliza SSL nos nomes e variáveis dos comandos.

Azure Database para PostgreSQL suporta ligações encriptadas usando TLS 1.2 e 1.3. Todas as ligações recebidas que tentam encriptar o tráfego usando TLS 1.0 e TLS 1.1 são negadas.

Por padrão, a conectividade segura entre o cliente e o servidor é imposta. Se quiser desativar a aplicação do TLS, permitindo comunicações cliente encriptadas e não encriptadas, pode alterar o parâmetro require_secure_transport do servidor para OFF. Você também pode definir a versão TLS definindo o ssl_max_protocol_version parâmetro server. Desaconselhamos fortemente a desativação do TLS.

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

  • 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 padrão, o PostgreSQL não executa nenhuma verificação do certificado do servidor. Por esse motivo, é possível falsificar a identidade do servidor (por exemplo, modificando um registro DNS ou assumindo o endereço IP do servidor) sem que o cliente saiba. Para evitar tal falsificação, deve ser utilizada a verificação do certificado TLS no cliente.

Existem muitos parâmetros de ligação para configurar o cliente para o TLS. Alguns aspetos importantes são:

  • ssl: Liga-te usando TLS. Esta propriedade não precisa de um valor associado a ela. A mera presença dela especifica uma ligação TLS. Para compatibilidade com versões futuras, o valor true é preferido. Neste modo, ao estabelecer uma ligação TLS, o driver do cliente valida a identidade do servidor para evitar ataques man-in-the-middle.

  • sslmode: Se você precisar de criptografia e quiser que a conexão falhe se não puder ser criptografada, defina sslmode=require. Esta configuração garante que o servidor está configurado para aceitar ligações TLS para este endereço host/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. Azure Database for PostgreSQL requer ligações TLS; portanto, esta configuração não deve ser utilizada.
    allow A criptografia é usada se as configurações do servidor exigirem ou a impuserem. Azure Database for PostgreSQL requer ligações TLS; portanto, esta definiçã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. Recomendamos esta configuração, a menos que resolvers DNS privados usem um nome diferente para referenciar a Azure Database para o servidor PostgreSQL.

O modo padrão sslmode utilizado é diferente nos 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, sslkeye sslrootcert: Esses parâmetros podem substituir o local padrão do certificado do cliente, a chave do 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 das bibliotecas de cliente Postgres, ao usar a sslmode=verify-full configuração, podem enfrentar falhas de conexão com certificados de CA raiz que são assinados cruzados com certificados intermediários. O resultado são caminhos de confiança alternativos. Nesse caso, recomendamos que você 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 clientes Windows que utilizam a loja de certificados do sistema para certificados raiz confiáveis, não é necessária qualquer ação, pois o Windows implementa novos certificados raiz da CA através do Windows Update.

Para clientes Java, a extensão do VS Code e outros clientes (por exemplo, PSQLPerl, ...) que não utilizam o armazém do sistema, e para clientes em Linux: é necessário fazer download e combinar os certificados raiz da CA num ficheiro PEM. No mínimo, inclui 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.

Recomendamos fortemente incluir 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. A lista de certificados de CA raiz Azure pode ser encontrada em detalhes da Azure Certificate Authority.

Para importar certificados para os armazenamentos 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, concatena-se 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

Aplicativos Java personalizados usam um keystore padrão, chamado cacerts, que contém certificados de autoridade de certificação (CA) confiáveis. Um arquivo de certificados chamado cacerts reside no diretório de propriedades de segurança, java.home\lib\security, onde java.home é o diretório do ambiente de tempo de execução (o jre diretório no SDK ou o diretório de nível superior do Java™ 2 Runtime Environment). Você pode usar as seguintes instruções para atualizar certificados de CA raiz do cliente para cenários de fixação de certificados de cliente com o PostgreSQL:

  1. Verifique cacerts o keystore java para ver se ele já contém os certificados necessários. Você pode listar certificados no keystore Java usando o seguinte comando:

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

    Se os certificados necessários não estiverem presentes no armazenamento de chaves java no cliente, como pode ser verificado na saída, você deve prosseguir com 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. Gere um armazenamento de certificados de CA combinado com todos os certificados de CA raiz necessários incluídos. O exemplo abaixo 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 de CA raiz no Azure App Services

Para os serviços de Aplicativo do Azure, conectando-se a uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, podemos ter dois cenários possíveis na atualização de certificados de cliente e isso depende de como você está usando SSL com seu aplicativo implantado nos Serviços de Aplicativo do Azure.

  • Novos certificados são adicionados ao Serviço de Aplicativo no nível da plataforma antes que ocorram alterações em sua instância de servidor flexível do Banco de Dados do Azure para 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 obter mais informações, consulte Adicionar e gerenciar certificados TLS/SSL no Serviço de Aplicativo do Azure, na documentação do Serviço de Aplicativo do Azure.
  • Se você estiver incluindo explicitamente o caminho para o arquivo de certificado SSL em seu código, será necessário baixar o novo certificado e atualizar o código para usá-lo.

Atualize os certificados da 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 ao Azure Database para instâncias de servidor flexível PostgreSQL, certifique-se de que todos os certificados de CA raiz estão incluídos na Loja de Certificados do Windows, 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 nossa 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 padrão, o Java armazena os certificados confiáveis em um arquivo especial chamado cacerts que está localizado dentro da pasta de instalação Java no cliente. O exemplo abaixo primeiro lê cacerts e carrega no 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 senha padrão para cacerts é changeit , mas deve ser diferente no cliente real, pois os administradores recomendam alterar a senha imediatamente após a instalação do Java. Depois de carregarmos o objeto KeyStore , podemos 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