Università degli Studi di Trieste

Facoltà di Ingegneria

Tesi di Laurea Magistrale in

INGEGNERIA INFORMATICA

ANALISI 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

Indice

Introduzione iv

Contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

Obiettivi e vincoli progettuali . . . . . . . . . . . . . . . . . . . . . . iv

Risultato e fasi del lavoro . . . . . . . . . . . . . . . . . . . . . . . . v

Articolazione della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . v

1 Analisi e progettazione 1

1.1 Problema e situazione preesistente . . . . . . . . . . . . . . . . . 1

1.2 Work�ow PCI-DSS . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 De�nizione 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 . . . . . . . . . . 9

2 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

2.2.5 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3 Conclusioni 37

3.1 Obiettivi e sviluppi futuri . . . . . . . . . . . . . . . . . . . . . 37

3.2 Lavoro svolto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3 Valutazioni personali . . . . . . . . . . . . . . . . . . . . . . . . 38

4 Bibliogra�a 39

Ringraziamenti 41

iii

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 un'orga-

nizzazione chiamata PCI1 che ha formulato uno standard (DSS2).

L'Ente responsabile degli standard di protezione PCI è un forum

globale aperto dedicato allo sviluppo, al miglioramento, alla memo-

rizzazione, alla distribuzione e all'implementazione degli standard

di sicurezza per la protezione dei dati degli account. La missio-

ne dell'Ente 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 standard

PCI DSS. Uno dei requisiti richiesti è l'analisi di Vulnerability Assessment sulla

propria infrastruttura pubblica da parte di una società certi�cata PCI ASV3.

Questo standard oltre a �ssare i limiti per il rilascio della certi�cazione delinea

un work�ow che il certi�catore è tenuto a seguire. Il progetto è stato avviato

in previsione di una espansione della domanda di tale certi�cazione.

Obiettivi e vincoli progettuali

L'obiettivo è di costruire uno strumento che faciliti gli operatori a seguire il

�usso imposto dallo standard, con particolare attenzione anche ai fattori com-

1Payment Card Industry2Data Security Standard3Approved Scanning Vendor

iv

merciali delle analisi. Inoltre dovrà inviare resoconti giornalieri agli operatori

sulle situazioni di allarme, gestire contratti, ticket di supporto al cliente, ana-

gra�ca dei clienti, gestione documentale e lo stato di ogni analisi e�ettuata.

Si è scelto di sviluppare un'applicazione web, accessibile solamente dalla rete

privata aziendale. Per la realizzazione sono state usate le seguenti tecnologie:

• Java;

• Spring, un framework con molte funzioni, in particolare è stato usato per

la gestione del pattern architetturale MVC4;

• ExtJS, un framework per la creazione di pagine web e l'interazione 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 generale

delle tecnologie impiegate. Successivamente si è iniziato ad implementare i

vari aspetti seguendo i principi dello sviluppo �agile�, rivedendo più volte la

struttura logica e �sica del progetto tramite prototipi, �no all'ottenimento del

risultato voluto. Il lavoro risultante è un portale web che permette la gestione

degli aspetti sopra citati.

Articolazione della tesi

Di seguito, un breve riepilogo dei contenuti presenti nei capitoli:

1. Si analizza il problema de�nendo i requisiti e le caratteristiche che do-

vranno essere implementate;

4Model View Controller è un design pattern che divide in modo rigido i compiti dellevarie classi all'interno di un'applicazione web

v

2. Si descrive l'interfaccia utente realizzata e l'implementazione della logica

del sistema;

3. Si delineano le conclusioni sul lavoro svolto e possibili sviluppi futuri;

4. Si espongono i riferimenti bibliogra�ci e le fonti utilizzate.

vi

Capitolo 1

Analisi e progettazione

1.1 Problema e situazione preesistente

In previsione di un aumento della domanda delle certi�cazioni PCI-DSS, si

è scelto di creare uno strumento atto alla gestione:

• delle analisi e�ettuate;

• della relativa documentazione, upload e download dei documenti;

• dell'anagra�ca del cliente;

• della situazione contrattuale.

Si è scelto di avviare un progetto completamente nuovo perché non era

presente alcuna piattaforma simile da poter usare come base di partenza. Pre-

cedentemente per la gestione dei dati sopra citati, a causa dell'esiguo numero

di clienti, veniva usato un foglio di calcolo per ogni cliente contenente tutte le

informazioni. All'aumentare dei clienti e delle analisi l'uso di fogli di calcolo

risulta poco agevole, in quanto introduce problemi di allineamento dei dati tra

le copie locali dei fogli.

1.2 Work�ow PCI-DSS

Lo standard PCI-DSS per il corretto svolgimento dell'attività di analisi di

vulnerabilità impone all'ASV1 di seguire il seguente work�ow.

1Approved Scanning Vendor

1

Figura 1.1: Work�ow PCI-DSS.

Questo work�ow descrive le fasi e le interazioni che devono avvenire tra l'a-

zienda che esegue l'analisi e quella che l'ha commissionato. Lo schema è diviso

in due zone per gli obblighi di ogni attore. Delinea anche i comportamenti da

