CAMPFIRE GitHub不正アクセスに学ぶシークレット管理｜認証情報の誤アップロードを防ぐ実務

「うちみたいな小さな会社で、GitHubの設定なんてそこまで気にしなくても」。そう思っていた方ほど、今回の事案は他人事ではないかもしれません。2026年6月2日、クラウドファンディング大手のCAMPFIRE（キャンプファイヤー）が、自社のGitHubアカウントへの不正アクセスについて、外部専門機関による調査結果を公表しました。原因は、従業員が発行したGitHubの認証情報が、個人で使っていた開発サーバに意図せずアップロードされ、第三者に悪用されたことでした。

この事案が中小企業の情シスや社内SEにとって重要なのは、攻撃の入り口が「高度なゼロデイ脆弱性」ではなく、「うっかりした認証情報の置き忘れ」という、どの現場でも起こりうるミスだった点です。この記事では、何が起きたのかを攻撃者の動きに沿って整理し、そこから中小企業が今日から実践できる「シークレット管理（認証情報の取り扱い）」の具体策を、専任担当がいない現場でもできるレベルで解説します。誰かを責めるためではなく、同じ落とし穴を避けるための教訓として読んでいただければと思います。

何が起きたのか｜「鍵の置き忘れ」から始まった連鎖

まず、今回の事案の流れを整理します。CAMPFIREの公表によると、漏えいのおそれがある個人情報は最大で22万5846件にのぼる可能性があるとされ、氏名・住所・電話番号・メールアドレス・口座情報が含まれていました。なお、クレジットカード情報は含まれていないと説明されています。

注目すべきは、その「入り口」です。きっかけは、従業員が発行したGitHubの認証情報（アクセストークンなど）が、本人が個人開発で使っていたサーバに意図せず置かれてしまっていたことでした。攻撃者はこの認証情報を不正に手に入れ、そこを足がかりに会社のGitHubアカウントへと侵入していきます。たった一つの「鍵の置き忘れ」が、大規模な情報漏えいの引き金になったのです。

攻撃者の動きを時系列で見る

公表された調査結果をもとに、攻撃者がどう動いたかを時系列で整理します。攻撃は一気に起きたのではなく、数週間かけて段階的に深く侵入していった点が特徴です。攻撃者の手口を知ることは、防御側がどこで気づけたかを考える材料になります。

時期	攻撃者の動き	防御側にとっての意味
3月12日以降	従業員が発行したGitHub認証情報を不正取得	そもそも鍵が外に出ていたことが起点
3月18日	GitHubアカウントへ不正アクセス、複数リポジトリをコピー	ソースコードという「設計図」が外部へ
4月2日	GitHub Actions(CI/CD)で任意の処理を試行	自動化基盤が攻撃の足場として悪用される
4月16日にかけて	クラウド環境の認証情報を探索・取得し管理領域へ侵入	リポジトリ内の鍵を辿って横展開

この流れで恐ろしいのは、攻撃者が一つの認証情報を起点に、次の認証情報を探し当てて侵入範囲を広げていった点です。GitHubのリポジトリに入り込んだ攻撃者は、その中からクラウド環境にアクセスするための鍵を見つけ出し、さらに奥へと進みました。「鍵が鍵を呼ぶ」連鎖です。これは、認証情報がソースコードや設定ファイルの中に紛れ込んでいると、一つの侵入が芋づる式に被害を広げてしまうことを示しています。

なぜ「シークレットの混入」がこれほど危ないのか

ここで言う「シークレット」とは、システムが他のシステムやサービスにアクセスするための認証情報の総称です。具体的には次のようなものを指します。

・アクセストークン: GitHubやクラウドサービスにプログラムからアクセスするための鍵。
・APIキー: 外部サービスを呼び出すための認証文字列。
・パスワード・接続情報: データベースなどへの接続に使う認証情報。
・秘密鍵: SSH接続や暗号化に使う鍵ファイル。

これらが、ソースコードや設定ファイル、あるいは個人のメモ代わりのサーバなどに「うっかり」置かれてしまうことを、シークレットの混入や漏えいと呼びます。今回のCAMPFIREの事案も、まさにこの「個人サーバへの混入」が出発点でした。

攻撃者にとってシークレットは「最高のご褒美」

