Hai appena affrontato la seconda prova della Maturità 2026? In questo articolo ti proponiamo lo svolgimento completo della prova di Sistemi e Reti, con l'analisi dettagliata del Quesito I.

Scopri il confronto tra soluzioni on-premise e cloud per la gestione dei dati BIM e l'analisi dei flussi di traffico generati dal sistema.

📄 Scarica il PDF completo della soluzione — tutti i passaggi e i grafici, pronti da stampare.

🗂️ File sorgente della prova: pagina 1 · pagina 2 · pagina 3

Vuoi risolvere la tua prova così? Prova il Risolutore Prove AI.

I

PROPOSTA DI SOLUZIONE — Seconda Prova di Maturità
Sistemi e Reti, 2026
Svolgimento del Quesito I: Analisi comparativa tra soluzioni di archiviazione "on-premise" e "cloud-based" per i dati del sistema BIM.

Analisi del traffico e dei dati
Il sistema descritto genera tre flussi di dati principali, caratterizzati da requisiti differenti:
1. Dati dei rilevamenti BIM (nuvole di punti): file di grandi dimensioni, richiedono elevata capacità di memorizzazione e banda larga per il trasferimento.
2. Immagini timelapse (4K/8K): file multimediali pesanti, generati in modo continuo e periodico.
3. Dati dei sensori di sicurezza: stringhe di testo o log di piccole dimensioni, ma con generazione ad alta frequenza e necessità di bassa latenza per la gestione degli allarmi.

Si analizzano di seguito le due tipologie di architettura di archiviazione richieste.

Soluzione On-Premise
L'architettura "on-premise" prevede l'installazione, la configurazione e la manutenzione di server e apparati di storage (come NAS - Network Attached Storage o SAN - Storage Area Network) fisicamente collocati all'interno del data center della sede centrale dell'azienda.

Vantaggi:
* Controllo totale: l'azienda ha il possesso fisico dei dischi e la gestione esclusiva delle policy di sicurezza e degli accessi.
* Velocità di accesso locale: gli operatori in sede centrale che utilizzano i software BIM specialistici accedono ai modelli 3D tramite la rete LAN (es. a $1 \text{ Gbps}$ o $10 \text{ Gbps}$), garantendo latenze minime e throughput elevato, fondamentale per il rendering e la modellazione parametrica.
* Costi operativi (OPEX) ridotti: una volta ammortizzato l'investimento iniziale, non vi sono canoni mensili legati al volume dei dati archiviati o al traffico in uscita.

Svantaggi:
* Costi in conto capitale (CAPEX) elevati: è necessario l'acquisto iniziale di hardware costoso, oltre ai costi per l'infrastruttura di supporto (alimentazione ridondata, condizionamento).
* Scalabilità complessa: l'aumento dello spazio di archiviazione richiede l'acquisto e l'installazione fisica di nuovi dischi o server, con tempi di latenza logistici.
* Manutenzione a carico dell'azienda: guasti hardware, aggiornamenti firmware e procedure di backup/Disaster Recovery devono essere gestiti dal personale IT interno.
* Collo di bottiglia WAN: l'accesso ai dati da parte dei cantieri remoti è limitato dalla larghezza di banda della connessione internet della sede centrale (attualmente indicata come ADSL, del tutto insufficiente e da sostituire con connettività FTTH).

Soluzione Cloud-Based
L'architettura "cloud-based" prevede l'utilizzo di risorse di storage fornite da un Cloud Service Provider (CSP) esterno, accessibili tramite rete Internet (es. Object Storage, Cloud NAS, database as a service).

Vantaggi:
* Scalabilità ed elasticità: lo spazio di archiviazione è virtualmente illimitato e può essere incrementato o ridotto istantaneamente in base alle esigenze dei cantieri attivi.
* Modello a consumo (OPEX): si paga solo per lo spazio effettivamente utilizzato e per il traffico generato, azzerando i costi di investimento iniziale (CAPEX).
* Accessibilità distribuita: i dati sono accessibili con le medesime prestazioni sia dalla sede centrale sia dai cantieri, facilitando la condivisione.
* Alta affidabilità e Disaster Recovery: i CSP garantiscono ridondanza geografica dei dati e SLA (Service Level Agreement) prossimi al $99.99\%$.

Svantaggi:
* Dipendenza dalla connettività: l'accesso ai dati è totalmente subordinato alla disponibilità e alle prestazioni della connessione Internet. L'elaborazione di modelli BIM pesanti direttamente dal cloud può risultare lenta.
* Costi ricorrenti: l'archiviazione a lungo termine di terabyte di dati (nuvole di punti e video 8K) comporta canoni mensili che, nel lungo periodo, possono superare i costi di un'infrastruttura fisica.
* Sicurezza e compliance: i dati risiedono su server di terze parti, richiedendo un'attenta valutazione delle normative sulla privacy e la cifratura end-to-end.

Proposta di adozione ed integrazione nel progetto
Considerate le peculiarità del progetto, si propone l'adozione di un'architettura ibrida (Hybrid Cloud), che integra i punti di forza di entrambe le soluzioni.