adottare 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 un

blocco, momentaneo, della procedura di analisi.

Prima dell'analisi delle vulnerabilità si procede ad una veri�ca degli indiriz-

zi IP forniti, e qualora si rilevino altri indirizzi IP pubblici collegati ai domini

sotto analisi si rende necessario decidere insieme al cliente se inserirli nella

analisi da e�ettuare.

Una volta individuati tutti gli IP da testare e ricevuta l'autorizzazione a

procedere, viene eseguita l'analisi di vulnerabilità tramite ipLegion2. Ogni2un software sviluppato internamente dalla Emaze per il controllo automatizzato delle

vulnerabilità

2

vulnerabilità è classi�cata con un livello di rischio che va da zero a dieci. Il

cliente viene considerato protetto se vengono individuate solo vulnerabilità di

grado da 0 a 3,9.

Nel caso in cui l'analisi termini con un fallimento inizia un confronto tra

ASV e cliente in modo da accertare eventuali falsi positivi. Una volta esclusi

gli eventuali falsi positivi se rimangono vulnerabilità di grado maggiore a 4

l'analisi risulta a tutti gli e�etti fallita. Per ottenere la certi�cazione il cliente

dovrà applicare i suggerimenti consigliati all'interno del report dell'attività e

richiedere una nuova analisi.

1.3 De�nizione delle entità

Il sistema deve poter gestire il dettaglio dei clienti con associati i relativi:

indirizzi IP, analisi e�ettuate e contratti stipulati. Inoltre deve mantenere lo

storico di queste entità.

Per il soddisfacimento di tali requisiti di gestione anagra�ca e documen-

tale sono state individuate quattro entità separate per modellare gli aspetti

essenziali.

Le entità individuate, con relativi attributi, sono:

• Analisi (data di esecuzione, contratto associato, indirizzi IP in esame,

risultato);

• Contratti (massimo numero di analisi e�ettuabili, inizio validità contrat-

to, �ne validità contratto, cliente associato);

• Clienti (anagra�ca varia);

• Indirizzi IP (indirizzi IP, data di inserimento nel sistema, contratto as-

sociato).

3

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 il

modello dello sviluppo agile si è reso necessario rimodellare le entità fonda-

mentali cambiando struttura a quelle già presenti, aggiungendone delle altre

e modi�candone le relazioni tra esse. Da tale confronto è anche emerso un

caso d'uso 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 d'uso

modi�ca il rapporto di parentela tra tutte le entità �no ad ora individuate e

risulta mancante un'entità che rappresenti il cliente principale. Si è inoltre

deciso di aggiungere un'entità che rappresenti i ticket di assistenza forniti ai

clienti in modo da tracciare anche questo aspetto delle analisi per una corretta

rendicontazione. Inoltre per questioni pratiche è stato inserito un campo note.

Le nuove entità identi�cate sono:

• Analisi (data di esecuzione, contratto associato, cliente �slave� associato,

indirizzi IP in esame, risultato, note);

• Contratti (numero massimo di analisi e�ettuabili, numero massimo di tic-

ket di assistenza usabili, inizio validità contratto, �ne validità contratto,

cliente �master� associato);

• Clienti �slave� (anagra�ca varia, cliente �master� associato, note);

4

