はじめに
ご無沙汰しております。ABEJAの大田黒（おおたぐろ）です。前回は弊社TechBlogにて、数千人規模のイベント向けに顔認証技術を利活用したお遊びプロダクトの設計・開発・デリバリーについての裏側を執筆させて頂きました。
今回のテーマは少しニッチな内容にはなりますが、自社で提供しているIoTソリューションにおけるセキュリティまわりの取り組みについて、ご紹介させていただければと思っております。
IoTデバイスを取り巻く環境
近年、IoT (Internet of things)の発展＆普及により、スマホから家の鍵をロックできるようになったり、スマートスピーカー経由で家電を制御したり等、IoT製品がかなり身近になってきました。IoTという単語は2014年ぐらいからキーワードとしてバズりはじめ、ようやく最近当たり前のようになってきました。そんなIoTの市場ですが、2030年(約10年後の日本)の日本において、IoT・AIによる経済成長へのインパクトは約270兆円に相当するとシミュレーションされています。GDPにして132兆円もの押し上げが生じると想定しており、AIと同様にIoTが日本の将来を背負う重要な技術として認識されています。既に盛り上がってきてますが、これからもっともっと盛り上がってくると予想されている感じです。
そんなIoTですが、市場の成長と合わせて、セキュリティに関わる問題も報告されています。上記は2019年にNICTERが観測した主な攻撃対象をDSTポートベースで分析したものですが、IoT関連機器（図中青色部分）への攻撃がほぼ半数を締めている事が確認できます。近年のサイバー攻撃への関心がIoT機器にある事が確認する事ができます。（※攻撃に関する詳しい情報は下記リンクより確認可能です）
IoT製品は、上記のようなインターネット経由からの攻撃はもちろん、物理的なリスクがある等、様々な脅威にさらされています。こういった環境下でIoTを使ったソリューション提供には、幅広い観点でのセキュリティ対策が必要になってきます。今回は、ABEJAにおける取り組みや考え方をいくつか紹介できればと思っています。
ABEJAにおけるIoTの利活用
我々の会社名を聞いて「AI」を想起される方は非常に多いのではないかと思っております。「AIの社会実装」を実現する為には、AIの単一領域技術だけでは難しく、Web・BigData・IoT等の周辺領域技術との連携が必要になります。ABEJAでは、実際にIoTを活用したソリューションも多く研究開発＆運用しており、既に数千台近いデバイスのプロダクション運用実績があります。この章では、ABEJAで提供するIoTを使ったソリューション例を簡単にご紹介させていただければと思います。
例：製造業での適用例 (機械部品の自動検品)
Fig 1: Jetson等の組み込みGPUボードを利用したソリューション例
システムの構成例
これらのソリューションでは、現場にIoTデバイス及びNW機器を設置しており、AIの推論をエッジもしくはクラウド上で推論を行っています。現場に導入するIoTデバイスやNW機器の構成は、お客様のニーズに合わせた設計開発を行っています。例えば、低レイテンシ(数十msec以内での推論)が求められる環境(自動検品等)では、推論処理をエッジ側で完結させる為にGPUを搭載した組み込み機器等を設置しています。
（余談ですが、JetsonみたいなGPUを搭載した組み込みボードがなかった時代、虹色に光るゲーミングPCを使ってPoCを進めたりしていた時代もありました...笑）
ABEJAの立ち位置
IoTに関わるプレイヤーには、大きく分けて「デバイスメーカー」「ソリューションの設計・開発・提供ベンダー」「機器設置工事業者」といったプレイヤーがいます。ABEJAでは、各パートが小規模ではありつつも、全ての領域がカバーできるナレッジを持ったメンバーが在籍しており、チームプレイで上記のようなソリューション開発とデリバリーまでを行っています。(昔は中国でデバイス製造までやっていた時期がありました。ABEJA新卒時代は、組み込みデバイス用のFW書いたりQCしたり色々してました。最近は、デバイスを作るよりは利用をする側を重視しており、デバイスメーカーと協業したデバイス提供の方へシフトしています。）
顧客ニーズを満たす為には、適材適所の技術選定とその研究開発がもちろん必要になりますが、お客様が安心してシステム導入・運用できる状態を継続的に作るには、セキュリティ対策が必要になります。次のセクションでは、ABEJAにおけるIoTデバイス導入・運用におけるセキュリティの考え方や行っている事の例などをご紹介できればと思っています。
IoTにおけるセキュリティの考え方
ITの世界では幅広く知られるところではありますが、基本的に「セキュリティ」と「コスト」「利便性」「デリバリー速度」はトレードオフ関係にあります。いわゆるQCDの話ではありますが、IoTの世界においても例外ではありません。特にIoTデバイスの場合、クラウド上に完結したWebサービスの特性とは異なり、デバイスやNW機材の物理盗難によるリスクもシナリオとして考える必要性があります。またIoTの市場が大きくなるにつれて、IoTデバイスへの攻撃件数の増加・攻撃手法の多様化も報告されています。そういった状況下で「全ての攻撃パターンを事前に把握して全てのパターンを対策していく」といったリスク真正面対抗アプローチでは、対策に必要なコスト・時間的投資が青天井になってしまい、IoTを活用したソリューションの導入を非現実的なモノに変えてしまいます。一方で、セキュリティ対策を怠り、適切なアクションを打たないと下記のようなインシデントを引き起こす可能性もあります。
IoTデバイスに関わるインシデントの例
- ①リモートからの不正侵入による情報流出被害や攻撃の加害者となってしまう事 (IoTに限らず一般的なシステムでも同様）
- 例: IoTデバイスを踏み台にし、顧客システムに対してウイルス感染被害や意図しないデータアクセスが発生する
- 例: IoTデバイスに完成したマルウェアがC&Cサーバーからの司令で特定サーバーにサイバー攻撃(DDos等)を仕掛ける
- ②ネットワーク機器盗難による接続情報流出と不正侵入被害 (IoT +一般的なシステムでも同様)
- 例：顧客または関連会社のサービス基盤にアクセスができてしまい、意図しない情報の外部漏洩やサービスダウンが発生する
- ③デバイス盗難(or デバイスのストレージ盗難)による技術流出や機密データの流出 (IoT特有)
- 例：汗と涙の結晶である機械学習モデルやソースコードといった情報資産が流出し、競合他社に利用される→競争力を失う
こういった状況下において、IoTデバイスを使ったソリューション・サービス提供をする一つのベンダーとして、下記のような基本スタンスで導入と運用を進めています。
大事なこと
お客さんや関連企業を確実に守りつつ、AI・IoT利活用による課題解決（DX実現等)に全集中
- インシデントに繋がりうる想定ケースに対して、効果的に防ぐための防御手段を講じる
- ※詳しいアクション例は後述します
- 妥協スタンスでセキュリティ対策を行わない
- 外部の脅威だけではなく、内部の脅威にもしっかり目を向けて守る
- 情報資産や業務を守ることはもちろん、誰かを「加害者」にする事があってはならない
- インシデントに繋がりうる想定ケースに対して、効果的に防ぐための防御手段を講じる
IoT関連機器の運用はライフサイクルが長くなる事が想定される為、長期に渡る保守運用を前提に考える
- 導入したら終わりという事はない
- むしろ導入してからが本番。IoT運用。
- IoTデバイスやネットワーク機器は、故障するし、交換やメンテナンス作業は発生する。
- デバイスにもよるが、「初期不良」「群発故障」「摩耗故障」といったバスタブ曲線と似たような特性がある（肌感）
- 保守運用作業（交換対応）まで含めて、考えていく必要性がある。
- 導入〜運用まで含めた幅広く、長いケアができるような仕組み・体制を作る
- 導入したら終わりという事はない
「機密性(Confidentiality)」や「完全性(Integrity)」だけではなく、「可用性(Availability)」も気合を入れる
- 機密性と完全性を追い求めすぎると、可用性が低下するケースがある。トレードオフがある。
- 可用性の低下＝お客様の業務停止につながる事があるので、可用性の担保もセキュリティ対策の重要課題として認識する
- IoTソリューションの可用性低下によるトラブルは、かなりクリティカルな問題に発展するケースが有るので要注意。
- 例）経営会議での意思決定に使う重要データが取得できなくなる
- 例）製造ラインが止まり、直接的な損害が発生する。
- Design for Failure思想
- 故障や交換を前提にして、ソリューションが動き、継続的な課題解決ができるシステム構成にする
- 冗長化等のシステム的な対応にとどまらず、人・組織を巻き込んで体制化するところもセットで。
- 機密性と完全性を追い求めすぎると、可用性が低下するケースがある。トレードオフがある。
お客様に安心して導入・運用できるようなコミュニケーションを心がける
- お客様組織内部の導入担当部門及び情報システム部門と連携し、不安点が解消できる形のシステムを提案する
- 丁寧な対話を重ねつつ、セキュリティ要件をPASSするシステム構成や運用体制を決める
- QCDの観点から案件のフェーズに応じたセキュリティレベルの合意を行う
- PoC→本番フェーズに移行するタイミング等で段階的にセキュリティレベルを上げていく
- お客様組織内部の導入担当部門及び情報システム部門と連携し、不安点が解消できる形のシステムを提案する
IoTにおけるセキュリティ対策のご紹介 (一例)
ABEJA社内では、基本的に「①仕組みで徹底的に守る」「②異変にすぐ気づく為の仕組み」「③迅速な対策適用ができる仕組み」という３本柱で各種対策ア クションを実施しています。②と③は万が一守りきれなかった時の為の対策アクションです。
※この章では、対策アクションの一例についてご紹介できればと思います。
※ここでは、過去にやったことがある事を事例としていくつか上げています。後述しますが、理想と現実のギャップがある中で、ROIや案件のフェーズ、各種トレードオフを考慮したアクション採用が必要になります。
アクション3本柱 + α
1.「仕組み」で徹底的に守る
物理
デバイスの物理的な隔離 (Isolation)
- IoTデバイスやNW機材が不特定多数の人に触れられるところに設置しない
- IoTデバイスやNW機器を顧客環境のセキュリティ区画下に設置する -「機材への物理アクセスの容易さ」と「機材の物理メンテナンス性」はトレードオフがあるので注意する
- IoTデバイスやNW機材が不特定多数の人に触れられるところに設置しない
不要なアクセスルートを閉じる
- Bluetooth機能をOFFにする (※使用しない場合)
- BlueBorne等の脆弱性に対する対応
- 不要USBポートは塞ぐ or 機能OFFにする
- 運用性とのトレードオフがあるので注意
- Bluetooth機能をOFFにする (※使用しない場合)
ネットワーク
ネットワーク機材の物理的な隔離 (Isolation)
- 顧客環境NWとは独立したNW機材の利用
- ルーターやL2スイッチはABEJA側で用意し、顧客環境とは独立したネットワークの構築を実施
- 顧客環境NWとは独立したNW機材の利用
デバイス及びネットワークの論理的な分離
- IoTデバイスを直接外部ネットワーク(インターネット等)に接続しない
- 顧客側で契約したISP・WANを利用せず、ABEJA側で用意したプロバイダー情報を利用する
- ※ABEJAでは、たくさんのIoTデバイスを高速に導入・セキュアに運用する為に、たくさんのIPアドレスと接続情報を保有しています
- 認可されていないデバイスの接続拒否
- Macアドレスフィルタリングは、利便性低下リスク＆有効性低いので注意。
ファイアウォールやNATゲートウェイの設置
- 接続の発着信はホワイトルール形式にし、意図しないコネクションは全て弾くようにする
- 他ネットワークとの通信は全てNATを経由する（インターネット通信含め）
End-to-Endの暗号化伝送路の構築
- サービスの管理者、ISP事業者による盗聴を前提としたデータ伝送路構築を行う
- 当たり前ではあるが、平文でネットワークに機密情報を流さない
本体固有情報に基づいた機材の信頼プロセス
- クラウド側との通信や顧客側情報資産にアクセスする場合、改ざんが難しい本体の固有情報を使いつつ、認証やメッセージの署名を行う
データ
- ストレージ内部データの暗号化
- IOボトルネック問題があるため、適用は慎重に。
- ソリューション例
- 例: OpenSSLを用いたファイルやオブジェクト単位の暗号化
- 例: fscrypt(ext4 encryption)を用いたディレクトリ単位の暗号化
- 例: luks/dm-crypt, BitLockerを用いたブロックストレージ単位の暗号化
- 例: SED, OPALを用いたストレージハードウェアでの暗号化
メンテナンス
クラウド側や連携サービスの情報アクセスにMFAを認証
- IoT側だけではなく、関連システムのセキュリティレベルも高める
SSHの認証にEd25519鍵を利用
- エドワーズ曲線デジタル署名アルゴリズム
- 強度・パフォーマンスのメリットに加えて、side-channel攻撃を受けにくいメリットもある
- SSHの認証に
二段階認証を適用- 利便性へのインパクトあり。HW及びOSのスタックの問題で高強度の鍵が使えない場合等で使うのが良いかも...?
- 例: google-authenticator-libpamの利活用
アプリケーション
認可されていないデバイス上でのアプリケーション立ち上げ禁止
- プロダクションビルドされたアプリケーションは起動できる環境を絞る
アプリケーションの実行ユーザーに気をつける
- rootアカウント利用は要注意
デバイス内アプリケーションのコンテナ仮想化と権限管理
- リッチなデバイスでは可能だが、コンテナ仮想化に必要なカーネルモジュールを持たない組み込み機器も多く存在
- RaspberryPiやJetsonレベルのデバイスであれば、実現可能。
2. 異変にすぐ気づく為の仕組み
デバイス
デバイスメトリクスやイベント監視とアラート
- CPU、メモリ、プロセス等の監視
- 各種イベントの監視
- SSHログインイベント
- 特権ユーザー行使
- 意図しない電源のON/OFFイベント
各種セキュリティ機構の導入とアラート
構成管理テストの定期実行
- 例: goss, InSpec, serverspec
- ファイルやプロセスやLISTENしているポート開放状況の理想状況との乖離がないか調べる
ネットワーク
ネットワークの監視とアラート
- ネットワーク型IDS/IPSの設置
- フローデータの蓄積と分析
脆弱性テストの定期実行
3. 迅速な対策適用ができる仕組み
攻撃に対する対応
- 不正アクセスイベントの自動検知と自動対応
- 例: fail2banの導入
- パスワード間違えると厄介だが、結構効果的。
- 例: fail2banの導入
被害拡大防止
- デバイスのIAMベース認証 (※クラウド側と連携する場合）
- トラブル発生時にデバイスのトークンのrevokeや紐づくユーザーIDを無効化する仕組み
保守対応
- FWのリモートアップデート機構
- OSやアプリケーション、各種ライブラリをリモートアップデートできる為の仕組み
- 万が一、問題が見つかった時に迅速にパッチをデリバリーできるようにする
4. その他
機密情報の取り扱い
- (大前提として) IoTデバイスや周辺ストレージ及びネットワーク上に機密情報を可能な限り配置しない
- 最低限の機密情報保持とする事が一番効果的な気がします
デバイスマネジメント
Fig: デバイスマネジメントの為の社内システム
- デバイスマネジメントの徹底
- 物理機材と情報資産の所在を管理するシステム・体制づくり
- FWや脆弱性情報とセットで管理する為の仕組みも一緒に必要
- Prod(顧客環境)で動いているデバイスだけではなく、社内の開発用デバイスなども管理対象にする
- 確実なサービスアウトの為のフロー設計と体制づくり
- 機密情報の入ったデバイスや機材を撤去し忘れる等を防ぐ
- サービスOUT時は確実にデバイスを破棄できるように各種調整をする
- 物理機材と情報資産の所在を管理するシステム・体制づくり
フロー・体制面
デバイスを巻き込んだDevSecOps
- ソフトウェア開発ライフサイクル(SDLC)に「セキュリティ」を組み込む
デバイスのメンテナンス対応（現地作業）をする為のフロー・体制づくり
- 設置して終わりではなく、継続的に保守運用ができるようにする
- IoTはトラブルがつきもの。何かあった時に機動性高く動ける土壌が必要。
ポリシー
- セキュリティポリシーの設計と運用体制の構築
- デバイスアクセスに必要なパスワードは強固なモノを採用する
- 民生品のIPカメラを利用するときは、絶対に初期設定のパスワードのまま運用しない
- 仮にインターネットに繋がっていなくても...
- デバイスアクセスに必要なパスワードは強固なモノを採用する
すすめる上での色々なギャップ
理想と現実のギャップ
上記で紹介した取り組みは、全てを実現する事は現実的に難しいケースがあります。ソリューション提供をすすめる中で実際に直面した問題例を下記に列挙しました。
HWリソース/NWリソース関係
- 選定したIoTデバイスのリソースがリッチではない為、限られたセキュリティ機構を搭載できない
- 例: ウイルススキャンやホスト型IDS/IPSの負荷が重すぎて、OOMでアプリが落ちる＆推論パフォーマンスが劣化する
- 例: SSHの鍵強度がRSAしか選択できない
- IoTデバイスが利用するインターネット回線(モバイル回線網）の帯域が細い・送信できるデータに限りがある
- 例: クラウドに全てのセキュリティ関連ログをリアルタイムに送ると、ギガを使い果たす
- セキュリティイベント取得しすぎて、ストレージの寿命起因で製品寿命が想定より短くなる
- 例: SDカードをメインストレージとして使うタイプの組み込みデバイスでは要注意（経験談）
- RAMディスクの活用やネットワーク越しにログを投げる等回避策はあります
プロジェクト進行関係
- スピード感が命なPoC案件においてPJ進行を妨げる要因になる可能性
- 例: セキュリティ担保の仕組みにフォーカスしてしまい、コアバリューの実装が遅れる
- 過度なセキュリティ機構の開発により、顧客課題に向き合えなくなる
- ほぼ上記と同様。コアバリューの実装が遅れる。
- 仕組みを入れすぎて運用負荷が高くなりすぎて、運用が回らなくなる
- 例: 取得したログが多すぎて監査が追いつかなくなり、見なくなる
人・組織関係
セキュリティ対策で講じた仕組みがキツすぎて開発者体験(DX: Developer Experience)が著しく低下する
- 例: デバイス上の機械学習モデルの更新をする為のデバイスログインが複雑。めんどくさくなる。
仕組みが複雑化した結果、誰も仕組みの全体像を理解できなくなり、開発と運用の両方ができなくなる
DevSecOpsしたいけど組み込みに詳しいセキュリティスペシャリストがなかなかいない
思想面のギャップ
境界防御型 VS ゼロトラスト
近年、「ゼロトラストセキュリティ」という考え方が浸透しています。そういった中で、絵に書いたような「境界防御型モデル」を見て違和感を感じた方も少なくないと思います。GoogleもBeyondCorpを公開する等、主要なITのプレイヤーがコミットしている事から、今後、不可逆で強い技術トレンドになってくると個人的には信じています。「ゼロトラスト」というパラダイムの市場期待が高まる中で、「境界防御型モデルは危険だと聞きました」という方もいらっしゃいましたので、改めてIoTソリューションへの適用について考えてみたいと思います。
実装観点
参考：政府情報システムにおけるゼロトラスト適用に向けた考え方
ゼロトラストな考え方はネットワーク業界で今後主流になってくる考え方になるとは思いますが、たくさんの仕組み（ID管理システム、脅威インテリジェンス、アクセスポリシー管理、アクセス可視化、ポリシーエンジン、ポリシーエンフォーサー）とその仕組みに対応したNW機材・デバイス採用等、非常にコストがかかってくるもになります。2021年現在、これらを実現するIoT向けのプラットフォーマーはいくつか誕生していますが、まだデファクトスタンダードに至っているモノはないと考えています。(点で実現する為のソリューションはいくつかでているので、複数ソリューションを組み合わせる事で実現はできそうですが、まだ運用負荷は高そうなイメージです）
情報アクセス観点
ゼロトラストが想定するようなアクセス端末（不特定多数＆多様な環境下で従業員PC）と産業用やサービスに組み込まれるIoTデバイスには下記のような違いがあります。
顧客ネットワークの情報リソースへのアクセスが限定的
- 例：特定のDBにデータ取得結果を書き込む等
ガイドラインやポリシー上、既に高いネットワーク分離レベルが既に求められる (既に分離されている)
- 例: 制御情報系NW、制御系NW、デバイスNWといった分離レベル
TPMモジュールを持たず、エージェントソフトウェアの導入さえ難しいデバイスが存在している
- 例：民生品カメラ等は、OS等をいじる事ができない
- 例：MIPS向けにビルドされている必要性がある
限定的な情報リソースへのアクセスと役割を持ったIoTデバイスの限定的導入(エンタープライズネットワークにJOINしない）であれば、「境界防御型モデル」を前提に地に足のついた各種対策を複数組み合わせる方が、ROI観点や運用管理観点でも良いと考えています。一方で、IoTデバイスが組織ネットワーク全体に広がる様々な情報資産に対してR/Wしたり、複数種類のIoTデバイスが動的に組織内ネットワーク上で運用される場合は、ゼロトラストな構成を検討していっても良いかもしれません。
ギャップとの戦い方
上記取り組みは、ITやIoT業界では広く知られた教科書的なプラクティスが含まれており、またIoTセキュリティに関わるガイドラインにも準拠するような取り組みになっています。また、実際に実施しようとするとぶつかる壁（理想と現実のギャップ）もあるという事もご説明させていただきました。
(IoTに限らず、ITシステムの導入全般でも同様ですが・・・）向き合い方としては、下記の様なスタンスで地道に向き合っていくしかないと考えています。
スイスチーズモデル（多層防御モデル）の考え方に則り、実装や運用コストの観点から合理的な複数の対策を採用
- ROI及び案件進行のレベル感（First PoC, Second PoC, ... , Production)に見合ったセキュリティ対策の提案
各ステークホルダーが受容可能なレベルまでリスクを低減させる
- セキュリティ機構実装に伴う各種トレードオフの共有と説明
- 社内、関連企業、お客様、お客様企業内の情報システム部門...
- セキュリティ機構実装に伴う各種トレードオフの共有と説明
実際に携わってみると痛感するところではありますが、なかなかハードな事がおおく、最初のPoC前の議論フェーズで躓くことも多くあるかと思います。（経験談）
次回予告
- どのようにして案件毎に技術の選定が異なるIoTシステムでにおいて導入や運用の再現性を持たせるか？
- IoT運用に必要なセキュリティ機構を中長期的にワークさせるには、どのような仕組みがあると良いか？
- 守りではなく、攻めのセキュリティ対策はできないか？
上記のような問いからスタートし、今回、IoTデバイスをセキュアに導入・運用する為の非公開プラットフォーム（ABEJA IoT Core)を社内向けに試作したので、次の記事でご紹介ができればと思います。
余談
これはABEJAでの仕事ではなく、完全にプライベートの話ですが・・・猫の首輪にBLEタグを付けて家の中の行動をトラッキングするプロダクトを趣味で作っていた時でした。カフェ等の家の外から簡単に開発できるようにと、使っていたRaspberryPiをグローバルIPアドレスでアクセスできるようにしていたのですが、ちゃんとセキュリティ対策をとっていなかった為、トロイの木馬に感染してしまいました。
僕の試作プロダクトのコード以外はシステム上になかった為、特に大きな被害はありませんでした。今回は、RaspberryPiのSDカードをワイプしてキッティングし直す事で開発を継続する事ができましたが、「IoTデバイスへの攻撃は実際に存在している」という事を身にしみて感じる良い教訓となりました。他にも気づいたらビットコインを掘られてたとか色々エピソードはありますが、そういった教訓が今回の記事を執筆するきっかけの一つになっています。
※ちなみにその時感染したトロイの木馬は下記の記事と同様のものです。 www.tobsan.se
まとめ
今回、IoTに関する社内の取り組みや考え方についてお話させて頂きました。次回、非公開プラットフォームの話を投稿できればと思っています。
採用情報
ABEJAでは、一緒に働くメンバーを大募集していますー！少しでもご興味があれば、ご確認頂けますと幸いです！
IoT仲間もっと増やしたいですー！
Wantedlty等でラフにメッセージ頂いても全然OKです。
