セキュリティ

CAMPFIRE GitHub不正アクセス事件｜開発者アカウントの管理とGitHubセキュリティ設定ガイド

2026年4月12日12分で読める

READ LATER / FREE NEWSLETTER

「製品を先に買い、止められない業務・重要データ・管理者権限が未整理のまま残る」を避ける判断材料を残す

あとで読む保存は登録不要。無料レターでは、この記事に近い「セキュリティ製品を買う前に棚卸しする3点」を受け取れます。

保存はこの端末だけ・メール不要／メルマガは営業電話なし・確認メール承認後に開始

GXO COLUMN

セキュリティ

クラウドファンディング大手CAMPFIREが、システム管理用GitHubアカウントへの不正アクセス被害を公表した。 ソースコードの管理基盤であるGitHubが攻撃対象になったことは、開発体制を持つ全ての企業にとって他人事ではない。

本記事では、事件の概要を整理した上で、GitHubアカウントが狙われる理由、そして中小企業のIT担当者・経営者が今日から実施すべきGitHubセキュリティ設定10項目を解説する。

事件概要：何が起きたのか

CAMPFIREの発表内容

横にスクロールして確認できます

項目	内容
被害企業	CAMPFIRE（クラウドファンディングプラットフォーム）
公表日	2026年4月3日
攻撃対象	システム管理用GitHubアカウント
攻撃手法	GitHubアカウントへの不正アクセス
影響範囲	ソースコード・関連情報への不正閲覧の可能性
対応状況	該当アカウントの無効化、外部専門機関と連携し調査中

CAMPFIREは不正アクセスを検知後、速やかに該当アカウントを無効化し、外部のセキュリティ専門機関と連携して調査を開始した。ユーザーの決済情報への直接的な影響は現時点で確認されていないが、ソースコードリポジトリへのアクセスが行われた可能性がある。

FREE DOWNLOAD

中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします

多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。

5ステップガイドを無料でダウンロード

なぜGitHubアカウントが狙われるのか

ソースコードは「情報の宝庫」

GitHubリポジトリには、ソースコードだけでなく以下のような機密情報が含まれている可能性がある。

APIキー・シークレットトークン — 外部サービスとの連携に使用する認証情報
データベース接続文字列 — 本番環境のDB接続情報がハードコードされているケース
内部ドキュメント — システム構成図、インフラ設計書、運用手順書
環境変数ファイル — .envファイルが誤ってコミットされているケース
顧客データの断片 — テストデータやマイグレーションファイルに含まれる実データ

攻撃者にとって、1つのGitHubアカウントを奪取するだけで、対象企業のシステム全体像を把握できる可能性がある。これが、GitHubアカウントが高い価値を持つ理由だ。

「システム管理用アカウント」の特有リスク

今回のCAMPFIREの事案で注目すべきは、攻撃対象が 個人の開発者アカウントではなく「システム管理用アカウント」 だった点だ。管理用アカウントは通常、複数のリポジトリに対して広範な権限を持っている。1つのアカウントが侵害されただけで、組織全体のコードベースが危険にさらされる。

また、管理用アカウントは以下の問題を抱えやすい。

複数の担当者間で認証情報を共有している
退職者のアクセス権が残ったまま放置されている
個人アカウントに比べて多要素認証（MFA）の設定が後回しにされている
アクティビティの監視が不十分で、不審なアクセスの検知が遅れる

GitHubセキュリティ設定10項目チェックリスト

以下は、中小企業のIT担当者が今日から順番に確認・設定すべき項目だ。

即日対応（所要時間：各15分以内）

1. 多要素認証（MFA）を全アカウントに強制する

GitHub Organization の設定で「Require two-factor authentication」を有効にする。2024年3月以降、GitHubは全ユーザーにMFAを義務化しているが、Organizationレベルでの強制設定が別途必要だ。ハードウェアセキュリティキー（YubiKeyなど）の利用を推奨する。

2. SSO（シングルサインオン）を導入する

GitHub Enterprise Cloud を利用している場合、SAML SSOを有効にし、社内のIdP（Azure AD、Okta、Google Workspaceなど）と連携する。これにより、退職者のアクセス権をIdP側で一括無効化できる。

