Steuern des Zugriffs auf IoT Hub mithilfe von Shared Access Signatures

In diesem Artikel werden die Optionen zum Sichern Ihres IoT Hubs beschrieben. IoT Hub verwendet Berechtigungen, um Zugriff auf den Endpunkt jedes IoT Hubs zu gewähren. Berechtigungen beschränkten den Zugriff auf einen IoT Hub basierend auf der Funktionalität.

Dieser Artikel bietet eine Einführung zu Folgendem:

  • Die verschiedenen Berechtigungen, die Sie einem Client für den Zugriff auf Ihren IoT Hub gewähren können.
  • Die von IoT Hub verwendeten Token zum Überprüfen von Berechtigungen.
  • Festlegen des Geltungsbereichs für Anmeldeinformationen zum Begrenzen des Zugriffs auf bestimmte Ressourcen.
  • Benutzerdefinierte Authentifizierungsmechanismen, die auf vorhandene Geräteidentitätsregistrierungen Authentifizierungsschemas zurückgreifen.

Hinweis

Einige der in diesem Artikel erwähnten Features (wie Cloud-zu-Gerät-Messaging, Gerätezwillinge und Geräteverwaltung) stehen nur im Standard-Tarif von IoT Hub zur Verfügung. Weitere Informationen zu den IoT Hub-Tarifen „Basic“ und „Standard“ finden Sie unter Wählen des passenden IoT Hub-Tarifs für Ihre Lösung.

Sie müssen über Berechtigungen für den Zugriff auf IoT Hub-Endpunkte verfügen. Beispielsweise muss ein Gerät ein Token mit den Anmeldeinformationen zusammen mit jeder an IoT Hub gesendeten Nachricht enthalten. Die Signaturschlüssel, wie die symmetrischen Schlüssel des Geräts, werden jedoch nie übertragen.

Access Control und Berechtigungen

Verwenden Sie Richtlinien für den gemeinsamen Zugriff für den Zugriff auf IoT Hub-Ebene, und verwenden Sie die Anmeldeinformationen der einzelnen Geräte, um den Zugriff nur auf dieses Gerät zu beschränken.

Richtlinien für den gemeinsamen Zugriff auf IoT Hub-Ebene

SAS-Richtlinien können eine beliebige Kombination von Berechtigungen gewähren. Sie können Richtlinien im Azure-Portal programmgesteuert mithilfe von IoT Hub-Ressourcenanbieter-REST-APIs oder mit dem CLI-Befehl az iot hub policy definieren. Ein neu erstellter IoT Hub verfügt über die folgenden Standardrichtlinien:

SAS-Richtlinie Berechtigungen
iothubowner Alle Berechtigungen
Dienst ServiceConnect-Berechtigung
device DeviceConnect-Berechtigung
registryRead RegistryRead-Berechtigung
registryReadWrite RegistryReadWrite- und RegistryWrite-Berechtigungen

In der folgenden Tabelle werden die Berechtigungen aufgeführt, die Sie zum Steuern des Zugriffs auf den IoT Hub verwenden können.

Berechtigung Notizen
ServiceConnect Diese Berechtigung gewährt Zugriff auf die clouddienstseitigen Endpunkte für Kommunikation und Überwachung.
Clouddiensten wird die Berechtigung erteilt, D2C-Nachrichten zu empfangen, C2D-Nachrichten zu senden und die zugehörigen Übermittlungsbestätigungen zu empfangen.
Erteilt die Berechtigung zum Abrufen der Übermittlungsbestätigungen für Dateiuploads.
Gewährt die Berechtigung zum Zugriff auf Zwillinge zum Aktualisieren von Tags und gewünschten Eigenschaften, zum Abrufen gemeldeter Eigenschaften und zum Ausführen von Abfragen.
Diese Berechtigung wird von Back-End Cloud Services verwendet.
DeviceConnect Diese Berechtigung gewährt Zugriff auf die geräteseitigen Endpunkte.
Gewährt die Berechtigung zum Senden von D2C-Nachrichten und zum Empfangen von C2D-Nachrichten.
Gewährt die Berechtigung zum Ausführen eines Dateiupload von einem Gerät.
Gewährt die Berechtigung zum Abrufen von gewünschten Eigenschaftsbenachrichtigungen für Gerätezwillinge und zum Aktualisieren von gemeldeten Eigenschaften.
Gewährt die Berechtigung zum Ausführen eines Dateiupload.
Diese Berechtigung wird von Geräten verwendet.
RegistryRead Diese Berechtigung gewährt Lesezugriff auf die Identitätsregistrierung. Weitere Informationen finden Sie unter Identitätsregistrierung.
Diese Berechtigung wird von Back-End Cloud Services verwendet.
RegistryReadWrite Diese Berechtigung gewährt Lese- und Schreibzugriff auf die Identitätsregistrierung. Weitere Informationen finden Sie unter Identitätsregistrierung.
Diese Berechtigung wird von Back-End Cloud Services verwendet.

