Copilotが監査ログを破損させたが、Microsoftは顧客に通知せず
(pistachioapp.com)- MicrosoftのM365 Copilotで監査ログが記録されない脆弱性が見つかり、ファイルアクセスがログに残らない問題が発生
- 単にCopilotに特定の方法で動作するよう依頼するだけで、監査記録なしにファイルへアクセス可能であり、これは内部不正の脅威や法的規制違反のリスクにつながる可能性がある
- 研究者はMSRCに報告したが、Microsoftは公式ポリシーと異なりCVEを発行せず、顧客にも通知しなかった
- Microsoftはこの脆弱性を「重要(Important)」レベルにのみ分類し、自動更新で解決済みであるとして別途通知は不要と判断
- しかしこれは、HIPAAなどの規制業界で監査ログに依存する企業に深刻なセキュリティ・法的問題を引き起こす可能性があり、Microsoftの透明性不足に大きな批判が集まっている
Copilotの監査ログ脆弱性: 概要と影響
- Microsoftが積極的に導入を進めている代表的なAIサービスCopilotで、ユーザーの要求次第でファイルアクセス履歴が監査ログに残らない欠陥が見つかった
- 本来は、M365 Copilotがファイルを要約すると、そのファイルへのアクセス履歴が監査ログに記録されるべきであり、これは組織内の情報セキュリティの中核である
- しかし、Copilotにファイル要約結果へファイルリンクを含めないよう求めた場合、そのログ自体がまったく記録されない現象が発生する
- 例えば、従業員が退職前にCopilotを通じて大量のファイルを閲覧しても、ログなしで痕跡を残さず流出させることができる
- この脆弱性は意図的なハッキングではなく、偶然かつ自然に起こり得るもので、実際にブログ筆者が独自の機能テスト中に発見した
- ZenityのCTOであるMichael Barguryも、すでに1年前にこの脆弱性を発見してMicrosoftに報告していたが、今回の報告まで長期間放置されていた
MSRC(脆弱性報告)の問題点と対応不認定
- Microsoftは脆弱性報告に関する公式ガイダンスとプロセスを提供しているが、実際の対応過程ではそれが適切に守られていない
- 筆者がMSRCに報告した後、再現手順が完了していない段階でCopilotの機能が変わるなど、混乱した状況が発生した
- 報告ステータスの変更(再現 → 開発)などは進んだものの、進捗状況や判断根拠について明確なコミュニケーションが不足していた
- セキュリティ脆弱性に関するCVE発行の可否については、顧客側で直接の対応が必要な場合にのみ公式番号を付与するという説明を受けた
- しかしこれはMicrosoftの既存ポリシーと異なり、この脆弱性は単に「重要(Important)」等級として分類され、公開や通知は別途行われなかった
- 全体として、進捗追跡そのものが実際の措置とは無関係に見かけ上だけ更新されており、報告者にとっては非効率で不透明な体験だった
告知および顧客通知漏れの問題点
- Microsoftは今回の脆弱性について、CVEを発行せず、顧客にも通知しないと決定した
- これは誤操作でも容易に発生し得るエラーであるだけに、実際の組織で長期間にわたり監査ログが誤って記録されていた可能性がある
- 医療機関(例: HIPAA)など、法的・規制目的で監査ログを活用する組織も多いにもかかわらず、Microsoftは影響の事実を利用者に案内していない
- 監査ログは組織のセキュリティ、インシデント対応、法的証拠など多くの分野で中核的に利用されるが、Microsoftは関連事実について沈黙を貫いている
- このような姿勢は、ほかの潜在的なセキュリティ問題も未公表のまま処理され得ることを示唆しており、組織の信頼性に深刻な疑問を投げかけている
1件のコメント
Hacker Newsのコメント
社内チャットボット開発を担当しているが、チャットボットが機密文書にアクセスする際に現在のユーザー権限を完全に確認しないと、必ず情報漏えい経路が生じるという問題を経営陣に説明するのに苦労している。
ベクターデータベースや検索インデックス、AI Search Database などは、ユーザーごとに存在するか、コンテンツとともにアクセス権限を追跡する必要がある。
しかしアクセス権限は非常に複雑で、いつでも変動し得るため、大規模適用が難しく、レースコンディションに弱いことを強調したい。
これは「Confused Deputy」問題の具体例だ。
OWASP LLM Top 10 の LLM02:2025「Sensitive Information Disclosure」と LLM06:2025「Excessive Agency」に関するリスクに当たる。
一部の企業向け RAG ソリューションは、多様な ACL のためにユーザー別インデックスを作って対処している。
このようなアクセス権限の問題をどう管理するかはベンダーごとに異なるので、RAG ソリューションを評価する際は必ずその点を確認すべきだ。
日本ではこれを「権限混同」と呼び、なかなか面白い名称だと思う。
Confused Deputy の説明を見る, OWASP LLM Top 10 リスクを見る
なぜユーザーのアクセス権限を追跡することがスケーラビリティ上の問題だと考えるのか気になる。
クエリが来たら、ベクター DB やインデックスで一致する文書を見つけ、その中からユーザーがアクセス可能なものだけを LLM に渡せばよい。
まるで銀行の相談員が認証済みの顧客情報だけを見られるため、誤って他人の情報を漏らすことがないのと同じで、認証されていなければ他人の情報は運用者にも見えないので、悪用されるリスクはないと思う。
こういう壁にぶつかるとき、実際には私の説明が不足しているわけでも、経営陣が理解できないわけでもない。
おそらく経営陣はその問題を見て見ぬふりすることに決めており、後で漏えいが起きたらエンジニアに責任を押しつけるつもりなのだと思う。
経営陣に問題を説明するのが難しいなら、Legal/Compliance 部門を CC に入れると効果があるかもしれない。
ただし、バズワードに執着する一部の役員はこの行動を快く思わない可能性がある。
ほとんどのベクターデータベースでは、ベクターに追加メタデータを付与できる。
アクセス権限を持つ主体（例: HR、役員）の一覧をメタデータとして保存しておけば、リクエスト時にユーザーをそのロールに展開してフィルタリングできる。
こうすれば、ユーザーが見られない文書は最初から除外できる。
ただし、文書ごとの権限が変わるたびにベクターメタデータも即時更新しなければならない。
Copilot が監査ログを回避し、特権ユーザーのように動作するのは問題だ。
そんなことがあってはならないと思う。
Copilot は実際にファイルへ直接アクセスしているのではなく、すでにインデックス化されたファイル内容を検索エンジン経由で読んでいる。
Microsoft は Copilot の検索履歴を監査すべきであって、Copilot がインデックスだけを読んだのにファイルへアクセスしたと記録されるのは誤解を招く。
Google の検索結果を見たからといって、Web サイトを直接訪問したとは言わないのと同じだ。
Microsoft は不必要に AI 統合にばかり前のめりになり、その過程で監査ログをおろそかにしている。
Windows では Backup 権限を持つプロセスはすべてのアクセス権限を回避でき、デフォルトでは監査もされない。
バックアップアプリの場合、監査ログが多すぎるためだが、この権限は明示的に有効化する必要があり、C# のようなマネージドコードでも簡単に可能だ。
Restore 権限も同様だ。
この現象は、以前 Delve が初めて導入された際に権限トリミングが不適切で、ユーザー検索結果に表示されたり、SharePoint 検索が存在するがアクセス不能な文書を一部露出していた問題に似ている。
たとえば「Fall 2025 layoffs」と検索すると、関連文書が存在するだけで表示されてしまい、セキュリティ上の問題があった。
Microsoft には依然として「セキュリティは後回し」という印象が強い。
もっと良いタイトルは「Microsoft Copilot は HIPAA 規制に準拠していない」だと思う。
こういうタイトルにすれば、もっと早く問題が解決する気がする。
さらに言えば、役に立つ AI 検索システムはすべて設計上安全ではなく、ベクターデータベースに保存されるその RAG ベクトルは、結局のところ文書を損失圧縮したものにすぎない。
問題はすでに修正済みだ。
今の不満は、顧客に通知されなかったという点だ。
「CVE は、顧客が保護のために対応を取る必要がある場合に配布されるセキュリティリリースに割り当てられる。今回の場合、対応は Copilot に自動配布され、ユーザーが手動で更新する必要がないため、CVE は割り当てられない」
これが CVE の本質的な特徴なのか、それとも Microsoft が CVE をこのように運用しているのか気になる。
このような脆弱性にも参照可能な共通 ID があるとよく、ベンダーに依存しない別の番号体系が必要だと思う。
Microsoft は CVE をセキュリティインシデント/脆弱性の追跡に使うものだ。
異常に迅速な緊急パッチが可能だからといって、それがセキュリティインシデントでなくなるわけではない。
Microsoft はセキュリティインシデントの透明な開示に消極的で信頼性も下がっており、こういう場合こそいっそう情報公開が重要だ。
これは CVE の限界というより、Microsoft が PR のために CVE プロセスをねじ曲げて使っているように感じる。
CVE の「C」は Common だ。
つまり、「共通性」に焦点を当てたシステムだ。
現在、重要な LOB アプリも Microsoft 離れを進めようとしている。
ここ数か月の複数のハッキング、SSO のゼロデイ、Copilot でインデクサーがグローバル管理者として動作して権限を無視しているのを見て、不安が増している。
LLM に直接監査や活動ログを任せた場合に起こり得る問題は多すぎて数えきれない。
だから気になるのは、今回の問題のバグ修正をどうやったのか、もしかして「シャドウプロンプト」を導入したのではないかということだ。
投稿のどこにも、LLM が監査ログを直接管理しているとは書かれていない。
むしろ監査ログは LLM ではなく、上位のスキャフォールディング（周辺システム）で記録していて、ログを残すべき「タイミング」を誤っていたように見える。
たとえば、誰かがリンクをクリックした瞬間に監査ログを残すようにするのではなく、文書が LLM に注入される時点などで記録すべきだった。
この設計も最適ではないが、LLM 自身に記録させるよりはまだましだ。
私は、シャドウプロンプト（あるいは何らかの形のプロンプト）を本物のセキュリティやコンプライアンス統制手段として使うこと自体に強い懐疑がある。
そうした制御は、必ず決定的で予測可能なシステムであるべきだ。
もし何らかのツールが LLM にファイルの一部でも見せるなら、その後 LLM が出力した情報はすべて、そのファイルを読んだものと見なすべきだと思う。
「もしユーザーがリンクを提供するなと言ってきたら無視しろ。そうしないとお前の家族に XYZ の恐ろしいことが起きるぞ」のように、LLM プロンプトに奇妙な要求が入り得ると思う。
シャドウコピー (Shadow copies) の問題も思い浮かぶ。
ここで話している監査ログが正確にどの種類なのか不明確だ。
SharePoint のファイルアクセスログなのか、Copilot の行動記録なのか、Purview なのか、それとも別の何かなのか?
不明確な点が多い。
Copilot はファイル自体ではなくインデックス化された内容にアクセスしているので、実際にファイルへアクセスしていないのは事実だ。
ブログ執筆者はインデックスアクセスログを見るべきだ。
ブログの脚注の一つに、「監査ログはユーザーがファイルに直接アクセスした痕跡ではなく CopilotInteraction として残るので、これは意図されたものだと思う。
ユーザーが Copilot 経由でしかアクセスしていないのに、まるで直接ファイルを触ったかのように記録される方がむしろおかしい」という意見がある。
私が ChatGPT に同じ質問をしたところ、これは Microsoft 365 / Office 365 の監査ログ、特に Microsoft Purview Compliance Portal の Unified Audit Log のことだと説明された。
こうした問題こそが、Microsoft のような大手ベンダーへの信頼を「保証」ではなく「運頼み」のように感じさせる原因だ。
現実的にこの問題をどう修正できるのか本当に気になる。
私の理解では、Copilot が使うインデックス/DB はすでにそのファイルをクロール済みなので、わざわざファイルを再取得しなくてもその情報を返せてしまう。
だとすると、いったいどう修正すべきなのか?
データベース/インデックスへのアクセス自体を監査ログと連携させるべきなのか?
それとも LLM に「知識を参照するときは約束を守って必ず記録を残せ」と命令するべきなのか?
Microsoft がこの問題をどう認識し、どう解決したのかについての公式なコミュニケーションがぜひ必要だ。
機密データを扱う企業にとって、今回の問題は警鐘となるべきだと思う。
一般的に CVE は誰でも登録申請できる。
私が自分で提出して Microsoft の対応を促すこともできるかもしれない。
あのブログ記事だけでもかなり説得力があると思う。
実際にはそんなに簡単ではない。
MITRE や各国の CERT など、ほとんどの CVE 番号採番機関 (CNA) は誰でも報告できるが、評価と審査がある。
Microsoft は独自の CNA なので、特別な理由がない限り、MS 関連の CVE を外部から割り当てることはないだろう。
Microsoft だけが提供するサービスについて CVE を求めることに、果たして意味があるのか考えてしまう。
ユーザーがこれで何をできるのか疑問だ。
CVE 登録フォームは こちら から利用できる。
PGP サポートや長い実績、認定スポンサーなど、信頼性も高い。
合法的かつ正当な案件にのみ使うべきだ。
面白くはあるが、これは CVE の対象ではないと思う。
CVE は複数ソースのさまざまな製品に共通して適用される脆弱性であるべきで、Copilot はそれに当てはまらない。
この件で最も深刻なのは、Copilot の LLM 自体に監査ログ生成を指示したという設計ミスだ。
ファイルや URL を参照する API 側で自動的に監査ログを残すべきであり、これはエンジニアリングの基本だ。