証明書管理の主な概念 (プレビュー)

Azureデバイスレジストリにおける証明書管理は、IoTデバイス向けのX.509証明書の管理を簡素化します。 本記事では、証明書管理および証明書ベースの認証に関する基本的な概念を紹介します。 詳細については、「証明書管理 (プレビュー)とは」を参照してください。

Important

Azure Device Registry 統合とMicrosoftベースの X.509 証明書管理を使用したAzure IoT Hubは、public プレビューであり、運用環境のワークロードには推奨されません。 詳細については、FAQ: IoT Hub の新機能を参照してください。

クラウド公開鍵基盤(PKI)

公開鍵基盤(PKI)は、認証機関、暗号鍵、ポリシー、およびデジタル証明書の発行、管理、更新、取り消しに使用されるプロセスの枠組みです。 証明書は、Web やデバイスの ID など、さまざまなシナリオのセキュリティ保護に不可欠です。 歴史的に、組織は独自のPKI環境を構築し運用しており、これにはハードウェアセキュリティモジュール(HSM)、証明書認証局ソフトウェア、IoTフリートにとって特に複雑な運用手順が含まれます。

クラウドPKIは従来のPKIと同じ証明書認証局の機能を提供しますが、それらをマネージドクラウドサービスとして提供します。 組織はPKIインフラを自ら展開・運用するのではなく、クラウド管理APIやライフサイクルワークフロー、自動化された運用を通じて証明書サービスを利用しています。 Azure Device Registry の証明書管理を活用すれば、デバイスのセキュリティを強化し、フルマネージドのクラウド PKI サービスへのデジタル トランスフォーメーションを加速できます。

MicrosoftクラウドPKIとサードパーティPKIの違い

IoT HubはX.509証明書認証のために2種類のPKIプロバイダーをサポートしていますが、Azureデバイスレジストリでの証明書管理は現在、MicrosoftクラウドPKIと独自のCAを持ち込むのみをサポートしています。 サードパーティ PKI プロバイダーの使用については、「 X.509 CA 証明書を使用したデバイスの認証」を参照してください。

PKI プロバイダー 統合が必要 Azure デバイス レジストリが必要です デバイスプロビジョニングサービスが必要です
Microsoft cloud PKI 認証機関はAzureデバイスレジストリで直接設定するか、自分でCAを用意してください。 はい はい
サード パーティ PKI (DigiCert、GlobalSign など) Yes. 手動統合が必要です。 いいえ いいえ

各名前空間は論理的に隔離されたクラウドPKI環境を受け取り、証明書操作がその名前空間内のリソースに制限されます。 顧客はクラウドPKIを別のAzureリソースとして管理していません。 代わりに、クラウドPKIは自動的にプロビジョニングされ、スコープ設定され、Azureデバイスレジストリの名前空間の一部として管理されます。

X.509 証明書

X.509 証明書は、デバイス、ユーザー、サービスなどのエンティティの ID に公開キーをバインドするデジタル ドキュメントです。 証明書ベースの認証には、安全性の低い方法に比べていくつかの利点があります。

  • 証明書では、公開キーと秘密キーの暗号化が使用されます。 公開キーは自由に共有されますが、秘密キーはデバイス上に残り、トラステッド プラットフォーム モジュール (TPM) またはセキュリティで保護された要素内に配置できます。 これにより、攻撃者はデバイスを偽装できなくなります。
  • 証明書は証明機関 (CA) 階層を通じて発行および検証されるため、組織はデバイスごとにシークレットを管理することなく、1 つの CA を介して何百万ものデバイスを信頼できます。
  • デバイスはクラウドに対して認証され、クラウドはデバイスに対して認証されるため、相互のトランスポート層セキュリティ(mTLS)認証が可能になります。

証明書の種類

X.509 証明書には、次の 2 つの一般的なカテゴリがあります。

  • CA 証明書: これらの証明書は証明機関 (CA) によって発行され、それらを使用して他の証明書に署名します。 CA 証明書には、ルート証明書と中間証明書が含まれます。

    • ルート CA: ルート証明書は、中間 CA への署名に使用できる、信頼された CA からの最上位の自己署名証明書です。

    • 中間証明書または発行CA: 中間証明書とは、信頼できるルート証明書が署名するCA証明書のことです。 異なる製造元のデバイスやデバイスの異なるモデルなど、デバイスのセットやグループごとに異なる中間証明書を使用すると便利な場合があります。

  • エンドエンティティ証明書またはデバイス証明書: CA証明書によって署名される証明書で、個人用証明書またはデバイス証明書です。 CAはユーザー、サーバー、またはデバイスにそれらを発行します。

