Credential Revocation API拡張の実務: GitHub OAuth/App漏えい対応を最短化する

GitHub Changelogで、Credential Revocation APIがGitHub OAuthとGitHub App資格情報まで広がったことは、単なるAPI改良ではありません。インシデント対応の世界では、これは封じ込め速度を上げる制御面アップグレードです。

資格情報漏えいの勝敗は、検知精度だけで決まりません。実際には「混乱した現場で何分で無効化できるか」が被害規模を決めます。

この拡張が埋める運用ギャップ

従来の多くの組織では、資格情報タイプごとに対応経路が分断されていました。

PATはA手順
OAuthトークンは手動運用
App資格情報は個別スクリプト

この分断が、最も急ぐべき初動で遅延を生みます。今回の拡張は、トークン種別を跨ぐ統一オペレーションを設計できる点が重要です。

まず作るべき「Revocation-first」契約

インシデント手順を、時間契約として定義します。

T+0〜5分: 分類と隔離

漏えいした資格情報タイプとスコープ判定
該当自動化ジョブを一時停止
高リスク書き込み経路を遮断

T+5〜15分: 無効化と検証

Revocation APIで対象資格情報を無効化
読み戻しチェックで状態確認
影響サービスアカウントに再認証を強制

T+15〜60分: 安全復旧

最小権限の新資格情報を再発行
自動化を段階再開
再試行/再侵入シグナルを監視

この契約を四半期ごとに演習するだけで、実戦時の迷いが激減します。

アーキテクチャ: Revocation Brokerを1つ置く

各パイプラインに無効化処理を分散実装すると、必ず品質差が出ます。中央のBrokerサービス化が有効です。

検知イベント受信（secret scanning、SIEM、手動通報）
リポジトリ所有者・環境重要度を付与
資格情報タイプ別にRevocation APIを実行
監査証跡をインシデントタイムラインへ保存

効果は明確で、ポリシー一貫性・監査性・演習容易性が同時に上がります。

復旧時に再び事故を作らない設計

無効化だけ強くしても、復旧で広権限トークンを再発行すると逆効果です。復旧の既定値を次のように固定します。

自動化資格情報は短TTL
環境境界ごとに分離
用途別に書き込み権限を分割
ワイルドカード権限は理由必須

「復旧が少し遅くても安全」を取るべき系統を最初に決めることが大事です。

可観測性はスクリーンショットでは不足

チャットに貼った画面キャプチャでは、後から分析できません。最低限、次を時系列で取得します。

資格情報タイプ別の無効化レイテンシ
誤無効化件数と業務影響
再発行時のスコープ肥大化率
漏えい起点の再発フィンガープリント

無効化時間が設計時の想定より長いなら、事故モデルを更新すべきです。

監査・法務整合のポイント

SOC 2、ISO 27001、社内監査で評価されるのは「やった」ではなく「追跡できる」ことです。証跡には以下を残します。

インシデントチケットID
資格情報識別子ハッシュ
無効化API実行時刻
復旧承認チェーン

技術対応が成功しても、この証跡が欠けると統制対応は失敗になります。

起きやすい失敗と予防策

失敗1: 無効化成功後にワークロードが静かに停止

予防: 資格情報依存マップを事前に作る。

失敗2: 緊急復旧で過剰権限トークンを再発行

予防: スコープテンプレートをpolicy-as-codeで検査。

失敗3: まだ有効かどうか判定できない

予防: 状態確認API + ダッシュボード警告を整備。

4週間パイロット計画

1週目: 資格情報タイプとオーナー棚卸し
2週目: Broker最小実装と監査ログ
3週目: OAuth/App漏えい想定の机上演習
4週目: 本番SLO導入と週次レポート

短期パイロットでも、依存関係の見えない負債がかなり表面化します。

まとめ

AI支援開発で変更速度が上がるほど、資格情報事故は「たまに起きる例外」から「いつでも起こり得る前提」に変わります。Revocation API拡張を使って、初動を人依存から運用契約に変えることが、2026年のセキュリティ基盤整備で最も費用対効果の高い一手です。

一次情報はGitHub ChangelogのCredential Revocation API更新を確認し、社内手順に落とし込んでください。