Compartilhar via

Conecte clientes com segurança TLS ao banco de dados

Visão geral

As conexões entre seus aplicativos cliente e o servidor de banco de dados são sempre criptografadas usando o TLS (Transport Layer Security) padrão do setor, anteriormente conhecido como SSL (Secure Sockets Layer).

Observação

O PostgreSQL de código aberto usa o nome herdado SSL em seus comandos, variáveis e documentação para evitar o rompimento de implementações existentes. Este documento usa o acrônimo TLS ao usar SSL em nomes de comando e variáveis.

O Banco de Dados do Azure para PostgreSQL dá suporte a conexões criptografadas usando TLS 1.2 e 1.3. Todas as conexões de entrada que tentam criptografar o tráfego usando o TLS 1.0 e o TLS 1.1 são negadas.

Por padrão, a conectividade protegida entre o cliente e o servidor é imposta. Se você quiser desabilitar a imposição do TLS, permitindo comunicações de cliente criptografadas e não criptografadas, você poderá alterar o parâmetro require_secure_transport do servidor para OFF. Você também pode definir a versão do TLS definindo o parâmetro do servidor ssl_max_protocol_version. Aconselhamos a não desabilitar o TLS.

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.

Configuração do TLS do cliente

Por padrão, o PostgreSQL não realiza 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 essa falsificação, a verificação de certificado TLS no cliente deve ser usada.

Há muitos parâmetros de conexão para configurar o cliente para TLS. Alguns importantes são:

  • ssl: conecte-se usando TLS. Essa propriedade não precisa de um valor associado a ela. A simples presença dele especifica uma conexão TLS. Para compatibilidade com versões futuras, o valor true é preferencial. Nesse modo, quando você está estabelecendo uma conexão TLS, o driver 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 ela não puder ser criptografada, defina sslmode=require. Essa configuração garante que o servidor esteja configurado para aceitar conexões TLS para esse endereço IP/host e que o servidor reconheça o certificado do cliente. Se o servidor não aceitar conexões TLS ou o certificado do cliente não for reconhecido, a conexão falhará. A tabela a seguir lista os valores para essa configuração:

    sslmode Explanation
    disable A criptografia não é usada. O Banco de Dados do Azure para PostgreSQL requer conexões TLS; portanto, essa configuração não deve ser usada.
    allow A criptografia será usada se as configurações do servidor a exigirem ou aplicá-la. O Banco de Dados do Azure para PostgreSQL requer conexões TLS; portanto, essa configuração é equivalente a prefer.
    prefer A criptografia será usada se as configurações do servidor permitirem isso. O Banco de Dados do Azure para PostgreSQL requer conexões TLS.
    require A criptografia é usada. Ele garante que o servidor esteja configurado para aceitar conexões TLS.
    verify-ca A criptografia é usada. Verifique o certificado do servidor em relação aos certificados raiz confiáveis armazenados no cliente.
    verify-full A criptografia é usada. Verifique o certificado do servidor no certificado armazenado no cliente. Ele também valida que os certificados do servidor usam o mesmo nome de host que a conexão. Recomendamos essa configuração, a menos que resolvedores DNS privados usem um nome diferente para fazer referência ao servidor do Banco de Dados do Azure para PostgreSQL.

O modo padrão sslmode usado é diferente entre clientes baseados em libpq, como PSQL e JDBC. Os clientes baseados em libpq usam prefer como padrão. JDBC clientes são configurados para usar verify-full.

  • sslcert, sslkey e 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 são padrão para /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8, e /defaultdir/root.crt, respectivamente, onde defaultdir corresponde a ${user.home}/.postgresql/ em sistemas Linux e a %appdata%/postgresql/ no Windows.

Importante

Algumas das bibliotecas cliente do Postgres, ao usar a configuração sslmode=verify-full, podem apresentar falhas de conexão com certificados AC raiz que são assinados entre certificados intermediários. O resultado são caminhos de confiança alternativos. Nesse caso, recomendamos que você especifique explicitamente o parâmetro sslrootcert. Ou defina a variável de ambiente PGSSLROOTCERT para um caminho local em que o certificado de AC raiz Microsoft RSA Root CA 2017 seja definido, do valor padrão de %APPDATA%\postgresql\root.crt.

Instalar autoridades de certificação raiz confiáveis (CAs)

Baixar e converter certificados de autoridade de certificação raiz (AC raiz)

Para clientes Windows que utilizam o repositório de certificados do sistema para certificados raiz confiáveis, nenhuma ação é necessária, pois o Windows distribui novos certificados raiz de CA pelo Windows Update.

