IIJの情報漏えいとは？セキュアMX侵害・影響範囲・公表内容を整理

IIJの情報漏えいで何が起きたのか

最初に分けるべきなのは、第一報の「可能性」と第二報の「事実確認」です

IIJ セキュアMX事案を読むときに最初に固定したいのは、4月15日の第一報と4月22日の第二報の役割の違いです。第一報は、4月10日に漏えいの可能性を確認したあと、影響が否定できない全契約を対象に広く知らせた公表でした。したがって、6,493契約、4,072,650メールアカウントという数字は、いきなり「確定被害件数」を意味しません。

一方、第二報では調査が進み、電子メールアカウント・パスワード、メール本文・ヘッダ情報、他社クラウドサービス認証情報について、どの契約で漏えい事実が確認されたかが示されました。重複を除いた確認済み契約数は 586契約です。この 2 つを同じ表現で読んでしまうと、影響範囲を過大にも過小にも誤解しやすくなります。

この事案は、利用企業の設定不備ではなく、サービス事業者側設備の侵害でした

IIJ の第一報では、IIJ セキュアMXサービスのサービス設備が 2024年8月3日以降に不正アクセスを受け、設備上で不正なプログラムが実行されていたと説明されています。つまり主役は、利用企業ごとの運用ミスや誤送信ではなく、サービス事業者側設備が侵害された incidentです。

この点が重要なのは、同じ「情報漏えい」でも、読むべき論点が変わるからです。自治体の USB 紛失や委託先の持ち出し事故なら物理持ち出し管理が主役になりますが、IIJ 事案ではサービス基盤への不正アクセス、第三者製ソフトウェア脆弱性、通信の秘密、監視体制が主役になります。したがって、このページも一般的なメール誤送信対策ではなく、IIJ セキュアMX事案そのものの整理に寄せています。

4月10日確認から 7月18日行政指導まで、論点は段階的に変わりました

4月10日から 4月15日までは、「漏えい可能性があるため広く告知し、経路を切り離して安全に使える状態へ戻した」ことが主題です。4月18日から 4月22日にかけては、原因となった脆弱性が対外的に公表され、IIJ も第二報で確認済みの漏えい事実を整理しました。7月18日になると、事案は総務省の行政指導を受ける通信の秘密の漏えい事案として扱われています。

つまりこの事案は、「4月15日に全部分かった」わけではありません。可能性の広報、脆弱性原因の外部公表、事実確認、再発防止策、行政対応という順番で見た方が、検索意図に対して最短で答えられます。

何が漏えいし、どこまで確定したのか

6,493契約は「広く知らせるための数字」、586契約は「確認済みの数字」です

この事案で最も誤読されやすいのは、第一報の 6,493契約と第二報の 586契約を同列に扱ってしまうことです。第一報では、影響が否定できないすべての契約と情報を対象に、可能性があるものを広く告知する方針が採られています。過去に利用終了済みの契約も含めたのは、過少告知を避けるためだと読むのが自然です。

第二報はこれと逆で、調査が進んだ結果として、実際に漏えい事実が確認された契約数を出しています。したがって、検索意図が「IIJ で結局どこまで確認されたのか」にあるなら、586契約という数字を主役にしつつ、「なぜ第一報では 6,493契約だったのか」も合わせて説明しないと不親切です。

メール本文は 6契約、他社クラウド認証情報は 488契約と、項目ごとに重みが違います

第二報では、漏えい事実が確認された情報が 3 つに分かれています。メール本文・ヘッダ情報は 6契約にとどまる一方、他社クラウドサービス認証情報は 488契約で確認されています。つまり、「メールサービスだからメール本文だけが論点」という単純な構図ではありません。

むしろ実務上は、他社クラウドサービスの認証情報が相対的に大きい ことが読みどころです。メールセキュリティサービスに連携した外部クラウド認証情報が流出すると、メールそのものだけでなく、周辺の業務導線や連携先評価も必要になります。この点は、SaaS ベンダーリスクやSaaS 台帳管理とも接続しますが、本記事ではあくまで IIJ 事案で公式に確認された範囲にとどめています。

契約終了済み顧客も対象に含まれた点は、通知設計の重さを示しています

第一報では、2024年8月3日時点で利用終了していた契約についても、電子メールアカウントや他社クラウド認証情報の漏えい可能性対象として案内されています。これは、現契約の顧客だけに閉じた incident ではなく、過去に利用していた顧客まで含む長い裾野を持つ事案だったことを示しています。

そのため、この事案を「一部顧客だけの局所インシデント」と表現するのはやや雑です。IIJ は第二報でも、現契約顧客には担当者と IIJサービスオンライン、過去顧客には専用フォームという形で案内線を分けています。検索意図の観点でも、「自社は対象か」「どの情報が対象か」を知りたい読者が多いので、この部分は省けません。

原因と行政対応で押さえるべき点

原因は Active! mail の未発見脆弱性悪用と整理されています

IIJ の第二報では、本件の不正アクセス原因は IIJ セキュアMXサービスで利用していた第三者製ソフトウェアの脆弱性を悪用されたことによるものだと明記されています。さらに、その脆弱性は不正アクセス発生から発覚のタイミングでは未発見であり、今回の事案を通じて初めて明らかになったものだとも説明されています。

ここで外部の一次資料として重なるのが、JVN#22348866↗です。JVN は 4月18日に Active! mail のスタックベースのバッファオーバーフロー脆弱性を緊急公表し、悪用済みであること、遠隔から任意コード実行や DoS を引き起こす可能性があること、修正版が 6.60.06008562 であることを示しています。IIJ 第二報が JVN を参照しているため、原因理解はこの 2 つを並べるとぶれにくくなります。

