X.509 証明書を使用して ID を認証する

  • [アーティクル]

IoT Hub は、X.509 証明書を使ってデバイスの認証を行います。 X.509 認証は、トランスポート層セキュリティ (TLS) 標準接続の確立の一部として物理層に IoT デバイスの認証を許可します。

X.509 CA 証明書は、他の証明書に署名できるデジタル証明書です。 デジタル証明書は、IETF の RFC 5280 標準で規定されている証明書形式の標準に準拠している場合、X.509 証明書と見なされます。 証明機関 (CA) とは、その所有者が他の証明書に署名できることを意味します。

この記事では、X.509 証明機関 (CA) の証明書を使って、IoT Hub に接続するデバイスの認証を行う方法について説明します。これには、次の手順が含まれます。

  • X.509 CA 証明書の入手方法
  • X.509 CA 証明書を IoT Hub に登録する方法
  • X.509 CA 証明書を使用してデバイスに署名する方法
  • X.509 CA で署名されたデバイスを認証する方法

重要

X.509 証明機関 (CA) の認証を使用するデバイスの次の機能は、まだ一般提供されていません。また、プレビュー モードを有効にする必要があります。

  • HTTPS、WebSocket 経由の MQTT、WebSockets プロトコル経由の AMQP。
  • ファイルのアップロード (すべてのプロトコル)。

これらの機能は、X.509 拇印認証を使用するデバイスで一般提供されています。 IoT Hub での X.509 認証の詳細については、「サポートされている X.509 証明書」を参照してください。

X.509 CA 機能により、証明機関 (CA) を使用して IoT Hub に対してデバイスを認証できます。 これにより、初回のデバイス登録プロセスとデバイス製造時のサプライチェーン ロジスティックスが簡素化されます。

認証と権限承認

"認証" は、ユーザーが身元を証明するプロセスです。 認証は、IoT Hub に対するユーザーまたはデバイスの ID を検証します。 AuthN と短縮される場合があります。 認可は、IoT Hub で認証されたユーザーまたはデバイスのアクセス許可を確定するプロセスです。 これにより、ユーザーがアクセスすることを許可されるリソースとコマンド、およびユーザーがそれらのリソースとコマンドで実行できる操作が指定されます。 承認は AuthZ と短縮される場合があります。

この記事では、X.509 証明書を使った認証について説明します。 証明書拇印や証明書機関 (CA) を Azure IoT Hub にアップロードすることで、IoT Hub のデバイスを X.509 証明書で認証できます。

X.509 証明書は、IoT Hub での認可ではなく認証に使われます。 Microsoft Entra ID や Shared Access Signature とは異なり、X.509 証明書によるアクセス許可はカスタマイズできません。

X.509 認証を適用する

セキュリティを強化するために、デバイスとモジュールの SAS 認証を許可しないように IoT ハブを構成し、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 証明書認証の利点

X.509 証明機関 (CA) 認証は、IoT Hub に対してデバイスを認証するための手法であり、このために、デバイス ID の作成とサプライ チェーンでのライフサイクル管理を大幅に簡素化する方法が使用されます。

X.509 CA 認証の特徴的な属性として、CA 証明書とそのダウンストリーム デバイスが一対多の関係になっていることがあります。 この関係により、1 つの X.509 CA 証明書を 1 度登録するだけで、任意の数のデバイスを IoT Hub に登録できます。 これがない場合、デバイスが接続できるようになる前に、デバイスごとに固有の証明書を事前登録する必要があります。 また、この一対多の関係により、デバイス証明書のライフサイクル管理操作も簡単になります。

