Protocolli fondamentali per l'accesso remoto IoT
La scelta del protocollo corretto dipende dai vincoli del dispositivo, dai requisiti di latenza e dalla necessità di accesso interattivo (shell, desktop) oppure solo di messaggistica command-and-control.
MQTT (Message Queuing Telemetry Transport)
MQTT è lo standard de facto per il command-and-control IoT. Utilizza un modello publish/subscribe, funziona su TCP/TLS e ha un overhead minimo — l'header fisso è di soli 2 byte. Ogni piattaforma cloud IoT principale utilizza MQTT come protocollo primario per i dispositivi.
Per l'accesso remoto nello specifico, MQTT funge da control plane: si pubblica un comando su un topic specifico del dispositivo, il dispositivo lo esegue e pubblica una risposta. Non si tratta di accesso interattivo alla shell — è esecuzione strutturata di comandi, che in realtà è preferibile per la maggior parte delle operazioni (aggiornamenti firmware, modifiche di configurazione, query diagnostiche).
Quando usarlo: Gestione a livello di flotta, aggiornamenti OTA, raccolta telemetria, comandi remoti non interattivi.
Tunneling SSH tramite gateway IoT cloud
Quando gli ingegneri necessitano di una shell interattiva su un dispositivo remoto — per il debug di un processo, l'ispezione dei log o il test di una modifica di configurazione — SSH rimane lo strumento adeguato. Ma la sessione SSH non deve mai essere esposta direttamente a internet.
Il pattern corretto:
1. Il dispositivo mantiene una connessione MQTT in uscita verso il broker IoT cloud.
2. Un operatore richiede un tunnel tramite la console cloud o l'API.
3. Il broker segnala al dispositivo di aprire un listener SSH locale.
4. Il broker fa da proxy del client SSH dell'operatore verso il dispositivo attraverso la connessione in uscita esistente.
5. Il tunnel ha una durata limitata e viene tracciato nei log.
AWS IoT Secure Tunneling implementa esattamente questo pattern. Azure IoT Hub Device Streams offre una funzionalità equivalente.
CoAP (Constrained Application Protocol)
CoAP è un protocollo RESTful leggero progettato per dispositivi fortemente vincolati (ad esempio: microcontrollori con 64 KB di RAM). Funziona su UDP, supporta DTLS per la crittografia e si mappa naturalmente sulla semantica REST (GET, PUT, POST, DELETE). È meno comune di MQTT per l'accesso remoto ma rilevante per la gestione dei dispositivi basata su LwM2M nelle telecomunicazioni e nella misurazione delle utenze.
Confronto tra protocolli
| Attributo | MQTT | SSH (tunnelizzato) | CoAP | HTTP/REST |
|---|---|---|---|---|
| Trasporto | TCP/TLS | TCP/TLS | UDP/DTLS | TCP/TLS |
| Overhead minimo | ~2 byte header | Basato su sessione | 4 byte header | Centinaia di byte |
| Shell interattiva | No | Sì | No | No |
| Adatto a dispositivi vincolati | Sì | Moderato | Sì | No |
| Supporto cloud-native | AWS IoT Core, Azure IoT Hub, HiveMQ | AWS Secure Tunneling, Azure Device Streams | Piattaforme LwM2M | API Gateway + Lambda/Functions |
| Bidirezionale | Sì (pub/sub) | Sì | Sì (observe) | Solo request/response |
Pattern delle piattaforme cloud per l'accesso remoto IoT
AWS IoT Core + Secure Tunneling
AWS IoT Core gestisce l'autenticazione dei dispositivi tramite certificati X.509, il routing dei messaggi tramite topic MQTT e l'autorizzazione basata su policy. Per l'accesso remoto interattivo, AWS IoT Secure Tunneling crea un tunnel basato su WebSocket tra un operatore e un dispositivo senza richiedere che il dispositivo abbia un indirizzo IP pubblico o porte in ingresso aperte.
Dettagli architetturali chiave:
- I tunnel vengono creati tramite la console AWS IoT o l'API, generando una coppia di token monouso (uno per la sorgente, uno per la destinazione).
- L'agente lato dispositivo (
localproxy) apre una connessione in uscita verso il servizio di tunneling. - I tunnel scadono dopo un timeout configurabile (default: 12 ore).
- Tutti i metadati del tunnel vengono registrati in CloudTrail.
Per le organizzazioni italiane, la region eu-south-1 (Milano) garantisce la residenza dei dati all'interno del territorio nazionale, un aspetto cruciale per la conformità alle indicazioni dell'ACN e alla strategia Cloud Italia.
AWS offre inoltre AWS IoT Greengrass per l'edge compute, che può eseguire funzioni Lambda locali e inferenza ML. I dispositivi Greengrass possono essere gestiti da remoto tramite l'API cloud di Greengrass, inclusi deployment di componenti e recupero dei log.
Azure IoT Hub + Device Streams
Azure IoT Hub utilizza chiavi simmetriche o certificati X.509 per l'identità dei dispositivi. Device Streams (generalmente disponibile) fornisce un pattern di accesso tunnelizzato simile ad AWS Secure Tunneling, con l'aggiunta del supporto sia per protocolli basati su TCP sia per proxying WebSocket.
Il fattore differenziante di Azure è l'integrazione più stretta con Microsoft Defender for IoT, che fornisce network detection and response (NDR) agentless specificamente per protocolli OT e IoT — inclusi Modbus, BACnet e DNP3. Questo è rilevante per le flotte IoT industriali dove l'accesso remoto deve essere monitorato a livello di protocollo, non solo a livello di trasporto.
La region Italy North di Azure consente alle organizzazioni italiane di mantenere i dati IoT all'interno dei confini nazionali, in linea con i requisiti di qualificazione dei servizi cloud dell'ACN.
Per l'edge compute, Azure IoT Edge esegue workload containerizzati sui dispositivi e supporta il deployment remoto dei moduli e il monitoraggio tramite IoT Hub.
GCP — Pub/Sub e lo scenario post-IoT-Core
Google ha dismesso il proprio servizio IoT Core nell'agosto 2023. Le organizzazioni su GCP ora tipicamente costruiscono la connettività IoT utilizzando:
- Cloud Pub/Sub come message broker
- Bridge MQTT tramite broker di terze parti (HiveMQ, EMQX o Mosquitto su GKE)
- Cloud IAM + Workload Identity Federation per l'autenticazione dei dispositivi
Questo approccio offre maggiore flessibilità ma richiede più assemblaggio. L'accesso remoto interattivo su GCP prevede tipicamente l'esecuzione di un bastion host o di una soluzione di tunneling gestita (come Teleport o Boundary di HashiCorp) davanti al broker MQTT.
Per le organizzazioni fortemente orientate a GCP, questo pattern autoassemblato è praticabile ma richiede un investimento operativo maggiore rispetto alle offerte integrate di AWS o Azure.
Identità zero-trust dei dispositivi: la base imprescindibile
Ogni architettura seria di accesso remoto IoT parte dall'identità del dispositivo. Se non è possibile verificare crittograficamente che un dispositivo sia effettivamente ciò che dichiara di essere, ogni altro controllo di sicurezza è costruito sulla sabbia.
Certificati X.509 e Mutual TLS
Lo standard di riferimento è costituito da certificati X.509 per-dispositivo emessi da una Certificate Authority (CA) privata sotto il vostro controllo. Ogni dispositivo conserva una chiave privata univoca (idealmente in un hardware security module o trusted platform module), e il broker IoT cloud valida il certificato a ogni connessione.
Il mutual TLS (mTLS) significa che anche il dispositivo valida il certificato del server, prevenendo attacchi man-in-the-middle anche in caso di compromissione del DNS.
AWS IoT Core, Azure IoT Hub e la maggior parte dei broker MQTT enterprise supportano mTLS nativamente. La sfida operativa è il provisioning dei certificati in fase di produzione e la rotazione dei certificati su larga scala — problemi che AWS IoT Device Defender e Azure DPS (Device Provisioning Service) affrontano in modo specifico.
Cosa non funziona su larga scala
- API key condivise incorporate nelle immagini firmware. Una chiave trapelata compromette l'intera flotta.
- Autenticazione username/password su MQTT. Le credenziali finiscono nei file di configurazione, nel version control e nei log CI/CD.
- Indirizzo MAC o numero di serie come identità. Sono banalmente falsificabili.
Gestione della postura di sicurezza IoT
Conformità normativa: GDPR, NIS2 e regolamentazione italiana
GDPR e il Garante per la Protezione dei Dati Personali
I dispositivi IoT che raccolgono dati collegati a persone identificabili — sensori di occupazione degli edifici, tracciamento delle flotte, dispositivi sanitari indossabili — rientrano pienamente nel perimetro del GDPR. L'articolo 25 (protezione dei dati fin dalla progettazione e per impostazione predefinita) richiede che i meccanismi di accesso remoto applichino la limitazione delle finalità: un ingegnere che effettua il debug di un sensore di temperatura non deve poter esfiltrare i dati di occupazione dallo stesso dispositivo.
Il Garante per la Protezione dei Dati Personali ha più volte ribadito che i trattamenti automatizzati tramite dispositivi IoT richiedono una valutazione d'impatto (DPIA) quando i dati raccolti consentono il monitoraggio sistematico delle persone fisiche. L'accesso remoto ai dispositivi deve essere incluso nella DPIA come potenziale vettore di accesso non autorizzato ai dati personali.
NIS2 e il recepimento italiano tramite ACN
La Direttiva NIS2, in vigore da ottobre 2024 e recepita in Italia con il D.Lgs. 138/2024, alza significativamente l'asticella. L'Agenzia per la Cybersicurezza Nazionale (ACN) è l'autorità competente per l'attuazione. Le organizzazioni nei settori essenziali e importanti devono:
- Mantenere un inventario degli asset di tutti i dispositivi connessi (Articolo 21).
- Implementare politiche di controllo degli accessi e autenticazione per gli endpoint IoT.
- Segnalare incidenti significativi entro 24 ore (allerta precoce) e 72 ore (notifica completa) all'ACN tramite il CSIRT Italia.
- Condurre valutazioni del rischio della catena di fornitura che coprano firmware e fornitori hardware IoT.
Per i clienti Opsio con operazioni in Italia, la conformità NIS2 per le flotte IoT prevede tipicamente l'integrazione della telemetria dei dispositivi in un SIEM centralizzato, l'applicazione dell'autenticazione basata su certificati e il mantenimento dei log di audit di tutte le sessioni di accesso remoto. Il nostro SOC gestisce il monitoraggio 24/7, inclusa la rilevazione di anomalie sui pattern dei topic MQTT che potrebbero indicare lateral movement.
Strategia Cloud Italia e qualificazione ACN
Le organizzazioni della PA italiana e i loro fornitori devono considerare anche il framework di qualificazione dei servizi cloud dell'ACN e la Strategia Cloud Italia. I dati classificati come "strategici" o "critici" devono risiedere su infrastrutture qualificate. Per le flotte IoT che gestiscono dati della PA, è fondamentale selezionare region cloud conformi — eu-south-1 (Milano) per AWS o Italy North per Azure — e verificare che il fornitore della piattaforma IoT soddisfi i requisiti di qualificazione.
Architettura cloud conforme alla normativa
Pattern operativi: cosa osserva il SOC/NOC di Opsio in produzione
Pattern 1: tunnel di debug orfani
Il riscontro di sicurezza IoT più comune nel nostro NOC sono i tunnel aperti per il troubleshooting e mai chiusi. Su AWS, questo si manifesta come sessioni di IoT Secure Tunneling che raggiungono il timeout di 12 ore seguite immediatamente dall'apertura di un nuovo tunnel — un ingegnere ha scriptato un loop di rinnovo del tunnel e se n'è dimenticato. Segnaliamo questi casi con un allarme CloudWatch su TunnelOpenCount che supera una soglia per dispositivo al giorno.
Pattern 2: tempeste di scadenza dei certificati
Le flotte in cui il provisioning dei dispositivi è avvenuto in batch spesso hanno certificati che scadono simultaneamente. Un batch di 5.000 dispositivi i cui certificati scadono tutti lo stesso martedì si disconnetteranno tutti contemporaneamente, innescando un'ondata di tentativi di riconnessione che assomiglia a un DDoS contro il broker IoT. Scaglionate le date di scadenza durante il provisioning e monitorate il TTL dei certificati con almeno 90 giorni di anticipo.
Pattern 3: la telemetria come vettore di lateral movement
Gli attaccanti che compromettono un dispositivo IoT raramente sono interessati ai dati del sensore. Utilizzano la connessione MQTT del dispositivo per pubblicare su topic a cui non dovrebbero avere accesso, testando policy sui topic eccessivamente permissive. Le policy di AWS IoT Core dovrebbero sempre limitare un dispositivo alla pubblicazione e sottoscrizione solo su topic contenenti il proprio Thing Name o client ID. Auditiamo queste policy trimestralmente per le flotte gestite da Opsio.
Costruire un'architettura di accesso remoto IoT: passo dopo passo
1. Stabilire l'identità del dispositivo. Effettuare il provisioning di certificati X.509 per-dispositivo in fase di produzione o al primo avvio. Utilizzare una CA privata. Conservare le chiavi private nell'hardware ove possibile.
2. Scegliere un broker IoT cloud. AWS IoT Core o Azure IoT Hub per esperienze gestite; broker MQTT self-hosted (HiveMQ, EMQX) su GCP o ambienti ibridi.
3. Implementare policy sui topic a privilegio minimo. Ogni dispositivo pubblica su dt/{thing-id}/telemetry e sottoscrive cmd/{thing-id}/commands. Nessun wildcard.
4. Distribuire un meccanismo di tunnel solo in uscita. AWS Secure Tunneling o Azure Device Streams per l'accesso interattivo. Ogni sessione con durata limitata.
5. Integrare telemetria e log di accesso dei dispositivi nel SIEM. CloudTrail (AWS), Azure Monitor (Azure) o Cloud Logging (GCP) che alimentano gli strumenti del SOC.
6. Automatizzare la rotazione dei certificati. AWS IoT Device Defender o una Lambda/Function personalizzata che attiva il re-provisioning prima della scadenza.
7. Monitorare le anomalie. Frequenza di pubblicazione insolita, sottoscrizioni a topic imprevisti, connessioni da range IP inattesi.
Quando usare (e quando evitare) strumenti di accesso remoto di terze parti
Strumenti come TeamViewer, Splashtop e AnyDesk sono progettati per l'accesso remoto a desktop e server. Funzionano per gateway IoT che eseguono distribuzioni Linux complete con interfaccia grafica — ad esempio un Raspberry Pi con una dashboard. Sono inadatti per:
- Dispositivi vincolati (microcontrollori, sensori basati su RTOS) che non possono eseguire un agente pesante.
- Flotte headless dove non c'è un display da condividere.
- Ambienti regolamentati dove la sovranità dei dati è importante — molti strumenti commerciali di accesso remoto instradano il traffico attraverso server relay controllati dal fornitore che potrebbero non risiedere nella giurisdizione richiesta. Per le organizzazioni italiane soggette ai requisiti ACN o che trattano dati della PA, questo è un punto critico.
Se i dispositivi IoT edge sono di fatto server Linux (NVIDIA Jetson, PC industriali), gli strumenti commerciali di accesso remoto possono integrare — non sostituire — un'architettura basata su broker IoT con certificati. Utilizzateli per il livello di interazione umana; utilizzate MQTT per la gestione della flotta.
DevOps gestito per pipeline IoT
Domande frequenti
Qual è il protocollo più sicuro per l'accesso remoto IoT?
MQTT su TLS 1.3 con autenticazione reciproca tramite certificati (mTLS) è la scelta più robusta per i canali di command-and-control. Per l'accesso interattivo alla shell, SSH tunnelizzato attraverso un gateway IoT cloud (non esposto direttamente a internet) evita di aprire porte in ingresso sui dispositivi edge. AWS IoT Secure Tunneling e Azure IoT Hub Device Streams implementano questo pattern in modo nativo.
Posso usare una VPN per l'accesso remoto IoT?
Le VPN funzionano per flotte piccole e statiche, ma diventano inadeguate su larga scala. Ogni dispositivo necessita di un tunnel persistente, che scarica la batteria sull'hardware vincolato e complica il NAT traversal. Le VPN concedono inoltre un accesso ampio a livello di rete, violando il principio del privilegio minimo. Gateway IoT dedicati con tunnel per-dispositivo e per-sessione sono più adatti per flotte che superano qualche decina di dispositivi.
In che modo la NIS2 influisce sulla gestione dei dispositivi IoT nell'UE?
La NIS2 (in vigore da ottobre 2024, recepita in Italia con il D.Lgs. 138/2024 sotto la supervisione dell'ACN) classifica molti settori dipendenti dall'IoT — energia, trasporti, manifatturiero, sanità — come entità essenziali o importanti. Queste organizzazioni devono implementare la gestione del rischio della catena di fornitura, la segnalazione degli incidenti entro 24 ore e dimostrare politiche di controllo degli accessi per tutti gli asset connessi, inclusi gli endpoint IoT. I dispositivi IoT non gestiti sono un rilievo frequente negli audit.
Quali sono i quattro sistemi primari della tecnologia IoT?
I quattro sistemi sono: rilevamento (sensori e attuatori che raccolgono dati dal mondo fisico), comunicazione (protocolli come MQTT, CoAP o cellulare che trasferiscono i dati dal dispositivo), elaborazione dati (edge compute o analytics cloud che trasformano la telemetria grezza in decisioni), e interfaccia utente (dashboard, API o loop di controllo automatizzati che agiscono sui dati elaborati). L'accesso remoto copre i livelli di comunicazione e interfaccia utente.
Come mi collego a un dispositivo IoT dietro NAT o firewall?
I dispositivi dietro NAT non possono accettare connessioni in ingresso. Il pattern standard prevede una connessione solo in uscita dal dispositivo verso un broker cloud (AWS IoT Core, Azure IoT Hub o un broker MQTT). Il broker effettua quindi il proxy delle sessioni remote verso il dispositivo attraverso il tunnel in uscita già stabilito. AWS chiama questa funzionalità "secure tunneling"; Azure utilizza "device streams". In questo modo si evita di esporre qualsiasi porta sulla rete del dispositivo.
