Provisioning sicuro dei dispositivi su scala produttiva
Ogni dispositivo che si connette al tuo cloud ha bisogno di un'identità univoca: un certificato X.509, una coppia di chiavi o un insieme di credenziali che dimostrino che è esattamente il dispositivo che dichiara di essere. Il provisioning del dispositivo è il processo che genera e consegna quell'identità: in fase di produzione, prima della spedizione, o da remoto dopo il deploy.
Una gestione debole delle identità dei dispositivi è la principale vulnerabilità di sicurezza in un prodotto IoT: una credenziale compromessa può esporre ogni dispositivo che la condivide.
La sfida del provisioning dei dispositivi
La maggior parte dei team parte dall'approccio più semplice possibile: un segreto condiviso o una credenziale hardcoded nel firmware. Funziona per un prototipo. Crolla su scala per diversi motivi:
- Credenziali condivise, rischio condiviso: se un dispositivo viene compromesso, ogni dispositivo con la stessa credenziale è esposto.
- I processi manuali non scalano: generare certificati su fogli di calcolo e scriverli sui dispositivi via USB va bene per piccoli lotti; non regge i volumi di produzione.
- Integrazione con la linea di produzione: il passo di provisioning deve integrarsi nel flusso della linea produttiva esistente, un processo che i tecnici in fabbrica possano eseguire in modo affidabile senza accedere a strumenti cloud.
- Dispositivi già in campo: i dispositivi già deployati con credenziali temporanee o non sicure hanno bisogno di un meccanismo per ottenere la propria identità definitiva senza dover tornare in fabbrica.
- Rotazione e scadenza dei certificati: i certificati X.509 hanno una durata; un sistema in produzione deve avere un piano di rinnovo prima che la scadenza causi un'interruzione di flotta.
- Audit trail: i regolatori e i clienti enterprise chiedono sempre più spesso documentazione su quando ogni dispositivo è stato registrato e con quale credenziale.
Cosa serve per farlo bene
Un sistema di provisioning corretto opera in due fasi:
Provisioning del certificato in produzione: durante la produzione, ogni dispositivo riceve un'identità univoca (un certificato X.509 firmato dalla tua CA) insieme alla configurazione iniziale. Questo passo di registrazione in produzione deve integrarsi con gli strumenti della linea, girare abbastanza velocemente da non diventare un collo di bottiglia e produrre un record di audit per ogni dispositivo.
Inizializzazione remota: per i dispositivi già in campo con credenziali temporanee (o senza credenziali), un processo di bootstrap sicuro permette al dispositivo di dimostrare la propria identità tramite un token monouso e ricevere il proprio certificato X.509 definitivo su un canale cifrato. Questo elimina la necessità di richiamare i dispositivi in fabbrica per aggiornare le credenziali.
Entrambe le fasi richiedono: una certificate authority (o l'integrazione con una esistente), un'API di enrollment, un client lato dispositivo e un audit log di back-office.
Come Connhex risolve il problema
Connhex fornisce due servizi dedicati al provisioning dei dispositivi:
Connhex Manufacturing gestisce la registrazione in produzione. Durante la fase produttiva, la tua linea chiama l'API Connhex (o usa la CLI open-source) per registrare ogni dispositivo, generarne il certificato e scrivere le credenziali sul dispositivo. Il processo richiede pochi secondi per unità e produce un audit trail completo. Nessun passaggio manuale, nessun foglio di calcolo.
Connhex Provisioning gestisce il ciclo di vita del certificato lato cloud: emissione, archiviazione e tracciamento della scadenza.
Connhex Remote Init gestisce il caso del dispositivo già deployato. Un dispositivo con un token temporaneo avvia un handshake sicuro, il backend Connhex valida il token e il dispositivo riceve il proprio certificato X.509 definitivo su un canale cifrato, senza alcun intervento umano e senza richiamare i dispositivi in fabbrica.
Entrambi i servizi sono modulari: se hai già un'infrastruttura cloud, puoi integrare solo Provisioning e Remote Init, lasciando tutto il resto invariato. È esattamente ciò che ha fatto Seitron.
L'infrastruttura di provisioning soddisfa direttamente il requisito del EU Cyber Resilience Act per le identità univoche dei dispositivi e l'architettura secure-by-design.
Vedi come funziona in pratica
Nel software, tendiamo ad usare la parola modularità troppo spesso: in questo caso, invece, il suo utilizzo è più che appropriato. La modularità di Connhex ci ha consentito una rapida integrazione di un servizio critico.
Senior Software Engineer - Seitron
Seitron, produttore italiano di termostati wireless e sistemi di termoregolazione, ha integrato Connhex Provisioning e Remote Init nella propria infrastruttura cloud esistente. Leggi la storia completa: Aggiungere Connhex Provisioning ad un'infrastruttura esistente.
Il provisioning è rilevante in ogni settore in cui Connhex è utilizzato: Connhex per HVAC · Connhex per i distributori automatici · Connhex per la smart home
Leggi la documentazione tecnica
- Connhex Provisioning, Introduzione
- Connhex Remote Init, Introduzione
- Connhex Manufacturing, Introduzione