このページの本文へ

セキュリティにかかるコストも許容できない? IoTビジネスにおける現実解を探る

IoTセキュリティに向けた“シフトレフト”が一筋縄ではいかない理由

2019年03月22日 07時00分更新

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

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

 セキュリティ業界では長らく提唱されている「シフトレフト」(プッシュレフトとも呼ばれる)。ソフトウェア開発ライフサイクルの初期段階(企画、設計など)から「セキュリティ」や「品質」の検討を行うべし、という概念だ。従来のように、開発が進んだ後にセキュリティや品質を“後付け”で考えるのではなく、より早い段階(時間軸で左方向=レフト)に移動(シフト)させることで、テストやリリース、運用後の段階になって脆弱性やバグが見つかるリスクと、その対応コストを軽減させることができる。

 シノプシスでシニアテクノロジーエバンジェリストを務めるティム・マッケイ氏は、アプリケーションの大規模化によって数十~数百もの脆弱性が潜在し、それが日々報告されるようになった現在、WAFのような外付け/後付けのセキュリティだけで保護するというアプローチは「非現実的だ」と指摘する。

シノプシス ソフトウェアインテグリティグループ シニアテクノロジーエバンジェリストのティム・マッケイ氏

 マッケイ氏によると、脆弱性やバグが発生する背景には、開発者個人がコーディングを学ぶ過程で身につけてしまった「悪習慣」があるという。現在のモダンなIDE(統合開発環境)には適切かつセキュアなコーディングを支援する機能が備わっているので、開発を続けながら知識を得ることができ、それによってより高品質でセキュアな製品/サービスが開発できるようになる。

 特にシフトレフトは、開発-リリース-改善の作業を短いサイクルで繰り返すアジャイル手法や、開発~運用のライフサイクルを効率的に回すDevOpsと相性が良いと、マッケイ氏は説明する。「最近は大規模アプリケーション開発の現場でもアジャイル開発手法の採用が始まっており、それにあわせてセキュリティの観点を(開発サイクルに)取り込む動きも活発化している」。

 こうして考えると、シフトレフトはこれからのソフトウェア開発において当然取るべきアプローチのように見える。だが、これがIoTの組み込みソフトウェア開発となると話はやや複雑だ。と言うよりも、そもそもIoTには“シフトレフト以前”の課題がある。

 まず、多くのIoTデバイスではメモリ容量やCPU性能といったハードウェア面での制約がある。メモリ容量が足りないために通信暗号化のためのHTTPS/TLSをフルスタック実装できない、あるいは新しいファームウェアの保存領域が確保できずOTA(Over the Air)アップデートが不可能、といったケースもある。

 もっとも、こうしたケースであれば、少し容量の大きいメモリチップを搭載するようにすれば解決できるはずだ。しかし、そこには「製品コスト」という大きな壁が立ちはだかる。

 「搭載するチップの価格が1.5ドルから1.8ドルに上がる程度でも、それが価格に反映されることで、製品によっては競争力に影響することもあるだろう。そもそもIoT製品は長期にわたって使われることも多く、ベンチャーの中には『自社の寿命を超えてまでセキュリティを担保する必要などない』と考える、つまり、セキュリティにコストをかける発想すらない者もいるかもしれない」

 もうひとつ、ハードウェアならではの悩みがある。ソフトウェアアップデートが可能なIoTハードウェアの場合、将来的に機能/サービスの追加を行う可能性を見越して、現時点では使わないモジュールをあらかじめ搭載しておくことがある。ビジネス戦略上、技術仕様書にも書かないことがあるかもしれない。しかし、あえて隠すことがセキュリティやプライバシーの問題をはらむ場合には、大ごとになってしまう。

 グーグルの「Nest Guard」デバイスをめぐる騒動がその良い例だ。これは同社のホームセキュリティサービス「Nest Secure」用のデバイスだが、2017年のサービス開始当初、マイクを内蔵していることは公表せず、技術仕様にも記載していなかった。だが、およそ1年後に音声アシスタント機能の追加を発表したことで内蔵マイクの存在が明るみとなり、「グーグルは秘密裏に会話を盗聴していたのではないか」という疑惑さえ取りざたされることになった。

 「セキュリティに加えて、プライバシーの観点からも製品やサービスを見直すことが必須の時代となった」(マッケイ氏)

 どうすれば現実的なかたちでIoTセキュリティを担保できるのか。マッケイ氏はやはり、デバイスメーカーや開発者の側の意識を“シフトレフト”に変えていくしかないと断言した。

 「たとえば製品に搭載するチップを選ぶとき、MQTT、Bluetooth、Wi-Fiなど、選択肢となるプロトコルスタックが多数あるのであれば、どれが最もセキュアに運用できるのかをファジングツールを使って検証し、その分析結果を自社のレピュテーション(評価)やビジネス価値などとも照合して、最適解を探るべきだ」

■関連サイト

カテゴリートップへ

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

アクセスランキング

  1. 1位

    ビジネス・開発

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

  2. 2位

    ITトピック

    「AI導入で人員を減らしても収益は増えない」その理由/「専任情シス不在」中小企業の3社に2社/ユーザーアカウント流出が加速、ほか

  3. 3位

    エンタープライズ

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

  4. 4位

    Team Leaders

    Power AutomateでSharePoint APIを使う ― SPOリストを自動作成するフローを作ろう

  5. 5位

    sponsored

    完全自動運転の実現へ、チューリングが開発基盤にGMO GPUクラウドを選んだ理由

  6. 6位

    ソフトウェア・仮想化

    日本の自治体がみんな使っている「ManageEngine」 IT運用のすべての課題解決を目指す

  7. 7位

    クラウド

    「すでに開発コードの4分の3はAI生成」 Google Cloud CEO、エージェント時代の戦略を語る

  8. 8位

    ソフトウェア・仮想化

    AIエージェントを野放しにしない ― ServiceNowは“AI司令塔”で自律とガバナンスを両立

  9. 9位

    ビジネス・開発

    「粗悪記事」「ゼロクリック」「搾取」からクリエイターをどう守るか? AIに強いnoteが挑む創作エコシステム

  10. 10位

    TECH

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

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