Presentazione - ANALISI DI PATTERN DI SICUREZZA PER APPLICAZIONI BASATE SU SERVIZI

760 views
671 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
760
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Presentazione - ANALISI DI PATTERN DI SICUREZZA PER APPLICAZIONI BASATE SU SERVIZI

  1. 1. V Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Dipartimento di Elettronica e Informazione ANALISI DI PATTERN DI SICUREZZA PER APPLICAZIONI BASATE SU SERVIZIRelatore: prof. Pierluigi PLEBANI Elaborato di Laurea di: Gianfranco CONTI Matricola: 737296 Anno Accademico 2009-2010
  2. 2. Obiettivi & Metodologia 2 v  Obiettivi preposti:   Fornire una panoramica tra gli strumenti e i requisiti di sicurezza;   Osservare come questi strumenti e requisiti vengano gestiti ed utilizzati all’interno di una SOA;   Cogliere gli aspetti salienti e il valore aggiunto che portano all’architettura stessa della SOA;   Evidenziare le peculiarità ed i vantaggi nell’utilizzo di questi strumenti. v  Metodologia seguita: ü  individuare alcune linee di sviluppo di maggiore interesse e approfondirle criticamente. Nome relatoreANALISI DI PATTERN DI SICUREZZA PER APPLICAZIONI BASATE SU SERVIZI
  3. 3. Overview 3   Una panoramica tra gli strumenti e i requisiti di sicurezza v  SOA, WS, BPEL, WS-SECURITY, SAML, XACML, Confidenzialità, Integrità e non ripudio, Autorizzazione ecc   Gestione ed utilizzo degli strumenti e dei requisiti di sicurezza in una SOA v  A Pattern Language for Identity Management (Circle of Trust, Identity Provider, Identity Federation) v  Patterns for the eXtensible Access Control Markup Language (XACML Authorization ., XACML Access Control Evaluation) v  A Pattern-Driven Security Process for SOA Applications v  BPEL Processes for Non-Repudiation Protocols in Web Services v  The Credentials Pattern ü  Patterns for Authentication and Authorization Infrastructures v  Data provenance in SOA-security-reliability-and-integrity ü  Authorization-Based Access Control for the SOA (Identity-based AC vs Authorization-Based AC) ü  Methodology and Tools for End-to-End SOA Security Configurations   Conclusioni Nome relatoreANALISI DI PATTERN DI SICUREZZA PER APPLICAZIONI BASATE SU SERVIZI
  4. 4. Patterns for Authentication and 4 Authorization Infrastructures 1 of 2 Viene proposto un pattern system derivato in grado di esprimere completamente ed esaustivamente una generica “attributed- based Authentication and Authorization Infrastructure”. v  Aspetti fondamentali:   apprendere da altre implementazione  evitare falle di sicurezza e bug per software di business critici;   modularizzazione dei pattern  assegnare uno specifico e accettato security pattern ad ogni singolo modulo. v  La catena di processo e i relativi pattern associati: Nome relatoreANALISI DI PATTERN DI SICUREZZA PER APPLICAZIONI BASATE SU SERVIZI
  5. 5. Patterns for Authentication and 5 Authorization Infrastructures 2 of 2 v  Le relazioni tra i pattern: I risultati ottenuti sono una classificazione e una valutazione completa delle migliori pratiche, nonché degli insegnamenti appresi. SAML è stato utilizzato per la comunicazione, mentre XACML per l’attuazione dell’attribute-based Access Control (ABAC). Nome relatoreANALISI DI PATTERN DI SICUREZZA PER APPLICAZIONI BASATE SU SERVIZI
  6. 6. Authorization-Based Access Control 6 for the Services Oriented Architecture 1 of 2 v  Con l’Identity-based Access Control - IBAC avremo che: ü  Il rapporto di fiducia tra due domini è l’unica cosa che può prevenire violazioni dal parte dei singoli domini è resterebbe comunque il problema della propagazione di tali informazioni tramite intermediari; ü  In caso di cambio di compiti, il dominio di riferimento deve aggiornare tutte le sue ACL e informare tutti gli altri domini è i domini interessati dovranno dunque aggiornare i propri DB è alti costi se i cambiamenti sono frequenti; ü  In caso di delega e/o revoca, il nuovo user delegato non sarà in grado di utilizzare il servizio finché non saranno aggiornati i DB è viceversa potrà continuare ad utilizzare la propria autorità finché la revoca non sarà propagata su tutti i DB; è la mancanza del requisiti di coerenza fra i DB limita fortemente la scalabilità; ü  I certificati emessi da un certo dominio devono essere processati da altri domini è in caso di aggiornamenti il sistema dovrà essere aggiornato in modo coordinato; è ciò comporta un forte limite per chi volesse entrare a far parte del sistema; ü  Ogni programma invoca i servizi presentando le asserzioni SAML dell’identità del principal è le autorità assegnate sono prese dall’ambient del principal; è sono consentiti attacchi informatici incorportati in link fasulli o script su pagine web è è possibile effettuare qualsiasi azione che gli admin hanno concesso al principal nel policy DB; è  Poca flessibilità e scalabilità; è  Difficoltà nell’utilizzo, nell’aggiornamento, nella delegazione e nella gestione nei DB; è  Sensibile ad errori, virus e perdita delle informazioni fra i domini. Nome relatoreANALISI DI PATTERN DI SICUREZZA PER APPLICAZIONI BASATE SU SERVIZI
  7. 7. Authorization-Based Access Control 7 for the Services Oriented Architecture 2 of 2 v  Con l’Authorization-based Access Control - ABAC avremo che: ü  ogni dominio ha informazioni riguardanti il solo principal è risolve il problema delle identità distribuite; ü  se si ha la necessità di cambiare dei compiti fra i vari utenti, si cambiano semplicemente le autorizzazioni dei rispettivi utenti è l’eventuale revoca è immediata; è nessun dominio ha la necessità di essere informato delle modifiche è nessuna perdita di informazioni ; ü  il formato dell’autorizzazione è necessaria soltanto da parte del servizio a cui si fa riferimento è facilita l’unione di nuove aziende al sistema, con il minimo effetto sui loro processi interni ü  Una richiesta deve portare solo le autorizzazioni del solo principal è se un programma ha un errore o contiene un virus, si potrà abusare delle sole autorità del principal e non di tutte come avviene con l’IBAC è  Facilità di scalabilità, di evoluzione, di delega e di gestione; è  Più privato e più sicuro; …per attuare ciò è necessario apportare una “piccola” modifica al modello IBAC ANALISI DI PATTERN DI SICUREZZA PER APPLICAZIONI BASATE SU relatore NomeANALISI DI PATTERN DI SICUREZZA PERAPPLICAZIONI BASATE SU SERVIZISERVIZI
  8. 8. Methodology and Tools for 8 End-to-End SOA Security Configurations 1 of 2 Il pattern in oggetto si pone il problema di come aiutare gli sviluppatori a concentrarsi sulle proprie responsabilità per la configurazione della sicurezza nelle applicazioni SOA-based durante l’intero processo di sviluppo, fornendo oltre al processo di configurazione della sicurezza anche il supporto della tecnologia per gli sviluppatori. v  Criticità nel processo di sviluppo “attuale”: ü  Nel processo di sviluppo non viene chiaramente definito come configurare la sicurezza; ü  I requisiti di sicurezza e le rispettive configurazioni sono determinare e realizzate in downstream phase; ü  Le informazioni richieste per la configurazione della sicurezza non sono disponibili nella fase di downstream; ü  In downstream phase lo sviluppatore non possiede sufficienti informazioni per creare corrette configurazioni di sicurezza; ü  Non vi è modo di sapere quale sicurezza è richiesta dai requisiti di business e se vengano o meno soddisfatti.  Come definire i ruoli dello sviluppatore da un punto di vista delle informazioni disponibili durante le fasi di sviluppo? v  Processo di sviluppo “futuro” proposto:   Il Business Analist definisce i business-level requirement è i requisiti di sicurezza devono essere chiariti come una business-level policy definita dai busines proces;   Il Software Architect crea un service model completo concreto per soddisfare il business è  i requisiti di sicurezza per la composizione devono essere specificati nel service model;   Il Developer (che nell’”attuale” processo di sviluppo, sviluppa e testa gli atomic service) NON ha nessun ruolo èsarà il Deployer attraverso WS-Security a specificare che il servizio verrà garantito dal deploy security configuration file;   Un Assembler crea il file di configurazione di sicurezza per ogni atomic service è i requisiti di sicurezza definiti al passo 2 vengono garantiti;   Il Deployer imposta la piattaforma che dovrà eseguire e gestire i servizi per una esecuzione sicura è  verrà eseguito il deploy della configurazione per la piattaforma. Nome relatoreANALISI DI PATTERN DI SICUREZZA PER APPLICAZIONI BASATE SU SERVIZI
  9. 9. Methodology and Tools for 9 End-to-End SOA Security Configurations 2 of 2 v  Per attuare ciò si propongono due tecnologie: ü  Model-Driven Security – è una tecnologia per generare concretamente in modo semi-automatico, un file di configurazione della sicurezza della model transformation dei requisiti di sicurezza, specificati dal Software architect. ü  Pattern-based Policy Application - supporta il Software architect nello specificare i requisiti (gli intent) di sicurezza della composizione dei servizi attraverso l’applicazione di un pattern che si occuperà di applicare gli intenti per i componenti (anche di basso livello). Nei pattern alcuni vincoli sono specificati, in modo tale che gli intenti non validi, siano individuati e corretti.  Si contribuirà dunque a generare configurazioni complesse in modo corretto, riducendo al contempo il carico di lavoro agli sviluppatori anche quando il dominio di sicurezza è di tipo federato. Nome relatoreANALISI DI PATTERN DI SICUREZZA PER APPLICAZIONI BASATE SU SERVIZI
  10. 10. Conclusioni 10 Si è appreso come la scelta e l’utilizzo di appropriati strumenti (WS-Security; SAML, XACML; X.509, Kerberos, TLS; AES, ecc) e requisiti (Confidentialità; Integrità & non-ripudio; Autenticazione e Autorizzazione) all’interno di pattern di sicurezza per applicazioni basate sul web, siano di fondamentale importanza per il raggiungimento di quegli obiettivi che un SOA da sempre si prepone di raggiungere: v  Scalabilità, Sicurezza e Gestione. Abbiamo inoltre appreso come sia utile e necessario a tale fine: ü  Centralizzare la gestione delle informazioni delle identità; ü  Realizzare una policy unificata di accesso in tutta l’organizzazione; ü  Utilizzare un approccio MDA che renda possibile considerare la sicurezza non più come un aspetto isolato; ü  Utilizzare pattern system derivati; ü  Considerare la provenienza dei dati; ü  Utilizzare un approccio riguardante le decisioni del controllo di accesso basate sull’autorizzazione (ABAC); ü  Utilizzare metodologie per configurazioni di sicurezza di tipo end-to-end per applicazioni SOA; ü  Utilizzare strumenti standard e ben conosciuti; Nome relatoreANALISI DI PATTERN DI SICUREZZA PER APPLICAZIONI BASATE SU SERVIZI

×