IoT Hubへ接続するときの認証やキーなど

2017年に書いた「Azure IoT HubのSASトークンについて」が、いまでもまぁまぁなアクセス数があります。

matsujirushi.hatenablog.jp

Azure IoT SDKsを使わずに、Azure IoT HubにMQTT, AMQP, HTTPSなどで接続するにはSASトークという文字列を渡さなければいけないのだが、このSASトークが一体何者か良く分からない。

この記事では、SASトークにフォーカスして書いていましたが、、、
2年経って、ようやく理解できた(!)ので、少し広い視野で、IoT Hubへ接続するときの認証やキーなどを、体系立てて書いてみたいと思います。

対象読者

本記事は、IoT Hubに接続するデバイスの開発者を対象にしています。特に、Azure IoT SDKを使わずにMQTTやAMQP, HTTPSプロトコルでIoT Hubに接続しようとしている方に有用です。クラウドサービスやツールの開発者にも、多少参考になるのではないかと思います。
IoT Hub Provisioning Serviceは(認証の動きが違うので)対象外です。(別記事で書きたいとは思っています。)

IoT Hubを操作できるヒト、モノ

IoT Hubを操作できるヒトやサービス、モノは、共有アクセスポリシーもしくはセキュリティ資格情報のどちらかに登録されていなければいけません。

厳密には例外もありますが、最初は細かいことは気にしない方が理解がしやすいです。

初っ端から「共有アクセスポリシーって何???」ですが、ここはグッとこらえてください。(用語は慣れて覚えるしかないのです、、、)

共有アクセスポリシーは、IoT Hubの共有アクセスポリシー画面に表示されるポリシーで、ポリシー名とアクセス許可(画面上は権限と表記)を登録します。デフォルトで5つのポリシーが登録されています。

セキュリティ資格情報は、IoT HubのIoTデバイス画面に表示されるデバイスで、デバイスIDを登録します。アクセス許可は登録されていません。

f:id:matsujirushix:20191231100821p:plain

共有アクセスポリシーには、ポリシー毎にアクセス許可を設定することができ、不用意な操作や悪意のある操作を防ぐことができます。たとえば、IoT HubのD2Cメッセージを受け取ってグラフ表示するサービスには、サービス接続のみをアクセス許可します。

セキュリティ資格情報のアクセス許可はデバイス接続のみです。アクセス許可を明示的に設定、変更することはできません。

f:id:matsujirushix:20191231101652p:plain

一般的には、ヒトやサービスは共有アクセスポリシーを使い、デバイスはセキュリティ資格情報を使います。セキュリティ資格情報の画面が「IoTデバイス」になっていることからも想像つきますね。

キー

ヒトやサービス、モノが、どの共有アクセスポリシーもしくはセキュリティ資格情報に対応しているかは、対応したキーを持っているかどうかで決まります。

雰囲気、自動車免許証番号のようなものです。自動車免許証番号123456(キー)は普通車を運転してもOK(アクセス許可)といった感じのものです。

IoT Hubでは、キーは1種類ではなく、共有アクセスキー対称キー、(X.509証明書の)秘密キーの3種類あります。

f:id:matsujirushix:20191231103106p:plain

共有アクセスキーと対称キーはIoT Hubが生成するので、それをサービスやモノに入れます。秘密キーを使う場合はIoT Hub外で生成します。

認証

IoT Hubにヒトやサービス、モノが接続したとき、それが何か?を判断するのに認証という手続きをします。

さきほどのキーを持っているか否か?で、対応する共有アクセスポリシーもしくはセキュリティ資格情報を判断するわけですが、キーをそのままネットワークに流してしまうと、キーが複製されてしまう危険性があります。

そこで、キーから(不可逆な)セキュリティトークを生成して、それをネットワークに流すことで、セキュリティを担保しながらキーを持つ相手だということを確認できるようにしています。

ここでいうセキュリティトークン、こ・れ・が、つまりSASトークン(Shared Access Signature Token)です。

f:id:matsujirushix:20191231111015p:plain

セキュリティトークンの生成

セキュリティトークンは、
共有アクセスキーの場合は、

  • 共有アクセスポリシー名
  • 共有アクセスキー
  • リソースURI
  • 有効期限

から、

対称キーからの場合は、

  • 対称キー
  • リソースURI
  • 有効期限

から、SHA256を使って生成します。

f:id:matsujirushix:20191231111528p:plain

f:id:matsujirushix:20191231111553p:plain

で、結局どうやるの?

一例として、デバイスで対称キーの場合を示します。

  1. IoT HubのIoTデバイス画面で、デバイスを追加する。(セキュリティ資格情報)
  2. 追加したデバイスの詳細画面から、主キー(対称キー)をコピーする。
  3. 対称キーをデバイスに保存する。
  4. 保存した対称キーから、セキュリティトークンを生成する。
  5. セキュリティトークンを使ってIoT Hubに接続(認証)する。

4.のセキュリティトークンはドキュメントにあるとおり、デバイスエクスプローラやaz iot hubコマンドなどで生成できますが、、、
セキュリティトークンはネットワークに流れることから、プログラムで有効期限を短いものを定期的に生成したほうが安心です。

状況に合わせた選択を

以上から、

  1. 対称キーからツールで生成したセキュリティトークンを使用
  2. 対称キーからプログラムで定期的にセキュリティトークンを生成して使用
  3. X.509証明書を使用

ぐらいが選択肢です。
開発、リリースの状況に合わせて選びましょう。

常時接続デバイスの場合、2.は期限切れのときに再接続を考慮しないといけないのでご注意を。

開発時にパッと試すだけなら1.、製品として販売するときは3.をオススメします。