Best Practices zum Ausführen eines IoT-Back-Ends in Google Cloud

Last reviewed 2024-05-31 UTC

Dieses Dokument enthält Best Practices für die Sicherheit zum Verwalten und Ausführen eines IoT-Back-Ends (Internet der Dinge) in Google Cloud. In einer IoT-Lösung verbindet ein IoT-Backend Edge-Geräte mit anderen Ressourcen. Dieses Dokument konzentriert sich auf die folgenden IoT-Back-Ends: Message Queuing Telemetry Transport-Broker (MQTT) und die IoT-Plattform.

Dieses Dokument ist Teil einer Reihe von Dokumenten, die Informationen zu IoT-Architekturen in Google Cloud und zur Migration von IoT Core enthalten. Die anderen Dokumente in dieser Reihe umfassen die folgenden Punkte:

In diesem Dokument werden Best Practices für die Bereitstellung und Verwaltung von Geräteanmeldedaten, die Authentifizierung und den Zugriff auf Edge-Geräte für die Kontrolle sowie den Zugriff von IoT Edge-Geräten auf Google Cloud-Ressourcen erläutert.

IdD-Architektur

Eine IoT-Architektur umfasst Dienste, mit denen Sie Geräteanmeldedaten bereitstellen und verwalten, Edge-Geräte authentifizieren und auf Zugriffssteuerungen sowie Edge-Geräte auf Google Cloud-Ressourcen zugreifen können. In diesem Dokument werden zwei IoT-Backend-Architekturen erläutert: eine mit MQTT-Broker und die andere mit einer IoT-Plattform. Die Hauptsicherheitsunterschiede zwischen diesen beiden Back-Ends sind die Geräteidentität und die Geräteverwaltung. IoT-Plattformen stellen diese Funktionen als Teil ihres Systems bereit, während MQTT-Broker diese Funktionen benötigen.

Im folgenden Diagramm wird die IoT-Architektur beschrieben.

IoT-Backend-Architektur

Die Architektur zeigt die Dienste, die für die folgenden drei Prozesse erforderlich sind:

  1. Die Bereitstellung von Zertifikaten. Dazu müssen Sie ein Edge-Gerät für die Konfiguration vorbereiten.

  2. Authentifizierung und Autorisierung, einschließlich des Authentifizierungsschemas, das das Edge-Gerät und der MQTT-Broker oder die IoT-Plattform zur Authentifizierung verwenden.

  3. Verbindungen zwischen Edge-Geräten und Google Cloud-Diensten. Dies sind Aufgaben, die vom Edge-Gerät ausgeführt werden, um eine Verbindung zu Cloudressourcen herzustellen und Daten hoch- oder herunterzuladen.

In diesem Dokument geht es um Best Practices für die Sicherheit bei der Bereitstellung und Authentifizierung.

Die Architektur verwendet eine Kombination der folgenden Dienste und Features:

  • Ein Edge-Gerät (z. B. ein medizinisches Gerät), das Sie an den Edges Ihrer Umgebung bereitstellen und in der Nähe der Daten liegt, die Sie verarbeiten möchten. Die Edge-Geräte stellen eine bidirektionale Verbindung zu Ihrem IoT-Backend her, d. h., sie können Nachrichten an das IoT-Backend senden und von diesem empfangen.
  • Ein IoT-Backend, das ein MQTT-Broker oder eine IoT-Plattform sein kann.
    • Ein MQTT-Broker bietet eine sichere Schnittstelle für Edge-Geräte, um eine Verbindung über das MQTT-Protokoll herzustellen. MQTT-Broker bieten keine Möglichkeiten für die Geräteidentität und die Geräteverwaltung und sind für die Bereitstellung externer Systeme zuständig.
    • Eine IoT-Plattform ist eine Cloud-Anwendung, mit der Edge-Geräte eine Verbindung herstellen und mit denen sie kommunizieren. IoT-Plattformen bieten eine sichere Schnittstelle für Edge-Geräte, um eine Verbindung über das MQTT-Protokoll herzustellen. Jede IoT-Plattform hat eine eigene Sicherheitsimplementierung, die bestimmt, wie sie Edge-Geräte authentifiziert und autorisiert und wie Geräteidentitäten verwaltet werden.
  • Ein zentraler Zertifikatspeicher, in dem die Zertifikate für alle Edge-Geräte gehostet werden.
  • Cloud-Ressourcen, auf die Edge-Geräte zugreifen müssen.

Edge-Gerät bereitstellen

Bevor ein Edge-Gerät eine Verbindung zu Ihren Backend-Arbeitslasten herstellen kann, müssen Sie für das Edge-Gerät ein Zertifikat bereitstellen. Es gibt zwei Hauptszenarien, die festlegen, wie Sie das Zertifikat bereitstellen:

  • Wenn Ihre Lösung auf kommerziellen, generischen Geräten basiert, haben Sie nach dem Kauf des Geräts die vollständige Kontrolle über den Bereitstellungsprozess.

  • Wenn Sie benutzerdefinierte Geräte verwenden, erfolgt die Erstbereitstellung während der Fertigung der Geräte und Sie müssen den Bereitstellungsprozess in Ihre Anbieter und Hersteller integrieren.

