Sicurezza

IronFlock è progettato per ambienti IoT industriali e aziendali dove la sicurezza non è opzionale. Il sistema segue un’architettura zero-trust con difesa in profondità a ogni livello — dalla connettività dei dispositivi all’isolamento dei dati.

Nessuna Porta Aperta sui Dispositivi

I dispositivi edge che eseguono IronFlock non espongono alcuna porta aperta. L’agente del dispositivo avvia tutte le connessioni in uscita verso il router di messaggi WAMP. Questo significa:

• Non sono necessarie regole firewall in entrata sulla rete del dispositivo.
• I dispositivi non sono individuabili o direttamente indirizzabili da internet.
• L’accesso remoto funziona tramite tunnel inversi — il dispositivo si connette verso l’esterno, non viceversa.

Questo elimina un’intera classe di vettori di attacco comuni nelle implementazioni IoT dove i dispositivi rimangono in ascolto su porte aperte (SSH, HTTP, MQTT).

Autenticazione

IronFlock utilizza OpenID Connect (OIDC) per l’autenticazione degli utenti.

Autenticazione Multi-Fattore

Tutti gli account supportano l’autenticazione a due fattori basata su TOTP (Time-based One-Time Password). Gli utenti possono abilitare il 2FA nelle impostazioni del proprio account usando qualsiasi app di autenticazione standard (Google Authenticator, Authy, 1Password, ecc.).

Chiavi API

Per l’accesso programmatico, gli utenti generano chiavi API che si autenticano contro la REST API. Le chiavi API vengono validate ad ogni richiesta tramite il backend prima che qualsiasi operazione venga eseguita.

Autenticazione del Dispositivo

I dispositivi si autenticano usando WAMP-CRA (Challenge-Response Authentication) con credenziali per dispositivo. Ogni dispositivo riceve un segreto univoco durante il processo di flashing che viene memorizzato sul dispositivo e utilizzato per tutte le connessioni successive.

Trasporti Cifrati

Tutta la comunicazione in IronFlock è cifrata:

Non esiste alcun percorso di comunicazione in chiaro nell’intero sistema.

Isolamento della Messaggistica

IronFlock utilizza WAMP (Web Application Messaging Protocol) per tutta la comunicazione in tempo reale. Il router dei messaggi impone un rigido isolamento tra i progetti:

Realm Separati

Ogni combinazione progetto-app ottiene il proprio realm di messaggistica sul router WAMP. Un realm è uno spazio dei nomi completamente isolato — i messaggi pubblicati in un realm sono invisibili a tutti gli altri realm.

Questo significa:

• I dispositivi nel Progetto A non possono vedere i messaggi del Progetto B.
• L’App X installata nel Progetto A ha un realm diverso rispetto all’App X installata nel Progetto B.
• Anche se la stessa app è installata in due progetti, i flussi di dati sono completamente separati.

Autenticazione del Realm

Ogni connessione al realm richiede autenticazione. Dispositivi, servizi backend e client UI devono presentare credenziali valide per unirsi a un realm. I client non autorizzati non possono iscriversi agli argomenti o chiamare procedure.

Isolamento del Database

Ogni progetto ottiene le proprie risorse database dedicate in FleetDB (PostgreSQL):

• Tabelle separate — Ogni combinazione progetto-app ha il proprio set di tabelle time-series. Non esiste una tabella condivisa dove i dati di progetti diversi potrebbero trapelare.
• Credenziali separate — Ogni backend dei dati ha credenziali di connessione univoche. Le app possono accedere solo ai dati del proprio progetto.
• Nessuna query cross-project — Il livello del database impone che le query non possano attraversare i confini del progetto.

Questo isolamento è applicato a livello infrastrutturale, non solo a livello applicativo. Anche un’app compromessa non può accedere ai dati di un altro progetto.

Sistema dei Privilegi

IronFlock applica un modello di privilegi per asset dove ogni progetto, dispositivo, gruppo, app, dashboard e backend dei dati ha il proprio controllo degli accessi:

