長期クレデンシャルか動的発行か――サービスアカウントの払い出し設計とworkload identity境界

サービスアカウントの払い出し設計で最初に問うべきは「この実行基盤はIDプロバイダーを持つか」という一点です。workload identityへ移行できる環境では長期クレデンシャルを根絶し、移行できない領域には有効期限とローテーションを設計する――この二段構えが認証基盤の設計判断の軸になります。判断を先送りにするほどキーの散在が進み、インシデントのリスクが積み上がります。実行基盤ごとに方式を分類し、長期キーが許容される領域を最小化することが設計の目標です。

長期クレデンシャルが残存する理由と動的発行切替の判断基準

長期キーが根絶されない構造的要因

長期クレデンシャルが消えない理由は「発行コストの低さ」と「廃止ワークフローの欠如」にあります。一度発行したキーは設定ファイル・CI/CDパイプライン・外部SaaS連携に埋め込まれ、担当者の異動後も誰も気づかないまま有効であり続けます。特に外部SaaSとのWebhook連携や、クラウドプロバイダーの外からAPIを呼び出す用途では、workload identityの前提条件を満たせないため構造的に長期キーが残ります。「必要になったら発行する」という運用が根付くと、キーは一方的に増殖します。

動的発行への切替判断フレーム

切替の判断は「実行基盤がIDプロバイダーを持つか」で始まります。GKE・EKS・AKS上のワークロードはネイティブでworkload identityに対応し、GitHub ActionsやGitLab CI/CDも2022年以降OIDCトークン発行に対応しています。これらの基盤を利用していれば、長期キーを残す設計上の根拠はほぼなくなります。オンプレVM・ベアメタル・IDプロバイダーを持たない実行環境では、動的発行の前提が成立しないため、長期キーの管理品質を高める設計が現実的な選択肢です。判断の根拠は「基盤の種類」であり、「使い慣れているかどうか」ではありません。

判断の先送りが生むリスク

「後で移行する」という先送りが最も危険なアンチパターンです。発行から6ヶ月以上経過したキーがインシデントの起点になるという傾向は、各社のセキュリティ報告書で共通して指摘されています。棚卸しポリシーがない環境では、キー数は環境数に比例して増殖します。想定例として、100台規模のVM環境では、サービスアカウントキーが30〜50個単位で散在し、全体の把握だけで数日の工数がかかる状況が十分に考えられます。移行判断を先送りにするコストは、当初の想定よりも常に大きくなります。

長期キー・OIDC・workload identityの比較表

3方式の技術特性

3方式は「クレデンシャルの寿命」「実行基盤の前提条件」「漏洩時リスク」の軸で性質が大きく異なります。長期キーはどの環境でも使えますが、漏洩時の影響範囲が広く、棚卸しコストが永続的に発生します。OIDCは短命なトークンを自動取得できますが、OIDCプロバイダーの可用性に依存します。workload identityはクレデンシャルの明示的な管理が不要になり、漏洩リスクを構造的に排除できます。3方式を同一の基準で比較せず、実行基盤ごとに適した方式を割り当てることが設計の基本です。

方式	有効期限	実行基盤の前提	漏洩時リスク	管理コスト	主な用途
長期キー（サービスアカウントJSONキー等）	無期限（手動失効まで）	不問（どこでも利用可）	高（即時悪用可能）	高（棚卸し・ローテーション必須）	外部SaaS連携・IDプロバイダー非対応環境
OIDC連携（短命トークン）	数分〜1時間（自動更新）	OIDCプロバイダーが必要（GitHub Actions等）	低（期限切れで自動無効化）	中（信頼関係の設定・更新）	CI/CD・GitOps・外部IdP連携
Workload Identity	自動（数分単位でローテーション）	対応マネージド基盤必須（GKE/EKS等）	最低（クレデンシャル自体が不在）	最低（プロバイダーが管理）	コンテナ・マネージドKubernetes

選定の優先順位と移行コストの実態

選定の優先順位は「workload identity → OIDC → 長期キー」の順で検討します。GKEやEKSを利用しているならworkload identityを第一選択にします。CI/CDはGitHub ActionsやGitLab CI/CDのOIDC対応を確認します。長期キーを選択するのは、他の2方式が技術的に成立しない場合のみとし、その場合は後述するローテーション設計を必ず伴わせます。想定例として、50本以上のCI/CDパイプラインにハードコードされた長期キーをOIDC方式に切り替える場合、調査・テスト・段階的切替を含めると2〜4週間の工数が見込まれます。キーが複数の場所に転記されている環境では、棚卸しフェーズだけで全体の30〜40%の工数を占めることが一般的な傾向です。

workload identityを使える条件と使えない条件の整理

使える条件：実行基盤とIDプロバイダーの要件

