Conectividade segura com TLS e SSL no Banco de Dados do Azure para PostgreSQL - Servidor Flexível

APLICA-SE A: Banco de Dados do Azure para PostgreSQL – Servidor Flexível

O Banco de Dados do Azure para PostgreSQL – Servidor Flexível impõe o uso do protocolo TLS para conectar os aplicativos cliente ao Banco de Dados do Azure para PostgreSQL – Servidor Flexível. 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.

O que é TLS? 

O TLS foi feito a partir do protocolo SSL do Netscape e o substituiu regularmente. Os termos SSL ou TLS/SSL ainda são usados de forma intercambiável. O TLS é feito de duas camadas: o programa de registros TLS e o programa do handshake do TLS. O programa de registros fornece segurança de associação. O programa de handshake capacita o servidor e o cliente a afirmar uns aos outros e coordenar avaliações de criptografia e chaves criptográficas antes que qualquer informação seja trocada.

O diagrama anterior mostra uma sequência de handshake do TLS 1.2 típica, que consiste nessas etapas:

1. O cliente começa enviando uma mensagem chamada ClientHello, que expressa a vontade de se comunicar por meio do TLS 1.2 com um conjunto de pacotes de criptografia que o cliente dá suporte.
2. O servidor recebe a mensagem, responde com ServerHello, e concorda em se comunicar com o cliente por meio do TLS 1.2 usando um conjunto de criptografia específico.
3. O servidor também envia seu compartilhamento de chaves. As especificidades desse compartilhamento de chaves mudam com base em qual conjunto de criptografia foi selecionado. Para o cliente e o servidor concordarem com uma chave criptográfica, eles precisam receber a parte um do outro, ou compartilhar.
4. O servidor envia o certificado (assinado pela autoridade de certificação [AC]) e uma assinatura em partes de ClientHello e ServerHello. Ele também inclui o compartilhamento de chaves. Dessa forma, o cliente sabe que é autêntico.
5. Depois que o cliente recebe com êxito os dados e depois gera seu próprio compartilhamento de chaves, ele o mistura com o compartilhamento de chaves do servidor para gerar as chaves de criptografia para a sessão.
6. O cliente envia ao servidor seu compartilhamento de chaves, habilita a criptografia e envia uma mensagem de Finished. Esta mensagem é um código hash de uma transcrição do que aconteceu até agora. O servidor faz o mesmo. Ele combina os compartilhamentos de chave para obter a chave e envia sua própria mensagem de Finished.
7. Agora, os dados do aplicativo podem ser enviados criptografados para a conexão.

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

Observação

Certificados SSL e TLS certificam que sua conexão é protegida com protocolos de criptografia de ponta. Ao criptografar a conexão na rede, você impede o acesso não autorizado aos seus dados em trânsito. Recomendamos usar versões mais recentes do TLS para criptografar suas conexões com o Banco de Dados do Azure para PostgreSQL – Servidor Flexível.

Embora não seja recomendado, se necessário, você pode desabilitar o TLS\SSL para conexões com o Banco de Dados do Azure para PostgreSQL – Servidor Flexível. Você pode atualizar o parâmetro do servidor require_secure_transport para OFF. Você também pode definir a versão do TLS definindo os parâmetros do servidor ssl_min_protocol_version e ssl_max_protocol_version.

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 – Servidor Flexível não dá suporte:

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

Observação

A Microsoft fez alterações de AC raiz para vários serviços do Azure, incluindo o Banco de Dados do Azure para PostgreSQL – Servidor Flexível. Para obter mais informações, consulte Alterações de certificado TLS do Azure e a seção Configurar o SSL no cliente.

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. Também é possível coletar todas as informações sobre o uso de SSL do 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 ao Banco de Dados do Azure para PostgreSQL – Servidor Flexível, defina ssl_min_protocol_version como 1.3. Essa configuração exige que os clientes se conectem ao servidor flexível do Banco de Dados do Azure para PostgreSQL para usar 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	Explicação
  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 usam /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8 e /defaultdir/root.crt como padrão, respectivamente, em que defaultdir é ${user.home}/.postgresql/ em sistemas nix e %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-full sslmode 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, consulte Anexação de certificados e serviços do Azure.

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

Para clientes que usam definições de configuração verify-ca e verify-full sslmode (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.

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.

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 réplicas recém-criadas estejam em um certificado de AC raiz mais recente do que o servidor primário criado anteriormente. Para clientes que usam as definições de configuração verify-ca e verify-full sslmode (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 – Servidor flexível 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 cifras é 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 (código de autenticação de mensagem)

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.

Atualmente, o Banco de Dados do Azure para PostgreSQL – Servidor Flexível dá suporte a muitos conjuntos de criptografia com a versão do protocolo TLS 1.2 que se enquadra na categoria HIGH:!aNULL.

Solucionar erros comuns 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 ao tentar acessar o Banco de Dados do Azure para PostgreSQL – Servidor Flexível 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.

Conteúdo relacionado

• Saiba como criar um servidor flexível do Banco de Dados do Azure para PostgreSQL por meio da opção Acesso privado (integração VNET) no portal do Azure ou na CLI do Azure.
• Saiba como criar um servidor flexível do Banco de Dados do Azure para PostgreSQL usando a opção Acesso público (Endereços IP permitidos) no portal do Azure ou na CLI do Azure.