Sicherheitsanmeldeinformationen auf Gerätebasis

Jeder IoT Hub enthält eine Identitätsregistrierung. Sie können für jedes Gerät in dieser Identitätsregistrierung Sicherheitsanmeldeinformationen konfigurieren, die DeviceConnect-Berechtigungen erteilen, deren Gültigkeitsbereich auf die entsprechenden Geräteendpunkte festgelegt ist.

SAS-Token

IoT Hub verwendet Shared Access Signature (SAS)-Token zum Authentifizieren von Geräten und Diensten, um das Senden von Schlüsseln über das Netzwerk zu vermeiden. SAS-Token sind im Hinblick auf Gültigkeitszeitraum und Bereich beschränkt. Azure IoT SDKs generieren Token automatisch, ohne dass eine spezielle Konfiguration erforderlich ist. In einigen Szenarien müssen Sie SAS-Token allerdings direkt generieren und verwenden. Zu diesen Szenarien zählen:

Sie verwenden SAS-Token, um zeitlich begrenzten Zugriff auf Geräte und Dienste für bestimmte Funktionen in IoT Hub zu gewähren. Zur Autorisierung der Verbindungsherstellung mit IoT Hub müssen Geräte und Dienste SAS-Token senden, die entweder mit einem freigegebenen Zugriffsschlüssel oder mit einem symmetrischen Schlüssel signiert sind. Symmetrische Schlüssel werden mit einer Geräteidentität in der Identitätsregistrierung gespeichert.

SAS-Tokenstruktur

Ein mit einem Schlüssel für den gemeinsamen Zugriff signiertes Token gewährt Zugriff auf alle Funktionen, die den SAS-Richtlinienberechtigungen zugeordnet sind. Ein Token, das mit einem symmetrischen Schlüssel der Geräteidentität signiert ist, erteilt nur die Berechtigung DeviceConnect für die zugeordnete Geräteidentität.

Ein SAS-Token weist das folgende Format auf:

SharedAccessSignature sig={signature-string}&se={expiry}&skn={policyName}&sr={URL-encoded-resourceURI}

Hier sind die erwarteten Werte:

Wert BESCHREIBUNG
{signature} Eine HMAC-SHA256-Signaturzeichenfolge in folgendem Format: {URL-encoded-resourceURI} + "\n" + expiry. Wichtig: Der Schlüssel wird aus Base64 decodiert und als Schlüssel für die HMAC-SHA256-Berechnung verwendet.
{resourceURI} Das URI-Präfix (nach Segment) der Endpunkte, auf die mit diesem Token zugegriffen werden kann – beginnend mit dem Hostnamen des IoT Hubs (kein Protokoll). SAS-Token, die den Back-End-Diensten zugewiesen werden, werden auf IoT-Hubebene angewendet; zum Beispiel: myHub.azure-devices.net. SAS-Token, die Geräten gewährt werden, müssen auf ein einzelnes Gerät angewendet werden; zum Beispiel: myHub.azure-devices.net/devices/device1.
{expiry} UTF8-Zeichenfolge, dargestellt als die Anzahl von Sekunden seit dem 1. Januar 1970 um 00:00:00 UTC.
{URL-encoded-resourceURI} URL-Codierung des Ressourcen-URI (beides in Kleinbuchstaben)
{policyName} Der Name der gemeinsam genutzten Zugriffsrichtlinie, auf die dieses Token verweist. Nicht vorhanden, wenn das Token auf Geräteregistrierungs-Anmeldeinformationen verweist.

Das URI-Präfix wird nach Segment, nicht nach Zeichen berechnet. Beispielsweise ist /a/b ein Präfix für /a/b/c, aber nicht für /a/bc.

