MOVEit リソースセンター

モノのインターネット（Internet of Things、IoT）には、ソフトウェア開発の設計段階からセキュリティ対策を組み込むことが奨励されているソフトウェア産業全体の傾向に違わず、セキュリティ保護策が必要です。

もし私の以前のブログ（モノのインターネットは怠惰を助長するか、革新を推進するか？）を読まれた方がいらっしゃったら、モノのインターネットに関する私の見解をご存知だと思いますが、IoT の遍在とさらなる広がりは、もはや誰にも押しとどめられないのは明らかです。この現実はセキュリティ上のリスクにつながり、厳重な管理が必要になってきます。

IoT には、作成されたデータを関係者だけが送受信できるようにするための何らかのチェックメカニズムを組み込むべきだとの指摘があります。どうしても必要でしょうか？

疑うべくもありません。センサーベースのデバイスであれ、特定の機能を実行する場合であれ、予防措置（設計段階でのセキュリティ強化）が講じられない限り、すべてのデバイスはハッキングに開放されることになります。トルコの石油パイプラインの監視モニタを無効にして侵入し爆発を起こしたり、 医療機器を攻撃したりするなど、いくつものハッキングの例があります。このような攻撃は生命を脅かす可能性があります。ハッカーたちはどんなターゲットでも躊躇なく選択し、しかも、サイバー犯罪者仲間に自らの攻撃を誇らしげに語ったりします。

それほど強い敵意があるわけではない攻撃もありますが、やはり注意が必要です。ベビーモニターがハッキングされ、ハッカーが幼児に直接語りかけたこともありました。スマートライフルに興味はありますか？そう、スマートライフルも簡単にハッキングできることをセキュリティ研究者夫妻が証明しました。弾丸の軌道を遠隔操作で調整できるばかりか、デフォルトの Wi-Fi パスワードが変更できなくなっていることもわかりました。

ネットワーク接続されたデバイスには、明らかに、生命を危険にさらしたり、会社や家族の平穏を脅かす可能性のあるリスクが存在します。このリスクをしっかり認識するためには、まずデバイスの通信方法を理解する必要があります。

IoT システムの仕組み

IoT は、ただネットワーク接続されたデバイスという捉え方ではすますことができない複雑性を含んでおり、理想的にはしっかり整備された専用の IoT インフラストラクチャが必要です。通常、IoT デバイスから最終分析までのパスデータを反映する4つの異なる段階があるとされます。これらの4つの段階のそれぞれでデータ処理が発生します。

• センサーまたはアクチュエータ - たとえば、センサーは水温を監視するためのデータを収集し、アクチュエータは所定の温度に達したときにバルブを閉じたり開けたりするような物理的動作をします。
• インターネット・ゲートウェイ - 収集されたアナログのセンサーデータはデジタルに変換され、Wi-Fi、有線LAN、インターネットのいずれかのプロトコルでストリーミングされます。リアルタイム分析はデータ集約的でネットワーク速度が遅くなる場合があるので、全データを処理のために送信します。これを IoT デバイスからの前処理集約段階と考えてください。
• エッジIT - データセンターにデータを送信する前に追加の分析を実行する中間段階です。これは、データセンターへのトラフィックを削減し、データセンターでネットワーク帯域幅を超えないようにするためです。すべてのデバイスの全データが必要なわけではなく、以降のアクションのためには設定された基準を満たすデータだけで事足ります。
• データセンターまたはクラウド - データの詳細な分析が可能です。オンプレミスの場合、生成されたレポートはデータセンターに送信されます。データ集約的な処理と分析がオフサイトで行われる場合は、オンサイトのネットワーク帯域幅の不足を心配する必要はありません。

どの段階がどのように実装されるかは、IoT センサーとデバイスの数、生成されるデータの量、データの処理方法によって異なります。実用的な IoT エコシステムはセキュリティを考慮する必要がありますが、工業用インターネットであれ、運用プロセスを補完するのに IoT デバイスを活用する目的であれ、セキュリティ保護のための有効な方法の1つは認証です。

IoT 認証とは？

データを保護し、データへのアクセスを適切なアクセス許可を持つユーザーだけに制限する機能は新しい考えではなく、多くの業界で広く適用されています。ネットワーク接続されたデバイスが最初から同じセキュリティ原則の対象とならなかったことの方が、むしろ不思議なくらいです。

