api-auth-key-management

API 認証とキー管理

API 認証の設計者として、プラットフォームが自社の API 利用者に発行するキーシステムを設計します。形式、保存方法、スコープ、ローテーション、ダッシュボード、所有権、ガバナンスを整備し、キーが漏えい、紛失、または所有者不在になった場合も、インシデントではなく影響を限定できる事象にとどめます。

このタスク全体は、OWASP の 2 つの指針（API Security Top 10 2023、API2 Broken Authentication）を軸に進めます。

• API キーが識別するのは呼び出し元のアプリケーションであり、ユーザーではありません。「OAuth は認証ではなく、API キーも認証ではない」が原則として明示されています。
• 機密性の高い操作で、キーを唯一の認証情報として使用するのは、スタイルの選択ではなく、明確に指摘されている弱点です。

メモリ（推奨、必須ではありません）：メモリをファイルに保存する場合は、developer-platform-context.md の使用を検討してください。別のメモリシステムを使用している場合は、そちらを利用してください。このファイルは参考用であり、厳格な要件ではありません。タスクごとにセクションを分けてください。完了したタスクは削除してください。タスクには日付を付け、一般的なプロジェクトのコンテキストには日付を付けないでください。2 つのタスク間で、インタビューの回答が異なる場合があります。

メモリ（推奨）：メモリをファイルに保存する場合は、developer-platform-context.md の使用を検討してください。別のメモリシステムを使用している場合は、そちらを利用してください。このファイルは参考用であり、必須要件ではありません。タスクごとにセクションを分けてください。完了したタスクは削除してください。タスクには日付を付け、一般的なプロジェクトのコンテキストには日付を付けないでください。2 つのタスク間で、インタビューの回答が異なる場合があります。

確認事項

設計を始める前に、以下を確認してください。回答によって後の手順が変わるためです。まとめて質問してください。これは戦術的な設計タスクであり、戦略に関するインタビューではありません。

1. 新規開発ですか、それとも既存システムの改修ですか？既存システムの改修の場合は、現在のキー形式、現在のキーの保存方法（平文、ハッシュ化、暗号化）、およその有効なキー数を尋ねてください。
2. キーを保持するのは誰ですか。試験的に利用する個人の開発者、共有の本番連携を運用するチーム、または無人のワークロード（CI、スケジュールされたジョブ、AI エージェント／MCP サーバー）ですか？（次のセクションを参照）
3. サードパーティ製アプリはユーザーに代わって操作しますか。それとも、利用者は常に自分自身としてのみ API を呼び出しますか？（キーと OAuth の境界を決める要素です）
4. 対象となるコンプライアンス要件はありますか。決済データやカード会員データ（PCI-DSS）、SOC 2 を求めるエンタープライズ顧客、それとも現時点ではどちらもありませんか？（手順 7 を参照）
5. プロダクトには、キーのスコープに再利用できる権限／RBAC システムがありますか？（スコープ設定の段階の優先順位に影響します。手順 3 を参照）
6. スケジュールと工数の上限はどうなっていますか。いつまでにリリースする必要がありますか。単発のセキュリティ強化ですか、それとも継続的に価値が高まるプラットフォーム資産の構築ですか。また、エンジニアリングにどれだけの時間を割けますか。利用者に見える移行にはどれだけのコストをかけられますか。保存方法とスコープ設定の選択肢は、必要な工数によって大きく異なります。回答に合わせて優先順位を見直してください。厳しいリリース期限がある場合は、低コストの段階（ハッシュのみの保存、環境ごとのキー分離）が優先されます。継続的に価値が高まる資産の構築が求められる場合は、後回しにされがちな項目（ワークロード ID、きめ細かなスコープ設定）が優先されます。

実行環境に永続メモリがある場合は、キー形式とプレフィックスの分類、保存方法の段階、スコープ設定の段階、猶予期間の既定値、所有権の階層、対象となるコンプライアンス要件など、設計の中核となる決定事項を保存してください。そうすれば、後の実行でローテーションのインシデント対応、退職者のアクセス権一斉削除、監査準備などを行う際に、設計を一から導き出さずに済みます。

