IoT - ecosistema, architettura e sicurezza - Anno 5 Modulo 4 Lezione 7

Anno 5 · Modulo 4 · Lezione 7

A cura di Prof. Giagnotti · Sistemi e Reti – Wireless e IoT

IoT - ecosistema, architettura e sicurezza

Dai 50 miliardi di dispositivi al modello a 4 livelli: come progettare, connettere e proteggere un ecosistema IoT reale tra LoRaWAN, MQTT, 5G mMTC e defense in depth — con casi di istituto, errori tipici e checklist operative.

📚 Modulo 4🌐 IoT🔒 Sicurezza📡 LPWAN

🎯 Obiettivi di apprendimento

✓Definire l'IoT e spiegare perché viene descritto come un ecosistema, costruendo un confronto sistematico con un ecosistema biologico

✓Descrivere l'architettura a quattro livelli di un sistema IoT spiegando il ruolo di ciascun livello e dei componenti che vi operano

✓Riconoscere e descrivere i principali campi di applicazione dell'IoT indicando le tecnologie wireless e i protocolli tipicamente usati in ciascuno

✓Identificare le principali minacce alla sicurezza IoT e le contromisure appropriate, applicando il modello defense in depth a un sistema IoT reale

📑 Indice

01Introduzione — il mondo che si connette 02Ecosistema IoT — confronto biologico 03Architettura a 4 livelli 04Campi di applicazione e tecnologie 05Sicurezza IoT — minacce e defense in depth 06Protocolli LPWAN e cloud — LoRaWAN, MQTT, CoAP 07Verifica / Esercizio guidato 08Riepilogo

Introduzione — il mondo che si connette

Ogni giorno attiviamo il riscaldamento dal telefono prima di tornare a casa. Il contatore del gas invia automaticamente la lettura alla società fornitrice. Nella fabbrica, un sensore vibrazionale rileva un'anomalia nel motore ore prima che si guasti. In ospedale, il braccialetto del paziente monitora il battito cardiaco ogni secondo e allerta il medico se supera una soglia critica.

Tutti questi scenari condividono un elemento comune: oggetti fisici del mondo reale — termostati, contatori, motori, braccialetti — connessi a Internet, capaci di raccogliere dati, comunicarli e ricevere istruzioni. Questo è l'Internet of Things.

📌 Definizione – IoT

L'Internet of Things (IoT) è la rete di oggetti fisici dotati di sensori, software e connettività di rete, capaci di raccogliere e scambiare dati con altri dispositivi e sistemi attraverso Internet — senza richiedere interazione umana diretta. Secondo le stime, entro il 2030 saranno connessi oltre 50 miliardi di dispositivi IoT nel mondo.

L'IoT non è una tecnologia singola ma la convergenza di più innovazioni che hanno raggiunto la maturità contemporaneamente: miniaturizzazione dei sensori, riduzione del costo dei microcontrollori, proliferazione della connettività wireless, disponibilità del cloud computing per l'elaborazione e lo storage dei dati.

🏫 Esempio istituto – cosa diventa IoT domani

Laboratorio domotica: termostato Zigbee, prese smart con misura consumo, sensore CO2 per ricambio aria. Il tutto su VLAN IoT 100 isolata. Dashboard su Raspberry Pi con Node-RED legge MQTT e decide accensione caldaia. Senza cloud esterno: privacy garantita, latenza < 50 ms, no dipendenza Internet.

💡 Tip docente – Come far capire IoT al volo

Parti da 3 oggetti che gli studenti hanno in tasca: cuffie, smartwatch, smartphone. Chiedi: cosa misura? Cosa trasmette? A chi? Questo è già IoT consumer. Poi sposta scala: stesso schema ma per 10.000 contatori acqua di una città → LPWAN. Il salto è solo raggio e batteria, non concetto.

L'Ecosistema IoT

Perché si parla di "ecosistema"

