Conectividade segura com TLS no Banco de Dados do Azure para PostgreSQL

O Banco de Dados do Azure para PostgreSQL impõe a conexão de seus aplicativos cliente a uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL usando o TLS (Transport Layer Security). O TLS é um protocolo padrão do setor que garante conexões de rede criptografadas entre o servidor de banco de dados e os aplicativos cliente. O TLS é um protocolo atualizado do protocolo SSL. Os termos SSL e TLS ainda são usados de forma intercambiável.

Cadeias de certificados

Uma cadeia de certificados é uma lista ordenada de certificados que contêm um certificado TLS/SSL e certificados de AC. Eles permitem que o receptor verifique se o remetente e todas as ACs são confiáveis. A cadeia ou caminho começa com o certificado TLS/SSL. Cada certificado na cadeia é assinado pela entidade identificada pelo próximo certificado na cadeia.

A cadeia termina com um certificado da AC raiz. Esse certificado sempre é assinado pela própria AC. As assinaturas de todos os certificados na cadeia precisam ser verificadas até chegar ao certificado de AC raiz.

Qualquer certificado que esteja na cadeia entre o certificado TLS/SSL e o certificado de AC raiz é chamado de certificado intermediário.

Versões do TLS

Várias entidades governamentais em todo o mundo mantêm diretrizes para TLS em relação à segurança de rede. Nos Estados Unidos, essas organizações incluem o Ministério da Saúde e Serviços Humanos e o National Institute of Standards and Technology. O nível de segurança que o TLS fornece é mais afetado pela versão do protocolo TLS e pelos pacotes de criptografia com suporte.

Um conjunto de criptografias é um conjunto de algoritmos que incluem uma criptografia, um algoritmo de troca de chaves e um algoritmo de hash. Eles só são usados em conjunto para estabelecer uma conexão TLS segura. A maioria dos clientes e servidores TLS dá suporte a várias alternativas. Eles precisam negociar quando estabelecem uma conexão segura para selecionar uma versão do TLS em comum e um conjunto de criptografia.

O Banco de Dados do Azure para PostgreSQL oferece suporte ao TLS 1.2 e posterior. Na RFC 8996, a IETF (Internet Engineering Task Force) declara explicitamente que o TLS 1.0 e o TLS 1.1 não devem ser usados. Ambos os protocolos foram preteridos no final de 2019.

Todas as conexões de entrada que usarem versões anteriores do protocolo TLS, como o TLS 1.0 e TLS 1.1, são negadas por padrão.

O IETF lançou a especificação TLS 1.3 no RFC 8446 em agosto de 2018 e agora o TLS 1.3 é a versão do TLS mais comum e recomendada em uso. O TLS 1.3 é mais rápido e seguro do que o TLS 1.2.

A autenticação do certificado é realizada usando certificados de cliente SSL para autenticação. Nesse cenário, o servidor PostgreSQL compara o atributo CN (nome comum) do certificado do cliente apresentado em relação ao usuário de banco de dados solicitado.

No momento, o Banco de Dados do Azure para PostgreSQL não dá suporte a:

• Autenticação baseada em certificado SSL.
• Certificados SSL/TLS personalizados.

Para determinar o seu status de conexão TLS\SSL atual, você pode carregar a extensão sslinfo e chamar a função ssl_is_used() para determinar se o SSL está sendo usado. A função retornará t se a conexão estiver usando SSL. Caso contrário, ele retornará f. Você também pode coletar todas as informações sobre o uso SSL da instância de servidor flexível do Banco de Dados do Azure para PostgreSQL por processo, cliente e aplicativo usando a seguinte consulta:

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

Para testar, você também pode usar o comando openssl diretamente:

openssl s_client -starttls postgres -showcerts -connect <your-postgresql-server-name>:5432

Esse comando imprime várias informações de protocolo de baixo nível, como a versão do TLS e a criptografia. Você deve usar a opção -starttls postgres. Caso contrário, esse comando informa que nenhum SSL está em uso. O uso desse comando requer pelo menos o OpenSSL 1.1.1.

