Perché proteggere una password se si può farne a meno?

Un problema che abbiamo imparato a considerare normale

Praticamente ogni applicazione web ha un pannello di amministrazione. E un pannello di amministrazione, di norma, ha un indirizzo di accesso, un modulo di autenticazione, un nome utente e una password.

Siamo così abituati a questa struttura che abbiamo quasi smesso di chiederci: deve per forza funzionare proprio così?

Quando hai un solo sito, il problema non sembra rilevante. Crei una password complessa, attivi l’autenticazione a due fattori, imposti un limite ai tentativi di accesso e sei a posto.

Ma cosa succede quando i progetti diventano dieci, venti o trenta?

Nel mio caso si tratta dell’ecosistema DigiMeld, che riunisce più di trenta progetti software indipendenti. Ognuno ha la propria architettura, la propria logica lato server e la propria interfaccia di amministrazione.

Di conseguenza, ognuno ha bisogno di un meccanismo di accesso amministrativo.

Per molto tempo ho adottato un approccio del tutto convenzionale: credenziali amministrative separate, password complesse e salvataggio nel browser.

Funzionava.

Ma a un certo punto mi sono chiesto: perché dovrei conservare così tante password amministrative? Perché devo proteggere non solo i server, ma anche gli strumenti che mi consentono di accedervi?

E non potrei fare a meno di questa necessità?

Sono arrivato a un’idea che in seguito è diventata la base della mia soluzione:

Forse non dovremmo proteggere un accesso permanente, ma il diritto di ottenere temporaneamente l’accesso.

E se non ci fosse affatto una pagina di accesso tradizionale?

Ho deciso di abbandonare il modello tradizionale di autenticazione amministrativa nei miei progetti.

Non limitarmi a nascondere il modulo di accesso.

Non rinominare l’indirizzo.

Non sostituire la password con una ancora più complessa.

Ma eliminare la necessità di un accesso tramite password sempre disponibile.

Naturalmente, le interfacce di amministrazione non sono scomparse. Sono ancora necessarie per gestire le applicazioni.

È cambiato il modo di accedervi.

Ora, per entrare nei pannelli di amministrazione dei progetti collegati, non è necessario inserire un nome utente e una password salvati.

Uso invece il mio sistema di identificazione e gestione degli accessi, MeldID.

Il principio è abbastanza semplice: l’accesso amministrativo viene concesso solo quando serve davvero, a un utente specifico e per un progetto specifico.

Il semplice fatto di avere un account, inoltre, non dà diritto ad aprire il pannello di amministrazione.

Questo diritto deve essere concesso separatamente.

Un accesso che un minuto prima non esisteva

È probabilmente la parte più interessante dell’intero concetto.

Nel modello tradizionale, l’amministratore dispone costantemente degli strumenti per accedere. Può usarli oggi, domani o tra un mese, finché restano validi.

Ho deciso di cambiare questo principio.

Al posto di credenziali amministrative permanenti, c’è la possibilità temporanea di avviare l’accesso.

Viene generata su richiesta tramite un dispositivo mobile attendibile, include una componente casuale crittograficamente robusta e ha una validità limitata.

Ma il semplice possesso di questo link temporaneo non comporta comunque l’ottenimento dell’accesso.

È un punto fondamentale.

Supponiamo che qualcuno riesca in qualche modo a ottenere il link. In un sistema tradizionale basato esclusivamente sulla segretezza dell’indirizzo, una simile fuga di informazioni potrebbe rappresentare un problema serio.

Nel mio modello, il link consente soltanto di avviare la procedura di verifica.

Per proseguire, è necessaria un’autorizzazione separata tramite un dispositivo mobile attendibile con MeldID.

Senza la relativa conferma, non viene creata alcuna sessione amministrativa.

Per questo considero il link temporaneo non un sostituto della password, ma uno degli elementi della procedura di concessione dell’accesso.

Sapere a chi rivolgersi e avere il diritto di entrare sono due cose completamente diverse.

Il telefono diventa uno strumento per gestire gli accessi

In questo modello, il dispositivo mobile svolge un ruolo molto più importante di quello di un semplice generatore di codici monouso.

Viene utilizzato per confermare le operazioni legate all’accesso amministrativo.

Quando voglio aprire il pannello di amministrazione, il sistema richiede una conferma tramite MeldID.

Visualizzo la richiesta sul dispositivo attendibile e confermo l’operazione.

Solo dopo la verifica, il sistema consente di proseguire con la procedura di accesso.

La conferma è legata a un’operazione specifica, non al semplice fatto che il telefono sia stato sbloccato.

La biometria del dispositivo mobile verifica l’utente localmente, mentre il server controlla la conferma crittografica proveniente dal dispositivo registrato.

Questo approccio consente di non affidarsi esclusivamente a una password o a un messaggio che dichiara che l’utente avrebbe confermato l’accesso.

