Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Bewährte Sicherheitsmethoden in AWS IoT Core

Dieser Abschnitt enthält Informationen zu bewährten Sicherheitsmethoden für AWS IoT Core. Informationen zu den Sicherheitsregeln für IoT-Lösungen finden Sie unter Zehn goldene Regeln in Bezug auf die Sicherheit für IoT-Lösungen.

Schutz von MQTT-Verbindungen in AWS IoT

AWS IoT Coreist ein verwalteter Cloud-Dienst, der es verbundenen Geräten ermöglicht, einfach und sicher mit Cloud-Anwendungen und anderen Geräten zu interagieren. AWS IoT Core unterstützt HTTP und MQTT WebSocket, ein schlankes Kommunikationsprotokoll, das speziell für die Toleranz von intermittierenden Verbindungen entwickelt wurde. Wenn Sie AWS IoT mithilfe von MQTT eine Verbindung herstellen, muss jeder Ihrer Verbindungen eine Kennung zugeordnet werden, die als Client-ID bezeichnet wird. MQTT-Client-IDs identifizieren MQTT-Verbindungen eindeutig. Wenn eine neue Verbindung mit einer Client-ID hergestellt wird, die bereits für eine andere Verbindung beansprucht wird, trennt der AWS IoT Message Broker die alte Verbindung, um die neue Verbindung zuzulassen. Die Client-IDs müssen in jedem einzelnen AWS-Konto Client eindeutig sein AWS-Region. Das bedeutet, dass Sie nicht die globale Eindeutigkeit von Kunden-IDs außerhalb Ihres Unternehmens AWS-Konto oder regionsübergreifend in Ihrem Land durchsetzen müssen. AWS-Konto

Die Auswirkungen und der Schweregrad von getrennten MQTT-Verbindungen auf Ihre Geräteflotte hängt von vielen Faktoren ab. Dazu zählen:

Um Konflikte mit Client-IDs und deren mögliche negative Auswirkungen zu vermeiden, stellen Sie sicher, dass jedes Gerät oder jede mobile Anwendung über eine AWS IoT IAM-Richtlinie verfügt, die einschränkt, welche Client-IDs für MQTT-Verbindungen zum Message Broker verwendet werden können. AWS IoT Sie können beispielsweise eine IAM-Richtlinie verwenden, um zu verhindern, dass ein Gerät unbeabsichtigt die Verbindung eines anderen Geräts schließt, indem es eine bereits verwendete Client-ID nutzt. Weitere Informationen finden Sie unter Autorisierung.

Alle Geräte in Ihrer Flotte müssen über Anmeldeinformationen verfügen, die nur beabsichtigte Aktionen autorisieren. Dazu gehören (aber nicht beschränkt auf) AWS IoT MQTT-Aktionen wie das Veröffentlichen von Nachrichten oder das Abonnieren von Themen mit einem bestimmten Umfang und Kontext. Die spezifischen Berechtigungsrichtlinien können für Ihre Anwendungsfälle variieren. Ermitteln Sie die Berechtigungsrichtlinien, die Ihren Geschäfts- und Sicherheitsanforderungen am besten entsprechen.

Verwenden Sie AWS IoT Core Richtlinien-Variablen und IAM-Richtlinienvariablen, um die Erstellung und Verwaltung von Berechtigungsrichtlinien zu vereinfachen. Richtlinienvariablen können in einer Richtlinie platziert werden. Sie werden zu dem Zeitpunkt, zu dem die Richtlinie ausgewertet wird, durch Werte aus der Anforderung des Geräts ersetzt. Mithilfe von Richtlinienvariablen können Sie eine einzelne Richtlinie für die Erteilung von Berechtigungen für mehrere Geräte erstellen. Sie können die relevanten Richtlinienvariablen für Ihren Anwendungsfall anhand Ihrer AWS IoT Kontokonfiguration, Ihres Authentifizierungsmechanismus und des Netzwerkprotokolls, das für die Verbindung zum AWS IoT Message Broker verwendet wird, identifizieren. Um jedoch die besten Berechtigungsrichtlinien zu schreiben, müssen Sie die Besonderheiten Ihres Anwendungsfalls und Ihr Bedrohungsmodell berücksichtigen.

