IoT Hub でのトランスポート層セキュリティ (TLS) のサポート

[アーティクル]
01/14/2025

IoT Hub は、トランスポート層セキュリティ (TLS) を使用して、IoT デバイスとサービスからの接続をセキュリティで保護します。

Note

Azure サービス全体での TLS 1.0 および 1.1 の廃止に関する発表に合わせて、Azure IoT Hub では、2025 年 8 月 31 日をもって TLS 1.0 および 1.1 のサポートを終了します。

したがって、"すべて" の IoT デバイスおよびサービスが、TLS 1.2 および推奨される暗号と互換性があることを、事前に適切にテストし、検証する必要があります。テストとコンプライアンスのメカニズムとして、最小限の TLS 適用機能を使用することを強くお勧めします

IoT Hub デバイスで実行されている TLS のバージョンを確認するには、このガイドの「IoT Hub デバイスの TLS バージョンの確認」を参照してください。

相互 TLS のサポート

相互 TLS 認証では、クライアントでサーバー (IoT Hub) 証明書を "認証" し、サーバー (IoT Hub) で X.509 クライアント証明書または X.509 拇印を使用してクライアントを "認証" する必要があります。 "認証" が完了すると、IoT Hub によって "認可" が実行されます。

Advanced Message Queuing Protocol (AMQP) および Message Queuing Telemetry Transport (MQTT) プロトコルの場合、IoT Hub は最初の TLS ハンドシェイクでクライアント証明書を要求します。クライアント証明書が提供されると、IoT Hub はそれを "認証" し、クライアントは IoT Hub 証明書を "認証" します。このプロセスを相互 TLS 認証と呼ばれています。 IoT Hub が MQTT 接続パケットを受信するか、AMQP リンクが開くと、IoT Hub は要求元クライアントのための "権限付与" を実行し、クライアントに X.509 認証が必要か判断します。相互 TLS 認証が完了し、クライアントに対して、デバイスとして接続することが認可されると、接続が許可されます。ただし、クライアントが X.509 認証を必要としており、TLS ハンドシェイク中にクライアント認証が完了しなかった場合、IoT Hub は接続を拒否します。

HTTP プロトコルの場合、クライアントが最初の要求を行うと、IoT Hub はクライアントが X.509 認証を必要とするか確認し、クライアント認証が完了していた場合、IoT Hub は権限を付与します。クライアント認証が完了しなかった場合、IoT Hub は接続を拒否します

TLS ハンドシェイクに成功すると、IoT Hub では、対称キーか X.509 証明書を利用してデバイスを認証できます。証明書ベースの認証の場合、IoT Hub では、指定した拇印または認証機関 (CA) に対して証明書を検証します。詳細については、「サポートされている X.509 証明書」をご覧ください。

IoT Hub のサーバー TLS 証明書

TLS ハンドシェイク中には、IoT Hub から RSA キー付きサーバー証明書が接続元のクライアントに提示されます。グローバル Azure クラウド内のすべての IoT ハブでは、DigiCert Global Root G2 によって発行された TLS 証明書が使用されます。

すべてのデバイスで、次の 3 つのルート CA を信頼することを強くお勧めします。

DigiCert Global G2 ルート CA
Microsoft RSA ルート CA 2017

これらの証明書をダウンロードするためのリンクについては、「Azure 証明機関の詳細」を参照してください。

ルート CA の移行はまれにしか行われません。ルート CA が侵害され、緊急のルート CA 移行が必要になる事態はほとんど発生しませんが、その場合に備えて、IoT ソリューションを常に準備しておく必要があります。

暗号スイート

安全な接続のための Azure セキュリティポリシーに準拠するために、IoT Hub では、TLS 1.2 用に次の RSA および ECDSA 暗号スイートがサポートされています。

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

現在、IoT Hub で許可されている暗号スイートは次のとおりです。ただし、これらの暗号スイートは、Azure セキュリティガイドラインでは推奨されなくなりました。

