Il contesto

Un cliente ha sviluppato un dispositivo autonomo con una UX interessante. Questo prodotto è pensato per essere lasciato senza assistenza in aree ad alto traffico, pronto per interazioni con gli utenti.
Quando si hanno dispositivi incustoditi, si hanno difficoltà aggiuntive nel garantire che il funzionamento rispetti il progetto.

Per esempio bisogna modulare le possibilità di accesso degli utenti per evitare che possano inavvertitamente causare deviazioni come il cambio di lingua, una disconnessione della rete, un ripristino delle impostazioni di fabbrica, possano accedere a informazioni confidenziali, eccetera.

Bisogna a tutti gli effetti bloccare il dispositivo, riducendo quello che può fare. Per ottenere questo risultato si può minimizzare a priori quello che il dispositivo può fare, ma questo può rendere molto complesse altre fasi come quelle di sviluppo o di assistenza tecnica. C'è pertanto bisogno di avere la possibilità di variare le capacità del dispositivo in maniera dinamica. Questo è chiamato modalità Kiosk.

Un altro esempio di difficoltà nel caso di dispositivi incustoditi remoti, può essere la distribuzione di aggiornamenti alle applicazioni, come si può fare? Certamente non è ipotizzabile visitare fisicamente ogni dispositivo per effettuare l'upgrade, c'è quindi bisogno di un metodo di distribuzione affidabile.

Abbiamo visto alcune delle complessità di gestire una flotta di dispositivi remoti, vediamole più in dettaglio.

Difficoltà

I dispositivi sono incustoditi, quindi vanno protetti da usi fuori dal perimetro definito dall'applicazione, ma allo stesso tempo devono poter essere aggiornati e devono poter svolgere la funzione per la quale sono progettati senza ulteriore intervento umano.

Nel caso del mio cliente questo si traduce essenzialmente in tre grandi macro categorie:

• come aggiornare le applicazioni?
  
• come evitare interazioni non previste?
• come assicurare che tutti i dispositivi mantengano uno stato coerente e verificabile?

Questi sono tutti punti molto validi, che richiedono pianificazione accurata al fine di essere risolti nel perimetro dei requisiti e del piano di business. Per esempio è abbastanza comune che grandi organizzazioni sviluppino internamente sistemi di aggiornamento remoto, ma questo è un processo ad alto impatto che non può facilmente essere affrontato da piccole organizzazioni e startup. Per esempio EVBox, per la quale ho lavorato, aveva sviluppato un sistema interno di aggiornamento sicuro dei dispositivi, ma in quel caso avevamo decine di migliaia di dispositivi, e avevamo dei requisiti di sicurezza molto alti. Sono stati questi ed il numero di dispositivi a far propendere per lo sviluppo interno del sistema.

Cosa fare quindi nel caso di piccole organizzazioni con differenti requisiti?

La soluzione: Mobile Device Management

Una possibile soluzione è usare una piattaforma di gestione dispositivi. Queste piattaforme si inseriscono sul dispositivo, facendolo comunicare con i loro server e fornendo una serie di servizi. Questi strumenti MDM solitamente possono gestire dispositivi sia Android che Apple, mentre ce ne sono di più specializzate per dispositivi Linux.

Nel mio caso il cliente aveva già scelto Android, quindi mi sono focalizzato sui servizi dedicati a questo ecosistema, il che ha semplificato l'aspetto della ricerca.

Se anche voi avete dei dispositivi IOT con Android, potete anche voi utilizzare una piattaforma MDM, questa si aggancerà alle APIs di Android permettendovi di gestire il dispositivo da un comodo pannello di controllo. Di solito le piattaforme MDM offrono tutte un certo numero di servizi, vediamo quali sono quelli più comuni:

• gestione della flotta
• gestione delle policy
• modalità kiosk
• gestione applicazioni
• aggiornamento remoto
• controllo remoto

Scegliere la piattaforma

Dato l'elevato numero di offerte sul mercato, e la frammentazione del mercato stesso dei dispositivi, fare questa scelta è un processo con molti passi, non c'è una soluzione generica. Certamente il prezzo sarà un fattore importante, ma in molti casi non il più importante, con aspetti tecnici che possono anche prendere il sopravvento come vedremo tra poco.

Del resto che senso avrebbe comprare una piattaforma economica che però non funziona sul dispositivo designato? Vediamo quindi quali aspetti ho valutato per arrivare ad una scelta.

Un aspetto sicuramente importante è la complessità d'uso della piattaforma MDM stessa: il mio cliente è una piccola impresa, non vuole dover mettere su un dipartimento IT per gestire la piattaforma MDM, né tantomeno i dispositivi lo richiedono. Pertanto la scelta dovrà cadere su una piattaforma che possa essere gestita in autonomia, senza personale specializzato, e senza causare eccessive complessità e frizioni nell'eseguire il compito.

Un altro aspetto imprescindibile e non meno importante è come avviene l'aggiunta dei dispositivi alla piattaforma. Nel caso in oggetto, si tratta di dispositivi industriali, ben diversi da quelli commerciali per utenti finali come smartphone e tablet. I dispositivi industriali spesso non hanno tutte le capacità dei dispositivi a cui siamo tutti abituati, e questo potrebbe creare difficoltà aggiuntive alle piattaforme MDM se non sono state espressamente progettate per questo caso d'uso.