Il termine ecosistema non è usato per analogia superficiale. Un sistema IoT complesso presenta caratteristiche strutturalmente simili a un ecosistema biologico: non è la somma di componenti isolati ma un sistema in cui entità eterogenee interagiscono continuamente, si influenzano a vicenda e si adattano all'ambiente circostante. Rimuovere o guastare un componente produce effetti a cascata sull'intero sistema — esattamente come l'estinzione di una specie altera l'equilibrio di un ecosistema naturale.

Dimensione	🌿 Ecosistema Biologico	📡 Ecosistema IoT
Definizione	Sistema dinamico formato da organismi viventi (biocenosi) e ambiente fisico (biotopo), interagiscono tramite flussi di energia e materia	Sistema dinamico di dispositivi fisici connessi, reti, piattaforme software e utenti che interagiscono tramite flussi di dati e comandi
Componenti	Produttori (piante), Consumatori (erbivori, carnivori), Decompositori (batteri, funghi), Ambiente abiotico	Sensori/Attuatori (raccolgono/agiscono), Gateway (aggregano), Piattaforma cloud (elabora), Applicazioni (fruiscono)
Interazioni	Predazione, simbiosi, competizione, catene alimentari — ogni specie influenza quelle con cui interagisce	Comunicazioni M2M, protocolli MQTT/HTTP/CoAP, API calls — un guasto si propaga lungo la catena
Equilibrio	Homeostasi — meccanismi di autoregolazione mantengono le popolazioni in equilibrio	Ottimizzazione continua — algoritmi ML regolano parametri, es. thermostat che impara le abitudini
Interconnessione	Reti trofiche complesse — nessun organismo isolato, scomparsa specie chiave destabilizza sistema	Reti multi-protocollo — dati fluiscono da sensori a app; gateway guasto isola cluster; cloud down paralizza migliaia device
Adattabilità	Evoluzione per selezione naturale su scala generazionale	OTA firmware update, scaling cloud, nuovi protocolli — adattamento in ore, non generazioni
Vulnerabilità	Specie invasive, inquinamento — biodiversità protegge	Credenziali default, botnet Mirai, ransomware OT — diversità protocolli e segmentazione protegge

Produttori → Sensori

Generano dati

Come le piante convertono sole in energia, i sensori convertono fenomeno fisico in byte digitali.

Consumatori → Applicazioni

Usano informazioni

Dashboard, ERP, app cittadino: consumano dati per decidere. Dati corrotti → decisioni errate.

Decompositori → Manutenzione

Riciclo e pulizia

OTA update, decommissioning sicuro, cancellazione chiavi. Senza riciclo, ecosistema pieno di device zombie.

Architettura a quattro livelli di un sistema IoT

Un sistema IoT non è una rete piatta: è organizzato in livelli logici che separano responsabilità, permettono scalabilità e isolamento dei guasti. Il modello più usato è a 4 livelli.

L1 – Percezione (Dispositivi)

Mondo fisico: sensori (temperatura, umidità, vibrazione, GPS) e attuatori (relè, motori, valvole). MCU a 8-32 MHz, 2-256 KB RAM, batteria. Comunicano via BLE, Zigbee, LoRa.

L2 – Connettività (Gateway / Rete)

Gateway aggrega L1 → IP. Converte Zigbee/MQTT-SN → MQTT/IP, filtra, bufferizza. Rete: LoRaWAN, NB-IoT, Wi-Fi, 5G. Punto ideale per IDS e firewall.

L3 – Elaborazione (Edge / Cloud)

Broker MQTT, time-series DB (InfluxDB), stream processing, ML. Edge per latenza critica (freno auto), cloud per storico e training.

L4 – Applicazione (Utente / Business)

Dashboard, app mobile, integrazione ERP/MES, API per terzi. Qui MFA, RBAC, audit log, GDPR.

💡 Tip docente – Disegna livelli live

Fai disegnare agli studenti un caso: contatore acqua smart. L1 = sensore flusso + LoRa radio a batteria 10 anni. L2 = gateway LoRaWAN sul tetto istituto. L3 = InfluxDB + alert se consumo anomalo. L4 = app segreteria. Dove metti TLS? Dove MFA? TLS al L2 (gateway→cloud), MFA al L4, OTA dal L3 verso L1 via gateway.