In beiden Fällen müssen Sie Gerätezertifikate mit einer Vertrauenskette erstellen, die mit einer Stammzertifizierungsstelle verknüpft ist. Diese Zertifikate authentifizieren die Geräteidentität und sorgen dafür, dass Aktualisierungen und Änderungen auf dem Gerät von vertrauenswürdigen Nutzern durchgeführt werden. Verwenden Sie eine Zertifizierungsstelle wie Certificate Authority Service, um die folgenden Aufgaben auszuführen:

Um ein Gerätezertifikat bereitzustellen, müssen Sie folgende Aufgaben ausführen:

  1. Generieren Sie das öffentliche/private Schlüsselpaar mit einer hardwarebasierten Sicherheitslösung, die von Ihrem Gerät unterstützt wird, z. B. einem sicheren Element (SE) oder einem Hardware Secure Module (HSM). SE oder das HSM speichert die privaten Schlüssel standardmäßig lokal und die privaten Schlüssel werden niemals extern verfügbar gemacht. Wenn Sie keine hardwarebasierte Sicherheitslösung verwenden, um ein öffentliches/privates Schlüsselpaar zu generieren, verwenden Sie stattdessen die Zertifizierungsstelle, um Schlüssel zu generieren. Weitere Informationen finden Sie unter Automatisch generierten Schlüssel verwenden.

  2. Gerätezertifikat signieren und generieren Nachdem Sie das öffentliche/private Schlüsselpaar generiert haben, laden Sie den öffentlichen Schlüssel herunter, erstellen Sie eine Zertifikatsignierungsanfrage (CSR) und senden Sie die CSR zur Signatur an die Zertifizierungsstelle. Die Zertifizierungsstelle generiert ein Gerätezertifikat, das mit der Stamm-CA verknüpft ist. Weitere Informationen finden Sie unter CSR verwenden. Wenn Sie automatisch generierte Schlüssel verwenden, können Sie ein Gerätezertifikat direkt von der Zertifizierungsstelle anfordern.

  3. Installieren Sie das signierte Gerätezertifikat auf dem Edge-Gerät und senden Sie das Zertifikat an ein zentrales Zertifikat-Repository wie Secret Manager.

Weitere Informationen finden Sie unter Sichere und zuverlässige öffentliche Schlüsselinfrastruktur mit Google Cloud CA Service (PDF) bereitstellen.

Informationen zu anderen Best Practices für die Bereitstellung finden Sie unter Best Practices zur automatischen Bereitstellung und Konfiguration von Edge- und Bare-Metal-Systemen und -Servern.

Für die Sicherung einer IoT-Lösung stehen drei Zertifikatstypen zur Verfügung:

  • Das Root-CA-Zertifikat stellt den Stamm für die Vertrauenskette aller anderen Zertifikate in Ihrem System bereit. Die Backend-Arbeitslasten verwenden das Root-Zertifikat, um die Clientzertifikate zu validieren, und die Edge-Geräte verwenden das Root-Zertifikat, um das Serverzertifikat zu validieren. Sie müssen das Root-Zertifikat sowohl an das IoT-Backend als auch an die Edge-Geräte verteilen.

  • Die Serverzertifikate werden zum Schutz der Endpunkte verwendet, die vom IoT-Backend verfügbar gemacht werden. Sie haben Serverzertifikate für die verschiedenen Verschlüsselungsalgorithmen, die Ihre Endpunkte unterstützen müssen. Serverzertifikate sind mit der Stammzertifizierungsstelle verknüpft. Ein Secret Manager verwaltet sowohl den privaten als auch den öffentlichen Teil der Serverzertifikate und speichert diese. Sie müssen Ihr IoT-Backend mit den Serverzertifikaten und den zugehörigen privaten Schlüsseln konfigurieren.

  • Die Clientzertifikate werden zur Identifizierung von Edge-Geräten verwendet. Jedes Edge-Gerät hat mindestens ein Clientzertifikat. Dies bedeutet, dass die Anzahl der Zertifikate mit der Anzahl der Edge-Geräte in Ihrer Umgebung zunimmt. Clientzertifikate sind mit der Stammzertifizierungsstelle verknüpft. Sie müssen Clientzertifikate an Ihre Edge-Geräte und das IoT-Backend verteilen.

Vorgang zum Generieren eines Gerätezertifikats mit einem HSM oder SE

Das folgende Diagramm zeigt, wie ein Gerätezertifikat bei Verwendung eines HSM oder SE bereitgestellt wird.

Vorgang zum Generieren eines Gerätezertifikats.