Para clientes Java, a extensão do VS Code e outros clientes (por exemplo, PSQLPerl, ...) que não utilizam o armazenamento do sistema e para clientes no Linux: você precisa baixar e combinar os certificados de CA raiz em um arquivo PEM. No mínimo, inclui os seguintes certificados de AC raiz:

Observação

Para regiões da China e para clientes com extensões de rotação: a AC raiz global Digicert (arquivo PEM) ainda é válida; inclua-a no arquivo PEM combinado.

É altamente recomendável incluir todos os certificados de autoridade de certificação raiz do Azure para reduzir a necessidade de atualizações futuras no arquivo combinado, caso ocorram alterações nos CAs raiz utilizados pelo Azure Database for PostgreSQL. A lista de certificados de AC raiz do Azure pode ser encontrada nos detalhes da Autoridade de Certificação do Azure.

Para importar certificados para repositórios de certificados do cliente, talvez seja necessário converter todos os certificados em formato CRT no formato PEM e concatenar os arquivos PEM em um único arquivo. Você pode usar o utilitário OpenSSL X509 para converter os arquivos CRT em PEM.

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

Combinar certificados de CA raiz em um único arquivo PEM

Para alguns clientes, você concatena todos os arquivos PEM em um único arquivo usando qualquer editor de texto ou ferramenta de linha de comando.

-----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 aplicativos Java

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

  1. Verifique o repositório de chaves Java cacerts para ver se ele já contém certificados necessários. Você pode listar os certificados no repositório 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 no repositório de chaves Java no cliente, como pode ser verificado na saída, você deverá prosseguir com as seguintes instruções:

  2. Faça uma cópia de backup do repositório de chaves personalizado.

  3. Baixe os arquivos de certificado e salve-os localmente onde você pode referenciá-los.

  4. Gere um repositório de certificados de AC combinado com todos os certificados de AC raiz necessários incluídos. O exemplo a seguir mostra o uso de DefaultJavaSSLFactory para usuários Java do 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 certificados de AC raiz nos Serviços de Aplicativos do Azure

Para os Serviços de Aplicativos do Azure, ao conectar-se a uma instância flexível do Banco de Dados do Azure para PostgreSQL, podemos ter dois cenários possíveis para a atualização dos certificados do cliente, dependendo de como você está utilizando o SSL com seu aplicativo implantado nos Serviços de Aplicativos do Azure.

  • Novos certificados são adicionados ao Serviço de Aplicativo no nível da plataforma antes que ocorram alterações na 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, precisará baixar o novo certificado e atualizar o código para usá-lo.

Atualizar os certificados de AC raiz ao usar clientes no Serviço de Kubernetes do Azure (AKS)

Se você estiver tentando se conectar ao Banco de Dados do Azure para PostgreSQL usando aplicativos hospedados no AKS (Serviços de Kubernetes do Azure), será semelhante ao acesso do ambiente de host de um cliente dedicado. Consulte as instruções detalhadas na documentação do AKS.

Atualizar certificados de Autoridades de Certificação Raiz para usuários do .NET (Npgsql) no Windows

Para usuários do .NET (Npgsql) no Windows, ao conectar-se às instâncias de servidor flexível do Banco de Dados do Azure para PostgreSQL, certifique-se de que todos os certificados de Autoridade Certificadora Raiz estão incluídos no Repositório de Certificados do Windows, Autoridades de Certificação Raiz Confiáveis. Windows Update mantém a lista padrão de CAs raiz do Azure. Se quaisquer certificados listados em nossa configuração recomendada não forem incluídos, importe os certificados ausentes.

Como usar o TLS com validação de certificado

Algumas estruturas de aplicativo que usam o PostgreSQL para seus serviços de banco de dados não habilitam o TLS por padrão durante a instalação. Sua instância do Banco de Dados do Azure para PostgreSQL impõe conexões TLS, mas se o aplicativo não estiver configurado para TLS, o aplicativo poderá falhar. Confira a documentação de seu aplicativo para saber como habilitar conexões TLS.

Conectar usando PSQL

O exemplo a seguir mostra como se conectar ao servidor usando a PSQL interface de linha de comando. Use a configuração de cadeia de conexão sslmode=verify-full ou sslmode=verify-ca para garantir a verificação de certificado TLS. Passe o caminho do arquivo de certificado local para o parâmetro sslrootcert.

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

Testar a conectividade do TLS

Antes de tentar acessar o servidor habilitado para TLS de um aplicativo cliente, verifique se você pode acessá-lo por meio de PSQL. Se você estabeleceu uma conexã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.

Você também pode carregar a extensão sslinfo e, em seguida, chamar a ssl_is_used() função para determinar se o TLS está sendo usado. A função retornará t se a conexão estiver usando TLS. Caso contrário, ele retornará f.

Obter uma lista de certificados confiáveis no Repositório de Chaves Java 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-o 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