モデルケースについて——本ページは、当社の技術・製品（Previento / GENBA Gate / クラウド・組込の構築）で構成した架空の事例です。業種・規模・システム構成は典型例として設定したもので、実在の企業・案件とは関係ありません。攻撃の手口は、防御のために一般に知られている範囲で記載しています。
想定するシステムと課題
複数の建設現場を抱える建設業で、安全管理のためにAIカメラ（危険検知）と環境センサーを現場に設置しているモデルケースです。機器はモバイル回線のルーター経由でクラウドへ映像とデータを送り、本社のネットワークとはVPNでつながっています。機器の管理画面は初期パスワードのまま、現場のネットワークは1つのセグメントで、カメラ・センサー・現場事務所のPCが同居していました。
「IoT機器が乗っ取られてDDoSの踏み台になった」という報道を受け、「現場の機器から本社に入られないか」「機器が何十台もあって、1台ずつ見ていられない」というご相談を想定しています。
AIによる攻撃は、こう来る
ATTACK SCENARIO
- 機器の探索——インターネットに応答するカメラやルーターの管理画面を、ツールが機械的に探す。機器の型番から、初期パスワードと既知の脆弱性が分かる
- 初期パスワードの総当たり——型番ごとの初期パスワードや、よく使われる組み合わせを順に試す。1台でも当たれば足場になる
- ボットネットへの組み込み——乗っ取った機器に不正なプログラムを置き、外部の指令サーバーと通信させる。機器は見た目には正常に動き続ける
- 現場内の横展開——同じセグメントの他の機器や現場事務所のPCへ、乗っ取った機器から接続する
- 本社への侵入——現場と本社を結ぶVPNを通って、本社の業務システムへ到達する。現場の機器は「信頼された内側」として扱われている
IoT機器は「小さなサーバー」です。パスワードを変えずに置けば、Webサーバーを初期設定で公開しているのと同じことが起きます。さらに、機器は数が多く、ログを1台ずつ見ることは現実的ではありません。入口を機器ごとに塞ぎ、「機器の通信がふだんと違う」ことを自動で見つける必要があります。
課題と解決アプローチ
⚠ CHALLENGE（課題）
- 機器の管理画面が初期パスワードのまま。インターネットから到達できる機器もある
- カメラ・センサー・現場PCが同じセグメントに同居
- 現場から本社へのVPNが「全部通す」設定で、機器が本社に到達できる
- 機器の数が多く、ログを1台ずつ見られない。ファームウェアの更新状況も不明
- 機器が乗っ取られても、外から見える異常がない
→
✅ SOLUTION（解決策）
- 機器ごとに個別の認証情報と証明書を設定。管理画面はインターネットから閉じ、現場ルーターのFWで外向き通信を必要な宛先のみに制限
- 現場ネットワークを機器用・事務所用に分離し、機器から本社へは必要な通信だけを許可
- 現場ゲートウェイ（GENBA Gate）で通信を集約し、Previento へ機器ごとの通信の宛先・量・時間帯を送る
- 機器の通信パターンの変化（新しい宛先、量の急増、夜間の通信）をAIが検知し、該当機器を遮断
- ファームウェアの一括管理と、エッジ側での異常検知を組込で実装
防御の構成（従来型の層 ＋ AIの層）
インターネット（機器探索・初期パスワード総当たり・指令サーバー） │ ▼ [入口] 現場ルーター FW ── 管理画面は外部から閉鎖、外向き通信はクラウド収集先のみ許可 │ ▼ [分離] 現場ネットワーク ├─ 機器セグメント：AI カメラ・センサー │ ├─ [認証] 機器ごとの個別パスワード・証明書（初期パスワード撤廃） │ └─ エッジ側：組込で通信の宛先・量を自己監視、異常時はゲートウェイへ通報 └─ 事務所セグメント：現場 PC ── 機器セグメントとは直接通信不可 │ ▼ 現場ゲートウェイ GENBA Gate ── 本社 VPN は 必要な通信のみ許可（機器 → 本社業務システムは不可） └─ [監視] 機器ごとの通信記録（宛先・量・時間帯）を Previento へ │ ▼ Previento（クラウド） ├─ 機器ごとのふだんの通信パターン（宛先・量・時間帯）を学習 ├─ 新しい宛先への通信・量の急増・夜間の通信を検知 ├─ 機器から現場内・本社への想定外の接続試行を重大で通知 └─ 重大 → 該当機器をゲートウェイで遮断 ＋ Slack / LINE 通知
凡例：緑＝従来型の防御（ファイアウォール・WAF・VPN・認証・分離）／青＝AIによる監視・判定（Previento）／赤＝攻撃
AIは、ここで何を判定するのか
- 機器ごとの「ふだん」を学ぶ——AIカメラは「クラウドの収集先へ、決まった量の映像を、稼働時間帯に送る」機器です。宛先・量・時間帯のふだんを機器ごとに学び、そこからのずれを異常とする。何十台あっても、人が1台ずつ見る必要がない
- 乗っ取りは「外向きの通信」に出る——ボットネットに組み込まれた機器は、見た目は正常でも、指令サーバーという新しい宛先と通信し始める。入口の防御で入られても、この「新しい宛先」で気づける
- 機器からの内向きの接続は、それ自体が異常——カメラが現場PCや本社の業務システムへ接続する理由はない。機器セグメントから他への接続試行は、成功・失敗を問わず重大として通知する
- エッジ側でも見る——回線が細い現場では、すべての通信記録をクラウドへ送れないことがある。組込ソフトとして機器やゲートウェイ側に軽量な自己監視を実装し、異常の要約だけを送る設計にする
当社はAIカメラ（GENBA IQ）や拠点間VPNゲートウェイ（GENBA Gate）、マイコンの組込ソフトを自社で開発しています。機器側の認証や自己監視を組込で実装できることが、このケースで入口から監視までを一貫して設計できる理由です。
導入ステップ（想定）
Week 1
現状調査
機器の型番・ファームウェア・認証情報の状態、現場ネットワークの構成、VPNの許可範囲を読み取りで確認。工事を止めない
Week 2
暫定策
全機器の初期パスワード変更、管理画面の外部公開停止、VPNの「全部通す」ルールの削除
Week 3-5
分離とゲートウェイ
現場ネットワークを機器用・事務所用に分離。GENBA Gate で通信を集約し、外向き・本社向けの通信を必要な宛先のみに制限。現場ごとに順次適用
Week 4
Previento と機器認証
機器ごとの証明書を配布。ゲートウェイから Previento へ通信記録を送り、1〜2週間かけて機器ごとのふだんを学習
Week 7〜
継続
ファームウェアの一括更新、新しい現場・機器の追加時のテンプレート適用、月次レポート