In diesem Diagramm werden die folgenden Schritte ausgeführt:

  1. Das Edge-Gerät generiert das öffentliche Schlüsselpaar in der Hardware.
  2. Sie laden den öffentlichen Schlüssel herunter und erstellen die CSR-Anfrage.
  3. Sie senden den CSR an die CA, um ein Zertifikat anzufordern.
  4. Die Zertifizierungsstelle führt die folgenden Aktionen aus:
    1. Signiert das Zertifikat
    2. Gibt das Gerätezertifikat an den Bereitsteller zurück.
  5. Der Bereitsteller führt die folgenden Aktionen aus:
    1. Sendet das Zertifikat an das Edge-Gerät.
    2. Speichert das Zertifikat im zentralen Zertifikatsspeicher.
  6. Das Edge-Gerät speichert das Zertifikat an einem sicheren Ort.

Vorgang zum Generieren eines Gerätezertifikats mithilfe der Zertifizierungsstelle

Das folgende Diagramm zeigt, wie ein Gerätezertifikat bei Verwendung einer Zertifizierungsstelle bereitgestellt wird.

Vorgang zum Generieren eines Gerätezertifikats.

In diesem Diagramm werden die folgenden Schritte ausgeführt:

  1. Sie generieren einen CSR und senden ihn an die CA, um ein Zertifikat anzufordern.
  2. Die Zertifizierungsstelle führt die folgenden Aktionen aus:
    1. Generiert ein öffentliches Schlüsselpaar und signiert den öffentlichen Schlüssel.
    2. Gibt das Gerätezertifikat und den privaten Schlüssel an den Bereitsteller zurück.
  3. Sie führen dabei die folgenden Aktionen aus:
    1. Senden Sie das Zertifikat und den privaten Schlüssel an das Edge-Gerät.
    2. Speichern Sie das Zertifikat und den privaten Schlüssel im zentralen Zertifikatsspeicher.
  4. Das Edge-Gerät speichert das Zertifikat an einem sicheren Ort.

Best Practices für die Geräteidentität

In diesem Abschnitt werden die Best Practices für Geräteidentitäten beschrieben.

Identitätsanbieter mit MQTT-Brokern verwenden

MQTT-Broker authentifizieren Edge-Geräte mithilfe von Geräteanmeldedaten, die von Plug-ins, Datenbanken und Dateien bereitgestellt werden. Verwenden Sie einen Identitätsanbieter (Identity Provider, IdP), um Ihre Geräteidentitäten systematisch und skalierbar zu verwalten. Der IdP verwaltet die Identitäten und Anmeldedaten für alle Geräte und fungiert als primäre "Source of Truth" für Geräteidentitäten.

Implementieren Sie eine systemspezifische Integrationsschicht, um die Geräteidentität im MQTT-Broker auf dem neuesten Stand zu halten. Weitere Informationen zum Verwalten von Geräteanmeldedaten finden Sie unter Edge-Gerät bereitstellen.

Digitale Identitäten der IoT-Plattform als „Source of Truth“ verwenden

Die IoT-Plattform hat Sicherheitsfeatures, die die Geräteidentitäten und Geräteanmeldedaten verwalten sowie Geräte authentifizieren und autorisieren, die auf die Plattform zugreifen. Diese Sicherheitsfeatures sorgen dafür, dass nur autorisierte Geräte auf die IoT-Plattform zugreifen dürfen und die Datenintegrität gewährleistet ist.

Prüfen Sie, ob die von der IoT-Plattform verwalteten Geräteidentitäten die primäre "Source of Truth" aller Geräte darstellen, die die IoT-Plattform verwaltet. Andere Komponenten in einer IoT-Lösung, die Informationen zur Geräteidentität benötigen, sollten auf dem Sicherheitssystem der IoT-Plattform basieren. Die IoT-Plattform gewährt Zugriffsrechte auf Geräte und leitet alle Sicherheitsänderungen in der gesamten IoT-Lösung weiter.

Best Practices für die Netzwerkverbindung

Die Sicherung der Netzwerkverbindung ist aus folgenden Gründen wichtig:

  • Sichere Netzwerke sorgen dafür, dass ein Gerät eine Verbindung zum richtigen Backend herstellt. Ein sicheres Netzwerk kann beispielsweise DNS-Spoofing verhindern. Dies ist ein Angriff, der versucht, Geräte umzuleiten, um eine Verbindung zu einem fehlerhaften Backend herzustellen, das von Angreifern gesteuert wird.
  • Sichere Netzwerke sorgen dafür, dass Dritte Ihre Datenzugriffe nicht lesen können. Ein sicheres Netzwerk kann beispielsweise einen Angriff über den mittleren Angriff verhindern, bei dem Angreifer den Traffic zwischen Ihrem Gerät und dem Backend lesen.

Verwenden Sie Transport Layer Security (TLS), um die Netzwerkkommunikation zwischen Ihren Edge-Geräten und Backend-Arbeitslasten zu schützen.