Wenn Sie beispielsweise Ihre Geräte in der AWS IoT Registrierung registriert haben, können Sie Dingrichtlinienvariablen in AWS IoT Richtlinien verwenden, um Berechtigungen auf der Grundlage von Dingeigenschaften wie Dingnamen, Dingtypen und Dingattributwerten zu gewähren oder zu verweigern. Der Dingname wird aus der Client-ID in der MQTT-Verbindungsnachricht abgerufen, die gesendet wird, wenn ein Ding eine Verbindung zu AWS IoT herstellt. Die Ding-Richtlinienvariablen werden ersetzt, wenn ein Ding mithilfe der gegenseitigen TLS-Authentifizierung eine Verbindung AWS IoT über MQTT oder mithilfe von authentifizierten Amazon Cognito-Identitäten über das WebSocket Protokoll herstellt. Sie können die AttachThingPrincipal API verwenden, um Zertifikate und authentifizierte Amazon Cognito-Identitäten an ein Ding anzuhängen. iot:Connection.Thing.ThingNameist eine nützliche Richtlinienvariable, um Client-ID-Einschränkungen durchzusetzen. Die folgende AWS IoT Beispielrichtlinie erfordert, dass der Name einer registrierten Sache als Client-ID für MQTT-Verbindungen zum AWS IoT Message Broker verwendet wird:

Wenn Sie laufende Client-ID-Konflikte identifizieren möchten, können Sie CloudWatch Logs für AWS IoT aktivieren und verwenden. Für jede MQTT-Verbindung, die der AWS IoT Message Broker aufgrund von Client-ID-Konflikten trennt, wird ein Protokolldatensatz ähnlich dem folgenden generiert:

{
    "timestamp": "2019-04-28 22:05:30.105",
    "logLevel": "ERROR",
    "traceId": "02a04a93-0b3a-b608-a27c-1ae8ebdb032a",
    "accountId": "123456789012",
    "status": "Failure",
    "eventType": "Disconnect",
    "protocol": "MQTT",
    "clientId": "clientId01",
    "principalId": "1670fcf6de55adc1930169142405c4a2493d9eb5487127cd0091ca0193a3d3f6",
    "sourceIp": "203.0.113.1",
    "sourcePort": 21335,
    "reason": "DUPLICATE_CLIENT_ID",
    "details": "A new connection was established with the same client ID"
}

Sie können einen CloudWatch Logs-Filter verwenden, {$.reason= "DUPLICATE_CLIENT_ID" } um beispielsweise nach Fällen von Client-ID-Konflikten zu suchen oder um CloudWatch Metrikfilter und entsprechende CloudWatch Alarme für die kontinuierliche Überwachung und Berichterstattung einzurichten.

Sie können AWS IoT Device Defender verwenden, um übermäßig freizügige Richtlinien AWS IoT und IAM-Richtlinien zu identifizieren. AWS IoT Device Defender bietet auch eine Audit-Überprüfung, die Sie benachrichtigt, wenn mehrere Geräte in Ihrer Flotte mit derselben Client-ID eine Verbindung zum AWS IoT Message Broker herstellen.

Mit AWS IoT Device Advisor können Sie überprüfen, ob Ihre Geräte zuverlässig eine Verbindung zu den bewährten Sicherheitsmethoden herstellen AWS IoT Core und diese befolgen können.

Weitere Informationen finden Sie auch unter

Synchronisieren der internen Uhr eines Geräts

Es ist wichtig, dass Sie eine genaue Uhrzeit auf Ihrem Gerät haben. X.509 Zertifikate haben ein Ablaufdatum und eine Gültigkeitsdauer. Die Uhr auf Ihrem Gerät wird verwendet, um sicherzustellen, dass ein Serverzertifikat noch gültig ist. Wenn Sie kommerzielle IoT-Geräte bauen, denken Sie daran, dass Ihre Produkte möglicherweise über einen längeren Zeitraum aufbewahrt werden, bevor sie verkauft werden. Real-time Während dieser Zeit können die Uhren schwanken und die Batterien können sich entladen. Daher reicht das Einstellen der Uhrzeit im Werk nicht aus.

