Leggere in inglese

Condividi tramite

Casi speciali per la crittografia delle connessioni verso SQL Server

  • Articolo

Un computer client deve considerare attendibile il certificato del server in modo che il client possa richiedere la crittografia TLS (Transport Layer Security) e che il certificato sia già presente nel server. Lo scenario più comune per la crittografia di SQL Server comprende ambienti che:

  • forzano la crittografia per tutte le connessioni client in ingresso a SQL Server.
  • Usare i certificati di un'autorità di certificazione commerciale pubblica che Windows considera già attendibile. Il certificato radice corrispondente per la CA viene installato nell'archivio Autorità di certificazione radice attendibili in tutti i computer della rete.

In questo scenario non è necessario eseguire passaggi aggiuntivi per la corretta crittografia dopo aver configurato SQL Server in base alla procedura descritta in Configurazione di SQL Server per la crittografia. Questo articolo illustra le procedure per crittografare le connessioni verso SQL Server per scenari meno comuni, non trattati in Configurazione del motore di database SQL Server per la crittografia delle connessioni.

Nota

Per un elenco completo dei partecipanti al Programma radice attendibile Microsoft, si veda Elenco dei partecipanti - Microsoft Trusted Root Program.

Usare un certificato rilasciato da un'autorità di certificazione commerciale pubblica e solo alcuni client necessitano di connessioni crittografate

  1. Configurare il certificato in SQL Server in base alla procedura descritta in Configurare SQL Server per l'uso dei certificati.

  2. Specificare la parola chiave per la crittografia nelle proprietà di connessione su Sì o Vero. Ad esempio, se si usa Microsoft ODBC Driver per SQL Server, la stringa di connessione deve specificare Encrypt=yes;.

Usare un certificato rilasciato da una CA interna o creato usando New-SelfSignedCertificate oppure makecert

Scenario 1: Si vogliono crittografare tutte le connessioni verso SQL Server

Dopo aver completato entrambe le procedure descritte in Passaggio 1: Configurare SQL Server per l'uso di certificati e Passaggio 2: Configurare le impostazioni di crittografia in SQL Server nell'articolo Configurare il motore di database di SQL Server per crittografare le connessioni, usare una delle opzioni seguenti per configurare l'applicazione client per la crittografia.

Opzione 1: configurare le applicazioni client per considerare attendibile il certificato del server. Questa impostazione impedisce al client di ignorare il passaggio che convalida il certificato del server e continuerà il processo di crittografia. Ad esempio, se si usa SQL Server Management Studio (SSMS) 20 e versioni successive, è possibile selezionare Trust Server Certificate (Certificato server attendibile) nella pagina Account di accesso (o nella pagina Opzioni nelle versioni precedenti).

Opzione 2: In ogni client, aggiungere l'autorità emittente del certificato all'archivio dell'autorità radice attendibile seguendo i seguenti passaggi.

  1. Esportare il certificato da un computer che esegue SQL Server usando la procedura documentata in Esportare il certificato del server.

  2. Importare il certificato usando la procedura documentata in Esportare e importare i certificati.

Scenario 2: solo alcuni client necessitano di connessioni crittografate

Dopo aver configurato il certificato per l'uso di SQL Server come documentato in passaggio 1 in Configurare il motore di database di SQL Server per crittografare le connessioni, usare una delle opzioni seguenti per configurare l'applicazione client per la crittografia:

opzione 1: configurare le applicazioni client per considerare attendibile il certificato del server e specificare la parola chiave di crittografia nelle proprietà di connessione per Sì o True. Ad esempio, se si usa Microsoft ODBC Driver per SQL Server, la stringa di connessione deve specificare Encrypt=Yes;TrustServerCertificate=Yes;.

Per altre informazioni sui certificati del server e sulla crittografia, vedere Uso di TrustServerCertificate.

Opzione 2: In ogni client, aggiungere l'autorità emittente del certificato all'archivio delle autorità radice attendibili e specificare i parametri di crittografia su Sì nella stringa di connessione:

  1. Esportare il certificato da un computer che esegue SQL Server usando la procedura documentata in Esportare il certificato da un computer che esegue SQL Server.

  2. Importare il certificato.

  3. Specificare la parola chiave per la crittografia nelle proprietà di connessione su Sì o Vero. Ad esempio, se si usa Microsoft ODBC Driver per SQL Server, la stringa di connessione deve specificare Utilizza crittografia per dati = Vero;

Usare il certificato autofirmato creato automaticamente da SQL Server

Scenario 1: Si vogliono crittografare tutte le connessioni verso SQL Server

  1. Abilitare la crittografia in SQL Server usando la procedura Passaggio 2: Configurare le impostazioni di crittografia in SQL Server documentata in Configurazione nel motore di database SQL Server per la crittografia delle connessioni.

  2. Configurare le applicazioni client per considerare attendibile il certificato del server. La fiducia nel certificato del server porta il client a saltare il passaggio di convalida del certificato del server e a continuare con il processo di crittografia. Ad esempio, se si usa SQL Server Management Studio (SSMS) 20 e versioni successive, è possibile selezionare Trust Server Certificate (Certificato server attendibile) nella pagina Account di accesso (o nella pagina Opzioni nelle versioni precedenti).

Scenario 2: solo alcuni client necessitano di connessioni crittografate

Configurare le applicazioni client per considerare attendibile il certificato del server e specificare la parola chiave di crittografia nelle proprietà di connessione su Sì o Vero. Ad esempio, se si usa Microsoft ODBC Driver per SQL Server, la stringa di connessione deve specificare Encrypt=Yes;TrustServerCertificate=Yes;.

Non è necessaria alcuna configurazione aggiuntiva in SQL Server per questo scenario.

Avviso

Le connessioni TLS/SSL crittografate con un certificato autofirmato non offrono una sicurezza avanzata, perché la lunghezza della chiave nei certificati autofirmati è più breve rispetto alla chiave nei certificati generati dalla CA. Sono vulnerabili ad attacchi di tipo man-in-the-middle. Non è consigliabile basarsi su TLS/SSL usando certificati autofirmato in un ambiente di produzione o su server connessi a Internet.

Contenuto correlato