こちらはSORACOM Advent Calendar 2020 14日目の記事です。

昨日は@n_mikuniさんによる目薬カウンターをつくる話でした。Orbitを使ってタグと連携してHarvestに入れるデータを作る、というのはいいですね！LagoonがあるのでHarvestにデータを入れたいけど、既製デバイスで送るデータ弄れない、なんて時に使える方法だと思いました。

はじめに

SORACOMのSIM認証については、いつか書きたいと思っていました。

IoTにおいては、デバイスはクラウドにつながることで、クラウドはデバイスにつながることで価値を出します。デバイスはクラウドにつながることでいつでもどこでも可視化できるようになったり、遠隔から管理したりすることができますし、クラウドはデバイスとつながることで現実世界の状況を把握したり、また現実世界に影響を及ぼすことができるようになります。

ところが、このデバイスとクラウドの接続、というのは思ったより簡単ではなく、IoTにおける大きな課題の一つになっています。下手に作るとセキュリティ的に大きな問題が出たり、生産や運用に大きな負担がかかったりします。SORACOMのSIM認証は、IoTにおいてデバイスとクラウドをシンプルに、かつ安全に接続するための有効な手段です。IoTにおけるブレイクスルーの一つと思っています。

SIM認証はSORACOMの中核の技術ですし、これを知っているのと知らないのとでは設計が大きく変わりますので、SORACOMユーザーのみならず、IoTに関わる皆さんにはぜひ知っておいてもらいたいものです。知っていれば、IoTの多くのケースで設計・実装をシンプルに、開発・運用を楽にでき、開発スピード、セキュリティ、生産に関わる課題など、全体的なレベルが底上げされます。もちろん様々な制約から使えないケースもあるとは思いますが、知っていてやむなくそうなるのと、知らないでそうなってしまうのとでは全然違いますからね。

この記事ではそのSIM認証の魅力と実際の使い方をお伝えできればと思います。何か変なところがあればお伝えください。

デバイス認証とは

IoTシステムにおいて、デバイスはクラウドサービスに接続し、データをアップロードしたり、設定をダウンロードしたり、クラウド上で機械学習などの高度な処理を実行させたり、遠隔操作を受けたりします。
この時、クラウドシステムは接続するデバイスを認証する必要があります。

認証とはどんな意味でしょうか？
代表的な説明として、ISO 27000(情報技術−セキュリティ技術−情報セキュリティマネジメントシステム−用語)における定義を参照しておきます。
https://kikakurui.com/q/Q27000-2019-01.html

3.5 認証（authentication）
エンティティの主張する特性が正しいという保証の提供。
注記エンティティは，“実体”，“主体”などともいう。情報セキュリティの文脈においては，情報を使用する組織及び人，情報を扱う設備，ソフトウェア及び物理的媒体などを意味する。

ちょっと難しいですが、名乗っている通りのもの(ユーザーやデバイスやプログラム)であることを保証する、ということですね。

たとえばシステムにログインする時にユーザー名をAdministratorとしてアクセスした時、本当にその人はAdministratorなのか？ということを確認します。ユーザー認証の場合はパスワードを知っているか確認し、正しいパスワードを知っていたらAdministratorだと判断します。

より実際の使用に即して考えると、以下の２つを確認していることになります。

正当な利用者であるか
誰 / 何であるか

ユーザーの認証であればAdministratorとUserは正当であることを確認した上でそれぞれ区別されるべきでしょうし、デバイスの認証であればTemparatureSensorとHumiditySensorは同じく正当でありかつ区別されることが期待されます。

この認証というものは、セキュリティ上めちゃくちゃ重要です。どんなに強固なシステムであっても管理者になりすまされてしまえば意味がありませんし、ほかのデバイスを偽って間違ったデータを上げられると、解析や制御が狂ったりもします。

世の中で起きているセキュリティ攻撃の多くは認証を突破しようとするものです。多数のパスワードを試したり推測したり盗聴したり、などですね。そのため、長くて複雑なパスワードを強制するようにしたり暗号化したり複数の認証方法を組み合わせたり、など、様々な対策で認証を破られないようにします。

通常のITシステムだとユーザーを認証して使う必要がありますが、IoTの場合はさらにデバイスを認証する必要があります。ただ、ユーザーの認証に比べてデバイスの認証は難しいんですよね。

もちろん通常のITシステムにおいてもユーザー認証は課題であるのですが、PCやスマートフォンなどを操作できる人がいるのであればパスワード認証や多要素認証が使えますし、何かトラブルがあっても、たとえばパスワード再発行などで対応できます。また、この方法はすでに様々なサービスやフレームワークで対応されていて導入もしやすいでしょう。人間が使用するPCやスマートフォンは認証に必要な暗号化などの処理を行うのに十分な性能を持っていることも期待できます。

一方でデバイスは入力や表示装置がない場合もあり、人がいない前提で動かないといけないものもあり、コストや電力の関係で十分なCPUパワーがない場合もあります。ITシステムで培われてきた資産がそのまま使えないことも多いです。

それで、IoT導入したいけどデバイス認証わからん、となったり、認証なしで作っちゃってあとで困る、ということになったりするのですね。

デバイス認証情報の課題

特に問題になるのは、認証情報をどうやって持たせるか、というところです。大きく以下の３点が課題となります。

人間が都度認証情報を入力できないケースが多い
共通の認証情報書き込みはセキュリティ的に問題あり
デバイス固有の認証情報の書き込み、管理するのは大変

まずIoTデバイスは人間が認証情報を入力してくれることをあてにできないケースが多いです。単純なセンサーデバイスだと表示装置や入力装置がなくそもそも入力できないこともありますし、人がいないところで長期間動作しないといけないものもあります。起動するたびに入力を必要とするというのは現実的ではないでしょう。

とすると、認証情報はデバイスに書き込む必要があります。簡単なのは共通の認証情報を書き込むことですが、この場合セキュリティ的に問題になります。正当な利用者であることは一応確認できますが、デバイスを識別することができません。また、何かの原因で認証情報が漏洩した場合、不正使用のリスクに晒されることになるため一刻も早く無効にしなければなりませんが、共通の認証情報を使っている場合すべてのデバイスが使用不可能になってしまいます。不正使用のリスクを承知の上で使い続けるか、全滅覚悟で無効にするかの二択なんてしたくありません。ということで、共通の認証情報を書き込む方法はセキュリティ上採用すべきではないですね。