1. Nei cantieri (Edge Storage):
   Si prevede l'installazione di un NAS locale rugged in ogni cantiere. Questo apparato funge da buffer temporaneo per l'acquisizione rapida delle nuvole di punti e delle foto timelapse via LAN/WLAN locale. I dati vengono poi sincronizzati in modo asincrono (es. durante le ore notturne) verso la sede o il cloud, per non saturare la banda WAN durante le ore lavorative.

2. Nella sede centrale (On-Premise per dati caldi):
   Si prevede l'installazione di una SAN/NAS ad alte prestazioni. I dati grezzi sincronizzati dai cantieri vengono elaborati qui. I progettisti lavorano sui modelli BIM "caldi" (ad accesso frequente) sfruttando l'alta velocità della LAN aziendale.

3. Nel Cloud (Archiviazione, Condivisione e IoT):
   * Dati sensori: I log dei sensori di sicurezza, essendo leggeri ma continui, vengono inviati direttamente a un database Cloud-based per l'analisi in tempo reale e la storicizzazione.
   * Condivisione: I video timelapse finalizzati e i modelli BIM esportati per la visualizzazione dei clienti vengono caricati su un Cloud Storage, facilitando l'accesso esterno senza esporre la rete della sede centrale.
   * Backup e Archiviazione a lungo termine: I progetti dei cantieri chiusi (dati "freddi") vengono spostati su servizi di Cloud Storage di tipo Archive (a basso costo), liberando spazio sui server on-premise della sede.

IV

PROPOSTA DI SOLUZIONE — Seconda Prova di Maturità
Sistemi e Reti 2026
Analisi degli effetti e delle finalità di un comando SSH in presenza di regole di Port Forwarding.

Quesito IV

Si richiede di analizzare il seguente comando:
$$ssh\ -p\ 25500\ [email protected]$$
e di esporne gli effetti e le finalità, data la presenza di una regola di reindirizzamento verso l'indirizzo privato $172.16.1.100$.

Analisi del comando e del contesto di rete
Il comando impartito invoca il client SSH (Secure Shell) per stabilire una connessione remota sicura. Analizziamo i parametri specificati:
* -p 25500: impone al client di tentare la connessione sulla porta TCP $25500$ anziché sulla porta standard di default per il protocollo SSH (porta TCP $22$).
* administrator: specifica l'username con cui si intende effettuare l'autenticazione sul sistema di destinazione.
* 200.1.1.1: rappresenta l'indirizzo IP pubblico di destinazione, assegnato all'interfaccia esterna del router o firewall perimetrale.

L'indirizzo $172.16.1.100$ appartiene a uno spazio di indirizzamento privato (Classe B, secondo la RFC 1918), pertanto non è direttamente instradabile su Internet. La regola configurata sul dispositivo $200.1.1.1$ è una regola di Destination NAT (DNAT), comunemente nota come Port Forwarding.

