Introduzione
L'industria del software è in una fase di intensa transizione
che vede come motore trainante il business e l'avanzamento
di una nuova visione dove le funzionalità offerte dai
vari asset software, sono viste come servizi "dinamici"
e "componibili", distribuiti sulla rete ( SOA -
Service Oriented Architecture ).
Il passaggio ad una visione architetturale orientata ai servizi,
prevede la costituzione di un layer di astrazione che nasconda
la complessità ed eterogeneità degli odierni
sistemi informativi (Figura 1).
Figura 1 - Gerarchia in architettura SOA
Colmare
il gap tra sistemi e servizi è logicamente più
complesso di gestire i singoli sistemi sottostanti: sistemi
eterogenei che collaborano alla soluzione (offrire il servizio),
mantenendo invariate le tecnologie su cui poggiano, richiedono
requisiti di gestione e sicurezza complessi.
Ad esempio, in caso di malfunzionamento (caduta del servizio,
manacanza di comunicazione, etc..) di uno dei componenti,
l'evento negativo si può propagare a macchia d'olio
verso gli altri componenti dell'architettura. La situazione
è ulteriormente aggravata dalla sovente mancanza di
controllo e conoscenza di tutto il dominio da parte di un
singolo gruppo di persone. (Figura 2)
Figura 2a - Interdipendenza delle componenti
Dal
punto di vista della gestione un'architettura SOA presenta
un grado di complessità maggiore in quanto singole
componenti possono essere aggiunte, modificate e corrette
riducendo al minimo gli impatti operazionali. Deve essere
possibile ridefinire i livelli di servizio (SLA) associati
ad ogni processo senza generare indisponibilità.
Figura 2b - Interdipendenza delle componenti
In
questo contesto il valore di business non è limitato
al singolo servizio, ma è accentrato sulla integrazione
e composizione di servizi. Al crescere della complessità
e del valore intrinseco che le architetture assumono, si amplificano
anche le esigenze di protezione dei sistemi che le compongono.
Pur essendo la necessità di maggior protezione ovvia
e visibile, la soluzione non è altrettanto banale:
non abbiamo necessità di un'ulteriore architettura
di sicurezza standalone, ma di una infrastruttura che possa
interagire tra le esistenti infrastrutture di sicurezza; Dobbiamo
focalizzare i nostri sforzi verso una soluzione che crei un
layer di astrazione sopra le tecnologie di sicurezza in uso.
La soluzione è "sovrastare" le attuali tecnologie
di sicurezza con un' architettura orientata ai servizi (SOA).
L'obiettivo di SOA non è definire ogni nuova funzionalità
(es. nuove tecniche di cifratura dei messaggi, nuovi metodi
di autenticazione, nuove tecnologie di trasmissione dei dati,
etc..), ma piuttosto fornire gli strumenti per rendere interoperabili
le attuali tecnologie senza creare vincoli funzionali e tutelandone
le caratteristiche in evoluzioni future.
I
concetti di un'architettura di sicurezza orientata ai servizi
Per capire pienamente come la sicurezza deve essere implementata
e gestita in un'architettura orientata ai servizi, è
necessario in primo luogo capire i principi della sicurezza
applicativa. La sicurezza, nel suo significato più
ampio, viene intesa come capacità di mitigare i rischi;
la sicurezza applicativa, in particolare, è volta a
ridurre l'esposizione ai seguenti attacchi:
- Eavesdropping:
questo attacco si concretizza nella compromissione della
riservatezza del messaggio senza però modificarne
la forma.
- Tampering:
una persona non autorizzata, modifica o sostituisce un messaggio
in transito.
- Impersonation:
l'informazione giunge a una persona che non è il
destinatario prefissato. Questo tipo di attacco può
presentarsi in una duplice forma attraverso l'impersonificazione
del destinatario (spoofing), attraverso l'esposizione di
credenziali fasulle (Mispresenation).
Ognuno
di questi attacchi lede i cinque requisiti che devono essere
propri di ogni sistema di sicurezza. In un'applicazione "lo
strato" che implementa la sicurezza deve garantire:
-
Auteniticazione: il destinatario deve essere sempre in grado
di verificare l'identità del mittente.
-
Autorizzazione: l'accesso ai dati deve sempre essere vincolato
da criteri che ne definiscono, previa autenticazione, le
azioni (lettura, scrittura) che possono essere intraprese
dai differenti utenti.
- Confidenzialità:
il contenuto di un messaggio deve essere disponibile solamente
per gli utenti autorizzati.
- Integrità:
il messaggio durante il transito non deve subire modifiche.
- Non
ripudio: Il "non ripudio" permette di provare
l'identità di tutte le parti che hanno partecipato
ad una transazione anche successivamente allo scambio del
messaggio.
Come
possono essere garantiti i cinque requisiti fondamentali in
un'architettura orientata ai servizi? La risposta è
intrinseca nella parola "trust". L'espressione "trust"
identifica : il requisito per cui ogni entità accetta
di delegare ad una seconda entità un set di azioni
necessarie alla fruizione del servizio.
Come un utente (service consumer), prima di affidare i propri
risparmi ad una banca (service provider), deve riporre su
di essa la propria fiducia (trust), altresì è
necessario creare una politica di trust tra i vari componenti
che costituiscono l'architettura SOA. Il fine ultimo di SOA
è creare "trust" tramite la definizione ed
applicazione di politiche di sicurezza sulla base di un modello
comune, senza appoggiarsi ad uno specifico meccanismo di sicurezza.
Un modello generico di politiche di trust deve fornire i seguenti
servizi:
- Policy
Enforcement Point: la componente applicativa che verifica
i diritti di autorizzazione prima di accordare l'accesso
a risorse protette. Per esempio, un'application server deve
verificare che un consumer presenti credenziali di autorizzazione
sufficienti ad accedere una data pagina web, modificare
un record di database, etc;
- Policy
Decision Point: il servizio che rilascia le credenziali
di accesso previa valutazione dell'identità del consumer,
dell'operazione e delle risorse richieste sulla base delle
politiche di sicurezza precedentemente definite. Ha una
conoscenza globale delle politiche di rete, ed è
consultato dai dispositivi di rete (come i routers) che
applicano le politiche;
- Polcy
Administration Point: un servizio che generi ed amministri
le policy;
- Security
Token Service: servizio che rilascia i token (credenziali
di autorizzazione ed autenticazione) sulla base delle informazioni
(proof of identity) fornite dal Policy Decision Point.
Figura 4 - Transazione distribuita
Nella
figura, sopra, è presentato il flusso che porta alla
conclusione di una transazione distribuita. Il Consumer ottiene
la risorsa, previa autenticazione tramite un terzo attore
di cui entrambe le parti (Seller e Consumer) ripongono fiducia.
Questo modello generale - richiesta, policies e security tokens
- supporta diversi modelli più specifici, come liste
di controllo accessi (ACL), identity management, etc, permette
l'utilizzo di tecnologie esistenti come i certificati a chiave
pubblica X.509, ticket Kerberos condivisi e password digests.
Inoltre, fornisce strumenti di integrazione permettendo la
creazione di bridge tra tecnologie differenti. Il modello
generale è sufficiente per costruire un meccanismo
di scambio di chiavi, autenticazione, autorizzazione, auditing,e
trust.
Autenticazione
e Autorizzazione
Il fine dell'autorizzazione e' controllare l'accesso alle
risorse (lettura di dati, scrittura, esecuzione di un programma,
utilizzo di una struttura hardware ...) mediante la definizione
di privilegi. Il metodo più semplice di gestire l'autorizzazione
è attraverso l'utilizzo di ACL (Access Control List)
che definiscono quali sono le azioni che possono essere condotte
su ogni risorsa da parte di un utente. Solitamente l'utilizzo
di ACL non è sufficiente per garantire il livello di
protezione necessario per ambienti enterprise dove sistemi
eterogenei vengono chiamati in causa, sia all'interno della
stessa azienda, sia attraverso più aziende. Ogni azienda
possiede policy di sicurezza proprie spesso supportate da
tecnologie differenti. La gestione dei diritti di autorizzazione
estesa su più sistemi e tecnologie, è un problema
che viene chiarito da specifiche che prendono il nome di WS-Security.
WS-Security definisce un layer di astrazione che permette
a infrastrutture differenti di "cooperare in piena fiducia".
Confidenzialità,
integrità e non ripudio
Garantire confidenzialità significa assicurare che
solo il destinatario possa conoscere i contenuti del messaggio.
Il problema di garantire confidenzialità diviene importante,
in quanto l'utilizzo dei Web Services comporta la gestione
del routing del messaggio tra gateway intermedi, utilizzando
esclusivamente le informazioni contenute sull'Header SOAP
o http: deve esistere un sistema che permetta ad ogni intermediario
di leggere, nonostante i metodi di crittazione, le parti del
messaggio che gli indicano come gestirlo (routing dinamico),
senza però comprometterne la confidenzialità
del contenuto. Allo stesso modo la garanzia dell'integrità
del messaggio e del non ripudio presentano problematiche,
molto simili a quelle appena esposte. Le specifiche WS-security
e quelle del linguaggio Security Assertion Markup Language
sono volte alla gestione di tale problematiche.
Service
Oriented Management
Preservare i requisiti di sicurezza, è solo una delle
problematiche cui gli IT Manager si trovano ad affrontare
nella migrazione da una architettura tradizionale ad una orientata
ai servizi.Tali problematiche possono essere diversificate
in cinque categorie: system management, Web Services lifecycle
management, business-oriented management, security management
e "SOA Enablement", come mostrato in Figura 5.
Figura 5 - Categorie di funzionalità nella gestione
Service Oriented
Le
categoria di System Management include le funzionalità
di monitoring dei WebServices e dei sistemi a loro sottostanti
includendo l'auditing, reporting ed il sistema di alerting
in caso di problemi. Sono presenti in questa categoria anche
l'identificazione ed il mantenimento dei livelli di servizio
e la gestione delle eccezioni.
Lifecycle Management ha il compito di gestire il processo
di inserimento di nuovi servizi in produzione, amministrarne
le successive modifiche e le dipendenze funzionali che si
vengono a creare. Le funzionalità di Business Management
rivolgono lo sguardo alla gestione dei processi di business,
fornendo sistemi di monitoring delle funzioni di business.
L'infrastruttura di sicurezza dei WebServices fornisce l'integrazione
dei vari sistemi di autenticazione, controllo accessi, encryption,
decryption e non ripudio attualmente in uso.
La più importante delle categorie prende il nome di
SOA Enablement: attività che si concentra sul controllo
della disponibilità ed affidabilità dei servizi
di business e dei processi che li connettono, scalabilità
dei sistemi e creazione di un sistema di comunicazione tra
le varie entità che compongono il servizio.
Approcci
architetturali a SOM (Service Oriented Management)
I principi fondamentali per la gestione di un sistema IT sono
visibilità e controllo. In genere, un prodotto di gestione
IT deve fornire visibilità e controllo sullo stato
di funzionamento delle tecnologie e dei servizi. Vi sono due
approcci architetturali che le soluzioni SOM posso offrire:
un'approccio proxy ed un' approccio distribuito.
Un proxy XML è una soluzione hardware o software che
accetta in ingresso traffico XML e lo passa avanti con o senza
modifiche a seconda delle necessità. Può operare
in modalità trasparente o come applicazione ausiliaria
sulla rete. Questo componente può essere utilizzato
come singolo gateway per tutti i Services interni che l'azienda
intende rendere disponibili oppure effettuare attività
di proxy verso servizi esterni alla rete locale. Il proxy
intercetta i messaggi SOAP per implementare alcune delle funzionalità
chiave del management incluso autenticazione, firma digitale,
cifratura, affidabilità, compressione, streaming e
gestione dello stato.
La soluzione proxy solitamente sottende un' approccio centralizzato
al problema: il core della soluzione è presente su
un unico server (o un cluster di server), ed eventualmente
alcune componenti distribuite sulla rete, ma mantenendo comunque
la maggior parte delle funzionalità centralizzate in
un unico punto. Il punto di forza di questa soluzione si individua
nelle possibilità e semplicità di controllo,
a scapito 'però' di maggior latenza aggiunta ai messaggi
XML. Latenza che può non essere tollerate in ambienti
che richiedono performance particolari.
Come risultato alle problematiche insorte, alcune soluzioni
SOM mantengono un approccio decentralizzato e distribuito
al management. Al posto di avere un' unico punto centrale
di controllo, viene proposta una soluzione di gestione punto-punto
distribuita sulla rete. Un' approccio distribuito è
infinitamente scalabile, e non introduce latenza nei messaggi
XML , ma al costo di un minor livello di controllo rispetto
alla soluzione centralizzata.
Conclusione
Le possibilità di integrazione e interoperabilità
fornite dal Web e dai WebServices permettono l'evoluzione
dell'economia dei servizi verso un modello di business globale
e confederato (ogni realtà è governata da proprie
leggi, ma collabora al risultato). Nonostante questo, la mancanza
di architetture di sicurezza che permettano, tramite l'utilizzo
di standard ed automatismi, un rapporto di fiducia tra entità
di business è un freno all'evoluzione cui stiamo assistendo.
Lo scopo fondamentale di una architettura di sicurezza orientata
ai servizi non è quello di sostituire le attuali tecnologie
ma piuttosto creare un layer di astrazione sopra l'infrastruttura
esistente fornendo a livello globale servizi propri di una
architettura tradizionale (autenticazione, autorizzazione,
non ripudio, etc..).
|