ニチレイへのサイバー攻撃で何が起きた? RansomHouseの主張と情報漏えいの可能性・供給網への影響

Share
「ニチレイへのサイバー攻撃で何が起きた?RansomHouseの主張と情報漏えいの可能性・供給網への影響」アイキャッチ画像

2026年7月13日、ニチレイは不正アクセスによるシステム障害を公表しました。影響は冷蔵倉庫の入出庫や冷凍食品の出荷に及び、7月24日に全拠点が通常稼働へ移行しました。その後、RansomHouseを名乗るグループによる犯行声明や、20万件以上のファイル公開が報じられています。本記事では、その後に明らかになった情報を踏まえ、公式発表で確認できる事実と攻撃者側の主張、第三者の観測を分けて整理し、食品・物流サプライチェーンへの影響と企業に求められる備えを解説します。

ニチレイが公式に確認したのは、サーバーへのサイバー攻撃、システム障害に伴う入出庫・出荷業務への影響、被害サーバーの一部に個人情報が保管されていたことです。一方、RansomHouseの関与、ランサムウェアによる暗号化、公開ファイルの真正性、情報漏えいの対象人数と範囲、侵入経路は、2026年8月13日時点で公式に確定していません。

※本記事は2026年8月13日時点で確認できる公表資料に基づき作成しています。RansomHouseの主張と20万件報道は、公式発表と混同しないよう補足情報として区分しています。

7月31日時点の公式発表に基づく経緯や、業務再開までの対応、BCPの観点はこちらの記事で解説しています。
前回記事(速報版) :「ニチレイへのサイバー攻撃で食品物流に影響―業務再開までの経緯と企業が見直すべきBCP

ニチレイへのサイバー攻撃で何が起きたのか

今回のニチレイへのサイバー攻撃は、情報システムだけの障害ではありませんでした。冷蔵倉庫の入出庫や冷凍食品の出荷が止まり、モノの流れそのものに影響が及んだ点が特徴です。食品物流は、保管温度や納品時間が厳しく管理される業務です。受発注や在庫、倉庫作業を支えるシステムが使えなくなれば、倉庫に商品があっても通常どおりに動かせない状況が起こり得ます。

ニチレイは障害発生当日に緊急対策本部を設置し、個人情報や顧客データの保護を優先してグループ内システムを遮断しました。遮断は被害拡大を防ぐために重要な措置ですが、その判断によって業務への影響が表面化することもあります。サイバーインシデントでは、「止めないこと」と「安全を確認できない状態で動かさないこと」の間で、経営判断が求められます。

ニチレイのサイバー攻撃を時系列で整理

7月13日~24日:サイバー攻撃の確認から通常稼働への移行

ニチレイは7月13日、不正アクセスによるシステム障害が発生したと発表しました。7月15日には自社サーバーへのサイバー攻撃を確認し、被害サーバーの一部に個人情報が保管されていたことから、個人情報保護委員会へ漏えいの可能性がある事案として速報しています。その後、7月17日から一部制限のもとで業務を順次再開し、7月24日には受発注制限を解除。影響を受けた全拠点が平常時の通常稼働へ移行しました。

※発生から業務再開までの詳しい経緯は、前回の速報版で解説しています。

8月7日:業績への影響を公表

8月7日の2026年12月期第1四半期決算説明資料(決算期変更に伴う変則決算)で、ニチレイはシステム障害による売上面のマイナス影響を最大50億円、営業利益への影響を8億円と見込み、緊急対応で発生したコストや今後見込まれる損失として特別損失10億円を織り込みました。金額の意味が異なるため、これらを単純に合算して「被害総額」とみなすことはできません。

8月10日:「20万件以上」のファイル公開が報じられる

8月10日、テレビ朝日ANNニュースはS&Jの観測として、RansomHouseを名乗るグループが少なくとも20万件以上のファイルを公開し、個人情報も含まれているとみられると報じました*1。ニチレイは追加で情報が公開されていることを把握しているものの、コメントを差し控えると回答したとされています。なお、8月13日時点で、ニチレイの公式サイトには第5報以降、漏えい範囲や対象人数を確定する追加発表は掲載されていません。

ニチレイから個人情報は漏えいしたのか

結論からいえば、ニチレイは「個人情報の漏えいの可能性」を公表していますが、実際に社外へ流出した情報の項目や対象人数、件数は明らかにしていません。公式に確認できるのは、被害サーバーの一部に個人情報が保管されていたこと、個人情報保護委員会へ報告したこと、対象者へ通知したことまでです。この対象者への通知が行われたこと自体も、個人情報の社外流出が確定したことを意味するものではありません。

個人情報保護法では、不正アクセスなどによる個人データの漏えいが発生した場合だけでなく、発生したおそれがある場合にも、一定の要件のもとで個人情報保護委員会への報告と本人通知が必要になります*2。したがって、「個人情報保護委員会へ報告した」という事実だけで、漏えいが確定したとは判断できません。調査が進むにつれて公表内容が更新されることもあるため、初報だけで結論づけず、続報を追う必要があります。

「20万件以上」は20万人分の個人情報ではない

報道で使われた「20万件以上」は、文書や画像、フォルダー内のデータなどを含むファイル数です。1人に複数のファイルがひもづく場合もあれば、個人情報を含まない業務資料が数えられている可能性もあります。反対に、1つのファイルに複数人の情報が含まれる可能性もあります。そのため、ファイル数から被害人数を換算することはできません。さらに、公開されたとされるファイルのすべてがニチレイから窃取された真正なデータなのか、S&Jがどの範囲を確認したのかについて、ニチレイによる公式な検証結果は出ていません。

RansomHouseとは?ニチレイへの犯行は確認されたのか

RansomHouseは、被害組織からデータを窃取し、公開をちらつかせて金銭を要求する恐喝活動で知られるグループです。パロアルトネットワークスのUnit 42は、RansomHouseをRansomware as a Service(RaaS)として分析し、データ窃取と暗号化を組み合わせる二重脅迫、ESXi環境を狙う管理ツール「MrAgent」と暗号化ツール「Mario」の利用を報告しています*3

ただし、これはRansomHouse一般の活動に関する技術分析です。ニチレイの環境でMrAgentやMarioが使われたこと、サーバーやファイルが暗号化されたことを示すものではありません。RansomHouseを名乗るグループは犯行を主張していますが、ニチレイは攻撃主体を公式に特定しておらず、侵入経路や攻撃手法も公表していません。

サイバー攻撃は食品・物流サプライチェーンへどう波及したか

ニチレイの事例で見落とせないのは、被害が自社のサーバー内にとどまらず、商品の保管と配送を待つ取引先や、その先の店舗運営へ波及し得ることです。食品物流は、多数の荷主、倉庫、輸配送会社、小売・外食企業をつなぐ共通基盤です。中核となる事業者の機能が止まれば、取引先自身のシステムが侵害されていなくても、商品を受け取れないという形で事業が止まります。

同時期、日本ケンタッキー・フライド・チキン株式会社(以降KFC)も、食材配送を委託する物流会社で発生した不正アクセス起因のシステム障害により、商品の一部品切れ、販売メニューの制限、営業時間の短縮などが生じたと公表しました*4。7月22日には全店舗への食材納品体制が整い、通常営業へ戻っています。KFCは物流委託先の社名を公表していないため、ニチレイの事案との関係を公式情報だけで断定することはできません。一方、この事例は、物流委託先のシステム障害が消費者向けサービスにまで波及し得る構造を示しています。

「サプライチェーン攻撃」と「サプライチェーンへの影響」は別物

ここで用語を分けて考える必要があります。サプライチェーン攻撃は一般に、取引先や委託先、利用するソフトウェアやサービスを足がかりとして標的へ侵入する攻撃を指します。今回、ニチレイへの侵入経路は公表されていないため、攻撃経路という意味でサプライチェーン攻撃だったとは断定できません。

一方で、サイバー攻撃による業務停止が供給網の先へ広がる「サプライチェーンリスク」は明確に表面化しました。侵入経路の問題と、事業依存関係による影響の連鎖は別の論点です。この二つを混同しないことが、ニュースを正確に読み、自社の対策へ落とし込む第一歩になります。

ニチレイが公表した業績への影響

ニチレイの2026年12月期第1四半期決算説明資料では、事業停止に伴う売上面のマイナス影響を最大50億円と見込んでいます。内訳は食品事業が20億円、低温物流事業が30億円です。営業利益への影響は8億円で、食品事業2億円、低温物流事業4億円、持株会社のシステム対応費用2億円とされています。さらに、緊急対応で発生したコストと今後発生が見込まれる損失として、10億円の特別損失を織り込みました。

※ニチレイが公表した売上への影響、営業利益への影響、特別損失は、それぞれ意味の異なる数字です。これらを単純に合算して「サイバー攻撃による被害総額」とみなすことはできません。

親会社株主に帰属する当期純利益の予想は252億円から204億円へ48億円下方修正されましたが、この48億円すべてがサイバー攻撃による損失ではありません。中東情勢によるコスト増や食品・物流事業の進捗など、複数の要因が含まれています。なお、連結売上高の通期予想自体は海外事業の伸長を反映して上方修正されています。

企業が学ぶべきサイバー攻撃対策

重要業務と外部依存を、システム単位ではなく事業単位で洗い出す

まず必要なのは、どのシステムが止まると、どの業務、取引先、商品、売上に影響するのかを平時に把握することです。自社システムの一覧だけでは足りません。物流、決済、クラウド、保守会社、受発注先など、重要業務を支える外部依存まで含め、許容停止時間と代替手段を整理します。委託先が止まった場合の連絡順序、手作業へ切り替えられる範囲、代替事業者の有無も、BCPとインシデント対応計画の両方で確認しておく必要があります。

また、インシデント対応訓練では自社がサイバー攻撃を受けるケースだけでなく、物流会社やクラウドサービス、主要な仕入先など、重要な委託先・取引先のシステムが停止するケースも想定することが重要です。自社システムが正常でも外部サービスが利用できない状況で、どこまで業務を継続できるのかを確認しておく必要があります。

「業務復旧」と「情報漏えい対応」を別の時計で管理する

ニチレイは7月24日に通常稼働へ移行しましたが、その後もダークウェブ上でのデータ公開が報じられました。ここから分かるのは、システム復旧の完了と、情報漏えい調査の完了は一致しないということです。前者は業務を安全に再開できるかという可用性の問題、後者は何が持ち出され、誰にどのような影響があるかという機密性と法令対応の問題です。復旧宣言後も、フォレンジック調査、漏えい範囲の特定、本人通知、二次被害の監視、対外説明を継続できる体制が欠かせません。

遮断・復旧・証拠保全を同時に進められる初動体制をつくる

攻撃を疑った場合は、インシデント対応責任者や専門家の判断のもと、必要に応じて感染が疑われる端末やサーバーをネットワークから隔離し、被害拡大を抑える必要があります。一方、電源断や安易な初期化によって調査に必要な証拠を失うおそれもあります。誰が遮断を判断し、どのログを保存し、外部の専門会社や警察、監督機関へいつ連絡するのかを事前に決め、机上訓練で確かめておくことが重要です。

経済産業省・独立行政法人情報処理推進機構(IPA)の「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第4版」でも、インシデント発生に備えた体制構築とサプライチェーン全体での対策を経営課題として位置づけています。

バックアップは取得だけでなく、隔離と復旧テストまで行う

ランサムウェアを含む破壊的な攻撃に備えるには、バックアップを本番環境と同じ認証基盤やネットワークに置き続けないことが重要です。実際に戻せるかを定期的に試し、復旧に必要な時間が事業側の許容範囲に収まるかまで確認して、初めてBCPとして機能します。

よくある質問

▼ ニチレイへの攻撃はランサムウェアだったのですか?
▼ 20万件とは20万人分の個人情報ですか?
▼ 個人情報の漏えいは確定していますか?
▼ ニチレイのシステムと業務は復旧していますか?
▼ 今回の事案はサプライチェーン攻撃ですか?

まとめ―復旧の速さだけでは測れないサイバー攻撃の損失

ニチレイへのサイバー攻撃は、冷蔵倉庫と冷凍食品出荷の停止、取引先への影響、個人情報漏えいの可能性、財務損失という複数の問題を同時に突きつけました。全拠点が通常稼働へ戻った後にデータ公開が報じられた経緯は、事業継続と情報保護を別々に備える必要性を示しています。

企業が見るべきなのは、自社への侵入を防げるかだけではありません。重要な委託先が止まったときに業務を続けられるか、攻撃を検知した直後に安全に遮断できるか、バックアップから所定時間内に戻せるか、漏えい調査と対外説明を長期にわたって続けられるかまでが、現在のサイバー攻撃対策です。平時のうちに外部専門会社との連絡経路や調査体制を整え、実際のシナリオで検証しておくことが、被害の大きさを左右します。漏えい調査と対外説明を長期にわたって続けられるかまでを想定することが、現在のサイバーリスク対策には求められます。

参考情報

編集責任:木下


BBSecの脆弱性診断・セキュリティ対策支援サービス

BBSec(ブロードバンドセキュリティ)では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。