Effetti del comando impartito
L'esecuzione del comando genera la seguente sequenza di eventi a livello di rete:
1. Il client genera un pacchetto TCP con indirizzo IP di destinazione $200.1.1.1$ e porta di destinazione $25500$.
2. Il pacchetto raggiunge il router/firewall perimetrale all'indirizzo $200.1.1.1$.
3. Il router intercetta il traffico e applica la regola di DNAT configurata: l'indirizzo IP di destinazione nell'header del pacchetto viene tradotto da $200.1.1.1$ a $172.16.1.100$. Contestualmente, la porta di destinazione viene tipicamente tradotta dalla $25500$ alla porta locale in ascolto sul server interno (generalmente la porta standard $22$).
4. Il pacchetto modificato viene instradato all'interno della rete locale (LAN) fino a raggiungere l'host $172.16.1.100$.
5. L'host interno risponde al router, il quale esegue l'operazione inversa (modificando l'IP sorgente da $172.16.1.100$ a $200.1.1.1$) e inoltra la risposta al client.
6. Si instaura il three-way handshake TCP e, successivamente, l'handshake crittografico SSH.
7. Al client viene richiesta la password (o la chiave asimmetrica) per l'utente administrator. Tale autenticazione non avviene sul router $200.1.1.1$, bensì direttamente sul sistema operativo dell'host interno $172.16.1.100$.

L'effetto finale è l'apertura di una sessione terminale remota, cifrata e interattiva, direttamente sul server interno $172.16.1.100$, operando con i privilegi dell'utente administrator.

Finalità dell'utilizzo
L'architettura descritta risponde a specifiche esigenze sistemistiche e di sicurezza:
* Accessibilità dall'esterno (NAT Traversal): Permette a un amministratore di raggiungere un server posizionato in una rete locale privata (LAN) dall'esterno (WAN/Internet), superando il limite della non instradabilità degli IP privati.
* Ottimizzazione degli IPv4 pubblici: Consente di esporre molteplici servizi interni utilizzando un singolo indirizzo IP pubblico. Mappando porte esterne diverse (es. $25500$, $25501$, ecc.) è possibile raggiungere macchine interne differenti.
* Security through Obscurity (Port Shifting): L'utilizzo di una porta non standard ad alto numero (come la $25500$) mitiga drasticamente il volume di attacchi automatizzati (botnet, script kiddies) che eseguono scansioni massive e tentativi di brute-force sulla porta SSH di default ($22$).
* Protezione perimetrale: Il server interno non è esposto direttamente a Internet. Il router funge da scudo, permettendo il transito del traffico solo sulla specifica porta configurata e scartando tutto il resto del traffico non esplicitamente autorizzato.

III

PROPOSTA DI SOLUZIONE — Seconda Prova di Maturità
Sistemi e Reti, 2026
Svolgimento del Quesito III: Misure tecniche per l'inibizione dell'accesso a piattaforme di Intelligenza Artificiale e relativa schedulazione.

Ipotesi aggiuntive:
Per la trattazione del quesito, si assumono le seguenti caratteristiche dell'infrastruttura di rete dell'istituto:
* I laboratori di informatica sono segmentati su reti logiche distinte (VLAN). Ad esempio: Laboratorio 1 su VLAN 10 (sottorete $192.168.10.0/24$), Laboratorio 2 su VLAN 20 (sottorete $192.168.20.0/24$).
* Il traffico in uscita verso Internet è gestito centralmente da un Next-Generation Firewall (NGFW) o da un Web Proxy server.
* Le postazioni dei laboratori sono inserite in un dominio Active Directory (AD).

Punto 1: Misure e tecniche per impedire l'accesso alle piattaforme IA

Per inibire l'accesso a piattaforme di Intelligenza Artificiale (es. ChatGPT, GitHub Copilot, Claude) non è sufficiente il blocco degli indirizzi IP (Layer 3), poiché tali servizi sono ospitati su infrastrutture cloud con IP dinamici e condivisi. Si rende necessario operare ai livelli superiori della pila ISO/OSI (Layer 7). Si propongono le seguenti tecniche concorrenti:

1. Filtraggio DNS (DNS Sinkholing)
Si configura il server DNS interno dell'istituto affinché risolva i nomi a dominio noti delle piattaforme IA (es. $chatgpt.com$, $api.openai.com$, $copilot.github.com$) verso un indirizzo IP inesistente o verso una pagina di blocco interna (es. $0.0.0.0$ o $127.0.0.1$).
Affinché la misura sia efficace, si imposta una regola sul firewall per bloccare il traffico in uscita sulla porta $53$ (DNS) e $853$ (DNS over TLS) per tutti gli host della rete, consentendolo esclusivamente al server DNS interno. In questo modo si impedisce agli studenti di aggirare il blocco impostando DNS pubblici (es. $8.8.8.8$).

2. Web Proxy con ispezione SSL (Layer 7)
Poiché il traffico verso le piattaforme IA è crittografato (HTTPS, porta $443$), un semplice proxy non può leggere l'URL completo. Si implementa un Web Proxy (es. Squid) configurato in modalità SSL Bump (o Deep Packet Inspection sul NGFW).
Questo richiede la distribuzione del certificato Root CA del proxy sulle macchine del laboratorio tramite Group Policy Object (GPO). Il proxy decifra il traffico, analizza l'URL e l'intestazione HTTP, e blocca le richieste dirette agli endpoint delle API di generazione codice.

3. Application Control tramite NGFW
I firewall di nuova generazione dispongono di firme applicative aggiornate dinamicamente. Si configura una regola di Application Control che identifica e scarta i pacchetti (Drop) associati alla categoria "Generative AI" o alle specifiche applicazioni, analizzando il campo SNI (Server Name Indication) dei pacchetti TLS durante l'handshake, senza necessità di decifrare l'intero payload.

4. Restrizioni sugli Endpoint (GPO)
Per impedire l'uso di estensioni del browser (es. estensioni per IDE online o plugin per Chrome/Edge che integrano l'IA), si configurano le policy di dominio (GPO) per implementare una Blocklist delle estensioni non autorizzate o una Allowlist che consenta l'installazione dei soli plugin approvati dai docenti.

flowchart TD
    A[Postazione Studente] -->|Richiesta HTTPS| B(Switch di Laboratorio)
    B --> C{Firewall / Proxy L7}
    C -->|Controllo SNI / URL| D{URL in Blacklist AI?}
    D -->|Sì| E[Pagina di Blocco / Drop]
    D -->|No| F[Accesso a Internet]
    A -->|Richiesta DNS| G(DNS Server Interno)
    G -->|Dominio AI| H[Risoluzione 0.0.0.0]
    G -->|Dominio Lecito| I[Risoluzione IP Reale]

Punto 2: Schedulazione e profilazione per laboratorio

Per limitare il blocco esclusivamente alle ore di lezione o di verifica, e solo per i laboratori interessati, si sfrutta la segmentazione di rete unita a regole temporizzate.

Profilazione per Laboratorio
L'identificazione del laboratorio avviene tramite l'indirizzo IP sorgente. Poiché il Laboratorio 1 appartiene alla sottorete $192.168.10.0/24$, le regole di inibizione verranno applicate unicamente ai pacchetti aventi come Source IP tale range.