証明書ライフサイクル操作

証明書管理は、認証局およびデバイス証明書のライフサイクル全体をサポートします。 異なるライフサイクル運用を理解することで、デバイスが運用期間中ずっと安全で途切れない接続を維持することができます。

  • 発行:証明書発行機関やデバイスの新しい証明書を生成し署名するプロセス。 このプロセスは証明書署名リクエストから始まります。

  • 更新:機器証明書の有効期限を延長し、現在の証明書が期限切れになる前に交換証明書を発行するプロセスです。 デバイス証明書は、デバイスの再プロビジョニングを必要とせずに更新できます。

  • ローテーション: 認証局を新しい認証局に置き換えつつ、信頼関係を維持するプロセス。 回転は、中間CAの有効期限が近づく場合や暗号要件が変更された際に一般的に行われます。

  • 取り消し:証明書がもはや信頼されなくなったり、侵害されたり、使用許可がなくなった場合、有効期限前に無効化する手続き。

  • 有効期限:証明書の有効期間の終了。 期限切れとなった証明書は認証に使用できず、更新または交換が必要です。

証明書署名要求

証明書署名要求 (CSR) は、IoT デバイスなどのクライアントが証明機関 (CA) から署名済み証明書を要求するために生成するデジタル署名されたメッセージです。 CSR には、デバイスの公開キーと識別情報 (登録 ID など) が含まれており、キーの所有権を証明するためにデバイスの秘密キーで署名されます。 CSR は、承認されたキー アルゴリズム、キー サイズ、サブジェクト フィールド形式など、PKI のポリシー要件に従う必要があります。 デバイスが新しい秘密キーを生成すると、新しい CSR も生成されます。 CA は CSR を検証して承認した後、デバイスの ID を公開キーにバインドする X.509 証明書を発行します。 このプロセスにより、秘密キーの所有を証明できるデバイスのみが信頼できる証明書を受け取ることができます。

Azureデバイスレジストリにおける証明書署名要求要件の詳細については、「Azureデバイスレジストリにおける証明書発行」をご覧ください。

認証局のローテーション

証明書発行機関のローテーションとは、既存のルートまたは中間CA証明書を、古い証明書が期限切れまたは侵害される前に新しいものに置き換える予定または緊急のプロセスです。 CAは信頼のアンカーであり、すべての下流証明書に署名するため、CAを置き換えることですべてのデバイスの暗号基盤が更新されます。

Azureデバイスレジストリでは、証明書発行機関は有効期限前に自動的にローテーションされます:

  1. 新しいCA世代: CAが期限切れになる前に、ADRは自動的に代替CAをプロビジョニングします。 このステップは、IoTサービスが旧来のCAと新しいCAの両方を信頼する移行期間の始まりとなります。 ADRが発行するデバイス証明書の有効期限を中間CAの有効期限より後に設定することはできないので、ゴースト証明書の心配は不要です。

  2. デバイス証明書の更新: この期間中、デバイスは置き換え先のCAを使用するよう移行する必要があります。 デバイスは、定期的な証明書更新プロセスに従って新しい証明書を単純に申請できます。 ADRは自動的にデバイス証明書署名要求を新しい中間CAに転送します。

  3. 旧CAの廃止: 移行期間が終了すると、ADRは旧CAを廃止します。 新しい証明書を取得しないデバイスは相互TLS(mTLS)に失敗し、接続を失います。 これらのデバイスはIoT Hubに接続するために新しい証明書を要求できます。

暗号アルゴリズムと鍵の種類

証明書は公開鍵暗号を用いてデバイスとサービス間の信頼を確立します。 各証明書には公開鍵が含まれており、認証機関(CA)によって暗号署名アルゴリズムを用いて署名されます。 証明書の強度、性能、互換性は、証明書作成および署名時に使用する鍵アルゴリズム、鍵サイズ、ハッシュアルゴリズムに依存します。

主要なアルゴリズム

証明書管理は非対称暗号を用いて信頼できるデジタルIDを確立します。 非対称暗号学では、数学的に関連した公開鍵と秘密鍵のペアが認証、デジタル署名、暗号化に使用されます。 暗号アルゴリズムの選択は、セキュリティ強度、性能特性、相互運用性、リソース要件に影響を与えます。 Azureデバイスレジストリの証明書管理は、証明書署名にエリプティックカーブ暗号(ECC)を使用します。

キーのサイズとキーカーブ