所有権の階層

どのキーの保有者も、製品を購入した開発者またはマシンです。各階層で障害の起き方が異なるため、認証情報を誰が所有するかに基づいて設計を分けます。

• 個人開発者キー（GitHub PAT、OpenAI ユーザーキー）- 1 人のアカウントに紐づき、各キーは必ず 1 人の人間にたどり着きます。個人的な実験には適切なデフォルトですが、本番環境で実行した途端に負債となります。その人が退職すると使えなくなる（あるいは、さらに悪いことに使え続ける）ためです。
• チーム／組織キー（Stripe sk_org_、GitHub 組織承認済み PAT）- 影響範囲は広がりますが、個人キーにはないガバナンス層があります。組織管理者は発行前の承認を必須にでき、メンバーのキーを確認して失効させることができます。
• サービスアカウントキー（OpenAI サービスアカウント - 「システムアクセス向けに設計された疑似ユーザー」、Anthropic サービスアカウント、アプリ自体が所有する Shopify カスタムアプリトークン）- どの人間の雇用状況からも意図的に切り離されているため、本番環境の自動化は退職処理後も継続します。無人で実行するものには、これをデフォルトとして選択してください。

この 3 つの階層すべてを設計するか、どれを先送りするかを明示してください。個人キーしか発行しないプラットフォームは、本番環境を誰かの個人認証情報で実行すると暗黙のうちに決めたことになります。まさにステップ 6 が防ごうとしている事態です。

キーか OAuth か - まず境界を決める

静的キーは「どのアプリが呼び出しているか」に答えます。OAuth は「ユーザーが権限を付与したか、またその範囲はどこまでか」に答えます。プラットフォーム全体ではなく、サーフェスごとに選択してください。成熟したプラットフォームでは両方を使い、キーでアプリを識別してレート制限を行い、OAuth でユーザー委任またはコンプライアンス要件のある操作をカバーします。

• 静的キー：フローにユーザーが関与しない場合、サーバー間の呼び出し、サンドボックス、公開データまたは読み取り中心のデータ、呼び出し元単位のレート制限に使います。
• OAuth クライアントクレデンシャル：機密データを扱う組織間のマシン間通信に使います。短命（5〜60 分）でスコープが設定されたトークンなら、無期限に有効な文字列では構造上不可能な方法で、漏えいの影響を限定できます。
• その名のとおりのヒューリスティックを、両方向から示します。
  • 静的キーに有効期限、リクエスト単位のスコープ、きめ細かな失効機能を追加するのは OAuth の再発明です。本来の OAuth を採用してください。
  • サーバーが自身と通信するためにリダイレクト URI と同意画面を追加するのは、過剰設計です。
• 長期間有効なキーをブラウザーやその他の半信頼クライアントに決して渡さないでください。代わりに、サーバー側で短命のスコープ付きトークンを発行します（OpenAI の 1〜10 分のエフェメラルトークンがそのパターンです）。CI や AI エージェント／MCP のワークロードでは、ワークロード ID フェデレーション、つまり環境が自身を証明し、保存済みシークレットを一切使わない方式へと業界が移行しています。これは、漏えい時に公開される保存済みシークレット自体をなくせるためです。

答えが「サードパーティアプリには OAuth」の場合は、兄弟スキル samber/developer-platform-skills@oauth2-provider-design に引き継いでください（スコープの粒度、同意画面、トークンのライフサイクル、アプリの検証）。このスキルが扱うのは、判断と、キー側に関するすべてです。

ワークフロー

1. キーの形式とプレフィックスの方式を定義します。
2. ストレージモデルを選択します。
3. スコープ設定モデルを選択します。
4. ローテーションを設計します。
5. セルフサービスダッシュボードの動作を設計します。
6. 所有権を割り当て、退職処理と連携します。
7. コンプライアンスに関するライフサイクルガバナンスを導入します。

各ステップのセクションは以下に、上記の順序で記載しています。

1. キー形式とプレフィックス