Erweitern Sie TLS mit mTLS, um ein Schema zur gegenseitigen Authentifizierung zu implementieren, mit dem beide Parteien miteinander kommunizieren können.

Eine Anleitung zur Verwendung von TLS finden Sie unter Eigenständige MQTT-Broker-Architektur in Google Cloud und IoT-Plattform-Produktarchitektur in Google Cloud.

Best Practices für die Zertifikatsverwaltung für MQTT-Broker

In diesem Abschnitt werden Best Practices für die Verwaltung von Zertifikaten bei Verwendung von MQTT-Brokern beschrieben.

Zertifikate zentral speichern

Server- und Gerätezertifikate an einem zentralen Ort speichern und verwalten Achten Sie insbesondere auf die folgenden Steuerelemente:

  • Ein Inventar aller Ihrer Geräte und der zugehörigen Zertifikate sowie der Serverendpunkte und deren Zertifikate
  • Weitere Informationen zu den Zertifikaten, z. B. Gültigkeit.
  • Zertifikate für Geräte hinzufügen und entfernen, damit Geräte über neue Zertifikate eine Verbindung herstellen können.
  • Zugriffsrechte für den zentralen Zertifikatsspeicher, um einzuschränken, was die verschiedenen Rollen im Backend mit den Zertifikaten tun können.

Verwenden Sie eine Secret-Speicher- und Verwaltungslösung wie Secret Manager oder HashiCorp Vault. Mit Secret Manager können Sie Geräteanmeldedaten versionieren, aktualisieren und ungültig machen und Zugriffsrichtlinien für Ihre Anmeldedaten verwalten.

Implementieren Sie für eine IoT-Plattform den Zugriff auf die Anmeldedaten mit Secret Manager API-Zugriff.

Zertifikate auf Edge-Geräten schützen

Verwenden Sie zum Speichern von Zertifikaten und Schlüsseln auf den Edge-Geräten eine lokale vertrauenswürdige Ausführungsumgebung oder einen Zertifikatspeicher, um die Anmeldedaten zu schützen und nicht autorisierte Zugriffe zu blockieren. Wenn Sie Secret-Material auf Ihren Geräten speichern müssen, verschlüsseln Sie dieses Material mit Methoden wie der Flash-Verschlüsselung und speichern Sie es auf manipulationssicheren Elementen, um nicht autorisierte Datenextraktion zu verhindern.

Zentralen Zertifikatsspeicher mit dem MQTT-Broker-Zertifikatsspeicher synchronisieren

MQTT-Broker müssen auf Clientzertifikate für die zertifikatbasierte Authentifizierung zugreifen. Daher müssen Sie die Zertifikatsspeicher von MQTT-Brokern mit dem zentralen Zertifikatspeicher synchronisieren. Prüfen Sie, ob Änderungen am zentralen Zertifikatsspeicher, z. B. zum Hinzufügen, Aktualisieren und Löschen von Zertifikaten, mit dem MQTT-Broker-Zertifikatsspeicher synchronisiert werden. MQTT-Broker verwenden Zertifikatspeicher wie MySQL, PostgresDB und Java Key Store. Je nachdem, welchen Zertifikatsspeicher Ihr MQTT-Broker verwendet, müssen Sie dafür sorgen, dass die folgenden Prozesse vorhanden sind:

  • Einen Prozess, der Änderungen im zentralen Zertifikatsspeicher überwacht und den Synchronisierungsprozess benachrichtigt.
  • Ein Prozess, der Änderungen im zentralen Zertifikatspeicher verwendet und die Änderungen im zentralen Zertifikatsspeicher mit dem vom MQTT-Broker verwendeten Zertifikatspeicher synchronisiert.

Wenn Sie Secret Manager als Zertifikatspeicher verwenden, können Sie Ereignisbenachrichtigungen als Monitoringprozess verwenden. Sie können den Synchronisierungsprozess als Listener der Ereignisbenachrichtigungen implementieren.

Zertifikate gleichmäßig auf Edge-Geräte verteilen

Verteilen Sie bei der Verwendung von MQTT-Brokern das Root-Zertifikat und die Clientzertifikate an Ihre Edge-Geräte. Wenn Sie Zertifikate verteilen, müssen Sie Ihre Kommunikationskanäle sichern, damit der Traffic nicht abgefangen wird.

Die wichtigsten Kommunikationskanäle für die Zertifikatsverteilung sind:

  • Ein direkter Pfad vom IoT-Backend zu den Edge-Geräten über vorhandene Kommunikationskanäle.
  • Ein indirekter Pfad, in dem Edge-Geräte die Zertifikate anfordern und herunterladen.

Während der Zertifikatsverteilung benötigen Sie die folgenden Komponenten:

  • Ein Zertifikatsspeicher, in dem Zertifikate zentral verwaltet werden.
  • Ein Verteilungskoordinator, der die Zertifikate sendet und den Verteilungsprozess für jedes Edge-Gerät verfolgt.
  • Ein Update-Handler auf dem Edge-Gerät, das die Zertifikate empfängt oder herunterlädt und auf dem Gerät speichert.