Ho altresì valutato l'operatività delle piattaforme, quanto facile fosse portare un dispositivo alla configurazione finale, quanto fosse automatico o manuale il processo (se configurare un dispositivo richiede mezz'ora di lavoro manuale, non può scalare!), di quanti passi fosse composto, quanto facile fosse cambiare la configurazione.

Ancora importante per il caso d'uso del mio cliente, è anche la gestione delle applicazioni poiché questo è un aspetto fondamentale del prodotto. Gestire il ciclo vitale delle applicazioni deve essere semplice e veloce da parte della piattaforma MDM, rendendo immediati la creazione di nuove applicazioni, il loro aggiornamento o il ritiro. E ulteriormente senza richiedere il Play Store.

L'ultimo aspetto che voglio menzionare oggi è l'applicazione di policy dispositivo. Questa funzionalità può sembrare poco importante, ma semplifica notevolmente le operazioni anche ad una piccola azienda. Le policy dispositivo infatti permettono in pochi secondi, di applicare intere configurazioni a flotte di dispositivi. Per esempio nel caso del mio cliente, ho creato una policy produzione e una testing. Questo permette di passare in pochi secondi da un sistema estremamente limitato e protetto, ad uno più aperto ed accessibile per attività di verifica. Immaginate dover magari aprire un dispositivo ed accedere a jumper o dover inserire chiavette per ottenere lo stesso, è molto più facile con una policy!

Adesso che abbiamo descritto i fattori che concorrono alla scelta, andiamo a vedere più in dettaglio quelli che sono stati i più importanti nel mio caso.

Complessità del prodotto

Nello scegliere una piattaforma MDM, è importante capire quale sia il loro mercato di riferimento. Infatti alcune sono dedicate alle grandi imprese con dipartimenti IT dedicati che intendono mettere al sicuro e gestire i dispositivi dei loro dipendenti (come smartphone e tablet). Queste piattaforme offrono possibilità di configurazione estremamente flessibili e granulari, e possono facilmente essere impossibili da gestire per realtà più piccole. Bisogna scegliere in maniera attenta e oculata una piattaforma che offra una complessità che sia possibile da gestire per la struttura del cliente.

Non sottovalutate questo aspetto. Prima ho mensionato l'aggiornamento remoto delle applicazioni. Ho fatto un test con ognuna delle piattaforme per verificare come funzionasse questa procedura, quanto fosse complessa e che velocità di distribuzione offrisse.

Una piattaforma in particolare, solamente per distribuire un aggiornamento di un'applicazione, mi ha chiesto due volte un codice 2FA, nonostante mi fossi già autenticato. Questo può diventare rapidamente troppo faticoso da gestire, e fa capire senza ombra di dubbio che il flusso ideale di questa piattaforma non vede molti aggiornamenti a breve distanza. Mentre il flusso che cercava il mio cliente è esattamente l'opposto: sviluppo rapido e distribuzioni a brevissima distanza.

Questo è solo un esempio di come valutare se la complessità d'uso della piattaforma sia adatta all'utente che intende usarla. E in questo caso non lo era.

Aggiunta dispositivi

Un altro aspetto daconsiderare è il processo per aggiungere dispositivi alla piattaforma.

La maggior parte delle piattaforme offre una modalità enterprise che utilizza i servizi dell'OS (Apple e Google Enterprise), ma anche una applicazione progettata per essere installata e sempre operativa, spesso chiamata demone, che tenga sotto controllo il dispositivo e lo connetta ai server della piattaforma. A volte riescono anche ad offrire una fusione delle due modalità, unendo pregi e difetti di entrambe. La parte critica sono i requisiti di ognuna di queste modalità.

Una applicazione potrebbe essere disponibile solo attraverso lo store , e se il dispositivo non ha accesso ai servizi commerciali (quindi niente Play Store) questo vuol dire che non sarà possibile installare l'applicazione. Inquesto caso bisogna verificare che la piattaforma MDM offra anche un APK per il side-loading, ovvero l'installazione manuale. In questo caso la piattaforma potrebbe essere compatibile con il dispositivo.

Un altro aspetto importante è che le applicazioni di monitoraggio e gestione spesso richiedono privilegi elevati, solitamente equivalenti a quelli di root, quindi bisogna avere un modo di concedere questi privilegi all'applicazione. Solitamente questo non è banale per dispositivi commerciali, anzi il rooting dei dispositivi è espressamente vietato da Goole, Apple, Samsung e gli altri, con clausole che annullano la garanzia se è stato manomesso il dispositivo. Su dispositivi IOT custom come quello del mio cliente, la storia è diversa. In questo caso spesso il sistema non è bloccato come sui dispositivi commerciali, o comunque lo sviluppatore ha la facoltà di concedere accesso alle applicazioni. In questo caso dovrebbe essere possibile concedere i necessari privilegi al demone della piattaforma MDM o tramite il pannello di controllo, oppure tramite ADB usando la modalità debug. In ogni caso, bisogna che la piattaforma MDM supporti questo tipo di modalità operativa, altrimenti non funzionerà.