3. 管理用の共有アカウントを廃止する

「admin」「deploy」などの共有アカウントを使っている場合は即座に廃止する。個人アカウントに適切な権限を付与し、操作の追跡可能性（トレーサビリティ）を確保する。

1週間以内に実施

4. IP制限を設定する

GitHub Enterprise Cloud では、Organization に対してIPアドレスの許可リストを設定できる。オフィスネットワークやVPN経由のアクセスのみを許可し、未知のIPからのアクセスをブロックする。

5. シークレットスキャン（Secret Scanning）を有効にする

GitHub の Secret Scanning 機能を有効にし、APIキー、トークン、パスワードがリポジトリにコミットされた場合に自動検知・アラートを発生させる。Push Protection も合わせて有効にすれば、シークレットを含むコミットのプッシュ自体をブロックできる。

6. Dependabotアラートを有効にする

依存パッケージの脆弱性を自動検知するDependabotを有効にする。Dependabot Security Updates を有効にすれば、修正パッチを含むPRが自動作成される。放置された脆弱性は攻撃者の入り口になる。

7. ブランチ保護ルールを設定する

mainブランチへの直接プッシュを禁止し、Pull Request経由のマージを必須にする。レビュー必須、ステータスチェック必須の設定を有効にし、コードの品質とセキュリティを担保する。

1か月以内に整備

8. 監査ログを定期的にレビューする

GitHub の Audit Log を月次でレビューする運用を確立する。特に注視すべきイベントは以下の通り。

新しいメンバーの追加・権限変更
リポジトリの可視性変更（Private → Public）
外部コラボレーターの招待
Webhookの追加・変更
通常と異なるIPアドレスからのアクセス

9. 外部コラボレーターとフォークポリシーを管理する

業務委託先やフリーランスにリポジトリへのアクセスを許可する場合、必要最小限のリポジトリに限定する。契約終了時のアクセス権削除手順を文書化し、四半期ごとに外部コラボレーターの棚卸しを行う。

10. GitHub Actionsのセキュリティを強化する

CI/CDパイプラインで使用するGitHub Actionsのパーミッションを最小限に設定する。サードパーティ製Actionsは信頼できるものに限定し、バージョンをSHAで固定する。GITHUB_TOKENのパーミッションもデフォルトのread-onlyを維持する。

FREE DOWNLOAD

中小企業の脆弱性対応月次運用テンプレ

情シス1人体制でも回せる脆弱性棚卸・対応フローのテンプレート（Excel版）。

30分で相談するテンプレをDL

対策の優先度と費用感

横にスクロールして確認できます

優先度	対策	費用	効果
最優先	MFA強制	無料（GitHub標準機能）	不正ログインの99%を防止
最優先	共有アカウント廃止	無料	操作追跡の基盤確立
高	Secret Scanning + Push Protection	無料（Public）/ Enterprise必要（Private）	認証情報漏洩の自動防止
高	Dependabotアラート	無料	既知脆弱性の自動検知
中	SSO連携	Enterprise Cloud（$21/user/月〜）	アクセス管理の一元化
中	監査ログレビュー	運用コストのみ	不審アクティビティの早期発見

よくある質問（FAQ）

Q. うちは5人のチームでGitHubを使っています。Enterprise Cloudは必要ですか？

小規模チームの場合、まずはGitHub Team プラン（$4/user/月）で十分だ。MFA強制、ブランチ保護、Secret Scanning（Public リポジトリ）は Team プランでも利用できる。IP制限やSAML SSOが必要になった段階でEnterprise Cloudへのアップグレードを検討すればよい。

Q. 個人のGitHubアカウントを業務で使わせています。問題はありますか？

問題がある。個人アカウントは退職時のアクセス権管理が困難になり、MFA設定の強制もできない。GitHub Organization を作成し、業務用リポジトリはOrganizationで管理する運用に切り替えるべきだ。個人アカウントをOrganizationのメンバーとして招待する形式であれば、メンバーの追加・削除が一元管理できる。