Caso reale – manutenzione predittiva in fabbrica

🏭 IIoT – vibrazione motore

Scenario: Motore 15kW in linea produzione. Sensore ADXL345 (L1) campiona 1.6kHz, gateway (L2) fa FFT locale e invia solo spettro via MQTT, cloud (L3) confronta con baseline ML, dashboard (L4) avvisa 48h prima del guasto. Risparmio: fermo non pianificato evitato = 12.000€.

Tecnologie: OPC-UA con PLC Siemens, MQTT per cloud, 5G privato <10 ms. Sicurezza: OPC-UA certificati, VLAN OT isolata, firmware firmato.

C / Arduino – L1 sensore low power

#include <DHT.h>
#define DHTPIN 2
DHT dht(DHTPIN, DHT22);
void setup(){ dht.begin(); }
void loop(){
  float t = dht.readTemperature();
  float h = dht.readHumidity();
  char payload[32];
  snprintf(payload, sizeof(payload), "{"t":%.1f,"h":%.1f}", t,h);
  mqtt_publish("istituto/aula3B/clima", payload, 1);
  deepSleep(600);
}

Campi di applicazione e tecnologie associate

L'IoT non è più un unico mercato ma decine di verticali con requisiti opposti: una pillola elettronica ha bisogno di sicurezza estrema e batteria microscopica, un magazzino automatizzato di banda e latenza.

🏭 Industria 4.0

IIoT • Digital Twin

Vibrazione, temperatura, consumo, robot. Protocolli: OPC-UA, MQTT, ModbusReti: Wi-Fi industriale, 5G privato

🌾 Smart Farming

Agricoltura precisione

Umidità suolo, pH, irrigazione, droni. Protocolli: MQTT, CoAP
Reti: LoRaWAN, Sigfox

⚡ Smart Grid

Energia

Smart meter gas/acqua/luce, gestione domanda. Protocolli: DLMS/COSEM, MQTT
Reti: NB-IoT, PLC

🏪 Smart Retail

Logistica scaffale

Scaffali peso, beacon BLE offerte, catena freddo. Protocolli: MQTT, HTTP REST
Reti: BLE beacon, Wi-Fi, RFID UHF

🏙️ Smart City

Città

Luce adattiva, traffico, parcheggi, rifiuti, aria. Protocolli: MQTT, CoAP, FIWARE
Reti: LoRaWAN, NB-IoT, 5G mMTC

🏥 IoMT

Sanità

ECG remoto, SpO2, pompe infusione. Protocolli: HL7 FHIR, MQTT
Reti: BLE, Wi-Fi

🚛 Logistica

Supply chain

GPS veicoli, catena freddo, AGV robot, RFID pallet. Protocolli: MQTT, AMQP
Reti: GNSS, 4G, RFID UHF, BLE

🚗 Connected Vehicle

V2X

V2X, OBD diagnostica, OTA firmware, guida assistita. Protocolli: MQTT, AMQP, DSRC
Reti: 4G/5G C-V2X, 802.11p

🏠 Consumer

Domotica

Termostati, luci, assistenti vocali, serrature. Protocolli: Matter, Zigbee, Z-Wave, MQTT
Reti: Wi-Fi, BLE, Thread

Settore	Tecnologia wireless tipica	Protocollo applicativo	Requisito chiave
Agricoltura precisione	LoRaWAN 868 MHz 15 km	MQTT / CoAP	Batteria 10 anni
Magazzino AGV	5G privato URLLC	OPC-UA / MQTT	Latenza <20 ms
Domotica aula	Zigbee mesh 2.4 GHz	Zigbee cluster + MQTT	Self-healing, costo basso
Contatore acqua città	NB-IoT licenziato	CoAP / DLMS	QoS garantita, 10k/km²
Wearable sanitario	BLE 5 LE	GATT + MQTT	Consumo uA, sicurezza

