MQTT -Clientauthentifizierung mit TLS

Verbindungen zwischen dem MQTT-Client und dem Warteschlangenmanager werden immer vom MQTT-Client eingeleitet. Der MQTT-Client ist immer der SSL-Client. Die Clientauthentifizierung für den Server und die Serverauthentifizierung des MQTT-Clients sind beide optional.

Wenn Sie dem Client ein privates signiertes digitales Zertifikat bereitstellen, können Sie den MQTT-Client bei IBM® MQauthentifizieren. Der Administrator von IBM MQ kann MQTT-Clients dazu zwingen, sich beim Warteschlangenmanager mithilfe von TLS zu authentifizieren. Eine Clientauthentifizierung kann nur im Rahmen einer gegenseitigen Authentifizierung angefordert werden.

Als Alternative zu SSL können bestimmte virtuelle private Netze (Virtual Private Network, VPN), z. B. IPsec, die Endpunkte einer TCP/IP-Verbindung authentifizieren. In einem VPN wird jedes IP-Paket, das im Netz übertragen wird, verschlüsselt. Sobald eine solche VPN-Verbindung hergestellt ist, haben Sie ein vertrauenswürdiges Netz aufgebaut. MQTT-Clients können auch mit TCP/IP über das VPN mit Telemetriekanälen verbunden werden.

Die Clientauthentifizierung über TLS setzt voraus, dass der Client über einen geheimen Schlüssel verfügt. Der geheime Schlüssel ist im Falle eines selbst signierten Zertifikats der private Schlüssel des Clients bzw. andernfalls ein Schlüssel, der von einer Zertifizierungsstelle ausgestellt wird. Mit dem Schlüssel wird das digitale Zertifikat des Clients signiert. Jede Person im Besitz des entsprechenden öffentlichen Schlüssels kann das digitale Zertifikat verifizieren. Zertifikate können vertrauenswürdig sein oder - falls sie verkettet sind - durch eine Zertifikatskette bis zu einem Trusted-Root-Zertifikat zurückverfolgt werden. Bei der Clientverifizierung werden alle Zertifikate in der vom Client bereitgestellten Zertifikatskette an den Server gesendet. Der Server überprüft die Zertifikatskette, bis er ein Zertifikat findet, dem er vertraut. Das vertrauenswürdige Zertifikat ist entweder das öffentliche Zertifikat, das auf Basis eines selbst signierten Zertifikats generiert wird, oder ein Stammzertifikat, das für gewöhnlich von einer Zertifizierungsstelle ausgestellt wird. In einem letzten (optionalen) Schritt kann das vertrauenswürdige Zertifikat mit einer aktuellen Zertifikatswiderrufsliste abgeglichen werden.

Das vertrauenswürdige Zertifikat kann von einer Zertifizierungsstelle ausgestellt und bereits im JRE Zertifikatspeicher enthalten sein. Es kann sich aber auch um ein selbst signiertes Zertifikat oder um jedes Zertifikat handeln, das dem Keystore des Telemetriekanals als vertrauenswürdiges Zertifikat hinzugefügt wurde.

Hinweis: Der Telemetriekanal verfügt über einen kombinierten Keystore/Truststore, der sowohl die privaten Schlüssel für einen oder mehrere Telemetriekanäle als auch alle öffentlichen Zertifikate für die Authentifizierung von Clients enthält. Da ein SSL-Kanal über einen Schlüsselspeicher verfügen muss und es sich dabei um dieselbe Datei wie der Vertrauensspeicher des Kanals handelt, wird der JRE Zertifikatspeicher nie referenziert. Wenn für die Authentifizierung eines Clients ein CA-Stammzertifikat erforderlich ist, müssen Sie das Stammzertifikat in den Schlüsselspeicher für den Channel aufnehmen, auch wenn sich das CA-Stammzertifikat bereits im JRE Zertifikatspeicher befindet. Der JRE Zertifikatspeicher wird nie referenziert.

Überlegen Sie sich, welchen Sicherheitsbedrohungen die Clientauthentifizierung entgegenwirken soll, und welche Rollen der Client und Server bei der Abwendung der Sicherheitsbedrohungen spielen. Die Authentifizierung des Clientzertifikats reicht allein nicht aus, um unbefugten Zugriff auf ein System zu verhindern. Wenn eine dritte Person über das Clientgerät verfügt, handelt das Clientgerät nicht unbedingt mit der Berechtigung des Zertifikatseigners. Verlassen Sie sich bei der Abwehr von unerwünschten Attacken niemals auf eine einzige Maßnahme. Verwenden Sie mindestens eine aus zwei Faktoren bestehende Authentifizierung und sichern Sie dies durch den Besitz eines Zertifikats ab, für das nicht öffentliche Informationen bekannt sein müssen. Verwenden Sie beispielsweise JAAS und authentifizieren Sie den Client mittels eines vom Server ausgestellten Kennworts.

Die größte Sicherheitsbedrohung für das Clientzertifikat ist, dass es in falsche Hände gelangt. Das Zertifikat befindet sich in einem kennwortgeschützten Keystore beim Client. Wie wird es in den Keystore gestellt? Wie erhält der MQTT-Client das Kennwort für den Keystore? Wie sicher ist der Kennwortschutz? Telemetriegeräte sind häufig einfach zu entfernen und können dann in Ruhe manipuliert werden. Muss das Gerät manipulationssicher sein? Die Verteilung und der Schutz clientseitiger Zertifikate gilt als besonders schwierig; diese Aufgabe wird als das Schlüsselverwaltungsproblem bezeichnet.

Eine weitere große Bedrohung besteht darin, dass das Gerät unbeabsichtigt für den Zugriff auf Server missbraucht wird. Wird die MQTT-Anwendung beispielsweise manipuliert, kann unter Verwendung der authentifizierten Clientidentität eine Schwachstelle in der Serverkonfiguration ausgenutzt werden.

Zur Authentifizierung eines MQTT-Clients mit SSL müssen Sie den Telemetriekanal und den Client konfigurieren.