MQTT Datenresidenz und Regionswahl: der Leitfaden

Bei der MQTT-Datenresidenz geht es darum zu wissen und zu steuern, wo Ihre IoT-Nachrichten auf dem Weg vom Gerät zur Anwendung verarbeitet und gespeichert werden. Dieser Artikel erklärt, welche Teile eines MQTT-Systems mit Daten in Berührung kommen, welche regulatorischen und vertraglichen Fragen üblicherweise gelten und wie Regionswahl und Bring-Your-Own-Cloud-Deployments helfen, sie zu erfüllen. Es handelt sich um einen praktischen Engineering-Leitfaden, nicht um Rechtsberatung; beziehen Sie für Entscheidungen Ihr Rechts- oder Compliance-Team ein.

Was Datenresidenz für MQTT bedeutet

Datenresidenz ist die Anforderung, dass bestimmte Daten innerhalb eines bestimmten geografischen Raums gespeichert oder verarbeitet werden, etwa in einem Land oder im Europäischen Wirtschaftsraum. Verwandte Begriffe werden oft unscharf verwendet:

Datenresidenz: wo sich Daten physisch befinden.
Datensouveränität: welches Recht welcher Jurisdiktion auf die Daten anwendbar ist.
Datenlokalisierung: eine gesetzliche Vorgabe, dass Daten in einem Land bleiben müssen.

Ein MQTT-Broker liegt im Datenpfad jeder Nachricht. Selbst wenn Ihre Datenbank im richtigen Land steht, empfängt, verarbeitet und speichert ein Broker in einer anderen Region diese Nachrichten womöglich trotzdem. Zu verstehen, was ein MQTT-Broker mit Ihren Daten macht, ist der Ausgangspunkt.

Wo Daten in einem MQTT-System liegen

Erfassen Sie jeden Ort, an dem eine Nachricht existieren kann, nicht nur Ihre Datenbank:

Ort	Was dort liegt	Frage zur Residenz
Gerät	Messwerte vor dem Senden, gepufferte Nachrichten	Wo sind die Geräte installiert?
Netzwerkpfad	Nachrichten während der Übertragung	Ist der Verkehr bis zum Broker durchgehend per TLS verschlüsselt?
Broker-Arbeitsspeicher	Nachrichten im Routing	In welcher Region läuft der Broker?
Retained Messages	Letzter Wert pro Topic	Wo und wie lange gespeichert?
Persistente Sitzungen	Wartende Nachrichten für Offline-Clients	Wo gespeichert, und wann laufen sie ab?
Broker-Logs	Client IDs, IP-Adressen, manchmal Topics	Enthalten Logs personenbezogene Daten, und wo werden sie aufbewahrt?
Subscriber und Backends	Alles Nachgelagerte	Wo laufen Ihre Services und Datenbanken?

Zwei Punkte werden leicht übersehen. Erstens sind Retained Messages und in Sitzungen wartende Nachrichten ruhende Daten auf dem Broker. Zweitens können Broker-Logs IP-Adressen und Client-Kennungen enthalten, die nach manchen Regelwerken personenbezogene Daten sind.

Regulatorische und vertragliche Treiber

DSGVO und personenbezogene Daten

Nach der EU-Datenschutz-Grundverordnung dürfen personenbezogene Daten nur mit geeigneten Garantien außerhalb des EWR übermittelt werden. Nicht alle IoT-Daten sind personenbezogen, viele aber schon: der Standort aus einem Fahrzeug-Tracker, die Belegung einer Wohnung, der einem Haushalt zugeordnete Energieverbrauch oder Gesundheitswerte von einem Wearable. Wenn sich ein Gerät einer Person zuordnen lässt, können seine Telemetriedaten personenbezogen sein. In der Fertigung betrifft das etwa Maschinendaten, die über Schichtpläne oder Anmeldungen am Bedienpanel einzelnen Mitarbeitenden zugeordnet werden können, was in Deutschland häufig auch den Betriebsrat auf den Plan ruft.

Branchen- und Kundenanforderungen

Über das Datenschutzrecht hinaus entstehen Residenzanforderungen oft durch:

Aufträge der öffentlichen Hand, die Hosting im Inland verlangen.
Kritische Infrastrukturen und Versorger mit nationalen Sicherheitsvorschriften; in der EU erweitert die NIS2-Richtlinie den Kreis der betroffenen Unternehmen deutlich, auch auf Teile des verarbeitenden Gewerbes.
Maschinenbauer und Zulieferer, deren Prozess- und Maschinendaten als Betriebsgeheimnis gelten und die ihren Kunden vertraglich zusichern, wo diese Daten verarbeitet werden.
Kunden aus Gesundheits- und Finanzwesen mit eigenen Richtlinien.
Einkaufsfragebögen von Unternehmen, die wissen wollen, wo jeder Unterauftragsverarbeiter läuft.