Para impor a versão mais recente e segura do TLS para proteção de conectividade do cliente a uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, defina ssl_min_protocol_version como 1.3. Essa configuração exige que os clientes que se conectam à instância de servidor flexível do Banco de Dados do Azure para PostgreSQL usem essa versão do protocolo apenas para se comunicarem com segurança. Os clientes mais antigos podem não conseguir se comunicar com o servidor porque não dão suporte a essa versão.

Configurar o SSL no 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. Todas as opções de SSL têm sobrecarga na forma de criptografia e troca de chaves, portanto, uma compensação é feita entre desempenho e segurança.

Para evitar falsificação, a verificação de certificado SSL no cliente deve ser usada.

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

• ssl: conectar usando SSL. Essa propriedade não precisa de um valor associado a ela. A simples presença dele especifica uma conexão SSL. Para compatibilidade com versões futuras, o valor true é preferencial. Nesse modo, ao estabelecer uma conexão SSL, o driver do cliente valida a identidade do servidor impedindo ataques man-in-the-middle. Ele verifica se o certificado do servidor é assinado por uma autoridade confiável e se o host ao qual você está se conectando é o mesmo que o nome do host no certificado.

• 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 SSL para esse endereço IP/host e que o servidor reconheça o certificado do cliente. Se o servidor não aceitar conexões SSL ou se o certificado do cliente não for reconhecido, a conexão falhará. A tabela a seguir lista os valores para essa configuração:

  Modo SSL	Explanation
  disable	A criptografia não é usada.
  allow	A criptografia será usada se as configurações do servidor a exigirem ou aplicá-la.
  prefer	A criptografia será usada se as configurações do servidor permitirem isso.
  require	A criptografia é usada. Isso garante que o servidor esteja configurado para aceitar conexões SSL para esse endereço IP/host e que o servidor reconheça o certificado do cliente.
  verify-ca	A criptografia é usada. Verifica a assinatura do certificado do servidor em relação ao certificado armazenado no cliente.
  verify-full	A criptografia é usada. Verifica a assinatura do certificado do servidor e do nome do host em relação ao certificado armazenado no cliente.

O modo sslmode padrão usado é diferente entre clientes baseados em libpq (como psql) e JDBC. Os clientes baseados em libpq usam prefer como padrão. Os clientes JDBC usam verify-full como padrão.

• 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.

As ACs são as instituições responsáveis pela emissão de certificados. Uma autoridade de certificação confiável é uma entidade que tem o direito de verificar se alguém é quem diz ser. Para que esse modelo funcione, todos os participantes devem concordar com um conjunto de ACs confiáveis. Todos os sistemas operacionais e a maioria dos navegadores da Web são fornecidos com um conjunto de ACs confiáveis.

O uso de definições de configuração verify-ca e verify-fullsslmode também é conhecido como anexação de certificado. Nesse caso, os certificados de AC raiz no servidor do PostgreSQL precisam corresponder à assinatura do certificado e até mesmo ao nome do host com o certificado no cliente.

Você pode precisar atualizar periodicamente os certificados armazenados do cliente quando as ACs mudarem ou expirarem nos certificados do servidor PostgreSQL. Para determinar se você está anexando ACs, veja Anexação de certificados e serviços do Azure.

Para obter mais informações sobre a configuração do SSL\TLS no cliente, veja a documentação do PostgreSQL.

Para os clientes que usam as definições de configuração verify-ca e verify-fullsslmode (ou seja, anexação de certificado), eles devem implantar três certificados de AC raiz nos repositórios de certificados do cliente:

• Os certificados de AC raiz DigiCert Global Root G2 e Microsoft RSA Root CA 2017, pois os serviços estão migrando do AC do Digicert para a Microsoft.
• Digicert Global Root CA para compatibilidade herdada.

