Gestione dei ruoli utente e installatore per prodotti connessi
Un prodotto connesso non ha un solo tipo di utente, ne ha almeno tre. Il team operativo del produttore ha bisogno di visibilità sull'intera flotta. Gli installatori sul campo mettono in servizio, configurano e mantengono i dispositivi presso i siti dei clienti; hanno bisogno di accedere ai dispositivi che gestiscono e a nient'altro. Gli utenti finali possiedono dispositivi specifici e interagiscono con essi tramite un'app consumer.
Ognuno di questi attori ha bisogno di una vista diversa dei dati e di un set di permessi distinto.
Dati visibili al cliente sbagliato, installatori che modificano accidentalmente dispositivi che non gestiscono, nessuna possibilità di audit su chi ha cambiato cosa o di revocare l'accesso al termine di un rapporto commerciale.
La sfida
I modelli di permessi nei prodotti IoT tendono a iniziare in modo semplice e ad accumulare complessità nel tempo:
- I modelli di accesso piatti falliscono su scala: un unico ruolo di amministratore che concede l'accesso a tutto funziona per tre dipendenti; diventa un rischio per la sicurezza con 50 installatori distribuiti su più clienti.
- Isolamento dei dati tra i clienti: un installatore che serve il cliente A non deve mai vedere i dati del cliente B, anche se entrambi sono nello stesso sistema. Imporre questo a livello applicativo è fragile e prono a errori.
- Strumenti specifici per l'installatore: gli installatori hanno bisogno di strumenti di commissioning, viste diagnostiche e accesso alla configurazione che gli utenti finali non dovrebbero mai vedere. Questi devono essere limitati in base al ruolo, non costruendo un'applicazione separata.
- Back-office del produttore: il produttore ha bisogno di visibilità trasversale sulla flotta, che non può concedere a nessun altro, oltre alla possibilità di delegare specifiche flotte a partner di assistenza senza esporre tutto.
- Requisiti di audit: i settori regolamentati e i clienti enterprise richiedono un record completo di chi ha effettuato l'accesso a cosa e cosa ha modificato.
- Feature gating a livello di app: le funzionalità disponibili solo per determinati ruoli (es. "configura la programmazione del termostato" è disponibile per gli installatori ma non per gli utenti finali) devono essere imposte a livello API, non solo nella UI.
Cosa serve per farlo bene
Un sistema di ruoli e permessi di livello professionale per l'IoT richiede:
- Modello dati gerarchico: i dispositivi appartengono ai siti; i siti appartengono ai clienti; i clienti appartengono al produttore. I permessi si propagano lungo questa gerarchia ma possono essere delimitati (scoped) a qualsiasi livello.
- Controllo degli accessi basato sui ruoli (RBAC): ruoli predefiniti (produttore admin, installatore, utente finale) con set di permessi configurabili collegati a ciascuno.
- Controllo degli accessi basato sugli attributi (ABAC): per casi più granulari, permessi basati sugli attributi della risorsa (es. "l'installatore può configurare, ma non eliminare, qualsiasi dispositivo nel sito a lui assegnato").
- Isolamento dei dati multi-tenant: imposto a livello di dati, non a livello applicativo. Una query dalla sessione di un installatore non può restituire dati al di fuori del suo ambito, indipendentemente dalla chiamata API.
- Amministrazione delegata: un produttore può concedere a un'azienda di installazione i diritti di amministratore sulla propria sottosezione della flotta, e quell'amministratore installatore può gestire i propri utenti, senza toccare nulla al di fuori del suo ambito.
- Audit log: ogni accesso e modifica viene registrato con autore, timestamp, risorsa ed esito.
Come Connhex risolve il problema
Connhex è stato costruito fin dal primo giorno attorno a un'architettura multi-tenant e consapevole dei ruoli, perché ogni produttore con cui lavoriamo ha esattamente questo problema.
Connhex Auth gestisce l'identità dell'utente su tutti i tipi di app: mobile, web e back-office. Registrazione, login, gestione delle sessioni e ciclo di vita dei token sono tutti gestiti da Auth, che si integra con qualsiasi frontend tramite flussi standard OAuth 2.0 / OIDC.
Il sistema IAM fornisce il modello dei permessi:
- Ruoli e policy: definisci cosa può fare ogni ruolo (leggere telemetria, inviare comandi, gestire utenti, visualizzare fatturazione) e assegna i ruoli a utenti o gruppi.
- Scoping delle risorse: ogni permesso è delimitato a una parte specifica della gerarchia dei dispositivi; una policy può concedere a un installatore l'accesso in lettura a tutti i dispositivi nei siti a lui assegnati, e a nient'altro.
- Isolamento multi-tenant: i dati di ogni organizzazione sono isolati a livello di dati. Le chiamate API di un installatore non possono restituire dati al di fuori del suo ambito, indipendentemente da come viene costruita la query.
- Amministrazione delegata: gli admin del produttore possono concedere diritti di sub-admin alle aziende di installazione, consentendo loro di gestire i propri utenti senza il coinvolgimento del produttore per ogni modifica.
Device Ownership formalizza la relazione con l'utente finale: un utente rivendica la proprietà del suo specifico dispositivo, e tale proprietà è imposta a livello API: la sua sessione app può accedere solo ai propri dispositivi.
Come funziona in pratica il modello a tre attori
Un tipico deployment per un produttore ha tre tipi di attori con accessi rigorosamente separati:
| Attore | Cosa può vedere | Cosa può fare |
|---|---|---|
| Admin Produttore | Tutti i dispositivi, tutti i clienti, tutti gli installatori | Aggiornare firmware, visualizzare analytics di flotta, gestire account installatori, accedere alla fatturazione |
| Installatore | Solo i dispositivi nei siti cliente a lui assegnati | Mettere in servizio i dispositivi, eseguire diagnosi, inviare configurazioni, visualizzare lo stato di salute del sito |
| Utente finale | Solo i propri dispositivi rivendicati | Visualizzare i dati del dispositivo, controllare le funzioni del dispositivo, gestire le preferenze dell'app |
È fondamentale che questo isolamento sia imposto a livello di dati, non a livello applicativo. La sessione API di un installatore non può restituire dati al di fuori dell'ambito assegnato, indipendentemente dai parametri passati. L'applicazione non ha bisogno di implementare logica di filtraggio; la piattaforma la impone automaticamente.
- Revocare immediatamente l'accesso di un installatore al termine di un rapporto commerciale, senza influenzare nessun altro.
- Sapere esattamente chi ha apportato una modifica alla configurazione, su quale dispositivo e quando.
- Concedere a un nuovo tecnico l'accesso delimitato al sito di uno specifico cliente senza esporre il resto della flotta.
- Consentire agli admin dei clienti enterprise di gestire i propri utenti senza il coinvolgimento del produttore per ogni modifica.
Nulla di tutto ciò è possibile senza controlli di accesso che siano realmente granulari.
Vedi come funziona in pratica
La gestione degli utenti e dei ruoli è fondamentale in tutti i settori in cui opera Connhex. È particolarmente rilevante nei casi d'uso HVAC e smart home, dove la relazione installatore-produttore-utente finale è il modello operativo principale:
Connhex per HVAC · Connhex per la smart home · Connhex per piscine e SPA · Connhex per i distributori automatici