となると、デバイス個別に認証情報を書き込むしかありません。
具体的には、事前に発行したデバイス用のIDとパスワードを書き込むか、TLS相互認証用のX.509証明書と秘密鍵を書き込むケースが多いと思います。でもこれって結構大変なんですよね。

まずデバイスは基本的には量産されるものです。量産されるということは、同じ物として生産されるということです。デバイスごとの個体差なんて、可能な限り排除したいんです。せいぜい製造番号くらいでしょうが、これも基本的には機能・性能には関係なく、あとからシール貼り付けるくらいにしたい。そこにデバイス固有の認証情報を間違えないように書き込む、だと？生産技術担当にぶっ飛ばされそうですよね。

生産ラインがインターネットにつながっていないこともあり得ます。むしろつながっていない方が多いんじゃないかな？IoTデバイスに必要なのはクラウドに接続するための情報なので、基本的にはそのクラウドシステムにアクセスしないと発行できないのですが、インターネットにつながっていない生産ラインでは発行できません。この場合は、どこか他のところで発行して、生産ラインに持っていくしかないです。生産を外部委託している場合などでは会社をまたぐこともあり得ます。間違えないように書き込むハードルが格段にあがりますね。また、生産ラインで書き込む場合生産部署や生産委託先はそのデバイス情報を知り得ることになります。不正が起こらないかな？ちょっと心配ですよね。

認証情報をどのように保存するか、という問題もあります。通常はSSDや内部のMMCなどのストレージデバイスに保存されることになるかと思いますが、何らかの方法でデバイスにログインしたり、ストレージデバイスを直接取り出して読み出す、などの方法で盗み出されてしまうリスクはあります。暗号化して保存すればリスクを小さくできますが、人間がいないところで立ち上がって自動で動作しないといけない関係上暗号鍵を外部から入力できないので、結局はデバイスのどこかに暗号化のキーを保存しておく必要があり、その部分も含めて解析されればやはり盗まれてしまいます。認証情報が取得されてしまえば、制限のないPCなどからの不正使用もできるようになってしまいます。

また、デバイスの認証情報を更新できるようにしないといけないケースがあります。万が一認証情報が漏洩した場合はやらなければなりませんし、一定期間での認証情報の更新が規格で求められる場合もあります。今はなくても今後必要になる、ということも十分考えられます。でも認証情報の更新って危険なんですよね。たとえば更新中に何らかのエラーが発生したり、電源遮断されたりすれば、更新失敗で新旧両方の認証情報が消えてしまうかもしれません。IoTは通信や電源、動作環境がどうなってるかは不明なケースが多いので、何があっても不思議ではないです。クラウドにつながってさえいればリモートメンテナンスもできましょうが、繋がらなくなってしまったらどうしようもありません。そうならないように最大限の工夫はするでしょうが。。万全を期してもやらかすときはやらかします。そういう危険な処理はできるだけしたくない。

そういった色々な課題があるため、IoTにおけるデバイス認証情報の発行には様々なパターンが用意されています。
代表的な例としてAWS IoTをあげると、デバイス個別の証明書発行専用の共通証明書を用意しておき、共通証明書を使ってデバイス個別の証明書を発行する(必要なければ共通証明書を削除する)といったこともできます。

2020年時点におけるAWS IoTの証明書発行については以下のスライドで説明されています。100枚を超えるボリュームの資料で、大きく７種類の方法が提供されています。それだけIoTにおけるデバイス認証情報の発行は大きなテーマなんですね。場合に応じて最適なパターンを選びますが、それでも事前準備や生産、運用のどこかのポイントで負荷がかかることになります。
https://www.slideshare.net/AmazonWebServicesJapan/aws-iot-238410980

長々と書いてしまいましたが、結局言いたいことはIoTのデバイス認証ってなんか大変だよね、ということです。
セキュリティに関わるところですし、運用の負荷を大きく左右するところなのでいい加減にはできないのですが、ここに時間をかけて本来IoTでやりたいことの実現が遅くなってしまうのも問題です。

簡単にできて、かつセキュリティが高く、運用負荷も小さくできる、そういうデバイス認証方法がないかな？と思うところなのですが、あります。
それがSORACOMのSIMによるデバイス認証です。

SIMによるデバイス認証

SIMによるデバイス認証とは何か？といえば、3GやLTEなどのセルラー通信で必要になるSIMによる認証を、ほかのアプリケーションやクラウド利用の認証にも使えるようにする、というものです。
セルラー通信を使う限りはSIMによる認証はされているのでそれ以上何かを準備する必要もなく、セルラー通信の高いセキュリティレベルが確保でき、SORACOMによる回線管理とデバイスの管理を統合できるため運用負荷も下げることができいます。

もう少し詳しく説明します。

SORACOMの基本となるサービスはSORACOM Air、セルラー通信による接続を提供するサービスです。(SigfoxやLoRaWANなどのLPWA通信による接続もありますが割愛します)

セルラー通信にはSIM(Subscriber Identity Module)というデバイスが必要になります。カードとして提供されることが多いですが、最近はチップで提供されることもあります。

セルラー通信にSIMが必要というとSIMが電波を出しているのか？と思われるかもしれませんが、そうではありません。電波を出しているのはモデムと言われるデバイスです。(これも正確ではないのですがややこしくなるので省略)

ではSIMは何をするためのものなのか？というと、名前の通り加入者(Subscriber)を識別(Identity)するためのものです。つまり認証のためのデバイスなんですね。

セルラー通信には認証が必須です。わかりやすいように電話番号で考えてみます。090-1111-2222から090-3333-4444に電話をかけたとします。この時以下のような点が要求されるでしょう。

090-1111-2222からの発信を090-3333-4444が着信すること(他はこの電話を取れない)
090-1111-2222の話した内容が090-3333-4444に聞こえ、逆に090-3333-4444の話した内容が090-1111-2222に聞こえること
電話の内容が他の電話機などで聞くことができないこと

すごく当たり前ですね。当たり前なんですが、これを実現するのは大変です。