Schedulazione tramite Time-based ACL (Esempio su apparati di rete)
Se si opera a livello di firewall/router, si definiscono degli oggetti temporali (Time Range) che ricalcano l'orario scolastico.
Esempio di logica di configurazione (sintassi simil-Cisco):
```text
time-range ORARIO_VERIFICA
periodic Monday 08:00 to 10:00
periodic Wednesday 10:00 to 12:00

access-list 100 deny tcp 192.168.10.0 0.0.0.255 any eq 443 time-range ORARIO_VERIFICA
```
(Nota: l'ACL L4 qui sopra è solo esemplificativa per la schedulazione; nella realtà si applicherà il time-range alla regola di Application Control L7).

Schedulazione tramite Web Proxy (Esempio Squid)
Se si utilizza un proxy server, si definiscono delle Access Control List (ACL) basate su sorgente, destinazione e tempo.
Esempio di configurazione:
```text

Definizione del laboratorio

acl lab_informatica src 192.168.10.0/24

Definizione dei domini AI

acl domini_ai dstdomain .chatgpt.com .openai.com .github.com/copilot

Definizione dell'orario di blocco (Lunedì-Venerdì, 08:00-13:00)

acl orario_scolastico time MTWHF 08:00-13:00

Regola di blocco

http_access deny lab_informatica domini_ai orario_scolastico
http_access allow lab_informatica
```

Automazione tramite API / Scripting
In contesti avanzati con NGFW dotati di API REST, si sviluppa uno script (es. in Python) eseguito tramite Cron job su un server di management. Lo script interroga il registro elettronico o un database degli orari scolastici e invia chiamate API al firewall per abilitare (enable: true) o disabilitare (enable: false) la regola di blocco dell'Application Control in tempo reale, garantendo che lo sblocco avvenga automaticamente al termine dell'ora di laboratorio.

Seconda parte

PROPOSTA DI SOLUZIONE — Seconda Prova di Maturità
Sistemi e Reti, Anno 2026
Svolgimento di due quesiti a scelta della Seconda Parte (Quesito I e Quesito IV), nel rispetto delle indicazioni della traccia.

Quesito I

Analisi delle soluzioni di archiviazione "on premise" e "cloud-based" per i dati BIM.

Si richiede di individuare e descrivere le differenze tra le architetture di storage locali (on premise) e basate su cloud, valutandone vantaggi e svantaggi in relazione all'archiviazione di nuvole di punti, immagini timelapse e log dei sensori.

1. Soluzione "On Premise"
L'infrastruttura on premise prevede l'installazione e la gestione di server fisici e apparati di storage (NAS - Network Attached Storage o SAN - Storage Area Network) direttamente presso la sede centrale della società.

• Vantaggi:
  • Controllo totale e Privacy: I dati risiedono fisicamente sui server aziendali, garantendo la massima aderenza alle policy di sicurezza interne e alle normative sulla protezione dei dati.
  • Velocità di accesso locale: Gli operatori in sede centrale che utilizzano i software BIM beneficiano di un accesso ai dati a velocità LAN (es. $1 \text{ Gbps}$ o $10 \text{ Gbps}$), fondamentale per la manipolazione di file di grandi dimensioni come le nuvole di punti 3D.
• Svantaggi:
  • Costi iniziali (CAPEX): Elevato investimento iniziale per l'acquisto di hardware, licenze e infrastrutture di raffreddamento/alimentazione.
  • Scalabilità limitata: L'aumento dello spazio di archiviazione richiede l'acquisto e l'installazione di nuovi dischi o server.
  • Collo di bottiglia per l'accesso remoto: I cantieri devono inviare i dati tramite VPN verso la sede. Essendo la sede dotata di una connessione WAN datata (ADSL), la banda in upload/download della sede rappresenterà un limite critico per il trasferimento dei dati dai cantieri.

2. Soluzione "Cloud-based"
L'infrastruttura cloud-based prevede l'utilizzo di servizi di storage forniti da provider esterni (es. AWS S3, Microsoft Azure Blob Storage, Google Cloud Storage) accessibili via Internet tramite modelli IaaS (Infrastructure as a Service) o SaaS (Software as a Service).

• Vantaggi:
  • Scalabilità elastica e Costi (OPEX): Lo spazio di archiviazione è virtualmente illimitato e si paga solo per l'effettivo utilizzo (modello pay-as-you-go), eliminando i costi di manutenzione hardware.
  • Accessibilità distribuita: I cantieri possono caricare i dati (immagini timelapse, log dei sensori, scansioni) direttamente sul cloud sfruttando la propria connessione Internet (es. 4G/5G o FWA locale), senza sovraccaricare la banda della sede centrale.
  • Disaster Recovery: I provider cloud garantiscono ridondanza geografica nativa e alta affidabilità (SLA elevati).
• Svantaggi:
  • Dipendenza dalla connettività: L'accesso ai dati richiede una connessione Internet costantemente attiva e performante.
  • Latenza per l'elaborazione locale: Scaricare dal cloud nuvole di punti di decine di Gigabyte per l'elaborazione sui client della sede centrale può risultare lento.

3. Proposta di integrazione (Architettura Ibrida)
Per ottimizzare i flussi di lavoro del sistema BIM, si propone un'architettura Hybrid Cloud:
* Cloud Storage: Utilizzato come repository primario per i dati provenienti dai cantieri (flussi video timelapse, log dei sensori IoT) e come backup a lungo termine. I cantieri inviano i dati direttamente al cloud.
* On Premise Storage (NAS in sede): Utilizzato per l'archiviazione operativa dei modelli 3D e delle nuvole di punti in fase di elaborazione. I dati grezzi caricati dai cantieri sul cloud vengono sincronizzati (scaricati) sul NAS della sede durante le ore notturne, permettendo ai tecnici di lavorare il giorno successivo a velocità LAN.

Quesito IV

Analisi del comando SSH e delle regole di reindirizzamento del traffico.

Si richiede di analizzare gli effetti e le finalità del seguente comando impartito da un terminale:
$$ssh\ -p\ 25500\ [email protected]$$
con la premessa che sull'apparato con IP $200.1.1.1$ è configurata una regola di reindirizzamento verso l'IP $172.16.1.100$.

1. Analisi sintattica del comando
* ssh: Invoca il client per il protocollo Secure Shell, utilizzato per l'accesso remoto sicuro e crittografato.
* -p 25500: Specifica che la connessione TCP deve essere stabilita sulla porta di destinazione $25500$, anziché sulla porta standard di default (TCP $22$).
* administrator: È lo username dell'account con cui si intende effettuare l'autenticazione sul sistema remoto.
* 200.1.1.1: È l'indirizzo IP pubblico di destinazione (presumibilmente l'interfaccia WAN del router/firewall della sede centrale).