X.509 CA 認証のもう 1 つの重要な属性として、サプライ チェーンのロジスティクスが簡素化されることがあります。 デバイスのセキュリティで保護された認証では、各デバイスが信頼の基盤として一意のシークレット (キーなど) を保持する必要があります。 証明書ベースの認証では、このシークレットは秘密キーです。 一般的なデバイス製造フローには、複数のステップと管理者が含まれています。 複数の管理者間でデバイスの秘密キーを安全に管理し、信頼を維持することは難しいうえにコストも高くなります。 証明機関を使用すると、各管理者にデバイスの秘密キーを委ねるのではなく、各管理者に署名して暗号の信頼チェーンを確立するため、この問題は解決します。 各管理者は、製造フローのそれぞれのステップでデバイスに署名します。 総合的な結果として、暗号の信頼チェーンの使用によりアカウンタビリティが組み込まれた最適なサプライ チェーンになります。

このプロセスによって、デバイスで一意の秘密キーが保護されている場合にセキュリティが最も強力になります。 この目的のために、秘密キーを内部で生成できるハードウェア セキュア モジュール (HSM) を使用することをお勧めします。

Azure IoT Hub Device Provisioning Service (DPS) を使用すると、デバイスのグループをハブに簡単にプロビジョニングできます。 詳細については、「チュートリアル: 登録グループを使って複数の X.509 デバイスをプロビジョニングする」を参照してください。

X.509 CA 証明書を入手する

X.509 CA 証明書は、各デバイスの証明書チェーンの先頭にあります。 証明書は、使用方法に応じて、購入または作成することができます。

運用環境の場合、証明書サービスの専門プロバイダーから X.509 CA 証明書を購入することをお勧めします。 CA 証明書を購入することで、ルート CA が、デバイスの正当性を保証する信頼されたサード パーティとして機能するという利点が得られます。 デバイスがオープン IoT ネットワークの一部であり、そのネットワークでデバイスがサード パーティの製品やサービスと対話する場合、このオプションを検討してください。

テスト目的で自己署名 X.509 CA 証明書を作成することもできます。 テスト用証明書の作成方法の詳細については、「テスト用の証明書を作成してアップロードする」を参照してください。

Note

運用環境では、自己署名証明書を使用することはお勧めしません。

X.509 CA 証明書の入手方法に関係なく、必ずその対応する秘密キー シークレットを保存し、常に保護されている状態にしておいてください。 この予防措置は、X.509 CA 認証で信頼を構築するために必要です。

デバイスに署名して証明書の信頼チェーンに入れる

X.509 CA 証明書の所有者は、中間 CA に暗号で署名できます。この中間 CA は別の中間 CA に署名でき、このプロセスが継続されます。このプロセスは、最後の中間 CA がデバイス証明書に署名すると終了します。 この結果、"証明書の信頼チェーン" と呼ばれる、証明書の連鎖が生成されます。 この信頼の委任は、暗号に関して可変の保管チェーンを確立し、署名キーの共有が回避されるため重要です。

信頼チェーン内の証明書を示す図。

デバイス証明書 (リーフ証明書とも呼ばれます) では、共通名 (CN) が、Azure IoT Hub に IoT デバイスを登録するときに使われたデバイス ID (CN=deviceId) に設定されている必要があります。 この設定は認証に必要です。

X.509 認証を使うモジュールの場合、モジュールの証明書の共通名 (CN) は、CN=deviceId/moduleId のような形式になっている必要があります。

証明書チェーンを作成する方法について確認してください。これは、デバイスに署名するときに行います。

X.509 CA 証明書を IoT Hub に登録する

X.509 CA 証明書を IoT Hub に登録します。ここでは、この証明書を使用して、登録時および接続時にデバイスを認証します。 X.509 CA 証明書の登録は 2 段階のプロセスであり、証明書ファイルのアップロードと、その後の所有証明の確立で構成されます。

アップロード プロセスでは、証明書を含むファイルのアップロードを行います。 このファイルには秘密キーが含まれていてはなりません。

