Soa: un sogno per il business o un incubo per la sicurezza?

Che la sicurezza sia un fattore strategico per la continuità e il successo di una qualsiasi impresa crediamo che non debba essere né posto in discussione né dimostrato. È, come si dice, un postulato. In quanto fattore strategico, spetta quindi al business decidere quale linea seguire in proposito, nel senso che, stabilito che la sicurezza assoluta non esiste, tocca ai responsabili delle linee di business, e al Ceo in ultima analisi, valutare di volta in volta il livello di rischio che può essere accettato a fronte delle opportunità per l’attività e lo sviluppo dell’impresa che l’assunzione di tale rischio comporta. Ed è in questa capacità di gestire rischi e opportunità a vantaggio ultimo dell’impresa che sta il valore di un top manager. Questo vale sia per il rischio d’impresa, sia per quello operativo; ma mentre per il primo la responsabilità esecutiva del risk management è ancora del Ceo (aiutato dal Cfo per gli aspetti finanziari), la responsabilità della gestione del rischio operativo, essendo la quasi totalità dei processi di un’impresa gestita dai Sistemi informativi, ricade sul Cio. Ridurre i rischi It equivale a ridurre il rischio operativo; e per il Cio, oggi più che mai, la sicurezza è tra i primi, se non il primo, degli obiettivi.
Un secondo problema che dipende dai processi aziendali e quindi ricade di nuovo sul Cio è la compliance. Rendere l’azienda conforme alle normative comporta sovente interventi sul piano della sicurezza, ma, spinti anche da rigide scadenze temporali, si tratta quasi sempre d’interventi limitati alla risoluzione di una specifica richiesta o problema. E siccome la crescente complessità dei sistemi, imposta dalle inevitabili nuove istanze del business, fa lievitare anche i costi per le soluzioni di sicurezza, questi crescono più in fretta dei fondi disponibili, fondi che peraltro l’attuale situazione economica rende più esigui ed aleatori.
Si tratta, evidentemente, di un quadro critico, ma che ha il merito di tracciare le basi di quella che è l’unica via d’uscita: un approccio al governo e alla gestione di quello che possiamo chiamare ‘rischio informativo’ che ne comprenda e integri tutti i possibili aspetti; quelli legati alle tecnologie (infrastruttura fisica e funzionamento di reti, server e dispositivi utente), quelli legati ai processi, alle applicazioni e ai dati, e quelli legati alle persone.
In questo approccio assume un’importanza fondamentale la gestione in sicurezza delle applicazioni. Non solo perché le applicazioni aziendali sono il punto sul quale convergono gli effetti dei rischi provenienti sia dagli utenti e dai processi che devono servire, sia dalle tecnologie e dall’infrastruttura da cui sono servite; ma soprattutto perché il mondo delle applicazioni diventa sempre più complesso ed è investito da quella rivoluzione che prende il nome di Soa.
Come sappiamo, nella Soa le applicazioni sono (in tutto o in parte) formate da componenti elementari, chiamati ‘servizi’, del processo che devono supportare. Questi servizi sono realizzati in modo del tutto indipendente dalle applicazioni e dalle piattaforme che li utilizzano e possono essere sviluppati sia dall’It aziendale sia da organizzazioni esterne ad esso per essere ‘esposti’, rispettivamente, sulla intranet o sul Web in modo da poter essere prelevati dall’applicazione che ne farà uso. In ogni caso, quello che caratterizza una Soa è che i servizi che vanno a comporre le varie applicazioni non sono strettamente integrati tra loro, ma accoppiati in modo labile tramite interfacce standard che ne permettono la ricomposizione in nuove sequenze che modificano o cambiano del tutto la logica applicativa. Estendendo il concetto dai blocchi elementari all’intera applicazione sono nati i cosiddetti mash-up, ossia (vedi anche articolo "Meshup d’impresa: rischi e opportunità" ) applicazioni composite, di regola Web based, che aggregano ed utilizzano dinamicamente informazioni e contenuti forniti da altre applicazioni Web per creare un nuovo servizio business.
Tutto ciò, in un disegno teoricamente perfetto, consente all’It una flessibilità esecutiva senza precedenti, che facilita le attività necessarie per rispondere tempestivamente ad ogni nuova richiesta del business, dalle più semplici modifiche di procedura ai grandi cambiamenti introdotti, per esempio, da fusioni e acquisizioni. La funzione It fornisce quindi un concreto supporto alla competitività dell’impresa. E grazie al riutilizzo degli asset It può farlo a costi inferiori, sia di struttura sia operativi, rispetto ai tradizionali modelli di sviluppo e manutenzione del parco applicativo. Cio ha portato, come è ovvio, al successo che la Soa sta riscuotendo nelle imprese. Ma ha portato anche una formidabile sfida alla sicurezza.
Infatti, proprio l’indipendenza tra i servizi e le applicazioni che ne derivano e il fatto che la ‘vita’ dei servizi Web (che sono quelli verso i quali la Soa è proiettata) si estenda ben oltre i confini entro i quali l’impresa può esercitare un certo controllo, rende la sicurezza di un ambiente Soa particolarmente critica. Né, d’altra parte, è applicabile una politica di stretto isolamento del sistema informativo e dell’area operativa delle applicazioni aziendali, dato che la conduzione del business e i suoi stessi processi si basano in larga parte sui rapporti che l’impresa ha con i partner, i clienti, i fornitori e tutte le altre entità coinvolte nel suo ecosistema relazionale.