Verteilen Sie Zertifikate während der Bereitstellung für Edge-Geräte und wenn Zertifikate rotiert werden müssen.

Sorgen Sie während des Bereitstellungsprozesses dafür, dass der Bereitsteller über verschlüsselte Kanäle wieSSH und verwendet Tools wie SCP. Da die Geräte nicht in Betrieb sind, können Sie Zertifikate direkt an die Edge-Geräte übertragen.

Verwenden Sie beim Rotieren von Zertifikaten den MQTT-Broker als Kommunikationskanal zwischen dem Distributionskoordinator und den Edge-Geräten. Verwenden Sie andere Kanäle, um Zertifikate auf das Gerät herunterzuladen. Verwenden Sie einen indirekten Zertifikatsverteilungspfad, um die Ausführung der Edge-Geräte in Betrieb zu minimieren. Der Prozess besteht aus den folgenden logischen Schritten:

  1. Der Verteilungskoordinator ruft Anmeldedaten aus dem Zertifikatspeicher ab.
  2. Der Distributionskoordinator überträgt die Anmeldedaten für den Zertifikatzugriff mit zusätzlichen Informationen wie der Download-URL an die Edge-Geräte.
  3. Der On-Device-Update-Handler empfängt die Zugriffsanmeldedaten und speichert die Informationen vorübergehend und bestätigt den Empfang.
  4. Der Update-Handler koordiniert den Download des Zertifikats, wenn das Gerät nicht aktiv ist. Der Update-Handler verwendet die Zugriffsanmeldedaten, um Zertifikate aus dem Anmeldedatenspeicher herunterzuladen.
  5. Nach dem Herunterladen der Zertifikate wird der Aktualisierungs-Handler mit der Zertifikatsrotation fortgesetzt, die im Abschnitt Zertifikatsrotation beschrieben wird.

Wenn Sie Secret Manager als zentralen Zertifikatsspeicher verwenden, können Sie kurzlebige Zugriffstokens generieren, um den Zugriff auf Zertifikate zu gewähren und zu beschränken. Weitere Informationen finden Sie unter Zugriffstokens sicher auf Geräte verteilen.

Verschlüsseln Sie die Verbindung zwischen Ihren Edge-Geräten und dem MQTT-Broker, um zu verhindern, dass die Zertifikate während der Übertragung verfügbar gemacht werden. Weitere Informationen finden Sie unter Best Practices für die Netzwerkverbindung.

Zertifikate automatisch rotieren

Um den Schaden zu begrenzen, den ein offengelegtes Zertifikat verursachen kann, generieren Sie Zertifikate mit einem endlichen gültigen Zeitraum und rotieren die Zertifikate, bevor sie ablaufen. Implementieren Sie bei umfangreichen IoT-Bereitstellungen ein automatisches Verfahren zur Zertifikatsrotation, um Ihre Geräte konsistent mit neuen Zertifikaten zu aktualisieren, bevor die alten ablaufen. Bereitgestellte Geräte ohne gültige Zertifikate bedeuten, dass die Geräte nicht mehr funktionieren. Dies kann kostspielig sein und die Gesamtfunktionalität Ihrer IoT-Lösung beeinträchtigen.

Ihre Edge-Geräte müssen bidirektional eine Verbindung zum MQTT-Broker herstellen, um sicherzustellen, dass sie Nachrichten an den MQTT-Broker senden und Nachrichten vom MQTT-Broker empfangen können.

Für die Zertifikatsrotation benötigen Sie die folgenden Komponenten:

  • Ein Monitoringprozess, der Ihr Zertifikatsinventar regelmäßig durchsucht und nach Zertifikaten sucht, die bald ablaufen. Der Monitoring-Prozess löst die Rotation von Zertifikaten für ablaufende Zertifikate aus.
  • Ein Rotationsprozess, der die Zertifikatsrotation initialisiert und überwacht.
  • Ein Handler für die Rotation des Gerätezertifikats auf dem Edge-Gerät, das mit dem MQTT-Broker kommuniziert und Zertifikatsrotationsschritte auf dem Gerät ausführt.

