analisi e gestione della sicurezza di una complessa applicazione ...

More documents

Recommendations

Info

2.4.2 Diagrammi UML CAPITOLO II - Talete: Autenticazione ed Autorizzazione Lo Unified Modeling Language (UML, traducibile come “linguaggio di modellazione unificato”) è una famiglia di notazioni grafiche che si basano su un singolo meta-modello e servono a supportare la descrizione e il progetto dei sistemi software, in particolare quelli costruiti seguendo il paradigma orientato agli oggetti (OO). La ragione principale per cui i linguaggi grafici sono stati introdotti è il livello di astrazione dei linguaggi di programmazione, che non è abbastanza alto da permettere la discussione diretta delle scelte di progetto. Per questo motivo, già durante la fase di analisi dei requisiti, spesso sono costruiti una serie di diagrammi basati su UML, così da poter sintetizzare graficamente tutti gli aspetti coinvolti nell’ambito del progetto, prima, durante e dopo la sua implementazione. Per quanto riguarda la fase di sintesi dei requisiti, sono stati realizzati i diagrammi delle attività e dei casi d’uso. In seguito è stato sviluppato il diagramma delle classi, così da sintetizzare la localizzazione, all’interno di esse, dei dati e dei metodi del software da sviluppare. 2.4.3 Diagramma dei casi d’uso I diagrammi dei casi d’uso servono per modellare i requisiti del sistema dal punto di vista dell’utente. In essi vengono individuati: 1) attore: rappresenta il ruolo che un utente deve svolgere; nel nostro caso abbiamo individuato l’utente generico, il concessionario, il proprietario, il consulente e l’amministratore. 2) caso d’uso: particolare compito che deve essere svolto; nel nostro caso sono state definite le operazioni di autenticazione, di modifica e di visualizzazione. In particolare, grazie alla 28
CAPITOLO II - Talete: Autenticazione ed Autorizzazione costruzione di questo diagramma è possibile vedere le operazioni che possono svolgere gli utenti che accedono a Talete: ad esempio il concessionario vede tutte le proprie organizzazioni, può creare e rimuovere organizzazioni, vede tutti i suoi consulenti e i permessi dei propri utenti; non può visualizzare gli altri concessionari o gli utenti delle altre organizzazioni. Il consulente vede le organizzazioni a cui appartiene, e quelle che hanno come concessionario il suo; può modificare alcuni dati di esse, ma non può aggiungere o cancellare organizzazioni. Non vede gli altri concessionari o i consulenti delle altre organizzazioni e non accede alla pagina delle autorizzazioni. Infine il proprietario vede la propria organizzazione e può aggiornare i dati relativi ad essa, vede i suoi consulenti, ma non visualizza né quelli altrui né i concessionari. Egli accede alla pagina delle autorizzazioni assegnando i permessi agli utenti della propria organizzazione. 3) Uses: indica una componente necessaria per svolgere una determinata operazione. Per quanto riguarda il nostro sistema ad esempio, tutti i casi d’uso sono subordinati alla fase di autenticazione; tuttavia nel disegno ne è rappresentato solo uno per evitare intrecci di linee. 4) Extends: indica le eccezioni o le varianti allo scenario principale. Nel nostro caso, lo use case definito come “numero massimo di consulenti raggiunto” è un’eccezione dello scenario “modificare consulenti della propria organizzazione”, in quanto ogni organizzazione può avere un determinato numero di consulenti; raggiunto questo valore non è più possibile aggiungerne degli altri. Nel diagramma in figura non sono stati aggiunti i collegamenti tra l’attore Amministratore e gli use case, in quanto l’amministratore può compiere qualsiasi azione e quindi sarebbe da collegare a tutti gli use case, e questo comporterebbe una notevole confusione nel grafico. 29
Page 1 and 2: UNIVERSITÀ POLITECNICA DELLE MARCH
Page 3 and 4: INDICE INDICE .....................
Page 5 and 6: ELENCO DELLE FIGURE Figura 1 Home p
Page 7 and 8: CAPITOLO I - Introduzione 5
Page 9 and 10: CAPITOLO I - Introduzione tecniche
Page 11 and 12: CAPITOLO I - Introduzione 2 Gestion
Page 13 and 14: CAPITOLO II - Talete: Autenticazion
Page 23 and 24: • Ampliamento della superficie di
Page 29: CAPITOLO II - Talete: Autenticazion
Page 35 and 36: 2.4.5 Diagramma delle classi CAPITO
Page 43 and 44: CAPITOLO III - Progettare un’appl
Page 45 and 46: 3.2 Il significato dei design patte
Page 55 and 56: 4.1 Introduzione CAPITOLO IV - La s
Page 57 and 58: CAPITOLO IV - La sicurezza nelle we
Page 81 and 82:
CAPITOLO IV - La sicurezza nelle we
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Mentre con AnomynousTemplate si ha:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
CAPITOLO V - La sicurezza nell’ar
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
1 porsi dalla prospettiva dell’at
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
CAPITOLO VI - Gli attacchi e il pro
Page 115 and 116:
6.1 Progetto OWASP CAPITOLO VI - Gl
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
6.2.5 I vantaggi nascosti CAPITOLO
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
6.10 Denial of Service CAPITOLO VI
Page 151 and 152:
6.11 Insecure Configuration Managem
Page 153 and 154:
CAPITOLO VII - Test per valutare la
Page 155 and 156:
7.1.1 Analisi del codice sorgente C
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
vulnerabilità critiche di applicaz
Page 165 and 166:
• Aggiungere la tecnologia SSL e
Page 167 and 168:
Durante questi anni universitari so
Page 169 and 170:
M. Fowler, D. Rice, M. Foemmel, E.
show all

analisi e gestione della sicurezza di una complessa applicazione ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?