🏫 Esempio classe – Smart classroom completa

Obiettivo: Aula 3B autonoma. L1: BME280, CO2 MH-Z19, PIR presenza, presa Zigbee. L2: Gateway Zigbee2MQTT + ESP32 LoRa per contatore acqua. L3: Raspberry Pi 4 Node-RED: CO2 > 1000 ppm → VMC ON, nessuno 15 min → luci OFF. L4: Grafana tablet ingresso. Sicurezza: tutto locale, VLAN 100, no cloud cinese.

Sicurezza nei sistemi IoT

La sicurezza IoT è uno dei problemi più complessi dell'informatica moderna. I dispositivi introducono una superficie di attacco enormemente estesa, composta spesso da hardware con risorse limitate, firmware non aggiornabile, password predefinite e protocolli legacy non cifrati.

⚠️ Vincolo strutturale – non è pigrizia, è fisica

CPU limitata: MCU 8-16 MHz non regge TLS pieno. RAM ridotta: 2-8 KB → protocolli leggeri CoAP, MQTT-SN che sacrificano sicurezza. Batteria: ogni operazione AES costa minuti di vita. Soluzione: offload su gateway e uso PSK/DTLS leggero.

Le principali minacce

🔓 Credenziali predefinite

Botnet Mirai 2016: 600.000 telecamere/router admin/admin → DDoS 1 Tbps. Lezione: mai lasciare default.

📡 Comunicazioni in chiaro

MQTT senza TLS (1883), HTTP, Telnet. Attaccante stessa rete intercetta e inietta comandi verso attuatori.

🔧 Firmware obsoleto

Telecamere 10 anni fa con CVE 2017 non patchabile. Ciclo vita device 10-20 anni vs supporto vendor 2-3 anni.

🌐 Superficie estesa

Ogni device entry point. Telecamera compromessa → foothold OT → SCADA impianto. Isolamento fondamentale.

🔄 Supply chain

Firmware malevolo in fabbrica, backdoor hardware. Difficile rilevamento.

🧠 Privacy leakage

Termostato rivela quando sei a casa, baby monitor diventa spy-cam. GDPR: minimizza dati.

Defense in Depth – contromisure per livello

Livello	Obiettivo	Contromisure pratiche
L4 Applicazioni	Accesso utente	MFA, RBAC, audit log immutabile, API gateway + rate limiting + WAF
L3 Cloud/Edge	Trust device	X.509 / JWT, cifratura at-rest, tenant isolation, anomaly ML, firmware firmato
L2 Gateway/Rete	Isolamento	VLAN 100 IoT dedicata, firewall only MQTT/443 outbound, IDS/IPS, MQTT over TLS 8883
L1 Dispositivi	Hardening	Cambia default, disabilita UART/JTAG, secure boot, TPM/secure element, OTA firmato

📌 Regola d'oro – IoT mai in LAN aziendale

Dispositivi IoT su VLAN separata, isolata con firewall che permette solo traffico necessario. Compromesso? Resta in VLAN IoT senza accesso a server aziendali. [Sensori] → VLAN 100 IoT → Firewall only MQTT/443 → Cloud IoT. ❌ No accesso diretto IoT → VLAN 10 server, VLAN 20 PC utenti.

Standard di riferimento

OWASP IoT Top 10

Vulnerabilità critiche

Password deboli, interfacce insicure, mancanza cifratura. Checklist base audit.

ETSI EN 303 645

Standard EU consumer

13 requisiti: no password universali default, policy update, protezione dati. Base Cyber Resilience Act.

NIST SP 800-213

Guida federale

Baseline capability e gestione rischio IoT enterprise.

IEC 62443

Industriale IIoT

Security Levels SL1-SL4 e zone/conduit per segmentazione OT.

🏫 Caso reale – Istituto vittima Mirai

Settembre 2023: NVR videosorveglianza istituto con password 123456 usato per DDoS. IP bloccato da ISP. Soluzione: reset, password 20 char, VLAN 100 isolata con firewall only NTP + cloud, update firmware. Inventaria device IoT come PC.