Baixar certificados de AC raiz e atualizar clientes de aplicativo em cenários de anexação de certificados

Para atualizar aplicativos cliente em cenários de anexação de certificados, você pode baixar os certificados:

• Microsoft RSA Root CA 2017
• DigiCert Global Root G2
• Digicert Global Root CA

Para importar certificados para os repositórios de certificados do cliente, talvez seja necessário converter os arquivos .crt do certificado para o formato .pem após o download dos arquivos de certificado dos URIs anteriores. Você pode usar o utilitário OpenSSL para fazer essas conversões de arquivo:

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

Informações sobre a atualização dos repositórios de certificados dos aplicativos cliente com novos certificados de AC raiz são documentadas em Atualizar certificados TLS cliente para clientes de aplicativo.

1. Experiência de perda de conectividade do aplicativo cliente para a instância de servidor flexível do Banco de Dados do Azure para PostgreSQL - tíquete de suporte aberto.
2. Se o certificado intermediário tiver sido rotacionado, talvez seja necessário atualizar o repositório de certificados do cliente com o novo certificado intermediário.
3. como verificar se você está anexando seu certificado intermediário - consulte Anexação de certificado e serviços do Azure.

Réplicas de leitura com cenários de anexação de certificados

Com a migração da AC raiz para Microsoft RSA Root CA 2017, é viável que as réplicas recém-criadas estejam em um certificado de AC raiz mais recente do que o servidor primário criado anteriormente. Para os clientes que usam as definições de configuração verify-ca e verify-fullsslmode (ou seja, a anexação de certificados) é necessário que a conectividade interrompida aceite três certificados da AC raiz:

• Microsoft RSA Root CA 2017
• DigiCert Global Root G2
• Digicert Global Root CA

No momento, o Banco de Dados do Azure para PostgreSQL não dá suporte à autenticação baseada em certificado.

Testar certificados de cliente conectando-se com psql em cenários de anexação de certificado

Você pode usar a linha de comando psql do cliente para testar a conectividade com o servidor em cenários de anexação de certificado:

$ psql "host=hostname.postgres.database.azure.com port=5432 user=myuser dbname=mydatabase sslmode=verify-full sslcert=client.crt sslkey=client.key sslrootcert=ca.crt"

Para obter mais informações sobre parâmetros de certificado e SSL, consulte a documentação do psql.

Testar conectividade TLS/SSL

Antes de tentar acessar o servidor habilitado para SSL do aplicativo cliente, verifique se você pode acessá-lo por meio de psql. Se tiver estabelecido uma conexão SSL, você deverá ver uma saída semelhante ao seguinte exemplo:

psql (14.5)Conexão SSL (protocolo: TLSv1.2, criptografia: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compactação: desativada)Digite "ajuda" para obter ajuda.

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

Conjuntos de criptografia

Um conjunto de criptografias é um conjunto de algoritmos criptográficos. Os protocolos TLS/SSL usam algoritmos de um pacote de criptografia para criar chaves e criptografar informações.

Um conjunto de criptografia é exibido como uma longa cadeia de caracteres de informações aparentemente aleatórias, mas cada segmento dessa cadeia de caracteres contém informações essenciais. Em geral, essa cadeia de caracteres de dados inclui vários componentes principais:

• Protocolo (ou seja, TLS 1.2 ou TLS 1.3)
• Algoritmo de troca de chaves ou contrato
• Algoritmo de assinatura digital (autenticação)
• Algoritmo de criptografia em massa
• Algoritmo do MAC (Message Authentication Code)

Diferentes versões do TLS/SSL dão suporte a diferentes conjuntos de criptografia. Os conjuntos de criptografia TLS 1.2 não podem ser negociados com conexões TLS 1.3 e vice-versa.

Neste momento, o Banco de Dados do Azure para PostgreSQL dá suporte a muitos pacotes de criptografia com a versão do protocolo TLS 1.2 que se enquadra na categoria HIGH:!aNULL .

Troubleshoot

