Kommunikationsarchitekturen für das IoT
Skalierbar, zuverlässig und sicher
Um IoT-Potenziale (Internet of Things) zu erschließen, bedarf es einer hoch skalierbaren und zuverlässigen IT-Infrastruktur. Diese sollte auf standardisierten Komponenten und offenen Protokollen basieren und die drei Schichten "Devices", "Controller" und "Datacenter" beziehungsweise die Cloud umfassen. Um die Systeme gegen Bedrohungen zu schützen, sind zudem verschiedene Sicherheitsmaßnahmen zu implementieren - beispielsweise eine sichere Authentifizierung sowie eine verschlüsselte Datenübertragung.
Das Internet der Dinge vernetzt intelligente Geräte aller Art wie mobile Geräte, Sensoren, Maschinen oder Fahrzeuge miteinander und mit der Cloud. Die Bandbreite möglicher neuer Anwendungen ist groß. Sie reicht von intelligenter Gebäudetechnik mit automatisiertem Beleuchtungs- oder Energie-Management über optimierte Lösungen für Inventarisierung, Logistik und Supply-Chain-Management bis hin intelligenten Fertigungssystemen.
Verteilte IoT-Lösungen können zu großen Sicherheitsherausforderungen führen, da die Systeme über das Internet vernetzt sind und Rechenleistung oder Speicherressourcen aus dem Datacenter eines Unternehmens oder aus der Cloud nutzen. Unternehmen müssen daher ihre Sicherheitsarchitektur erweitern, um sich vor Datenverlust, Diebstahl und immer anspruchsvolleren Denial-of-Service-Attacken effizient zu schützen. Dazu gehören umfassende Authentifizierungs-, Autorisierungs- und Auditing-Funktionen. Diese schaffen Vertrauen, regeln den Zugriff auf Ressourcen und gewährleisten die Einhaltung der gesetzlichen Vorschriften und internen Richtlinien (Compliance). Unternehmen sollten außerdem starke Verschlüsselungsverfahren einsetzen, um ihr geistiges Eigentum und Kundendaten vor Diebstahl zu schützen.
Drei-Schichtenmodell
Intelligente IT-Lösungen, die auf Techniken beispielsweise von Red Hat basieren, erfüllen die Anforderungen der IoT-Systeme an Skalierbarkeit, Zuverlässigkeit und Sicherheit. Sie gründen auf einem hierarchischen Modell mit Geräteschicht (Edge, Device Tier), Steuerungsschicht (Controller, Gateway Tier) und Rechenzentrums- (Datacenter Tier) oder Cloud-Schicht. Dabei kommen standardisierte Protokolle und Komponenten zum Einsatz.
Die Edge-Ebene umfasst eine Vielzahl von intelligenten Endgeräten. Dazu gehören mobile Geräte, Wearables, Sensoren, Steuerungs- und Regelgeräte sowie autonome Maschinen und Appliances. Die Kommunikation zwischen den Geräten und den Steuerungs- oder Kontrollpunkten basiert auf Standard-Netzwerkprotokollen, sei es kabelgebunden oder drahtlos. Auch die Weiterleitung der Rohdaten sowie der Austausch der Steuerungsinformationen beruht auf offenen Messaging-Standards.
MQTT zwischen Edge und Controller
Zur Kommunikation zwischen Edge und Controller kommt zum Beispiel MQTT (Message Queue Telemetry Transport) zum Einsatz. Dieses Protokoll hatten bereits 1999 die beiden Unternehmen IBM und Arcom Control Systems im Rahmen eines Projekts zur Überwachung einer Ölpipeline entwickelt. Es zeichnet sich durch eine hohe Zuverlässigkeit aus und eignet sich für den Einsatz in Mobilfunknetzen und in Netzen mit geringer Bandbreite. Eine Implementierung des Protokolls erfordert zudem wenig Programmcode. MQTT wurde 2010 unter einer freien Lizenz veröffentlicht, ist seit 2013 ein Oasis-Standard und hat in der Zwischenzeit den Versionsstand 3.1.1 erreicht. MQTT zeichnet sich durch einen geringen Protokoll-Overhead aus.
MQTT ist ein sogenanntes Publish-Subscribe-Protokoll, das auf einer Hub-and-Spoke-Architektur basiert. Dabei kommuniziert der Sender (Producer) einer Nachricht nicht direkt mit einem Empfänger (Consumer), sondern über einen Broker. Durch die Entkopplung beider Seiten kann der Producer - beispielsweise ein Sensor - auch dann Daten übermitteln, wenn kein Empfänger, etwa ein Gateway, online ist. Mehr noch: Der Producer hat keine Kenntnisse darüber, ob es für die Daten einen oder mehrere Consumer gibt. Der Broker agiert als Server für Producer und Consumer, die als Clients beide mit dem Broker verbunden sind. MQTT arbeitet vollständig unabhängig von dem eigentlichen Inhalt der Nachrichten. Im Unterschied zu einem Client/Server-Protokoll wie HTTP arbeitet MQTT ereignisorientiert. Im erstgenannten Fall fragt der Client beim Server nach, ob neue Nachrichten vorliegen. In einem ereignisorientierten Modell informiert der Broker die Consumer, wenn Daten zu einem bestimmten "Topic" vorliegen.
Drei QoS-Stufen
Consumer müssen für ein oder mehrere Topics angemeldet sein und werden daher auch als Subscriber bezeichnet. In einem Topic sind Nachrichten zu einem bestimmten Thema zusammengefasst. Dies können beispielsweise die durch einen Sensor gemessenen Temperaturen oder die Gesundheitsdaten nicht stationärer Patienten sein. Das MQTT-Protokoll bietet für die Kommunikation dabei drei Quality-of-Service-(QoS-)Stufen:
QoS-0: At Most Once. Auf dieser untersten Stufe ist gewährleistet, dass die Nachricht höchstens ein Mal zugestellt wird. Ein Producer kennzeichnet in diesem Fall eine Publish-Nachricht mit der QoS-Stufe 0. Da sich der Sender nicht weiter um die Nachricht kümmert, trägt diese schnelle und ressourcenschonende Form von Message Exchange auch die Bezeichnung "Fire and Forget". Bei dieser gibt es keine Garantie, dass die Nachricht auch tatsächlich ankommt. Anders ausgedrückt: Es kann zu Nachrichtenverlusten kommen, die jedoch nicht weiter ins Gewicht fallen, wenn kurz nach einem verloren gegangenen Wert schon der nächste übermittelt wird.
Dies lässt sich am Beispiel der erwähnten Überwachung einer Ölpipeline verdeutlichten, auf der viele unterschiedliche Sensoren (im Sinne von Fühlern, die physikalische Größen in elektrische Signale umwandeln) und Aktoren (zuständig beispielsweise, um ein Ventil zu öffnen oder zu schließen) im Einsatz sind. Auf QoS-0-Stufe muss der Temperatursensor, der jede Sekunde einen Messwert versendet, diese Daten nicht zwingend mit einer höheren Sicherheitsstufe versenden, da der Verlust eines einzelnen Datenpakets nicht unbedingt von Relevanz ist.
QoS-1: At Least Once. Die nächste QoS-Stufe stellt sicher, dass die Nachricht mindestens ein Mal beim Consumer eintrifft. Dies bedeutet aber auch, dass eine Nachricht mehrmals zugestellt werden kann. Der Producer speichert dazu die Nachricht in einer Datei, und die Message steht dann im Notfall für eine erneute Übertragung bereit. Dazu versendet der Producer eine Publish-Nachricht mit einem "Packet Identifier" an den Consumer. Dieser bestätigt den Erhalt mit einem Paket, das denselben Packet Identifier enthält. Hat der Producer dieses Antwortpaket noch nicht erhalten, kann er die ursprüngliche Nachricht - inklusive Packet Identifier und Inhalt - beliebig oft an den Consumer versenden.
Um beim Beispiel der Ölpipeline zu bleiben: Meldet sich ein Temperatursensor (technisch betrachtet ein MQTT-Client - also eine sendende oder empfangende Anwendung) - an einem Broker an, ist es gut, wenn dieser Client davon ausgehen kann, dass seine Registrierung am Broker auch wirklich stattgefunden hat. Aus diesem Grund erfolgt unter anderem der Nachrichtenversand zur Registrierung eines MQTT-Clients am MQTT-Broker mit QoS-1.
QoS-2: Exactly Once. Auf der höchsten QoS-Stufe ist gewährleistet, dass Duplikate ausgeschlossen sind und die Nachrichten genau ein Mal zugestellt werden. Damit sich diese Garantie auch einhalten lässt, gibt es eine zweistufige Bestätigung. Der Consumer antwortet auf den Erhalt einer Nachricht mit einem Empfangspaket. Daraufhin verschickt der Producer ein weiteres Paket, auf das wiederum der Consumer antwortet. Dies lässt sich ebenfalls am Beispiel der Ölpipeline verdeutlichen: Sind nicht nur Daten von Sensoren zu ermitteln, sondern im Gegenzug über MQTT auch Aktoren zu steuern, dann könnte man sich vorstellen, dass aufgrund von Messwerten über einen Aktor der Durchfluss eines Ventils um zehn Prozent erhöht werden soll. Die Nachricht mit diesem Steuerkommando sollte in diesem Fall natürlich nur ein Mal beim Empfänger ankommen, dies jedoch mit Sicherheit.
Verschlüsselte Datenübertragung
Von Haus aus ist MQTT nicht ausreichend sicher, da das Protokoll unverschlüsseltes TCP verwendet. Andererseits kann MQTT genau aus diesem Grund TLS-Verschlüsselung (Transport Layer Security) nutzen. TLS stellt dabei einen sicheren Kommunikationskanal zwischen einem Client und einem Server bereit.
Noch einmal zurück zum Ausgangspunkt, der Architektur mit den drei Schichten Devices, Controller und Datacenter: Die Controller-Ebene, auf der die Sensordaten aggregiert und geprüft werden, fungiert als Bindeglied zwischen den Geräten und dem Rechenzentrum beziehungsweise der Cloud. Sie sammelt und speichert Gerätedaten und leitet sie beispielsweise via Java-Messaging-Service an das Rechenzentrum weiter; umgekehrt vermittelt sie Steuerungsinformationen an die Geräte - alles auf der Basis offener Messaging-Standards. Darüber hinaus dient Controller-Ebene als Zwischenspeicher für Daten, die für die taktische Analyse oder für regulatorische Anforderungen erforderlich sind. Eine Alternative zum beschriebenen Drei-Schichtenmodell bildet ein Zwei-Schichtenmodell, in dem die Geräte direkt mit den Rechenzentren oder der Cloud verbunden sind. Letzteres eignet sich sehr gut für Consumer-Anwendungen, die weniger Bandbreite und keine Gateway-Ebene für die Verteilung von Workloads benötigen.
Patrick Steiner, Lead Architect Enterprise Accounts Germany bei Red Hat, www.redhat.de./pf
Lesen Sie mehr zum Thema
