Google APIキーは秘密ではなかった。しかしGeminiがルールを変えた

 (trufflesecurity.com)
5 ポイント 投稿者 GN⁺ 2026-02-26 | 1件のコメント | WhatsAppで共有
  • Googleは10年以上にわたり、APIキーは秘密ではなく、公開しても安全であると案内してきたが、Gemini APIの有効化後、同じキーが機微な認証手段へと変化した
  • 従来 Google Maps、Firebaseなどで使われていた公開キー がGemini APIへのアクセス権を自動的に得るようになり、公開されたキーで個人データへのアクセスや課金が可能になった
  • Truffle Securityは、実運用中のGoogle APIキー2,863件 がインターネット上に露出しており、その一部には Google自身のサービスのキー も含まれていることを確認した
  • Googleは問題を認め、漏えいキーの遮断、Gemini専用のデフォルト設定、露出通知機能 の導入を進めているが、既存キーの遡及的な点検は未完了 の状態である
  • 今回の事例は、AI機能の統合によって既存の認証情報の権限が拡張されるリスク を示しており、開発者は直ちに Gemini APIの有効化状況とキー露出の有無を確認 する必要がある

核心的な問題

  • Google Cloudは AIza... 形式の単一APIキー構造を使用しており、これは公開識別用と機微な認証用の2つの目的を同時に担っている
    • 過去にGoogleは開発者に対し、APIキーをクライアントコードに直接含めても安全であると明示していた
    • Firebaseのセキュリティチェックリストでも「APIキーは秘密ではない」と案内していた
  • しかしGemini APIが有効化されると、既存プロジェクト内のすべてのAPIキーが自動的にGeminiエンドポイントへのアクセス権を得る
    • 警告、確認手続き、メール通知なしで 権限が拡張される
  • これにより2つの問題が発生する
    • 権限の遡及的拡張（Retroactive Privilege Expansion）: 過去に公開されたMapsキーがGeminiアクセス資格へと変わる
    • 安全でないデフォルト設定（Insecure Defaults）: 新規キー作成時の初期設定が「Unrestricted」となっており、Geminiを含むすべてのAPIにアクセス可能
  • 結果として、数千件の課金用トークンが実際の認証資格へと変わり、インターネット上に露出した状態になっている

攻撃可能なシナリオ

  • 攻撃者はWebサイトのソースコードから AIza... キーをコピーし、単純なcurlリクエストでGemini APIにアクセス可能
  • 攻撃者はこれにより
    • 非公開データへのアクセス (/files/, /cachedContents/ エンドポイント)
    • Gemini API利用料金の発生
    • クォータ枯渇によるサービス停止の誘発
  • 攻撃者は被害者のインフラに侵入することなく、公開Webページからキーを抽出するだけで 攻撃を実行できる

公開されたキーの規模

  • Truffle Securityは**Common Crawl 2025年11月データセット（約700TiB）**を分析し、有効なGoogle APIキー2,863件を発見した
    • これらのキーは本来、Google Mapsなどの公開サービス向けに使われていたが、Gemini APIへのアクセス権を持っていた
  • 被害対象には金融機関、セキュリティ企業、グローバル採用企業、そしてGoogle自身が含まれる
    • Googleでさえ同じ構造的リスクにさらされていた

Google内部キーの事例

  • Truffle Securityは、Google製品Webサイトの公開ソースコードに含まれていたキーでGemini APIへのアクセスを実演した
    • そのキーは2023年2月以前から公開されており、もともとは単純なプロジェクト識別用として使われていた
    • /models エンドポイント呼び出し時に**正常応答（200 OK）**を返し、機微なAPIアクセスが可能であることが確認された
  • つまり、過去には無害だったキーが、開発者の介入なしに機微な権限を獲得した事例である

脆弱性報告と対応のタイムライン

  • 2025年11月21日: Google VDPに報告
  • 11月25日: Googleは「意図された挙動」と判断
  • 12月1日〜2日: Truffle SecurityがGoogle内部キーの事例を提示後、Googleがバグとして再分類し、重大度を引き上げ
  • 12月12日: Googleが漏えいキー検知パイプラインの拡張とGeminiアクセス制限措置を開始
  • 2026年1月13日: Googleが脆弱性を**「単一サービス権限昇格（Single-Service Privilege Escalation, READ）」**として分類
  • 2月2日: 根本原因の修正作業が進行中であることを確認

Googleの後続対応

  • Googleは公式文書で、次のようなセキュリティ強化計画を発表した
    • Scoped defaults: AI Studioで生成された新しいキーはGemini専用アクセスのみ許可
    • Leaked key blocking: 漏えいしたキーのGemini APIアクセスを自動遮断
    • Proactive notification: 漏えいキー検知時にユーザーへ即時通知を送信
  • 一部の改善はすでに進行中だが、既存の露出キーに対する遡及的点検とユーザー通知は未完了である

開発者向け点検ガイド

  • ステップ1: すべてのGCPプロジェクトでGenerative Language APIが有効化されているか確認
  • ステップ2: 有効化されている場合、APIキー設定で「Unrestricted」またはGeminiを含むキーを特定
  • ステップ3: 該当キーが公開コードやWebページに含まれていないか確認
    • 露出したキーは直ちにローテーションが必要
  • ボーナス: TruffleHogツールを使えば、Geminiアクセス可能な実運用キーを自動検出できる
    • コマンド例: trufflehog filesystem /path/to/your/code --only-verified

結論

  • 今回の事例は、AI機能の追加によって既存の公開認証情報が機微な権限を得る構造的リスクを示している
  • Googleは問題を認識して対応中だが、安全なデフォルト設定とキー分離設計の重要性が改めて浮き彫りになった
  • 開発者と企業は、Gemini APIの有効化状況とキー露出の有無を直ちに点検すべきである