所有の証明ステップには、ユーザーと IoT Hub 間で暗号のチャレンジと応答のプロセスが含まれます。 デジタル証明書の内容がパブリックであるために傍受されやすい場合、IoT Hub で、ユーザーが実際に CA 証明書を所有しているか確認する必要があります。 所有権を自動的に確認するか、手動で確認するかを選択できます。 手動で確認する場合、Azure IoT Hub によってランダム チャレンジが生成されます。このチャレンジに、CA 証明書の対応する秘密キーを使用して署名します。 推奨されているように秘密キー シークレットを保存して保護している場合、このステップを完了するための情報を持っているのはユーザー本人のみです。 秘密キーの秘密性が、この方法における信頼の源です。 チャレンジに署名したら、結果を含むファイルをアップロードしてこのステップを完了し、手動で証明書を確認します。

CA 証明書を登録する方法を参照してください。

X.509 CA 証明書で署名されたデバイスを認証する

すべての IoT ハブには、それに対する接続が許可されたデバイスおよびモジュールに関する情報を保存する ID レジストリがあります。 デバイスまたはモジュールを接続できるようにするには、そのデバイスまたはモジュールのエントリが IoT ハブの ID レジストリに存在する必要があります。 ID レジストリに保存されている資格情報に基づいて、デバイスまたはモジュールが IoT ハブで認証されます。

X.509 CA 証明書を登録し、デバイスに署名して証明書の信頼チェーンに入れました。最後のステップは、デバイスが接続するときにデバイスを認証することです。 X.509 CA 署名デバイスは、接続するとき、検証のためにその証明書チェーンをアップロードします。 チェーンには、中間 CA とデバイス証明書がすべて含まれています。 この情報を使用して、IoT Hub は 2 段階のプロセスでデバイスを認証します。 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 回限りの設定操作を数回実行する必要があります。 このエンド ツー エンドのシナリオには、次の手順が含まれます。

  1. X.509 CA 証明書を取得する

  2. X.509 CA 証明書を IoT Hub に登録する

  3. デバイスに署名して証明書の信頼チェーンに入れる

  4. デバイスを接続する

「チュートリアル: テスト用の証明書を作成してアップロードする」では、これらの手順が説明されています。

証明書を取得する

Company-X は、公的なルート証明機関から X.509 CA 証明書を購入すること、または自己署名プロセスを通じて X.509 CA 証明書を作成することができます。 どちらの場合も、2 つの基本的な手順、つまり、公開キーと秘密キーのペアを生成することと、公開キーで証明書に署名することが必要になります。

これらの手順を実行する方法の詳細は、それぞれのサービス プロバイダーによって異なります。

X.509 CA 証明書を生成するためのフローを示す図。

証明書を購入する

CA 証明書を購入することで、既知のルート CA が IoT デバイスの接続時にデバイスの正当性を保証する信頼されたサード パーティとして機能するという利点が得られます。 デバイスがサード パーティの製品やサービスとやり取りする場合は、このオプションを選びます。

X.509 CA 証明書を購入するには、ルート証明書のサービス プロバイダーを選びます。 ルート CA プロバイダーにより、公開キーと秘密キーのペアの作成方法と、サービスの証明書署名要求 (CSR) の生成方法が案内されます。 CSR は、証明機関からの証明書を申請する正式なプロセスです。 この購入の結果、証明機関の証明書として使用するための証明書を取得できます。 X.509 証明書の遍在性を考慮すると、この証明書は IETF の RFC 5280 標準に合わせて適切に書式設定されている可能性があります。

自己署名証明書の作成

自己署名 X.509 CA 証明書を作成するプロセスは、X.509 CA 証明書を購入するプロセスと似ていますが、自己署名 X.509 CA 証明書を作成するプロセスでは、ルート証明機関のようなサードパーティの署名者は関与しません。 この例では、Company-X が、ルート証明機関に代わってその証明機関の証明書に署名します。

証明機関の証明書を購入する準備が整うまで、テスト目的でこのオプションを選択できます。 また、デバイスが IoT Hub の外部にあるサード パーティのサービスに接続しない場合は、運用環境で自己署名 X.509 CA 証明書を使用できます。