まず携帯電話の回線事業者は、かかってきた電話が確実に090-1111-2222からの発信であることを確認できなければなりません。
また、090-3333-4444に電話をつながなければならず、そのためにはその電話機が現在どの基地局とつながっているかを把握していなければなりません。
他の電話機では取れない、盗聴もできないよう、その電話機と基地局との間で暗号通信ができなければならず、そのためには暗号パラメータを事前に共有しておかなければなりません。

この要求を実現するためには２つの要素が必要であり、一つは回線事業者がもつデータベース(3GではHLR、4GではHSSと呼ばれる)、もう一つは電話機に入っているSIMです。HLRの中には加入者ID(IMSI)や加入プラン、現在接続している基地局などの情報のほか、電話機を認証するための情報が保存されています。一方でSIMにも同じIMSIと秘密情報が保存されています。SIMは耐タンパー性に優れたセキュリティチップで、この中に入っている情報は直接読み出せず、チップを分解するなどの方法でも読み出すことが非常に困難であり、複製も難しいようになっています。そのため普通のストレージに保存するよりはるかに安全に秘密情報を持たせることができます。

セルラー通信では基地局に接続する際にSIM内にある秘密情報を用いてHLRに対して認証を行い、正当な加入者であることが確認できたら通信が許可される、という仕組みになっています。この際にセルラー通信の暗号化を行うためのパラメータの共有もされており、認証ができたら暗号通信もできるようになっています。詳しい仕組みは3GPPの規格に記載されていますので、興味ある方は以下を確認していただければと思います。
https://www.etsi.org/deliver/etsi_ts/133100_133199/133102/11.05.01_60/ts_133102v110501p.pdf

このような形で、セルラー通信ではすでに世界中で使われていても問題にならないレベルのセキュリティでの認証がすでにされています。(これに問題あったら携帯通信ができない)SORACOMの様々なサービスは、このSIMによるデバイス認証を利用することにより、使用の簡単さと高いセキュリティを両立させているわけです。

SORACOMとSIM認証

SORACOMはリリース時点からこのSIM認証を特徴としていました。
具体的にはSORACOM Beamというサービスです。
https://soracom.jp/services/beam/

これはbeam.soracom.ioに対して暗号化していないHTTPやTCP、UDPで通信すると、SORACOM内で暗号通信であるHTTPSに変換され、かつSIM認証で確認されたIMSIとそれを検証するための署名をHTTPヘッダにつけた状態で指定したサーバーに転送できる、というものです。

サーバーに対する認証は必要なく、HTTPにCookieやトークンをつける必要もありません。このため、シンプルに送信したいデータを送るだけでよくなっています。これは特にマイコンなどCPUパワーが貧弱なデバイスや電力消費を抑えたいデバイスで効果が高いですが、そうでなくてもデバイス内にサーバーに対する認証情報を持たずに済ませられる点が非常に重要です。

実際使ってみると実に便利なんですよね。認証情報を個別に用意して書き込む必要は無くなりますし、サーバーに対する接続設定などはすべてクラウド上のSORACOMに対してすれば良くなります。デバイスに対して遠隔で設定するのは大変ですが、クラウド上であれば簡単に設定できます。

これがリリース時点で出ていたことが今から見ても驚きです。リリース時にはMVP(Minimum Viable Product：実用最小限の製品)を出せ、と言われますが、まさにそのお手本と思います。SORACOMが単に安い回線だというだけではなく、今までの他のサービスと違ってIoTの大きな課題を解消しうるものである、ということが明確にわかるサービスだと思います。

すごく便利なので、今後はSORACOMに限らずIoT用の回線は皆こんな感じになっていくんだろうな、と思っていました。でも、多分僕の知る限りは今のところSIM認証を利用できるIoT回線サービスはSORACOM以外には見当たりません。

いくつか理由があると思うのですが、SORACOMはパケット交換を自社開発のソフトウェアで実施していて自由が効く、という技術的な面と、回線の管理やクラウドサービスとの連携などの設定をユーザー側に開放してくれている、というプラットフォーム戦略的な面が大きいのかなと思っています。SIM認証ができてもそれが任意のサービスと結び付けられないと意味ないですからね。

このあたりのSIM認証、シンプルなインターフェースで様々なサービスに連携可能、ユーザーがコンソールやWebAPIで自由に回線やそれに付随するサービスを管理可能、といった特長が組み合わさって、IoTプラットフォームとしてのSORACOMの魅力を作り上げているのかな、と思っています。

SORACOM使える前提でサービス設計するとすごく簡単になってしまって、他の回線使う場合とのギャップが大きくなりすぎることだけが問題かな。。

SIM認証によるサービス使用のパターン

ここから具体的な話をします。
僕はSIM認証によるサービス利用のパターンを以下の4パターンに分類しています。(ソラコムによる分類ではないです)

ソラコム自身のサービスを使うもの
ソラコムに外部サービスの認証情報を保存して連携するもの
外部サービスの認証情報を生成するもの
認証されたデータを作成するもの

どんなものなのか、見ていきましょう。

1. ソラコム自身のサービスを使うもの

SIM認証のパターンその1はSORACOM内のサービスを使うパターンです。
SORACOMサービスはSIM認証で識別された通信を受け取って、そのままサービス提供します。

このパターンの特長はとにかくシンプルだということです。
事前の設定はON/OFF以外必要ありません。

以下、具体的なサービスで説明します。

設定を読み込ませたい時はSORACOM Air メタデータサービス

デバイスに動作などの設定をさせたい要求は普通にあると思います。
たとえばセンサー値の種類や取得・アップロード間隔などですね。
この時使用を検討すべきはSORACOM Air メタデータサービスです。
https://dev.soracom.io/jp/start/metadata/
なんと無料です。

SORACOMでは、SIM個別に名前やタグ、またSIMのグループに共通のデータをつけることができます。
この情報を、SORACOMで通信しているデバイスから取得できる機能がSORACOM Air メタデータサービスです。

使い方は簡単で、以下のURLに対してHTTPアクセスするだけです。
http://metadata.soracom.io/v1/subscriber

これでSIMの識別IDであるIMSIやSIMにつけた名前、任意につけたタグを読み出すことができます。
グループ共通の情報を読み出す際は以下のURLです。
http://metadata.soracom.io/v1/userdata

