agility made possible

Transcript

1 WHITE PAPER Soluzione per la gestione della protezione Web di CA Technologies Febbraio 2012 protezione delle architetture IT basate su servizi con CA SiteMinder Web Services Security agility made possible

2 sommario EXECUTIVE SUMMARY 3 SEZIONE 1: La sfida 4 La sfida della gestione della protezione per i servizi SEZIONE 2: L'opportunità 5 La transizione verso la service-oriented architecture Informazioni sulla protezione SOA Livelli di protezione SOA Cosa manca alla protezione SOA/WS? SEZIONE 3: I vantaggi 11 CA SiteMinder Web Services Security si occupa delle sfide in materia di gestione della protezione Vantaggi principali Architettura del prodotto CA SiteMinder Web Services Security Caratteristiche principali di CA SiteMinder Web Services Security SEZIONE 4: 15 Valore aggiunto a ogni livello dell'ambiente SOA Applicabilità intersettoriale SEZIONE 5: 18 Conclusioni 2

3 executive summary La sfida Service-oriented architecture e Web service (SOA/WS) stanno emergendo come la nuova ondata di architetture applicative per le aziende basate su IT. Le organizzazioni si stanno indirizzando verso SOA/WS per migliorare velocità, flessibilità e costi di creazione e deployment delle applicazioni per usi interni ed esterni. Tuttavia, come per tutte le nuove architetture IT, in particolare quelle altamente distribuite, la gestione della protezione può costituire una sfida significativa. Senza un'architettura adeguata, la protezione dell'applicazione viene spesso creata in silos, con un conseguente aumento del rischio di perdita di informazioni, dei costi dell'amministrazione della protezione e della complessità della conformità alle normative relative all'it. L'opportunità Con la gestione della protezione centralizzata consentita da CA SiteMinder Web Services Security (WSS), le organizzazioni possono gestire la protezione dei propri deployment SOA/WS aziendali indipendentemente dal numero di Web service o tecnologie infrastrutturali diverse distribuiti. Grazie alla protezione centralizzata e basata su policy come parte integrante dell'infrastruttura di servizi SOA/WS, è possibile esternalizzare la protezione dai servizi stessi. In questo modo si agevola il carico amministrativo e si riducono i costi per la fornitura di una protezione aziendale coerente e affidabile per SOA/WS. I vantaggi CA SiteMinder WSS fornisce protezione per i Web service basata su identità: autenticazione, autorizzazione e auditing (AAA). Questa soluzione è in grado pertanto di ridurre il tempo e i costi necessari per lo sviluppo e la manutenzione dei servizi, agevolando anche la diminuzione del rischio IT tramite controllo e monitoraggio maggiori. Inoltre, l'utilizzo congiunto di CA SiteMinder WSS e CA SiteMinder costituisce un'ampia soluzione combinata di protezione Web. Questa soluzione protegge sia le applicazioni e i portali Web tradizionali sia i Web service basati su XML, sfruttando la stessa architettura basata su server di agenti e policy. 3

4 Sezione 1: La sfida La sfida della gestione della protezione per i servizi Le soluzioni Service-oriented architecture (SOA) sono emerse come l'approccio più innovativo e spesso migliore alla creazione e al deployment di applicazioni IT. Includendo generalmente gli standard Internet tramite l'utilizzo di Web service (WS) basati su XML, l'approccio SOA mantiene la promessa di maggiore flessibilità e agilità dell'it. Questo perché consente alle organizzazioni di pubblicare i propri servizi per la moltitudine di potenziali consumatori di servizi interni ed esterni. L'approccio basato sui servizi modifica radicalmente la modalità di progettazione e creazione delle applicazioni. È in grado di supportare un'infinita varietà di processi di business, ma allo stesso tempo mette in discussione il modo in cui le organizzazioni IT governano, gestiscono e proteggono applicazioni e dati. Esattamente come con la prima apparizione delle applicazioni e dei portali Web protetti negli anni '90, l'arrivo delle applicazioni basate su SOA/WS crea svariate sfide di gestione della protezione e dell'it da risolvere prima del deployment su vasta scala. Posto che il deployment di SOA/WS può avvenire per uso interno, esterno o entrambi insieme, l'identità di chi ha accesso e il tipo di contenuti accessibili hanno un'importanza intrinseca per SOA/WS. In breve, SOA/WS necessita della funzionalità equivalente diventata standard con siti Web e portali, firewall e sistemi di Web access management (WAM), sfruttando l'approccio e la filosofia generali già provate per la protezione dei siti Web, ma adattandoli in particolare all'orientamento ai servizi e ai Web service basati su XML. La gestione della protezione per SOA/WS non è una novità assoluta, dato che i requisiti di protezione di SOA/WS sono ampiamente coerenti con quelli delle applicazioni basate su Web. Ad esempio, con i siti Web e SOA/WS, è importante la riservatezza dei dati privati e la garanzia che i messaggi non siano stati alterati (integrità). È ugualmente importante distinguere l'identità del richiedente (autenticazione), decidere il livello dei diritti garantiti all'applicazione o all'utente richiedente (autorizzazione) e registrare ciò che accade ed è accaduto nell'ambiente da un punto di vista della protezione (auditing/reporting). Un tipico deployment iniziale odierno di SOA/WS unisce un deployment del portale tradizionale sul front end per l'utente umano e una chiamata Web service sul back end per conto dell'utente di Web service ospitati internamente o da partner esterni. In questo scenario, molte organizzazioni vogliono preservare senza problemi il contesto di identità e protezione in tutte le fasi dell'applicazione. Infatti, le organizzazioni desiderano avviare la sessione dell'utente in modo tradizionale mediante l'esecuzione di un login utente su una o più transazioni di Web service sul back end. In quest'ottica, poiché molti hop di questi Web service implicano spesso domini di protezione interni o esterni separati, occorre stabilire e incrementare (tramite federazione) la fiducia tra questi domini di protezione in modo basato su standard e scalabile. CA SiteMinder Web Services Security è stato sviluppato da CA Technologies per risolvere questi problemi offrendo un prodotto software per la protezione SOA/WS basato su identità che protegge l'accesso ai servizi controllando le informazioni sulla protezione contenute nei documenti XML inviati dai consumatori dei servizi. Sfruttando una serie fondamentale di standard SOA/WS, CA SiteMinder WSS utilizza policy di protezione centralizzate collegate alle identità dell'utente per fornire autenticazione, autorizzazione, federazione, gestione delle sessioni e servizi di auditing della protezione. CA SiteMinder WSS si inserisce in un deployment SOA/WS eterogeneo offrendo policy enforcement point (PEP) basati su agenti controllati e gestiti da policy decision point (PDP) o server delle policy centralizzati. 4