ブログで取り上げるには IoT デバイスのカテゴリーはあまりにも多岐にわたりますが、数々の IoT デバイスは、それぞれ、セキュリティレベルの点で大きく異なっています。Bluetooth、RFID（無線周波数識別、radio frequency identification)、 Wi-Fi などの近接型プロトコルを使用して接続するものと、GPS、4Gを使用するもの、または有線接続するものがあります。近くのデバイスをスキャンしたり、短いコード（デフォルトから変更されている場合も、変更されていない可能性もあります）を入力したりするだけで簡単に接続できるケースもあれば、多要素認証の形式を使用してデバイスと受信者のアクセス許可を確認して初めて接続できるケースもあります。

ここで質問です。「IoT 認証とは何でしょうか？」クイズ番組のように短い１文で答えることは不可能ですが、１つか２つのパラグラフでなら説明できるかもしれません。

IoT のユースケースは、IoT 製品の数だけあると言えるかもしれないほど様々ですが、現在のトレンドは変化が起こりつつあることを示唆しています。IoT デバイスの製造業者に広く行き渡るまでには時間がかかるかもしれませんが。誰もがよく知っているオンラインショッピングを考えてみてください。SSL（ブラウザによっては錠記号が表示され、アドレスは https で始まるような）を利用していない店から購入したいと思いますか？オンラインショッピングにおけるSSLと類似したアプローチは、IoT デバイスの場合、デジタル証明書がサイト、この場合は IoT デバイス、の信ぴょう性を証明するPKI（public key infrastructure、公開鍵インフラストラクチャ）として知られているものです。

デジタル証明書は、それなしでは確立しにくい IoT デバイスに対する信頼レベルを保証し、インフラストラクチャを監視する IoT アプリケーションと組み合わせて利用すると、セキュリティが弱い未認証デバイスへのアクセスを識別して防止することができます。

私見では、ブロックチェーンとPKIを対比する議論はありませんが、言及する価値はあります。ブロックチェーンの分散型元帳の使用は、PKIを強化し、デジタル証明書管理が監査可能であり、変更が不可逆であることを保証することができます。分散化されていない場合、IoT のPKIは、デジタル証明書プロバイダが財務上の理由で使用している可能性がありますが、基本的には認証をしっかり管理することを目指しています。

IoT 認証のインプリメンテーション

どのような認証方法をとったとしても、目的が IoT のセキュリティであることに変わりはありません。利便性のために二要素認証で十分か、SSO（シングルサインオン）が必要かを検討して結論を下すべきかもしれません。Azure IoT を使用してすべてのデバイスを管理したい場合もあるでしょう。サービス品質に関する特定の要件があって、MQTT クライアントの使用が必要になることもあります。MQTT（メッセージ・キュー・テレメトリ・トランスポート）は、IoT デバイスによって使用される可能性があるメッセージ・プロトコルの1つです。

IoT デバイスはさまざまなプロトコルとスタンダードを使用しており、認証方法を検討するときにはこのバリエーションを考慮する必要があります。したがって、これらのバリエーションに精通していることは必須であり、購入した IoT デバイスが確実に安全な方法で認証できるかを確かめるには、そのデバイスに関する深い知識が求められます。手動アップデートが必要な場合（OTA機能が欠けているケース）もあり、デフォルトから変更できないように設定がロックされている場合もあるかもしれません。 IoT プラットフォームで要件の多くを自動化することが可能かどうかも検討するべきかもしれません。

IoT デバイスをセキュリティ保護するためには IoT 認証が必要であり、それにはいくつかの方法があります。セキュリティのためには便利さを多少犠牲にしてでも専用の IoT ネットワークを構築することを選択せざるを得ないかもしれません。安全な方法ですべてを統合することは可能ですが、そのためにはデバイスが設計段階からセキュリティを考慮したものである必要があります。結果として、一部のデバイスを廃棄する必要があるかもしれませんが、セキュアなインフラストラクチャを確保して安心したいのであれば、致し方ない代償でしょう。

参考ホワイトペーパー：データ保護のコンプライアンスを徹底するための７項目