Condividi tramite

Crittografa le connessioni a SQL Server in Linux

  • Articolo

Si applica a: SQL Server - Linux

SQL Server in Linux può usare TLS (Transport Layer Security) per crittografare i dati trasmessi attraverso una rete tra un'applicazione client e un'istanza di SQL Server. SQL Server supporta gli stessi protocolli TLS sia in Windows che in Linux: TLS 1.2, 1.1 e 1.0. I passaggi per configurare TLS sono tuttavia specifici del sistema operativo in cui SQL Server è in esecuzione.

Requisiti per i certificati

Assicurarsi che i certificati siano conformi ai requisiti seguenti:

  • L'ora di sistema corrente deve essere successiva al valore della proprietà Valid from del certificato e antecedente al valore della proprietà Valid to del certificato.

  • Il certificato deve essere destinato all'autenticazione del server. Ciò richiede che la proprietà Enhanced Key Usage del certificato specifichi Server Authentication (1.3.6.1.5.5.7.3.1).

  • Il certificato deve essere creato utilizzando l'opzione KeySpec di AT_KEYEXCHANGE. In genere, la proprietà di utilizzo della chiave del certificato (KEY_USAGE) include anche la crittografia a chiave (CERT_KEY_ENCIPHERMENT_KEY_USAGE).

  • La proprietà Subject del certificato deve specificare che il nome comune (CN, Common Name) corrisponde al nome host oppure al nome di dominio completo (FQDN, Fully Qualified Domain Name) del server.

    Nota

    I certificati con caratteri jolly sono supportati.

Configurazione delle librerie OpenSSL per l'utilizzo (facoltativo)

È possibile creare nella directory /opt/mssql/lib/ collegamenti simbolici che facciano riferimento alle librerie libcrypto.so e libssl.so da usare per la crittografia. Questa opzione è utile se si vuole imporre a SQL Server l'uso di una versione specifica di OpenSSL diversa da quella predefinita fornita dal sistema. Se questi collegamenti simbolici non sono presenti, SQL Server caricherà le librerie OpenSSL predefinite configurate nel sistema.

Questi collegamenti simbolici devono essere denominati libcrypto.so e libssl.so ed essere inseriti nella directory /opt/mssql/lib/.

Nota

Per un esempio di uso di Let's Encrypt per generare un certificato, vedere il post di blog Sbloccare la potenza dei dati in Azure con SQL Server in Linux macchine virtuali di Azure e Ricerca di intelligenza artificiale di Azure.

Panoramica

TLS viene usato per crittografare le connessioni da un'applicazione client a SQL Server. Se configurato correttamente, TLS garantisce la sia privacy che l'integrità dei dati per le comunicazioni tra il client e il server. Le connessioni TLS possono essere avviate dal client oppure dal server.

La sezione seguente descrive la configurazione della crittografia avviata dal client.

Generare il certificato

/CN deve corrispondere al nome di dominio completo dell'host di SQL Server.

Attenzione

Questo esempio usa un certificato autofirmato. Non usare certificati autofirmati per gli scenari di produzione. È consigliabile usare i certificati della CA.

Assicurarsi che le cartelle in cui vengono salvati i certificati e le chiavi private siano accessibili dall'utente/gruppo mssql con l'autorizzazione impostata su 700 (drwx-----). È possibile creare cartelle manualmente con l'autorizzazione impostata su 700 (drwx------) e la proprietà dell'utente/gruppo mssql o impostare l'autorizzazione su 755 (drwxr-xr-x) e la proprietà di altri utenti ma sempre accessibili al gruppo di utenti mssql. Ad esempio, è possibile creare una cartella denominata sslcert nel percorso /var/opt/mssql/ e salvare il certificato e la chiave privata con autorizzazioni per i file impostati su 600, come illustrato nell'esempio seguente.

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/

Configurare 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

Registrare il certificato nel computer client (Windows, Linux o macOS)

  • Se si usa un certificato della CA firmato, è necessario copiare nel computer client il certificato dell'Autorità di certificazione (CA) invece del certificato dell'utente.

  • Se si usa il certificato autofirmato, è sufficiente copiare il .pem file PEM nelle cartelle seguenti, a seconda della distribuzione, ed eseguire i comandi per abilitarlo

  • Ubuntu: copiare il certificato in /usr/share/ca-certificates/, rinominare l'estensione in .crt e usare dpkg-reconfigure ca-certificates per abilitarlo come certificato della CA di sistema.

  • RHEL: copiare il certificato in /etc/pki/ca-trust/source/anchors/ e usare update-ca-trust per abilitarlo come certificato della CA di sistema.

  • SUSE: copiare il certificato in /usr/share/pki/trust/anchors/ e usare update-ca-certificates per abilitarlo come certificato della CA di sistema.

  • Windows: importare il file .pem come certificato nell'utente corrente > Autorità di certificazione radice attendibili > Certificati

  • macOS:

    • Copiare i dati del certificato in /usr/local/etc/openssl/certs

    • Eseguire il comando seguente per ottenere il valore hash:

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

    • Rinominare il certificato con il valore. Ad esempio: mv mssql.pem dc2dd900.0. Assicurarsi che dc2dd900.0 sia in /usr/local/etc/openssl/certs

Esempi di stringhe di connessione

Attenzione

Usare sempre una password complessa. Per ulteriori informazioni, vedere Password Policy.

  • SQL Server Management Studio

    Screenshot della finestra di dialogo di connessione di SQL Server Management Studio.

  • sqlcmd

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

  • ADO.NET

    "Encrypt=True; TrustServerCertificate=False;"

  • ODBC

    "Encrypt=Yes; TrustServerCertificate=no;"

  • JDBC

    "encrypt=true; trustServerCertificate=false;"

Errori di connessione comuni

Messaggio d'errore Fix
The certificate chain was issued by an authority that is not trusted. Questo errore si verifica quando i client non riescono a verificare la firma sul certificato presentato da SQL Server durante l'handshake TLS. Verificare che il client consideri attendibile direttamente il certificato di SQL Server oppure la CA che ha firmato il certificato di SQL Server.
The target principal name is incorrect. Verificare che il campo Nome comune nel certificato di SQL Server corrisponda al nome del server specificato nella stringa di connessione del client.
An existing connection was forcibly closed by the remote host. Questo errore può verificarsi quando il client non supporta la versione del protocollo TLS richiesta da SQL Server. Se ad esempio la configurazione di SQL Server richiede TLS 1.2, verificare che i client supportino anche il protocollo TLS 1.2.

Ubuntu 20.04 e altre versioni recenti della distribuzione Linux

Sintomo

Quando un'istanza di SQL Server in Linux carica un certificato creato con un algoritmo di firma che usa meno di 112 bit di sicurezza (ad esempio MD5, SHA-1), è possibile osservare un errore di connessione, come illustrato di seguito:

È stata stabilita una connessione con il server, ma si è verificato un errore durante il processo di accesso. (provider: provider SSL, errore: 0 - Una connessione esistente era stata chiusa forzatamente dall'host remoto. (Microsoft SQL Server, Errore: 10054)

L'errore è dovuto al livello di sicurezza 2 di OpenSSL abilitato per impostazione predefinita in Ubuntu 20.04 e versioni successive. Il livello di sicurezza 2 impedisce la creazione di connessioni TLS con meno di 112 bit di sicurezza.

Soluzione

Installare un certificato con un algoritmo di firma che usa almeno 112 bit di sicurezza. Gli algoritmi di firma che soddisfano questo requisito includono SHA-224, SHA-256, SHA-384 e SHA-512.