Soluzione Simulazione II Prova Istituti Tecnici Informatica - Parte Sistemi e Reti (28 febbraio 2019)

Nel seguente documento si vuole proporre una possibile soluzione della prova che potete trovare in allegato, almeno per la porzione riguardante Sistemi & Reti. Ovviamente, troverete online numerose soluzioni, tutte diverse tra di loro. Cercate di far tesoro delle tecnologie utilizzate perché possono essere facilmente riutilizzate in diverse problematiche e prove.

il progetto, anche mediante rappresentazioni grafiche, dell’infrastruttura tecnologica ed informatica necessaria a gestire il servizio nel suo complesso, dettagliando:
1. l’infrastruttura di comunicazione, in termini di caratteristiche dei canali, degli apparati e dei protocolli, che permette di trasmettere le informazioni di ciascuna stazione al sistema centrale;
2. le caratteristiche generali dei componenti hardware e software del sistema sia a livello centrale che nelle stazioni;
3. le misure e gli apparati per assicurare la continuità del servizio.

Indice dei contenuti

Infrastruttura

La domanda di sistemi è il primo quesito di cui riportiamo l’estratto. E’ un sistema molto generico dove si lascia al lettore la possibilità di strutturare come si preferisce l’infrastruttura di rete. E’ bene in questi casi fare tutta una serie di premesse che semplificano la trattazione. Innanzi tutto bisogna studiare che genere di sistema utilizzare se cablato o meno. Sicuramente il sistema cablato presenta molte similitudini con le simulazioni fatte in laboratorio con il Cisco Packet Tracer. Più ostica in genere per gli alunni è invece la trattazione con reti mobili/wireless. Bisogna valutare poi se si vuole una soluzione specifica ideata e realizzata appositamente per questo sistema o ci si appoggia ad una infrastruttura pubblica esistente per abbattere i costi di gestione, ma che contempla altri aspetti di sicurezza. Proviamo a scegliere una soluzione cablata e dedicata, la più semplice ma sicuramente la più costosa. Seguiranno poi altre possibili implementazioni sfruttando le reti mobili, soluzione probabilmente ottimale per costi e prestazioni. A tal proposito, si consideri l’immagine riportata.

Nella figura abbiamo volontariamente riportato tutte le soluzioni ed alternative che discutiamo. In una traccia di esame, al lettore il compito di scegliere e disegnare la singola soluzione di interesse. Le stazioni sono collegate con cavi in fibra ottica ad un router di frontiera. I cavi in fibra consentono di coprire distanze lunghe anche decine di km rispetto al centro di controllo. Valutare se tali distanze superano di molto le caratteristiche di attenuazione dei cavi così da rimettere un hub riamplificatore a distanza intermedia. Il router scelto può essere generico con 3 schede di rete gigabit con interfaccia per la fibra. Prevediamo una interfaccia con collegamento DSL/WAN per accessi esterni, in modo che il software permetta la registrazione degli utenti e la gestione dell’app. Le stazioni, nonostante i 50 alloggiamenti previsti, hanno un solo punto di accesso per il riconoscimento e aprono uno degli stalli in modo autonomo. Non c’è bisogno quindi di collegare ogni singolo stallo alla nostra rete, ma soltanto le postazioni. Per semplicità, immaginiamo di predisporre in città 3 stalli. Ad ogni stallo assegniamo una rete differente per suddividere il traffico e meglio gestire le comunicazioni. Nel esempio in figura le 3 reti sono rispettivamente con indirizzi privati 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24. Ai capi del sistema, nelle stazioni, ci sono i lettori RFID. In genere ci sono soluzioni All-in-one dotate di interfaccia ethernet o in alternativa, si può realizzare un piccolo dispositivo con Arduino e un sensore ricevente RFID. Poiché stiamo utilizzando fibre ottiche, potrebbe essere necessario un bridge che converte il segnale gigabit della fibra in un segnale ethernet: difficilmente esistono sensori RFID con una costa interfaccia per la fibra ottica! Alle singole 3 interfacce arduino o i lettori che si occupano di gestire gli RFID, possono essere assegnati altrettanti 4 IP fissi visto che non ci sono particolari esigenze, e rispettivamente gli IP 192.168.10.5, 192.168.20.5,192.168.30.5. Il lettore poteva anche scegliere soluzione con un router con meno interfaccia e uno switch con almeno 4 porte per collegare le varie stazioni. I dispositivi per coerenza con il cablaggio devono essere con interfacce di rete gigabit e ovviamente devono supportare la fibra ottica.