2. Meccanismo di rete (Port Forwarding / DNAT)
L'indirizzo $200.1.1.1$ è un IP pubblico instradabile su Internet, mentre l'indirizzo $172.16.1.100$ appartiene alla classe di indirizzamento privato (RFC 1918).
Il dispositivo all'indirizzo $200.1.1.1$ (router o firewall) implementa una regola di Destination NAT (DNAT), comunemente nota come Port Forwarding.
Quando il router riceve un pacchetto TCP sull'interfaccia pubblica con IP destinazione $200.1.1.1$ e porta destinazione $25500$, il processo di traduzione interviene modificando l'header del pacchetto:
* L'IP di destinazione viene riscritto da $200.1.1.1$ a $172.16.1.100$.
* La porta di destinazione viene tipicamente traslata dalla $25500$ alla porta standard del servizio SSH (TCP $22$) in ascolto sul server interno (tecnica di Port Translation).

flowchart LR
    A((Client Remoto)) -- "IP Dest: 200.1.1.1\nPorta Dest: 25500" --> B["Router / Firewall\n(IP WAN: 200.1.1.1)"]
    B -- "DNAT (Port Forwarding)\nIP Dest: 172.16.1.100\nPorta Dest: 22" --> C["Server Interno\n(IP LAN: 172.16.1.100)"]
    style B fill:#f9f,stroke:#333,stroke-width:2px

3. Effetti del comando
L'esecuzione del comando instaura un tunnel crittografato end-to-end tra il client remoto e il server interno situato nella LAN (IP $172.16.1.100$). Il client remoto riceverà il prompt di autenticazione (richiesta password o verifica della chiave asimmetrica) generato dal demone SSH del server interno, non dal router. Una volta autenticato, l'utente avrà accesso a una shell a riga di comando sul dispositivo $172.16.1.100$ con i privilegi dell'utente administrator.

4. Finalità dell'utilizzo
Questa configurazione risponde a due finalità principali:
* Amministrazione remota: Permette a un amministratore di sistema (o a un tecnico dal cantiere) di accedere e gestire un server situato nella rete privata della sede centrale attraverso Internet, superando il confine del NAT.
* Sicurezza (Security through obscurity): Esponendo il servizio SSH su una porta non standard ad alto numero (es. $25500$) anziché sulla porta $22$, si riduce drasticamente il volume di traffico generato da bot automatizzati e script di brute-force che scansionano costantemente la rete pubblica alla ricerca di servizi SSH vulnerabili sulle porte di default.

II

PROPOSTA DI SOLUZIONE — Seconda Prova di Maturità
Sistemi e Reti, 2026
Svolgimento del Quesito II: Misure di sicurezza informatica e continuità trasmissiva per l'infrastruttura BIM.

Ipotesi aggiuntive:
Si assume che la sede centrale sia stata preventivamente dotata di connettività a banda ultralarga (es. $FTTH$), superando il preesistente collegamento $ADSL$ citato nella prima parte della traccia, per poter supportare il traffico generato dai cantieri. Si assume inoltre che il traffico critico includa sia i dati massivi (nuvole di punti, video 4K) sia i dati a bassa latenza (allarmi dei sensori di sicurezza).

Quesito II

