Presentazione Aniketos @
Aniketos: Agenda. Introduzione. Presentazione del progetto. Possibili impieghi dei primi risultati. Demo 1 Demo 2
Aniketos: Il progetto. Aniketos è un progetto di ricerca finanziato nell'ambito del programma quadro FP7 (Seventh Framework Programme for Research and Technological Development 2007-2013) Il progetto è allineato all obiettivo strategico 1.4 infrastrutture sicure ed affidabili definiti dalla Commissione Europea nel bando ICT dell FP7. Il consorzio costituito per la realizzazione di Aniketos è composto da grandi operatori industriali e di ricerca nel campo ICT e TLC (Sintef, ESI, CNR, Thales, LJMU, Selex Elsag, Search, Atos, UNITN, ATC, SAP, Italtel, Plus, DBL, Wind, Daem). La durata totale del progetto è di 42 mesi (Settembre 2010 Gennaio 2014).
Aniketos: la piattaforma. Il progetto Aniketos è finalizzato allo sviluppo di una piattaforma software di supporto alla progettazione, alla creazione ed al successivo utilizzo a run-time di servizi web costituiti a partire da servizi atomici o da altri servizi composti già disponibili. Gli utilizzatori dei servizi accederanno in modo trasparente e dinamico a diversi abbinamenti di componenti del servizio composto a seconda della loro disponibilità e attributi di sicurezza e affidabilità.
Aniketos: la piattaforma. Ai progettisti la piattaforma fornisce in fase di design metodi per la specifica dei requisiti di sicurezza, l'analisi del livello di sicurezza di un servizio, suggerimenti sulla risoluzione, e la condivisione di informazioni sull esistenza di nuove minacce e vulnerabilità (attraverso una community dedicata). Il valore aggiunto della piattaforma sarà nell instaurare e mantenere continuamente la sicurezza e l'affidabilità in un ambiente orientato ai servizi in continua evoluzione in tutto il ciclo di progettazione, creazione ed utilizzo dei servizi web. Sicurezza Affidabilità
Aniketos: la piattaforma.
Aniketos: principali fruitori. La piattaforma si configura quindi come un potente strumento che si rivolge principalmente ad i seguenti attori o ad altri riconducibili a questi: Progettisti/Sviluppatori: per la creazione ed il delivery di nuovi servizi. In generale, tuttavia, l ingaggio per tali sviluppi va ricondotto a progetti finanziati da Service Provider. Service Provider: per supportare l aumento del portafoglio servizi e conseguentemente di revenue per la loro fruizione, Utenti finali del servizio per l appeal di utilizzo, fidelizzazione e affidabilità percepite. È tuttavia importante notare che le totali potenzialità della piattaforma Aniketos saranno consolidate nel corso del progetto.
Aniketos: principali mercati. La piattaforma si potrebbe rivolgere principalmente ad i seguenti mercati: Mercato pubblico: ad esempio per l on-line ed il social shopping ma comunque più generale a tutti i e-business players a cui la piattaforma offrirebbe i sui elementi caratterizzanti di sicurezza ed affidabilità. Industria: ad esempio ICT, TELCO, Turismo, Banking: per la crescente richiesta di nuovi servizi sempre più evoluti da vendere all Utente finale da parte dei Service Provider. Pubblica amministrazione centrale e locale, tra gli obiettivi principali dei risultati del progetto, per supportare la crescente necessità di offerta di servizi al cittadino in perfetta sinergia con le direttive Europee in materia. Vista la natura e le potenzialità offerte dalla piattaforma si potrebbe pensare di immetterle gradualmente nel mercato con un meccanismo di tipo pay-per-use o a canone periodico sotto forma di servizio offerto da un Service Provider ai propri Clienti.
Aniketos: futuri impieghi e commercializzazione. PaaS (Platform as a Service) potrebbe essere una possibile forma di commercializzazione del prodotto del Progetto Aniketos in architettura ad alta affidabilità con server fisicamente collocati presso il data center del Service Provider. Il Service Provider esporrebbe in questo caso delle interfacce per costruire memorizzare e gestire i propri web services composti costruiti con i requisiti di sicurezza e affidabilità propri di Aniketos. Il Service Provider amministrerebbe la community dedicata di Aniketos per la condivisione di informazioni su come mitigare nuove minacce e vulnerabilità. Il Cliente utilizza tali interfacce per costruire memorizzare e gestire i propri web services composti e per amministrarli (configurazione, attivazione, disattivazione) a design-time. L utente finale utilizza il servizio configurato dal suo Cliente usufruendo a run-time delle caratteristiche di continuo monitoraggio dei livelli di sicurezza e affidabilità del servizio
Aniketos: stato del progetto. Durante la riunione plenaria Aniketos tenutasi a Parigi (Febbraio 2012) sono stati presentati i seguenti moduli della piattaforma: Uno strumento completamente grafico per il design dei servizi composti e la specifica dei requisiti di sicurezza Un repository di ricerca per le minacce e link alle contromisure. Un service registry per l'archiviazione dei servizi Aniketos (Marketplace). Un modulo che permette la sottoscrizione e la notifica di determinati tipi di eventi secondo l approccio publish-subscribe. Un modulo che genera i composition plan effettuando il discovery dei servizi registrati nel Marketplace in accordo alle specifiche funzionali Un modulo che permette l ordinamento (ranking) dei composition plan secondo criteri di affidabilità, disponibilità, privacy e trust. Un modulo per la convalida e verifica di un servizio composto.
Aniketos: possibili impieghi primi risultati di progetto. Valutare se alcuni risultati del progetto Aniketos possano essere utilizzati per arricchire le potenzialità della SMP SaaS in termini di: Supporto alla fase di creazione dei servizi a catalogo (web services) tramite utilizzo della componente BPM di Aniketos N:B: da valutare eventuali sovrapposizioni con la componente attualmente usata nella SMP basata sul prodotto jbpm di JBOSS Offerta di tale componente BPM come servizio a catalogo della SMP. N:B: da valutare eventuale business case associato
Aniketos: possibili impieghi primi risultati di progetto. Supporto alla definizione dei requisiti di sicurezza nelle prime fasi del processo di sviluppo dei servizi a catalogo tramite il tool STS-ml (socio-technical security modelling language) di Aniketos. Lo strumento permette di definire i requisiti di sicurezza sul piano organizzativo (business), e consente agli analisti di rappresentare le proprietà di sicurezza e trust che sono fondamentali per la progettazione di applicazioni orientate ai servizi. Lo strumento STS si propone di aiutare gli analisti durante tutto il processo di ingegneria dei servizi. Offerta di tale componente STS come servizio a catalogo della SMP. N:B: da valutare eventuale business case associato, royalties, ecc
Designing secure and trustworthy composite services Demo 1. Tool di supporto alla definizione dei requisiti di sicurezza: Sts tool and language (socio-technical security modelling tool and language) Demo 2. Componente BPM di Aniketos: Service Composition Framework
Sts tool and language 14
Design of composite services In Aniketos il design dei servizi composti comprende (oltre alla specifica di requisiti funzionali): La specifica delle security properties che i servizi devono garantire L espressione dei requisiti di trustworthiness L sts tool permette al service designer: L espressione dei security requirements La verifica automatica di tali requisiti 15
Language outline 16
Security and trustworthiness modelling: steps Per il design di un servizio composto con relativi security requirements è necessario seguire i seguenti step: i. Identificare gli attori principali ii. Individuare ed analizzare gli obiettivi degli attori iii. Definire le interazioni tra gli attori iv. Esprimere i requisiti di security e trustworthiness 17
Esempio di utilizzo dell Sts-Tool Obiettivo: design di un composite service per la pianificazione di viaggi con focus sugli aspetti di security e trustworthiness 18
Design of the Travel planner composite service (1/7) i. Identificare gli attori principali 19
Design of the Travel planner composite service (2/7) ii. iii. Individuare ed analizzare gli obiettivi degli attori Definire le interazioni tra gli attori 20
Design of the Travel planner composite service (3/7) Social view 21
Design of the Travel planner composite service (4/7) iv. Esprimere i requisiti di security e trustworthiness Non-delegation Non-repudiation Trustworthiness constraint (tc) Paymentprocessor.Trustworthiness>5 22
Design of the Travel planner composite service (5/7) Resource view 23
Design of the Travel planner composite service (6/7) Authorization view 24
Design of the Travel planner composite service (7/7) Need-to-know integrity 25
Deriving commitments Dalle tre view, il tool sarà in grado di derivare automaticamente i commitments Attualmente i commitments vengono derivati manualmente E in corso il lavoro di formalizzazione per abilitare il mapping I Commitments costituiscono l input per la specifica dei security contract template Il contract template è espresso da un insieme di ConSpec policies dalle policies verranno generate le monitoring rules per verificare che a run time non venga violato il contratto 26
Derivazione dei commitments per il Travel planner Formalmente il commitment è espresso da una relazione quaternaria C (debtor, creditor, antecedent, consequent) Commitments derivati dall esempio: C1 = C(PP, TP, D1=delegate(TP, PP, payment processed), nonrepudiation (D1)) C 2 = C(PP, TP, D 1, non-delegation (payment processed)) C 3 = C(PP, TP, delegation(tp, PP, payment processed), maintain(tc)) C 4 = C(AP, TP, subscribed(tp, tc), monitor(ap, tc)) C 5 = C(AP, TP, subscribed(tp, tc) violated(tc), notify(ap, TP)) 27
ConSpec per l espressione di security policies ConSpec syntax 28
Esempio di utilizzo di ConSpec Trustworthiness constraint (tc) Paymentprocessor.Trustworthiness>5 Esempio di policy ConSpec relativa al trustworthiness requirement SCOPE method SECURITY STATE string availability_id = "TRUSTWORTHINESS"; int trustworthiness_threshold = 5; BEFORE invokeservice(s) PERFORM (org.aniketos.trust.trustmodule.evaluatetrustworthiness(s) > trustworthiness_threshold) -> skip BEFORE serverequest(cln) PERFORM (org.aniketos.trust.trustmodule.evaluatetrustworthiness(cln)> trustworthiness_threshold) -> skip 29
Service Composition Framework 30
Service Composition Framework Basato su BPMN 2.0 Estensione di Activiti Designer, tool per la modellazione di processi BPMN Composto da una serie di plugin di Eclipse (OSGI bundles) Permette: La creazione di una specifica funzionale BPMN del servizio composto (service specification) Il discovery di servizi atomici nel Marketplace ed il binding di questi alla service specification (composition plan) La creazione di una serie di composition plan tramite combinazione dei servizi atomici restituiti
Service Composition Framework Service specification Lo sviluppatore crea una service specification tramite la definizione di un processo BPMN (drag & drop degli elementi BPMN presenti nella palette). Il processo sarà composto da diversi Service Task. Ognuno di questi prevede l invocazione di una operazione messa a disposizione da un web service atomico.
Service Composition Framework Service discovery Pagina di configurazione di ogni Service Task dove lo sviluppatore può definire il type del servizio da cercare all interno del Marketplace. Una volta avviato il discovery, il campo Operation conterrà la lista delle operazioni disponibili in tutti i web services di tipo type restituiti. Lo sviluppatore può selezionare una operazione, definire i valori di input ed associare il valore di ritorno ad una variabile del processo.
Service Composition Framework Composition plans Lo sviluppatore può cliccare sul bottone Create Composition Plans ed avviare la creazione di una serie di composition plan. Ogni composition plan rispecchia il diagramma BPMN definito ma i singoli service task contenuti in esse saranno collegati a differenti web services effettuando una combinazione dei servizi ottenuti nella fase di discovery. 12/12/2012 Copyright SELEX Elsag. All rights 34 reserved.
Empty slide to be used in between presentation chapters if needed Text Grazie per l attenzione