Diverse combinazioni di servizi: la sfida della security
Chi intende realizzare un’infrastruttura di sicurezza in un ambiente orientato ai servizi deve considerare in primo luogo la necessità di una diversa, e più complessa, gestione delle identità e degli accessi. I servizi sui quali, in una Soa, si basano le applicazioni composite vanno infatti singolarmente individuati attribuendo loro identità che vanno distinte e disaccoppiate dalle identità attribuite agli utenti (che, ricordiamo, possono essere persone o applicazioni software). A differenza che in un ambiente tradizionale, dove il rapporto tra le applicazioni e gli utenti, umani e non, è predefinito, in una Soa uno stesso servizio può far parte di applicazioni fruite da utenti diversi. Diventa quindi necessario fare in modo che i servizi possano essere composti e ricomposti senza che ci si debba ogni volta preoccupare di come portare la user-identity di un dato utente da un servizio all’altro.
Un discorso analogo riguarda gli accessi. Un utente può essere abilitato ad accedere a un servizio che a un certo punto viene combinato con altri servizi, ai quali invece quell’utente non ha accesso, per creare un servizio (ossia un processo di business) di livello superiore. Bisogna stabilire allora, caso per caso, se mantenere o meno i privilegi di accesso dell’utente e se questi privilegi devono estendersi al nuovo servizio così creato, andando quindi a riesaminare la policy di sicurezza per ogni nuova combinazione di servizi che venga realizzata.
Occorre in sostanza, ed in ciò consiste la sfida di un ambiente Soa, che le policy di sicurezza tengano in considerazione l’integrabilità dei servizi in diverse combinazioni in funzione dei cambiamenti dei processi di business. Diventa quindi indispensabile una gestione centralizzata ed unificata delle policy di sicurezza che da un lato sia quanto più possibile semplificata nelle sue regole per consentire quella flessibilità dei processi di business che è l’obiettivo stesso della Soa, ma dall’altro permetta di individuare e definire, con termini omogenei, tutti i legami che intercorrono tra gli utenti le operazioni di business. Ciò è necessario anche per applicare le funzioni di auditing previste dalla compliance alle leggi e ai regolamenti.
Per questo è utile definire un modello di riferimento che aiuti a realizzare un’architettura, dapprima logica e in un secondo tempo fisica, entro la quale collocare le varie soluzioni di sicurezza che il mercato propone per risolvere i problemi che si presentano a livello di infrastruttura, di applicazioni, di servizi di business e di servizi di sviluppo. In questo modello possiamo identificare quattro aree principali:
1) Gestione delle security policy, per la definizione, attuazione e monitoraggio delle politiche di sicurezza, a partire dalla gestione di identità e accessi di cui si è parlato;
2) Governo e gestione del rischio, con i meccanismi che permettono di attuare le politiche di sicurezza di cui sopra nell’intero ambiente interessato dalla Soa e i processi di analisi e valutazione dei rischi;
3) Sicurezza Business, riguardante cioè le esigenze di sicurezza del business, come la protezione dei dati scambiati tra i servizi, la sicurezza dei sistemi e della rete e così via;
4) Sicurezza It, che descrive l’infrastruttura Soa e provvede a rendere sicuri i servizi It erogando servizi, ad esempio, di certificazione d’identità, di ‘strong authentication’, di data integrity ed altri ancora.
A queste macro-aree possiamo aggiungerne una quinta, più ristretta, relativa alle tecnologie abilitanti, a partire dalla crittografia, utilizzate dai servizi di sicurezza per assolvere ai loro compiti.