モデルケースについて——本ページは、当社の技術・製品（Previento / GENBA Gate / クラウド・組込の構築）で構成した架空の事例です。業種・規模・システム構成は典型例として設定したもので、実在の企業・案件とは関係ありません。攻撃の手口は、防御のために一般に知られている範囲で記載しています。
想定するシステムと課題
関西と関東に拠点を持つ物流業で、配送管理・在庫管理の基幹システムをAWS上で運用しているモデルケースです。Webサーバー・APIサーバー・DBをEC2とRDSで構成し、社員は拠点やドライバーの端末からブラウザで利用。構築時のセキュリティグループは「とりあえず全部通す」設定が残り、管理コンソールと踏み台サーバーの多要素認証は任意でした。
取引先を装ったメールが社員に届くようになり、「盗まれたIDとパスワードで入られたら、WAFでは止まらないのでは」というご相談を想定しています。
AIによる攻撃は、こう来る
ATTACK SCENARIO
- AIが書いたフィッシング——取引先の文体・案件名を模した自然な日本語のメールで、偽のログイン画面へ誘導する。不自然さで見分けることはできない
- 正規の資格情報でログイン——盗んだIDとパスワードで、業務システムと踏み台サーバーへ、見慣れない接続元からログインする。認証は成功する
- 内部の偵察——踏み台から、到達できるサーバーとポートを探す。「全部通す」セキュリティグループなら、DBにも直接つながる
- 横展開——APIサーバー・DBサーバーへ順に接続し、権限の高いアカウントを探す
- 持ち出しと破壊——配送先の個人情報を大量に取得し、バックアップを消してランサムウェアを展開する
このケースの攻撃は、最初から最後まで「正規の認証」を通っています。入口のWAFも、パスワードの総当たり検知も反応しません。頼れるのは、通信を最小化して横展開の範囲を狭めることと、「正規のログインだが、ふだんと違う」「ログインのあとに横展開が続いた」という流れに気づくことです。
課題と解決アプローチ
⚠ CHALLENGE（課題）
- セキュリティグループが「全部通す」設定のまま。DBに踏み台から直接到達できる
- 管理コンソール・踏み台の多要素認証が任意
- 生成AIによる自然なフィッシングで、資格情報の流出が現実的なリスク
- ログイン成功は「正常」として記録され、誰も見ていない
- 侵入後に隔離する手順がなく、気づいても止められない
→
✅ SOLUTION（解決策）
- セキュリティグループとNACLを「必要な通信のみ」に最小化。DBはAPIサーバーからのみ
- コンソール・踏み台・VPNのMFAを必須化。パスワードのみのログインを廃止
- Previento で各サーバーのログイン成功の接続元・国・時間帯、横展開の接続を24時間判定
- 「見慣れない接続元のログイン成功 → 内部偵察 → 横展開」の相関を重大で通知
- 重大判定に応じて、当社が構築した連携で該当サーバーを隔離用セキュリティグループへ切り替え
防御の構成（従来型の層 ＋ AIの層）
フィッシングで盗まれた正規の ID・パスワード（見慣れない接続元から） │ ▼ [認証] 多要素認証 必須（コンソール・踏み台・VPN） ── パスワードだけでは入れない │ ▼ [入口] ALB ＋ WAF ── Web へのスキャン・攻撃文字列を遮断 │ ▼ VPC ├─ パブリックサブネット：踏み台（MFA・保守元 IP のみ） │ └─ [監視] Previento エージェント ── SSH ログイン・sudo・内部への接続試行を収集 ├─ プライベートサブネット：Web / API サーバー（EC2） │ ├─ [公開範囲] セキュリティグループ：ALB → Web、Web → API のみ許可 │ └─ [監視] Previento エージェント ── アクセスログ・ログイン・API の接続元を収集 └─ [分離] DB サブネット：RDS ── API サーバーからのみ接続可（踏み台から直接は不可） │ ▼ Previento（クラウド） ├─ 見慣れない接続元・国・時間帯からのログイン成功を「要確認」 ├─ ログイン後の内部ポート探索・横展開の接続を同じ接続元でつなぐ ├─ 個人情報を扱う API への大量アクセス・転送量の急増を検知 └─ 重大 → 隔離用セキュリティグループへ切替（当社構築の連携）＋ Slack / LINE 通知
凡例：緑＝従来型の防御（ファイアウォール・WAF・VPN・認証・分離）／青＝AIによる監視・判定（Previento）／赤＝攻撃
AIは、ここで何を判定するのか
- 「正規だが、ふだんと違う」ログインを拾う——社員の拠点・ドライバー端末の接続元と時間帯を信頼済みとして学び、それ以外の国・接続元からのログイン成功を「要確認」にする。失敗の連続がなくても、成功そのものが異常になり得る
- ログインの「あと」をつなぐ——見慣れない接続元のログイン成功のあとに、内部のポート探索や他サーバーへの接続が続いたら、「侵害の疑い」として1件にまとめて重大で通知する。1行ずつでは正常に見える操作も、並べると横展開が見える
- セキュリティグループの変化に気づく——「全部通す」設定への変更や、DBへの新しい許可ルールの追加は、攻撃者が横展開のために行う操作でもある。設定の変化そのものを検知の対象にする
- 止めるところまでを設計する——通知を見てから手で隔離するまでの時間が、持ち出しの時間になる。重大判定で該当サーバーを隔離用セキュリティグループへ切り替える連携を、お客様の運用ルールに合わせて当社が構築する
自動隔離は、誤検知で業務が止まるリスクと背中合わせです。当社は、まず通知のみで運用して誤検知を減らし、しきい値と信頼済みの登録が落ち着いてから、重大判定に限って自動隔離を有効にする段階的な進め方を提案します。
導入ステップ（想定）
Week 1
読み取り診断
セキュリティグループ・NACL・IAMの設定、MFAの有効状況、踏み台からの到達範囲を読み取りで確認。本番を止めない
Week 2
暫定策
コンソール・踏み台のMFA必須化、使っていないIAMユーザーとアクセスキーの停止、「全部通す」ルールの削除
Week 3-4
通信の最小化
セキュリティグループを「必要な通信のみ」に設計し直し、DBをAPIサーバーからのみに限定。変更は段階的に適用し、業務影響を確認
Week 3
Previento 導入
踏み台・Web・APIサーバーにエージェントを設置。社員の接続元・時間帯を信頼済みに登録し、通知のみで運用開始
Week 6〜
自動隔離と継続
誤検知が落ち着いたら重大判定に限って自動隔離を有効化。月次レポート、権限の棚卸し、フィッシング訓練の支援