Protocolli LPWAN e cloud — LoRaWAN, MQTT, CoAP, 5G

LPWAN (Low Power Wide Area Network) è la risposta per sensori che devono parlare a km con batteria anni: contatori acqua, tracciamento bestiame, allagamenti.

Confronto protocolli IoT

MQTT: pub/sub su TCP, leggero, QoS 0/1/2, broker centrale → ideale cloud. CoAP: REST su UDP, simile HTTP ma binario, DTLS → ideale constrained. LoRaWAN: star-of-stars, chirp spread 868MHz, AES-128 doppio livello. 5G mMTC / NB-IoT: licenziato, QoS garantita, 1M device/km².

LoRaWAN – OTAA join ESP32

# OTAA – mai ABP in produzione: chiavi hardcoded non ruotano
#include <LoRaWAN.h>
const char* devEui = "70B3D57ED000ABCD";
const char* appEui = "0000000000000001";
const char* appKey = "A0B1C2D3E4F5A0B1C2D3E4F5A0B1C2";
void setup(){
  LoRaWAN.begin(EU868);
  LoRaWAN.setKeysOTAA(devEui, appEui, appKey);
  LoRaWAN.join();
}
void loop(){
  lpp.addTemperature(1, 22.5);
  LoRaWAN.send(lpp.getBuffer(), lpp.getSize());
  LowPower.sleep(600000);
}

MQTT over TLS – Mosquitto X.509

# mosquitto.conf - gateway
listener 8883
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key
require_certificate true
use_identity_as_username true
# client ESP32:
# mosqClient.tls_set(ca_certs="ca.crt", certfile="device.crt", keyfile="device.key")
# publish istituto/aula3B/co2 850 qos 1

CoAP + DTLS PSK per sensori constrained

# CoAP REST su UDP, ideale senza TCP
# GET coap://gateway/temp -> 22.5 C
# PSK DTLS invece di X.509 per risparmiare RAM
coap-client -m post -u "Aula3B-PSK-2026" -k "s3gretaPSK!" coaps://192.168.100.1:5684/co2 -e "850"

5G slicing per IoT critico

# Network Slicing 5G – 3 slice isolate
sliceId: 1 sst: 1 eMBB dnn:internet.istituto qos:5QI=9 best effort
sliceId: 2 sst: 2 URLLC dnn:iot.urllc.istituto qos:5QI=82 latency 10ms 99.999% isolated:true
sliceId: 3 sst: 3 mMTC dnn:iot.mmtc.istituto maxDevices:10000 battery:PSM+eDRX

💡 Tip docente – Demo live 20 min

2 ESP32: uno publish MQTT, l'altro subscriber con LED rosso se >1000 ppm. Mosquitto su Pi. Wireshark: mostra MQTT in chiaro vs TLS 8883. QoS 0 vs 1: stacca Wi-Fi durante publish QoS0 → perso; QoS1 → ritrasmesso.

🚨 Errore comune – ABP vs OTAA LoRaWAN

ABP usa chiavi statiche mai aggiornate: se rubi device, hai chiavi per sempre. OTAA negozia NwkSKey/AppSKey a ogni join con nonce. In produzione usa sempre OTAA + frame counter check.

Verifica / Esercizio guidato

🔬 Progetta l'IoT sicuro dell'istituto – da 0 a cloud

Hai 3 piani, 15 aule, lab meccanico, magazzino, parcheggio, serra 400 m. Richieste: clima aule, conta persone, allarme allagamento, contatori acqua serra, tracciamento attrezzi. Vincoli: budget limitato, VLAN esistenti, open preferred, GDPR.

