Gemini APIキー悪用:露出キーをGoogle Cloudで検出

TL;DR

設定ミスのあるAPIキーを悪用してGemini APIでコンテンツを生成する手口が急増しています。被害に遭う前にぜひお読みください。
問題のあるAPIキーを特定するための無料オープンソーススキャンツールを公開しました。こちらからご利用ください: https://github.com/doitintl/gcp-apikey-check

いま何が起きているのか

DoiTでは、クラウドに関するあらゆる事例を日々目にしています。最近、Geminiにまつわる予期せぬ高額請求の報告がコミュニティから相次いでいます。自社アプリでGeminiを使っているかどうかに関わらず、ある朝目を覚ますとコンテンツ生成による多額の請求が届いている——その多くは画像や動画の生成で、課金アラートが間に合わないスピードで請求額が膨らんでいきます。Google APIキーをどこかで使っている方は、ぜひこのまま読み進めてください。あなたのキーも危険にさらされているかもしれません。

なぜ起きるのか

Google Cloudも他のクラウドプロバイダーと同様、責任共有モデルで運用されています。基盤インフラの責任はGoogleが負い、その利用に関するセキュリティはユーザーが負う仕組みです。Googleは単一のAPIキー形式(AIza...)を、公開可能なプロジェクト識別子と、機密性の高い認証情報という、まったく異なる2つの目的で使い回しています。

Google MapsやFirebaseのAPIキーの問題は以前から指摘されてきました。APIキー生成時のデフォルトでは制限が一切かかっておらず、特定のWebサイト・IPアドレス・SDKへの利用範囲の絞り込みは開発者任せだったためです。そして、それが徹底されてきたとは言えません。Google MapsやFirebaseのAPIキーはフロントエンドのクライアントコードに埋め込まれることが多く、もともと秘匿性は高くなく、実質的には課金識別子として使われてきました。

問題が深刻化したのは、制限のないMapsまたはFirebaseのAPIキーが存在するプロジェクト内でGemini APIが有効化されるようになってからです。攻撃者はこれらのキーを見つけると、すぐに悪用の手口を編み出しました。

Google CloudプロジェクトでGemini APIが有効化されると、そのプロジェクト内で特定のAPIにスコープされていない既存のAPIキーすべてが、知らぬ間にGeminiエンドポイントへのアクセス権を得てしまいます。警告も、メールも、確認も一切ありません。何年も前にWebサイトに埋め込んだMapsキーが、ページソースをのぞいた誰もが使える有効なGemini認証情報になっている、ということが起こり得るのです。

キー漏洩のもう一つの経路は、APIキーや静的なService Accountキーを誤って公開GitHubリポジトリにコミットしてしまうケースです。かつては攻撃者にすぐ拾われ、暗号通貨マイニングに使われていましたが、近年Googleはこの種の不正検知の精度を大きく向上させています。

攻撃者は何をするのか

手口は驚くほど単純です。攻撃者はページソースを開いてAIza...キーをコピーし、Geminiの画像生成APIを呼び出す——それだけです。インフラへの侵入も、認証情報の窃取も、高度なエクスプロイトも不要。あなたのキーとHTTPリクエスト1本があれば十分で、それを短時間に何度も繰り返し、すべてあなたのアカウントに課金されます。

自社は大丈夫か?

次の問いに答えられるでしょうか。

Generative Language APIまたはGemini Agent Platform API(旧Vertex AI)が、いずれかのGCPプロジェクトで有効になっていませんか?
API制限もアプリケーション制限も設定されていないAPIキーが存在しませんか?
MapsまたはFirebaseのキーが、AI APIと同じキーになっていませんか?
古い、使われていない、あるいはowner / editorロールを持つService Accountキーが残っていませんか?

プロジェクトが少数ならともかく、数が多くなれば組織全体を手作業で確認するのは現実的ではありません。

数分で組織全体をスキャン

DoiTは日々Google Cloudのお客様と協業しています。お客様に提供しているのと同じ可視性をより広いコミュニティにも届けたい——そう考えて開発したのがgcp-apikey-checkです。無料・オープンソースで公開しています。

git clone https://github.com/doitintl/gcp-apikey-check
cd gcp-apikey-check
uv sync

# 組織全体をスキャン
uv run gcpkeyscan.py --org-id YOUR_ORG_ID

# 単一プロジェクトをスキャン
uv run gcpkeyscan.py --project-id YOUR_PROJECT_ID

このツールは、請求額の急増につながる典型的な設定ミスを検出します。具体的には、制限のないキー、MapsとAI APIが同じキーに同居しているケース、アプリケーション制限のないFirebaseキー、過度に広いワイルドカードのリファラールールなどです。さらに、古い、未使用、あるいは過剰な権限を持つService Accountキーを洗い出し、組織ポリシーでSAキーの作成自体が許可されているかも確認します。検出結果は深刻度(CRITICAL / HIGH / MED)でタグ付けされ、JSONおよびCSVで出力されるため、すぐに対処に移れます。

直す——そして「そもそもキーが要るのか」を見直す

最も大事な前提を一つ。最良のAPIキーは「APIキーを使わないこと」です。

Google自身のベストプラクティスも明確で、APIキーとService Accountキーは可能な限り避けるべきとされています。APIキーにはアイデンティティがなく、デフォルトで有効期限もなく、きめ細かな監査ログも残りません。バックエンドサービスやGCP上のworkloadsであれば、ほぼ常により良い選択肢が存在します。

サーバー間認証では、Service Accountキーではなく Workload Identity Federation を使う
GCP上で動くworkloadsには、IAMロールと組み合わせたApplication Default Credentialsを使う
Geminiは適切なIAMでサーバーサイドから呼び出し、クライアントサイドのコードにキーを露出させない

Mapsの埋め込み、FirebaseクライアントSDK、その他の正当なクライアントサイド用途でAPIキーが避けられない場合は、必ず適切に制限してください。

各キーを、必要なAPIだけにスコープする
アプリケーション制限を追加する:Web向けはHTTPリファラー、モバイル向けはバンドルID、サーバー向けはIPレンジ
MapsやFirebaseのキーを、Geminiをはじめとする他のAI APIと同じキーに絶対に同居させない
使っていないAPIは無効化する
課金アラートを設定し、急増を数日見逃すような事態を防ぐ

すぐには無くせないService Accountキーについては、90日を超えたものはローテーションし、ownerやeditorロールを外し、最近使われていないものは削除してください。

幸い、Googleは新規APIキー作成時のデフォルトを以前より厳格にしており、現在は制限のないキーを作ることができなくなっています。Google AI Studioも、Gemini APIに限定された新規キーを発行するようになりました。これですべてが解決するわけではありませんが、健全なデフォルトは確実に助けになります。

請求書が届いてからでは遅い

Googleはデフォルト強化に舵を切っていますが、それがいつ実現するのか、すでに展開済みのキーをどこまで守ってくれるのかは、まだ見えていません。予期せぬ高額請求について発信している開発者たちは皆、手遅れになるまで自身の露出に気づきませんでした。

今日のうちにスキャンを実行してください。何があるかを把握し、深刻なものから直し、可能なところからキーそのものの廃止へと進めていきましょう。

https://github.com/doitintl/gcp-apikey-check