GitHub Actions OIDC実践 2026, Custom Claimsで作るABAC型マルチクラウドデプロイ
2026年4月のGitHub Actionsまわりの更新で、CI認証は「鍵をなくす」段階から「条件で厳密に許可する」段階へ進みました。多くのチームはすでにOIDC連携で静的キーを排除していますが、実運用ではまだ事故が起きます。理由はシンプルで、許可条件が粗いからです。
同一リポジトリ内の任意ワークフローが本番権限を取得できる状態だと、1つの依存関係侵害やワークフロー改ざんで本番到達が成立します。ここを防ぐには、OIDCをABAC（属性ベースアクセス制御）として扱う必要があります。
今回の変化が意味すること
直近の改善は派手ではありませんが、運用上の価値が大きいです。
- OIDCトークンのコンテキスト属性を使った厳密な判定
- ジョブ/サービスの構成制御の改善
- 環境ゲートとワークフロー経路を連動させる設計のしやすさ
これにより「誰が」「どのワークフロー経路で」「どの環境へ」変更しようとしているかを、IAM側で明確に判定できます。
参考: https://github.blog/changelog/
RBAC依存からABACへ
従来のCI権限は、実質的にこうなりがちでした。
mainブランチからの実行なら本番ロール許可- リポジトリ単位で広い書き込み権限
ABACでは次の属性を組み合わせます。
repositoryrefjob_workflow_refenvironmentaud
例えば「deploy-prod.yml という承認済み再利用ワークフローから、production 環境ゲート通過後に、main 上で実行された場合のみ許可」という条件を作れます。これで偶発的な横流れをほぼ止められます。
AWSでの具体実装パターン
本番デプロイを想定した最小パターンです。
deploy-prod.ymlを再利用ワークフローとして分離production環境に必須承認を設定- IAMロールの信頼ポリシーで
job_workflow_refとenvironmentを厳密一致 - 権限はデプロイに必要なAPIへ限定（例: ECS更新, SSM読取）
これだけで「同じリポジトリ内の別ワークフローから本番権限を借りる」経路を遮断できます。
GCP/Azureでも同じ設計思想
- GCP Workload Identity Poolはクレーム条件で細粒度制御が可能
- Azure Federated Credentialsもsubject/audienceを狭く保てる
クラウド固有の書き方は違っても、設計原則は共通です。まず組織としてクレーム命名規約を決め、それを各クラウドへ写経する方が運用コストは下がります。
3層パイプライン設計
運用しやすいのは次の分離です。
- Tier1: Build（アーティファクト生成のみ, クラウド書き込みなし）
- Tier2: Staging（非本番限定ロール）
- Tier3: Production（人手承認 + 最厳密ABAC）
特に重要なのは、BuildジョブとProduction権限を物理的に分離することです。単一ワークフローに全権限を載せる構成は、事故時の被害範囲が広すぎます。
継続運用のガードレール
- クレーム契約を
ci-claims-v1としてバージョン管理 - ワークフロー変更PRでIAM条件の差分レビューを必須化
- 許可テストだけでなく拒否テスト（ネガティブテスト）をCI化
- 想定外条件でトークン受理されたら即アラート
「設定したら終わり」ではなく、アクセス制御自体をソフトウェアとして扱うことが鍵です。
30日で進める導入手順
1週目: 既存ワークフローの棚卸し（どれがクラウド書き込みを持つか）
2週目: クレーム設計と命名規約を定義、本番経路を再利用ワークフローへ分離
3週目: 1クラウドでABAC適用、CIにポリシー検証を追加
4週目: 残りクラウドへ展開、侵害想定の机上演習を実施
まとめ
OIDCは「秘密情報を減らす」ための仕組みです。ABACは「短命トークンでも誤用させない」ための仕組みです。2026年のCIセキュリティでは、この2つをセットで設計するのが実務上の標準になりつつあります。早めにクレーム中心設計へ移行したチームほど、例外運用が減り、レビューも速くなります。
