多くのテクノロジー企業と同様に、Microsoft も AI に全力で取り組んでいます。同社の主力 AI 製品である Copilot（様々な形態で提供）は、ユーザーが日常業務で AI を活用し、Microsoft サービスと連携してタスクを実行できるようにします。しかし残念ながら、これは同時に、さまざまな新たなセキュリティ問題も引き起こしています。
7 月 4 日、M365 Copilot で問題が発生しました。ファイルにアクセスして情報を返すことがあるものの、監査ログにそれが反映されないという問題です。さらにテストを進めたところ、Copilot にその動作を指示するだけで、実際にその動作が実行されることがわかりました。これにより、痕跡を残さずにファイルにアクセスできるようになりました。セキュリティと法令遵守の両面で問題が発生する可能性があるため、私は直 ちに Microsoft の MSRC ポータルを通じてこの問題を報告しました。
Microsoft は、脆弱性を報告する際に どのようなことが期待されるかについての明確なガイド を提供しています。さらに困ったことに、彼らはそのガイドに全く従いませんでした。プロセス全体が混乱を極めていました。そして、彼らはこの問題を「重要な」脆弱性として分類し、修正したものの、顧客への通知や公表は行わないことにしました。つまり、監査ログに誤りがあり、Microsoft はそれを顧客に伝えるつもりがないということです。
この記事は3つのパートに分かれています。第1パートでは、Copilot の脆弱性とそれが引き起こす可能性のある問題について解説します。第2パートでは、Microsoft がこの件をどのように処理したかを概説します。第3パートでは、Microsoft がこの情報を公開しないという決定、そしてそれがなぜ Microsoft の顧客にとって大きな損失になると考えるのかについて説明します。
脆弱性：Copilot と監査ログ
ここでの脆弱性は非常に単純です。通常、M365 Copilot にファイルの要約を依頼すると、要約が表示され、監査ログには Copilot があなたに代わってファイルにアクセスしたことが記録されます。[1]
それは良いことです。監査ログは重要です。誰かがあなたの会社を辞めて競合他社を立ち上げる前に、大量のファイルをダウンロードしたと想像してみてください。その記録は必要でしょうし、もしその人物がCopilotを使って検出を逃れられるようでは困ります。[2] あるいは、企業に機密性の高い個人データがあり、法務およびコンプライアンス上の理由から、誰がそのファイルにアクセスしたかを厳密に記録する必要がある場合、この場合もCopilot経由で行われたアクセスについて把握しておく必要があります。これらはほんの一例です。組織は正確な監査ログを必要としています。
しかし、Copilotに要約したファイルへのリンクを提供しないように依頼したらどうなるでしょうか？その場合、監査ログは空になります。
このように、監査ログは間違っています。悪意のある内部関係者にとって、検出を回避するのはCopilotに問い合わせるだけで簡単です。[3]
「うわっ、でもそんなに多くの人が気づいていないから大丈夫だろう」と思うかもしれません。残念ながら、それは間違いです。これを発見した時、私は監査ログを破る方法を探していたわけではありません。Pistachioで開発中の機能をテストするために、単に監査ログをトリガーしよ うとしていたのですが、それが信頼できないことに気づきました。つまり、これは偶然に発生する可能性があるということです。[4] そのため、組織でM365 Copilotライセンスをご利用の場合、監査ログはおそらく間違っているでしょう。
更新：ZenityのCTOであるMichael Bargury氏が1年前にこの問題を発見し、公開しましたが、Microsoftは未だに修正していません（そのため、私は報告しました）。彼は、AI関連の問題点の中でも、このトピックについて非常に興味深い講演を行いました。該当箇所はこちらです。
MSRCの問題点
これまでMicrosoftに脆弱性を報告したことは一度もありませんでした。しかし、そのプロセスに対する最初の反応は、かなり好意的でした。報告できるというだけでも、Microsoftの基準からすると非常に親切だと感じました。そして、先ほども述べたように、どのような対応を期待すべきかについてのガイドまで用意されていました。
残念ながら、計画通りには何も進みませんでした。7月7日に私の報告のステータスは「再現中」に変更されましたが、7月10日にさらなる証拠を提示しようとした時には、機能が変更されていました。これはMicrosoftのポリシーではありません。彼らはまず問題を再現し、その後修正作業を開始すると「開発」に移行するはずです。「再現中」のまま機能が変更されたのを見て、Microsoftが私に連絡して問題を再現できないと主張するのではないかと心配しましたが、実際には私の報告に基づいて修 正しただけでした。
そこでMSRCに何が起こっているのか尋ねたところ、簡単な説明ではなく、レポートのステータスを「開発中」に変更し、何も言わずに終わりました。それまでは、Microsoftは一定のプロセスに従い、必要に応じて私と調整を行うものだと思っていました。ところが、そのプロセスは現実を反映したものではなく、セキュリティ研究者向けのDomino's Pizza Trackerのようなものだと感じました。ステータスは現実とはかけ離れています。
8月2日、Microsoftは完全な修正プログラムを8月17日にリリースし、8月18日からは自由に情報開示できると私に伝えました。そこで、CVE番号はいつ発行されるのか尋ねたところ、次のような返答がありました。
CVEは、お客様がセキュリティ対策を講じる必要があるセキュリティリリースで展開された修正プログラムに付与されます。この場合、緩和策は自動的にCopilotにプッシュされ、ユーザーは手動で製品を更新する必要がなく、CVEも割り当てられません。
これはMicrosoftのポリシーとは全く異なります。私はMicrosoftのポリシーへのリンクでMicrosoftに指摘しました。するとMSRCは、まるで私が間違っているかのように、「MSRCがこれらのケースにどのように対処しているかについて、お客様が十分に把握していない可能性があることを理解しています」と返信しました。そして、この脆弱性は「重大」ではなく「重要」に分類されているため、CVEを発行しない理由を説明しました。[5] もちろ ん、その時点以前にMicrosoftがこの脆弱性を分類したことを私に伝えたことはありませんでした。
Microsoftの「何も言わない」という決断
Microsoftがこの脆弱性に対してCVEを発行しないのであれば、どのようにして顧客に通知するのでしょうか？答えは、公表するつもりはないということです。8月14日の電話会議で、Microsoftは私に、この件を公表する予定はないと言いました。[6]
私はそれが間違っていると強く感じています。もしこれが難解なエクスプロイトであれば、黙ってやり過ごしても良いかもしれませんが、現実には非常に簡単に起こり、ほとんど偶然に起こります。8月18日より前にCopilotを使用していた組織で働いている場合、監査ログが不完全である可能性が非常に高いです。
組織はそれを知る必要がないのでしょうか？HIPAAの対象であり、技術的保護要件の一部を満たすためにMicrosoftの監査ログに依存している企業はどうでしょうか？ MicrosoftはM365 CopilotがHIPAA準拠であると主張しているにもかかわらず、彼らには知らされないのでしょうか？ 同様の要件を持つ他の規制対象組織がほぼ確実に存在し、それらにも知らされないでしょう。
組織がインシデントの検知、調査、対応に監査ログを利用しているケースは非常に多く、監査ログが重要な証拠として使用される訴訟もあります。米国政府は、Microsoftが監査 ログに高額な料金を請求していることを問題視し、ある米国上院議員はMicrosoftを非難し、監査ログを不可欠なセキュリティ機能と称しました。
そして今、Microsoftは、監査ログがCopilotを使用しているすべての顧客にとって明らかに誤りであったにもかかわらず、誰もそれを知る必要はないと主張しています。これは、Microsoftが他にどのような問題をひそかに隠蔽しようとしているのか、深刻な疑問を提起します。
- 1
監査ログには、ユーザーがファイルにアクセスしたことが通常のSharePointFileOperation FileAccessedイベントとしてではなく、CopilotInteractionレコードとして表示されます。これは意図された動作であり、私見では正しいです。ユーザーがCopilot経由でファイルにアクセスしただけなのに、あたかも直接アクセスしたかのように見せかけるのはおかしなことです。
- 2
理想的には、ログを監視してこのような事象を検知できる仕組みが必要ですが、少なくとも事後に証明できるように記録は残しておきたいものです。
- 3
これはCopilot経由でアクセスしたことがあるファイルにしか機能しないと思っているかもしれませんが、それは間違いです。どのファイルでも機能します。
- 4
この事象のスクリーンショットをここに掲載できれば良かったのですが、Copilot がチャット履歴からチャットを切り捨ててしまうようで、私の画面にはもう表示されていません。
- 5
これは彼らのポリシーと一致していますが、私はこれに賛成できません。ルールでは、Microsoft 以外の当事者がリスク評価を行う必要がある場合は CVE を発行する必要があるとされています。私の意見では、Microsoft は脆弱性の分類に基づいて包括的なルールを設定するのではなく、実際の脆弱性に基づいて判断すべきです。
- 6
Microsoftはこの脆弱性の公開日を8月18日と設定しました。私はMicrosoftに対し、電話と書面の両方で、上記のすべての理由から、この問題を公開しないという同社の決定に同意できない旨を伝えました。Microsoftは、私が問題の範囲を誤解しているという根拠を一切示していません。もしこの問題が私が考えているほど広範囲に及んでいなかったのであれば、Microsoftは私にその旨を伝える機会を十分に持っていたにもかかわらず、そうしなかったのです。もちろん、Microsoftが自ら報告し、私たちがすべての詳細を把握できれば最善だったでしょうが、Microsoftはそうしませんでした。