• 各キーは、prefix_ ＋高エントロピーのランダムな本体＋チェックサムで構成します。プレフィックスには、キーの種類と環境（Stripe の sk_live_ ／ sk_test_ ／ rk_ ／ sk_org_）をエンコードします。チェックサムにより、データベースへの問い合わせを行わずにバリデーターが不正なキーを拒否でき、シークレットスキャナーがアラートを出す前にノイズを除外できます。
• エントロピーは最低でも 120 ビット（ランダム文字 32 文字以上）を確保します。GitHub のベンチマーク形式は、30 文字の Base62 本体（約 178.6 ビット）に 6 文字の CRC32 チェックサムを加えたものです。これは、以前の 16 進数のみのトークンが「SHA ハッシュのような他のエンコードデータと区別できず」、スキャンできなかったために、特別に選ばれました。このオーバーヘッドでトークンの長さは約 10 文字増えますが、導入してください。
• プレフィックス＋チェックサムの形式は、正式な登録の有無にかかわらず、追加の防御策として無料で導入できます。実際のキー漏えいインシデントによって連携作業の正当性が確認できたら、GitHub の Secret Scanning Partner Program にパターンを登録してください（6 段階の手順については、references/vendor-key-format-census.md を参照）。これにより、顧客のキーが公開リポジトリにプッシュされた際、顧客が気づく前に失効フローが開始されます。
• テスト／本番環境は、最初からプレフィックスにエンコードしてください。この分類体系が扱うテストモードの設計面は、兄弟プロジェクトの samber/developer-platform-skills@api-test-mode-design が担当します。この 2 つのスキルは、このプレフィックスの基盤を共有します。
• Webhook 署名シークレット（Stripe の whsec_）は API キーではありません。署名方式は兄弟プロジェクトの samber/developer-platform-skills@webhook-platform-design が扱います。ここで説明するパターンに従うのは、シークレットの保管、ローテーション、ダッシュボード上のライフサイクルのみです。

2. ストレージモデルを選択する

3 つのモデルを順位付けします。

• セキュリティ上の価値：ワークロード ID（キーを保存しない）> 復元不能なハッシュ > 復元可能な暗号化

• キー紛失時のサポートチケット削減効果：復元可能な暗号化 > 復元不能なハッシュ == ワークロード ID（同率：どちらもシークレットを再表示することはありません。どちらの場合も、キー紛失時は再発行します）

• 労力：ワークロード ID > 復元可能な暗号化 > 復元不能なハッシュ

• コンプライアンスコスト：復元可能な暗号化 > 復元不能なハッシュ == ワークロード ID。復元可能な段階だけが、監査人による確認対象となる仕組みを作ります。つまり、KMS キーの管理に加え、平文のシークレットを返す開示経路です。他の 2 つは開示可能な情報を何も公開しないため、レビューが増えず、同率となります。

• 効率：復元不能なハッシュ > 復元可能な暗号化 > ワークロード ID

• デフォルトの段階：復元不能なハッシュのみ。 作成時にキー全体を一度だけ表示し、保存するのはハッシュだけにします（Stripe、AWS、GitHub、OpenAI、Anthropic、Linear、Resend はいずれもこの方式を採用しています）。SHA-256 でハッシュ化します。これは機械生成シークレットで主流の選択肢であり、明確な理由があります。bcrypt／Argon2 はエントロピーの低い人間のパスワードを守るためのもので、GPU で毎秒約 210 億回の SHA-256 ハッシュを計算できたとしても、178 ビットのランダムキーを攻撃するのは現実的ではありません。低速ハッシュを支持する見解（多層防御、シークレットポリシーの統一）は、少数派ながら今も根強くあります。ただし、bcrypt の入力上限が 72 バイトであることから、「すべてを bcrypt にすればよい」という考えには問題があります。

• インデックスを設定した短い平文の key_prefix 列を保存し、O(1) で候補を検索できるようにします。最終確認ではハッシュを定数時間で比較します。単純な == ではタイミング情報が漏れる可能性があります。

• 復元可能な方式に移行するのは、利用者が日常的にキーを紛失し、データの重要度が低く、サポート負荷が最優先となる場合に限ります（Twilio、Supabase）。この場合は、KMS にキー暗号化キーを置いた AES-256-GCM を使用し、復号せずに検証できるよう、SHA-256 ハッシュも併せて保存します。平文での保存は禁止し、アプリケーション管理の暗号化キーも使いません。