C’è poi un altro vantaggio: è possibile gestire i dispositivi attendibili.

Se un dispositivo non deve più essere utilizzato per confermare gli accessi, è possibile revocargli lo stato di attendibile.

A quel punto non potrà più essere utilizzato per autorizzare le operazioni in questione.

Un sistema, tanti progetti indipendenti

Quando ho iniziato a sviluppare questo meccanismo, uno degli obiettivi principali era mantenere l’indipendenza di ciascun progetto.

Non volevo riunire tutti i pannelli di amministrazione in un’unica enorme applicazione.

Ogni servizio DigiMeld doveva continuare a gestire la propria logica, le proprie impostazioni, i propri utenti e i propri dati.

Perciò ho separato le due funzioni.

MeldID si occupa dell’identificazione e della concessione dell’abilitazione amministrativa.

Il singolo progetto, invece, gestisce le proprie funzioni amministrative e verifica che le autorizzazioni siano valide.

Ne è risultato un modello centralizzato di gestione degli accessi, senza dover centralizzare le applicazioni stesse.

Inoltre, i permessi vengono assegnati separatamente.

L’amministratore di un progetto non ottiene automaticamente accesso agli altri solo perché ha un account MeldID.

È possibile definire un gruppo specifico di utenti autorizzati per ciascuna area amministrativa.

I permessi degli utenti ordinari e le autorizzazioni amministrative, inoltre, restano separati.

Questo si è rivelato particolarmente comodo per un ecosistema composto da decine di servizi.

Perché preferisco l’accesso temporaneo a quello permanente

C’è un altro principio che ho scelto consapevolmente di integrare nel sistema.

L’accesso amministrativo non deve durare all’infinito.

L’autorizzazione è valida per un periodo limitato e scade indipendentemente dal fatto che l’utente continui a usare il browser.

Per continuare a lavorare dopo la scadenza, occorre ripetere la procedura di conferma.

In questo modo, un’autorizzazione concessa una volta non si trasforma in un diritto permanente.

Ma limitare la durata non basta.

È importante poter revocare anticipatamente un accesso già concesso.

Per questo MeldID prevede la revoca centralizzata delle autorizzazioni amministrative.

Quando un’autorizzazione viene revocata, i progetti collegati ricevono un evento corrispondente e invalidano le sessioni amministrative associate.

Così, la gestione degli accessi non si conclude nel momento in cui l’utente ha effettuato l’accesso con successo.

Per me, poter revocare le autorizzazioni è importante quanto poterle concedere.

Un sistema distribuito deve comunque tenere conto dei ritardi nella trasmissione degli eventi, dell’indisponibilità temporanea di singoli componenti e di altre circostanze operative. La scadenza delle sessioni costituisce un’ulteriore misura di protezione.

Cosa è cambiato nel lavoro di tutti i giorni?

Prima di tutto, non è più necessario ricorrere continuamente alle password amministrative salvate.

Non devo più tenere nel browser un insieme di credenziali per accedere a ogni pannello di amministrazione collegato.

Gestisco invece le autorizzazioni tramite un unico meccanismo.

Scelgo il progetto necessario, confermo l’accesso e lavoro.

Quando l’accesso amministrativo non serve più, posso revocarlo.

È particolarmente comodo che l’aggiunta di un nuovo progetto non richieda di riprogettare da capo l’intero sistema di autenticazione amministrativa.

È sufficiente collegarlo al modello esistente e definire le autorizzazioni necessarie.

Naturalmente, questo non significa che siano scomparsi tutti i rischi per la sicurezza.

Anche le autorizzazioni temporanee, i dispositivi attendibili, le sessioni lato server e l’infrastruttura centrale devono essere protetti.

Ma non devo più affrontare separatamente, per ogni applicazione, lo stesso problema della gestione delle password amministrative.

Ed è proprio questo uno dei miei obiettivi iniziali.

Ma queste tecnologie non esistono già?

Certo che esistono.

L’autenticazione senza password, la gestione degli accessi privilegiati, le autorizzazioni temporanee e la conferma tramite dispositivi attendibili sono concetti noti da tempo nel settore della sicurezza informatica.

Approcci simili si trovano nei sistemi di Identity and Access Management, Privileged Access Management e nei modelli Zero Trust.

Non pretendo di aver inventato questi principi.

Il mio obiettivo era un altro.

Avevo bisogno di creare un sistema integrato tutto mio, capace di risolvere problemi specifici dell’infrastruttura DigiMeld e di consentire la gestione dell’accesso amministrativo a molti progetti indipendenti.

Ho quindi riunito diversi approcci già noti in un’unica architettura, conforme ai miei requisiti.

E ritengo che il valore del lavoro ingegneristico non consista necessariamente nell’inventare una tecnologia completamente nuova.

