こちらの記事でDPSが何をしたい時に使うサービスなのかを書きました。
https://qiita.com/mstakaha1113/items/231c859d7427b466d4ad
またこちらでは、実際にデバイスとIoT Hubとの連携を体験しました。
https://qiita.com/mstakaha1113/items/1ccaaf445ea6f7ffd76c
今回は、IoT Hub Device Provisioning Service (DPS)の中の主な機能を、メニューからピックアップしてご紹介したいと思います。
今回ご紹介する機能
- 概要
- 共有アクセスポリシー
- リンク済みIoT Hub
- 証明書
- 登録を管理します
- 割り当てポリシーを管理します
概要
概要はAzureを使ったことがある方ならおなじみメニューです。
DPSでキーになるものは
- サービスエンドポイント
- グローバルエンドポイント
- IDスコープ
の3つです。
まずは全体像をご理解ください。
登場人物は以下のとおりです。
- デバイス：配布したデバイス(複数存在する)
- DPS：Device Provisioning Service(1つしか存在しない)
- サービス提供者：このIoTサービスを運用する人(みなさま？)
- IoT Hub：IoT Hub(複数存在する)
IoT Hubも同じ考え方なのですが、まずDPSを中心にして不特定多数の接続があるデバイス側と運用をつかさどる運用側に分けて考えます。
サービス提供者がDPSにアクセスする際に使うのが"サービスエンドポイント"、デバイスがDPSにアクセスする際に使うのが"グローバルエンドポイント"です。
サービス提供者は、例えばデバイス用にグループ登録を準備したり、デバイスの登録状況を確認したりします。
このような作業を実施するためのプログラムがアクセスするアクセスポイントが"サービスエンドポイント"になります。
デバイスは、実際にIoT Hubにアクセスするための情報を、DPSから取得します。
この時にアクセスするアクセスポイントが"グローバルアクセスポイント"になります。
グローバルアクセスポイントですが、これは世界で1つのアドレスになっています。だれがどこでDPSサービスを立ち上げても同じアドレスです。
このエンドポイントは全世界で冗長化されており、それを全世界の人が利用します。信頼性が高く、またコストも低く抑えられる仕組みです。
しかしグローバルエンドポイントは、誰からのどこ向けの依頼なのかを判断しなければなりません。
そこで扱われるのが"ID スコープ"になります。
この値だけは、各DPSごとに分割されています。
共有アクセスポリシー
サービス提供者側をプログラムで制御しようとした際に用いるキー情報です。
詳細はAzure IoT Hub Device Provisioning Service のアクセスを制御するをご確認ください。
リンク済みIoT Hub
DPSとIoT Hubのリンクを管理しています。
デバイスからの依頼を受けたDPSは、ここで関連付けられたIoT Hubに対してプロビジョニング作業を実施します。
証明書
DPSには3種類のデバイス認証手段が準備されています。
- 対象キー(文字列)
- X.509(証明書)
- TPM(ハードウェア)
また、デバイスの登録単位には
- グループ：複数デバイスを1つの証明書や対象キーで扱う
- 個別：デバイス単位に証明書や対象キーを準備する
の2種類が存在します。
この"証明書"は、"X.509"を用いて"グループ"登録を実施する際に利用します。
| グループ | 個別 | |
|---|---|---|
| 対象キー | ||
| X.509 | ここで使う | |
| TPM |
（ここらへんは"登録を管理します"にて少し掘り下げます）
X.509証明書を用いて認証する際は、この"証明書"のところにルート証明書を登録します。
登録時は
- 証明書をアップロードする
- 確認用コードを生成し"検証証明書"をアップロードする
という作業を行います。
使って良い証明書かどうかを確認している感じです。
この作業を"グループ"登録と分離することで、証明書に関する作業の煩わしい部分を分割しています。
<証明書のアップロードイメージ>
１．とりあえず証明書をアップロード
２．まだ認証されていない状態
３．本当に扱えるのか確認作業
４．認証されて使えるようになった
実際の運用でも、証明書の登録は誰でもやって良いわけではないと思いますし、いつかは証明書の更新作業等も発生すると思います。またデバイスの企画と製造が異なる会社であることは想定されますので、会社をまたいだ時には中間証明書を発行して、それを渡すのが適切な管理方法です。よって、このようなメニューの分割は適切だと思います。
登録を管理します
日本語訳が微妙ですが、そのままの機能です。
"証明書"にて少し触れましたが、デバイスのDPSへの登録は大きく５種類が存在します。
| グループ | 個別 | |
|---|---|---|
| 対象キー | ○ | ○ |
| X.509 | ○ | ○ |
| TPM | - | ○ |
TPMはハードウェアの機構を用いた認証ですので、こちらはグループによる登録は存在しません。
グループ登録
メニューは"登録グループ"ですが。。。
グループ登録は複数のデバイスで認証を使いまわします。こういう言い方をするとセキュアではない印象を与えてしまうかもしれませんが、そんなことはありません。十分にセキュアですし、問題が発生したデバイス(ID)は個別に利用不可にもできます。
何より、1つ1つのデバイスに対してバラバラの認証情報を書き込むという行為から解放されます。作業が楽になるということは、セキュアな状態を作り出すうえで大切です。
<グループ登録のイメージ(X.509 & 対象キー)>
個別登録
個別登録は、個々のデバイス用に認証情報を準備して登録するというものです。
そのままですので、説明は省略します。
デバイスの数がある程度限られていて、要件上個別に登録しなければならない場合は、こちらをご利用いただければと思います。
例えば医療機器とか、自社内で扱う工場用デバイスとか、そういう用途であれば良いと思います。
一般のコンシューマー向けに配布する場合は管理が煩雑になりますので、個人的にはあまりお勧めしません。
割り当てポリシーを管理します
IoT Hubにデバイスからの登録依頼を"割り当てる"ポリシーを管理します。
Webアプリの前に置くロードバランサ―みたいなものだと想像ください。
ポリシーは3つから選択します。
- 最短待機時間
- 加重が均等に分布
- 静的構成
いくつもの国をまたがるようなデバイスを一括で管理したい場合は"最短待機時間"をお勧めします。
IoT Hubを利用が想定される場所に近いリージョンに配置し、DPSとリンクし"最短待機時間"ポリシーを適用することで、デバイスが接続した時に近くのIoT Hubを勝手に選択して稼働し始めます。
もちろん、そうやっても大丈夫なバックエンドを作ってください。
日本でしか使わないけど、東西リージョンでDRを構える場合は、"最短待機時間"か"加重が均等に分布"をお勧めします。
デバイスの特性上、北海道なら東、沖縄なら西というのが良いバランスになるのであれば"最短待機時間"、バランスが悪ければ"加重が均等に分布"をお勧めします。
バックエンドが対応できない等、何らかの問題があるのであれば"静的構成"をお勧めします。
まとめ
今回は、理解しておくと楽になるDPSの主な機能をご紹介しました。
デバイスのスペック、数量、非機能要件、管理負荷、バックエンドの仕掛け等を考慮し、最適解を導き出していただけたらと思います。