デバイスの設定はこのようにタグやユーザーデータに保存しておき、メタデータサービスで読み出すのがいいでしょう。この構成の良いところは、同じURLでアクセスしてもそのSIM固有の情報が読み出せることです。デバイス固有の情報はすべてSORACOM上に持たせることができ、デバイス内に持たせる必要がなくなります。これはデバイスがステートレスになり、交換可能になることを意味します。

上の方で、デバイスは同じものとして量産し、個別の情報は持たせたくない、という話をしました。SIM認証が使えるSORACOMだと認証情報をデバイス個別に持たせる必要はありません。さらに突き詰めると、デバイスの設定をSORACOM内に持たせておけば、デバイスに持たせておく必要がなくなります。

これにより何が実現できるのか？それは交換可能なデバイスです。デバイスに個別に設定がされていると、交換しても同じようには動かないので、交換するデバイスには交換する先と同じ設定をしてから交換する必要があります。これだと短時間で誰でも交換できる、というわけにはいかないですよね。デバイスにライセンス情報などが書かれている場合は尚更です。一方、設定がすべてSORACOMのSIMに結び付けられている場合はどうでしょうか。メタデータから設定を取得するようにすると、新しいデバイスにSIMを入れ替えるだけで以前と同じ設定で動作します。これだけであれば誰でも交換できそうですよね。(SIMも壊れた場合に備えるには同じ設定がされたSIMを用意する必要がありますが)

これは僕が勝手に言っているだけではなく、SORACOMのリファレンスデバイスであるGPSマルチユニットでも同様の構成が取られています。設定はユーザーデータに入っていて、それを読み出して動作するので、SIMを入れ替えると入れ替えたSIMの動作になります。

これはクラウドが出てきてから言われるようになった、サーバーはペットのように扱わず、家畜にように扱え、という考えと同様のものです。ハードウェアはいつ壊れるかわかりません。そんな時にすぐに交換できる体制になっていれば、運用の負担を減らせることは間違い無いです。SORACOMを使う場合は設定をメタデータにおき、デバイスには情報を持たせない状態にできないか考えてみましょう。（メタデータはあまり大きなデータを持たせられないので、設定が大きくなる場合は後述のSORACOM Harvest Filesを使いましょう）

SIM認証なしで同じことを実現しようとすると、認証のための仕組みの他に、設定を持つデータベースや自デバイス以外の情報を取得できないようにする認可制御が必要になり、結構面倒です。

データをアップロードしたい場合はSORACOM Harvest Data

次はSORACOM Harvest Dataです。
https://soracom.jp/services/harvest/

これはharvest.soracom.ioにデータをアップロードすると、IMSIをキーとし、タイムスタンプがついたデータとして保存される、というサービスです。

IoTにおいて時系列データを保存する、というのはもっとも基本的な使い方でしょう。ですが、これ簡単にできますか？

まずデータベースが必要です。場合によってはテーブル作成やスキーマなどを決める必要もあるでしょう。データベースにデータを保存するプログラムが必要で、そのプログラムに対してデータを渡す入り口も必要になります。入り口がインターネットであれば不正使用されないよう認証を入れる必要がありますし、閉域の場合はそのネットワークの用意をする必要があります。データの可視化はSQLで直接見れる人はそれで良いですが、普通は何らかの可視化のアプリケーションが必要になります。データベースやデータ投入プログラム、可視化プログラムを動作させるサーバーを用意する必要もありますね。

結構大変じゃないですか？必要な知識、技術はデータベース、ネットワーク、セキュリティ、アプリケーションなど多岐にわたります。もちろんやればできますし、最近は簡単に構築できるクラウドサービスもたくさんあります。でもそれはある程度慣れてるから言えることであって、ちょっと現場のデータをクラウドで可視化してみたいなぁ、くらいの状態からはギャップがありすぎます。

そんな僕たちの強い味方がSORACOM Harvest Dataです。使い方は簡単。SORACOMコンソール上でHarvest Dataの設定をONにして、データをharvest.soracom.ioに送りつけるだけです。多分これ以上簡単にはできないでしょう。アップロードしたデータはSORACOMコンソール上から確認できる他、SORACOM Lagoonというサービスできれいに可視化することもできます。

めちゃくちゃ簡単なので、デバイスの開発の際にとりあえずデータが送れることや、指定されたフォーマットになっていることなどを素早く確認したい時にはとても便利です。ちょっとデバイス側の動き確認したいだけなのに、クラウドインフラを整えないといけないと大変ですよね。そもそもデバイス側の人は自分でインフラ作れないことが多いでしょうし、インフラ側を整えるのが後になるほどデバイスの開発も進められない、ということにもなります。こういう時にとりあえずHarvestにデータ上げられるところまで確認できていれば、デバイス側の開発も進められるでしょう。

実際サービスに使用するセンサー値などの他、デバイスのメモリやストレージなどのメトリクスやログをアップロードして、監視に役立てるのもいいですよ。

SIM認証によって認証をしなくてよくなり、アップロードされたデータは自動的に付与されるIMSIで識別することができます。

ファイルをアップロード/ダウンロードしたい場合はSORACOM Harvest Files

次はSORACOM Harvest Filesです。
https://soracom.jp/services/harvest/

これはSORACOM内にあるファイルストレージに対し、ファイルをアップロード、ダウンロードすることができるサービスです。
Harvest Dataでセンサーデータなどの小さいデータはアップロードできますが、画像ファイルや機器専用のバイナリファイルなどはアップロードできませんし、そういったファイル単位で扱うものはファイルとしてアップロードしたいものです。
またメタデータサービスはあまり大きなデータは扱えないため、大きな設定ファイルが必要になる場合には使えません。

そのような場合に便利なのがSORACOM Harvest Filesです。
Harvest Dataと同じように、認証なしでファイルのデータをharvest-files.soracom.ioに対して送信するだけで、ファイルをアップロードすることができます。
また、同じく認証なしでファイルを取得することもできます。

これもIoTでよくあるケースだと思いますが、自分で用意するのはちょっと面倒です。(ファイルストレージについてはITではよくあるユースケースのため、こちらの方が比較的簡単で対応できる方法も多いですが)