暗号スイート	TLS バージョンのサポート
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256	TLS 1.2
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384	TLS 1.2
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256	TLS 1.2
TLS_RSA_WITH_AES_256_GCM_SHA384	TLS 1.2
TLS_RSA_WITH_AES_128_GCM_SHA256	TLS 1.2
TLS_RSA_WITH_AES_256_CBC_SHA256	TLS 1.2
TLS_RSA_WITH_AES_128_CBC_SHA256	TLS 1.2
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA	TLS 1.0/1.1/1.2
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA	TLS 1.0/1.1/1.2
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA	TLS 1.0/1.1/1.2
TLS_RSA_WITH_3DES_EDE_CBC_SHA	TLS 1.0/1.1/1.2
TLS_RSA_WITH_3DES_EDE_CBC_SHA	TLS 1.0/1.1/1.2
TLS_RSA_WITH_AES_128_CBC_SHA	TLS 1.0/1.1/1.2
TLS_RSA_WITH_AES_256_CBC_SHA	TLS 1.0/1.1/1.2

クライアントからは、ClientHello の間、上位の暗号スイートの一覧を提案できます。ただし、IoT Hub ではサポートされないものもあります (ECDHE-ECDSA-AES256-GCM-SHA384 など)。その場合、IoT Hub はクライアントの設定に従おうとしますが、最終的には ServerHello と暗号スイートをネゴシエートします。

TLS 1.2 と強力な暗号スイートを使用するように IoT Hub を強制する

IoT デバイスの TLS 1.2 および強力な暗号スイートへのコンプライアンスを確保するために、Azure IoT Hub の最小限の TLS 適用機能を使用してコンプライアンスを強制できます。

現在、この機能は、次のリージョンで IoT Hub の作成時にのみ使用できます (他の Azure リージョンは、2025 年にサポートされる予定です)。

米国東部
米国中南部
米国西部 2
US Gov アリゾナ
US Gov バージニア (TLS 1.0/1.1 のサポートはこのリージョンでは利用できません - TLS 1.2 の強制を有効にする必要があります。そうしないと、IoT ハブの作成は失敗します)

Azure portal で TLS 1.2 と強力な暗号スイートの強制を有効にするには、次の手順を実行します。

Azure portal で IoT Hub の作成ウィザードを開始します
前述の一覧からリージョンを選択します。
[管理] -> [詳細設定] -> [トランスポート層セキュリティ (TLS)] -> [TLS の最小バージョン] で、1.2 を選択します。この設定は、サポートされているリージョンで作成された IoT ハブにのみ表示されます。
[作成] をクリックします。
IoT デバイスをこの IoT Hub に接続します

ARM テンプレートを使用して作成するには、サポートされているリージョンのいずれかに新しい IoT ハブをプロビジョニングし、次のリソース仕様で minTlsVersion プロパティを 1.2 に設定します。

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.Devices/IotHubs",
            "apiVersion": "2020-01-01",
            "name": "<provide-a-valid-resource-name>",
            "location": "<any-of-supported-regions-below>",
            "properties": {
                "minTlsVersion": "1.2"
            },
            "sku": {
                "name": "<your-hubs-SKU-name>",
                "tier": "<your-hubs-SKU-tier>",
                "capacity": 1
            }
        }
    ]
}

この構成を使用して作成された IoT Hub リソースは、TLS バージョン 1.0 および 1.1 を使用して接続を試みるデバイスとサービスクライアントを拒否します。同様に、ClientHello メッセージに推奨される暗号が示されていない場合、TLS ハンドシェイクは拒否されます。

Note

minTlsVersion プロパティは読み取り専用であり、IoT Hub リソースを作成した後に変更することはできません。したがって、"すべて" の IoT デバイスおよびサービスが、TLS 1.2 および推奨される暗号と互換性があることを、事前に適切にテストし、検証する必要があります。

フェールオーバーが発生した場合、IoT Hub の minTlsVersion プロパティは、フェールオーバー後も geo ペアリージョンで有効なままです。

IoT Hub デバイスの TLS バージョンの確認

Azure IoT Hub は、Azure Monitor ログを使用して分析できる複数のカテゴリの診断ログを提供できます。 IoT Hub デバイスの TLS バージョンは、接続ログで確認できます。

