Criptografar conexões para o SQL Server no Linux

  • Artigo

Aplica-se a:SQL Server – Linux

O SQL Server no Linux pode usar o protocolo TLS para criptografar os dados transmitidos por uma rede entre um aplicativo cliente e uma instância do SQL Server. O SQL Server é compatível com os mesmos protocolos TLS no Windows e no Linux: TLS 1.2, 1.1 e 1.0. No entanto, as etapas para configurar o TLS são específicas para o sistema operacional no qual o SQL Server está em execução.

Requisitos para certificados

Antes de começar, você precisa verificar se os certificados seguem estes requisitos:

  • A hora do sistema atual deve ser posterior à propriedade Valid from do certificado e anterior à propriedade Valid to para do certificado.

  • O certificado deve ser significativo para a autenticação do servidor. Isso requer que a propriedade Enhanced Key Usage do certificado especifique Server Authentication (1.3.6.1.5.5.7.3.1).

  • O certificado deve ser criado usando a opção KeySpec de AT_KEYEXCHANGE. Normalmente, a propriedade de uso de chave do certificado (KEY_USAGE) também inclui a codificação de chaves (CERT_KEY_ENCIPHERMENT_KEY_USAGE).

  • A propriedade Subject do certificado deve indicar que o nome comum (CN) é igual ao nome do host ou ao nome de domínio totalmente qualificado (FQDN) do computador servidor.

    Observação

    Há suporte para certificados curinga.

Como configurar bibliotecas OpenSSL para uso (opcional)

Você pode criar links simbólicos no diretório /opt/mssql/lib/ que fazem referência a quais bibliotecas libcrypto.so e libssl.so devem ser usadas para criptografia. Isso será útil se você quiser forçar o SQL Server a usar uma versão específica do OpenSSL diferente da versão padrão fornecida pelo sistema. Se esses links simbólicos não estiverem presentes, o SQL Server carregará as bibliotecas do OpenSSL padrão configuradas no sistema.

Esses links simbólicos devem se chamar libcrypto.so e libssl.so e ser colocados no diretório /opt/mssql/lib/.

Visão geral

O TLS é usado para criptografar conexões de um aplicativo cliente para o SQL Server. Quando configurado corretamente, o TLS fornece privacidade e integridade de dados para comunicações entre o cliente e o servidor. As conexões TLS podem ser iniciadas pelo cliente ou iniciadas pelo servidor.

A seção a seguir descreve a configuração da criptografia iniciada pelo cliente.

Gerar certificado

/CN deve corresponder ao nome de domínio totalmente qualificado do host do SQL Server.

Cuidado

Este exemplo usa um certificado autoassinado. Os certificados autoassinados não devem ser usados para cenários de produção. Você deve usar certificados de autoridade de certificação.

Verifique se as pastas em que você salva os seus certificados e as suas chaves privadas podem ser acessadas pelo usuário/grupo mssql e têm a permissão definida como 700 (drwx-----). É possível criar pastas manualmente que tenham a permissão definida como 700 (drwx------) e pertençam ao usuário/grupo mssql ou que tenham a permissão definida como 755 (drwxr-xr-x) e pertençam a outro usuário, mas ainda sejam acessíveis ao usuário/grupo mssql. Por exemplo, você pode criar uma pasta chamada sslcert no caminho /var/opt/mssql/ e salvar o certificado e a chave privada com as permissões nos arquivos definidas como 600, conforme mostrado no exemplo a seguir.

openssl req -x509 -nodes -newkey rsa:2048 -subj '/CN=mssql.contoso.com' -keyout mssql.key -out mssql.pem -days 365
sudo chown mssql:mssql mssql.pem mssql.key
sudo chmod 600 mssql.pem mssql.key
#Saving the certificate to the certs folder under /etc/ssl/ which has the following permission 755(drwxr-xr-x)
sudo mv mssql.pem /etc/ssl/certs/ drwxr-xr-x
#Saving the private key to the private folder under /etc/ssl/ with permissions set to 755(drwxr-xr-x)
sudo mv mssql.key /etc/ssl/private/

Configurar o SQL Server