ストレージサービス、たとえばAmazon S3を用意して、その中にアップロード対象のバケットを用意してアクセス設定などをする必要があります。また、デバイスへの権限をどうやって与えるかは結構難しいです。IAMユーザーを発行する？Cognitoで認証して一時的な認証情報を渡す？その場合、アクセス権限はどうする？などの課題があります。特に権限関係をちゃんとやろうとすると面倒ですね。どのデバイスからでもすべてのパスにアップロード/ダウンロードできてもいいのなら簡単なのですが。。

SIM認証を使えば認証が必要なくなりますし、:imsiというパスを使えば回線のIMSIに変換されて保存されるのでファイルの識別もできます。また、こちらは権限設定が必要なのですが、権限内に:imsiというパスを指定すれば、その回線しかアップロードやダウンロードできないようにするのは比較的簡単です。

ファイルを扱うデバイスの場合は、使用を検討してみると良いでしょう。

2. ソラコムに外部サービスの認証情報を保存して連携するもの

次は外部サービスと連携するパターンをみていきましょう。
SORACOMサービスだけでも設定、データ、ファイルの保存と閲覧ができることは確認できましたが、これだけで完結できるIoTサービスだけではありません。外部のクラウドサービスや、自社のWebサービスなどと連携してサービス提供するケースも多いでしょう。
とはいえ、外部サービスはそのサービス専用の認証方法が決まっており、SORACOMのSIM認証をそのまま使うというわけにはいきません。

なので、事前に外部サービスの認証情報をSORACOMに保存しておき、SORACOMから外部サービスを利用できる状態とした上で、SORACOMはデバイスをSIMで認証し、届いたデータを外部サービスに転送する、という形になります。

SORACOMは外部サービスに対するプロキシの役割を果たしている、と考えられますね。
外部クラウドから見るとデバイス個別に認証しているわけではないため、共通の認証情報を設定して包括的に認証することもできます。デバイスの場合と違って、仮にその認証情報が流出してしまったとしてもSORACOMの設定を変更するだけで済むので、すぐに対応することができます。包括的な認証の場合正当な利用者であることは確認できますが、デバイス個別のID(IMSI)をどのように取得するかはサービスごとに違うため、その点は注意して使いましょう。(データそのものに入れることはもちろん可能ですが、その場合他のデバイスから詐称されることを防げないため、SORACOMが付与する情報を使うのがセキュリティ的に良いです)

サービスの設定には、どのサービスと連携するのか、そのサービスの認証情報などを設定することになります。各サービスごとに必要な情報を発行して、SORACOMの認証情報ストアに保存します。万が一に備えて、できるだけ小さい権限の認証情報を保存しましょう。(悪用や流出のリスクは小さいでしょうが、認証情報の基本的な考えです。外部に預ける場合は特に)

SORACOMサービス自体を利用するパターンに比べると面倒ですが、デバイスに１つ１つ設定するのに比べればはるかに生産や運用の負担が掛からず、自動化もでき、後からの変更も容易です。素晴らしいですね。

それでは具体的なサービスを見ていきましょう。

SaaSを利用したい場合はSORACOM Funnel

外部のクラウドサービスを利用する場合、まず検討したいのがSaaS(Software as a Service)です。
すでに世の中にはIoTの課題を解決する様々なサービスがあり、自分がコーディングなどしなくてもそこにデータを送るだけで解決するケースは多いです。使えるものは使っていきましょう。

SaaSのサービスと連携する時に使用するのがSORACOM Funnelです。
https://soracom.jp/services/funnel/

代表的なクラウドサービスのAWS、Azure、GCPにデータを送れる他、SORACOMのパートナー企業のサービスにもデータ転送ができます。

AWS、Azure、GCPについては、クラウドサービス内のサービス連携の起点となるサービスに転送されています。AWS IoTであれば、AWS IoTにデータが届いたらどのサービスに処理させるか、をAWS側に設定させる必要も出てきます。

一方でパートナー企業のサービスは、単体で使えるSaaSが多いです。使えるサービスがあれば、デバイスからのデータ送信をSORACOM Funnel経由にすると、短時間で対応させることができるでしょう。

2020/12/14時点で対応しているサービス

アクロクエストテクノロジー株式会社 Torrentio
株式会社アプレッソ DataSpider Cloud
ブレインズテクノロジー株式会社 Impulse
アステリア株式会社 Platio
Kii Thing Interaction Framework
ウィングアーク1st株式会社 MotionBoard
株式会社YE DIGITAL MMCloud
Teradata IntelliCloud
ESRIジャパン株式会社 ArcGIS Online
株式会社ランドログ LANDLOG
株式会社オプティム OPTiM Cloud IoT OS
株式会社Fusic mockmock
ESRIジャパン株式会社 ArcGIS Online