第二報は「脆弱性があった」だけでなく「現在そのソフトウェアを使っていない」とまで示しています

第二報では、原因となった第三者製ソフトウェアによるオプション機能は 2025年2月をもって提供終了しており、現在は利用していないとも説明されています。これは読者にとって重要で、「同じ形で今も露出しているのか」という問いへの一部回答になります。

ただし、これをもって「問題は完全に終わった」と読むのは早計です。なぜなら、7月18日には総務省の行政指導へ進んでおり、論点が単なる一つの脆弱性対応から、監視体制、再発防止、全社セキュリティ統制に広がっているからです。

7月18日の行政指導は、技術対策だけでなく監視体制と全社管理が論点だったことを示します

7月18日の IIJ 公表↗では、総務省から通信の秘密の漏えい事案として書面による行政指導を受けたことが示されています。ここで IIJ は、サービス設備における振る舞い検知機能の強化を 6月26日に完了し、Web アプリケーションファイアウォールの多層化による防御強化を 7月中に完了見込みだと説明しています。

さらに、社長直轄プロジェクトを発足し、IIJ セキュアMXサービスを含めたサービス全体のセキュリティレベルを従前水準より高めるとしています。つまりこの事案は、「脆弱性を塞いだ」で終わるのではなく、監視と経営レベルの再発防止まで見ないと整理が不完全です。

事案後の公開導線棚卸しなら ASM診断 PRO

先に明確にすると、ASM診断 PRO は IIJ セキュアMX事案そのものを防いだと主張する製品ではありません。メールサービス基盤内部の脆弱性悪用や通信の秘密の漏えいを直接防ぐ代替策でもありません。ただし、incident 後に外から見える公開導線や管理漏れを洗い直す入口としては使いやすい構成です。

たとえば incident 後には、公開された管理画面、旧ホスト、サポート導線、古いドキュメント、残存 subdomain、staging、外部公開 API、FAQ ページ、問い合わせフォームなどを改めて確認したくなります。内部調査とは別に、外部から見える面を洗い直しておくと、説明用の棚卸しや対外報告の整理が進めやすくなります。

その意味で ASM診断 PRO は、今回の原因説明ではなく、公開面の現状確認を始める導線として位置付けるのが自然です。外部公開資産台帳やセキュリティレポート雛形と一緒に使うと、incident 後の整理へつなげやすくなります。

よくある質問（FAQ）

IIJ の全顧客で漏えいが確定したのですか

いいえ。4月15日の第一報では、IIJ セキュアMXサービスの全契約 6,493契約を「漏えい可能性が否定できない範囲」として広く告知していますが、4月22日の第二報で漏えい事実が確認された契約は重複除外後で 586契約です。第一報と第二報の数字は意味が異なります。

メール本文まで漏えいしたのですか

IIJ の第二報では、メール本文・ヘッダ情報の漏えい事実が確認された契約は 6契約とされています。したがって、「メール本文が広範囲で漏れた」と一括で読むのは正確ではありません。一方で、他社クラウドサービス認証情報は 488契約で確認されており、こちらの方が広い論点になっています。

原因は Active! mail の脆弱性だったのですか

IIJ の第二報は、IIJ セキュアMXで利用していた第三者製ソフトウェアの未発見脆弱性悪用が原因だったと説明しており、4月18日には JVN が Active! mail の緊急脆弱性情報を公表しています。したがって、公式資料ベースでは Active! mail 系の脆弱性公表と本件原因は接続して読めます。

なぜ総務省の行政指導まで進んだのですか

7月18日の IIJ 公表では、本件が通信の秘密の漏えい事案として総務省の書面指導対象になったと説明されています。つまり単なる障害や一時的な不正アクセスではなく、通信事業者としての説明責任と再発防止体制が問われる事案になったということです。

SaaS ベンダーリスクや委託先管理の記事と何が違うのですか

本記事は IIJ セキュアMX事案そのものの時系列、影響範囲、公表内容、行政対応を整理する事例整理ページです。一般論としての委託先評価はSaaS ベンダーリスク、委託先アカウント管理の一般論は業務委託先セキュリティが主役です。役割を分けることで、指名検索の読み手が迷いにくくなります。

まとめ

IIJ の情報漏えいは、4月10日の確認、4月15日の第一報、4月18日の JVN 公表、4月22日の第二報、7月18日の総務省行政指導を分けて読むと整理しやすくなります。特に重要なのは、第一報の 6,493契約は広い可能性通知であり、第二報の 586契約は確認済み契約数であること、そして原因が第三者製ソフトウェアの未発見脆弱性悪用だったことです。

• 4月15日の数字と 4月22日の数字は役割が違うため、同じ意味で比べない方がよい
• メール本文よりも、他社クラウドサービス認証情報 488契約の方が広い実務影響を持つ
• 4月18日の JVN 公表と第二報を並べると、原因理解が安定する
• 7月18日の行政指導まで追うと、技術対策だけでなく監視体制と全社統制の見直しが論点だったと分かる

まずは IIJ と JVN の一次資料で時系列を固定し、そのうえで必要ならセキュリティレポート雛形や外部公開資産台帳へ落とし込んでください。incident 後に外から見える公開導線も洗い直すなら、アタックサーフェスやサブドメイン監視も合わせて見ると整理しやすくなります。