Il quesito richiede di definire le misure di sicurezza informatica (escludendo l'autenticazione) per la sede centrale, per i cantieri e per il canale di comunicazione tra essi, includendo le strategie per garantire la continuità trasmissiva.

1. Misure di sicurezza nella Sede Centrale
Per proteggere i server repository BIM e i sistemi di elaborazione interni, si implementano le seguenti misure:
* Sicurezza Perimetrale: Adozione di un $NGFW$ (Next-Generation Firewall) operante a livello applicativo (Livello 7 del modello ISO/OSI). Il dispositivo deve integrare funzionalità di $IDS/IPS$ (Intrusion Detection and Prevention System) per l'ispezione profonda dei pacchetti ($DPI$) e il blocco di traffico anomalo o malevolo.
* Segmentazione di Rete: Suddivisione della $LAN$ in reti virtuali isolate tramite protocollo $IEEE\ 802.1Q$. Si configurano $VLAN$ distinte: $VLAN\ Server\ BIM$, $VLAN\ Uffici$, $VLAN\ Ospiti$. Il routing inter-VLAN è demandato al firewall centrale, che applica rigide $ACL$ (Access Control List) per consentire solo il traffico strettamente necessario.
* Protezione End-point e Dati: Installazione di agenti $EDR$ (Endpoint Detection and Response) su tutte le workstation e i server. I dati archiviati sui server (Data at Rest) sono protetti tramite cifratura dei dischi con standard $AES-256$.

2. Misure di sicurezza nei Cantieri
Data l'esposizione fisica e ambientale dei dispositivi in cantiere, si adottano misure specifiche per l'Edge computing:
* Sicurezza Perimetrale Locale: Installazione di un apparato di frontiera (Router/Firewall) di tipo rugged (resistente a polvere, urti e sbalzi termici) per filtrare il traffico tra la rete del cantiere e l'esterno.
* Sicurezza Wireless: Le comunicazioni $WLAN$ per i tablet e le fotocamere timelapse sono protette tramite protocollo $WPA3$. Si abilita la funzione di $Client\ Isolation$ per impedire la comunicazione diretta tra i dispositivi wireless, mitigando il rischio di propagazione di malware in caso di compromissione di un singolo tablet.
* Isolamento IoT: I sensori di sicurezza (gas, fumi, vibrazioni) vengono attestati su una rete logica dedicata e isolata dal traffico ad alta intensità di banda, garantendo priorità e sicurezza ai pacchetti di allarme.
* Gestione Dispositivi Mobili: Adozione di una piattaforma $MDM$ (Mobile Device Management) per i tablet rugged. L'MDM impone la cifratura della memoria locale e abilita la funzione di $Remote\ Wipe$ (cancellazione remota) in caso di furto o smarrimento del dispositivo nel cantiere.

3. Sicurezza del canale di comunicazione remota (Cantiere - Sede)
Per garantire la riservatezza (Confidentiality) e l'integrità (Integrity) dei dati in transito (Data in Transit) su reti pubbliche (Internet), si implementa una rete privata virtuale.
* VPN Site-to-Site: Si instaura un tunnel $VPN$ permanente tra il firewall del cantiere e il firewall della sede centrale.
* Protocolli e Algoritmi: Si utilizza la suite $IPsec$ in modalità $Tunnel$. Per la cifratura del payload ($ESP$) si adotta l'algoritmo simmetrico $AES-256$. Per garantire l'integrità dei dati e l'anti-replay (fondamentale per i log dei sensori di sicurezza) si utilizza l'algoritmo di hashing $SHA-256$.

4. Continuità trasmissiva (High Availability e Fault Tolerance)
Per garantire che il flusso di dati (in particolare le notifiche di allarme in tempo reale) non subisca interruzioni, si progetta un'architettura ridondata sia a livello di link fisico che di apparati.
* Ridondanza dei canali in Sede Centrale: Si implementa un approccio $Multi-WAN$. Al collegamento primario ad alte prestazioni (es. $FTTH$) si affianca un collegamento di backup su tecnologia trasmissiva differente (es. $FWA$ o $FTTC$) per evitare il Single Point of Failure a livello di ISP o di infrastruttura cablata.
* Ridondanza dei canali nel Cantiere: Il router rugged del cantiere viene equipaggiato con moduli $Multi-WAN$. Si utilizza una connessione primaria basata su rete radiomobile $5G/4G\ LTE$ e una connessione secondaria di backup (es. connessione satellitare LEO o una seconda SIM $LTE$ di un operatore differente).
* Gestione del Failover: I firewall di sede e di cantiere sono configurati in logica $SD-WAN$ (Software-Defined WAN). Il sistema monitora costantemente la latenza, il jitter e la perdita di pacchetti sui link (tramite protocolli come $IP\ SLA$). In caso di degrado o caduta del link primario, il traffico viene instradato automaticamente sul link di backup in tempi nell'ordine dei millisecondi ($Automatic\ Failover$).
* Ridondanza Hardware (Sede Centrale): Per evitare interruzioni dovute a guasti hardware, si installano due $NGFW$ identici in configurazione cluster $Active/Passive$, gestiti tramite protocolli di ridondanza del gateway come $VRRP$ (Virtual Router Redundancy Protocol). Se il firewall primario si guasta, il secondario assume immediatamente l'indirizzo IP virtuale del gateway, mantenendo attivi i tunnel $IPsec$.

flowchart TD
    subgraph Sede_Centrale ["Sede Centrale (HQ)"]
        FW_HQ_A["NGFW Primario (Active)"]
        FW_HQ_B["NGFW Backup (Passive) - VRRP"]
        LAN_HQ["LAN Sede (VLAN Segmentate)"]
        FW_HQ_A --- LAN_HQ
        FW_HQ_B --- LAN_HQ
    end

    subgraph Cantiere ["Cantiere Edile"]
        FW_CANT["Router/Firewall Rugged"]
        WLAN_CANT["WLAN WPA3 (Tablet/Cam)"]
        IoT_CANT["Rete IoT (Sensori Sicurezza)"]
        FW_CANT --- WLAN_CANT
        FW_CANT --- IoT_CANT
    end

    WAN1_HQ["Link Primario (FTTH)"]
    WAN2_HQ["Link Backup (FWA)"]

    WAN1_CANT["Link Primario (5G)"]
    WAN2_CANT["Link Backup (Satellitare)"]

    FW_HQ_A --- WAN1_HQ
    FW_HQ_A --- WAN2_HQ
    FW_HQ_B -.- WAN1_HQ
    FW_HQ_B -.- WAN2_HQ

    FW_CANT --- WAN1_CANT
    FW_CANT --- WAN2_CANT

    WAN1_HQ --- INTERNET((Internet))
    WAN2_HQ --- INTERNET
    WAN1_CANT --- INTERNET
    WAN2_CANT --- INTERNET

    FW_CANT <== "Tunnel VPN IPsec (AES-256 / SHA-256)\nFailover SD-WAN automatico" ===> FW_HQ_A

Prima Parte

PROPOSTA DI SOLUZIONE — Seconda Prova di Maturità
Disciplina: Sistemi e Reti, 2026
Risoluzione della Prima Parte: Progetto di infrastruttura di rete per cantieri e sede centrale (BIM).

Ipotesi aggiuntive:
Per il dimensionamento dell'infrastruttura si assumono i seguenti parametri operativi:
- Numero massimo di cantieri attivi contemporaneamente: $5$.
- Dotazione per singolo cantiere: $5$ tablet rugged, $4$ fotocamere timelapse, $20$ sensori IoT (sicurezza/ambientali).
- Volume di dati generato giornalmente per cantiere: $20\text{ GB}$ per nuvole di punti (BIM), $5\text{ GB}$ per fotogrammi timelapse.
- Trasferimento dati concentrato in una finestra lavorativa di $8\text{ ore}$.
- Sede centrale: $50$ postazioni di lavoro afferenti agli uffici tecnici.

Punto 1) Progetto generale dell'infrastruttura di rete nel cantiere