workload identityが機能するには、実行環境がクラウドプロバイダーの認証エンドポイントと通信できることと、実行基盤がIDトークンを発行できることの2点が必要です。GKEはWorkload Identity Poolに直接統合でき、EKSはIAM Roles for Service Accounts（IRSA）でPodごとにIAMロールをバインドできます。各マネージドKubernetesでは、Podの実行時にサービスアカウントのトークンが自動的にマウントされ、クラウドAPI呼び出し時に透過的に交換されます。実行基盤がこの仕組みに対応しているかどうかが、設計判断の分岐点です。

使えない条件のパターン

次のパターンではworkload identityが成立しないため、長期キーまたは別の認証方式を設計する必要があります。オンプレVMやベアメタルサーバーでクラウドSDKを実行する場合はIDトークンの発行元がないため不可です。クラウドAPIを外部SaaS（監視ツール・ログ収集サービスなど）から呼び出す場合も、そのSaaSがIDプロバイダーとして登録されていない限り不可です。古いエージェント型ミドルウェアで認証プロセスを制御できない場合も同様で、これらは「技術的に使えない」領域として明示的に台帳に記録します。

適用可否の確認チェックリスト

設計時に以下のチェックリストで実行基盤を評価します。すべて「はい」であればworkload identityを第一選択にできます。

• 実行基盤はGKE・EKS・AKSなどのマネージドKubernetes、またはGitHub Actions・GitLab CI/CDなどのOIDC対応CI/CDか
• 実行環境からクラウドプロバイダーの認証エンドポイントに疎通できるか
• デプロイ時にサービスアカウントやIAMロールをPod・ジョブ単位でバインドできる設計になっているか
• IDトークンの発行をミドルウェアまたはクラウド基盤に委ねられる構成になっているか

1つでも「いいえ」が含まれる実行環境では、その理由を台帳に記録した上でOIDCまたは長期キーの管理設計に移行します。「条件を満たさない理由」の記録が、後からの棚卸しや移行判断の根拠になります。

クレデンシャルのローテーション方式と有効期限設計

有効期限の設計方針

長期キーを使わざるを得ない領域では、有効期限と強制ローテーション周期を設計します。有効期限の目安は最長90日・推奨30日です。GCPのサービスアカウントキーはデフォルトで有効期限が設定されないため、組織ポリシー（constraints/iam.serviceAccountKeyExpiryHours）でキー有効期限を強制する設定も有効な設計です。ただし、有効期限を短くするほど更新頻度が増えるため、自動ローテーションの仕組みを先に整備せずに期限だけ短縮すると運用負荷が激増します。「期限の長さ」よりも「期限内に自動更新できる仕組みがあるか」を先に確認する順番で進めます。

自動ローテーションの設計パターン

自動ローテーションの基本設計は「新キー発行 → 配布 → 旧キー失効」の3ステップです。切替中のサービス断を防ぐため、新旧キーが並存するオーバーラップ期間を設けます。Secret ManagerやHashiCorp Vaultを使う場合は、シークレットのバージョン管理と配布の仕組みを設計します。Kubernetesへの配布はExternal Secrets Operatorを使ったシークレット同期が代表的です。GitHub ActionsやGitLab CI/CDのシークレットストアであれば、APIを通じた自動更新スクリプトでパイプラインを止めずに切り替えられます。ローテーションロジックをアプリケーション層に持ち込まないことが設計上の重要なポイントです。

フライング失効アンチパターン

よくあるつまずきとして、新キーの配布が完了する前に旧キーを失効させる「フライング失効」があります。これはサービス断に直結する典型的なアンチパターンです。猶予期間は最低でも24時間以上確保し、配布完了を確認してから旧キーを失効させるシーケンスを自動化します。失敗検知・アラート・手動ロールバック手順もあらかじめ定義しておくことが必須です。自動化の信頼性が担保できない段階では、手動承認ステップを挟む設計にして、段階的に自動化を拡張します。

払い出し申請・廃止ワークフローの設計

申請フローに含めるべき情報設計

払い出し申請フローには「用途（接続先サービス・APIスコープ）」「実行基盤（IDプロバイダーの有無）」「有効期限（期限なし申請を禁止）」「承認者と技術責任者の区別」の4項目を最低限含めます。用途が不明確なキーは後から棚卸しができないため、申請時に用途の記録を必須化します。実行基盤の確認欄でIDプロバイダーの利用可否を確認させることで、申請段階でworkload identityへの誘導も組み込めます。フォーム項目の設計が、後から棚卸しや廃止判断の精度を左右します。

廃止ワークフローの設計

