Partilhar via

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

  • Artigo

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 a conexão de seus aplicativos cliente ao Banco de Dados do Azure para PostgreSQL - Servidor Flexível 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 foi feito a partir do protocolo SSL da Netscape e tem substituído regularmente. Os termos SSL ou TLS/SSL ainda são, por 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. O show de handshake permite que o servidor e o cliente se afirmem mutuamente e coordenem avaliações de criptografia e chaves criptográficas antes que qualquer informação seja negociada.

Diagrama que mostra a sequência típica de handshake TLS 1.2.

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

  1. O cliente começa enviando uma mensagem chamada ClientHello que expressa a vontade de se comunicar via TLS 1.2 com um conjunto de pacotes de codificação que o cliente suporta.
  2. O servidor recebe a mensagem, responde com e concorda em se comunicar com ServerHelloo cliente via TLS 1.2 usando um pacote de codificação específico.
  3. O servidor também envia seu compartilhamento de chave. As especificidades desse compartilhamento de chave mudam com base no conjunto de codificação selecionado. 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 [CA]) e uma assinatura em partes de ClientHello e ServerHello. Inclui também a quota-chave. Desta forma, o cliente sabe que é autêntico.
  5. Depois que o cliente recebe com êxito os dados e, em seguida, gera seu próprio compartilhamento de chave, ele os mistura com o compartilhamento de chave do servidor para gerar chaves de criptografia para a sessão.
  6. O cliente envia ao servidor seu compartilhamento de chave, habilita a criptografia e envia uma Finished mensagem. Esta mensagem é um hash de uma transcrição do que aconteceu até agora. O servidor faz o mesmo. Ele mistura os compartilhamentos de chaves para obter a chave e envia sua própria Finished mensagem.
  7. Agora, os dados do aplicativo podem ser enviados criptografados na conexão.

Cadeias de certificados

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

A cadeia termina com um certificado de autoridade de certificação raiz. Este certificado é sempre assinado pela própria autoridade de certificação. 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 TLS/SSL e o certificado de autoridade de certificação raiz na cadeia é chamado de certificado intermediário.

Versões TLS

Várias entidades governamentais em todo o mundo mantêm diretrizes para TLS em relação à segurança da rede. Nos Estados Unidos, essas organizações incluem o Departamento de Saúde e Serviços Humanos e o Instituto Nacional de Padrões e Tecnologia. 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 que incluem uma cifra, um algoritmo de troca de chaves e um algoritmo de hash. Eles são usados juntos para estabelecer uma conexão TLS segura. A maioria dos clientes e servidores TLS suporta várias alternativas. Eles têm que negociar quando estabelecem 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.

O IETF lançou a especificação TLS 1.3 no RFC 8446 em agosto de 2018, e o TLS 1.3 é 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.

Nota

Os certificados SSL e TLS certificam que sua conexão está protegida com protocolos de criptografia de última geração. Ao criptografar sua conexão no fio, você impede o acesso não autorizado aos seus dados durante o trânsito. É altamente recomendável que você use as 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 o recomendemos, se necessário, você pode desabilitar TLS\SSL para conexões com o Banco de Dados do Azure para PostgreSQL - Servidor Flexível. Você pode atualizar o require_secure_transport parâmetro server para OFF. Você também pode definir a versão TLS definindo ssl_min_protocol_version e ssl_max_protocol_version parâmetros do servidor.

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

No momento, o Banco de Dados do Azure para PostgreSQL - Servidor Flexível não oferece suporte:

Nota

A Microsoft fez alterações de autoridade de certificação 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 SSL no cliente.

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, ele retorna f. Você também pode coletar todas as informações sobre o uso SSL do seu Banco de Dados do Azure para servidor flexível 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 openssl comando diretamente:

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

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

Para impor a versão TLS mais recente e segura para proteção de conectividade do cliente para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível, defina ssl_min_protocol_version como 1.3. Essa configuração requer que os clientes que se conectam ao seu servidor flexível do Banco de Dados do Azure para PostgreSQL usem essa versão do protocolo apenas para se comunicar com segurança. Os clientes mais antigos poderão não conseguir comunicar com o servidor porque não suportam esta versão.

