ハクソク

世界を動かす技術を、日本語で。

GoogleのAPIキーは秘密ではなかったが、ジェミニがルールを変えた

89日前原文(trufflesecurity.com)

概要

  • Google APIキー は長年「秘密情報ではない」とされてきたが、 Gemini API の登場で状況が一変
  • 公開済みAPIキー がGemini経由で機密データにアクセス可能となる重大な権限昇格リスク
  • 2,800件超のAPIキー がインターネット上で発見され、悪用可能な状態
  • Google自身も被害者 となるほどの設計上の問題
  • 即時の監査と運用見直し が必要

Google APIキーとGeminiによる権限昇格問題

  • Google APIキー（ AIza...形式）は、これまでMapsやFirebaseなど 公開用途 で利用されてきた
  • 公式ドキュメント でも「APIキーは秘密情報ではない」と明記
    • 例：Firebaseのセキュリティチェックリスト、Google MapsのJavaScript埋め込み手順
  • 本来は プロジェクト識別子や課金管理 のためのトークン設計
  • しかし、 Gemini API （Generative Language API）が有効化されると、既存APIキーが 自動的にGeminiの認証情報としても機能
    • 開発者への 通知や警告なし で権限が拡張される
  • その結果、 公開済みAPIキー でGemini経由の機密データ取得や課金が可能となる

問題の本質

  • Retroactive Privilege Expansion（遡及的権限拡張）
    • 過去に作成・公開したMaps用キーが、後からGemini用の「秘密鍵」へと変貌
  • Insecure Defaults（安全でないデフォルト設定）
    • 新規APIキーはデフォルトで「無制限」設定、全API（Gemini含む）へのアクセスが可能
  • Key Separationの欠如
    • 公開用/秘密用の明確なキー分離がなく、同一形式で両方を担う設計
  • 安全な初期値の欠落
    • GCPのAPIキー作成パネルのデフォルト設定がGemini等の機密APIにもアクセス許可

攻撃シナリオと被害範囲

  • 攻撃者は WebページのソースからAPIキーを取得 し、Gemini APIにリクエスト
    • 例：curl "https://generativelanguage.googleapis.com/v1beta/files?key=$API_KEY"
  • 成功時、以下の被害が発生
    • 機密データ取得 （アップロードファイル、キャッシュデータ等）
    • 課金被害 （LLM利用による高額請求）
    • リソース枯渇 （APIクォータ消費による正規サービス停止）
  • 2,863件 の公開APIキーが実際に悪用可能状態で発見
    • 金融機関、セキュリティ企業、大手リクルート会社、 Google自身 も含む

実例：Google自身の公開キー

  • Google製品の公開Webページに埋め込まれたAPIキーでGemini APIへアクセス可能
  • 本来Maps専用だったキー が、Geminiの機密エンドポイントにも有効化
  • 開発者の認識外で特権が拡張 されていた事実

Googleの対応と今後の方針

  • 報告当初は「意図した挙動」として対応が遅れる
  • 証拠提示後に問題を認識し、修正対応を開始
    • 流出キー検出パイプラインの拡張
    • Gemini APIへのアクセス制限
    • 根本原因の修正計画
  • 今後のロードマップ
    • AI Studio経由の新規キーはGemini限定アクセスに
    • 流出キーの自動ブロック
    • 流出時の積極的通知
  • 既存キーの監査・通知は困難だが、今後の改善が期待される

直ちに取るべき対策

  • 全GCPプロジェクトでGemini APIの有効化状況を確認
    • GCPコンソール > APIs & Services > 有効なAPI一覧で"Generative Language API"を確認
  • APIキーの設定監査
    • APIs & Services > Credentialsで各APIキーの制限状況を確認
      • 警告アイコン 付き（無制限設定）
      • Gemini APIが許可サービスに含まれる キー
  • 公開状態のキーがGeminiアクセス権を持っていないか確認
    • 特に古いキーは要注意
    • 該当する場合は 即時ローテーション（再発行・差し替え）
  • TruffleHog等のツールでコード・CI/CD・Web資産をスキャン
    • trufflehog filesystem /path/to/your/code --only-verified

まとめと教訓

  • AI機能追加による既存認証基盤のリスク拡大 への注意喚起
  • 公開識別子の「静かな特権昇格」 はGoogleに限らず今後も発生しうる
  • 設計段階でのキー分離・最小権限・安全なデフォルト の重要性

参考リソース

Hackerたちの意見