Use as diretrizes nesta seção solução de problemas para identificar e resolver rapidamente problemas comuns de TLS/SSL. Comece reproduzindo o problema e coletando dados de diagnóstico (mensagens de erro do lado do cliente, saída psql, saída de s_client OpenSSL e logs de servidor), verifique os parâmetros do servidor (require_secure_transport, ssl_min_protocol_version, ssl_max_protocol_version), a cadeia de certificados e as configurações de sslmode/sslrootcert do cliente para identificar incompatibilidades em versões de protocolo, conjuntos de criptografia ou certificados ausentes/girados.

Erros de conectividade TLS/SSL

1. A primeira etapa para solucionar problemas de compatibilidade de versão do protocolo TLS/SSL é identificar as mensagens de erro que você ou seus usuários estão vendo quando tentam acessar a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL na criptografia TLS do cliente. Dependendo do aplicativo e da plataforma, as mensagens de erro podem ser diferentes. Em muitos casos, elas apontam para a questão subjacente.
2. Para confirmar a compatibilidade de versão do protocolo TLS/SSL, verifique a configuração do TLS/SSL do servidor do banco de dados e do cliente do aplicativo para garantir que eles ofereçam suporte a versões compatíveis e pacotes de criptografia.
3. Analise quaisquer discrepâncias ou lacunas entre o servidor de banco de dados e as versões de TLS/SSL do cliente e conjuntos de criptografia. Tente resolvê-las habilitando ou desabilitando determinadas opções, fazendo upgrade ou downgrade de software ou alterando certificados ou chaves. Por exemplo, talvez seja necessário habilitar ou desabilitar versões específicas do TLS/SSL no servidor ou no cliente, dependendo dos requisitos de segurança e compatibilidade. Por exemplo, talvez seja necessário desabilitar o TLS 1.0 e o TLS 1.1, que são considerados não seguros e preteridos, e habilitar o TLS 1.2 e o TLS 1.3, que são mais seguros e modernos.
4. O certificado mais recente emitido com Microsoft RSA Root CA 2017 tem intermediário na cadeia com assinatura cruzada pela AC Digicert Global Root G2. Algumas das bibliotecas cliente do Postgres, ao usar a configuração sslmode=verify-full ou sslmode=verify-ca, podem apresentar falhas de conexão com certificados AC raiz que têm assinatura cruzada entre certificados intermediários. O resultado são caminhos de confiança alternativos.

Para contornar esses problemas, adicione todos os três certificados necessários ao repositório de certificados do cliente ou 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.

Problemas de anexação de certificado

1. Verifique se você está usando a anexação de certificado em seu aplicativo.
2. Produzir a lista de certificados que estão em seu repositório raiz confiável
   1. Por exemplo, você pode obter uma lista de certificados confiáveis no Repositório de Chaves Java programaticamente.
   2. Por exemplo, você pode verificar o repositório de chaves java cacerts para ver se ele já contém certificados necessários.
3. Você está usando anexação de certificado, se tiver certificados intermediários individuais ou certificados de servidor PostgreSQL individuais.
4. Para remover a anexação de certificado, remova todos os certificados do repositório raiz confiável e adicione os novos certificados.
   1. Você pode baixar os certificados atualizados do repositório oficial da Microsoft: detalhes da Autoridade de Certificação do Azure.
      1. Cadeia atual:
         1. DigiCert Global Root G2
         2. Autoridade de Certificação RSA TLS do Microsoft Azure 03 / 04 / 07 / 08
      2. Nova rede
         1. DigiCert Global Root G2
         2. Microsoft TLS RSA Root G2
         3. Microsoft TLS G2 RSA CA OCSP 02/04/06/08 /10/12 /14/16

Se você estiver enfrentando problemas mesmo após seguir estas etapas, entre em contato com o suporte da Microsoft. Inclua no título ICA Rotation 2026.

Conteúdo relacionado

• Portal do Azure
• Azure CLI
• Portal do Azure
• Azure CLI