A volte consiste nel definire correttamente il problema e nel trovare una soluzione adatta.

MeldID non serve solo per i pannelli di amministrazione

Vale la pena fare una precisazione.

MeldID non è stato creato esclusivamente come strumento per il mio accesso amministrativo personale.

Offre anche agli sviluppatori un SDK per integrare nei propri progetti meccanismi di identificazione e conferma dell’accesso.

Inoltre, questo SDK è disponibile gratuitamente.

Per esempio, uno sviluppatore esterno può usare MeldID come ulteriore livello di verifica dell’autenticazione degli utenti.

Anche se l’applicazione mantiene il tradizionale accesso con nome utente e password, il corretto inserimento di queste credenziali potrebbe non essere sufficiente a completare l’autenticazione.

L’utente riceve una richiesta sul proprio dispositivo mobile attendibile, dove può confermare o rifiutare il tentativo di accesso.

Questo consente di ridurre il rischio di accessi non autorizzati in caso di compromissione delle credenziali.

È importante distinguere questa funzionalità di MeldID, disponibile al pubblico, dal modello di accesso amministrativo che ho sviluppato per i progetti DigiMeld.

Entrambi si basano su principi comuni di fiducia e conferma delle operazioni, ma rispondono a esigenze diverse.

La sicurezza non consiste solo nel proteggere ciò che già esiste

Il lavoro su questo sistema mi ha spinto a guardare in modo diverso ai consueti meccanismi di autenticazione.

Spesso cerchiamo di proteggere ciò che esiste per ragioni storiche.

Aggiungiamo nuove verifiche, restrizioni, altre password e livelli di protezione.

A volte è davvero necessario.

Ma a volte è più utile porsi un’altra domanda:

È davvero necessario che il meccanismo da proteggere continui a esistere nella sua forma attuale?

Nel mio caso, la risposta è stata no.

Non avevo bisogno di un modulo di accesso amministrativo sempre disponibile.

Avevo bisogno di poter ottenere in sicurezza i privilegi amministrativi proprio quando erano necessari.

Sono due esigenze diverse.

Passare dalla prima alla seconda ha cambiato non solo l’architettura tecnica, ma anche il lavoro quotidiano sui progetti.

Non un punto d’arrivo, ma una direzione scelta

Oggi questa architettura è già operativa in gran parte dell’ecosistema DigiMeld.

I progetti rimanenti vengono gradualmente trasferiti al nuovo modello di accesso amministrativo.

Procedo con la migrazione un progetto alla volta, verificando il funzionamento di ogni applicazione; una volta completata la transizione, ho in programma un ulteriore audit dell’intero sistema.

Alcuni elementi dell’interfaccia e le regole di gestione delle sessioni potrebbero ancora cambiare.

Ma l’idea di fondo è ormai definita.

Non voglio tornare a un modello in cui, per gestire decine di progetti miei, devo conservare e usare costantemente decine di password amministrative.

Questo non significa che consideri la mia implementazione una soluzione universale per tutti.

Organizzazioni diverse hanno esigenze, infrastrutture, modelli di minaccia e modalità di amministrazione diverse.

Ciò che è comodo e adeguato per l’ecosistema DigiMeld non sarà necessariamente la scelta migliore per un altro sviluppatore.

Tuttavia, il principio di concedere privilegi temporanei merita attenzione.

Per concludere

Ho deciso di condividere questa esperienza non perché mi consideri l’inventore di un nuovo metodo di autenticazione.

E nemmeno perché voglia presentare un altro sistema come assolutamente sicuro.

La sicurezza assoluta non esiste.

Mi sembra semplicemente interessante il modo stesso di porre la questione.

Invece di proteggere all’infinito un accesso amministrativo permanente, possiamo ripensare se sia davvero necessario che esista.

Invece di conservare decine di password, possiamo usare autorizzazioni temporanee.

Invece di concedere fiducia automaticamente dopo la prima autenticazione, possiamo confermare l’assegnazione di privilegi specifici.

Invece di aspettare la scadenza della sessione, possiamo prevedere la revoca centralizzata dell’accesso.

Infine, invece di avere un meccanismo di accesso separato per ogni progetto, possiamo realizzare un unico sistema di gestione delle autorizzazioni amministrative, mantenendo indipendenti le applicazioni.

Non sostengo che questo approccio elimini la possibilità di una compromissione.

Sposta semplicemente l’attenzione dalla protezione di credenziali permanenti alla concessione e alla revoca controllate dei privilegi.

Forse, a volte, il modo più efficace per ridurre la superficie di attacco non è aggiungere un altro meccanismo di protezione, ma rinunciare a ciò di cui il sistema può fare a meno.

È proprio da questa idea che è iniziata, per me, la storia di MeldID Admin Gateway.