Azure IoT Hub Device Provisioning Service (DPS)

解決する課題

工場出荷後に世界各地へ展開される大量の IoT デバイスを、人手で 1 台ずつ IoT Hub に登録することなく、初回起動時に自動で適切なハブへ割り当てて接続させるための、ゼロタッチ登録の仕組みを提供します。

• 数千から数百万台規模のデバイスを 製造時の情報だけで自動登録したい
• 各デバイスに 接続先の IoT Hub やキーを焼き込まずに出荷したい
• デバイスの所在地や属性に応じて 複数の IoT Hub へ振り分けたい
• 負荷分散や移行のために、デバイスの 接続先ハブを後から付け替えたい
• 個別の資格情報や証明書チェーンで なりすましを防ぎつつ大規模に展開したい

主要概念と用語

• DPS（Device Provisioning Service）: デバイスの初回接続を仲介し、適切な IoT Hub への登録と割り当てを自動化するヘルパーサービス。テレメトリは扱わず、登録だけを担う
• ID スコープ（ID Scope）: DPS インスタンスを一意に識別する値。デバイスはこの値とグローバルエンドポイントへ接続して登録を要求する
• 登録（Enrollment）: どのデバイスを受け入れるかを定義する設定。個別登録と登録グループの 2 種類がある
• 個別登録（Individual Enrollment）: 1 台のデバイスを単独で登録するエントリ。TPM 認証や単独デバイスに使う
• 登録グループ（Enrollment Group）: 同じ認証情報を共有する複数デバイスをまとめて受け入れる設定。X.509 中間証明書や対称キーのグループに使う
• 証明書の構成証明（Attestation）: デバイスの正当性を確認する方式。X.509 証明書・TPM（エンドースメントキー）・対称キーの 3 つがある
• 割り当てポリシー（Allocation Policy）: 複数の IoT Hub が候補のとき、どのハブへ割り当てるかを決める規則（最小負荷ハブ・静的・ハッシュ・カスタムなど）
• 再プロビジョニング（Reprovisioning）: デバイスが再度 DPS に接続した際の振る舞い。接続先ハブの再評価や移行に使う
• カスタム割り当てポリシー: Azure Functions などで独自ロジックを実装し、属性に応じてハブを動的に選ぶ仕組み

仕様・制限・クォータ

• 役割: DPS はあくまで初回登録の仲介役であり、テレメトリや C2D メッセージは扱わない。接続後の通信は IoT Hub が担う
• 構成証明の方式: X.509 証明書・TPM・対称キーの 3 方式に対応する。グループ単位の登録は X.509 中間証明書または対称キーで構成する
• 複数ハブのリンク: 1 つの DPS に複数の IoT Hub をリンクでき、割り当てポリシーで振り分けられる。地理分散や負荷分散に使う
• 登録数・スループット: 登録エントリ数や 1 分あたりの登録操作数には上限があり、リージョンや構成で変わる。大規模な一斉登録時はスロットリングに注意する
• グローバルエンドポイント: デバイスは固定のグローバルデバイスエンドポイントへ接続し、ID スコープで自身の DPS を特定する
• 具体的な上限値・単価はリージョンや時期で変わるため、最新の公式情報で確認する

内部の仕組み

デバイスは出荷時に ID スコープとグローバルデバイスエンドポイント、そして自身の構成証明情報（証明書や対称キーなど）だけを持って起動します。初回接続時、デバイスは IoT Hub ではなく DPS のグローバルエンドポイントに対して登録を要求します。

DPS はデバイスの構成証明を検証し、対応する **登録（個別登録または登録グループ）**を探します。一致すれば、リンクされた候補の IoT Hub の中から 割り当てポリシーに従って 1 つを選び、そのハブにデバイス ID を登録します。最後に DPS は、割り当てられたハブの接続情報をデバイスへ返します。

デバイスは返された接続情報を保存し、以降は 直接その IoT Hub に接続します。つまり DPS が経路に入るのは初回登録時だけで、平常時のテレメトリは DPS を通りません。負荷分散や移行が必要になったときは、再プロビジョニングでデバイスを再度 DPS に接続させ、割り当て先ハブを再評価して付け替えられます。

