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 servidor flexível do Banco de Dados do Azure para PostgreSQL impõe a conexão de seus aplicativos cliente ao Servidor flexível do Banco de Dados do Azure para PostgreSQL usando 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. TLS é um protocolo atualizado de Secure Sockets Layer (SSL).

O que é o TLS? 

TLS feito a partir da Netscape Communications Corp's. Secure Sockets Layer mostrar e tem regularmente suplantado, no entanto, os termos SSL ou SSL / TLS ainda são às vezes usados de forma intercambiável. O TLS é feito de duas camadas: o show de registro TLS e o show de handshake TLS. O show de registro dá segurança de associação, enquanto o show de handshake permite que o servidor e o cliente se afirmem e coordenem avaliações de criptografia e chaves criptográficas antes que qualquer informação seja negociada.

O diagrama acima mostra a sequência típica de handshake TLS 1.2, consistindo no seguinte:

1. O cliente começa enviando uma mensagem chamada ClientHello, que essencialmente expressa a vontade de se comunicar via TLS 1.2 com um conjunto de pacotes de codificação suportados pelo cliente
2. O servidor recebe isso e responde com um ServerHello que concorda com a comunicação com o cliente via TLS 1.2 usando um pacote de codificação específico
3. Junto com isso, o servidor envia seu compartilhamento de chave. As especificidades desse compartilhamento de chave mudam com base no conjunto de codificação selecionado. O detalhe importante a ser observado é que, para que o cliente e o servidor concordem 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) e uma assinatura em partes de ClientHello e ServerHello, incluindo o compartilhamento de chaves, para que o cliente saiba que eles são autênticos.
5. Depois que o cliente recebe com êxito os dados acima mencionados e , em seguida , gera seu próprio compartilhamento de chave, mistura-o com o compartilhamento de chave do servidor e, portanto, gera as chaves de criptografia para a sessão.
6. Como etapas finais, o cliente envia ao servidor seu compartilhamento de chaves, habilita a criptografia e envia uma mensagem Concluído (que é um hash de uma transcrição do que aconteceu até agora). O servidor faz o mesmo: mistura os compartilhamentos de chaves para obter a chave e envia sua própria mensagem Concluído.
7. Nesse momento, os dados do aplicativo podem ser enviados criptografados na conexão.

Cadeias de certificados

Uma cadeia de certificados é uma lista ordenada de certificados, contendo um certificado SSL/TLS e certificados de autoridade de certificação (CA), que permite ao recetor verificar se o remetente e todas as autoridades de certificação são confiáveis. A cadeia ou caminho começa com o certificado SSL/TLS e cada certificado na cadeia é assinado pela entidade identificada pelo próximo certificado na cadeia. A cadeia termina com um certificado de autoridade de certificação raiz. O certificado da autoridade de certificação raiz é sempre assinado pela própria autoridade de certificação (CA). As assinaturas de todos os certificados na cadeia devem ser verificadas até o certificado da autoridade de certificação raiz. Qualquer certificado que fique entre o certificado SSL/TLS e o certificado de autoridade de certificação raiz na cadeia é chamado de certificado intermediário.

Versões TLS

Existem várias entidades governamentais em todo o mundo que mantêm diretrizes para TLS em relação à segurança de rede, incluindo o Departamento de Saúde e Serviços Humanos (HHS) ou o Instituto Nacional de Padrões e Tecnologia (NIST) nos Estados Unidos. O nível de segurança que o TLS fornece é mais afetado pela versão do protocolo TLS e pelos pacotes de codificação suportados. Um conjunto de cifras é um conjunto de algoritmos, incluindo uma cifra, um algoritmo de troca de chaves e um algoritmo de hash, que são usados juntos para estabelecer uma conexão TLS segura. A maioria dos clientes e servidores TLS suporta várias alternativas, portanto, eles têm que negociar ao estabelecer uma conexão segura para selecionar uma versão TLS comum e um pacote de codificação.

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

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

A Internet Engineering Task Force (IETF) lançou a especificação TLS 1.3 no RFC 8446 em agosto de 2018 e agora é a versão 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 de certificado é realizada usando certificados de cliente SSL para autenticação. Nesse cenário, o servidor PostgreSQL compara o atributo CN (nome comum) do certificado de cliente apresentado com o usuário do banco de dados solicitado. O servidor flexível do Banco de Dados do Azure para PostgreSQL não oferece suporte à autenticação baseada em certificado SSL no momento.