攻撃者の視点に立つと、シークレットは喉から手が出るほど欲しいものです。なぜなら、正規の認証情報さえ手に入れば、システムは攻撃者を「正当な利用者」として扱ってしまうからです。脆弱性を突いて無理やりこじ開けるよりも、正規の鍵で堂々と正面玄関から入るほうが、検知もされにくく確実です。

だからこそ攻撃者は、公開リポジトリや、たまたまアクセスできたサーバを、まず「鍵が落ちていないか」という目で漁ります。実際、世界中で公開リポジトリにうっかり置かれた認証情報を自動で探し回る動きが日常的に起きています。一度ネットワーク上に出てしまった鍵は、数分で見つかると考えておくのが安全です。今回のように、個人開発サーバという「死角」に置かれた鍵も、攻撃者の探索網に引っかかってしまったわけです。

ソースコードと自動化基盤が狙われる理由

今回、攻撃者はまずソースコードのリポジトリをコピーし、次にGitHub Actions（コードのテストや配布を自動化する仕組み、いわゆるCI/CD）を悪用しました。なぜこの2つが狙われるのかを理解しておくと、守るべき場所が見えてきます。

ソースコードは、いわばシステムの「設計図」です。中身を読めば、どんな仕組みで動いているか、どこに認証情報が埋め込まれているかが手に取るように分かります。攻撃者にとっては、次にどこを攻めればよいかを教えてくれる地図のようなものです。一方のCI/CD環境は、本来は開発者の作業を自動化するための便利な仕組みですが、強い権限を持つ認証情報がそこに集まりがちです。攻撃者がこの自動化基盤を握ると、正規の処理を装って好きなコードを実行し、さらに奥のクラウド環境へと手を伸ばせてしまいます。便利さと危うさは表裏一体で、自動化が進んだ現場ほど、その入り口の守りが重要になります。

つまり、リポジトリとCI/CDは「鍵が集まりやすく、かつ次の侵入の足場になりやすい」場所です。ここを攻撃者の目線で見直し、不要な鍵が眠っていないか、過剰な権限が与えられていないかを点検することが、被害の連鎖を断つうえで効いてきます。

中小企業が今日から実践できるシークレット管理

では、同じ落とし穴を避けるには何をすればよいのでしょうか。専任のセキュリティ担当がいない中小企業でも、今日から始められる現実的な対策を、優先度の高い順に整理します。大がかりなツール導入を前提にしていないものから挙げます。

1. シークレットスキャンを有効にする

最初にやってほしいのが「シークレットスキャン（secret scanning）」の有効化です。これは、リポジトリの中に認証情報らしき文字列が紛れ込んでいないかを自動で検知してくれる仕組みです。GitHubには無料で使えるシークレットスキャンの機能があり、公開リポジトリでは標準で有効になっています。さらに、認証情報を含むコードをアップロードしようとした瞬間にブロックする「プッシュ保護」という仕組みもあります。

つまり、「うっかり鍵を含めてしまった」段階で機械が気づいてくれる体制を、まず作るわけです。人間の注意力だけに頼ると、今回のような置き忘れは必ず起こります。機械的なチェックを入り口に置くことで、ヒューマンエラーを構造的に減らせます。設定画面から有効にするだけで始められるので、最も費用対効果の高い一歩と言えます。

2. 鍵をコードに「直書き」しない

そもそも認証情報をソースコードや設定ファイルに直接書き込まない、というのが大原則です。直書きしてしまうと、そのファイルがどこかにコピーされた瞬間、鍵も一緒に運ばれてしまいます。代わりに、認証情報は「環境変数」や、後述する専用の保管庫に置き、コードからはそれを呼び出す形にします。

あわせて重要なのが、間違って公開したくないファイルを管理対象から外す設定です。Gitには、特定のファイルを追跡対象から除外する仕組み（いわゆる除外設定ファイル）があります。認証情報や個人的な設定ファイルをここに登録しておけば、誤ってアップロードする事故を減らせます。Linuxサーバー上でのファイル権限や鍵ファイルの管理については、姉妹サイトLinuxMaster.JPでも基本を解説しています。

3. 個人の開発環境にも目を配る

