CI/CDからクラウドへの認証方式を比較する:長期キー、Environment保護、OIDC、外部シークレット管理の選び方

比較に使う5つの判断基準

CI/CDの認証方式は「どれが安全か」だけでは選べません。本記事では次の5つの観点で比較します。どれを重視するかで、向く方式が変わります。

漏えい時の被害範囲は、認証情報が外部に出たとき、攻撃者が何を、どれだけの期間操作できるかで決まります。権限の広さと有効期間の掛け算で考えます。有効期限とローテーションの手間は、認証情報を定期的に作り直す作業が人手に残るかどうかです。手作業が残る方式では、ローテーションは忘れられやすくなります。対応クラウドやツールの制約は、接続先がその方式に対応しているかどうかです。どれほど優れた方式でも、接続先が非対応なら使えません。導入・運用コストには、初期設定の難しさ、追加の基盤の運用、従量課金の費用が含まれます。監査ログの追いやすさは、ある操作が「どのリポジトリの、どのワークフローの、どの実行から」行われたかを後から特定できるかどうかです。インシデント対応の速さに直結します。

4方式の比較表

長期アクセスキーをリポジトリシークレットに置く方式

クラウドのIAMユーザーなどで発行したアクセスキーを、GitHubのリポジトリシークレットに登録してワークフローから参照する方式です。設定が簡単で、APIキー認証しか提供しない外部サービスにも使えます。

弱点は、鍵が漏れると失効させるまで誰でも使える点です。リポジトリへの書き込み権限を持つ人は、ワークフローを書き換えてシークレットを参照できます。サードパーティ製アクションが侵害された場合も、そのアクションを使うジョブのシークレットが危険にさらされます。執筆時点の代表例として、2025年3月にtj-actions/changed-filesが改ざんされ、ワークフローのログにシークレットが出力された事案(CVE-2025-30066)があります。また、クラウド側のログには「どのキーが使われたか」は残りますが、「どのワークフロー実行から使われたか」までは分かりません。

この方式を使い続ける場合は、キーの権限を最小限にし、ローテーション周期を決めて担当者を明確にします。アクションはタグではなくコミットSHAで固定します。

Environment保護付きシークレット

GitHubのEnvironment(デプロイ先ごとの設定単位)にシークレットを置き、保護ルールを付ける方式です。保護ルールには、承認者のレビュー必須化、待機時間、デプロイ可能なブランチやタグの制限があります。たとえば本番用のキーを「mainブランチから、承認を経たジョブだけ」が読めるように絞れます。

弱点は、鍵自体は長期キーのままという点です。利用条件を絞っても、一度漏れた鍵の被害範囲は変わりません。ローテーションも手作業のままです。さらに、プライベートリポジトリで使える保護ルールはGitHubの契約プランによって異なります。導入前にGitHubの公式ドキュメントで自社のプランの対応状況を確認してください。

OIDCによる短期トークン連携

OIDC(OpenID Connect)は、IDトークンを使って身元を証明する標準規格です。GitHub Actionsはジョブごとに署名付きのIDトークンを発行できます。クラウド側はそのトークンを検証し、短時間だけ有効な認証情報を返します。AWSのIAM OIDCプロバイダー、Microsoft Entra IDのワークロードIDフェデレーション、Google CloudのWorkload Identity Federationが対応しています。執筆時点ではPyPIやnpmのTrusted Publishingなど、パッケージ公開の場面でも採用が広がっています。ワークフロー側では次の権限指定が必要です。

permissions:
  id-token: write
  contents: read

長所は、リポジトリに保管する秘密情報がなくなることです。ローテーションも不要になります。トークンにはsub(リポジトリ名、ブランチ、Environment名などを含む識別子)が入るため、クラウド側の監査ログから呼び出し元を特定しやすくなります。

弱点は信頼条件の設計にあります。クラウド側でsubやaudの条件をワイルドカードで広く書くと、意図しない別リポジトリやブランチからもロールを引き受けられます。条件は「特定リポジトリの特定ブランチ」や「特定Environment」まで絞ってください。また、発行された短期認証情報も、有効期間内に漏れれば使われます。セッション時間は必要最小限にします。非対応のSaaSには使えないため、他の方式との併用が前提になります。詳しくはGitHubのOIDC解説を参照してください。

外部シークレット管理基盤(Vault・クラウドのSecrets Manager)

HashiCorp VaultやAWS Secrets Manager、Azure Key Vault、Google CloudのSecret Managerにシークレットを集約し、CIは実行時に取り出す方式です。CI以外のアプリケーションやサーバーと同じ基盤で管理でき、取得のたびに基盤側へ記録が残ります。Vaultの動的シークレット機能を使えば、データベースの認証情報などを要求のたびに発行し、短時間で失効させられます。Secrets Managerにも自動ローテーションの仕組みがあります。

弱点は二つあります。一つは、基盤にアクセスするための認証が別途必要な点です。ここに長期トークンを置くと、問題を移しただけになります。基盤への認証にはOIDCを組み合わせるのが基本です。もう一つはコストです。Vaultを自前で運用するなら、可用性やバックアップ、バージョンアップの体制が要ります。クラウドのシークレット管理サービスは、シークレット数やAPI呼び出し数に応じた課金が発生します。

チーム規模と環境で分ける選び方

個人や数人のチームで、AWS・Azure・Google Cloudのいずれかに配備している場合は、OIDCを第一候補にします。追加費用がかからず、ローテーション作業もなくなります。本番デプロイだけはEnvironmentと組み合わせ、信頼条件をそのEnvironmentに絞ると効果が大きくなります。

接続先がAPIキー認証しか提供しないSaaSの場合は、長期キーを避けられません。この場合はEnvironment保護付きシークレットに置き、キーの権限を絞り、ローテーション周期を運用ルールとして決めます。

複数のクラウドやオンプレミスにまたがり、CI以外でも同じ秘密情報を使う中規模以上の組織では、外部シークレット管理基盤が向きます。基盤を運用する担当者を確保できることが条件です。確保できない段階で導入すると、基盤自体が管理されない資産になります。

オンプレミスの古い製品などOIDCも外部基盤も使えない環境では、長期キーを残すことになります。その場合は、キーを使えるワークフローとブランチをEnvironmentで限定し、ログ監視で補います。

移行に着手するときの確認順序

まず、現在リポジトリや組織に登録されているシークレットを棚卸しし、接続先ごとにOIDC対応の有無を確認します。対応している接続先から順にOIDCへ移し、移行後は旧キーを無効化して削除します。キーを残したままにすると、移行の効果はありません。非対応の接続先は、Environment保護と権限の最小化で守ります。複数チームで同じ秘密情報を共有している実態が見えたら、外部シークレット管理基盤の導入を検討する時期です。各クラウドの対応状況や仕様は更新されるため、設定前に各社の公式ドキュメントを確認してください。