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 einfaches Kommunikationsprotokoll, das speziell für die Tolerierung intermittierender Verbindungen entwickelt wurde. Wenn Sie eine Verbindung AWS IoT über MQTT herstellen, muss jede Ihrer Verbindungen mit einer Kennung verknüpft sein, die als Client-ID bezeichnet wird. Der MQTT-Client identifiziert MQTT-Verbindungen IDs eindeutig. Wenn eine neue Verbindung mit einer Client-ID hergestellt wird, die bereits für eine andere Verbindung beansprucht wurde, löscht der AWS IoT Message Broker die alte Verbindung, um die neue Verbindung zuzulassen. Der Client IDs muss in jedem Fall AWS-Konto einzigartig sein AWS-Region. Das bedeutet, dass Sie nicht die globale Einzigartigkeit des Kunden IDs außerhalb Ihrer Region AWS-Konto oder regionsübergreifend innerhalb Ihrer AWS-Konto Region erzwingen müssen.

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

Um Client-ID-Konflikte und ihre möglichen negativen Auswirkungen zu vermeiden, stellen Sie sicher, dass jedes Gerät oder jede mobile Anwendung über eine AWS IoT oder IAM-Richtlinie verfügt, die einschränkt, welcher Client für MQTT-Verbindungen zum Message Broker verwendet werden IDs kann. 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 mit Rechten 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 Richtlinienvariablen 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 Ihres 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 Ihre Geräte beispielsweise in der AWS IoT Registrierung registriert haben, können Sie Ding-Richtlinienvariablen in AWS IoT Richtlinien verwenden, um Berechtigungen auf der Grundlage von Dingeigenschaften wie Dingnamen, Dingtypen und Dingattributwerten zu gewähren oder zu verweigern. Der Name des Dings wird aus der Client-ID in der MQTT-Verbindungsnachricht abgerufen, die gesendet wird, wenn ein Ding eine Verbindung AWS IoT herstellt. Die Ding-Richtlinienvariablen werden ersetzt, wenn ein Ding AWS IoT über MQTT mithilfe der gegenseitigen TLS-Authentifizierung oder MQTT über WebSocket das Protokoll mithilfe authentifizierter Amazon Cognito Cognito-Identitäten eine Verbindung herstellt. Sie können die AttachThingPrincipalAPI verwenden, um Zertifikate und authentifizierte Amazon Cognito Cognito-Identitäten an eine Sache anzuhängen. iot:Connection.Thing.ThingNameist eine nützliche Richtlinienvariable, um Client-ID-Beschrä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:

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": "iot:Connect",
			"Resource": [
				"arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"
			]
		}
	]
}

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