Infatti le modalità normali per concedere questo tipo di privilegi, specificamente per il mondo Android, sono zero-touch e Android Enteprise. Queste due modalità permettono al dispositivo di parlare con i server della piattaforma MDM scelta, e così facendo sarà il dispositivo a configurarsi autonomamente per garantire i necessari privilegi di accesso alla piattaforma MDM. E di nuovo questo dipende dalla disponibilità dei relativi servizi specifici di Google. Quindi nel caso di versioni customizzate di Android basate su AOSP per dispositivi IOT, è molto probabile che questi servizi non siano disponibili e che quindi queste modalità non possano essere utilizzate.

Questo è il caso del dispositivo del mio cliente, pertanto ho dovuto scegliere piattaforme MDM che rendessero disponibile un APK per l'installazione manuale, e le relative istruzioni per la concessione dei privilegi. Questo ha ovviamente ristretto le scelte.

Una volta installato il demone, è ora di collegare il dispositivo all'account dell'organizzazione, questo è più propriamente il cosiddetto enrollment. Tra i servizi che ho testato, alcuni prevedevano solo l'enrollment tramite QR code, escludendo quindi il dispositivo che non avesse una telecamera, in questo caso infatti anche se si riesce ad installare il demone, non c'è modo di dargli il codice di collegamento a meno che la piattaforma non offra modalità alternative.

Il processo di selezione

Una volta arrivati ad avere una lista delle piattaforme che sembrano compatibili dopo aver analizzato i requisiti descritti sopra. adesso vediamo come procedere all'analisi delle funzionalità, e come ho proceduto per il mio cliente.

Iniziamo con il definire il tipo di dispositivo da controllare: il mio cliente ha sviluppato un dispositivo industriale, senza telecamera, e ha alcune installazioni con Android AOSP 13, e altre con la versione 14, tutte comunque senza Google Play Services. Questo esclude automaticamente le piattaforme che richiedono assolutamente i Play Services per funzionare, e quelle che richiedono esclusivamente la lettura di un QR per l'enrollment. Rimangono quelle che permettono l'installazione manuale, e l'inserimento manuale di un codice per il collegamento del dispositivo. Ecco le piattaforme che hanno superato una prima selezione e che ho analizzato

Per ognuna di queste ho proceduto a creare un account di prova o gratuito, installare il demone sul dispositivo, collegarlo alla piattaforma, creare policy, caricare e aggiornare un'applicazione, e contattare il supporto tecnico.

Risultati dell'analisi

Ecco cosa ho scoperto

Miradore

Non sono stato in grado di installare questa applicazione, è disponibile solo tramite Play Store, non ci sono metodi alternativi.
Scartata
‍

TinyMDM

Non sono stato in grado di installare questa applicazione, è disponibile solo tramite Play Store. Il supporto tecnico mi ha proposto una versione beta, ma non hanno potuto propormi un modo alternativo per garantire i privilegi di esecuzione.
Scartata

Hexnode

Molto semplice da installare, ha anche automaticamente installato un modulo VPN e uno di controllo remoto, ottimo! Le prime difficoltà sono comparse con l'uso della piattaforma: controlli troppo granulari, policy molto complesse, richieste multiple di autenticazione anche per azioni semplici, difficoltà nel concedere i diritti di esecuzione.
Alla fine scartata per eccessiva complessità d'uso.

Scalefusion

Facile da installare e collegare, facile gestire le applicazioni, le policy e la modalità kiosk. Le problematiche sono emerse nella gestione dei privilegi, nel controllo remoto che non sono riuscito a far funzionare, e nella distribuzione di applicazioni che non funzionava sempre.
Scartata per comportamento inaffidabile

AirDroid Business

Facile da installare e collegare, istruzioni per installazione e privilegi facili e immediatamente disponibili, policy, gruppi e modalità kiosk estremamente intuitivi, in pratica tutto ha funzionato subito. Quando ho avuto qualche difficoltà, il supporto tecnico mi ha aiutato in brevissimo tempo.
Accettata

Ecco una tabella riassuntiva delle prove e di quanto evidenziato

Conclusioni

Scegliere la giusta piattaforma Android MDM per dispositivi IOT richiede cura nel valutare la compatibilità con i dispositivi, il costo e i requisiti operativi. Le piattaforme testate avevano ognuna pro e contro, e la selezione si è focalizzata sulle necessità specifiche del caso d'uso del mio cliente.

La chiave del successo nella scelta, in questo caso, è stato il processo di enrollment che ha essenzialmente escluso molte delle piattaforme per parziale o totale incompatibilità. Seguire un processo strutturato e fare prove approfondite mi ha permesso di fare una scelta oculata , che grazie ai dati è in grado di supportare l'azienda ed i suoi obiettivi.

Se anche voi state cercando una soluzione per la gestione di dispositivi e trovate che sia complesso trovare quella giusta, posso aiutarvi. Andate alla pagina di contatto e approfondiamo insieme i vostri bisogni!

‍

‍