先週、部下の一人から「ちょっと気になる記事があって」と声をかけられました。セキュリティ企業Aikidoが発表した調査で、Google APIキーは削除後も最長約23分間、認証に成功するケースがあるという内容でした。中央値でも約16分。削除したつもりが、まだ生きている。これは正直、ゾッとしました。
私の部門では昨年からSalesforceと社内システムのAPI連携を進めており、開発ベンダーとのやり取りの中でAPIキーの管理はそれなりに議論してきました。「漏れたらすぐ削除する」というフローは整備済みで、情報システム部門にも確認を取っています。ただ、「削除したら即無効」という前提で設計していた部分は否定できません。その前提が崩れるとなると、話が変わってきます。
Aikidoの調査によれば、GoogleのインフラはAPIキーの削除情報を世界中のサーバーへ段階的に反映する仕組みになっています。大規模システムを安定稼働させるための設計思想で、これ自体は理にかなっています。ただ認証情報の無効化に同じ考え方を当てはめると、攻撃者が削除後も秒間3〜5回のリクエストを送り続けることで、まだ反映が終わっていないサーバーに当たり続けられるわけです。BigQueryやMaps向けのAPIキーでも同様の挙動が確認されていると報告されています。
さらに厄介なのが、被害の性質です。Aikidoのジョー・レオン氏が指摘しているのは、Geminiが有効なプロジェクトであれば、攻撃者がアップロード済みファイルやキャッシュされた会話内容を外部送信できる可能性があるという点です。料金を使われる問題だけでなく、データが持ち出される問題でもある。これは営業DXに関わる私には無視できない視点です。
今回の件を受けて、まず自部門のAPI利用状況を棚卸しするよう担当者に指示しました。うちの部門では外部SaaSとのAPI連携が現時点で7本動いています。それぞれのキー管理手順と、インシデント時のフローを改めて確認する必要があります。
経営陣への説明を考えると、「削除後も23分使える」という事実はそのままでは伝わりにくいです。「削除 = 即停止」という常識が覆されている、という点を投資対効果の文脈で整理する必要があります。Googleの課金ポリシーの話も頭に入れておかないといけません。2026年4月に改定されたポリシーでは、条件次第で利用上限が250ドルから10万ドルへ自動引き上げになるケースがあります。日本円で約1590万円です。これは稟議書に数字として乗せやすい。
一方でGoogleは、この問題について「システムの想定通りの動作であり、セキュリティ問題ではない」という立場を取っています。ベンダー側が「仕様です」と言っている以上、利用者側で運用を変えるしかありません。Aikidoは「削除を即時完了ではなく30分程度かかる作業として扱うべき」と述べており、その間の監視をGoogle Cloudコンソールで行うよう推奨しています。この運用コストをどう社内で吸収するかが、現場の課題になります。
今後、API連携を含む開発案件のベンダー提案を評価するときに、私が確認項目に加えたいと思っているのは以下の点です。
正直なところ、これまでベンダー提案のセキュリティ評価では「アクセス制御があるか」「通信が暗号化されているか」くらいを見ていました。APIキーの失効タイムラグまで突っ込んで確認したことはありませんでした。今回の件で、確認すべき粒度が一段細かくなったと感じています。
部下には「今すぐ何かが起きているわけじゃないけど、知っているのと知らないのとでは対応速度が違う」と伝えました。25人のチームで営業DXを推進していく以上、こういう地味な知識のアップデートが後々の判断を左右します。ちょうど来月、情報システム部門との定例が入っているので、そこでこの話題を持ち込むつもりです。社内のAPIキー管理規定に「削除後30分間の監視」という一文を追加してもらえるか、打診してみます。
私の部門では昨年からSalesforceと社内システムのAPI連携を進めており、開発ベンダーとのやり取りの中でAPIキーの管理はそれなりに議論してきました。「漏れたらすぐ削除する」というフローは整備済みで、情報システム部門にも確認を取っています。ただ、「削除したら即無効」という前提で設計していた部分は否定できません。その前提が崩れるとなると、話が変わってきます。
Aikidoの調査によれば、GoogleのインフラはAPIキーの削除情報を世界中のサーバーへ段階的に反映する仕組みになっています。大規模システムを安定稼働させるための設計思想で、これ自体は理にかなっています。ただ認証情報の無効化に同じ考え方を当てはめると、攻撃者が削除後も秒間3〜5回のリクエストを送り続けることで、まだ反映が終わっていないサーバーに当たり続けられるわけです。BigQueryやMaps向けのAPIキーでも同様の挙動が確認されていると報告されています。
さらに厄介なのが、被害の性質です。Aikidoのジョー・レオン氏が指摘しているのは、Geminiが有効なプロジェクトであれば、攻撃者がアップロード済みファイルやキャッシュされた会話内容を外部送信できる可能性があるという点です。料金を使われる問題だけでなく、データが持ち出される問題でもある。これは営業DXに関わる私には無視できない視点です。
経営陣にどう説明するか
今回の件を受けて、まず自部門のAPI利用状況を棚卸しするよう担当者に指示しました。うちの部門では外部SaaSとのAPI連携が現時点で7本動いています。それぞれのキー管理手順と、インシデント時のフローを改めて確認する必要があります。
経営陣への説明を考えると、「削除後も23分使える」という事実はそのままでは伝わりにくいです。「削除 = 即停止」という常識が覆されている、という点を投資対効果の文脈で整理する必要があります。Googleの課金ポリシーの話も頭に入れておかないといけません。2026年4月に改定されたポリシーでは、条件次第で利用上限が250ドルから10万ドルへ自動引き上げになるケースがあります。日本円で約1590万円です。これは稟議書に数字として乗せやすい。
一方でGoogleは、この問題について「システムの想定通りの動作であり、セキュリティ問題ではない」という立場を取っています。ベンダー側が「仕様です」と言っている以上、利用者側で運用を変えるしかありません。Aikidoは「削除を即時完了ではなく30分程度かかる作業として扱うべき」と述べており、その間の監視をGoogle Cloudコンソールで行うよう推奨しています。この運用コストをどう社内で吸収するかが、現場の課題になります。
現場の運用として何をするか
今後、API連携を含む開発案件のベンダー提案を評価するときに、私が確認項目に加えたいと思っているのは以下の点です。
- APIキー漏洩時の検知から削除までの手順が明文化されているか
- 削除後の監視フロー (コンソール上のリクエスト確認) が組み込まれているか
- Googleの新APIキー形式 (削除反映が約1分) への移行計画があるか
正直なところ、これまでベンダー提案のセキュリティ評価では「アクセス制御があるか」「通信が暗号化されているか」くらいを見ていました。APIキーの失効タイムラグまで突っ込んで確認したことはありませんでした。今回の件で、確認すべき粒度が一段細かくなったと感じています。
部下には「今すぐ何かが起きているわけじゃないけど、知っているのと知らないのとでは対応速度が違う」と伝えました。25人のチームで営業DXを推進していく以上、こういう地味な知識のアップデートが後々の判断を左右します。ちょうど来月、情報システム部門との定例が入っているので、そこでこの話題を持ち込むつもりです。社内のAPIキー管理規定に「削除後30分間の監視」という一文を追加してもらえるか、打診してみます。