ウェビナー開催のお知らせ

  • 2026年8月19日(水)14:00~15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―
  • 2026年8月26日(水)「AI時代に見直すセキュリティ対策 ~ASMの考え方で始める攻撃対象領域の可視化とリスク対策~
  • 最新情報はこちら


    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    ニチレイへのサイバー攻撃で食品物流に影響―業務再開までの経緯と企業が見直すべきBCP

    Share
    ニチレイへのサイバー攻撃で食品物流に影響アイキャッチ画像

    2026年7月、ニチレイがサイバー攻撃を受け、冷蔵倉庫の入出庫業務や冷凍食品の出荷業務に影響が生じました。同社は被害拡大を防ぐためグループのシステムを遮断し、一部制限のもとで業務を順次再開。7月24日には、影響を受けた業務が通常稼働へ移行しました。本事案は、サイバー攻撃が情報漏えいだけでなく、物流や取引先を含む事業継続にも影響を及ぼすことを示しています。本記事では、公式発表に基づいて対応の経緯を整理し、企業が見直すべきBCPについて解説します。

    ※本記事は2026年7月31日時点で確認できる公表資料に基づき作成しています。公表されていない製品名、CVE番号、攻撃者、侵入手法の詳細については推測を加えずに構成しています。

    ニチレイへのサイバー攻撃とは

    2026年7月13日、株式会社ニチレイは不正アクセスによるシステム障害が発生したと公表しました*5。影響が出たのは、ニチレイロジグループ各社の冷蔵倉庫における入出庫業務と、ニチレイフーズの冷凍食品出荷業務です。同社は発生当日に緊急対策本部を立ち上げるとともに、お客さまや取引先の個人情報・顧客データなどの保護を最優先し、グループで使用するシステムの遮断措置を講じたことを、2日後の第2報*2で明らかにしています。その後、7月17日から一部制限のもとで業務を順次再開し、7月24日には、影響を受けた入出庫業務と冷凍食品出荷業務の受発注制限を解除して、全拠点を平常時の通常稼働へ移行しています。

    この事案が示したのは、サイバー攻撃の被害が情報漏えいだけにとどまらないことです。攻撃を受けた疑いが生じれば、被害拡大を防ぐためにシステムを止める判断が必要になる場合があります。受発注、在庫管理、倉庫の入出庫、出荷といった業務がITでつながる現在、封じ込め措置そのものが事業停止リスクを伴います。本件からは、侵入を防ぐ対策だけでなく、システムを遮断した後も業務を継続し、段階的に復旧する計画が欠かせないことが分かります。サイバーセキュリティ対策とBCPは、一体で検討すべき課題です。

    7月13日から24日まで―公式発表で追う対応と復旧

    7月13日:不正アクセスによるシステム障害を公表

    ニチレイは7月13日、不正アクセスによるシステム障害が同日に発生したと発表しました。第1報の時点では、個人情報や顧客データが社外へ流出した事実は確認されていないとしていました。一方、冷蔵倉庫の入出庫業務と冷凍食品の出荷業務にはすでに影響が生じており、障害の範囲は公表時点で日本国内に限られると説明しています。

    ここで注意したいのは、7月13日が「攻撃者の侵入日」と確認されたわけではない点です。公式発表から断定できるのは、不正アクセスによるシステム障害が7月13日に発生し、同日公表されたことまでです。攻撃者が最初に侵入した日時や、不正アクセスを検知した正確な時刻・契機は明らかにされていません。

    7月15日:サイバー攻撃を確認、個人情報漏えいの可能性を報告

    7月15日の第2報で、ニチレイは調査の結果、自社サーバがサイバー攻撃を受けたことを確認したと発表しました。さらなる被害拡大を防ぐため、攻撃の詳細は非開示としています。また、被害を受けたサーバの一部に個人情報が保管されていたため、個人情報保護委員会へ「漏えいの可能性がある事案」として第一報を行いました。

    同社は発生当日の7月13日にグループで使用するシステムを遮断しており、この遮断措置に伴って冷蔵倉庫の入出庫と冷凍食品出荷に影響が生じたと説明しています。なお、7月16日付のIR情報では、連結業績への影響は精査中とされ、重要な影響が判明した場合は速やかに開示すると説明しています。

    7月17日:受発注を制限しながら部分稼働

    7月17日、ニチレイは外部のセキュリティ専門会社の支援のもと、影響を受けた業務を順次再開しました。ただし、直ちに平常運転へ戻ったわけではなく、顧客や取引先からの受発注を一部制限し、冷蔵倉庫と食品工場を部分稼働させる形での再開でした。この段階でも、原因と影響範囲は調査中とされていました。

    7月22日から24日:対象者への通知と通常稼働への移行

    7月22日の第4報*3では、外部のセキュリティ専門会社に加え、警察および関係機関と連携して対応していることが公表されました。被害サーバの一部に個人情報が保管されていたため、対象者へ別途通知を行っていることも明らかにされています。

    7月24日、ニチレイは受発注制限を解除し、影響を受けていた入出庫業務と冷凍食品出荷業務について、全拠点が平常時の通常稼働へ移行したと発表しました。ただし、これは影響業務の通常稼働への移行を示すものであり、原因調査や影響範囲の特定まで完了したことを意味するものではありません。

    なぜ食品サプライチェーンへの影響が注目されたのか

    ニチレイが2026年5月12日に公開した「事業概要説明資料」によると、同社の低温物流事業は全国75カ所に冷蔵倉庫を保有し、冷蔵倉庫の保管能力で国内1位です。さらに、ニチレイグループ外の取扱比率が90%を超えるとされています。今回、75カ所すべてに同じ程度の支障が生じたと公表されているわけではありません。ただし、この事業構造から、低温物流業務の中断がニチレイグループ以外の荷主にも波及し得ることが分かります。

    実際、ミールキット宅配サービスのヨシケイは7月27日、ニチレイグループのシステム障害により倉庫からの商品出庫に支障が生じ、一部エリアで代替品や代替食材を届ける場合があると公表しました*4。ニチレイは7月24日に影響業務の通常稼働への移行を発表していますが、自社の業務が再開しても、取引先側では在庫調整や代替品の手配などが続く場合があります。ヨシケイの発表は、障害の影響が取引先の商品供給にまで波及したことを示す事例といえます。

    なお、サイバー攻撃の影響が取引先へ波及したことと、取引先などを侵入経路とする「サプライチェーン攻撃」は区別する必要があります。ニチレイは侵入経路を公表していないため、本件をサプライチェーン攻撃と分類することはできません。一方、業務停止の影響が取引関係を通じて広がるリスクは、物流や食品製造だけでなく、決済、医療、クラウドサービスなどにも共通します。

    個人情報は漏えいしたのか

    2026年7月31日時点で、ニチレイは個人情報の漏えいを確定したとは発表していません。公表されているのは、被害サーバの一部に個人情報が保管されていたこと、漏えいの可能性がある事案として個人情報保護委員会へ第一報を行ったこと、対象者へ別途通知したことです。

    個人情報保護委員会は、不正の目的をもって行われたおそれがある個人データの漏えい等について、実際の漏えいが確定した場合だけでなく、それがある段階も報告対象になると示しています*5。このため、個人情報保護委員会への報告が行われたことだけをもって、外部流出が確定したとは判断できません。

    対象人数、顧客・従業員などの属性、情報項目、持ち出しの有無、不正利用の有無も公表されていません。したがって、現段階で「顧客情報が流出した」「大規模な個人情報漏えいが起きた」と書くのは不正確です。新たな公式発表が出た場合は、漏えいの事実、対象範囲、二次被害の有無を分けて確認する必要があります。

    ランサムウェア攻撃だったのか

    ニチレイは、攻撃手法、侵入経路、悪用された脆弱性、マルウェアの種類、データ暗号化や身代金要求の有無、攻撃者について公表していません。このため、本件をランサムウェア攻撃、ゼロデイ攻撃、あるいは特定の攻撃グループによる犯行と断定できる公式情報はありません。

    攻撃者を名乗る第三者の主張が報じられた場合でも、それだけで攻撃手法や犯行主体が確定するわけではありません。本記事では、ニチレイまたは捜査機関が確認した情報と、外部からの未検証の主張を区別して扱います。

    ニチレイの事例から企業が見直すべきサイバー攻撃対策

    重要業務とシステムの依存関係を可視化する

    対策の出発点となるのは、止まると事業や顧客に大きな影響が出る業務を特定し、それを支えるシステム、データ、拠点、委託先を対応付けることです。受発注システムだけを復旧しても、在庫情報、倉庫作業、輸配送との連携が戻らなければ商品は届きません。業務影響分析(BIA)を用いて復旧の優先順位を整理し、目標復旧時間(RTO)や目標復旧時点(RPO)に加え、システム停止中も最低限維持すべき業務とその水準を、IT部門と現場部門で共有しておくことが有効です。

    多層防御によって被害範囲を限定する

    ニチレイは侵入経路や攻撃手法を公表していないため、本件の原因に特定の対策不足を結び付けることはできません。以下は、同種の業務停止に備えるための一般的な対策です。

    サイバー攻撃への備えでは、侵入を防ぐだけでなく、侵入された場合にも被害を広げない対策が必要です。重要システムやネットワークの分離、特権アカウントの適切な管理、多要素認証、ログの保全・監視などを組み合わせ、攻撃者による内部での移動や権限拡大を抑制します。

    経済産業省・独立行政法人情報処理推進機構(IPA)の「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第4版」も、侵入を防ぐ入口対策に加え、内部での活動拡大を防ぐネットワーク対策、外部への不正通信を防ぐ出口対策、重要データを守る対策を組み合わせる多層防御を示しています。

    「システムを止めた状態」で続ける手順を用意する

    不正アクセスの疑いがある状況では、ネットワークの遮断や機器の隔離、サービス停止が必要になることがあります。IPAの「中小企業のためのセキュリティインシデント対応の手引き」でも、被害拡大の可能性がある場合の初動対応として、ネットワーク遮断や対象機器の隔離、システム・サービスの停止を挙げています。

    だからこそ、BCPはバックアップからシステムを戻す手順だけでは不十分です。システムを遮断した際に利用する代替手順を、業務内容に応じて事前に設計しておく必要があります。例えば、受発注や入出庫を電話、メール、紙の帳票などへ一時的に切り替える場合も、処理可能な件数、誤処理を防ぐ照合方法、記録の保全、平常系へ戻す際のデータ反映まで検証しなければなりません。机上演習に加え、主要システムを利用できない状況を想定し、代替手順が実際に機能するか確認することが重要です。

    復旧可能なバックアップと復旧手順を検証する

    バックアップは、データを保存しているだけでは事業復旧を保証できません。本番環境と同時に暗号化・削除されないよう、ネットワークから分離した媒体や異なる環境にも保管し、バックアップデータの完全性を定期的に確認する必要があります。

    さらに、復元テストを実施し、重要なシステムやデータを想定した時間内に復旧できるかを検証します。復旧の順序、必要な担当者、利用する機器や認証情報、システム間の依存関係も事前に整理しておくことが重要です。

    サイバー攻撃を受けた環境を安全確認なしに復元すると、侵害された設定やマルウェアまで戻してしまうおそれがあります。原因調査や安全性の確認と並行して、どの時点のデータを、どの環境へ、どの順番で戻すかを判断できる復旧手順を整備しておく必要があります。

    初動対応をIT部門だけに背負わせない

    インシデント発生時には、封じ込め、証拠保全、原因調査、復旧に加え、顧客や取引先への連絡、個人情報保護委員会などへの報告、警察との連携、経営判断が並行して進みます。ニチレイも緊急対策本部を設置し、外部のセキュリティ専門会社、警察、関係機関と連携しました。

    平時から、経営、情報システム、事業部門、法務、広報、個人情報保護担当の役割と連絡順序を決め、フォレンジック調査や復旧を依頼する外部専門家の連絡先を整えておくべきです。対応手順は、社内システムが利用できない状況でも参照できる場所に保管します。また、調査に必要なログやデータを不用意に消去しないよう、対象機器の隔離方法や外部専門家へ連絡する判断基準を訓練しておくことが重要です。

    取引先を含めて復旧情報を共有する

    自社が通常稼働へ戻っても、取引先側では在庫不足、納品遅延、代替商品の手配、顧客への案内が続く可能性があります。サプライチェーン全体の復旧を早めるには、「何が止まっているか」「どの業務をいつ再開するか」「制限が残るか」を、攻撃者に利する情報を避けながら継続的に共有することが重要です。

    公表文のひな型だけでなく、重要取引先への連絡経路、問い合わせ窓口、更新頻度、技術情報と事業影響を分けて説明するルールまで準備しておくと、混乱を抑えやすくなります。セキュリティ部門が把握する復旧状況を、物流、営業、調達、顧客対応の言葉へ変換する役割も必要です。

    よくある質問

    ▼ ニチレイのシステム障害はいつ発生しましたか
    ▼ どの業務に影響が出ましたか
    ▼ 個人情報は漏えいしましたか
    ▼ ランサムウェア攻撃だったのでしょうか

    まとめ―サイバー攻撃対策は業務復旧まで設計する

    ニチレイへのサイバー攻撃では、冷蔵倉庫の入出庫と冷凍食品出荷に支障が生じ、制限付きの再開を経て通常運用へ戻りました。一方、2026年7月31日時点では、攻撃手法や侵入経路、個人情報の外部流出の有無、最終的な影響範囲は公表されていません。

    今回の事例から企業が学ぶべきなのは、侵入防止策だけではありません。被害拡大を防ぐためにシステムを遮断しても重要業務を続けられるか、安全性を確認しながらどの順番で復旧するか、取引先へ何を伝えるかまで含めて設計する必要があります。サイバー攻撃をIT障害として閉じず、経営と現場を巻き込んだサイバーBCPとして準備することが、事業とサプライチェーンの強靱性を左右します。

    【参考情報】

    編集責任:木下


    BBSecの脆弱性診断・セキュリティ対策支援サービス

    BBSec(ブロードバンドセキュリティ)では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。


    ウェビナー開催のお知らせ

  • 2026年8月19日(水)14:00~15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―
  • 2026年8月26日(水)「AI時代に見直すセキュリティ対策 ~ASMの考え方で始める攻撃対象領域の可視化とリスク対策~
  • 最新情報はこちら


    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    【続報】KDDIメールシステムへの不正アクセス、約1,223万人のメールアドレス漏えい―未知の脆弱性が原因

    Share
    KDDIメールシステムへの不正アクセス、約1,223万人のメールアドレス漏えいアイキャッチ画像

    2026年6月17日、KDDI株式会社は、ISP事業者向けに提供するメールシステムが不正アクセスを受けていたことを確認しました。この不正アクセスにより、約1,223万人分のメールアドレスと、そのうち約762万人分のパスワードが漏えいしました。原因は、ソフトウェアベンダーも把握していなかった第三者製ソフトウェアの脆弱性です。本記事では、確定した被害範囲とゼロデイ攻撃との関係、認証情報漏えいのリスク、企業が見直すべき対策を解説します。

    ※本記事は2026年7月31日時点で確認できる公表資料に基づき作成しています。公表されていない製品名、CVE番号、攻撃者、侵入手法の詳細については推測を加えずに構成しています。

    KDDIのISP向けメールシステムへの不正アクセスとは

    KDDIは2026年6月23日、同社がISP事業者向けに提供するメールシステムで不正アクセスが発生し、メール関連情報が外部に漏えいした可能性があると公表しました*6。初報で示されたのは、メールボックスにひもづくメールアドレスとパスワードの最大1,422万件です。この時点では調査中の最大値で、解約済みの利用者や一定期間利用されていない休眠アカウントも含まれていました。

    その後、KDDIは7月6日に調査結果を公表*2し、7月21日に対象人数を訂正しました。更新後の確定値は、メールアドレスが12,231,954人分、パスワードが7,616,173人分です。

    影響したISP事業者とメールサービス

    対象として公表されたのは6社です。STNetの「ピカラ光サービス」「ピカラモバイルサービス」「お仕事ピカラサービス」に係るメール、KDDIウェブコミュニケーションズのレンタルサーバー「CPI」のメール、JCOMの「J:COM NET」とケーブルテレビ事業者向けメール、中部テレコミュニケーションの「コミュファ光」「ビジネスコミュファ」のメール、ニフティの「@niftyメール」、ビッグローブの「BIGLOBEメール」です。

    一方、KDDIは、auメール、UQ mobileメール、au one netメールについて、今回のシステムとは異なる設備で構築されており、本件による影響や情報漏えいはないと説明しています。「KDDIのメールが一律に被害を受けた」と広げて表現するのは適切ではありません。

    また、KDDIが示した全体人数は、6社すべてで同じ種類の情報が漏えいしたことを意味しません。事業者別の調査結果には差があり、たとえばJ:COM NET利用者についてJCOMが確認した漏えい情報はメールアドレスのみです。CPIについても、KDDIはパスワードそのものの漏えいはないと公表しています。一方、JCOMがケーブルテレビ事業者向けに提供するメールサービスでは、一部の利用者についてパスワード漏えいが確認されています。対象者は契約先の公式案内で、自分に該当する情報と必要な対応を確認することが重要です。

    2026年5月16日の発生から2026年7月の確定公表まで

    KDDIの調査では、不正アクセスは一部のISP事業者において2026年5月16日から発生していました。KDDIが不正アクセスを確認したのは6月17日で、同日に被疑箇所を特定し、システム改修と脆弱性への対処を実施しています。発生開始から確認までには約1か月の隔たりがあり、未知の脆弱性を突いた攻撃を早期に検知する難しさが表れています。

    確認後の対応として、KDDIは6月21日に、外部通信を制御する全サーバーへのEDR導入を完了しました。さらに6月23日、第三者機関によるフォレンジック調査を通じ、本件で悪用された脆弱性以外に不審な痕跡が存在しないことを確認したとしています。6月24日には総務省から電気通信事業法に基づく報告を求められ、7月6日に報告書を提出しました。

    利用者対応では、KDDIと各ISP事業者がメールアカウントのパスワード変更を進めました。7月6日の公表時点では、日常的に利用されているアカウントを中心に多数の変更が行われ、利用頻度の低いアカウントを含めてISP事業者による強制変更を進めていると説明されています。公表資料が示すのは当時の進捗であるため、その後の完了状況は各ISP事業者の最新案内で確認する必要があります。

    なぜ「ゼロデイ攻撃」と整理できるのか

    KDDIは公式資料で「ゼロデイ」という言葉を用いていません。ただし、悪用された脆弱性は、KDDIが不正アクセスを確認した2026年6月17日時点で、当該ソフトウェアのベンダーも認識していなかったと説明されています。

    米国国立標準技術研究所(NIST)は、「従来知られていなかったハードウェア、ファームウェア、ソフトウェアの脆弱性を悪用する攻撃」をゼロデイ攻撃と定義しています*3。この定義に照らせば、本件をゼロデイ脆弱性の悪用事例として整理することには根拠があります。

    ただし、KDDIの更新資料には、第三者製ソフトウェアの製品名、脆弱性の技術的詳細、CVE番号、攻撃者の属性は記載されていません。したがって、侵入手法や攻撃主体、脆弱性の深刻度を推測で補うべきではありません。現時点で確実に言えるのは、第三者製ソフトウェアの未知の脆弱性が悪用され、メールアドレスとパスワードの漏えいが確認されたことです。

    ゼロデイ攻撃では、公開済みの修正プログラムを適用するという通常の脆弱性管理だけでは初動時の防御が間に合いません。そのため、外部公開範囲の縮小、ネットワーク分離、権限の最小化、EDRやNDRによる挙動監視、外向き通信の監視、十分な期間のログ保全といった、脆弱性そのものに依存しない多層防御が重要になります。KDDIがシステム改修に加えてEDR導入とフォレンジック調査を実施した点も、検知と影響範囲確認の重要性を示しています。

    「サプライチェーン攻撃」ではなく、サプライチェーンリスクとして見る

    本件では第三者製ソフトウェアの脆弱性が悪用されましたが、これだけを根拠に、サプライチェーン攻撃と断定するのは慎重であるべきです。公表資料には、ソフトウェアベンダーの開発環境や更新配布経路が侵害され、悪意あるコードが供給されたという説明はありません。確認されているのは、KDDIのメール基盤に導入されていたソフトウェアの脆弱性が攻撃されたという事実です。

    一方で、サイバーセキュリティのサプライチェーンリスクという観点では重要な事例です。NIST SP 800-161 Rev.1は、組織が利用する製品やサービスを含むサプライチェーン全体について、リスクを特定、評価、低減することを求めています。自社システムであっても、その構成要素には商用ソフトウェア、OSS、クラウドサービス、保守事業者など多くの外部依存が含まれます。脆弱性が一つの共通基盤に存在すれば、直接の契約関係やサービス名称が異なる複数の利用者へ影響が広がり得ます。

    今回、6社のISP事業者が提供する複数ブランドのメールサービスに影響が及んだことは、共通基盤への集中が障害時や侵害時の影響範囲を大きくすることを示しました。各ISPが個別に侵入されたとする公表ではなく、共通して利用するメール基盤で発生した事案である点が重要です。サービス名や契約先だけを見てリスクを分けるのではなく、実際にどの基盤、製品、運用主体を共有しているかまで把握する必要があります。

    パスワード漏えいで警戒すべき二次被害

    確認された情報にはメールアドレスだけでなく、7,616,173人分のパスワードが含まれます。ただし、KDDIの初報は漏えいした可能性のあるパスワードについて、ハッシュ化または暗号化されたものも含むと説明しており、すべてが平文で保存されていた、あるいは直ちに不正ログインが成立したと読み替えることはできません。また、7月21日更新資料で「漏えいが確認された情報」として人数が示されたのはメールアドレスとパスワードで、メール本文や添付ファイルの漏えい確認について同資料に記載はありません。

    それでも、メールアドレスと認証情報の組み合わせは二次攻撃への備えが必要です。同じパスワードを他のサービスでも使い回していれば、漏えいした組み合わせを別サービスに試すパスワードリスト攻撃につながるおそれがあります。IPAは、パスワードを長く複雑にし、使い回さないことに加え、利用できるサービスでは多要素認証を設定するよう推奨しています。

    さらに、漏えいしたメールアドレスを宛先として、ISPやKDDIを装ったフィッシングメールが送られる可能性も考慮すべきです。ただし、これは将来のリスクに関する一般的な注意であり、本件を原因とするフィッシング被害や他サービスへの不正ログインが確認されたという意味ではありません。利用者への注意喚起では、確認済みの事実と想定されるリスクを混同しない表現が求められます。

    企業が見直すべき4つの実務ポイント

    外部依存と共通基盤の「影響半径」を把握する

    最初に必要なのは、導入している製品やサービスの一覧だけではなく、それぞれがどのデータにアクセスでき、どの顧客、事業、関連会社へ影響し得るかを結び付けて把握することです。SaaSやマネージドサービスの契約先が別々でも、背後で同じ認証基盤やメール基盤を共有している可能性があります。重要度、外部公開の有無、保存データ、依存先、代替手段、停止・侵害時の連絡先を整理し、共通基盤の事故が起きた場合の影響半径を平時から想定しておく必要があります。

    未知の脆弱性を前提に補完的統制を置く

    脆弱性管理は不可欠ですが、パッチが存在しない期間をゼロにはできません。インターネットから直接到達できる機能を最小限にし、管理系機能を分離し、サービスアカウントを含む権限を必要最小限に抑えることが基本です。加えて、EDRやNDR、WAFなどを環境に応じて組み合わせ、通常と異なるプロセス実行、大量のデータ参照、想定外の外向き通信を検知できる状態を整えます。未知の脆弱性を直接検知できなくても、悪用後の挙動を捉えられれば滞在時間と被害範囲を縮小できます。

    認証情報漏えい時の対応手順を事前に決める

    認証情報が漏えいした場合、対象者の特定、パスワードの強制変更、既存セッションやトークンの失効、不審なログインの調査、利用者への通知、問い合わせ対応を並行して進める必要があります。パスワード使い回しへの注意やフィッシング対策も同時に案内し、多要素認証を利用できる環境では導入を促すことが有効です。通知文面、意思決定者、関係部署、委託先との連絡経路をインシデント対応計画に組み込んでおけば、大規模なリセットが必要になったときの混乱を減らせます。

    休眠・解約済みアカウントをデータ管理の問題として扱う

    初報の最大件数には、解約済み利用者や一定期間使われていない休眠利用者も含まれていました。使われていないアカウントは、利用者が異常に気付きにくい一方、管理対象と漏えい時の対応負荷を増やします。法令、契約、事業上の必要性を踏まえて保存期間を定め、不要になったアカウントの無効化やデータ削除、匿名化を進めることが重要です。保持が必要な場合も、現役アカウントと同じ到達性や権限を残さず、用途に応じた分離と監視を行うべきです。

    対象サービスの利用者が確認すべきこと

    対象となるメールサービスの利用者は、まず契約中のISP事業者が公開する最新情報を確認してください。パスワード変更の案内がある場合は、メール本文のリンクからではなく、ブックマークや公式サイトから手続きページへアクセスする方が安全です。メールと同じパスワードを他のサービスで使っている場合は、そちらもサービスごとに異なるパスワードへ変更し、提供されていれば多要素認証を有効にします。不審なログイン履歴、転送設定、送信履歴がないかも確認し、身に覚えのない操作があればISPの公式窓口へ相談してください。

    よくある質問

    ▼ KDDIのauメールも今回の不正アクセスの対象ですか
    ▼ この事案はゼロデイ攻撃ですか
    ▼ サプライチェーン攻撃と呼んでよいですか

    まとめ:未知の脆弱性と共通基盤のリスクを分けて考える

    KDDIのISP事業者向けメールシステムへの不正アクセスは、12,231,954人分のメールアドレスと7,616,173人分のパスワードが漏えいした大規模インシデントです。しかし、注目すべきなのは件数だけではありません。ベンダーも把握していなかった脆弱性が悪用されたこと、一つの共通基盤を通じて複数のISPサービスへ影響が及んだこと、休眠・解約済み利用者を含む認証情報の対応が必要になったことが、企業の実務に直結する論点です。

    既知の脆弱性に迅速に対処する体制を整えたうえで、未知の脆弱性を前提とする監視と分離、外部依存関係と影響半径の把握、認証情報漏えい時の対応手順、不要データの削減を進める必要があります。サプライチェーン攻撃という言葉を安易に当てはめるのではなく、確認された事実と、そこから導ける共通基盤・外部依存のリスクを切り分けて検討することが、再発防止策を具体化する第一歩となるでしょう。

    【参考情報】

    編集責任:木下


    BBSecの脆弱性診断・セキュリティ対策支援サービス

    BBSec(ブロードバンドセキュリティ)では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。


    ウェビナー開催のお知らせ

  • 2026年8月19日(水)14:00~15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―
  • 2026年8月26日(水)「AI時代に見直すセキュリティ対策 ~ASMの考え方で始める攻撃対象領域の可視化とリスク対策~
  • 最新情報はこちら


    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    DDoS攻撃とは?仕組み・種類・被害・対策を企業向けに解説

    Share

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    DDoS攻撃とは?仕組み・種類・被害・対策を企業向けに解説アイキャッチ画像

    DDoS攻撃は、大量の通信を送り付けて、Webサイトやサーバーを利用しにくくするサイバー攻撃です。サービス停止や業務の停滞を招くおそれがあるため、企業は仕組みと対策を理解しておく必要があります。本記事では、DDoS攻撃の種類や被害、基本的な対策を解説します。

    DoS攻撃との違いを詳しく知りたい方、実際にDDoS攻撃を受けた場合の初動対応や復旧の流れについて知りたい方は以下の記事もあわせてご覧ください。
    DoS攻撃とDDoS攻撃の違いとは
    DDoS攻撃を受けたらどうする?

    DDoS攻撃とは

    DDoS攻撃(Distributed Denial of Service attack)は、Webサイトやサーバー、ネットワーク機器などに大量の通信やリクエストを送り付け、正常なサービス提供を妨害するサイバー攻撃です。攻撃を受けると、Webサイトの表示遅延やサービス停止、ネットワークの応答遅延などが発生し、正規の利用者がサービスを利用できなくなることがあります。

    DDoS攻撃の特徴は、攻撃者が多数の端末やネットワークを利用する点にあります。攻撃者は、マルウェアなどに感染した機器で構成される「ボットネット」を悪用します。

    世界中の端末から一斉に通信を送るため、単一の送信元を遮断するだけでは防ぎにくい攻撃です。近年では、ECサイトや金融機関、自治体、医療機関など、幅広い組織が標的となっています。企業規模を問わず対策が求められています。

    また、DDoS攻撃は、サービス停止だけを目的とするものではありません。攻撃による混乱に乗じて、不正アクセスや情報窃取など、別の攻撃を試みる「陽動」として利用されるケースもあります。

    DDoS攻撃を理解するためには、まずDoS攻撃との違いや、どのような目的で実行されるのかを知ることが重要です。

    DoS攻撃との違い

    DoS攻撃は、単一または少数の端末からサービスを妨害する攻撃です。DDoS攻撃は、多数の端末から分散して通信を送るため、攻撃元の特定や遮断が難しくなります。

    DoS攻撃とDDoS攻撃の違いについては、以下の記事で詳しく解説しています。ぜひあわせてご覧ください。「DoS攻撃とDDoS攻撃の違いとは

    なぜDDoS攻撃が行われるのか

    DDoS攻撃の目的は、単にWebサイトやサービスを停止させることだけではありません。企業活動を妨害したり、金銭を要求したり、別のサイバー攻撃を成功させるための陽動として利用されたりするなど、さまざまな目的で実行されます。

    例えば、ECサイトや予約システムを停止させることで売上機会の損失を狙うケースや、競合他社への業務妨害を目的とした攻撃が報告されています。

    また、サービス停止による混乱の中で、不正アクセスや情報窃取を試みることもあります。このような「陽動攻撃」として、DDoS攻撃が利用されるケースもあります。

    近年では、IoT機器の普及やボットネットの大規模化が進んでいます。その結果、専門的な知識がなくても、攻撃サービスを利用して大規模なDDoS攻撃を実行できる環境が問題視されています。

    こうしたサービスは、DDoS-for-Hire、すなわちDDoS請負サービスなどと呼ばれます。そのため、企業規模を問わず、DDoS攻撃を想定した備えが重要になっています。

    DDoS攻撃の仕組み

    DDoS攻撃は、多数の端末やサーバから、標的へ一斉に大量の通信を送る攻撃です。サーバやネットワーク機器に過剰な負荷をかけ、正常なサービス提供を妨げます。

    攻撃対象は、Webサイトだけではありません。DNSサーバやVPN、API、クラウドサービスなど、多岐にわたります。

    攻撃者は、自ら大量の通信を送るのではありません。マルウェアに感染したIoT機器やパソコン、サーバーなどを遠隔操作します。そして、ボットネットを構築して攻撃を実行するのが一般的です。

    また、DDoS攻撃は、大量の通信によって回線帯域を圧迫するものだけではありません。ネットワーク機器に負荷をかける攻撃や、Webアプリケーションへ大量のリクエストを送る攻撃など、複数の手法があります。

    そのため、自社サービスを守るためには、攻撃の仕組みを理解し、それぞれの手法に応じた対策を講じることが重要です。

    ボットネットによる分散攻撃

    DDoS攻撃では、多くの場合「ボットネット(Botnet)」と呼ばれるネットワークが悪用されます。ボットネットとは、マルウェアに感染したパソコンやサーバ、IoT機器などが攻撃者の遠隔操作下に置かれた状態のネットワークです。攻撃者はこれらの端末へ一斉に指示を送り、標的に大量の通信を発生させます。

    近年では、監視カメラやルーター、ネットワーク機器など、十分なセキュリティ対策が施されていないIoT機器がボットネットに組み込まれる事例も確認されています。機器の所有者が気付かないまま攻撃に加担しているケースも少なくありません。

    ボットネットを利用したDDoS攻撃では、世界中に分散した多数の端末から同時に通信が送られるため、単一の送信元を遮断するだけでは十分な対策が難しくなります。

    攻撃の流れ

    DDoS攻撃は、一般的に次のような流れで実行されます。

    1. ボットネットの構築
      攻撃者は、マルウェアに感染したパソコンやサーバー、IoT機器などを遠隔操作できる状態にし、ボットネットを構築します。
    2. 攻撃対象の選定
      WebサイトやECサイト、VPN、DNSサーバー、APIなど、攻撃対象となるシステムを選定します。
    3. 攻撃命令の送信
      攻撃者がボットネットへ攻撃命令を送ると、多数の端末が一斉に標的へ通信やリクエストを送信します。
    4. サービスへの影響
      大量の通信によってネットワーク回線やサーバー、ネットワーク機器、Webアプリケーションに負荷がかかり、応答遅延やサービス停止などが発生します。

    攻撃の種類によっては、ネットワーク帯域を圧迫するだけでなく、ファイアウォールやロードバランサーなどのネットワーク機器に負荷をかけるものや、Webアプリケーションへ大量のリクエストを送るものもあります。そのため、攻撃の種類に応じた対策を講じることが重要です。

    DDoS攻撃の主な種類

    DDoS攻撃にはさまざまな手法がありますが、大きく分けると「ボリューム攻撃」「プロトコル攻撃」「アプリケーション層攻撃」の3種類に分類できます。

    攻撃対象や攻撃方法が異なるため、サービスへの影響や有効な対策もそれぞれ異なります。攻撃の種類を理解することは、自社サービスがどのようなリスクにさらされているのかを把握し、適切な対策を講じるための第一歩です。

    ここでは、代表的な3つの攻撃手法について解説します。

    ボリューム攻撃

    ボリューム攻撃は、大量の通信を送り付けてネットワーク回線の帯域を圧迫し、正規の利用者がサービスへアクセスできない状態にする攻撃です。DDoS攻撃の中でも代表的な手法であり、回線容量を超える通信が発生すると、サーバーが正常に稼働していてもサービスを利用できなくなることがあります。

    代表的な手法として、UDP FloodDNS Amplification(DNSリフレクション攻撃)NTP Amplificationなどがあります。特にDNSやNTPなどの公開サーバーを悪用する反射・増幅型攻撃では、小さなリクエストを利用して何倍もの通信量を発生させるため、攻撃者は比較的少ない通信量でも大きな負荷を与えることができます。

    プロトコル攻撃

    プロトコル攻撃は、TCP/IPなどの通信プロトコルの仕組みを悪用し、サーバーやファイアウォール、ロードバランサーなどのネットワーク機器に負荷をかける攻撃です。通信回線そのものを埋め尽くすボリューム攻撃とは異なり、ネットワーク機器やサーバーの処理能力を消費させることで、正常な通信を妨害します。

    代表的な手法としては、SYN Floodがあります。TCP通信の接続要求(SYNパケット)を大量に送り付けることで、サーバは接続待ちの状態を維持し続けることになり、新たな正規ユーザからの接続を受け付けられなくなる場合があります。このほか、Ping FloodSmurf攻撃などもプロトコル攻撃の一種として知られています。

    アプリケーション層攻撃

    アプリケーション層攻撃は、WebサイトやWebアプリケーション、APIなどを標的とするDDoS攻撃です。利用者が直接アクセスするサービスが狙われます。

    通信量そのものはそれほど多くなくても、サーバーが処理に時間を要するリクエストを大量に送ることで、CPUやメモリなどのリソースを消費させ、サービスの応答遅延や停止を引き起こします。

    代表的な手法としてHTTP Floodがあります。通常のWeb閲覧と同じHTTPリクエストを大量に送信するため、正規のアクセスと見分けにくく、単純な通信量の監視だけでは検知が難しい場合があります。また、検索機能やログイン画面、APIなど、サーバー負荷の高い処理を集中的に狙う攻撃も確認されています。

    DDoS攻撃による被害

    DDoS攻撃による影響は、単にWebサイトが一時的に閲覧できなくなるだけではありません。サービス停止による売上機会の損失や業務の停滞、顧客対応の負荷増加など、企業活動全体へ影響が及ぶ可能性があります。

    また、長時間にわたってサービスが利用できない状態が続くと、企業の信頼低下やブランドイメージの毀損につながるおそれもあります。

    近年では、DDoS攻撃を単独で行うだけでなく、その混乱に乗じて不正アクセスや情報窃取など別の攻撃を試みるケースも報告されています。そのため、DDoS攻撃は単なる通信障害ではなく、企業の事業継続に関わるセキュリティリスクとして捉えることが重要です。

    ここでは、企業が受ける代表的な被害について解説します。

    サービス停止

    DDoS攻撃による代表的な被害は、Webサイトやオンラインサービスの停止です。

    大量の通信やリクエストが送られると、サーバーやネットワーク機器に過剰な負荷がかかります。その結果、Webページの表示遅延やタイムアウト、エラーが発生し、正規の利用者がサービスを利用できなくなることがあります。

    特に、ECサイトや予約システム、会員向けサービス、決済サービスなど、インターネットを通じて提供されるサービスでは、短時間の停止であっても売上機会の損失や顧客満足度の低下につながる可能性があります。

    さらに、DDoS攻撃ではサーバー自体に障害が発生していなくても、回線帯域の逼迫やネットワーク機器への負荷によってサービスが利用できなくなる場合があります。そのため、システムが正常に稼働しているように見えても、利用者からは「サービスが停止している」と認識されるケースも少なくありません。

    業務への影響

    DDoS攻撃の影響は、Webサイトの停止だけにとどまりません。公開サービスと社内システムが同じネットワークや認証基盤を利用している場合には、VPNや業務システム、クラウドサービスなどへ影響が及び、日常業務に支障をきたすことがあります。

    また、サービス停止に伴い、顧客や取引先からの問い合わせが急増し、カスタマーサポートや営業部門の対応負荷が高まることもあります。

    ECサイトでは注文処理や決済が滞り、BtoBサービスでは取引先の業務に影響を与えるなど、事業継続にも大きな影響を及ぼす可能性があります。さらに、障害対応のために情報システム部門やセキュリティ担当者が長時間の対応を余儀なくされ、本来予定していた業務が停滞するケースも少なくありません。

    企業の信頼低下

    DDoS攻撃によるサービス停止が長時間続いたり、繰り返し発生したりすると、企業に対する信頼の低下につながるおそれがあります。利用者は「サービスが安定して利用できない企業」という印象を持つ可能性があり、顧客離れや新規顧客の獲得機会の損失につながることもあります。

    さらに、DDoS攻撃をきっかけに、自社のセキュリティ対策やインシデント対応体制が十分であるかを取引先や顧客から問われることもあります。そのため、平時から適切な対策を講じるとともに、攻撃発生時には迅速かつ適切な対応を行うことが、企業の信頼維持につながります。

    企業が実施すべきDDoS攻撃対策

    DDoS攻撃は、完全に防ぐことが難しいサイバー攻撃の一つです。そのため、攻撃を受けることを前提に、被害を最小限に抑えるための対策を講じることが重要です。ここでは、企業が押さえておきたい代表的なDDoS攻撃対策を紹介します。

    通信の監視と異常検知

    DDoS攻撃による被害を最小限に抑えるためには、通信状況を継続的に監視し、通常とは異なるアクセスを早期に検知できる体制を整えることが重要です。

    アクセス数や通信量、リクエスト数などの推移を日頃から把握しておくことで、異常な増加が発生した際に迅速な対応につなげることができます。

    近年では、SIEM(Security Information and Event Management)やネットワーク監視ツールを活用し、異常な通信を自動で検知・通知する仕組みを導入する企業も増えています。

    DDoS攻撃は短時間で通信量が急増するケースが多いため、異常を検知してから対応を開始するまでの時間が重要です。

    CDN・WAF・DDoS対策サービスの活用

    DDoS攻撃は、攻撃元が世界中の多数の端末に分散しているため、自社設備だけで防ぎきることは難しく、外部サービスとの連携が対策の基本方針になります。特に、大量の通信が発生するボリューム攻撃では、自社ネットワークに到達する前に不要な通信を分散・遮断する仕組みが重要になります。

    • CDN(Content Delivery Network):コンテンツを複数のサーバーに分散して配信することで、通信負荷を分散し、サービスの継続性向上に役立ちます。
    • WAF(Web Application Firewall):Webアプリケーションへの不正なアクセスや不審なリクエストを検知・制御する機能を備えており、特にアプリケーション層を狙った攻撃への対策として有効です。
    • DDoS対策サービス:専用の設備で攻撃トラフィックを検知・吸収・フィルタリングし、正常な通信のみを自社環境へ転送する仕組みを提供しています。

    攻撃の規模やサービスの重要度に応じて、ISPやクラウド事業者が提供する対策サービスも含め、自社に適した構成を検討するとよいでしょう。

    自社の対策状況に不安がある場合

    「どのサービスを、どこまで導入すべきか」の判断が難しい場合は、専門会社によるDDoS耐性評価・セキュリティ診断を活用するのも一つの方法です。現状のリスクを可視化したうえで、優先度をつけて対策を進めることができます。

    インシデント対応体制の整備

    DDoS攻撃は、技術的な対策だけで完全に防ぐことは困難です。そのため、攻撃を受けた際に迅速かつ適切に対応できる体制をあらかじめ整備しておくことが重要です。

    具体的には、攻撃発生時の連絡体制や対応手順を文書化し、情報システム部門だけでなく、経営層や広報部門、カスタマーサポート部門など、関係者の役割を明確にしておくことが求められます。

    また、ISPやクラウド事業者、セキュリティベンダーなどの連絡先や支援体制を事前に確認しておくことで、緊急時の対応を円滑に進められます。

    まとめ

    DDoS攻撃は、大量の通信によってWebサイトやネットワークサービスを利用できない状態にするサイバー攻撃です。攻撃手法にはボリューム攻撃、プロトコル攻撃、アプリケーション層攻撃などがあり、それぞれ特徴や有効な対策が異なります。

    企業は、通信の監視や異常検知、CDN・WAF・DDoS対策サービスの活用に加え、インシデント対応体制の整備など、多層的な対策を講じることが重要です。また、攻撃を完全に防ぐことは難しいため、被害を最小限に抑えるための備えも欠かせません。

    攻撃発生時の具体的な対応手順や、復旧までの流れについては、以下の記事で詳しく解説しています。あわせてご覧ください。
    DDoS攻撃を受けたらどうする?初動対応から復旧までの流れを解説

    【関連記事】

    DDos攻撃について、SQAT.jpでは以下の記事でも解説しています。こちらもあわせてぜひご覧ください。

    【参考情報】


    DDoS対策や公開システムのセキュリティに不安はありませんか?

    DDoS攻撃への備えには、ネットワークやWebアプリケーションのリスクを把握することが重要です。BBSecでは、脆弱性診断をはじめ、お客様の環境に応じたセキュリティ評価をご提供しています。

    Webアプリケーション脆弱性診断バナー

    アクセス急増の原因が複雑で判断が難しい場合や、継続的な運用に不安がある場合は、第三者の視点を取り入れることも有効です。定期的なセキュリティ診断や評価を通じて、自社では気づきにくいリスクを把握することができます。


    公開日:2021年6月23日
    更新日:2026年7月29日

    編集責任:木下


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    APT攻撃対策とは?検知・監視・初動対応の考え方

    Share
    APT攻撃対策とは?検知・監視・初動対応の考え方アイキャッチ画像

    前回記事で解説した通り、APT攻撃は標的組織を事前に調査したうえで侵入し、権限昇格や横展開を重ねながら目的の情報に近づいていきます。一度侵入を許すと長期間にわたり情報窃取や不正活動が継続するケースも少なくありません。そのためAPT攻撃対策では「侵入させない」ことだけを目指すのではなく、侵入前対策・侵入後対策・インシデント対応体制を組み合わせ、早期発見と被害最小化を実現する仕組みが欠かせません。本記事では、その具体的な対策内容について解説します。

    APT攻撃の侵入経路や攻撃の流れについて詳しく知りたい方は、「APT攻撃の手口とは?侵入から情報窃取までの流れを解説」で、初期侵入から情報窃取までのプロセスを解説しています。ぜひあわせてご覧ください。

    なぜAPT攻撃は防ぎにくいのか

    APT攻撃が防ぎにくい理由は、攻撃者が特定の組織を狙い、時間をかけて侵入経路を探すためです。一般的なマルウェア感染やばらまき型攻撃とは異なり、APT攻撃では、攻撃者が標的組織の業務、取引先、利用システム、従業員の役割などを事前に調査します。そのうえで、標的型メールや脆弱性の悪用、正規アカウントの不正利用など、検知されにくい手口を選びます。また、APT攻撃では、最初の侵入後すぐに目立つ被害が発生するとは限りません。攻撃者は内部ネットワークに潜伏し、権限昇格や横展開を行いながら、機密情報や認証情報の所在を探ります。正規の管理ツールや盗まれたID・パスワードを使って活動する場合もあり、従来型の境界防御だけでは不審な動きを見落とす可能性があります。そのため、APT攻撃対策では、入口を守る対策に加えて、侵入後の異常を検知する仕組み、ログをもとに調査できる体制、被害を最小化する初動対応が欠かせません。さらに、入口対策だけでなく、「侵入を前提」とした検知・監視・対応体制も必要です。

    侵入前対策

    APT攻撃への備えとして、まず重要になるのは侵入前対策です。侵入前対策とは、攻撃者が組織内へ入り込む可能性を下げるための基本的な防御策です。完全な防御は難しいものの、攻撃者にとって侵入しにくい環境を作ることで、被害の発生確率を下げることができます。 なかでも重要なのが、多要素認証、脆弱性管理、標的型メール対策です。これらは単独ではなく、多層防御の考え方で組み合わせることが重要です。複数の対策を組み合わせ、攻撃者が一つの弱点を突破しても、次の段階へ進みにくい状態をつくることが求められます。

    MFA(多要素認証)

    IDとパスワードだけに頼らず、スマートフォンアプリ、セキュリティキー、生体認証など、複数の認証要素を組み合わせて本人確認を行う仕組みです。APT攻撃では、フィッシングメールやマルウェアによって認証情報が盗まれることがあります。IDとパスワードだけで社内システムやクラウドサービスへアクセスできる環境では、攻撃者が正規ユーザになりすましてログインするリスクが高まります。MFAを導入することで、パスワードが漏えいした場合でも、不正ログインを防げる可能性が高まります。ただし、MFAを導入すればすべての攻撃を防げるわけではありません。近年は、MFAを突破しようとするフィッシングや、認証疲れを狙った攻撃も確認されています。そのため、可能であればフィッシング耐性の高い認証方式(例:FIDO2、パスキーなど)を採用し、管理者アカウントやリモートアクセス、クラウド管理画面など、重要度の高い環境から優先的に適用することが重要です。

    脆弱性管理

    APT攻撃では、VPN機器、公開サーバ、メールサーバ、業務システム、クラウド環境などの脆弱性が侵入経路として悪用されることがあります。特に、インターネットからアクセス可能な機器やシステムに未修正の脆弱性が残っている場合、攻撃者にとって侵入の足がかりになります。脆弱性管理では、単に脆弱性情報を収集するだけでなく、自社のどのシステムに影響があるのか、外部公開されているのか、悪用事例があるのか、業務上の重要度は高いのかを踏まえて、対応の優先順位を決める必要があります。すべての脆弱性へ同時に対応することは現実的ではないため、実際に悪用されている脆弱性や、外部から攻撃可能なシステムを優先して修正する考え方が重要です。また、パッチ適用がすぐに難しい場合には、一時的な回避策、アクセス制限、監視強化、不要サービスの停止などを組み合わせる必要があります。APT攻撃では、脆弱性の放置が初期侵入や横展開につながる可能性があるため、脆弱性管理は単なる情報システム部門の運用作業ではなく、経営リスクを下げるための重要な取り組みといえます。

    標的型メール対策

    標的型メールは、APT攻撃の代表的な侵入経路の一つです。現在はメールだけでなく、チャットやクラウドサービスを悪用した攻撃も増えています。標的型メール対策では、メールセキュリティ製品による検査だけでなく、従業員教育、訓練、報告しやすい仕組みの整備が重要です。攻撃メールを完全に遮断することは難しいため、従業員が不審なメールに気づき、開封前または開封後すぐに報告できる体制を作る必要があります。また、メールをきっかけに認証情報が入力されるケースもあるため、MFAやアクセス制御と組み合わせて対策することが効果的です。標的型メール対策は、単独で完結するものではなく、認証管理、端末防御、ログ監視、インシデント対応と連動させることで、初めてAPT攻撃への実効性が高まります。

    標的型攻撃の手口の詳細は「標的型攻撃とは?代表的な手口と企業が取るべき対策を解説」をご参照ください。

    侵入後対策

    APT攻撃では、侵入前対策をすり抜けられる可能性があります。そのため、侵入後に攻撃者の活動を検知し、被害拡大を防ぐ仕組みが必要です。侵入後対策の中心になるのが、EDR、SIEM、ログ監視です。従来のセキュリティ対策では、外部からの攻撃を境界で防ぐことに重点が置かれてきました。しかし、クラウド利用、テレワーク、サプライチェーン連携が広がる現在では、社内と社外の境界があいまいになっています。APT攻撃への対策では、端末、サーバー、ネットワーク、クラウド、IDの動きを継続的に監視し、通常とは異なる振る舞いを早期に見つけることが重要です。

    EDR

    EDRは、Endpoint Detection and Responseの略で、PCやサーバーなどのエンドポイント上の不審な挙動を検知し、調査や対応を支援する仕組みです。APT攻撃では、マルウェアの実行、認証情報の窃取、管理ツールの悪用、不審なプロセスの起動などが端末上で発生することがあります。EDRは、こうした端末上の動きを可視化し、攻撃の兆候を把握するために有効です。EDRの重要な役割は、単にマルウェアを検知することではありません。侵入後に何が起きたのか、どの端末からどの端末へ移動したのか、どのファイルが操作されたのか、どのアカウントが使われたのかを調査するための情報を提供する点にあります。APT攻撃では、発見時点で攻撃がすでに横展開している場合もあります。そのため、EDRによって端末単位の挙動を把握し、感染端末の隔離、プロセス停止、調査対象の特定などを迅速に行える状態を整えておく必要があります。最近では、EDRに加え、メールやクラウドも含めて分析するXDRを導入する企業も増えています。

    SIEM

    SIEMは、Security Information and Event Managementの略で、複数のシステムからログを集約し、相関分析(複数のログを組み合わせて関連性を分析すること)を行う仕組みです。APT攻撃では、個々のログだけを見ると小さな異常に見える行動が、複数のログを組み合わせることで攻撃の流れとして見えてくることがあります。たとえば、通常とは異なる国や地域からのログイン、深夜帯の管理者権限利用、短時間での大量アクセス、普段使わない端末からの認証、ファイルサーバへの大量アクセスなどは、単独では見逃されることがあります。しかし、SIEMで複数のログを関連付けることで、初期侵入、権限昇格、横展開、情報窃取の兆候を把握しやすくなります。SIEMを有効に活用するには、ログを集めるだけでなく、どのログを監視対象にするのか、どのような条件でアラートを出すのか、誰が確認するのか、アラート発生後にどのような初動を取るのかを事前に決めておく必要があります。そしてツールを導入するだけではなく、運用設計まで含めて整えることも重要です。社内で運用が難しい場合は、SOCサービスなど外部監視サービスを利用する方法もあります。

    ログ監視

    ログ監視は、APT攻撃対策の基盤となる取り組みです。攻撃者の行動は、認証ログ、端末ログ、プロキシログ、DNSログ、VPNログ、クラウドサービスの監査ログ、ファイルアクセスログなどに痕跡として残ることがあります。しかし、ログが取得されていなかったり、保存期間が短かったり、必要な項目が記録されていなかったりすると、インシデント発生後に攻撃の流れを追跡できません。特にAPT攻撃では、侵入から発見までに時間がかかることがあるため、一定期間のログを保管し、過去にさかのぼって調査できる状態を作る必要があります。ログ監視では、単に大量のログを保存するだけでは不十分です。重要なのは、通常時のアクセス傾向を把握し、そこから外れた動きを見つけることです。普段アクセスしないサーバーへの接続、短時間での権限変更、退職者アカウントの利用、海外からのVPN接続、大量のファイル圧縮や外部送信など、攻撃の兆候となる行動を継続的に確認する必要があります。保持期間は法令や業種要件、インシデント対応を考慮して決める必要があります。

    ゼロトラストの考え方

    ここまで紹介した侵入前対策・侵入後対策は、いずれもゼロトラストという一つの考え方の実装例と捉えることができます。

    ゼロトラストとは、社内ネットワークにいるから安全、正規ユーザだから安全といった前提を置かず、ユーザ、端末、アプリケーション、データへのアクセスを継続的に確認する考え方です。従来の境界防御では、社内ネットワークの内側を比較的信頼する考え方が一般的でした。しかし、APT攻撃では、一度内部へ侵入した攻撃者が正規アカウントや管理ツールを悪用し、横展開する可能性があります。そのため、社内ネットワーク内の通信であっても、常に正当性を確認し、必要最小限の権限だけを付与することが前提になります。ゼロトラストの実現には、MFA、ID管理、端末管理、アクセス制御、ログ監視、ネットワーク分離、継続的なリスク評価などが関係します。単一の製品を導入すれば完成するものではなく、組織の業務やシステム構成に合わせて段階的に整備していく必要があります。

    APT攻撃への対策としてゼロトラストを取り入れることで、攻撃者が一つのアカウントや端末を悪用しても、重要情報へ簡単に到達できない環境を作りやすくなります。侵入を前提に、被害範囲を限定し、異常を早期に検知するという点で、ゼロトラストはAPT対策と相性のよい考え方です。

    インシデント対応体制

    APT攻撃への対策では、検知した後の初動対応によって被害の大きさが大きく左右されます。初動対応では「封じ込め(Containment)」「根絶(Eradication)」「復旧(Recovery)」の順で進める考え方が一般的です。不審な挙動を発見しても、対応手順や判断基準が決まっていなければ、関係者への連絡、端末隔離、証拠保全、外部報告、復旧判断が遅れてしまいます。その間に攻撃者が横展開を進めたり、情報を外部へ持ち出したりする可能性があります。

    インシデント対応体制では、まず「誰が判断するのか」を明確にする必要があります。情報システム部門、セキュリティ担当、経営層、法務、広報、事業部門、外部専門家など、関係者の役割を事前に決めておくことが重要です。特にAPT攻撃では、技術的な調査だけでなく、事業影響、顧客対応、取引先対応、法的対応、広報対応が必要になる場合があります。 また、初動対応では、証拠を消さないことも重要です。感染が疑われる端末をすぐに初期化してしまうと、侵入経路や攻撃範囲を調査するための情報が失われる可能性があります。端末の隔離、ログ保全、アカウント停止、通信遮断、影響範囲の確認などを、状況に応じて慎重に実施する必要があります。平時からインシデント対応手順を整備し、訓練を行っておくことで、実際の攻撃発生時に混乱を減らすことができます。APT攻撃対策は、技術的な防御だけではなく、組織としてどのように判断し、対応するかまで含めた取り組みです。

    まとめ

    APT攻撃対策では、侵入を完全に防ぐことだけを目指すのではなく、侵入前対策、侵入後対策、インシデント対応体制を組み合わせることが重要です。MFA、脆弱性管理、標的型メール対策によって侵入リスクを下げ、EDR、SIEM、ログ監視によって侵入後の不審な動きを早期に検知します。さらに、インシデント対応体制を整備し、攻撃が疑われる場合に迅速な初動対応を取れるようにしておくことで、被害の拡大を抑えることができます。APT攻撃は、攻撃者が時間をかけて目的達成を狙う攻撃であるため、企業側も継続的な監視と改善を前提に備える必要があります。

    次の記事はこちら
    APT攻撃事例から学ぶ ―国内外の被害事例と企業が取るべき対策―」
    APT攻撃は実際にどのような企業・組織で発生しているのでしょうか。代表的な国内外の事例から、攻撃の特徴や企業が学ぶべきポイントを解説します。

    【参考情報】

    編集責任:木下


    APT攻撃への備えをご検討中の方へ

    APT攻撃は、侵入を完全に防ぐことが難しい高度なサイバー攻撃です。侵入経路の把握や脆弱性管理、監視体制の強化など、継続的な対策が求められます。弊社、ブロードバンドセキュリティ(BBSec)では、脆弱性診断、アタックサーフェス管理調査、セキュリティ運用サービス、コンサルティングサービスなど、企業のセキュリティ対策を支援するサービスを提供しています。


    ウェビナー開催のお知らせ

    最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    見落としがちなIT資産がセキュリティ事故を招く?企業で起こりやすい5つの管理課題

    Share
    「見落としがちなIT資産管理の課題5選」アイキャッチ画像

    前回記事では、IT資産管理の基本と重要性を解説しました。管理されていない端末やクラウド環境、シャドーIT、サポート終了製品など、見落とされたIT資産が被害につながるケースも少なくありません。今回は、管理が行き届かない場合に実際どのような問題が起こりやすいのか、企業で起こりやすい5つの管理課題を具体的に見ていきます。

    IT資産管理の基本について知りたい方は、まず「IT資産管理とは」をご覧ください。
    IT資産管理とは?企業のセキュリティ対策で最初に取り組むべき理由を解説

    セキュリティ事故は、必ずしも高度な攻撃だけで起こるわけではありません。実際には、管理されていない端末、放置されたクラウド環境、退職者のアカウント、サポート終了ソフトウェアなど、見落としがちなIT資産がきっかけになることがあります。IT資産管理が不十分な状態では、脆弱性情報が公開されても対象資産を特定できず、インシデント発生時にも影響範囲をすばやく把握できません。

    なぜ管理漏れが起こるのか

    IT資産の管理漏れは、担当者の怠慢だけで起こるものではありません。むしろ、事業スピードに管理体制が追いつかないことで発生します。新しいSaaSを部門単位で契約する、検証用にクラウド環境を作成する、テレワーク用に端末を追加する、業務委託先にアカウントを付与する。こうした日常的な業務の中で、台帳更新や承認プロセスが後回しになると、実態とのズレが広がっていきます。

    企業で起こりやすい5つの管理課題

    台帳が更新されない

    IT資産管理で最も起こりやすい課題は、資産台帳が更新されないことです。導入時には正確だった台帳も、ソフトウェア更新やクラウド環境の追加が反映されなければ、すぐに実態とずれていきます。特にExcelやGoogleスプレッドシートで管理している場合、更新担当者が限られ、現場の変更が反映されないまま時間が経過しがちです。その結果、台帳上は存在するのに実際には廃棄済みの機器、逆に台帳にはないが稼働している資産が発生します。インシデント対応時にこの状態だと、影響範囲の特定に時間がかかり、初動対応の遅れにつながります。

    シャドーITが増える

    シャドーITとは、情報システム部門や管理部門が把握していないIT資産やサービスが、業務目的で利用されている状態を指します。英国のサイバーセキュリティ機関NCSCでは、「シャドーITは悪意によって生まれるとは限らず、従業員が業務を進めるために、承認済みのツールやプロセスでは対応できない課題を解決しようとして発生することが多い」と説明しています。たとえば、ファイル共有が不便だから個人用クラウドストレージを使う、社内承認に時間がかかるため部門でSaaSを契約する、開発検証のために個人名義に近い形でクラウド環境を作る、といった行動です。本人に悪意がなくても、会社のセキュリティポリシー、バックアップ、アクセス制御、監査ログ、退職時のアカウント削除の対象外になるため、情報漏洩や不正アクセスのリスクが高まります。シャドーIT対策で重要なのは、単に禁止することではありません。なぜ現場が非公式な手段を使わざるを得なかったのかを把握し、業務に必要なツールを安全に使える仕組みに変えることです。

    クラウド資産が把握できない

    クラウド環境では、サーバやストレージ、データベース、コンテナ、API、アカウント、権限設定などが短時間で作成・変更・削除されます。オンプレミス環境のように物理的なサーバーが目に見えるわけではないため、管理対象から漏れやすいのが特徴です。検証用に作ったクラウド環境が放置され、インターネットに公開されたままになる。開発者が一時的に広い権限を付与し、その後も戻されない。ログ設定やバックアップ設定が本番環境と異なる。こうした状態は、クラウド利用が進む企業ほど起こりやすくなります。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)の「Cybersecurity Performance Goals」でも、既知の資産だけでなく、未知の資産、シャドー資産、未管理資産を特定し、新たな脆弱性への検知・対応を速めることが目的として示されています。

    EOL(End of Life)・EOS(End of Service)を見逃す

    サポートが終了したOS、ネットワーク機器、VPN機器、業務アプリケーション、ミドルウェアを使い続けることも、IT資産管理上の大きな課題です。サポートが終了した製品は、脆弱性が発見されても修正プログラムが提供されない可能性があります。資産台帳にサポート期限や保守期限が記録されていなければ、更新計画を立てることもできません。

    EOL・EOSについては前回記事でも触れていますので、あわせてご覧ください。

    また、ソフトウェア資産の構成管理まで行いたい場合、EOL・EOS対策の延長としてSBOM(ソフトウェア部品表)も重要になります。経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引 Ver.2.0」では、資産管理台帳だけでは、下位コンポーネントとして利用されるOSSなどに脆弱性が見つかった場合に、間接的な影響を検知できない場合があると説明されています。

    SBOMについては、「SBOMとは?ソフトウェア部品表の基本と企業が導入すべき理由」でも解説しています。あわせてご覧ください。

    部門ごとに管理している

    IT資産管理が部門ごとに分断されていることも、企業でよく見られる課題です。情報システム部門はPCとネットワーク機器を管理し、開発部門はクラウド環境を管理し、総務部門はリース契約を管理し、各事業部がSaaS契約を管理している。このような状態では、全社としてどのIT資産が存在するのかを把握できません。部門ごとの管理は、現場のスピードを保つうえでは便利です。しかし、セキュリティ事故が起きたときには、誰が責任者なのか、どの情報が保存されているのか、どの範囲に影響があるのかが分からなくなります。特に、SaaSやクラウドサービスでは、管理者権限を持つ担当者が異動・退職した後に、契約やアカウントだけが残り続けるケースもあります。

    管理課題を解決するポイント

    IT資産管理の課題を解決するには、台帳を作るだけでは不十分です。重要なのは、資産が増える、変わる、使われなくなるタイミングで、台帳や管理システムが自然に更新される運用を作ることです。まず、IT資産管理の対象範囲を明確にします。PCやサーバだけでなく、クラウド環境、SaaS、アカウント、ネットワーク機器、ソフトウェア、ライセンスまで含めるかを決めます。次に、資産ごとに管理責任者を定めます。所有者が曖昧な資産は、脆弱性対応や費用管理、廃棄判断が遅れやすくなります。そのうえで、購買、入社、異動、退職、クラウド作成、SaaS契約、機器廃棄といった業務フローにIT資産管理を組み込みます。ツールを導入する場合も、単体で完結させるのではなく、ID管理、EDR、MDM、脆弱性管理、クラウド管理と連携させることで、実態に近い情報を保ちやすくなります。

    課題を解決する具体的な運用方法については「IT資産管理を効率化する方法とは?担当者が押さえたい運用のポイント」をご覧ください。

    まとめ:見えていないIT資産は、守れない

    IT資産管理の課題は、すぐに大きな障害として表面化するとは限りません。しかし、管理漏れ、シャドーIT、クラウド資産の放置、サポートが終了した製品・機器の見逃し、部門ごとの分断が積み重なると、セキュリティ事故の温床になります。

    次回は、こうした課題を解決するための具体的な運用方法について解説します。

    【参考情報】

    編集責任:木下


    公開IT資産を可視化してみませんか?

    社内で管理しているIT資産と、インターネット上から見える資産は必ずしも一致しません。攻撃者視点で公開資産を可視化する「アタックサーフェス調査サービス」をご紹介します。

    BBSecのアタックサーフェス調査サービス

    インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報(OSINT)を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。


    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    アフラック不正アクセスで約438万人の個人情報漏洩 ―保険会社を狙うサイバー攻撃のリスクと企業が取るべき対策

    Share
    「アフラック不正アクセスで約438万人の個人情報漏洩」アイキャッチ画像

    保険会社が保有する個人情報は、単なる氏名や住所にとどまりません。契約内容、証券番号、保障内容、口座情報など、生活や資産に深く関わる情報が含まれるため、ひとたび情報漏えいが発生すると、なりすまし連絡やフィッシング詐欺、電話詐欺などに悪用される恐れがあります。

    アフラック生命保険は2026年6月30日、「契約者専用サイト「アフラック よりそうネット」などのシステムが第三者による不正アクセスを受け、顧客の個人情報を含む一部情報が漏えいした」と公表しました。対象となる顧客数は約438万人で、このうち約23万人については保険料振替口座情報も含まれるとされています。現時点で、本件に関わる情報の不正利用は確認されていません。 本記事では、アフラックの不正アクセス事案の概要を整理しながら、保険会社や金融機関、個人情報を扱う企業が見直すべきサイバーセキュリティ対策、情報漏えい対策、インシデント対応のポイントを解説します。

    ※本記事は2026年6月30日までに公開された情報もとに作成しています。ご覧いただく時期によっては古い情報となっている場合もありますので、ご承知おきください。

    アフラックで発生した不正アクセスと個人情報漏洩の概要

    アフラック生命保険の公式発表*4によると、不正アクセスを受けたのは、契約者専用サイト「アフラック よりそうネット」などのシステムです。「アフラック よりそうネット」は、契約内容の確認や住所・電話番号の変更などを、パソコンやスマートフォンから行える契約者向けサイトと説明されています。

    漏洩した顧客関連の情報には、氏名、生年月日、性別、住所、電話番号、証券番号、保障内容、保険料振替口座情報などが含まれます。保険料振替口座情報には、金融機関名、支店名、預金種類、口座番号、口座名義などが含まれるとされています。一方で、「マイナンバーおよびクレジットカード情報は含まれていない」と公表されています。漏洩件数は、顧客数で約438万人です。そのうち、漏洩した項目に保険料振替口座情報が含まれる顧客数は約23万人とされています。また、代理店関連の個人情報として、代理店代表者氏名、代理店住所、代理店電話番号など、約4万店分の情報も漏洩したとのことです。

    不正アクセスはいつ発生し、いつ判明したのか

    公式発表によれば、情報漏洩が判明したのは2026年6月25日です。同日、アフラックは当該不正アクセスを遮断し、不正アクセスの拡大を防ぐため、関連するシステムを停止しました。その後の調査で、不正アクセスが最初に発生したのは2026年6月15日であり、6月25日までに複数回、不正にアクセスされていたことが確認されています。一方で、原因の詳細は「調査中」とされています。現時点で、脆弱性の悪用、認証情報の窃取、内部アカウントの悪用、ランサムウェア攻撃など、具体的な攻撃手口は公表されていません。

    現在停止しているサービスと顧客対応

    アフラックは、不正アクセスの拡大を防ぐため、一部システムを停止しています。公式ページでは、よりそうネット、人間ドック・健診予約サービス、妊活コンシェルジュサービス、オンライン家計簿サービス「マネーフォワード for アフラック」、アフラックAIサポートコンシェルジュなどが、現在利用できないサービスとして案内されています。ただし保険金・給付金の請求をはじめとする各種問い合わせや手続きは、「コールセンターなどで通常どおり受け付けている」と説明されています。対象となる顧客には、「順次、お詫びとお知らせの文書を送付する」としており、「金融庁・警察等の関係機関にも報告済み」とのことです。 システム停止は、利用者にとって不便を生みます。しかし、不正アクセスの範囲が判明していない段階で関連システムを止める判断は、被害拡大を抑えるうえで重要な初動対応です。

    独立行政法人情報処理推進機構(IPA)が公開している「情報漏えい発生時の対応ポイント集」でも、不正アクセスによって個人情報や機密情報が漏えいする危険性が確認された場合、ネットワークからの切り離しやサービス停止などの処置が必要になると説明されています。

    なぜ保険会社の個人情報漏えいは深刻なのか

    今回のアフラック不正アクセス事案で注目すべき点は、漏洩した可能性のある情報の組み合わせです。氏名、住所、電話番号、生年月日だけでなく、証券番号や保障内容、保険料振替口座情報まで含まれる場合、攻撃者は「保険契約の確認」「給付金手続き」「口座情報の確認」「契約内容の更新」などを装った連絡を行いやすくなります。これは、単なるメールアドレス漏洩よりも、なりすましの説得力が高まりやすい情報漏洩といえます。

    フィッシング対策協議会はフィッシングについて、「実在する組織を騙って、ユーザネーム、パスワード、アカウントID、ATMの暗証番号、クレジットカード番号といった個人情報を詐取すること」と説明しています*2。今回の事案で実際にフィッシング被害が確認されたわけではありませんが、保険会社をかたる不審なメール、SMS、電話には十分な注意が必要です。 特に、金融機関名や口座番号が含まれる可能性がある顧客については、口座そのものから直ちに出金されるとは限らないものの、別の詐欺や本人確認の突破材料として悪用されるおそれがあります。アフラックも公式発表の中で、不審な連絡を受けた場合や、保険料振替口座における不審な取引などの懸念が生じた場合には、同社連絡先へ連絡するよう案内しています。

    企業が学ぶべきポイントは「侵入されない」だけではない

    サイバーセキュリティ対策というと、ファイアウォール、ウイルス対策ソフト、多要素認証、脆弱性診断など、「侵入を防ぐ対策」に目が向きがちです。もちろん、これらの対策は重要です。しかし、今回のように不正アクセスが複数回行われ、一定期間後に判明した事案を見ると、企業に求められるのは「侵入を完全に防ぐ」ことだけではありません。重要なのは、侵入の兆候を早期に検知し、被害範囲を特定し、必要なシステムを迅速に隔離し、顧客や関係機関へ適切に説明できる体制です。

    個人情報保護委員会では、「個人データの漏えい等が発生し、個人の権利利益を害するおそれがある場合、個人情報保護委員会への報告および本人への通知が必要」と説明しています*3。該当する事態には、「財産的被害が生じるおそれがある事態」、「不正の目的をもって行われた漏えい等が発生した事態」、「1,000人を超える漏えい等が発生した事態」が含まれます。また、本人へ通知する際には、「概要、個人データの項目、原因などを、本人にとって分かりやすい方法」で伝える必要があります。企業の情報漏洩対応では、技術的な調査だけでなく、顧客への説明、問い合わせ対応、監督官庁への報告、再発防止策の公表までを一連のインシデント対応として設計しておく必要があります。

    関連記事:情報漏洩対策の基本を詳しく知りたい方へ

    情報漏洩対策は、不正アクセスを防ぐだけでは十分ではありません。情報漏洩が発生する原因や企業への影響、技術・運用・組織の3つの観点から取り組むべき対策について、基礎から分かりやすく解説しています。あわせてご覧ください。
    情報漏洩対策とは何か ―企業が知るべき原因・リスク・防止策の全体像―

    金融・保険業界で高まるサードパーティリスク管理の重要性

    今回のアフラックの事案について、現時点の公式発表では、委託先や外部サービスが侵入経路だったとは説明されていません。そのため、本件をサードパーティ起点のインシデントと断定することはできません。一方で、金融庁は金融分野のサイバーセキュリティ対策として、サードパーティ・サイバーセキュリティリスク管理の重要性を継続的に取り上げています*4。金融庁の関連資料では、金融機関が管理すべきサードパーティや、その先に存在するNthパーティの範囲、集中リスク、契約後の継続的なモニタリングなどが課題として示されています。

    アフラックでは2023年にも、業務委託先の外部業者において同社保有の個人情報の一部が流出した事案が公表されていました*5。この2023年事案では、対象となった顧客数は132万3,468人で、流出した個人情報の項目は姓のみ、年齢、性別、証券番号、保険種類番号、保障額、保険料などでした。今回の2026年事案とは発生経路や漏洩項目が異なるため同一視はできませんが、保険会社が扱う情報の価値と、外部委託先を含めた管理体制の重要性を考えるうえで、過去事例として参照できます。

    保険会社、金融機関、医療機関、自治体、BtoBサービス事業者など、重要な個人情報を扱う組織では、自社システムだけでなく、外部委託先、クラウドサービス、SaaS、開発会社、運用保守会社まで含めたリスク管理が欠かせません。契約時のセキュリティチェックだけで終わらせず、運用中の監査、ログ確認、脆弱性対応、インシデント発生時の連絡体制まで確認しておくことが重要です。

    企業が今すぐ見直すべきセキュリティ対策

    今回の事案から企業が学ぶべき第一のポイントは、個人情報を保管するシステムのアクセス管理です。顧客情報、契約情報、口座情報などを扱う管理画面では、多要素認証、IPアドレス制限、権限の最小化、休眠アカウントの棚卸し、特権IDの監視を徹底する必要があります。IDとパスワードだけに依存した認証は、フィッシングや認証情報漏えいによって突破されるリスクがあります。

    第二のポイントは、ログ監視と異常検知です。不正アクセスが発生しても、ログが取得されていなければ、侵入経路や閲覧された情報、被害範囲を後から正確に追うことが難しくなります。個人情報保護委員会のフォレンジック調査に関する資料でも、不正アクセスの原因や被害範囲を明らかにし、効果的な再発防止策につなげるために、ログなどの証拠保全が重要であることが示されています。

    第三のポイントは、インシデント発生時の復旧体制です。経済産業省の「サイバーセキュリティ経営ガイドライン Ver 3.0」では、インシデントにより業務停止等に至った場合に備え、復旧手順書の策定、復旧対応体制の整備、サプライチェーンも含めた実践的な演習の実施が必要であるとされています。顧客向けサービスを止める判断、代替手段の案内、問い合わせ窓口の設置は、平時に準備していなければ迅速に実行できません。

    第四のポイントは、個人情報の持ち方そのものの見直しです。すべての情報を同じシステムで参照できる状態にしていないか、業務上不要な項目まで保存していないか、口座情報などの重要情報に追加の保護措置を設けているかを確認する必要があります。情報漏えい対策では、侵入を防ぐことに加え、万が一侵入された場合でも漏洩範囲を最小化する設計が求められます。

    顧客側が注意すべきこと

    今回のアフラック不正アクセス事案では、現時点で情報の不正利用は確認されていないとされています。しかし、漏洩した可能性のある情報には電話番号や住所、証券番号、保障内容、口座情報が含まれるため、顧客側でも不審な連絡に注意する必要があります。もしも、「契約内容の確認が必要です」「保険料の引き落とし口座を再登録してください」「給付金の手続きに必要です」といった連絡があった場合でも、メールやSMSに記載されたURLを安易に開かず、公式サイトや正規の問い合わせ窓口から確認することが大切です。警察庁もフィッシング対策として、迷惑メッセージブロック機能の活用や、ID・パスワードの使い回しを避けることを呼びかけています*6。特に、保険会社や金融機関を名乗る電話で、暗証番号、認証コード、インターネットバンキングのログイン情報などを求められた場合は注意が必要です。正規の企業を装った連絡であっても、その場で情報を伝えず、いったん電話を切って公式窓口に確認する対応が安全です。

    まとめ 情報漏えい対策は「防御」から「検知・対応・復旧」へ

    アフラックの不正アクセスによる個人情報漏えいは、保険会社や金融機関だけの問題ではありません。顧客情報、契約情報、決済情報、口座情報、問い合わせ履歴などを扱うすべての企業にとって、情報漏えい対策とインシデント対応の重要性を改めて示す事案です。

    今回の公式発表で確認できるのは、約438万人の顧客情報が漏えいし、そのうち約23万人については保険料振替口座情報が含まれること、代理店約4万店分の情報も漏洩したこと、そして不正アクセスが6月15日から6月25日まで複数回確認されていることです。一方で、原因や攻撃手口の詳細は調査中であり、現時点で断定できる情報は限られています。

    企業に求められるのは、侵入を防ぐための対策だけではありません。異常を早く見つける監視体制、被害範囲を確認するログ管理、顧客へ説明できる情報整理、サービス停止時の代替手段、復旧手順、再発防止策までを含めた総合的なサイバーセキュリティ体制です。 個人情報漏洩は、発生してから対応を考えるのでは遅すぎます。自社の顧客情報がどこにあり、誰がアクセスでき、どのログが残り、インシデント発生時に誰が判断するのか。今回の事案を機に、企業は不正アクセス対策、脆弱性管理、ログ監視、委託先管理、インシデント対応計画を改めて見直す必要があります。

    【参考情報】

    編集責任:木下


    BBSecの脆弱性診断・セキュリティ対策支援サービス

    BBSec(ブロードバンドセキュリティ)では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。


    ウェビナー開催のお知らせ

  • 2026年7月8日(水)13:00~14:00「企業は何から対策すべきか?― OWASP Top 10:2025から読み解く、最新のセキュリティリスクと対策の考え方 ―
  • 2026年7月15日(水)14:00~15:00「AI事業者ガイドライン第1.2版に基づくセキュリティ対策の実践ポイント~生成AIからAIエージェントへ~
  • 2026年7月22日(水)14:00~15:00「そのIT資産、本当に把握できていますか?~見落としがちなセキュリティリスクと対策の第一歩~
  • 最新情報はこちら


    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    サッポロHD海外2社に不正アクセス ―海外グループ会社を狙うサイバー攻撃リスクとは

    Share
    「サッポロHD海外2社に不正アクセス」アイキャッチ画像

    サッポロホールディングスが公表した海外グループ会社2社への不正アクセスは、海外拠点を狙ったサイバー攻撃リスクを改めて浮き彫りにしました。現時点では情報漏洩の有無や影響範囲は調査中ですが、海外子会社や現地法人のセキュリティがグループ全体の事業継続や信頼に影響を及ぼす可能性があります。本記事では、本件の概要を整理するとともに、海外拠点が攻撃の入口になりやすい理由や、企業が見直すべき認証管理、ログ監視、脆弱性管理などの対策について解説します。

    ※本記事は2026年6月30日までに公開された情報もとに作成しています。ご覧いただく時期によっては古い情報となっている場合もありますので、ご承知おきください。


    サッポロホールディングス株式会社は2026年6月24日、同社の海外グループ会社2社のシステムに対して不正アクセスが発生したことを公表しました*7。対象となったのは、POKKA PTE. LTD.とSLEEMAN BREWERIES LTD.です。サイバー攻撃の恐れがある不正な通信ログを検知し、初動調査を行った結果、不正アクセスが判明したとされています。

    今回の事案で注目すべきなのは、国内本社ではなく海外グループ会社で不正アクセスが確認された点です。企業のグローバル展開が進むなか、海外子会社、海外拠点、現地法人、委託先、販売会社などを含めたセキュリティ対策は、もはや一部門だけの問題ではありません。サイバー攻撃は、もっとも守りが弱い場所から侵入し、グループ全体の信頼や事業継続に影響を及ぼす可能性があります。 サッポロホールディングスの公表によると、POKKA PTE. LTD.では2026年6月14日、SLEEMAN BREWERIES LTD.では同年6月17日に不正アクセスを確認しています。安全確保のため、関係するシステムや機器は遮断され、外部専門家の協力のもと原因や影響範囲の調査が進められています。公表時点では、情報漏洩の事実および影響範囲は確認中であり、国内事業への影響は確認されていません。また、2社への不正アクセスについて、現時点で因果関係は認められていないとされています。

    サッポロHDの海外グループ会社で何が起きたのか

    今回の不正アクセスは、サッポロホールディングスの海外グループ会社であるPOKKA PTE. LTD.とSLEEMAN BREWERIES LTD.において確認されました。POKKA PTE. LTD.は海外飲料事業、SLEEMAN BREWERIES LTD.は海外酒類事業に関係する企業です。サッポロホールディングスは海外酒類事業を北米中心に展開しており、海外飲料事業ではシンガポール、マレーシア、中東など約60か国でPOKKAブランドを展開していると説明しています。

    このことから、今回の事案は単なる「海外拠点のトラブル」として片付けるべきものではありません。企業が海外展開を進めるほど、システム、ネットワーク、アカウント、取引先、現地運用体制は複雑になります。国内本社のセキュリティレベルが高くても、海外子会社や現地拠点の監視体制、認証管理、端末管理、ログ管理が十分でなければ、攻撃者にとって侵入口になり得ます。ただし、現時点で公表されている情報からは、ランサムウェア攻撃であったか、特定の攻撃グループが関与したか、どのような情報が外部に流出したかは確認できません。したがって、本件を「情報漏洩事故」や「ランサムウェア被害」と断定することは避ける必要があります。一次ソースから確認できるのは、不正な通信ログの検知、不正アクセスの判明、関係システム・機器の遮断、外部専門家による調査、情報漏洩の有無は確認中という点です。

    なぜ海外グループ会社はサイバー攻撃の入口になりやすいのか

    海外グループ会社や海外子会社は、サイバー攻撃の入口になりやすい構造的なリスクを抱えています。理由の一つは、拠点ごとにIT環境やセキュリティ運用の成熟度が異なりやすいことです。本社ではEDR、ログ監視、多要素認証、脆弱性管理が整備されていても、海外拠点では現地事情や人員不足により、同じ水準の対策が実施されていないケースがあります。

    もう一つの理由は、グループ会社が業務上、本社や他拠点とつながっていることです。販売、製造、物流、会計、メール、クラウドサービスなど、業務に必要な連携がある以上、一つの拠点への不正アクセスが、別拠点への攻撃や認証情報の悪用につながる可能性は否定できません。今回のサッポロホールディングスの発表では2社間の因果関係は認められていないとされていますが、企業一般のリスクとしては、海外拠点を含めたグループ全体のセキュリティ統制が重要になります。

    独立行政法人情報処理推進機構(IPA)から公開された「情報セキュリティ10大脅威 2026」でも、組織向け脅威の上位に「サプライチェーンや委託先を狙った攻撃」が挙げられています。これは、攻撃者が必ずしも本丸である大企業や本社を直接狙うのではなく、関係会社、委託先、取引先、外部サービスなどを経由して侵入を試みるリスクが高まっていることを示しています。

    不正通信ログの検知が示す「早期発見」の重要性

    今回の公表で見落としてはならないのが、「サイバー攻撃の恐れがある不正な通信ログを検知した」という点です。不正アクセスは、必ずしも最初から目に見える被害として現れるわけではありません。ファイルが暗号化される、Webサイトが改ざんされる、顧客情報が公開されるといった被害が起きる前に、攻撃者がネットワーク内で探索や権限拡大を行っている場合があります。

    そのため、企業にとって重要なのは、攻撃を完全に防ぐことだけではなく、異常な通信、不審なログイン、通常と異なる端末挙動を早期に見つける体制です。ログを取得していても、監視や分析ができていなければ、攻撃の兆候を見逃してしまいます。特に海外拠点では、時差、言語、現地ベンダーとの契約、運用担当者の違いにより、インシデントの発見や報告が遅れる可能性があります。 不正アクセス対策では、ファイアウォールやウイルス対策ソフトだけでは不十分です。EDRによる端末監視、SIEMによるログ分析、SOCによる常時監視、ID管理、多要素認証、脆弱性診断、ペネトレーションテストなどを組み合わせ、攻撃を受けた場合でも早期に検知し、被害を最小化する考え方が求められます。

    情報漏洩が確認されていない段階でも対応が必要な理由

    サッポロホールディングスは、公表時点で情報漏洩の事実および影響範囲は確認中としています。ここで重要なのは、「漏洩が確認されていない」ことと「リスクがない」ことは同じではないという点です。サイバー攻撃では、外部送信の痕跡、認証情報の悪用、攻撃者の侵入経路、アクセスされたファイル、影響を受けたシステムを慎重に調査する必要があります。

    調査中の段階では、企業は被害範囲を過小評価することも、過度に断定することも避けなければなりません。公表内容において「確認中」「影響が確認された場合は速やかに報告」といった表現が使われているのは、調査結果に基づいて正確に説明する姿勢の表れといえます。企業が同様の事案に備えるためには、インシデント発生後の連絡体制、初動対応手順、システム遮断の判断基準、外部専門家への相談ルート、顧客・取引先への説明方針を事前に整備しておくことが重要です。サイバー攻撃を受けてから対応を考えるのではなく、攻撃を受ける前提で準備しておくことが、事業継続と信頼維持につながります。

    海外拠点を持つ企業が見直すべきセキュリティ対策

    海外グループ会社や海外子会社を持つ企業は、まずグループ全体のIT資産を把握する必要があります。どの拠点にどのシステムがあり、誰が管理し、どのネットワークとつながっているのかが分からなければ、リスクの評価も対策の優先順位付けもできません。

    次に重要なのが、認証情報の管理です。海外拠点のVPN、メール、クラウドサービス、業務システムに対して多要素認証を導入し、不要なアカウントや退職者アカウントを放置しないことが求められます。攻撃者は、脆弱性だけでなく、漏洩したID・パスワードや使い回された認証情報を悪用することがあります。

    また、脆弱性管理も欠かせません。海外拠点では、本社の管理外にあるサーバ、ネットワーク機器、リモートアクセス環境、業務アプリケーションが残っている場合があります。定期的な脆弱性診断や外部公開資産の棚卸しを行い、攻撃者から見える入口を減らすことが重要です。

    さらに、ログ監視とインシデント対応訓練も見直すべきです。不正通信ログを検知しても、その意味を判断できる人がいなければ対応は遅れます。検知、報告、遮断、調査、復旧、再発防止までの流れを整備し、海外拠点を含めて実効性を確認しておく必要があります。

    サイバー攻撃対策は「国内本社だけ」では足りない

    今回のサッポロホールディングスの事案は、海外グループ会社への不正アクセスとして公表されました。国内事業への影響は確認されていないとされていますが、企業にとっては、海外拠点を含むグループ全体のセキュリティを見直すきっかけになります。

    サイバー攻撃は、企業規模や知名度に関係なく、システムの弱点、管理のすき間、監視の遅れを突いてきます。特に海外展開を進める企業では、本社、海外子会社、委託先、取引先、クラウドサービスを含めた全体像を把握し、どこから攻撃されても早期に検知・対応できる体制を作ることが欠かせません。 不正アクセス、情報漏洩、ランサムウェア、サプライチェーン攻撃への備えは、もはや情報システム部門だけの課題ではありません。経営リスクとしてセキュリティを捉え、グループ全体で守る仕組みを整えることが、企業の信頼と事業継続を守るための第一歩です。

    まとめ

    サッポロホールディングスの海外グループ会社2社で確認された不正アクセスは、海外拠点を持つ企業にとって重要な示唆を含んでいます。公表時点では情報漏洩の有無や影響範囲は確認中であり、国内事業への影響も確認されていません。しかし、海外子会社や現地法人を含むグループ全体のセキュリティ管理が求められる時代であることは明らかです。

    企業は、海外拠点のセキュリティ対策を現地任せにせず、IT資産の把握、認証管理、脆弱性診断、ログ監視、インシデント対応体制の整備を進める必要があります。攻撃を完全に防ぐことが難しい今、重要なのは、侵入の兆候を早く見つけ、被害を広げない仕組みを持つことです。 サイバー攻撃対策を見直す際は、国内本社だけでなく、海外グループ会社、委託先、取引先、クラウド環境まで含めた全体像を確認することが欠かせません。今回の事案は、グローバル企業だけでなく、海外取引や外部委託を行うすべての企業にとって、自社のセキュリティ体制を点検する機会といえるでしょう。

    【参考情報】

    サッポロビール株式会社「当社の海外グループ会社2社のシステムへの不正アクセス発生について」(2026年6月24日公表)(https://www.sapporobreweries.com/notice/detail/20260624000010.html

    編集責任:木下


    BBSecの脆弱性診断・セキュリティ対策支援サービス

    BBSec(ブロードバンドセキュリティ)では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。


    ウェビナー開催のお知らせ

  • 2026年7月8日(水)13:00~14:00「企業は何から対策すべきか?― OWASP Top 10:2025から読み解く、最新のセキュリティリスクと対策の考え方 ―
  • 2026年7月15日(水)14:00~15:00「AI事業者ガイドライン第1.2版に基づくセキュリティ対策の実践ポイント~生成AIからAIエージェントへ~
  • 2026年7月22日(水)14:00~15:00「そのIT資産、本当に把握できていますか?~見落としがちなセキュリティリスクと対策の第一歩~
  • 最新情報はこちら


    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    インシデント対応体制とは?CSIRTの役割と企業が整えるべき運用のポイント

    Share
    「インシデント対応体制とはCSIRTの役割と企業が整えるべき運用のポイント」アイキャッチ画像

    サイバー攻撃や情報漏えいなどのセキュリティインシデントでは、迅速かつ適切な対応が被害の拡大防止につながります。そのためには、担当者任せではなく、役割分担や連絡体制をあらかじめ整備しておくことが重要です。本記事では、インシデント対応体制の基本的な考え方をはじめ、CSIRTやSOCの役割、企業が体制を構築・運用する際のポイントを解説します。

    インシデント管理の全体像については、以下の記事をご覧ください。
    セキュリティインシデント管理とは?企業が押さえるべき対応フローと体制の全体像

    サイバー攻撃や情報漏洩、ランサムウェア感染、不正アクセスなどのセキュリティインシデントは、発生してから担当者が個別に対応するだけでは十分に対処できません。インシデント対応では、技術的な調査や復旧だけでなく、経営判断、法務確認、顧客対応、広報対応、取引先との調整など、複数の部門が関係します。

    そのため、企業にはあらかじめインシデント対応体制を整備しておくことが求められます。誰が異常を受け付け、誰が初動対応を判断し、誰が調査を進め、誰が経営層や外部関係者へ報告するのかが決まっていなければ、発生直後の混乱を避けることはできません。JPCERT/CCは「CSIRTマテリアル」について、組織的なインシデント対応体制である「組織内CSIRT」の構築を支援する目的で作成したものと説明しています。また、すべての組織が同じ形のCSIRTを持つべきというものではなく、それぞれの組織の状況に応じた適切な形があるとしています。つまり、インシデント対応体制は、大企業だけが整備する特別な仕組みではなく、企業規模や事業内容に応じて現実的に設計すべきものです。

    なぜ体制が必要なのか

    インシデント対応体制が必要な理由は、セキュリティインシデントが一部門だけで完結する問題ではないためです。たとえば、マルウェア感染が発生した場合、情報システム部門は端末隔離やログ調査を行います。しかし、個人情報漏洩の可能性があれば法務や個人情報保護の担当部門が関与し、顧客影響があれば営業やカスタマーサポートが対応し、外部公表が必要になれば広報や経営層の判断が必要になります。

    不正アクセスやランサムウェア感染では、技術的な調査と同時に、事業継続の判断も必要になります。システムを停止するのか、どの業務を優先して復旧するのか、取引先へいつ説明するのかといった判断は、現場担当者だけで決められるものではありません。事前に体制がなければ、関係者への連絡が遅れ、対応の優先順位も曖昧になります。

    NIST SP 800-61 r2「Computer Security Incident Handling Guide」でも、効果的なインシデント対応は複雑な取り組みであり、成功する対応能力を確立するには、計画とリソースが必要であるとされています。また、インシデント対応では、IT部門だけでなく、法務などの内部関係者や、外部のインシデント対応チーム、法執行機関などとの連携も想定されています。

    体制がない企業では、インシデントが発生したときに「誰に報告すればよいか分からない」「誰が判断責任を持つのか分からない」「外部ベンダーに何を依頼すればよいか分からない」という状態になりがちです。平時であれば多少の確認不足は補えますが、インシデント発生時には時間が限られています。対応の遅れは、被害拡大や情報漏洩、事業停止、信用低下につながる可能性があります。

    独立行政法人情報処理推進機構(IPA)が公開するプラクティス・ナビ「指示7 インシデント発生時の緊急対応体制の整備」の中で、CSIRT等の対応体制が整備されていないこと、証拠保全ルールや外部報告・公表ルールが定められていないこと、想定インシデントに応じた分析・対応手順がないこと、CSIRT業務が属人化していること、演習を行っていないことを課題として挙げています。

    インシデント対応体制とは、単に担当者の名前を決めることではありません。発生時に必要な判断、作業、報告、連携を整理し、組織として動ける状態にすることです。対応体制が整っていれば、発生直後の混乱を抑え、被害拡大防止、原因調査、復旧、再発防止までを一貫して進めやすくなります。

    インシデント対応体制の基本構成

    インシデント対応体制は、企業規模や業種、システム構成によって異なります。ただし、多くの企業に共通する基本構成として、CSIRT、SOC、各部門の連携があります。これらはそれぞれ役割が異なり、単独で機能するものではありません。CSIRTは、インシデント対応を組織として進めるための中核的な役割を担います。インシデントの受付、事実確認、対応方針の調整、関係部門への連絡、外部機関や専門ベンダーとの連携、再発防止策の整理などを担うことが一般的です。企業によっては、専任組織として設置される場合もあれば、情報システム部門やセキュリティ担当者を中心に兼任体制で運用される場合もあります。SOCは、Security Operation Centerの略で、主に監視や検知、分析を担う機能です。EDR、SIEM、ファイアウォール、クラウド監査ログ、認証ログなどを監視し、不審な通信や挙動を検知します。SOCは、インシデントの兆候を早期に発見し、CSIRTや情報システム部門へエスカレーションする役割を持ちます。自社内にSOCを持つ企業もありますが、専門ベンダーのSOCやMDRサービスを活用する企業もあります。

    各部門の役割も重要です。情報システム部門は、端末、サーバ、ネットワーク、クラウド環境の技術的対応を担います。法務部門は、個人情報保護法や契約上の責任、監督官庁への報告要否などを確認します。広報部門は、外部公表やメディア対応、顧客向け説明文の調整を担います。営業部門やカスタマーサポート部門は、顧客や取引先からの問い合わせ対応を担います。経営層は、事業停止や外部公表、重大なリスク判断について意思決定を行います。

    これらの体制は、実際のインシデント対応フローの中で機能します。具体的な対応手順については、以下の記事で詳しく解説しています。
    インシデント対応フローとは?発生時に企業が取るべき手順と判断ポイント

    重要なのは、CSIRT、SOC、各部門の役割を分けるだけでなく、連携の流れを決めておくことです。SOCが検知したアラートを誰に報告するのか、CSIRTがどの基準で重大度を判断するのか、法務や広報をどのタイミングで巻き込むのか、経営層への報告基準は何かを定めておかなければ、体制図があっても実際には動きません。インシデント対応体制は、組織図上の箱を作ることではなく、実際に発生したときに機能する連絡・判断・対応の仕組みを作ることです。

    CSIRTとは何か

    CSIRTとは、Computer Security Incident Response Teamの略で、コンピューターセキュリティインシデントに対応するチームを意味します。JPCERT/CCによれば、CSIRTは「Computer Security Incident Response Team=コンピューターセキュリティインシデントに対応するチーム」の略であると説明されています。CSIRTの役割は、単に技術的な調査を行うことだけではありません。組織内で発生したインシデントの情報を集約し、対応方針を整理し、関係部門をつなぎ、必要に応じて外部機関や専門ベンダーと連携することが重要な役割です。企業によっては、脆弱性情報の収集、注意喚起、セキュリティ教育、訓練、再発防止策の推進など、平時の活動もCSIRTが担う場合があります。

    JPCERT/CCの公開する資料「組織内 CSIRT の役割とその範囲」では、組織内CSIRTの役割には違いがあり、インシデントへの直接対応、支援的対応、調整役としての対応などが示されています。つまり、CSIRTは必ずしもすべての技術対応を自ら行う必要はありません。企業の体制に応じて、現場対応を支援する立場、部門間を調整する立場、外部専門家との窓口になる立場など、現実的な役割を設計することが重要です。

    CSIRTが必要とされる理由は、インシデント発生時に情報と判断を一元化するためです。インシデント対応では、端末の隔離、ログ調査、外部連絡、顧客説明、法務判断、復旧作業など、さまざまな対応が同時に発生します。これらが各部門でばらばらに進むと、情報の食い違いや判断の遅れが起こりやすくなります。CSIRTが中心となって情報を集約すれば、経営層への報告も整理しやすくなります。経営層が必要とするのは、単なる技術情報ではなく、事業への影響、顧客への影響、復旧見通し、法的・契約上のリスク、外部公表の必要性などです。CSIRTは、技術部門と経営判断をつなぐ役割を担うことで、インシデント対応を企業全体のリスク対応として進めやすくします。ただし、CSIRTは設置するだけでは機能しません。連絡先が古い、権限が曖昧、判断基準がない、訓練をしていない、担当者が兼任で実質的に動けないといった状態では、有事に十分な役割を果たせません。CSIRTの必要性を理解したうえで、自社の規模やリソースに合った運用を設計することが大切です。

    体制が機能しない原因

    インシデント対応体制が機能しない原因として、最も多いのが属人化です。特定の担当者だけがシステム構成を理解している、ログの確認方法を知っている、外部ベンダーとの連絡先を把握している、過去のインシデント対応の経緯を覚えているという状態では、その担当者が不在のときに対応が止まります。属人化は、日常業務では見えにくい問題です。詳しい担当者がいれば、普段のトラブルはその人が解決できてしまいます。しかし、インシデント発生時には、短時間で多くの判断と作業が必要になります。特定の個人に情報や判断が集中すると、対応速度が落ち、確認漏れや連絡漏れが起こりやすくなります。

    IPAのプラクティス・ナビ「プラクティス7-4 CSIRT業務の属人化回避も兼ねたインシデントや脅威に関する情報の共有・蓄積」では、CSIRT業務の属人化回避を目的とした情報共有・蓄積の重要性を示しています。公開されている事例でも、CSIRT設立の中核だった従業員が退職した際に対応能力が低下し、その後、業務を属人化させない仕組みの整備が必要になったことが紹介されています。

    もう一つの原因は、判断基準がないことです。どのアラートをインシデントとして扱うのか、どの段階でCSIRTを招集するのか、端末隔離やシステム停止を誰が判断するのか、外部報告や公表を検討する基準は何かが決まっていなければ、現場は迷います。判断基準がないと、対応は担当者の経験や感覚に依存します。経験豊富な担当者であれば適切に判断できる場合もありますが、担当者が変われば対応品質も変わります。また、重大なインシデントほど、技術的な判断だけでなく、事業影響や法務リスク、顧客影響を含めた判断が必要になります。判断基準が曖昧なままでは、経営層への報告も遅れやすくなります。

    体制が機能しない企業では、形式的な体制図だけが存在していることもあります。CSIRTという名前はあるものの、実際のメンバー、役割、権限、連絡手順、訓練計画が決まっていない状態です。このような体制では、インシデント発生時に「誰が何をするのか」を改めて確認することになり、初動対応が遅れます。 さらに、部門間の連携不足も大きな要因です。情報システム部門が技術対応を進めていても、法務や広報、営業、経営層への共有が遅れると、顧客説明や外部公表の準備が間に合いません。反対に、経営層や広報が十分な事実確認を待たずに情報発信を進めると、誤った説明につながる可能性があります。インシデント対応体制を機能させるには、体制図を作るだけでなく、情報共有の流れ、判断権限、報告基準、記録方法を具体化する必要があります。

    体制構築のポイント

    インシデント対応体制を構築するうえで重要なのは、まず対応フローを明確にすることです。検知、初動対応、調査、復旧、再発防止という流れの中で、誰がどの工程を担当するのかを整理します。たとえば、従業員からの不審メール報告を誰が受け付けるのか、SOCや監視サービスのアラートを誰が確認するのか、感染端末の隔離を誰が実施するのか、経営層への報告を誰が行うのかを定めます。このとき、細かすぎる手順書を作ることよりも、実際に使える判断ルールを整備することが大切です。インシデントは事案ごとに状況が異なるため、すべてを手順書通りに進められるとは限りません。だからこそ、重大度の判断基準、エスカレーション条件、外部連携の基準、証拠保全の原則、復旧判断の考え方を整理しておく必要があります。

    IPA「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第4版」では、インシデント発生時の緊急対応体制の整備として、司令塔としてのCSIRTの設置、従業員の初動対応の規定、想定されるインシデントに関するセキュリティ分析計画の事前策定、情報共有・蓄積、インシデント対応演習などが示されています。

    次に重要なのが、訓練です。手順書や体制図を作っても、実際に動かしていなければ、有事に機能するとは限りません。インシデント対応訓練では、ランサムウェア感染、不正アクセス、情報漏洩、Webサイト改ざん、委託先からの侵害連絡など、想定シナリオをもとに、連絡、判断、報告、初動対応の流れを確認します。訓練では、技術対応だけでなく、経営層への報告、法務確認、広報文案の検討、顧客問い合わせへの対応、外部ベンダーへの連絡も含めて確認することが望ましいです。実際に演習してみると、連絡先が古い、判断者が不在時の代替ルートがない、ログの取得範囲が不足している、委託先との責任分界点が曖昧といった課題が見つかります。

    体制構築では、外部リソースの活用も現実的な選択肢になります。すべての企業が専任CSIRTや自社SOCを持てるわけではありません。特に中堅・中小企業では、情報システム部門が日常業務とセキュリティ対応を兼任しているケースも多くあります。その場合は、外部SOC、MDR、インシデント対応支援ベンダー、フォレンジック調査会社、顧問弁護士、保険会社など、必要な支援先を平時から整理しておくことが重要です。ただし、外部委託すればすべて任せられるわけではありません。外部ベンダーが調査や監視を支援しても、最終的な事業判断、顧客対応、外部公表、再発防止策の実行は企業自身が行う必要があります。外部リソースは、自社の対応体制を補完するものとして位置づけることが大切です。

    インシデント対応体制の整備は、情報漏洩対策全体の一部でもあります。あわせて以下の記事もご確認ください。
    情報漏洩対策とは何か ―企業が知るべき原因・リスク・防止策の全体像―

    まとめ

    インシデント対応体制とは、セキュリティインシデントが発生したときに、企業が組織として対応するための仕組みです。CSIRT、SOC、情報システム部門、法務、広報、営業、経営層などが連携し、検知、初動対応、調査、復旧、再発防止を進められる状態を整えることが重要です。CSIRTは、インシデント対応の司令塔や調整役として、情報を集約し、対応方針を整理し、関係部門や外部機関との連携を担います。SOCは、監視や検知、分析を通じて、インシデントの兆候を早期に発見する役割を持ちます。各部門は、それぞれの専門性に基づいて、技術対応、法務判断、顧客説明、広報対応、経営判断を担います。

    一方で、体制は作るだけでは機能しません。属人化した対応、曖昧な判断基準、古い連絡先、訓練不足、部門間連携の弱さがあると、インシデント発生時に初動が遅れます。特に、誰が判断し、誰が報告し、誰が外部と連携するのかが曖昧な状態では、対応の品質は担当者個人に依存してしまいます。 企業がまず取り組むべきことは、自社のインシデント対応フローを整理し、役割分担と連絡ルートを明確にすることです。そのうえで、重大度の判断基準、証拠保全ルール、外部報告・公表の検討基準、委託先や外部ベンダーとの連携方法を定め、定期的な訓練によって実効性を確認する必要があります。インシデント対応体制は、セキュリティ部門だけのための仕組みではありません。情報漏洩対策、事業継続、顧客信頼、経営リスク管理を支える重要な基盤です。自社の規模に合った現実的な体制から整備し、継続的に見直していくことが、インシデント発生時の被害最小化につながります。

    【参考情報】

    編集責任:木下


    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    ウェビナー開催のお知らせ

    最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    KDDIメールシステムに不正アクセス、最大1,422万件漏えいの可能性―企業が見直すべき「共通基盤リスク」とは

    Share
    「KDDIメールシステムに不正アクセス、最大1,422万件漏えいの可能性」アイキャッチ画像

    KDDI株式会社(以降、KDDI)がISP事業者向けに提供するメールシステムで不正アクセスが確認され、BIGLOBEメール、@niftyメール、J:COM NET、コミュファ光、ピカラ光、CPIなど複数のメールサービスにおいて、メールアドレスやパスワードが外部に漏えいした可能性があることが公表されました。漏えいした可能性のある情報は最大1,422万件にのぼり、現在利用中のユーザーだけでなく、解約済みの顧客や一定期間利用のない休眠アカウントも含まれるとされています。

    今回の事案で注目すべきなのは、単に「メールアドレスとパスワードが漏えいした可能性がある」という点だけではありません。KDDIが提供するISP向けの共通メール基盤に不正アクセスが発生したことで、複数の事業者・複数のサービスに影響が広がった点が重要です。これは、現代の企業システムにおいて避けて通れない「外部委託先リスク」「サプライチェーンリスク」「共通基盤リスク」を象徴する事案といえます。

    本記事では、KDDIの公式発表および関係各社の公表情報をもとに、今回の不正アクセスの概要、影響範囲、利用者が取るべき対応、そして企業が学ぶべきセキュリティ対策について解説します。

    KDDIのISP向けメールシステムで何が起きたのか

    KDDIは、インターネットサービスプロバイダー、いわゆるISP事業者向けに提供しているメールシステムにおいて、不正アクセスを受けていたことを2026年6月17日に確認しました。KDDIの発表によると、不正アクセスの原因は、同システムで利用していた第三者製ソフトウェアの脆弱性を悪用されたことによるものです。

    KDDIは同日、被害拡大を防ぐためにシステムを改修し、不正アクセスの被疑箇所を特定したうえで、技術的な防御措置を実施したとしています。また、個人情報保護委員会や総務省への報告・相談を含む必要な対応も進めていると説明しています。

    現時点で公表されている漏えい可能性のある情報は、対象メールサービスで作成されたメールボックスに紐づくメールアドレスとパスワードです。件数は最大1,422万件とされており、この数字には解約済みの顧客や、一定期間利用していない休眠アカウントも含まれています。なお、パスワードの中には、ハッシュ化または暗号化されたものも含まれるとされています。

    ここで注意したいのは、最大1,422万件という数字が「実際に漏えいした件数」と確定したものではないという点です。KDDIは調査継続中であるため、現時点では漏えいした可能性のある最大値として公表されています。

    影響を受けるメールサービス

    今回の不正アクセスで対象とされているのは、KDDIがISP事業者向けに提供していたメールシステムを利用する複数のメールサービスです。KDDIの発表では、STNetのピカラ光サービス、ピカラモバイルサービス、お仕事ピカラサービスに係るメールサービス、KDDIウェブコミュニケーションズのレンタルサーバー「CPI」のメールサービス、JCOMのJ:COM NETおよびケーブルテレビ事業者向けメールサービス、中部テレコミュニケーションのコミュファ光・ビジネスコミュファのメールサービス、ニフティの@niftyメール、ビッグローブのBIGLOBEメールが対象として挙げられています。

    各社の発表を見ても、KDDIが提供する基盤システムを利用していたこと、第三者製ソフトウェアの脆弱性悪用によって不正アクセスが発生したこと、メールアドレスやメールパスワードなどが漏えいした可能性があることが説明されています。BIGLOBEでは、BIGLOBEメールアドレス、BIGLOBE IDおよびパスワードが漏えいした可能性があると公表しています。@niftyでは、メールアドレスおよびメールパスワードが第三者に漏えいした可能性があるとして、利用者にメールパスワードの変更を求めています。

    このように、ひとつの基盤システムに起きた不正アクセスが、複数ブランドの利用者に影響する形になっています。これは、クラウドサービス、外部委託システム、SaaS、共通認証基盤などを活用する多くの企業にとっても、決して他人事ではありません。

    なぜメールアドレスとパスワードの漏えいは危険なのか

    メールアドレスとパスワードの漏えいは、単なる連絡先情報の流出にとどまりません。メールアカウントは、多くのWebサービスや業務システムにおいて本人確認やパスワード再設定の起点として使われています。そのため、メールアカウントに不正ログインされると、他サービスへの侵入、なりすまし、フィッシングメールの送信、業務情報の閲覧など、被害が連鎖するおそれがあります。

    特に危険なのは、同じパスワードを複数のサービスで使い回しているケースです。攻撃者は、漏えいしたメールアドレスとパスワードの組み合わせを使い、別のWebサービスやクラウドサービスへのログインを試みることがあります。これは一般にパスワードリスト攻撃、またはクレデンシャルスタッフィングと呼ばれる手口です。

    今回の件では、対象情報にメールパスワードが含まれる可能性があるため、利用者は対象メールサービスのパスワードを変更するだけでなく、同じ、または似たパスワードを使用している他サービスについても見直す必要があります。メール、ECサイト、SNS、クラウドストレージ、業務用SaaSなどでパスワードを使い回している場合は、早急な変更が望まれます。

    利用者が今すぐ取るべき対応

    対象サービスを利用している可能性がある場合、まずは各ISP事業者やサービス提供会社の公式案内を確認することが重要です。検索結果やSNS上のリンクからではなく、公式サイト、公式サポートページ、契約時に案内された会員ページなどから確認することで、フィッシングサイトに誘導されるリスクを下げられます。

    次に、対象となるメールパスワードを変更します。@niftyのように、一定期限までに変更が確認できない場合、システム側でメールパスワードを順次無効化すると案内している事業者もあります。Outlook、Macメール、スマートフォンのメールアプリなどを利用している場合は、Web上でパスワードを変更した後、メールソフト側に保存されているパスワードも更新する必要があります。

    また、メールパスワードとログインパスワードを同じ文字列にしている場合や、他のサービスでも同じパスワードを使っている場合は、それらも変更すべきです。メールアカウントは、他サービスのパスワード再設定メールを受け取る重要な入口です。メールアカウントの安全性が崩れると、他のアカウントにも被害が広がる可能性があります。 加えて、しばらくの間は不審なメールへの警戒が必要です。今回の不正アクセスに便乗し、「パスワード変更が必要です」「アカウントを確認してください」などと称する偽メールが送られる可能性もあります。本文中のURLを安易にクリックせず、ブックマークや公式アプリ、公式サイトから手続きすることが大切です。

    「委託先だから安全」ではないという現実

    今回の事案は、企業のセキュリティ対策を考えるうえで重要な教訓を含んでいます。多くの企業は、自社の業務効率化やコスト削減、専門性の確保を目的に、メール基盤、クラウドサービス、決済システム、顧客管理システム、認証基盤などを外部サービスに委託しています。これは現代の事業運営では自然な選択です。

    しかし、外部サービスを利用しているからといって、リスクが自社から消えるわけではありません。委託先や共通基盤でインシデントが発生すれば、自社の顧客情報、業務データ、ブランド信頼にも影響が及びます。特に、複数の事業者が同じ基盤を利用している場合、一箇所の脆弱性が広範囲のサービスに波及する可能性があります。 企業に求められるのは、外部委託先を「便利なサービス提供者」として見るだけでなく、自社のセキュリティ境界の一部として管理する姿勢です。契約時のセキュリティ要件、脆弱性対応の体制、インシデント発生時の報告フロー、影響範囲の確認方法、利用者への通知方針などを事前に整理しておかなければ、実際に問題が起きた際の初動対応が遅れてしまいます。

    第三者製ソフトウェアの脆弱性はなぜ狙われるのか

    KDDIは今回の不正アクセスについて、第三者製ソフトウェアの脆弱性が悪用されたと説明しています。現時点でソフトウェア名やCVE番号などの詳細は公表されていませんが、一般論として、第三者製ソフトウェアの脆弱性は攻撃者にとって非常に狙いやすいポイントです。

    企業システムは、自社開発のプログラムだけで構成されているわけではありません。OS、ミドルウェア、メールサーバー、認証機能、管理画面、ライブラリ、監視ツールなど、さまざまな外部コンポーネントに支えられています。これらのどこかに脆弱性が存在し、修正が遅れれば、攻撃者に侵入口を与えることになります。 特に、インターネットからアクセス可能なシステムや、多数の顧客情報を扱う共通基盤では、脆弱性管理の遅れが大きなインシデントにつながりかねません。脆弱性情報を収集し、影響有無を確認し、必要なパッチ適用や回避策を迅速に実施する体制が不可欠です。

    企業が見直すべきセキュリティ対策

    今回のような不正アクセスや情報漏えいリスクに備えるには、単にパスワードを強化するだけでは不十分です。まず重要なのは、自社がどの外部サービスや委託先に、どのような情報を預けているのかを把握することです。顧客情報、メールアドレス、認証情報、業務データ、ログ情報など、預託している情報の種類と影響範囲を整理しておく必要があります。

    次に、委託先や利用サービスに対するセキュリティ確認を継続的に行うことが求められます。契約時だけでなく、運用中も脆弱性対応、インシデント報告体制、アクセス制御、ログ管理、バックアップ、暗号化、権限管理などの観点で確認を続けることが重要です。

    さらに、自社側でも認証情報の管理を強化する必要があります。多要素認証の導入、パスワード使い回しの禁止、不要アカウントの棚卸し、退職者や休眠アカウントの削除、権限の最小化などは、基本的でありながら効果の高い対策です。今回の件で解約済みや休眠アカウントも最大件数に含まれていることは、使われていないアカウントや古いデータの管理がいかに重要かを示しています。 最後に、インシデント発生時の対応手順を事前に整備しておくことも欠かせません。誰が影響範囲を確認し、誰が顧客へ通知し、どのタイミングで監督官庁へ報告し、どのように再発防止策を公表するのか。こうした手順が曖昧なままでは、被害の拡大だけでなく、顧客からの信頼低下にもつながります。

    メール漏えいではなくサプライチェーンリスクの問題

    今回のKDDIメールシステム不正アクセスは、メールアドレスとパスワードの漏えい可能性が注目されています。しかし、企業のセキュリティ担当者や経営層が本当に見るべきポイントは、その背後にある構造です。

    ひとつの共通基盤に脆弱性があり、そこを攻撃されることで、複数のISP事業者やメールサービスに影響が広がりました。これは、外部委託やクラウド利用が進む現在の企業環境において、どの企業にも起こり得る問題です。自社のシステムが直接攻撃されていなくても、委託先、取引先、共通基盤、利用中のSaaSで起きたインシデントが、自社の顧客対応や事業継続に影響する可能性があります。 セキュリティ対策は、もはや自社ネットワークの内側だけを守ればよい時代ではありません。外部サービスを含めた全体像を把握し、脆弱性管理、委託先管理、認証情報管理、インシデント対応を一体として整備することが求められます。

    まとめ

    KDDIのISP事業者向けメールシステムに対する不正アクセスでは、メールアドレスやパスワードが最大1,422万件漏えいした可能性があると公表されました。対象にはBIGLOBEメール、@niftyメール、J:COM NET、コミュファ光、ピカラ光、CPIなど複数のメールサービスが含まれており、共通基盤に起きた不正アクセスが広範囲に影響する構図となっています。

    利用者は、各事業者の公式案内を確認し、対象となるメールパスワードを速やかに変更することが重要です。同じパスワードを他サービスで使い回している場合は、あわせて変更し、不審なメールや偽のパスワード変更案内にも注意が必要です。

    企業にとっては、今回の事案を「大手通信会社の情報漏えい」として見るだけでは不十分です。第三者製ソフトウェアの脆弱性、外部委託先の管理、共通基盤への依存、休眠アカウントの扱い、インシデント発生時の連絡体制など、自社のセキュリティ運用を見直すきっかけにすべきです。 サイバー攻撃は、自社の真正面から来るとは限りません。取引先、委託先、クラウドサービス、共通基盤を経由して影響が及ぶ時代だからこそ、企業にはサプライチェーン全体を見据えたセキュリティ対策が求められています。

    【参考情報】

    編集責任:木下


    BBSecの脆弱性診断・セキュリティ対策支援サービス

    BBSec(ブロードバンドセキュリティ)では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。


    ウェビナー開催のお知らせ

  • 2026年7月1日(水)13:00~14:00「ランサムウェア対策は「侵入前提」で考える―最新事例から学ぶ、企業に求められるリスク把握と対策の考え方―
  • 2026年7月8日(水)13:00~14:00「企業は何から対策すべきか?― OWASP Top 10:2025から読み解く、最新のセキュリティリスクと対策の考え方 ―
  • 2026年7月15日(水)14:00~15:00「AI事業者ガイドライン第1.2版に基づくセキュリティ対策の実践ポイント~生成AIからAIエージェントへ~
  • 2026年7月22日(水)14:00~15:00「そのIT資産、本当に把握できていますか?~見落としがちなセキュリティリスクと対策の第一歩~
  • 最新情報はこちら


    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る