• Clienti �master� (anagra�ca 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 de�nitivo delle entità.

Questo schema rappresenta le entità che e�ettivamente formano la base

dati del sistema.

1.4 Scelta DBMS

La scelta si poneva tra un database relazionale come PostGreSQL, ed uno

non relazionale orientato ai documenti come MongoDB. Si è deciso di usare

5

quest'ultimo per sfruttare la possibilità di salvare �les in modo nativo al suo

interno.

Questo particolare DBMS non richiede la de�nizione di tabelle e relazioni

prima di poterlo usare, e conseguentemente, non si de�niscono i tipi di dato

che dovrà contenere. Quindi non necessita di una progettazione vera e propria

in quanto, all'atto di salvare un'entità, il driver si prenderà l'onere � ove non

sia già presente � di creare una collezione, simile al concetto di tabella dei

database relazionali, in cui salvare l'entità stessa. All'interno di tale collezione

verranno salvate tutte le entità dello stesso tipo codi�cate in BSON3, per motivi

prestazionali.

MongoDB permette di salvare anche entità con struttura diversa all'interno

della stessa collezione. Ad esempio se dalla shell di amministrazione si eseguono

i 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 attributo

in più. Da questo esempio si può notare la struttura simile al formato JSON

e l'aggiunta di un ID univoco generato automaticamente. La possibilità di

salvare entità con struttura diversa, risulta molto utile per la memorizzazione

di entità complesse che al loro interno includono altre entità. Inoltre MongoDB

permette di e�ettuare backup senza interrompere l'attività, in aggiunta qualora

si renda necessario, gestisce automaticamente la replica su più nodi così da

aumentare la sicurezza dei dati.

Di contro MongoDB non implementa il concetto di transazione come i

DBMS relazionali, preferendo il salvataggio di intere entità. Non implementa

nessun concetto di relazione, quindi è esclusa la possibilità di far eseguire in

modo automatico delle query di join, ma qualora sia possibile, è da preferire

3formato JSON binario

6

una denormalizzazione salvando un unico documento con all'interno tutte le

informazioni ad esso collegate.

Tale denormalizzazione è stata e�ettuata sull'entità delle analisi che inglo-

ba l'entità degli indirizzi IP così da salvarne esattamente lo stato in un dato

istante. Se non fosse possibile eseguire questa denormalizzazione risulta neces-

sario eseguire più interrogazioni per reperire tutte le informazioni. Per questi

motivi, se si è costretti a gestire più collezioni, il database potrebbe perdere di

consistenza 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 in

quanto sono:

• autorizzazioni a analizzare i sistemi;

• report dell'analisi di vulnerabilità;

• informative;

• altri documenti.

Si è deciso di implementare questa particolare funzionalità tramite codice

nativo dopo aver vagliato l'opportunità di usare un CMS4 come �Alfresco�,

scartato per l'elevata complessità necessaria per la gestione di un'operazione

così semplice. Per eseguire il salvataggio dei �le esistono sostanzialmente due

metodi:

• salvataggio nel File System;

• salvataggio nella base dati (MongoDB).

Inizialmente, prima di scegliere il DBMS da usare, il salvataggio avveniva

nel File System del server. Questo particolare approccio consente di accedere

4Content Management System

7

ai �le memorizzati tramite connessione remota alla cartella di salvataggio, ma

rende il backup dell'intero sistema più elaborato. Come accennato preceden-

temente la decisione di usare MongoDB come DBMS ha permesso di salvare

nativamente documenti all'interno del database tramite GridFS.

GridFS è una funzione di MongoDB che permette di salvare �le di di-

mensioni arbitrarie all'interno del database. Il salvataggio avviene in modo

automatico creando due collezioni �fs.�les� e �fs.chunks�; la prima collezione

contiene tutti i dati relativi alle informazioni sul �le quali: nome, dimensione,

l'hash MD5, data di caricamento, eventuali metadati accessori. La seconda

collezione contiene il �le vero e proprio serializzato e diviso in �pezzi� da 256

kB.

1.5 Avvisi, riepiloghi

Il sistema �nale deve mettere in evidenza le situazioni che richiedono l'at-

tenzione di un operatore come:

• contratti in scadenza;

• certi�cazioni 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 all'apertura del-

l'applicazione, sulla home page. Inoltre si è deciso di far compilare ed inviare

quotidianamente al sistema delle email automatiche ad una mailing list in-

terna. Oltre alle situazioni d'allarme precedentemente elencate, si è scelto di

inviare tramite mail un'ulteriore avviso che riguarda un'analisi bloccata in uno

stato intermedio da almeno una settimana.

L'applicazione deve anche fornire un riepilogo delle analisi eseguite e dei

ticket usati �ltrati per contratto. Tale riepilogo come requisito aggiuntivo,

oltre ad essere accessibile tramite interfaccia web, deve essere esportabile in

formato CSV per essere poi utilizzato come riepilogo consuntivo del contratto.

8

1.6 Sicurezza

Anche se è previsto che il sistema sia accessibile solamente da rete interna

è stato richiesto di implementare un sistema di autenticazione dell'operatore

tramite il server di autenticazione aziendale. In modo da consentire l'accesso

solamente al gruppo di lavoro autorizzato e rendendo possibile l'identi�cazione

degli operatori che hanno eseguito alcune operazioni.

Inoltre, principalmente a scopo didattico, si è dovuto prestare particolare

attenzione ad eventuali problematiche di sicurezza applicative seguendo in fase

di 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 dell'azienda, è

lo sviluppo agile. Tale tecnica prevede una iterazione continua su brevi periodi

temporali delle fasi di analisi, progettazione e sviluppo; confondendo di fatto

i margini delle varie fasi. Lo sviluppo agile mette al centro l'interazione con

il committente ed eventualmente gli altri membri del team. Questa interazio-

ne stretta porta spesso ad un cambiamento dei requisiti, e per cui si rende

necessario ridisegnare il modello dei dati, implementare qualche funzione non

prevista nell'interfaccia utente, modi�care la logica applicativa.

Questa strategia di sviluppo, per essere e�cace, deve essere supportata da

altre tecniche come il Test Driven Development, che mette in risalto l'impor-

tanza di scrivere test d'unità, integrazione e test di accettazione per ogni classe

implementata.

Inoltre tale tecnica deve essere supportata anche da opportune tecnolo-

gie. Si rende quindi necessaria un'infrastruttura di Continuous Integration per

rilasciare le nuove versioni del progetto appena pronte. In modo da riceve-

re immediatamente delle valutazioni sulle funzioni appena implementate. Il

Continuous Integration è stato garantito tramite le seguenti tecnologie:

• Mercurial, sistema di version control;

9

• Jenkins e Maven, per eseguire compilazioni e test in modo automatico;

• Tamakoji, per mantenere un repository contenente i pacchetti da instal-

lare sull'ambiente di test (o produzione).

Figura 1.4: Schema struttura Continuous Integration.

Tamakoji è uno strumento per mantenere un repository YUM5 contenente

pacchetti RPM6 sviluppato internamente derivato da Koji.

5Yellow dog Updater, Modi�ed è un sistema di gestione dei pacchetti compatibile con ipacchetti RPM

6Red Hat Package Manager, pacchetto di installazione compatibile con la distribuzioneLinux Fedora e derivate

10

Capitolo 2

Realizzazione

A causa del metodo di sviluppo utilizzato, la fase di realizzazione non è

realmente separata dalle fasi di analisi e progettazione, infatti sia l'interfaccia

gra�ca che l'implementazione della logica applicativa si sono sviluppate mentre

venivano aggiunti o modi�cati i requisiti iniziali in base al prototipo fornito.

2.1 Interfaccia utente

L'interfaccia gra�ca è stata implementata tramite il framework Javascript

ExtJS. Grazie a questo framework è possibile creare interfacce complesse, lo-

gicamente simili alle interfacce scritte tramite codice nativo. Tale framework

rende disponibile in Javascript il concetto di classe, consentendo l'ereditarietà

ed uno stile di programmazione ad oggetti. Grazie all'ereditarietà fra clas-

si, mette a disposizione la possibilità di estendere e personalizzare gli elementi

precon�gurati e - usando i container di basso livello - creare componenti propri

aderenti alle proprie necessità. Il framework si occupa inoltre di mantenere le

viste consistenti ad eventuali zoom da parte degli utenti e garantisce la stessa

rappresentazione su tutti i browser.

Tra i componenti gra�ci più utilizzati troviamo:

• Grid, usato per la visualizzazione dei dati sotto forma di tabella;

• Form, usato per l'inserimento dei dati e la modi�ca.

Il framework porta con se anche una serie di fogli di stile, personalizzabili

qualora si presenti la necessità.

11

Inoltre implementa componenti che si occupano dell'interazione client-server

che, consentono di acquisire informazioni dal server in formato JSON, e di

elaborarle automaticamente per la corretta visualizzazione nel browser. Ta-

li componenti sono principalmente reader e store. I primi si occupano di

interpretare in modo corretto la risposta JSON, mentre gli store rendono di-

sponibili le informazioni agli altri componenti dopo averli, ad esempio, ordinati

o convertiti in un formato più appropriato.

Le richieste sono inviate al server tramite richieste AJAX, per non bloccare

l'interfaccia mentre si attende una risposta. I componenti gra�ci possono venir

combinati insieme ai componenti di invio e ricezione per rendere dinamica la

pagina. 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 con�gurazioni particolarmente complesse, si può con�gurare il

reader all'intero della dichiarazione dello store, per poi associarlo alla tabella

che visualizzerà i dati presenti nello store mantenendo la vista aggiornata ad

un'eventuale modi�ca dei dati contenuti nello store.

Usando questo framework i sorgenti delle pagine web non contengono quasi

per nulla codice HTML, ma solo Javascript. L'uso di ExtJS, come potenziale

svantaggio, porta ad una dichiarazione prolissa di ogni aspetto per tutti i

pannelli fonte di facili errori.

Ogni pop-up introdotto è una �nestra modale, cioè disabilita il resto del-

l'interfaccia utente �nché rimane attiva. Inoltre è stato richiesto di associare la

scorciatoia da tastiera �ESC� per chiudere la �nestra attiva più velocemente.

Immediatamente dopo l'autenticazione, si viene rediretti verso l'home page

da cui si può accedere a tutte le funzioni del progetto.

12

2.1.1 Home Page

Figura 2.1: Pagina principale.

Questa pagina riassume tutte le situazioni d'allarme e d'interesse sia per

questioni commerciali sia per questioni legate alle analisi e�ettuate. Nella parte

superiore sono elencate, raggruppate per cliente principale, tutte le ultime

analisi 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 in

scadenza.

Figura 2.2: Dettaglio contratti in scadenza.

13

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 una

rapida modi�ca del valore di soglia con cui eseguire la ricerca ed un selettore

numerico per aver maggior precisione.

Eseguendo un doppio click sulle analisi di vulnerabilità presenti nella parte

superiore, si apre una �nestra di dettaglio contenente tutte le informazioni

disponibili per quella speci�ca analisi.

14

Figura 2.5: Dettaglio analisi.

Tramite il link in alto a sinistra si accede alla sezione di gestione anagra�ca,

contrattuale e delle analisi.

2.1.2 Pagina di gestione

In questa pagina è concentrato tutto il contenuto informativo della base

dati. È possibile aggiungere e modi�care le informazioni di:

• Cliente principale;

• Cliente secondario;

• Contratti;

• Ticket di supporto;

• Indirizzi IP;

• Analisi;

15

• Documentazione (upload e download).

Figura 2.6: Pagina di gestione.

I pulsanti funzione appaiono disabilitati se non è possibile eseguire l'o-

perazione associata. Selezionando un cliente principale le tabelle secondarie

vengono popolate con le informazioni riguardanti i contratti e le informazioni

riguardanti i clienti associati al cliente principale; sbloccando nel contempo

anche la possibilità di aggiungerne di nuovi. Selezionando un contratto, o un

cliente si attivano le restanti operazioni disponibili, spiegate successivamente.

Eseguendo un doppio click su un cliente, sia principale che secondario, si

apre un pop-up di dettaglio, dal quale è possibile modi�care alcune informa-

zioni; ad esempio si potrà modi�care l'indirizzo email o il numero di telefono

ma 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

Dalla �nestra di dettaglio del ticket, è possibile aggiungere, eliminare e

modi�care tickets. All'atto di inserimento e modi�ca il sistema registra chi ha

immesso 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 indirizzi

associati al cliente con relativa data d'immissione e fornisce la possibilità di

aggiungerne nuovi.

17

Figura 2.8: Dettaglio Indirizzi IP.

Nella vista delle analisi è presente lo storico di tutte le analisi svolte da

un dato cliente raggruppate per contratto. È messo in risalto lo stato di ogni

analisi. Da questa vista è possibile con un doppio click modi�care lo stato e

alcuni dettagli dell'analisi.

Figura 2.9: Dettaglio Analisi.

Gli stati disponibili identi�cano vari momenti in cui un'analisi di vulne-

rabilità può essere sospesa in attesa di un'azione del cliente o del personale

interno. Ad esempio l'attesa di documentazione da parte del cliente, l'attesa

dell'autorizzazione a procedere o l'analisi è stata piani�cata.

18

Ad ogni analisi dalla vista precedente si possono aggiungere un numero

arbitrario di documenti di qualsiasi dimensione, tali �le una volta caricati si

potranno scaricare dall'apposita vista con un semplice doppio click sulla riga

corrispondente.

Figura 2.10: Download e upload dei �le.

2.1.3 Analisi Usabilità

In generale l'applicazione è stata strutturata per richiedere meno di dieci

click per qualsiasi operazione. Di seguito vengono esposte alcune analisi di

usabilità del sistema per alcuni i casi d'uso più frequenti.

Visualizzazione situazioni d'allarme

Immediatamente dopo il log-in, nella pagina iniziale sono in evidenza le

principali situazioni d'allarme.

Numero di click: da 0 a 2.

Visualizzazione ultime analisi con relativo stato

Immediatamente dopo il log-in, nella pagina iniziale sono le ultime analisi

di tutti i clienti con relativo stato.

Numero di click: 0 per la visualizzazione 2 per il dettaglio.

Visualizzazione, inserimento, modi�ca analisi

Dalla home page è necessario andare nella pagina di gestione selezionare

prima i cliente principale poi il cliente secondario ed in�ne aprire il dettaglio

delle analisi.

19

Numero di click: 4 per la visualizzazione, 5 per l'inserimento, 6 per la

modi�ca.

Visualizzazione, inserimento, modi�ca ticket supporto

Dalla home page è necessario andare nella pagina di gestione selezionare

prima i cliente principale poi il contratto associato ed in�ne aprire il dettaglio

dei ticket di supporto.

Numero di click: 4 per la visualizzazione, 5 per l'inserimento, 6 per la

modi�ca.

20

2.2 Implementazione

Per rispettare il pattern architetturale MVC1 le entità sopra citate (sez.

1.3) sono state divise in packages e trascritte come dei POJO2. Per ogni classe

così creata si è reso necessario creare delle classi accessorie chiamate DTO3 che

sono gli unici oggetti �abilitati� a valicare i con�ni tra Model-View-Controller.

Il design pattern adottato si può immaginare come un grattacielo dove il livello

più basso è a contatto con il modello dei dati mentre il più alto è a contatto

con l'operatore. Ogni livello può interagire solo con il livello immediatamente

sopra e sotto. Ogni livello non deve conoscere l'implementazione dei livelli a

lui vicini, ma solo l'interfaccia dei metodi esposti, ed inoltre deve �ignorare�

l'esistenza dei livelli più distanti. Rispettando queste regole si potrà cambia-

re l'implementazione di un qualsiasi livello, o parte di esso, senza intaccare

l'operatività degli altri livelli.

Inoltre il progetto, nel rispetto del pattern MVC, è stato suddiviso in tre

packages 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 dell'inter-

faccia utente;

• mail, raggruppa le classi necessarie a comporre e spedire le email di

noti�ca.

Per l'implementazione è stato usato il framework per applicazioni aziendali

Spring. Questo framework fornisce molti moduli importabili separatamente

secondo le esigenze di progetto. Tra questi troviamo:

• Spring Web MVC, fornisce strumenti per facilitare la corretta implemen-

tazione del pattern MVC;

1Model View Controller2Plain Old Java Object, cioè che non implementa nessuna interfaccia del framework3Data Transfer Object

21

• Spring Security, fornisce strumenti per l'autenticazione e autorizzazione

dell'utente;

• 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 speci�co per MongoDB. Similmente esistono specializzazioni

che aiutano nella con�gurazione della sicurezza e consentono di usare diversi

protocolli per l'autenticazione.

Spring fornisce la possibilità di �iniettare� i parametri dei costruttori del-

le classi tramite appositi �les di con�gurazione. All'interno di questi �les si

dichiarano dei �bean� che rappresentano l'istanza della classe creata tramite

Spring. È possibile iniettare i bean de�niti in altri bean, creando una catena

di dipendenze. Questa caratteristica risulta particolarmente utile quando si

rende necessario cambiare implementazione di una classe slegando, di fatto, la

classe utilizzatrice da una precisa implementazione della classe utilizzata.

Tramite l'uso di apposite annotazioni è possibile far eseguire l'iniezione

automatica delle dipendenze al framework in modo da diminuire la lunghezza

del �le di con�gurazione; l'iniezione automatica cerca tra tutti i beans de�niti

il bean di tipo compatibile con il parametro del costruttore annotato. Questa

caratteristica è stata largamente usata nella parte web dell'applicazione, si è

usato un approccio misto nella parte mail e totalmente dichiarativo nel package

core preferendo un maggior controllo.

2.2.1 Gerarchia delle classi

L'interazione tra i vari packages e componenti esterni può essere schema-

tizzata:

22

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 livello

basso dell'architettura MVC. I packages �web� e �mail� sono allo stesso livello

ed 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 solo

un'implementazione delle varie classi.

23

Figura 2.12: Classi appartenenti al package core.

24

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

• 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 speci�ci dei metodi

che verranno eseguiti quando verrà e�ettuata una richiesta all'URL. Inoltre ha

al suo interno classi di supporto per l'esportazione in formato CSV dei dati e

per l'integrazione con il framework ExtJS.

Il package �mail� contiene le classi necessarie a compilare ed inviare ad una

mailing list delle e-mail contenenti le situazioni d'allarme.

2.2.2 Package �core�

Questo package comprende al suo interno tutte le classi che implementano:

• la logica applicativa;

• la de�nizione della struttura degli oggetti da persistere;

• il collegamento con la base dati.

I repository fanno parte del livello più basso dell'astrazione 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 database

i dati richiesti e il restituiscono al livello superiore.

Per la loro implementazione si è deciso di procedere inizialmente con la

creazione di repository residenti in memoria usando strutture dati come liste e

mappe di oggetti. Sono stati aggiunti metodi per eseguire le operazioni CRUD4

oltre a dei metodi speci�ci per eseguire delle �query� prestabilite. Questa

implementazione è servita solo a rendere il prototipo più completo e consentire

la scrittura di test di unità, che sono serviti a stipulare un �contratto� sulle

operazioni consentite e come comportarsi con operazioni non concesse. Inoltre

questo tipo di implementazione serve esclusivamente per lo sviluppo delle prime

4Create Read Update Delete

26

versioni del prototipo iniziale perché poco soggetta al cambio della struttura

delle entità che si vuole salvare.

Una volta scelto MongoDB come DBMS da usare si è proceduto ad imple-

mentare tutte le interfacce dei repository per l'uso del DBMS. È stato deciso

di usare il mapper di oggetti per MongoDB del framework Spring. In questo

modo il mapper, in associazione al driver per MongoDB, si occupa di salvare

l'entità desiderata in una collezione con il nome dell'entità. Se questa collezio-

ne non è presente verrà creata dinamicamente. Per concludere il salvataggio

l'oggetto viene mappato estraendo ogni sua proprietà e salvandola come:{Property : Value}

aggiungendo un campo contenente il nome di classe completo del package di

appartenenza. Se non presente viene anche aggiunto un campo id genera-

to automaticamente da MongoDB. Ad esempio un'analisi memorizzata ha la

seguente 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 speci�ci per eseguire delle interrogazioni più complesse alla

base dati. Per questo passaggio sono stati fondamentali i test di unità scritti

precedentemente per i repository in memoria, facendo in modo di garantire

che le due implementazioni della interfaccia di repository risultassero del tutto

confondibili dagli altri moduli software.

Le facade sono posizionate ad un livello intermedio che si pone tra il livello

dei controller ed i repository. Queste classi implementano gran parte della

27

logica applicativa sgravando il livello dei controller dall'implementazione della

logica più complessa, come l'interrogazione di più repository per la compila-

zione di un report. Se non sono previste operazioni particolari, questo livello

viene introdotto per coerenza e semplicemente richiamerà i metodi delle clas-

si di livello inferiore restituendo i risultati al livello superiore. Questo livello

solitamente 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 intercettare

le richieste provenienti dalla GUI, comporre e inviare le risposte in un formato

standard.

È stata usata la servlet DispatcherServlet, un'implementazione inclusa

nel framework Spring, specializzandola successivamente per gestire le richieste

a:

• pagine HTML e JSP;

• risorse JSON.

Per la specializzazione della servlet che gestisce le richieste a pagine con

estensione htm si è deciso di usare un InternalResourceViewResolver che

si occupa, tramite un opportuno controller, di restituire una speci�ca pagina

JSP.

La con�gurazione 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"/>

</bean>

Un controller associato risulta:

@RequestMapping(value = "home.htm",method = RequestMethod.GET)

public ModelAndView showHomePage(Map<String, Object> model){

return new ModelAndView("home", model);}

28

così facendo ad ogni richiesta a ./home.htm la servlet si occupa di ricercare la

pagina ./WEB-INF/views/home.jsp e restituirla al browser.

Similmente è stata con�gurata 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 per

costruire la risposta.

A questa servlet sono associati svariati controller più complessi, rispetto

ai precedenti. Ad esempio, il controller per la memorizzazione di una nuova

analisi risulta:

@RequestMapping(value = "storeAnalysis.json",method = RequestMethod.POST)

@ResponseBodypublic ExtjsJsonBuilder<ExtjsJsonStringBuilder>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 un\'analisi",e);return ExtjsJsonBuilder.failMessage("Memorizzazione analisi fallita "+ e.getMessage());

}}

