1. Università degli Studi di Trieste
Facoltà di Ingegneria
Tesi di Laurea Magistrale in
INGEGNERIA INFORMATICA
A NALISI
E SVILUPPO DI UNO
STRUMENTO PER L ’ AUTOMAZIONE
DELLA VERIFICA DI CONFORMITÀ
ALLO STANDARD PCI - DSS
Laureando: Relatore:
Lorenzo Caenazzo Prof. Alberto Bartoli
Correlatori:
Alessandro Budai
Enrico Milanese
Anno Accademico 2011-2012

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

3. 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 Bibliograa 39
Ringraziamenti 41
iii

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 un'orga-
1 2
nizzazione chiamata PCI che ha formulato uno standard (DSS ).
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
3
propria infrastruttura pubblica da parte di una società certicata PCI ASV .
Questo standard oltre a ssare i limiti per il rilascio della certicazione delinea
un workow che il certicatore è tenuto a seguire. Il progetto è stato avviato
in previsione di una espansione della domanda di tale certicazione.
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-
1 Payment Card Industry
2 Data Security Standard
3 Approved Scanning Vendor
iv

5. merciali delle analisi. Inoltre dovrà inviare resoconti giornalieri agli operatori
sulle 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 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
4
la gestione del pattern architetturale MVC ;
• 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 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 delle
varie classi all'interno di un'applicazione web
v

6. 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 bibliograci e le fonti utilizzate.
vi

7. Capitolo 1
Analisi e progettazione
1.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;
• dell'anagraca 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 Workow PCI-DSS
Lo standard PCI-DSS per il corretto svolgimento dell'attività di analisi di
1
vulnerabilità impone all'ASV di seguire il seguente workow.
1 Approved Scanning Vendor
1

8. Figura 1.1: Workow PCI-DSS.
Questo workow 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 verica 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 eettuare.
Una volta individuati tutti gli IP da testare e ricevuta l'autorizzazione a
2
procedere, viene eseguita l'analisi di vulnerabilità tramite ipLegion . Ogni
2 un software sviluppato internamente dalla Emaze per il controllo automatizzato delle
vulnerabilità
2

9. vulnerabilità è classicata 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 eetti fallita. Per ottenere la certicazione il cliente
dovrà applicare i suggerimenti consigliati all'interno del report dell'attività e
richiedere 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 lo
storico di queste entità.
Per il soddisfacimento di tali requisiti di gestione anagraca 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 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. 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 modicandone 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
modica 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à 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. • 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 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

12. quest'ultimo per sfruttare la possibilità di salvare les in modo nativo al suo
interno.
Questo particolare DBMS non richiede la denizione di tabelle e relazioni
prima di poterlo usare, e conseguentemente, non si deniscono 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
3
verranno salvate tutte le entità dello stesso tipo codicate in BSON , 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 eettuare 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
3 formato JSON binario
6

13. una denormalizzazione salvando un unico documento con all'interno tutte le
informazioni ad esso collegate.
Tale denormalizzazione è stata eettuata 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
4
nativo dopo aver vagliato l'opportunità di usare un CMS 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
4 Content Management System
7

14. 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;
• 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 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

15. 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'identicazione
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, modicare la logica applicativa.
Questa strategia di sviluppo, per essere ecace, 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

16. • 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.
5
Tamakoji è uno strumento per mantenere un repository YUM contenente
6
pacchetti RPM sviluppato internamente derivato da Koji.
5 Yellowdog Updater, Modied è un sistema di gestione dei pacchetti compatibile con i
pacchetti RPM
6 Red Hat Package Manager, pacchetto di installazione compatibile con la distribuzione
Linux Fedora e derivate
10

17. 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
graca che l'implementazione della logica applicativa si sono sviluppate mentre
venivano aggiunti o modicati i requisiti iniziali in base al prototipo fornito.
2.1 Interfaccia utente
L'interfaccia graca è 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
precongurati 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 graci più utilizzati troviamo:
• Grid, usato per la visualizzazione dei dati sotto forma di tabella;
• Form, usato per l'inserimento dei dati e la modica.
Il framework porta con se anche una serie di fogli di stile, personalizzabili
qualora si presenti la necessità.
11

18. 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 graci 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 congurazioni particolarmente complesse, si può congurare 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 modica 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

19. 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 eettuate. 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

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 una
rapida modica 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 specica analisi.
14

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 base
dati. È possibile aggiungere e modicare le informazioni di:
• Cliente principale;
• Cliente secondario;
• Contratti;
• Ticket di supporto;
• Indirizzi IP;
• Analisi;
15