Häufig ist die strengste Anforderung gar kein Gesetz, sondern eine Klausel in einem Kundenvertrag. Für Unternehmen mit Werken in Deutschland, Österreich und der Schweiz kommt hinzu, dass die Schweiz nicht zum EWR gehört und ein eigenes Datenschutzgesetz hat. Sammeln Sie diese Anforderungen, bevor Sie ein Hosting-Modell wählen.

Residenzrisiken im Design verringern

Engineering-Entscheidungen können das Problem verkleinern, unabhängig davon, wo der Broker läuft:

Personenbezogene Daten im Payload minimieren. Senden Sie Geräte-IDs, keine Namen oder Adressen. Lösen Sie Identitäten in Ihrem Backend auf, in der richtigen Region.
Personenbezogene Daten aus Topic-Namen heraushalten. Topics erscheinen in Logs, Explorern und Debugging-Tools.
TLS für jede Verbindung nutzen. Die Ports 8883 und 8084 verschlüsseln Daten während der Übertragung.
Ruhende Daten auf dem Broker begrenzen. Nutzen Sie den Nachrichtenablauf (Message Expiry) von MQTT 5 und eine vernünftige Session Expiry, und vermeiden Sie Retained Messages mit personenbezogenen Daten.
Am Edge verarbeiten. Aggregieren oder anonymisieren Sie auf einem Gateway, bevor Sie in die Cloud publizieren. In einer Architektur mit Unified Namespace (UNS) kann ein lokaler Broker im Werk die vollständigen Rohdaten halten, während nur verdichtete Kennzahlen wie OEE oder Energieverbrauch pro Linie den Standort verlassen.
Den Datenfluss dokumentieren. Ein Diagramm mit jeder Komponente und ihrer Region beantwortet die meisten Einkaufsfragen.

Hier ein Python-Beispiel (paho-mqtt 2.x), das pseudonyme Telemetrie mit einem MQTT-5-Nachrichtenablauf publiziert, sodass der Broker sie verwirft, wenn kein Subscriber sie innerhalb von zehn Minuten abholt.

import json
import ssl
import time
import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
                     protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.connect("YOUR_BROKER_HOST", 8883, keepalive=60)
client.loop_start()

props = Properties(PacketTypes.PUBLISH)
props.MessageExpiryInterval = 600   # Sekunden

payload = {"device": "dev-4f9a", "kwh": 1.84, "ts": int(time.time())}  # keine Namen oder Adressen
info = client.publish("site-07/meter/dev-4f9a/telemetry", json.dumps(payload),
                      qos=1, properties=props)
info.wait_for_publish()
client.loop_stop()
client.disconnect()

Zielkonflikte bei der Regionswahl

Die Wahl der Broker-Region ist eine Abwägung zwischen Residenz, Latenz und Komfort:

Residenz: Die Region muss Ihre rechtlichen und vertraglichen Anforderungen erfüllen.
Latenz: Geräte und Konsumenten weit weg vom Broker erleben längere Round Trips; siehe MQTT-Broker-Latenz nach Region.
Co-Location: Ein Broker in der Nähe Ihres Backends reduziert regionsübergreifenden Datentransfer.
Fleets in mehreren Regionen: Wenn Sie in mehreren Jurisdiktionen verkaufen, benötigen Sie unter Umständen einen Broker pro Region, wobei jedes Gerät für seinen Heimat-Broker konfiguriert ist.

Der letzte Punkt ist architektonisch wichtig. Eine über Regionen verteilte Geräteflotte bedeutet meist getrennte Broker und getrennte Backends pro Region, wobei nur aggregierte, nicht personenbezogene Daten in eine globale Sicht fließen.

Aufbewahrung und Löschung

Fragen zur Residenz gehen meist mit Fragen zur Aufbewahrung einher. Legen Sie fest, wie lange jede Datenart in jeder Stufe leben darf: im Gerätepuffer, auf dem Broker als Retained oder wartende Nachricht, in Logs und in Ihren Datenbanken. Ermöglichen Sie Löschungen pro Gerät und pro Kunde, denn das Offboarding eines Kunden oder die Umsetzung eines Löschantrags bedeutet, Daten überall dort zu entfernen, wohin sie kopiert wurden. Eine Retained Message zu löschen ist in MQTT einfach: Publizieren Sie einen leeren Retained-Payload auf dasselbe Topic.

