Vpn

Molte aziende hanno uffici e stabilimenti situati in diverse città, a volte anche in diversi stati. Prima che esistessero le reti pubbliche per i dati, le aziende affittavano dalla compagnia telefonica le linee per collegare fra loro alcune o tutte le loro sedi. Alcune aziende lo fanno ancora. Una rete costruita con i computer aziendali e le linee telefoniche affittate è detta rete privata. Un esempio di rete privata che connette tre siti è mostrata nella figura seguente.

Le reti private funzionano bene e sono molto sicure. Quando le uniche linee presenti sono affittate non è possibile che il traffico di rete possa fuoriuscire dall’azienda, salvo che un intruso riesca a intercettare fisicamente le comunicazioni, il che non è affatto facile. Il problema delle reti private è dato dal loro costo. Infatti, affittare una singola linea T1 può costare migliaia di dollari al mese, affittare una T3 molto di più. Quando arrivarono sulla scena le reti pubbliche per i dati e successivamente Internet, molte aziende vollero spostare il loro traffico dati (e se possibile anche vocale) sulle reti pubbliche, ma senza abbandonare la sicurezza delle linee private. Questa domanda portò in breve tempo all’invenzione delle VPN (Virtual Private Network). Le VPN permettono di sovrapporre delle reti sopra le reti pubbliche, ma senza abbandonare le proprietà di sicurezza tipiche delle reti private. Sono chiamate “virtuali” perché sono una mera illusione, così come i circuiti virtuali non sono veri circuiti e la memoria virtuale non è vera memoria. Le VPN possono essere costruite sopra le reti ATM (o frame relay), ma un approccio che diventa sempre più comune consiste nel costruire le VPN direttamente sopra Internet. Una tipica architettura consiste nell’avere un firewall per ogni ufficio e creare dei tunnel attraverso Internet fra tutte le coppie di uffici, come mostrato nella figura precedente. Se viene usato l’IPsec per il tunneling, è possibile aggregare tutto il traffico fra ogni possibile coppia di uffici in una singola SA con autenticazione e cifratura. Questo fornisce controllo dell’integrità, segretezza e anche una considerevole immunità all’analisi del traffico. Ogni coppia di firewall deve negoziare allo startup i parametri della sua SA: i servizi, le modalità, gli algoritmi e le chiavi. Molti firewall sono progettati per gestire le VPN, e ciò vale anche per alcuni normali router. Visto che i firewall sono impiegati principalmente nell’ambito della sicurezza, è naturale che i tunnel delle VPN comincino e finiscano su dei firewall. In questo modo si realizza una chiara separazione fra Internet e l’azienda. Firewall, VPN e IPsec su ESP in modalità tunnel costituiscono una combinazione naturale e molto usata nella pratica. Il traffico comincia a scorrere dopo che sono state stabilite le SA. Per un router su Internet, un pacchetto che viaggia attraverso un tunnel VPN non è altro che un normale pacchetto. L’unica cosa strana è la presenza di un’intestazione IPsec dopo la normale intestazione dell’IP. Visto che le intestazioni extra non hanno effetto sulla procedura di forwarding dei pacchetti, i router semplicemente le ignorano. Impostare le VPN in questo modo presenta il vantaggio fondamentale della completa trasparenza delle operazioni nei confronti degli utenti e del loro software. I firewall impostano e gestiscono le SA. L’unica persona che è al corrente di queste impostazioni è l’amministratore di sistema che deve configurare e gestire i firewall. Per tutti gli altri utenti, è come se ci fosse una rete privata su linea dedicata.

Modelli di processo

Nel post precedente ho trattato il processo software dal punto di vista della sua maturità a livello aziendale. In questo post mi soffermerò sulle fasi che compongono un processo software.
Le principali attività (e sottoattività) costituenti il processo di sviluppo sono le seguenti:
• la fase di analisi, ovvero l’indagine preliminare sul contesto in cui il prodotto software deve inserirsi, sulle caratteristiche che deve esibire, ed eventualmente su costi e aspetti logistici della sua realizzazione; questa fase può essere scomposta in sottoattività quali analisi di fattibilità, analisi e modellazione del dominio applicativo, analisi dei requisiti e così via. In senso ampio si può dire che l’analisi ha lo scopo di definire (il più precisamente possibile) il problema da risolvere. Questa fase è costituita anche da raccolta dei dati tramite colloqui tra cliente/committente e relativi sviluppatori. Al termine della fase verrà creato un documento che descrive le caratteristiche del sistema.
• la fase di progetto, in cui si definiscono le linee essenziali della struttura del sistema da realizzare, in funzione dei requisiti evidenziati dall’analisi e dal documento finale da essa creato. Anche questa fase può essere scomposta in sottoattività, dal progetto architetturale al progetto dettagliato. Si può dire che il progetto ha lo scopo di definire (a un certo livello di dettaglio) la soluzione del problema. In questa fase sarà sviluppato un documento che permetterà di avere una definizione della struttura di massima (architettura di alto livello) e una definizione delle caratteristiche dei singoli componenti (moduli).
• la fase di implementazione o codifica del sistema, ovvero la sua realizzazione concreta; questa tipicamente consiste nella realizzazione di uno o più programmi in un determinato linguaggio di programmazione, benché possano essere coinvolte anche tecnologie diverse (database, linguaggi di scripting e via dicendo). Nella maggior parte dei casi è possibile distinguere almeno una sottoattività di implementazione dei singoli moduli che costituiscono il sistema e la sottoattività dell’integrazione di tali moduli a formare il sistema complessivo. Complessivamente, l’implementazione ha lo scopo di realizzare la soluzione.
• la fase di collaudo, volta a misurare in che modo il sistema realizzato soddisfa i requisiti stabiliti nella fase di analisi, ovvero a valutarne la correttezza rispetto alle specifiche. Anche il collaudo è normalmente scomponibile almeno nelle due attività del collaudo dei singoli moduli e quello del sistema integrato. Le tipologie specifiche di test (prove) si possono inoltre distinguere in funzione dei particolari aspetti dei moduli o del sistema che vengono valutati; si parla per esempio di test funzionali, test di performance, test di accettazione, test d’installazione.
• la fase di manutenzione, che comprende tutte le attività di modifica del software successive al suo rilascio presso il cliente o la sua immissione sul mercato. Queste attività possono essere volte a correggere errori del software, adattarlo a nuovi ambienti operativi, o estenderne le funzionalità. La manutenzione incide sui costi, si stima che il 60% dei costi dipenda dalla manutenzione. Ogni modifica al software comporta necessariamente la necessità di nuovi test, sia relativi alle nuove funzionalità eventualmente introdotte, sia mirati a verificare che le modifiche apportate non abbiano compromesso funzionalità preesistenti (test di regressione). Una linea standard di verifica prevede dei test sui moduli più precisamente si occupa di controllare che i moduli presi singolarmente funzionino e che una volta assemblati assieme i moduli continuino a funzionare.
• in tutti i cicli di vita del software svolge inoltre un ruolo essenziale la documentazione dei prodotti delle varie sottoattività; la stesura della documentazione viene quindi regolamentata nello stesso modo delle attività menzionate.
• Un elemento chiave in tutti i processi ingegneristici è la misurazione. Una metrica software è la misura di alcune proprietà del software o delle sue specifiche. Le metriche permettono di valutare il budget per il progetto, la produttività individuale, la produttività del progetto, la qualità del software, ecc…