5 In questo documento si analizzano le motivazioni per le quali SOA/WS stanno ottenendo adesioni nelle aziende, i problemi di protezione che possono derivare dal loro utilizzo e infine il modo in cui CA SiteMinder WSS risolve i problemi relativi alla protezione e alla gestione delle distribuzioni SOA/WS su scala enterprise. Sezione 2: L'opportunità La transizione verso la service-oriented architecture Si stima che la maggior parte delle grandi organizzazioni in tutto il mondo abbia iniziato a utilizzare servizi Service-oriented Architecture/Web (SOA/WS) o stia progettando di farlo nel prossimo futuro. Il passaggio ai deployment basati su cloud aggiunge solo un'enfasi maggiore sull'utilizzo di SOA/WS per l'integrazione dell'applicazione. Il fascino di SOA/WS è legato ampiamente alla sua capacità di aumentare la velocità di sviluppo e deployment dell'applicazione, la riutilizzabilità e la flessibilità, riducendo i costi per l'it. Ampliando i guadagni già realizzati sfruttando portali e applicazioni Web tradizionali, SOA/WS prende il modello di applicazioni interdominio focalizzate sui servizi a utenti umani e generalizza questo concetto su applicazioni basate su computer che potrebbero o meno agire sotto il controllo diretto di una persona. SOA/WS sfrutta direttamente i vantaggi di Internet e della tecnologia Internet per fornire flessibilità di integrazione dell'applicazione indipendentemente dal fatto che il consumatore del servizio si trovi su Internet o sulla Intranet/Extranet dell'azienda. L'approccio SOA/WS agevola l'integrazione delle applicazioni interne, sfruttando al contempo gli standard per aprire gli stessi servizi al mondo in generale, che si tratti di clienti, partner o altre organizzazioni partner. L'utilizzo dell'it per consentire e velocizzare tali collaborazioni di terzi non è un fenomeno nuovo. Le strutture di dati a formato fisso, ad esempio electronic data interchange (EDI), sono state utilizzate tradizionalmente per l'invio di dati tra i partner commerciali. Eppure, in questa nuova generazione di processi di business globali davvero integrati, l'edi è un sistema di comunicazioni altamente limitato, non aperto agli infiniti tipi di comunicazioni e transazioni necessari per le organizzazioni. Tuttavia, l'edi fornisce un esempio utile di ciò che è possibile e può essere considerato la prima generazione di scambio di informazioni digitali interaziendale su scala relativamente ampia. È necessaria una serie di interfacce basate su standard aperte utilizzabili da qualsiasi organizzazione per integrare i sistemi di business in modo sicuro e affidabile. Come per tutte le nuove tecnologie, anche SOA/WS pone dei problemi che occorre risolvere prima di poter utilizzare questa tecnologia su ampia scala. Date la scala e la flessibilità importanti insite in SOA/WS, qualsiasi soluzione distribuita deve essere affidabile, disponibile, scalabile, gestibile e sicura, garantendo sempre il monitoraggio efficace dell'ambiente. Questi problemi fondamentali di gestione IT richiedono un'evoluzione del pensiero. Mentre questo documento si concentra sulle nuove sfide della gestione della protezione portate alla ribalta da SOA/WS, è importante ricordare che la protezione è solo una parte delle sfide della gestione IT sollevate da SOA/WS. Storicamente, i cattivi erano aggressori dall'esterno dell'organizzazione, che cercavano di lanciare attacchi come negazione del servizio, spoofing dei messaggi e DNS poisoning per impedire il funzionamento dell'applicazione. Questo non è più un presupposto corretto, perché gli insider sono sempre più sia 5