証明書を 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 証明書を登録するためのプロセス フローを示す図。

証明書をアップロードする

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 の登録が完了します。

デバイスに署名して証明書の信頼チェーンに入れる

IoT では、接続するデバイスごとに一意の ID が必要になります。 証明書ベースの認証の場合、これらの ID は証明書の形式になります。 この例では、証明書ベースの認証は、各 Smart-X-Widget で一意のデバイス証明書が保有されている必要があることを意味します。

各デバイスに一意の証明書を提供する、有効ではあっても非効率的な方法は、Smart-X-Widget 用の証明書を事前に生成し、対応する秘密キーを持つサプライ チェーン パートナーを信頼するという方法です。 Company-X の場合、これは Factory-Y と Technician-Z の両方を信頼することを意味します。 この方法には、次のように、信頼を確保するために克服しなければならない課題があります。

  • 秘密キーを共有しないという PKI のベスト プラクティスを無視するうえに、デバイスの秘密キーをサプライ チェーン パートナーと共有しなければならないことにより、サプライ チェーンにおける信頼構築はコストが高くなります。 デバイスの秘密キーを保管する安全な部屋などのシステムや、定期的なセキュリティ監査などのプロセスが必要になります。 どちらも、サプライ チェーンのコストを引き上げます。

  • サプライ チェーンでデバイスを安全にアカウンティングすること、その後それらをデプロイで管理することは、デバイス固有の証明書 (および秘密キー) を生成した時点から、デバイスを廃棄する時点まで、すべてのキーとデバイスのペアについて一対一のタスクとなります。 これにより、グループの概念が何らかの形で明示的にプロセスに組み込まれていない限り、デバイスのグループ管理は除外されます。 したがって、安全なアカウンティングとデバイスのライフ サイクル管理は運用上の大きな負担になります。

X.509 CA 証明書認証は、証明書チェーンを使用することで、これらの課題を見事に解決します。 証明書チェーンは、CA が中間 CA に署名することから始まり、その中間 CA が別の中間 CA に署名し、最終の中間 CA がデバイスに署名するまで続きます。 この例では、Company-X が Factory-Y に署名します。次に Factory-Y が Technician-Z に署名し、最後に Technician-Z が Smart-X-Widget に署名します。

証明書チェーン階層の例を示す図。

このチェーン内の証明書の伝播は、権限の論理的な引き継ぎを示します。 多くのサプライ チェーンは、この論理的な引き継ぎに従っています。つまり、各中間 CA は、上流 CA のすべての証明書を受け取り、署名してチェーンに入れます。最終的に、最後の中間 CA が各デバイスに署名し、チェーンからのすべての証明機関の証明書をデバイスに挿入します。 この引き継ぎは、工場の階層がある契約製造会社が特定の工場に製造を委託する場合に一般的にものです。 階層は複数レベル (たとえば、地理、製品の種類、製造ライン) で構成される場合がありますが、最後の工場だけがデバイスと対話できます。ただし、チェーンは階層の最上位から保持されます。

代替チェーンには、デバイスと対話する別の中間 CA を含めることができます。その場合、デバイスと対話する CA が、その時点での証明書チェーンの内容を挿入します。 CA の一部だけがデバイスと物理的に対話するハイブリッド モデルも可能です。

次の図は、Smart-X-Widget の例で、信頼の証明書チェーンがどのように結び付くかを示しています。

