La creazione di una piattaforma IoT, di Internet of Things, richiede disporre di un piano strategico di business e di infrastrutture prima di sviluppare il sistema operativo della soluzione. La pianificazione e la progettazione dell’infrastruttura sono state discusse nelle prime due parti di questa serie di articoli. Questa terza parte finale esplora la connettività, i dispositivi industriali sul campo e le modalità di interazione con la piattaforma IoT. Le indicazioni e le riflessioni contenute in questi articoli sono attribuite ad Alex Casalboni, Senior Developer Advocate AWS.
Stabilire il processo per l’onboarding dei dispositivi è solamente una parte dell’equazione che porta alla creazione di una piattaforma IoT. Ci sono anche alcuni requisiti di base e misure tecniche che devono essere considerate.
Identità univoca dei dispositivi
È necessario avere un metodo per identificare in modo univoco ogni singolo dispositivo che si collega al backend.
Ma come si fa ad assegnare in modo sicuro gli ID univoci per evitare abusi?
Mentre gli indirizzi MAC sono facili da falsificare, gli ID univoci universali generati (UUID) possono funzionare, ma è meglio avere ID hardware che sono intrinsecamente legati al firmware del dispositivo.
Uno degli scenari di attacco nell’Internet of Things è quello di essere soggetti alla ricezione di dati da un gruppo di device fittizi o compromessi, ottenendo così dati errati o subendo quindi un attacco DDoS (Distributed Denial-of-Service).
Pertanto, quando si creano gli ID, occorre considerare quanto può essere facile falsificare o riprodurre gli ID dei dispositivi – dei buoni ID univoci dovrebbero essere difficili da riprodurre, duplicare o indovinare. Poiché gli ID dovrebbero essere parte del dispositivo, sarebbe meglio assegnarli durante la produzione dello stesso.
Oltre alla sicurezza, gli ID sono utili quando si cerca di gestire dei device specifici e quando i dati che vengono immessi nella piattaforma devono essere mappati sul gemello digitale, il tenant o sulla shadow (il container virtuale dei dati del dispositivo).
Aggiornamenti del firmware
Se si costruiscono dispositivi IoT con software preconfigurato, è possibile che si verifichino alcuni problemi prima della loro installazione presso un cliente.
Cosa succede se si costruisce il dispositivo con il firmware attuale, ma prima che i dispositivi vengano messi in funzione, si trova e si risolve un grave bug nel firmware?
Come si aggiorna il dispositivo senza mettere a rischio il backend? In questo caso, è necessaria una strategia per ottenere nuove versioni del firmware sul dispositivo prima della messa in funzione.
Una soluzione è quella di avere un servizio web separato per gli aggiornamenti del firmware che abbia restrizioni inferiori sui dispositivi da connettere, e poi far sì che il cliente abiliti questo servizio web come destinazione nel firewall aziendale.
Questo consentirebbe gli aggiornamenti automatici via internet una volta che il dispositivo ha la connettività Internet. In alternativa, si potrebbe sviluppare un meccanismo per aggiornare il firmware manualmente tramite una porta USB o un apposito strumento di messa in servizio basato su LAN.
Configurazione di base dei dispositivi
Ogni dispositivo deve avere una configurazione di base come l‘indirizzo IP, il server DNS, il gateway predefinito e i proxy se non è presente il DHCP (se si equipaggiano i dispositivi con 3G/4G e una SIM invece di utilizzare LAN cablata o WLAN, questa parte può essere saltata).
Questo può essere fatto con un web server integrato (come sui dispositivi domestici) che un tecnico del servizio di assistenza sul campo utilizza via LAN.
Si può anche fornire un file di configurazione tramite protocollo FTP o via USB, entrambe opzioni manuali che richiedono il tempo di un tecnico sul campo.
Tuttavia, qualsiasi porta aperta su un dispositivo è un rischio per la sicurezza.
In alternativa, si può utilizzare uno strumento di messa in servizio che introduce questi dati via LAN e un protocollo proprietario; ad esempio, il dispositivo espone una REST API tramite un server web locale.
Se si utilizza un server web locale sul dispositivo, è fondamentale assicurarsi che sia sicuro.
Certificati e token
La maggior parte dei sistemi IoT nel cloud richiedono che un dispositivo, o il software di un dispositivo, fornisca un certificato valido che è stato precedentemente fornito dal backend.
Di conseguenza, durante l’onboarding di un dispositivo, potrebbe essere necessario generare un certificato sul cloud che deve essere caricato sul dispositivo stesso. S
istemi ancora più sicuri richiedono che venga generato un token di onboarding per un determinato ID del dispositivo che consenta l’onboarding solo durante un determinato periodo di tempo per ridurre il rischio di configurare un dispositivo pericoloso.
Per questo, è necessario che un tecnico sul campo generi i dati richiesti sul cloud, o localmente e registrando i dati sul cloud in una fase successiva, e poi li carichi sul dispositivo. Questo collegherà il dispositivo con il backend cloud in modo efficace e sicuro.
Aggiornamenti del certificato
Per motivi di sicurezza, poi, i certificati scadono e devono essere rinnovati regolarmente, ad esempio, ogni 12 mesi.
In questo modo si riduce la possibilità di attacco con certificati vecchi e rubati. Pertanto, è necessario un meccanismo per l’aggiornamento dei certificati che può coincidere con il processo necessario per aggiornare la configurazione e il firmware nelle fasi successive del ciclo di vita dell’apparecchio.
3G/4G e SIM
Se si equipaggiano i dispositivi con 3G/4G e una SIM, potrebbe essere necessario configurare altre cose. Ad esempio, la scheda SIM dovrà essere attivata dall’operatore o dal provider della SIM.
Considerate anche che le società telco forniscono diverse opzioni per gestire la connettività mondiale per le schede SIM e l’attivazione in massa, quindi si rende necessario prendere alcune decisioni. Inoltre, poiché il processo è diverso da fornitore a fornitore, i compiti che dovranno essere svolti dai tecnici possono variare.
Altre complessità che si possono incontrare al di là di questi scenari comuni includono le procedure di sostituzione dei dispositivi rotti, lo smantellamento, il reset dei dispositivi per la nuova messa in servizio, e così via.
In ogni caso, se si decide di progettare un proprio processo di onboarding, bisogna cercare di ridurre al minimo lo sforzo richiesto ai tecnici sul campo.
Non tutte le aziende hanno ingegneri con una formazione ed esperienza nella gestione del software, nell’ingegneria del software o nel cloud computing. Gran parte di queste organizzazioni sono ancora concentrate su compiti meccanici ed elettrici.
Piattaforme di Industrial IoT, come pianificare l’ecosistema di riferimento
Linee guida per progettare una soluzione IIoT sul cloud di AWS
Progettare una piattaforma IIoT su cloud: il tema della scalabilità
IIoT su cloud, come progettare per avere una distribuzione più rapida
Progettare su cloud una piattaforma IIoT multi-region e multi-tenant
Costruire una piattaforma IoT con dispositivi industriali sul campo
Connettività internet per piattaforme IoT e onboarding dei dispositivi
