RTLS für IT und OT.
RTLS ist Betriebstechnologie. Es nutzt dein Netzwerk, integriert sich mit bereits sicheren Systemen und erzeugt neue Daten, die verwaltet werden müssen. Das ist die IT- und OT-Perspektive – die Fragen, die beantwortet werden sollten, bevor Hardware bestellt wird.
Das Netzwerk, Segmentierung und IEC 62443
RTLS-Deployments bestehen die Sicherheitsprüfung nicht, wenn sie als IT-Projekte und nicht als OT-Projekte behandelt werden.
Der richtige Ausgangspunkt ist eine Purdue-modellbewusste Architektur: Wo befinden sich die Anchors, Gateways und Middleware? Welche Zone? Welche Leitungen? Moderne RTLS-Plattformen unterstützen die IEC 62443-ausgerichtete Segmentierung,
gegenseitiges TLS, rollenbasierten Zugriff und Audit-Logging – aber nur, wenn es von Gate 1 aus konzipiert ist.
Die Nachrüstung der Sicherheit nach der Unterzeichnung der Architektur kostet mehr als eine Neugestaltung.
Identität und Zugang – wer welchen Ort sehen kann
Standortdaten sind von Natur aus sensibel: Sie können Mitarbeiter identifizieren, Prozesswissen offenlegen und regulatorische Risiken schaffen (DSGVO, Betriebsrat).
Die rechte Kontrollebene trennt die Rohpositionstelemetrie von der abgeleiteten Analyse, wendet rollenbasierten Zugriff auf der API-Ebene an und protokolliert jede Abfrage.
Die Standardeinstellungen auf den meisten Anbieterplattformen sind für europäische Unternehmenskontexte falsch – sie müssen explizit abgestimmt werden.
Integrationsmuster, die tatsächlich skalieren
Drei Integrationsmuster funktionieren im Unternehmensmaßstab: Streaming (MQTT oder Kafka für hochfrequente Positionsereignisse in eine digitale Zwillings- oder Analyseschicht),
API-gesteuert (REST oder gRPC für WMS, MES oder EMR, um Standorte auf Abruf zu ziehen) und ESB-vermittelt (wo man bereits einen Enterprise-Servicebus betreibt, MuleSoft, Boomi).
Das falsche Muster bindet dich an das Datenmodell des Anbieters. Wir entwerfen für das Muster, das dein Stapel bereits verwendet.
Lieferanten- und Lieferkettenkontrolle
Moderne Beschaffung erfordert SBOM-, SOC 2- oder ISO 27001-Attestationen sowie Patch-Management-Verpflichtungen von RTLS-Lieferanten. Nicht alle Anbieter erfüllen diese Maßstäbe – und diejenigen, die es tun, sind nicht immer die technisch stärksten.
Wir führen eine Vendor-Prüfung anhand Ihrer spezifischen Sicherheitslage durch (oft direkt mit Ihrem CISO) und erstellen eine Scorecard, die einer Überprüfung durch Third-Party-Risiken standhält.
Häufig gestellte Fragen
Braucht RTLS ein eigenes VLAN, oder kann es bestehende Infrastruktur nutzen?
Das hängt von der Technologie und Ihrer operativen Risikotoleranz ab. BLE und Wi-Fi basierende RTLS können bestehende Infrastruktur sorgfältig nutzen; UWB-Anker profitieren typischerweise von einem dedizierten VLAN.
Wir entwerfen Segmentierung als Teil der Architektur, nicht als Nachgedanke.
Wie werden Standortdaten während des Transports und in Ruhe gesichert?
Moderne Plattformen unterstützen gegenseitige TLS für den Transit und AES-256 im Ruhezustand mit rollenbasiertem Zugriff und Audit-Protokollierung. Wir überprüfen die Umsetzung, nicht die Marketingbehauptung, während der Überprüfung von Gate 1 und dem Pilotprojekt.
Können wir RTLS in einer Air-Gapped oder mit eingeschränktem Netzwerk laufen lassen?
Ja – häufig im Verteidigungs-, Pharma- und einigen industriellen Kontexten. Wir haben architektonische Systeme, die vollständig vor Ort laufen und keine ausgehende Verbindung haben, auch in klassifizierten Einrichtungen. Die Händler-Shortlist wird kürzer; Wir navigieren es.
Wie sieht die Integration mit unserem bestehenden SIEM aus?
Die meisten RTLS-Plattformen senden Syslog-, JSON- oder CEF-formatierte Events, die sauber mit Splunk, Sentinel, Elastic oder QRadar integriert werden. Die spezifische Ereigniskartierung erfolgt in Phase 1 mit Ihrem Sicherheitsteam.
Zuletzt aktualisiert: