2017年11月22日 12:00

IoTセキュリティの問題は「脆弱性」だけか

近年、インターネットや近距離無線通信(BluetoothやNFCなど)につながった機器が増えてきました。

みなさんのご家庭でも、スマートフォンと繋がるコーヒーメーカーや時計などがあるのでは無いでしょうか?それに伴って、KDLにも「IoTセキュリティの疑問」についてお声がけをいただくことが増えました。

今回は、IoT機器のセキュリティについて幾つかの事例をご紹介します。

皆さんは様々なIoT機器がスマートフォンやパソコンを通じてインターネットと繋がっていた状況で、セキュリティの欠陥があるとどのようなリスクがあるか考えたことはあるでしょうか?

例えば、電子錠がスマートフォンと通信する際に通信の暗号化が上手く行われていないと認証鍵が漏洩して、不正に電子錠を開錠されてしまうかもしれません。

体重計や体温計はどうでしょうか。もし、セキュリティの欠陥がある機器を医療現場に導入した場合に、患者の体重や体温などの情報が第三者に漏洩するかもしれません。

どれも「利用者のプライバシー」という面と「製造メーカーの製品品質」という面で、喜ばしいことではありません。

IoTのセキュリティについて、もう少し詳しくみてみましょう。

最近、日本でもよく見かけるスマートペットフィーダーを例に挙げて考えてみます。
スマートペットフィーダーとは、飼い主が旅行などで遠出をして在宅していなくても、スマートフォンなどから餌を与えることができるIoTシステムです。

IoT機器とそれに関係した端末や通信、管理サーバなど

<IoT機器とそれに関係した端末や通信、管理サーバなど>

スマートペットフィーダーで遠隔地から操作できるということは、サービスの提供者によってインターネットからアクセスできるAPIサーバーが設置されている可能性が高いと考えられます。
また、APIサーバーにリクエストを送信するスマートフォンアプリもあるでしょうし、IoT機器付近にいるときだけ何かの機能で使える近距離無線も実装されている可能性があります。

スマートペットフィーダーで死守すべきセキュリティポイントは?

先程挙げた、APIサーバーやアプリ、近距離無線などすべてを確実に保護できていることが理想ですが、仮にたった1つだけ「安全にできる」のであれば一番死守されるべきポイントはどこでしょうか?

システムの大まかな概要を見て考えてみましょう。

このスマートペットフィーダーのシステムは、下図のような構成だと仮定します。

スマートペットフィーダーのシステムの概要

<スマートペットフィーダーのシステムの概要>

飼い主が遠隔地からペットに餌を与えることを主目的としたIoT機器なので、「スマホアプリなどからインターネットを経由してAPIサーバーにリクエストを送信」し「APIサーバーからスマートペットフィーダーに餌をあげるリクエストを送信」することで目的の機能を実現しています。

このときに、もし攻撃者の手により「クラウドAPIサーバー」がダウンするとどうなるでしょうか?

攻撃者によりクラウドAPIサーバーがダウンした図

<攻撃者によりクラウドAPIサーバーがダウンした図>

クラウドAPIサーバーがダウンしたことにより、飼い主とペットを繋ぐ生命線とも言えるネットワーク経路が絶たれてしまうため、飼い主はペットに対して餌をあげることができなくなってしまいました。ペットは餌を食べることができません。

このような問題が起こらないように、クラウドAPIサーバーは特に堅牢に作っておくべきなのです。

セキュリティを意識した開発によってAPI機能のセキュリティ品質を上げることは勿論、サーバーの設定も利用用途に適した設定にしておくべきです。またサーバーを冗長化しておくことなども有効でしょう。

鍵が開けられない?IoT関連のサーバートラブルと対策について

このような事例は、IoT業界で多いのでしょうか?

過去に、IoT電子錠を作成するベンダーが姿を消しサーバーが閉鎖した例があります。

その結果、IoT電子錠はAPIサーバーがないため、正常なリクエスト送受信が行えず自由に開閉錠できない「無意味なモノ」になってしまいました。これらは今後国内でも起こり得る問題です。

[参考] MY SMART LOCK VENDOR DISAPPEARED AND SHUT THE SERVERS. LONG LIVE MY SMART LOCK!

お客様からのお問い合わせで一番多いのは、「IoT機器経由で変なリクエストを送られると、クラウド上にあるデータは漏洩しますか?」というお問い合わせです。もともとクラウドとスマホは作ってきたけれども、「IoT」が入ってくることは初めてで、どのような脅威があるか知りたいというパターンが多いです。

IoT機器の3つの通信パターンを例にみていきましょう。

IoT機器の通信パターンの例

<IoT機器の通信パターンの例>

  • 一番上・・・IoT機器自身が直接クラウドサーバーに対してリクエストを送信
  • 真ん中・・・IoT機器がスマートフォンを経由することでクラウドサーバーにデータを送信
  • 一番下・・・IoT機器とスマートフォン間の通信のみ

どれも多くの機器で採用されているパターンですが、「IoT機器経由で変なリクエストを送られると、クラウド上にあるデータは漏洩しますか?」と質問に対する回答としては、クラウドサーバーの情報漏洩防止の観点で考えると、まずはクラウドサーバー側のセキュリティに力を入れるべきです。

理由としては、IoT機器が直接クラウドと通信する場合やスマートフォン経由で通信する場合でも、不正なリクエストが送信されてくることは念頭においたほうが良く、堅牢性を確保するためには、クラウドサーバーのAPIなどで一般的なセキュリティ対策(バリデーションチェック・エスケープなど)を行うことが重要であると考えるからです。

それが出来てからIoT機器側のセキュリティを考えていけば、最初にクリアしなければならない課題を解決しつつ、製品品質を向上させることができます。

デモ機の段階でセキュリティ対策を

KDLのようなセキュリティ診断サービスを提供する企業に対してIoT機器のセキュリティに関する相談をされる場合、デモ機の製作段階で一度実機を見せていただくことが望ましいです。

簡単なものでも、通信コネクションの取り方やIoT機器への書き込み権限など、お客様のデモ機を触ることで気づくことが多々あります。お客様の中には、NDAを結ぶまではNGというケースも多いですが、基板を見せていただくことで気付く問題も多々あります。

そのようなセキュリティ診断士の目線から、「今後製品を開発する上でどのようなことを気にしなければならないか」というアプローチをとることもできます。

もし、自社のIoT機器のセキュリティ品質が気になったときは、まずは下記の点をチェックしてみてください。この中に1つでも心配な点があれば、それ以外にも問題を含んでいる可能性があります。

チェックポイントの例

<チェックポイントの例>

IoT機器のセキュリティに懸念があれば、ぜひお声がけください。一緒にセキュリティ品質をあげ、製品品質をあげる取り組みを支援させていただきたいと思います!

本件に関するお問い合わせ

フォーム・お電話で、お気軽にお問い合わせください。

お電話でのお問い合わせ:078-327-2280

ページの先頭に戻る