nel quale si nota l'uso massivo di annotazioni per eseguire la mappatura tra

parametri della richiesta e parametri del metodo, e l'uso di una classe di sup-

porto per la costruzione di una risposta JSON in un formato compatibile con

il framework ExtJS.

29

Tale classe di supporto si è resa necessaria in quanto il framework ExtJS

richiede che le risposte in formato JSON abbiano un campo booleano che

identi�ca se la risposta è stata generata in modo corretta o è frutto di un

errore.

2.2.4 Avvisi mail

Le mail vengono inviate tramite protocollo SMTP gestito attraverso Java-

Mail e Spring.

Vengono inviate ad una mailing list prede�nita usando un template per

ogni situazione d'allarme in modo da avvisare gli operatori interni.

Si è scelto di noti�care 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 dell'invio delle mail di avviso poteva essere eseguita

in due modi:

• schedulazione tramite cron;

• schedulazione interna ad Apache-Tomcat.

Si è scelta la seconda opzione in quanto la schedulazione attraverso cron

avrebbe richiesto la divisione del progetto in due o più sotto progetti, e sche-

dulare l'avvio di uno di questi a periodi pre�ssati attraverso la modi�ca di

un �le di con�gurazione del sistema operativo. Ciò avrebbe reso l'invio delle

email immune da un'eventuale interruzione di Apache, ma è stata valutata