Für die meisten Systeme bedeutet dies, dass die Software des Geräts einen NTP-Client (Network Time Protocol) enthalten muss. Das Gerät sollte warten, bis es mit einem NTP-Server synchronisiert wird, bevor es versucht, eine Verbindung zu AWS IoT Core herzustellen. Wenn dies nicht möglich ist, sollte das System dem Benutzer die Möglichkeit geben, die Zeit des Gerätes so einzustellen, dass nachfolgende Verbindungen erfolgreich sind.

Nachdem das Gerät mit einem NTP-Server synchronisiert wurde, kann es eine Verbindung mit AWS IoT Core herstellen. Wie viel Taktversatz zulässig ist, hängt davon ab, was Sie mit der Verbindung tun möchten.

Überprüfen des Serverzertifikats

Das erste, womit ein Gerät interagiert, AWS IoT ist das Öffnen einer sicheren Verbindung. Wenn Sie Ihr Gerät mit verbinden, stellen Sie sicher AWS IoT, dass Sie mit einem anderen Server sprechen AWS IoT und nicht, der sich als ein anderer Server ausgibt. AWS IoT Jeder der AWS IoT Server ist mit einem für die Domain ausgestellten Zertifikat ausgestattet. iot.amazonaws.com Dieses Zertifikat wurde AWS IoT von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt, die unsere Identität und unser Eigentum an der Domain verifiziert hat.

Eines der ersten Dinge, die getan werden AWS IoT Core , wenn ein Gerät eine Verbindung herstellt, ist, dem Gerät ein Serverzertifikat zu senden. Geräte können überprüfen, ob sie eine Verbindung zu iot.amazonaws.com erwartet haben und ob der Server am Ende dieser Verbindung ein Zertifikat einer vertrauenswürdigen Autorität für diese Domäne hat.

TLS-Zertifikate haben ein X.509 Format und enthalten eine Vielzahl von Informationen wie den Namen, den Standort, den Domainnamen und eine Gültigkeitsdauer der Organisation. Der Gültigkeitszeitraum wird als ein Paar von Zeitwerten angegeben, die notBefore und notAfter genannt werden. Dienste wie Dienste AWS IoT Core verwenden begrenzte Gültigkeitszeiträume (z. B. ein Jahr) für ihre Serverzertifikate und beginnen mit der Bereitstellung neuer Zertifikate, bevor die alten ablaufen.

Verwenden einer einzigen Identität pro Gerät

Verwenden Sie eine einzige Identität pro Client. Geräte verwenden in der Regel X.509 Client-Zertifikate. Web- und Mobilanwendungen verwenden Amazon Cognito Identity. Auf diese Weise können Sie detaillierte Berechtigungen auf Ihre Geräte anwenden.

Sie könnten beispielsweise eine Anwendung haben, die aus einem Mobiltelefon besteht, das Statusaktualisierungen von zwei verschiedenen Smart-Home-Objekten empfängt einer Glühbirne und einem Thermostat. Die Glühbirne sendet den Status ihres Batteriestands und ein Thermostat sendet Meldungen über die Temperatur.

AWS IoT authentifiziert Geräte einzeln und behandelt jede Verbindung einzeln. Sie können differenzierte Zugriffskontrollen mithilfe von Autorisierungsrichtlinien anwenden. Sie können eine Richtlinie für den Thermostat definieren, die es ihm ermöglicht, in einem Themenbereich zu veröffentlichen. Sie können eine separate Richtlinie für die Glühbirne definieren, die es ihr ermöglicht, in einem anderen Themenbereich zu veröffentlichen. Schließlich können Sie eine Richtlinie für die mobile App definieren, die es ihr nur erlaubt, sich mit den Themen für den Thermostat und die Glühbirne zu verbinden und diese zu abonnieren, um Nachrichten von diesen Geräten zu empfangen.

Wenden Sie das Prinzip der geringsten Privilegien an und beschränken Sie die Berechtigungen pro Gerät so weit wie möglich. Alle Geräte oder Benutzer sollten über eine AWS IoT Richtlinie verfügen AWS IoT , die es ihnen nur erlaubt, eine Verbindung mit einer bekannten Client-ID herzustellen und bestimmte, festgelegte Themen zu veröffentlichen und zu abonnieren.

Verwenden Sie eine Sekunde AWS-Region als Backup