Der folgende Code generiert ein SAS-Token mithilfe des Ressourcen-URI, dem Signaturschlüssel, des Richtliniennamens und des Ablaufzeitraums. In den nächsten Abschnitten wird erläutert, wie die verschiedenen Eingaben für die verschiedenen Anwendungsfälle für Token initialisiert werden.

var generateSasToken = function(resourceUri, signingKey, policyName, expiresInMins) {
    resourceUri = encodeURIComponent(resourceUri);

    // Set expiration in seconds
    var expires = (Date.now() / 1000) + expiresInMins * 60;
    expires = Math.ceil(expires);
    var toSign = resourceUri + '\n' + expires;

    // Use crypto
    var hmac = crypto.createHmac('sha256', Buffer.from(signingKey, 'base64'));
    hmac.update(toSign);
    var base64UriEncoded = encodeURIComponent(hmac.digest('base64'));

    // Construct authorization string
    var token = "SharedAccessSignature sr=" + resourceUri + "&sig="
    + base64UriEncoded + "&se=" + expires;
    if (policyName) token += "&skn="+policyName;
    return token;
};

Protokolldetails

Jedes unterstützte Protokoll, z.B. MQTT, AMQP und HTTPS, transportiert Tokens auf unterschiedliche Weise.

Bei Verwendung von MQTT weist das CONNECT-Paket die Geräte-ID als Client-ID, {iothubhostname}/{deviceId} im Feld „Benutzername“ und ein SAS-Token im Feld „Kennwort“ auf. {iothubhostname} sollte der vollständige CNAME des IoT Hubs (z.B. „contoso.azure-devices.net“) sein.

Bei Verwendung von AMQP unterstützt IoT Hub SASL PLAIN und die auf AMQP-Ansprüchen basierte Sicherheit.

Wenn Sie eine auf AMQP-Ansprüchen beruhende Sicherheit verwenden, gibt der Standard vor, wie die oben aufgeführten Token übertragen werden.

Für SASL PLAIN kann der Benutzername Folgendes sein:

  • {policyName}@sas.root.{iothubName}, wenn Token auf IoT Hub-Ebene verwendet werden.
  • {deviceId}@sas.{iothubname}, wenn Token für Geräte verwendet werden.

In beiden Fällen enthält das Kennwortfeld das Token gemäß der Beschreibung unter IoT Hub-SAS-Token.

HTTPS implementiert die Authentifizierung, indem ein gültiges Token in den Anforderungsheader Authorization eingeschlossen wird.

Beispiel: Benutzername (bei der Geräte-ID wird Groß-/Kleinschreibung berücksichtigt): iothubname.azure-devices.net/DeviceId

Kennwort (Sie können ein SAS-Token mit dem CLI-Erweiterungsbefehl az iot hub generate-sas-token oder den Azure IoT Tools für Visual Studio Code generieren):

SharedAccessSignature sr=iothubname.azure-devices.net%2fdevices%2fDeviceId&sig=kPszxZZZZZZZZZZZZZZZZZAhLT%2bV7o%3d&se=1487709501

Hinweis

Die Azure IoT SDKs generieren automatisch Token, wenn eine Verbindung mit dem Dienst hergestellt wird. In einigen Fällen unterstützen die Azure IoT SDKs nicht alle Protokolle oder Authentifizierungsmethoden.

Besonderheiten für SASL PLAIN

Bei Verwendung von SASL PLAIN mit AMQP kann ein Client, der eine Verbindung mit einem IoT Hub herstellt, ein einziges Token für jede TCP-Verbindung verwenden. Wenn das Token abläuft, wird die TCP-Verbindung mit dem Dienst getrennt, und es wird ein Versuch zur erneuten Verbindungsherstellung ausgelöst. Dieses Verhalten ist für eine Back-End-App unproblematisch, für eine Geräte-App jedoch schädlich. Dies hat folgende Gründe:

  • Gateways stellen eine Verbindung üblicherweise für eine Vielzahl von Geräten her. Bei Verwendung von SASL PLAIN muss für jedes Gerät, das eine Verbindung mit einem IoT Hub herstellen möchte, eine eigene TCP-Verbindung erstellt werden. Bei diesem Szenario erhöht sich der Verbrauch von Rechen- und Netzwerkressourcen erheblich, und es kommt zu einer höheren Latenz für jede Geräteverbindung.

  • Der erhöhte Ressourcenverbrauch bei der erneuten Verbindungsherstellung nach jedem Tokenablauf wirkt sich negativ auf Geräte mit Ressourceneinschränkungen aus.