L'infrastruttura del cantiere deve essere temporanea, modulare e garantire la segmentazione del traffico.

Apparati:
- Router/Firewall 5G: Funge da gateway verso la WAN e terminatore del tunnel VPN verso la sede centrale.
- Switch PoE (Power over Ethernet): Fornisce connettività cablata e alimentazione ad Access Point e fotocamere.
- Access Point Wi-Fi 6 (802.11ax): Garantiscono connettività wireless ad alta capacità per i tablet rugged.
- Gateway IoT (LoRaWAN o Zigbee): Raccoglie i dati dai sensori a basso consumo e li instrada sulla rete IP.
- Edge Server / NAS locale: Svolge la funzione di buffer temporaneo per i dati BIM/timelapse in caso di caduta della connessione WAN e gestisce gli allarmi locali dei sensori.

Canali e Protocolli:
- Wired: Cablaggio UTP Cat 6/6a per i collegamenti Switch-AP, Switch-Server e Switch-Fotocamere.
- Wireless: Wi-Fi (WPA3) per i tablet; LoRaWAN per i sensori ambientali (copertura estesa, basso consumo).
- Protocolli applicativi: HTTPS/FTPS per trasferimento file BIM, RTSP per streaming/fotogrammi, MQTT per la telemetria dei sensori.

Schema di indirizzamento (Subnetting):
Si adotta la classe di indirizzi privati $192.168.X.0/24$ (dove $X$ identifica il cantiere, es. $X=10$ per il Cantiere 1), suddivisa in VLAN per separare i domini di broadcast e applicare policy di sicurezza.
Si utilizza la subnet $192.168.10.0/24$ partizionata con CIDR $/27$ (30 host utili per subnet).

Schema grafico dell'infrastruttura di cantiere:

flowchart TD
    WAN((Rete Internet)) <--> |Connessione 5G / VPN| R[Router / Firewall 5G]
    R <--> |Trunk 802.1Q| SW[Switch PoE Layer 2]
    
    SW <--> |VLAN 10| SVR[(Edge Server / NAS Locale)]
    SW <--> |VLAN 30 - PoE| CAM1[Fotocamera Timelapse 1]
    SW <--> |VLAN 30 - PoE| CAM2[Fotocamera Timelapse 2]
    
    SW <--> |VLAN 20 - PoE| AP[Access Point Wi-Fi 6]
    AP -.- |Wireless| TAB1[Tablet Rugged 1]
    AP -.- |Wireless| TAB2[Tablet Rugged 2]
    
    SW <--> |VLAN 40| IOT[Gateway IoT LoRaWAN]
    IOT -.- |Wireless LoRa| SENS1((Sensore Gas))
    IOT -.- |Wireless LoRa| SENS2((Sensore Vibrazioni))

Punto 2) Rete pre-esistente in sede centrale e potenziamento

Stato attuale:
La rete pre-esistente è descritta come una LAN per uffici tecnici con accesso a Internet tramite router ADSL. Questa tecnologia (asimmetrica, con velocità di upload tipicamente limitata a $1\text{ Mbps}$) è totalmente inadeguata per ricevere flussi di dati massivi (nuvole di punti) e terminare connessioni VPN multiple.