{
    "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 Protokollfilter verwenden, {$.reason= "DUPLICATE_CLIENT_ID" } um beispielsweise nach Instanzen 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 zu freizügige Richtlinien AWS IoT und IAM-Richtlinien zu identifizieren. AWS IoT Device Defender bietet auch eine Auditprüfung, die Sie benachrichtigt, wenn mehrere Geräte in Ihrer Flotte über dieselbe Client-ID eine Verbindung zum AWS IoT Message Broker herstellen.

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

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 Ablaufzeit. Die Uhr auf Ihrem Gerät wird verwendet, um sicherzustellen, dass ein Serverzertifikat noch gültig ist. Wenn Sie kommerzielle IoT-Geräte erstellen, denken Sie daran, dass Ihre Produkte vor dem Verkauf über einen längeren Zeitraum gelagert werden können. Echtzeituhren können während dieser Zeit abweichen und die Batterien können entladen werden, sodass die werkseitige Zeiteinstellung nicht ausreicht.

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, was ein Gerät tut, um mit ihm zu interagieren, AWS IoT ist, eine sichere Verbindung herzustellen. Wenn Sie Ihr Gerät mit verbinden, stellen Sie sicher AWS IoT, dass Sie mit einem anderen Server sprechen AWS IoT und nicht mit einem anderen Server, der sich als solcher ausgibt. AWS IoT Jeder der AWS IoT Server ist mit einem Zertifikat ausgestattet, das für die Domain ausgestellt wurde. iot.amazonaws.com Dieses Zertifikat wurde AWS IoT von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt, die unsere Identität und unser Eigentum an der Domain verifizierte.

Wenn ein Gerät eine Verbindung herstellt, wird dem Gerät als Erstes ein Serverzertifikat gesendet. AWS IoT Core 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 liegen im X.509-Format vor und enthalten eine Vielzahl von Informationen wie Name, Standort, Domänenname und Gültigkeitsdauer für die Organisation. Der Gültigkeitszeitraum wird als ein Paar von Zeitwerten angegeben, die notBefore und notAfter genannt werden. Dienste wie 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. Für alle Geräte oder Benutzer sollte eine AWS IoT Richtlinie gelten AWS IoT , die es ihnen nur erlaubt, eine Verbindung mit einer bekannten Client-ID herzustellen und bestimmte Themen zu veröffentlichen und zu abonnieren.

Verwenden Sie eine Sekunde AWS-Region als Backup

Erwägen Sie, innerhalb 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. Auf die zugehörige GitHubBibliothek kann zwar weiterhin zugegriffen werden, sie AWS wurde jedoch im Juli 2023 als veraltet eingestuft und bietet keine Wartung oder Unterstützung mehr für sie. Besuchen Sie Kontakt, um Ihre eigenen Lösungen zu implementieren oder zusätzliche Supportoptionen zu erkunden. 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 zu definieren, mit der Geräte bereitgestellt werden, wenn sie zum AWS IoT ersten Mal eine Verbindung herstellen. Weitere Informationen finden Sie unter J Bereitstellung ust-in-time .

Berechtigungen zum Ausführen von 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 Amazon Resource Name (ARN) durch die Geräterolle ersetzenyour-device-role-arn, die Sie unter den Voraussetzungen erstellt haben.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "your-device-role-arn",
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": "iotdeviceadvisor.amazonaws.com"
                }
            }
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "execute-api:Invoke*",
                "iam:ListRoles",   // Required to list device roles in the Device Advisor console
                "iot:Connect",  
                "iot:CreateJob",
                "iot:DeleteJob",
                "iot:DescribeCertificate", 
                "iot:DescribeEndpoint",
                "iotjobsdata:DescribeJobExecution",
                "iot:DescribeJob",                                 
                "iot:DescribeThing",
                "iotjobsdata:GetPendingJobExecutions",
                "iot:GetPolicy",
                "iot:ListAttachedPolicies",
                "iot:ListCertificates",
                "iot:ListPrincipalPolicies",
                "iot:ListThingPrincipals",
                "iot:ListThings",
                "iot:Publish",    
                "iotjobsdata:StartNextPendingJobExecution",
                "iotjobsdata:UpdateJobExecution",
                "iot:UpdateThingShadow",                
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:DescribeLogGroups",
                "logs:DescribeLogStreams",
                "logs:PutLogEvents",
                "logs:PutRetentionPolicy"
            ],
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor2",
            "Effect": "Allow",
            "Action": "iotdeviceadvisor:*",
            "Resource": "*"
        }
    ]
}

Confused-Deputy-Prävention im dienstübergreifenden Szenario 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 ein dienstübergreifendes Identitätswechsels zu dem Problem mit dem verwirrten Stellvertreter führen. Ein dienstübergreifender Identitätswechsel kann auftreten, wenn ein Dienst (der Anruf-Dienst) einen anderen Dienst anruft (den aufgerufenen Dienst). 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 mit Dienstprinzipalen schützen können, denen Zugriff auf Ressourcen in Ihrem Konto gewährt wurde.

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.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "ConfusedDeputyPreventionExamplePolicy",
    "Effect": "Allow",
    "Principal": {
      "Service": "iotdeviceadvisor.amazonaws.com"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "ArnLike": {
        "aws:SourceArn": "arn:aws:iotdeviceadvisor:us-east-1:123456789012:suitedefinition/ygp6rxa3tzvn"
      },
      "StringEquals": {
        "aws:SourceAccount": "123456789012"
      }
    }
  }
}