Traccia di soluzione della prima simulazione della prova scritta di Sistemi e reti per l indirizzo Informatica e Telecomunicazioni articolazione Informatica dell Istituto tecnico settore tecnologico (MIUR 2016) 0) Ipotesi aggiuntive La banca dati cui si riferisce il testo della simulazione viene interpretata come un DBMS: allo scopo di ottimizzarne sia la gestione che la sicurezza viene installato su un server separato dal server che ospita il sito web. 1) Progetto dell infrastruttura di rete Una soluzione classica per la rete del giornale locale è quella che prevede una DMZ per i server accessibili dall esterno separata dalla rete LAN per il direttore, i giornalisti e i redattori, a sua volta separata dalla rete W- LAN usata dai collaboratori. Per garantire una maggiore sicurezza è possibile prevedere la separazione delle reti dell ufficio del direttore, degli uffici dei giornalisti e dell ufficio dei redattori mediante VLAN: in questo caso il collegamento tra lo switch centrale della rete LAN ed il router sarà di tipo trunk e la relativa interfaccia del router sarà configurata con i 3 diversi indirizzi IP di default- gateway delle 3 VLAN. Questa soluzione impone uno schema di indirizzamento coerente che prevede 5 reti separate per le quali si utilizzano indirizzi IPv4 privati (statici per la rete LAN e dinamici per la rete W- LAN utilizzando un server DHCP integrato nell access- point): la configurazione NAT sul router permetterà di associare ad un indirizzo pubblico configurato lato WAN l indirizzo privato del server web (il server DBMS non sarà invece direttamente accessibile dalla rete esterna). La subnet mask 255.255.255.0 prevista per tutte le reti coniuga la semplicità di configurazione con il numero di host previsto per ciascuna rete che è sempre inferiore a 253. Volendo incrementare il livello di sicurezza delle reti LAN e W- LAN è possibile prevedere un altrettanto classica configurazione della rete DMZ utilizzando due router- firewall separati: 1
Con riferimento alla prima soluzione proposta sono necessari i seguenti dispositivi di rete: 1 router con funzionalità VLAN e firewall 3 porte LAN Ethernet 1Gbps 1 porta WAN per fibra ottica (100Mbps simmetrica) 1 switch ad alte prestazioni con funzionalità 4 porte Ethernet 1Gbps VLAN 1 switch (uffici giornalisti) 32 porte Ethernet 1Gbps 2 switch (ufficio direttore e ufficio redattori) 4 porte Ethernet 1Gbps 1 access- point autenticazione e crittografia WPA- 2, server DHCP L access- point e lo switch con funzionalità VLAN sono dispositivi configurabili ed in quanto tali utilizzano un proprio indirizzo IP per esporre un servizio di configurazione normalmente nella forma di un server web embedded. Il contesto descritto non giustifica connessioni a 10Gbps, per cui l intero cablaggio è realizzato con cavi Ethernet UTP categoria 6 con banda di 1Gbps. Per la tecnologia di connessione alla rete Internet è necessario prevedere un contratto con un ISP specializzato per un servizio FTTB/FTTH (Fiber To The Building/Home) che preveda almeno 100Mbps sia in upstream che in downstream: l elevata banda in upstream è resa necessaria dagli accessi quotidiani di almeno 5000 utenti che, per le caratteristiche del servizio offerto, hanno probabilmente distribuzione temporale ampiamente concentrata. 2) Tecniche di protezione della rete locale e dei server interni La protezione della rete e dei server da accesi esterni non desiderati è realizzata mediante un insieme di tecniche implementate a diversi livelli dello stack ISO/OSI: protezione della rete W- LAN con standard WPA- 2 e autenticazione degli accessi mediante un server Radius che realizza un servizio AAA (Authentication, Authorization, Accounting) regole di firewall sul router per realizzare la DMZ dei server e limitare l accesso alle reti LAN e W- LAN uso del protocollo TLS per l accesso dall esterno al server web (HTTPS) autenticazione degli accessi al servizio web, eventualmente mediante ricorso ad un servizio SSO (Single Sign On) limitazione della configurabilità del router, dello switch core della rete LAN e dell access- point della rete W- LAN da Si forniscono di seguito esempi essenziali delle liste delle regole di firewall per il router nell ipotesi che il server Radius appartenga ad una quarta VLAN di servizio con indirizzo 192.168.40.0/24 e abbia indirizzo IP 192.168.40.1. Interfaccia WAN in ingresso* protocollo indirizzo origine porta origine indirizzo destinazione porta destinazione permesso TCP qualsiasi qualsiasi 192.168.1.X 192.168.10.X qualsiasi concesso solo per connessione stabilita 192.168.20.X 192.168.30.X TCP qualsiasi qualsiasi 192.168.0.1 80 (HTTP) concesso 443 (HTTPS) UDP qualsiasi 53 (DNS) qualsiasi qualsiasi concesso qualsiasi qualsiasi qualsiasi qualsiasi qualsiasi negato 2
* deve essere valutata l abilitazione del protocollo ICMP Interfaccia LAN in uscita protocollo indirizzo origine porta origine indirizzo destinazione porta destinazione permesso TCP 192.168.1.X qualsiasi qualsiasi qualsiasi negato UDP 192.168.1.X qualsiasi 192.168.40.1 1812 (RADIUS) concesso 1813 (RADIUS) TCP qualsiasi qualsiasi qualsiasi qualsiasi concesso solo per connessione stabilita UDP qualsiasi 53 (DNS) qualsiasi qualsiasi concesso ICMP qualsiasi - qualsiasi - concesso qualsiasi qualsiasi qualsiasi qualsiasi qualsiasi negato 3) Servizi e relativa configurazione La rete del giornale locale espone i seguenti servizi: servizio web sul server 192.168.0.1 pubblicamente accessibile servizio DBMS sul server 192.168.0.2 accessibile esclusivamente dal server web e dai computer della rete LAN servizio DHCP integrato nell access- point della rete W- LAN Per il servizio web è possibile installare un server Apache (disponibile sia come demone per S.O. Linux che come servizio per S.O. Windows), la cui configurazione avviene modificando il file testuale httpd.conf ; è in particolare necessario configurare le porte di ascolto del servizio, (tipicamente TCP 80 per HHTP e TCP 443 per HTTPS, ma possono essere diverse se si configura il NAT sul router con una tecnica di port- forwarding). L abilitazione TLS necessaria per il supporto HTTPS può essere effettuata attivando il modulo OpenSSL integrato e richiede un certificato del server: data la tipologia pubblica del servizio offerto è necessario che il certificato sia generato da una CA (Certification Autority) accreditata da AgID (Agenzia per l Italia Digitale). Per il servizio DBMS è possibile installare un server My- SQL (disponibile sia come demone per S.O. Linux che come servizio per S.O. Windows) la cui configurazione può essere effettuata semplicemente utilizzando l applicazione My- SQL Workbench che consente di impostare tra gli altri i seguenti parametri: tipologia degli storage engine set di caratteri password dell utente amministratore utenti e relativi privilegi e password porta di ascolto (normalmente TCP 3306) 3
numero di connessioni contemporanee client affidabili La configurazione del server DHCP integrato nell access- point (accessibile dai client wireless sulla porta UDP 67) che realizza la rete W- LAN sarà limitata all impostazione dei parametri della rete stessa (sotto l ipotesi che l indirizzo 192.168.1.1 sia attribuito all access- point stesso): network: 192.168.1.0 netmask: 255.255.255.0 default- gateway: 192.168.1.254 address- range: 192.168.1.2 192.168.1.253 DNS- address: fornito da ISP lease- time: 36000s (10h) Nell ipotesi di disporre di un unico indirizzo IP pubblico per l interfaccia WAN verso la rete Internet, nel router deve essere configurato il servizio NAT: statico di tipo port- forwarding per rendere accessibile il server web associando il suo indirizzo IP privato (192.168.0.1) all indirizzo IP pubblico esclusivamente per le porte 80 (HTTP) e 443 (HTTPS) dinamico (IP overloading) per le quattro reti interne (la rete W- LAN e le tre VLAN che costituiscono la rete LAN) che necessitano di accedere alla rete Internet esterna esclusivamente come client (navigazione web, servizi di posta elettronica, ) 4) Confronto tra soluzione interna e hosting/housing esterno La soluzione di rete proposta è qualitativamente carente per quanto riguarda affidabilità e sicurezza, in particolare del servizio web ad accesso pubblico. Essendo la rete priva di ridondanza dei dispositivi (router, switch e server) e della connettività Internet, la disponibilità del servizio è infatti soggetta ad interruzione in presenza di un qualsiasi guasto, o temporanea mancanza di alimentazione o di connettività. Inoltre, anche per la tipologia del servizio offerto, è possibile prevedere attacchi relativamente frequenti finalizzati a limitare la disponibilità del servizio stesso, o ad alterare i contenuti 4
esposti. Infine l erogazione di un servizio pubblico disponibile senza soluzione di continuità richiede la presenza o reperibilità continuativa di personale tecnico in grado di mantenere il servizio stesso e intervenire in caso di interruzione della disponibilità. Per questi motivi la soluzione interna risulta al tempo stesso insoddisfacente sotto il profilo qualitativo ed estremamente costosa anche in ragione della tipologia di connettività alla rete Internet che impone. La soluzione esterna prevede in questo caso l acquisto di un servizio di hosting standard (web server + DBMS) che qualsiasi data- center (ad esempio Aruba S.p.A.) offre a costi contenuti garantendo parametri di sicurezza e di disponibilità irraggiungibili per una soluzione interna di una piccola organizzazione, evitando al tempo stesso l acquisto e la gestione tecnica dei server e di un infrastruttura di rete resa complessa dalla presenza della DMZ. La prevedibile distribuzione temporale degli accessi al sito web del giornale concentrati in alcune ore della giornata rende il servizio descritto il candidato ideale per una soluzione cloud di noleggio di un server virtuale con configurazione (numero di CPU, quantità di memoria RAM, banda di networking, ) variabile in funzione del traffico e/o dell ora, permettendo di ottimizzare sia la qualità del servizio stesso che il suo costo. 5
Quesiti 1) Nell ipotesi che i privilegi di accesso ad uno specifico articolo da parte di un specifico utente possano essere nessuno (nel caso di articoli non pubblicamente disponibili) solo lettura (nel caso di articoli pubblicamente disponibili o riservati per gli utenti registrati) lettura e scrittura (per gli utenti interni del giornale: direttore, redattori e giornalisti) il seguente diagramma E/R modellizza la porzione di un database relazionale che permette di autenticare gli utenti e di attribuire loro i corretti privilegi di accesso agli articoli: Tenendo conto che le password degli utenti per motivi sia di sicurezza che di privacy devono essere memorizzate in forma cifrata mediante una funzione hash, il database relazionale risultante può essere così schematizzato (è previsto un utente anonimo che ha i privilegi di un qualsiasi utente non registrato): 6
In [1] alle pagine 379 387 è riportato il codice in linguaggio PHP necessario per gestire l autenticazione ed il controllo degli accessi degli utenti mediante l uso delle sessioni e la generazione di specifiche pagine HTML: nel caso specifico deve essere integrata la verifica del privilegio dell utente corrente relativamente ad un articolo richiesto mediante una query in linguaggio SQL. 2) In [2] alle pagine 140 145 e in [3] alle pagine alle pagine 1224 1227 sono riportate le informazioni essenziali sui protocolli TLS e HTTPS, comprendenti la generazione dei certificati per il server e la loro conservazione presso una CA (Certification Autority). 3) In [2] alle pagine 108 128 e in [3] alle pagine alle pagine 1207 1219 sono trattate le tecniche crittografiche a chiave simmetrica e pubblica/privata utilizzate per garantire segretezza, autenticità e integrità dei documenti, compresa la firma elettronica. 4) Se si escludono poche eccezioni, i servizi applicativi resi disponibili in rete sono basati sui due principali protocolli del livello di trasporto: UDP (User Datagram Protocol), di tipo non connesso TCP (Transmission Control Protocol) di tipo connesso Sono ad esempio basati su UDP i protocolli di livello applicativo DHCP, DNS, SNMP, ; sono invece basati su TCP i protocolli di livello applicativo FTP, telnet/ssh, SMTP, POP, HTTP/HTTPS,. In [2] alle pagine 2 18 sono trattati i protocolli di trasporto UDP e TCP e alle pagine 37 58 alcuni protocolli applicativi che su di essi si basano. In [3] alle pagine alle pagine 1884 1887 sono trattati i protocolli di trasporto UDP e TCP e alle pagine 1283 1313 alcuni protocolli applicativi che su di essi si basano. 7
Riferimenti bibliografici [1] F. Formichi e G. Meini, Corso di informatica, vol. 3, Zanichelli editore, 2013 [2] P. Ollari, Corso di sistemi e reti, vol. 3, Zanichelli editore, 2013 [3] A. Liberatore, M.L. Ferrario, G. Meini, F. Formichi, O. Bertazioli, G. Naldi e L. Marcheselli (a cura di), Manuale Cremonese di informatica e telecomunicazioni, Zanichelli editore, 2015 8
Traccia di soluzione della seconda simulazione della prova scritta di Sistemi e reti per l indirizzo Informatica e Telecomunicazioni articolazione Informatica dell Istituto tecnico settore tecnologico (MIUR 2016) Ipotesi aggiuntive Anche in considerazione della limitata quantità di dati che devono essere trasmessi/ricevuti dai dispositivi installati a bordo degli automezzi, si ritiene la connettività alla rete Internet offerta dalla rete telefonica cellulare con tecnologia UMTS/LTE adeguata per copertura e qualità alle esigenze del sistema di gestione e controllo delle flotte aziendali. Analisi della realtà e progetto del sistema Una tipica soluzione SaaS prevede un servizio ospitato su un server, fisico o virtuale, di un data- center a cui accedono i client che in questo caso sono sia i dispositivi installati a bordo degli automezzi, che i browser utilizzati per l esecuzione dell applicazione web per la gestione e il controllo delle flotte aziendali. I dispositivi installati a bordo degli automezzi eseguono una APP che accede al servizio invocando una web- API HTTP esposta da un web- service di tipo REST, mentre l applicazione di gestione e controllo delle flotte aziendali è resa disponibile alle aziende clienti nella forma di un applicazione web accessibile mediante un normale browser per pagine HTML/JavaScript. Il web- service e l applicazione web interagiscono con un unico database gestito da un DBMS transazionale. Caratteristiche e funzionalità dei dispositivi installati a bordo degli automezzi I dispositivi installati a bordo degli automezzi di ciascuna flotta aziendale devono avere le seguenti caratteristiche: connettività UMTS/LTE per l accesso continuativo alla rete Internet (eventualmente con antenna esterna) dispositivo GPS integrato (eventualmente con antenna esterna) display grafico a colori per la visualizzazione dell interfaccia utente della APP del sistema di gestione flotte 9
connessione al sistema audio di bordo per la riproduzione vocale di messaggi e avvisi touchscreen per l interazione dell utente con la APP del sistema di gestione flotte microfono per l interazione vocale dell utente con la APP del sistema di gestione flotte Il dispositivo può essere derivato da un tablet commerciale le cui caratteristiche in termini di memoria FLASH/RAM e di CPU sono senz altro adeguate per l esecuzione della APP del sistema di gestione flotte. L interazione della APP eseguita dal dispositivo con il web- service esposto dal servizio è esemplificata dal seguente diagramma UML di sequenza: La trasmissione di informazioni dal web- service verso il dispositivo installato a bordo dell automezzo avviene in risposta ad una interrogazione periodicamente ripetuta da parte della APP in esecuzione sul dispositivo stesso; in alternativa potrebbero essere utilizzati dei web- socket per rendere disponibile un canale di comunicazione in modalità push. Protocolli di comunicazione La sicurezza dei dati scambiati tra i dispositivi installati a bordo degli automezzi e i server che espongono il web- service può essere garantita dall adozione dello standard HTTPS basato su protocollo TLS 1, mentre la riservatezza dei dati delle diverse aziende che utilizzano il sistema può essere garantita da ACME mediante il rilascio di API key univocamente associate alle singole aziende clienti e la registrazione di username/password per l autenticazione e la diversificazione dei diversi ruoli all interno della singola azienda. Di seguito è definita le web- API del web- service che il sistema di gestione flotte espone verso le APP dei dispositivi installati a bordo degli automezzi (URL: https://car- ws.acme.com/) nell ipotesi che i singoli veicoli siano identificati dalla propria targa. 1 in [2] alle pagine 140 145 e in [3] alle pagine alle pagine 1224 1227 sono riportate le informazioni essenziali sui protocolli TLS e HTTPS, comprendenti la generazione dei certificati per il server e la loro conservazione presso una CA (Certification Autority) 10
inoltro della posizione del veicolo al server (da effettuarsi periodicamente) RICHIESTA metodo: URL: corpo (XML): RISPOSTA codice di stato: POST https://car- ws.acme.com/position/targa?id=key <position> <timestamp> </timestamp> <latitude> </latitude> <longitude> </longitude> <speed> </speed> </position> 200 = posizione registrata 400 = errore richiesta (targa inesistente o chiave non autorizzata) 500 = errore server ESEMPIO RICHIESTA POST https://car- ws.acme.com/position/ab123xyz?id=1234567890abcdef <position> <timestamp>2016-04- 20T09:48:52</timestamp> <latitude>43.55</latitude> <longitude>10.3167</longitude> <speed>55.5</speed> </position> inoltro di un evento anomalo al server RICHIESTA metodo: URL: corpo (XML): RISPOSTA codice di stato: POST https://car- ws.acme.com/event/targa?id=key <event> <timestamp> </timestamp> <code> </code> <description> </description> </event> 200 = evento registrato 400 = errore richiesta (targa inesistente o chiave non autorizzata) 500 = errore server ESEMPIO RICHIESTA POST https://car- ws.acme.com/event/ab123xyz?id=1234567890abcdef <event> <timestamp>2016-04- 20T09:48:52</timestamp> <code>123</code> <description>guasto meccanico</description> </event> 11
richiesta di un percorso impostato sul server (da effettuarsi periodicamente) RICHIESTA metodo: URL: RISPOSTA codice di stato: corpo (XML): GET https://car- ws.acme.com/route/targa?id=key 200 = percorso fornito 400 = errore richiesta (targa inesistente o chiave non autorizzata) 500 = errore server <route destination=" "> <position> <latitude> </latitude> <longitude> </longitude> </position> <position> <latitude> </latitude> <longitude> </longitude> </position> </route> ESEMPI RISPOSTA (IL SECONDO ESEMPIO È RELATIVO AD UN PERCORSO NON IMPOSTATO) 200 <route destination="pisa"> <position> <latitude>43.55</latitude> <longitude>10.3167</longitude> </position> <position> <latitude>43.6167</latitude> <longitude>10.4</longitude> </position> </route> 200 <route destination=""> </route> richiesta di una mappa specificando la posizione centrale e il raggio in Km (il server restituisce mappe a scala costante) RICHIESTA metodo: URL: corpo (XML): GET https://car- ws.acme.com/map?id=key <map> <center> <latitude> </latitude> 12
<longitude> </longitude> </center> <radius> </radius> </map> RISPOSTA codice di stato: corpo (PNG): 200 = mappa restituita 400 = errore richiesta (chiave non autorizzata o mappa non generabile) 500 = errore server immagine ESEMPIO RICHIESTA GET https://car- ws.acme.com/map?id=1234567890abcdef <map> <center> <latitude>43.55</latitude> <longitude>10.3167</longitude> </center> <ray>1.5</ray> </map> richiesta di uno o più messaggi impostati sul server (da effettuarsi periodicamente) RICHIESTA metodo: URL: RISPOSTA codice di stato: corpo (XML): GET https://car- ws.acme.com/text/targa?id=key 200 = messaggio fornito 400 = errore richiesta (targa inesistente o chiave non autorizzata) 500 = errore server <messages> <message> <timestamp> </timestamp> <text> </text> <message> <message> <timestamp> </timestamp> <text> </text> <message> </messages> ESEMPI RISPOSTE (IL SECONDO ESEMPIO È RELATIVO ALL ASSENZA DI MESSAGGI SUL SERVER) 200 <messages> <message> <timestamp>2016-04- 20T09:48:52</timestamp> <text>manutenzione prenotata per 22/04/2016</text> </message> 13
</messages> 200 <messages> </messages> richiesta di un messaggio vocale impostato sul server (da effettuarsi periodicamente) RICHIESTA metodo: URL: RISPOSTA codice di stato: corpo (WAW): GET https://car- ws.acme.com/vocal/targa?id=key 200 = messaggio fornito 400 = errore richiesta (targa inesistente o chiave non autorizzata) 500 = errore server audio 14
Quesiti 1) Nell ipotesi che i ruoli di accesso ai dati memorizzati nel database del server ACME da parte di un utente di un azienda siano autista (con privilegio di accesso in lettura ad un insieme limitato di informazioni) operatore (con privilegio di accesso in lettura/scrittura ad alcune informazioni quali posizioni di tutti i veicoli, eventi ricevuti dai veicoli, messaggi e percorsi inviati ai veicoli, ) amministratore (con privilegio in lettura/scrittura su tutte le informazioni, compresa la possibilità di modificare la flotta di veicoli, le credenziali degli autisti e degli operatori, ) il seguente diagramma E/R modellizza la porzione di un database relazionale che permette di autenticare gli utenti del servizio compresi gli automezzi in quanto la targa viene associata alla API key assegnata all azienda e di attribuire loro i corretti privilegi di accesso ai dati: Tenendo conto che le password degli utenti per motivi sia di sicurezza che di privacy devono essere memorizzate in forma cifrata mediante una funzione hash, il database relazionale risultante può essere così schematizzato: 15
In [1] alle pagine 379 387 è riportato il codice in linguaggio PHP necessario per gestire l autenticazione ed il controllo degli accessi degli utenti mediante l uso delle sessioni e la generazione di specifiche pagine HTML: nel caso specifico deve essere integrata la verifica del privilegio dell utente corrente in relazione alle operazioni che può effettuare. 2) La web API HTTP del web- service esposto dal server ACME è documentata nella prima parte della soluzione; nell ipotesi che i dispositivi installati a bordo degli automezzi siano dotati di S.O. Android il linguaggio di programmazione della APP è necessariamente Java; il codice che segue implementa una classe il cui costruttore inoltra al web- service la posizione e la velocità attuali dell automezzo: class SendPosition { private String url = "https://car-ws.acme.com/position/"; private String body = "<?xml version=\"1.0\" encoding=\"utf-8\"?>"; private int status = 0; private int length; public SendPosition(String targa, String key, float latitude, float longitude, float speed) { try { // costruzione del timestamp nel formato ISO 8601 TimeZone timezone = TimeZone.getTimeZone("UTC"); DateFormat dateformat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mmZ"); dateformat.settimezone(timezone); String timestamp = dateformat.format(new Date()); // costruzione del body XML da inoltrare al WS body += "<position>\r\n"; body += "<timestamp>" + timestamp + "</timestamp>\r\n"; body += "<latitude>" + Float.toString(latitude) + "</latitude>\r\n"; body += "<longitude>" + Float.toString(longitude) + "</longitude>\r\n"; body += "<speed>" + Float.toString(speed) + "</speed>\r\n"; body += "</position>\r\n"; length = body.length(); // costruzione dello URL di invocazione del WS url += URLEncoder.encode(targa, "UTF-8") + "?id=" + URLEncoder.encode(key, "UTF-8"); URL server = new URL(url); HttpsURLConnection service = (HttpsURLConnection)server.openConnection(); // impostazione degli header della richiesta HTTP di invocazione del WS service.setrequestproperty("host", "https://car-ws.acme.com"); service.setrequestproperty("content-type", "application/xml"); service.setrequestproperty("content-length", Integer.toString(length)); // impostazione del metodo HTTP di invocazione del WS (POST) service.setdooutput(true); service.setrequestmethod("post"); // streaming del body XML OutputStreamWriter stream = new OutputStreamWriter(service.getOutputStream(), "UTF-8"); BufferedWriter output = new BufferedWriter(stream); output.write(body); output.flush(); output.close(); // invocazione del WS service.connect(); // codice di stato della risposta del WS status = service.getresponsecode(); } catch (IOException exception) {} } }; public int getstatus() { return status; } 16
Volendo creare un oggetto istanza della classe SendPosition nel codice di un metodo di una activity è necessario che il costruttore sia invocato in un thread separato da quello principale della APP; a questo scopo è possibile incapsulare SendPosition in una classe Java che implementa un thread: public class SendPositionThread extends Thread { volatile boolean done; volatile boolean error; String targa; String key; float latitude; float longitude; float speed; public SendPositionThread(String targa, String key, float latitude, float longitude, float speed) { this.targa = targa; this.key = key; this.latitude = latitude; this.longitude = longitude; this.speed = speed; this.done = false; this.error = true; } public boolean getdone() { return done; } public boolean geterror() { return error; } }; public void run() { SendPosition sendposition = new SendPosition(targa, key, latitude, longitude, speed); if (sendposition.getstatus() == 200) error = false; done = true; } 3) Una rete Intranet è una rete aziendale che espone servizi accessibili alle applicazioni software ed al personale della stessa azienda utilizzando i protocolli normalmente utilizzati per la rete Internet, ad esempio: HTTP/HTTPS per rendere disponibili pagine web interattive e web- service, FTP per consentire l archiviazione ed il recupero di file, SMTP/POP/IMAP per la gestione della posta elettronica, In [2] alle pagine 37 58 e in [3] alle pagine 1283 1313 sono trattati alcuni protocolli applicativi; in [4] alle pagine 24-31 è trattato in modo specifico il protocollo HTTP. 4) Nella seguente tabella sono confrontati i vantaggi e gli svantaggi di una soluzione basata su infrastruttura interna (server fisici collocati nella DMZ della rete aziendale) e di una soluzione cloud (server virtuali resi disponibili da un data- center): Vantaggi: Infrastruttura interna ad ACME Cloud in data- center esterno ad ACME Vantaggi: nessun costo iniziale 17
costo di mantenimento sempre adeguato alle necessità del servizio effettivamente offerto: le risorse del/i server virtuale/i (spazio di storage, capacità di elaborazione, banda di connettività Internet, ) sono adeguate continuamente e dinamicamente in funzione del numero di aziende servite e del numero di automezzi monitorati esposizione di sicurezza del servizio erogato e dei dati memorizzati mitigata dal monitoraggio continuo e dalle misure adottate dal data- center Svantaggi: affidabilità in caso di guasti o incidenti garantita dal data- center Svantaggi: alto costo iniziale dovuto all acquisto e alloggiamento dei server in locale sicuro e climatizzato, all allestimento di un infrastruttura di rete opportunamente ridondata e con alimentazione garantita per un adeguato periodo di tempo anche in caso di interruzione dell erogazione dell energia elettrica alto costo di mantenimento dovuto alla presenza/reperibilità continuativa di personale tecnico specializzato per pronto intervento a fronte di problemi hardware e/o software e al noleggio di connettività Internet ridondata e con banda larga in upstream necessità di prevedere risorse (spazio di storage, capacità di elaborazione, banda di connettività Internet, ) in quantità superiore alle reali necessità per poter far fronte all espansione del numero di aziende servite e del numero di automezzi monitorati elevata esposizione di sicurezza del servizio erogato e dei dati memorizzati affidabilità in caso di guasti o incidenti comunque limitata 18
Riferimenti bibliografici [1] F. Formichi e G. Meini, Corso di informatica, vol. 3, Zanichelli editore, 2013 [2] P. Ollari, Corso di sistemi e reti, vol. 3, Zanichelli editore, 2013 [3] A. Liberatore, M.L. Ferrario, G. Meini, F. Formichi, O. Bertazioli, G. Naldi e L. Marcheselli (a cura di), Manuale Cremonese di informatica e telecomunicazioni, Zanichelli editore, 2015 [4] G. Meini, F. Formichi, Tecnologie e progettazione di sistemi informatici e di telecomunicazioni, vol. 3, Zanichelli editore, 2014 19