Interventi di potenziamento necessari:
1. Aggiornamento WAN: Sostituzione della linea ADSL con una connessione FTTH (Fiber to the Home/Enterprise) o linea dedicata simmetrica con capacità minima di $1\text{ Gbps}$, essenziale per supportare il traffico convergente dai cantieri e l'accesso cloud.
2. Sicurezza Perimetrale: Inserimento di un Next-Generation Firewall (NGFW) in sostituzione del vecchio router. Il NGFW gestirà il routing, l'Intrusion Prevention System (IPS) e fungerà da concentratore VPN (IPsec) per i cantieri.
3. Core Network: Implementazione di uno switch Core Layer 3 per il routing inter-VLAN ad alte prestazioni, collegato a switch di accesso Gigabit/10G per le postazioni CAD/BIM.
4. Infrastruttura Server/Storage: Creazione di una Server Farm interna (o adozione di un'architettura ibrida) comprendente:
- Un sistema SAN (Storage Area Network) ad alta capacità e ridondanza (RAID 6 o 10) per il repository dei modelli BIM e dei video timelapse.
- Server per l'autenticazione centralizzata (Active Directory / RADIUS).
- Server di log (Syslog/SIEM) per la storicizzazione dei dati dei sensori di sicurezza.

Punto 3) Canali di comunicazione Cantiere-Sede e stima capacità

Tipologia di canale:
Si sceglie di implementare una VPN IPsec Site-to-Site su rete pubblica Internet. Essendo i cantieri temporanei, si adotta una connettività WAN primaria basata su rete radiomobile 5G (o 4G LTE Advanced in assenza di copertura), che garantisce rapidità di installazione e banda sufficiente.

Stima della capacità trasmissiva (Throughput):
Calcoliamo il traffico generato da un singolo cantiere in una giornata lavorativa di $T = 8\text{ ore} = 28800\text{ s}$.
- Dati BIM (nuvole di punti): $D_{BIM} = 20\text{ GB}$
- Dati Timelapse: $D_{CAM} = 5\text{ GB}$
- Volume totale: $D_{TOT} = 25\text{ GB}$

Convertiamo il volume in Megabit:
$$D_{TOT(Mbit)} = 25 \times 1024 \times 8 = 204800\text{ Mbit}$$

Calcoliamo il throughput netto richiesto in upload dal cantiere:
$$Th_{netto} = \frac{204800\text{ Mbit}}{28800\text{ s}} \approx 7,11\text{ Mbps}$$

Considerando l'overhead dei protocolli (TCP/IP, crittografia IPsec) e il traffico real-time dei sensori IoT (stimato in $< 0,5\text{ Mbps}$), si applica un fattore di maggiorazione del $20\%$:
$$Th_{lordo} = 7,11 \times 1,2 \approx 8,53\text{ Mbps}$$

Conclusione sul dimensionamento:
- Cantiere: Una connessione 5G standard offre velocità di upload ampiamente superiori a $10\text{ Mbps}$, risultando idonea. L'apparato scelto è un Router 5G industriale con supporto VPN hardware.
- Sede Centrale: Dovendo aggregare il traffico di $5$ cantieri simultanei, la banda minima garantita in download deve essere $5 \times 8,53 = 42,65\text{ Mbps}$. La linea FTTH da $1\text{ Gbps}$ proposta al Punto 2 soddisfa ampiamente il requisito.

Punto 4) Autenticazione, protocolli e servizi

Per garantire l'accesso sicuro ai sistemi della sede centrale, si implementa un'architettura di autenticazione centralizzata basata su Active Directory (AD).

Autenticazione nella Sede Centrale (Locale):
- Protocolli e Servizi: Si utilizza il protocollo Kerberos/LDAP per il Single Sign-On (SSO) degli operatori sulle postazioni di lavoro.
- Accesso alla rete: Implementazione dello standard IEEE 802.1X. Gli switch di accesso fungono da Authenticator e interrogano un server RADIUS (NPS) per verificare le credenziali dell'utente o il certificato della macchina prima di abilitare la porta di rete.

Autenticazione dai Cantieri (Remoto):
- Livello Apparato (Tablet/Sensori): I tablet si autenticano alla rete Wi-Fi del cantiere tramite WPA3-Enterprise. L'Access Point locale inoltra le richieste EAP al server RADIUS in sede centrale attraverso il tunnel VPN. I sensori IoT utilizzano chiavi pre-condivise (PSK) o certificati X.509 gestiti dal Gateway locale.
- Livello Operatore (Accesso ai software BIM): Per l'accesso ai repository BIM e ai sistemi aziendali dai tablet, si richiede l'autenticazione tramite protocollo HTTPS/TLS 1.3 combinata con MFA (Multi-Factor Authentication). L'operatore inserisce le credenziali AD (tramite protocollo SAML 2.0 o OAuth 2.0 se i servizi sono esposti via web) e conferma l'accesso tramite un token OTP generato da un'app su smartphone aziendale.

Vuoi la soluzione della tua prova?

Carica la tua prova scritta (PDF o foto) sul Risolutore Prove AI: risolve tutti i quesiti con grafici e ti consegna il PDF completo.