systemctl stop mssql-server
sudo cat /var/opt/mssql/mssql.conf
sudo /opt/mssql/bin/mssql-conf set network.tlscert /etc/ssl/certs/mssql.pem
sudo /opt/mssql/bin/mssql-conf set network.tlskey /etc/ssl/private/mssql.key
sudo /opt/mssql/bin/mssql-conf set network.tlsprotocols 1.2
sudo /opt/mssql/bin/mssql-conf set network.forceencryption 0
systemctl restart mssql-server

Registrar o certificado no computador cliente (Windows, Linux ou macOS)

  • Se você estiver usando um certificado assinado por AC, precisará copiar o certificado de Autoridade de Certificação (AC), em vez do certificado do usuário para o computador cliente.
  • Se você estiver usando o certificado autoassinado, copie o arquivo .pem para as pastas a seguir respectivas à distribuição e execute os comandos para habilitá-lo:
  • Ubuntu: copie o certificado para /usr/share/ca-certificates/, renomeie sua extensão para .crt e use dpkg-reconfigure ca-certificates para habilitá-lo como o Certificado de Autoridade de Certificação do sistema.
  • RHEL: copie o certificado para /etc/pki/ca-trust/source/anchors/ e use update-ca-trust para habilitá-lo como Certificado de Autoridade de Certificação do sistema.
  • SUSE: copie o certificado para /usr/share/pki/trust/anchors/ e use update-ca-certificates para habilitá-lo como Certificado de Autoridade de Certificação do sistema.
  • Windows: importe o arquivo .pem como um certificado em Usuário Atual > Autoridades de Certificação Raiz Confiáveis > Certificados.
  • macOS:

    • Copie os dados do certificado para /usr/local/etc/openssl/certs.

    • Execute o seguinte comando para obter o valor de hash:

      /usr/local/Cellar/openssl/1.0.2l/openssl x509 -hash -in mssql.pem -noout

    • Altere o nome do certificado para o valor. Por exemplo: mv mssql.pem dc2dd900.0. Verifique se dc2dd900.0 está em /usr/local/etc/openssl/certs.

Cadeias de conexão de exemplo

  • SQL Server Management Studio

    Screenshot of SQL Server Management Studio connection dialog.

  • SQLCMD

    sqlcmd -S <sqlhostname> -N -U sa -P '<YourPassword>'

  • ADO.NET

    "Encrypt=True; TrustServerCertificate=False;"

  • ODBC

    "Encrypt=Yes; TrustServerCertificate=no;"

  • JDBC

    "encrypt=true; trustServerCertificate=false;"

Erros de conexão comuns

Mensagem de erro Fix
The certificate chain was issued by an authority that is not trusted. Esse erro ocorre quando os clientes não conseguem verificar a assinatura no certificado apresentado por SQL Server durante o handshake de TLS. Verifique se o cliente confia no certificado do SQL Server diretamente ou na AC que assinou o certificado do SQL Server.
The target principal name is incorrect. Verifique se o campo nome comum no certificado do SQL Server corresponde ao nome do servidor especificado na cadeia de conexão do cliente.
An existing connection was forcibly closed by the remote host. Esse erro pode ocorrer quando o cliente não é compatível com a versão do protocolo TLS exigida pelo SQL Server. Por exemplo, se SQL Server estiver configurado para exigir o TLS 1.2, verifique se os clientes também são compatíveis com o protocolo TLS 1.2.

Ubuntu 20.04 e outras versões de distribuição recentes do Linux

Sintoma

Quando um SQL Server em uma instância do Linux carrega um certificado que foi criado com um algoritmo de assinatura usando menos de 112 bits de segurança (exemplos: MD5, SHA-1), você pode observar um erro de falha de conexão, como neste exemplo:

Uma conexão com o servidor foi estabelecida com êxito, mas ocorreu um erro durante o processo de logon. (provedor: Provedor SSL, erro: 0 – Uma conexão existente foi fechada à força pelo host remoto) (Microsoft SQL Server, Erro: 10054)

O erro ocorre porque o nível de segurança 2 do OpenSSL está habilitado por padrão no Ubuntu 20.04 e versões posteriores. O nível de segurança 2 proíbe que conexões TLS com menos de 112 bits de segurança sejam estabelecidas.

Solução

Instale um certificado com um algoritmo de assinatura usando pelo menos 112 bits de segurança. Os algoritmos de assinatura que atendem a esse requisito incluem SHA-224, SHA-256, SHA-384 e SHA-512.