I vari stalli poi sono collegati con semplici sensori direttamente alla stazione di riferimento e non richiedono una configurazione di rete specifica. Devono avere dei sensori che ne rivelano se aperto o chiuso con la presenza quindi della bicicletta. La soluzione Arduino pensata per gestire RFID in questo caso potrebbe essere vincente anche per assolvere questa funzione con degli attuatori, ovviamente 50 per ogni stazione, che su misura aprono gli stalli e che, in base al loro posizione/stato, possono essere indice di presenza della bicicletta. In caso diverso, con l’uso ad esempio del solo kit RFID, si dovrà prevedere una soluzione specifica e/o proprietaria.

Le biciclette non sono monitorate, anche se al lettore potrà certamente venire il dubbio di gestire il monitoraggio con un sistema di tracciamento GPS a cui abbinare un sistema GSM o LORA per l’invio dei dati alla stazione con gli stalli o a quella centrale. Non essendo specificatamente richiesta, si consiglia di mantenere semplice la trattazione ed evitare di aggiungerla se non come idea generica per sviluppi futuri.

La zona di gestione, è una classica DMZ con i server necessari, un firewall fisico per la gestione della sicurezza, tutto cablato con cavi ed interfacce gigabit ethernet. Non occorre in questa sezione la fibra ottica, una semplice interfaccia gigabit con i relativi cavi di CAT7. Anche qui è possibile utilizzare un indirizzamento privato di classe C, ad esempio 192.168.100.0/24 per la rete e IP fissi ancora una volta per i server ad es. 192.168.100.10 e 192.168.100.15 rispettivamente per il server dati e web. Opzionale, l’inserimento di un server DNS interno alla nostra rete per meglio gestire. Ovviamente sono da configurare le schede di rete con IP, gateway (ovviamente anche su interfaccia del router) e DNS (nel caso pubblico possiamo impostare quelli di Google 8.8.8.8 e 8.8.4.4). La zona DMZ è accessibile dal traffico esterno e va quindi configurato il firewall e la sezione del router di frontiera collegata con un modem DSL e opportuno abbonamento con un ISP. L’interfaccia verso internet avrà IP pubblico e andrà configurata una NAT opportuna verso le interfacce interne alla LAN

Componenti hw/sw

A livello periferico, dobbiamo gestire il sistema che permette il prelievo e restituzione di un veicolo. Nella traccia si parla di un tecnologia RFID. Ovviamente il nostro compito progettuale prevede di intercettare un evento in cui con RFID si preleva la bicicletta. Per mantenere bassi i costi e la difficoltà di implementazione possiamo usare delle basette Arduino o MicroArduino nelle stazioni che intercettano il sensore RFID e inviano, con opportuno software C, un feedback al nostro db di riferimento. L’alternativa sono le soluzioni preconfezionate in commercio.

A livello centrale prevediamo due server con delle caratteristiche hw/sw di questo tipo:

Sistema con doppio alimentatore 700w
2 o più processori Xeon di ultima generazione
16 GB di memoria Ram con bit di parità DDR4
5 hard disk SSD da 500 GB, tre configurati con Raid 5 per elevate prestazioni e due con Raid 1 per il mirroring
2 schede di rete 10 Gigabit (1 di backup)

Sistema operativo: Linux Debian o CentOS

I software da installare sono MySQL con capacità InnoDB sul server database, PhpMyAdmin, Apache con supporto SQL e PHP 7 per il server web.

In questo caso non abbiamo previsto di lasciare i server in outsourcing, ovvero di affidare i server ad un fornitore terzo che eroga i servizi in cloud, probabilmente su sistemi virtualizzati. Soluzione di questo tipo potrebbe costare anche meno se il Comune non avesse un centro informatico CED col personale a lavoro. Un sistema in outsourcing risparmierebbe anche numerose complicazioni sul disaster recovery. Si lascia al lettore, la comparazione delle due tecniche.

E’ menzionata anche una app che va previsto sia accessibile da store Android/Iphone. Non facciamo considerazioni particolari su questa, se ne consiglia la creazione con tecnologie all’avanguardia crossplatform come Flutter o React Native.

A livello sw/hw non prevediamo in questa circostanza un tunnelling VPN tra stazioni e gestione centrale, poiché stiamo lavorando su una rete privata e dedicata. Prevedere invece per il server Apache che ospiterà il software di registrazione una interfaccia SSL/TLS per HTTPS in modo da rendere sicure le connessioni degli utenti e la registrazione a mezzo di password. Segnalare sempre all’utente suggerimenti per creare password sicure e da cambiare periodicamente. Tutte le interfacce che gireranno sul server Apache dovranno prevedere opportune contromisure per il login robusto e la prevenzione di SQL Injection.

Continuità del servizio

Gestire la continuità di un servizio così complesso non è banale. Possiamo però dare delle linee generali molto semplici. Iniziamo dagli apparati.

