今後ウェブアプリケーションの機能としてIoT連携は一気に増えてくることだろうと予想しています。そのためIDaaSでIoT機器(デバイス)も安全に管理していきたいところです。
こんな要件があるとします:
- ユーザーは複数のIoT機器を持っていて、ユーザーの携帯とIoT機器はLAN(家庭内ネットワーク)で繋がっている。
- ユーザーは携帯にインストールされた管理アプリケーションから各機器を操作できる。
- 操作した内容はインターネット経由でウェブAPIに送信され、家の外にいてもウェブブラウザから機器の状態を閲覧できる。
この記事では実際に構築まではしませんが、文中の用語の統一をしたいため要件に一番マッチしそうなCIAMに特化したAuth0に構築すると仮定します。
Auth0視点でアプリケーションを見ると、大きく3つの登場人物がいます。
この要件を実現する方法はいくつかありますが、ぱっと思いつくのは次の構成ではないかと思います。
図のようにそれぞれの機器をIDaaS上ではなくアプリケーション側で個別管理する方法です。
これでも十分なのですが、認証周りをIDaaSに任せたいのでこの機器をAuth0上で管理したいとします。
Auth0で機器を管理する方法は2つ考えられます。
1つは公式のブログで紹介されているように、機器をアプリケーション(M2M)として管理する方法です。
The rise of Internet of Things devices makes a great case for machine to machine solutions. Many (if not most) of IoT devices are small, autonomous, specialized devices that collect and send data to a server. Let’s say you have a fleet of small IoT devices that you use to collect data on the number of cars that are parked in your parking lot. You have many devices that are continuously reporting data to a central server. These devices communicate over WiFi. To avoid intrusions, and even though your WiFi network is password protected, you use the client credentials grant, giving each IoT device its own client ID and client secret. These devices are trusted: you set them up and no-one else can interact with them.
DeepL翻訳:
モノのインターネット（Internet of Things）デバイスの台頭は、Machine to Machineソリューションの素晴らしい事例となっています。IoTデバイスの多くは（ほとんどとは言わないまでも）、データを収集してサーバーに送信する、小型で自律的な専用デバイスです。例えば、駐車場に停まっている車の台数のデータを収集するために使用する小型のIoTデバイスの一団があるとしましょう。多くのデバイスが、中央のサーバーに継続的にデータを報告しています。これらのデバイスはWiFiで通信します。侵入を防ぐために、WiFiネットワークがパスワードで保護されている場合でも、クライアント・クレデンシャル・グラントを使用して、各IoTデバイスに独自のクライアントIDおよびクライアント・シークレットを与えます。これらのデバイスは信頼されており、あなたが設定し、他の誰も彼らと対話することはできません。
機器のライフサイクルがその他アプリケーションのように長く、誰かの持ち物ではなくグローバルなものだという要件の元ではM2Mは最適でしょう。
ですがこの方法には冒頭の要件を満たしたいとした場合、以下の不都合がありそうです:
- M2Mアプリケーションとして登録すると、機器がどの利用者の持ち物であるかを判断しにくい。利用者と機器を紐付けるためのデータストアが別途必要になる。
- 機器のパスワードであるクライアントシークレットをAuth0の管理者に知られてしまう。機器は利用者のものなのでパスワードは知られないようにしておきたい。
これらが問題かというとそうでもありませんが、要件を満たすには別のアプローチが良さそうです。
次に思いつくのは、機器をIDaaSの第一級市民であるユーザーとして扱うという方法です。
機器がユーザーとして管理されると、以下のメリットが考えられます:
- 利用者自身がAPIにアクセスしたのか、機器によってアクセスされたのかをユーザーの属性で判断できる。
- 機器に付与するロールと利用者のロールを違うものにすることで、機器しかアクセスできないAPIの提供といった仕様を認可レイヤーで制御できる。
- ユーザーメタデータに機器の情報を保存できるため、利用者との紐付け情報をもたせることができる。
- 管理画面上で機器ごとの最終ログイン日時といった情報を閲覧できたり、Hook(Auth0でいえばActions)のスクリプトで柔軟に制御できたりと、ユーザーとして扱うことによる付加価値が多くある。
多くのIDaaSはユーザー数課金のため、機器の数に応じて金額がかさむのは気になるところですが、IDaaSを利用するセキュリティリスクの軽減と、上のメリットから派生する実装コスト削減を考慮すると悪くはないのではないかと思います。
今後の設計の参考に。
この記事は IDaaS Advent Calendar 2022 4日目の投稿です。
IDaaSを利用したアプリケーション開発にお悩みの方は弊社TC3までお問い合わせください。また、優秀なアーキテクトからの応募も常時受け付けています。