Sécurité
IronFlock est conçu pour les environnements IoT industriels et d’entreprise où la sécurité n’est pas optionnelle. Le système suit une architecture zero-trust avec défense en profondeur à chaque couche.
Aucun port ouvert sur les appareils
Les appareils edge exécutant IronFlock n’exposent aucun port ouvert. L’agent de l’appareil initie toutes les connexions sortantes vers le routeur de messages WAMP. Cela signifie :
- Aucune règle de pare-feu entrante n’est nécessaire sur le réseau de l’appareil.
- Les appareils ne sont pas découvrables ou directement adressables depuis internet.
- L’accès à distance fonctionne via des tunnels inversés.
Authentification
IronFlock utilise OpenID Connect (OIDC) pour l’authentification des utilisateurs.
Authentification multi-facteurs
Tous les comptes supportent l’authentification à deux facteurs basée sur TOTP. Les utilisateurs peuvent activer la 2FA dans les paramètres de leur compte.
Clés API
Pour l’accès programmatique, les utilisateurs génèrent des clés API qui s’authentifient contre l’API REST.
Authentification des appareils
Les appareils s’authentifient en utilisant WAMP-CRA (Challenge-Response Authentication) avec des identifiants par appareil.
Transports chiffrés
Toute la communication dans IronFlock est chiffrée :
| Connexion | Protocole | Chiffrement |
|---|---|---|
| Navigateur vers IronFlock | HTTPS | TLS 1.2+ |
| Appareil vers routeur | WSS (WebSocket Secure) | TLS 1.2+ |
| Service vers service | WSS | TLS (interne) |
| Connexions base de données | PostgreSQL SSL | TLS |
| Tunnels d’accès à distance | Proxy inversé sur TLS | TLS |
Isolation de la messagerie
Chaque combinaison projet-application obtient son propre realm de messagerie sur le routeur WAMP. Un realm est un espace de noms complètement isolé.
Isolation de la base de données
Chaque projet obtient ses propres ressources de base de données dédiées dans FleetDB (PostgreSQL) :
- Tables séparées — Chaque combinaison projet-application a ses propres tables de séries temporelles.
- Identifiants séparés — Chaque backend de données a des identifiants de connexion uniques.
Sécurité de la chaîne d’approvisionnement logicielle
La sécurité ne se limite pas à la manière dont le logiciel s’exécute — elle commence par la manière dont il est construit et distribué. Le IronFlock Supervisor, le seul composant d’IronFlock qui s’exécute directement sur vos appareils, est produit au travers d’une chaîne d’approvisionnement durcie et entièrement automatisée, afin que vous puissiez avoir confiance en ce qui parvient exactement à votre flotte.
- Surface d’attaque minimale — Le Supervisor est distribué sous la forme d’un unique binaire Go lié statiquement, sans aucune dépendance d’exécution externe ni interpréteur embarqué. Il n’y a aucun gestionnaire de paquets, aucune arborescence de bibliothèques dynamiques, et rien qui écoute les connexions entrantes — ce qui réduit considérablement ce qu’un attaquant pourrait cibler.
- Analyse continue des vulnérabilités — Chaque version est analysée pour détecter les vulnérabilités connues (CVE) à travers notre propre code et toutes ses dépendances, à l’aide d’une analyse tenant compte de l’accessibilité qui se concentre sur les chemins de code que le binaire peut réellement exécuter. Les analyses sont également exécutées selon une planification hebdomadaire, de sorte que les vulnérabilités divulguées après la publication d’une version apparaissent toujours sur les builds déjà déployés.
- Nomenclature logicielle (SBOM) — Chaque version publie une SBOM CycloneDX complète — un inventaire intégral de chaque composant et version entrant dans le binaire. Cela vous offre, ainsi qu’à vos auditeurs, une transparence exacte sur ce que vous exécutez.
- Builds signés et vérifiables — Chaque binaire de version est accompagné d’une attestation de provenance signée par sigstore, liée cryptographiquement à son contenu exact. La signature est inviolable et vérifiable de manière indépendante, ce qui vous permet de confirmer qu’un binaire a bien été produit par le pipeline d’IronFlock et n’a pas été altéré en transit.
- Publications automatisées et contrôlées — La compilation, la signature et la publication ont lieu dans un pipeline CI contrôlé — jamais sur la machine d’un développeur individuel. Rien n’est publié tant que l’ensemble de la suite automatisée de tests et de sécurité n’a pas réussi, garantissant que l’artefact distribué est exactement celui qui a été testé et attesté.
- Mises à jour OTA sécurisées — Les mises à jour OTA sont livrées via des canaux chiffrés et proviennent uniquement de builds signés et publiés par IronFlock — ainsi les appareils se mettent à jour eux-mêmes sans jamais ouvrir de port entrant ni faire confiance à un artefact non vérifié.
Ensemble, ces contrôles vous offrent une chaîne de traçabilité vérifiable, du code source jusqu’au binaire exécuté sur chaque appareil.
Conformité
L’architecture de sécurité d’IronFlock supporte la conformité avec :
- IEC 62443 — Sécurité des systèmes d’automatisation et de contrôle industriels
- ISO 27001 — Gestion de la sécurité de l’information
- SOC 2 — Contrôles de l’organisation de service pour la sécurité des données
- RGPD — Données stockées dans les centres de données de l’UE (configurable)
- EU Cyber Resilience Act (CRA) — Les SBOM par version et un processus de gestion continue et documenté des vulnérabilités répondent directement aux obligations fondamentales du CRA pour les produits comportant des éléments numériques.
- SLSA / NIST SSDF — La provenance de build signée et un pipeline CI contrôlé s’alignent sur les cadres reconnus d’intégrité de la chaîne d’approvisionnement et de développement logiciel sécurisé.