Sicherheit
IronFlock ist für industrielle und unternehmenskritische IoT-Umgebungen konzipiert, in denen Sicherheit keine Option, sondern eine Notwendigkeit ist. Das System folgt einer Zero-Trust-Architektur mit Defense-in-Depth über jede Schicht hinweg — von der Gerätekonnektivität bis zur Datenisolation.
Keine offenen Ports auf Geräten
Edge-Geräte, die IronFlock ausführen, haben keine offenen Ports. Der Geräteagent initiiert alle Verbindungen ausgehend zum WAMP-Nachrichtenrouter. Das bedeutet:
- Keine eingehenden Firewall-Regeln sind im Gerätenetzwerk erforderlich.
- Geräte sind nicht auffindbar und nicht direkt aus dem Internet erreichbar.
- Fernzugriff funktioniert über Reverse-Tunnel — das Gerät verbindet sich nach außen, nicht umgekehrt.
Dies eliminiert eine ganze Klasse von Angriffsvektoren, die bei IoT-Bereitstellungen üblich sind, bei denen Geräte auf offenen Ports lauschen (SSH, HTTP, MQTT).
Authentifizierung
IronFlock verwendet OpenID Connect (OIDC) für die Benutzerauthentifizierung.
Multi-Faktor-Authentifizierung
Alle Konten unterstützen TOTP-basierte Zwei-Faktor-Authentifizierung (Time-based One-Time Password). Benutzer können 2FA in ihren Kontoeinstellungen mit jeder Standard-Authenticator-App aktivieren (Google Authenticator, Authy, 1Password usw.).
API-Schlüssel
Für programmatischen Zugriff erzeugen Benutzer API-Schlüssel, die sich gegen die REST-API authentifizieren. API-Schlüssel werden bei jeder Anfrage durch das Backend validiert, bevor eine Operation ausgeführt wird.
Geräteauthentifizierung
Geräte authentifizieren sich über WAMP-CRA (Challenge-Response-Authentifizierung) mit gerätespezifischen Zugangsdaten. Jedes Gerät erhält während des Flashvorgangs ein einzigartiges Geheimnis, das auf dem Gerät gespeichert und für alle nachfolgenden Verbindungen verwendet wird.
Verschlüsselte Übertragungswege
Alle Kommunikation in IronFlock ist verschlüsselt:
| Verbindung | Protokoll | Verschlüsselung |
|---|---|---|
| Browser zu IronFlock | HTTPS | TLS 1.2+ |
| Gerät zu Router | WSS (WebSocket Secure) | TLS 1.2+ |
| Dienst zu Dienst | WSS | TLS (intern) |
| Datenbankverbindungen | PostgreSQL SSL | TLS |
| Fernzugriffs-Tunnel | Reverse Proxy über TLS | TLS |
Es gibt keinen unverschlüsselten Kommunikationsweg im gesamten System.
Nachrichtenisolation
IronFlock verwendet WAMP (Web Application Messaging Protocol) für alle Echtzeitkommunikation. Der Nachrichtenrouter erzwingt strikte Isolation zwischen Projekten:
Separate Realms
Jede Projekt-App-Kombination erhält ihren eigenen Messaging-Realm auf dem WAMP-Router. Ein Realm ist ein vollständig isolierter Namensraum — Nachrichten, die in einem Realm veröffentlicht werden, sind für alle anderen Realms unsichtbar.
Das bedeutet:
- Geräte in Projekt A können keine Nachrichten von Projekt B sehen.
- App X, installiert in Projekt A, hat einen anderen Realm als App X, installiert in Projekt B.
- Selbst wenn dieselbe App in zwei Projekten installiert ist, sind die Datenflüsse vollständig getrennt.
Realm-Authentifizierung
Jede Realm-Verbindung erfordert Authentifizierung. Geräte, Backend-Dienste und UI-Clients müssen gültige Zugangsdaten vorlegen, um einem Realm beizutreten. Nicht autorisierte Clients können keine Topics abonnieren oder Prozeduren aufrufen.
Datenbankisolation
Jedes Projekt erhält seine eigenen dedizierten Datenbankressourcen in FleetDB (PostgreSQL):
- Separate Tabellen — Jede Projekt-App-Kombination hat ihren eigenen Satz von Zeitreihentabellen. Es gibt keine gemeinsame Tabelle, in der Daten verschiedener Projekte durchsickern könnten.
- Separate Zugangsdaten — Jedes Daten-Backend hat einzigartige Verbindungszugangsdaten. Apps können nur auf die Daten ihres eigenen Projekts zugreifen.
- Keine projektübergreifenden Abfragen — Die Datenbankschicht stellt sicher, dass Abfragen keine Projektgrenzen überschreiten können.
Diese Isolation wird auf Infrastrukturebene erzwungen, nicht nur auf Anwendungsebene. Selbst eine kompromittierte App kann nicht auf Daten eines anderen Projekts zugreifen.
Privilegiensystem
IronFlock erzwingt ein Asset-bezogenes Privilegienmodell, bei dem jedes Projekt, Gerät, jede Gruppe, App, jedes Dashboard und Daten-Backend seine eigene Zugriffskontrolle hat:
- Der Eigentümer eines Assets hat die volle Kontrolle und kann anderen Benutzern Berechtigungen erteilen.
- Der Projekteigentümer hat automatisch volle Kontrolle über alle Assets innerhalb dieses Projekts.
- Jede Berechtigung ist ein diskretes boolesches Flag — es gibt keine breiten „Admin”-Rollen, die uneingeschränkten Zugriff gewähren.
- Alle Privilegienänderungen werden in einem unveränderlichen Audit-Trail aufgezeichnet.
Siehe Privilegien für die vollständige Liste der Berechtigungen pro Asset-Typ.
Sicherheit der Software-Lieferkette
Sicherheit endet nicht bei der Frage, wie die Software ausgeführt wird — sie beginnt damit, wie die Software erstellt und ausgeliefert wird. Der IronFlock Supervisor, die einzige IronFlock-Komponente, die direkt auf Ihren Geräten läuft, wird über eine gehärtete, vollständig automatisierte Supply Chain erstellt, damit Sie genau dem vertrauen können, was Ihre Flotte erreicht.
- Minimale Angriffsfläche — Der Supervisor wird als einzelnes, statisch gelinktes Go-Binary ohne externe Laufzeitabhängigkeiten und ohne eingebetteten Interpreter ausgeliefert. Es gibt keinen Paketmanager, keinen Baum dynamischer Bibliotheken und nichts, das auf eingehende Verbindungen lauscht — was die Angriffsfläche drastisch reduziert.
- Kontinuierliches Schwachstellen-Scanning — Jedes Release wird auf bekannte Schwachstellen (CVEs) geprüft, sowohl in unserem eigenen Code als auch in allen Abhängigkeiten, mithilfe einer erreichbarkeitsbewussten Analyse, die sich auf die Code-Pfade konzentriert, die das Binary tatsächlich ausführen kann. Scans laufen zudem wöchentlich nach Zeitplan, sodass Schwachstellen, die nach der Auslieferung einer Version offengelegt werden, weiterhin gegen bereits ausgerollte Builds erkannt werden.
- Software Bill of Materials (SBOM) — Jedes Release veröffentlicht eine vollständige CycloneDX SBOM — ein vollständiges Inventar jeder Komponente und Version, die in das Binary eingeflossen ist. Das verschafft Ihnen und Ihren Auditoren exakte Transparenz darüber, was Sie ausführen.
- Signierte, verifizierbare Builds — Jedes Release-Binary trägt eine sigstore-signierte Provenance-Attestierung, die kryptografisch an seinen exakten Inhalt gebunden ist. Die Signatur ist manipulationssicher und unabhängig verifizierbar, sodass Sie bestätigen können, dass ein Binary von IronFlocks Pipeline erzeugt und auf dem Transportweg nicht verändert wurde.
- Kontrollierte, automatisierte Releases — Build, Signierung und Veröffentlichung erfolgen in einer kontrollierten CI-Pipeline — niemals auf dem Rechner einzelner Entwickler. Nichts wird veröffentlicht, solange nicht die vollständige automatisierte Test- und Sicherheits-Suite besteht, wodurch sichergestellt ist, dass das ausgelieferte Artefakt exakt jenes ist, das getestet und attestiert wurde.
- Sichere Over-the-Air-Updates — OTA-Updates werden über verschlüsselte Kanäle ausgeliefert und stammen ausschließlich aus von IronFlock veröffentlichten, signierten Builds — sodass Geräte sich selbst aktualisieren, ohne jemals einen eingehenden Port zu öffnen oder einem unverifizierten Artefakt zu vertrauen.
Zusammen ergeben diese Kontrollen eine verifizierbare lückenlose Nachweiskette vom Quellcode bis zum Binary, das auf jedem Gerät läuft.
Compliance
Die Sicherheitsarchitektur von IronFlock unterstützt die Einhaltung von:
- IEC 62443 — Sicherheit industrieller Automatisierungs- und Steuerungssysteme
- ISO 27001 — Informationssicherheitsmanagement
- SOC 2 — Kontrollstandards für Datensicherheit bei Dienstleistungsorganisationen
- DSGVO — Daten werden in EU-Rechenzentren gespeichert (konfigurierbar), Audit-Trail für Datenzugriff
- EU Cyber Resilience Act (CRA) — Release-spezifische SBOMs und ein dokumentierter, kontinuierlicher Prozess zum Umgang mit Schwachstellen adressieren unmittelbar die Kernpflichten des CRA für Produkte mit digitalen Elementen.
- SLSA / NIST SSDF — Signierte Build-Provenance und eine kontrollierte CI-Pipeline stehen im Einklang mit anerkannten Rahmenwerken für Supply-Chain-Integrität und sichere Softwareentwicklung.
Die Kombination aus verschlüsselten Übertragungswegen, Authentifizierung, projektbezogener Datenisolation, granularen Privilegien, umfassender Audit-Protokollierung und einer gehärteten Software Supply Chain bietet die Kontrollen, die von diesen Rahmenwerken gefordert werden.