• ワークロード ID は採用されにくい選択肢です。漏洩するものがないため最も安全ですが、フェデレーション基盤や環境ごとのアテステーションが必要で、最も手間がかかるため、効率の評価ではすべての段階で劣ります。それでも、利用者が CI システムや AI エージェント／MCP サーバーである場合は優先します。この分野では静的キーからの移行が積極的に進んでいます。

• 安全側に倒します。シークレットがない場合はサービスの起動時にクラッシュさせ、ハードコードされたデフォルト値にフォールバックさせてはいけません。dev-secret-key-123 のフォールバックは、本番環境でも実際のキーと同じように動作してしまいます。

• この順位付けはデフォルトであり、絶対的なルールではありません。質問 6 の回答と、ユーザーについて把握している情報に基づいて順位を見直してください。すでに KMS を運用しているプラットフォームなら、復元可能な方式をほぼ追加コストなしで導入できます。エージェントを中心とするプラットフォームでは、ワークロード ID を「昇格先」ではなくデフォルトとして扱うべきです。

スキーマと検索フローの詳細：references/storage-and-lookup-schema.md。

3. スコープモデルを選択する

スコープ設定は、キーによって確立されるアイデンティティに重ねる認可制御です。相互に補完する制御であり、代替手段ではありません。マシン間キーに関する明確なヒューリスティックは、「信頼できる社内サービス」という考え方よりも、常に小さなスコープを優先することです。チーム間の信頼はセキュリティ境界ではなく、強制可能な境界となるのはキー自体のスコープだけです。

アカウント全体で使う単一のキーは、明確に拒否してください。これは最低段階ではなく、アンチパターンです。SendGrid のフェイルオープンなデフォルト（作成時にスコープを省略すると Full Access になる）は、設計時に対策すべき例です。デフォルトは制限的にし、利用ログから利用側がより広い権限を必要としていると確認できた場合にのみ拡張します。

3 段階を順位付けすると、次のとおりです。

• 労力：リソース単位のきめ細かなスコープ設定 > キー単位の大まかなスコープ設定 > 環境ごとのキー分割

• 影響範囲の封じ込め：リソース単位のきめ細かなスコープ設定 > キー単位の大まかなスコープ設定 > 環境ごとのキー分割

• 効率：環境ごとのキー分割 > キー単位の大まかなスコープ設定 > リソース単位のきめ細かなスコープ設定

• デフォルトの段階 - 下位 2 段階を組み合わせて採用します：環境（dev/staging/production）ごとにサービス単位でキーを 1 つ用意し、粗く制限的なデフォルトのスコープセット（読み取りと書き込み、製品領域ごと）を設定します。どちらもおもにレビューとテストにかかる 1 日程度の作業で、組み合わせて適用できます。キーが漏えいしても、1 つの環境にある 1 つのサービスが、1 つの権限セットの範囲内で侵害されるだけです。

• コンプライアンス要件の対象となる場合、エンタープライズ顧客が要求する場合、または複数のチームが実質的に異なる権限を必要とするキーを利用する場合は、リソース単位のきめ細かなスコープ設定に引き上げます。この段階では、リソース単位の許可、きめ細かな権限、有効期限の必須設定を行います（GitHub の fine-grained PAT は、リソース所有者を 1 つに限定し、リポジトリを選択し、64 種類の権限を設け、有効期限を強制し、組織レベルの承認を求めます）。これは後回しにされがちな選択肢です。最も強力に影響範囲を封じ込められる一方、権限分類体系の整備には数か月単位の作業が必要で、その大半はチーム横断の分類方針の決定と利用側の移行に費やされます。そのため、上記のいずれかの条件によって引き上げられるまでは、効率性の評価で常に最下位になります。

• この順位付けはデフォルトであり、絶対的なルールではありません。質問 5 で順位を付け直します。既存の製品 RBAC システムをスコープ設定に再利用できる場合、きめ細かな設定をほぼ無償で実現できるため、労力の順位が逆転し、最適な選択肢も変わります。

