GitHub OIDC＋Repository Custom Propertiesで作るABAC実装設計

なぜ重要か

GitHub ActionsのOIDCトークンでrepository custom propertiesが扱えるようになると、CI/CD権限管理は「リポジトリ名ベース」から「属性ベース」へ進化できます。これは大規模組織ほど効果が大きい変化です。

同じ技術スタックでも、データ機密度や業務影響が違えば必要な権限は変わります。ABACはその文脈差を扱えます。

RBACだけでは詰まる理由

従来RBACは以下で破綻しがちです。

• role乱立で追跡不能
• 命名規則依存で例外が増殖
• 組織改編時に権限更新が遅れる
• 緊急対応で恒久例外が残る

ABACは「誰か」だけでなく「どんな属性の変更か」を判定に使えるため、例外を減らせます。

先に属性辞書を決める

IAM条件式を書く前に、属性辞書を固定します。

• data_class: public/internal/restricted
• system_tier: tier1/tier2/tier3
• deployment_scope: sandbox/stage/prod
• owner_team: 正規化済みチームID
• change_window: business-hours/24x7

辞書が曖昧だと、ポリシーが読み解けない“呪文”になります。

信頼ポリシーの実装骨格

最低限、以下を検証する条件を入れます。

• issuer / audience整合
• workflow identity
• custom property claim
• protected branch / environment一致

例として、本番書き込み権限はdeployment_scope=prodかつtier1属性を持ち、承認済みの再利用workflow経由のみ許可、という形です。

属性変更のガバナンス

custom propertiesは権限制御入力なので、変更プロセスも統制対象です。

• 属性オーナーを定義
• 変更時に承認履歴を残す
• 定期attestationを実施
• 一時属性は期限切れ自動失効

ここが弱いと、ABACは“改ざん可能な自己申告”に落ちます。

開発体験を設計する

正規ルートが遅いと必ず迂回が生まれます。次を用意します。

• 必須claimを注入済みの再利用workflow
• 属性不足時の明確なlintエラー
• 判定結果を見える化するダッシュボード
• 修正手順テンプレート

セキュリティを「お願い」ではなく「最短経路」にすることが鍵です。

まとめ

OIDC＋custom propertiesは、CI/CDを属性駆動の統制モデルへ移す現実的な手段です。属性辞書、変更ガバナンス、開発者向け導線の3点を同時に作り込めば、権限リスクと運用摩擦を同時に下げられます。