AI901-Foundry#38-2
注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。
前提
ある企業の社内開発者が、Azure AI Foundry の GPT-4o を呼び出す Python の軽量チャット クライアント (社内 Slack ボット代替) を構築します。本番デプロイは Azure App Service で、認証 / 秘匿性 / 運用性のベスト プラクティスを守る必要があります。
解決策
API キーを Python ファイルにハードコードし、その Python ファイルを GitHub の Public リポジトリにコミットしてから Azure App Service にデプロイします。messages 配列ではなく単一文字列でモデルに渡します。
この解決策は目的を満たしますか?
解説
【判定: いいえ】の理由
本提案は深刻なセキュリティ違反と仕様違反を同時に含みます。第一に、API キーを GitHub Public リポジトリにコミットするとキーが世界中に公開され、ボット ネットによる即時悪用 / 課金乱用 / 認証情報のリークが発生します。GitHub 自動スキャナがキーを検出して Microsoft に通報し、自動的にキーを失効させる仕組みもありますが、検出までの数時間で大量の不正利用が起きうるレベルの致命的事故です。第二に、Foundry SDK のチャット API は messages 配列形式を要求し、単一文字列では呼び出しが失敗します。Microsoft Responsible AI Standard の Privacy and security 原則を完全に違反する設計で、本番運用は許容できません。正しくは Microsoft Entra ID + managed identity + messages 配列の組み合わせを採用すべきです。
【「はい」が違う理由】
セキュリティ事故と技術的不能の両面で致命的なため、「目的を満たす」と判定する根拠は皆無です。
本提案は深刻なセキュリティ違反と仕様違反を同時に含みます。第一に、API キーを GitHub Public リポジトリにコミットするとキーが世界中に公開され、ボット ネットによる即時悪用 / 課金乱用 / 認証情報のリークが発生します。GitHub 自動スキャナがキーを検出して Microsoft に通報し、自動的にキーを失効させる仕組みもありますが、検出までの数時間で大量の不正利用が起きうるレベルの致命的事故です。第二に、Foundry SDK のチャット API は messages 配列形式を要求し、単一文字列では呼び出しが失敗します。Microsoft Responsible AI Standard の Privacy and security 原則を完全に違反する設計で、本番運用は許容できません。正しくは Microsoft Entra ID + managed identity + messages 配列の組み合わせを採用すべきです。
【「はい」が違う理由】
セキュリティ事故と技術的不能の両面で致命的なため、「目的を満たす」と判定する根拠は皆無です。

コメント