2026年に入ってから、名の知れたサービスが立て続けにGitHub経由の情報漏洩を公表した。会計SaaS大手のマネーフォワードも、クラウドファンディングのCAMPFIREもそうだ。
最初にニュースを見たときは「大手でもやられるのか」くらいの感想だった。でも詳細を追うほど、これは他人事じゃないなと背筋が冷えた。漏れ方の構造が、自分が支援している会社でも普通に起こり得るものだったからだ。
情シスとして本当に見るべきなのは「大手が」でも「GitHubが」でもない。認証情報と権限の管理が甘いと、規模に関係なく同じ落ち方をする——そこだ。結論から言うと、大がかりなツール導入の前に、まず「棚卸し」でリスクの大半は潰せる。この記事では、事件を材料に、情シスが自社で今日やることに落とし込む。
- ▶ 大手SaaSの漏洩が「認証情報の管理不徹底」で起きているという共通構造
- ▶ 開発をしていない会社の情シスにも直結する理由
- ▶ 認証情報と権限を「維持コストのかかる資産」として捉える考え方
- ▶ 情シスが今日から着手できる棚卸しの3ポイント
▼ 大手でも「認証情報がコードに書いてあった」で漏れる
マネーフォワードの公表内容を事実だけ拾うと、こうだ。ソフト開発とシステム管理に使っているGitHubの認証情報が漏れ、それを使った第三者の不正アクセスでリポジトリ（ソースコードの保管庫）がコピーされた。中に含まれていたファイルから、ビジネスカードの保持者名と番号下4桁など一部の個人情報が流出した可能性がある、という流れだ。
本番データベースからの漏洩は確認されていない、と後続の報告で明言されている。つまり「本丸のDBを破られた」わけではない。問題はもっと手前、開発環境の側に認証情報や個人情報が置かれていたことにある。
①認証情報（鍵・トークン・パスワード）が漏れた → ②それでアクセス権を奪われた → ③本来そこに無いはずの情報まで一緒に持っていかれた。
この3段構えは、GitHubに限らずあらゆるSaaSアカウントで再現する。
マネーフォワードが発覚後すぐにやったのは、侵害経路になった認証情報の無効化とアカウント遮断、そしてソースコードに含まれていた各種認証キー・パスワードの一斉洗い替えだった。銀行連携機能も即座に止めている。裏を返せば、「止める」「鍵を全部作り直す」を素早く判断できるかが、二次被害を防ぐ最後の砦だったということだ。
▼ 「うちは開発してないから関係ない」が一番危ない
ここで多くの情シスが「開発会社の話でしょ」と流す。これが危ない。
認証情報の直書きや権限の放置は、GitHubだけの現象じゃない。SaaS全盛のいま、APIキー・トークン・共有パスワードは、開発をしていない会社にも普通に散らばっている。ある会社で棚卸しをかけたとき、こういうものがゾロゾロ出てきた。
- ▶ 業務ツール連携のために発行した、有効期限なしのAPIキーがスプレッドシートに平文で貼ってある
- ▶ 退職したエンジニアが作った自動化スクリプトが、誰も中身を知らないまま今も動いている
- ▶ 「全員で使う」共有アカウントのパスワードが、Slackの過去ログを漁れば出てくる
これらは全部、今回の事件と同じ構造だ。鍵が管理されずに転がっていて、それを握れば本来アクセスできないものに手が届く。開発の有無は関係ない。
▼ 認証情報と権限は「作った瞬間から維持コストが発生する資産」
ここが持論だ。AIやSaaSのおかげで、連携やトークン発行みたいな「作る」コストは劇的に下がった。数クリックでAPIキーが出る。でも作成コストが下がっても、維持コストは1ミリも下がっていない。
発行したトークンは、誰かが定期的に棚卸しして、要らなくなったら消して、生きているものはローテーションする——この維持を続けないと安全は保てない。そして維持コストは、作った本人が意識しない限り誰も払わない。
オーナーが決まっていない認証情報や権限は、時間が経つと「誰が管理してるか分からない」状態になる。誰のものでもない鍵は、実質、それを拾った人のものだ。漏れたとき、社内の誰も「それ自分の担当です」と言えない。
だから設計の起点は「誰がこの鍵のオーナーか」を明示することにある。触る人がいる限り、明示的にオーナーを決めない限り、その責任は宙に浮く。
▼ 情シスが今日から棚卸しすべき3つ
大がかりなツール導入の前に、まず現状把握だ。次の3つを洗う。
| 棚卸し対象 | 具体的に見るもの | 危険サイン |
|---|---|---|
| ①認証情報のありか | APIキー・アクセストークン・共有パスワードが、どこに、どんな形で保存されているか | スプレッドシートやチャット履歴に平文で存在している |
| ②アクセス権の棚卸し | 各SaaSの管理者権限・連携アプリ・トークンの一覧。退職者・異動者の権限が残っていないか | 「なぜこの人がAdminなのか」を誰も説明できない |
| ③止める手順の有無 | 漏洩が疑われたとき「連携を止める・鍵を作り直す」を誰がどう判断するか | インシデント時の手順書（ランブック）が存在しない |
①は「鍵がコードや平文に書かれていないか」の話で、まさに今回の事件の核心。②はPAT（個人アクセストークン）やOAuth連携アプリ、各SaaSの管理者権限を定期的に見直し、不要なものを無効化する。退職者・異動者のアクセス権が残ったままになっていないかは最優先で確認したい。③は、事故が起きてから手順を考えていては遅い、という話だ。
理想は、鍵をコードに書けない仕組みが仕込まれていて、権限は最小で、キーのローテーションが自動で回り、止める手順が用意されている状態。ここまで一気にやる必要はない。まず「棚卸しして、要らないものを消す」だけでもリスクは大きく下がる。
▼ 「触ると壊れるから放置」が事故の温床
棚卸しをすると、必ず「触ると何が壊れるか分からないから放置されている鍵」が見つかる。動いているスクリプト、名前だけの連携アプリ、消していいか判断できない管理者アカウント。
この「触ると壊れるから放置」こそが、ローテーションされない鍵を生み、オーナー不在を固定化する。放置は楽だが、放置された鍵は年月とともに「誰も止め方を知らない爆弾」になっていく。怖くて触れないものほど、優先的に棚卸しの対象にすべきだ。
▼ まとめ
- ▶ 大手の漏洩は「認証情報の管理不徹底」で起きている。規模ではなく管理の問題だ
- ▶ 認証情報・権限の直書きや放置は、開発をしない会社にも普通に潜んでいる
- ▶ 鍵と権限は「作った瞬間から維持コストが発生する資産」。作成が楽になった分、放置されやすい
- ▶ オーナーが決まっていない鍵は、実質、拾った人のものになる
- ▶ まずは「認証情報のありか・アクセス権・止める手順」の3点を棚卸しする
📅 30分無料相談、受け付けています
「認証情報や権限がどこにどれだけあるのか把握できていない」「何から手をつければいいかわからない」——そういった段階からお気軽にどうぞ。棚卸しの入口を一緒に整理します。
📅 30分無料相談を予約する →