Die Rotation von Zertifikaten führt die folgenden Schritte aus:

  1. Der Rotationsprozess sendet eine Initialisierungsnachricht an das Edge-Gerät, um die Zertifikatsrotation zu starten.
  2. Der Gerätezertifikat-Rotations-Handler bestätigt die Initialisierungsnachricht, indem er eine Antwort an den Rotationsjob sendet.
  3. Beim Rotationsprozess wird ein neues Zertifikat von der Zertifizierungsstelle angefordert. Diese Anfrage ähnelt der Anfrage zur Zertifikatbereitstellung, mit der Ausnahme, dass die Schlüssel und CSR als MQTT-Broker-Nachrichten gesendet werden.
  4. Nach dem Empfang des neuen Zertifikats von der Zertifizierungsstelle verteilt der Rotationsjob das Zertifikat an den zentralen Zertifikatsspeicher und an das Edge-Gerät. Außerdem wird das Zertifikat mit dem Zertifikatsspeicher des MQTT-Brokers synchronisiert.
  5. Der Handler für die Rotation des Gerätezertifikats speichert das neue Zertifikat und initialisiert mit dem neuen Zertifikat eine neue Verbindung mit dem MQTT-Broker.
  6. Nachdem die neue Verbindung hergestellt wurde, sendet der Rotations-Handler für die Gerätezertifikate eine abgeschlossene Nachricht an den MQTT-Broker.
  7. Nach dem Erhalt der abgeschlossenen Nachricht wird durch das Rotationsverfahren das alte Zertifikat im zentralen Zertifikatspeicher ungültig.

Verwenden Sie zum Schutz der Zertifikate, die während der Rotation gesendet werden, dedizierte MQTT-Themen für die Zertifikatsrotation. Beschränken Sie den Zugriff auf diese Themen nur auf den Rotationsjob und das Edge-Gerät.

Aktivieren Sie die Persistenz für die Änderungen und den Fortschritt, um den Prozess der Zertifikatsrotation vor Laufzeitfehlern zu schützen.

Weitere Informationen zum Rotieren von Secrets mit Secret Manager finden Sie unter Secret-Rotation.

Best Practices für die Zertifikatsverwaltung für IoT-Plattformen

Wenn Sie eine IoT-Plattform verwenden, verwenden Sie die von der Plattform bereitgestellten Mechanismen zur Zertifikatsaktualisierung und -verteilung. Zu Sicherungszwecken können Sie die Anmeldedaten regelmäßig von Ihrer IoT-Plattform in einen sekundären Secret-Speicher wie Secret Manager exportieren.

Best Practices für die Authentifizierung mit einem MQTT-Broker

Bei dem gegenseitigen Authentifizierungsprozess prüfen Backend-Arbeitslasten die Identität von Edge-Geräten und Edge-Geräte die Identität von Backend-Arbeitslasten. Nachdem die Backend-Arbeitslasten die Identität des Edge-Geräts bestätigt haben, autorisieren die Backend-Arbeitslasten den Gerätezugriff auf Ressourcen.

Die folgenden Abschnitte enthalten Best Practices für Authentifizierungsmethoden bei der Verwendung von MQTT-Brokern.

Authentifizierungsmethode für MQTT-Broker auswählen

Verschiedene IoT-Back-Ends unterstützen unterschiedliche Authentifizierungsmethoden. Am häufigsten werden folgende Methoden verwendet:

  • Authentifizierung mit Nutzername und Passwort, wobei das Edge-Gerät seinen Nutzernamen und sein Passwort angibt, um seine Identität zu bestätigen.
  • Tokenbasierte Authentifizierung, bei der verschlüsselte Sicherheitstokens verwendet werden, um die Identität des Edge-Geräts zu prüfen.
  • Benutzerdefinierte Authentifizierungsschemas, bei denen Sie einen benutzerdefinierten Mechanismus implementieren, um die Identität des Edge-Geräts zu prüfen.

Als Teil des MQTT-Standards unterstützen MQTT-Broker die Authentifizierung mit Nutzernamen und Passwort als Standard für MQTT CONNECT-Pakete.

Das Paket MQTT CONNECT enthält außerdem das Feld Client Identifier, mit dem Sie den Client gegenüber dem MQTT-Broker eindeutig identifizieren können. Edge-Geräte senden das Paket MQTT CONNECT an den MQTT-Broker, wenn sie eine Verbindung herstellen.

Neben den Feldern für Nutzername, Passwort und Client-ID im Paket MQTT CONNECT unterstützt MQTT 5.0 die erweiterte Authentifizierung, mit der Sie eine Challenge-Antwort für Authentifizierungsabläufe erstellen können. MQTT 5.0 ermöglicht mehrere AUTH-Paketaustausche zwischen dem Edge-Gerät und dem MQTT-Broker.

Passwortspeicher mit Nutzername und Passwortauthentifizierung verwenden

Konfigurieren Sie für die Nutzernamen- und Passwortauthentifizierung den MQTT-Broker so, dass er einen Passwortspeicher verwendet. Der Passwortspeicher bietet einen zentralen Speicherort zum Verwalten von Passwörtern für alle Edge-Geräte, die eine Verbindung zum MQTT-Broker herstellen. Standardmäßig sind die Felder für Nutzername, Passwort und Client-ID in der MQTT-Spezifikation optional. Konfigurieren Sie daher den Authentifizierungsmechanismus, um zu prüfen, ob die Felder für Nutzername, Passwort und Client-ID im Paket MQTT CONNECT vorhanden sind.