6 i consumatori di un'applicazione SOA/WS sia un vettore legittimo di minacce, rubando dati sensibili e arrestando i processi di business, indipendentemente dal vero intento dell'insider. Nel migliore dei casi, il concetto di insider e outsider diventa estremamente vago dal punto di vista SOA/WS. A causa di questa ambiguità, l'approccio tradizionale del deployment della protezione su più livelli, in cui prodotti e processi hanno protetto la rete, il data center, le applicazioni e gli end point, non è più sufficiente. In un ambiente in cui i servizi vengono richiesti da un richiedente che può essere interno o esterno all'organizzazione (o da un'applicazione interna che agisce per conto di un outsider), i servizi di protezione come autenticazione e autorizzazione sono più importanti che mai. SOA/WS abilita una nuova generazione di applicazioni aperte, integrate e accessibili, ma richiede anche una serie di policy di utilizzo rafforzate in modo coerente che garantiscano la scalabilità per fornire servizi di gestione su livelli e granularità che vanno oltre quanto attualmente presente nel mondo IT. Un altro rischio della gestione della protezione per SOA/WS è la pratica di creare la logica di protezione (che conferma l'identità del richiedente e i diritti di accesso, ad esempio) direttamente ed esclusivamente in ciascun servizio, piuttosto che fornirla come servizio di protezione condiviso. Poiché la scalabilità dei deployment SOA/WS continua ad aumentare, questa tendenza verso la creazione di silos di protezione sta diventando sempre meno pratica per le organizzazioni che dispongono di un numero di servizi nell'ordine delle centinaia e potenzialmente delle migliaia. I silos di protezione ridondanti non solo sono costosi da creare e mantenere, ma aumentano anche i rischi e rendono difficile il raggiungimento della conformità normativa. In definitiva, influiscono su contabilità e controllo. Con il proliferare delle applicazioni basate su SOA/WS, le organizzazioni devono pensare a come fornire almeno lo stesso livello (e si spera anche migliore) di protezione disponibile per la generazione corrente di applicazioni client/server e basate su Web. Un'ulteriore complicazione è costituita dai requisiti normativi sempre più severi, che influiscono direttamente sull'it e richiedono ai dirigenti aziendali di garantire l'inviolabilità delle transazioni e dei reporting finanziari correlati e di fornire protezione delle informazioni personali private. Informazioni sulla protezione SOA Per capire i requisiti di protezione intrinseci in un ambiente basato su SOA/WS, è importante analizzare come le aziende hanno affrontato (e affrontano tuttora) il passaggio alle applicazioni basate su Web negli ultimi dieci anni circa. La prima generazione di applicazioni Web integrava la protezione direttamente nelle applicazioni stesse. Questi cosiddetti silos di protezione prevedevano l'implementazione di una directory degli utenti, di access control list (ACL) e di serie di policy di accesso per ogni applicazione. Fondamentalmente, ogni applicazione in un'architettura completamente centralizzata gestiva letteralmente autenticazione, autorizzazione e auditing (AAA) dei propri utenti su qualche livello. Quando le organizzazioni sono passate a una sola manciata di applicazioni Web, questo approccio basato su silos alla protezione delle applicazioni Web non era scalabile e si è dimostrato non sicuro e costoso da gestire. Così, negli anni '90, è stata introdotta una classe di applicazioni di protezione completamente nuova per consentire alle applicazioni di esternalizzare autenticazione, autorizzazione, auditing e le funzioni amministrative dell'utente in un'infrastruttura di protezione a gestione centralizzata e altamente scalabile, che può essere utilizzata da tutte le applicazioni Web nell'azienda. Allo stesso tempo, ha iniziato a proliferare una tecnologia standard per le directory degli utenti denominata LDAP per fornire ai repository centralizzati difficilmente scalabili questa infrastruttura di protezione esternalizzata. 6