Para determinar o status atual da conexão TLS\SSL, você pode carregar a extensão sslinfo e, em seguida, chamar a função para determinar se o ssl_is_used() SSL está sendo usado. A função retorna t se a conexão estiver usando SSL, caso contrário, retorna 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 testes, você também pode usar o comando openssl diretamente, por exemplo:

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

Este comando imprime várias informações de protocolo de baixo nível, incluindo a versão TLS, cifra e assim por diante. Você deve usar a opção -starttls postgres, ou caso contrário, este comando informa que nenhum SSL está em uso. Usar este comando requer pelo menos OpenSSL 1.1.1.

Configurando SSL no Cliente

Por padrão, o PostgreSQL não executa nenhuma verificação do certificado do servidor. Isso significa que é 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 SSL carregam sobrecarga na forma de criptografia e troca de chaves, então há um compromisso que deve ser feito entre desempenho e segurança. Para evitar falsificação, a verificação do certificado SSL no cliente deve ser usada. Há muitos parâmetros de conexão para configurar o cliente para SSL. Alguns importantes para nós são:

1. SSL. Conecte-se usando SSL. Esta propriedade não precisa de um valor associado a ela. A mera presença dele especifica uma conexão SSL. No entanto, para compatibilidade com versões futuras, o valor "true" é preferido. Neste modo, ao estabelecer uma conexão SSL, o driver do cliente valida a identidade do servidor, impedindo ataques "man in the middle". Ele faz isso verificando se o certificado do servidor está 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.
2. sslmode. Se você precisar de criptografia e quiser que a conexão falhe, se não puder ser criptografada, defina sslmode=require. Isso garante que o servidor esteja configurado para aceitar conexões SSL para esse endereço Host/IP e que o servidor reconheça o certificado do cliente. Em outras palavras, se o servidor não aceitar conexões SSL ou o certificado do cliente não for reconhecido, a conexão falhará. A tabela abaixo lista os valores para essa configuração:

O modo sslmode padrão usado é diferente entre clientes baseados em libpq (como psql) e JDBC. Os clientes baseados em libpq usam como padrão preferir e os clientes JDBC como padrão para verificar cheio.

3. 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. Esses padrões são /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8 e /defaultdir/root.crt, respectivamente, onde defaultdir é ${user.home}/.postgresql/ em sistemas *nix e %appdata%/postgresql/ no windows.

As autoridades de certificação (AC) 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 autoridades de certificação confiáveis. Todos os sistemas operacionais e a maioria dos navegadores da Web são fornecidos com um conjunto de CAs confiáveis.

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

Download de certificados de autoridade de certificação raiz e atualização de clientes de aplicativos em cenários de fixação de certificados

Para atualizar aplicativos cliente em cenários de fixação de certificados, você pode baixar certificados dos seguintes URIs:

• Autoridade de certificação raiz Microsoft RSA 2017 https://www.microsoft.com/pkiops/certs/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crt
• DigiCert Raiz Global G2 https://cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem
• AC raiz global da Digicert https://cacerts.digicert.com/DigiCertGlobalRootCA.crt

Para importar certificados para repositórios de certificados de cliente, talvez seja necessário converter arquivos .crt de certificado para o formato .pem, depois de baixar arquivos de certificado dos URIs acima. Você pode usar o utilitário OpenSSL para fazer essas conversões de arquivo, como mostrado no exemplo abaixo:

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

Informações detalhadas sobre como atualizar repositórios de certificados de aplicativos cliente com novos certificados de CA raiz foram documentadas neste documento de instruções.

Ler réplicas com cenários de fixação de certificados

Com a migração da autoridade de certificação raiz para a Microsoft RSA Root Certificate Authority 2017 , é viável que as réplicas recém-criadas estejam em um certificado de autoridade de certificação raiz mais recente do que o servidor primário criado anteriormente. Portanto, para clientes que usam as definições de configuração verify-ca e verify-full sslmode, ou seja, a fixação de certificados, é imperativo que a conectividade interrompida aceite três certificados de autoridade de certificação raiz:

• Autoridade de certificação raiz Microsoft RSA 2017 https://www.microsoft.com/pkiops/certs/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crt
• DigiCert Raiz Global G2 https://cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem
• AC raiz global da Digicert https://cacerts.digicert.com/DigiCertGlobalRootCA.crt