Ecosistema: mappa dipendenze – produttore, consumatore, decompositore? Se gateway piano 2 down, cosa succede? Resilienza?
Architettura 4 livelli: per ogni esigenza indica L1 device, L2 rete (Zigbee vs LoRaWAN vs NB-IoT), L3 (Mosquitto, InfluxDB, Node-RED rule), L4 (Grafana, Telegram alert). Motiva batteria e portata.
Wireless: perché serra 400 m non Zigbee? Perché LoRaWAN 868 MHz sì? Calcola link budget e SF.
Sicurezza: defense in depth per attrezzi tag BLE – L1 secure boot? L2 VLAN 100 + firewall? L3 X.509? L4 RBAC? Simula furto tag BLE.

✅ Soluzione ragionata

1) Ecosistema & resilienza: Produttori = sensori clima, PIR, flusso acqua, BLE tag. Consumatori = Grafana, alert Telegram, ERP inventario. Decompositori = OTA update, cancellazione chiavi fine anno. Gateway piano2 down → aule isolate: Zigbee mesh self-healing via router piano1 e 3, ma LoRaWAN serra isolata se unico gateway. Soluzione: 2 gateway LoRa overlapping + buffer locale SQLite store-and-forward. Cloud down → edge Node-RED continua regole locali.

2) Mapping: Clima aule BME280+MH-Z19 Zigbee → Zigbee2MQTT → Mosquitto TLS+Influx+Node-RED if CO2>1000→VMC ON → Grafana. Conta persone PIR+ToF → aggregazione presenze anonime GDPR. Allagamento sensore acqua+valvola NC → azione locale diretta chiude valvola anche senza cloud → alert Telegram. Contatori serra LoRa SX1276 batteria 10y → gateway rooftop → costi acqua. Attrezzi BLE beacon battery 2y → gateway BLE per stanza → last-seen + geofence.

3) Tecnologie: Zigbee 100m indoor, non 400m outdoor metallo. LoRaWAN 15km LOS, SF12 -137dBm, batteria 10 anni Tx 20 byte ogni 15 min. Link budget 14 dBm +8 dBi -90dB = -68 dBm sopra sensibilità.

4) Sicurezza furto tag BLE: L1 tag solo ID randomizzato ruota 15 min anti-tracking. L2 gateway con encrypted adv + PSK, VLAN 100 isolata non raggiunge VLAN studenti. L3 Mosquitto X.509, ACL, anomaly ML tag di notte. L4 RBAC studente vede disponibile sì/no, admin vede tutto + MFA + audit WORM. GDPR: presenze anonimizzate 24h. Clonazione rilevata da geofence incoerente.

Riepilogo e concetti chiave

✓Ecosistema, non somma device: produttori sensori, consumatori app, decompositori OTA/decommissioning. Guasto si propaga; biodiversità protegge.

✓Architettura 4 livelli: L1 percezione MCU constrained, L2 gateway/rete VLAN IoT+TLS, L3 edge/cloud broker TSDB ML, L4 app MFA/RBAC/audit.

✓LPWAN vs 5G: LoRaWAN/NB-IoT = km, anni batteria, 50kbps. 5G mMTC 1M device/km², URLLC <10ms IIoT critico. Zigbee/BLE metri mesh.

✓MQTT vs CoAP: MQTT pub/sub TCP TLS 8883 QoS retained cloud. CoAP REST UDP DTLS PSK constrained 2KB RAM. OTAA > ABP LoRaWAN.

✓Sicurezza = segmentazione: regola d'oro VLAN 100 IoT isolata, firewall only outbound, X.509 device, code signing, MFA L4. Mirai: cambia default.

✓Standard: OWASP Top10, ETSI 303 645 no default universali, NIST 800-213, IEC 62443 zone/conduit OT.

✓Regola d'oro progettazione: parti da portata/batteria/latenza/banda → scegli tech.

📚 Prossimo passo — Fine Modulo 4

Hai chiuso il percorso wireless: da WPAN low-power a WLAN Wi-Fi 6E, da WMAN/5G slicing a IoT LPWAN. Ora sai mappare ecosistema, scegliere LoRaWAN vs 5G mMTC, mettere MQTT over TLS e isolare VLAN IoT.

← Lezione precedenteWMAN e WWAN WiMAX reti cellulari e 5G Fine Modulo 4Modulo completato