このページの本文へ

前へ 1 2 3 次へ

脆弱なIoTシステムの設置にはご用心、「Black Hat USA 2021」講演レポート【後編】

「カプセルホテルのIoTをハッキング」…その後の対策は? 現地調査してみた

2022年04月01日 08時00分更新

文● 谷崎朋子 編集● 大塚/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

IoT活用で迫られる「機能」と「セキュリティ」のバランス

 今回の調査結果や修正が必要な箇所については、筆者からカプセルホテルに報告した。報告から1週間後には、同社を技術支援する会社とともに修正・対応を進めたとの連絡も受けている。すべてのiPod touchにApple IDを登録し、そのほかの点についても順次対応を進めているという。スムーズなやり取りと迅速な対応に、あらためて感謝したい。

 アクセスガイド機能を使ってiPod touchのパスコードロックを行っている点については、実は当初、MDM(モバイルデバイス管理)の制御機能である「Single App Mode」を設定し、バッテリ切れで再起動したあとも専用アプリしか起動しないように制御していたという。しかし、IoTデバイスとの接続不良が頻発し、そのたびにMDMの管理画面から制御を一次解除、再設定するのは日常業務において煩雑すぎると判断。セキュリティと業務の最大公約数的な機能として、アクセスガイドを使って運用していると説明があった。

 IoTはハードウェア、ソフトウェアの両面で制約が多く、当初導入しようと考えたセキュリティ対策が、不具合が原因であきらめるしかなかったというケースも少なくない。だからといって、日々の業務で大きな負担になるようなセキュリティ対策を強いることは得策ではない。上述したホテル側の判断も、悩んだ末のものだろう。

 同ホテルでは、すべてのiPod touchをMDM管理しているほか、CS8700コントローラーなどが接続するWi-Fiネットワークには特定デバイス以外は接続できないようMACアドレス制限をかけ、デバイス間のペアリング制限もかけるなど、いくつもの対策を実践していると述べている。

 ただし、残念ながらMACアドレスは偽装が容易であり、ネットワークへの不正アクセス対策としてMACアドレス制限に頼るのは好ましくない(たとえばAppleのサポートページを参照)。本来ならば専用モバイルアプリとCS8700コントローラーの間でメッセージ認証を行い、第三者による不正操作を防ぐのがベストだ。

 「メッセージ認証では、正しい秘密鍵もしくは共通鍵でメッセージが送られてきたかどうかを1パケットで確認できる。そのため、物理的に制約の厳しいIoTデバイスでは認証方法のひとつとしてよく採用されている」。そう説明する杉浦氏は、今回のケースであれば、リッチデバイスのiPod touchで動作する専用アプリにメッセージ認証機能を追加実装することは当然ながら可能で、HTTPSサーバーを内蔵するのも厳しそうなNasnosコントローラーであっても「メッセージ認証機能ならギリギリいける」と述べる。

 もっとも、これはメーカー側で認証機能を実装する必要があり、ユーザーであるホテル側ではどうすることもできない。

IoTメーカー/ユーザーの双方で参照してほしい資料

 IoTにまつわるセキュリティの問題は、なにも本稿で取り上げたNasnosやカプセルホテルだけのものではない。メーカー、ユーザーの両方で広く考えるべき問題だ。

 ハードウェア、ソフトウェアの両面で制約が多いIoTデバイスで、どこまでセキュリティ機能を実装できるのか、設計時にどこまでセキュリティリスクを考慮すべきなのかは、IoT業界全体が抱える永遠の課題と言えるだろう。通常、セキュリティ対策は製品の売上に直結するようなものではないため、実装の優先順位が低くなるのは理解できる話だ。

 デバイスを導入する側も同様で、まずはそのIoTデバイスを使って業務が効率化できるか、快適なサービスが実現するかといった観点で検討を行うはずだ。セキュリティ対策の重要さはわかっていても、利益とのバランスを考え、経営上の判断からある程度のリスクを取らざるを得ないこともあるだろう。

 新しい製品やサービス、イノベーションを阻害するほどセキュリティを偏重する必要はない。それでも「正しく適切な」バランスを見定める力はぜひ身につけたい。

 そのために、たとえば総務省/経済産業省の「IoT推進コンソーシアム IoTセキュリティワーキンググループ」が作成したIoT導入ガイドライン「IoTセキュリティガイドライン」を一読するのもよいだろう。かなりフワフワした内容なので“指針”とすることはお勧めしないが、「IoTにはこういう問題があるんだな」とざっくり知る程度であれば、十分な内容だ。