設計パターン / ベストプラクティス

• 登録グループで一括受け入れ: 同一機種を大量展開するなら、X.509 中間証明書か対称キーの登録グループでまとめて受け入れ、1 台ごとの個別登録を避ける
• 証明書チェーンで安全に配布: 製造ラインで各デバイスにリーフ証明書を発行し、中間証明書を DPS の登録グループに登録して信頼チェーンで検証する
• 地理分散は割り当てポリシー: 複数リージョンの IoT Hub をリンクし、最小負荷ハブや静的割り当て、ハッシュで近接ハブへ振り分ける
• 動的な振り分けはカスタム割り当て: デバイスの属性やペイロードに応じてハブを選びたい場合は、Azure Functions のカスタム割り当てポリシーで実装する
• 移行・再分散は再プロビジョニング: ハブの統廃合や負荷の偏りには、再プロビジョニングでデバイスを別ハブへ付け替える
• 資格情報はデバイス固有に: 登録グループでもリーフ証明書はデバイスごとに固有とし、漏洩時に個別失効できるようにする

運用・監視

• Azure Monitor のメトリクスで、登録の試行数・成功・失敗を監視し、一斉登録時のスロットルや認証失敗を早期に検知する
• 登録の失敗ログで、構成証明の不一致や無効化された証明書による拒否を追跡する
• 診断設定でログを Log Analytics へ送り、デバイス単位の登録履歴と傾向を分析する
• 個別登録・登録グループの無効化で、廃棄や漏洩したデバイス群の受け入れを止められるようにしておく
• 大量の一斉起動が見込まれるときは、登録のスループット上限を踏まえて 段階的にロールアウトする

コスト

課金は主に 登録に成功した操作の数に基づきます。テレメトリ量とは独立しており、登録は基本的に初回と再プロビジョニング時に発生するため、平常運用での課金は限定的です。大量のデバイスを一度に登録する初期展開時にコストが集中する点を見込んでおきます。

セキュリティ

• 構成証明: デバイスの正当性を X.509 証明書・TPM・対称キーのいずれかで検証する。大規模・高セキュリティでは証明書ベースを推奨
• 信頼チェーン: 登録グループでは中間証明書を登録し、製造時に発行したリーフ証明書を チェーンで検証してなりすましを防ぐ
• 資格情報の焼き込み回避: デバイスには接続先ハブやハブのキーを焼き込まず、ID スコープと自身の証明書だけを持たせて出荷する
• 個別失効: 漏洩・廃棄に備え、登録エントリやデバイス証明書を 個別に無効化できるようにする
• 転送の暗号化: 登録時の通信はすべて TLS で保護される
• マネージド ID と Entra ID: カスタム割り当ての Functions などからの接続はマネージド ID を使い、接続文字列のハードコードを避ける

関連サービス・比較

DPS は AWS の IoT フリートプロビジョニングに相当し、大量デバイスの初回登録とハブ割り当てを自動化します。テレメトリと双方向通信そのものは Azure IoT Hub が担うため、両者は組み合わせて使います。主な対応関係を示します。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# DPS インスタンスを作成
az iot dps create \
  --resource-group demo-rg \
  --name demo-dps-0628 \
  --location japaneast

# 既存の IoT Hub を DPS にリンク（割り当て候補にする）
az iot dps linked-hub create \
  --dps-name demo-dps-0628 \
  --resource-group demo-rg \
  --connection-string "<iot-hub-connection-string>" \
  --location japaneast

# 対称キーの個別登録を作成（自動生成キーを利用）
az iot dps enrollment create \
  --dps-name demo-dps-0628 \
  --resource-group demo-rg \
  --enrollment-id sensor-001 \
  --attestation-type symmetricKey

# 登録の状態を確認
az iot dps enrollment show \
  --dps-name demo-dps-0628 \
  --resource-group demo-rg \
  --enrollment-id sensor-001