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

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

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

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

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

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

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

漏洩した顧客関連の情報には、氏名、生年月日、性別、住所、電話番号、証券番号、保障内容、保険料振替口座情報などが含まれます。保険料振替口座情報には、金融機関名、支店名、預金種類、口座番号、口座名義などが含まれるとされています。一方で、「マイナンバーおよびクレジットカード情報は含まれていない」と公表されています。漏洩件数は、顧客数で約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に戻る

    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に戻る

    【企業のためのランサムウェア対策ガイド】ランサムウェアの感染経路とは ―企業が見落としがちなVPN・RDP侵入リスクを解説

    Share
    ランサムウェアの感染経路とは ―企業が見落としがちなVPN・RDP侵入リスクを解説アイキャッチ画像

    ランサムウェア対策を考えるうえで重要なのが、「どこから侵入されるのか」を理解することです。近年の企業向けランサムウェア攻撃では、メールだけでなく、VPN機器やリモートデスクトップ(RDP)の脆弱性、認証情報の悪用、サプライチェーン経由の侵入など、多様な経路が利用されています。本記事では、企業が見落としがちな代表的な感染経路と、その対策の考え方について解説します。

    ランサムウェアの基本的な仕組みや全体像については、以下の記事で整理しています。
    ランサムウェアとは何か ―企業が知るべき被害・仕組み・対策の基本―

    ランサムウェアは、ある日突然社内のパソコンやサーバ上で実行されるように見えます。しかし実際には、その前段階で攻撃者が企業ネットワークへ侵入しています。メール、VPN機器、リモートデスクトップ、ソフトウェアの脆弱性、外部委託先など、侵入経路はさまざまです。特に近年は、単に添付ファイルを開かせる攻撃だけでなく、インターネットに公開されたVPN機器やリモートアクセス環境の脆弱性、認証情報の悪用、委託先や外部サービスを踏み台にした侵入が問題になっています。警察庁やIPAの資料でも、国内のランサムウェア被害ではVPN機器やリモートデスクトップなど、テレワーク環境に関連する経路が多く確認されています。

    ランサムウェアはどこから侵入するのか

    ランサムウェアの感染経路は、ひとつに限定されません。攻撃者は、企業の外部に開いている入口、従業員が日常的に使うメール、保守やテレワークのためのリモート接続、未修正のソフトウェア、さらには取引先や委託先との接続関係まで、複数の経路を組み合わせて侵入を試みます。従来は、ランサムウェアというと「不審なメールの添付ファイルを開いて感染する」というイメージが強くありました。もちろんメールは現在でも重要な感染経路ですが、企業におけるランサムウェア被害では、VPN機器やリモートデスクトップなど、外部から社内環境へ接続するための仕組みが狙われるケースが目立ちます。

    米国サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)が公開している「#StopRansomware Guide」でも、ランサムウェアやデータ恐喝型攻撃の初期侵入経路として、インターネットに公開された脆弱性や設定ミス、フィッシング、認証情報の悪用、リモートアクセス環境などが重視されています。つまり、ランサムウェア対策は「端末にウイルス対策ソフトを入れる」だけでは不十分であり、外部公開資産、認証、運用設定、委託先管理まで含めて考える必要があります。

    代表的な感染経路

    メールによる感染

    メールは、現在でもランサムウェア感染の代表的な入口です。攻撃者は、請求書、見積書、配送通知、業務連絡、採用関連の連絡などを装い、添付ファイルや本文中のリンクを開かせようとします。従業員が添付ファイルを開いたり、リンク先で認証情報を入力したりすると、マルウェア感染やアカウント窃取につながる可能性があります。ただし、近年のランサムウェア攻撃では、メールから即座に暗号化が始まるとは限りません。メールをきっかけに認証情報を盗み、その後VPNやクラウドサービスへ不正ログインする場合もあります。また、メール経由で侵入したマルウェアが端末内の情報を収集し、攻撃者が次の侵入経路を探す足がかりになることもあります。そのため、メール対策は「怪しいメールを開かないように教育する」だけでは不十分です。迷惑メール対策、添付ファイルの検査、URLフィルタリング、多要素認証、端末の挙動監視を組み合わせ、万が一クリックされても被害が広がりにくい仕組みを整える必要があります。

    VPN機器の脆弱性

    企業のランサムウェア対策で特に注意すべき感染経路が、VPN機器の脆弱性です。VPNは、テレワークや拠点間接続、外部からの保守作業に欠かせない仕組みですが、インターネット側に公開されているため、攻撃者にとっても狙いやすい入口になります。独立行政法人情報処理推進機構(IPA)「情報セキュリティ10大脅威 2026」でも、ランサムウェア被害の感染経路としてVPN機器経由が大きな割合を占め、VPN機器経由とリモートデスクトップ経由を合わせると毎年高い割合を占めていることが示されています。

    VPN機器に未修正の脆弱性が残っている場合、攻撃者は認証を突破したり、機器上の情報を盗んだり、社内ネットワークへ侵入したりする可能性があります。特に、サポート切れの機器、更新が滞っているファームウェア、初期設定に近いまま運用されている環境、不要なアカウントが残っている環境は危険です。VPN機器は一度導入すると、業務インフラとして長く使われがちです。そのため、導入時には問題がなかったとしても、数年後に深刻な脆弱性が公表され、攻撃対象になることがあります。ランサムウェア対策では、VPN機器のメーカー名、型番、バージョン、サポート期限、適用済みパッチを定期的に確認することが重要です。

    リモートデスクトップ(RDP)の悪用

    リモートデスクトップ(RDP)も、ランサムウェアの代表的な感染経路です。RDPは、離れた場所から社内のPCやサーバを操作できる便利な仕組みですが、外部から直接接続できる状態になっていると、攻撃者にとって格好の侵入口になります。CISAが公開するランサムウェア関連アドバイザリ(#StopRansomware: Akira Ransomware)でも、RDPやVPNなどのリモートアクセスサービスが初期侵入に使われる事例が継続的に示されています。

    攻撃者は、単純なパスワードの総当たり攻撃、過去に漏えいした認証情報の悪用、設定不備の探索などによって、RDP接続を突破しようとします。一度RDP経由で社内端末やサーバへ入られると、攻撃者は管理者権限の取得、他端末への横展開、データの持ち出し、バックアップの削除、ランサムウェアの実行へと進む可能性があります。RDPを業務上どうしても使う場合は、インターネットへ直接公開しないことが基本です。VPNやゼロトラスト型のアクセス制御を経由させ、多要素認証を必須にし、接続元制限、ログ監視、不要アカウントの削除を徹底する必要があります。

    ソフトウェアの脆弱性

    ランサムウェアの感染経路として見落とされやすいのが、OS、ミドルウェア、業務システム、Webアプリケーション、ネットワーク機器などのソフトウェア脆弱性です。Verizon「2025 Data Breach Investigations Report」(DBIR)でも、脆弱性の悪用による初期アクセスが増加していることが示されており、境界デバイスや外部公開システムの管理が企業のセキュリティ課題として重要になっています。

    攻撃者は、公開された脆弱性情報をもとに、未修正のシステムをインターネット上で探索します。特に危険なのは、外部からアクセスできるシステムに深刻な脆弱性が残っている場合です。VPN、ファイアウォール、メールサーバ、ファイル転送システム、Web管理画面、クラウド連携用の管理コンソールなどは、攻撃者から常に探索対象になっていると考えるべきです。脆弱性対策では、単にパッチを適用するだけではなく、自社がどのシステムを外部公開しているかを把握することが出発点になります。資産管理が不十分なままでは、どの機器に脆弱性があるのか、どのシステムを優先して更新すべきかを判断できません。

    サプライチェーン経由の感染

    ランサムウェアの感染経路は、自社のネットワークや端末だけに限られません。委託先、外部サービス、クラウドサービス、保守ベンダー、取引先との接続環境を通じて侵入されることもあります。こうした外部経由の侵入は、サプライチェーン攻撃としても知られています。Verizon「2025 Data Breach Investigations Report」でも、漏えい・侵害に第三者が関与する割合が増加していることが示されており、サプライチェーンリスクは企業規模を問わず無視できない課題になっています。

    たとえば、業務委託先が利用しているアカウントが侵害され、そのアカウントを使って自社環境へ不正アクセスされるケースがあります。また、外部保守用に開放していたリモート接続が攻撃者に悪用される場合や、取引先とのファイル共有環境を通じてマルウェアが持ち込まれる場合もあります。サプライチェーン経由の感染が厄介なのは、自社だけで完全に制御しにくい点です。自社のセキュリティ対策が一定水準に達していても、接続先や委託先の管理が甘ければ、そこが攻撃者にとっての入口になります。

    こうした外部経由の侵入は、サプライチェーン攻撃としても知られています。詳しくは以下の記事で解説しています。
    サプライチェーン攻撃とは ―委託先・外注先リスクから情報漏えいを防ぐ全体像―

    ランサムウェア対策としては、委託先との接続経路、付与している権限、共有している情報、外部アカウントの管理状況を定期的に見直す必要があります。外部委託先に対しても、多要素認証、アクセス権限の最小化、ログ取得、契約上のセキュリティ要件、インシデント発生時の連絡体制を確認しておくことが重要です。

    なぜ気づかず侵入されるのか

    ランサムウェア感染が深刻化する理由のひとつは、攻撃者が侵入してから暗号化を実行するまでに時間差があることです。企業側から見ると、ある日突然ファイルが暗号化されたように見えます。しかし実際には、その前に認証情報の窃取、社内探索、権限昇格、横展開、データ窃取といった活動が行われている場合があります。攻撃者が長く潜伏できる背景には、認証情報の管理不備があります。退職者や異動者のアカウントが残っている、管理者権限が過剰に付与されている、同じパスワードを複数システムで使い回している、多要素認証が導入されていない、といった状態では、攻撃者にとって侵入後の行動が容易になります。また、設定ミスも大きな問題です。RDPがインターネットに公開されている、VPN機器のファームウェアが古い、管理画面に外部からアクセスできる、不要なポートが開いている、ログが保存されていないといった状態は、攻撃者にとって有利に働きます。

    NIST(米国立情報技術研究所)NIST IR 8374 Rev.1「Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile」では、ランサムウェアへの備えとして、識別、防御、検知、対応、復旧を含めた包括的なリスク管理の重要性が示されています。これは、ランサムウェア対策が単なるマルウェア対策ではなく、資産管理、アクセス制御、バックアップ、ログ監視、インシデント対応を含む経営課題であることを意味します。

    感染リスクを下げるための考え方

    ランサムウェアの感染リスクを下げるには、すべての対策を一度に完璧に実施しようとするのではなく、侵入されやすい場所から優先順位をつけて対策することが重要です。特に企業では、VPN機器、リモートデスクトップ、外部公開サーバ、メール、認証情報、委託先接続の順に確認すると、自社の弱点を見つけやすくなります。

    最初に行うべきことは、外部から見える資産の棚卸しです。どのVPN機器を使っているのか、RDPが外部公開されていないか、古いサーバや管理画面が残っていないか、クラウドサービスの管理者アカウントが適切に管理されているかを確認します。自社が把握していないシステムは、守ることも更新することもできません。次に、認証情報の保護を強化します。多要素認証の導入、不要アカウントの削除、管理者権限の最小化、パスワードの使い回し防止、ログイン試行の監視は、ランサムウェア対策の基本です。特にVPN、RDP、クラウド管理画面、メールアカウントには優先的に適用すべきです。さらに、脆弱性管理を継続的に行う必要があります。OSやソフトウェアの更新だけでなく、ネットワーク機器、VPN、ファイアウォール、NAS、ファイル転送システムなど、外部公開される可能性のある機器の脆弱性情報を確認し、リスクの高いものから修正します。バックアップも重要ですが、バックアップがあるだけでは十分ではありません。攻撃者にバックアップまで削除・暗号化されないよう、ネットワークから分離したバックアップや、復旧手順の確認が必要です。ランサムウェア対策では、感染を防ぐ対策と、感染した場合でも事業を止めない対策を組み合わせることが求められます。

    まとめ

    ランサムウェアの感染経路は、メールだけではありません。VPN機器の脆弱性、リモートデスクトップの悪用、ソフトウェアの未修正脆弱性、認証情報の窃取、設定ミス、委託先や外部サービスを経由したサプライチェーン攻撃など、企業のさまざまな入口が狙われています。特に近年の企業向けランサムウェア攻撃では、攻撃者が事前に社内ネットワークへ侵入し、権限を広げ、データを盗み、最後に暗号化を実行する流れが一般化しています。そのため、ランサムウェア対策は「感染後にどう復旧するか」だけでなく、「どこから入られる可能性があるか」を把握し、侵入経路を減らすことから始める必要があります。

    企業がまず取り組むべきことは、自社の外部公開資産を把握し、VPNやRDPの設定を見直し、ソフトウェアの脆弱性を管理し、認証情報を守り、委託先との接続経路を確認することです。すべてを一度に完璧にする必要はありませんが、攻撃者にとって狙いやすい入口を放置し続けることは、ランサムウェア被害のリスクを高めます。ランサムウェアの感染経路を理解することは、対策の出発点です。自社のどこが侵入口になり得るのかを確認し、優先順位をつけて改善していくことが、企業のランサムウェア対策において最も現実的で効果的な第一歩になります。

    万が一感染してしまった場合の具体的な対応については、以下の記事で詳しく解説しています。
    セキュリティインシデントの基礎から対応・再発防止まで 第2回:セキュリティインシデント発生時の対応 ─初動から復旧まで

    【参考情報】

    編集責任:木下


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

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

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

    クレジットカード情報漏洩に備える ―非保持化・PCI DSS準拠でも漏洩が起きる理由とは―

    Share
    クレジットカード情報漏洩に備える ―非保持化・PCI DSS準拠でも漏洩が起きる理由とは―アイキャッチ画像

    クレジットカード情報漏洩は、ECサイト加盟店だけの問題ではありません。非保持化やPCI DSS準拠を実施していても、Webサイトの脆弱性や設定不備を起点に漏洩が発生するケースは少なくありません。本記事では、実際の漏洩事例や発生後に直面する課題を踏まえながら、情報漏洩に備えるために押さえておきたいポイントを解説します。

    なぜクレジットカード情報漏洩が起きるのか

    クレジットカード情報漏洩は、ECサイト加盟店だけの問題として発生するわけではありません。ECサイトの決済は、ECサイト加盟店、決済代行事業者(PSP:Payment Service Provider)、アクワイアラ、国際ブランドなど、複数の事業者が連携して成り立っています。そのため、サイバー攻撃者に狙われる対象は、カード情報を直接保有するシステムだけに限られません。

    実際には、ECサイト加盟店のECサイトや管理画面、CMS、外部委託先、決済画面へ遷移する前後の処理など、周辺のどこかにWebアプリケーションの脆弱性や設定不備が存在するだけで、カード情報の窃取につながる可能性があります。カード情報を自社で保持していない場合でも、サイト改竄や悪意あるコードの挿入によって、利用者が入力した情報が攻撃者へ送信されてしまうケースがあります。弊社のPFI調査資料でも、カード情報を自社保有していない企業からの漏洩に関する相談が多く発生していることが示されています。

    ECサイトでは外部サービス連携、プラグイン更新、機能追加などが継続的に発生します。そのため、一度安全な構成を整備したとしても、それだけで安全性が維持されるわけではありません。日々の運用の中で新たに生まれた脆弱性が、攻撃の端緒となる場合があります。特に、Webアプリケーションの脆弱性や管理画面の設定不備は、PFI調査において主要な漏洩の原因として挙げられています。決済は複数の事業者が関与する仕組みであるため、そのサプライチェーンの一箇所で発生したサイバー攻撃が、ECサイト加盟店の業務停止、PSPへの問い合わせ対応、アクワイアラや国際ブランドへの報告対応へと波及する可能性があります。クレジットカードの情報漏洩は、単なる技術的な事故ではなく、決済サプライチェーン全体へ影響を及ぼすインシデントとして捉える必要があります。

    実際に発生している情報漏洩事例

    公表資料や業界資料を見ると、漏洩のきっかけは一様ではありません。ECサイトの改竄、不正ファイルの設置、偽の決済画面への誘導、委託先や関連システムの不備など、さまざまな経路からカード情報の窃取につながっています。経済産業省の資料でも、ECサイト加盟店、ECシステム提供事業者、PSP、消費者を狙ったフィッシング被害など、複数の漏洩事案の類型が整理されています。たとえば、ECサイト加盟店のECサイトに存在する脆弱性を突かれ、サイトが改竄されるケースがあります。この場合、カード情報を保持していなくても、不正ファイルの設置や偽の決済画面への誘導により、利用者が入力したカード番号等が攻撃者へ送信される可能性があります。また、委託先業者によるサイト更新時の設定不備を起点に、不正アクセスや情報漏洩につながるケースもあります。さらに、決済関連システム側の脆弱なアプリケーションへ不正アクセスされる事例も挙げられています。

    PSPで情報漏洩が発生すると、利用者、ECサイト加盟店、クレジットカード会社など、多くの関係者を巻き込む被害につながるおそれがあります。これらの事例は、クレジットカード情報漏洩が単一のセキュリティ製品だけで防げる問題ではなく、開発、運用、委託管理、監視のすべてが関係する問題であることを示しています。また、近年は発覚経緯にも変化が見られます。2024年のカード情報流出事件では、警察の指摘により発覚した事案が35.1%を占めたとの分析もあります。また、2024年のクレジットカード不正利用被害額は555億円とされ、その9割超がECサイトでの番号盗用によるものとされています*2

    これらの事例から分かるのは、クレジットカード情報漏洩が例外的な事故ではなく、現実的にはEC決済の現場で継続的に発生する身近なリスクだということです。PSPにとっても、漏洩元が自社であるか否かにかかわらず、問い合わせ、調査協力、ECサイト加盟店支援、関係者への説明といった対応が発生し得る点を踏まえる必要があります。

    なぜ対策していても防げないのか

    クレジットカードの情報漏洩対策として、「カード情報を保持しない非保持化」や「PCI DSS準拠」といった取り組みは非常に重要です。しかし、これらはリスクを低減するための対策であり、残念ながら漏洩を完全に防ぐことを保証してくれるものではありません。たとえば、カード情報の非保持化を行っている場合でも、ECサイトが改竄され、偽の入力フォームや悪意あるスクリプトが設置されてしまえば、利用者が入力したカード情報が攻撃者へと送信される可能性があります。つまり、カード情報を「保管していない」ことと、「情報入力時に窃取されない」ことは別の問題なのです。ECサイト全体の安全性まで担保されるわけではありません。PCI DSSについても同様です。PCI DSSに準拠していること自体が将来の侵害を否定してくれるものではありません。実際のインシデントでは、Webアプリケーションの脆弱性、管理画面の設定不備、委託管理先の不備、脆弱なパスワード設定など、複数の問題が重なって発生するケースが見られます。弊社のPFI調査資料でも、アプリケーションの脆弱性や管理画面の設定不備が主要な漏洩原因として挙げられています。

    重要なのは、「非保持化しているから安全」、「PCI DSSに準拠しているから安全」と受け止めるのではなく、それぞれの対策が守れる範囲と限界を理解することです。クレジットカード情報漏洩は、技術、運用、管理といった複数の要因が重なって発生するため、防御だけではなく、継続的な監視や発生時の対応体制まで含めて備える必要があります。

    インシデント発生後の現実

    クレジットカード情報漏洩が疑われる事態に直面すると、現場では短時間で多くの判断が求められます。特に、次のような課題が発生する可能性があります。

    • 初動対応の遅れ
      被害拡大を防ぐため、ECサイトの停止、クレジットカード決済の一時停止、不正ファイルの確認、関係者への連絡などを並行して進める必要があります。対応が遅れた場合、新たな被害につながるおそれがあります。
    • ログ不足
      原因や影響範囲を調査しようとしても、必要なログが保存されていない、保存期間が短い、委託先から提供されないといった状況では、調査が難航します。ログの保全・管理体制が不十分であることが課題となるケースも少なくありません。
    • 調査・報告対応
      インシデント対応では、被害拡大を防ぐための封じ込めも重要です。さらに、個人情報保護委員会への報告や本人通知、公表対応など、時間的制約のある対外対応も並行して進めなければなりません。
    • 業務・信用への影響
      決済停止やECサイト停止は、売上の減少、顧客対応、問い合わせ対応の発生に直結します。実際に、クレジットカード決済の停止が長期化した事例や、決済再開までの期間、クレジットカード決済以外でECサイトを継続できるかといった相談も挙げられています。決済再開に向けた調整や関係者との連携も必要となり、事業運営や信用面にも大きな影響を及ぼす可能性があります。

    PSPはどこまで責任を負うのか?

    クレジットカード情報漏洩のインシデントでは、実際に情報漏洩が発生したECサイト加盟店やシステム事業者だけでなく、決済に関わる複数の事業者が対応を求められる場合があります。特にPSPはインシデント発生時に一定の関与が発生する可能性があります。たとえば、ECサイト加盟店からの問い合わせ対応、決済停止や再開に関する調整、関係各所への情報共有、調査協力などが挙げられます。また、利用者への影響範囲や決済への影響を整理する中で、PSPが保有するログや取引情報の確認が必要になるケースもあります。

    もちろん、すべてのケースでPSPが法的責任を負うとは限りません。しかし実際には、「どのシステムで何が起きたのか」、「どこまで影響が及んでいるのか」を整理する過程で、決済のハブとしての対応が求められる場面があります。関係者間で認識や説明内容に差異が生じれば、公表内容や顧客説明にも影響する可能性があります。また、インシデント発生時には、技術的な問題だけでなく、ECサイト加盟店や委託先との調整、問い合わせ対応、事実確認など、実務面での負荷も大きくなります。そのためPSPにとっても、インシデント対応は「加盟店側の問題」と安易に切り離して考えられるものではありません。重要なのは、インシデント発生後に責任範囲を議論することだけではなく、平時から、どのような連携体制で対応するのか、どの情報を誰が保有しているのか、どのように調査や報告を進めるのかを十分に整理しておくことです。

    インシデント対応で求められるフォレンジック調査

    クレジットカード情報漏洩が疑われる場合、適切な封じ込めや再発防止につなげるためにも、何が起きたのかを客観的に把握することが重要です。そのため、フォレンジック調査では次のような対応を行います。

    • 原因の特定
      ECサイトの改竄、不正ファイルの設置、管理画面からの侵入など、どのような経路で侵害が発生したのかを調査し、事実関係を整理します。
    • 被害範囲の把握
      どの期間に、どの画面やシステムが影響を受け、どの情報が漏洩した可能性があるのかを確認します。影響範囲を把握することで、関係者への説明、外部報告、顧客対応、決済再開の判断をしやすくなります。
    • 侵入経路や影響の分析
      ログ、ファイル、通信履歴、システム構成などを調査し、侵入経路や改竄内容、攻撃の時系列、影響範囲を明らかにします。
    • 報告・説明対応の支援
      クレジットカード情報漏洩が疑われる場合には、アクワイアラや国際ブランド等への報告対応が求められることがあります。第三者による調査結果は、事実確認や説明責任を果たすうえで重要な根拠となります。
    • 再発防止にむけた基盤づくり
      フォレンジック調査は単なる原因調査ではなく、被害拡大防止、再発防止、関係者への説明を支えるための重要なプロセスです。ログ、ファイル、通信、システム構成などを確認し、侵入経路や改竄内容、攻撃の時系列、影響範囲を明らかにしていきます。何が分かり、何が分からないのかを整理することで、その後の対応につなげることができます。特にクレジットカード情報漏洩が疑われる場合には、アクワイアラや国際ブランド等への報告対応も想定されるため、第三者による調査結果が重要になる場面があります。

    初動対応を左右する平時の備え

    クレジットカード情報漏洩のインシデントでは、発生後の初動対応がその後の調査、報告、復旧に大きく影響します。どのシステムを確認するのか、どのログを保全するのか、誰に連絡するのかが整理されていなければ、対応開始までに時間を要してしまいます。結果として、被害範囲の特定や関係者への説明も遅れる可能性があります。そのため重要になるのが、「平時からの備え」です。具体的には、システム構成や委託先の把握、ログの保存場所や保全方針の確認、関係者の連絡先や判断権限の整理、初動対応手順の整備、外部専門家との連携体制の確保などが挙げられます。さらに、NDAや基本契約を事前に整えておけば、インシデント発生後に契約条件や情報共有範囲を調整する時間を減らし、調査や封じ込めに着手しやすくなります。これらを事前に確認しておくことで、発生時に「何から手を付けるか」と迷う時間を減らすことができます。

    平時の備えは技術部門だけの課題ではありません。法務、広報、顧客対応、経営層、委託先を含めた体制整備が必要です。インシデント発生時には、技術調査と並行して、報告、通知、公表、問い合わせ対応が進むためです。クレジットカード情報漏洩対策では、防御策を強化することはもちろん重要です。しかし、それだけでは十分とはいえません。万一に発生した場合は、速やかに封じ込め、調査し、説明できる状態を作っておくことが重要です。

    有事に備えた準備はできていますか?

    クレジットカード情報漏えいが発生した場合、初動対応、原因調査、被害範囲の特定、関係各所への報告など、多くの対応を短期間で進める必要があります。BBSecでは、PCI SSC認定のPFIとして、クレジットカード情報漏えいフォレンジック調査を提供しています。万が一の際に迅速な対応を行うためにも、平時からの備えをご検討ください。
    クレジットカード情報漏えいフォレンジック調査サービスはこちら

    まとめ

    クレジットカード情報漏洩は、ECサイト加盟店だけの問題ではなく、PSPを含む決済サプライチェーン全体に影響を及ぼすインシデントです。情報の非保持化やPCI DSS準拠といった対策は重要ですが、それだけでリスクを完全に防ぐことはできません。だからこそ、防御策に加え、発生時の初動対応、調査、関係者連携まで含めて、平時から備えておくことが重要です。


    「非保持化しているから安心」とは言い切れない時代へ
    情報漏洩インシデントは、Webアプリケーションの脆弱性や設定不備、運用上の課題など、複数の要因が重なって発生します。PCI DSS v4.0では、継続的な脆弱性管理やペネトレーションテストなど、従来以上に運用・監視を重視した対応が求められています。情報漏洩リスクに備えるために、PCI DSS v4.0で押さえておきたいポイントをウェビナーで詳しく解説しています。
    【関連ウェビナー】「今さら聞けない!PCI DSS v4.0で求められる脆弱性診断
    詳細・お申し込みはこちら


    無料PDF|SQAT® Security Report 2026春夏号

    サービスに関する疑問や質問はこちら


    Security Serviceへのリンクバナー画像
    BBSecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    BBSecホワイトペーパー「企業のセキュリティ成熟度チェックリスト」資料ダウンロードボタン

    編集責任:木下

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

    企業のセキュリティ成熟度 vol.2

    Share

    セキュリティ成熟度別ロードマップ

    このようなお悩みはありませんか?

    • 何から対策を始めるべきかわからない
    • 対策の優先順位を整理したい
    • 限られたリソースで効率的に改善を進めたい

    本資料ではセキュリティ成熟度に応じて優先的に取り組むべき対策と、
    段階的な改善の進め方をわかりやすく整理しています。

    資料イメージ

    セキュリティ成熟度ロードマップ_全体像
    成熟度別の対策ロードマップ
    成熟度向上で得られる効果
    改善に向けた次のアクション

    まずは現状把握から始めたい方へ

    セキュリティ対策の優先順位を検討する前に、まずは自社の対策状況を把握することが重要です。「企業のセキュリティ成熟度チェック」では、40項目のセルフチェックを通じて、現在の対策状況や改善が必要な領域を確認できます。

    企業のセキュリティ成熟度チェックリストページリンクボタン

    企業のセキュリティ成熟度チェックがダウンロードできるURLをお送りいたします。
    ダウンロードご希望の方は下記の申し込みフォームからお申し込みください。

    関連サービス


    改善計画の策定や対策の優先順位付けでお悩みではありませんか?

    セキュリティ対策は、企業の状況や成熟度によって優先すべき取り組みが異なります。
    「何から着手すべきかわからない」
    「自社に適した対策を整理したい」
    といった場合は、お気軽にご相談ください。
    BBSecが現状や課題を整理し、改善に向けた進め方をご提案します。


    Security NEWS TOPに戻る

    企業のセキュリティ成熟度 vol.1

    Share

    企業のセキュリティ成熟度チェック

    このようなお悩みはありませんか?

    • 自社のセキュリティ対策レベルがわからない
    • どこに課題があるかわからない
    • セキュリティ対策の状況を客観的に確認したい

    本資料では、40項目のチェックシートを通じて
    セキュリティ対策状況の可視化と改善優先度の整理を支援します。

    資料イメージ

    BBSecセキュリティ成熟度チェック_チェックの概要イメージ
    資料概要
    BBSecセキュリティ成熟度チェック_チェックシートイメージ
    40項目のチェックシート
    BBSecセキュリティ成熟度チェック_スコア判定と改善アクション
    スコア判定と改善アクション

    診断結果の次の一手をお考えの方へ

    vol.1「企業のセキュリティ成熟度チェック」で現状を把握した後は、結果に応じた対策の優先順位を整理することが重要です。vol.2「セキュリティ成熟度別ロードマップ」では、成熟度に応じて何から取り組むべきか、どのような順番で対策を進めるべきかを解説しています。チェック結果を具体的な改善アクションにつなげたい方は、ぜひあわせてご活用ください。

    セキュリティ成熟度別ロードマップページリンクボタン

    企業のセキュリティ成熟度チェックがダウンロードできるURLをお送りいたします。
    ダウンロードご希望の方は下記の申し込みフォームからお申し込みください。

    関連サービス


    チェック結果を次のアクションにつなげませんか?

    チェック結果を踏まえ、優先的に取り組むべき対策や改善の進め方について
    専門家がご相談を承ります。自社に適した対策の整理にぜひご活用ください。


    Security NEWS TOPに戻る

    ゼロデイ脆弱性とは?最新事例と企業が取るべき対策を解説

    Share
    ゼロデイ脆弱性とは?最新事例と企業が取るべき対策を解説アイキャッチ画像

    ゼロデイ脆弱性は、修正パッチが提供される前に悪用される極めて危険な脆弱性です。ChromeやFirefox、VPN機器など、企業で日常的に利用される製品でも継続的に確認されており、情報漏えいや業務停止につながるケースもあります。本記事では、ゼロデイ脆弱性の基本的な仕組みや実際の被害事例、従来対策が通用しにくい理由を整理しながら、企業に求められる現実的な対策について解説します。

    ゼロデイ脆弱性が実際にどのように悪用されるのかについては、以下の記事で詳しく解説しています。
    世界で多発するゼロデイ攻撃とは?Apple・Google・Ciscoを襲った脆弱性の実態と対策

    本記事は2026年5月時点の情報をもとに作成しています。記載している脆弱性情報やCVE詳細は、公開後に内容が更新される場合があります。最新情報は各ベンダーおよびNVD・CISAの公式情報をご確認ください。

    はじめに

    ChromeやFirefoxなど、日常業務で広く使われている主要ブラウザでも、ゼロデイ脆弱性は繰り返し確認されています。ゼロデイ脆弱性とは、製品ベンダーや利用企業が十分な修正猶予を持てないまま悪用される、極めて危険度の高い脆弱性です。企業にとってゼロデイ脆弱性が厄介なのは、単に危険な脆弱性であるという点だけではありません。多くの場合、攻撃が確認された時点では、すでに悪用が始まっているか、修正パッチの適用が間に合っていない状態です。つまり、通常のパッチ管理や既知のマルウェア検知だけでは、防御が後手に回る可能性があります。 Webブラウザ、VPN機器、セキュリティ製品、業務アプリケーション、開発支援ツールなど、企業活動を支えるソフトウェアの多くは、常に外部との接点を持っています。そのため、ゼロデイ脆弱性は情報漏えい、業務停止、信用毀損、取引先への影響といったビジネスリスクに直結します。まず押さえたいのは、ゼロデイ脆弱性を悪用した攻撃に対し、完全に避けるのではなく、発生を前提に、侵入されにくく、侵入されても早期に検知し、被害を抑え込める体制を整えることです。

    ゼロデイ脆弱性とは何か

    ゼロデイ脆弱性とは、製品ベンダーや利用者がまだ十分に把握していない、または修正パッチが提供されていない脆弱性を指します。「ゼロデイ」という言葉は、攻撃者に悪用される可能性があるにもかかわらず、防御側に残された対応猶予が実質的にゼロ日であることに由来します。ここで整理しておきたいのが、「脆弱性」と「攻撃」は同じものではないという点です。脆弱性は、ソフトウェアやシステムに存在するセキュリティ上の欠陥です。一方で、ゼロデイ攻撃は、その未知または未修正の欠陥を悪用して、情報の窃取、権限昇格、不正コード実行、システム侵入などを行う攻撃行為を指します。NIST(米国立標準技術研究所)では、ゼロデイ攻撃を「これまで知られていなかったハードウェア、ファームウェア、ソフトウェアの脆弱性を悪用する攻撃」と定義しています。

    たとえば、あるブラウザに不正なHTMLページを処理した際に任意のコード実行につながる欠陥があったとします。その欠陥自体がゼロデイ脆弱性であり、攻撃者が細工したWebページへ利用者を誘導して実際に悪用すれば、それがゼロデイ攻撃になります。CVEはこうした脆弱性を識別するための共通番号であり、NVD(米国国立脆弱性データベース)ではCVEプログラムについて、「特定のコードベースで確認された脆弱性を参照するための辞書、または用語集のような仕組みだ」と説明しています。

    なぜゼロデイ脆弱性は危険なのか

    ゼロデイ脆弱性が危険視される最大の理由は、修正パッチが存在しない、または広く適用される前に攻撃が始まることです。一般的な脆弱性対応では、ベンダーが脆弱性情報を公開し、修正パッチを提供し、企業が影響範囲を確認して適用するという流れになります。しかしゼロデイの場合、この順番が崩れます。攻撃者が先に脆弱性を把握し、攻撃に利用してから、ベンダーや利用者が気づくことがあるためです。もう一つの問題は、従来型のシグネチャ検知が効きにくいことです。シグネチャ型のセキュリティ対策は、既知のマルウェアや既知の攻撃パターンを検出するうえでは有効です。しかし、まだ十分に解析されていない攻撃コードや、新しい悪用手法に対しては、検知が遅れる可能性があります。NISTの関連文献でも、「ゼロデイ攻撃は未知の脆弱性を悪用するため従来のシグネチャ型検知では事前に攻撃シグネチャを用意できず有効性に限界がある*2」とされています。

    ゼロデイ攻撃は、標的型攻撃にも使われやすい傾向があります。攻撃者にとって、未修正の脆弱性は価値の高い侵入口です。特に、ブラウザ、VPN、ファイアウォール、メールサーバ、リモートアクセス製品、エンドポイント管理製品などは、企業ネットワークの入口や重要な業務環境とつながっているため、攻撃が成功した場合の影響が大きくなります。 ビジネス面では、ゼロデイ脆弱性の悪用は情報漏えい、業務停止、顧客対応コストの増加、監督官庁や取引先への報告、ブランド信用の低下などに発展します。攻撃の起点が一台の端末や一つのWebアクセスであっても、その後に認証情報の窃取、横展開、機密情報の持ち出しが行われれば、被害は組織全体へ拡大します。

    実際の被害事例

    Google Chromeで相次いだゼロデイ脆弱性

    ゼロデイ脆弱性の代表的な事例として、Google Chromeの脆弱性が挙げられます。Chromeは多くの企業で標準ブラウザとして利用されており、Webメール、SaaS、業務システム、クラウド管理画面などへのアクセスにも使われています。そのため、Chromeのゼロデイ脆弱性は、単なる個人利用者向けブラウザの問題ではなく、企業の業務端末リスクとして捉える必要があります。

    2025年には、Chromeで悪用が確認されたゼロデイ脆弱性が複数回修正されました。BleepingComputerでは、2025年から2026年にかけてChromeは複数のゼロデイ脆弱性を修正したと報じています*2。2026年2月には、CVE-2026-2441が修正されました。NVDによれば、この脆弱性はChromeのCSSにおけるUse After Free(解放済メモリの再利用)の問題であり、 Google Chrome 145.0.7632.75より前のバージョンでは、細工されたHTMLページを介してリモート攻撃者がサンドボックス内で任意のコードを実行できる可能性がありました。GoogleのChrome Releasesでも、この脆弱性について「実際に悪用が確認されている」旨が記載されています。2026年3月には、CVE-2026-3909CVE-2026-3910が修正されました。CVE-2026-3909は「Skia(Chromeが使用するグラフィック処理ライブラリ)における境界外の書き込み」で、細工されたHTMLページを介して境界外メモリアクセスにつながる可能性があります。CVE-2026-3910は「V8(ChromeのJavaScript実行エンジン)における不適切な実装」で、細工されたHTMLページを介してサンドボックス内で任意のコード実行が可能となるおそれがありました。GoogleはCVE-2026-3910について、「実際に悪用が確認されている」と公表しています。また、2026年3月末にはCVE-2026-5281も修正されています。NVDによれば、これはChromeのDawnにおける解放済メモリの再利用の脆弱性で、レンダラープロセスが侵害された状態で、細工されたHTMLページを通じて任意のコード実行につながる可能性があるものです。Googleはこの脆弱性についても、「実際に悪用が確認されている」と公表しています。

    これらの事例が示しているのは、Webブラウザが単なる閲覧ツールではなく、企業ネットワークへの入口になり得るということです。利用者が業務中にWebサイトを閲覧する、SaaSへアクセスする、メール内のリンクを開くといった日常的な操作が、ゼロデイ攻撃のきっかけになる可能性があります。

    OpenAI Codexに関するサンドボックス迂回の事例

    近年は、開発支援ツールやAI関連ツールもゼロデイリスクの対象になっています。Zero Day Initiativeは2026年4月、OpenAI Codexに関するZDI-26-305を公開しました*3。この脆弱性は、影響を受けるOpenAI Codex環境においてサンドボックスを迂回できる可能性があるものとされ、攻撃には、「標的ユーザーが悪意あるJavaScriptを含むリポジトリをCodexで処理する必要がある」と説明されています。OpenAI Codex CLIでは2025年にも、サンドボックス設定ロジックの問題により、意図したワークスペース境界を迂回し、Codexプロセスが権限を持つ範囲で任意のファイル書き込みやコマンド実行につながる可能性がある脆弱性が、GitHub Security Advisoryで公開されています*4。この問題はCodex CLI 0.39.0で修正され、利用者には更新が推奨されています。

    この事例から分かるのは、ゼロデイ脆弱性がOSやブラウザだけの問題ではないということです。開発者が利用するCLIツール、AIエージェント、コード生成支援ツール、CI/CD環境も、企業の重要な攻撃面になりつつあります。特に、ソースコード、認証情報、クラウド設定、APIキーにアクセスする可能性があるツールでは、サンドボックスや権限管理を過信しない運用が必要です。

    ゼロデイ攻撃の仕組み

    ゼロデイ攻撃の流れ概要図

    ※ゼロデイ攻撃では、脆弱性公開前や修正前に攻撃が始まるため、従来型のシグネチャ検知だけでは防御が難しい場合があります。

    ゼロデイ攻撃は、脆弱性の発見から攻撃実行までが非常に速い場合があります。攻撃者は、ソフトウェアの不具合を独自に発見することもあれば、脆弱性情報が闇市場や限定的なコミュニティで売買されることもあります。その後、攻撃者はその脆弱性を悪用するエクスプロイトコードを作成し、標的組織に対して攻撃を実行します。まず、未公開または未修正の脆弱性が発見されるところから始まります。次に、その脆弱性を悪用するための攻撃コードが作成されます。ブラウザの脆弱性であれば、細工されたHTMLページやJavaScriptが使われることがあります。VPNや外部公開サーバの脆弱性であれば、インターネット越しに直接攻撃が行われることもあります。攻撃が成功すると、攻撃者は端末やサーバへ侵入し、認証情報の取得、権限昇格、内部ネットワークへの横展開を試みます。その後、機密情報の収集、データの持ち出し、ランサムウェアの展開、バックドア設置などへ進む可能性があります。

    ゼロデイ攻撃の基本的な仕組みについては、以下の記事でも詳しく解説しています。
    世界で多発するゼロデイ攻撃とは?Apple・Google・Ciscoを襲った脆弱性の実態と対策

    従来対策が通用しない理由

    ゼロデイ脆弱性への対応で難しいのは、従来のセキュリティ対策が必ずしも十分に機能しないことです。もちろん、ウイルス対策ソフト、ファイアウォール、パッチ管理、メールセキュリティ、URLフィルタリングといった対策は今でも重要です。しかし、ゼロデイ攻撃では、これらをすり抜ける可能性があります。シグネチャ型対策は、既知の攻撃には強い一方で、未知の攻撃には限界があります。攻撃コードが新しく、まだ検体や攻撃パターンが共有されていない場合、検知ルールが存在しないことがあります。さらに、攻撃者は正規のWeb通信、正規のプロセス、正規の認証情報を利用して侵入後の活動を行うため、外形上は通常の業務通信に見えることもあります。また、境界防御だけに依存した対策では対応が難しいケースも増えています。クラウドサービスやリモートワークの拡大により、従来の「社内は安全」という前提だけでは、ゼロデイ攻撃のような未知の脅威への対応が難しくなっています。ゼロデイ攻撃では、社内端末、クラウドアカウント、開発端末、外部公開資産のどこからでも侵入口が生まれる可能性があります。

    ゼロトラストの考え方を含め、従来型セキュリティ対策の課題については、こちらの記事でも詳しく解説しています。
    ゼロトラストセキュリティ -今、必須のセキュリティモデルとそのポイント-

    ゼロデイ脆弱性への対策

    ゼロデイ脆弱性への対策では、未知の攻撃を完全に防ぐことだけでなく、侵入後の被害を最小限に抑えるアプローチが重要です。ゼロトラストに基づく権限管理や多要素認証に加え、EDRやXDRによる侵入後の検知、ASMによる攻撃面の把握、SOCによる継続監視などを組み合わせた多層的な対策が求められます。

    ゼロデイ攻撃対策を支援するBBSecのアプローチ

    ゼロデイ攻撃へ備えるには「脆弱性情報を知ること」だけでなく、「自社がどの製品を利用しているのか」「どこが外部公開されているのか」を知ることで自社環境への影響を迅速に把握し、継続的に監視・対応できる体制を持つことが重要になります。

    ブロードバンドセキュリティ(BBSec)では、EDR-MSSによる侵入後の検知・対応、G-MDRによる高度な脅威分析、ASMによる攻撃面の可視化を通じて、企業のゼロデイ対策を支援しています。ゼロデイ脆弱性への備えを強化したい方は、以下のサービスページもあわせてご覧ください。

    ASM(アタックサーフェス管理)の考え方や、攻撃面を継続的に把握する重要性については、こちらの記事でも詳しく解説しています。
    脆弱性管理とIT資産管理 -サイバー攻撃から組織を守る取り組み-

    まとめ

    ゼロデイ脆弱性は、主要ブラウザやVPN機器、業務ソフトウェアなど、企業が利用するさまざまな環境で発生する可能性があります。ゼロデイ攻撃による被害を抑えるためには、パッチ管理だけでなく、ゼロトラストに基づく権限管理、EDRやXDRによる侵入後の検知、ASMによる攻撃面の把握、SOCによる継続監視などを組み合わせた多層的な対策が求められます。

    【参考情報】


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

  • 2026年6月3日(水)14:00~15:00「金融機関の対応事例に学ぶPQC移行の進め方と実務ポイント
  • 2026年6月10日(水)14:00~14:30「Webサイトの見えない脅威を可視化する 外部タグ・サードパーティースクリプトの監視対策
  • 最新情報はこちら


    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

    サービスに関する疑問や質問はこちらからお気軽にお問合せください。


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

    編集責任:木下

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

    ソーシャルエンジニアリングとは?代表的な手口・事例・対策を解説

    Share

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

    SQAT® Security Report 2020-2021年 秋冬号掲載
    「人という脆弱性~ソーシャル・エンジニアリング攻撃~」より一部抜粋

    特殊詐欺のイメージ画像(電話・お金・メモ)

    サイバー攻撃というとシステムの脆弱性を狙うイメージがありますが、実際には「人」を狙う攻撃が多く発生しています。ソーシャルエンジニアリングは、人間の心理や行動の隙を悪用して情報を窃取する攻撃手法です。標的型メール、なりすまし、SNSを利用した情報収集など、その手法は年々巧妙化しています。本記事では、ソーシャルエンジニアリングの代表的な手口や心理的脆弱性について解説します。

    ※本記事は「SQAT® Security Report 2020-2021年 秋冬号」の内容を一部再編集したものです。

    この記事でわかること

    • ソーシャルエンジニアリングとは何か
    • 人が騙される心理的要因
    • 代表的な攻撃手法
    • 企業で必要な対策
    • セキュリティ教育の重要性

    ソーシャルエンジニアリングとは

    そもそも、ソーシャル・エンジニアリングとは何なのだろうか? ソーシャル・エンジニアリングフレームワークの第一人者と知られるクリストファー・ハドナジー(Christopher Hadnagy)氏は、著作『ソーシャル・エンジニアリング』(日経BP社)の中で、ソーシャル・エンジニアリングを「人を操って行動を起こさせる行為。ただし、その行動が当人の最大の利益に適合しているか否かを問わないこともある」と定義づけている。これには警察官、弁護士、医師といった人々が、標的当人の利益となるように誘導するといったケースも含まれているが、一般的にサイバー攻撃におけるソーシャル・エンジニアリングとは、不正アクセスするのに必要なシステム情報、アカウント、パスワード、ネットワーク・アドレス等を正規のユーザあるいはその家族、友人などから人間の心理的な隙や、行動のミスにつけ込んで手に入れる手法と位置付けられることが多くなっている。ソーシャル・エンジニアリング攻撃の定義は様々なものがあるが、その共通するところは、人を介して攻撃を行うという点である。

    なぜ人は騙されるのか

    では、なぜ人が脆弱性となってしまうのか、この点について、原因の一つとなっていると考えられる、人に存在する心理的脆弱性を見ていきたい。ハドナジー氏は人には以下のような8つの心理的脆弱性が備わっていると主張している。

    返礼

    人からの親切に対し、お返しをせずにはいられない特性
    例:プレゼントのお返しに、何かしてほしいことはないかと聞く。

    義務感

    社会的、法的、道徳的に、人がなすべきだと感じている行動をとってしまう特性
    例:身体が不自由な人に、積極的に手を差し伸べなくてはならないと考えて寄付を行う。

    譲歩

    何かを譲ってもらったら、同じように譲らなくてはならないと考える特性
    例:相手の大きな要求を最初に断ったのだから、次の小さな要求には応じてあげたいと考える。

    希少性

    入手しづらいものであるほど貴重なものに思え、手に入れたくなってしまう特性
    例:同様の商品の中で手に入れるなら、期間限定で販売された商品を手に入れたいと考える。

    権威

    組織的、社会的に、強い権威者とみなされる者の命令に従ってしまう特性
    例:強い権威を持つ人間が言っているのだから、正しいと考える。

    言質と一貫性

    自分や他人の行動・言質が、過去から一貫性がとれていることを高く評価する特性
    例:一度購入すると言ったものが、予想よりも高かったとしても、前言を撤回するのは恥ずかしいと考える。

    好意

    好意を持っている人から頼まれると、承諾してしまう特性
    例:親密な人から何かを頼まれると、そうでない人から頼まれるよりも簡単に請け負ってしまう。

    コンセンサスもしくは社会的証明

    他人の考えにより、自分が正しいかどうかを判断する特性
    例:有名人が利用している商品を、自分も利用したいと考える。


    代表的なソーシャルエンジニアリング攻撃

    ここ数年、ソーシャル・エンジニアリングを用いた攻撃による大規模な事件が多数発生している。

    ・2015年に発生した日本年金機構の大規模な情報漏洩事件*5
    ・2017年の大手航空会社が3億8000万円をだましとられた事件*2
    ・2018年の暗号通貨の不正送金事件*3
    ・2020年7月に起きた大手SNSの大規模アカウントハック事件*4

    これらはすべてソーシャル・エンジニアリングを用いた攻撃に端を発しているといわれている。ソーシャル・エンジニアリングを用いた攻撃の高まりを受けて、IPA(独立行政法人 情報処理推進機構)が「ソーシャル・エンジニアリングを巧みに利用した攻撃の分析と対策」*5 を発表したのが2009年であるが、10年以上が経過した今も、ソーシャル・エンジニアリングを用いた攻撃は、収まる気配がない。それは、ソーシャル・エンジニアリングが持つ、人間という脆弱性を狙う性質に原因がある。ここでは、今一度、ソーシャル・エンジニアリングと人間とのかかわりを考えていきたいと思う。


    公開日:2021年9月17日
    更新日:2026年5月27日

    編集責任:木下


    Security Report 2020-2021年 秋冬号表紙画像

    弊社では、ソーシャルエンジニアリング攻撃や人的脆弱性について詳しく解説した
    SQAT® Security Report 2020-2021年 秋冬号」を無料公開中です。ぜひ資料ダウンロードをしてご一読ください。

    ※参考(続き)
    contents
    4.人へのバッファオーバーフロー攻撃
    5.人間の隙をつくソーシャル・エンジニアリング攻撃
    6.テクノロジーが人間を追い詰める
    7.ソーシャル・エンジニアリングに対する防御
    8.おわりに

    人的セキュリティ対策を強化したい方は、ぜひご活用ください。

    無料PDF|SQAT® Security Report 2020-2021秋冬号

    その他のSQAT® Security Report

    無料PDF|SQAT® Security Report 2026春夏号

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

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

    脆弱性診断は受けたけれど ― SSVCで考える「脆弱性管理」と優先順位付け

    Share

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

    ~とある会社Aと脆弱性診断の結果を受け取った関係者とのやり取り~

    脆弱性診断を受けたA社では入社3年目のセキュリティ担当・Bさんが結果に頭を抱えています。なぜなら、社内ネットワークに使っているスイッチにCVSSスコア9.8の脆弱性、リモートアクセスに使用しているVPNゲートウェイにCVSSスコア8.8、オンラインショップ用の受発注管理に利用しているデータベースにCVSSスコア7.5の脆弱性が見つかってしまったからです。リスクはどれも「高」レベルとして報告されたため、Bさんは上司に相談し、すべてに修正パッチを当てるようスイッチとVPNゲートウェイについてはインフラチームの担当者に、データベースについては開発部に連絡することにしました。

    インフラチームのCさんとSlackでやり取りをしていたBさんはCさんからこんなことを伝えられます。

    インフラチームCさん「修正パッチを適用するとなると、インフラチームは基本みんなリモートだから、誰かを土日のどこかで休日出勤させるか、急ぎだったら平日の夜間に勤務させて、パッチを当てることになるけど、どれぐらい急ぎなの?」

    「あと、VPNとスイッチ、どっちを先に作業したほうがいいの?パッチの情報を調べてみたら、VPNのほうは一度途中のバージョンまで上げてから最新バージョンまで上げないといけないみたいで、作業時間がすごくかかりそうだから、別日で作業しないとだめかもしれないんだよね」

    Bさんは答えに詰まってしまいました。リスクレベルは高だといわれているけれども、どれぐらい急ぐのかは誰も教えてくれないからです。

    答えに詰まって「確認してから折り返し連絡します」と返したところ、「セキュリティ担当はいいなあ。土日とか夜間に作業しなくていいし、すぐに答えなくてもいいんだから」と嫌味までいわれてしまいました。

    Bさんは脆弱性診断の結果が返ってきてから1週間後、開発部門のD部長にセキュリティ担当と開発部門の定例会議の際に報告事項としてパッチ適用の件を報告しました。するとD部長はこういいました。

    開発部D部長「この件、1週間ほど報告に時間を要したようですが、脆弱性診断の結果以外に何か追加の情報はありますか?あと、この脆弱性診断の結果によるとリスクレベル高とありますが、社内の規定としてどの程度急ぐかといった判断はされましたか?」

    開発部のほかの人にもこんなことをいわれてしまいます。

    開発部担当者「パッチを適用する場合、ステージング環境で影響を調査したうえで必要であればコードや設定の修正などを行う必要がありますが、その時間や工数は考慮されていないですよね。通常の開発業務とどちらを優先すべきかといった判断はどうなっているんですか?」

    Bさんはまたもや言葉に詰まってしまいます。セキュリティ担当は自分と上司の2人だけ、上司は別の業務との兼務でパッチの適用の優先順位付けまで考えている時間はありません。自分もEDRやファイアウォールの運用をしながら脆弱性診断の依頼や結果を受け取るだけで、とても他の部門の業務内容や環境のことまで把握しきる余裕がないのです。


    ここまで、架空の会社A社と脆弱性診断の結果を受け取った関係者の反応を物語形式でお送りいたしました。現在、弊社の脆弱性診断サービスでは脆弱性単体のリスクの度合いの結果をご提供させていただくことはあっても、その脆弱性をどういった優先度で修正しなければならないかといった情報はご提供しておりません。なぜならば、パッチを適用するにあたって優先順位をつけるためにはお客様しか知りえない、以下の要素が必要になるためです。

    パッチ適用の優先順位をつけるための3つの要素

    1. 脆弱性を持つアセットが置かれている環境
      ・インターネット上で公開された状態か、IPSやFWなどで制御されたネットワーク内か、もしくはローカル環境依存といった非常に限定的な環境かといった分類
      ・CVSSでいう環境スコア(CVSS-E)の攻撃区分(MAV)にあたる、実際の環境依存の要素
    2. アセットが攻撃を受けた場合に事業継続性に与える影響
    3. アセットが攻撃を受けた場合に社会や社内(運用保守・人材)に与える影響

    冒頭のA社のケースでは以下のように整理できるでしょう。

    アセットが置かれている環境

    • VPN:インターネット上で公開された状態
    • データベース:設定を間違っていなければIPSやFWなどで制御されたネットワーク配下だが、公開ネットワーク寄り
    • スイッチ:設置環境によって制御されたネットワーク内かローカル環境になる。

    アセットが公開されている場合、攻撃者からよりアクセスしやすいことからより緊急度が高いといえるので、VPN=データベース>スイッチの順になると考えられるでしょう。

    アセットが攻撃を受けた場合に事業継続性に与える影響

    アセットが攻撃を受けた場合に自社の事業継続にどの程度影響が出るかといった要素です。
    仮にランサムウェア攻撃によって影響を受けた場合、それぞれのアセットの停止でどの程度の影響が出るかを想定してください。A社の場合事業継続性への影響度順でいうと、データベース>VPN>スイッチの順になると考えられます。

    今回の場合はデータベースが事業に直結しており、顧客情報を含むデータを持っているため、継続性への影響度が高いという想定です。アセットの利用目的や環境によってはこの順番が入れ替わることもあります。

    アセットが攻撃を受けた場合に社会や社内に対して与える影響

    A社がランサムウェア攻撃を受けた場合はオンラインショッピングサイトのデータベース関連で以下の影響が見込まれます。

    • 顧客情報の漏洩
    • 運用およびシステムの復旧にかかる費用と工数

    このほかにVPNやスイッチもフォレンジック調査の対象となって業務が行えなくなる可能性が高いと考えられます。VPNに関しては利用できない期間、社員の出社が必須になるなどワークスタイルへの影響も出る可能性もあります。こういったことから、社会および社内に対して与える影響でA社の例を考えると影響度は、データベース>VPN=スイッチと考えられるでしょう。

    SSVCとは

    こうした情報があったうえで利用ができようになる優先順位付けの方法があります。それが「SSVC(Stakeholder-Specific Vulnerability Categorization)」です。SSVCは脆弱性管理プロセスに関与する利害関係者のニーズに基づいて脆弱性に優先順位を付けるための方法論とされており、経営・マネジメント層、システム開発者、システム運用者といったステークホルダーと一緒に脆弱性に対処していくための方法論といえます。SSVCは脆弱性そのものの技術的評価ではなく、脆弱性にどのように対処するかという観点での評価を行うフレームワークになります。

    SSVCの3つのモデル

    1. ソフトウェアやハードウェアの供給者、すなわちパッチを開発する人が用いる「Supplier Decision Model
    2. ソフトウェアやハードウェアを利用する側、つまりパッチを適用する人が用いる「Deployer Decision Model
    3. CSIRTやPSIRT、セキュリティ研究者やBug Bounty Programなど、脆弱性に対して何らかの調整やコミュニケーションのハブとなりうる人、コーディネーターが用いる「Coordinator Decision Model

    このうち、「Deployer Decision Model」と「Supplier Decision Model」ではプライオリティ(対応優先度)付けの結果を4つにわけています。

    SSVCで得られるプライオリティ付けの結果

    Deployer ModelSupplier Model
    Immediateすべてのリソースを投入し、通常業務を止めてでもパッチの適用を直ちに行うべきである全社的にすべてのリソースを投入して修正パッチを開発し、リリース
    Out-of-cycle定期的なメンテナンスウィンドウより前に、やむを得ない場合は残業を伴う形で緩和策または解消策を適用緩和策または解消策を他のプロジェクトからリソースを借りてでも開発し、完成次第セキュリティパッチとして修正パッチをリリース
    Scheduled定期的なメンテナンスウィンドウで適用通常のリソース内で定期的な修正パッチのリリースタイミングでパッチをリリース
    Defer現時点で特に行うことはない現時点で特に行うことはない

    ここではDeployer Decision ModelをもとにA社がどのようにパッチを適用すべきか検討してみましょう。

    まず、Bさんは上司に相談したうえで、前述した3つの要素、「脆弱性を持つアセットが置かれている環境」、「事業継続性への影響」、「社会や社内への影響度」を定義していく必要があります。また、この定義に当たっては実際の環境や利用用途、部門内のリソースなどをよく知っているインフラチームや開発部といった当事者、つまりステークホルダーの関与(少なくとも承認)が必要となってきます。このほかに優先順位付けの結果、”Immediate”や”Out-of-Cycle”が出た場合の対応プロセスも用意しておく必要があります。Bさん1人で何かできることはそれほど多くはなく、社内のステークホルダーへの聞き取りや経営層への説明、必要なプロセスの準備と合意形成など、上司や部門全体も含めて組織的に取り組まなければならないといえます。さらに、Bさんは脆弱性自体が持つ以下の要素を調べる必要があります。

    脆弱性が持つ要素

    自動化の可能性

    攻撃者がツール化して脆弱性を悪用するかどうかを判定するものとなります。これは攻撃者がツール化した場合、攻撃者間でツールの売買が行われるなど汎用的に悪用される可能性があるため、把握が必要な要素となります。一部の脆弱性はCISA VulnrichmentやCVSS4.0のSupplement MetricsのAutomatableの値が参照できますが、情報の参照先がないものについてはPoCの有無やPoCの内容から自動化の可否を判断する必要があります。この点はSSVC利用の難点として挙げられることもあります。

    悪用の状況

    実際に攻撃されていることを示すActive、PoCのみを示すPoC、悪用されていないことを表すNoneの3つに分類されます。この情報は時間の経過とともに変化する可能性が最も高く、逐次状況を確認する必要があります。情報の参照先は、KEVカタログ、CISA VulnrichmentのExploitationの値、CVSS4.0のThreat MetricsやNVDのReferenceのPoCの有無といったものが利用できます。唯一難点があるとすれば、日本国内でシェアの高い国内メーカー機器の情報がKEVカタログやCISA Vulnrichmentなどにあまり反映されない点にあります。

    まとめ ~CVSSとSSVCの活用~

    これまではCVSSが高い値のものだけ対処していた、という組織も多いでしょう。CVSSは脆弱性の単体評価ができ、脆弱性が広く悪用された場合の深刻度を測るための評価システムです。ただし、その脆弱性が存在するアセットがどのように利用されているか、そのアセットが業務継続性や運用保守、ひいては社会全体に対してどのような影響を与えるかといった観点が欠けていることが長らく問題視されてきたのも事実です。

    脆弱性管理は手間がかかる、登場人物が多い、意見がまとまらないといったこともあるでしょうし、「自動化の可能性とかわからないし、攻撃の状況をずっと見ているほどの時間の余裕はない!」といった様々なお声があるかと思います。しかし、今この瞬間どの企業がいつサイバー攻撃を受けるのか全く見当もつかない状況の中、少しでもリスクを回避したい、どこにリスクがあるのか手がかりをはっきりしておきたいという企業の皆さまもいらっしゃるかもしれません。本記事を通じて、こういった脆弱性管理手法があることを知っていただき、活用することでリスク回避ができるようになるための役立つ情報提供となれば幸いです。

    参考情報:


    公開日:2024年9月10日
    更新日:2026年5月13日

    編集責任:木下

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

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

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

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

    最新情報はこちら

    Youtubeチャンネルのご案内

    SQATチャンネル(@sqatchannel9896)では毎月、アナリストが語る「セキュリティトピック」解説動画やウェビナー動画を更新しています。 ぜひチャンネル登録をして、チェックしてみてください。


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

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