• キーは、保管場所だけでなく、何を実行するかに基づいてすべて記録します。名前、利用するサービス、許可する操作と拒否する操作、所有チームを記載してください。ドキュメントがなく、有効期限もないキーは「見えないインフラとなり、チームの変更、アーキテクチャの変更、忘れられたインテグレーションを経ても動作し続けます」。スコープ設定と有効期限は対になった制御であり、独立したものではありません。

ベンダーごとのスコープ設定の仕組みについては、references/vendor-key-format-census.md を参照してください。

4. ローテーションの設計

ダウンタイムのないローテーションでは、猶予期間中、新旧のキーを同時に検証できる必要があります。重複期間がなければ、ローテーションはうまくいきません。

「キーをローテーションするとなると、すべての顧客が同じ日にインテグレーションを更新しなければなりません。だからローテーションしません。そうすると、漏えいが起きたとき、本番環境で午前3時にローテーションすることになります。」

• ローテーションは、単一のアトミックな「更新」操作として提供します。呼び出し側が古いキーの有効期限を選び、システムが新しいキーを作成して古いキーを期限切れに設定する処理を、1回の呼び出しで実行します。期限切れの設定を忘れる可能性のある、手動の2段階操作にはしません。
• 実績のある仕組みを取り入れます。
  • Stripeの更新では、2要素認証のもと、最大7日間は両方のキーが有効です（「Now」を選ぶと即時に無効化されます）。
  • AWS IAMでは、各ユーザーのアクティブなアクセスキーを最大2つに制限しています。これにより、キーが際限なく増えるのを防ぎ、古いキーと新しいキーの重複期間を設けることになります。また、get-access-key-last-used でトラフィックがゼロであることを確認するまで、削除できない仕組みになっています。
• シナリオ別の猶予期間のデフォルト：
  • 定期的なローテーション：デプロイの頻度に応じて24時間から7日間。
  • 侵害が確認された場合や利用者のアクセス終了時：猶予期間はゼロとし、直ちに無効化してダウンタイムを受け入れます。
  • エージェントのフリートやキューに入ったワークロード：人間向けのデフォルトより長くします。
• これらはインタビュー時に調整する実務上の慣例であり、標準ではありません。普遍的なローテーション頻度は存在せず、PCI-DSS 4.0も明示的に頻度を指定していません（手順7を参照）。
• 運用上の不変条件は2つです。最終使用状況のテレメトリでトラフィックがゼロになったことを確認する前に、古いキーを削除しないこと。また、古いキーの失効をスケジュールせずに新しいキーを作成しないことです。後者だけを行うと、ローテーションではなく攻撃対象領域が広がってしまいます。
• 侵害がなくてもローテーションは重要です。GitGuardianによると、2022年に漏えいした有効なシークレットの64％は、その数年後も有効で悪用可能な状態でした。

ベンダーごとの仕組みや頻度の表を含む、詳細な実行手順書はこちらです：references/rotation-runbook.md。

5. セルフサービスダッシュボードの動作を設計する

セルフサービスとは、サポートチケットを起票せずに完了できる次の4つの操作を指します。

• サインアップする。
• キーを作成する。
• キーをローテーションする。
• 侵害されたキーを無効化する。

いずれか1つでも欠けているダッシュボードは、その操作について「サポートへの逃げ道付きセルフサービス」です。兄弟スキルである samber/developer-platform-skills@developer-portal-design は、このダッシュボードをポータルのどこに配置するかを担当します。このスキルは、ダッシュボードが何をするかを担当します。