Erwägen Sie, in einer Sekunde eine Kopie Ihrer Daten AWS-Region als Backup zu speichern. Beachten Sie, dass die AWS Lösung mit dem Namen Disaster Recovery for nicht mehr verfügbar AWS IoT ist. Die zugehörige GitHub Bibliothek ist zwar weiterhin zugänglich, AWS wurde aber im Juli 2023 als veraltet eingestuft und bietet keine Wartung oder Unterstützung mehr für sie an. Um Ihre eigenen Lösungen zu implementieren oder zusätzliche Support-Optionen zu erkunden, besuchen Sie Kontakt. AWS Wenn mit Ihrem Konto ein AWS Technical Account Manager verknüpft ist, wenden Sie sich an diesen, um Hilfe zu erhalten.

Just-in-Time-Bereitstellung nutzen

Die manuelle Erstellung und Bereitstellung jedes Geräts kann zeitaufwändig sein. AWS IoT bietet die Möglichkeit, eine Vorlage für die Bereitstellung von Geräten zu definieren, wenn sie zum AWS IoT ersten Mal eine Verbindung herstellen. Weitere Informationen finden Sie unter Just-in-time Bereitstellung.

Berechtigungen zum Ausführen AWS IoT Device Advisor-Tests

Die folgende Richtlinienvorlage zeigt die Mindestberechtigungen und die IAM-Entität, die für die Ausführung von AWS IoT Device Advisor-Testfällen erforderlich sind. Sie müssen sie your-device-role-arn durch die Geräterolle Amazon Resource Name (ARN) ersetzen, die Sie unter den Voraussetzungen erstellt haben.

Cross-service verwirrte stellvertretende Prävention für Device Advisor

Das Problem des verwirrten Stellvertreters ist ein Sicherheitsproblem, bei dem eine Entität, die keine Berechtigung zur Durchführung einer Aktion hat, eine privilegiertere Entität zur Durchführung der Aktion zwingen kann. In AWS kann dienstübergreifender Identitätswechsel zu einem verwirrten Stellvertreter-Problem führen. Cross-service Ein Identitätswechsel kann auftreten, wenn ein Dienst (der aufrufende Dienst) einen anderen Dienst (den aufgerufenen Dienst) anruft. Der Anruf-Dienst kann so manipuliert werden, dass er seine Berechtigungen verwendet, um auf die Ressourcen eines anderen Kunden zu reagieren, auf die er sonst nicht zugreifen dürfte. Um dies zu verhindern, AWS bietet Tools, mit denen Sie Ihre Daten für alle Dienste schützen können, deren Dienstprinzipale Zugriff auf Ressourcen in Ihrem Konto erhalten haben.

Wir empfehlen die Verwendung der globalen Bedingungskontext-Schlüssel aws:SourceArn und aws:SourceAccount in ressourcenbasierten Richtlinien, um die Berechtigungen, die Device Advisor einem anderen Service erteilt, auf eine bestimmte Ressource zu beschränken. Wenn Sie beide globalen Bedingungskontextschlüssel verwenden, müssen der aws:SourceAccount-Wert und das Konto im aws:SourceArn-Wert dieselbe Konto-ID verwenden, wenn sie in derselben Richtlinienanweisung verwendet werden.

Der Wert aws:SourceArn muss der ARN Ihrer Suite-Definitionsressource sein. Die Suite-Definitionsressource bezieht sich auf die Testsuite, die Sie mit Device Advisor erstellt haben.

Der effektivste Weg, um sich vor dem Confused-Deputy-Problem zu schützen, ist die Verwendung des globalen Bedingungskontext-Schlüssels aws:SourceArn mit dem vollständigen ARN der Ressource. Wenn Sie den vollständigen ARN der Ressource nicht kennen oder wenn Sie mehrere Ressourcen angeben, verwenden Sie den globalen Bedingungskontext-Schlüssel aws:SourceArn mit Platzhaltern (*) für die unbekannten Teile des ARN. Beispiel: arn:aws:iotdeviceadvisor:*:account-id:suitedefinition/*

Das folgende Beispiel zeigt, wie Sie die globalen Bedingungskontext-Schlüssel aws:SourceArn und aws:SourceAccount in Device Advisor verwenden können, um das Confused-Deputy-Problem zu vermeiden.