Sono sempre più frequenti le richieste da parte di It manager che devono risolvere i problemi generati dai loro utenti relativamente alle presunte inconciliabilità di una struttura di strong authentication con quella di produttività personale. C’è una risposta: fare il Single sign on.
Allo stato attuale la maggior parte degli utenti si lamenta della molteplicità delle informazioni di accounting in relazione al numero di applicazioni utilizzate. Troppi userId, troppe password, troppi token, insomma.
Le organizzazioni, soprattutto quelle che operano su scala internazionale, hanno una molteplicità di applicazioni, reti e piattaforme. I loro dipendenti, inoltre, devono poter accedere alle informazioni a prescindere dal luogo ove queste si trovino; e allo stesso tempo le aziende devono poter garantire la sicurezza di accesso. Senza poi contare la cosiddetta "legge sulla privacy" che, di fatto, ha stabilito dettami ben precisi sulle modalità di fruizione delle applicazioni, anche in ordine alla necessità di "non replicare" l’accesso contemporaneo dello stesso utente da due workstation differenti.
L’avvocato Luca De Grazia, patrocinante in Cassazione ed esperto internazionale di privacy, ha "ammonito" i responsabili It aziendali, affermando che in mancanza di idonei meccanismi di autenticazione, associati a corrette politiche di sicurezza, qualunque altro tipo di tecnologia se non allineata con quanto stabilito dalle normative, potrebbe rivelarsi in contrasto con il Dpr n.318/99, applicativo e integrativo della legge 675/96. Ciò significa che una delle esigenze fondamentali è quella di conciliare aspetti tecnologici, produttività e aderenza alle leggi vigenti, queste ultime in continua evoluzione.
Una soluzione a queste problematiche è data da una corretta implementazione di un sistema di Single sign on (Sso). Il suo obiettivo è gestire in maniera integrata e univoca più processi di autenticazione riconducibili a un unico utente.
Le basi di un Sso
Solitamente un sistema di questo genere ha un engine centralizzato di gestione che, ovviamente, effettua vari controlli di congruità basandosi sia su politiche sia su l’esercizio di crittosistemi. Appare, quindi, evidente che ci si debba appoggiare su un servizio di directory e di Pki. In questo caso è necessario sceglierne uno basato su standard aperti (Ldap) e su una crittografia robusta, possibilmente non proprietaria, in grado di garantire la massima integrazione tra sistemi appartenenti ad altri poli transazionali.
Utilizzando un sistema di crittografia di questo genere si potranno raggiungere vari obiettivi di sicurezza che vanno dall’autenticazione "certa" dell’utente (soprattutto in caso di utilizzo di dispositivi biometrici) all’impossibilità di ripudiare le transazioni effettuate.
Il livello superiore della soluzione è dato dalla creazione di un ambiente grafico, dotato di icone che identificano le applicazioni alle quali l’utente può accedere dopo essersi autenticato con successo.
È indubbio, quindi, che l’integrazione debba essere assoluta, anche in ordine alle tipologie di sistemi di tipo two factor che potrebbero essere impiegati. Nulla deve impedire, quindi, di utilizzare l’infrastruttura di base integrata con sistemi di token e di biometria. Molti di questi sono implementati in azienda prima dell’installazione di un sistema Sso. Questo comporta l’esigenza di massima compatibilità verso il basso, nonché di una tutela degli investimenti già effettuati.
I requisiti di amministrazione
Un problema spesso evidenziato è poi quello dell’amministrazione dei sistemi di autenticazione sotto Os/390. Appare necessario, quindi, che la scelta di un sistema Sso debba poter soddisfare la gestibilità anche di queste piattaforme, quindi non solo i vari Windows Nt, 2000 o Unix. Questo, ovviamente, non è l’unico nodo da sciogliere. Rimane altresì il tema della gestibilità da parte degli amministratori.
Una buona soluzione è quella proposta da alcuni vendor i quali consentono il management dell’engine via Web. In questo caso il polo centrale ha un Web server in grado di generare pagine dinamiche, che tra l’altro, tengano traccia dei tentativi di intrusione. Solitamente si interviene con un repository dei log, a sua volta tutelato da un firewall. In questa maniera ogni violazione è registrata e gli allarmi indirizzati ai responsabili della sicurezza. E mai come in questo periodo stiamo assistendo alla massima integrazione tra sistemi di Sso con firewall e Ids.
La personalizzazione degli ambienti, poi, è un’altra palese "conditio sine qua non". Il trend è quello di fornire soluzioni con un Software developer kit (Sdk), comprendente Api che possono essere utilizzate sia dai software vendor, sia dai dipartimenti di sviluppo interni all’azienda per accedere a risorse particolari. Se tutto ciò accade, la produttività delle aziende che adottano un Sso, aumenta, grazie anche a una conseguenziale velocità operativa e un innalzamento del livello di sicurezza generale.
