La verifica di TLS e certificati deve seguire tutti i collegamenti che trasportano dati personali, dal client ai componenti interni e ai fornitori. Il simbolo di connessione protetta nel browser descrive soltanto una parte del percorso. Per ottenere una protezione affidabile occorre conoscere endpoint, protocolli, identità del servizio, gestione delle chiavi e comportamento in caso di errore.
Questa guida sviluppa il percorso operativo del controllo delle configurazioni TLS: inventario, riferimento tecnico, certificati, collaudo e manutenzione. Le raccomandazioni IETF per l’uso sicuro di TLS e DTLS costituiscono un riferimento tecnico; l’articolo 32 GDPR richiede misure adeguate al rischio, senza fissare una configurazione identica per ogni servizio.
Nel luglio 2026, la RFC 9852 ha aggiornato la RFC 9325 per i nuovi protocolli che utilizzano TLS: richiede TLS 1.3 come impostazione predefinita e consente TLS 1.2 come opzione non predefinita per esigenze di adozione. Il suo ambito non comprende DTLS e non introduce un divieto legale generale o una scadenza universale per i servizi esistenti che utilizzano TLS 1.2. Nel fascicolo distinguete quindi protocollo nuovo, servizio esistente e requisiti tecnici effettivamente applicabili.
Inventariare gli endpoint realmente utilizzati
Elencate siti, API, servizi di posta, console amministrative, applicazioni interne e connessioni verso terzi. Per ogni endpoint registrate nome, porta, componente che termina TLS, proprietario e utenti previsti. Includete ambienti secondari che trattano dati reali: un sistema di assistenza può essere meno visibile del portale pubblico e contenere informazioni altrettanto delicate.
Collegate l’inventario alla mappatura dei sistemi e dei flussi. Un collegamento può attraversare bilanciatori, proxy e servizi applicativi, con protezioni differenti su ciascun tratto. Indicate dove il contenuto viene decifrato e quali soggetti o processi possono accedervi.
Verificate anche endpoint non più documentati ma ancora raggiungibili. Domini storici, servizi di prova e configurazioni lasciate attive dopo una migrazione possono mantenere una superficie di esposizione. La loro presenza deve avere un proprietario e una finalità oppure diventare un’azione di rimozione controllata.
Definire la configurazione ammessa
Scegliete un riferimento tecnico aggiornato e compatibile con il contesto. Registrate versione, data della valutazione e sistemi cui si applica. Le raccomandazioni possono evolvere; una configurazione approvata anni prima deve essere riesaminata, soprattutto quando librerie o client non sono più supportati.
Documentate protocolli ammessi, algoritmi pertinenti, autenticazione del servizio e restrizioni richieste. Evitate di mescolare prescrizioni di fonti diverse senza verificare le ipotesi. Un riferimento destinato a una pubblica amministrazione straniera può essere utile sul piano tecnico, ma non diventa automaticamente un obbligo giuridico italiano.
La scheda dovrebbe distinguere baseline ordinaria ed eccezioni. Per un client datato, descrivete necessità, dati trattati, esposizione, compensazioni e piano di aggiornamento. La compatibilità non può essere una giustificazione indefinita per mantenere una configurazione debole senza decisione del responsabile del servizio.
Verificare identità e catena del certificato
Controllate che il certificato corrisponda al nome utilizzato dal client e che la catena sia verificabile nel contesto previsto. Esaminate scadenza, soggetto emittente e configurazione degli intermedi. Il servizio può funzionare su un browser moderno e fallire su un client applicativo che utilizza un archivio di fiducia diverso.
Per le infrastrutture interne, chiarite come vengono distribuiti i riferimenti di fiducia e chi può emettere certificati. Una propria autorità di certificazione richiede protezione e gestione: non è sufficiente aggiungere un certificato a ogni dispositivo senza conoscere il processo di rinnovo e revoca.
Verificate il comportamento in presenza di nome errato, certificato scaduto o catena non attendibile. Un client che ignora questi errori può perdere la garanzia sull’interlocutore pur cifrando il traffico. Le eccezioni utilizzate nello sviluppo devono essere individuate e separate dalle configurazioni che trattano dati reali.
Governare chiavi private e rinnovi
Identificate dove si trovano le chiavi private, chi può leggerle e quali processi le utilizzano. Limitate copie e distribuzioni manuali. Un rinnovo automatizzato riduce alcune attività ripetitive, ma introduce dipendenze da credenziali, servizi e autorizzazioni che devono essere protette e monitorate.
La guida alla gestione delle chiavi permette di collegare generazione, custodia, rotazione e revoca. Distinguete rinnovo del certificato e sostituzione della chiave quando il processo lo richiede. Preparate un percorso per una sospetta compromissione, senza attendere la scadenza ordinaria.
Create avvisi che raggiungano un referente e un sostituto. Non limitatevi alla data di scadenza: verificate che il rinnovo sia stato distribuito a tutti i nodi e che il servizio presenti effettivamente il nuovo certificato. Un bilanciatore o un ambiente secondario può mantenere la versione precedente e produrre errori intermittenti.
Esaminare terminazione TLS e collegamenti interni
Disegnate il percorso dal client al dato. Se TLS termina su un proxy, documentate il tratto successivo e il suo livello di protezione. Considerate rete, privilegi, possibilità di intercettazione e autenticazione fra componenti. La presenza di un segmento interno non elimina automaticamente il rischio.
Quando viene utilizzata autenticazione reciproca, chiarite come si identificano i client e come vengono revocate le loro credenziali. Una configurazione valida sul server non descrive il ciclo di vita dei certificati distribuiti alle applicazioni. Il cambiamento di un fornitore o la cessazione di un’integrazione deve raggiungere anche questi accessi.
Il rafforzamento dei sistemi Windows e Linux completa l’esame di servizi, privilegi e librerie. TLS non corregge un processo compromesso che legge i dati dopo la decifratura: la protezione del canale deve inserirsi in un insieme coerente di misure.
Collaudare con un campione motivato
Definite cosa volete verificare prima di eseguire uno strumento. Uno scanner esterno osserva ciò che è raggiungibile dal suo punto di vista; un client interno può seguire un percorso differente. Conservate data, endpoint, metodo, configurazione osservata e limiti della prova.
| Controllo | Domanda | Esito utile |
|---|---|---|
| Protocollo | Il collegamento negozia una modalità ammessa? | Versione e condizioni osservate |
| Identità | Il client verifica il servizio atteso? | Comportamento con nome e catena validi |
| Errore | Una credenziale non valida viene rifiutata? | Fallimento controllato e messaggio coerente |
| Rinnovo | Tutti i nodi presentano il certificato aggiornato? | Campione delle istanze e data |
| Percorso | I tratti successivi al proxy sono conosciuti? | Mappa e controllo dei collegamenti |
| Revoca | Una credenziale cessata non permette più l’accesso? | Prova sul contesto pertinente |
Non usate un voto sintetico come unica conclusione. Leggete le rilevazioni e collegate ogni differenza al rischio e al servizio. Un risultato eccellente su un endpoint pubblico non dimostra che una API interna o un client di integrazione gestiscano correttamente i certificati.
Gestire anomalie e modifiche
Assegnate ogni anomalia a un referente con una decisione esplicita: correggere, approfondire, accettare temporaneamente con condizioni o dismettere il servizio. Per le modifiche che possono interrompere client esistenti, predisponete un pilota e una comunicazione alle funzioni coinvolte.
I log di sicurezza possono aiutare a riconoscere errori di negoziazione, accessi rifiutati e anomalie di rinnovo. Evitate però di registrare chiavi, segreti o contenuti personali non necessari. La diagnostica deve fornire informazioni sufficienti senza trasformarsi in una nuova copia dei dati trasmessi.
Se l’interruzione di un certificato incide su un servizio importante, collegate lo scenario al piano di continuità operativa. La soluzione di emergenza non dovrebbe consistere nel disabilitare indiscriminatamente la verifica dell’identità. Prevedete un recupero controllato e una persona autorizzata a decidere.
Conservare una baseline utilizzabile
Il fascicolo finale riunisce inventario, riferimento tecnico, configurazioni ammesse, gestione dei certificati, prove ed eccezioni. La politica di sicurezza informatica può stabilire quando i nuovi servizi devono entrare nell’inventario e chi ne conferma la verifica.
Riesaminate la baseline quando cambiano componenti, autorità di certificazione, minacce o requisiti dei client. Una verifica ripetibile deve permettere di capire non soltanto se il canale appare protetto, ma quale identità viene verificata, dove termina la protezione e chi mantiene le dipendenze necessarie al suo funzionamento.
Dopo la dismissione di un endpoint, verificate anche DNS, regole del bilanciatore e automazioni di rinnovo. Un nome ancora configurato può essere riutilizzato accidentalmente o mantenere credenziali non più necessarie. La chiusura deve includere rimozione dei riferimenti, revoca degli accessi pertinenti e aggiornamento della mappa, con una prova che il vecchio percorso non continui a ricevere traffico applicativo significativo.