GitHub Actions OIDC × Repository Custom Properties 実践設計：安全なデプロイ信頼連鎖を作る

変化の本質：CIの身元情報に“業務文脈”が入る

GitHub ActionsのOIDCトークンで、repository custom propertiesをクレームに使える流れは、単なる便利機能ではありません。これまでの「リポジトリ名ベースの雑な許可」から、業務文脈を含むデプロイ認可へ移行できる転換点です。

CIは機械IDを持っていても、データ機密度やサービス重要度といった判断材料をIAMに渡せないことが多く、結果として過剰権限や属人運用が起きがちでした。

従来方式がスケールしない理由

よくある旧来パターンは次の通りです。

repo-name-* のような命名規則だけで本番ロールを許可
多数のリポジトリで共有される長寿命資格情報
例外条件がWikiや口頭で管理される

オーナー変更や組織改編にIAM更新が追従できず、権限ドリフトが発生します。事故時には「とりあえず恒久例外」が積み上がり、統制が崩れます。

新しい基準アーキテクチャ

OIDCクレームを“ポリシー入力”として扱います。

1) プロパティ分類を最小で定義する

最初から項目を増やしすぎないのがコツです。

data_classification: public / internal / confidential / regulated
deployment_tier: dev / staging / prod
service_criticality: low / medium / high
owner_team: 正規化されたチームID

自由入力は避け、列挙値で厳密化します。

2) クラウド側ポリシーでクレームを必須化

IAMでは issuer / audience だけでなく、上記クレーム制約を評価します。例：

deployment_tier=prod かつ service_criticality=high のみ高権限ロールを許可
data_classification=regulated は追加ガードレール（承認や検査）を要求

3) CIで“事前ポリシー検証”を走らせる

実デプロイ前に不整合を止める仕組みを入れます。

対象環境に対して必要プロパティが揃っているか
署名、テスト、レビューなど必須制御が満たされるか
失敗時は修正可能なエラー文を返す

段階導入モデル

Phase A: 現状棚卸し

既存repo→role信頼関係をエクスポート
サービスを機密度・重要度で分類
未設定/不正値のプロパティを洗い出し

Phase B: 非ブロッキング運用

PR時点でスキーマ検証
ミスマッチ警告ダッシュボードを可視化
例外件数と解消リードタイムを測定

Phase C: 段階的ブロッキング

まず本番・規制対象から強制
一時例外は承認必須＋TTL必須
期限切れ例外を自動通知

併用すべき制御

OIDCクレームが強くても、単独では不十分です。

トークン短寿命化
Artifact provenance/SLSA系証跡
ブランチ保護と必須レビュー
高リスク期間のデプロイ凍結窓

多層防御にすることで、設定ミス時の被害半径を縮小できます。

監査・インシデント対応の観点

事故時に数分で答えられる状態を目指します。

どのクレームで申請されたか
どのポリシールールで許可されたか
いつ誰がプロパティを変更したか
例外があった場合、その理由と期限

CIログだけでなく、改ざん耐性のある監査イベントとして保存するのが重要です。

典型的な失敗パターン

項目増殖：フィールドだけ増えて責任者不在
手作業ロール編集：Policy-as-Codeを迂回
恒久例外化：暫定措置が常態化
語彙崩壊：同じ意味に複数表記が混在

経営報告に使えるKPI

準拠クレームで実行されたデプロイ比率
ポリシー不整合の平均修復時間
有効な例外件数（経過日数バケット付き）
高権限ロール引受回数（tier別）

統制品質を、技術詳細に依存しない形で示せます。

まとめ

Repository custom propertiesを使ったOIDCは、単なるメタデータではなく身元情報契約です。早期に運用設計まで整えた組織ほど、開発速度を落とさずに最小権限と監査可能性を両立できます。