もどかしいのは、これらのキーの多くがずっと前に生成されて、接続できるGCPサービスが少なかったことだよね。（例えば、FirebaseリモートコンフィグやFirestoreとか）Geminiが登場したとき、そのキーに対してサービスがデフォルトで無効になっていればよかったのに、Geminiが有効になってしまったせいで、悪用する人たちが簡単にこれらのキーを使えるようになっちゃった。（例えば、APKファイルに保存された「公開」キーとか）

└

Gemini APIはデフォルトで有効になってないから、プロジェクトのオーナーが明示的に有効にしないといけない。ここで説明されてる問題は、開発者XがMaps用のAPIキーを作って、開発者YがGeminiをオンにした結果、XのキーがGeminiにアクセスできるようになってしまったってこと。XもYもそれに気づいてないんだよね。解決策は、GCPプロジェクトを複数の目的で使い回さないこと、特に本番環境ではね。

漏洩したキーのブロック。漏洩したと見なされたAPIキーをGemini APIで使用する場合、デフォルトでブロックされるようになってる。Googleがそれを秘密だと言っていなければ、「漏洩」したキーは存在しないはずだよ。理想的には、Geminiリリース前に作成されたすべてのキーがGeminiにアクセスできないようにすべきだね。もし漏洩したキーの「発見」で誤検知があって、Geminiのキーがブロックされるようなことになったら面白いけど、驚きはしないな。

└

どうやってこれから回復するのか全然わからないよね。最低限、Generative Language APIの権限をリリース前に作成されたすべてのAPIキーから削除しなきゃいけないと思う。でもそれでも完全な解決にはならない。リリース後に作成されたキーの中にも、うっかりそれを持っているものがあるからね。もしかしたら、発行されたすべてのAPIキーから一律にGenerative Language APIの権限を削除しなきゃいけないかも。これで多くのアプリが壊れちゃうだろうね。これが問題だと認めたくないのも納得だよ。Geminiのトラフィックの全体のパーセンテージにしても、レベルのミスだよ。マジで、キーがキャッシュされたコンテキストやGeminiのアップロードを漏洩させるなんて、Googleが今まで出した中で最悪のセキュリティ脆弱性かもしれない。

最後の方の含みは、Googleがこの問題をまだ解決していないってこと？これは本当にまずい。急いでGeminiを顧客に届けようとした結果、明らかに大きな見落としがあったし、修正が顧客のワークフローを壊す可能性が高い。Googleにとっては非常に悪い印象だね。

誰かがGeminiのプロンプトを作って、これらの公開キーを見つけて、自分自身のコピーを起動するのが待ちきれない。

これって、すごく…明白じゃない？こんな大きな会社が、才能や専門知識を持っているのに、こんな明らかな欠陥を防ぐための標準テストや仕様がないなんて、どういうこと？

└

おそらく、社内のAIツールを使ってこれを構築したんじゃないかな。

└

こういうのは標準的な面接に追加することが提案されたけど、彼らはバイナリツリーを逆にするのに忙しすぎたんだよね。

└

まず第一に、Googleは昔の会社とはまるで別物になっちゃったよね。とはいえ、ある規模、特に複雑さに達すると、こういう見落としが起こりやすくなるっていう進化的な説明があると思う。

└

こんな大きな会社だと…左手が右手のやってることを知らないって感じだね。

└

彼らの「才能と専門知識」は、ほとんど広告を売ることに特化してるよね。

なるほど、そういうことか。昔のAndroidイメージにハードコーディングされてたGoogleのキーが、Geminiで使えるってことに気づいてたんだ（もちろん研究目的でね）。一部はすぐにレート制限がかかってたから、他の人が使ってたのかもしれないけど、まだ使えるのもあったんだよね。それが2ヶ月前に全部無効化されるまで。しかも、いくつかはその前にGemini APIのアクセスも無効にされてたみたい。

遡及的特権拡張。3年前に作ったMapsキーを、Googleの指示通りに自分のウェブサイトのソースコードに埋め込んだ。先月、チームの開発者が内部プロトタイプのためにGemini APIを有効にした。今や、あなたの公開MapsキーがGeminiの資格情報になってる。誰かがそれをスクレイピングすれば、あなたがアップロードしたファイルやキャッシュされたコンテンツにアクセスできて、AIの請求書が増えちゃう。誰も教えてくれなかった。これはひどいよね。信じられない。

うわぁ。早く動くことで生じたインピーダンスミスマッチだね。GCPの認証モデルは、oAIのAPIキーのモデルとは全然違う設計になってるから、今年の痛いポイントの一つだけど、特に厄介だよ。共感はするけど、GCPを扱うのは常に大変だから、ちょっと共感が薄れるかな。

GCPのコードをGeminiで振動させたせいで起きたバグって感じだね。