X.509 証明書を使用して ID を認証する
IoT Hub は、X.509 証明書を使ってデバイスの認証を行います。 X.509 認証では、トランスポート層セキュリティ (TLS) 標準接続の確立の一部として IoT デバイスを認証できます。
X.509 認証局 (CA) 証明書は、その他の証明書に署名できるデジタル証明書です。 デジタル証明書は、IETF の RFC 5280 標準で規定されている証明書形式の標準に準拠している場合、X.509 証明書と見なされます。
X.509 CA 機能により、証明機関 (CA) を使用して IoT Hub に対してデバイスを認証できます。 これにより、初回のデバイス登録プロセスとデバイス製造時のサプライチェーン ロジスティックスが簡素化されます。
認証と権限承認
"認証" は、ユーザーが身元を証明するプロセスです。 認証は、IoT Hub に対するユーザーまたはデバイスの ID を検証します。 AuthN と短縮される場合があります。
認可は、IoT Hub で認証されたユーザーまたはデバイスのアクセス許可を確定するプロセスです。 これにより、ユーザーがアクセスすることを許可されるリソースとコマンド、およびユーザーがそれらのリソースとコマンドで実行できる操作が指定されます。 承認は AuthZ と短縮される場合があります。
X.509 証明書は、IoT Hub での認可ではなく認証のみに使われます。 Microsoft Entra ID や Shared Access Signature とは異なり、X.509 証明書によるアクセス許可はカスタマイズできません。
証明書認証の種類
証明書拇印や認証局 (CA) を IoT Hub にアップロードすることで、IoT Hub を使用したデバイスを X.509 証明書を使用して認証できます。
X.509 CA 署名済み - このオプションは、運用シナリオにお勧めで、この記事ではこれに焦点を当てています。
デバイスに CA 署名済みの X.509 証明書がある場合は、デバイスを登録する前に、署名チェーン内のルートまたは中間 CA 証明書を IoT Hub にアップロードします。 デバイスの証明書チェーンには、検証済みの X.509 CA による X.509 証明書があります。 接続時に、デバイスがその完全な証明書チェーンを提示すると、IoT ハブは X.509 CA を認識しているため、それを検証できます。 複数のデバイスが、同じ検証済み X.509 CA で認証できます。
X.509 自己署名済み
デバイスに自己署名された X.509 証明書がある場合は、認証のための証明書のバージョンを IoT Hub に提供します。 デバイスを登録するときに、証明書の "拇印" をアップロードします。これは、デバイスの X.509 証明書のハッシュです。 接続時に、デバイスがその証明書を提示すると、IoT ハブはわかっているハッシュに対してそれを検証できます。
重要
X.509 認証局 (CA) の認証を使用するデバイスの次の機能は、まだ一般提供されていません。また、プレビュー モードを有効にする必要があります。
- HTTPS、WebSocket 経由の MQTT、WebSockets プロトコル経由の AMQP。
- ファイルのアップロード (すべてのプロトコル)。
これらの機能は、X.509 拇印認証を使用するデバイスで一般提供されています。
X.509 認証を適用する
セキュリティを強化するために、デバイスとモジュールの SAS 認証を許可しないように IoT Hub を構成し、許可されている唯一の認証オプションとして X.509 を残します。 現在のところ、この機能は Azure portal では使用できません。 構成するには、IoT Hub リソース プロパティの disableDeviceSAS と disableModuleSAS を true に設定します。
az resource update -n <iothubName> -g <resourceGroupName> --resource-type Microsoft.Devices/IotHubs --set properties.disableDeviceSAS=true properties.disableModuleSAS=true
X.509 CA 証明書認証の利点
IoT では、接続するデバイスごとに一意の ID が必要になります。 証明書ベースの認証の場合、これらの ID は証明書の形式になります。
各デバイスに一意の証明書を提供する、有効ではあっても非効率的な方法は、証明書を事前に生成し、すべてのサプライ チェーン パートナーに対応する秘密キーを提供するという方法です。 この方法には、次のように、信頼を確保するために克服しなければならない課題があります。
秘密キーを共有しないという PKI のベスト プラクティスを無視するうえに、デバイスの秘密キーをサプライ チェーン パートナーと共有しなければならないことにより、サプライ チェーンにおける信頼構築はコストが高くなります。 デバイスの秘密キーを保管する安全な部屋などのシステムや、定期的なセキュリティ監査などのプロセスが必要になります。 どちらも、サプライ チェーンのコストを引き上げます。
サプライ チェーンでデバイスを安全にアカウンティングすること、その後デバイスの廃棄を介してそれらをデプロイで管理することは、すべてのキーとデバイスのペアについて一対一のタスクとなります。 このリレーションシップにより、グループの概念が何らかの形で明示的にプロセスに組み込まれていない限り、デバイスのグループ管理は除外されます。 したがって、安全なアカウンティングとデバイスのライフ サイクル管理は運用上の大きな負担になります。
X.509 CA 証明書認証は、証明書チェーンを使用することで、これらの課題を見事に解決します。 証明書チェーンは、CA が中間 CA に署名することから始まり、その中間 CA が別の中間 CA に署名し、最終の中間 CA がデバイスに署名するまで続きます。 証明書チェーンでは、CA 証明書とその下流デバイスの間に一対多リレーションシップが構築されます。 このリレーションシップにより、1 つの X.509 CA 証明書を 1 度登録するだけで、任意の数のデバイスを IoT Hub に登録できます。
また、X.509 CA 認証により、サプライ チェーンのロジスティクスも簡素化されます。 一般的なデバイス製造フローには、複数のステップと管理者が含まれています。 認証局を使用すると、各管理者にデバイスの秘密キーを委ねるのではなく、各管理者に署名して暗号の信頼チェーンを確立できます。 各管理者は、製造フローのそれぞれのステップでデバイスに署名します。 総合的な結果として、暗号の信頼チェーンの使用によりアカウンタビリティが組み込まれた最適なサプライ チェーンになります。
このプロセスによって、デバイスで一意の秘密キーが保護されている場合にセキュリティが最も強力になります。 この目的のために、秘密キーを内部で生成できるハードウェア セキュア モジュール (HSM) を使用することをお勧めします。
Azure IoT Hub Device Provisioning Service (DPS) を使用すると、デバイスのグループをハブに簡単にプロビジョニングできます。 詳細については、「チュートリアル: 登録グループを使って複数の X.509 デバイスをプロビジョニングする」を参照してください。
X.509 証明書フロー
このセクションでは、X.509 CA 証明書を使用して、IoT Hub に接続するデバイスの認証を行う方法について説明します。これには、次の手順が含まれます。
- X.509 CA 証明書を入手する。
- X.509 CA 証明書を使用してデバイスに署名する。
- X.509 CA 証明書を IoT Hub に登録する。
- X.509 CA を使用して署名されたデバイスを認証する。
- デバイス証明書が侵害された場合は取り消す。
X.509 CA 証明書を入手する
X.509 CA 証明書は、各デバイスの証明書チェーンの先頭にあります。 証明書は、使用方法に応じて、購入または作成できます。
運用環境の場合、証明書サービスの専門プロバイダーから X.509 CA 証明書を購入することをお勧めします。
テスト目的で自己署名 X.509 CA 証明書を作成することもできます。 テスト用証明書の作成方法の詳細については、「テスト用の証明書を作成してアップロードする」を参照してください。 運用環境では、自己署名証明書を使用しないことをお勧めします。
X.509 CA 証明書の入手方法に関係なく、必ずその対応する秘密キー シークレットを保存し、常に保護されている状態にしておいてください。
証明書を購入する
CA 証明書を購入することで、既知のルート CA が IoT デバイスの接続時にデバイスの正当性を保証する信頼されたサード パーティとして機能するという利点が得られます。 デバイスがオープン IoT ネットワークの一部であり、そのネットワークでデバイスがサード パーティの製品やサービスと対話する場合、このオプションを選択してください。
X.509 CA 証明書を購入するには、ルート証明書のサービス プロバイダーを選びます。 ルート CA プロバイダーにより、公開キーと秘密キーのペアの作成方法と、サービスの証明書署名要求 (CSR) の生成方法が案内されます。 CSR は、証明機関からの証明書を申請する正式なプロセスです。 この購入の結果、証明機関の証明書として使用するための証明書を取得できます。 X.509 証明書の遍在性を考慮すると、この証明書は IETF の RFC 5280 標準に合わせて適切に書式設定されている可能性があります。
自己署名証明書の作成
自己署名 X.509 CA 証明書を作成するプロセスは、X.509 CA 証明書を購入するプロセスと似ていますが、自己署名 X.509 CA 証明書を作成するプロセスでは、ルート証明機関のようなサードパーティの署名者は関与しません。
証明機関の証明書を購入する準備が整うまで、テスト目的でこのオプションを選択できます。 また、デバイスが IoT Hub の外部にあるサード パーティのサービスに接続しない場合は、運用環境で自己署名 X.509 CA 証明書を使用できます。
デバイスに署名して証明書の信頼チェーンに入れる
X.509 CA 証明書の所有者は、中間 CA に暗号で署名できます。この中間 CA は別の中間 CA に署名でき、このプロセスは、最後の中間 CA がデバイス証明書に署名するまで継続されます。 この結果、"証明書の信頼チェーン" と呼ばれる、証明書の連鎖が生成されます。 この信頼の委任は重要です。なぜなら、これにより、証拠保全が確立され、署名キーの共有が回避されるからです。
このチェーン内の証明書の伝播は、権限の論理的な引き継ぎを示します。 多くのサプライ チェーンは、この論理的なハンドオフに従います。これにより、各中間 CA が署名されてチェーンに入れられると同時に、すべての上流 CA 証明書を受信します。 最後の中間 CA は最終的に各デバイスに署名し、チェーンからのすべての認証局証明書をデバイスに挿入します。
デバイス証明書 (リーフ証明書とも呼ばれます) では、Azure IoT Hub に IoT デバイスを登録するときに使用されたデバイス ID (CN=deviceId) に共通名 (CN) が設定されている必要があります。 この設定は認証に必要です。
X.509 認証を使うモジュールの場合、モジュールの証明書の共通名 (CN) は、CN=deviceId/moduleId のような形式になっている必要があります。
証明書チェーンを作成する方法について確認してください。これは、デバイスに署名するときに行います。
X.509 CA 証明書を IoT Hub に登録する
X.509 CA 証明書を IoT Hub に登録します。ここでは、この証明書を使用してデバイスが認証されます。 X.509 CA 証明書は、証明書の信頼チェーン内に CA がある任意のデバイスを認証できます。 X.509 CA 証明書の登録は 2 段階のプロセスであり、証明書ファイルのアップロードと、その後の所有証明の確立で構成されます。
アップロード プロセスでは、証明書を含むファイルのアップロードを行います。 このファイルには秘密キーが含まれていてはなりません。
所有の証明ステップには、ユーザーが実際に CA 証明書を所有していることを確認するための、ユーザーと IoT Hub の間の暗号のチャレンジと応答のプロセスが含まれます。 所有権を自動的に確認するか、手動で確認するかを選択できます。 手動で確認する場合、IoT Hub によってランダム チャレンジが生成されます。このチャレンジに、CA 証明書の秘密キーを使用して署名します。 推奨されているように秘密キー シークレットを保存して保護している場合、このステップを完了するための情報を持っているのはユーザー本人のみです。 秘密キーの秘密性が、この方法における信頼の源です。 チャレンジに署名した後、結果を含むファイルをアップロードして確認を完了します。
CA 証明書を登録する方法を参照してください。
X.509 CA 証明書で署名されたデバイスを認証する
X.509 CA 証明書を登録し、デバイスに署名して証明書の信頼チェーンに入れました。最後のステップは、デバイスを認証することです。 X.509 CA 署名デバイスは、接続するとき、検証のためにその証明書チェーンをアップロードします。 この情報を使用して、IoT Hub は 2 段階のプロセスでデバイスを認証します。
最初に、IoT Hub は、証明書チェーンの内部一貫性を暗号的に確認します。 次に、IoT Hub は、所有証明チャレンジをデバイスに発行します。 IoT Hub は、デバイスから正常な所有証明応答を受け取ると、デバイスの認証を宣言します。 この宣言は、デバイスの秘密キーが保護されていること、またこのデバイスのみがこのチャレンジに対して正常に応答できることを前提としています。 秘密キーを保護するために、ハードウェア セキュア モジュール (HSM) のようなセキュアなチップをデバイスで使用することをお勧めします。
IoT Hub へのデバイス接続が正常に行われると、認証プロセスは完了です。これはまた、セットアップが正しいことも示しています。 デバイスが接続されるたびに、IoT Hub によって TLS セッションが再ネゴシエートされ、そのデバイスの X.509 証明書が検証されます。
デバイス証明書を取り消す
IoT Hub では、証明書ベースの認証を使用してデバイスを認証するときに、証明機関からの証明書失効リストは確認されません。 証明書が侵害された可能性があるために IoT Hub への接続をブロックする必要があるデバイスがある場合は、ID レジストリでそのデバイスを無効にします。 詳細については、「デバイスの無効化と削除」を参照してください。
サンプル シナリオ
Company-X は、専用インストールのために設計された Smart-X-Widget を作成しています。 Company-X は、製造とインストールの両方を外部に委託しています。 Factory-Y が Smart-X-Widget を製造し、Technician-Z がそれらをインストールしています。 Company-X は、Smart-X-Widget が Factory-Y からインストール担当の Technician-Z に直接出荷されるようにしたいと考えており、その後、Smart-X-Widget が Company-X の IoT Hub のインスタンスに直接接続されるようにしたいと考えています。 これを実現するには、Company-X は、Smart-X-Widget を自動接続するための準備として 1 回限りの設定操作を数回実行する必要があります。 このエンド ツー エンドのシナリオには、次の手順が含まれます。
X.509 CA 証明書を取得する
X.509 CA 証明書を IoT Hub に登録する
デバイスに署名して証明書の信頼チェーンに入れる
デバイスを接続する
「チュートリアル: テスト用の証明書を作成してアップロードする」では、これらの手順が説明されています。
証明書を取得する
Company-X は、公的なルート証明機関から X.509 CA 証明書を購入すること、または自己署名プロセスを通じて X.509 CA 証明書を作成することができます。 どちらの場合も、2 つの基本的な手順、つまり、公開キーと秘密キーのペアを生成することと、公開キーで証明書に署名することが必要になります。
これらの手順を実行する方法の詳細は、それぞれのサービス プロバイダーによって異なります。
証明書を IoT Hub に登録する
Company-X は、X.509 CA を IoT Hub に登録する必要があります。IoT Hub は、接続時に Smart-X-Widget の認証を行います。 この 1 回限りのプロセスによって、任意の数の Smart-X-Widget デバイスを認証および管理できるようになります。 CA 証明書とデバイス証明書の間の一対多の関係は、X.509 CA 認証方法を使用する主な利点の 1 つです。 Smart-X-Widget デバイスごとに個別の証明書拇印をアップロードする方法もありますが、この方法では運用コストが増加します。
X.509 CA 証明書の登録は、証明書をアップロードし、その後、所有証明を提供するという 2 段階のプロセスです。
証明書をアップロードする
X.509 CA 証明書のアップロード プロセスは、単に IoT Hub に CA 証明書をアップロードするというプロセスです。 IoT Hub は、ファイル形式の証明書を必要とします。
いかなる場合でも、証明書ファイルに秘密キーを含めないでください。 公開キー基盤 (PKI) を規定する標準のベスト プラクティスでは、Company-X の秘密キーに関する情報は、Company-X 内にのみ留めておくことが求められます。
所有を証明する
X.509 CA 証明書は、他のデジタル証明書と同様に、傍受されやすい公開情報です。 そのため、傍受者は、証明書を傍受し、その証明書を自分のものとしてアップロードしようとする可能性があります。 この例では、IoT Hub は、Company-X がアップロードした CA 証明書が実際に Company-X に属しているかどうかを確認する必要があります。 このために、Company-X にチャレンジが送信されます。Company-X は、所有証明 (PoP) フローを通じて、証明書を所有していることを証明します。
IoT Hub は、所有証明フローで、Company-X がその秘密キーを使用して署名する乱数を生成します。 Company-X が PKI のベスト プラクティスに従って秘密キーを保護していれば、Company-X だけが所有証明チャレンジに正しく応答できます。 IoT Hub は、所有証明チャレンジの応答に成功すると、X.509 CA 証明書の登録に進みます。
IoT Hub からの所有証明チャレンジに対する応答に成功すると、X.509 CA の登録が完了します。
デバイスに署名して証明書の信頼チェーンに入れる
この例では、証明書ベースの認証は、各 Smart-X-Widget で一意のデバイス証明書が保有されている必要があることを意味します。 Company-X は、デバイスごとに個別の証明書とキーのペアを作成するのではなく、CA 証明書を使用し、デバイスごとに信頼の証明書チェーンを作成することを決定します。
この例では、Company-X が Factory-Y に署名します。次に Factory-Y が Technician-Z に署名し、最後に Technician-Z が Smart-X-Widget に署名します。
次の図は、Smart-X-Widget の例で、信頼の証明書チェーンがどのように結び付くかを示しています。
- Company-X は、Smart-X-Widget と物理的にやり取りすることはありません。 Factory-Y の中間 CA 証明書に署名することで、信頼の証明書チェーンを開始します。
- Factory-Y は、Company-X からの署名を備えた独自の中間 CA 証明書を持っています。 これらのアイテムのコピーを各デバイスに渡します。 また、中間 CA 証明書を使用して、Technician-Z の中間 CA 証明書と Smart-X-Widget のデバイス証明書に署名します。
- Technician-Z は、Factory-Y からの署名を備えた独自の中間 CA 証明書を持っています。 これらのアイテムのコピーを各デバイスに渡します。 また、中間 CA 証明書を使用して、Smart-X-Widget のデバイス証明書に署名します。
- すべての Smart-X-Widget デバイスに、独自の一意のデバイス証明書と、サプライ チェーンでやり取りした各中間 CA の証明書からの公開キーと署名のコピーが含まれます。 これらの証明書と署名を追跡すると、元の Company-X ルートに戻ることができます。
CA 認証方式は、デバイス製造サプライ チェーンに安全なアカウンタビリティを提供します。 この証明書チェーン プロセスにより、チェーン内の各メンバーのアクションは暗号化によって記録され、検証できます。
このプロセスは、デバイスの一意の公開キーと秘密キーのペアが個別に作成され、秘密キーが常にデバイス内で保護されていることを前提とします。 さいわいなことに、内部でキーを生成し、秘密キーを保護できる、ハードウェア セキュア モジュール (HSM) 形式の安全なシリコン チップが存在します。 Company-X は、Smart-X-Widget の部品表にこのような安全なチップを 1 つ追加するだけで済みます。
デバイスを認証する
X.509 CA 認証用に製造されたデバイスには、一意のデバイス証明書と、それぞれの製造サプライ チェーンからの証明書チェーンが用意されています。 デバイスの接続は、初めての場合でも、証明書チェーンのアップロードと所有証明の 2 段階のプロセスで行われます。
この例では、各 Smart-X-Widget は、一意のデバイス証明書を Factory-Y および Technician-Z の X.509 CA 証明書と共にアップロードした後、IoT Hub からの所有証明チャレンジに応答します。
IoT Hub は、Company-X からの事前登録済み X.509 CA 証明書を使用して、アップロードされた証明書チェーンが内部的に一貫性があるか、およびそのチェーンの発端が X.509 CA 証明書の有効な所有者であるかを確認します。 X.509 CA の登録プロセスと同様に、IoT Hub は、所有証明のチャレンジ/応答プロセスを使用して、チェーン、さらにはデバイス証明書が、それをアップロードしたデバイスに属しているかを確認します。 正常な応答により、IoT Hub はデバイスを認証済みとして受け入れ、接続を許可します。
信頼の基盤は、秘密キー (デバイスの秘密キーを含む) を保護することです。 したがって、デバイスの秘密キーを保護するためのハードウェア セキュア モジュール (HSM) 形式の安全なシリコン チップと、チェーン内のいかなる証明書からの秘密キーも共有しないというベスト プラクティスはついては、その重要性をいくら強調しても足りません。
次のステップ
登録グループを使用して複数の X.509 デバイスをプロビジョニングするために、デバイス プロビジョニング サービスを使用する。
X.509 証明書を構成するフィールドの詳細については、「X.509 証明書」を参照してください。
ルート CA 証明書または下位 CA 証明書があり、それを IoT ハブにアップロードする場合は、その証明書を所有していることを確認する必要があります。 詳細については、「チュートリアル: テスト用の証明書を作成してアップロードする」を参照してください。