una bassa criticità a fronte dell'inserimento di una maggiore complessità nel

progetto. La schedulazione tramite Apache-Tomcat può essere programmata

in svariati modi. Si è deciso di implementarla usando Spring-Task, che oltre

ad una riga nel �le di con�gurazione

30

<task:annotation-driven />

e l'annotazione del metodo da schedulare

@Scheduled(cron = "0 0 0 * * ?")public void scheduledMethod() {...}

non richiede altre operazioni.

2.2.5 Sicurezza

Per gestire l'autenticazione si è deciso di usare Spring-Security, che fornisce

tramite �le di con�gurazione le funzionalità di autenticazione e autorizzazione

con svariati metodi.

Si è deciso di con�gurare opportunamente questo modulo per l'uso del ser-

ver LDAP5 interno per fare in modo che gli utenti registrati nella rete possano

accedervi senza ulteriori registrazioni. In questo modo un utente non autenti-

cato, che cerca di accedere, viene rediretto ad un semplice form d'autenticazio-

ne. Il sistema delega la veri�ca delle credenziali al server remoto. È possibile

inoltre limitare l'autorizzazione dell'uso del sistema ad un gruppo ristretto di

utenti, tramite la creazione di un �gruppo di lavoro� sul server LDAP.

5Lightweight Directory Access Protocol

