CAMPFIRE GitHub不正アクセス事案の技術的考察と再発防止策

SRE・開発エンジニアの視点で、今回のインシデントの攻撃ベクトル分析と、モダンな開発組織が取るべき具体的な防御策をまとめます。

本事案の核心は、「ソースコードの閲覧権限」が「インフラへのフルアクセス権」へ昇格したことにあります。

起点（Initial Access）： 個人用アクセストークン（PAT）の窃取と推測。特に Classic PAT はスコープが粗く、1つのトークンがアカウントが属する全リポジトリへの読み取り権限を持つため、攻撃者にとっての「万能鍵」となります。
横展開（Lateral Movement）： * ソースコード内の環境変数テンプレート（.env.example）や過去のコミット履歴から、接続先ホスト名や認証情報を特定。
- CI/CD設定（GitHub Actions等）に含まれる長期的なクレデンシャル（AWS Access Key等）を悪用。
最終目的（Exfiltration）： 取得した認証情報を用いて、VPC内の顧客データベースや管理システムへ不正アクセスを実行。

「鍵」の管理を属人化させず、最小権限の原則（PoLP）を徹底することが重要です。

PATの移行と制限： * Classic PATの廃止： 組織レベルで Fine-grained PAT への移行を強制する。これにより、リポジトリ単位・操作単位で権限を絞り込み、有効期限を短縮（最大1年）できます。
- GitHub Appsの活用： システム間の連携には、個人に紐づかない GitHub Apps を使用し、インストール先を限定します。
OIDC（OpenID Connect）によるパスワードレス化：
- GitHub Actions から AWS/GCP 等へアクセスする際、長期的なアクセスキーを Secrets に保存するのはアンチパターンです。
- IDプロバイダ（IdP）連携による一時的な認証トークン発行に切り替え、漏洩リスクを構造的に排除します。

「人間は必ずミスをする」という前提で、ガードレールを設置します。

Push Protection の有効化：
- GitHubのリポジトリ設定で Push protection をONにし、シークレット（APIキーやトークン）が含まれるコミットをプッシュ時点でブロックします。
履歴のスキャンと無効化：
- gitleaks や trufflehog を用いて、過去の全コミット履歴をスキャンします。
- 検出された場合、「git rm」は無意味です。直ちに該当の認証情報を無効化（Revoke）し、ローテーションを実行してください。

今回のCAMPFIREの対応から、エンジニアが平時に準備しておくべき対応フローです。

爆発半径（Blast Radius）の想定：
- 「ソースコードが見られた」＝「そのコードが触れる全リソースが侵害された」と見なす。
- 全トークン、全SSH鍵、全DBパスワードの即時ローテーション・自動化スクリプトを整備しておく。
監査ログの可視化：
- GitHubの Audit Log やクラウドの CloudTrail 等をSIEM（Datadog, Splunk等）に集約し、普段使われないIPや時間帯からのアクセスを検知できる体制を構築する。

エンジニアとしての要点： GitHubは単なるコード置き場ではなく、**「インフラの地図と合鍵が詰まった機密区画」**です。PATの棚卸しとOIDCへの移行は、明日からでも着手すべき最優先事項と言えます。