- viene mostrata di default senza necessità di espandere la maschera
- ha la tipologia di Encryption impostata al primo avvio come “Mandatory”.
Cliccando “Connect” in un’istanza in cui non è configurata la crittografia delle connessioni otterremo un errore del tutto simile a questo:
Per iniziare: cos'è la Crittografia della Connessione (Connection Encryption)?
Perché è importante?
- Protezione dei dati sensibili: le informazioni sensibili, come le credenziali degli utenti e i dati aziendali critici, sono protette da intercettazioni durante la trasmissione.
- Integrità dei dati: la crittografia garantisce che i dati non vengano alterati durante il trasferimento.
- Conformità normativa: molte normative di sicurezza dei dati, come GDPR, HIPAA (Health Insurance Portability and Accountability Act), e PCI-DSS (Payment Card Industry Data Security Standard), richiedono la crittografia dei dati in transito.
Come si implementa Crittografia della Connessione (Connection Ecryption)?
Il passaggio essenziale per configurare una connessione criptata in SQL Server è quello di ottenere un certificato SSL/TLS.
Ci sono diverse possibilità per ottenere un certificato, tipicamente:
Può essere emesso da un'autorità di certificazione (Certification Authority o brevemente CA) riconosciuta e approvata da Microsoft (tipicamente un servizio a pagamento).
Internamente alla propria organizzazione, se si prevendono CA interne al proprio perimetro aziendale.
In proprio tramite la generazione di certificato auto firmato.
Il certificato emesso deve avere le seguenti caratteristiche per funzionare correttamente con SQL Server:
Key Usage (KU): Il certificato deve avere l'attributo "Key Usage" che include "Digital Signature" e "Key Encipherment".
Enhanced Key Usage (EKU): Il certificato deve includere l'attributo "Server Authentication" (OID 1.3.6.1.5.5.7.3.1).
Nome Comune (CN) o Subject Alternative Name (SAN): Il nome comune (CN) del certificato deve corrispondere al nome del server SQL o deve essere presente nel campo Subject Alternative Name (SAN).
Algoritmi di Crittografia: SQL Server supporta certificati che utilizzano algoritmi di crittografia come RSA. È importante che la lunghezza della chiave sia adeguata (ad esempio, almeno 2048 bit per RSA).
Attenzione, è buona prassi impostare nel CN l’esatto FQDN (Fully Qualified Domain Name) dell’istanza. In alternativa ma obbligatoriamente va impostato come possibile alternativa (SAN) se vogliamo che client in fase di connessione validi il certificato.
Ho ottenuto il certificato, ora?
Un certificato si presenta come un file o una coppia (certificato e chiave privata), tipicamente i formati più comuni sono i seguenti:
Formato PFX (PKCS #12) (.pfx o .p12): è il formato preferito per importare certificati in SQL Server perché consente di gestire facilmente la chiave privata associata al certificato. Durante l'importazione, SQL Server richiederà la password associata al file PFX per sbloccare la chiave privata.
Formato CER/CRT (X.509) (.cer o .crt): sebbene SQL Server possa utilizzare certificati in questo formato, essi devono essere combinati con la chiave privata corrispondente. Questo formato da solo non è sufficiente per configurare SQL Server per le connessioni SSL/TLS.
Formato PEM (.pem): SQL Server non supporta direttamente l'importazione di file PEM. Tuttavia, è possibile convertire un file PEM in un file PFX, che è supportato, utilizzando strumenti come OpenSSL.
Formato DER (.der): come il formato PEM, SQL Server non supporta direttamente l'importazione di file DER. Tuttavia, questi file possono essere convertiti in un formato PFX utilizzabile.
Qualora avessimo in nostro possesso certificato e chiave private disgiuntamente è necessario accoppiarli con uno strumento apposito, anche in questo caso OpenSSL può essere un candidato.
Il file (certificato) va “agganciato” all’istanza SQL Server attraverso SQL Server Configuration Manager: esiste la scheda “Certificate” dedicata allo scopo.
L’opzione è raggiungibile alla voce da SQL Server Network Configuration - Protocols for MSSQLSERVER - Tasto destro "Properties".
Il certificato che vogliamo associare all’istanza deve essere una voce disponibile nel menu a tendina Certificate; per comparire deve essere stato correttamente importato.
Se la versione di SQL Server è 2019 o superiore è possibile importarlo direttamente tramite il pulsante dedicato “Import” seguendo la procedura guidata. Per versioni precedenti, ma in generale in ogni caso, è possibile procedere all’importazione attraverso la Windows Management Console.
Per un ulteriore approfondimento su questa operazione si rimanda alla documentazione ufficiale Microsoft qui.
Se il certificato, una volta importato, rispecchia tutti i requisiti necessari comparirà come voce nel menu tendina. Qualora esistessero più certificati con lo stesso nome è possibile selezionarne uno alla volta e verificarne i dettagli attraverso il tasto “View…” per selezionare quello corretto.
Cliccando “Apply” il certificato verrà associato all’istanza, apparirà quindi un messaggio che ci indica che le modifiche saranno effettive solo al primo riavvio del servizio MSSQL.
Nel caso il file venga importato tramite MMC (Windows Management Console) è necessario assicurarsi che l’utenza che esegue il servizio di SQL Server sia in possesso dei permessi sul certificato stesso. Sintomo della mancanza di permessi è il crash dell’istanza in fase di avvio del servizio.
Ho attivato il certificato e riavviato l’istanza, cosa cambia?
Lato client cosa è necessario fare?
Lato server abbiamo seguito i passi necessari per attivare l’encryption. Una domanda che sovente viene posta è: che impatto ha questo sul client e quali accorgimenti è necessario attuare?
Questi possono variare dalla tipologia e dalla versione dei driver di connessione utilizzati.
Genericamente (soprattutto se vogliamo SOLO connessioni criptate) possiamo riassumere i controlli necessari in:
- Utilizzo di un Driver di Connessione Compatibile: sembra banale in quanto anche le tecnologie meno recenti supportano largamente l’encryption ma vale la pena sempre fare una verifica con la documentazione ufficiale. In caso di applicativi è necessario determinare quale sia la tipologia e della versione del connettore.
- Configurazione della Stringa di Connessione:spesso, soprattutto sui driver meno recenti, va specificato che si intende stabilire una connessione criptata. La stringa di connessione va quindi modificata in maniera da esplicitare l’indicazione tipicamente con l’aggiunta di una parola chiave.
Es. In Ado.Net (C#) va aggiunta alla stringa di connessione: Encrypt=True;
Se si tratta di applicativi di qui non abbiamo controllo diretto va verificato se l’opzione è configurabile in qualche maniera.
Nelle versioni più recenti può essere vero anche il contrario: Entity Framework Core 7.0 per esempio se non specificato imposta la connection encryption di default a True obbligando a modificare la stringa esplicitamente a false se la crittografia non è supportata dall’istanza. - Certificato del Server:se l’istanza utilizza un certificato auto firmato o un certificato emesso da una CA interna, il certificato radice (root certificate) deve essere installato nel client. Questo è necessario perché i certificati non riconosciuti da CA pubbliche non saranno considerati attendibili dal client, cosa necessaria per iniziare la catena di validazione prevista dal TLS/SSL.
Verifica delle connessioni in ingresso a SQL Server
Per verificare lo stato delle connessioni sull’istanza è possibile eseguire la seguente query:
SELECT * FROM sys.dm_exec_connections
L’opzione Trust Server Certificate
Anche una connessione locale all’istanza deve seguire la stessa regola, non funziona nemmeno “localhost”.
I certificati hanno una data di scadenza
È bene ricordarsi che un certificato ha una data di fine validità, alla scadenza quindi la validazione dello stesso fallirà bloccando le connessioni in ingresso. È buona norma attrezzarsi in tal senso ed essere avvisati per evitare disservizi.
In conclusione
