このページの本文へ

前へ 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

    訓練だとわかっていても「緊張で脇汗をかいた」 LINEヤフー、初のランサムウェア訓練からの学び

  2. 2位

    ビジネス・開発

    最悪のシナリオは「フィジカルAI」による基幹産業の衰退 日本の勝ち筋は、“同期技術”と“ドメイン知識”

  3. 3位

    ITトピック

    若手が言わない“本音の退職理由”上位は/「データ停止は景気後退よりも企業の脅威」6割/クライアントに告げずAI活用するフリーランス、ほか

  4. 4位

    Team Leaders

    ファイル名が命名規則に合っているかの自動チェック、Power Automateのフローで実現しよう

  5. 5位

    TECH

    “GPUなし”ノートPCで動くLLMで、ローカルAIエージェントを自作する

  6. 6位

    TECH

    糖尿病超早期を採血なしで検出、予防へ! 代謝や臓器のつながりに着目した予防法開発

  7. 7位

    ビジネス

    廃校がAIの心臓部に!? 地方の遊休施設を「AIデータセンター」に生まれ変わらせるハイレゾの挑戦がアツいぞ

  8. 8位

    TECH

    業界横断で“サイバー攻撃から供給網を死守” NTT・アサヒ・トライアルらが「流通ISAC」始動

  9. 9位

    Team Leaders

    バックオフィス業務もAIに“丸投げ” マネーフォワードが「Cowork」機能を2026年7月に投入へ

  10. 10位

    sponsored

    AI議事録はもう「Zoom」1つでいい “やりっぱなしの会議”を次のアクションへ変える

集計期間:
2026年04月07日~2026年04月13日
  • 角川アスキー総合研究所