データは以下のような形で届きます。( https://dev.soracom.io/jp/start/funnel/ からの抜粋)

{
  "operatorId": "OP0000000000",
  "timestamp": 1452791551499,
  "destination": {
    "resourceUrl": "https://firehose.us-west-2.amazonaws.com/my-kinesis-firehose",
    "service": "firehose",
    "provider": "aws"
  },
  "credentialsId": "my-aws-credentials",
  "payloads": {
    "message":"Hello SORACOM Funnel via UDP!"
  },
  "sourceProtocol": "udp",
  "imsi": "440XXXXXXXXXXXX"
}

送ったデータはpayloadsの中に含まれ、imsi要素も含まれていますので、これを使ってデバイスを識別するとよいでしょう。

SORACOM Funnelでは多彩なサービスと連携することができますが、サービスごとに違う認証情報をデバイスに保存するのは大変です。デバイスの認証はSIM認証で、クラウドサービスの認証はSORACOMで行う、と切り分けることにより、デバイス側を様々な認証方法に対応させることなく様々なサービスを利用することができます。これもSORACOMのSIM認証の大きな効果ですね。

FaaSを使いたい場合はSORACOM Funk

用途にあうSaaSが見つからない場合、独自の処理内容を実行させたい場合は、FaaS(Function as a Service)の利用を検討してみましょう。
FaaSではプログラムを書くだけでデータに対して処理を実行させることができます。
通常はプログラムを動作させるためのサーバーを用意したり、プログラミング言語の実行環境を用意したり、そのプログラムを実行させる入り口となるミドルウェアを動かしたり、色々しなければならないのですが、FaaSではそのようなインフラ部分を用意することなく、プログラムを用意するだけで良いので、準備や運用が大幅に削減できます。

FaaSのサービスと連携する場合に使用するのがSORACOM Funkです。(Funcではないことに注意)
https://soracom.jp/services/funk/

代表的なクラウドサービスでのFaaS、AWS Lambda、Azure Functions、GCP Cloud Functionsを呼び出して、実行結果を返すことができます。

AWS Lambdaの場合、以下のようなIMSIなどの情報はcontextとして渡されます。(https://dev.soracom.io/jp/funk/how-it-works/ からの抜粋)

{
  "custom": {
    "srn": "srn:soracom:OP00XXXXXXXX:jp:Subscriber:44052XXXXXXXXXXX",
    "operatorId": "OP00XXXXXXXX",
    "sourceProtocol": "udp",
    "resourceId": "44052XXXXXXXXXXX",
    "resourceType": "Subscriber",
    "imsi": "44052XXXXXXXXXXX",
    "imei": "35956XXXXXXXXXX"
  }
}

custom.imsiを参照してデバイス識別できます。必要に応じてSORACOM APIを使えば、IMSIに紐づいたタグ情報なども取得できます。

Azure Functions / GCP Functionsの場合は、headersのx-soracom-tokenにJWT(JSON Web Token)形式で以下の情報が渡されています。

{
  "iss": "https://soracom.io",
  "aud": "srn:soracom:OP00XXXXXXXX:jp:Subscriber:44052XXXXXXXXXXX",
  "jti": "4i2qn8oqu78",
  "iat": 1558673437,
  "typ": "soracom/token/v1",
  "sub": "funk.soracom.io",
  "ctx": {
    "srn": "srn:soracom:OP00XXXXXXXX:jp:Subscriber:44052XXXXXXXXXXX",
    "operatorId": "OP9012345678",
    "sourceProtocol": "udp",
    "resrouceId": "440101234567890",
    "resrouceType": "Subscriber",
    "imsi": "440101234567890"
  }
}

JWTはSORACOMの公開鍵を使って検証することができます。ctx.imsiを参照してデバイス識別できます。

デバイスから直接FaaSを呼び出す、またWebAPIサービスを経由して呼び出す場合には、やはりそれぞれのSDKなどが必要になります。SIM認証によってシンプルにデータのやり取りだけでFaaSを使えるのはSORACOMの便利なところです。デバイスにやらせるのが重い処理や、外部サービスとの連携が必要な処理などは、積極的にFaaSと連携していくと良いでしょう。

MQTTを使いたい場合はSORACOM Beam(MQTT)

IoTでよく利用されるプロトコルにMQTT(Message Queuing Telemetry Transport)があります。以下のような特徴を持つプロトコルです。

軽量なヘッダー
常時接続でPub/Subすることにより双方向の通信が可能
QoSの設定により送達確認が可能

特にリアルタイムでの受信を可能にする点が貴重で、IoT用途で普及が進んでおり、大手クラウドサービスでもIoTサービスのメインの接続手段として採用されているので、廃れる心配はそれほどないと考えられます。

SORACOM Beam MQTTの構成では、デバイスとSORACOM BeamがMQTT接続、SORACOM Beamと外部のMQTTブローカーがMQTTS接続し、送られてきたデータを相互にやりとりすることになります。

このMQTTなのですが、認証にはTLSの相互認証にてされることが多いです。一応MQTTブローカーとの間でTLS通信(サーバー認証のみ)して、IDとパスワードで認証をする、HTTPと同じような認証方法を取ることもできるのですが、基本的に人間が入力するID/Password認証に比べ、デバイスの場合はどうせIDとPasswordをデバイスに保存させなければなりません。であれば、それがクライアント証明書と秘密鍵に変わってもさほど負担は変わらないのですね。(クライアント証明書の期限が十分長ければ)TLS相互認証であれば、TLS通信が確立した時点でデバイス認証がされ、デバイスの識別ができる状態になるので、常時接続のMQTTと相性もよいのでしょう。ということで、クラウドサービスのMQTTと接続するためには、クライアント証明書と秘密鍵が必要になります。これはSORACOMの認証ストアに保存します。

MQTTで接続できたらデータの発行(Publish)、および購読(Subscribe)するだけです、データはMQTTのペイロードとして届きます。デバイス識別は、トピックの末尾にIMSIをつけるオプションがあるので、それを使うと良いでしょう。

クライアント証明書は基本的にはデバイスごとに発行することが推奨されています。SORACOM Beamを使うことで、グループで１つのクライアント証明書でよくなり、管理の手間が減りますが、AWS IoTなどのサービスから見ると同じ証明書で複数のクライアントから接続されているように見えるので、セキュリティ的に問題あるとみなされるかもしれません。また、証明書ごとに権限をつける形になるため、同じグループに属するデバイスは同じ権限になってしまいます。例えば同じグループの他デバイスへのデータが受信できるようになってしまうかもしれないので、問題にならないか確認する必要はあるでしょう。問題ある場合はSIMごとにグループを作ることで対応することになります。

とはいえ、クライアント証明書を発行し、デバイスごとに保存させるのは、IoTデバイス生産および運用上の大きな課題です。SORACOMのSIM認証を使えば、それがクラウドサービス上で完結させられるのは大きいです。MQTTを使いたい場合は検討しても良いかと思います。(CPUパワーが許せば、後述のSORACOM Kryptonを使う方がいい場合もあります)

一般的なHTTPサーバーと連携したい場合はSORACOM Beam

ここまでのどれにも該当しない場合、たとえば自社のWebサーバーと連携させたい場合などは、SORACOM Beamを使うことになります。
https://soracom.jp/services/beam/

SORACOMの外部サービスとの連携では一番汎用的に使用することができます。
HTTPやTCP、UDPでbeam.soracom.ioに送ったデータを、HTTPSに変換して、外部サービスに転送する、というものです。

最初の方で説明した通り、このサービスはSORACOMがリリースされた時点ではすでにあり、SIM認証を生かしてデバイスの開発・動作・運用の負荷を下げられる画期的なサービスとして注目されました。FunnelやFunkが使える場合はそちらを使った方がより簡単だとは思いますが、Beamの便利さが失われたわけではありません。

現在でもBeamの有利な点として、「Webサイトエントリポイント」があります。FunnelやFunkは基本的には１つのサービスにしか対応させられませんが、Webサイトエントリポイントはbeamへのパスをそのまま転送できるので、複数のWebAPIがある場合でもまとめてBeamに対応させることができます。デバイスから複数の処理を呼び出す必要がある場合には検討しても良いでしょう。

Beamでは、対応するサーバー側がアクセスの正当性を検証する必要があり、そのために署名をつける機能があります。
署名は以下のように算出され、X-Soracom-SignatureというHTTPヘッダーにて届きます。

SHA256(${事前共有鍵文字列x-soracom-imei=${IMEI}x-soracom-imsi=${IMSI}x-soracom-timestamp=${TIMESTAMP})

事前共有鍵をBeamに設定しておくことで、この鍵を知らなければ正しい署名が作れないようになっています。アクセスを受け取るサーバーは、各HTTPヘッダと事前共有鍵から署名を算出し、X-Soracom-Signatureと同じになることで、アクセスの正当性およびデバイス識別IDとしてのIMSIを確認することができます。

デバイスごとにパスワードなどを管理しなくてもHTTPサーバーにてデバイスごとの認証ができるのは、リリース以来のSORACOMの強みですね。

外部サービスの認証情報を生成するもの

次のパターンは外部サービスの認証情報を生成するものです。
2番のパターンで外部サービスと連携させる方法をみましたが、デバイスから直接クラウドサービスを利用したい場合もあります。その場合にはそのクラウドサービスに対するデバイス固有の認証情報が必要になるのですが、その場合でもデバイス個別の対応をせずに済む方法はないでしょうか？

SORACOMでは、SIM認証を使ってデバイス固有の情報を生成する、という方法を使ってその課題を解決しています。

この方法であれば、SIMがあればクラウドの認証情報を生成できるため、工場などで個別に認証情報を生成して保存させる必要がありません。また、必要な時にだけ認証情報を発行して、必要なくなれば削除する、といった使い方もできるようになります。

SORACOMのサービスを使って連携するのに比べ、各クラウドサービスを直接使うことになるため、現時点でSORACOMサービスとの連携では使用できないサービスを使う場合にはこちらになります。また、SORACOM Beamなどのサービスは額の小さな従量課金とは言え無料ではありませんので、リクエスト回数が多いとそれなりに料金がかかります。クラウド直接利用の構成にすることでその料金を削減することも考えられます。

デバイスの負担は大きくなりますが、ラズペリーパイなどある程度性能の高いデバイスであれば問題になりませんし、各クラウド事業者が提供するSDKがそのまま使えるメリットも出ます。すでにクラウドを直接利用する構成になっていて、デバイスの認証情報の発行が課題になっている場合に変更を最小限に解決する方法としても使えるので、デバイスの性能やリクエスト回数、シンプルなインターフェースで利用したいかSDKをそのまま使いたいか、などを考えて、SORACOMサービスとの連携で利用するか、直接利用するかを決めると良いでしょう。

ただし現時点ではSORACOM Inventory、AWS IoTおよびAmazon Cognitoしか対応していないのには注意が必要です。Cognitoに対応しているためAWSサービスには対応できるのですが、他のクラウドには対応できないのですね。

では、具体的なサービスをみていきましょう。

デバイスの遠隔操作や管理をしたい場合はSORACOM Inventoryのブートストラップ

SORACOM Inventoryというサービスがあります。これはLwM2Mというプロトコルを使って、デバイス管理をするためのサービスです。
https://soracom.jp/services/inventory/

こちらはSORACOMサービスでは珍しく、セルラー通信でなくても使用できます。逆に言えば、SIM認証を使った通信で認証しているわけではないので、デバイス認証にはデバイスIDとデバイスシークレットという認証情報を接続時に送る必要があります。

ではこの認証情報はどうやってデバイスに渡せば良いのでしょうか？SORACOMのコンソールやWebAPIで生成して保存する方法もありますが、LwM2Mにはブートストラップという認証情報をデバイスに渡す仕組みがあり、それを利用することもできます。この際、SORACOM AirのSIM認証を使って正規のリクエストであることを確認し、安全なセルラー通信網を使うことで安全に認証情報を渡すことができます。認証情報が渡せればそれを使って暗号通信ができるので、安全にSORACOM InventoryのLwM2Mのサーバーとやりとりをすることができます。

なお、ブートストラップではアクセスの正当性をSIM認証で確認するものの、デバイスの識別情報はendpointというデバイス側から指定する情報となるため、識別はSIM認証と結びついていません。これはInventoryは同じ回線で複数のデバイスに対する認証情報を発行することが想定されているためと考えられます。ただしどのSIMでブートストラップされたのかは確認することができます。

このSORACOM Inventoryとブートストラップの組み合わせはかなり便利で、LwM2Mに対応したプログラムを起動するだけで遠隔操作を受け付ける状態になります。試してみたことのない人は是非試していただければと思います。

AWSサービスが使いたい場合にはSORACOM Krypton

AWSサービスを利用するには、AWSの認証情報が必要です。事前にデバイスに認証情報を入れていない状態で認証情報を手に入れるのに、SORACOM Kryptonというサービスが利用できます。
https://soracom.jp/services/krypton/

KryptonではAmazon Cognito、AWS IoT、SORACOM Inventoryの認証情報を取得できますが、代表してAmazon Cognitoで説明します。

Amazon Cognitoを使うと、指定した権限を持つ一時的なAWSユーザーを作成することができます。CognitoはユーザーのID、パスワードで認証できる他、AmazonやFacebookと認証連携することもできますが、独自の認証と連携させることもできます。つまりSIM認証とも連携できます。(連携部分はSORACOMが開発しています)

Kryptonを使うことにより、SIM認証で正当性を確認され、Cognitoで生成された一時的なユーザーの認証情報をデバイスに渡すことができるので、デバイスはその認証情報を使ってAWSにアクセスすることができます。

この方法で作られたCognitoのユーザー(Identity)のID(正確には開発者ID)はIMSIになるので、どの回線から作られたユーザーかを識別することができます。(ややこしいことにAWSの権限設定に使えるcognito-identity.amazonaws.com:subはIMSIではないCognitoのIDになるので注意が必要です)

また、Kryptonの特徴として、セルラー回線じゃなくてもSIM認証を使うことができます。最初の方に書いた通り、SIM自体は加入者情報を持っているセキュリティチップであるため、SIMに対してセルラー通信と同じようにアクセスすれば、セルラー通信じゃない経路で情報のやりとりをしてもSIM認証ができるのですね。ただしこれはSORACOMがHLRを管理しているSORACOM IoT SIM(グローバルSIM)に限ります。特定地域向けIoT SIM(日本版SIM)はDocomoやKDDIが回線の管理をしていて、SORACOMサービスからは直接そこにアクセスできないので、セルラー通信でのSIM認証しかできません。ここはちょっと残念ですね。

Kryptonを使うと生産時に認証情報を保存させておく必要がないので生産が楽ですし、この方法で作れる認証情報は一定時間で有効期限が切れるため、仮に漏洩してしまっても影響は小さいです。デバイスへの認証情報の保存に課題があるなら使うことを検討してみましょう。

同じようにAWS IoTやSORACOM Inventoryの認証情報を作ることもできますので、そちらのサービスを使う場合も検討してもいいかと思います。特にAWS IoTはSORACOM BeamのMQTT、SORACOM Funnelでも使うことができますが、ある程度性能が高いデバイスであればKryptonでの利用がいいんじゃないかなと思ってたりします。(証明書が個別に発行できる。AWS IoTのデバイスSDKがそのまま使える、MQTT通信のたびにコストがかからない、などの理由です)

4. 認証されたデータを作成するもの - SORACOM Endorse

最後は認証データを作成する、というパターンです。
これを実現するサービスはSORACOM Endorseです。
https://soracom.jp/services/endorse/

SORACOM Endorseはサービス名が「認証サービス」となっており、説明の最初に書いてあるタイトルが「SIMを使用した認証」です。つまりSIM認証そのものをサービス化したのがSORACOM Endorseといってもいいものかと思います。これを最後に持ってきたのもそれが理由です。

SORACOM EndorseはSORACOM Airのセルラー回線にてリクエストを出すと、SIM認証によってその正当性が確認され、検証に必要な情報とともにJWT(JSON Web Token)の形で返ってきます。この情報はSORACOMの秘密鍵により署名されており、JWTを検証することでその内容が確かであることが確認できる、というものです。

具体的には以下のような内容がJWTに入っています。(https://dev.soracom.io/jp/start/endorse/ からの抜粋)

{
  "iss": "https://soracom.io",
  "aud": "soracom-endorse-audience",
  "exp": 1451116301,
  "jti": "hkK7qNyXzEMVAXfTq1MBuA",
  "iat": 1451116121,
  "nbf": 1451116061,
  "sub": "soracom-endorse",
  "soracom-endorse-claim": {
    "imsi": "440XXXXXXXXXXXX",
    "imei": "353XXXXXXXXXXXX"
  }
}

SORACOMによって署名されていること、署名された時間、そしてimsiやimeiがここに書かれている通りであることが保証されます。また、リクエスト時に認証してほしい情報を送ることで、その情報をJWTに入れることができます。

{
  "iss": "https://soracom.io",
  "aud": "soracom-endorse-audience",
  "exp": 1451116301,
  "jti": "hkK7qNyXzEMVAXfTq1MBuA",
  "iat": 1451116121,
  "nbf": 1451116061,
  "sub": "soracom-endorse",
  "soracom-endorse-claim": {
    "imsi": "440XXXXXXXXXXXX",
    "requestParameters": {
      "username": "foo",
      "sessionId": "bar"
    }
  }
}

この場合はusernameがfoo、sesssionIdがbarと送られてきたことを保証します。ただこちらはリクエストした内容であり自由に指定できるため、SORACOMに保証できるのはこのデータが送られてきたことのみで、このパラメータの正当であるかは保証できません。

さて、ぶっちゃけこのSORACOM Endorseは影が薄いサービスです。てか何に使うんだこれ？って感じだと思います。Endorse実際に使ってるよ、という方いるんですかね？(いたらすみません)これはまあ現時点では仕方ないのかな、と思っています。今後化ける可能性は十分あるのですが。

これデバイスの身分証明書みたいなものだと思うんですよね。

あなたは誰ですか？
私はIMSI: 440100123456789です、この正当性はSORACOM Endorseで証明できます
間違い無いですね。そのIMSIは使用許可が出てるからサービス使えますよ

という感じで使えるものです。で、身分証明書ってそれで証明したら使える、っていうサービスが増えないと意味ないじゃ無いですか。もちろん自社サービスで使うこともできるんですけど、自社サービスならBeamやFunkで十分です。でもBeamやFunkは基本的には秘密情報を入れないと使えないので、他社サービスを使うのは多分難しい。使えるIMSIを指定してサービス契約して、サービスを呼び出す時にはIMSIが入ったEndorseのJWTをつけて呼び出して、そのトークンを検証して使用可否を判断して、API呼び出し回数によって課金される、とか、そういう感じのサービスが増えてくると、認証サービスであるEndorseが活躍できると思うんですよね。

SORACOMのSIMを認証カードとして使って、いろんなIoTサービスがEndorse経由で使えるようになればいいなと思うのです。ちょっと面白いな、という人がありましたら、Endorseのトークンで使用許可を出すWebAPIとかを作って公開してもらえればと思っています。

おわりに

かなり長くなってしまいました。
デバイスの認証はIoTにおける大きな課題ですが、SORACOMのSIM認証によってシンプルに解決できそうだな、ということが伝わればいいなと思います。
せっかくSORACOM使ってるのに通信のためだけに使っているのはちょっともったいないんですよね。せっかくならサービスを駆使して、デバイスの負荷を軽く、セキュリティ的に強く、運用を楽にしたいところです。
何か面白そう、使えそうなものがあれば試してもらえればと思います。

明日は@noexpectさんです。Prometheusが得意な方っぽい。どんな話が聞けるか楽しみです！

SORACOMのSIM認証を語り尽くす2020