• Il proprietario di un asset ha il pieno controllo e può concedere permessi ad altri utenti.
• Il proprietario del progetto ha automaticamente il pieno controllo su tutti gli asset all’interno di quel progetto.
• Ogni permesso è un flag booleano discreto — non esistono ruoli “admin” ampi che concedono accesso illimitato.
• Tutte le modifiche ai privilegi vengono registrate in un audit trail immutabile.

Vedi Privilegi per l’elenco completo dei permessi per tipo di asset.

Sicurezza della Supply Chain del Software

La sicurezza non si ferma a come il software viene eseguito — inizia da come il software viene costruito e distribuito. Il Supervisor di IronFlock, l’unico componente di IronFlock che viene eseguito direttamente sui tuoi dispositivi, è costruito attraverso una supply chain rafforzata e completamente automatizzata, così puoi fidarti esattamente di ciò che arriva alla tua flotta.

• Superficie di attacco minima — Il Supervisor viene distribuito come un singolo binario Go collegato staticamente, senza dipendenze di runtime esterne e senza interprete incorporato. Non c’è alcun gestore di pacchetti, nessun albero di librerie dinamiche e nulla in ascolto di connessioni in entrata — riducendo drasticamente ciò che un attaccante potrebbe prendere di mira.
• Scansione continua delle vulnerabilità — Ogni release viene scansionata alla ricerca di vulnerabilità note (CVE) sia nel nostro codice sia in tutte le dipendenze, utilizzando un’analisi consapevole della raggiungibilità che si concentra sui percorsi di codice che il binario può effettivamente eseguire. Le scansioni vengono inoltre eseguite con cadenza settimanale, così le vulnerabilità divulgate dopo il rilascio di una versione emergono comunque rispetto alle build già distribuite.
• Software Bill of Materials (SBOM) — Ogni release pubblica un SBOM CycloneDX completo — un inventario integrale di ogni componente e versione confluiti nel binario. Questo offre a te, e ai tuoi auditor, una trasparenza esatta su ciò che stai eseguendo.
• Build firmate e verificabili — Ogni binario di release porta con sé un’attestazione di provenienza firmata con sigstore legata crittograficamente al suo contenuto esatto. La firma rende evidente qualsiasi manomissione ed è verificabile in modo indipendente, così puoi confermare che un binario è stato prodotto dalla pipeline di IronFlock e non è stato alterato durante il trasferimento.
• Release automatizzate e controllate — Build, firma e pubblicazione avvengono in una pipeline CI controllata — mai sulla macchina di un singolo sviluppatore. Nulla viene pubblicato a meno che l’intera suite automatizzata di test e sicurezza non venga superata, garantendo che l’artefatto distribuito sia esattamente quello che è stato testato e attestato.
• Aggiornamenti over-the-air sicuri — Gli aggiornamenti OTA vengono distribuiti su canali cifrati e provengono esclusivamente da build firmate e pubblicate da IronFlock — così i dispositivi si aggiornano da soli senza mai aprire una porta in entrata né fidarsi di un artefatto non verificato.

Insieme, questi controlli ti offrono una catena di custodia verificabile dal codice sorgente al binario in esecuzione su ciascun dispositivo.

Conformità

L’architettura di sicurezza di IronFlock supporta la conformità con:

• IEC 62443 — Sicurezza dei sistemi di automazione e controllo industriale
• ISO 27001 — Gestione della sicurezza delle informazioni
• SOC 2 — Controlli per le organizzazioni di servizi sulla sicurezza dei dati
• GDPR — Dati archiviati in data center UE (configurabile), audit trail per l’accesso ai dati
• EU Cyber Resilience Act (CRA) — Gli SBOM per ogni release e un processo documentato e continuo di gestione delle vulnerabilità rispondono direttamente agli obblighi fondamentali del CRA per i prodotti con elementi digitali.
• SLSA / NIST SSDF — La provenienza firmata delle build e una pipeline CI controllata si allineano ai framework riconosciuti per l’integrità della supply chain e lo sviluppo sicuro del software.

La combinazione di trasporti cifrati, autenticazione, isolamento dei dati per progetto, privilegi granulari, registrazione audit completa e una software supply chain rafforzata fornisce i controlli richiesti da questi framework.