Stellen Sie sicher, dass die inaktiven und übertragenen Passwörter so verschlüsselt sind:

Tokenbasierte Authentifizierung in Betracht ziehen

Bei der tokenbasierten Authentifizierung senden Edge-Geräte ein Token zur Authentifizierung an den MQTT-Broker. Geräte können das Token selbst generieren oder das Token von anderen Authentifizierungsdiensten abrufen. Im Vergleich zu Passwörtern sind Tokens kurzlebig: Tokens sind nur für einen Zeitraum mit einem expliziten Ablaufdatum gültig. Prüfen Sie immer den Ablauf, wenn Sie Tokens validieren.

Mit JSON Web Tokens (JWT) kann die tokenbasierte Authentifizierung implementiert werden. Edge-Geräte können das JWT generieren und sich beim MQTT-Broker authentifizieren. Das JWT ist als Passwortfeld in das MQTT-CONNECT-Paket eingebettet.

JWT bietet folgende Vorteile:

  • Mit JWT können Sie den Verschlüsselungsalgorithmus auswählen, der zum Signieren des Tokens verwendet wird. JWT funktioniert gut mit eingeschränkten Edge-Geräten, bei denen Sie einen weniger ressourcenintensiven Verschlüsselungsalgorithmus wie ECC zum Signieren des Tokens verwenden können.
  • Mit der Kryptografie mit einem öffentlichen Schlüssel wird der private Schlüssel nur auf dem Edge-Gerät verwendet und ist niemals für andere Parteien freigegeben. Ein privater Schlüssel hilft, diese Methode sicherer zu machen als die Authentifizierung mit Nutzername und Passwort, bei der die Anmeldedaten über die Verbindung gesendet werden und eine Verschlüsselung der Daten erfordern.

Benutzerdefinierte Authentifizierungsschemas in Betracht ziehen

Einige MQTT-Broker unterstützen unterschiedliche Authentifizierungsmechanismen und -Protokolle. Wenn Ihr MQTT-Broker beispielsweise benutzerdefinierte Authentifizierungsschemas unterstützt, können Sie ihn so konfigurieren, dass er Folgendes unterstützt:

  • Branchenstandard-Authentifizierungsprotokolle wie OpenID Connect, Security Assertion Markup Language (SAML) und LDAP, Kerberos und Simple Authentication and Security Layer (SASL). Diese Protokolle delegieren die Geräteauthentifizierung an Ihre vorhandenen Identitätsanbieter. Einige MQTT-Broker unterstützen eine erweiterte Authentifizierung und erweiterbare Authentifizierungsmechanismen, mit denen Sie den MQTT-Broker auf neue Protokolle und Identitätsanbieter erweitern können.
  • Zertifikatsbasierte gegenseitige Authentifizierung Einige MQTT-Broker unterstützen ein gegenseitiges Authentifizierungsschema, z. B. die mTLS-basierte Authentifizierung.

Best Practices für Zugriffssteuerung und Autorisierung

Aufgrund des Publisher- und Abonnentenkommunikationsmusters des MQTT-Protokolls wird die Gerätezugriffssteuerung mithilfe von MQTT-Themen definiert. MQTT-Themen steuern, wie ein Gerät mit Ihrem IoT-Backend kommunizieren kann. Jedes IoT-Backend hat unterschiedliche Implementierungen für die Zugriffssteuerung und Autorisierung. In der Dokumentation zum IoT-Backend finden Sie Optionen zum Einrichten von MQTT-Themen.

Dienstkonten für einen einzigen Zweck verwenden, um auf Google Cloud-Ressourcen zuzugreifen

Der Zugriff auf Google Cloud-Ressourcen wird durch IAM-Zulassungsrichtlinien verwaltet, die den Zugriff auf die Ressource mit einer Reihe von Hauptkonten binden. Typische Hauptkonten sind Nutzerkonten, Dienstkonten und Gruppen. Dienstkonten werden normalerweise von einer Anwendung oder Computing-Arbeitslast verwendet, um autorisierte API-Aufrufe für Cloud-Ressourcen durchzuführen. Mit Dienstkonten können IoT-Edge-Geräte auf Cloud-Ressourcen zugreifen.

Da die Geräteidentität vom IoT-Backend verwaltet wird, müssen Sie eine Identität zwischen dem IoT-Backend und IAM zuordnen, damit das Edge-Gerät auf Google Cloud-Ressourcen zugreifen kann.

Wenn Sie eine große Anzahl von Geräten verwalten, macht das Limit für die Anzahl der Dienstkonten für jedes Google Cloud-Projekt die direkte Zuordnung zwischen Gerät und Dienstkonto unmöglich.

Erstellen Sie stattdessen Dienstkonten, die mit den Cloud-Ressourcen verknüpft sind, auf die Ihre IoT-Lösung zugreifen muss, wie unter Dienstkonten für einzelne Zwecke erstellen beschrieben. Erstellen Sie beispielsweise ein eindeutiges Dienstkonto für jeden der folgenden Anwendungsfälle:

  • Software-Updatepakete herunterladen
  • Große Mediendateien hochladen
  • Daten aus einem Latenzstream aufnehmen

