Analisi e sviluppo di uno strumento per l'automazione della verifica di conformità allo standard pci dss

564 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
564
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Analisi e sviluppo di uno strumento per l'automazione della verifica di conformità allo standard pci dss

  1. 1. Università degli Studi di Trieste Facoltà di Ingegneria Tesi di Laurea Magistrale in INGEGNERIA INFORMATICA A NALISI E SVILUPPO DI UNOSTRUMENTO PER L ’ AUTOMAZIONEDELLA VERIFICA DI CONFORMITÀ ALLO STANDARD PCI - DSS Laureando: Relatore:Lorenzo Caenazzo Prof. Alberto Bartoli Correlatori: Alessandro Budai Enrico Milanese Anno Accademico 2011-2012
  2. 2. IndiceIntroduzione iv Contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv Obiettivi e vincoli progettuali . . . . . . . . . . . . . . . . . . . . . . iv Risultato e fasi del lavoro . . . . . . . . . . . . . . . . . . . . . . . . v Articolazione della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . v1 Analisi e progettazione 1 1.1 Problema e situazione preesistente . . . . . . . . . . . . . . . . . 1 1.2 Workow PCI-DSS . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Denizione delle entità . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 Scelta DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4.1 Documenti . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Avvisi, riepiloghi . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.6 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.7 Metodologia di sviluppo e tecnologie adottate . . . . . . . . . . 92 Realizzazione 11 2.1 Interfaccia utente . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.1 Home Page . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.2 Pagina di gestione . . . . . . . . . . . . . . . . . . . . . 15 2.1.3 Analisi Usabilità . . . . . . . . . . . . . . . . . . . . . . 19 2.2 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.1 Gerarchia delle classi . . . . . . . . . . . . . . . . . . . . 22 2.2.2 Package core . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2.3 Package web . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.4 Avvisi mail . . . . . . . . . . . . . . . . . . . . . . . . . 30 ii
  3. 3. 2.2.5 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Conclusioni 37 3.1 Obiettivi e sviluppi futuri . . . . . . . . . . . . . . . . . . . . . 37 3.2 Lavoro svolto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.3 Valutazioni personali . . . . . . . . . . . . . . . . . . . . . . . . 384 Bibliograa 39Ringraziamenti 41 iii
  4. 4. Introduzione Questa tesi illustra il lavoro da me svolto presso la Emaze Networks S.p.A.Contesto Le maggiori emittenti di carte di credito hanno deciso di formare unorga- 1 2nizzazione chiamata PCI che ha formulato uno standard (DSS ). LEnte responsabile degli standard di protezione PCI è un forum globale aperto dedicato allo sviluppo, al miglioramento, alla memo- rizzazione, alla distribuzione e allimplementazione degli standard di sicurezza per la protezione dei dati degli account. La missio- ne dellEnte responsabile degli standard di protezione PCI è mi- gliorare la sicurezza dei dati relativi ai pagamenti garantendo una formazione appropriata e una conoscenza degli standard PCI.Tutti i soggetti che trattano dati di carte di credito devono aderire allo standardPCI DSS. Uno dei requisiti richiesti è lanalisi di Vulnerability Assessment sulla 3propria infrastruttura pubblica da parte di una società certicata PCI ASV .Questo standard oltre a ssare i limiti per il rilascio della certicazione delineaun workow che il certicatore è tenuto a seguire. Il progetto è stato avviatoin previsione di una espansione della domanda di tale certicazione.Obiettivi e vincoli progettuali Lobiettivo è di costruire uno strumento che faciliti gli operatori a seguire ilusso imposto dallo standard, con particolare attenzione anche ai fattori com- 1 Payment Card Industry 2 Data Security Standard 3 Approved Scanning Vendor iv
  5. 5. merciali delle analisi. Inoltre dovrà inviare resoconti giornalieri agli operatorisulle situazioni di allarme, gestire contratti, ticket di supporto al cliente, ana-graca dei clienti, gestione documentale e lo stato di ogni analisi eettuata.Si è scelto di sviluppare unapplicazione web, accessibile solamente dalla reteprivata aziendale. Per la realizzazione sono state usate le seguenti tecnologie: • Java; • Spring, un framework con molte funzioni, in particolare è stato usato per 4 la gestione del pattern architetturale MVC ; • ExtJS, un framework per la creazione di pagine web e linterazione client- server; • Apache Tomcat, come servlet container; • un DBMS, a scelta tra PostGreSQL o MongoDB.Queste tecnologie sono state imposte per politica aziendale.Risultato e fasi del lavoro Il lavoro di tesi si è svolto con una parte iniziale di apprendimento generaledelle tecnologie impiegate. Successivamente si è iniziato ad implementare ivari aspetti seguendo i principi dello sviluppo agile, rivedendo più volte lastruttura logica e sica del progetto tramite prototipi, no allottenimento delrisultato voluto. Il lavoro risultante è un portale web che permette la gestionedegli aspetti sopra citati.Articolazione della tesi Di seguito, un breve riepilogo dei contenuti presenti nei capitoli: 1. Si analizza il problema denendo i requisiti e le caratteristiche che do- vranno essere implementate; 4 Model View Controller è un design pattern che divide in modo rigido i compiti dellevarie classi allinterno di unapplicazione web v
  6. 6. 2. Si descrive linterfaccia utente realizzata e limplementazione della logica del sistema;3. Si delineano le conclusioni sul lavoro svolto e possibili sviluppi futuri;4. Si espongono i riferimenti bibliograci e le fonti utilizzate. vi
  7. 7. Capitolo 1Analisi e progettazione1.1 Problema e situazione preesistente In previsione di un aumento della domanda delle certicazioni PCI-DSS, siè scelto di creare uno strumento atto alla gestione: • delle analisi eettuate; • della relativa documentazione, upload e download dei documenti; • dellanagraca del cliente; • della situazione contrattuale. Si è scelto di avviare un progetto completamente nuovo perché non erapresente alcuna piattaforma simile da poter usare come base di partenza. Pre-cedentemente per la gestione dei dati sopra citati, a causa dellesiguo numerodi clienti, veniva usato un foglio di calcolo per ogni cliente contenente tutte leinformazioni. Allaumentare dei clienti e delle analisi luso di fogli di calcolorisulta poco agevole, in quanto introduce problemi di allineamento dei dati trale copie locali dei fogli.1.2 Workow PCI-DSS Lo standard PCI-DSS per il corretto svolgimento dellattività di analisi di 1vulnerabilità impone allASV di seguire il seguente workow. 1 Approved Scanning Vendor 1
  8. 8. Figura 1.1: Workow PCI-DSS. Questo workow descrive le fasi e le interazioni che devono avvenire tra la-zienda che esegue lanalisi e quella che lha commissionato. Lo schema è divisoin due zone per gli obblighi di ogni attore. Delinea anche i comportamenti daadottare in caso di: • informazioni parziali; • analisi andata a buon ne; • analisi fallita. In prima approssimazione ogni scambio di dati tra ASV e cliente è accom-pagnato da una serie di documenti e tali interazioni possono portare ad unblocco, momentaneo, della procedura di analisi. Prima dellanalisi delle vulnerabilità si procede ad una verica degli indiriz-zi IP forniti, e qualora si rilevino altri indirizzi IP pubblici collegati ai dominisotto analisi si rende necessario decidere insieme al cliente se inserirli nellaanalisi da eettuare. Una volta individuati tutti gli IP da testare e ricevuta lautorizzazione a 2procedere, viene eseguita lanalisi di vulnerabilità tramite ipLegion . Ogni 2 un software sviluppato internamente dalla Emaze per il controllo automatizzato dellevulnerabilità 2
  9. 9. vulnerabilità è classicata con un livello di rischio che va da zero a dieci. Ilcliente viene considerato protetto se vengono individuate solo vulnerabilità digrado da 0 a 3,9. Nel caso in cui lanalisi termini con un fallimento inizia un confronto traASV e cliente in modo da accertare eventuali falsi positivi. Una volta esclusigli eventuali falsi positivi se rimangono vulnerabilità di grado maggiore a 4lanalisi risulta a tutti gli eetti fallita. Per ottenere la certicazione il clientedovrà applicare i suggerimenti consigliati allinterno del report dellattività erichiedere una nuova analisi.1.3 Denizione delle entità Il sistema deve poter gestire il dettaglio dei clienti con associati i relativi:indirizzi IP, analisi eettuate e contratti stipulati. Inoltre deve mantenere lostorico di queste entità. Per il soddisfacimento di tali requisiti di gestione anagraca e documen-tale sono state individuate quattro entità separate per modellare gli aspettiessenziali. Le entità individuate, con relativi attributi, sono: • Analisi (data di esecuzione, contratto associato, indirizzi IP in esame, risultato); • Contratti (massimo numero di analisi eettuabili, inizio validità contrat- to, ne validità contratto, cliente associato); • Clienti (anagraca varia); • Indirizzi IP (indirizzi IP, data di inserimento nel sistema, contratto as- sociato). 3
  10. 10. Figura 1.2: Schema provvisorio delle entità. Una volta realizzato il primo prototipo basato su queste entità basilari,e sottoponendolo alla valutazione da parte dei futuri utilizzatori del sistema,sono state notate delle lacune nel modello dei dati iniziale. In accordo con ilmodello dello sviluppo agile si è reso necessario rimodellare le entità fonda-mentali cambiando struttura a quelle già presenti, aggiungendone delle altree modicandone le relazioni tra esse. Da tale confronto è anche emerso uncaso duso inizialmente non preso in esame: il cliente acquista un pacchet-to di analisi e cede tali analisi a sua volta a suoi clienti. Questo caso dusomodica il rapporto di parentela tra tutte le entità no ad ora individuate erisulta mancante unentità che rappresenti il cliente principale. Si è inoltredeciso di aggiungere unentità che rappresenti i ticket di assistenza forniti aiclienti in modo da tracciare anche questo aspetto delle analisi per una correttarendicontazione. Inoltre per questioni pratiche è stato inserito un campo note. Le nuove entità identicate sono: • Analisi (data di esecuzione, contratto associato, cliente slave associato, indirizzi IP in esame, risultato, note); • Contratti (numero massimo di analisi eettuabili, numero massimo di tic- ket di assistenza usabili, inizio validità contratto, ne validità contratto, cliente master associato); • Clienti slave (anagraca varia, cliente master associato, note); 4
  11. 11. • Clienti master (anagraca varia, note); • Indirizzi IP (indirizzi IP, data di inserimento nel sistema, cliente slave associato); • Ticket assistenza (data esecuzione, durata, contratto associato, operatore che ha eseguito il ticket, note). Figura 1.3: Schema denitivo delle entità. Questo schema rappresenta le entità che eettivamente formano la basedati del sistema.1.4 Scelta DBMS La scelta si poneva tra un database relazionale come PostGreSQL, ed unonon relazionale orientato ai documenti come MongoDB. Si è deciso di usare 5
  12. 12. questultimo per sfruttare la possibilità di salvare les in modo nativo al suointerno. Questo particolare DBMS non richiede la denizione di tabelle e relazioniprima di poterlo usare, e conseguentemente, non si deniscono i tipi di datoche dovrà contenere. Quindi non necessita di una progettazione vera e propriain quanto, allatto di salvare unentità, il driver si prenderà lonere ove nonsia già presente di creare una collezione, simile al concetto di tabella deidatabase relazionali, in cui salvare lentità stessa. Allinterno di tale collezione 3verranno salvate tutte le entità dello stesso tipo codicate in BSON , per motiviprestazionali. MongoDB permette di salvare anche entità con struttura diversa allinternodella stessa collezione. Ad esempio se dalla shell di amministrazione si eseguonoi seguenti comandi: db.test.save({num : 1}) db.test.save({num : 2 , str : Stringa}) db.test.find() {_id : ObjectId(50fd69fb8eadef9a1d8c1315), num : 1} {_id : ObjectId(50fd6a0e8eadef9a1d8c1316), num : 2, str : Stringa}non ricevo alcun errore, anche se il secondo documento salvato ha un attributoin più. Da questo esempio si può notare la struttura simile al formato JSONe laggiunta di un ID univoco generato automaticamente. La possibilità disalvare entità con struttura diversa, risulta molto utile per la memorizzazionedi entità complesse che al loro interno includono altre entità. Inoltre MongoDBpermette di eettuare backup senza interrompere lattività, in aggiunta qualorasi renda necessario, gestisce automaticamente la replica su più nodi così daaumentare la sicurezza dei dati. Di contro MongoDB non implementa il concetto di transazione come iDBMS relazionali, preferendo il salvataggio di intere entità. Non implementanessun concetto di relazione, quindi è esclusa la possibilità di far eseguire inmodo automatico delle query di join, ma qualora sia possibile, è da preferire 3 formato JSON binario 6
  13. 13. una denormalizzazione salvando un unico documento con allinterno tutte leinformazioni ad esso collegate. Tale denormalizzazione è stata eettuata sullentità delle analisi che inglo-ba lentità degli indirizzi IP così da salvarne esattamente lo stato in un datoistante. Se non fosse possibile eseguire questa denormalizzazione risulta neces-sario eseguire più interrogazioni per reperire tutte le informazioni. Per questimotivi, se si è costretti a gestire più collezioni, il database potrebbe perdere diconsistenza in caso di cancellazioni.1.4.1 Documenti Il sistema nale pone come requisito fondamentale la gestione del salvatag-gio di documenti in qualsiasi formato e di ogni dimensione. Questi documenti,solitamente in formato PDF, devono essere associati alle singole analisi inquanto sono: • autorizzazioni a analizzare i sistemi; • report dellanalisi di vulnerabilità; • informative; • altri documenti. Si è deciso di implementare questa particolare funzionalità tramite codice 4nativo dopo aver vagliato lopportunità di usare un CMS come Alfresco,scartato per lelevata complessità necessaria per la gestione di unoperazionecosì semplice. Per eseguire il salvataggio dei le esistono sostanzialmente duemetodi: • salvataggio nel File System; • salvataggio nella base dati (MongoDB). Inizialmente, prima di scegliere il DBMS da usare, il salvataggio avvenivanel File System del server. Questo particolare approccio consente di accedere 4 Content Management System 7
  14. 14. ai le memorizzati tramite connessione remota alla cartella di salvataggio, marende il backup dellintero sistema più elaborato. Come accennato preceden-temente la decisione di usare MongoDB come DBMS ha permesso di salvarenativamente documenti allinterno del database tramite GridFS. GridFS è una funzione di MongoDB che permette di salvare le di di-mensioni arbitrarie allinterno del database. Il salvataggio avviene in modoautomatico creando due collezioni fs.les e fs.chunks; la prima collezionecontiene tutti i dati relativi alle informazioni sul le quali: nome, dimensione,lhash MD5, data di caricamento, eventuali metadati accessori. La secondacollezione contiene il le vero e proprio serializzato e diviso in pezzi da 256kB.1.5 Avvisi, riepiloghi Il sistema nale deve mettere in evidenza le situazioni che richiedono lat-tenzione di un operatore come: • contratti in scadenza; • certicazioni che stanno per terminare la propria validità; • raggiungimento da parte di un cliente del limite delle analisi o dei ticket di supporto. Per fare ciò si è scelto di visualizzare queste informazioni allapertura del-lapplicazione, sulla home page. Inoltre si è deciso di far compilare ed inviarequotidianamente al sistema delle email automatiche ad una mailing list in-terna. Oltre alle situazioni dallarme precedentemente elencate, si è scelto diinviare tramite mail unulteriore avviso che riguarda unanalisi bloccata in unostato intermedio da almeno una settimana. Lapplicazione deve anche fornire un riepilogo delle analisi eseguite e deiticket usati ltrati per contratto. Tale riepilogo come requisito aggiuntivo,oltre ad essere accessibile tramite interfaccia web, deve essere esportabile informato CSV per essere poi utilizzato come riepilogo consuntivo del contratto. 8
  15. 15. 1.6 Sicurezza Anche se è previsto che il sistema sia accessibile solamente da rete internaè stato richiesto di implementare un sistema di autenticazione delloperatoretramite il server di autenticazione aziendale. In modo da consentire laccessosolamente al gruppo di lavoro autorizzato e rendendo possibile lidenticazionedegli operatori che hanno eseguito alcune operazioni. Inoltre, principalmente a scopo didattico, si è dovuto prestare particolareattenzione ad eventuali problematiche di sicurezza applicative seguendo in fasedi realizzazione le best security practice per lo sviluppo in ambito web.1.7 Metodologia di sviluppo e tecnologie adot- tate La tecnica di sviluppo utilizzata, per questo ed altri progetti dellazienda, èlo sviluppo agile. Tale tecnica prevede una iterazione continua su brevi perioditemporali delle fasi di analisi, progettazione e sviluppo; confondendo di fattoi margini delle varie fasi. Lo sviluppo agile mette al centro linterazione conil committente ed eventualmente gli altri membri del team. Questa interazio-ne stretta porta spesso ad un cambiamento dei requisiti, e per cui si rendenecessario ridisegnare il modello dei dati, implementare qualche funzione nonprevista nellinterfaccia utente, modicare la logica applicativa. Questa strategia di sviluppo, per essere ecace, deve essere supportata daaltre tecniche come il Test Driven Development, che mette in risalto limpor-tanza di scrivere test dunità, integrazione e test di accettazione per ogni classeimplementata. Inoltre tale tecnica deve essere supportata anche da opportune tecnolo-gie. Si rende quindi necessaria uninfrastruttura di Continuous Integration perrilasciare le nuove versioni del progetto appena pronte. In modo da riceve-re immediatamente delle valutazioni sulle funzioni appena implementate. IlContinuous Integration è stato garantito tramite le seguenti tecnologie: • Mercurial, sistema di version control; 9
  16. 16. • Jenkins e Maven, per eseguire compilazioni e test in modo automatico; • Tamakoji, per mantenere un repository contenente i pacchetti da instal- lare sullambiente di test (o produzione). Figura 1.4: Schema struttura Continuous Integration. 5 Tamakoji è uno strumento per mantenere un repository YUM contenente 6pacchetti RPM sviluppato internamente derivato da Koji. 5 Yellowdog Updater, Modied è un sistema di gestione dei pacchetti compatibile con ipacchetti RPM 6 Red Hat Package Manager, pacchetto di installazione compatibile con la distribuzioneLinux Fedora e derivate 10
  17. 17. Capitolo 2Realizzazione A causa del metodo di sviluppo utilizzato, la fase di realizzazione non èrealmente separata dalle fasi di analisi e progettazione, infatti sia linterfacciagraca che limplementazione della logica applicativa si sono sviluppate mentrevenivano aggiunti o modicati i requisiti iniziali in base al prototipo fornito.2.1 Interfaccia utente Linterfaccia graca è stata implementata tramite il framework JavascriptExtJS. Grazie a questo framework è possibile creare interfacce complesse, lo-gicamente simili alle interfacce scritte tramite codice nativo. Tale frameworkrende disponibile in Javascript il concetto di classe, consentendo lereditarietàed uno stile di programmazione ad oggetti. Grazie allereditarietà fra clas-si, mette a disposizione la possibilità di estendere e personalizzare gli elementiprecongurati e - usando i container di basso livello - creare componenti propriaderenti alle proprie necessità. Il framework si occupa inoltre di mantenere leviste consistenti ad eventuali zoom da parte degli utenti e garantisce la stessarappresentazione su tutti i browser. Tra i componenti graci più utilizzati troviamo: • Grid, usato per la visualizzazione dei dati sotto forma di tabella; • Form, usato per linserimento dei dati e la modica. Il framework porta con se anche una serie di fogli di stile, personalizzabiliqualora si presenti la necessità. 11
  18. 18. Inoltre implementa componenti che si occupano dellinterazione client-serverche, consentono di acquisire informazioni dal server in formato JSON, e dielaborarle automaticamente per la corretta visualizzazione nel browser. Ta-li componenti sono principalmente reader e store. I primi si occupano diinterpretare in modo corretto la risposta JSON, mentre gli store rendono di-sponibili le informazioni agli altri componenti dopo averli, ad esempio, ordinatio convertiti in un formato più appropriato. Le richieste sono inviate al server tramite richieste AJAX, per non bloccarelinterfaccia mentre si attende una risposta. I componenti graci possono venircombinati insieme ai componenti di invio e ricezione per rendere dinamica lapagina. Per popolare una tabella cè bisogno almeno di: • uno store JSON; • un reader JSON; • la tabella dove visualizzare i dati ricevuti (grid). A meno di congurazioni particolarmente complesse, si può congurare ilreader allintero della dichiarazione dello store, per poi associarlo alla tabellache visualizzerà i dati presenti nello store mantenendo la vista aggiornata aduneventuale modica dei dati contenuti nello store. Usando questo framework i sorgenti delle pagine web non contengono quasiper nulla codice HTML, ma solo Javascript. Luso di ExtJS, come potenzialesvantaggio, porta ad una dichiarazione prolissa di ogni aspetto per tutti ipannelli fonte di facili errori. Ogni pop-up introdotto è una nestra modale, cioè disabilita il resto del-linterfaccia utente nché rimane attiva. Inoltre è stato richiesto di associare lascorciatoia da tastiera ESC per chiudere la nestra attiva più velocemente. Immediatamente dopo lautenticazione, si viene rediretti verso lhome pageda cui si può accedere a tutte le funzioni del progetto. 12
  19. 19. 2.1.1 Home Page Figura 2.1: Pagina principale. Questa pagina riassume tutte le situazioni dallarme e dinteresse sia perquestioni commerciali sia per questioni legate alle analisi eettuate. Nella partesuperiore sono elencate, raggruppate per cliente principale, tutte le ultimeanalisi di tutti i clienti, mettendone in risalto lo stato. Nella parte inferiore invece si possono eseguire delle interrogazioni che ri-guardano i contratti in scadenza, le analisi eseguite, e le analisi che sono inscadenza. Figura 2.2: Dettaglio contratti in scadenza. 13
  20. 20. Figura 2.3: Dettaglio analisi rimanenti. Figura 2.4: Dettaglio analisi in scadenza. In tutte le viste è stato introdotto nella parte inferiore uno slider, per unarapida modica del valore di soglia con cui eseguire la ricerca ed un selettorenumerico per aver maggior precisione. Eseguendo un doppio click sulle analisi di vulnerabilità presenti nella partesuperiore, si apre una nestra di dettaglio contenente tutte le informazionidisponibili per quella specica analisi. 14
  21. 21. Figura 2.5: Dettaglio analisi. Tramite il link in alto a sinistra si accede alla sezione di gestione anagraca,contrattuale e delle analisi.2.1.2 Pagina di gestione In questa pagina è concentrato tutto il contenuto informativo della basedati. È possibile aggiungere e modicare le informazioni di: • Cliente principale; • Cliente secondario; • Contratti; • Ticket di supporto; • Indirizzi IP; • Analisi; 15
  22. 22. • Documentazione (upload e download). Figura 2.6: Pagina di gestione. I pulsanti funzione appaiono disabilitati se non è possibile eseguire lo-perazione associata. Selezionando un cliente principale le tabelle secondarievengono popolate con le informazioni riguardanti i contratti e le informazioniriguardanti i clienti associati al cliente principale; sbloccando nel contempoanche la possibilità di aggiungerne di nuovi. Selezionando un contratto, o uncliente si attivano le restanti operazioni disponibili, spiegate successivamente. Eseguendo un doppio click su un cliente, sia principale che secondario, siapre un pop-up di dettaglio, dal quale è possibile modicare alcune informa-zioni; ad esempio si potrà modicare lindirizzo email o il numero di telefonoma non la denominazione sociale e la partita IVA. Selezionando un contratto è possibile: • gestire i ticket di supporto; • esportare in formato CSV i dati relativi al contratto. 16
  23. 23. Dalla nestra di dettaglio del ticket, è possibile aggiungere, eliminare emodicare tickets. Allatto di inserimento e modica il sistema registra chi haimmesso il ticket ai ni di una corretta fatturazione. Figura 2.7: Dettaglio Ticket. Selezionando un cliente si attivano le seguenti funzioni: • gestione indirizzi IP; • gestione analisi con relativa documentazione. La nestra di gestione degli indirizzi IP mostra la sequenza degli indirizziassociati al cliente con relativa data dimmissione e fornisce la possibilità diaggiungerne nuovi. 17
  24. 24. Figura 2.8: Dettaglio Indirizzi IP. Nella vista delle analisi è presente lo storico di tutte le analisi svolte daun dato cliente raggruppate per contratto. È messo in risalto lo stato di ognianalisi. Da questa vista è possibile con un doppio click modicare lo stato ealcuni dettagli dellanalisi. Figura 2.9: Dettaglio Analisi. Gli stati disponibili identicano vari momenti in cui unanalisi di vulne-rabilità può essere sospesa in attesa di unazione del cliente o del personaleinterno. Ad esempio lattesa di documentazione da parte del cliente, lattesadellautorizzazione a procedere o lanalisi è stata pianicata. 18
  25. 25. Ad ogni analisi dalla vista precedente si possono aggiungere un numeroarbitrario di documenti di qualsiasi dimensione, tali le una volta caricati sipotranno scaricare dallapposita vista con un semplice doppio click sulla rigacorrispondente. Figura 2.10: Download e upload dei le.2.1.3 Analisi Usabilità In generale lapplicazione è stata strutturata per richiedere meno di dieciclick per qualsiasi operazione. Di seguito vengono esposte alcune analisi diusabilità del sistema per alcuni i casi duso più frequenti.Visualizzazione situazioni dallarme Immediatamente dopo il log-in, nella pagina iniziale sono in evidenza leprincipali situazioni dallarme. Numero di click: da 0 a 2.Visualizzazione ultime analisi con relativo stato Immediatamente dopo il log-in, nella pagina iniziale sono le ultime analisidi tutti i clienti con relativo stato. Numero di click: 0 per la visualizzazione 2 per il dettaglio.Visualizzazione, inserimento, modica analisi Dalla home page è necessario andare nella pagina di gestione selezionareprima i cliente principale poi il cliente secondario ed inne aprire il dettagliodelle analisi. 19
  26. 26. Numero di click: 4 per la visualizzazione, 5 per linserimento, 6 per lamodica.Visualizzazione, inserimento, modica ticket supporto Dalla home page è necessario andare nella pagina di gestione selezionareprima i cliente principale poi il contratto associato ed inne aprire il dettagliodei ticket di supporto. Numero di click: 4 per la visualizzazione, 5 per linserimento, 6 per lamodica. 20
  27. 27. 2.2 Implementazione 1 Per rispettare il pattern architetturale MVC le entità sopra citate (sez. 21.3) sono state divise in packages e trascritte come dei POJO . Per ogni classe 3così creata si è reso necessario creare delle classi accessorie chiamate DTO chesono gli unici oggetti abilitati a valicare i conni tra Model-View-Controller.Il design pattern adottato si può immaginare come un grattacielo dove il livellopiù basso è a contatto con il modello dei dati mentre il più alto è a contattocon loperatore. Ogni livello può interagire solo con il livello immediatamentesopra e sotto. Ogni livello non deve conoscere limplementazione dei livelli alui vicini, ma solo linterfaccia dei metodi esposti, ed inoltre deve ignorarelesistenza dei livelli più distanti. Rispettando queste regole si potrà cambia-re limplementazione di un qualsiasi livello, o parte di esso, senza intaccareloperatività degli altri livelli. Inoltre il progetto, nel rispetto del pattern MVC, è stato suddiviso in trepackages principali: • core, suddiviso a sua volta in packages contenenti le entità, raggruppa tutta la logica applicativa; • web, raggruppa i controller e classi di supporto per la gestione dellinter- faccia utente; • mail, raggruppa le classi necessarie a comporre e spedire le email di notica. Per limplementazione è stato usato il framework per applicazioni aziendaliSpring. Questo framework fornisce molti moduli importabili separatamentesecondo le esigenze di progetto. Tra questi troviamo: • Spring Web MVC, fornisce strumenti per facilitare la corretta implemen- tazione del pattern MVC; 1 Model View Controller 2 Plain Old Java Object, cioè che non implementa nessuna interfaccia del framework 3 Data Transfer Object 21
  28. 28. • Spring Security, fornisce strumenti per lautenticazione e autorizzazione dellutente; • Spring Data, fornisce strumenti per la gestione di basi di dati. Ad ogni macro modulo si possono aggiungere dei moduli specializzati, co-me un modulo specico per MongoDB. Similmente esistono specializzazioniche aiutano nella congurazione della sicurezza e consentono di usare diversiprotocolli per lautenticazione. Spring fornisce la possibilità di iniettare i parametri dei costruttori del-le classi tramite appositi les di congurazione. Allinterno di questi les sidichiarano dei bean che rappresentano listanza della classe creata tramiteSpring. È possibile iniettare i bean deniti in altri bean, creando una catenadi dipendenze. Questa caratteristica risulta particolarmente utile quando sirende necessario cambiare implementazione di una classe slegando, di fatto, laclasse utilizzatrice da una precisa implementazione della classe utilizzata. Tramite luso di apposite annotazioni è possibile far eseguire liniezioneautomatica delle dipendenze al framework in modo da diminuire la lunghezzadel le di congurazione; liniezione automatica cerca tra tutti i beans denitiil bean di tipo compatibile con il parametro del costruttore annotato. Questacaratteristica è stata largamente usata nella parte web dellapplicazione, si èusato un approccio misto nella parte mail e totalmente dichiarativo nel packagecore preferendo un maggior controllo.2.2.1 Gerarchia delle classi Linterazione tra i vari packages e componenti esterni può essere schema-tizzata: 22
  29. 29. Figura 2.11: Interazione tra i packages. Nello schema si nota la divisione dei compiti secondo il pattern architettu-rale MVC tra i packages principali. Dove il package core contiene il livellobasso dellarchitettura MVC. I packages web e mail sono allo stesso livelloed entrambi usano le funzionalità messe a disposizione dal core. La struttura delle classi del packages core può essere espressa con il se-guente schema, dove vengono tralasciate le interfacce e viene presentata solounimplementazione delle varie classi. 23
  30. 30. Figura 2.12: Classi appartenenti al package core. 24
  31. 31. Per il corretto funzionamento le classi di Facade dipendono da uno o piùclassi Repository mentre esse dipendono solo dal DBMS scelto. Di seguito sono riportate le dipendenze delle Facade nei confronti dei Re-pository: • AnalysisFacade AnalysisRepository ContractRepository CustomerRepository MasterCustomerRepository SupportTicketRepository • CustomerFacade CustomerRepository MasterCustomerRepository • ContractFacade ContractRepository AnalysisRepository MasterCustomerRepository SupportTicketRepository • SupportTicketFacade SupportTicketRepository • MasterCustomerFacade MasterCustomerRepository • IpPoolFacade IpPoolRepository 25
  32. 32. • DocumentFacade DocumentRepository Il package web ha al suo interno delle classi chiamate Controller che,tramite il framework Spring e le sue servlet, collega ad URL specici dei metodiche verranno eseguiti quando verrà eettuata una richiesta allURL. Inoltre haal suo interno classi di supporto per lesportazione in formato CSV dei dati eper lintegrazione con il framework ExtJS. Il package mail contiene le classi necessarie a compilare ed inviare ad unamailing list delle e-mail contenenti le situazioni dallarme.2.2.2 Package core Questo package comprende al suo interno tutte le classi che implementano: • la logica applicativa; • la denizione della struttura degli oggetti da persistere; • il collegamento con la base dati. I repository fanno parte del livello più basso dellastrazione MVC. Imple-mentano il collegamento tra applicazione e la base dati. Ricevono dal livello su-periore dei DTO e li convertono in oggetti da salvare, estraggono dal databasei dati richiesti e il restituiscono al livello superiore. Per la loro implementazione si è deciso di procedere inizialmente con lacreazione di repository residenti in memoria usando strutture dati come liste e 4mappe di oggetti. Sono stati aggiunti metodi per eseguire le operazioni CRUDoltre a dei metodi specici per eseguire delle query prestabilite. Questaimplementazione è servita solo a rendere il prototipo più completo e consentirela scrittura di test di unità, che sono serviti a stipulare un contratto sulleoperazioni consentite e come comportarsi con operazioni non concesse. Inoltrequesto tipo di implementazione serve esclusivamente per lo sviluppo delle prime 4 Create Read Update Delete 26
  33. 33. versioni del prototipo iniziale perché poco soggetta al cambio della strutturadelle entità che si vuole salvare. Una volta scelto MongoDB come DBMS da usare si è proceduto ad imple-mentare tutte le interfacce dei repository per luso del DBMS. È stato decisodi usare il mapper di oggetti per MongoDB del framework Spring. In questomodo il mapper, in associazione al driver per MongoDB, si occupa di salvarelentità desiderata in una collezione con il nome dellentità. Se questa collezio-ne non è presente verrà creata dinamicamente. Per concludere il salvataggiologgetto viene mappato estraendo ogni sua proprietà e salvandola come: {Property : Value}aggiungendo un campo contenente il nome di classe completo del package diappartenenza. Se non presente viene anche aggiunto un campo id genera-to automaticamente da MongoDB. Ad esempio unanalisi memorizzata ha laseguente struttura: { _id : ObjectId(50ffad82991ad77dc97025a3), _class : net.emaze.pci.core.analysis.Analysis, dateInMillis : NumberLong(1333013378360), contractId : 1, customerId : 50ffad82991ad77dc970259c, ipPool : { addresses : [ 192.168.1.1, localhost ], dateInMillis : NumberLong(1333013378360), customerId : 50ffad82991ad77dc970259c }, result : stOK, note : analysis note } Una volta implementate le operazioni CRUD, si è proceduto ad implemen-tare anche i metodi specici per eseguire delle interrogazioni più complesse allabase dati. Per questo passaggio sono stati fondamentali i test di unità scrittiprecedentemente per i repository in memoria, facendo in modo di garantireche le due implementazioni della interfaccia di repository risultassero del tuttoconfondibili dagli altri moduli software. Le facade sono posizionate ad un livello intermedio che si pone tra il livellodei controller ed i repository. Queste classi implementano gran parte della 27
  34. 34. logica applicativa sgravando il livello dei controller dallimplementazione dellalogica più complessa, come linterrogazione di più repository per la compila-zione di un report. Se non sono previste operazioni particolari, questo livelloviene introdotto per coerenza e semplicemente richiamerà i metodi delle clas-si di livello inferiore restituendo i risultati al livello superiore. Questo livellosolitamente viene usato anche per le funzioni di log e auditing.2.2.3 Package web Questo package raccoglie al suo interno le classi responsabili di intercettarele richieste provenienti dalla GUI, comporre e inviare le risposte in un formatostandard. È stata usata la servlet DispatcherServlet, unimplementazione inclusanel framework Spring, specializzandola successivamente per gestire le richiestea: • pagine HTML e JSP; • risorse JSON. Per la specializzazione della servlet che gestisce le richieste a pagine conestensione htm si è deciso di usare un InternalResourceViewResolver chesi occupa, tramite un opportuno controller, di restituire una specica paginaJSP. La congurazione di questa specializzazione risulta: bean id=viewResolver class= org.springframework.web.servlet.view. InternalResourceViewResolver property name=prefix value=/WEB-INF/views// property name=suffix value=.jsp/ /beanUn controller associato risulta: @RequestMapping(value = home.htm, method = RequestMethod.GET) public ModelAndView showHomePage(MapString, Object model) { return new ModelAndView(home, model); } 28
  35. 35. così facendo ad ogni richiesta a ./home.htm la servlet si occupa di ricercare lapagina ./WEB-INF/views/home.jsp e restituirla al browser. Similmente è stata congurata la specializzazione della servlet che è re-sponsabile di soddisfare le richieste in formato JSON. Per tale specializzazioneè stata usata la classe MappingJacksonJsonView che si occupa di serializza-re in formato JSON il valore di ritorno dei metodi presenti nei controller percostruire la risposta. A questa servlet sono associati svariati controller più complessi, rispettoai precedenti. Ad esempio, il controller per la memorizzazione di una nuovaanalisi risulta: @RequestMapping(value = storeAnalysis.json, method = RequestMethod.POST) @ResponseBody public ExtjsJsonBuilderExtjsJsonStringBuilder storeAnalysis( @RequestParam(dateInMillis) long dateInMillis, @RequestParam(result) String result, @RequestParam(contractId) String contractId, @RequestParam(customerId) String customerId, @RequestParam(note) String note) { try { final IpPool ipPool = ipPoolFacade.loadLastIpPoolOfCustomerId( customerId ); analysisFacade.storeAnalysis( new RequestAnalysis(dateInMillis, contractId, customerId, ipPool, result, note) ); return ExtjsJsonBuilder.successMessage( Analisi memorizzata con successo); } catch (Exception e) { logger.error( Errore durante il salvataggio di unanalisi,e); return ExtjsJsonBuilder.failMessage( Memorizzazione analisi fallita + e.getMessage()); } }nel quale si nota luso massivo di annotazioni per eseguire la mappatura traparametri della richiesta e parametri del metodo, e luso di una classe di sup-porto per la costruzione di una risposta JSON in un formato compatibile conil framework ExtJS. 29
  36. 36. Tale classe di supporto si è resa necessaria in quanto il framework ExtJSrichiede che le risposte in formato JSON abbiano un campo booleano cheidentica se la risposta è stata generata in modo corretta o è frutto di unerrore.2.2.4 Avvisi mail Le mail vengono inviate tramite protocollo SMTP gestito attraverso Java-Mail e Spring. Vengono inviate ad una mailing list predenita usando un template perogni situazione dallarme in modo da avvisare gli operatori interni. Si è scelto di noticare le seguenti situazioni ritenute rilevanti: • Analisi in scadenza; • Limite di analisi quasi raggiunto; • Contratti in scadenza; • Analisi bloccate in uno stato intermedio. Per la schedulazione dellinvio delle mail di avviso poteva essere eseguitain due modi: • schedulazione tramite cron; • schedulazione interna ad Apache-Tomcat. Si è scelta la seconda opzione in quanto la schedulazione attraverso cronavrebbe richiesto la divisione del progetto in due o più sotto progetti, e sche-dulare lavvio di uno di questi a periodi pressati attraverso la modica diun le di congurazione del sistema operativo. Ciò avrebbe reso linvio delleemail immune da uneventuale interruzione di Apache, ma è stata valutatauna bassa criticità a fronte dellinserimento di una maggiore complessità nelprogetto. La schedulazione tramite Apache-Tomcat può essere programmatain svariati modi. Si è deciso di implementarla usando Spring-Task, che oltread una riga nel le di congurazione 30
  37. 37. task:annotation-driven /e lannotazione del metodo da schedulare @Scheduled(cron = 0 0 0 * * ?) public void scheduledMethod() {...}non richiede altre operazioni.2.2.5 Sicurezza Per gestire lautenticazione si è deciso di usare Spring-Security, che forniscetramite le di congurazione le funzionalità di autenticazione e autorizzazionecon svariati metodi. Si è deciso di congurare opportunamente questo modulo per luso del ser- 5ver LDAP interno per fare in modo che gli utenti registrati nella rete possanoaccedervi senza ulteriori registrazioni. In questo modo un utente non autenti-cato, che cerca di accedere, viene rediretto ad un semplice form dautenticazio-ne. Il sistema delega la verica delle credenziali al server remoto. È possibileinoltre limitare lautorizzazione delluso del sistema ad un gruppo ristretto diutenti, tramite la creazione di un gruppo di lavoro sul server LDAP. 5 Lightweight Directory Access Protocol 31
  38. 38. Figura 2.13: Processo di autorizzazione. 32
  39. 39. 2.3 Test 6 Un tassello molto importante della tecnica di sviluppo adottata è il TDD .Per la scrittura e lesecuzione dei test è stato usato il framework JUnit. Sonostati scritti principalmente tre tipi di test: • test unitari; • test di integrazione; • test di accettazione. I test scritti tramite JUnit si possono generalmente suddividere in tre fasi: 1. precondizioni; 2. operazioni; 3. asserzione. Nella prima fase si creano tutte le condizioni necessarie anché si possaeseguire il test. In questa fase si istanziano classi, si riempiono liste, mappe etabelle, anche con dati errati o non validi per testare se un determinato metodoin situazioni che potrebbero causare un arresto imprevisto dellapplicazione.Può essere eseguita anche al di fuori del metodo di test se le operazioni diinizializzazione risultano particolarmente onerose, come la connessione ad undatabase. Nella seconda fase si testano le singole operazioni. Se possibile allinternodi un test si dovranno usare solo operazioni già testate o facenti parte diframework o delle API Java in quanto queste operazioni sono già largamentetestate ed il comportamento previsto è descritto nella documentazione. Nella terza ed ultima fase si confronta il risultato delloperazione con ilrisultato previsto. Questa fase può avvenire sia se loperazione da testarefallisce lanciando uneccezione sia confrontando lo stato precedente e quellosuccessivo o il valore di ritorno delloperazione. 6 Test Driven Development 33
  40. 40. I test unitari servono a testare le funzionalità di una classe. Per dimostrareche la classe in esame è conforme alle speciche è necessario che superi consuccesso tutti i test. Per ogni metodo di ogni classe scritta, soprattutto per le classi della partecore, sono stati scritti uno o più test per certicarne il comportamento. Visto che molte classi utilizzano il concetto di tempo si è reso necessariocreare due implementazioni di un interfaccia Clock, una che restituisce il tempoin millisecondi del sistema, usata nella versione reale del sistema, laltra invecegestibile per poter testare il passare del tempo nel sistema. I test dunità sullimplementazione in memoria delle classi di repositorysono serviti anche a dimostrare che le implementazioni speciche per MongoDBavessero lo stesso comportamento prima di procedere al cambio. Ad esempio: Per testare il repository in memoria: @Test public void canStoreACustomer() { HashMapString, Customer map = new HashMapString, Customer(); InMemoryCustomerRepository inMemoryCustomerRepository = new InMemoryCustomerRepository(map); inMemoryCustomerRepository. storeCustomer(NEW_CUSTOMER); Assert.assertEquals(1, map.values().size()); } Per il repository che fa uso del DBMS MongoDB: @Test public void canStoreACustomer() { repository.storeCustomer(NEW_CUSTOMER); Assert.assertEquals(1, mongoOperations.findAll(Customer.class).size()); }Similmente le due implementazioni dovranno lanciare le stesse eccezioni a causadegli stessi eventi. Per testare il repository in memoria: 34
  41. 41. @Test(expected = IllegalArgumentException.class) public void storingNullCustomerThrows() { HashMapString, Customer map = new HashMapString, Customer(); InMemoryCustomerRepository inMemoryCustomerRepository = new InMemoryCustomerRepository(map); inMemoryCustomerRepository.storeCustomer(null); } Per il repository che fa uso del DBMS MongoDB: @Test(expected = IllegalArgumentException.class) public void storingNullCustomerThrows() { repository.storeCustomer(null); } I test di integrazione vericano la corretta interazione tra più classi. Itest eseguiti sulle classi di facade, e sulle classi del package mail, si possonoraggruppare sotto questa categoria. Come descritto nella sezione 2.2.1 ogni classe di facade ha uno o più repo-sitory da cui dipende. Da questo fatto si è reso necessario, per eseguire i test,introdurre delle implementazioni semplicate dei repository. Queste implemen-tazioni che simulano il componente reale si chiamano mock implementandosolo alcuni metodi e anchessi con una logica estremamente semplicata. Ad esempio le implementazioni mock dei repository restituiscono un ele-mento predenito invece di memorizzare gli elementi dallesterno, oppure han-no della logica comandabile dallesterno come: @Override public CollectionContract loadExpiringContracts(long deadlineInMillis) { if (expiring) { return Collections.singletonList(contract); } else { return Collections.ContractemptyList(); } } public void setExpiring(boolean expiring) { this.expiring = expiring; }in cui è possibile decidere dalla classe di test se il contratto è in scadenzaoppure no. 35
  42. 42. I test di accettazione simulano alcuni requisiti forniti dal cliente per dimo-strare che i requisiti sono stati capiti e soddisfatti. Questultimi sono dei test abbastanza complessi, perché un test di accetta-zione deve dimostrare che la logica del backend per operazioni complesse è statascritta in modo da soddisfare i requisiti, senza alcun riferimento allinterfacciagraca. Per fare ciò si testano molte classi nello stesso momento e si verica se ilsistema risponde nel modo desiderato. Ad esempio se si vuole vericare se ilsistema restituisce le analisi in scadenza sarà necessario inserire: • uno o più clienti principali; • uno o più clienti secondari; • almeno un contratto; • degli indirizzi IP; • almeno una analisi.inne spostando il fronte temporale vericare se il sistema restituisce eetti-vamente lanalisi, o le analisi, in scadenza. 36
  43. 43. Capitolo 3Conclusioni3.1 Obiettivi e sviluppi futuri Tutti gli obiettivi principali per la messa in produzione del sistema sonostati raggiunti, consentendo ad Emaze di poter sfruttare il sistema per segui-re in modo più preciso il workow PCI-DSS, mettendo a disposizione deglioperatori un sistema di gestione delle analisi e dei clienti centralizzato. Come sviluppi futuri il sistema potrebbe: • avviare automaticamente le analisi pianicate tramite il software azien- dale ipLegion; • inviare ai clienti e-mail automatiche di notica compilate tramite oppor- tuni template; • controllare in modo semi-automatico il report di unanalisi per determi- nare se si è stata completata con un successo od un insuccesso; • inviare ai clienti, dopo una revisione, i documenti che attestano lesito dellanalisi; • guidare loperatore in modo più rigido attraverso le fasi delle analisi; • collegare, se possibile, il sistema al software gestionale SAP usato in azienda per la rendicontazione automatica del lavoro svolto. 37
  44. 44. 3.2 Lavoro svolto Sono state scritte complessivamente più di 8500 linee di codice e congu-razione suddivise in: • 2200 codice Javascript; • 3400 codice Java, per un totale di 82 classi suddivise in 12 packages; • 2300 codice per il test delle varie classi. Sul sistema di Continuous Integration sono state eseguite più di 60 buildautomatiche con più di 200 commit nel sistema di Version Control. Al momento della stesura della tesi, sono state applicati alcuni bug xminori ed il portale viene messo in produzione allinterno della intranet diEmaze.3.3 Valutazioni personali Personalmente sono soddisfatto del lavoro svolto che mi ha permesso diacquisire capacità e conoscenze, di confrontarmi con un ambiente lavorativo dilivello avanzato. Mi ha permesso di acquisire nozioni di medio-alto livello su diversi fra-mework utilizzati comunemente per la creazione di applicazioni enterprise. 38
  45. 45. Capitolo 4Bibliograa 1. Head First Design Patterns, Eric Freeman Elisabeth Freeman, OReilly Media 2. Spring in action, Craig Walls, Manning Pubblications Co. terza edizione 3. MongoDB in action, Kyle Banker, Manning Pubblications Co. terza edizione 4. Sito e documentazione Spring http://www.springsource.org/ (a) Pacchetto base http://www.springsource.org/spring-framework i. Spring MVC http://static.springsource.org/spring/docs/3.1.x/ spring-framework-reference/html/mvc.html (b) Mapper e driver MongoDB http://www.springsource.org/spring-data/mongodb (c) Autenticazione http://www.springsource.org/spring-security i. Autenticazione tramite LDAP http://static.springsource.org/spring-security/ site/docs/3.1.x/reference/ldap.html 5. Sito ExtJS http://www.sencha.com/products/extjs 39
  46. 46. (a) API della specica versione utilizzata http://docs.sencha.com/ext-js/4-1/#!/api6. Sito MongoDB http://www.mongodb.org/7. Sito PCI-DSS https://www.pcisecuritystandards.org/security_standards/ 40
  47. 47. Ringraziamenti Il primo ringraziamento va ai miei genitori, nanziatori unici di questoperiodo universitario. A Cinzia la mia ragione di vita. Un ringraziamento particolare va a Davide fonte di innita conoscenza, cheha saputo guidarmi in questa avventura. Inne ringrazio tutti i miei amici che mi hanno pazientemente sopportatoin tutti questi anni. 41

×