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 connexion qui traverse un réseau échappant au contrôle d’IronFlock est chiffrée :

Les services IronFlock communiquent entre eux et avec leurs bases de données sur un réseau privé inaccessible depuis l’extérieur — le réseau du cluster dans le cloud, l’hôte lui-même sur une appliance.

Sur une IronFlock Appliance, ce qui est chiffré dépend du mode dans lequel elle fonctionne : dans son mode par défaut HTTP en clair, les navigateurs et les appareils se connectent sans TLS. Voir Ce que protège chaque mode.

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é, et non sur la machine d’un développeur individuel ; les quelques étapes encore effectuées manuellement sont indiquées dans Clés de signature. 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é.
• Clés de signature publiées — Les clés avec lesquelles les appareils et les appliances vérifient chaque installateur et chaque mise à jour, leurs empreintes et la manière dont une clé est remplacée sont présentées sur la page Clés de signature.

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.

Signaler des vulnérabilités

Pour signaler une vulnérabilité, et pour savoir comment les correctifs de sécurité sont annoncés et quels avis ont été publiés, consultez Avis de sécurité.

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é. La provenance de build des images de service de la plateforme satisfait à SLSA Build Level 3 (voir Clés de signature).