Sorgen Sie dafür, dass jedes Dienstkonto nur ausreichende Zugriffsrechte für den jeweiligen Anwendungsfall hat, um die geringste Berechtigung zu implementieren. Gewähren Sie beispielsweise für ein Dienstkonto, das zum Herunterladen von Softwarepaketen verwendet wird, nur Lesezugriff auf den Cloud Storage-Bucket.

Zugriffstokens sicher an Geräte verteilen

Normalerweise kommunizieren Ihre Edge-Geräte über MQTT mit Ihrer IoT-Plattform. Für bestimmte Anwendungsfälle benötigen Ihre Geräte jedoch möglicherweise direkten Zugriff auf Google Cloud-Ressourcen. Sie könnten beispielsweise Folgendes versuchen:

  • Zum Herunterladen von Inhalten benötigt ein Edge-Gerät während des Downloads nur Lesezugriff auf einen Cloud Storage-Bucket.
  • Zum Hochladen von Daten in einen Cloud Storage-Bucket benötigt ein Edge-Gerät Schreibzugriff auf den Bucket.

Verwenden Sie für diese Anwendungsfälle die Workload Identity-Föderation, bei der der Zugriff auf Google Cloud-Ressourcen über Zugriffstokens gewährt wird. Dank der Workload Identity-Föderation ist es nicht mehr erforderlich, Cloud-spezifische Anmeldedaten auf den Edge-Geräten bereitzustellen. Die Zugriffsverteilung erfolgt dynamisch nach Bedarf.

Konfigurieren Sie die Workload Identity-Föderation zwischen Ihrem Geräteidentitätsanbieter und Google Cloud, um Zugriffstokens für Cloud-Ressourcen an Ihre Geräte zu verteilen. Zur Unterstützung der Workload Identity-Föderation müssen Sie sicherstellen, dass Ihr IoT-Backend die Anforderungen der Workload Identity-Föderation erfüllt und die Best Practices für die Sicherheit befolgt, die Ihren Anwendungsfällen entsprechen.

Für den Zugriff auf Google Cloud-Ressourcen mithilfe der Workload Identity-Föderation müssen Ihre Edge-Geräte den Workflow OAuth 2.0 Token Exchange implementieren. Dieser Vorgang umfasst die folgenden Schritte:

  • Das Gerät ruft den Security Token Service auf und stellt seine eigenen Anmeldedaten bereit.
  • Der Security Token Service überprüft die Identität des Edge-Geräts. Dazu werden die Anmeldedaten des Edge-Geräts geprüft, das vom Geräteidentitätsanbieter bereitgestellt wurde.
  • Wenn die Identitätsbestätigung erfolgreich ist, gibt der Security Token Service ein föderiertes Token an das Edge-Gerät zurück.
  • Das Edge-Gerät verwendet das föderierte Token, um die Identität des Einzelzweckdienstkontos zu übernehmen, und ruft ein kurzlebiges OAuth 2.0-Zugriffstoken ab.
  • Das Gerät verwendet das kurzlebige OAuth 2.0-Zugriffstoken, um sich bei Google Cloud APIs zu authentifizieren und auf die erforderlichen Cloud-Ressourcen zuzugreifen.

Verwenden Sie Zugriffsgrenzen für Anmeldedaten, um den Zugriff des kurzlebigen Zugriffstokens auf bestimmte Buckets und Objekte in Cloud Storage einzuschränken. Mit einer Zugriffsgrenze für Anmeldedaten können Sie den Zugriff auf die kurzlebigen Anmeldedaten beschränken und die Anzahl der Ressourcen minimieren, die in Ihren Cloud Storage-Buckets verfügbar gemacht werden, wenn ein Zugriffstoken manipuliert wurde.

Die Workload Identity-Föderation bietet eine skalierbare Möglichkeit, den Cloud-Zugriff sicher auf Edge-Geräte zu verteilen. Weitere Informationen zur Authentifizierung finden Sie unter Authentifizierung bei Google.

Zugriff auf Cloud-Ressourcen überwachen und prüfen

Aktivieren Sie Cloud-Audit-Logs, um Logeinträge zu erstellen, wenn Ihre Edge-Geräte über authentifizierte API-Anfragen auf Cloud-Ressourcen zugreifen. Mit Cloud-Audit-Logs können Sie kritische Aktionen beobachten, die von Ihren Edge-Geräten in Google Cloud ausgeführt werden. Darüber hinaus erstellt Cloud-Audit-Logging die Audit-Traces und Logs, die Sie zur Untersuchung von Problemen benötigen. Weitere Informationen finden Sie unter Identität eines Dienstkontos für den Zugriff auf Google Cloud übernehmen.

Nächste Schritte