Gestire correttamente la fiducia in una rete Zero Trust Security è fondamentale: sapere quanto fidarsi di qualcuno è infatti inutile senza essere in grado di associare un volto a quell’identità di cui vorremmo fidarci.
Quindi, la domanda è: come possiamo essere ragionevolmente certi che la persona (o il sistema) dall’altra parte della linea (Ethernet, Wi-Fi o satellitare che sia) sia effettivamente chi sostiene di essere?
Zero Trust Security: cos’è, quali sono i principi cardine e i fondamenti applicativi
Indice degli argomenti
Lo standard per l’autenticazione forte in una rete ZTS
Tipicamente i sysadmin esaminano l’indirizzo IP del sistema remoto e chiedono una password. Sfortunatamente, da soli questi metodi non sono sufficienti per realizzare una rete ZTS, dove abbiamo appreso che gli attackers potrebbero comunicare da qualsiasi indirizzo IP a loro piacimento e inserirsi tra noi e un host remoto (apparentemente) affidabile.
Pertanto, è importante impiegare l’autenticazione forte (“strong authentication”) su ogni flusso della rete ZTS.
Il metodo più diffuso per ottenere questo, è l’adozione di uno standard denominato X.509, che la maggior parte dei sysadmin conosce (e dovrebbe padroneggiare). X.509 definisce uno standard di certificato digitale che consente di verificare le identità attraverso una catena di fiducia (“Chain of trust”) ed è comunemente utilizzato come principale meccanismo d’autenticazione delle connessioni TLS (ex SSL).
Al lettore meno esperto pongo questa domanda: perché dovremmo volere utilizzare un meccanismo di autenticazione su TLS? La configurazione TLS più diffusa convalida che il client stia interagendo con una risorsa server attendibile, ma non che il server stia effettivamente interagendo con un client a sua volta trustato (“fidato”).
Questo scenario pone un ovvio problema per le reti ZTS e, a tal fine, il lettore sappia che TLS supporta anche l’autenticazione reciproca (mTLS, acronimo di Mutual TLS), in cui il server convalida anche il client.
Questo scenario è un passo importante per la protezione di risorse private, giacché in caso contrario il client sarà stato appunto non autenticato (lasciando quindi al server la possibilità di “agganciare” inavvertitamente anche client non autorizzati, quando non espressamente malevoli).
Una scadenza per le credenziali di accesso
Oltre agli aspetti di mutua autenticazione, è fondamentale che le credenziali abbiano anche una scadenza impostata e successivamente verificata da sistemi automatizzati: infatti, impostare una scadenza minimizza le possibilità che le chiavi di autenticazione possano essere compromesse o rubate nel medio/lungo periodo, offrendo al tempo stesso ai sysadmin l’opportunità di riaffermare la Chain of trust (catena della fiducia).
L’atto di cambiare e rinnovare periodicamente le chiavi a una certa scadenza va sotto il nome di rotazione delle credenziali (“credential rotation”) ed è fondamentale per minimizzare la possibilità che le password vengano rubate o compromesse nel lasso di tempo impostato dai sysadmin (“countdown delle credenziali”).
A tal proposito, dovrebbero essere evitati come la peste nera tutti quei sistemi o servizi che offrono credenziali hardcoded o comunque impossibili da cambiare, così come bisognerebbe fare attenzione a questi aspetti nel momento in cui ci troviamo davanti a una reingegnerizzazione, o ancor di più, a una scrittura a tavolino del progetto di una nuova rete ZTS. La frequenza di rotazione delle credenziali è spesso inversamente proporzionale al costo della rotazione stessa.
L’importanza delle PKI in una rete ZTS
Per definirsi tale, un’infrastruttura ZTS ha necessità di affidarsi ad una o più PKI per dimostrare le identità in tutta la rete. Le entità che possono essere autenticate con un certificato digitale includono:
- dispositivi
- utenti
- applicazioni
A causa dell’enorme numero di certificati digitali che una rete ZTS ha necessità di rilasciare, è importante mettere in piedi processi di automatizzazione. Se sono assolutamente necessari funzionari in carne ed ossa per elaborare richieste di firma dei certificati, la procedura sarà applicata con maggior lentezza, indebolendo complessivamente il sistema.
Detto questo, per quanto riguarda i certificati ritenuti assolutamente importanti, probabilmente il cliente desidererà mantenere un processo di rilascio e autenticazione basato su risorse umane.
PKI è generalmente implementato come sistema di trust pubblico, supportando certificati X.509 in uso su Internet. In questa modalità, la terza parte fidata è trustata pubblicamente, consentendo ai client di autenticare le risorse che appartengono ad altre organizzazioni.
Sebbene l’infrastruttura PKI pubblica sia considerata da anni attendibile, non è consigliabile per l’uso in una rete ZTS; uno dei primi fattori che votano a sfavore dell’utilizzo di una PKI pubblica è il costo: un sistema PKI pubblico si basa su CA (Certification Authority) pubbliche per ottenere la convalida dei certificati. Queste CA sono imprese a sé stanti, e generalmente (fatto salvo il più unico che raro caso di Let’s Encrypt) addebitano un costo per la firma sul certificato. Poiché una rete ZTS deve disporre di molti certificati, la firma, ovviamente, può divenire velocemente un costo non banale, soprattutto se si ragiona in termini di policy di rotazione.
Un altro svantaggio significativo delle PKI pubbliche è il fatto che è rischioso fidarsi completamente (azzarderei “ciecamente”) delle CA. Esistono molte CA pubbliche che operano in paesi con una legislazione molto diversa da quella europea, soprattutto in tema di privacy e sorveglianza di massa.
In una rete ZTS che sfrutti uno o più infrastrutture PKI pubbliche, una qualsiasi di queste CA può tecnicamente sbirciare tra i flussi (oltre al fatto stesso che anche una PKI pubblica può essere compromessa: chi non ricorda infatti l’eclatante caso della CA Diginotar?) apparentemente cifrati di cui la tua rete si fida, e da qui sorge la mia domanda: ti fidi delle leggi e dei governi in cui operano quelle CA? Forse sì, forse no: l’approccio più cauto, tuttavia, per evitare sorprese di qualunque tipo, è che probabilmente non dovresti più di tanto fidarti.
A tal fine, mentre è vero che esistono “mitigazioni” come il blocco dei certificati o l’installazione di soluzioni di Trust in una singola CA pubblica, rimane comunque complicato mantenere la fiducia in un’organizzazione disgiunta.
Inoltre, aspetti di flessibilità e personalizzazione possono risentirne quando ci si affida alle CA pubbliche, giacché quest’ultime impiegano spesso massicce misure di sicurezza utilizzando policy che filtrano come vengono formati i certificati e quali informazioni possano o non possano esservi annegate all’interno, e in che sezione.
Ciò può influire negativamente sull’autenticazione ZTS in quanto, spesso, è necessario archiviare i metadati specifici del sito all’interno del certificato, ad esempio come un ruolo o come un ID utente.
Inoltre, non tutte le CA pubbliche forniscono interfacce programmabili, rendendo l’automatizzazione più complessa.