7 Ci sono molte somiglianze tra applicazioni Web e applicazioni basate su SOA/WS, incluso il fatto che entrambe possono essere distribuite su intranet (per l'utilizzo aziendale), extranet (per i partner di business) o anche su Internet pubblico (per i consumatori). La differenza principale è che l'utente in un mondo SOA può essere un'altra macchina che utilizza il linguaggio XML, WSDL e SOAP, invece che una persona che visualizza una pagina Web su un browser. Tuttavia molte sfide di protezione sono fondamentalmente le stesse e possono essere risolte utilizzando un approccio simile alla gestione della protezione. Prima di passare alle soluzioni possibili, analizziamo più nel dettaglio i requisiti di protezione di SOA/WS. Nonostante i requisiti di protezione siano molto simili a quelli delle applicazioni Web tradizionali, esistono alcune differenze che saranno sottolineate. I requisiti di protezione per le applicazioni basate su SOA/WS includono: Prevenzione di minacce/malware. Il traffico XML non è diverso dal traffico Web o di e può pertanto portare a destinazione payload dannosi. Conformemente alle best practice per altri tipi di traffico, occorre vagliare tutto il traffico XML in ingresso su edge/dmz per accertarsi che non ci siano malware o altri attacchi mirati ai servizi di business, inclusi virus, negazioni di servizio, spoofing di messaggi, e così via. Autenticazione. Chi è l'altra parte che sta tentando di accedere a un servizio? Non importa se l'altra parte è un processo di un computer o un altro servizio Web: prima di eseguire qualsiasi operazione, è necessario confermare l'identità del richiedente. Nessuno consente l'accesso a chiunque in un'applicazione Web ad alto profilo senza un'autenticazione positiva. Le applicazioni SOA/WS non devono essere diverse. Autorizzazione. In seguito all'autenticazione, cosa possono fare i consumatori di servizi con i Web service dell'organizzazione? A quali servizi possono accedere? A quali dati è possibile accedere e quali transazioni e funzioni di business possono essere utilizzate? Esattamente come gli utenti ottengono i diritti per utilizzare determinate funzioni in un portale Web, il service provider Web deve garantire diritti simili per conto di un consumatore di servizi, sia dal'interno sia dall'esterno. Auditing e reporting. Dati i seri requisiti normativi per registrare ogni transazione di materiali e monitorare attentamente le operazioni del business in caso di violazioni dei dati o altri problemi, l'ambiente SOA/WS deve consentire il tracking di ciascuna transazione e la ricostituzione delle attività di business in modo legalmente valido. In modo analogo, è fondamentale essere in grado di fornire report di attività a livello aziendale. Amministrazione delle identità. Le organizzazioni devono gestire identità, credenziali e diritti per le applicazioni basate su SOA/WS, esattamente come fanno attualmente nelle architetture IT tradizionali. Poiché i Web service spesso agiscono per conto di utenti o altre applicazioni o processi tecnologici, il single sign-on e il provisioning di credenziali e diritti di accesso sono fondamentali per consentire la scalabilità sicura dell'ambiente. Gestibilità enterprise/gestione di policy centralizzata. Con il semplice numero dei potenziali servizi disponibili attraverso un approccio basato su SOA/WS, come può un'organizzazione avere una panoramica a livello aziendale di cosa accade con le potenziali centinaia o migliaia di applicazioni basate su SOA distinte in esecuzione? Inoltre, è fondamentale essere in grado di creare e rafforzare la policy di protezione centralizzata che può cambiare rapidamente in base ai requisiti del business, senza influire sul servizio di business sottostante né modificarlo. 7

8 Gestione delle sessioni. In modo simile a Web application single sign-on (Web SSO), i Web service possono essere parte dei processi di business in cui occorre aggiornare le sessioni su più Web service per un'intera transazione. Si può pensare a questo come SSO per i Web service. Supporto di un'infrastruttura eterogenea. Un vantaggio chiave delle applicazioni Web e ora di quelle basate su Web service è che non sono necessari hardware, reti o applicazioni specifici a condizione che siano conformi a una serie standard di tecnologie di interscambio. È possibile distribuire i Web service in molti modi diversi e senza dubbio in molte grandi organizzazioni. Pertanto la capacità di proteggerli costantemente in questo mondo eterogeneo è fondamentale. Prestazioni, affidabilità, disponibilità e scalabilità. È superfluo parlare della disponibilità di tutti questi aspetti di un ambiente di computing di classe aziendale. Molte applicazioni Web devono garantire la scalabilità a milioni o decine di milioni di utenti con disponibilità al 99,999%. Allo stesso modo, le applicazioni basate su SOA, in cui la riutilizzabilità è un vantaggio chiave, possono raggiungere un livello di utilizzo maggiore di un ordine di grandezza con gli stessi requisiti di disponibilità al 99,999%. Inoltre, la natura interdipendente delle applicazioni basate su SOA/WS implica che un problema in un componente del servizio può influire negativamente su molti altri servizi. Supporto standard. SOA/WS si basa su standard (quali XML, WSDL, SOAP, ecc.), inclusi una serie di standard di protezione (WS-Security e altri), che devono essere supportati al fine di fornire l'interoperabilità richiesta che consente deployment e gestione semplici per i servizi interni ed esterni. I suddetti requisiti di protezione devono essere forniti in un ambiente flessibile di livello aziendale che consenta a un'organizzazione di raggiungere quanto promesso da SOA/WS. Presupponendo che molte grandi organizzazioni avranno in definitiva migliaia di Web service basati su SOA compresi diversi componenti autonomi, l'idea di inserire funzionalità di protezione in ciascun componente non è pratica. Così, la protezione SOA (esattamente come Web access management prima) deve essere fornita come infrastruttura o servizio centralizzati per mantenere i massimi livelli di flessibilità ed efficienza. Livelli di protezione SOA Il deployment della protezione per SOA/WS può avvenire in svariati posizioni a seconda dell'architettura dell'applicazione. La protezione SOA/WS viene spesso implementata sull'edge (o perimetro) della rete, in una piattaforma SOA o in un container di applicazioni SOA, come illustrato nello schema seguente. A oggi c'è stata un'integrazione minima tra queste aree di protezione disparate, con il risultato di un'enorme quantità di duplicazione nella funzionalità. Così le aziende hanno spesso dovuto gestire policy di protezione simili in parti diverse dell'architettura SOA/WS. La gestione di queste molteplici policy di protezione può essere problematica per svariate ragioni. Richiede più risorse, può causare lacune nella protezione e può anche duplicare difese simili. Le best practice impongono una difesa a livelli per la protezione SOA, ma tali livelli devono essere coerenti, coordinati e gestiti all'interno di una policy centralizzata. 8

9 Figura A. Livelli di protezione SOA e importanza della gestione di policy, auditing e reporting di protezione centralizzati. Livelli di protezione SOA Utenti del servizio PROTEZIONE LIMITE DMZ Provider di servizi Minacce XML PROTEZIONE PIATTAFORMA SOA PROTEZIONE CONTAINER Minacce XML REPORTING, AUDITING, GESTIONE POLICY CENTRALIZZATI Provider di servizi Utenti del servizio In definitiva, una soluzione di protezione SOA/WS deve supportare gli sviluppatori dell'applicazione senza caricarli di dettagli sulla modalità di protezione di ciascun componente del servizio. Ma allo stesso tempo, è fondamentale anche una modalità di rafforzamento della policy organizzativa centralizzata e strutturata su tutti i Web service distribuiti che consenta di garantire un reporting end-to-end adeguato. Questo equilibrio è ciò che sta portando molte organizzazioni a prendere in considerazione un sistema di protezione SOA/WS in grado di fornire la flessibilità necessaria, insieme a una gestione centralizzata di livello mondiale. Analizziamo più in dettaglio ogni livello. Protezione edge (perimetro). Offerti attraverso fattori di forma hardware o software che risiedono all'interno dell'area di rete demilitarizzata di un'organizzazione, questi sistemi basati su edge (anche noti comunemente come XML security gateway o XML firewall) costituiscono la prima linea di difesa per le applicazioni SOA/WS. Questi sistemi vengono generalmente distribuiti come proxy inversi per il traffico XML, in modo da controllare ed elaborare tutti i messaggi in ingresso per garantire la conformità alle policy di protezione. 9

10 Gli XML security gateway verificano la presenza di malware basati su XML e altre minacce nel traffico in ingresso, inclusi virus e attacchi di negazione del servizio. Sul perimetro si può anche verificare un trasferimento di protocollo per consentire la compatibilità con le applicazioni distribuite e altri standard. Protezione della piattaforma SOA. Dato il numero elevato di servizi distribuiti in una grande azienda, molti hanno implementato una piattaforma SOA/WS che funziona da intermediario per collegare, mediare e gestire i servizi disponibili. Gli sviluppatori SOA/WS possono scegliere di utilizzare alcune delle funzionalità di protezione integrate nelle piattaforme SOA, ma a rischio di duplicare le difese, lasciare potenzialmente lacune nella protezione e creare silos di protezione da aggiungere alle future sfide di gestione e conformità. Le piattaforme SOA tendono a utilizzare gli standard di protezione SOA/WS (incluso WS-*) per essere in grado di emettere diritti e supportare la federazione tra diversi sistemi interni o esterni all'organizzazione. Protezione del container SOA. Le applicazioni SOA/WS sono distribuite all'interno di container, creati generalmente utilizzando le specifiche Java J2EE Microsoft s.net. Poiché SOA/WS si basa su standard, l'ambiente di sviluppo non è attinente al deployment dei servizi stessi, ma fa la differenza quando si tenta di proteggere l'ambiente. Come con le piattaforme SOA, J2EE e.net offrono determinate funzionalità di protezione che possono essere create direttamente nell'applicazione a discrezione dello sviluppatore, ma hanno gli stessi rischi della duplicazione di funzioni, della creazione di silos di protezione, che si aggiungono alle sfide di gestione e conformità, e delle potenziali lacune nella protezione all'interno dell'applicazione. Cosa manca alla protezione SOA/WS? Come detto prima, la duplicazione delle funzioni di protezione tra diversi domini SOA (edge, piattaforma e container) è chiaramente inefficiente e richiede gestione e risorse dello sviluppatore decisamente maggiori che portano a un aumento dei costi IT. Oltre alla sovrapposizione, è difficile implementare una policy di protezione SOA coerente su tutti i livelli e su tutte le svariate applicazioni in esecuzione nell'ambiente. Si può fare un confronto con Web access management, in cui all'inizio erano implementati molti livelli di protezione diversificati (edge, container, all'interno dell'applicazione), consolidati poi in un'infrastruttura di protezione comune per aumentare il livello di protezione e ridurre il tempo e le risorse necessari per proteggere le applicazioni. La buona notizia è che questo problema è stato risolto nel dominio delle applicazioni basate su Web e molte di quelle tecniche sono applicabili direttamente al mondo di SOA/WS. Le applicazioni basate su SOA seguiranno probabilmente lo stesso percorso evolutivo delle applicazioni basate su Web in precedenza. Ciò prepara la strada alla comparsa di una nuova generazione di soluzioni di protezione SOA/WS per rafforzare la protezione centralizzata su tutti i livelli dell'applicazione, unendo il meglio di entrambe le realtà. Le esigenti applicazioni SOA/WS di oggi richiedono una protezione effettiva a ogni livello, utilizzando un'interfaccia di gestione comune, un rafforzamento delle policy coerente e un reporting integrato per l'auditing e la conformità in tutto l'ecosistema SO. 10

11 Sezione 3: I vantaggi CA SiteMinder Web Services Security si occupa delle sfide in materia di gestione della protezione CA SiteMinder WSS dispone di una buona posizione per offrire protezione end-to-end per SOA/WS fornendo gestione delle policy centralizzata, rafforzamento delle policy per diversi livelli di protezione e auditing centrale a un deployment SOA/WS aziendale. Separando la protezione dai servizi stessi, CA SiteMinder WSS consente di ridurre significativamente il carico amministrativo e gli altri costi associati alla fornitura di protezione per SOA/Web service. CA SiteMinder WSS controlla le informazioni sulla protezione contenute nei documenti XML inviati dai consumatori dei servizi e le utilizza per determinare l'accesso. Fornisce funzionalità di livello aziendale per SOA/Web service esposti internamente ed esternamente, bloccando le minacce XML e controllando contemporaneamente l'accesso per i consumatori di servizi legittimi. Come Web access management prima, CA SiteMinder WSS separa ampiamente la protezione dalla sfera dello sviluppatore dell'applicazione, consentendo allo sviluppatore di focalizzare l'attenzione sulla logica dell'applicazione e al professionista della protezione di concentrarsi sulla protezione e sulla riduzione dei rischi. CA SiteMinder WSS apporta una vision della protezione dei servizi condivisi ai precedenti silos di protezione SOA disparati. Basato su un server di policy centralizzato, ogni messaggio viene controllato per rafforzare le policy di autenticazione e autorizzazione. Inoltre, i messaggi in ingresso e in uscita possono essere trasformati e protetti in base alla policy dell'organizzazione. Con agenti in esecuzione sui maggiori server di applicazioni, all'interno dei principali container SOA, CA SiteMinder WSS abilita un modello end-to-end per proteggere SOA/Web service dall'edge al container. Vantaggi principali Protezione coerente. In opposizione alla protezione diversificata implementata in molte posizioni senza policy di protezione comuni, CA SiteMinder WSS offre un punto singolo di accesso a controllo e auditing, rafforzando coerentemente le policy di protezione dell'organizzazione. Costi di sviluppo ridotti. Gli sviluppatori non devono più inserire la protezione nei rispettivi componenti delle applicazioni SOA/WS. L'esternalizzazione della protezione offre un'efficienza significativa dello sviluppatore e risultati per un time-to-market più rapido dei servizi di business. Creazione semplificata delle policy di protezione. La nuova interfaccia utente focalizzata sui Web service semplifica la creazione delle policy di protezione utilizzando un file WSDL. Questa interfaccia utente amministrativa può connettersi a più server delle policy, consentendo di gestire tutti i componenti esistenti da un unico server di amministrazione condiviso. Auditing centralizzato delle policy di protezione SOA. Le policy di sicurezza implementate sui server delle policy centralizzati vengono controllate in ogni momento della transazione per garantire l'implementazione dei controlli opportuni in qualsiasi fase del processo di transazione. Ciò consente inoltre un reporting centrale conforme ai requisiti di auditing e conformità. 11

12 Gestione della sessione e single sign-on. La gestione centralizzata della protezione consente inoltre il single sign-on (SSO) in cui, in seguito all'autenticazione, le richieste di Web service non devono essere più autenticate nuovamente durante il passaggio delle transazioni alle diverse fasi del servizio (se previste dall'organizzazione o da terzi) che costituiscono un processo di business tipico. È possibile configurare le sessioni per essere valide per determinati periodi, aggiungendo flessibilità. Affidabilità e disponibilità elevate per Web service. I Web service sono sempre disponibili così come CA SiteMinder WSS, fornendo affidabilità e uptime impareggiabili anche per i processi di business industriale più impegnativi, 24 ore al giorno, 7 giorni a settimana. Sfrutta gli standard in un ambiente aperto e a piattaforma neutra. CA SiteMinder WSS supporta gli standard Web service applicabili, inclusi XML, SOAP, REST, WSDL, SSL, WS-Security, XML encryption e XML Signature. Può utilizzare l'ambiente Web access management esistente. Basato sugli stessi server delle policy e architettura basata su agenti dell'offerta di Web access management leader nel settore di CA Technologies, CA SiteMinder, CA SiteMinder WSS è in grado si sfruttare lo stesso ambiente di deployment di CA SiteMinder e insieme forniscono una protezione Web completa per siti Web, applicazioni e Web service. Esternalizzando le funzioni di sicurezza SOA in un'infrastruttura comune si riducono notevolmente i costi di sviluppo e si fornisce un punto singolo di controllo accessi e amministrazione per le centinaia (o addirittura migliaia) di servizi distinti implementati nelle più grandi aziende. CA SiteMinder WSS fornisce funzionalità di protezione complete dall'edge ai container SOA. Architettura del prodotto CA SiteMinder Web Services Security Server delle policy: policy decision point (PDP). Il server delle policy di CA SiteMinder WSS fornisce il policy decision point (PDP) per CA SiteMinder WSS ed è la parte centrale della piattaforma di gestione centralizzata, basata su policy. Il server delle policy si basava sul server delle policy in CA SiteMinder, aggiungendo ulteriori funzionalità progettate per supportare standard di elaborazione e protezione specifici di XML. Il server delle policy può utilizzare gli agenti SOA di CA SiteMinder WSS e un gateway di protezione XML opzionale come policy-enforcement point (PEP) per i Web service ovunque siano ospitati. 12