Verwenden von SAS-Token aus Diensten

Dienste können SAS-Token mithilfe einer freigegebenen Zugriffsrichtlinie generieren, die die entsprechenden Berechtigungen definiert, wie zuvor in Zugriffssteuerung und -berechtigungen erläutert.

Beispielsweise würde ein Dienst mithilfe der vorab erstellte SAS-Richtlinie mit dem Namen registryRead, ein Token mit den folgenden Parametern erstellen:

  • Ressourcen-URI: {IoT hub name}.azure-devices.net
  • Signaturschlüssel: einer der Schlüssel der registryRead -Richtlinie
  • Richtlinienname: registryRead
  • Eine Ablaufzeit
var endpoint = "myhub.azure-devices.net";
var policyName = 'registryRead';
var policyKey = '...';

var token = generateSasToken(endpoint, policyKey, policyName, 60);

Das Ergebnis, das Lesezugriff für alle Geräteidentitäten gewähren würde, wäre:

SharedAccessSignature sr=myhub.azure-devices.net&sig=JdyscqTpXdEJs49elIUCcohw2DlFDR3zfH5KqGJo4r4%3D&se=1456973447&skn=registryRead

Für Dienste gewähren SAS-Token nur Berechtigungen auf IoT Hub-Ebene. Das heißt, ein Dienst, der mit einem Token basierend auf der Dienstrichtlinie authentifiziert wird, kann alle Vorgänge ausführen, die von der ServiceConnect-Berechtigung gewährt werden. Diese Vorgänge umfassen den Empfang von Geräte-zu-Cloud-Nachrichten, das Senden von Cloud-zu-Gerät-Nachrichten, usw. Wenn Sie ihren Diensten einen genaueren Zugriff gewähren möchten, z. B. durch Beschränken eines Dienstes nur auf das Senden von Cloud-zu-Gerät-Nachrichten, können Sie Azure Active Directory verwenden. Weitere Informationen finden Sie unter Steuern des Zugriffs auf IoT Hub mit Azure AD.

Authentifizieren eines Geräts für IoT Hub

Unterstützte X.509-Zertifikate

Sie können ein X.509-Zertifikat verwenden, um ein Gerät bei IoT Hub zu authentifizieren. Laden Sie hierzu entweder einen Zertifikatfingerabdruck oder eine Zertifizierungsstelle (Certificate Authority, CA) in Azure IoT Hub hoch. Weitere Informationen finden Sie unter Geräteauthentifizierung mit X.509-Zertifikaten. Informationen zum Hochladen und Überprüfen einer Zertifizierungsstelle bei Ihrem IoT Hub finden Sie unter Einrichten der X.509-Sicherheit in Ihrem Azure IoT Hub.

Erzwingen der X.509-Authentifizierung

Zur Erhöhung der Sicherheit kann ein IoT Hub so konfiguriert werden, dass die SAS-Authentifizierung für Geräte und Module nicht zugelassen ist, sodass X.509 die einzige akzeptierte Authentifizierungsoption bleibt. Dieses Feature steht im Azure-Portal zurzeit nicht zur Verfügung. Um es zu konfigurieren, legen Sie in den IoT Hub-Ressourceneigenschaften disableDeviceSAS und disableModuleSAS auf true fest:

az resource update -n <iothubName> -g <resourceGroupName> --resource-type Microsoft.Devices/IotHubs --set properties.disableDeviceSAS=true properties.disableModuleSAS=true

Verwenden von SAS-Token als Gerät

Es gibt zwei Methoden zum Abrufen von DeviceConnect-Berechtigungen mit IoT Hub über SAS-Token: mit einem symmetrischen Identitätsschlüssel aus der Identitätsregistrierung oder mit einem Schlüssel für den gemeinsamen Zugriff.

Denken Sie daran, dass alle Funktionen, auf die auf Geräten zugegriffen werden kann, für Endpunkte mit dem Präfix /devices/{deviceId} absichtlich verfügbar gemacht werden.

Die geräteseitigen Endpunkte sind (unabhängig vom Protokoll):

