CAMPFIREのGitHub不正アクセス事件に学ぶ、今すぐやるべきセキュリティ対策

2026年4月に発生したCAMPFIREのGitHub不正アクセス事件をケーススタディに、エンジニアが今すぐ実施すべきPAT管理・シークレットスキャン・OIDC連携などの実践的対策を解説します。

「まさか自分たちは大丈夫」と思っていませんか？

GitHubのアクセストークン、個人アカウントに直接設定していませんか？退職したメンバーのトークンが今もリポジトリにアクセスできる状態になっていませんか？ git log を追えば過去にコミットされた秘密鍵やパスワードが出てくる……なんてことはないでしょうか。

2026年4月、クラウドファンディングサービス「CAMPFIRE」でGitHubアカウントへの第三者不正アクセスが発生しました。ソースコードの閲覧からはじまり、最終的に4月24日には最大225,846件の個人情報（口座情報を含む）の漏えい可能性が公表されるに至り、GitHub侵害が顧客情報漏えいにまで発展した深刻な事例となりました。

しかし、これはCAMPFIREに限った話ではありません。弊社Fivenine Designでも複数のクライアント案件でGitHubを日常的に利用しており、「明日は我が身」という危機感を強く持っています。今回の記事では、公表された事実をもとにインシデントの全体像を整理し、同じ轍を踏まないための技術的対策を実践レベルで解説します。

インシデントの経緯：公表済みの事実を時系列で整理する

まずはCAMPFIREが公式に発表した内容を正確に把握しておきましょう。憶測や誇張は百害あって一利なし。事実だけを見ます。

2026/04/02

異常を検知

22:50頃、GitHubアカウントへの第三者不正アクセスを検知

2026/04/03

第一報公表

不正アクセスの事実とソースコード閲覧の可能性を公表

2026/04/14

第二報公表

取引先1社の連絡先および開発関係者413名の氏名・メールアドレスが閲覧可能な状態だったと判明

2026/04/22

第三報公表

顧客情報管理システムの一部に外部からの不正アクセス痕跡を確認（影響範囲は検証中）

2026/04/24

第四報公表

最大225,846件の個人情報漏えい可能性を公表。プロジェクトオーナー120,929件・支援者130,155件・パートナー1,282件。氏名・住所・電話番号・メアド・口座情報（82,465件に口座情報含む）。クレジットカード情報は含まず

CAMPFIREが実施した対策（公表内容）

CAMPFIREは事後対策として以下を実施したと公表しています。

漏えい認証情報の無効化・再発行
個人用アクセストークン（PAT）から、権限を限定した認証方式への移行
組織内のアクセス権限の見直し

これらの対策は、セキュリティインシデント対応の教科書通りでもあります。逆に言えば、これらが事前に整備されていれば被害を防げた——あるいは大幅に縮小できた可能性があります（推測）。

サーバー・インフラでお困りですか？

障害対応・移行・パフォーマンスチューニングなど、ご相談ください

無料で相談する

なぜGitHub経由でここまで被害が広がるのか

GitHubリポジトリへのアクセスが突破口になった場合、被害が連鎖的に拡大しやすい構造上の理由があります。

flowchart TD
    A[GitHubアカウント侵害] --> B[ソースコード閲覧]
    B --> C[コード内の認証情報を発見]
    C --> D[DBパスワード / APIキー / クラウド認証情報]
    D --> E[本番DB・クラウドリソースへのアクセス]
    E --> F[顧客情報・決済情報の漏えい]
    B --> G[環境変数ファイル .env の発見]
    G --> D
    A --> H[コミット履歴の閲覧]
    H --> I[過去にコミットされた秘密情報を発見]
    I --> D

リポジトリには「アプリのロジックだけでなく、インフラへの鍵」が眠っていることが少なくありません。.env ファイルのコミットミスや、ハードコードされたAPIキーは特に危険で、コミット履歴を遡ればずっと昔の情報も掘り起こせてしまいます。

今すぐ実施すべき技術的対策 6選

対策1：Fine-grained PAT（きめ細かいアクセストークン）への移行

CAMPFIREが「権限を限定した認証方式への移行」を実施したとおり、まず着手すべきはPersonal Access Token（PAT）の見直しです。