22. • 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 modicare alcune informa-
zioni; ad esempio si potrà modicare 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

23. Dalla nestra di dettaglio del ticket, è possibile aggiungere, eliminare e
modicare tickets. All'atto di inserimento e modica 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

24. 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 modicare lo stato e
alcuni dettagli dell'analisi.
Figura 2.9: Dettaglio Analisi.
Gli stati disponibili identicano 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 pianicata.
18

25. 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, modica analisi
Dalla home page è necessario andare nella pagina di gestione selezionare
prima i cliente principale poi il cliente secondario ed inne aprire il dettaglio
delle analisi.
19

26. Numero di click: 4 per la visualizzazione, 5 per l'inserimento, 6 per la
modica.
Visualizzazione, inserimento, modica ticket supporto
Dalla home page è necessario andare nella pagina di gestione selezionare
prima i cliente principale poi il contratto associato ed inne aprire il dettaglio
dei ticket di supporto.
Numero di click: 4 per la visualizzazione, 5 per l'inserimento, 6 per la
modica.
20

27. 2.2 Implementazione
1
Per rispettare il pattern architetturale MVC le entità sopra citate (sez.
2
1.3) sono state divise in packages e trascritte come dei POJO . Per ogni classe
3
così creata si è reso necessario creare delle classi accessorie chiamate DTO che
sono gli unici oggetti abilitati a valicare i conni 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
notica.
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;
1 Model View Controller
2 Plain Old Java Object, cioè che non implementa nessuna interfaccia del framework
3 Data Transfer Object
21

28. • 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 specico per MongoDB. Similmente esistono specializzazioni
che aiutano nella congurazione 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 congurazione. All'interno di questi les si
dichiarano dei bean che rappresentano l'istanza della classe creata tramite
Spring. È possibile iniettare i bean deniti 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 congurazione; l'iniezione automatica cerca tra tutti i beans deniti
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

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

30. Figura 2.12: Classi appartenenti al package core.
24

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. • 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 metodi
che verranno eseguiti quando verrà eettuata 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 denizione 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
4
mappe di oggetti. Sono stati aggiunti metodi per eseguire le operazioni CRUD
oltre a dei metodi specici 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
4 Create Read Update Delete
26

33. 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 specici 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

34. 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 specica pagina
JSP.
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/
/bean
Un controller associato risulta:
@RequestMapping(value = home.htm,
method = RequestMethod.GET)
public ModelAndView showHomePage(MapString, Object model)
{
return new ModelAndView(home, model);
}
28

35. 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 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 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)
@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 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

36. Tale classe di supporto si è resa necessaria in quanto il framework ExtJS
richiede che le risposte in formato JSON abbiano un campo booleano che
identica 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 predenita usando un template per
ogni situazione d'allarme 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 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 pressati attraverso la modica di
un le di congurazione 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 congurazione
30

37. 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 congurazione le funzionalità di autenticazione e autorizzazione
con svariati metodi.
Si è deciso di congurare opportunamente questo modulo per l'uso del ser-
5
ver LDAP 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 verica 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.
5 Lightweight Directory Access Protocol
31

38. Figura 2.13: Processo di autorizzazione.
32

39. 2.3 Test
6
Un tassello molto importante della tecnica di sviluppo adottata è il TDD .
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 anché 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.
6 Test Driven Development
33

40. I test unitari servono a testare le funzionalità di una classe. Per dimostrare
che la classe in esame è conforme alle speciche è 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 certicarne 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 speciche per MongoDB
avessero 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 causa
degli stessi eventi.
Per testare il repository in memoria:
34

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. 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 semplicate dei repository. Queste implemen-
tazioni che simulano il componente reale si chiamano mock implementando
solo alcuni metodi e anch'essi con una logica estremamente semplicata.
Ad esempio le implementazioni mock dei repository restituiscono un ele-
mento predenito invece di memorizzare gli elementi dall'esterno, oppure han-
no della logica comandabile dall'esterno 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 scadenza
oppure no.
35

42. 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
graca.
Per fare ciò si testano molte classi nello stesso momento e si verica se il
sistema risponde nel modo desiderato. Ad esempio se si vuole vericare 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.
inne spostando il fronte temporale vericare se il sistema restituisce eetti-
vamente l'analisi, o le analisi, in scadenza.
36

43. 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 workow 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 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 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

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

45. Capitolo 4
Bibliograa
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

46. (a) API della specica 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

47. 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 innita conoscenza, che
ha saputo guidarmi in questa avventura.
Inne ringrazio tutti i miei amici che mi hanno pazientemente sopportato
in tutti questi anni.
41