Transport Layer Security e certificati digitali
Questo articolo descrive i dettagli del protocollo Transport Layer Security (TLS) e dei certificati digitali.
Sicurezza del Livello di Trasporto (TLS)
I protocolli TLS e SSL si trovano tra il livello del protocollo dell'applicazione e il livello TCP/IP, in cui possono proteggere e inviare i dati dell'applicazione al livello di trasporto. I protocolli TLS/SSL usano algoritmi di una suite di crittografia per creare chiavi e crittografare le informazioni. Il client e il server negoziano la versione del protocollo e la suite di crittografia da usare per la crittografia durante la fase iniziale di connessione (pre-accesso). La versione TLS più elevata supportata è sempre preferibile nell'handshake TLS. Per controllare le versioni dei protocolli TLS supportate da versioni diverse dei sistemi operativi Windows, vedere Protocolli in TLS/SSL (SSP Schannel).To check the TLS protocols versions supported by different version of Windows operating systems, see Protocols in TLS/SSL (Schannel SSP). Sono state segnalate diverse vulnerabilità note su SSL e versioni precedenti di TLS. È consigliabile eseguire l'aggiornamento a TLS 1.2 per la comunicazione sicura.
SQL Server può usare TLS per crittografare i dati trasmessi attraverso una rete tra un'istanza di SQL Server e un'applicazione client. TLS usa un certificato per implementare la crittografia.
Abilitando la crittografia TLS è possibile aumentare la sicurezza dei dati trasmessi nelle reti tra le istanze di SQL Server e le applicazioni. Tuttavia, quando tutto il traffico tra SQL Server e un'applicazione client viene crittografato tramite TLS, è necessaria l'elaborazione aggiuntiva seguente:
- È necessario un round trip di rete aggiuntivo in fase di connessione.
- I pacchetti inviati dall'applicazione all'istanza di SQL Server devono essere crittografati dallo stack TLS client e decrittografati dallo stack TLS del server.
- I pacchetti inviati dall'istanza di SQL Server all'applicazione devono essere crittografati dallo stack TLS del server e decrittografati dallo stack TLS del client.
Importante
A partire da SQL Server 2016 (13.x), Secure Sockets Layer (SSL) è stato sospeso. Usare TLS (è consigliato TLS 1.2). Per altre informazioni, vedere l'articolo KB3135244 - Supporto di TLS 1.2 per Microsoft SQL Server. SQL Server 2022 introduce il supporto per TLS 1.3. Per altre informazioni, vedere Supporto di TLS 1.3. Se non esistono protocolli corrispondenti tra il computer client e server, è possibile verificarsi l'errore descritto in Una connessione esistente chiusa forzatamente dall'host remoto.
Panoramica del certificato digitale
I certificati digitali sono file elettronici che funzionano come una password online per verificare l'identità di un utente o di un computer. Vengono usati per creare il canale crittografato usato per le comunicazioni client. Un certificato è un'istruzione digitale rilasciata da un'autorità di certificazione (CA) che garantisce l'identità del titolare del certificato e consente alle parti di comunicare in modo sicuro usando la crittografia.
I certificati digitali forniscono i servizi seguenti:
- Crittografia: consentono di proteggere i dati scambiati da furti o manomissioni.
- Autenticazione: verificano che i loro titolari (persone, siti Web e persino dispositivi di rete come i router) siano realmente chi o cosa sostengono di essere. In genere, l'autenticazione è unidirezionale, in cui l'origine verifica l'identità della destinazione, ma è possibile anche l'autenticazione TLS reciproca.
Un certificato contiene una chiave pubblica e collega tale chiave pubblica all'identità di una persona, di un computer o di un servizio che contiene la chiave privata corrispondente. Le chiavi pubbliche e private vengono usate dal client e dal server per crittografare i dati prima che vengano trasmessi. Per gli utenti, i computer e i servizi di Windows, l'attendibilità nella CA viene stabilita quando il certificato radice viene definito nell'archivio certificati radice attendibile e il certificato contiene un percorso di certificazione valido. Un certificato viene considerato valido se non è stato revocato (non si trova nell'elenco di revoche di certificati della CA o CRL) o è scaduto.
I tre tipi principali di certificati digitali sono descritti nella tabella seguente:
| TIPO | Descrizione | Vantaggi | Svantaggi |
|---|---|---|---|
| Certificato autofirmato | Il certificato viene firmato dall'applicazione che l'ha creata o creata usando New-SelfSignedCertificate. | Costo (gratuito) | - Il certificato non viene considerato automaticamente attendibile dai computer client e dai dispositivi mobili. Il certificato deve essere aggiunto manualmente all'archivio certificati radice attendibile su tutti i computer e dispositivi client, ma non tutti i dispositivi mobili consentono modifiche all'archivio certificati radice attendibile. - Non tutti i servizi funzionano con certificati autofirmato. - Difficile stabilire un'infrastruttura per la gestione del ciclo di vita dei certificati. Ad esempio, i certificati autofirmati non possono essere revocati. |
| Certificato rilasciato da una CA interna | Il certificato viene rilasciato da un'infrastruttura a chiave pubblica (PKI) nell'organizzazione. Un esempio è Servizi certificati di Active Directory. Per altre informazioni, vedere Panoramica di Servizi certificati Active Directory. | - Consente alle organizzazioni di rilasciare i propri certificati. - Meno costoso rispetto ai certificati di una CA commerciale. |
- Maggiore complessità per distribuire e gestire l'infrastruttura a chiave pubblica. - Il certificato non viene considerato automaticamente attendibile dai computer client e dai dispositivi mobili. Il certificato deve essere aggiunto manualmente all'archivio dei certificati radice attendibili su tutti i computer e dispositivi client, ma non tutti i dispositivi mobili consentono modifiche a questo archivio. |
| Certificato rilasciato da una CA commerciale | Il certificato viene acquistato da una CA commerciale attendibile. | La distribuzione dei certificati è semplificata perché tutti i client, i dispositivi e i server considerano automaticamente attendibili i certificati. | Costo. È necessario pianificare in anticipo per ridurre al minimo il numero di certificati necessari. |
Per dimostrare che un titolare del certificato è chi dichiara di essere, il certificato deve identificare accuratamente il titolare del certificato ad altri client, dispositivi o server. I tre metodi di base per eseguire questa operazione sono descritti nella tabella seguente:
| Metodo | Descrizione | Vantaggi | Svantaggi |
|---|---|---|---|
| Corrispondenza dell'oggetto del certificato | Il campo Oggetto del certificato contiene il nome comune (CN) dell'host. Ad esempio, il certificato rilasciato per www.contoso.com può essere usato per il sito https://www.contoso.comWeb . |
- Compatibile con tutti i client, i dispositivi e i servizi. -Compartimentazione. La revoca del certificato per un host non influisce sugli altri host. |
- Numero di certificati necessari. È possibile usare il certificato solo per l'host specificato. Ad esempio, non è possibile usare il www.contoso.com certificato per ftp.contoso.com, anche quando i servizi vengono installati nello stesso server.-Complessità. In un server Web, ogni certificato richiede la propria associazione di indirizzi IP. |
| Corrispondenza del nome alternativo del soggetto del certificato (SAN) | Oltre al campo Oggetto , il campo Nome alternativo soggetto del certificato contiene un elenco di più nomi host. Per esempio:www.contoso.comftp.contoso.comftp.eu.fabrikam.net |
-Comodità. È possibile usare lo stesso certificato per più host in più domini separati. - La maggior parte dei client, dei dispositivi e dei servizi supporta i certificati SAN. - Controllo e sicurezza. Si sa esattamente quali host sono in grado di usare il certificato SAN. |
- È necessaria una pianificazione più approfondita. È necessario specificare l'elenco degli host quando si crea il certificato. - Mancanza di compartimentazione. Non è possibile revocare in modo selettivo i certificati per alcuni degli host specificati senza influire su tutti gli host nel certificato. |
| Corrispondenza del certificato wildcard | Il campo Oggetto del certificato contiene il nome comune, che include il carattere jolly (*), più un singolo dominio o sottodominio. Ad esempio, *.contoso.com o *.eu.contoso.com. Il *.contoso.com certificato wildcard può essere usato per:www.contoso.comftp.contoso.commail.contoso.com |
Flessibilità. Non è necessario fornire un elenco di host quando si richiede il certificato ed è possibile usare il certificato in un numero qualsiasi di host che potrebbero essere necessari in futuro. | - Non è possibile utilizzare certificati wildcard con altri domini di primo livello (TLD). Ad esempio, non è possibile usare il certificato wildcard *.contoso.com per host *.contoso.net.- È possibile usare solo i certificati con caratteri jolly per i nomi host al livello del carattere jolly. Ad esempio, non è possibile usare il *.contoso.com certificato per www.eu.contoso.com. In alternativa, non è possibile usare il *.eu.contoso.com certificato per www.uk.eu.contoso.com.- I client, i dispositivi, le applicazioni o i servizi meno recenti potrebbero non supportare i certificati con caratteri jolly. - I caratteri jolly non sono disponibili con i certificati di convalida estesa (EV). - Sono necessarie verifiche e controlli accurati. Se il certificato con caratteri jolly viene compromesso, influisce su ogni host nel dominio specificato. |