アフラック不正アクセスで約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に戻る

    備えあれば憂いなし!サイバー保険の利活用

    Share

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

    瓦版アイキャッチ(リスクとお金(コインをもっている手)のイメージ)

    サイバー攻撃による被害は増加の一途をたどっています。一般社団法人日本損害保険協会の調査によると、国内企業の約4割以上がサイバー攻撃被害に対する不安を抱えています。そのような不安に備える「サイバー保険」をご存じでしょうか。本記事ではサイバー攻撃を受けた場合に発生するコスト・損失に触れつつ、サイバー保険について解説し、セキュリティ対策の見直し方法についてご紹介いたします。

    他人事ではない!増加するサイバー攻撃による被害

    サイバー攻撃による被害は増加の一途を辿っており、昨今は企業規模・業界問わず被害に遭う可能性があります。

    国内では特にパソコンに保存したファイルやハードディスクを暗号化して、身代金を要求する不正プログラムである「ランサムウェア」による感染被害が多発しています。企業・団体等におけるランサムウェア被害として、令和4年上半期に都道府県警察から警察庁に報告のあった件数は114件であり、令和2年下半期以降、右肩上がりで増加しています。

    【企業・団体におけるランサムウェア被害の報告件数の推移】

    実際、一般社団法人日本損害保険協会の調査*2によると、国内企業の多くはコロナ渦でテレワークの導入が進んでおり、サイバー攻撃を受ける可能性について約4割の企業が「高まった」と回答しています。しかし同時に4割以上の企業がサイバーリスク対策における課題について「現在行っている対策が十分なのかわからない」と回答しており、リスクの高まりを認識しながらもセキュリティ対策への自信のなさがうかがえます。

    特に中小企業の場合は、セキュリティに対する知識や対策に必要な資源が限られているため、原因の特定や対策の実施が困難なケースも少なくありません。こういった背景からサプライチェーン上の脆弱な企業を狙われ、サプライチェーン全体が被害を受ける事案も見受けられます。

    サイバー攻撃の被害を受けてしまうと、個人情報の漏えい、機密データの改竄、サーバ停止やシステムの破壊などが発生する可能性があり、事業継続に影響を与えかねない脅威となります。

    国内で発生したサイバーインシデント事例

    2022年に国内で起こったサイバー攻撃の事例は以下の通りです。

    【国内サイバーインシデント事例】
    年月被害概要原因
    2022/1県の災害情報管理システムから津波に関する緊急速報メール大量送信*2 プログラム設定ミス
    2022/3アニメ製作会社が不正アクセスを受け複数の人気番組の放映スケジュールに影響*3システム障害
    2022/3代行申請企業の従業員がEmotetに感染し、情報漏洩となりすまし被害*4マルウェア感染
    2022/3国内メーカーホームページへの不正アクセスによりメールアドレス流出(約1万件)*5SQLインジェクション
    2022/5比較情報サイト運営等を行う企業がクラウドサービスの設定ミスにより最長6年間個人情報を不用意に公開(約5,000件)*6クラウド設定ミス
    2022/5国内人材情報企業の資格検定申込サイトに対する海外からの攻撃でメールアドレス流出(約29万件)*7SQLインジェクション
    2022/8組合直売店のネットショップ専用パソコンがEmotetに感染して顧客氏名やメールアドレス等流出(約50,000件)*8マルウェア感染

    【サプライチェーンの脆弱性を悪用した攻撃の事例】

    2022年3月1日に国内大手自動車メーカーの部品仕入先企業が同社の外部取引先企業との専用通信に利用していたリモート接続機器の脆弱性をきっかけとして不正アクセスを受け、この影響により自動車メーカーが国内全14工場28ラインを停止させる事態となった このサイバー攻撃は大手企業を狙ったサプライチェーン攻撃とみられる*9

    データ侵害発生時にかかるコスト

    機密情報等の漏洩が発生すると、その復旧作業に莫大なコストがかかります。復旧コスト自体も年々増加傾向にあるほか、データ侵害により信用失墜につながることで、深刻なビジネス上の被害を引き起こします。実際にデータ侵害による平均総コストの内、システム復旧や顧客の再獲得などにかかった割合は38%にものぼるとのことです。

    【4つのカテゴリ別データ侵害の平均総コスト(単位:100万米ドル)】

    サイバー攻撃を受けた場合に生じる費用・金銭的損失

    サイバー事故が発生した際に生じる費用は大きく分けて3つあります。

    損害賠償責任に伴う費用のサムネ
    インシデント対応に必要となる事故対応費用のサムネ
    事故発生により事業継続上被った金銭的損害のサムネ

    企業の経営者はこういったサイバー攻撃により発生する費用を未然に防ぐため、以下のようなガイドラインなども参考にしつつ、企業の追うべき責任について理解しておくことが重要です。

    【参考情報:ガイドライン】
    ・一般社団法人 日本経済団体連合会
     「サイバーリスクハンドブック 取締役向けハンドブック 日本版
    ・内閣官房内閣サイバーセキュリティセンター(NISC)
     「サイバーセキュリティ関係法令Q&A ハンドブック Ver1.0

    サイバー保険とは

    前述のような費用を包括的に補償する役割を果たすのが「サイバー保険」です。
    保険に加入することで、最悪の事態が起きた場合でも幅広い補償とサポートがうけられることで事業活動継続の命綱となります。(※補償の内容はサービスによって異なります。)

    サイバー保険の加入率は海外では増加傾向にあり、米国の企業で5割近く、英国では約4割に上る*10とのことです。これに対して、日本国内では大企業・中小企業共に加入率は1割以下との報告*11がありますが、サイバーセキュリティを取り巻く状況を鑑みると、今後国内でも認知・普及が広まっていくことが考えられます。

    サイバー保険の有効性

    これまで見てきたようにサイバー攻撃によるリスクは、金銭的損害、機会損失、信用失墜などがあります。事業活動継続のためには、こういったリスクに対してどう対処していくかをリスクの影響度や深刻度などに応じて自身で判断する必要があります。

    【主なリスク対策方法】
    リスク対策の種類概要対策例
    リスクの回避リスクの発生確率を低くする ・外部からのアクセスを許可しない
    ・物理的にもシステム接続を不可能にする
    ・クレジットカード情報などの個人情報を保存しない・収集しない
    リスクの低減リスク発生による影響を小さくする・通信の暗号化の強度を高くする
    ・認証機構を堅牢にし、セキュアな多要素認証を強制する
    リスクの移転リスクの影響を第三者に移すサイバー保険への加入
    リスクの受容リスクの発生を認め、
    何もしない
    対策をしない

    万が一の金銭的な損失に備え、自社ではなく保険会社という他者に補償させるという「リスクの移転」手段の1つとして有効なのが、サイバー保険です。

    今一度セキュリティ対策の見直しを

    サイバー攻撃手法は日々更新されており、さらに取引先や子会社などを含むサプライチェーンを踏み台にした攻撃など、どんなにセキュリティ対策を実施していても自組織のみではインシデント発生を防ぎきれないのが実情です。脆弱性診断の定期的な実施といった基本的なセキュリティ対策を行うとともに、万が一インシデントが発生してしまった場合の備えとして信頼できる第三者の専門企業に相談することをおすすめします。

    公開日:2022年11月2日
    更新日:2026年7月1日

    編集責任:木下


    サイバー保険付帯脆弱性診断サービスの紹介

    ※外部サイトにリンクします。

    サイバー保険付帯の対象となる脆弱性診断

    BBSecのSQAT® 脆弱性診断サービスすべてが対象となります。また、複数回脆弱性診断を実施した場合、最新の診断結果の報告日から1年間有効となります。

    またBBSecでは緊急対応支援サービスも提供しています。突然の大規模攻撃や情報漏えいの懸念等、緊急事態もしくはその可能性が発生した場合は、BBSecにご相談ください。セキュリティのスペシャリストが、御社システムの状況把握、防御、そして事後対策をトータルにサポートさせていただきます。

    ※外部サイトにリンクします。

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

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像

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

    ウェビナーダイジェスト動画

    Share

    アーカイブ動画

    過去ご好評いただいたウェビナーの抜粋動画を無料で公開しています。


    ピックアップ

    ウェビナーダイジェスト版:2026年、企業が直面するサイバー脅威― IPA『情報セキュリティ10大脅威 2026』から考える対応戦略 ―

    2025年

    ウェビナータイトル画面「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜」2025.9.10(水)開催
    フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜
    再生時間:05:01
    ウェビナータイトル画面「進化するランサムウェア攻撃」2025.7.16(水)開催
    進化するランサムウェア攻撃-国内最新事例から学ぶ!被害を防ぐ実践ポイント10項目を解説-
    再生時間:05:00
    ウェビナータイトル画面「ランサムウェア対策の要! ペネトレーションテストとは?」2025.1.22(水)開催
    ランサムウェア対策の要! ペネトレーションテストとは?-ペネトレーションテストの効果、脆弱性診断との違い-
    再生時間:04:55

    2024年

    ウェビナーダイジェスト版:脆弱性診断の新提案!スピード診断と短納期で解決する「SQAT with Swift Delivery」セミナー2024.12.18(水)開催
    脆弱性診断の新提案!スピード診断と短納期で解決する「SQAT® with Swift Delivery」セミナー
    再生時間:05:09
    ウェビナーダイジェスト版:中小企業に迫るランサムウェア!  サプライチェーン攻撃とは- サプライチェーン攻撃から企業を守るための取り組み2024.11.20(水)開催
    中小企業に迫るランサムウェア! サプライチェーン攻撃とは- サプライチェーン攻撃から企業を守るための取り組み
    再生時間:05:11
    2024.11.13(水)開催
    ウェブ担当者必見!プライバシー保護規制対応と情報セキュリティ
    -サイバー攻撃への事前・事後対応-

    再生時間:05:07
    2024.8.7(水)開催
    AWS・Azure・GCPユーザー必見!企業が直面するクラウドセキュリティリスク
    再生時間:05:18
    2024.7.10(水)開催
    ランサムウェアの脅威を知る~脅威に備えるためのランサムウェア対策
    再生時間:05:02
    2024.6.19(水)開催
    サイバー攻撃に備えるために定期的な脆弱性診断の実施を!-ツール診断と手動診断の比較-
    再生時間:05:04
    2024.5.22(水)開催
    対応必須! 情報セキュリティ事故発生時の緊急対応とは
    再生時間:05:09
    2024.4.24(水)開催
    知っておきたいIPA『情報セキュリティ10大脅威 2024』~セキュリティ診断による予防的コントロール~
    再生時間:05:19
    2024.4.17(水)開催
    変化する不確実性の時代における「安心・安全・安定のWebサイト運営」セミナー
    再生時間:03:00

    2023年

    2023.11.15(水)開催
    Webアプリケーションの脆弱性対策-攻撃者はどのように攻撃するのか-
    再生時間:05:42
    2023.10.18(水)開催
    自動車産業・製造業におけるセキュリティ対策のポイント-サプライチェーン攻撃の手口と対策方法-
    再生時間:04:56
    2023.8.9(水)開催
    DevSecOpsを実現!-ソースコード診断によるセキュリティ対策のすすめ-
    再生時間:05:29
    2023.7.20(水)開催
    今さら聞けない!PCI DSSで求められる脆弱性診断あれこれ
    再生時間:05:00
    2023.6.21(水)開催
    今さら聞けない!クラウドセキュリティあれこれ
    再生時間:05:00
    2023.5.17(水)開催
    今さら聞けない!ペネトレーションテストあれこれ
    再生時間:05:20
    2023.4.19(水)開催
    知っておきたいIPA『情報セキュリティ10大脅威 2023』~セキュリティ診断による予防的コントロール~
    再生時間:05:00
    2023.3.15(水)開催
    予防で差がつく!脆弱性診断の話
    再生時間:04:57
    2023.1.27(水)開催
    今さら聞けない!ソースコード診断あれこれ
    再生時間:05:00

    2022年

    2022.6.22(水)開催
    テレワーク運用時代のセキュリティ情報の集め方-セキュリティに求められる情報収集とは-
    再生時間:04:51
    ウェビナーダイジェスト版:企業の対策すべき脆弱性入門2022.4.21(水)開催
    企業の対策すべき脆弱性入門
    再生時間:05:13

    TOP-更新情報に戻る


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

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

    脆弱性診断は受けたけれど ― 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コーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    脆弱性スキャンとは?脆弱性診断ツールの選び方と導入ポイント

    Share

    「脆弱性スキャンとは?脆弱性診断ツールの選び方と導入ポイント」アイキャッチ画像

    脆弱性スキャンは、企業のシステムやネットワーク、Webアプリケーション、クラウド環境に存在する既知の脆弱性を効率よく洗い出すための基本的な手段です。近年は、公開サーバーやVPN機器だけでなく、クラウド上のワークロード、コンテナ、OSSライブラリまで管理対象が広がっており、手作業だけで安全性を確認するのは現実的ではありません。そこで重要になるのが、脆弱性スキャナーや脆弱性診断ツールを使って、環境全体を継続的に確認する考え方です。CISAも、インターネット公開資産に対する継続的な 脆弱性スキャンを、基本的な「サイバーハイジーン(Cyber Hygiene)」の一環として位置付けています。

    ただし、脆弱性スキャンを導入すれば自動的に安全になるわけではありません。スキャンはあくまで既知の弱点を機械的に見つける仕組みであり、誤検知や過検知、設定不備の見落とし、業務影響を踏まえた優先順位判断までは自動では完結しません。そのため実務では、脆弱性スキャンの役割を正しく理解したうえで、脆弱性診断や脆弱性管理のプロセスと組み合わせて運用する必要があります。本記事では、脆弱性スキャンとは何か、脆弱性診断との違い、ツール比較のポイント、導入時の考え方までを整理します。

    脆弱性スキャンとは

    脆弱性スキャンとは、サーバー、ネットワーク機器、Webアプリケーション、クラウド環境などに対して自動的に検査を行い、既知の脆弱性や不適切な設定、不足している更新などを検出する仕組みです。企業が脆弱性スキャンを導入する目的は、攻撃者に悪用される前に自社環境の弱点を見つけ、修正につなげることにあります。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)のCyber Hygiene Servicesでも、Vulnerability Scanning(脆弱性スキャン)はインターネットから到達可能な資産を継続的に監視し脆弱性の有無を評価するサービス、として説明されています。

    脆弱性スキャンの特徴は、自動化にあります。人手では確認しきれない大量のIPアドレス、Webアプリケーション、仮想マシン、コンテナイメージなどを機械的に点検し、既知の脆弱性情報や設定ミスと突き合わせることで、短時間に広い範囲を確認できます。NIST SP 800-115『Technical Guide to Information Security Testing』でも、自動化されたテスト手法は情報セキュリティ評価の重要な手段とされ、SCAPのような標準化された枠組みが脆弱性管理の自動化を支えるものとして紹介されています。

    一方で、脆弱性スキャンには限界もあります。自動スキャンは既知のパターンには強いものの、業務ロジックに起因する脆弱性や、文脈を踏まえた攻撃シナリオまでは把握しきれない場合があります。また、誤検知や重複検知が発生することもあるため、結果をそのまま鵜呑みにするのではなく、影響の確認と優先順位付けが必要です。つまり脆弱性スキャンは、脆弱性管理の入口として非常に有効ですが、それだけで完結するものではありません。

    脆弱性スキャンを適切に実施するためには、対象となるIT資産を正確に把握することが重要です。サーバーやネットワークだけでなく、クラウド環境やOSSコンポーネントも対象となります。IT資産管理と脆弱性管理の関係については、以下の記事も参考になります。
    脆弱性管理とIT資産管理 -サイバー攻撃から組織を守る取り組み-

    脆弱性診断との違い

    脆弱性スキャン脆弱性診断は混同されやすい言葉ですが、実務上は役割が異なります。脆弱性スキャンは、既知の脆弱性や設定不備を自動的に広く洗い出すことに向いています。これに対して脆弱性診断は、専門家が対象システムの構造や挙動を踏まえながら、ツールだけでは見つけにくい問題も含めて詳細に評価する行為です。OWASPでは、ペネトレーションテストやセキュリティテストがスキャン単独よりも実際の攻撃可能性やリスク評価をより正確に把握する助けになる、と説明しています*12

    たとえば、Webアプリケーションに対する自動スキャンでは、SQLインジェクションやクロスサイトスクリプティングの典型的なパターンは検出しやすい一方で、権限管理の不備や業務フロー上のロジック欠陥、複数機能をまたいだ複雑な脆弱性は取り逃がす可能性があります。OWASPのOWASP Web Security Testing Guideでは、Webセキュリティ評価が単なる自動実行ではなく、アプリケーションの設計や攻撃面を踏まえた体系的なテストであることを示しています。

    そのため企業では、脆弱性スキャンと脆弱性診断を対立概念として捉えるよりも、目的に応じて使い分けることが重要です。日常的な広範囲確認には脆弱性スキャンが向いており、公開Webサービスや重要システムの深い評価には脆弱性診断が向いています。脆弱性スキャンは継続運用の基盤、脆弱性診断は重点箇所の深掘りというように整理すると理解しやすいでしょう。

    脆弱性スキャンの種類

    脆弱性スキャンにはいくつかの種類があり、どこを対象にするかで使うツールや評価軸が変わります。

    Webスキャン

    OWASPでは、Webアプリケーション脆弱性スキャンを、外部からWebアプリケーションを自動検査し、XSS、SQLインジェクション、コマンドインジェクション、パストラバーサル、不適切な設定などの脆弱性を探すツール、として説明しています*2。いわゆるDAST(Dynamic Application Security Testing)に近い領域であり、インターネット公開されるサービスでは特に重要です。企業サイト、会員サイト、管理画面、APIなど、公開面があるならWebスキャンは有力な選択肢になります。

    ネットワークスキャン

    サーバー、ルーター、ファイアウォール、VPN装置などに対して、開いているポート、稼働サービス、既知の脆弱性、更新不足の状況を確認するものです。特にインターネットに公開された機器は攻撃対象になりやすいため、CISAも継続的なスキャンの重要性を強調しています。

    クラウドスキャン

    クラウドでは、OSやミドルウェアの脆弱性だけでなく、ストレージの公開設定、IAM権限、コンテナ設定、イメージの更新状況なども安全性に大きく影響します。従来型のネットワークスキャンだけでは十分でなく、CSPMやCNAPP系の機能を持つツールでクラウド設定やワークロードを可視化する必要があります。共有責任モデルのもとでは、クラウド事業者が管理しない部分は利用企業側が継続的に見なければなりません。

    さらに、OSS脆弱性スキャン、いわゆるSCAも見逃せません。現代のソフトウェアは多くのOSSライブラリに依存しており、アプリケーション本体に問題がなくても、依存パッケージの脆弱性がリスクになります。NTIA(米国商務省電気通信情報局:National Telecommunications and Information Administration)が公開している「The Minimum Elements For a Software Bill of Materials (SBOM) 」では、SBOMをソフトウェアを構成する各種コンポーネントとサプライチェーン上の関係を記録する正式な記録、と定義しており、OSS脆弱性管理の前提として極めて重要です。SCAやSBOM対応ツールを使うことで、どのアプリケーションにどの部品が含まれているかを把握しやすくなります。

    脆弱性スキャナーの比較

    脆弱性スキャナーを比較するとき、まず見るべきなのはCVE対応の範囲です。脆弱性スキャンの基本は、既知の脆弱性データと自社環境を突き合わせることにあるため、どの程度広くCVE情報やベンダー情報に対応しているかは重要です。とはいえ、単に「CVEに対応している」と書かれているだけでは不十分で、更新頻度、対応製品の広さ、クラウドやコンテナへの追従性まで見たほうが実務では役立ちます。CISAが示す脆弱性管理の考え方*3でも、継続的に変化する資産や脅威を前提にした運用が重視されています。

    次に確認したいのがスキャン精度です。脆弱性スキャナーは便利ですが、誤検知が多すぎると運用部門が疲弊し、逆に本当に重要な項目を見逃しやすくなります。逆に、検知が甘ければ見つかるべき脆弱性を取り逃がすことになります。ツールの比較では、単なる検知件数ではなく、結果がどれだけ実務で使いやすいか、重複排除や重要度の絞り込みがしやすいかも見ておく必要があります。OWASPが指摘するようにスキャン結果だけでは実際の攻撃可能性を完全に評価できない*4ため結果の解釈しやすさも重要です。

    さらに、OSSライブラリ検出やSBOM生成の可否は、近年ますます重要になっています。SCAに対応していないツールでは、アプリケーション内部の依存関係まで把握できず、ソフトウェアサプライチェーンリスクへの対応が難しくなります。SBOMを生成・管理できるかどうかは、脆弱性スキャンの範囲をインフラからソフトウェア部品まで広げられるかどうかに直結します。NTIAはSBOMが脆弱性管理、ソフトウェア在庫管理、ライセンス管理などの基本ユースケースに役立つとしています。

    脆弱性スキャン導入のポイント

    脆弱性スキャンを導入する際に考えるべきポイントは以下のとおりです。

    導入目的の明確化

    公開Webサイトの安全性を高めたいのか、社内サーバーの更新漏れを防ぎたいのか、クラウド設定不備を見つけたいのか、OSS脆弱性を把握したいのかで、適したツールは変わります。目的が曖昧なまま「有名だから」という理由だけで導入すると、期待した検知ができなかったり、運用負荷だけが増えたりします。

    導入後の運用体制の整備

    脆弱性スキャンは、導入しただけでは意味がなく、誰が結果を確認し、どこまで精査し、どの基準で是正依頼を出し、修正後にどう再確認するかまで決めておく必要があります。NISTのパッチ・脆弱性管理ガイドでも、技術そのものより、継続運用のプロセス設計が重要であることが示されています。ツール導入はゴールではなく、脆弱性管理のサイクルを回すための手段です。

    資産管理との連携

    スキャン結果を脆弱性対応に直結させるためには、資産管理との連携も欠かせません。どのサーバーがどの業務に使われているのか、どのシステムが外部公開されているのか、どのアプリケーションがどのOSS部品を利用しているのかが分からなければ、検出された脆弱性の優先順位を決められません。特にクラウドやコンテナ環境では、資産の増減が激しいため、台帳やCMDB、クラウド資産可視化と組み合わせた運用が重要です。

    脆弱性診断・ペネトレーションテストとの併用

    脆弱性スキャンは広く速く確認するのに強い一方で、業務ロジックや複雑な攻撃経路までは十分に評価できないことがあります。公開サービスや重要システムでは、重点的な診断を組み合わせるほうが現実的です。OWASPも、ペネトレーションテストがスキャンだけでは見えない実攻撃視点の評価に役立つと説明しています。

    脆弱性スキャンで脆弱性を発見した後は、迅速に対応を行うことが重要です。適切な優先順位付けやパッチ適用を行わなければ、攻撃リスクを低減することはできません。脆弱性対応の具体的な手順については、以下の記事で詳しく解説しています。
    脆弱性対応とは?CVE対応とパッチ管理の実務フロー

    脆弱性管理との関係

    脆弱性スキャンは、脆弱性管理そのものではありませんが、脆弱性管理を支える重要な要素です。脆弱性管理は、資産把握、脆弱性情報収集、評価、是正、再確認を継続的に回す運用全体を指します。その中で脆弱性スキャンは、「発見」と「継続的な監視」を支える手段として機能します。CISAが脆弱性管理を、脆弱性や悪用可能な状態の頻度と影響を減らす取り組みとして整理している*5ことからも、スキャン単独ではなく運用全体の中で捉えるべきことが分かります。

    脆弱性スキャンは、脆弱性管理の一部として実施される重要なプロセスです。しかし、スキャンを実施するだけでは不十分であり、発見した脆弱性を評価・対応まで含めて継続的に管理する必要があります。企業の脆弱性管理全体の流れについては、以下の記事で詳しく解説しています。
    脆弱性管理とは?企業が行うべき脆弱性管理の基本と実践手順【2026年版】

    実務では、脆弱性スキャンで見つけた結果をそのまま並べるだけでは意味がありません。資産の重要度、公開状態、CVSS、既知悪用の有無、業務影響などを踏まえて優先順位を決め、必要な修正や診断につなげていく必要があります。さらに、OSS脆弱性についてはSCAやSBOMを組み合わせて調査範囲を広げることが重要です。つまり脆弱性スキャンは、脆弱性管理の入口であり、全体運用へつなぐための観測手段だといえます。

    まとめ

    脆弱性スキャンとは、既知の脆弱性や設定不備を自動的に洗い出し、企業の攻撃面を継続的に可視化するための基本手段です。ネットワークスキャン、Webスキャン、クラウド環境スキャン、OSS脆弱性スキャンといった種類があり、企業のシステム構成に応じて適切に選ぶ必要があります。ただし、脆弱性スキャンは万能ではなく、脆弱性診断やペネトレーションテストのような深い評価とは役割が異なります。広く見つけるのがスキャン、深く確かめるのが診断、と整理すると理解しやすいです。

    導入時に重要なのは、ツールの知名度ではなく、自社の目的に合っているかどうかです。CVE対応の広さ、スキャン精度、クラウド対応、OSSライブラリ検出、SBOM生成の可否などを見極めたうえで、導入後に誰がどのように結果を処理するかまで設計しておく必要があります。脆弱性スキャンを単独の製品選定で終わらせず、脆弱性管理の継続運用へつなげることが、企業にとって本当の導入効果につながります。

    【参考情報】


    【関連ウェビナーのご案内】
    本記事では、脆弱性スキャンとは何か、脆弱性診断との違い、ツール比較のポイント、導入時の考え方までを整理しました。次回、5月20日(水)14時からの開催のウェビナーでは、AssetViewFutureVulsのメーカーが登壇し、各領域の役割をどのように整理し、どのように連携させれば実効性ある脆弱性管理が実現できるのか、解説します。脆弱性管理の考え方について深くを理解されたい方は、ぜひご参加ください。

    その他のウェビナー開催情報はこちら


    BBSecでは

    BBSecでは以下のようなご支援が可能です。 お客様のご状況に合わせて最適なご提案をいたします。

    SQAT®脆弱性診断サービス

    サイバー攻撃に対する備えとして、BBSecが提供する、SQAT脆弱性診断サービスでは、攻撃者の侵入を許す脆弱性の存在が見逃されていないかどうかを定期的に確認することができます。自組織の状態を知り、適切な脆弱性対策をすることが重要です。

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

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

    編集責任:木下

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


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

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


    Security Serviceへのリンクバナー画像

    BBSecコーポレートサイトへのリンクバナー画像

    セキュリティ緊急対応のバナー画像

    ウェビナーアーカイブ動画ページバナー画像

    脆弱性管理とは?企業が行うべき脆弱性管理の基本と実践手順【2026年版】

    Share
    「脆弱性管理とは?企業が行うべき脆弱性管理の基本と実践手順」アイキャッチ画像

    企業のIT環境は、もはや社内サーバーやネットワーク機器だけで完結しません。業務システムはクラウドへ移行し、開発現場ではOSSの利用が当たり前になり、SaaSやコンテナ、API連携を含めた複雑な構成が一般化しています。こうした環境では、ひとつの脆弱性が単独の問題にとどまらず、情報漏えい、業務停止、サプライチェーン全体への影響へとつながることがあります。だからこそ今、多くの企業にとって重要になっているのが「脆弱性管理」です。

    脆弱性管理とは、脆弱性を見つけることそのものではありません。自社にどの資産があり、どこに弱点があり、それがどの程度危険で、いつまでに何を直すべきかを継続的に判断し、実際に改善し続ける運用を指します。本記事では、脆弱性管理の基本から、企業が実務で押さえるべき流れ、ツールの考え方、クラウドやOSS時代に欠かせないSBOMの活用まで、2026年時点の実務に沿って整理します。

    脆弱性管理とは

    脆弱性管理とは、システムやソフトウェア、クラウド環境、ネットワーク機器などに存在するセキュリティ上の弱点を継続的に把握し、評価し、修正し、再確認する一連の運用です。単発の診断や一度きりの点検ではなく、変化し続けるIT環境に合わせて回し続けることに意味があります。CISAも、脆弱性管理を「脆弱性や悪用可能な状態の発生頻度と影響を減らす取り組み」と位置づけています。

    脆弱性管理では、日々公開される脆弱性情報を継続的に確認することが重要です。多くの脆弱性は CVE(Common Vulnerabilities and Exposures) という識別番号で管理されています。CVEの仕組みについては、以下の記事で詳しく解説しています。
    CVEとは?脆弱性情報の共通識別番号を解説

    CVEは、公開されたサイバーセキュリティ上の脆弱性を識別し、共通の参照先として扱うための仕組みです。一方、NVDはそのCVE情報に対してCVSSなどの評価情報や関連データを付与し、脆弱性管理の自動化や優先順位付けに役立つデータベースとして機能しています。つまり実務では、「CVEで対象を識別し、NVDやベンダー情報で内容と深刻度を確認する」という流れが基本になります。

    現在の企業システムは、オンプレミス環境だけでなく、AWS・Azure・Google Cloud などのクラウド環境やSaaSサービスを組み合わせて構築されるケースが増えています。そのため、脆弱性管理はサーバーやネットワークだけでなく、クラウド環境やソフトウェアコンポーネントも含めて実施する必要があります。クラウドでは、基盤の一部は事業者が管理していても、設定、アクセス権、ゲストOS、コンテナイメージ、アプリケーションなどは利用企業側の責任範囲に残るためです。AWS、Microsoft、Google Cloudはいずれも共有責任モデルを明示しており、利用者側の継続的な管理を前提にしています。

    なぜ企業に脆弱性管理が必要なのか

    企業に脆弱性管理が必要な最大の理由は、脆弱性が「見つかっただけの情報」ではなく、「実際に悪用される入口」になっているからです。公開された脆弱性のすべてが直ちに攻撃に使われるわけではありませんが、CISAは実際に悪用が確認された脆弱性を Known Exploited Vulnerabilities(KEV) Catalog として公開し、組織に優先対応を促しています。つまり現代の脆弱性管理では、公開情報を眺めるだけでなく、「いま悪用されているか」「自社に影響するか」を見極めることが重要です。

    脆弱性を放置するリスクも明確です。攻撃者は、修正が遅れたVPN機器、公開サーバー、業務アプリケーション、ミドルウェア、コンテナ環境などを足がかりに侵入し、そこから権限昇格や横展開を進めます。問題は、重大な脆弱性があっても、自社資産を把握できていなければ「影響を受けているのに気づけない」ことです。脆弱性管理は、修正作業の前段として、自社に何が存在しているかを見える化する意味でも不可欠です。

    さらに、近年はOSS利用の拡大によって、ソフトウェアサプライチェーン全体のリスク管理が重要になっています。NTIAはSBOMを、ソフトウェアを構成する各種コンポーネントとそのサプライチェーン上の関係を記録する正式な記録と説明しています。OSSライブラリや依存パッケージに脆弱性が含まれていた場合、アプリケーション本体に問題がなくても、企業システム全体に影響が及ぶ可能性があります。これが、いわゆるソフトウェアサプライチェーンリスクです。

    クラウド利用の拡大も、脆弱性管理の必要性をさらに高めています。クラウド環境では、サーバーを一度構築して終わりではなく、構成変更、イメージ更新、コンテナ再配備、アクセス制御変更などが高頻度で発生します。そのため、脆弱性管理を継続的に実施しなければ、未更新のソフトウェアや脆弱なイメージ、設定不備がそのまま攻撃対象になる可能性があります。共有責任モデルのもとでは、クラウド事業者がすべてを守ってくれるわけではありません。自社が責任を持つ範囲を理解し、そこを継続的に点検する必要があります。

    脆弱性管理の基本プロセス

    脆弱性管理の基本プロセスは、一般に以下のような流れです。

    • 脆弱性の発見
    • 脆弱性評価
    • 修正
    • 検証

    ただし実務では、前提としてソフトウェア資産の把握が欠かせません。なぜなら、何を保有しているか分からない状態では、脆弱性情報を受け取っても影響判断ができないからです。NVDのような脆弱性データベースは、脆弱性管理の自動化や評価に使える標準化データを提供していますが、それを生かすには自社資産との突合が必要です。

    脆弱性の発見は、公開情報の確認だけでなく、スキャンツール、構成管理情報、ベンダーアドバイザリ、クラウドのセキュリティ機能など、複数の情報源を組み合わせて行います。次に必要になるのが評価です。ここではCVSSのような一般的な深刻度だけでなく、インターネット公開の有無、業務影響、悪用実績、代替策の有無、修正難易度などを踏まえて、自社にとっての優先度を決める必要があります。NVDも、CVSSは深刻度の定性的な指標であり、リスクそのものではないと明示しています。

    その後、実際に修正を行います。修正方法は、パッチ適用、設定変更、バージョンアップ、アクセス制御の見直し、機能停止、ネットワーク遮断などさまざまです。最後に、修正後の検証を実施し、本当に脆弱性が解消されたか、別の不具合を生んでいないかを確認します。この「修正して終わりにしない」ことが、脆弱性管理を単なる作業ではなく運用として成立させるポイントです。脆弱性管理では、まず自社のIT資産を正確に把握することが重要です。対象にはサーバーやネットワークだけでなく、クラウド環境、利用しているOSSライブラリなども含まれます。

    IT資産管理と脆弱性管理の関係については、以下の記事で詳しく解説しています。
    脆弱性管理とIT資産管理とは?サイバー攻撃から組織を守る取り組み

    近年では SBOM(Software Bill of Materials) を利用してソフトウェア構成を可視化する企業も増えています。SBOMは、ソフトウェアに何の部品が含まれているかを一覧化する考え方で、影響範囲の特定や依存関係の把握に有効です。
    SBOMとは?ソフトウェア部品表の基本と企業が導入すべき理由

    脆弱性管理のフロー(実務)

    実務に落とし込むと、脆弱性管理の流れは以下のような順番で整理することができます。

    1. 脆弱性情報の収集
    2. クラウド・OSSへの影響確認
    3. 優先度判断
    4. 修正
    5. 再確認

    まず行うべきは、CVE、ベンダーアドバイザリ、クラウドベンダー通知、各種セキュリティ情報の収集です。ここで漏れがあると、そもそも対応のスタート地点に立てません。CISAは、実際に悪用が確認された脆弱性についてKEV Catalogの確認と優先的な是正を強く推奨しています。

    次に必要なのが、収集した情報が自社環境に関係するかどうかの確認です。オンプレミス機器だけなら比較的見通しが立ちますが、現在はクラウド上のワークロード、コンテナ、OSSライブラリ、CI/CDで取り込んだ部品まで視野に入れなければ、実態を取り逃がします。とくにOSS脆弱性は、アプリケーション本体よりも深い依存関係に潜んでいる場合があり、SBOMやSCAの仕組みがないと把握が難しくなります。

    優先度判断では、CVSSの高さだけで対応順を決めないことが重要です。CVSSは比較の基準になりますが、公開サーバーにあるのか、認証が必要なのか、すでに悪用実績があるのか、業務停止時の影響はどれほどかによって、実際の対応順は変わります。NVDもCVSSをリスクそのものではないと説明しており、KEVのような実悪用情報と組み合わせて判断するのが現実的です。

    修正段階では、パッチ適用だけに視野を限定しないことが大切です。クラウド環境では、OSやミドルウェアの更新に加え、コンテナイメージの差し替え、設定変更、公開範囲の見直し、権限調整なども重要な対策になります。修正後は再スキャンや設定確認を行い、実際に解消されたことを確認します。ここで検証が不十分だと、「対応したつもり」で終わってしまい、後になって再発見されることがあります。

    脆弱性管理では、脆弱性を発見するだけでなく、発見された脆弱性に対して迅速に対応することが重要です。適切な脆弱性対応を行わなければ、攻撃者に悪用され、情報漏えいやシステム停止などの重大なインシデントにつながる可能性があります。脆弱性対応の基本的な流れや実務での対応方法については、以下の記事で詳しく解説しています。
    脆弱性対応とは?CVE対応とパッチ管理の実務フロ

    近年ではクラウド環境やOSSライブラリに含まれる脆弱性の影響調査も重要になっています。SBOMを利用すると、影響範囲を迅速に把握できます。

    脆弱性管理ツールの種類

    脆弱性管理を実務で回すには、ツールの力を借りることが現実的です。ただし、ひとつの製品で全領域を完全にカバーできるとは限りません。一般的な脆弱性スキャナーは、ネットワーク機器、サーバー、OS、ミドルウェア、Webアプリケーションの既知脆弱性を見つけるのに有効ですが、OSSライブラリの依存関係やソフトウェア部品表までは十分に扱えないことがあります。そこで、管理ツール、クラウドセキュリティツール、SBOM管理ツール、SCAツールなどを役割ごとに組み合わせる設計が必要になります。

    たとえば、CSPMやCNAPPのようなクラウド向けツールは、クラウド設定やワークロードの状態を継続的に可視化するのに向いています。一方、SCAはアプリケーションが依存しているOSSコンポーネントを洗い出し、既知脆弱性との突合を支援します。SBOM管理ツールは、その構成情報を継続管理し、影響調査を効率化する役割を持ちます。2026年の脆弱性管理では、ネットワークやサーバーだけを見ていても不十分で、クラウドとソフトウェアサプライチェーンまで含めた多層的な可視化が必要です。

    OSSの脆弱性を管理するために、SCA(Software Composition Analysis)ツールやSBOM管理ツールを導入する企業も増えています。これは、ソフトウェアの構成部品とその依存関係を可視化しなければ、OSS由来の脆弱性が自社に影響するかどうかを迅速に判断しにくいためです。NTIAも、SBOMをソフトウェア構成要素の透明性向上に役立つ仕組みとして整理しています。

    SCA(Software Composition Analysis)ツールとは
    ソフトウェアに含まれるオープンソースや外部ライブラリの構成要素を解析し、既知の脆弱性やライセンスリスクを可視化するセキュリティツールです。依存関係を自動的に検出し、CVEなどの脆弱性データベースと照合することで、潜在的なリスクを早期に特定できます。また、ライセンス違反の有無も確認でき、コンプライアンス対応にも有効です。開発プロセスに組み込むことで、セキュアで安全なソフトウェア開発を支援します。

    脆弱性スキャンについてはこちらの記事でも詳しく解説しています。
    脆弱性スキャンとは?脆弱性診断ツールの選び方と導入ポイント

    企業の脆弱性管理の課題

    多くの企業が脆弱性管理に苦労する理由は、脆弱性そのものより、管理対象の広がりにあります。

    IT資産の把握

    まず大きいのが、IT資産の把握が難しいことです。クラウド移行、テレワーク、SaaS利用、部門独自導入のツール、コンテナ活用が進むと、情報システム部門が把握していない資産が生まれやすくなります。この状態では、脆弱性情報を受け取っても、自社への影響有無を正確に判断できません。

    OSS依存関係の管理

    現代のソフトウェアは、直接導入しているライブラリだけでなく、その下位の依存関係にも数多くの部品を抱えています。表面的には安全に見えても、深い階層に脆弱なコンポーネントが含まれていることは珍しくありません。

    SBOMの未整備

    SBOMが未整備だと、こうした影響範囲調査に時間がかかり、対応の遅れにつながります。

    クラウド環境の可視化不足

    クラウドでは、責任分界が従来のオンプレミスとは異なり、サービス形態によって利用者側の責任範囲が変わります。そのため、「クラウド事業者が面倒を見ているはず」と誤解してしまうと、更新漏れや設定不備を放置しやすくなります。共有責任モデルを前提に、自社の管理範囲を明確にしなければ、脆弱性管理は形骸化します。

    OSS利用時に重要な脆弱性管理(SBOMの活用)

    OSSの活用は、開発効率や品質向上の面で大きなメリットがありますが、その一方で脆弱性管理を複雑にします。理由は明快で、企業が自分で一から書いていないコードであっても、最終的に自社サービスや製品の一部として責任を負うからです。OSS由来の脆弱性は、アプリケーション本体ではなく依存パッケージに潜んでいることも多く、目視や台帳だけで追いきるのは現実的ではありません。

    ここで重要になるのがSBOMです。NTIAはSBOMを、ソフトウェアを構成する各種コンポーネントとサプライチェーン上の関係を記録する正式な記録と定義しています。これを整備しておけば、新たな脆弱性が公表された際に、「自社のどのシステムに、その部品が含まれているか」を調べやすくなります。結果として、影響調査の初動が速くなり、不要な全件調査や属人的な確認作業を減らせます。

    SBOMは、単に監査対応のために作る資料ではありません。脆弱性管理の実務で使えてこそ意味があります。たとえば、SCAツールで依存関係を検出し、その情報をSBOMとして管理し、脆弱性公表時に突合するという流れが定着すれば、OSS脆弱性への対応速度と精度を高めやすくなります。今後の企業システムでは、OSS利用時の脆弱性管理をSBOM抜きで考えることは難しくなっていくでしょう。

    脆弱性管理を効率化する方法

    脆弱性管理を効率化する方法はいくつかあります。

    資産管理の自動化

    資産台帳を手作業で維持する運用では、クラウドやコンテナ、SaaSの増減に追いつけません。CMDB、クラウド資産可視化、ID管理、EDRやMDMの情報などを組み合わせて、現時点の資産情報を継続的に更新できる状態を目指す必要があります。資産情報が整えば、脆弱性情報との突合精度も上がります。

    OSS脆弱性監視

    OSS脆弱性監視の仕組みを作ることも重要です。開発時点だけでなく、運用中のアプリケーションについても、依存ライブラリの脆弱性を継続監視しなければなりません。脆弱性管理をインフラ部門だけの仕事にせず、開発部門やDevOps運用の中に組み込むことが、今の実務では不可欠です。

    SBOMによるソフトウェア構成管理

    SBOMによるソフトウェア構成管理を取り入れることで、影響調査の速度と精度をさらに高められます。SBOMが整っていれば、新たなCVEが公表された際にも、対象ソフトウェアの所在確認を短時間で進めやすくなります。加えて、KEVのような実悪用情報を監視し、CVSSだけでなく悪用実績も含めて優先順位を決める運用にすれば、限られた人員でも効果的に対応しやすくなります。脆弱性管理を効率化するとは、単にツールを増やすことではなく、「見つける」「判断する」「直す」を早く回せる仕組みへ変えることです。

    まとめ

    脆弱性管理とは、脆弱性を発見する作業ではなく、自社のIT資産、クラウド環境、OSSコンポーネントを継続的に把握し、影響を判断し、優先順位をつけて修正し、再確認する運用そのものです。2026年の企業環境では、オンプレミスだけを見ていては不十分で、クラウド、SaaS、コンテナ、OSSまで含めた視点が欠かせません。とくに、実際に悪用される脆弱性への対応と、SBOMを活用したソフトウェア構成の可視化は、これからの脆弱性管理の重要な柱になります。

    まず取り組むべきなのは、完璧な仕組みを一気に作ることではなく、自社の資産を洗い出し、脆弱性情報を収集し、優先度を判断し、修正後に確認するという基本サイクルを止めずに回すことです。そのうえで、クラウド可視化、SCA、SBOM管理などを段階的に取り入れていけば、脆弱性管理は現場で機能する実践的な仕組みに育っていきます。


    【関連ウェビナーのご案内】
    本記事では、脆弱性スキャンとは何か、脆弱性診断との違い、ツール比較のポイント、導入時の考え方までを整理しました。次回、5月20日(水)14時からの開催のウェビナーでは、AssetViewFutureVulsのメーカーが登壇し、各領域の役割をどのように整理し、どのように連携させれば実効性ある脆弱性管理が実現できるのか、解説します。脆弱性管理の考え方について深くを理解されたい方は、ぜひご参加ください。

    その他のウェビナー開催情報はこちら


    BBSecでは

    BBSecでは以下のようなご支援が可能です。 お客様のご状況に合わせて最適なご提案をいたします。

    SQAT®脆弱性診断サービス

    サイバー攻撃に対する備えとして、BBSecが提供する、SQAT脆弱性診断サービスでは、攻撃者の侵入を許す脆弱性の存在が見逃されていないかどうかを定期的に確認することができます。自組織の状態を知り、適切な脆弱性対策をすることが重要です。

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

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

    編集責任:木下

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


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

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


    Security Serviceへのリンクバナー画像
    BBSecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    ウェビナーアーカイブ動画ページバナー画像

    サービスデモ動画

    Share

    サービス紹介デモ動画

    BBSecで提供しているサービスをご紹介するデモ動画を公開しています。



    デイリー自動脆弱性診断サムネ

    デイリー自動脆弱性診断-Cracker Probing-Eyes®-
    再生時間:02:58
    関連情報:デイリー自動脆弱性診断-Cracker Probing-Eyes®

    【資料ダウンロード】


    クロスサイトスクリプティング攻撃デモンストレーションサムネ

    クロスサイトスクリプティング攻撃デモンストレーション
    再生時間:03:12

    【資料ダウンロード】


    ランサムウェア感染リスク可視化サービスサムネ

    ランサムウェア感染リスク可視化サービス
    再生時間:05:46
    関連情報:ランサムウェア対策総点検

    TOP-更新情報に戻る


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

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

    OWASP Top 10 2025:OWASP Top 10 2021からの変更点と企業が取るべきセキュリティ強化ポイント

    Share

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

    OWASP Top 10 2025:OWASP Top 10 2021からの変更点と企業が取るべきセキュリティ強化ポイントアイキャッチ画像

    OWASP Top 10はWebアプリケーションの主要なセキュリティリスクをまとめた世界的な基準です。2025年版では、ソフトウェアサプライチェーンに起因する問題や例外処理の不備など、新たなリスク項目が追加され、順位も変動しています。本記事ではこれらの新しい動向も踏まえ、各項目を平易に解説し、企業が取るべきセキュリティ対策の方向性を提示します。

    はじめに

    2025年11月、国際的なセキュリティ啓発コミュニティであるOWASP(オワスプ:Open Web Application Security Project)から、「OWASP Top 10 2025」が公開されました。前回の「OWASP Top 10 2021」より4年ぶりの公開となります。本記事ではOWASP Top 10 2025から追加された新たなリスク項目や順位変動を踏まえ、企業が取るべきセキュリティ対策の方向性を提示します。

    OWASP Top 10とは

    Webアプリケーションの代表的なセキュリティリスクをまとめた国際的なガイドラインで、意識向上を目的とする啓発資料です。全てのセキュリティ要件を網羅する標準というより、優先的な対策項目を示すリストと考えます。

    OWASP Top10は、Webアプリケーションに存在する代表的な脆弱性をまとめた指標です。脆弱性とは、システムやソフトウェアに存在するセキュリティ上の弱点のことを指します。
    → 「脆弱性の意味を正しく理解する―読み方・具体例・種類をわかりやすく解説

    OWASP Top 10 2025の特徴

    今回の「OWASP Top 10 2025」では、ソフトウェア開発の全工程にわたる新しいリスクが反映されました。特に、依存ライブラリやCI/CD環境を含む「ソフトウェアサプライチェーンの不備」や、「例外処理(エラー処理)の不備」という2つの新カテゴリが追加されています。これにより、従来のコード脆弱性に加え、開発・運用プロセス全体に起因するリスクが明確に強調されました。

    また、2021年版まで独立項目だった「サーバーサイドリクエストフォージェリ(SSRF)」はA01(アクセス制御)に統合され、権限回避系の攻撃に含まれるようになっています。

    OWASP Top 10の概要、「OWASP Top 10 2021」のリスク項目一覧について、以下の記事で解説しています。あわせてぜひご覧ください。
    OWASP Top 10―世界が注目するWebアプリケーションの重大リスクを知る―

    OWASP Top 10 2021からの主な変更点

    A01: アクセス制御の不備 (Broken Access Control)

    引き続き1位です。従来のアクセス制御不備に加え、サーバーサイドリクエストフォージェリ(SSRF)攻撃がこのカテゴリに含まれるようになりました。

    A02: セキュリティ設定のミス (Security Misconfiguration)

    2021年5位から2025年2位に上昇しました。サーバやアプリの初期設定ミスや不要なサービス公開など、設定不備のリスクが増加しています。

    A03: ソフトウェアサプライチェーンの不備 (Software Supply Chain Failures)

    2021年版のA06「脆弱で古くなったコンポーネント」から大幅に拡張され、2025年版に新設されたカテゴリです。依存パッケージやビルド環境への攻撃を含み、開発~配布の全過程におけるマルウェア侵入のリスクを扱います。

    A04: 暗号化の失敗 (Cryptographic Failures)

    前回2位から今回は4位に下降しました。古い暗号方式や不適切な暗号設定によって、機密データ漏洩のリスクが引き続き高い項目です。

    A05: インジェクション (Injection)

    前回3位から5位に下降しました。依然として多く検出されるリスクですが、他カテゴリの変動により相対的に順位が変わりました。

    A06: セキュアでない設計 (Insecure Design)

    2021年に新設された項目で、前回4位から6位になりました。設計段階でセキュリティを考慮しないことによるリスクを指し、脅威モデル不足などが該当します。最近は設計レビューや脅威モデルの導入が増えつつあります。

    OWASP Top 10 2021およびセキュアなWebアプリケーション開発にむけてどのように取り組むべきかについて、以下の記事で解説しています。あわせてぜひご覧ください。
    Webアプリケーション開発プロセスをセキュアに ―DevSecOps実現のポイント―

    A07: 認証の失敗 (Authentication Failures)

    名称が「識別と認証の不備」から若干変更され、順位は7位で維持されました。ログイン機能やパスワード管理の不備などが含まれ、標準的な認証フレームワークの利用増加でやや改善傾向にあります。

    A08: ソフトウェアとデータの整合性の不備(Software or Data Integrity Failures)

    前回同様8位です。ソフトウェア更新時やデータ伝送時の改ざん検知の欠如を扱い、サプライチェーンより下層でのデータ改ざんリスクが対象です。

    A09: ログ監視・アラートの不備 (Logging & Alerting Failures)

    同じく9位を維持しました。ログ監視や侵入検知の仕組みが不十分で、攻撃検知が遅れるリスクを指します。名称も「セキュリティログとモニタリングの不備」から変更されています。

    A10: 例外処理の不備 (Mishandling of Exceptional Conditions)

    2025年に新設された新しいカテゴリです。エラー発生時の不適切な処理(例:内部情報露出やセーフティネットの欠如)により、システム全体の安全性が損なわれるリスクを扱います。

    OWASP Top 10 2025のリスク項目詳細解説

    A01: アクセス制御の不備 (Broken Access Control)

    攻撃者が本来許可されていない操作やデータにアクセスできる脆弱性です。例として、URLやパラメータを操作して他ユーザーの情報を取得したり、管理者権限を取得したりする攻撃が挙げられます。

    A02: セキュリティ設定のミス (Security Misconfiguration)

    システムやアプリの初期設定・構成に誤りがある状態です。脆弱なデフォルト設定や、不要なサービスの有効化、パッチ未適用のサーバ起動などにより、本来防げる攻撃を許してしまいます。

    A03: ソフトウェアサプライチェーンの不備 (Software Supply Chain Failures)

    外部ライブラリやパッケージ管理システムが攻撃され、正規ソフトウェアにマルウェアが混入するリスクです。開発者の環境やCI/CDパイプラインを介して侵入するため、従来型のコード診断だけでは検知しづらい問題となっています。

    A04: 暗号化の失敗 (Cryptographic Failures)

    古い暗号方式や誤った暗号設定によって、暗号化すべきデータの機密性が損なわれるリスクです。例えば、弱い鍵長の使用や最新プロトコルの不採用により、攻撃者に通信内容を解読される危険があります。

    A05: インジェクション (Injection)

    ユーザ入力を十分に検証せずにSQL文やOSコマンド等に含めて実行することで、不正なコードが実行される脆弱性です。SQLインジェクションクロスサイトスクリプティング(XSS)などが代表例で、攻撃者がデータベース改ざんやセッションハイジャックを実行します。

    A06: セキュアでない設計 (Insecure Design)

    設計段階でセキュリティが考慮されておらず、必要な防御策(脅威モデルやセキュアアーキテクチャ)が欠落しているリスクです。実装以前の段階で脆弱性を取り除かないと、後工程では完全対応できない欠陥を内包します。

    A07: 認証の失敗 (Authentication Failures)

    ログインやセッション管理に欠陥があり、不正ログインを許してしまう脆弱性です。例えば、パスワードポリシー不備やセッションIDの固定化、二要素認証不備などにより、攻撃者が他人の権限を奪取する可能性があります。

    A08: ソフトウェアとデータの整合性の不備(Software or Data Integrity Failures)

    ソフトウェア更新やデータ取得時に改ざんを検知できない状態で、不正なコードやデータが実行されてしまうリスクです。例えば、更新ファイルやコンテナイメージが攻撃者によって差し替えられても気づかない場合が該当します。

    A09: ログ監視・アラートの不備 (Logging & Alerting Failures)

    インシデント発生時に監査ログが残らない、またはアラートが機能しない状態で、攻撃を見逃してしまうリスクです。攻撃検知や対策対応が遅れるため、被害が拡大する可能性があります。

    A10: 例外処理の不備 (Mishandling of Exceptional Conditions)

    エラー・例外発生時に適切な対処がされず、システムが想定外の動作をしたり機密情報を漏洩したりする脆弱性です。具体例として、エラーメッセージで内部情報を出力するものや、例外処理のループ抜けでシステム停止しないなどがあります。

    OWASP Top 10 2025で注目すべきポイント

    • サプライチェーンリスクの急浮上
    • 例外処理カテゴリの新設が示す業界動向
    • コード脆弱性から“開発プロセスの安全性”への時代変化

    OWASP Top 10 2025は、従来の入力検証など個別コード脆弱性に加え、サプライチェーンや設計、例外処理といったシステム全体に関わる根本原因を重視しています。企業はこれを踏まえ、開発プロセスや設計段階からの脆弱性予防策を強化する必要があります。

    企業が取るべき対応(例)

    • 開発プロセス全体のセキュリティレビュー
    • サプライチェーン管理の強化
    • 設計段階のセキュリティ確保(脅威モデリング等)
    • ログ・アラート体制の見直し

    情報システム部門やセキュリティ担当者は、今回のリスク項目をセキュリティ教育・セキュリティ診断・セキュリティ監査項目に組み込み、継続的な対策に活用しましょう。特にサプライチェーンや例外処理の項目は従来対応が十分でないことも多く、注力すべきポイントです。

    まとめ

    OWASPはTop 10に加え、SAMMやASVSなどのフレームワーク活用も推奨しています。OWASP Top 10は優先対策項目の一助と位置付け、組織全体のセキュリティ成熟度を高める施策を並行して検討することが望まれます。

    脆弱性診断の活用

    では、意図せず作りこまれてしまう脆弱性に、どう対処すればいいでしょうか。それには脆弱性診断を実施することが、最も有効な手段の一つと言えます。

    脆弱性診断によって、システムにどのような脆弱性があり、どの程度のリスクがあるのか可視化され、その優先度に応じてセキュリティ対策を検討・実施することができます。

    脆弱性診断を効果的に活用するには、システムの機能や取り扱う情報の重要度に応じて、実施時期や頻度を考慮することも大切です。セキュリティ事情は常に変化しています。日々新たな脆弱性が発見され、サイバー攻撃も巧妙化する一方です。また、何年も前に報告されたのに放置されがちな脆弱性が、改めて悪用されることもあります。健康診断と同様、脆弱性診断も定期的に実施することが重要なのです。

    また、「SQAT® Security Report」では、セキュリティ事情に関するトピックをお伝えしております。情報収集の一助としてご活用ください。

    【参考情報】

    OWASP Top 10 2025リリースノート/Aikidoブログ(https://www.aikido.dev/blog/owasp-top-10-2025-changes-for-developers#:~:text=OWASP%20emphasizes%20that%20the%20Top,Application%20Security%20Verification%20Standard


    BBSecの脆弱性診断サービス

    弊社では、お客様のニーズに合わせて、様々な脆弱性診断サービスを提供しております。システムの特徴やご事情に応じてどのような診断を行うのが適切かお悩みの場合も、ぜひお気軽にご相談ください。

    「毎日/週など短いスパンで定期診断して即時に結果を知りたい」

    デイリー自動脆弱性診断「Cracker Probing-Eyes®」は、脆弱性の検出結果を、お客様側での簡単な操作で、日々確認できます。導入のための設備投資が不要で、コストを抑えつつ手軽に診断できます。 世界的なセキュリティ基準をベースにした弊社独自基準を設け、シグネチャの見直しも弊社エンジニアが定期的に行うことで、信頼性の高い診断を実現しております。

    「システム特性に応じた高精度な診断をしたい」

    対象システムの機能が複雑である、特にミッションクリティカルであるなどの理由により、広範囲かつより網羅性の高い診断をご希望の場合は、弊社エンジニアが手動で実施する「SQAT®脆弱性診断サービス」をおすすめします。

    Webアプリケーション、ネットワークはもちろんのこと、ソースコード診断やクラウドの設定に関する診断など、診断対象やご事情に応じて様々なメニューをご用意しております。

    公開日:2025年12月5日
    更新日:2026年3月11日

    編集責任:木下

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


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

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

    脆弱性診断の必要性とは?ツールなど調査手法と進め方

    Share

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

    「脆弱性診断の必要性とは?」アイキャッチ画像

    企業が施すセキュリティ対策は広範かつ複雑になっています。外部からのサイバー攻撃や、内部での情報の持ち出しなど、セキュリティの脅威が多様化しているためです。企業が保護すべき情報、アプリケーション、機器の種類・数などが拡大していることも理由に挙げられます。

    「脆弱性診断」ではアプリケーションやサーバ、ネットワークに、悪用できる脆弱性がないかを診断します。本記事では、ライフサイクル別にどんな診断が必要か、ツール診断と手動診断、ペネトレーションテストとの違いなどを解説します。

    脆弱性診断とは

    脆弱性診断とは、企業・組織のシステムに内在するセキュリティ上の既知の欠陥(=脆弱性)を特定する検査です。

    脆弱性とは、システムやソフトウェアに存在するセキュリティ上の弱点を指します。
    →「脆弱性の意味を正しく理解する―読み方・具体例・種類をわかりやすく解説

    Webアプリケーション、スマホアプリケーション、サーバ、ネットワークなど診断対象により様々な脆弱性診断があります。セキュリティ上の問題点を可視化することで、情報漏洩やサービス停止等のセキュリティ事故を防ぐために、どのような対策を実施すればよいか検討するのに役立ちます

    脆弱性のリスクについてはこちらの関連記事もあわせてご参照ください。
    BBSec脆弱性診断結果からみる― 脆弱性を悪用したサイバー攻撃への備えとは ―
    定期的な脆弱性診断でシステムを守ろう!-放置された脆弱性のリスクと対処方法-
    既知の脆弱性こそ十分なセキュリティ対策を!
    今、危険な脆弱性とその対策―2021年上半期の診断データや攻撃事例より―

    脆弱性診断の必要性

    情報資産を守るため

    CIA説明画像

    情報のセキュリティの3要素、「機密性」「完全性」「可用性」を守るためにも、脆弱性診断は必要な理由の一つです。

    「機密性」…限られた人だけが情報に接触できるように制限をかけること。
    「完全性」…不正な改ざんなどから保護すること。
    「可用性」…利用者が必要なときに安全にアクセスできる環境であること。

    これらの要素を適切に満たすことが、情報セキュリティを担保する上では欠かせないものとなります。

    情報セキュリティ事故を未然に防ぐため        

    攻撃者より先にシステムに隠れた脆弱性を検出して対策することで、攻撃や事故発生の確率を下げることができます。ひとたび個人情報やクレジットカード情報の漏えい事故が発生すれば、さまざまな対応・復旧費用や対策工数の発生は避けられません。ブランドの毀損や企業イメージの低下も招きます。

    サービス利用者の安心のため

    パソコンやインターネットを補助的に利用していた昔と異なり、現在はWebサービスやアプリケーションそのものが利益を生み出しています。生活や経済がネットワークなしに成り立たない現在、脆弱性診断などのセキュリティ対策は、事業を継続しサービス利用者の安心を守るため、欠かせないものとなっています。

    脆弱性診断の種類

    診断対象により、さまざまな脆弱性診断サービスがあります。まず、企業が開発したWebアプリケーションが挙げられます。問合せや会員登録といった、入力フォームの入出力値の処理、ログイン機能の認証処理などに対して、幅広く網羅的に脆弱性診断が行われます。

    次に、そのWebアプリケーションを実行するサーバやネットワーク機器、OSやミドルウェアに脆弱性がないか検査するプラットフォーム診断があります。

    アプリケーションの脆弱性診断には、既知の攻撃パターンを送付して対象システムやソフトウェアの挙動を確認する「ブラックボックステスト」という方法があります。 「ブラックボックステスト」では、実装時における脆弱性は検出できますが、そもそもプログラムの設計図であるソースコード中に存在する脆弱性を網羅的には検査することには適していません。

    この場合、ソースコード開示のもと「ソースコード診断」する方法が有効です。「ソースコード診断」は「ブラックボックステスト」に対して 「ホワイトボックステスト」とも呼ばれます。また、「ソースコード診断」はさらに、プログラムを実行しないで行う「静的解析」と、実行して行う「動的解析」に分類できます。

    ソースコード診断についてはこちらの記事もあわせてご参照ください。
    ソースコード診断の必要性とは?目的とメリットを紹介

    そのほか、近年増加の一途をたどるスマホアプリケーションIoT機器を対象とした脆弱性診断もあります。

    脆弱性診断画像

    (株式会社ブロードバンドセキュリティのサービス分類に基づく)

    脆弱性診断とペネトレーションテストの違い

    脆弱性診断とペネトレーションテストは、双方とも脆弱性などを検出する点では似ていますが、目的と方法が少し異なります。脆弱性診断は既知の脆弱性を網羅的に検出することを目的としています。

    ペネトレーションテストは、「侵入テスト」の名前のとおり、疑似的なサイバー攻撃を仕掛けてセキュリティ対策の有効性を評価するために実施します。技術的アプローチだけでなく、対象となる組織の構成や、業務手順、ときには物理的な施設の特徴すら加味して、攻撃シナリオを作成する「レッドチーム演習」と呼ばれるテストを実施することもあります。

    シナリオに沿ってペネトレーションテスターが攻撃を実行し、システムに侵入できるか、ターゲットとする資産(多くは知的財産)にたどり着くことができるかどうかなどをテストします。ペネトレーションテストは脆弱性診断と比べて、技術力はもちろん、より幅広い見識やセンスが求められます。

    脆弱性診断のやり方(方法)

    脆弱性診断にはツールを使って自動で診断する「ツール診断」とエンジニアが診断する「手動診断」があります。

    ツール診断

    「ツール診断」では、セキュリティベンダーが、商用または自社開発した脆弱性診断ツールを用いて脆弱性を見つけ出します。脆弱性診断ツールと呼ばれるコンピュータプログラムを実行して、その応答から脆弱性を検知していくもので、自動診断とも呼ばれます。機械的に不正なHTTPリクエストを送り付ける疑似攻撃を行いますが、クラッカーによる攻撃とは異なり、あくまでも 脆弱性を見つけ出すことが目的であるため、システムを破壊することはありません。

    CPEサービスリンクバナー

    ツール診断は機械的な検査であるため、過検知や誤検知なども含まれることが多く、その結果は担当者が補正することで正確な情報が得られます。比較的手軽に行えることから、開発段階で実施されることも多い診断です。また、定期的な簡易診断として用いることで、コストを低減しつつ最新の状態を保つことができるといった利用方法もあります。

    脆弱性診断ツールとは

    脆弱性診断ツールには、たとえばWebアプリケーション診断の場合に、検査コードと呼ばれる不正なHTTPリクエストを送信し 擬似攻撃するプログラムがあります。

    手動診断

    技術者がプロキシツールを介してWebブラウザでサイトにアクセスした際に発生するリクエストを書き換える形で、脆弱性を確認する方法です。ツール診断と比べ検査項目も広く、また細かな検査ができるのが特徴です。

    手動診断は、経験と専門性を持つ技術者によって実施され、機械的な判断では見落としてしまう画面遷移・分岐にも対応できるメリットがあります。発見した脆弱性の再現手順や、最新動向を加味した対策方法などを提示してくれるのも、手動診断ならではの特徴と言えます。

    ツール診断と手動診断は、どちらが優れていると比較するものではありません。それぞれの特長を生かし、予算に合わせて組み合わせることで、コストパフォーマンスを発揮できるでしょう。

    脆弱性診断サービスの流れ

    セキュリティベンダーに脆弱性診断を依頼する際は、まず
    診断する範囲
    を決めます。組織にとって重要度が高い部分、すなわちサイバー攻撃を許してはいけないシステムやサーバ、Webアプリケーションを選定します。

    診断が終了するとベンダーからレポートが提供され、報告会が行われることもあります。レポートに記載された脆弱性には深刻度などがスコア化されていることもあります。内容に応じて優先度をつけて、脆弱性をふさぐ必要があります。

    チームによる診断・分析・保守画像

    継続的なセキュリティ対策の実施を

    脆弱性診断は一度実施したらそれで終わり、というものではありません。脆弱性診断により発見された問題に対し対策を実施することで、より堅牢なシステム・環境・体制を構築することができます。

    重要なのは、システムライフサイクルの各フェーズで、適切な診断を実施し、洗い出されたセキュリティ上の問題に優先順位をつけて、ひとつひとつ対処することです。診断ツールの検討に関しては自組織の環境やシステム特性に合わせたものを選定し、継続的なセキュリティ対策に有効活用できるようにしましょう。

    まとめ

    企業の情報システムが複雑かつ大規模になった現在、カード情報や個人情報・機密情報を狙う内外からの脅威に対して、企業もさまざまな予防手段を打っていく必要があります。情報システムやそれを取り巻く環境・体制が堅牢であるかどうかを検査、評価する方法として「脆弱性診断」があります。

    ・脆弱性診断とは企業・組織のシステムに内在するセキュリティ上の既知の欠陥(=脆弱性)
     を特定する検査
    ・Webアプリケーション、スマホアプリケーション、サーバ、ネットワークなど診断対象により様々な脆弱性診断がある
    ・脆弱性診断を実施し洗い出されたセキュリティ上の問題に優先順位をつけて、ひとつひとつ対処することが重要である


    公開日:2020年5月23日
    更新日:2026年3月11日

    編集責任:木下

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


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

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


    Security Serviceへのリンクバナー画像
    BBSecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    ウェビナーアーカイブ動画ページバナー画像