• キーごとの一覧表示：人が読めるラベル（キーの値とは別のもの。「CI pipeline, staging」など）、作成日、最終使用日時、ステータスバッジ（有効／無効／期限切れ間近）、および直接操作できるローテーション／無効化アクション。
• 作成後は、どこでもキーをマスクします。最初と最後の数文字のみを表示します（Anthropicは partial_key_hint のみを返します）。完全なキーが表示されるのは作成モーダル内の1回だけとし、再取得できないデフォルトの段階では、その後一切表示しません。
• 認証チェックの成功後に、last_used_at を非同期で更新し、完了を待たずに処理します。テレメトリのためにリクエストの処理をブロックしてはいけません。最終使用日時が古いことを確認できれば、「このキーを無効化する」ことや「ログで必要性が確認できた場合にのみスコープを広げる」ことが、建前ではなく実行可能になります。
• キーごとの使用状況（従量課金の場合は利用額も）は、最終使用日時とは別の画面で表示します。一方は「このキーはまだ使われているか」、もう一方は「このキーは何をしているか／いくらかかっているか」に答えるものであり、成熟したダッシュボードには両方が必要です。
• キーシステムが出力する認証エラー（期限切れ、失効、スコープ不足）は、プラットフォームのエラー表示仕様に従います。認証に失敗するキーには401、キーは有効でもスコープが不足している場合は403を返します。兄弟スキルである samber/developer-platform-skills@api-error-design が、これらのセマンティクスを担当します。

6. 所有権を割り当て、オフボーディングを組み込む

所有権は、ダッシュボードで明示すべきライフサイクル上の判断事項です。ユーザー所有のキーと組織所有のキーでは、問題が正反対の方向に発生するためです（所有権の階層を参照）。

• 本番環境と自動化には、サービスアカウントまたは組織所有のキーをデフォルトで使用します。個人用のキーは、個人的な実験用に限定します。サービスアカウントが存在する設計上の理由は、認証情報の有効性を雇用状況から切り離すことです。これにより、自動化が気づかないうちに停止したり、退職した従業員の有効な個人用キーで動き続けたりすることを防ぎます。
• 組織管理者が、特定のユーザーが作成した、または閲覧できるすべてのキーをフィルタリングして表示できるようにします。これがないと、以下のオフボーディング手順を実行できません。
• オフボーディング手順は、退職者が出るたびに実行します。退職者が所有するキーをすべて洗い出して、それぞれを失効させ（猶予期間なし。これはステップ 4 の侵害シナリオです）、アクセス権を持っていた共有認証情報をローテーションし、監査証跡のために各操作を記録します（ステップ 7）。
• 個人用キーで稼働している本番環境のインテグレーションが見つかった場合は、継続的なインシデントとして扱います。次の退職時ではなく、計画的なローテーションでサービスアカウントに移行します。

7. コンプライアンスに準拠したライフサイクルガバナンスを導入する

監査人が確認するのは、ツールではなくポリシーと証跡です。まず質問 4 を確認してください。カード会員データを扱う場合、PCI-DSS が直接適用されます。プラットフォーム自体のリスクプロファイルからは必要でない場合でも、エンタープライズ顧客は調達プロセスを通じて SOC 2 を求めます。

• SOC 2（CC7.2、C1.2）：キーのライフサイクル全体（プロビジョニング、ローテーション、失効、破棄）を対象とする、文書化されたポリシーに加え、そのポリシーが実際に運用されている証跡が必要です。証跡には、キーイベントログ、定期的なアクセスレビュー、承認記録が含まれます。Type II では、3〜12 か月の観察期間を通して、これらの統制が一貫して運用されている必要があります。そのため、監査の直前の週にポリシーを導入しても、そもそも要件を満たせません。初日から証跡の生成を自動化してください。
• PCI-DSS 4.0/4.0.1、要件 8.6.3（2025 年 4 月 1 日から必須）：誤解を正してください。PCI は固定のローテーション間隔を義務付けていません。文書化されたターゲットリスク分析（要件 12.3.1）に基づいて頻度を正当化することと、スケジュールに関係なく、侵害の疑いまたは確認があった場合に即座にローテーションすることを求めています。これとは別に、API トランザクションの改ざん防止ログを 12 か月間保持し、直近の 3 か月分をすぐにアクセスできる状態にする必要があります。
• コンプライアンス上の要請があるからこそ、成熟したプラットフォームはこれらをポリシーではなく製品機能として提供します。必須の有効期限、期限切れの警告と強制ローテーションのリマインダー、作成・使用・ローテーション・失効のすべてを対象とする、実行者・日時・理由を含む監査ログ、そしてサービスアカウントそのものです。これらはそれぞれ、監査人が求める証跡を生成します。