Endpunkt Funktionalität
{iot hub host name}/devices/{deviceId}/messages/events Senden von Gerät-an-Cloud-Nachrichten.
{iot hub host name}/devices/{deviceId}/messages/devicebound Empfangen von Cloud-an-Gerät-Nachrichten.

Verwenden eines symmetrischen Schlüssels in der Identitätsregistrierung

Wenn Sie den symmetrischen Schlüssel einer Geräteidentität zum Generieren eines Tokens verwenden, wird das policyName-Element (skn) des Tokens nicht angegeben.

Beispielsweise muss ein Token, das für den Zugriff auf alle Gerätefunktionen erstellt wird, die folgenden Parameter aufweisen:

  • Ressourcen-URI: {IoT hub name}.azure-devices.net/devices/{device id}
  • Signaturschlüssel: ein symmetrischer Schlüssel für die {device id} -Identität
  • Kein Richtlinienname
  • Eine Ablaufzeit

Ein Beispiel mit der oben genannten Node.js-Funktion:

var endpoint ="myhub.azure-devices.net/devices/device1";
var deviceKey ="...";

var token = generateSasToken(endpoint, deviceKey, null, 60);

Das Ergebnis, das Zugriff auf alle Funktionen für „device1“ gewährt wird, wäre:

SharedAccessSignature sr=myhub.azure-devices.net%2fdevices%2fdevice1&sig=13y8ejUk2z7PLmvtwR5RqlGBOVwiq7rQR3WZ5xZX3N4%3D&se=1456971697

Hinweis

Sie können ein SAS-Token mit dem CLI-Erweiterungsbefehl az iot hub generate-sas-token oder den Azure IoT Tools für Visual Studio Code generieren.

Verwenden einer SAS-Richtlinie für den Zugriff im Auftrag eines Geräts

Wenn Sie ein Token auf der Grundlage einer SAS-Richtlinie erstellen, legen Sie das Feld skn auf den Namen der Richtlinie fest. Diese Richtlinie muss die Berechtigung DeviceConnect erteilen.

Die beiden wichtigsten Szenarien für die Verwendung von SAS-Richtlinien für den Zugriff auf Gerätefunktionen sind:

Da die SAS-Richtlinie potenziell Zugriff gewähren kann, um als ein beliebiges Gerät eine Verbindung herzustellen, ist es wichtig, beim Erstellen von SAS-Token den richtigen Ressourcen-URI zu verwenden. Diese Einstellung ist besonders wichtig für Tokendienste, die das Token mit dem Ressourcen-URI auf ein bestimmtes Gerät festlegen müssen. Dieser Punkt ist weniger relevant für Protokollgateways, da sie Datenverkehr bereits für alle Geräte vermitteln.

Beispielsweise würde ein Tokendienst, der die vorab erstellte SAS-Richtlinie mit dem Namen device verwendet, ein Token mit den folgenden Parametern erstellen:

  • Ressourcen-URI: {IoT hub name}.azure-devices.net/devices/{device id}
  • Signaturschlüssel: einer der Schlüssel der device -Richtlinie
  • Richtlinienname: device
  • Eine Ablaufzeit

Ein Beispiel mit der oben genannten Node.js-Funktion:

var endpoint ="myhub.azure-devices.net/devices/device1";
var policyName = 'device';
var policyKey = '...';

var token = generateSasToken(endpoint, policyKey, policyName, 60);

Das Ergebnis, das Zugriff auf alle Funktionen für „device1“ gewährt wird, wäre:

SharedAccessSignature sr=myhub.azure-devices.net%2fdevices%2fdevice1&sig=13y8ejUk2z7PLmvtwR5RqlGBOVwiq7rQR3WZ5xZX3N4%3D&se=1456971697&skn=device

Ein Protokollgateway könnte das gleiche Token für alle Geräte verwenden, indem einfach der Ressourcen-URI auf myhub.azure-devices.net/devicesfestgelegt wird.

Erstellen eines Tokendiensts zum Integrieren vorhandener Geräte

Mit der Identitätsregistrierung von IoT Hub können Sie Sicherheitsanmeldeinformationen und die Zugriffssteuerung pro Gerät/Modul mithilfe von Token konfigurieren. Wenn eine IoT-Lösung bereits über eine benutzerdefinierte Identitätsregistrierung und/oder über ein Authentifizierungsschema verfügt, können Sie diese Infrastruktur durch Erstellen eines Tokendiensts in IoT Hub integrieren. Auf diese Weise können Sie andere IoT-Features in der Lösung nutzen.