●IoTセキュリティガイドライン ver 1.0
 https://www.soumu.go.jp/main_content/000428393.pdf

 日本スマートフォンセキュリティ協会(JSSEC)が出している「IoTセキュリティチェックシート」も参考になる。IoT導入時に考慮すべきセキュリティのポイントが網羅されており、導入する企業がIoTメーカーやSIerと協議する際の要件定義にも使える内容だ。

●IoTセキュリティチェックシート 第2.1版
 https://www.jssec.org/iot

「IoTセキュリティガイドライン ver 1.0」「IoTセキュリティチェックシート 第2.1版/」

 またIoT導入企業であれば、セキュリティコンサルタントやハッカーによるペネトレーションテスト(侵入テスト)も積極的に取り入れたい。これは導入製品の脆弱性やネットワーク構成上のリスクなどを、攻撃者の視点で洗い出すテストだ。テストを実施することで、妥当な対策ラインの見極めもしやすくなるだろう。

 IoTデバイスのメーカーであれば、設計や開発の各フェーズでセキュリティ要件を検証し、実装するセキュア開発を導入するのがベストだ。これは、JPCERT/CCの「IoTセキュリティチェックリスト」が役に立つ。

●IoTセキュリティチェックリスト
 https://www.jpcert.or.jp/research/IoT-SecurityCheckList.html

 また、セキュアIoTプラットフォーム協議会(SIOTP協議会)が公開する「IoTセキュリティ手引書 Ver2.0」も、IoT製品やサービスを開発・提供する場合に有用だ。本ガイドラインは、調達基準などの国際標準IEC62443や、米国セキュリティ規格NIST SP800-171に挙げられるセキュリティ要件をベースに、設計や製造、調達、量産、販売、サービス運用、廃棄などの製品ライフサイクルの各フェーズにおいて、検討すべきセキュリティ項目をまとめたもの。既存の開発フェーズにセキュリティ対策を盛り込みたいが何を検討すべきか分からないときに参考となる。

●IoTセキュリティ手引書 Ver2.0
 https://prtimes.jp/main/html/rd/p/000000070.000030782.html

「IoTセキュリティチェックリスト」

 メーカーとユーザーの双方で適切なセキュリティ対策が進み、IoT製品やIoT環境の安全が確保されたら、きっと“いたずら好きなお化け”も「もう何もできないや」と退散してくれることだろう。

■関連サイト

前へ 1 2 3 次へ

カテゴリートップへ

本記事はアフィリエイトプログラムによる収益を得ている場合があります

アクセスランキング

  1. 1位

    TECH

    フォーティネットの「SSL-VPN廃止」 IPsec移行と脱VPN、それぞれの注意点を総ざらい

  2. 2位

    ソフトウェア・仮想化

    「SaaSの死」の影響は感じない ― グローバル以上に好調な日本市場、ServiceNow鈴木社長が語る

  3. 3位

    ネットワーク

    ネットワークとセキュリティの統合に強み 通信事業者系ZTNA/SASEサービス3選

  4. 4位

    TECH

    「蟻の一穴」となるリモートアクセスVPNの脆弱性 ZTNA/SASEはなぜ必要か?

  5. 5位

    デジタル

    海外駐在員の負担を軽減し、ワンチームへ kintoneは言語と文化の壁を越える「翻訳の魔法」

  6. 6位

    ビジネス

    医療費5兆円抑制につながる“国産ヘルスケア基盤”構築へ SMBC×富士通×ソフトバンクが業務連携

  7. 7位

    エンタープライズ

    基盤も古いし、コードも酷い! そんなクエストにGitHub Copilotで試行錯誤しまくった「みんな」こそ最高

  8. 8位

    サーバー・ストレージ

    「30%ではなく“30倍”の生産性向上へ」 AIエージェント時代に求められるIT基盤、マイケル・デル氏が語る

  9. 9位

    ビジネス・開発

    いますぐ捨てたいITサービスは? AI推しにそろそろ飽きてません? 情シスさんのホンネを「ゆるっとナイト」で聞いた

  10. 10位

    ITトピック

    AIセキュリティで必要な6つの対策/20代の半数が「検索エンジンを使わない」/生成AIツールはエンジニアの「業務インフラ」へ、ほか

集計期間:
2026年05月19日~2026年05月25日
  • 角川アスキー総合研究所