従来の「Classic PAT」は権限スコープが粗く、一度侵害されると広範なリポジトリにアクセスされてしまいます。GitHub が推奨する Fine-grained PAT は、リポジトリ・権限・有効期限を細かく絞り込めます。

# GitHub > Settings > Developer settings > Personal access tokens > Fine-grained tokens

1. 「Generate new token」をクリック
2. Token name: 用途を明記（例: ci-deploy-prod-2026）
3. Expiration: 最長90日を推奨（無期限は絶対に避ける）
4. Resource owner: 個人 or 組織を選択
5. Repository access: 「Only select repositories」で必要なリポジトリだけ指定
6. Permissions:
   - Contents: Read-only（CIが読むだけなら書き込み不要）
   - Actions: Read and write（GitHub Actions操作が必要な場合のみ）
   - Secrets: なし（原則として不要）

# Classic PAT の問題点
# - スコープが「repo」だと全リポジトリの読み書きが可能
# - 有効期限なしで発行できてしまう
# - どのリポジトリに使っているか追跡しにくい
# - 組織の場合、個人が退職しても無効化を忘れがち

# Fine-grained PAT で解決できること
# - 特定リポジトリ・特定権限に限定
# - 有効期限の強制設定
# - 組織オーナーが一覧・取り消し可能

対策2：GitHub Actions OIDC連携でPATをゼロにする

CI/CDパイプラインでAWSやGCPにデプロイする際、PATやシークレットにクラウド認証情報を保存している現場は今も多いはずです。OpenID Connect（OIDC）を使えばトークンそのものを保存せずに済みます。

OIDCの仕組みは「GitHub ActionsがGitHubのOIDCエンドポイントから短命のトークンを取得し、そのトークンでAWS/GCPに一時認証する」というものです。仮にリポジトリが侵害されても、払い出し済みの長命トークンが存在しないため被害を大幅に抑制できます。

# .github/workflows/deploy.yml
name: Deploy to AWS (OIDC)

on:
  push:
    branches: [main]

permissions:
  id-token: write   # OIDCトークン取得に必須
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # AWS認証情報をSecretsに保存しない！OIDCで取得する
      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy
          aws-region: ap-northeast-1
          # セッションは最長1時間で自動失効

      - name: Deploy
        run: aws s3 sync ./dist s3://my-bucket/

# .github/workflows/deploy-gcp.yml
name: Deploy to GCP (OIDC)

on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Authenticate to Google Cloud via OIDC
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: 'projects/123456789/locations/global/workloadIdentityPools/my-pool/providers/my-provider'
          service_account: '[email protected]'

      - name: Deploy to Cloud Run
        uses: google-github-actions/deploy-cloudrun@v2
        with:
          service: my-service
          region: asia-northeast1
          image: gcr.io/my-project/my-image

OIDC導入後の変化： GitHub Secrets から AWS_ACCESS_KEY_ID や AWS_SECRET_ACCESS_KEY のような長命の認証情報を完全に削除できます。リポジトリが仮に侵害されても、攻撃者はクラウドリソースに直接アクセスするための有効な鍵を手にできません。

対策3：git-secrets / gitleaksでコミット前にシークレットを検出する

コードレビューでは気づきにくい「うっかりコミット」を、ツールで機械的に防ぎましょう。

# インストール（macOS）
brew install gitleaks

# インストール（Linux）
curl -sSfL https://raw.githubusercontent.com/gitleaks/gitleaks/main/scripts/install.sh | sh -s -- -b /usr/local/bin

# リポジトリ全体をスキャン
gitleaks detect --source . --verbose

# 直近のコミット差分だけスキャン（高速）
gitleaks detect --source . --log-opts="HEAD~5..HEAD"

# pre-commitフックとして設定
# .git/hooks/pre-commit に以下を記述
#!/bin/sh
gitleaks protect --staged --verbose
if [ $? -ne 0 ]; then
  echo "[ERROR] シークレットが検出されました。コミットを中止します。"
  exit 1
fi

# .github/workflows/secret-scan.yml
name: Secret Scanning

