あるエンジニアが業務用パソコンで外部企業の採用面接課題を実行しました。本人は開発環境を設定しているだけのつもりでしたが、実際にはマルウェアによって pyenv の実行ファイルが差し替えられていました。数週間後、攻撃者は侵害したパソコンを利用し始め、さらに社内の AI ツールを通じて別のエンジニアのパソコンを制御し、最終的にコンテナのデプロイ用 token を入手しました。今や管理者は「この AI Agent は使いやすいか」と問うだけでなく、さらに踏み込んで「1 つのアカウントやエンドポイント（endpoint）が侵害された場合、攻撃者は AI Agent を通じてどのシステムに侵入できるのか」を確認する必要があります。
このような攻撃手法は、ラテラルムーブメント（lateral movement）と呼ばれます。攻撃者はまず 1 つのアカウントやエンドポイントを侵害し、既存の権限、接続、信頼関係を悪用して、攻撃範囲をほかの人やシステムへと広げます。企業が AI Agent を導入する際には、まず閲覧できるデータ、接続できるサービス、実行できる操作を制限し、問題がないことを確認してから段階的に業務範囲を拡大するべきです。最初からすべての権限、接続、操作を許可し、問題が発生してから見直す運用では、1 つのエンドポイントが侵害されただけで、より多くのシステムに影響が及ぶおそれがあります。
AI Agent は業務を遂行できる一方、攻撃者による他システムへの侵入を助ける可能性もある
iThome は、Binance が公表した初期調査について報じています。ハッカーはまず、改ざんされた開発ツールと偽の採用面接を通じて、ウォレット担当エンジニアの業務用パソコンに侵入しました。その後、10 月 20 日に侵害済みのパソコンと社内 AI ツールを利用して、別のウォレット担当エンジニア 2 名のパソコンを制御し、コンテナのデプロイ権限を持つ token を発見しました。10 月 30 日には、盗み出した認証情報を使ってコンテナをデプロイし、悪意のあるスクリプトを実行しました。さらにウォレット署名サービスへ侵入し、最終的に複数のブロックチェーン上のホットウォレットから約 63.4 億米ドル相当の暗号資産を流出させました。
この初期調査では、すべての技術的な詳細が明らかにされていないため、各段階を AI Agent が自律的に実行したと断定することはできません。しかし、この事件によって管理上の問題は明確になりました。社内 AI ツールが別のエンジニアのパソコンに接続でき、デプロイ用の認証情報を取得したり、高権限のサービスを呼び出したりできる場合、攻撃者は 1 人のユーザーのアカウント権限を奪うだけで、そのユーザーが持つ既存の接続や権限を悪用し、ほかのシステムへ侵入できる可能性があります。台湾企業でよく見られる状況に置き換えると、営業担当者の見積書作成を支援する AI Agent に、仕入れ価格の下限を読み取る権限、顧客マスタを変更する権限、本番環境へデプロイする権限まで同時に付与する必要はありません。
したがって企業は、各 AI Agent を誰が使用するのか、どの部門に属するのか、どのデータを閲覧できるのか、どのサービスを呼び出せるのか、どの操作を実行できるのかを洗い出し、その結果に基づいて検知対策を強化する必要があります。棚卸しの際には、「この権限が悪用された場合、攻撃者は次にどこへ侵入できるのか」と直接問いかけることが有効です。明確な業務上の必要性に結び付かない部門横断アクセスは、まず削除するべきです。また、デプロイ、権限変更、外部へのデータ送信といった高権限の作業は専用ロールに限定し、実行前に指定された担当者の承認を得る必要があります。
権限と接続はデフォルトで無効にし、業務上必要な場合のみ許可する
権限管理には、最小権限の原則（principle of least privilege）を適用できます。これは、各ユーザーと各 AI Agent に対し、現在の業務を完了するために必要な権限だけを付与する考え方です。企業は、ユーザーがログイン後に操作できる機能と、AI Agent がユーザーに代わってツールを呼び出す際に実際に読み取りまたは変更できるリソースという、2 つのレベルを個別に確認する必要があります。両者が共有する権限範囲が広すぎる場合、フロントエンドでロールを分けていても、バックエンドでの操作が業務上必要な範囲を超える可能性があります。
EgentWrX では、フロントエンドとバックエンドの権限を分けて設定できます。企業は組織階層に応じて組み込みロールまたはカスタムロールを設定し、各部門の担当者が自部門とその配下部門だけを閲覧できるよう制限できます。この設計により、一般ユーザーの利用権限とバックエンドの管理権限を分離できます。ただし、ロール名を設定するだけではリスクを軽減できません。導入チームは、各ロールが閲覧できるデータと実行できる操作を一つずつ確認する必要があります。管理上の利便性を理由に、高権限を長期間残したままにしてはいけません。
接続についても、同様の管理方法を採用する必要があります。企業は、AI Agent が接続する必要のある外部ドメイン、社内データベース、ツールサービスを一覧化し、デフォルトではすべて拒否したうえで、業務上の必要性に応じて個別に許可するべきです。EgentWrX の場合、外向き通信の許可リスト（egress allowlist）はデフォルトですべて拒否され、外部ドメインは一つずつ許可しなければなりません。また、AI Agent が社内ネットワークを経由して社内データベースを参照できるようにすることも可能ですが、データベース連携は読み取り専用で、書き込みはできません。こうした仕組みにより、AI Agent がアクセスできるデータと変更できるリソースを減らせますが、エンドポイント保護、認証情報のローテーション、開発ツールの入手元管理も省略してはなりません。
システムを評価する際には、「連携できるか」だけを確認するのではなく、システム責任者に接続先一覧、権限マトリクス、高権限操作の承認プロセスを提示してもらう必要があります。企業はまず、カスタマーサービス担当者による注文状況の照会や、品質管理担当者による検査基準の参照など、範囲が明確な業務を 1 つ選ぶとよいでしょう。読み取り専用権限だけで業務を完了できることを確認してから、ほかの操作を許可するかどうかを判断します。
エンドポイント保護が警告を出さなくても、AI Agent の操作履歴を追跡できるようにする
Binance によると、当時、エンドポイント保護ソフトウェアはマルウェアを検知できず、攻撃者は侵入の痕跡も隠していました。同社は以前、端末を交換して関連する認証情報をリセットしていましたが、エンジニアの職務情報や同僚に関する情報はすでに流出していました。事件後、Binance は影響を受けたウォレットシステムと社内 AI ツールを再構築し、関連する認証情報を無効化しました。また、独立したセキュリティ企業に再調査を依頼する方針も示しています。つまり、エンドポイントの警告は調査資料の一部にすぎず、警告がなかったからといって、AI Agent が悪用されていないと判断することはできません。
企業は、AI Agent の監査証跡も別途保存する必要があります。少なくとも、誰がいつロールを変更したのか、どの接続を許可したのか、どの高権限ツールを呼び出したのか、誰が監査記録をダウンロードしたのかを追跡できなければなりません。EgentWrX の監査ログは 55 種類のリソースタイプを対象としており、エクスポートセンターから出力できます。また、ハッシュチェーン（hash chain）を使って記録が改ざんされていないかを検証でき、管理者が監査記録をダウンロードした操作自体も記録されます。これらの記録は、企業によるインシデント調査や証拠提示に役立ちますが、すべての攻撃を防げることを保証するものではありません。
企業は AI Agent のログを正式にセキュリティインシデント対応プロセスへ組み込み、平常時から定期的にログをエクスポートして、記録が完全であるかを検証する必要があります。インシデント発生後は、エンドポイント、ID、接続、AI Agent の操作記録を同じタイムライン上に並べて照合します。エンドポイントの異常が見つかった場合は、パソコンの交換や認証情報のリセットだけでなく、攻撃者が接触した可能性のある同僚の情報、ロールの変更、既存のジョブスケジュール、外部接続も確認し、後から再び悪用できるアクセス経路が残っていないことを確かめなければなりません。
企業は、まず一度、演習を実施するとよいでしょう。あるエンジニアのアカウントが侵害されたと仮定した場合、セキュリティチームはその日のうちに、影響を受ける AI Agent、認証情報、パソコン、サービスを一覧化できるでしょうか。1 つでも特定できない項目があれば、関連する管理策をさらに強化する必要があります。
よくある質問
この事件を受けて、企業はすべての AI Agent を停止する必要がありますか？
全面的に停止する必要はありません。ただし、業務上の必要性を説明できない部門横断アクセス、高権限操作、外部接続は、まず無効にするべきです。そのうえで、業務範囲が明確で、データの読み取りだけを必要とする項目から再検証し、ロール、承認担当者、ログが実際のプロセスと対応していることを確認してから、段階的に許可範囲を広げます。
AI Agent は、ユーザーが持つ既存のアカウント権限をそのまま利用できますか？
すべての権限をそのまま利用させることは推奨されません。ユーザーが閲覧できるデータであっても、AI Agent が各タスクを実行する際に必ず必要とは限らないためです。企業は、ツール呼び出しとデータアクセスの範囲を別途洗い出し、不要な権限を削除する必要があります。また、デプロイや権限変更などの操作は、専用ロールに限定して実行するべきです。
社内データベースを読み取り専用にすれば、ラテラルムーブメントを防ぐには十分ですか？
十分ではありません。読み取り専用にすることで、データが変更されるリスクは軽減できますが、攻撃者が機密情報を読み取ったり、書き込み可能な別のサービスへ移動したりする可能性は残ります。企業はさらに、AI Agent が接続できるホストと外部ドメインを制限し、認証情報の有効範囲を縮小するとともに、呼び出しごとの記録を保存する必要があります。
AI Agent の監査ログには、最低限どのような情報を記録する必要がありますか？
少なくとも、ログイン ID、ロール変更、接続設定、ツール呼び出し、高権限操作、承認結果、ログのダウンロード操作を記録する必要があります。これらの記録はエクスポート可能で、完全性を検証できなければなりません。そうすることで、セキュリティチームは AI Agent の操作と、エンドポイントや ID システムで発生したイベントを同じタイムライン上に並べて調査できます。
参考資料
- Binance、63 億米ドル窃盗事件の攻撃チェーンを公表。ハッカーが偽の面接でエンジニアにマルウェアを実行させる — iThome が、Binance の公表した初期調査、攻撃チェーン、インシデント対応をまとめた記事。
