MQTT-Broker einrichten/ Einfache Benutzerverwaltung
Beschreibung
[Bearbeiten]Der Broker wird zur Nutzung von Nutzernamen und Passwort eingerichtet. Es sind zwei unterschiedliche Zwecke möglich, die getrennt konfiguriert werden können:
- Anmeldung am Broker
- Rechte für einzelne Topics
Die Anmeldung lässt sich für jeden Port getrennt einstellen. So kann der lokale, unverschlüsselte Port ohne Authentifizierung gestaltet werden, während der nach außen geöffnete Port nur mit Authentifizierung zu nutzen ist.
Die Nutzerverwaltung der Topics lässt sich unabhängig von der Anmeldung nutzen. Wird keine Authentifizierung genutzt, kann dennoch eine Anmeldung mit Nutzername erfolgen.
|
|
Das Passwort wird bei Verbindungsversuch im Klartext übertragen, auch wenn das Passwort selbst beim Broker nur als Hashwert gespeichert wird. Die Verwendung von Nutzernamen und Passwort sollte somit nur in gesicherten Netzwerken erfolgen oder mit TLS-Transportverschlüsselung. |
|---|
Einrichtung
[Bearbeiten]Passwörter vorbereiten
[Bearbeiten]Zur Authentifizierung von Nutzern wird eine Passwortdatei benötigt, in der zu jedem Nutzernamen ein Passwort-Hash abgelegt ist. Die Nutzerverwaltung bei Mosquitto ist getrennt von anderen Methoden, so dass keine zentrale Nutzerverwaltung mit anderen Diensten genutzt werden kann.
Um diese Passwortdatei zu erzeugen, gibt es zwei Varianten, die in den ersten Unterabschnitten beschrieben werden. Anschließend erfolgt die Nutzerverwaltung einheitlich. Verwendet wird das Kommandozeilenprogramme mosquitto_passwd.
Initialisierung
[Bearbeiten]Mit dem Parameter -c wird eine neue Datei kreiert (create). Es wird mindestens ein Nutzername erwartet, zu dem direkt ein Passwort abgefragt wird:
mosquitto_passwd -c [Pfad zur Datei] [Nutzer]
Eine bereits existierende Datei wird ohne Rückfrage überschrieben. Diese Methode scheint unter Windows mit Problemen behaftet zu sein.
Umwandlung einer Textdatei
[Bearbeiten]Es wird eine Textdatei vorbereitet, in der pro Zeile ein Nutzer mit Passwort gespeichert ist. Als Trenner wird ein Doppelpunkt : verwendet:
UserA:PasswordA
UserB:PasswortB
Mit dem Parameter -U wird diese Textdatei umgewandelt:
mosquitto_passwd -U [Pfad zur Textdatei]
Neue Nutzer zufügen
[Bearbeiten]Neue Einträge werden wie folgt zugefügt:
mosquitto_passwd -b [Pfad] [Nutzer] [Passwort]
Es muss hierbei sowohl Nutzername und Passwort in der Kommandozeile übergeben werden.
Löschen von Nutzern
[Bearbeiten]Einträge können wir folgt gelöscht werden:
mosquitto_passwd -D [Pfad] [Nutzer]
Konfiguration des Broker/Listener
[Bearbeiten]Die Passwortdatei wird in der Konfiguration wie folgt eingetragen:
password_file [Pfad zur Passworddatei]
Bleibt die anonyme Anmeldung noch möglich, dann lassen sich mittels Benutzername die Zugriffe auf verschiedene Topics regeln und auch einzelne Topics zur anonymen Nutzung freischalten.
Anmeldung am Broker
[Bearbeiten]Zur Anmeldung am Broker muss der Client Nutzername und Passwort übertragen. Sowohl Nuterzname und Passwort werden im Klartext übertragen, wodurch lauschende Prozesse diese Zugangsdaten erfahren können. Die Nutzung von Nutzername und Password erhöht die Sicherheit nur marginal. Nutzername und Passwort dürfen in anderen Situationen nicht für kritische Anwendungen verwendet werden.
Mit dem Nutzernamen lassen sich Rechte an einzelnen Topics verwalten.
Rechteverwaltung der Topics (ACL)
[Bearbeiten]Der MQTT-Broker beherrscht eine einfache Rechteverwaltung. Zu jedem Topic lassen sich Lese- und Schreibrechte anhand Nutzername und Client ID verwalten. Die Client ID kann von jedem Client frei gewählt werden und wird nicht weiter abgesichert. So kann ein zweiter Client sich mit der gleichen Client ID anmelden und erhält dementsprechend die zugewiesenen Rechte.
Die Rechte werden auf dem Broker in einer access control list (ACL) als Textdatei verwaltet.
Diese Textdatei wird für einen Listener wie folgt eingebunden:
acl_file [Pfad zur ACL]
Die ACL-Textdatei besteht aus drei Bereichen:
- Allgemeiner Bereich
- Die hier definierten Rechte gelten für alle Clients, wenn keine weiteren Regel definiert werden.
- Nutzerbereich
- Für einzelne Nutzer werden Rechte an einzelne Topics verwaltet. Für einen Nutzer gelten ausschließlich die in diesem Abschnitt definierten Regeln. Die im allgemeinen Bereich werden nicht angewendet.
- Client-Bereich
- Topic-Bäume lassen sich anhand der Client-ID filtern und Rechte zuweisen.
Die Rechte an einem Topic werden im Allgemeine Bereich und im Nutzerbereich mit dem Schlüsselwort topic, optional den Rechten (default Lese- und Schreibrecht) und dem Topic definiert. Der Allgemeine Bereich befindet sich immer am Anfang der Textdatei. Für jeden Nutzer wird ein neuer Abschnitt mit dem Schlüsselwort user [Nutzername] eingeleitet. Der Abschnitt geht bis zum nächsten Abschnitt. In einem Abschnitt lassen sich beliebig viele Topic-Rechte definieren.
Zusätzlich wird mit dem Schlüsselwort pattern die Rechte an speziellen Topics abhängig von der Client- bzw. User-ID verwaltet und damit der Client-Bereich definiert.
Die Definitionen des Client-Bereichs haben Vorrang gegenüber den Regeln des Nutzer- und des Allgemeinbereichs.
Beispiel mit einem Nutzer:
[Bearbeiten]topic read #
user nutzera
topic readwrite Küche/#
Die erste Zeile definiert den Allgemeinen Bereich. Dort werden alle Clients zunächst ausschließlich Lese-Rechte an allen Topics gewährt. Mit der dritten Zeile wird der Abschnitt für nutzera definiert. Dieser Nutzer erhält Schreib- und Leserechte an allen Topics unterhalb von Küche.
Beispiel mit zwei Nutzern
[Bearbeiten]user nutzera
topic readwrite Küche/#
user nutzerb
topic read Küche/#
topic Küche/+/status
Es fehlt der allgemeine Bereich. Somit haben Clients, die sich gegenüber dem Broker nicht mit einem Nutzernamen ausweisen, keine Lese- oder Schreibrechte an einem Topic.
Schreib- und Leserechte unterhalb Küche werden dem Nutzer nutzera zugewiesen. Dem Nutzer nutzerb werden Schreib- und Leserechte an alle Topics unterhalb Küche zugewiesen, die auf der 3. Ebene mit status enden. Zudem erhält nutzerb noch Leserechte an alle anderen Topics unterhalb Küche.
Das Topic Küche/Kühlschrank/Offen darf von nutzera beschrieben und gelesen werden, von nutzerb nur gelesen. Das Topic Küche/Mikrowelle/status darf von beiden Nutzern beschrieben und gelesen werden. Das Topic Küche/Herd/1/status darf nur von nutzera beschrieben werden. Von beiden Nutzern darf es gelesen werden. Da das Subtopic status hier auf der 4. Ebene ist, greift die Schreibregel in der ACL nicht.
Beispiel für eine Client-ID
[Bearbeiten]pattern readwrite Küche/%c/status
pattern readwrite Nutzer/%u/status
Die erste Zeile gewährt, abhängig von der Client-ID Schreib- und Leserechte an bestimmten Topics unterhalb Küche. Meldet sich ein Client mit der ID Kühlschrank an, hat dieser Client Schreib- und Leserechte an dem Topic Küche/Kühlschrank/status.
Die zweite Zeile gewährt den Nutzer Schreib- und Leserechte an dem Topic Nutzer/[Nutzername]/status.
Beispiel für kombinierte Regeln für Nutzer und Client
[Bearbeiten]topic read #
user nutzera
topic readwrite Küche/+/status
pattern readwrite Küche/%c/#
Alle Clients dürfen alle Topics lesen. Nutzera hat zudem Schreibrechte an alle Topics unterhalb Küche, die auf 3. Ebene mit status enden. Clients haben auf die ihnen zugewiesenen Topics Schreibrechte. Meldet sich ein Client Kühlschrank mit dem Account von nutzera an, hat dieser Schreibrechte auf alle Topics unterhalb Küche/Kühlschrank, auch wenn nutzera nur Schreibrechte auf Küche/Kühhlschrank/status hat. Zudem hat dieser Client Schreibrechte auf alle Topics unterhalb Küche, dessen 3. Ebene auf status endet. Andere Topics sind von dem Client dann nicht lesbar, da das allgemeine Leserecht nur im Allgemeinen Bereich definiert wurde, nicht im Nutzerbereich.