Ein Tokendienst ist ein benutzerdefinierter Clouddienst. Er verwendet eine SAS-Richtlinie von IoT Hub mit der Berechtigung DeviceConnect, um Token für den Gerätebereich oder Modulbereich zu erstellen. Mit diesen Token kann ein Gerät oder ein Modul eine Verbindung mit Ihrer IoT Hub-Instanz herstellen.

Schritte des Tokendienstmusters

Hier sind die wichtigsten Schritte des Tokendienstmusters:

  1. Erstellen Sie eine IoT Hub-SAS-Richtlinie mit der Berechtigung DeviceConnect für Ihren IoT-Hub. Sie können diese Richtlinie im Azure-Portal oder programmgesteuert erstellen. Diese Richtlinie wird vom Tokendienst zum Signieren der von ihm erstellten Token verwendet.

  2. Wenn ein Gerät/Modul auf IoT Hub zugreifen muss, fordert es von Ihrem Tokendienst ein signiertes Token an. Das Gerät kann mit Ihrer benutzerdefinierten Identitätsregistrierung bzw. mit dem Authentifizierungsschema authentifiziert werden, um die Geräte- oder Modulidentität zu ermitteln, die der Tokendienst zum Erstellen des Tokens verwendet.

  3. Der Tokendienst gibt ein Token zurück. Das Token wird mit /devices/{deviceId} oder /devices/{deviceId}/module/{moduleId} als resourceURI erstellt, wobei deviceId das authentifizierte Gerät bzw. moduleId das authentifizierte Modul ist. Der Tokendienst verwendet die SAS-Richtlinie, um das Token zu erstellen.

  4. Das Gerät/Modul nutzt das Token direkt mit IoT Hub.

Hinweis

Sie können die .NET-Klasse SharedAccessSignatureBuilder oder die Java-Klasse IotHubServiceSasToken zum Erstellen eines Tokens im Tokendienst verwenden.

Der Tokendienst kann die Gültigkeitsdauer für das Token wie gewünscht festlegen. Wenn das Token abläuft, trennt IoT Hub die Geräte-/Modulverbindung. Das Gerät/Modul muss dann ein neues Token vom Tokendienst anfordern. Eine kurze Ablaufzeit erhöht die Last für das Gerät/Modul und den Tokendienst gleichermaßen.

Damit ein Gerät/Modul eine Verbindung mit Ihrem Hub herstellen kann, müssen Sie es der IoT Hub-Identitätsregistrierung hinzufügen – auch wenn es für die Verbindung ein Token und keinen Schlüssel verwendet. Aus diesem Grund können Sie weiterhin die geräte-/modulspezifische Zugriffssteuerung nutzen, indem Sie Geräte-/Modulidentitäten in der Identitätsregistrierung aktivieren oder deaktivieren. Dieser Ansatz verringert die Risiken der Verwendung von Token mit langen Ablaufzeiten.

Vergleich mit einem benutzerdefinierten Gateway

Das Tokendienstmuster ist der empfohlene Weg zur Implementierung einer benutzerdefinierten Identitätsregistrierung bzw. eines Authentifizierungsschemas mit IoT Hub. Dieses Muster wird empfohlen, da der größte Teil des Lösungsdatenverkehrs weiterhin über IoT Hub abgewickelt wird. Wenn das benutzerdefinierte Authentifizierungsschema allerdings so eng mit dem Protokoll verknüpft ist, muss der gesamte Datenverkehr unter Umständen durch ein benutzerdefiniertes Gateway verarbeitet werden. Ein Beispiel eines solchen Szenarios ist die Verwendung von Transport Layer Security (TLS) und vorinstallierten Schlüsseln (PSKs). Weitere Informationen finden Sie unter Verwendung eines IoT Edge-Geräts als Gateway.

Weiteres Referenzmaterial

Weitere Referenzthemen im IoT Hub-Entwicklerhandbuch:

Nächste Schritte

Nachdem Sie gelernt haben, wie Sie den Zugriff auf IoT Hub steuern, sind möglicherweise die folgenden Themen im IoT Hub-Entwicklerhandbuch für Sie interessant:

Wenn Sie einige der in diesem Artikel beschriebenen Konzepte ausprobieren möchten, sehen Sie sich die folgenden IoT Hub-Tutorials an: