AI攻撃を前提にシステム設計を見直す
生成AIの能力向上は、サイバー攻撃にも影響を与えている。記事では、Claude Codeを利用し、標的の発見や認証情報の窃取など、攻撃工程の80〜90％をAIに自律実行させたとされる事例を紹介している。
また、脆弱性が公開されてから攻撃に利用されるまでの時間が短くなっているという。記事で示された顧客事例では、最短約2時間で攻撃開始の兆候が確認された。
事実として記事が示す結論は、重要システムを「止めない」ことだけでは不十分であり、侵害が起きても被害を限定し、復旧を速める設計が必要だという点である。
対策の2本柱
1．脆弱性へ迅速に対応する
第一の対策は、システムを構成するソフトウェアを把握し、脆弱性が見つかった際に対象を特定できる状態を作ることだ。
- SBOM：ソフトウェアの構成要素を一覧化し、脆弱性の影響を受けるシステムを確認する。
- 修正パッチ：対象システムへ速やかに適用する。
- ネットワーク分離：パッチを適用できない場合、対象を外部ネットワークから切り離す。
記事によると、Anthropicは脆弱性発見能力を防御側で活用するため、AWS、Microsoft、Googleなどと「Project Glasswing」を立ち上げた。
2．侵害時の影響範囲を限定する
第二の対策は、システムをサービス単位に分散させ、一部が侵害されても他の機能やデータへ影響が広がりにくい構造にすることだ。
記事は、顧客情報と住所情報を別々のサービスで管理する例を挙げる。一方だけが攻撃されても、情報を結合した完全な形で漏えいしにくくなる。
マイクロサービスとAPIの役割
記事は、重要システムで従来型のモノリシックな構成だけに依存することへ疑問を呈し、マイクロサービスを利用した機能分割を提案している。
- マイクロサービス：データと機能をサービス単位に分け、障害や侵害の影響範囲を縮小する。
- API：サービス間の接続を明示し、業務機能ごとに独立した対応を可能にする。
- 複数サービスによる冗長化：同じ機能を提供する選択肢を複数用意し、一つの停止時にも業務を継続する。
API単位でソフトウェアやネットワークの障害対応を行える構成は、復旧時間の短縮にもつながると記事は説明している。
設計に使う2つの図
状態遷移図
状態遷移図は、システムが取り得る状態と、電文やAPIリクエストなどを受けて状態がどう変化するかを整理する手法である。
マイクロサービス構成では、記事はAPI単位で状態遷移図を作る必要性を指摘する。これにより、接続開始、処理、正常終了、エラーといった振る舞いをサービスごとに明確化できる。
データフローダイアグラム（DFD）
DFDは、業務内でデータがどこから来て、どのように加工され、どこへ保存・出力されるかを表す図である。
記事では、DFDはバッチ処理だけでなく、リアルタイムのトランザクションデータがどのように変換、処理、蓄積されるかを整理する用途でも有効だとしている。さらに、Systems of Insightのような分析基盤へ供給するデータの整理と可視化にも役立つという。
設計時の実践チェックポイント
- SBOMでソフトウェア構成を継続的に管理する。
- 脆弱性発見後のパッチ適用またはネットワーク分離手順を決める。
- 機能とデータをサービス単位に分け、侵害範囲を限定する。
- サービス間APIを洗い出し、API単位の状態遷移図を作る。
- DFDでリアルタイムを含むデータの流れを可視化する。
- 重要機能には代替サービスを用意し、全体として業務を継続できる構成を検討する。
記事から読み取れる設計思想
以下は記事の主張を整理した解釈である。AIによって攻撃速度が上がる環境では、全ての侵入を事前に防ぐ設計だけに依存するのは難しい。構成要素を把握する「可視性」、侵害を局所化する「分割」、停止時にも機能を補える「冗長性」を組み合わせることが、重要システムの継続性を高める鍵になる。
