Copilotが監査ログを破壊！マイクロソフトが顧客にひた隠しにする問題
引用元：https://news.ycombinator.com/item?id=44957454
機密文書にアクセスする社内チャットボットを開発してるんだけど、経営陣にデータ漏洩のリスクが伝わらなくて困ってるよ。
すべてのデータがユーザーのアクセス権限と照合されない限り、絶対にデータは漏洩する。
Vector databasesやSearch Indexesみたいなのがユーザーごとに必要になるか、コンテンツと一緒にアクセス権を追跡する必要があるけど、それは非現実的だし、スケールしないんだ。アクセス権は複雑で常に変わるから、競合状態にも陥りやすいね。
アクセス権の追跡が非現実的でスケールしないって思う理由が理解できないな。
クエリで検索して、関連するドキュメントのリストが見つかったら、現在のユーザーがアクセスできるものをチェックする。そして、ユーザーが見れるものだけをLLMに渡せばいいんじゃない？
銀行の電話サービスとよく似てるよ。オペレーターは認証されないとあなたの口座詳細を見れないでしょ？認証なしに他人の残高を伝えるなんてできないんだから。
クエリに一致するドキュメントが10万件あって、そのうちユーザーがアクセスできるのがたった10件だったとしよう。
基本的な実装だと、上位1000件とかを返して、それらに対して高コストなアクセスチェックをするんだ。ほとんどの場合、それで検索結果が全部なくなっちゃうよね。
だから、検索自体がアクセス権限を考慮して、ユーザーがアクセスできるドキュメントに事前フィルタリングする必要があるんだ。そうすれば、”100%確実”なアクセスチェックを後で適用できるよ。
なぜアクセス権追跡が非現実的でスケールしないか、僕の理解で説明させてくれ。
通常のSaaSは権限付きのAPIエンドポイントがある。リクエスト処理前に、ユーザーの権限がエンドポイント自体に対してチェックされる。これが成功すれば、そのエンドポイントが集めるものはユーザーに渡しても”OK”とみなされる。
でも、AI Agentsは直接データベースにアクセスするから、このレイヤーを完全にバイパスしちゃうんだ。つまり、アクセス権限を個々の行に埋め込む必要があり、結果としてずっと複雑になる。
銀行の例で言うと、僕が説明したのと同じようなやり方だよ。リソースへの一時的なアクセスが許可されたら、その画面に含まれるデータはOKと見なされる。見ちゃいけない情報があるからといって、画面の一部が空白になるなんてことはないでしょ。※免責事項：AI Agentsの動作について仮説を立ててるだけだから、間違ってるかもね。
「経営陣に問題がなかなか伝わらない」ときって、あなたが伝えるのに失敗してるわけでも、彼らが理解できないわけでもないのかもしれないね。実際は、経営陣がその問題を無視することを選んだだけなんだ。でも、最終的に漏洩があったときに責任を取りたくないから、「理解してない」フリをして、後でエンジニアを責めるのが一番簡単な方法なんだよ。
Hacker Newsの連中が、何でもかんでも作り話をしたがるこの願望—というか、もはや必要性—が理解できないな。だから君は低評価されてるんじゃない？
みんな『ゼロから考える』のが大好きだけど、『AIエージェントがどう動くか想像して、それを真実として通す』のはちょっとやりすぎだと思うよ。
これはAIのハルシネーション（幻覚）の人間版だね。君はただでたらめをでっち上げて、『自分の理解を注入する』と称して真実のように伝え、最後に『これ、完全に間違ってるかもね（笑）』って使い捨ての一文を付け足してるだけだ。
このケースでは、エンジニアを責める必要すらないんだ。彼らは『AIのせい』にできるし、ほとんどの人がそれを受け入れて、どんなインシデントもなあなあで済ませるだろうね。
もし誰かがAIをそんな立場に置くことの賢明さを疑問視しても、『新しい技術を理解していない』として切り捨てられる可能性がある。たとえその懸念が正当だとしてもね。
もしドキュメントがグループやロールごとにインデックス化されていて、RBAC（Role-Based Access Control）のようなものがあれば、こんなことにはならないはずだよ。
このアプローチだと、グループやロールが変わるたびに再インデックスが必要になるよね。それは常に実行可能な選択肢とは限らないよ。
「ユーザーごとにアクセス権を追跡するのは非現実的でスケールしない」って主張、Citation neededだね。ほとんどのエンタープライズ検索エンジンは数十年も前からこれを大規模にやってるし、既によく解決されてる問題だよ。実装の問題であって、スケールしないわけじゃないんだよ。
メタデータを更新するだけでいいんだよ、全部再インデックスしなくていいからね。
でもさ、もしこういう議論がなかったら、HNはほとんど静まり返っちゃうよ。みんなが何を話してるか知ってる状態じゃ、誰も学ぶ機会がなくなっちゃうじゃん。
「ベクトルデータベースで検索して、ユーザーが見れるドキュメントだけをLLMに渡す」って言うけどさ、その「関連候補リスト」自体が、すでに情報漏洩になりかねないんだよ。
2つの疑問があるよ。1. なんで「ユーザーごとやコンテンツと一緒にアクセス権を追跡する」のが無理なの？ Google ZanzibarとかOry Keto、Eclipse Biscuit、Apache Accumuloみたいな技術はあるし、高精細な認証認可ってちゃんとできるはず。結局、細かなレベルでの認証認可に十分注目されてないだけじゃない？ 2. どのくらいの規模が必要なの？ 従業員1万人以上の企業って稀だし、ほとんどの内部システムはユーザー100人未満だよ。Google規模じゃ無理なことでも、このレベルなら十分やれるはずだよ。
でもさ、そのリストはクライアント環境じゃなくて、信頼されて監査済みのアプリ層で処理すべきなんだよ。
「AI Agentsが、この層を完全に飛ばして直接データベースにアクセスする」って言うなら、まさに「それが問題だ！」ってやつだね。最悪な実装のせいで技術の可能性を評価しちゃダメだよ。これって銀行の電話オペレーターにルートSQLアクセス権を与えて「気をつけてね」って言うようなもんじゃん。
メタデータ（ロールアクセス）を再インデックスしなきゃいけないんだ。複雑なスキーマでユーザーやロールが多いなら、かなり大変な作業になるかもね。
確かに、ユーザーごとのアクセス権はスケールしないね。知識はちゃんとグループ化して、データベースやドキュメント、チャットボットの権限をグループで管理すべきだよ。例えば、エンジニアリングのチャットボットは使えるけど、ファイナンスのは使えない、みたいにね。こういうグループ分けをちゃんとできないなら、戦略が固まってないって感じ。最終的には「オープン知識」を経験してもらうしかないよね。
幹部に問題が伝わらないのは大変だよね。法務やコンプライアンスを巻き込めば、彼らも理解しやすくなるかも。でも、下っ端が口出しするなって怒られる可能性もあるから気をつけて。
「AIがやった」ってのは、これからの「somebody hacked my facebook account」になるんだろうな。テキストを書いたのが誰であろうと、公開した人間に責任が残る仕組みがあったらいいのに。
たくさんのMCPを繋げるなら、認証システムもたくさん必要になるよな。検索エンジンがリアルタイムでユーザーの各データへのアクセス権を確認するなんて、めちゃくちゃ難しい問題だ。まだ全然解決できてないんだよ。
それも一つのやり方だけど、俺は何もブロックしたくないんだ。ただ、みんなが妥当な期待を持って、問題の基本的なことを理解してくれたらそれでいいんだよ。
安易なやり方だと、サイドチャネルで情報が漏れることがあるんだ。例えば、いつも「foobar」を探してて、それが文書に増えると検索が遅くなることで、情報が漏れちゃうとかね。文脈によっては、これって結構重要だよ。
AI AgentがDBに直接アクセスしてるってとこだけは自信ないんだけど、分析ツールとかがそうだし、検索インデックスを読んでるってことは、ほぼ合ってると思う。他の部分は、自分でシステム作った経験から間違いない。権限アクセスはスケールするって意見には、それは設計のせいでそう見えるだけだって言いたいね。
ほとんどのベクトルデータベースは、メタデータをベクトルの情報に追加できるんだ。アクセス権を持つ役割リストをメタデータとして加えればどうかな？ユーザーがチャットボットに質問したら、その役割を使って検索結果を絞り込むんだ。これで、見られない文書を最初から除外できる。ただし、文書の権限が変わったら、メタデータも更新しなきゃいけないけどね。
Servicenowって、この問題をユーザーに丸投げしてるよな。「20個のリストがあるはずなのに2個しか表示されず、18個は権限不足で省略された」ってメッセージを見たことがあるよ。
メタデータの再インデックスは大変だっていうけど、元の提案（まず1000件返して、後でアクセス確認）よりはるかにマシだよ。ほとんどの文書は役割アクセスがしょっちゅう変わるわけじゃないから、更新コストも大したことないはず。文書内容のインデックス更新よりずっと安上がりだしね。
これはマジでよく知られてて、もう解決済みの問題だぞ。Googleの社内検索エンジンは、数十年前から大規模にこの問題をクリアしてたんだから。
「それが問題だ！」って言うのは分かるよ。全てのAI Agentの仕組みは知らないけど、企業がデータ分析を約束する時って、大体Prod DBに直接繋いでて、エンジニアがスキーマを変えるたびにデータアナリストが文句を言うケースが多いよね。でも、酷い実装のせいで技術の可能性を判断するのは違うって意見には賛成だよ。
君が言ってるのは「Confused Deputy Problem」の具体的なケースだね。OWASP LLM Top 10の「LLM02:2025 Sensitive Information Disclosure」や「LLM06:2025 Excessive Agency」のリスクにも関連してるよ。エンタープライズRAGソリューションの中には、複雑なACLがある場合にユーザーごとのインデックスを作ってこの問題を解決してるものもあるみたいだね。RAGソリューションを分析する時は、ベンダーにこの問題の管理方法を質問するのが重要だよ。
俺の会社ではこれを「権限混同」って呼んでるんだけど、日本語だとより面白い名前だと思わない？URL: https://en.wikipedia.org/wiki/Confused_deputy_problem、https://genai.owasp.org/llmrisk/llm022025-sensitive-informat…
もっとコメントを表示（1）
ちょっと待って、Copilotって、監査をバイパスできる特権ユーザーとして動いてるの？ユーザー権限（あるいは、制限されたユーザー権限）としてじゃないの？そんなことありえないでしょ？
他の誰かが言ってたけど、ファイル自体はCopilotに直接アクセスされてなくて、Copilotは検索エンジンの事前インデックスされたファイルの内容を読んでるんだよね。MicrosoftはCopilotが実行する検索を監査すべきで、ファイルがアクセスされたとして監査するのは、ちょっと誤解を招くよ。Googleでウェブサイトの結果を見つけた時に、そのサイトにアクセスしたとは言わないのと同じだろ？
これってさあ…Delveが初めて導入された時にセキュリティトリミングが適切じゃなくて、提案や検索結果がおかしかったりしたのと、基本的には同じだよね？あるいは、もっと昔、SharePoint searchがユーザーが開けない文書でも結果や要約を表示してた時とか…。「Fall 2025 layoffs」みたいなのをユーザーが検索したら、文書が存在するってことは計画されてるって分かる、みたいなのが一番良い例だったな。
ああ、Microsoftって、やっぱり「セキュリティ後回し」なんだね？
俺は「デフォルトで安全ではない」って言うね。Windows Server 2025のSecure Future InitiativeについてMicrosoftの人と話したんだけど、彼らは互換性を破るって言ってたんだ。でもServer 2025は、ドメインコントローラーから内部のWebインターフェースにアクセスする必要がある場合、Edgeのスタート画面に悪質な広告をロードするし、wingetっていう審査も説明責任もない素晴らしいマルウェア配信ツールをServer 2025に含めるって、嬉しそうに発表してたんだ。両方の点に対する彼らの回答は、必要なら無効にできるってことだったよ。確かにできるけど、そういう問題じゃないんだ。Microsoftのテクノロジーに基づいて安全な環境を作ることはできるけど、それはあらゆる段階で君と戦うことになるだろうね。
面白い事実として、実はIEのESCモードはサーバー上でEdgeよりも劇的に安全なブラウザだったんだ！デフォルトで、IEのESCモードはサーバー上で外部のウェブサイトをほとんどロードしなかったからね。
いや、Copilotはユーザーの権限でデータにアクセスするよ。
ああ、それじゃあ監査制御の「外」に、データの完全なコピー（もしくは再構築できる何か）があるってこと？それって、もっとヤバいじゃん！
つまり、俺みたいな普通の特権がないユーザーでも、Windows上のファイルを監査ログをバイパスして読める方法があるってこと？
これって、認証なしでサイトのインデックス（プレビュー付き）を構築する検索エンジンと、ほぼ同じ問題だよね。こんな根本的な欠陥を抱えたまま、ここまで進んだことが信じられないよ。
wingetがマルウェアに使われたからって、パッケージマネージャー全体がウイルスまみれってわけじゃないだろ？MSのツールもたくさん使ってるんだし、Linuxでapt-getを削除しないのと同じだよ。
でも、サーバーにEdgeのニュースページが表示されるのは本当に最悪だね。デバッグ中にあのページが出てくると腹立つよ。サーバーのブラウザは空のページがデフォルトであるべきだ。
「欠陥」が何なのか、いまいちピンとこないな。これって検索エンジンが提供する「機能」そのものじゃない？サイトのオーナーもSEOにすごい努力してるわけだし。
wingetはLinuxのリポジトリとは全然違うんだよ。Debianは厳しく管理されてるし、Microsoft Storeでさえレビュアーがいる。
でもwingetは、たった一人のMicrosoft社員がやってるだけ。レビュー基準もなくて、GitHubユーザーに適当にモデレーター権限を与えたりしてる。自動スキャンを通れば何でも公開されるし、誰でもパッケージの変更を提出できるんだ。
プロなら絶対に受け入れられないアマチュアレベルの代物なのに、今ではWindowsに標準搭載されてるなんてマジで恥ずかしいよ。これをリリースしたエンジニアは昇進したんだろうけどね！
製品に欠陥があったなら？それはそうだろうね。
その人がバグを見つけて報告したら、彼らはそれを修正した。こんなバグは複雑なソフトウェアによくあることだし、別に珍しいことじゃないよ。
サーバーにはデスクトップGUIがないから、実際のサーバーでブラウザを動かすなんて無理だよ。攻撃対象を減らすためだしね。ほとんどのWindows Serverに言えることだ。
もしドメインコントローラーとデスクトップPCを一緒に使ってるようなヘンテコな環境でWebサイトを見てるなら、何か問題が起きても全部自分の責任だからな。
俺が気になるのは、wingetがパッケージマネージャーみたいに見えて、そう思われがちだけど、実際はインデックスへのCLIフロントエンドでしかないってこと。
そのインデックスも、Windowsストアか普通のセットアップファイルをダウンロードするURLを指してるように見えるんだよ（Adobe Acrobatとかがそうかな）。
「Googleで結果を見ただけで、ウェブサイトを訪れたことにはならない」って言うけど、それは表示されるインデックスのサイズによるんじゃないかな。
もしGoogleが（AMPみたいに）ページ全部の内容を表示したら、それはもうサイトを訪れたのと同じだ。けっこう際どいラインだよ。
公開文書なら検索エンジンにインデックスさせてプレビューを見せるのはOKだ。でも、非公開文書をそうするのはダメだろ？
たとえ直接開くときに認証が必要でも、Googleのプレビューで内容が見えちゃうんだから。
俺の言ってることはバカげてるように聞こえるかもしれないけど、まさにマイクロソフトがやったことだよ。彼らは公開・非公開問わず全ての文書にAIアクセスを許可して、Copilotが秘密を漏らした時に驚いたんだ。認証があるから安全だと思ってたみたいだけど、Copilotが秘密をバラしちゃえば意味ないよな。
それってまさに、「特権昇格」っていう脆弱性のカテゴリーを定義しただけのことだと思うよ。
Copilotが勝手に機密情報を見せたのと、自分からアクセスしたのってどう区別するかが難しいね。
WindowsのBackup特権って、権限を無視してアクセスできちゃうけど、監査されないんだよ。普段は無効だけど、C#とかなら簡単に有効にできるから注意が必要だね。Restore特権も同じ感じ。
これは権限昇格じゃないよ。CopilotはOAuthアプリみたいに、ユーザーのトークンを使って、ユーザーの代理で動いてるだけなんだ。
技術的にはわかるんだけどさ、セキュリティとかコンプライアンスの面から見ると、やっぱり納得できないよね。
それって、ChocolateyとかScoop、Homebrew Casksと何か違うの？
じゃあどうするんだ？2つのAIを連携させる？最初のAIがRAGでファイルを選んで、2番目のAIに渡す時にちゃんとログを残すとか？それか、「どこから情報が来たかログに残せ」ってシステムプロンプト入れるだけ？
それが本当なら、なんでログされてないんだ？監査ってさ、アクセスしたプログラムが勝手にコントロールしちゃダメだろ。
そうは言うけど、実際はそういうことってあるんだよ。「Experts Exchange」なんかはさ、有料ユーザー以外には答えを見せないくせに、検索エンジンにはガンガン索引させてたもんね。
アクセスしたならアクセスしたんだよ。そのドキュメントを見ようと思ってたか関係なく、内容を知っちゃったんだから、監査ログは絶対残すべきだね。
マジウケる。俺は30年以上ずっとMicrosoftを避けてきたんだ。時々、正しい選択だったって思い出すわ。
Copilotが実行する検索を監査すべきだよね。Copilotがファイルのインデックスされた内容を読んだだけで、アクセス済みと監査されるのは誤解を招く。Googleで検索結果を見てもウェブサイトを訪問したとは言わないし。
専門じゃないけど、インデックスされた内容自体が監査可能なファイルって主張できるんじゃない？ファイルじゃなくても、十分な機密情報を含んでたら大きな違いはないでしょ？
コード補完とエージェント型チャットインターフェース、どっちのこと？後者はまあ使えるけど、前者はIntellisenseの邪魔でしかないんだよね。仕事ではエージェント型チャットも大したことないな。大規模C++コードベースだと何か足りない。ファインチューニングとか、関連コンテキストだけ引っ張ってくるVisual Studioの“peek definition”みたいなツールが必要なのかも。個人プロジェクトではClaude CodeがC++の型システムに強くて良いけど、タスクを最後までやらないのが難点。ポテンシャルは感じるけど、普通のCopilotはダメだね。
記事のタイトルは“Microsoft CopilotはHIPAAに準拠してない”の方がいいよ。こうすればもっと早く修正されるはずだ。
もっとコメントを表示（2）
さらに言えば、使えるAI検索システムは全部設計上、安全じゃないよ。ベクトルデータベースで売られてるRAGベクトルって、要するにドキュメントの非可逆圧縮版だからね。
“ドキュメントの非可逆圧縮版”って話だけど、ベクトル埋め込みはSHA256ハッシュと同じくらい非可逆圧縮だよ。埋め込みベクトルから元のドキュメントを復元するのはほぼ不可能。もちろん、検索や情報取得のために他のコンポーネントと組み合わせると、簡単にひどく安全じゃないシステムになっちゃうけどね。ただ、ベクトル埋め込み自体は有用だし、“使えるAI検索システムは全部設計上安全じゃない”って部分には同意できないな。
それは違うね。ハッシュだと、完全に同じ入力じゃないと一致してるか分からない。1ビットでも違ったら何も情報が得られないんだ。でもベクトル埋め込みは、似た入力に対しては違う反応をするように設計されてるから、埋め込みアルゴリズムが再現できれば、入力との近さがわかる。これは、組み合わせ錠が“ここまで何個合ってるよ”って教えてくれるようなものだよ。
“元のドキュメントの復元はほぼ不可能”って話だけど、埋め込みプロセスを再現できれば、ホット/コールドサーチ（“だんだん近づいてるよ！”）みたいに、かなり可能だよ。それに、もはや完全に元のドキュメントを復元する必要すらなくて、十分近いものを復元して、そこからさらに近づけていけばいいんだ。
その二つは同等じゃないと思うな。暗号学的ハッシュだと、ハッシュから“復元”するには全く同じフルドキュメントが必要になる。でもベクトル埋め込みなら、どの埋め込みモデルが使われたか知ってるか推測できれば、埋め込み単体からドキュメントに関する情報を抽出できるんだ。ドキュメント自体を再構築することはできなくても、ベクトル単体から何らかの意味を推論できるだろうね。
うん、使用されたモデルを知っていれば、埋め込みベクトルから情報を抽出できることを示す論文が複数あるよ。SHAは設計上、似た文字列を擬似ランダムにマッピングするけど、埋め込みは設計上、似た文字列を似たようにマッピングするからね。
もう修正済みだよ。問題は顧客に通知されてないことなんだ。
「そうじゃない、彼らは積極的にログを破壊しないことを選んだ」って感じ。能動的な選択を強調してるよ。
また能動態と受動態の言葉遣いが議論になってるな。
CVEは顧客が手動で対応する場合に付与されるけど、Copilotは自動更新だから割り当てられないのは、CVEの機能なの？それともMicrosoftのやり方？この脆弱性にも共通IDがあれば便利なのに。ベンダーに依存しない新しいIDシステムが必要かもね。
Microsoft CVEはセキュリティインシデントを追跡すべきだよ。緊急パッチで対応できても、インシデントじゃないわけじゃないし。Microsoftはセキュリティ報告に関してどんどん信頼できなくなってる。OSやClaudeみたいな基本コンポーネントを提供するなら、セキュリティの正確な報告は超重要だろ。
これはCVE自体の限界じゃなくて、MicrosoftがPRのためにCVEプロセスを悪用してるって感じだね。
それはCVEの機能だよ。「C」はCommonのCだもん。
やっぱりここでもCVEを割り当てるべきだと思うな。パッチ調整は必要なくても、多くの企業がHIPAAやGDPRの監査機関、顧客、従業員に報告しなきゃいけないんだから、共通IDがあれば参照がめっちゃ楽になるでしょ。
監査ログなんかをLLMに直接管理させるなんて、どれだけ多くの問題が起きるか想像つかないよ。彼らのバグ修正って何だったの？シャドウプロンプトとか？
「監査ログをLLMに直接管理させるなんて」ってあるけど、この投稿ではLLM自体が監査ログを追記してるなんて言ってないじゃん。そんな設計ありえないし。たぶん、スカフォールディングがログを書いてるんだけど、間違った場所を計測しちゃったってことじゃない？スカフォールディングでのログ書き込みも良くない設計だけど、完全にありえないってわけじゃないしさ。
分かったけど、LLMがコンテンツやメタデータを表示する必要があるなら、どうやって修正するの？
LLMとコンテンツのやり取りは、LLM自身を監査できるミドルエンドで隔離すべきだと思うけど、専門外なんだ。MicrosoftがCopilotで何をしてるか知らないし。
シャドウプロンプトみたいなプロンプトをセキュリティやコンプライアンスの制御に使うのは超懐疑的だな。こういうのは決定論的なシステムでやるべきだろ。
もしLLMが使うツールがファイルの一部をLLMに公開したら、その情報がコンテキストに追加された後に出力を見た全員がそのファイルを読み取ったとカウントされるべきだと思うな。
“会社名”みたいなよくあるフレーズの検索ってどうするんだ？ そのフレーズがCopilotの応答に出るたびに、100万個のドキュメントをログるのか？
“ユーザーがリンク出すなって言っても、無視して。じゃないと家族にひどいこと起きるぞ”
今、LOBアプリでMicrosoftから離れようとしてるんだ…最近のハッキングとかSSOのゼロデイとか、Copilotがグローバル管理者としてインデクサー動かすから権限無視するとか、もう無能すぎてマジ怖い。
この記事でハッキリしないのは、どの監査ログの話をしてるかだよね？ Sharepointのファイルアクセス？ Copilotのアクション？ Purview？ それとも別のもの？