鍵のサイズまたは鍵曲線は、証明書の公開鍵/秘密鍵ペアの暗号強度を決定します。 鍵サイズが大きいほど、またはより強力な楕円曲線であるほど、一般的に暗号学的な強度が向上しますが、証明書のサイズ、処理要件、性能にも影響を及ぼします。 例えば、Azureデバイスレジストリの証明書管理では、P-384カーブを使ってECC証明書を発行します。

ハッシュアルゴリズム

証明書発行機関は、証明書に署名する際に暗号学的ハッシュ関数を使用します。 ハッシュ関数は証明書内容の固定長ダイジェストを生成し、発行CAがそのダイジェストにデジタル署名します。 ハッシュアルゴリズムは証明書の完全性、改ざん検出、信頼チェーン検証、デジタル署名の検証を助けます。 Azureデバイスレジストリの証明書管理はSHA-384を使用します。

デジタル署名

証明書発行機関が証明書を発行する際、証明書発行機関の秘密鍵と選択した署名アルゴリズムを用いて証明書にデジタル署名を行います。

証明書検証中:

  1. 証明書のハッシュが再計算されます。

  2. CAの公開鍵はデジタル署名の検証を行います。

  3. 証明書チェーンは信頼できるルートCAまで検証されます。

チェーン内の証明書を改変すると、署名検証が失敗し、証明書は信頼できません。

ハードウェア保護キー vs. ソフトウェア保護キー

証明書発行機関(CA)は、証明書の発行および署名に秘密鍵に依存しています。 CAのセキュリティは、これらの秘密鍵の生成、保存、使用方法に大きく依存します。

ソフトウェア保護キーは ソフトウェアに保存され、不正アクセスを防ぐためにオペレーティングシステムの保護に依存しています。 導入は簡単ですが、ソフトウェアキーはマルウェア、認証情報盗難、設定ミス、不正アクセスなどによる侵害に対して一般的に脆弱です。

ハードウェアで保護された鍵は、機密性の高い鍵マテリアルを保護するために設計された専用の暗号装置であるハードウェアセキュリティモジュール(HSM)内で生成・保存されます。 HSMに保存された秘密鍵はハードウェアの境界を決して出ず、すべての暗号署名処理はデバイス内で行われます。 これにより鍵の露出リスクが大幅に低減され、組織が厳格なセキュリティおよびコンプライアンス要件を満たすのに役立ちます。

Azureデバイス レジストリでは、証明書発行機関にハードウェア保護キーが使用されます。 証明書発行機関の秘密鍵はAzure Key Vault管理HSMによって保護されており、署名作業がFIPS認証済みのハードウェアセキュリティ境界内で行われ、秘密鍵マテリアルがエクスポートされないようにしています。

オンラインCAとオフラインCAの比較

また、認証機関はネットワークのアクセス性や運用モデルによって分類することもできます。

オフラインのCAはそのほとんどの期間、本番ネットワークから切断されたままです。 オフラインCAは高保証のルートCAとして使用しましょう。なぜなら秘密鍵はネットワークベースの脅威から隔離されているからです。 管理操作は通常手動処理を必要とするため、オフラインCAは高い安全性を備えている一方で、運用上も負荷がかかります。

オンラインCAはネットワークに接続し、証明書発行、更新、ライフサイクル操作を自動的に実行できます。 オンラインCAはスケーラブルな証明書管理と自動化を可能にしますが、署名鍵やCAインフラを保護するための強力な制御が必要です。

Azureデバイスレジストリはオンライン認証機関を利用して、クラウドスケールでの証明書の自動発行、更新、失効、ローテーションをサポートします。 Azure Managed HSMは、ハードウェアにより保護された鍵ストレージを用いてこれらのオンラインCAを保護し、オンラインCAの運用上の利点と強力な鍵保護制御を組み合わせています。 Bring Your Own CA(BYOCA)信頼モデルを利用する顧客は、ルートCAをオフラインで管理し、オンラインの発行認証局の信頼確立にのみ使用します。 このアプローチは、オフラインの信頼アンカーのセキュリティ利点とクラウド管理のオンラインCAのスケーラビリティを組み合わせています。

認証と承認

  • 認証 とは、IoT Hub に ID を証明することを意味します。 ユーザーまたはデバイスが主張する通りの存在であることを検証します。 このプロセスは、多くの場合、 AuthN と呼ばれます。

  • 承認 とは、認証されたユーザーまたはデバイスが IoT Hub でアクセスまたは実行できることを確認することを意味します。 リソースとコマンドのアクセス許可を定義します。 承認は AuthZ と呼ばれることもあります。

IoT Hub は、X.509 証明書を認証にのみ使用し、認可には使用しません。 Microsoft Entra IDや共有アクセス署名とは異なり、X.509証明書はカスタマイズ可能な権限をサポートしていません。