13 Figura B. CA SiteMinder Web Services Security e architettura basata su PEP/PDP/PAP corrispondente. Architettura di CA SiteMinder Web Services Security REQUESTER SERVIZIO WEB SERVIZI WEB AGENTE SOA J2EE CLIENTE AGENTE AGENTE SOA ESB AGENTE SOA MAINFRAME PARTNER AGENTE SOA.NET PDA SERVER POLICY PROTEZIONE AMMINISTRATORE GATEWAY DI SICUREZZA XML APPLICAZIONE STORE POLICY STORE CHIAVI STORE UTENTI REPORTING/ AUDITING FIREWALL FIREWALL Architettura di deployment di riferimento di CA SiteMinder WSS. Il deployment di CA SiteMinder WSS può avvenire in un'architettura altamente distribuita che fornisce una combinazione di policy enforcement point distribuiti (tramite gateway di protezione XML opzionali e agenti SOA) e policy decision point basati su server delle policy centralizzati. 1. Le richieste di Web service provenienti dall'esterno nella rete possono essere protetta da un gateway di protezione XML opzionale in esecuzione nel DMZ. In alternativa, un utente può anche accedere al Portal Server, che a sua volta esegue una richiesta di Web service a un Web service ospitato su DMZ. 2. I Web service distribuiti all'interno di un'azienda possono anche eseguire richieste tra loro come parte di un processo di business particolare, protetto da agenti SOA come parte dell'ultimo miglio della protezione SOA/WS. 3. Il server delle policy centrale comune protegge il traffico di Web service e del sito Web quando si utilizzano insieme CA SiteMinder e CA SiteMinder WSS. 13

