API キーが漏れたと分かったら、最初にやることは3つです。まず、そのキーを無効にして、新しいキーに作り直します。次に、そのキーで何が行われたかを利用履歴で調べ、身に覚えのないものを消します。そして、発行元の窓口に連絡して、請求の扱いを相談します。コードや履歴から消す作業は、そのあとです。
私たちの経験: 公開リポジトリに、AWS のキーを上げてしまった
2015年、私たちは、仕事で使っていた AWS アカウントのアクセスキーを、公開の GitHub リポジトリに上げてしまいました。
自分たちでは気づけませんでした。知らせてきたのは AWS のセキュリティチームです。電話がつながらず、メールで「キーが外から見える状態になっている」と連絡が来ました。そのときにはもう、知らない誰かがそのキーを使って、サーバーを大量に立てていました。当時は仮想通貨のマイニングが流行っていて、拾われたキーは、他人のお金でマイニングをするのに使われたのです。
通知が来た時点で、請求はすでに数千ドルに達していました。最終的に、不正に使われた分は7千ドル強にまで膨らみました。
AWS に返信し、キーを削除して、勝手に作られたリソースを消して回りました。返金は、かろうじて認めてもらえました。ただし、AWS の窓口から示された条件は「今後のセキュリティを確保すること」と「今回限り」。次はない、ということです。
この一件で、身にしみたことが2つあります。ひとつは、漏れたあとは、手順の順序で被害の大きさが変わること。もうひとつは、返金は、当てにしてよいものではないことです。
最初にやること: 止める、調べる、消す、連絡する
ここからは、AWS のアクセスキーを例に、公式ドキュメントに沿って説明します。他のサービスも、考え方の骨格は同じです。
1. 止める: キーを作り直して、古いキーを無効にする
AWS の手順では、次の順で進めます。
- 新しいアクセスキーを作る。
- 使っているアプリやツールを、新しいキーに切り替える。
- 古いキーが、まだ使われているかを確かめる（IAM の最終使用日時、
get-access-key-last-used）。 - 古いキーを、削除せず、まず無効（Inactive）にする。
- アプリが新しいキーで動くことを確かめる。問題があれば、古いキーを一時的に有効に戻せる。
- 問題がなければ、古いキーを削除する。
AWS は、使われていない様子でも、いきなり削除せず、まず無効にすることを勧めています。止めてから様子を見て、問題がなければ消す、という順序です。
注意点があります。AWS は、キーが公開されたことを検知すると、そのユーザーに隔離用のポリシー（AWSCompromisedKeyQuarantine）を自動で付けることがあります。このポリシーは、キーの作成・無効化・削除（iam:CreateAccessKey、iam:UpdateAccessKey、iam:DeleteAccessKey）や、CloudTrail の検索（cloudtrail:LookupEvents）などを拒否します。つまり、漏れたキー自身の権限では、キーの更新も、履歴の検索もできない場合があります。そのときは、別の管理者権限の人が操作します。この隔離ポリシーは、外さないでください。 公式の説明は、外さずに、AWS が作るサポートケースの指示に従うよう求めています。
2. 調べる: そのキーで、何が行われたか
AWS の CloudTrail には「イベント履歴」があります。何も設定していなくても、過去90日分の管理イベントを、リージョンごとに検索できます。アクセスキーの ID で絞り込めます（lookup-events の AccessKeyId）。
見るのは、次のような操作です。
- アクセスキー、ユーザー、ロール、ポリシー、一時的な認証情報が、勝手に作られていないか
- 見覚えのない時刻や、見覚えのないリージョンでの操作がないか
AWS の公式ガイドは、見つけた不審なアクセスキー、ポリシー、ロール、一時的な認証情報を削除するよう案内しています。
限界も知っておいてください。イベント履歴は、管理イベントだけで、データへの読み書き（データイベント）は出ません。90日を超えた分も出ません。また、検索はリージョンごとで、一度に絞れる条件は1つです。
3. 消す: 勝手に作られたものを、全リージョンで探す
AWS の公式ガイドは、次のことを案内しています。
- コンソールで、自分が作ったものだけが残っているかを確かめる。
- 先月と今月の使用量を比べる。
- 全リージョンを確かめる。自分が使っていないリージョンも含めて。
- 不要なものを削除する。調査のために残す必要があるサーバー（EC2 インスタンス）は、削除前にスナップショットを取る。
普段使っていないリージョンも、忘れずに切り替えて確かめてください。
4. 連絡する: 発行元の窓口に、やったことを伝える
AWS は、公開されたキーを検知すると、サポートケースを自動で作り、AWS Health ダッシュボードとメールで知らせる、と説明しています。メールの宛先は、アカウントに登録した「セキュリティの連絡先」です。AWS の公式ガイドは、やった対応を、サポートセンターで、そのケースに返信するよう案内しています。
連絡先が古いと、通知に気づけません。登録している連絡先が、今も届くか確かめてください。（この点は、公式の記述から私たちが整理したものです。）
5. 請求: 返金は、当てにしない
私たちの場合は、かろうじて返金してもらえました。しかし、これは窓口から「今回限り」と言われた対応です。返金されるかどうかは、サービスの提供元が判断します。そのため、返金を前提に動かないことを勧めます。請求が出ているときは、無効化と調査を進めながら、早めに窓口へ連絡してください。
GitHub に上げた場合: 履歴から消す前に、無効化する
キーを GitHub に上げてしまった場合に、よくある間違いが、履歴からの削除を先にやることです。GitHub の公式ドキュメントは、順序をこう説明しています。
- 消したいデータが秘密情報なら、最初の手順は、それを失効または更新することです。失効または更新すれば、それ以降は使えず、それで足りる場合もあります。
- 履歴の書き換え（
git-filter-repoなど）はそのあとです。ただ、書き換えても、クローンやフォーク、GitHub 上のキャッシュされた表示、プルリクエストなどに、コミットが残っている場合があります。キャッシュされた表示やプルリクエストの削除は、GitHub サポートに依頼します。
つまり、履歴から消しても、すでに見られた可能性は消えません。だから、無効化が先です。
公開リポジトリには、GitHub のシークレットスキャンが無料で自動実行されます。提携先のサービスのキーが見つかると、GitHub は発行元に知らせ、発行元がキーの失効などの対応をとることがあります。ただ、これに頼らず、自分で無効化してください。
他のサービスのキーが漏れたとき
生成 AI、決済、メール配信など、AWS 以外のサービスのキーも、考え方は同じです。止める（無効化と再発行）、調べる（利用履歴）、消す（勝手に作られたもの）、連絡する（発行元の窓口） の順で動きます。画面の場所や、請求の扱いはサービスごとに違うので、各サービスの公式ドキュメントで確認してください。
私たちが今やっていること: 漏れても、被害が小さい形にしておく
いま私たちは、キーを漏らさないための備えを、人の注意ではなく、仕組みに任せるようにしています。
- CI/CD で、秘密の鍵を含むコードを通さない。 人が気をつけるだけでなく、公開前の検査で止めます。
- 長期のアクセスキーを置かない。 OIDC を使います。
- 請求額のアラームを置く。 想定外の請求に、早く気づくためです。
それぞれ、公式ドキュメントでも勧められています。
- AWS は、長期のアクセスキーをコードやリポジトリに埋め込まず、IAM ロールの一時的な認証情報を使うよう勧めています。CI/CD のようにAWS の外で動くものでも、一時的な認証情報を使えます。GitHub Actions なら、OIDC を使うと、AWS の認証情報を長期の GitHub シークレットとして保存しなくても、AWS にアクセスできます。
- 請求額は、CloudWatch の請求アラームや AWS Budgets で通知できます。ただし、AWS Budgets は通知までに遅れが出ることがあり、通知の前に、請求が閾値を超えることもあると公式に書かれています。アラームは、被害を小さくするためのものです。ゼロにするものではありません。
これから仕組みを入れるなら、次をおすすめします。
- GitHub の secret scanning と push protection。 無料で使えます。公開リポジトリでは secret scanning が自動で動き、個人のアカウントでは、秘密の鍵を含む push を止める機能が最初から有効です。
- CI に、秘密の鍵を検出するツールを入れる。 たとえば gitleaks は、Git のリポジトリやファイルから、パスワードや API キー、トークンを検出するオープンソースのツールです。GitHub Actions や、コミット前のチェックとしても使えます。
- AWS Budgets で、予算のアラートを設定する。 上に書いたとおり通知には遅れが出ることがあるので、被害を小さくする備えとして使います。
キーが外から見えていないかを公開前に確かめる方法は、APIキーがブラウザやコードから見えていないかにまとめています。
wizgeek にできること
公開前に、キーの置き場所や、権限、監視が整っているかを確かめたいときは、ご相談ください。試作の構成と機能を把握し、認証・データベース・インフラ・セキュリティ・監視のうち何が足りないかを整理して、構成案をお渡しします（本番化の診断：5万円〜、税別）。構成案をもとに、お客様側で実装していただくこともできます。公開後の保守運用は、月10万円〜（税別）です。
公開前に確かめる4点の全体像は、AIで作ったアプリを本番化するにはに、異常を検知する仕組みの考え方は、バックアップと監視にあります。