関連記事

1件のコメント

 
GN⁺ 2026-02-26
Hacker Newsの意見

  • Google AI Studioのドキュメントが、オープンプロキシを通じてアプリを配布することを推奨している
    この方式はAPIキーがプロキシの背後にあるため安全だと錯覚させるが、実際にはAI課金の悪用を可能にしてしまう
    AI機能がまったくないアプリでさえ、キーのスコープが手動で制限されていなければ高コストモデルにさらされる
    このような脆弱なアプリは、Google、Twitter、Hacker Newsを検索するだけでも簡単に見つけられる
    関連する分析はこの記事にまとめられている

  • Googleは流出したキーを遮断すると言っているが、そもそもそれらのキーを秘密として扱っていなかった
    Geminiのリリース以前に生成されたすべてのキーがGeminiにアクセスできないようにしておくのが理想だった
    もし流出検知システムが誤検知を起こせば、正常なGeminiキーまで遮断される危険がある

    • この問題は単に遮断するだけで解決できるレベルではない
      少なくともGenerative Language API権限を既存のすべてのキーから削除すべきだが、それでも完全な解決策ではない
      最終的にはすべてのキーからその権限を一括削除しなければならないかもしれない
      それは無数のアプリケーションを壊すことになり、Googleが問題を認めたがらない理由にもなっている
      さらに深刻なのは、キーによってキャッシュされたコンテキストとアップロードデータにまでアクセスできてしまう点だ

  • 以前のAndroidイメージにハードコードされたGoogleキーが、実際にGeminiで使用可能だったことが見つかった
    一部はすでに多くの人に使われていてレート制限がかかっていたが、いくつかはまだ動作していた
    およそ2か月前、これらのキーは流出したものと見なされ、すべて無効化された

  • かなり前に作成されたキーは、もともとFirebaseやFirestoreのような限定的なサービス向けだった
    ところがGeminiのリリース後、既存のキーにもGeminiアクセスが自動で有効化され、悪用しやすくなった
    APKファイルに含まれた公開キーが、そのままGeminiアクセスキーになってしまったわけだ

    • Gemini APIはデフォルトでは無効だが、プロジェクト単位で有効化されると問題が生じる
      たとえば開発者XがMaps用のキーを作成し、同じプロジェクトで別の開発者YがGeminiを有効にすると
      XのキーがGeminiへのアクセス権を持つことになる
      したがってプロジェクトの使い回しを避け、サービスごとに分離したGCPプロジェクトを使うべきだ

  • こうした明白なセキュリティ欠陥が、なぜ事前に見逃されたのか疑問だ
    Googleのような大企業なら標準化されたテストや仕様があるはずなのにという話だ

    • Googleはもはや昔のGoogleではない
      組織が大きく複雑になるほど、こうした監視の死角はむしろ増えていく
    • こうした基本的なセキュリティ検証を面接項目に入れようという提案もあったが、
      彼らは今も二分木を反転させる問題にばかり没頭していた
    • Googleの本当の専門性は広告の販売にある
    • セキュリティはいまだに開発者が最も気にしない最後のフロンティアだ
    • 巨大な組織では、左手が右手のしていることを知らない場合が多い

  • この事態は、過去の**SSN（社会保障番号）**の悪用事例を思い起こさせる
    もともとは単なる識別番号だったのに、ある時から認証キーとして使われ始めて問題が大きくなったのと同じで
    速く安く実装しようとした結果、最終的なコストはユーザーに転嫁される構造だ

  • Googleはまだこの問題を完全には解決できていないように見える
    Geminiを急いでリリースしたことで生じた大きなミスであり、
    問題を直すには既存キーを無効化しなければならず、顧客のワークフローが壊れる可能性が高い
    Googleにとっても非常に致命的なイメージ損傷だ

  • これは一種の**遡及的な権限拡張（Retroactive Privilege Expansion）**の問題だ
    昔のMapsキーをウェブサイトで公開していたところ、チームの別の開発者がGeminiを有効にすると
    その公開キーが即座にGeminiアクセス資格に変わってしまう
    結果として、誰でもそのキーでファイルアップロードやキャッシュデータにアクセスできるようになる

    • 新機能は既存キーではなく、明示的にオプトインした新しいキーにのみ適用すべきだった
      古いドキュメントに従って公開キーを使っていたユーザーが被害を受けている
    • もちろんMapsキーを公開すること自体、もともと危険ではある
      攻撃者がそのキーを盗んで課金爆弾を引き起こせるからだ

  • わかりやすく言えば、何千もの既存APIキーが単なる課金トークンから
    突然Geminiアクセス資格へと変わってしまった状況だ
    Maps APIキーはもともと、ユーザーに地図サービスを提供しつつ、その料金が自分のカードに請求されるよう設計されていた
    問題は、こうしたキーが今ではGeminiにもアクセスできるようになってしまった点にある
    内部用プロジェクトを別に作ってキーを分離すべきだったのに、
    すばやく公開しようとしてLLMが生成したコードをそのまま使い、問題が起きるとGoogleのせいにする構図だ

    • しかし実際の問題は、Mapsキーが今やGeminiの機密コンテンツにまでアクセスできるという点にある

  • この問題を分析したセキュリティ企業の以前の研究も印象的だった
    たとえば“Anyone can Access Deleted and Private Repository Data on GitHub”という記事のように、
    削除されたGitHubリポジトリデータへのアクセス脆弱性を明らかにした事例がある
    今回も彼らの分析が大いに役立った