14 Basati su un'architettura estensibile e scalabile, è possibile aggiungere e migliorare i servizi di protezione seguendo lo sviluppo delle esigenze di protezione e gestione per i Web service. L'integrazione con le directory LDAP standard di settore, i sistemi di database relazionali e gli archivi di identità mainframe per la gestione centralizzata dell'identità degli utenti e delle informazioni sui diritti offre la massima flessibilità di implementazione di CA SiteMinder WSS per soddisfare i requisiti di business ed estendere l'infrastruttura IT esistente, non viceversa. Agenti SOA: policy enforcement point (PEP). CA SiteMinder WSS offre diversi policy enforcement point per garantire la protezione end-to-end a tutta l'infrastruttura aziendale SOA/WS. Gli agenti sono disponibili per i principali container.net e J2EE. Vengono sviluppati regolarmente nuovi agenti SOA come quelli per le piattaforme ESB e SOA aggiuntive. SOA security manager SDK: per PEP integrati personalizzati. Questo Java API consente a partner e clienti di scrivere agenti SOA personalizzati per il proprio ambiente. Questo API aperto consente a partner e clienti di CA di estendere le integrazioni esistenti con SOA Security Manager, in cui le piattaforme SOA, i firewall XML o altre applicazioni utilizzano CA SiteMinder WSS per fornire un ambiente di autenticazione e autorizzazione gestito a livello centrale. Caratteristiche principali di CA SiteMinder Web Services Security CA SiteMinder WSS offre molte funzionalità importanti al mercato, tra cui: Gestione centralizzata delle policy di protezione SOA. Implementando un modello di servizio condiviso, CA SiteMinder WSS esternalizza la protezione dal Web service sottostante, offrendo la possibilità di rafforzare coerentemente la policy di protezione a tutti i livelli del Web service, inclusi edge/perimetro, sulla piattaforma SOA e all'interno del container SOA. Web service con riconoscimento dell'identità. CA SiteMinder WSS collega il flusso XML all'identità di un utente (sia umano sia un'altra applicazione), garantendo il mantenimento di autenticazione, autorizzazione e diritti opportuni durante tutta la transazione. Single sign-on sicuro e gestione della sessione sincronizzata. CA SiteMinder WSS gestisce lo stato della sessione ed elimina la riautenticazione di messaggi XML durante le transazioni a fasi multiple e federate tra servizi a più componenti e confini organizzativi. Mapping delle credenziali. CA SiteMinder WSS non solo autentica e autorizza le richieste di Web service, ma supporta anche la generazione di un nuovo token di protezione per lo stesso richiedente, tramite il mapping dell'identità in un token di protezione a un altro che funge generalmente da Security Token Service. Inoltre, i token SMSESSION di CA SiteMinder SMSESSION possono essere mappati su WS-Security SAML Assertions per fornire ulteriore apertura e interoperabilità. Creazione di policy di protezione tramite WSDL. Una nuova interfaccia utente basata su Web semplifica la creazione di policy di protezione dal file WSDL. Il file WSDL può essere caricato da un file o da un indirizzo URL. Una volta caricato, l'interfaccia utente del prodotto visualizza tutte le operazioni del Web service e consente all'amministratore di proteggere con grande facilità diverse operazioni del Web service con uno o più schemi di autenticazione. 14

15 Supporto per la federazione. Supportando lo standard WS-Security per le informazioni di protezione contenute nei documenti XML/SOAP, è possibile gestire le transazioni interaziendali tra i domini di protezione da un'autenticazione singola. Infatti, un caso di utilizzo tipico di CA SiteMinder WSS è la fornitura di un servizio di autenticazione basato su Web service da sfruttare come servizio di autenticazione condiviso dell'azienda. Autorizzazione dinamica basata sul contenuto XML nella richiesta. Come parte del processo di autorizzazione, è possibile creare una policy di protezione per confrontare dinamicamente il contenuto XML con gli attributi dell'utente memorizzati nell'archivio utente. Deployment flessibile per gli enforcement point. CA SiteMinder WSS fornisce agenti per i principali container J2EE e.net ed è completamente interoperativo con le soluzioni di altri vendor SOA, inclusi. NET, J2EE, e vendor leader quali IBM, Microsoft, Oracle e molti altri. Conformità agli standard. CA SiteMinder WSS supporta tutti gli standard Web service importanti, garantendo interoperabilità e compatibilità a standard futuri, inclusi XML, SOAP, REST, WS-Security (SAML, Username, X509), XML Signature, XML encryption, WSDL e SSL. Estende la piattaforma CA SiteMinder provata. CA SiteMinder WSS fornisce integrazione senza problemi con la piattaforma di protezione Web CA SiteMinder, sfruttando lo stesso archivi odi policy e offrendo un single sign-on ad applicazioni e Web service protetti da CA SiteMinder. Sezione 4: Valore aggiunto a ogni livello dell'ambiente SOA CA SiteMinder WSS aggiunge valore a ogni livello dell'ambiente SOA/WS. Come illustrato nei casi di utilizzo seguenti, si può ottenere il valore reale di un ambiente SOA/WS protetto solo sfruttando una policy di protezione, nonché logging e reporting centralizzati che forniscono servizi di protezione completi a livello aziendale. 15

16 Figura 3. Caso di utilizzo Single sign-on (SSO). SSO dal portale ai Web service interni ed esterni BROWSER DEL CLIENTE PORTALE BANCA SERVIZIO WEB DI ELABORAZIONE APPLICAZIONE CARTA DI CREDITO 5 4 TOKEN DI SICUREZZA + RICHIESTA XML/SOAP AGENTE SOA INTERNET UN: GEORGE PW:89676 AGENTE WEB CA SOA SECURITY MANAGER E SERVER POLICY COMUNI CA SITEMANAGER INTERNET RICHIESTA XML/SOAP + SAML SICUREZZA-WS SERVIZIO WEB CARTA DI CREDITO SERVIZIO DI PROTEZIONE CONFORME CON LA SICUREZZA-WS 1. L'utente accede al portale della banca con CA SiteMinder e richiede una carta di credito. 2. L'applicazione basata sul portale esegue una chiamata SOAP al servizio interno di carte di credito utilizzando il contesto di protezione dell'utente. 3. La sessione dell'utente viene convalidata e autorizzata da SOA Agent PEP/Policy Server PDP che protegge il servizio di carte di credito. 4. CA SiteMinder WSS genera quindi un token WS-Security/SAML e lo aggiunge a SOAP Header della richiesta per la fase successiva nel Web service, in questo esempio al Web service di controllo credito. 5. Il servizio di carte di credito invia la richiesta SOAP con il token SAML al servizio di controllo credito esterno fornito da un partner. 6. Il servizio di controllo credito autentica il richiedente utilizzando lo standard WS-Security SAML e fornisce la risposta al servizio carte di credito, che a sua volta restituisce l'approvazione o il rifiuto della carta di credito all'utente sull'applicazione basata sul portale. Vantaggi principali di questo caso di utilizzo L'utente deve semplicemente eseguire l'autenticazione sul portale della banca, il resto della transazione non è visibile. Tuttavia, il contesto dell'utente viene aggiornato in ogni fase. Il portale della banca a il Web service first-step (interno) sono protetti da un singolo servizi basato su policy abilitato da una combinazione di CA SiteMinder WSS e CA SiteMinder. In questo modo si risparmiano tempo e denaro necessari per lo sviluppo e l'amministrazione della protezione. Ogni applicazione/servizio è protetto fino all'ultimo miglio (tramite agenti) e non riceve protezione da servizi di protezione distanti eventualmente utilizzabili. Con CA SiteMinder WSS, non c'è modo di aggirare la protezione fornita. 16

17 La funzionalità di mapping delle credenziali consente la mappatura del contesto di protezione sugli standard basati su token di protezione, ad esempio WS-Security SAML in questo caso, per completare la transazione. I Web service o il portale stesso non devono gestire il mapping delle credenziali perché è compito del sistema di protezione fornito da CA SiteMinder WSS. L'utilizzo di standard di protezione è particolarmente importante, come in questo caso, quando si desidera l'integrazione sicura con i servizi di terzi. Applicabilità intersettoriale È possibile migliorare potenzialmente un numero di scenari di business praticamente infinito tramite l'utilizzo di SOA/WS e della protezione, rendendo possibile uno scambio di informazioni digitali interaziendale flessibile. Illustriamo qui altri brevi scenari per fornire informazioni sufficienti per immaginare la possibile applicazione di SOA/WS alla propria organizzazione. In ciascun caso, è possibile intravedere l'importanza di come un sistema di protezione basato su policy centralizzato, come CA SiteMinder WSS, agevola notevolmente la protezione di queste applicazioni critiche. Sanità. È possibile utilizzare un'applicazione SOA/WS per fornire rimandi e autorizzazioni in tempo reale per appuntamenti con gli specialisti. Un portale Web utilizzato dal medico di base può inviare una richiesta di Web service sul back-end al Web service di riferimento per verificare se il rimando è consentito o meno in base alle informazioni del medico e all'assicurazione sanitaria del paziente. Una policy di protezione coerente può essere migliorata in qualsiasi fase della transazione, anche se ogni parte utilizza una soluzione di protezione diversa, grazie all'utilizzo di standard comuni che agevolano l'interoperabilità. In questo caso, CA SiteMinder WSS può essere utilizzato da entrambe le parti dello scenario. Tuttavia, se si presuppone il suo utilizzo per proteggere il servizio di rimandi, non solo CA SiteMinder WSS è in grado di convalidare la validità delle informazioni di protezione nella richiesta a scopi di autenticazione, ma può anche prendere parte alla decisione di autorizzazione a più livelli. Area finanziaria. Un'applicazione spessa in esecuzione su desktop di un commerciale può richiamare più Web service utilizzando diversi protocolli e formati per eseguire servizi commerciali di valuta e opzioni. CA SiteMinder WSS, agendo da servizio di autenticazione condiviso, può fornire una WS-Security SAML Assertion al client desktop da riutilizzare per accedere a questi e ad altri Web service, ospitati all'interno o all'esterno dell'organizzazione. CA SiteMinder WSS può anche essere utilizzato per proteggere qualsiasi Web service, in particolare e più probabilmente quelli ospitati internamente, sull'ultimo miglio del servizio stesso. Spedizioni. Una ditta di spedizioni può esporre le informazioni sul tracking della spedizione in tempo reale tramite un Web service per l'integrazione con le applicazioni specifiche dei clienti. Industria manifatturiera. Un produttore di auto mondiale può distribuire servizi di informazioni innovativi su base continua direttamente ai clienti finali nelle proprie auto, a pagamento in base al servizio o come parte di un bundle di prodotti a valore aggiunto. In questo caso, l'accesso ai servizi può essere determinato in parte dall'identità dell'auto stessa e può includere il monitoraggio continuo delle prestazioni dell'auto, necessario per la manutenzione, e il provisioning di servizi premium non comprati o non disponibili al momento dell'acquisto originale. Se si pensa a tutti i servizi eventualmente utili alla guida di un'auto, molti di questi possono essere disponibili con un approccio basato su SOA/WS. CA SiteMinder WSS può assumere il ruolo importante di protezione dei servizi da un uso errato o da attacchi diretti. 17

18 Sezione 5: Conclusioni Le architetture orientate ai servizi e i Web service stanno emergendo come la nuova ondata principale di architetture di applicazioni. L'obiettivo di SOA/WS è migliorare velocità, flessibilità e costi di creazione e deployment delle applicazioni per gli utenti interni ed esterni. Tuttavia, le strategie e le architetture di protezione devono essere pianificate in anticipo oppure le organizzazioni correranno il rischio di ripetere gli errori del passato con la protezione che cerca sempre di recuperare essendo distribuita come collage di tecnologie e processi. Non è sufficiente risolvere i problemi di protezione SOA/WS discussi nel presente documento in base all'approccio tradizionale di deployment di molti livelli di protezione incoerenti, incompatibili e che si sovrappongono. La protezione deve essere inserita nell'ambiente come servizio di infrastruttura, consentendo un deployment flessibile ed efficiente in termini di costi, dall'edge al container. La bella notizia è che i problemi di protezione per le applicazioni basate su SOA/WS sono molto simili quelli che abbiamo affrontato quando si sono diffuse le applicazioni tradizionali basate su Web. Le organizzazioni devono gestire a livello centrale la protezione dei deployment SOA/WS aziendali, esattamente come fanno oggi per i siti Web e i portali, indipendentemente dal numero di Web service o dalle diverse tecnologie infrastrutturali distribuiti. Si può raggiungere questo fornendo una protezione basata su policy centralizzata come parte integrante dell'infrastruttura SOA/WS, consentendo l'astrazione della protezione dagli stessi servizi. CA SiteMinder WSS estende l'architettura provata di CA SiteMinder per fornire la piattaforma di protezione SOA/WS più completa del settore, offrendola protezione dei Web service basati su identità: autenticazione, autorizzazione e auditing (AAA). Inoltre, CA SiteMinder WSS se utilizzato con CA SiteMinder, fornisce una soluzione di protezione Web completa che protegge le applicazioni Web/i portali tradizionali e i Web service basati su XML, sfruttando gli stessi agenti, proxy e architettura basata su server delle policy. Per ulteriori informazioni su CA SiteMinder Web Services Security, visitare il sito ca.com/siteminder-wss CA Technologies è un'azienda di soluzioni e software di gestione IT con esperienza e competenze in tutti gli ambienti IT, dagli ambienti mainframe e distribuiti fino a quelli virtuali e cloud. CA Technologies gestisce e protegge gli ambienti IT, consentendo ai clienti di erogare servizi più flessibili. I prodotti e i servizi innovativi di CA Technologies offrono alle organizzazioni IT la visibilità e il controllo essenziali per stimolare l'agilità del business. La maggior parte delle aziende incluse nella classifica Global Fortune 500 si affida a CA Technologies per la gestione degli ecosistemi IT in continua evoluzione. Per ulteriori informazioni, visitare il sito CA Technologies all indirizzo Copyright 2012 CA Technologies. Tutti i diritti riservati. Tutti i marchi, i nomi commerciali, i marchi di servizio e i logo citati nel presente documento sono di proprietà delle rispettive società. CS2138_0212