今回の事案で見逃せないのが、漏えいの起点が「個人で使っていた開発サーバ」だった点です。会社の本番環境をいくら固めても、従業員の個人的な開発環境に会社の鍵が置かれていれば、そこが穴になります。仕事用の認証情報を、私的な環境やサービスに持ち込まないというルールを、明文化して共有することが大切です。

これは技術というより運用とルールの問題です。「悪気はなかった」で済まないのがセキュリティの厳しいところですが、裏を返せば、ルールを決めて周知するだけで防げる事故でもあります。便利だからと業務の鍵を個人環境にコピーする習慣を、組織として断ち切ることが、地味ですが効果の高い対策になります。

4. 鍵の権限を絞り、定期的に入れ替える

万が一鍵が漏れても被害を小さく抑えるために、認証情報には「最小限の権限」だけを与えるのが基本です。一つのトークンに何でもできる強い権限を持たせていると、漏れたときの被害が一気に広がります。必要な操作だけができる権限に絞っておけば、攻撃者が手に入れても動ける範囲を狭められます。

さらに、鍵には有効期限を設け、定期的に作り直す運用が有効です。古い鍵を使い回し続けると、いつどこで漏れたか分からないまま放置されがちです。CAMPFIREも対策として、個人用アクセストークンに依存しない認証方式への移行を進めたと公表しています。鍵を「発行しっぱなし」にせず、定期的に棚卸しして入れ替える習慣をつけましょう。

対策	やること	難易度・コスト
シークレットスキャン	GitHubの検知機能とプッシュ保護を有効化	低（設定のみ・無料機能あり）
直書き禁止	環境変数や保管庫を使い、除外設定を整備	低～中（運用の見直し）
個人環境のルール化	業務用の鍵を私的環境に持ち込まない明文化	低（ルール周知が中心）
権限最小化・定期更新	権限を絞り、有効期限を設けて入れ替え	中（運用の継続が要る）

Before / After｜シークレット管理を見直すと何が変わるか

これらの対策を入れる前と後で、攻撃者から見た「攻めやすさ」がどう変わるかを対比してみます。いずれも大きな予算を前提にしていません。

観点	Before（対策前）	After（見直し後）
鍵の混入検知	人の注意力頼みで見落としが起きる	シークレットスキャンが自動で検知・ブロック
鍵の置き場所	コードや設定に直書き、個人環境にも散在	環境変数・保管庫に集約し管理対象外に
漏れたときの被害	強権限の鍵で広範囲が一気に危険に	権限最小化で攻撃者の動ける範囲が狭い
鍵の鮮度	発行しっぱなしで放置されがち	有効期限と定期更新で古い鍵を一掃

After欄の鍵は「高価なツールを買う」ことではなく、設定と運用ルールの見直しにある点です。だからこそ、専任担当のいない組織にも現実的な打ち手になります。

もし鍵が漏れたら｜検知と対応の手順

対策をしていても、事故はゼロにはできません。大切なのは「漏れたかもしれない」と気づいたときに、慌てず順序立てて動けることです。ここでは、認証情報の漏えいが疑われたときの基本的な対応手順を整理します。

・ステップ1｜まず鍵を無効化する: 漏れた、または漏れた疑いのある認証情報は、何よりも先に無効化（失効）させます。鍵を作り直して古い鍵を使えなくすれば、攻撃者の入り口を塞げます。CAMPFIREも初動として不正利用された認証情報の無効化を実施しています。
・ステップ2｜影響範囲を確認する: その鍵で何にアクセスできたかを洗い出します。どのリポジトリ、どのクラウド環境、どのデータに手が届く鍵だったのかを把握しないと、被害の全体像がつかめません。
・ステップ3｜不正な痕跡を探す: アクセスログを確認し、見覚えのないアクセスや、不審なリソースの作成・操作がないかを調べます。今回の事案でも、攻撃者がCI/CD環境で勝手な処理を試したり、クラウドリソースを作成したりしていました。
・ステップ4｜不正なリソースを止める・消す: 攻撃者が作った不審なリソースやアクセス経路を停止・削除します。
・ステップ5｜再発防止と監視強化: なぜ鍵が漏れたのかを振り返り、ルールや仕組みを見直します。あわせてログ監視を強化し、次に同じことが起きたら早く気づける体制を整えます。

