Azure IoT Hub での証明書管理は、IoT デバイスの X.509 証明書の管理を簡略化するように設計されています。 この記事では、IoT Hub での証明書管理と証明書ベースの認証に関連する基本的な概念について説明します。 詳細については、「 証明書管理 (プレビュー)とは」を参照してください。
Important
ADR 統合と Microsoft がサポートする X.509 証明書管理を備えた Azure IoT Hub は パブリック プレビュー 段階であり、運用環境のワークロードには推奨されません。 詳細については、「 FAQ: IoT Hub の新機能」を参照してください。
公開キー 基盤 (PKI)
PKI は、デジタル証明書を使用して、デバイスとサービス間のデータを認証および暗号化するシステムです。 PKI 証明書は、Web やデバイス ID など、さまざまなシナリオをセキュリティで保護するために不可欠です。 IoT の設定では、PKI 証明書の管理は困難で、コストがかかり、複雑になる可能性があります。特に、デバイス数が多く、セキュリティ要件が厳しい組織の場合です。 証明書管理を使用すると、デバイスのセキュリティを強化し、完全に管理されたクラウド PKI サービスへのデジタル変換を高速化できます。
Microsoft 対 サードパーティのPKI
IoT Hub では X.509 証明書認証に対して 2 種類の PKI プロバイダーがサポートされていますが、現在、証明書管理は Microsoft が管理する (ファーストパーティ) PKI のみをサポートしています。 サードパーティ PKI プロバイダーの使用については、「 X.509 CA 証明書を使用したデバイスの認証」を参照してください。
| PKI プロバイダー | 統合が必要 | Azure Device Registry が必要 | デバイスプロビジョニングサービスが必要です |
|---|---|---|---|
| Microsoft が管理する PKI | No. Azure Device Registry で証明機関を直接構成します。 | イエス | イエス |
| サード パーティ PKI (DigiCert、GlobalSign など) | Yes. 手動統合が必要です。 | いいえ | いいえ |
X.509 証明書
X.509 証明書は、デバイス、ユーザー、サービスなどのエンティティの ID に公開キーをバインドするデジタル ドキュメントです。 証明書ベースの認証には、安全性の低い方法に比べていくつかの利点があります。
- 証明書では、公開キーと秘密キーの暗号化が使用されます。 公開キーは自由に共有されますが、秘密キーはデバイス上に残り、トラステッド プラットフォーム モジュール (TPM) またはセキュリティで保護された要素内に配置できます。 これにより、攻撃者はデバイスを偽装できなくなります。
- 証明書は証明機関 (CA) 階層を通じて発行および検証されるため、組織はデバイスごとにシークレットを管理することなく、1 つの CA を介して何百万ものデバイスを信頼できます。
- デバイスはクラウドに対して認証され、クラウドはデバイスに対して認証され、相互トランスポート層セキュリティ (TLS) 認証が有効になります。
- 証明書には有効期間が定義されており、一元的に更新または取り消すことができます。
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 証明書を発行します。 このプロセスにより、秘密キーの所有を証明できるデバイスのみが信頼できる証明書を受け取ることができます。
Device Provisioning Service での証明書署名要求の要件
証明書管理では、デバイスはプロビジョニングまたは再プロビジョニング中に CSP を送信します。 Device Provisioning Service (DPS) では、公開キー暗号化標準 (PKCS) #10 の仕様に従って、Base64 でエンコードされた識別エンコード規則 (DER) 形式の CSR が必要です。 この申請では、プライバシー強化メール (PEM) のヘッダーとフッターは除外されます。 CSR の共通名 (CN) フィールドは、デバイス登録 ID と正確に一致している必要があります。
認証と承認
認証 とは、IoT Hub に ID を証明することを意味します。 ユーザーまたはデバイスが主張する通りの存在であることを検証します。 このプロセスは、多くの場合、 AuthN と呼ばれます。
承認 とは、認証されたユーザーまたはデバイスが IoT Hub でアクセスまたは実行できることを確認することを意味します。 リソースとコマンドのアクセス許可を定義します。 承認は AuthZ と呼ばれることもあります。
X.509 証明書は、承認ではなく、IoT Hub での認証にのみ使用されます。 Microsoft Entra ID と Shared Access Signature とは異なり、X.509 証明書を使用してアクセス許可をカスタマイズすることはできません。