Wie BYOC das Residenzthema löst

Die stärkste Antwort auf die Frage „Wo sind unsere Daten?" lautet: „In unserem eigenen Cloud-Account, in einer Region, die wir gewählt haben." Genau das ist das Bring-Your-Own-Cloud-Modell. Mit ConnectMQ BYOC läuft der Broker in Ihrem Cloud-Account und ConnectMQ verwaltet ihn. So bestimmen Sie Region, Netzwerkgrenzen und Logging-Richtlinie selbst und vermeiden trotzdem den Betriebsaufwand des Self-Hostings. Details finden Sie in unserem Artikel zum BYOC MQTT-Broker.

Andere ConnectMQ-Pläne decken andere Bedürfnisse ab. Serverless-Broker auf dem geteilten Cluster sind ideal für Entwicklung, Pilotprojekte und Daten ohne Residenzvorgaben. Ein Dedicated-Plan bietet Ihnen einen isolierten Cluster. Fragen Sie bei beiden ConnectMQ, wo die Infrastruktur läuft, und nehmen Sie die Antwort in Ihre Datenflussdokumentation auf. Organisationen, die alles selbst betreiben müssen, können Self Managed Enterprise in Betracht ziehen.

Unabhängig vom Plan ändert sich auf der Client-Seite nichts: MQTT 3.1.1 oder 5.0 über TLS auf Port 8883 oder Secure WebSocket auf 8084 mit dem Pfad /mqtt. Eine Flotte von einem Hosting-Modell in ein anderes zu verschieben, heißt lediglich, Host und Zugangsdaten zu aktualisieren.

Residenz-Checkliste vor dem Launch

Listen Sie die Jurisdiktionen auf, in denen sich Geräte, Nutzer und Kunden befinden.
Klassifizieren Sie Payload-Felder: personenbezogen, pseudonym oder nicht personenbezogen.
Dokumentieren Sie die Region des Brokers, jedes Subscribers und jeder Datenbank.
Konfigurieren Sie Message Expiry, Session Expiry und die Richtlinie für Retained Messages.
Stellen Sie sicher, dass TLS für alle Clients verpflichtend ist.
Entscheiden Sie, ob BYOC oder Broker pro Region erforderlich sind.
Halten Sie Testdaten von öffentlichen Brokern fern; der Bereich des kostenlosen öffentlichen MQTT-Brokers ist für alle lesbar und nur für unkritische Experimente geeignet.

Starten Sie mit ConnectMQ

Beginnen Sie mit dem kostenlosen Serverless-Plan unter app.connectmq.com, ganz ohne Kreditkarte, und verwenden Sie nicht personenbezogene Testdaten. Sobald die Residenzanforderungen feststehen, sprechen Sie mit ConnectMQ über Dedicated- oder BYOC-Deployments. Einen vollständigen Überblick über Hosting-Modelle bieten der Leitfaden zum Cloud-MQTT-Broker und der Beitrag dazu, was ein verwalteter MQTT-Broker leistet.

Häufig gestellte Fragen

Ist MQTT-Datenresidenz nur für gespeicherte Daten relevant?

Nein. Nach vielen Richtlinien zählt auch die Verarbeitung, und ein Broker verarbeitet jede Nachricht. Retained Messages, wartende Sitzungen und Logs sind zudem ruhende Daten auf dem Broker.

Sind IoT-Telemetriedaten personenbezogene Daten im Sinne der DSGVO?

Das können sie sein, wenn sie sich auf eine identifizierbare Person beziehen, etwa Standort oder Energieverbrauch eines Haushalts. Bitten Sie Ihren Datenschutzbeauftragten, Ihre Payloads zu klassifizieren.

Wie hilft BYOC bei der Datenresidenz?

Der Broker läuft in Ihrem eigenen Cloud-Account, in einer Region Ihrer Wahl und nach Ihren Richtlinien, während der Anbieter ihn betreibt.

Kann ich einen Broker für Geräte in mehreren Ländern nutzen?

Technisch ja, doch wenn jedes Land eigene Residenzvorschriften hat, benötigen Sie möglicherweise einen Broker pro Region, wobei die Geräte ihrem Heimat-Broker zugeordnet sind.

MQTT-Datenresidenz und Regionswahl für IoT-Messaging