GitHub資格情報漏えいに備える実務設計: Revocation Firstで回すCI/CDインシデント対応

CI/CDは人間より機械資格情報に依存する時代になりました。だからこそ、トークン漏えいでは「調査してから止める」よりも、止めてから調査する順序が合理的です。

1. Revocation Firstの基本手順

1. 疑わしい資格情報ファミリーを緊急失効
2. 影響パイプラインを制御モードへ移行
3. 最小権限で再発行/ローテーション
4. 監査ログで影響範囲を確定
5. 一時的な強化ポリシーのまま段階復旧

最初に確実な封じ込めを行うことで、判断ミスの余地を減らせます。

2. 資格情報台帳を“運用資産”にする

速く失効するには、どの鍵がどこで使われているかを平時に把握しておく必要があります。

• 所有チームと緊急連絡先
• 発行経路（App/OAuth/PAT/OIDC）
• スコープ（org/repo/environment）
• TTLと更新方式
• 依存ジョブと代替運転手順

理想はコード管理です。表計算だけでは更新遅延が起きます。

3. 資格情報の種類ごとに復旧戦略を分ける

• 人間の対話ログイン
• bot/サービス資格情報
• OIDC由来の短命資格情報
• 外部連携シークレット

同一手順で扱うと復旧が遅くなり、逆に危険な暫定運用を招きます。

4. 緊急時でも危険な“暫定拡権”を避ける

本番復旧を急ぐほど、過剰権限を戻してしまいがちです。予めデグレード運転を決めておくと防げます。

• 非重要リポジトリはread-only CI
• デプロイは手動承認必須
• 署名/配布系操作はdeny-by-default
• 環境対象をstaging中心に限定

可用性を維持しつつ、攻撃面を広げない設計が必要です。

5. 計測指標と訓練

• 失効完了までの平均時間（MTTRv）
• オーナー/TTLメタデータ完備率
• 手動シークレット編集なし復旧率
• 再発インシデントの根本原因分類

四半期ごとの机上訓練で、実際の制約込みで検証します。対応品質は有事ではなく平時に作られます。

まとめ

資格情報漏えいは例外ではなく前提です。だからこそ、失効速度、台帳精度、復旧の定型化を“仕組み”として整えるべきです。Revocation Firstは、現代のCI/CD防御における最短距離です。