廃止設計が甘いと未使用キーが延々と残存します。廃止トリガーは「担当者の異動・退職」「システムの廃止・移行」「定期棚卸しによる未使用検知」の3パターンを明示します。廃止の実行は「失効（Revoke）→ 削除」の2段階とし、失効から削除まで最低7日の猶予を設けることで誤廃止時の復旧を可能にします。廃止申請も払い出し申請と同じチケットシステムで管理し、申請なしの直接削除を禁止する運用設計が望ましいです。廃止手順の欠如が、長期キーの残存を生む最大の構造的要因になります。

棚卸しの自動化設計

手動棚卸しは定期的に行き詰まります。クラウドプロバイダーのAPIでサービスアカウントキーの最終使用日時を定期取得し、アラートを上げる仕組みを設計します。「90日間未使用のキーを失効候補としてリスト化」「180日間未使用のキーをチケットに自動起票」のようなルールを自動化すると、棚卸し工数を大幅に削減できます。想定例として、この自動化を導入することで、20人チームの四半期棚卸しを1〜2日から数時間に圧縮することが見込まれます。自動検知の仕組みなしに運用する場合、棚卸しは形骸化します。

クラウドとオンプレ混在時のfederation設計

federation構成の前提条件

Workload Identity Federationは、外部のIDプロバイダー（AWS STS・Azure AD・Kubernetes・GitLabなど）が発行したトークンをクラウドが信頼する仕組みです。オンプレ基盤からクラウドAPIを呼び出す場合、オンプレ側にOIDCプロバイダーを立てることでfederationを成立させられます。代表的なパターンとして、オンプレKubernetesクラスタをOIDCプロバイダーとして登録する方法があります。この構成ではkube-apiserverのOIDC設定とエンドポイントの外部公開可否が前提条件になるため、既存クラスタへの後付けは再起動を伴う点を設計段階で確認します。

信頼境界の設計と最小権限

federationでは「どのIDプロバイダーからのトークンを、どの条件で信頼するか」という信頼境界の設計が核心です。条件が広すぎると特定の実行基盤以外からも信頼されてしまうため、Attribute Condition（例：attribute.repository や attribute.namespace の指定）を必ず設定します。「任意のトークンを信頼する」設定はfederation全体がバイパスされるリスクを生みます。これはworkload identity設計でよくある致命的なアンチパターンであり、信頼条件の絞り込みは設計レビューの必須チェック項目です。

オンプレID基盤との統合パターン選定

オンプレ環境にActive DirectoryやLDAPが存在する場合、SAML/OIDCブリッジ経由でWorkload Identity Poolに接続する構成が選択肢に入ります。ただし、ブリッジ層（ADFS・Dex・Keycloakなど）の可用性がクラウドAPIアクセスの依存点になるため、SLA設計とフェイルオーバー設計を先に確認します。オンプレID基盤の管理コストが高い場合は、VMインスタンスへのサービスアカウント直接アタッチ（Instance Metadata Service経由）を使う方がシンプルで安全な設計になります。複雑な統合より、シンプルな構成で長期キーの必要領域を絞る判断の方が現実的なケースも多いです。

インシデント時のクレデンシャル無効化手順設計

無効化フローの事前設計

インシデントが発生してから手順を考えるのでは遅く、無効化手順は事前に設計・文書化・演習まで済ませておく必要があります。設計すべき手順は「漏洩を疑ったキーの即時失効 → 影響範囲の特定 → 代替クレデンシャルの発行・配布 → 事後調査」の順です。特に「即時失効」の操作は、権限を持つ担当者が休日・夜間でも実行できる体制とアクセス経路を設計しておくことが重要です。Runbookはインシデント管理ツールやWikiに格納し、年に1回以上の手順確認で陳腐化を防ぎます。

影響範囲の特定設計

インシデント時に最も時間がかかるのは「このキーがどこで使われているか」の特定です。申請フローで記録した用途情報が台帳として整備されていれば、影響サービスの特定は短時間で終わります。台帳がない場合はクラウドプロバイダーの監査ログ（Cloud Audit Logs・CloudTrail・Activity Logなど）の時系列解析が必要になりますが、ログ保存期間が短いと解析できないケースもあります。監査ログは最低90日分を保存する設計にしておくことが、インシデント対応の前提条件になります。

事後の棚卸しと再発防止設計

インシデント後に見落とされがちなのが、同類キーの一斉棚卸しです。1件の漏洩が発覚したら、同じ発行パターン・同じ用途で発行されたキーが他にも存在する可能性を疑います。インシデントをトリガーに「同条件キーの全件棚卸し → 不要キーの失効 → 申請フローの見直し」まで行うことで再発防止につながります。キーを失効させるだけで終わると、同じ構造的問題から次のインシデントが生まれます。インシデントの原因が「廃止手順がなかった」「棚卸し頻度が低かった」といった設計上の欠陥であれば、その設計自体を修正することが根本的な対処です。