31

Figura 2.13: Processo di autorizzazione.

32

2.3 Test

Un tassello molto importante della tecnica di sviluppo adottata è il TDD6.

Per la scrittura e l'esecuzione dei test è stato usato il framework JUnit. Sono

stati 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 a�nché si possa

eseguire il test. In questa fase si istanziano classi, si riempiono liste, mappe e

tabelle, anche con dati errati o non validi per testare se un determinato metodo

in situazioni che potrebbero causare un arresto imprevisto dell'applicazione.

Può essere eseguita anche al di fuori del metodo di test se le operazioni di

inizializzazione risultano particolarmente onerose, come la connessione ad un

database.

Nella seconda fase si testano le singole operazioni. Se possibile all'interno

di un test si dovranno usare solo operazioni già testate o facenti parte di

framework o delle API Java in quanto queste operazioni sono già largamente

testate ed il comportamento previsto è descritto nella documentazione.

Nella terza ed ultima fase si confronta il risultato dell'operazione con il

risultato previsto. Questa fase può avvenire sia se l'operazione da testare

fallisce lanciando un'eccezione sia confrontando lo stato precedente e quello

successivo o il valore di ritorno dell'operazione.

6Test Driven Development

33

I test unitari servono a testare le funzionalità di una classe. Per dimostrare

