本文へスキップ
>_ITDITDセキュリティ対策プラットフォーム

セキュリティ対策

入口はバラバラ、終わり方は同じ——2026年の大型情報漏えい4件(KDDI・アフラック・デジタル庁・さくら)に共通する教訓

2026年に公表された国内の大型情報漏えい4件を、各組織の公式発表だけで比較。侵入口は未知の脆弱性・Webの照会機能・VPN機器とバラバラなのに、3社が再発防止策に「検知の強化」を挙げました。正規の利用と同じ形の攻撃に何が効くのかを整理します。

公開日 2026-09-11 更新日 2026-09-11 最終確認 2026-09-11 19分で読める

対象:自社のサービスや社内システムの守りを考える立場の方と、報道で名前を見た事案の要点を正確に知りたい方。本記事は各組織の公式発表を一次情報として比較する解説で、攻撃手順は扱いません。

4件を並べる(各組織の公式発表より)

組織(公表)対象(公表時点)侵入口(公表内容)発生から判明まで
KDDI(6月23日〜)メールアドレス 12,231,954名、うちパスワード 7,616,173名の漏えいを確認システムに組み込んだ第三者製ソフトウェアの脆弱性(確認時点でベンダーも未認識)5月16日から発生 → 6月17日に確認(約1か月
アフラック生命保険(6月30日〜)お客様 約440万人(うち口座情報 約22万人)、代理店 約4万店「オンライン相談」「よりそうネット」で、アクセスとデータ照会の手口に対する制御が不十分6月10日に最初の漏えい → 6月25日に判明(15日
デジタル庁(9月11日)職員等の個人情報 約24.6万件が漏えいした可能性VPN機器の脆弱性侵入の開始時期は非公表 → 6月25日に大量アクセスで検知
さくらインターネット(8月17日〜)会員情報 1,360,563アカウントが対象となる可能性、レンタルサーバー 951アカウント非公表(模倣攻撃防止のため)販売管理システムは2023年4月〜2026年3月 → 2026年8月9日に別の異常で検知(約3年

件数を横に比べて「どこが一番ひどいか」を読まない

この表の数字は確定の度合いが揃っていません。KDDIとアフラックは漏えいを確認した人数、デジタル庁は漏えいした可能性、さくらインターネットは対象となる可能性がある総数です。システムの性質も、保存されていた情報の種類も違います。件数の大小で順位をつけることに意味はなく、当サイトもそうしません。比べる価値があるのは、各組織が自分の事案から何を学んだと書いたか——再発防止策のほうです。

各事案で公表された要点

KDDI:ISP事業者向けメールシステム
何が
KDDIが開発し、ISP事業者向けに提供するメール基盤(アカウント管理・送受信・Webメール・メール保存を一体で提供)への不正アクセス。KDDI自身のauメール等は別設備で影響なしと説明
原因
「本システムの一部として導入していた第三者製のソフトウェアの脆弱性を悪用されたことによるもの」。確認時点(6月17日)で「本ソフトウェアベンダーが認識していない脆弱性」だったとしています
件数
初報(6月23日)では「最大1,422万件」の可能性。7月6日の報告(7月21日訂正)で、漏えいが確認されたのはメールアドレス12,231,954名、うちパスワード7,616,173名
対応
ISP事業者と連携してパスワード変更を進め、利用頻度の低い利用者も含めてISP事業者による強制変更を実施。6月21日に外部通信を制御する全サーバーへのEDR導入を完了。今後はよりセキュリティ強度の高い通信規格への移行を進めるとしています
アフラック生命保険:顧客向けWebサービスと代理店ツール
何が
代理店が非対面の保険設計・申込に使う「オンライン相談」と、契約者向けWebサービス「アフラック よりそうネット」への不正アクセス。同社は、それ以外のシステムで同種・類似の漏えいはないことを確認したとしています
原因(7月31日の調査結果)
「今回の攻撃で使われたアクセスとデータ照会の手口に対する制御が不十分であった」。検知・遮断の機能はあったが「アクセスの形式が通常の利用時と同様であったことから、不正アクセスとして直ちに検知することができませんでした」。さらに「短時間に大量のデータ照会があった場合に監視・制御する機能が不足していた」
事前の対策
設計時のセキュリティレビューとリリース前の侵入テストは実施していたが、「今回の攻撃で使われた手口に関するリスクを想定できていませんでした」
件数
お客様約440万人(うち保険料振替口座情報を含む約22万人)、代理店約4万店。マイナンバー、クレジットカード情報、メールアドレスは含まれていないとしています
デジタル庁:ガバメントソリューションサービス(GSS)
何が
各府省庁等の職員が共通で使う業務環境への不正アクセス。一般の方の個人情報は含まれていないことを確認したとしています
原因
「第三者がネットワーク接続機器(VPN)の脆弱性を利用してシステムに侵入」。製品名・脆弱性の識別番号は非公表
検知
6月25日、保守運用担当者のアカウントを利用したサーバ上の大量のファイルへのアクセスを検知。詳しくは VPN機器が最大の侵入口になっている で解説しています
さくらインターネット:販売管理システムとレンタルサーバー
何が
契約情報を管理する販売管理システムと、「さくらのレンタルサーバ」の一部環境への不正アクセス。両者の関連性を示す明確な根拠は確認されなかったとしています
期間
販売管理システムへの不正アクセスは「2023年4月以降、2026年3月までの間」。検知は2026年8月9日、レンタルサーバーのメンテナンス用サーバーの異常から
原因
侵入経路は模倣攻撃防止の観点から非公表。一部の初期パスワードがハッシュ化されていなかったことも公表。利用者向けの対応は レンタルサーバーが不正アクセスされたとき、利用者は何をすべきか にまとめています

共通していたのは「検知」だった

入口の話をすると4件はばらばらになります。しかし、各組織が自分で書いた再発防止策を並べると、同じ言葉が出てきます。

3 / 4
再発防止策に「検知・監視の強化」を明記した組織(KDDI・アフラック・さくら)
15日
アフラック:最初の漏えいから判明まで
約1か月
KDDI:発生から確認まで(未知の脆弱性)
約3年
さくら:販売管理システムへの不正アクセスが続いた期間

各社が挙げた「検知」の再発防止策

  • KDDI:不正アクセス検知の強化のため、外部通信を制御する全サーバーへのEDR導入(6月21日に完了)
  • アフラック:アプリケーションとセキュリティ機器における大量アクセスに対する監視と制御の強化
  • さくらインターネット早期検知を目的とした監視対象・検知機能の拡充、ログの取得範囲・保管期間・分析体制の見直し

デジタル庁は「検知が働いた」側

  • 異常に気づいたきっかけは、保守運用担当者のアカウントによる大量のファイルへのアクセス
  • 侵入は防げていないが、量の異常から範囲を確定し、アカウント停止と通信遮断に進めた
  • 再発防止策は「脆弱性管理方法の見直し」「外部からの接続方法の改善」=入口側

正規の利用

ログイン → 自分の契約を照会 → 数件を閲覧

正規の形をした攻撃

ログイン → 照会 → 閲覧(ここまで同じ形)

1人が数件か、数万件か

速さ

人の操作の速度か、機械の速度か

時間の長さ

遡れるだけのログが残っているか

攻撃が正規の利用と同じ形をしていると、「何をしたか」では見分けられない。残る手がかりは「どれだけ」と「いつ」だけになる。

自分の組織で、今日やること

1

データを返す機能に「量の上限」と通知を付ける

アフラックが挙げた原因のひとつは「短時間に大量のデータ照会があった場合に監視・制御する機能が不足していた」ことでした。顧客情報を返すAPIや画面に、1回あたり・1時間あたりに返せる件数の上限と、上限に近づいたら人に知らせる通知を付けます。正しいログインで入られた場合でも、数万件を短時間で持ち出す動きは、人の使い方と形が違います。何を・誰単位で・いくつまで数えるかの設計は レート制限と濫用対策 で詳しく扱っています。

2

照会のたびに「この人がこのデータを見てよいか」を確かめる

アフラックの再発防止策の1つ目は「アクセス時における認証およびデータ照会時の認可」の強化です。ログインできたかどうか(認証)と、そのデータを見てよいかどうか(認可)は別の問題で、後者を1件ごとに確かめていないと、正しくログインした人が他人のデータまで照会できてしまいます。この違いは 認証と認可の違い、典型的な欠陥は IDOR で解説しています。

3

ログを「気づいたときに遡れる期間」だけ残す

さくらインターネットの事案では、販売管理システムへの不正アクセスが約3年前から始まっていました。気づいたときに、その期間のログが残っていなければ、何が起きたかも、何が起きなかったかも言えません。同社も再発防止策にログの取得範囲と保管期間の見直しを挙げています。容量の都合で数週間分しか残していないなら、少なくとも認証とデータ照会のログだけは長く残す、という切り分けが現実的です。

4

「未知の脆弱性は必ずある」前提で、入られた後に気づく

KDDIの件で悪用されたのは、確認時点でベンダー自身も認識していなかった脆弱性でした。当時は適用できる修正が存在しません。更新を完璧に回していても防げない入口がある以上、サーバー上の不審な動き・外部への通信に気づく仕組み(KDDIが全サーバーに導入した EDR はその一例)が最後の防御になります。

5

それでも入口の更新は続ける

検知が大事だという話は、入口の守りを軽くしてよいという意味ではありません。デジタル庁の事案はVPN機器の脆弱性が入口でした。既知の脆弱性を放置しない運用は、今もいちばん費用対効果が高い守りです。VPN機器については VPN機器が最大の侵入口になっている、優先順位の付け方は CVSS・EPSS・KEVで優先順位を決める を参照してください。

当サイトの視点:侵入テストは「想定した手口」しか見つけない

アフラックの調査結果でいちばん重い一文は、原因そのものより「システム設計時のセキュリティレビューやシステムリリース前の侵入テストを実施していましたが、今回の攻撃で使われた手口に関するリスクを想定できていませんでした」という部分だと当サイトは考えます。対策をやっていなかったのではなく、やっていたのに想定の外から来た——これはどの組織にも起こりうることです。

事前の検査は、検査する側が思いついた手口しか確かめられません。だから最後の網は、本番で「普段と違う量・速さ・時間帯」に気づく仕組みになります。4件のうち3社がそろって検知を再発防止策に挙げたのは、この限界にそれぞれの事案でぶつかったからだと読めます。レビューとテストは「入口を減らす」ため、検知は「入られた後の時間を縮める」ため——役割が違うので、片方でもう片方は埋まりません。

個人として、今日やること

事故の件数より、自分に届く「便乗の連絡」のほうが現実の危険

①同じパスワードを使い回さない——KDDIの件ではパスワードの漏えいが確認されています。同じパスワードを他のサービスで使っていれば、そちらが開きます(パスワードマネージャーが現実解です)。②組織名を名乗る連絡のリンクや電話番号を使わない——デジタル庁とさくらインターネットは組織を装った連絡への注意を明記し、アフラックも不審な連絡を受けた場合は窓口へ連絡するよう求めています。確認は公式サイトに自分でアクセスして行います。③口座情報が対象なら取引を確認する——アフラックは口座情報が漏えいした契約者について金融機関と連携するとしています。不審な取引があれば、金融機関と当該組織の窓口の両方に連絡してください。

出典(公開記録)

本記事の事実関係は、以下の各組織の公式発表にもとづきます。公表されていない製品名・侵入経路は推測していません。

  • KDDI株式会社「ISP事業者向けメールシステムに対する不正アクセスの発生について」(2026年6月23日) — newsroom.kddi.com
  • KDDI株式会社「ISP事業者向けメールシステムに対する不正アクセスについてのお詫びとご報告」(2026年7月6日、7月21日更新) — newsroom.kddi.com
  • アフラック生命保険株式会社「当社システムに対する不正アクセスの発生および情報漏えいに関するお詫びとお知らせ(第二報)」(2026年7月13日) — aflac.co.jp
  • アフラック生命保険株式会社「当社システムに対する不正アクセスの発生および情報漏えいに関する調査結果と再発防止策について」(2026年7月31日) — aflac.co.jp
  • デジタル庁「ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について」(2026年9月11日) — digital.go.jp
  • さくらインターネット株式会社「当社システムへの不正アクセスに関する調査結果および再発防止策について(第三報)」(2026年9月10日) — sakura.ad.jp

更新履歴

2026-09-11:初版。4組織の公式発表(2026年9月11日時点で公開されている最新のもの)にもとづく。各事案で続報が出た時点で更新します。

次に読む

よくある質問

Q2026年に国内で公表された大型の情報漏えいには、どんなものがありますか?
A

各組織の公式発表によれば、KDDIのISP事業者向けメールシステム(メールアドレス12,231,954名・うちパスワード7,616,173名の漏えいを確認)、アフラック生命保険(お客様約440万人、うち保険料振替口座情報を含む約22万人、代理店約4万店)、デジタル庁のガバメントソリューションサービス(職員等の個人情報約24.6万件が漏えいした可能性)、さくらインターネット(会員情報1,360,563アカウントが対象となる可能性)などがあります。件数は各社が公表した時点の数字で、確定の度合いは事案ごとに異なります。

Qアフラックの情報漏えいの原因は何だったのですか?
A

アフラックは2026年7月31日の調査結果で、『オンライン相談』と『アフラック よりそうネット』のシステムにおいて、攻撃で使われたアクセスとデータ照会の手口に対する制御が不十分だったと公表しています。不正アクセスを検知・遮断する機能は備えていたものの、アクセスの形式が通常の利用時と同様だったため直ちに検知できず、短時間に大量のデータ照会があった場合に監視・制御する機能も不足していたと説明しています。

QKDDIの件はパッチを当てていれば防げたのですか?
A

KDDIの説明では、悪用されたのはシステムの一部として導入していた第三者製ソフトウェアの脆弱性で、KDDIが不正アクセスを確認した2026年6月17日の時点では、そのソフトウェアのベンダーも認識していない脆弱性でした。つまり当時は適用できる修正が存在しなかったことになります。こうした未知の脆弱性に対しては、侵入された後に気づき、広がりを止める仕組みが最後の防御になります。

Q4件に共通する教訓は何ですか?
A

侵入口は互いに似ていません。それでもKDDI・アフラック・さくらインターネットの3社は再発防止策に検知の強化(全サーバーへのEDR導入、大量アクセスの監視と制御、早期検知の監視拡充とログ保管期間の見直し)を挙げ、デジタル庁は大量のファイルアクセスという量の異常で気づけた事案でした。攻撃が正規の利用と同じ形をしているとき、残る手がかりは量と時間です。入口を守る努力は続けつつ、入られた後に気づく仕組みへ同じだけ投資する必要があります。

Q個人として何をすればよいですか?
A

3つです。同じパスワードを複数のサービスで使い回さない(KDDIの件ではパスワードの漏えいが確認されています)。事故に便乗した、組織名を名乗る連絡のリンクや電話番号を使わず、公式サイトに自分でアクセスして確認する。口座情報が対象の場合は、口座の取引を確認し、不審な点があれば金融機関と当該組織の窓口に連絡する。