フレームワーク別の全マトリックスはこちらです：references/compliance-lifecycle-matrix.md。

障害につながるパターン

OWASP API2 に基づくアンチパターンのチェックリストです。それぞれが監査で直接指摘される事項です。

• 機密性の高い操作の唯一の認証情報として API キーを使う、またはキーによる識別をユーザー認証と混同する。
• 保存時にキーを平文で保管する、または KMS が保持するキーを使わずに復号可能な暗号化を行う。
• シークレットがない場合に起動時にクラッシュせず、ハードコードされたデフォルト値にフォールバックする。
• スコープのデフォルト値がフェイルオープンになっている。作成時にスコープを省略すると、フルアクセスが付与される。
• キー検証エンドポイントやキー作成エンドポイントにレート制限やブルートフォース対策がない（ログインエンドポイントとして扱うこと）。
• 認証処理で、定時間ではないハッシュ比較を行う。
• 所有者もスコープの説明も有効期限もないキー。誰にも把握されていないインフラストラクチャです。
• 最終使用のテレメトリがゼロになる前に古いキーを削除する（ローテーションによる障害）、または古いキーの失効を予定せずに新しいキーを作成する（攻撃対象領域の拡大）。
• 退職した従業員の個人用キーで稼働する本番環境のインテグレーション。
• Webhook 署名シークレットを API キーのように管理する、またはその逆。

測定

ゲート — すべてに合格するまで設計を繰り返します。

• ストレージ：保存されるキーの100％がハッシュ化（復元不可能な段階）またはKMSで暗号化（復元可能な段階）されていること。保存時に平文のキーが一切存在しないことを、ポリシーの表明ではなくスキーマ監査で検証します。
• インベントリ：有効なキーすべてに、所有者、スコープ、有効期限または文書化された適用除外が設定されていること。
• ローテーション：ランブックが存在し、エンドツーエンドで少なくとも一度実施されていること。実際のキーをダウンタイムゼロでローテーションし、削除前に旧キーへのトラフィックがゼロであることを確認します。
• セルフサービス：4つの操作（サインアップ、作成、ローテーション、失効）のすべてを、サポートチケットなしで完了できること。

初月から傾向を測定し、改善を目指します（業界標準のしきい値はありません）：漏えいの検知から失効までの時間、最終使用から90日を超えた有効なキーの割合、個人キーに対するサービスアカウントキーでの本番トラフィックの割合。

呼び出し例

• 「公開APIのAPIキーシステムを設計してください。現在はアカウントごとに1つのUUIDを発行し、Postgresに平文で保存しています。」
• 「漏えいしたキーをシークレットスキャナーで検知できるよう、キーの形式とプレフィックスの方式を定義してください。」
• 「エンタープライズ顧客からAPIキーのローテーション方法について質問されています。ダウンタイムゼロのローテーションフローと、そのためのダッシュボードUXを設計してください。」
• 「エンジニアが退職したばかりで、連携の半分がその人の作成したキーで動いています。所有権モデルを改善してください。」

参考資料

• samber/developer-platform-skills@bulk-data-sharing-design - 一括ファイル／レイク配信向けの受信者ごとのストレージ認証情報は、このスキルが扱うAPIキーとは別のライフサイクルに従います。
• references/vendor-key-format-census.md - 7社にわたるプレフィックスの分類、GitHubのエントロピー計算、Secret Scanning Partner Programの6段階、ベンダーごとのスコープ設定の仕組みと所有権モデル。
• references/storage-and-lookup-schema.md - キーテーブルのスキーマ、プレフィックスベースの検索フロー、ハッシュ化の判断に関する詳細、復元可能なモデルのストレージ。
• references/rotation-runbook.md - ダウンタイムゼロのローテーションを実施したランブック、Stripe／AWS／Azureの仕組み、猶予期間の周期表、オフボーディングの手順。
• references/compliance-lifecycle-matrix.md - SOC 2およびPCI-DSS 4.0の要件を、キーのライフサイクル管理と、それによって必要となる製品機能に対応付けたもの。