on: [push, pull_request]

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # 全コミット履歴を取得

      - name: Run gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}  # 組織利用は有料プラン

対策4：GitHub側のPush Protection / Secret Scanningを有効化する

リポジトリ側でも多層防御を設定します。これはコードを1行も書かずにGitHub画面から有効化できます。

# GitHub リポジトリ > Settings > Security > Code security and analysis

1. Secret scanning → Enable
   └ 有効にすると、過去のコミット履歴にあるシークレットも検出して通知

2. Push protection → Enable
   └ シークレットが含まれるコードのpushをブロック
   └ 誤検知の場合は理由を入力してバイパス可能（ログに記録される）

3. Dependency graph → Enable
4. Dependabot alerts → Enable
   └ 脆弱性のある依存ライブラリを自動検出

# 組織全体に一括適用する場合
# Organization > Settings > Code security > Apply to all repositories

Push Protection の効果： 仮に開発者がうっかり .env をステージングしても、GitHubサーバー側でブロックされます。gitleaks のローカルフックと組み合わせることで「コミット前」「プッシュ時」の二重チェックが実現します。

対策5：GitHub Appsを使ってPATを組織から排除する

CI/CD用途のPATを組織から完全に排除したい場合、GitHub Apps の利用を検討してください。GitHub AppsはPATと異なり、「個人アカウント」ではなく「アプリ（bot）」として認証されるため、特定のメンバーの退職・アカウント侵害に左右されません。

# GitHub Appのインストールトークンを取得するスクリプト例（Node.js）
# 依存: @octokit/auth-app

const { createAppAuth } = require('@octokit/auth-app');

const auth = createAppAuth({
  appId: process.env.GITHUB_APP_ID,
  privateKey: process.env.GITHUB_APP_PRIVATE_KEY,
  installationId: process.env.GITHUB_APP_INSTALLATION_ID,
});

// インストールトークンは1時間で自動失効する
const { token } = await auth({ type: 'installation' });
console.log('取得したトークン:', token);
// このトークンをAPI呼び出しに使用する

PAT vs GitHub Apps の比較：

比較項目	Classic PAT	Fine-grained PAT	GitHub Apps
認証主体	個人アカウント	個人アカウント	アプリ（Bot）
退職時の影響	手動削除が必要	手動削除が必要	影響なし
権限の細かさ	粗い	細かい	最も細かい
トークン有効期限	設定次第（無期限可）	最長1年	1時間（自動失効）
組織管理	困難	可能	容易
導入コスト	低い	低い	高い

対策6：監査ログで不審なアクセスを早期検知する

CAMPFIREが不正アクセスを検知したのは2026年4月2日22:50頃とされています。監査ログを定期的に確認する習慣があれば、侵害の初期段階で異変に気づける可能性があります。

# GitHub Organization の監査ログ取得（REST API）
# 必要な権限: org:admin

curl -H "Authorization: Bearer YOUR_TOKEN" \
     -H "Accept: application/vnd.github+json" \
     "https://api.github.com/orgs/YOUR_ORG/audit-log?phrase=action:git&per_page=100" \
     | jq '.[] | {actor, action, created_at, repository, country_name}'

# 注目すべきイベント種別
# git.clone       : リポジトリのクローン
# git.fetch       : リモートからのフェッチ
# repo.access     : リポジトリへのアクセス権変更
# org.invite_member / org.remove_member : メンバー変更
# personal_access_token.access : PATによるアクセス
# two_factor_authentication.disabled : 2FA無効化（要警戒！）

# 不審なIPアドレスからのアクセスを抽出
curl -H "Authorization: Bearer YOUR_TOKEN" \
     "https://api.github.com/orgs/YOUR_ORG/audit-log?per_page=100" \
     | jq '.[] | select(.actor_ip != null) | {actor, actor_ip, action, created_at}'

監査ログ確認のポイント：

深夜・休日の大量クローン操作
普段と異なる国・地域からのアクセス
2FAの無効化操作
退職済みメンバーのアカウントによるアクセス

よくある失敗パターンと対処法

開発現場でよく見かける「やりがちなミス」を整理しておきます。弊社でもクライアントのコードレビュー時に似たケースを発見することがあります。