ある会社の証明書から別の会社の証明書への信頼の証明書チェーンを示す図。

  1. Company-X は、Smart-X-Widget と物理的にやり取りすることはありません。 Factory-Y の中間 CA 証明書に署名することで、信頼の証明書チェーンを開始します。
  2. Factory-Y は、独自の中間 CA 証明書を用意し、Company-X からの署名を入手します。 これらのアイテムのコピーをデバイスに渡します。 また、中間 CA 証明書を使用して、Technician-Z の中間 CA 証明書と Smart-X-Widget のデバイス証明書に署名します。
  3. Technician-Z は、独自の中間 CA 証明書を用意し、Factory-Y から署名を入手します。 これらのアイテムのコピーをデバイスに渡します。 また、中間 CA 証明書を使用して、Smart-X-Widget のデバイス証明書に署名します。
  4. すべての Smart-X-Widget デバイスに、独自の一意のデバイス証明書と、サプライ チェーンでやり取りした各中間 CA の証明書からの公開キーと署名のコピーが含まれます。 これらの証明書と署名を追跡すると、元の Company-X ルートに戻ることができます。

CA 認証方式は、デバイス製造サプライ チェーンに安全なアカウンタビリティを提供します。 この証明書チェーン プロセスにより、チェーン内の各メンバーのアクションは暗号化によって記録され、検証できます。

このプロセスは、デバイスの一意の公開キーと秘密キーのペアが個別に作成され、秘密キーが常にデバイス内で保護されていることを前提とします。 さいわいなことに、内部でキーを生成し、秘密キーを保護できる、ハードウェア セキュア モジュール (HSM) 形式の安全なシリコン チップが存在します。 Company-X は、Smart-X-Widget の部品表にこのような安全なチップを 1 つ追加するだけで済みます。

デバイスを認証する

最上位レベルの CA 証明書が IoT Hub に登録され、デバイスが一意の証明書を持ったら、それらのデバイスはどのように接続しますか? X.509 CA 証明書を IoT Hub に一度登録することで、場合によっては何百万台ものデバイスがどのように初回から接続および認証されるのでしょうか。 前に X.509 CA 証明書の登録で見たのと同じ証明書のアップロードと所有証明のフローを使います。

X.509 CA 認証用に製造されたデバイスには、一意のデバイス証明書と、それぞれの製造サプライ チェーンからの証明書チェーンが用意されています。 デバイスの接続は、初めての場合でも、証明書チェーンのアップロードと所有証明の 2 段階のプロセスで行われます。

証明書チェーンのアップロード中、デバイスは、その一意の証明書とその証明書チェーンを IoT Hub にアップロードします。 IoT Hub は、事前登録された X.509 CA 証明書を使用して、アップロードされた証明書チェーンが内部的に一貫性があるか、およびそのチェーンの発端が X.509 CA 証明書の有効な所有者であるかを検証します。 X.509 CA の登録プロセスと同様に、IoT Hub は、所有証明のチャレンジ/応答プロセスを使用して、チェーン、さらにはデバイス証明書が、それをアップロードしたデバイスに属しているかを確認します。 正常な応答により、IoT Hub はデバイスを認証済みとして受け入れ、接続を許可します。

この例では、各 Smart-X-Widget は、デバイスに一意の証明書を Factory-Y および Technician-Z の X.509 CA 証明書と共にアップロードした後、IoT Hub からの所有証明チャレンジに応答します。

デバイス証明書を検証するためのフローを示す図。

信頼の基盤は、秘密キー (デバイスの秘密キーを含む) を保護することです。 したがって、デバイスの秘密キーを保護するためのハードウェア セキュア モジュール (HSM) 形式の安全なシリコン チップと、秘密キーを共有しない (たとえば、一方の工場から他方の工場に秘密キーを預けない) というベスト プラクティスはついては、その重要性をいくら強調しても足りません。

次のステップ

登録グループを使用して複数の X.509 デバイスをプロビジョニングするために、デバイス プロビジョニング サービスを使用する。

X.509 証明書を構成するフィールドの詳細については、「X.509 証明書」を参照してください。

ルート CA 証明書または下位 CA 証明書があり、それを IoT ハブにアップロードする場合は、その証明書を所有していることを確認する必要があります。 詳細については、「チュートリアル: テスト用の証明書を作成してアップロードする」を参照してください。