”Vecchio come la Rete”, il tema del Digital identity management ritorna giovane e interessante se applicato a strutture di commercio elettronico. Il vincolo del non-ripudio della transazione obbliga a uno sforzo di riconoscimento dell’utente che, a volte, le aziende non riescono a compiere
Se si guarda alla cronologia degli eventi correlati, la gestione dell’identità digitale (detta anche Digital identity management) ha origini abbastanza datate, e forse direttamente collegate ai lontani furti di Social Security Number accaduti negli Usa. Tuttavia, allo stato attuale, l’argomento riveste un’importanza maggiore, in quanto sempre più applicazioni relative all’e-business si basano su autenticazione dei poli transazionali e, soprattutto, sul non ripudio.
Gli analisti sono chiari: nei prossimi tre anni tutte le applicazioni di commercio elettronico sussisteranno solo se saranno garantiti autenticazione, accounting e accessi granulari. Non saranno consentite falle.
La storia dell’identity management vede ormai il “semplice” binomio UserId/password andare verso un declino irrecuperabile. Il fatto è che le applicazioni di oggi sono sempre più trasversali e interessano più organizzazioni contemporaneamente, anche sotto forma di servizi basati su Web. Perciò, a prescindere dai motori applicativi propri di ogni soluzione, si ritiene che un’infrastruttura comune di “secure” identity management dovrà essere implementata.
Allo stato attuale è possibile farlo in due modi:
* utilizzando un’applicazione residente che gestisce internamente la parte transazionale di base e si affida a gateway esterni di verifica dell’identità e dei pagamenti;
* utilizzando un outsourcer. In tal caso tutta la gestione è “data fuori”.
Va comunque detto che è probabile che l’outsourcer lavori, a propria volta, affidandosi a un terzo, in quanto non in grado (per varie ragioni) di erogare il servizio richiesto.
Di base la gestione di un’identità digitale poggia su due punti fondamentali. Il primo è relativo al metodo di autenticazione. Quest’ultimo, a propria volta, si basa su autenticazione di tipo “strong” (forte) e sull’utilizzo di certificati digitali.
Il concetto di strong authentication è inerente l’utilizzo di token e/o di biometria. In questo modo l’utilizzo delle password diventa marginale, e lascia il posto a fattori di ben più importanti caratteristiche. La seconda parte riguarda la gestione dell’identità in senso stretto, cioè la certificazione dell’identità medesima.
A questo punto, ovviamente, intervengono strutture quali le Pki (Public key infrastructure) e la protezione perimetrale. Solitamente queste ultime due componenti lavorano in maniera integrata e, in molti casi, l’una sembra assorbire l’altra. Nello specifico, il firewalling è in grado, interagendo altresì con i servizi di metadirectory, di applicare in prima persona le politiche di accounting, raggiungendo livelli di granularità davvero molto alti.
Il metadirectory (si veda a pagina VII) è sicuramente una delle componenti cruciali di tutta l’infrastruttura. Detta anche Data store, l’Md è comunque correlata, nel funzionamento, a una varietà di processi come, autenticazione, verifica dell’identità, autorizzazione e via dicendo. Tuttavia le directory sono soltanto dei contenitori, necessari ma non sufficienti, da soli, a gestire l’Identity management.
Dal punto di vista implementativo, alla base di tutto c’è l’esigenza di definire utenti e operazioni ad essi correlati. Deve inoltre essere possibile applicare politiche e regole definite e poterle modificare in qualsiasi momento. Scalabilità e portabilità sono fondamentali in questa tipologia di sistema. Non importa quanto la struttura sia grande o estesa: ogni identità, vista come oggetto, deve essere gestibile in maniera rapida e flessibile. Tuttavia può verificarsi anche la possibilità di dover gestire gruppi omogenei di utenti aventi profili simili. Ecco, allora, che la granularità deve trasformarsi in una flessibile aggregazione di identità.
Un valido precursore
il 4 domain model
Anche se sono ancora molti i consorzi di carte di credito che utilizzano il paradigma del “three domain”, Visa, per esempio, fece tesoro di esperienze di competitor non proprio positive e creò una soluzione più snella, denominata 3Dm, Three domain model.
Lo scopo di 3Dm è garantire l’autenticazione completa delle parti in gioco. In questo caso, tuttavia, l’utente deve scaricare un modulo software costituito da un plug in. Le componenti più complesse del sistema sono affidate ai server. I tre “domini” consistono nella banca “Acquirer”, che si occupa degli on line Merchant, “l’issuer”, cioè l’istituto di credito emittente, e nella struttura per l’interoperabilità dei soggetti. Questo sistema ha dalla sua una metodica di riscontri sull’identità dei poli decisamente robusta. Rimane, ancora, da determinare definitivamente che ruolo deve avere il database delle carte di credito, gestito dal Merchant.
Un’idea italiana, che ha visto la luce quasi due anni fa, è stata il “Four domain model”, in base al quale il database dei numeri di carta di credito non è più di competenza del Merchant, ma resta competenza esclusiva degli Issuer. La verifica della emissione viene effettuata direttamente (via gateway) con il circuito dell’Issuer. I riscontri sull’identità del Merchant erano evidentemente finalizzati ad una maggiore robustezza. In quello scenario, il valore aggiunto nei confronti del Buyer veniva dato dalla presenza di un’assicurazione sulla transazione, fornita dal service provider (denominato PagoSicuro) agli utenti registrati. Ammesso che anche i non registrati potevano effettuare acquisti con un Merchant associato a PagoSicuro, ma senza assicurazione, la registrazione non implicava l’immissione di numeri di carta, ma soltanto dei dati personali, cautelati su un database offline con crittosistemi a 128bit. Tutte le procedure di interazione tra il Buyer e PagoSicuro sono gestite da crittosistema: all’utente non sono richiesti strati aggiuntivi di software né ulteriori procedure di registrazione. Per la gestione del Pin non c’è bisogno di smart card (a suo tempo, peraltro, fu anche pensato un duplice crittosistema implementabile eventualmente con un token del tipo SecureID o una chiave Usb).
In questo momento alcune aziende stanno rivalutando il modulo di Pagosicuro, integrandolo direttamente in un’architettura di tipo Web Service e basata su metadirectory.
Corsi e ricorsi storici, verrebbe da dire. Fatto sta che , nonostante i disfattisti vedano, con un’alternanza di tre anni, il ripetersi degli stessi concetti, magari con un un rebranding, le esigenze di clienti e fornitori sono rimaste le stesse: fare business in “relativa” tranquillità.
A conforto di ciò, l’ex direttore editoriale del Computer Security Institute (il responsabile del rapporto mondiale Csi/Fbi per intenderci), ora passato al mondo della consulenza, è rimasto piacevolmente colpito dal fatto che, nel nostro Paese, non vi siano ancora concetti simili al Social Security Number, così gettonato dai Cyber Criminali per eseguire le truffe online. Peraltro, anche se in formato molto ridotto, le truffe di questo genere esistono anche qui in Italia, e soprattutto nel settore di alcuni acquisti online e nelle gestioni delle identità di accesso degli utenti dial up a Internet. È indubbio, comunque, che la situazione debba sicuramente cambiare e, forse, in questo caso la nuova tecnologia dei servizi Web assume un ruolo infungibile dal punto di vista delle soluzioni applicabili.