Gli switch che si scelgono nelle reti cablate, sono spesso elementi di criticità che si potrebbe raddoppiare con una spesa minima. Switch complessi di terzo livello, potrebbero essere più costosi e complessi da riconfigurare ma non sono nelle nostre scelte per il momento. Altri apparati da considerare punti critici sono sicuramente i server, nel nostro caso il database per la gestione del servizio e dei dati utente e per il tracciamento, un server web per la fruizione dei contenuti dal gestore del sistema. I server in genere hanno già tecnologie pensate alla ridondanza: doppio alimentatore per assicurare la corrente, doppio processore, sistemi di 2 o più dischi con Raid 1 in Mirroring che fanno il backup dei dati. Gli stessi server devono essere collegati a gruppi di continuità opportunamente dimensionati per consentire ai server di lavorare anche con sbalzi di corrente o brevi interruzioni di fornitura della corrente elettrica. Tutti questi elementi critici e le varie soluzioni devono essere contemplate in un opportuno piano di Disaster Recovery dove si individuano le criticità e le soluzione appunto per la Business Continuity. Poichè abbiamo in house un server web, particolarmente critica sarà la gestione e prevenzione dei DDoS, attacchi molto diffusi. Prevedere anche una serie di backup periodici sia in locale che su cloud dei dati sensibili e di una immagine dei sistemi operativi configurati sui due server in modo da poter ripristinare in modo semplice ed istantaneo i singoli server in caso di avaria.

II PARTE SIMULAZIONE

QUESITO I

In relazione al tema proposto, si integri il progetto con le pagine che consentono la produzione di un report contenente le bici noleggiate da un utente, le stazioni in cui sono state prelevate e restituite, la durata del noleggio ed i relativi costi. Si discuta la problematica riguardante l’invio periodico e automatico del suddetto report sulla base di una temporizzazione impostata dall’utente nel suo profilo, e si proponga una soluzione motivandola adeguatamente.

Il quesito in oggetto è piuttosto controverso poiché esula dalle competenze base che acquisiscono i ragazzi, quindi può risultare particolarmente ostico se non sviluppato in laboratorio. Il lettore può comunque prevedere una soluzione a mezzo di una opportuna pagina PHP con HTML/CSS che visualizza le informazioni richieste. Non è specificato nel quesito come il report deve essere inviato, con quale formato e tecnologia. Una possibile soluzione potrebbe essere quella di convertire l’output della pagina creata in un file PDF con librerie note del PHP come PDFlib o FPDF. Il risultato dello script PHP/FPDF verrebbe subito dato in pasto alla funzione mail del PHP o altra analoga. A questo punto è possibile temporizzare un comando creando una procedura batch con il comando CRON su piattaforma Linux che carica periodicamente la pagina PHP che crea il PDF ogni volta e lo invia con una mail. Qui di seguito il frammento di codice PHP che sfruttando FPDF, crea un report di esempio con un vettore di dati che ipotizziamo caricato da opportuna query SQL. Nella parte più in basso del codice c’è commentata la riga che stampa a video il report da usare anche per altre esercitazioni e il frammento ostico da ricordare per inviare la mail. Trovate il codice con la libreria FPDF in allegato, basta posizionare la cartella sul vostro server Apache e lanciare lo script.

<?php
include ('fpdf/fpdf.php');

define('EURO', chr(128));

/*
...query che preleva i dati e li posiziona in un array e/o variabili
contenente le bici noleggiate da un utente, le stazioni in cui sono state prelevate e restituite, la durata del noleggio ed i relativi costi.

*/

$utente = "Pietro Gamba Di Legno";

$data = array(
  array(
    'id_stazioneprelievo' => 'S001',
    'id_stazioneconsegna' => 'S001',
    'id_bicicletta' => 'F1234',
    'tempoaffitto' => '60',
    'importo' => 5),

  array(
    'id_stazioneprelievo' => 'S001',
    'id_stazioneconsegna' => 'S002',
    'id_bicicletta' => 'F1456',
    'tempoaffitto' => '65',
    'importo' => 6),

  array(
    'id_stazioneprelievo' => 'S001',
    'id_stazioneconsegna' => 'S001',
    'id_bicicletta' => 'F1234',
    'tempoaffitto' => '120',
    'importo' => 10),

  array(
    'id_stazioneprelievo' => 'S003',
    'id_stazioneconsegna' => 'S001',
    'id_bicicletta' => 'F1274',
    'tempoaffitto' => '60',
    'importo' => 5),

  array(
    'id_stazioneprelievo' => 'S002',
    'id_stazioneconsegna' => 'S002',
    'id_bicicletta' => 'F125',
    'tempoaffitto' => '180',
    'importo' => 15)
);

// crea PDF

$pdf = new FPDF();
$pdf->AddPage();
$pdf->SetFont('Arial', 'B', 16);
$pdf->Cell(40, 10, 'Report biciclette utente'.$utente);
$pdf->Ln();