che la classe in esame è conforme alle speci�che è necessario che superi con

successo tutti i test.

Per ogni metodo di ogni classe scritta, soprattutto per le classi della parte

core, sono stati scritti uno o più test per �certi�carne� il comportamento.

Visto che molte classi utilizzano il concetto di tempo si è reso necessario

creare due implementazioni di un interfaccia Clock, una che restituisce il tempo

in millisecondi del sistema, usata nella versione reale del sistema, l'altra invece

gestibile per poter testare il �passare del tempo� nel sistema.

I test d'unità sull'implementazione in memoria delle classi di repository

sono serviti anche a dimostrare che le implementazioni speci�che per MongoDB

avessero lo stesso comportamento prima di procedere al cambio. Ad esempio:

Per testare il repository in memoria:

@Testpublic void canStoreACustomer() {

HashMap<String, Customer> map= new HashMap<String, Customer>();

InMemoryCustomerRepositoryinMemoryCustomerRepository= new InMemoryCustomerRepository(map);

inMemoryCustomerRepository.storeCustomer(NEW_CUSTOMER);

Assert.assertEquals(1, map.values().size());}

Per il repository che fa uso del DBMS MongoDB:

@Testpublic void canStoreACustomer() {

repository.storeCustomer(NEW_CUSTOMER);

Assert.assertEquals(1,mongoOperations.findAll(Customer.class).size());

}