Configurar SSL no cliente

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. Todas as opções SSL carregam sobrecarga na forma de criptografia e troca de chaves, de modo que um compromisso é 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 aspetos importantes são:

  • 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. Para compatibilidade com versões futuras, o valor true é preferido. Nesse modo, quando você está estabelecendo uma conexão SSL, o driver do cliente valida a identidade do servidor para evitar ataques man-in-the-middle. Ele verifica 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.

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

    Modo SSL Explicação
    disable A encriptação não é utilizada.
    allow A criptografia é usada se as configurações do servidor exigirem ou a impuserem.
    prefer A criptografia é usada se as configurações do servidor permitirem.
    require A encriptação é usada. Ele garante que o servidor esteja configurado para aceitar conexões SSL para esse endereço IP do host e que o servidor reconheça o certificado do cliente.
    verify-ca A encriptação é usada. Verifique a assinatura do certificado do servidor em relação ao certificado armazenado no cliente.
    verify-full A encriptação é usada. Verifique a assinatura do certificado do servidor e o nome do host em relação ao certificado armazenado no cliente.

    O modo padrão sslmode usado é diferente entre clientes baseados em libpq (como psql) e JDBC. O padrão dos clientes baseados em libpq é .prefer Clientes JDBC padrão para 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 padrão para /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8e /defaultdir/root.crt, respectivamente, onde defaultdir está ${user.home}/.postgresql/ em sistemas nix e %appdata%/postgresql/ no Windows.

As autoridades competentes 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.

As definições de uso verify-ca e verify-full sslmode configuração também podem ser conhecidas como fixação de certificado. Nesse caso, os certificados de CA raiz no servidor PostgreSQL têm que corresponder à assinatura do certificado e até mesmo ao nome do host em relação ao certificado no cliente.

Talvez seja necessário atualizar periodicamente os certificados armazenados no cliente quando as autoridades de certificação forem alteradas ou expirarem em certificados de servidor PostgreSQL. Para determinar se você está fixando CAs, consulte Fixação de certificados e serviços do Azure.

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

Para clientes que usam verify-ca definições de configuração verify-full sslmode (ou seja, fixação de certificado), eles devem implantar três certificados de CA raiz nos repositórios de certificados do cliente:

Baixar certificados de CA raiz e atualizar 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:

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 anteriores. Você pode usar o utilitário OpenSSL para fazer estas conversões de arquivo:

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

As informações sobre como atualizar os repositórios de certificados de aplicativos cliente com novos certificados de CA raiz estão documentadas em Atualizar certificados TLS de cliente para clientes de aplicativos.

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.

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

Com a migração da autoridade de certificação raiz para a AC raiz do Microsoft RSA 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. Para clientes que usam verify-ca definições de configuração verify-full sslmode (ou seja, fixação de certificado), é imperativo que a conectividade interrompida aceite três certificados de autoridade de certificação raiz:

No momento, o Banco de Dados do Azure para PostgreSQL - Servidor Flexível não oferece suporte à autenticação baseada em certificado.

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

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


$ 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 SSL e parâmetros de certificado, consulte a documentação do psql.

Testar a conectividade TLS/SSL

Antes de tentar acessar seu servidor habilitado para SSL a partir de um aplicativo cliente, certifique-se de que você pode acessá-lo via psql. Se você estabeleceu uma conexão SSL, deverá ver uma saída semelhante ao exemplo a seguir:

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 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, ele retorna f.

Conjuntos de cifras

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 inclui 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 do TLS/SSL 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.

No momento, o Banco de Dados do Azure para PostgreSQL - Servidor Flexível dá suporte a muitos pacotes de codificação com a versão do protocolo TLS 1.2 que se enquadram na categoria HIGH:!aNULL .

Solucionar 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 seu Banco de Dados do Azure para servidor flexível PostgreSQL sob criptografia TLS do cliente. Dependendo do aplicativo e da plataforma, as mensagens de erro podem ser diferentes. Em muitos casos, apontam para a questão subjacente.

  2. Para ter certeza da compatibilidade da versão do protocolo TLS/SSL, verifique a configuração TLS/SSL 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 TLS/SSL e pacotes de codificação do cliente. Tente resolvê-los ativando ou desativando 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 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 obsoletos, e habilitar o TLS 1.2 e o TLS 1.3, que são mais seguros e modernos.

  4. O mais novo certificado emitido com o Microsoft RSA Root CA 2017 tem intermediário na cadeia cross-signed pela Digicert Global Root G2 CA. Algumas das bibliotecas de cliente Postgres, ao usar sslmode=verify-full ou sslmode=verify-ca configurações, 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.

    Para contornar esses problemas, adicione todos os três certificados necessários ao armazenamento de certificados do cliente ou especifique explicitamente o sslrootcert parâmetro. Ou, defina a PGSSLROOTCERT variável de ambiente para o 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.

Conteúdos relacionados

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