Testando certificados de cliente conectando-se com psql em cenários de fixação de certificados

Você pode usar a linha de comando psql do seu cliente para testar a conectividade com o servidor em cenários de fixação de certificados, conforme mostrado no exemplo abaixo:

$ 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 ssl e certificado, você pode seguir a documentação do psql.

Testando a conectividade SSL/TLS

Antes de tentar acessar seu servidor habilitado para SSL a partir do aplicativo cliente, certifique-se de que você pode acessá-lo via psql. Você verá uma saída semelhante à seguinte se tiver estabelecido uma conexão SSL.

Conexão psql (14.5)SSL (protocolo: TLSv1.2, cifra: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compressão: off)Digite "help" para obter ajuda.

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

Suítes Cipher

Um conjunto de cifras é um conjunto de algoritmos criptográficos. Os protocolos TLS/SSL usam algoritmos de um conjunto de codificação para criar chaves e criptografar informações. Um conjunto de codificação é exibido como uma longa cadeia de informações aparentemente aleatórias, mas cada segmento dessa cadeia contém informações essenciais. Geralmente, essa cadeia de dados é composta por vários componentes principais:

• Protocolo (ou seja, TLS 1.2 ou TLS 1.3)
• Algoritmo de troca ou acordo de chaves
• Algoritmo de assinatura digital (autenticação)
• Algoritmo de encriptação em massa
• Algoritmo de código de autenticação de mensagem (MAC)

Diferentes versões de SSL/TLS suportam diferentes pacotes de codificação. Os pacotes de codificação TLS 1.2 não podem ser negociados com conexões TLS 1.3 e vice-versa. A partir deste momento, o Banco de Dados do Azure para servidor flexível PostgreSQL oferece suporte a muitos pacotes de codificação com a versão do protocolo TLS 1.2 que se enquadram na categoria HIGH:!aNULL .

Solução de problemas de erros de conectividade SSL\TLS

1. A primeira etapa para solucionar problemas de compatibilidade de versão do protocolo SSL/TLS é identificar as mensagens de erro que você ou seus usuários estão vendo ao tentar acessar seu Banco de Dados do Azure para PostgreSQL - Servidor Flexível sob criptografia TLS do cliente. Dependendo do aplicativo e da plataforma, as mensagens de erro podem ser diferentes, mas em muitos casos apontam para o problema subjacente.
2. Para ter certeza da compatibilidade da versão do protocolo SSL/TLS, você deve verificar a configuração SSL/TLS do servidor de banco de dados e do cliente do aplicativo para garantir que eles suportem versões compatíveis e pacotes de codificação.
3. Analise quaisquer discrepâncias ou lacunas entre o servidor de banco de dados e as versões SSL/TLS e pacotes de codificação do cliente e tente resolvê-las ativando ou desabilitando determinadas opções, atualizando ou fazendo downgrade de software ou alterando certificados ou chaves. Por exemplo, talvez seja necessário habilitar ou desabilitar versões específicas de SSL/TLS no servidor ou no cliente, dependendo dos requisitos de segurança e compatibilidade, como desabilitar o TLS 1.0 e o TLS 1.1, que são considerados inseguros e obsoletos, e habilitar o TLS 1.2 e o TLS 1.3, que são mais seguros e modernos.
4. O mais recente certificado emitido com a Microsoft RSA Root Certificate Authority 2017 tem um intermediário na cadeia assinado pela Digicert Global Root G2 CA. Algumas das bibliotecas de cliente Postgres, ao usar as configurações sslmode=verify-full ou sslmode=verify-ca , podem enfrentar falhas de conexão com certificados de CA raiz que são assinados com certificados intermediários, resultando em caminhos de confiança alternativos. Para contornar esses problemas, adicione todos os três certificados necessários ao armazenamento de certificados do cliente ou especifique explicitamente o parâmetro sslrootcert , explicado acima, ou defina a variável de ambiente PGSSLROOTCERT para o caminho local onde o certificado de autoridade de certificação raiz Microsoft RSA Root Certificate Authority 2017 é colocado, a partir do valor padrão de %APPDATA%\postgresql\root.crt.

Conteúdos relacionados

• Saiba como criar uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL usando a opção Acesso privado (integração VNet) no portal do Azure ou na CLI do Azure.
• Saiba como criar uma instância de 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.