$pdf->Ln(5);

$pdf->SetFont('Helvetica', 'B', 10);
$pdf->Cell(30, 7, 'Cod. bicicletta', 1);
$pdf->Cell(30, 7, 'Staz. prelievo', 1);
$pdf->Cell(40, 7, 'Staz. consegna', 1);
$pdf->Cell(40, 7, 'Durata affitto', 1);
$pdf->Cell(40, 7, 'Prezzo pagato', 1);
$pdf->Ln();

$pdf->SetFont('Helvetica', '', 10);

foreach($data as $row) {
  $pdf->Cell(30, 7, $row['id_bicicletta'], 1);
  $pdf->Cell(30, 7, $row['id_stazioneprelievo'], 1);
  $pdf->Cell(40, 7, $row['id_stazioneconsegna'], 1);
  $pdf->Cell(40, 7, $row['tempoaffitto'], 1);
  // formattazione italiana
  $pdf->Cell(40, 7, EURO . ' ' . number_format($row['importo'], 2, ',', '.'), 1, 0, 'R');
  $pdf->Ln();
}

//Stampa a video per test/debug
//$pdf->Output();

//Gestione invio mail
$message="Il tuo report è pronto";
$eol = "\r\n";
$content = chunk_split(base64_encode($pdf->Output('S')));
$body .= $eol . $message . $eol . $eol; 
$body .= $eol . $content . $eol . $eol;
mail("info@alfredocentinaro.it", "Il tuo report", $body);

Sull’opportunità di inviare il report periodicamente tramite batch si possono incontrare alcuni rischi per i server. Infatti l’invio su tempi molto brevi, anche dell’ordine di minuti, di numerosi report quanti sono gli utenti può congestionare il sistema sia per le risorse di calcolo necessarie che devono eseguire lo script PHP, le query SQL e la procedura di mail, sia le risorse di connessione e la congestione del traffico delle mail in uscita. Per tanto, conviene guidare l’impostazione del tempo di invio cercando di spalmarlo almeno su base settimanale, probabilmente scaglionando un certo quantitativo di utenti/report alla volta, o con un opportuno bottone funzione direttamente da applicativo web in modo da essere anche on demand su richiesta degli utenti. Per quanto riguarda il database, essendo questi campi soggetti a reportistica frequente, potrebbe essere opportuno creare degli opportuni indici per aumentare le prestazioni sui campi scelti, a scapito ovviamente di occupazione in ram, piuttosto che valutare la creazione di una vista su misura. Il pdf stampato verrebbe come nell’immagine seguente.

QUESITO IV

Alla luce delle problematiche relative alla sicurezza ed integrità delle informazioni archiviate nei sistemi informatici e della loro riservatezza, si discutano vantaggi e svantaggi delle principali tecniche per l’autenticazione degli utenti di un sistema informatico di rete, discutendo sistemi e protocolli utilizzati in tale contesto.

L’autenticazione di un utente su un servizio, portale o altro, in rete è uno dei momenti più sensibili della gestione della sicurezza informatica. Il sistema più semplice ed intuitivi che conosciamo è il classico Username/Password. Queste devono viaggiare in un tunnel SSL/TLS per consentire integrità e riservatezza delle informazioni personali. Le password non devono mai essere memorizzate direttamente in chiaro su un database come un campo di testo, ma vanno sempre usate impronte delle suddette password con funzioni di hash come MD5 e SHA, meglio la seconda con la versione SHA2, per verificare la correttezza della password mantenendo la segretezza e riservatezza della password stessa. Nel caso ad autenticarsi sia un utente su una postazione wireless, il discorso si complica poiché si devono coinvolgere i protocolli 802.11x con WEP, WPA e WPA2, ultimo dei quali ritenuto affidabile e sicuro. Questi sono da utilizzare con un server RADIUS. Quelli descritti sono classici modi di autenticazione basati su password. Nuovi metodi di autenticazione si basano su più procedure che conferiscono ulteriore robustezza al processo. Pensiamo alla doppia autenticazione che facciamo sulla posta Gmail o il registro elettronico in classe. Questo sistema si base su “Qualcosa che so” e “Qualcosa che ho”, ovvero una password e un codice PIN inviato sul telefonino. Al posto del telefonino ci sono svariati metodi alternativi di attuare la doppia autenticazione: dalla mail, con una app che genera un codice One Time, l’inserimento di un Captcha, l’uso di generatori automatici come quelli di banche e posta, l’uso di un barcode 2/3D piuttosto che l’uso di un dispositivo RFID, tecnologia questa in forte espansione. In alcuni casi “Quello che ho” si sostituisce con un “Quello che sono” se al posto del PIN usiamo impronte digitali, impronta iride o altre grandezze biometriche.

Ultima modifica 25 Febbraio 2024