セキュリティ対策
2026年の情報漏えいは「脆弱性」より「正規の認証情報」で起きている — 国内事案の横断分析
2026年8月に国内で公表されたインシデントを並べると、侵入経路の主流がはっきり見えます。脆弱性を突かれた事案より、正規の認証情報やアカウントを使って入られた事案のほうが多い——委託先のMicrosoft 365、BIツール、社用メール、GitHubの認証情報、事業者の管理環境。公表内容にもとづいて経路で分類し、パッチ運用では埋まらない部分に何を置くべきかを整理します。
対象：自社や自分のサイトのセキュリティを考えている人。ここでは個別事件の詳細ではなく、**2026年8月に国内で公表された事案を並べたときに見える「経路の傾向」**を扱います。事実はすべて各社の公表内容と報道にもとづき、原因の推測は行いません。
経路で分類する
各社の公表内容にもとづく分類です（数値・原因はいずれも公表された範囲のみ）。
| 公表 | 組織 | 起点となった場所 | 分類 |
|---|---|---|---|
| 8/3 | 講談社 | 社用メールアカウント（連絡先が窃取され、一部宛にその社員を装ったメールが送信された） | 認証情報 |
| 8/4・8/7 | イノベーション | GitHubの認証情報（設定ファイルへの直書きと、リポジトリ内の個人情報という二重の不備を公表） | 認証情報 |
| 8/13 | チャーム | ECサイトへの不正アクセス（約23万件・パスワードのハッシュ値を含む） | システム直撃 |
| 8/14 | ニチレイ | ランサムウェア攻撃（7/13にシステム障害。従業員情報が漏えいの恐れ） | システム直撃 |
| 8/17・8/19 | さくらインターネット | 事業者の管理環境と契約情報を管理するシステム（対象となり得る会員情報 1,360,563アカウント） | 認証情報／事業者側 |
| 8/20 | 大阪・関西万博協会 | 再委託先のMicrosoft 365（5/13のフィッシングメールが発端） | 認証情報／委託先 |
| 8/20 | VOISING | BIツールへの不正アクセス（最大約17万人） | 認証情報／SaaS |
| 8月 | 科学技術振興機構（報道） | メールボックスへの不正アクセス（約16,000通） | 認証情報 |
| 8/12 | OCS（ANAグループ・報道） | プログラムの脆弱性 | システム直撃 |
数字の読み方
上表の件数・人数は各社が公表した時点の値で、多くは調査継続中です。特にさくらインターネットの 1,360,563 は「対象となる可能性のある会員情報の総数」であって、漏えいが確定した件数ではありません（同社はデータの外部持出しは現時点で確認されていないとしています）。調査中の数字を確定値のように扱わないことは、この種の記事を読むときの基本です。
なぜ「自分の城」を固めても止まらないのか
起点：あなたの外にある正規の入口
委託先のM365 ／ BIツール ／ 社用メール ／ GitHubトークン ／ 事業者の管理環境
攻撃者は「正規の操作」をする
奪った認証情報で普通にログインし、普通にデータを読む
あなたのサーバー（無傷）
パッチも WAF も CSP も、この経路の上に無い
脆弱性を突く攻撃は「壊して入る」ので、直せば塞がります。しかし**認証情報を使う攻撃は「鍵を持って入る」**ので、塞ぐべき穴が存在しません。守るべきは穴ではなく、鍵そのもの——誰が持っていて、どこに置いてあり、いつまで有効か、です。
この型に効かないもの
- パッチ運用：脆弱性を1つも使わない攻撃には無関係
- WAF・IPS：正規のログインは異常な通信に見えない
- 「うちは小さいから狙われない」：狙われたのは委託先や事業者で、あなたは巻き添え
- 契約形態の変更：VPSに移しても、盗まれるのは認証情報
この型に効くもの
- 多要素認証（特にメールとGitHubとSaaSの管理者）
- 認証情報の寿命を短く、範囲を狭く（長期トークンをやめる）
- 委託先とSaaSの棚卸し——誰が自分のデータに触れるかの一覧
- 秘密を設定ファイルに直書きしない／リポジトリに個人情報を置かない
- 「読まれた前提」での被害想定（何が置いてあるかを減らす）
今日からできること
『自分の外にある入口』を一覧にする
契約しているホスティング／SaaS／BIツール／メール基盤／コード管理、そして委託先。この一覧が無いと、事故のニュースが出たときに「自分は対象か」すら判断できません。作り方は 資産棚卸しチェックリスト にまとめています。
メールとコード管理に多要素認証を最優先で入れる
上表で起点になった場所のうち複数がメールとコード管理の認証情報です。この2つは、取られるとそこから他のすべてを再発行できてしまう入口なので、優先度が違います。→ 多要素認証の選び方
長期の認証情報を棚卸しして、寿命と範囲を切る
設定ファイルへの直書き、期限のないアクセストークン、全リポジトリに効く鍵。盗まれることを前提に、盗まれても使える範囲と時間を小さくします。→ .envとAPIキーの基礎 ／ gitleaksでコミット前に止める
事業者側が落ちた場合の想定を1回やっておく
「契約先が侵害された」という通知が来たとき、自分は何を失うのか。この問いに事前に答えておくと、当日やることが決まります。→ レンタルサーバーが不正アクセスされたとき利用者は何をすべきか
便乗フィッシングを想定に入れる
大規模事案の直後は、その事案を騙るメールが必ず増えます。実際に8月の事案では、窃取された連絡先に対してその社員を装ったメールが送信されたことが公表されています。「事故のお知らせ」メールこそ、リンクを踏まず公式サイトへ自分で行く。→ フィッシングとは
当サイトの視点：これは『大企業の話』ではない
上表には大きな組織が並びますが、起点になった場所は規模と無関係です——メールアカウント、SaaSの管理者権限、リポジトリに置いた認証情報。個人開発でも中身は同じで、むしろ小規模ほど外部サービスへの依存度が高く、1つの認証情報が広い範囲に効いてしまいがちです。当サイトの立場は一貫していて、「壊されないようにする」より「鍵を配りすぎない・置きっぱなしにしない」ほうが、いまは効きます。パッチ運用は前提として続けたうえで、重心をそちらに移すという話です。
出典
事実関係は各社の公表と報道にもとづきます。原因や責任の断定は行わず、公表された範囲のみを扱っています。
- さくらインターネット — 第一報（8/17）／第二報（8/19・8/26更新）／FAQ
- 2025年日本国際博覧会協会 — 再委託先における不正アクセス事案に関するご報告とお詫び（8/20）
- 講談社 — 不正アクセスによる個人情報流出のお詫びとお知らせ（8/3）
- チャーム — 不正アクセスによるシステム障害発生に関するお知らせとお詫び（8/13）
- イノベーション — GitHubへの不正アクセスに関する詳細調査の完了（確定報・8/7）
- ニチレイ関連の報道 — ＠IT（8/15）
- VOISING関連の報道 — ITmedia NEWS（8/21）
次に読む
- 備え：資産棚卸しチェックリスト ／ 多要素認証の選び方
- 事業者側の事故：レンタルサーバーが不正アクセスされたとき、利用者は何をすべきか
- 認証情報の窃取：npm install 一発で認証情報が抜かれる ／ .envとAPIキーの基礎
- 事例：KADOKAWA ランサムウェア事件（2024）（フィッシングで盗まれた認証情報が起点）
よくある質問
Q2026年の情報漏えいで一番多い侵入経路は何ですか？
2026年8月に国内で公表された主要事案を各社の発表にもとづいて分類すると、ソフトウェアの脆弱性を突かれたものより、正規の認証情報やアカウントを経由して入られたもののほうが多くなりました。具体的には、委託先のMicrosoft 365アカウント、BIツール、社用メールアカウント、GitHubの認証情報、そしてサービス提供事業者の管理環境です。
Qパッチを当てていれば防げますか？
この型には効きません。正規の認証情報で入られる攻撃は、脆弱性を1つも使わないことがあります。パッチ運用は別の攻撃型に対して必要ですが、認証情報型には『認証情報の寿命と範囲』『多要素認証』『委託先とSaaSの棚卸し』という別の対策が要ります。どちらか一方では穴が残ります。
Q自社が直接攻撃されなくても被害を受けるのですか？
受けます。2026年8月の事案では、再委託先が受け取ったフィッシングメールを起点に委託元の関係者情報が漏えいの可能性となったケース、契約しているホスティング事業者側が侵害されたケースがあります。いずれも自社のサーバーは無傷でも影響を受けます。だから『自分が使っている外部』の一覧を持つことが防御の一部になります。
Q個人や小規模でも同じことが起きますか？
起きます。むしろ小規模ほど、SaaSと外部サービスへの依存度が高くなります。同じ月には、設定ファイルに認証情報を直書きしたことが起点となった事案も公表されています。規模ではなく『どこに認証情報が置いてあり、誰が使えるか』が分かれ目です。