**問題：** `DATABASE_URL` や `SECRET_KEY` がリポジトリ履歴に残り続ける。削除コミットをしても `git log` で復元可能。

**対処：** `git filter-repo` または `BFG Repo-Cleaner` で履歴ごと完全削除する。その後、必ず認証情報を再発行すること（削除しても漏えいリスクは残る）。

```bash
# BFG で .env を含むコミットを履歴から削除
bfg --delete-files .env
git reflog expire --expire=now --all
git gc --prune=now --aggressive
git push --force
```

**問題：** read-onlyのCI処理なのに書き込み権限まで付与されており、侵害時のダメージが最大化する。

**対処：** Fine-grained PATに移行し、必要最小権限の原則（PoLP）を徹底する。CI/CDなら `Contents: Read-only` で大半のユースケースをカバーできる。

**問題：** 退職後も元社員がリポジトリにアクセスできる状態が続く。悪意がなくても、その元社員のアカウントが侵害されれば間接的な被害を受ける。

**対処：** オフボーディングチェックリストにGitHub Organizationからの削除を必須項目として追加する。SSOと連携できる場合はIdP（Okta等）側で一括制御する。

**問題：** 作業上の利便性からOrganizationの全員をOwnerにしているケースが散見される。1人が侵害されると組織全体が陥落する。

**対処：** Ownerは最小人数（2名程度）に絞り、開発者は「Member」権限に留める。リポジトリへのアクセスはTeam単位で管理する。

**問題：** 一部メンバーが2FA未設定のまま運用されており、そのアカウントがパスワードリスト攻撃で突破される。

**対処：** `Organization > Settings > Authentication security > Require two-factor authentication` を有効化する。設定後、2FA未設定のメンバーは自動的に組織から除外されるため、事前に周知が必要。

対策の優先順位を整理する

全対策を一度に導入するのは現実的ではありません。リスクの高さと導入コストのバランスで優先順位をつけましょう。

まず今週中にやること： 2FA強制化とPush Protectionの有効化は、コードを1行も書かずにGitHub管理画面から5分で完了します。この2つから着手してください。

まとめ：「検知できた」だけでは終わらない時代に

CAMPFIREのケースで特筆すべきは、検知から22日後の第四報で最大22.5万件の漏えい可能性が公表された点です。第一報時点では「個人情報流出の事実は確認されていない」とされていたものが、調査の進展に伴って最終的に顧客の氏名・住所・口座情報を含む大規模漏えいへと発展しました。GitHubアカウントの侵害を起点にどのように顧客情報管理システムへ到達したかの詳細はまだ完全には公表されていません（推測：ソースコードから得た情報を起点に別システムへのアクセス経路が辿られた可能性）。

重要なのは、侵害の入口（GitHubアカウント）と、その先にある本番システムを切り離す設計です。OIDCによる短命トークン・最小権限のPAT・組織の2FA強制——これらは「万が一を想定した多層防御」であり、開発効率を大きく損なうものではありません。

弊社Fivenine Designでもクライアント案件のコードレビューで .env のコミットミスを見かけることがあり、本記事の対策は決して大企業だけの話ではないと実感しています。「うちの規模では大げさ」ではなく、「この規模だからこそ、一人ひとりの対策が組織全体のセキュリティを左右する」という認識を持っていただければ幸いです。

サーバー・インフラでお困りですか？

障害対応・移行・パフォーマンスチューニングなど、ご相談ください

無料で相談する

サーバー管理、丸ごとお任せください

サーバー保守・運用

監視・障害対応・パフォーマンス改善まで、安定稼働をサポートします

200件以上の制作実績顧客満足度97% 初回相談無料

サービス詳細 30秒で送信 — 無料で相談する

※ 通常1営業日以内にご返信します

今すぐ実行できるセキュリティチェックリスト

GitHubセキュリティの設定見直しや、OIDC導入・GitHub Apps化の実装サポートが必要な場合は、Fivenine Designにお気軽にご相談ください。 神奈川を拠点に、Laravel・WordPress・Next.jsを中心とした開発と運用を支援しています。現状のセキュリティ構成を一緒に棚卸しするところから始めることも可能です。