この手順の肝は「ステップ1の無効化を最優先にする」ことです。原因究明や報告も重要ですが、攻撃者がまだ鍵を使える状態を放置すると被害が広がり続けます。まず止血、それから精査、という順番を体に染み込ませておくと、いざというとき動けます。

よくある誤解と注意点

シークレット管理について、現場で陥りやすい誤解を整理しておきます。

・「公開しなければ大丈夫」: 非公開リポジトリでも、認証情報を直書きするのは危険です。今回のように、別経路でアクセスされれば中身は読まれます。
・「個人のサーバなら会社は関係ない」: 個人環境に会社の鍵を置けば、そこが会社への侵入口になります。私的・業務の線引きを認証情報にも適用する必要があります。
・「一度設定すれば終わり」: 鍵は発行して放置せず、定期的に棚卸しして入れ替えることで、漏れたときの被害を抑えられます。
・「うちは狙われない」: 攻撃者は公開された鍵を自動で探しています。規模に関係なく、ネットに鍵が出れば見つかると考えるべきです。

よくある質問（FAQ）

Q. シークレットスキャンは無料で使えますか?

GitHubには無料で使えるシークレットスキャンの機能があり、公開リポジトリでは標準で有効になっています。認証情報を含むコードのアップロードをブロックするプッシュ保護も提供されています。まずは設定画面から有効になっているかを確認するとよいでしょう。利用しているプランや設定によって範囲が異なるため、公式のヘルプで自社の条件を確認してください。

Q. すでに鍵を直書きしてしまったコードがあります。どうすれば?

まず、その鍵を無効化して作り直してください。過去のコミット履歴に残った鍵は、ファイルから消すだけでは履歴に残り続けます。確実なのは「漏れた鍵そのものを使えなくする」ことです。そのうえで、今後は環境変数や保管庫を使う運用に切り替えましょう。

Q. なぜ非公開リポジトリでも危ないのですか?

非公開でも、今回のように認証情報が別の経路で漏れれば、攻撃者にアクセスされます。リポジトリの中に鍵があると、一つの侵入から芋づる式に被害が広がります。公開・非公開に関わらず、鍵を直書きしない原則は変わりません。

Q. 個人で使う開発サーバにも会社のルールを適用すべきですか?

はい。今回の事案の起点は個人開発サーバへの認証情報の混入でした。業務用の鍵を私的な環境に持ち込まないというルールを明文化し、周知することが、技術的な対策と同じくらい重要です。

Q. 専任のセキュリティ担当がいない小さな会社でも何かできますか?

できます。シークレットスキャンの有効化、鍵の直書き禁止、個人環境への持ち込み禁止ルールの3つは、いずれも設定と周知が中心で、大きな投資を必要としません。まずこの3つから始めるのが現実的です。

Q. 鍵の権限を絞ると不便になりませんか?

多少の手間は増えますが、漏れたときの被害を大きく左右します。一つのトークンに強すぎる権限を持たせると、漏れた瞬間に広範囲が危険にさらされます。必要な操作だけに絞る習慣は、長い目で見れば安全とトラブル対応の手間を減らします。

Q. 漏えいが疑われたとき、最初にやるべきことは何ですか?

漏れた疑いのある認証情報を、何よりも先に無効化することです。原因究明や報告も大切ですが、攻撃者が鍵を使える状態を放置すると被害が広がり続けます。まず止血、それから影響範囲の確認という順番が基本です。

本記事のまとめ

CAMPFIREの事案は、従業員が発行したGitHubの認証情報が個人開発サーバに意図せず置かれ、それを起点に最大22万5846件の個人情報が漏えいするおそれにつながった、というものでした。高度な脆弱性ではなく「鍵の置き忘れ」という、どの現場でも起こりうるミスが入り口だった点に、私たちが学ぶべき教訓があります。

守る側がやるべきことは、決して特別ではありません。シークレットスキャンを有効にして機械に見張らせ、鍵をコードに直書きせず、業務用の鍵を個人環境に持ち込まないルールを徹底し、権限を絞って定期的に入れ替える。そして万一漏れたら、まず無効化を最優先に、順序立てて対応する。どれも専任担当のいない中小企業でも今日から始められます。誰かのミスを責めるのではなく、ミスが起きても被害が広がらない仕組みを作る。それが、この事案から受け取るべき本当の学びです。正しく備えて、落ち着いて守っていきましょう。