APIキーの棚卸し・ローテーション手順｜所有者不明の秘密情報を残さない運用
SaaS、クラウド、社内アプリを増やすほど、APIキーは管理画面、Secret Manager、CI/CD、サーバー設定、委託先の環境へ散らばります。発行時の担当者が異動し、用途を説明できないキーが残ると、不要な権限を閉じられず、漏えい時にも影響範囲と停止判断が定まりません。
結論から言うと、APIキーの棚卸しでは値そのものを集めず、キーを識別できるID、発行元、利用先、所有者、環境、権限・制限、保管場所、最終利用、依存業務、失効条件を台帳化します。ローテーションは新しいキーを作ってすぐ旧キーを消すのではなく、新キーの制限確認、配布、段階切替、利用監視、業務結果の照合を行い、旧キー依存がなくなってから失効します。
本記事のポイント
- APIキー台帳には秘密値を記録せず、識別子、発行元、所有者、利用先、権限、保管場所、最終利用、失効条件を結び付けます。
- 停止を避けるローテーションは、新キー発行、制限確認、配布、段階切替、監視、旧キー失効を別工程として進めます。
- 所有者不明や漏えい疑いのキーは放置せず、露出範囲、権限、最近の利用、依存先を確認し、危険度に応じて即時失効または隔離切替します。
APIキーの棚卸しで記録する項目を固定する
最初に、APIキーを「文字列の一覧」ではなく「利用中の認証・識別経路」として捉えます。APIキーの意味はサービスによって異なり、プロジェクトを識別して利用量を割り当てるもの、特定APIへのアクセスを許可するもの、サービスアカウントへ権限を結び付けるものがあります。名前だけで危険度を決めず、キーを持つ人が何を実行できるか、どのデータや課金へ到達するかを確認します。
台帳へ秘密値を貼り付けてはいけません。値の代わりに、提供サービスが発行するキーID、表示名、末尾数文字、Secret Managerの論理名やversion IDなど、照合に必要な識別子だけを記録します。秘密値を台帳へ複製すると、棚卸し資料そのものが新しい漏えい経路になります。
| 台帳項目 | 記録する内容 | 判断できること |
|---|---|---|
| 識別情報 | 提供者、プロジェクト・組織、キーID、表示名、環境 | 同名キーや本番・検証の取り違えを防ぐ |
| 所有者 | 業務責任者、技術担当、承認者、緊急連絡先 | 変更・失効を誰が判断するか明確にする |
| 利用先 | アプリ、バッチ、CI/CD、連携先、委託先、実行主体 | 停止時に影響する処理を特定する |
| 権限・制限 | 許可API、操作範囲、送信元IP、参照元、アプリ制限、quota | 漏えい時の到達範囲と縮小余地を評価する |
| 保管・配布 | Secret Managerの論理名、CI変数、取得経路、閲覧権限 | 平文コピーや過剰な閲覧権限を見つける |
| 利用状況 | 作成日、最終利用、呼出数、主要エラー、利用リージョン | 未使用候補と不審利用を分ける |
| 終了条件 | 次回確認日、切替方法、監視項目、失効承認、復旧条件 | 期限超過や「消せないキー」の常態化を防ぐ |
発見元は一つに決めません。クラウドやSaaSの資格情報一覧、Secret Manager、CI/CDのsecret・変数、サーバーやコンテナの設定、API gateway、実行ログ、コードのsecret scanningを突き合わせます。設定ファイルだけを見ると、管理画面で発行された未使用キーや、委託先が保持するキーを見落とします。逆に管理画面だけを見ると、どのアプリがどのキーを使っているか分かりません。
企業サイトでは、計測タグ、チャット、埋め込み、フォーム連携が別々の管理者によって追加されることがあります。ブラウザ側へ露出する識別子と、サーバーだけに置く秘密情報を分けながら利用先を洗い出す方法は、企業サイトの外部スクリプト棚卸しも参考になります。Google Cloudも、不要キーの削除、アプリごとの分離、利用監視、APIや利用元の制限を推奨しています。
ローテーション方式と旧キーの停止条件を決める
ローテーションの前に、提供サービスが複数キーの同時有効化、旧キーの復元、version指定、失効予約、利用ログ、キー単位の制限に対応しているか確認します。Google Cloudの公式手順は、旧キーと同じ制限を持つ新キーを作り、アプリを新キーへ更新し、すべての更新後に旧キーを削除する順番です。ただし、棚卸しで過剰権限が見つかった場合は、旧設定をそのまま複製せず、必要なAPI、送信元、環境へ絞った新キーを用意します。
| 状況 | 切替方式 | 旧キーの扱い | 復旧の考え方 |
|---|---|---|---|
| 計画的な定期交換 | 新旧を短期間併用し、利用先を段階切替 | 依存ゼロを確認後に失効 | 漏えい疑いがなければ確認期間内だけ旧キーへ戻せる |
| 権限縮小 | 制限を絞った新キーでcanary実行 | 不足権限がないと確認後に失効 | 権限を広げ直す前に失敗操作を特定する |
| 漏えい・公開リポジトリ混入 | 新キーを緊急発行し、影響度に応じて即時切替 | 高危険度なら待たずに失効 | 疑わしい旧キーへ戻さず別の新キーを再発行する |
| 所有者不明 | 利用ログと依存先を限定観測し、担当を仮置き | 未使用証拠または代替切替後に失効 | 停止による業務影響を隔離できる窓口を用意する |
| サービス終了 | データ移行と連携停止を先に完了 | APIキー、OAuth、Webhookをまとめて失効 | 旧環境の権限を復旧手段として残さない |
APIキーとWebhook署名シークレットは似ていますが、切替点が異なります。APIキーは一般にクライアントが外部APIへ提示する資格情報であり、利用するアプリ側を新キーへ更新します。Webhook署名シークレットは受信側が配送の正当性を検証する値であり、送信側と受信側の併用仕様を確認します。後者の詳しい段階切替はWebhook署名シークレットのローテーションで整理しています。
旧キーの停止条件は「新キーで1回成功した」では不足です。定期バッチ、月次処理、障害時だけ動く復旧ジョブ、別リージョン、古いworker、委託先の手動作業は、通常時間帯の確認では見えません。最大実行間隔と再試行期間を含む観測窓を決め、新旧キー別の利用件数、認証エラー、処理遅延、業務レコード反映を照合します。
停止しないローテーションを7ステップで進める
安全な交換は、秘密値を差し替える一回の作業ではありません。利用先の固定、新キーの制限、配布、段階切替、監視、旧キー失効を分け、各段階に担当者、成功条件、停止条件、証跡を付けます。
- 対象と変更範囲を固定する：キーID、発行元、環境、所有者、利用アプリ、実行主体、権限、最終利用を台帳で確認します。今回変えないキーや関連secretも明示し、複数変更を混ぜません。
- 依存先と観測点を洗い出す：ソースコード、Secret Manager、CI/CD、コンテナ、サーバーレス環境、バッチ、委託先、手動runbookを照合します。APIの成功率だけでなく、注文、通知、CRM更新など最終結果の確認方法を決めます。
- 制限付きの新キーを発行する：本番・検証を分離し、必要なAPI、操作、IP、参照元、アプリへ制限します。発行直後に秘密値をチケットやチャットへ貼らず、専用保管先へ直接登録します。
- 実行環境へ安全に配布する：新versionや新しい論理参照を設定し、閲覧権限を実行主体へ絞ります。設定値をログへ出さず、全instanceが新しい参照を取得できるかを確認します。
- 小さい範囲から新キーへ切り替える：検証環境、canary worker、低リスク処理などから開始し、認証成功、quota、権限不足、レート制限、遅延を確認して対象を広げます。
- 新旧キー別に利用と業務結果を監視する：新キーの成功だけでなく、旧キーの呼出しが残っていないか、認証エラーが増えていないか、下流の件数が一致するかを確認します。失敗イベントの突合方法はWebhook失敗イベントの再送・再処理手順の台帳設計も応用できます。
- 旧キーを失効し、残骸を回収する：提供側で旧キーを無効化または削除し、Secret Managerの旧version、CI変数、ローカル設定、委託先保管、手順書の古い参照を外します。実行者、時刻、確認ログ、影響なしの結果を台帳へ記録します。
ローテーション中の復旧は、セキュリティ事故と通常の設定ミスで分けます。計画交換で新キーの制限不足が見つかり、旧キーに漏えい疑いがない場合は、限定した時間だけ旧キーへ戻して再設計できます。漏えい対応では旧キーへ戻さず、別の新キーを発行し、危険な処理を止めたうえで復旧します。
サービスの解約や乗り換えでは、APIキーだけを消して完了にしません。データexport、連携先切替、Webhook停止、OAuth token、サービスアカウント、共有リンクを一つの終了計画で閉じます。全体の終了条件はAI・SaaSサービスの終了・乗り換え計画で確認できます。
所有者不明・漏えい疑いのキーを放置しない
所有者不明のキーは、即削除か永久保留かの二択にしません。まず仮の対応責任者を置き、発行元、権限、公開範囲、最終利用、呼出元、業務影響を短時間で確認します。利用記録がない場合も、ログの保存期間外に月次・年次処理がある可能性を確認し、停止テストや新キーへの隔離切替で証拠を増やします。
| 状態 | 優先対応 | 確認する証拠 | 完了条件 |
|---|---|---|---|
| 公開場所へ露出した本番キー | 影響の大きい操作を止め、原則として即時失効 | 公開時刻、権限、利用ログ、操作結果、課金 | 旧キー無効化、不正利用調査、新キー切替 |
| 所有者不明だが最近利用あり | 実行元を隔離し、仮所有者の下で新キーへ切替 | 送信元、user agent、ジョブ、宛先API、下流結果 | 利用先と責任者が確定し、旧キーを失効 |
| 長期間利用なし | 無効化候補として影響確認 | ログ保存範囲、定期処理、障害復旧手順、委託先 | 必要な観測期間後に失効し、再発行窓口を記録 |
| 権限過大・制限なし | 制限付き新キーへ優先移行 | 実際のAPI操作、IP、環境、quota、データ範囲 | 必要最小限の新キーだけが利用される |
GitHubは、漏えいした秘密情報について、公開範囲、最終利用、アクセス範囲、依存サービスを確認し、高リスクなら早く失効するよう案内しています。コードから値を消すだけでは、コピー済みの資格情報は使い続けられます。提供者側で失効し、露出から失効までの利用と業務結果を調べる必要があります。secret scanningの警告を受け取る担当と、サービス提供者へ失効を依頼できる権限者を事前に決めてください。
外部からキー露出の連絡を受ける可能性があるなら、報告窓口、一次応答、技術担当への引継ぎ、緊急失効権限をつなげます。窓口の公開と更新責任はsecurity.txtと脆弱性報告対応で整理できます。
継続運用では、全キーを同じ周期で機械的に交換するより、権限、露出経路、利用頻度、再発行の容易さ、事業影響で優先順位を付けます。所有者不明数、制限なしキー数、最終利用不明数、確認期限超過数、漏えい検知から失効までの時間を指標にすると、交換回数ではなく残存リスクを減らせます。可能なサービスでは、長期APIキーを短命token、workload identity、管理されたservice accountへ置き換えることも検討します。
よくある質問
APIキーの棚卸しでは何を記録しますか？
秘密値ではなく、キーID、発行元、プロジェクト・環境、所有者、承認者、利用アプリ、実行主体、権限・制限、保管場所、作成日、最終利用、次回確認日、失効条件を記録します。値はSecret Managerなどの専用保管先に置き、台帳からは参照情報だけをたどれるようにします。
利用中のAPIキーを停止せずにローテーションするにはどうしますか？
新旧キーを併用できる仕様を確認し、制限付き新キーを発行して一部の実行環境から切り替えます。新キーの認証成功、権限、quota、エラー、遅延、下流の業務結果を確認しながら対象を広げ、旧キーだけを使う処理がなくなってから失効します。
所有者や利用先が分からないAPIキーをどう扱いますか？
仮の対応責任者を置き、提供側ログ、送信元、CI/CD、Secret Manager、コード、バッチ、委託先を照合します。最近の利用や高い権限があれば隔離した新キーへ切り替え、未使用候補でもログ保存期間と定期処理を確認してから失効します。担当不明のまま期限だけ延長しません。
旧APIキーを失効できる条件は何ですか？
全利用先が新キーを取得し、想定する最大実行間隔と再試行期間を通じて旧キーの正規利用がゼロで、認証エラーや業務件数の差異がないことが条件です。その後、提供側の旧キー、保管先の旧version、CI変数、委託先のコピーを順に無効化します。
APIキーは何日ごとにローテーションすべきですか？
一律の日数だけでは決められません。提供者の期限、キーの権限、公開可能性、利用頻度、監視能力、交換のしやすさ、事業影響に基づいて周期を決めます。定期日だけでなく、担当変更、権限変更、保管先移行、漏えい疑い、サービス終了も交換契機にします。
環境変数に保存すればAPIキー管理は十分ですか？
十分ではありません。環境変数はコードへの直書きを避けられますが、発行元、所有者、閲覧権限、version、監査、最終利用、失効を自動で管理しません。専用保管先を正本にし、実行主体だけが取得できるようにし、台帳で利用先と終了条件を管理します。
公式仕様・公的資料を確認する
旧APIキーを失効する合図は、新しいキーが使えた時ではなく、旧キーでしか成功しない正規処理がゼロだと確認できた時です。秘密値を集めない台帳、所有者と依存先の対応、制限付き新キー、段階切替、利用と業務結果の監視、失効証跡をつなげることで、定期交換と緊急対応を同じ運用として実行できます。