これらのログを表示するには、次の手順を実行します。

Azure portal で IoT Hub に移動します。
リソースメニューの [監視] で、[診断設定] を選択します。診断設定で、[接続] のチェックマークがオンになっていることを確認します。
リソースメニューの [監視] で、[ログ] を選択します。
次のクエリを入力します。

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DEVICES" and ResourceType == "IOTHUBS"
| where Category == "Connections"
| where OperationName == "deviceConnect"
| extend props_json = parse_json(properties_s)
| project DeviceId = props_json.deviceId, TLSVersion = props_json.tlsVersion

クエリ結果の例は、次のようになります。
注: TLS バージョンのクエリは、HTTPS 接続を使用しているデバイスに対して使用することはできません。

SDK および IoT Edge 用の TLS 構成

次のリンクを使用して、IoT Hub クライアント SDK で TLS 1.2 および許可されている暗号を構成します。

Language	TLS 1.2 をサポートするバージョン	ドキュメント
C	タグ 2019-12-11 以降	リンク
Python	バージョン 2.0.0 以降	リンク
C#	バージョン 1.21.4 以降	リンク
Java	バージョン 1.19.0 以降	リンク
NodeJS	バージョン 1.12.2 以降	リンク

IoT Edge デバイスは、IoT Hub との通信時に TLS 1.2 を使用するように構成できます。このためには、IoT Edge ドキュメントページを使用してください。

楕円曲線暗号 (ECC) サーバー TLS 証明書

ECC 証明書の検証 (ECC のみの暗号スイートを使用) を使用すると、RSA 証明書と同様のセキュリティが提供されると同時に、コンピューティング、メモリ、および帯域幅の使用が最大 40% 削減されます。このような削減は、IoT デバイスにとって重要です。そのプロファイルおよびメモリのサイズが小さくなるためであり、ネットワーク帯域幅が制限された環境でのユースケースに対応することができます。

IoT Hub の ECC サーバー証明書を使用するには、次の手順を実行します。

すべてのデバイスで、次のルート CA が信頼されていることを確認します。
- DigiCert Global G2 ルート CA
- Microsoft RSA ルート CA 2017
ECDSA の暗号スイート "のみ" を含め、RSA のものについてはいずれも "除外" するように、クライアントを構成してください。 ECC 証明書でサポートされている暗号スイートは、次のとおりです。
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
クライアントを IoT Hub に接続します。

TLS 最大フラグメント長ネゴシエーション

IoT Hub では、TLS 最大フラグメント長ネゴシエーションもサポートされています。これは、TLS フレームサイズネゴシエーションと呼ばれることもあります。この機能はパブリックプレビュー段階にあります。

この機能を使用すると、プレーンテキストの最大フラグメント長を、既定の 2^14 バイトより小さい値に指定できます。ネゴシエートされると、IoT Hub とクライアントによってメッセージのフラグメント化が開始され、すべてのフラグメントがネゴシエートされた長さよりも確実に小さくなります。この動作は、コンピューティングまたはメモリに制約があるデバイスに役立ちます。詳細については、公式の TLS 拡張機能仕様を参照してください。

このパブリックプレビュー機能の公式 SDK サポートはまだ利用できません。開始するには

IoT Hub を作成します。
OpenSSL を使用する場合は、SSL_CTX_set_tlsext_max_fragment_length を呼び出して、フラグメントのサイズを指定します。
クライアントを IoT Hub に接続します。

証明書のピン留め

IoT Hub エンドポイントに関連付けられた TLS サーバー証明書および中間証明書は、Microsoft がほとんどまたはまったく予告なしに頻繁に切り替えるため、これらの証明書のピン留めやフィルター処理を行わないことを強くお勧めします。必要な場合は、この Azure IoT ブログ記事の説明に従ってルート証明書のみをピン留めしてください。

次のステップ

IoT Hub のセキュリティおよびアクセス制御の詳細については、「IoT Hub へのアクセスの制御」を参照してください。
デバイス認証に X509 証明書を使用する方法の詳細については、「X.509 CA 証明書を使用したデバイス認証」を参照してください。

次の方法で共有