GitHub Actions OIDC × Custom Propertiesで実現するABAC実装ガイド

GitHub Actions OIDCトークンがリポジトリのCustom Propertiesを扱えるようになったことで、CI/CDの権限設計は一段進みます。これは単なる機能追加ではなく、静的ロール運用から属性ベース制御（ABAC）への移行機会です。

従来運用の限界

多くの組織では、CI用クラウド権限が次のように肥大化します。

• 環境ごとに似たロールが乱立
• 例外対応でロール条件が複雑化
• リポジトリの重要度と権限強度が連動しない

この状態では、最小権限を維持するほど運用負荷が上がり、結果的に“広めに許可”へ流れます。

ABACを成立させる属性設計

ABACの肝は、属性の命名規則と統制です。実務で有効なのは、次のような属性セットです。

• データ分類（public / internal / restricted）
• 規制境界（pci / sox / none）
• デプロイ重要度（low / high）
• オーナー領域（platform, payments など）

これらをOIDCクレームに反映し、クラウドIAM側で評価すれば、権限付与を“実態に沿って”自動化できます。

基本ポリシーパターン

導入時は次を最低ラインにします。

1. trust policyはdeny-by-default
2. org/repo一致を必須化
3. 必要属性の一致を必須化
4. セッション有効時間を短縮
5. 監査ログへ属性値を記録

この5点だけでも、権限の過剰化と原因不明アクセスを大幅に減らせます。

属性改ざんリスクに対処する

属性が権限判断に使われる以上、属性変更は“設定作業”ではなく“セキュリティ変更”です。よって以下が必要です。

• 属性変更の承認フロー
• CODEOWNERSによるレビュー必須化
• 日次ドリフト検知
• 緊急例外（break-glass）のチケット連携

属性管理を野放しにすると、ABACは逆に新しい攻撃面になります。

4週間での導入ロードマップ

• 1週目: 属性タクソノミー確定
• 2週目: 既存リポジトリへ属性付与・欠損洗い出し
• 3週目: 非本番で強制検証
• 4週目: 本番適用と監査ダッシュボード公開

小さく始め、例外を可視化しながら適用範囲を広げるのが成功パターンです。

まとめ

OIDC + Custom Properties は、YAMLを減らす機能ではなく、組織規模に耐える権限制御基盤です。リポジトリの意図（属性）をクラウド認可に直結できれば、速度と統制を同時に満たせます。

参考: https://github.blog/changelog/