MokaByte 88 - 7mbre 2004 
Sicurezza in architetture SOA

di
P. Fornasari
e
M. Minzoni
Le architetture "SOA" nascono come risposta al problema di gestire architetture complesse ed eterogenee, fornendo agli utenti servizi di alto livello e di facile comprensione che possono essere integrati nei processi aziendali. Sorgono, in questo contesto, nuove problematiche di sicurezza e management legate all'integrazione dei servizi.

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:

  1. Eavesdropping: questo attacco si concretizza nella compromissione della riservatezza del messaggio senza però modificarne la forma.
  2. Tampering: una persona non autorizzata, modifica o sostituisce un messaggio in transito.
  3. 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:

  1. Auteniticazione: il destinatario deve essere sempre in grado di verificare l'identità del mittente.
  2. 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.
  3. Confidenzialità: il contenuto di un messaggio deve essere disponibile solamente per gli utenti autorizzati.
  4. Integrità: il messaggio durante il transito non deve subire modifiche.
  5. 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..).


MokaByte® è un marchio registrato da MokaByte s.r.l. 
Java®, Jini® e tutti i nomi derivati sono marchi registrati da Sun Microsystems.
Tutti i diritti riservati. E' vietata la riproduzione anche parziale.
Per comunicazioni inviare una mail a info@mokabyte.it