Similmente le due implementazioni dovranno lanciare le stesse eccezioni a causa

degli stessi eventi.

Per testare il repository in memoria:

34

@Test(expected = IllegalArgumentException.class)public void storingNullCustomerThrows() {

HashMap<String, Customer> map= new HashMap<String, Customer>();

InMemoryCustomerRepositoryinMemoryCustomerRepository= 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 veri�cano la corretta interazione tra più classi. I

test eseguiti sulle classi di facade, e sulle classi del package mail, si possono

raggruppare 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 sempli�cate dei repository. Queste implemen-

tazioni che simulano il componente reale si chiamano �mock� implementando

solo alcuni metodi e anch'essi con una logica estremamente sempli�cata.

Ad esempio le implementazioni mock dei repository restituiscono un ele-

mento prede�nito invece di memorizzare gli elementi dall'esterno, oppure han-

no della logica �comandabile� dall'esterno come:

@Overridepublic Collection<Contract>loadExpiringContracts(long deadlineInMillis) {if (expiring) {

return Collections.singletonList(contract);} else {

return Collections.<Contract>emptyList();}

}

public void setExpiring(boolean expiring) {this.expiring = expiring;

}

in cui è possibile decidere dalla classe di test se il contratto è in scadenza

oppure no.

35

I test di accettazione simulano alcuni requisiti forniti dal cliente per dimo-

strare che i requisiti sono stati capiti e soddisfatti.

Quest'ultimi sono dei test abbastanza complessi, perché un test di accetta-

zione deve dimostrare che la logica del backend per operazioni complesse è stata

scritta in modo da soddisfare i requisiti, senza alcun riferimento all'interfaccia

gra�ca.

Per fare ciò si testano molte classi nello stesso momento e si veri�ca se il

sistema risponde nel modo desiderato. Ad esempio se si vuole veri�care se il

sistema 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.

in�ne spostando il fronte temporale veri�care se il sistema restituisce e�etti-

vamente l'analisi, o le analisi, in scadenza.

36

Capitolo 3

Conclusioni

3.1 Obiettivi e sviluppi futuri

Tutti gli obiettivi principali per la messa in produzione del sistema sono

stati raggiunti, consentendo ad Emaze di poter sfruttare il sistema per segui-

re in modo più preciso il work�ow PCI-DSS, mettendo a disposizione degli

operatori un sistema di gestione delle analisi e dei clienti centralizzato.

Come sviluppi futuri il sistema potrebbe:

• avviare automaticamente le analisi piani�cate tramite il software azien-

dale ipLegion;

• inviare ai clienti e-mail automatiche di noti�ca compilate tramite oppor-

tuni template;

• controllare in modo semi-automatico il report di un'analisi per determi-

nare se si è stata completata con un successo od un insuccesso;

• inviare ai clienti, dopo una revisione, i documenti che attestano l'esito

dell'analisi;

• guidare l'operatore 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

3.2 Lavoro svolto

Sono state scritte complessivamente più di 8500 linee di codice e con�gu-

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 build

automatiche con più di 200 commit nel sistema di Version Control.

Al momento della stesura della tesi, sono state applicati alcuni bug �x

minori ed il portale viene messo in produzione all'interno della intranet di

Emaze.

3.3 Valutazioni personali

Personalmente sono soddisfatto del lavoro svolto che mi ha permesso di

acquisire capacità e conoscenze, di confrontarmi con un ambiente lavorativo di

livello avanzato.

Mi ha permesso di acquisire nozioni di medio-alto livello su diversi fra-

mework utilizzati comunemente per la creazione di applicazioni enterprise.

38

Capitolo 4

Bibliogra�a

1. Head First Design Patterns, Eric Freeman & Elisabeth Freeman,

O'Reilly 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

(a) API della speci�ca versione utilizzata

http://docs.sencha.com/ext-js/4-1/#!/api

6. Sito MongoDB http://www.mongodb.org/

7. Sito PCI-DSS

https://www.pcisecuritystandards.org/security_standards/

40

Ringraziamenti

Il primo ringraziamento va ai miei genitori, �nanziatori unici di questo

periodo universitario. A Cinzia la mia ragione di vita.

Un ringraziamento particolare va a Davide fonte di in�nita conoscenza, che

ha saputo guidarmi in questa avventura.

In�ne ringrazio tutti i miei amici che mi hanno pazientemente sopportato

in tutti questi anni.

41