サイバー攻撃

2026年6月12日2026年6月22日

セキュリティインシデント発生時の対応 ―初動から復旧まで解説―

セキュリティインシデントが発生した際は、限られた時間の中で被害拡大を防ぎ、原因を調査し、業務復旧を進める必要があります。しかし、実際の現場では「まず何をすべきか」「どこまで影響が広がっているのか」「誰に報告すべきか」と判断に迷うケースも少なくありません。

初動対応の遅れや判断ミスは、情報漏えいや業務停止などの被害拡大につながる可能性があります。本記事では、セキュリティインシデント発生時に企業が取るべき対応について、初動対応から復旧までの流れを解説します。

なお、インシデント管理の全体像については、以下の記事で詳しく解説しています。
「セキュリティインシデント管理とは？企業が押さえるべき対応フローと体制の全体像」

インシデント対応が遅れると被害が拡大する―「初動対応」の重要性

セキュリティインシデントが発生した際、最初に求められるのは「被害の拡大を防ぐこと」です。具体的には、該当システムのネットワーク接続を遮断する、影響範囲を限定する、ログを確保して証拠を保存するといった行動が挙げられます。ここで重要なのは、焦ってシステムを完全に停止させたり証拠を消去したりしてしまわないことです。例えば、感染が疑われるPCを慌てて初期化すると、攻撃経路やマルウェアの痕跡といった重要な調査情報を失うことになり、後続の対応が困難になります。そのため、インシデント発生時には「まず拡大防止と証拠保全を優先する」という基本原則を徹底する必要があります。初動段階での判断ミスが、被害規模や復旧にかかる時間を大きく左右するのです。

セキュリティインシデント対応の基本フロー

社内連携と報告体制

セキュリティインシデントが発生した際、技術的な対応と同じくらい重要なのが「社内連携と報告体制」です。現場担当者が異常を検知した場合、直属の上司や情報システム部門への迅速な報告はもちろん、経営層へのエスカレーションルートを明確にしておくことが不可欠です。さらに、インシデント対応を一部門だけに任せるのではなく、法務・広報・総務など関連部門との連携が欠かせません。例えば、法務部門は法的リスクの確認や外部機関への届出判断を担い、広報部門は顧客や取引先への適切な情報発信を行います。これらが連携できていないと、組織全体としての対応が後手に回り、混乱や信頼失墜を招く恐れがあります。そのため、平常時から「誰が・どのタイミングで・誰に報告するか」を明文化したインシデント対応計画を整備しておくことが重要です。

被害範囲の特定

セキュリティインシデントが発生した際に、初動対応で重要なのが「被害範囲の特定」です。単なる障害や一時的な不具合と、外部からの不正アクセスやマルウェア感染といったインシデントを明確に区別する必要があります。具体的には、ログの解析やネットワーク監視、ユーザ報告などを通じて、侵入経路や影響を受けたシステム、漏洩が疑われる情報を洗い出します。この段階で誤った判断を下すと、被害を過小評価して対応が遅れたり、逆に過大評価して不要な混乱を招いたりするリスクがあります。そのため、迅速かつ客観的に状況を評価できる仕組みを整えておくことが欠かせません。

被害の封じ込め・拡大防止

被害範囲を特定した後は、被害の「封じ込め」が必要です。これは、インシデントの拡大を防ぎ、さらなる被害を最小限に抑えるための重要なプロセスです。例えば、侵害を受けたサーバをネットワークから切り離す、攻撃者が利用したアカウントを即座に無効化する、通信を一時的に遮断するなどの対応が考えられます。ただし、封じ込めの方法を誤ると、証拠が失われたり、攻撃者に異変を察知されて活動を隠蔽されたりする恐れもあります。そのため、封じ込めの対応はセキュリティチーム内で役割を明確にし、優先順位を付けて慎重に進めることが求められます。

原因調査・ログ解析・フォレンジック調査

封じ込めが完了した後は、インシデントの原因を突き止める「原因調査」が不可欠です。攻撃者がどのように侵入したのか、どの脆弱性を悪用したのか、内部関係者の過失や不正が関与していないかなど、多角的な視点から調査を進める必要があります。ログ解析やフォレンジック調査を通じて、攻撃経路や被害状況を正確に把握することが求められます。この段階で調査が不十分だと、再発防止策が不完全となり、再び同様の被害を招く可能性が高まります。そのため、外部のセキュリティ専門家の協力を得るケースも少なくありません。

復旧対応

原因が特定された後は、システムやサービスの復旧作業に移ります。ただ単に停止したサービスを再開させるのではなく、原因を取り除き、安全性を確認したうえで再稼働することが重要です。例えば、脆弱性が悪用されていた場合はセキュリティパッチを適用し、不正アクセスで改竄されたデータがあればバックアップから復旧します。また、復旧の際には「段階的な再開」を意識することが推奨されます。いきなり全システムを戻すのではなく、優先度の高いシステムから順に稼働させ、監視を強化しながら正常性を確認することで、再度の障害発生や攻撃再開のリスクを軽減できます。

関係者への報告・情報共有

復旧作業と並行して、関係者への適切な報告や情報共有も欠かせません。セキュリティインシデントは自社だけの問題ではなく、取引先や顧客、さらには規制当局にまで影響が及ぶ可能性があります。そのため、影響範囲を正確に把握したうえで、必要な関係者に迅速かつ誠実に情報を提供することが求められます。特に個人情報漏洩が発生した場合、法令やガイドラインに従った報告が義務付けられているケースも多く、対応を怠れば法的リスクや企業の信頼失墜につながります。また、社内向けの情報共有も重要であり、従業員が不安や誤情報に惑わされないよう、明確なメッセージを発信する体制を整えることが望まれます。

再発防止策の検討

インシデント対応の最終段階は、再発を防ぐための改善策を講じることです。単に原因を修正するだけでなく、組織全体のセキュリティ体制を見直す機会として活用することが重要です。例えば、脆弱性管理の仕組みを強化する、アクセス制御のルールを見直す、ログ監視やアラートの精度を高めるなど、技術的な改善が挙げられます。また、従業員へのセキュリティ教育や定期的な訓練を実施し、人為的なミスや不注意を減らす取り組みも効果的です。さらに、インシデント対応の流れを記録し、振り返り（ポストモーテム）を行うことで、今後同様の事態が発生した際に迅速かつ適切に対処できる体制を構築できます。

BBSecでは

セキュリティインシデントの再発防止や体制強化を確実に行うには、専門家の支援を受けることも有効です。BBSecでは緊急対応支援サービスも提供しています。突然の大規模攻撃や情報漏洩の懸念等、緊急事態もしくはその可能性が発生した場合は、BBSecにご相談ください。セキュリティのスペシャリストが、御社システムの状況把握、防御、そして事後対策をトータルにサポートさせていただきます。

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

まとめ

本記事では、セキュリティインシデントが発生した際に組織が取るべき対応を、初動から原因調査、復旧、関係者への報告、そして再発防止まで段階的に解説しました。インシデント対応は単なる技術的作業ではなく、社内連携や外部機関との調整、法令遵守、そして企業全体の信頼維持といった広範な要素が関わります。特に初動対応の速さや正確さは被害の拡大を防ぐ鍵となるため、日頃からの対応体制の整備や訓練が欠かせません。次回第3回では、インシデントの発生を未然に防ぐ取り組みや、組織全体でのセキュリティ強化策について詳しく解説し、実践的な予防策のポイントを紹介します。

インシデント発生時の対応を円滑に進めるためには、平時から対応体制を整備しておくことが重要です。
「インシデント対応体制とは？CSIRTの役割と企業が整えるべき運用のポイント」

【参考情報】

NIST SP 800-61 Rev. 2（https://csrc.nist.gov/pubs/sp/800/61/r2/final）
経済産業省「サイバー攻撃の被害に遭ってしまったら御活用を！―中小企業のためのセキュリティインシデント対応の手引き―」（https://www.meti.go.jp/policy/netsecurity/sme_incident.html）
独立行政法人情報処理推進機構(IPA)セキュリティセンター「中小企業のためのセキュリティインシデント対応の手引き」2024年7月（https://www.ipa.go.jp/security/sme/f55m8k0000001wpz-att/outline_guidance_incident.pdf）

公開日：2025年10月8日
更新日：2026年6月17日

編集責任：木下

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

最新情報はこちら

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

2026年6月12日2026年6月22日

セキュリティインシデントとは？基礎知識と代表的な事例を解説

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

サイバー攻撃や情報漏えい、不正アクセス、ランサムウェア感染など、企業を取り巻くセキュリティリスクは年々増加しています。こうした事象は「セキュリティインシデント」と呼ばれ、発生した場合は情報資産の損失だけでなく、事業停止や信用低下につながる可能性があります。

しかし、「どのような事象がセキュリティインシデントに該当するのか」「企業はどのようなリスクを認識すべきか」を正しく理解できていないケースも少なくありません。

本記事では、セキュリティインシデントの定義や代表的な事例、企業への影響についてわかりやすく解説します。

インシデント管理や対応フローの全体像については、関連記事もあわせてご覧ください。
「セキュリティインシデント管理とは？企業が押さえるべき対応フローと体制の全体像」

セキュリティインシデントの定義

セキュリティインシデントとは、情報システムやネットワークにおいて、情報のセキュリティの3要素、「機密性」「完全性」「可用性」を脅かす事象の総称です。具体的には、不正アクセスや情報漏洩、マルウェア感染、サービス運用妨害（DoS）攻撃などが含まれます。近年はクラウドやリモートワークの普及により、攻撃対象や被害の範囲が広がり、セキュリティインシデントの発生リスクは増大しています。国内外で大規模な事件が相次いで報道されるなか、インシデントの発生はもはや大企業に限られた問題ではなく、中小企業や自治体、教育機関に至るまで幅広い組織が直面しています。そのため、経営層から現場担当者に至るまで、セキュリティインシデントへの理解と備えが求められているのです。

セキュリティインシデントの種類（例）

一口にセキュリティインシデントといっても、その内容は多岐にわたります。代表的なものとしては、まず「不正アクセス」が挙げられます。攻撃者が外部からシステムに侵入し、機密情報を窃取したり改竄したりするケースです。次に「マルウェア感染」があります。ウイルスやランサムウェアなどの悪意あるソフトウェアにより、データが暗号化され業務が停止する被害が増えています。また、従業員による「内部不正」も見逃せません。権限を持つ社員が意図的に情報を持ち出すケースや、誤操作による情報流出が問題化しています。さらに「情報漏洩」や「サービス停止（DoS/DDoS攻撃など）」も、企業活動を直撃する深刻なインシデントです。このようにセキュリティインシデントは外部攻撃だけでなく、内部要因やシステム障害など多面的に発生し得るため、幅広い視点での備えが不可欠です。

実際に発生した主なセキュリティインシデント事例

セキュリティインシデントは国内外で日々多発しています。この表は2025年8月から9月にかけて発生した主要な国内インシデント事例をまとめたものです。ランサムウェア攻撃や不正アクセスによる被害が多く、特に製造業や重要インフラへの影響が深刻化している傾向が見られます。

被害報告日	被害企業	概要	主な原因	影響範囲
2025年9月	国内ガス・電力会社	人為的ミス	LPガス検針端末の紛失	顧客情報6,303件の漏洩等のおそれ*1
2025年9月	国内デジタルサービス運営委託事業者	個人情報漏洩	受講状況管理ツールへの登録作業ミス	リスキリングプログラム受講者1名の個人情報が他の受講者1名に閲覧可能に*2
2025年9月	国内食料品小売業	個人情報漏洩	サーバへの第三者からの不正アクセス	企業情報及び個人情報が流出した可能性*3
2025年9月	委託事業者	操作・管理ミス	オペレーターの利用者情報取り違い	高齢者の見守り・安否確認が行われず*4
2025年9月	国内オフィス機器販売会社	個人情報漏洩	第三者による不正アクセス	カード支払い顧客の情報漏洩の可能性*5
2025年8月	ハウステンボス株式会社	システム障害	第三者による不正アクセス	一部サービスが利用できない状況に*6
2025年8月	国内電力関連会社	不正ログイン	リスト型攻撃（複数IPアドレスから大量ログイン試行）	ポイント不正利用444件*7
2025年8月	国内機器メーカー企業	不正アクセス	海外グループ会社を経由した第三者の不正アクセス	一部サービス提供停止（8月16日復旧）*8
2025年8月	医療用メーカー企業	マルウェア感染	システムのランサムウェア感染	2日間出荷停止、その後再開*9
2025年8月	国内建設事業者	マルウェア感染	システムのランサムウェア感染	海外グループ会社の一部サーバが暗号化*10
2025年8月	国内外郭団体	乗っ取り	第三者による一部メールアドレスの乗っ取り	迷惑メール送信元として悪用*11
2025年8月	暗号資産交換事業者	クラウド設定ミス	顧客データ移転作業中のクラウド設定ミス	海外メディアの報道で発覚、アクセス制限不備*12
2025年8月	国内銀行	元従業員による情報の不正取得	出向職員による電子計算機使用詐欺	アコムから出向の元行員が逮捕・懲戒解雇*13
2025年8月	国内病院	個人情報不正利用	委託職員が診療申込書から電話番号を不正入手	LINEで患者に私的メッセージを送付*14
2024年12月	国内総合印刷事業者	マルウェア感染	VPNからの不正アクセス（パスワード漏洩または脆弱性悪用）	複数のサーバが暗号化される被害*15https://maruni.jp/notice_20250809/

これらの事例は「セキュリティインシデントは特定の大企業だけの問題ではない」という現実を示しており、規模や業種にかかわらず備えが不可欠であることを強調しています。

セキュリティインシデントが企業に与える影響

セキュリティインシデントが発生すると、企業は多方面に深刻な影響を受けます。最もわかりやすいのは、システム停止や情報漏洩に伴う金銭的損失です。業務が一時的に止まることで売上が減少し、復旧作業や調査にかかる費用も膨大になります。さらに、顧客情報や取引先情報が流出すれば、企業の信頼性が大きく揺らぎ、契約解除や取引停止に直結する可能性があります。また、個人情報保護法や業界ごとのセキュリティ基準に違反すれば、法的責任や行政処分を受けるリスクも高まります。株式市場に上場している企業であれば、セキュリティインシデントの公表によって株価が急落するケースも少なくありません。このように、単なるシステム障害にとどまらず、企業経営全体に打撃を与える点がセキュリティインシデントの恐ろしさといえます。

セキュリティインシデントを理解したら、次に重要なのは実際に発生した際の対応手順です。初動対応から復旧までの流れについては、以下の記事で詳しく解説しています。
「インシデント対応フローとは？発生時に企業が取るべき手順と判断ポイント」

まとめ

本記事では、セキュリティインシデントの定義や種類、実際に発生した事例、そして企業に及ぼす影響について解説しました。改めて強調すべきは、セキュリティインシデントは大企業だけでなく、中小企業や自治体、教育機関などあらゆる組織にとって現実的な脅威であるという点です。しかも一度発生すると、金銭的損失だけでなく、顧客や取引先からの信頼低下、法的リスク、社会的信用の失墜といった連鎖的な被害を引き起こします。こうした背景から、セキュリティインシデントを「発生してから考える」姿勢ではなく、「発生する前提で備える」姿勢が求められています。次回は、実際にインシデントが発生した際にどのような対応が必要なのか、初動から復旧までの流れを詳しく解説します。

【関連記事】

セキュリティインシデントへの理解を深めたい方は、以下の記事もあわせてご覧ください。

セキュリティインシデント管理とは？企業が押さえるべき対応フローと体制の全体像
セキュリティインシデント発生時の対応 ―初動から復旧まで解説―
セキュリティインシデントの再発防止策とは？体制強化と継続的改善のポイント
インシデント対応フローとは？発生時に企業が取るべき手順と判断ポイント
インシデント対応体制とは？CSIRTの役割と企業が整えるべき運用のポイント

【参考情報】

NIST SP 800-61 Rev. 2（https://csrc.nist.gov/pubs/sp/800/61/r2/final）
ScanNetSecurity,（https://scan.netsecurity.ne.jp/category/incident/latest/?page=1）

公開日：2025年10月1日
更新日：2026年6月17日

編集責任：木下

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

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

最新情報はこちら

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

2026年6月12日2026年6月12日

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

ランサムウェアの感染経路とは ―企業が見落としがちな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回：セキュリティインシデント発生時の対応 ─初動から復旧まで」

【参考情報】

警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」（https://www.npa.go.jp/bureau/cyber/pdf/R07_cyber_jousei.pdf）
JPCERT/CC「侵入型ランサムウェア攻撃を受けたら読むFAQ」（https://www.jpcert.or.jp/magazine/security/ransom-faq.html）

編集責任：木下

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

2026年6月4日2026年6月8日

クレジットカード情報漏洩に備える ―非保持化・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サイトでの番号盗用によるものとされています*16。

これらの事例から分かるのは、クレジットカード情報漏洩が例外的な事故ではなく、現実的には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春夏号

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

BBSecホワイトペーパー「企業のセキュリティ成熟度チェックリスト」資料ダウンロードボタン

編集責任：木下

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

2026年5月28日2026年6月1日

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

ゼロデイ脆弱性は、修正パッチが提供される前に悪用される極めて危険な脆弱性です。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-3909とCVE-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による攻撃面の可視化を通じて、企業のゼロデイ対策を支援しています。ゼロデイ脆弱性への備えを強化したい方は、以下のサービスページもあわせてご覧ください。

アタックサーフェス調査 -SQAT^® ASM-（攻撃面の可視化・管理）
エンドポイントセキュリティ EDR-MSS（侵入後の検知・対応）
G-MDR^®（高度な脅威分析・対応）

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

まとめ

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

【参考情報】

NIST（米国立標準技術研究所）Information Technology Laboratory Computer Security Resource Center「zero day attack」（https://csrc.nist.gov/glossary/term/zero_day_attack）
NVD（米国国立脆弱性データベース）「CVEs and the NVD Process」（https://nvd.nist.gov/general/cve-process）
Zero Day Initiative (ZDI)「(0Day) OpenAI Codex Sandbox Escape Vulnerability」
https://www.zerodayinitiative.com/advisories/ZDI-26-305/

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

2026年6月3日（水）14:00～15:00「金融機関の対応事例に学ぶPQC移行の進め方と実務ポイント」

2026年6月10日（水）14:00～14:30「Webサイトの見えない脅威を可視化する外部タグ・サードパーティースクリプトの監視対策」

最新情報はこちら

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

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

編集責任：木下

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

2026年5月15日2026年5月21日

情報漏洩はなぜ起きるのか ―企業で多い原因と最新事例から見るリスクの実態―

情報漏洩というと、外部の攻撃者による大規模な不正アクセスを思い浮かべる方が多いかもしれません。しかし実際には、誤送信や紛失、権限設定の不備、委託先での事故、クラウドの運用ミスなど、日常業務の延長で起きる事案も少なくありません。情報漏洩の原因を正しく理解することは、企業の情報漏洩対策を実効的なものにする第一歩です。本記事では、最新事例をもとに、企業で多い原因と情報漏洩リスク、対策の考え方を解説します。

情報漏洩の全体像や基本的な考え方については、以下の記事で整理しています。
「情報漏洩対策とは何か ―企業が知るべき原因・リスク・防止策の全体像―」

情報漏洩の多くは“想定外”で起きている

多くの企業が情報漏洩を「自社が攻撃される特殊な事故」と捉えがちですが、実際には“想定していなかった経路”から起きるケースが目立ちます。個人情報保護委員会から報告された年次報告によると、個人データの漏えい等事案について8,928件の報告処理が行われており、発生原因としては病院や薬局における要配慮個人情報を含む書類の誤交付や紛失、不正アクセス、クレジットカードの誤送付などが多かったとされています*5https://www.ppc.go.jp/aboutus/report/。つまり、情報漏洩は高度なサイバー攻撃だけでなく、紙・メール・業務フローといった身近な部分でも起き続けています。

さらに厄介なのは、自社だけではコントロールしきれないところで事故が起きることです。個人情報保護委員会「不正アクセス発生時のフォレンジック調査の有効活用に向けた論点整理のための参考資料」（令和８年１月16日）によると、不正アクセスによる漏えい等報告件数が増加しており、令和6年度の直接受付分では不正アクセスによる報告件数が4,024件に達したことが示されています。この数値にはSaaS提供事業者への不正アクセスにより、多数の利用企業へ影響が及んだ事案も含まれており、企業が自社の運用だけを見ていても十分ではないことが分かります。

見落とされやすいのは、「情報漏洩はセキュリティ部門だけの課題ではない」という点です。営業が使うクラウド、委託先が使う再委託先サービス、バックオフィスの紙帳票、現場の持ち出し端末など、事故の起点は部門横断で存在します。だからこそ、情報漏洩対策は製品導入だけでなく、業務設計や権限設計、委託先管理を含めて捉える必要があります。

情報漏洩の主な原因とは？企業で多い5つのパターン

人的ミス

情報漏洩の原因として古くから多いのが人的ミスです。メールの誤送信、添付ファイルの取り違え、紙書類の誤交付、USBメモリやノートPCの紛失といった事故は、特別な攻撃がなくても発生します。人的ミスが減らない理由は、担当者の注意力だけに依存しているからです。確認手順が曖昧だったり、ダブルチェックが形骸化していたり、忙しい時に例外運用が常態化していたりすると、同じような事故は繰り返されます。情報漏洩対策では、個人の注意喚起だけでなく、ミスしても大事故にならない設計が求められます。

権限管理ミス

必要以上の権限が付与されたままになっていることも、情報漏洩の大きな原因です。退職者や異動者の権限が削除されていない、共有フォルダが広く閲覧可能になっている、クラウド上の情報に不要なアクセス権が残っていると、内部不正やアカウント侵害が起きた際の被害が一気に拡大します。個人情報保護委員会は安全管理措置の中で、組織的・技術的な統制の必要性を示しており、アクセス権限の適切な管理はその中心的な要素です。

権限管理ミスは、事故が起きるまで表面化しにくい点が厄介です。実務では「業務が止まらないこと」を優先して権限が広がりがちですが、その積み重ねが情報漏洩リスクを高めます。情報漏洩対策を考える際は、誰がどの情報にアクセスできるのかを定期的に棚卸しする必要があります。

設定不備

クラウドやWebサービスの設定不備も、近年の情報漏洩で頻出する原因の一つです。これには単なる操作ミスではなく、誰が何を公開し、どこまで共有し、いつ見直すのかという運用ルールの不足が背景にあることが多くあります。また、設定不備は、システム担当者だけの問題でもありません。現場部門が便利さを優先して外部共有設定を変更したり、試験用データを本番と同じ場所に残したりすることで、情報漏洩につながるケースもあります。クラウド利用が前提となった今、設定ミスは特別な失敗ではなく、どの企業でも起こりうる実務上のリスクです。

マルウェア（ランサムウェア）によるサイバー攻撃も、情報漏洩の主要因です。攻撃の目的は業務停止だけではなく、個人情報や企業情報の窃取と公開を組み合わせた二重脅迫に及ぶことが多く、被害は広範囲に及びます。

サプライチェーン経由の情報漏洩

近年、特に重要性が増しているのが、委託先や再委託先、利用中の外部サービスを経由した情報漏洩です。自社では直接不正アクセスを受けていなくても、業務を委託している先や、相手先が利用しているクラウド環境に問題があれば、結果として自社の顧客情報や取引情報が漏れることがあります。独立行政法人情報処理推進機構（IPA）が毎年公開する「情報セキュリティ10大脅威 2026」でも、「サプライチェーンや委託先を狙った攻撃」が「ランサム攻撃による被害」に続けて第2位に挙げられており、その継続的な深刻さを指摘しています。

委託先や外部サービスを経由したリスクについては、サプライチェーン攻撃の記事でも詳しく解説しています。
「サプライチェーン攻撃とは ―委託先・外注先リスクから情報漏洩を防ぐ全体像―」

実際に起きている情報漏洩事例

情報漏洩事例は、発生原因によっていくつかのパターンに整理できます。近年はサイバー攻撃だけでなく、委託先や外部サービス経由の事故も増えています。

類型	主な原因	主な内容・特徴	代表的な事例
人的ミス型	誤送信・紛失・誤交付	日常業務の延長で発生。メール誤送信や紙書類の取り違え、端末紛失など	病院・薬局での誤交付、書類紛失
権限管理・設定不備型	過剰権限・公開設定ミス	共有フォルダやクラウド設定の不備によって情報が意図せず閲覧可能になる	クラウド共有設定ミス、退職者権限の残存
サイバー攻撃型	不正アクセス・ランサムウェア	情報窃取と業務停止が同時発生。二重脅迫型攻撃も増加	KADOKAWA2、損害保険ジャパン3
委託先・外部サービス型	SaaS侵害・再委託先事故	委託先やクラウドサービス経由で情報が漏えい	みずほ証券4、野村證券5

人的ミス型では、メールの誤送信や書類紛失、端末の置き忘れなど、日常業務の延長で情報漏洩が発生します。特別な攻撃がなくても起こりうるため、多くの企業で継続的な課題となっています。個人情報保護委員会の活動実績でも、病院や薬局における誤交付や紛失が主要原因として挙げられており、業務ミスがそのまま漏洩事故につながる実態が示されています。

また、権限管理ミスや設定不備も、近年の情報漏洩で多く見られる原因です。退職者アカウントの権限が残ったままになっていたり、共有フォルダやクラウドストレージが過剰公開状態になっていたりすると、不正アクセスや内部不正が発生した際に被害が拡大しやすくなります。クラウド利用が一般化した現在では、設定ミスそのものが重要なリスク要因になっています。

サイバー攻撃型では、ランサムウェアや不正アクセスによって、情報漏洩と業務停止が同時に発生するケースが増えています。近年は情報を窃取したうえで公開を脅迫する「二重脅迫」も広がっており、被害は長期化・広域化しやすくなっています。KADOKAWAの事例では、ランサムウェアを含むサイバー攻撃によって「ニコニコ」を含む複数サービスが停止し、約25万4,000人分の個人情報等の漏えいが確認されました*6。また、損害保険ジャパンも2025年に不正アクセスによる顧客情報漏えいの可能性を公表*7しており、初動対応後のフォレンジック調査の重要性も示されています。

さらに近年は、委託先や再委託先、利用中のクラウドサービスを経由した情報漏洩も増加しています。自社が直接攻撃を受けていなくても、外部サービスや委託先で発生した事故によって顧客情報や取引情報が漏洩するケースも少なくありません。みずほ証券や野村證券では、再委託先企業が利用していたクラウドサービスへの不正アクセスにより、顧客関連情報の流出が公表されました。

こうした事例に共通するのは、「想定外の場所が起点になる」「単一の対策だけでは防ぎきれない」「発覚後に影響範囲の特定が難しい」という点です。情報漏洩対策では、自社システムだけでなく、権限管理や業務運用、委託先管理を含めた全体的な見直しが重要になります。

なぜ情報漏洩は繰り返し起きるのか

同じような情報漏洩事故が繰り返される理由の一つは、業務の属人化です。担当者しか知らない運用、引き継がれていない例外ルール、慣習で続いている権限付与などが残っていると、問題が見えないままリスクが蓄積します。事故が起きたときだけルールを追加しても、実務の現場で運用可能な形になっていなければ再発防止にはつながりません。個人情報保護委員会が安全管理措置として組織的・人的・技術的対策を求めているのは、こうした属人的運用を避けるためでもあります。

もう一つの理由は、可視化不足です。どの情報をどこで持ち、誰がアクセスでき、どの委託先に渡し、どのクラウドに保存しているのかが見えていない企業では、情報漏洩リスクを事前に評価できません。不正アクセスが増加している今、見えない資産、見えない権限、見えない再委託は、そのまま事故要因になります。

さらに、事故が起きるまで「うちは大丈夫」と考えてしまうことも再発の温床です。IPAや国家サイバー統括室（旧NISC）「サイバーセキュリティ2025」が示しているように、ランサム攻撃やサプライチェーン経由の被害はすでに幅広い業種で発生しています。情報漏洩対策は特定業界の一部企業だけの話ではなく、どの企業にも関係する経営課題です。

こうした事故を防ぐための具体的な対策については、以下の記事で詳しく解説しています。
「企業の情報漏洩対策 ―すぐに実践できる防止策と運用のポイント」

まとめ

情報漏洩は、単純な「外部からの攻撃」だけで起きるものではありません。人的ミス、権限管理ミス、設定不備、サイバー攻撃、委託先や再委託先での事故など、複数の原因が複雑に絡み合って発生します。個人情報保護委員会の統計でも誤交付や紛失、不正アクセスが継続して多く報告されており、さらに近年はSaaS事業者や委託先を経由した広域的な影響も目立っています。つまり、情報漏洩対策では「どこから漏れるか分からない」という前提に立ち、社内運用、自社システム、委託先管理を一体で見直す必要があります。情報漏洩対策は、IT部門だけの課題ではなく、企業全体の業務設計と管理体制の問題です。「どこから漏れるか分からない」ことを前提に、継続的な見直しを行うことが求められます。

情報漏洩を防ぐために企業が取るべき対策を整理した記事もあわせてご覧ください。
「企業の情報漏洩対策 ―すぐに実践できる防止策と運用のポイント」

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

2026年5月27日（水）14:00～15:00「～取引先から求められる前に押さえる～ SCS評価制度への対応準備と現実的な進め方」

2026年6月3日（水）14:00～15:00「金融機関の対応事例に学ぶPQC移行の進め方と実務ポイント」

2026年6月10日（水）14:00～14:30「Webサイトの見えない脅威を可視化する外部タグ・サードパーティースクリプトの監視対策」

最新情報はこちら

編集責任：木下

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

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

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

2026年5月8日2026年5月8日

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

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つの要素

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

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

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

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

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

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

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

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

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

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

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

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

SSVCとは

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

SSVCの3つのモデル

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

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

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

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

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

まず、Bさんは上司に相談したうえで、前述した3つの要素、「脆弱性を持つアセットが置かれている環境」、「事業継続性への影響」、「社会や社内への影響度」を定義していく必要があります。また、この定義に当たっては実際の環境や利用用途、部門内のリソースなどをよく知っているインフラチームや開発部といった当事者、つまりステークホルダーの関与（少なくとも承認）が必要となってきます。このほかに優先順位付けの結果、”Immediate”や”Out-of-Cycle”が出た場合の対応プロセスも用意しておく必要があります。Bさん１人で何かできることはそれほど多くはなく、社内のステークホルダーへの聞き取りや経営層への説明、必要なプロセスの準備と合意形成など、上司や部門全体も含めて組織的に取り組まなければならないといえます。さらに、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は脆弱性の単体評価ができ、脆弱性が広く悪用された場合の深刻度を測るための評価システムです。ただし、その脆弱性が存在するアセットがどのように利用されているか、そのアセットが業務継続性や運用保守、ひいては社会全体に対してどのような影響を与えるかといった観点が欠けていることが長らく問題視されてきたのも事実です。

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

参考情報：

独立行政法人情報処理推進機構（IPA）「共通脆弱性評価システムCVSS v3概説」
https://www.ipa.go.jp/security/vuln/scap/cvssv3.html
カーネギー・メロン大学「SSVC: Stakeholder-Specific Vulnerability Categorization」
https://certcc.github.io/SSVC/

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

編集責任：木下

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

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

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

最新情報はこちら

Youtubeチャンネルのご案内

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

2026年4月9日2026年5月21日

情報漏洩対策とは何か ―企業が知るべき原因・リスク・防止策の全体像―

情報漏洩対策は、単にウイルス対策ソフトを入れたり、アクセス制限を強めたりするだけでは不十分で、「何が漏れるのか」「なぜ起きるのか」「起きたときに何が起きるのか」「どう防ぐのか」を分けて整理することが重要です。なぜならば、実際の情報漏洩は不正アクセスのような外部からの攻撃だけでなく、誤送信や設定不備、委託先での事故など、日常業務の延長線上で発生することが少なくないためです。

個人情報保護委員会は、漏えい等事案への対応体制の整備や定期的な点検、見直しの必要性を示しており、IPA（独立行政法人情報処理推進機構）でも企業の情報セキュリティ対策を経営課題として継続的に進める必要があるとしています。本記事では、情報漏洩対策の全体像や基本的な考え方について整理します。

情報漏洩がなぜ起きるのか、実際の原因や事例については以下の記事で詳しく解説しています。
「情報漏洩はなぜ起きるのか ―企業で多い原因と最新事例から見るリスクの実態―」

情報漏洩とは何か

情報漏洩とは、本来アクセス権限を持たない第三者に、企業が保有する情報が意図せず、あるいは不正に渡ってしまうことを指します。ここでいう情報には、顧客情報や従業員情報のような個人情報だけでなく、営業秘密、契約情報、設計情報、認証情報、メール本文、取引先とのやり取り、さらにはクラウド上で扱う業務データまで含まれます。

個人情報保護委員会が公表している「個人情報の保護に関する法律についてのガイドライン（通則編）」でも、個人データの漏えい等を防ぐために安全かつ適切な管理措置を講じるための内容が示されており、企業にとって情報漏洩は法務、経営、現場運用のすべてに関わる問題です。

近年、情報漏洩がより起こりやすくなっている背景には、業務のデジタル化が急速に進んだことがあります。クラウドサービスやSaaSの利用拡大により、データは社内サーバだけでなく外部環境にも分散して保存・共有されるようになりました。その結果、設定不備や共有範囲の誤りが事故の起点になる場面が増えています。

さらに、委託先や外部サービスを含めたサプライチェーン全体で情報を扱うことが当たり前になり、自社だけを守っていればよい時代ではなくなっています。経済産業省でも国内外のサプライチェーンでつながる関係者への目配りの必要性を明記しており、IPA「情報セキュリティ10大脅威2026」でもサプライチェーンや委託先を狙った攻撃が上位に挙げられています。

情報漏洩が企業に与える影響

情報漏洩が起きた企業に生じる大きな影響は以下のとおりです。

信用低下

まず生じるのは、信用の低下です。漏洩した情報の件数や内容だけでなく、「管理が甘い企業ではないか」「再発防止ができるのか」といった不信感が、顧客や取引先、株主、採用候補者にまで広がります。情報セキュリティ事故は単発のITトラブルではなく、企業の信頼基盤そのものを揺るがす経営リスクとして扱う必要があります。経済産業省およびIPAが公開している「サイバーセキュリティ経営ガイドライン Ver 3.0」でもサイバーリスクを経営者が主導して把握し、組織的に対処すべき課題として位置付けています。

損害賠償・対応コストの増大

漏洩の可能性が判明した後には、事実関係の調査、影響範囲の特定、本人通知、関係機関への報告、公表、問い合わせ対応、再発防止策の策定など、多くの業務が短期間に発生します。個人情報保護委員会のガイドラインでも、漏えい等事案の発生時には、調査、本人通知、報告、再発防止策の決定、公表などを行う体制をあらかじめ整備しておくことが求められています。つまり、情報漏洩対策は事故後のためにも必要であり、平時の備えが不十分だと、事故後の負担はさらに重くなります。

事業停止の可能性

さらに、情報漏洩は事業停止リスクにも直結します。不正アクセスやランサムウェア攻撃を伴うケースでは、単なる情報流出にとどまらず、システム停止や業務遅延、取引停止が同時に発生することがあります。

JPCERT/CCが2021年11月に公開した資料「経営リスクと情報セキュリティ～ CSIRT：緊急対応体制が必要な理由～」の中で、インシデント発生時には対処方針の決定、問題解決、収束、再発防止の分析、教育啓発までを含めた緊急対応体制が必要であると整理しています。情報漏洩は「漏れたら終わり」ではなく、「漏れた瞬間から事業継続の問題になる」という視点が重要です。

情報漏洩による影響や損失の考え方については、以下の記事で詳しく解説しています。
「サイバー攻撃被害コストの真実―ランサムウェア被害は平均2億円？サイバー攻撃のリスク評価で“事業停止損害”を可視化」

情報漏洩が起きる主な原因

情報漏洩の原因として最も見落とされやすいのが、人的ミスです。宛先の誤送信、ファイルの添付ミス、書類の紛失、権限設定の誤り、持ち出しルール違反などは、特別な攻撃を受けなくても起こります。個人情報保護委員会の年次報告でも、書類の誤交付や紛失、誤送付といった事案が多く見られるとされています。情報漏洩という言葉から外部攻撃を想像しがちですが、実務では人の確認不足やルール運用の甘さが起点になる事故が依然として多いのが実態です。

一方で、近年無視できないのが不正アクセスによる情報漏洩です。個人情報保護法サイバーセキュリティ連絡会が公表した資料「不正アクセス発生時のフォレンジック調査の有効活用に向けた着眼点」（令和８年１月16日）でも、不正アクセス被害は近年多発しており、同委員会が受け付ける不正アクセスによる漏えい等報告件数も増加していると明記しています。また、「令和６年度個人情報保護委員会年次報告」では、SaaS事業者への不正アクセスが多数の利用企業に影響した事案の影響も含まれるものの、不正アクセス由来の報告件数が大きく増えたことが示されています。この点は、企業が自社環境だけでなく、利用中のサービスや委託先のセキュリティ状況も確認しなければならないことを意味します。

さらに、委託先やサプライチェーン経由の漏洩リスクも大きくなっています。自社では適切に管理していても、外部ベンダー、運用委託先、クラウドサービス事業者、グループ会社のいずれかに弱点があれば、そこが侵入口になります。

委託先や外部サービスを経由したリスクについては、サプライチェーン攻撃の記事も参考になります。
「サプライチェーン攻撃とは ―委託先・外注先リスクから情報漏えいを防ぐ全体像―」

企業が取るべき情報漏洩対策

企業の情報漏洩対策は、技術対策、運用対策、組織・体制整備の三層で考えると整理しやすくなります。

技術対策

アクセス制御、認証強化、ログ取得、暗号化、端末管理、バックアップ、脆弱性対応などが含まれます。ただし、技術対策だけでは事故を防ぎきれません。たとえばアクセス制御の仕組みがあっても、権限付与の運用が曖昧であれば過剰権限が残り、ログを取っていても見直されなければ不審な操作に気付けません。

運用対策

運用対策として重要なのは、ルールを定めることではなく、現場で守られる状態をつくることです。個人情報保護委員会は、安全管理措置として、組織的、人的、物理的、技術的な観点での対応を示しています。これは裏を返せば、教育や承認手続、持ち出し管理、点検、監査、見直しまで含めて初めて情報漏洩対策になるということです。従業員教育を年一回実施しただけで対策済みとは言えず、権限棚卸しやルールの実効性確認が継続して回っているかが問われます。

組織・体制整備

事故が起きたときに誰が判断し、誰が調査し、誰が報告し、誰が公表を担うのかを曖昧にしないことも重要です。個人情報保護委員会のガイドラインは、漏えい等事案の発生時に備えた報告連絡体制や対応体制の整備を求めています。また、JPCERT/CCは、緊急対応、分析、普及啓発、注意喚起、演習を含めた機能の必要性を示しています。情報漏洩対策は、製品導入の話ではなく、事故前提で回る組織づくりの話でもあります。

具体的な情報漏洩対策や運用のポイントについては、以下の記事で詳しく解説しています。
「企業の情報漏洩対策 ―すぐに実践できる防止策と運用のポイント―」

まず何から始めるべきか

情報漏洩対策を強化したい企業が最初にやるべきことは、新しいツールを入れることではなく、「現状把握」です。どの情報を、どこで、誰が、何の目的で扱っているのかが見えていなければ、守るべき対象も優先順位も定まりません。

IPA「中小企業の情報セキュリティ対策ガイドライン」でも、情報資産を洗い出し、台帳化し、重要度に応じて管理することが実践の出発点として示されています。情報漏洩対策は、漠然とした不安に対して製品を足していくのではなく、自社の重要情報と業務フローを見える化するところから始めるべきです。さらにそのうえで、優先順位付けも必要になります。すべてを同じ強さで守るのではなく、情報漏洩時の影響が大きい情報、外部共有が多い情報、委託先を含めて扱われる情報、インターネット経由でアクセスされる情報から順に見直すほうが実務的です。また、「サイバーセキュリティ経営ガイドライン Ver 3.0」でも、リスクの識別と変化に応じた見直しの重要性が示されています。情報漏洩対策は一度整えたら終わりではなく、事業環境や利用サービスの変化に応じて見直し続ける運用そのものが重要です。

どの対策を優先すべきかについては、脆弱性管理の考え方が重要になります。以下の記事もあわせてぜひご覧ください。
「脆弱性管理とは？企業が行うべき脆弱性管理の基本と実践手順【2026年版】」

まとめ

情報漏洩対策とは、個人情報や機密情報が外部に漏れるのを防ぐための技術、運用、組織的な取り組み全体を指します。実際の情報漏洩は、人的ミス、不正アクセス、設定不備、委託先事故など複数の原因で発生し、企業には信用低下、対応コスト増大、事業停止といった深刻な影響をもたらします。だからこそ、企業は「攻撃を防ぐ」だけでなく、「漏れてしまう前提で備える」視点を持たなければなりません。重要なのは、守るべき情報を把握し、優先順位を付け、技術対策と運用対策と体制整備を一体で進めることです。公的ガイドラインでも、体制整備、点検、監査、教育、報告連絡体制の重要性が繰り返し示されています。情報漏洩対策は、担当者任せの部分最適ではなく、企業全体で継続的に回すべき経営課題です。

【参考情報】

個人情報保護委員会「個人データの漏えい等の事案が発生した場合等の対応について（平成29年個人情報保護委員会告示第１号）」
https://www.ppc.go.jp/personalinfo/legal/leakAction/leakAction_detail/
IPA（独立行政法人情報処理推進機構）「中小企業の情報セキュリティ対策ガイドライン第4.0版」
https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf
IPA（独立行政法人情報処理推進機構）中小企業の情報セキュリティ対策ガイドライン
https://www.ipa.go.jp/security/guide/sme/about.html
IPA（独立行政法人情報処理推進機構）「セキュリティ対策の基本と共通対策情報セキュリティ10大脅威 2025 版」
https://www.ipa.go.jp/security/10threats/eid2eo0000005231-att/kihontokyoutsuu_2025.pdf
経済産業省「サイバーセキュリティ経営ガイドラインと支援ツール」
https://www.meti.go.jp/policy/netsecurity/mng_guide.html

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

2026年4月15日（水）14:00～15:00「AI時代のサイバー脅威最前線 ― IPA『情報セキュリティ10大脅威2026』から学ぶ防御戦略 ―」
2026年4月22日（水）14:00～14:30「Swift CSCF v2026変更点解説セミナー
― Control 2.4 (Back Office Data Flow Security)の必須化とCustomer client connectorへの要件適用拡大 ―」
2026年5月13日（水）14:00～15:00「攻撃は本当に成立するのか？ペネトレーションテストで検証する実践的セキュリティ対策（デモ解説）」

最新情報はこちら

編集責任：木下

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

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

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

2026年4月6日2026年4月9日

IPA情報セキュリティ10大脅威2026にみる、AI時代のサイバーリスク

「IPA情報セキュリティ10大脅威 2026に見る、AI時代のサイバーリスク」アイキャッチ画像

近年、生成AIをはじめとするAI技術の進展により、組織におけるAIの活用は急速に広がっています。本記事では、IPA「情報セキュリティ10大脅威 2026」の内容をもとに、AIの利用をめぐるサイバーリスクについて整理するとともに、企業に求められる対応の方向性について解説します。

IPA「情報セキュリティ10大脅威」速報版の記事はこちら。「AIの利用をめぐるサイバーリスク」以外の脅威の項目についても知りたい方は、こちらもぜひあわせてご覧ください。
「【速報版】情報セキュリティ10大脅威 2026 -脅威と対策を解説-」

はじめに

業務効率の向上や新たな価値創出の手段として、多くの企業がAIの導入を進めています。一方でAI利用に伴うリスクについても、十分な注意が求められています。こうした状況を反映して、IPA（独立行政法人情報処理推進機構）が公表した「情報セキュリティ10大脅威 2026」において、「AIの利用をめぐるサイバーリスク」という脅威が初めてランクインし、3位に位置付けられました。

なぜいま「AIの利用」が脅威として注目されるのか

IPA「情報セキュリティ10大脅威」は、前年に発生した社会的影響の大きい事案等をもとに選定されたものであり、順位は単純に危険度の高さを示すものではありません。しかし、AI利用に関するリスクが新たに選出されたことは、企業や組織におけるAI活用の拡大と、それに伴う課題の顕在化を示すものといえるでしょう。

2026年3月12日に公開された、IPA「情報セキュリティ10大脅威 2026」解説書では、AIは有用なツールである一方で、十分な理解がないまま利用した場合、情報漏洩や権利侵害といった問題につながる可能性があると指摘されています。特に、生成AIへの入力内容が外部に取り扱われることによる機密情報の漏洩や、生成された情報の正確性を確認せずに業務に利用することによって発生するトラブルなど、従来の情報システム利用とは異なる観点でのリスクが挙げられています。また、AIは利用者の裾野が広く、専門的な知識がなくても活用できるという特性を持っています。そのため、組織として利用状況を把握しきれないまま、個人単位で業務利用が進むケースも想定されます。このような利用形態は、管理の行き届かないリスク、いわゆるシャドーITに類似した問題を引き起こす可能性があります。

AI利用をめぐる主なリスク

IPAはAIの利用拡大に伴い、いくつかの代表的なリスクが指摘しています。これらは、AIの技術そのものというよりも、その利用方法や特性に起因するものが多い点が特徴です。

情報漏洩リスク
誤情報生成リスク（ハルシネーション）
サイバー攻撃の高度化リスク
利用実態の把握困難（シャドーAI）
権利侵害リスク

生成AIへの入力内容に起因する情報漏洩

クラウドサービスとして提供されるAIに対し、機密情報を入力することで、意図せず外部に情報が送信される可能性があるというリスクです。

AIの出力結果に関するリスク

対話型AIは実在しない情報を生成する（＝ハルシネーション）場合があり、このことを十分に理解せずに利用すると、誤った判断や誤情報発信につながるおそれがあります。

AIの悪用によるサイバー攻撃の高度化

AIを活用することで、攻撃の効率化や手口の巧妙化が進む可能性があります。さらに、組織における利用実態の把握が難しい点も重要なリスクです。

シャドーAIのリスク

個人単位でAIサービスを利用されてしまうことで、組織の目の届かない範囲での利用が発生する可能性があります。

著作権侵害などの権利問題

AIの利用に関する理解不足により、著作権侵害などの権利問題が生じる可能性も指摘されています。

AI利用において想定される主な事例

AI利用に伴うリスクは、特別な環境でのみ発生するものではなく、日常業務の中で自然に発生し得るものです。例えば業務の効率化を目的として、従業員が個人で利用している生成AIサービスを業務に活用するケースが考えられます。メール文面の作成や資料作成の補助としてAIを利用する延長で、社内資料の内容や顧客情報をそのまま入力してしまうことがありえます。生成AIはクラウド上で動作しており、入力した内容はサービス側で処理されます。場合によっては、入力内容がサービスの改善や学習に利用されることもありえます。この点を十分に理解しないまま利用すると、機密情報を外部サービスに送信してしまうことになり、情報漏洩につながるおそれがあるのです。

また、対話型AIの回答をそのまま精査せずに業務に利用してしまうことで問題に発展する可能性もあります。調査や資料作成の過程でAIが生成した情報を十分に確認せずに利用した結果、ハルシネーションの内容を含んだまま社内外に共有してしまうといった事態が起こり得ます。このように、AI利用に伴うリスクは特定の専門領域に限らず、日常業務の延長線上で発生する点に特徴があります。

組織における課題

AIの利用が広がる一方で、組織としてこれらのリスクを適切に管理することにはいくつかの課題があります。

社内でのAI利用の促進とルールの策定のバランス

まず、AI利用に関するルールやガイドラインの整備が追いついていない点が挙げられます。現場での利用が先行する中で、組織としての利用方針が明確でない場合、統一的な管理が難しくなります。また、利用状況の把握が困難であることも大きな課題です。クラウド型のAIサービスは個人単位で容易に利用可能なため、組織として誰がどのように利用しているかを正確に把握することが難しくなります。実際には、想定以上に広範囲で利用が進んでいるケースも少なくありません。さらに、ポリシーを整備しても現場に浸透しないという課題もあります。AIは業務効率の向上に直結するため、利便性を優先してルールが守られないケースや、現場ごとに独自の運用が行われるといった状況も発生し得ます。加えて、AI利用と既存のセキュリティ対策との間にギャップが生じる点も課題です。従来のセキュリティ対策は想定していなかった利用形態が増えることで、管理や統制が追いつかない場面が生じる可能性があります。さらに、利用者への教育不足も課題の一つです。AIの特性やリスクに関する教育や周知が十分でないために、組織として意図しない利用が広がり、統制が効かなくなるおそれがあります。

このように、AIの活用においては、ルール整備や利用状況の把握といった基本的な対応に加え、実際の運用における課題も踏まえた継続的な対応が求められます。

企業が取るべきアクション

AIの利用に伴うリスクに対応するためには、個別の技術対策にとどまらず、組織としての管理と運用の整備が重要となります。AI利用に関しては、ルール整備や教育、基本的なセキュリティ対策の徹底といった観点での対応が求められています。

AIの利用に関するルールやガイドラインの整備
どのような用途でAIを利用してよいのか、入力してよい情報の範囲、利用してはならない行為などを明確に定めることで、利用に伴うリスクを一定程度抑制することが可能となります。
利用状況の把握と管理
AIサービスは個人単位でも容易に利用できるため、組織としてどのように利用されているかを把握し、必要に応じて管理の対象とすることが重要です。これにより、管理の行き届かない利用、いわゆるシャドーAIの発生を抑制することが期待されます。
AI利用者への教育
AIの特性やリスクについて正しく理解させることで、生成結果の確認や適切な情報の取り扱いといった基本的な行動を促すことができます。技術的な制御だけでなく、利用者の理解を前提とした運用が不可欠です。
基本的なセキュリティ対策の徹底・見直し
認証の適切な運用や情報管理の強化といった既存の対策は、AI利用においても引き続き基盤となるものです。その上で、AIの利用が業務に広く組み込まれる中では、従来の対策だけでは対応しきれない場面も想定されるため、AI利用を前提としたセキュリティの見直しや再設計が必要となる可能性もあります。

このように、AIの安全な活用には、ルール、管理、教育、AIを前提とした基本的なセキュリティ対策といった複数の観点からの継続的な取り組みが重要です。

AI時代に求められるセキュリティ支援

こうした課題に対応するためには、組織単独での取り組みだけでなく、専門的な支援の活用も有効です。以下のようなセキュリティ支援の例が挙げられます。

セキュリティ診断・リスクアセスメント
AI利用に伴うリスクを把握するためのセキュリティ診断やリスクアセスメントが重要となります。現状の利用状況や潜在的なリスクを可視化することで、適切な対策の検討につなげることができます。
運用監視体制の強化
AIの利用状況を継続的に監視し、問題の早期発見や対応を行う体制を整備することで、リスクの低減が期待されます。
AI利用ガイドライン策定支援
組織の実態に即したルールを整備し、現場で実際に運用可能な形に落とし込むことが求められます。

さいごに

「情報セキュリティ10大脅威 2026」において、「AIの利用をめぐるサイバーリスク」が新たにランクインしたことは、AI活用の拡大と、それに伴う課題の顕在化を示すものといえます。AIに関するリスクは、新たな技術そのものに起因するというよりも、その利用方法や理解不足に起因する側面が大きい点が特徴です。そのため、対策としては、ルール整備や利用状況の把握、教育といった組織的な対応に加え、基本的なセキュリティ対策を継続して実施することが重要となります。

また、IPAが示す通り、10大脅威の順位は危険度の高さを示すものではなく、自組織の状況に応じて適切にリスクを評価し、優先順位を定めて対策を講じることが求められます。 AIの活用は今後さらに進むことが想定されますが、その利便性を最大限に活かすためにも、リスクを正しく理解し、組織として適切に管理・運用していくことが重要です。

【関連ウェビナーのご案内】
本記事では、生成AIの利用に伴うサイバーリスクと、企業への影響について整理しました。AIの活用が進む一方で、情報漏えいや誤利用、統制の難しさといった課題が現実のものとなっています。では、こうしたリスクは実際にどのように悪用され、どのような攻撃として現れているのでしょうか。2026年4月15日に開催のウェビナーでは、生成AIを悪用した具体的な事例をもとに、サイバー脅威の実態と防御戦略を詳しく解説します。リスクの「背景」だけでなく、「実際に何が起きるのか」を理解したい方は、ぜひご参加ください。

ウェビナー最新情報はこちら

BBSecでは

当社では様々なご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。当当サイトSQAT^® jpのお問い合わせページよりお気軽にお問い合わせください。後日営業担当者よりご連絡させていただきます。

SQAT^® 脆弱性診断

BBSecの脆弱性診断は、精度の高い手動診断と独自開発による自動診断を組み合わせ、悪意ある攻撃を受ける前にリスクを発見し、防御するための問題を特定します。Webアプリケーション、ネットワークはもちろんのこと、ソースコード診断やクラウドの設定に関する診断など、診断対象やご事情に応じて様々なメニューをご用意しております。

SQAT^® ペネトレーションテスト

「ペネトレーションテスト」では実際に攻撃者が侵入できるかどうかの確認を行うことが可能です。脆弱性診断で発見したリスクをもとに、実際に悪用可能かどうかを確認いたします。

編集責任：木下

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

2026年3月24日2026年3月31日

セキュリティ運用は何から始めるべきか担当者が最初に整理すべきポイント

セキュリティ運用を始める際に最初に必要なのはツール導入ではなく、「何を守るか」と「どの順序で対応するか」を整理することです。セキュリティは単発の施策ではなく、継続的に判断と改善を繰り返す活動であるため、最初の設計を誤ると後から修正が難しくなります。本記事では、実務担当者が最初に整理すべきポイントを現場目線で解説します。

セキュリティ運用の全体像や考え方については、以下の記事で整理しています。
「セキュリティ運用とは？属人化を防ぎ継続的に回す基本の考え方」

「セキュリティ運用を始めたいが、何から手を付ければよいのか分からない」。これは多くの企業担当者が最初に直面する課題です。検索でも「セキュリティ運用何から始める」「セキュリティ運用方法」「セキュリティ運用チェックリスト」といったキーワードが増えており、導入段階から運用段階へ関心が移っていることがうかがえます。セキュリティ対策そのものについての情報は多く存在しますが、実際の運用をどの順序で立ち上げるべきかについては、体系的に語られることが少ないのが現状です。

「何を守っているか分からない」状態が最大の問題

セキュリティ運用を始める際、多くの組織がいきなりツール導入やチェックリスト作成に進みます。しかし提供された文脈に基づくと、最初に取り組むべき課題は技術ではありません。「自分たちは何を守っているのか」を把握することです。企業には業務システム、クラウドサービス、端末、アカウント、外部委託先など、さまざまな資産が存在します。ところが実際には、全体像が整理されないまま個別対策が積み重なっているケースが少なくありません。この状態では、どのリスクが重要なのか判断できず、対応が場当たり的になります。資産やシステムの棚卸しは単なる一覧作成ではなく、「事業にとって停止すると困るものは何か」という視点で整理する作業です。優先順位が存在しない運用では、軽微な問題に時間を使い、本来対応すべきリスクを見逃す可能性があります。

守るべき対象や優先順位を整理する際には、サイバー攻撃リスク評価の考え方が役立ちます。「サイバー攻撃リスク評価の進め方：見えない脅威を可視化するプロセスと実践」

セキュリティ運用の最小単位を作る

セキュリティ運用という言葉から大規模な仕組みを想像すると、着手のハードルが高くなります。しかし実務では、まず「最小単位」を作ることが重要です。運用は、情報を集め、それを判断し、必要な対応を行い、その結果を記録するという循環によって成立します。この四つの流れが成立していれば、規模が小さくても運用は始まっています。情報収集とは脆弱性情報や注意喚起の把握を指します。判断とは自社への影響を考える行為であり、対応は設定変更やパッチ適用など具体的な行動です。そして記録は、後から判断理由を再確認できる状態を作ります。多くの組織では対応だけが行われ、判断理由や経緯が残されません。その結果、同じ問題が繰り返されます。最小単位とは作業量を減らすことではなく、循環を成立させることを意味します。

日常業務に組み込める運用とは

セキュリティ運用が続かない理由の一つは、「特別な仕事」として設計されてしまう点にあります。通常業務とは別に毎日実施する作業を増やすと、忙しい時期に必ず停止します。現実的な運用は、毎日行うものではなく、一定の周期や条件に応じて動く仕組みとして設計されます。たとえば月次で確認する作業、更新時のみ実施する確認、アラート発生時に対応する流れなど、業務のリズムに合わせることが重要になります。提供された構成意図に基づくと、セキュリティ運用とは負担を増やすことではなく、既存業務の中に判断ポイントを組み込むことだと理解できます。運用が日常に溶け込んだとき、初めて継続性が生まれます。

よくある失敗例

セキュリティ運用を開始した組織が直面しやすいのが、形骸化です。チェックリストを作成しても実際には確認されず、記録だけが残る状態は珍しくありません。チェックそのものが目的化すると、リスク低減という本来の目的が見えなくなります。また、ツール導入によって運用が自動化されたと誤解されるケースもあります。ツールは検知や可視化を支援しますが、最終的な判断は組織側に残ります。判断基準がなければ、アラートは増えるだけで改善につながりません。さらに問題となるのが属人化の放置です。「詳しい人がいるから大丈夫」という状態は短期的には効率的ですが、長期的には運用停止リスクを高めます。

実際に、運用が形骸化した結果、ランサムウェアや委託先経由の被害につながるケースもあります。
「サプライチェーン攻撃とは ―委託先・外注先リスクから情報漏えいを防ぐ全体像―」

小さく始めて回し続けるコツ

セキュリティ運用を成功させる組織に共通しているのは、最初から完成形を目指さない点です。理想的な運用設計を追求すると準備期間が長期化し、実運用が始まらないことがあります。むしろ重要なのは、小さく始めて継続することです。判断軸を共有し、「どのように考えて対応したのか」を残すだけでも、組織の知識は蓄積されていきます。運用は改善を前提とした活動です。最初から完璧である必要はなく、回しながら修正することで現実に適合していきます。提供された文脈に基づくと、セキュリティ成熟度は導入規模ではなく継続期間によって高まる傾向があると整理できます。

体制の話は次のステップ

ここまでの内容は、担当者レベルで始められるセキュリティ運用の基礎です。しかし運用を継続し、属人化を防ぐためには、やがて役割分担や体制設計が必要になります。誰が判断し、誰が実行し、どこに記録が集約されるのかが明確になることで、運用は個人依存から組織運用へと移行します。ただし体制設計は最初の段階で無理に行う必要はありません。まずは回る運用を作ることが先になります。

運用を属人化させず、継続的に回すための体制づくりについては、次の記事で詳しく解説します。
「セキュリティ運用体制の作り方属人化を防ぐための役割分担と外部活用の考え方」

セキュリティ運用は「始め方」で成否が決まる

セキュリティ運用は高度な技術から始まるものではありません。何を守るのかを理解し、小さな循環を作り、それを日常業務の中で継続することから始まります。チェックリストやツールは重要な要素ですが、それだけでは運用は成立しません。判断・対応・記録という流れが回り始めたとき、セキュリティは単発対応から継続的な活動へ変わります。「セキュリティ運用は何から始めるべきか」という問いへの答えは一つではありませんが、提供された構成意図に基づくと、最初に必要なのは完璧な設計ではなく、回り続ける最小単位を作ることだと言えるでしょう。

本記事は、企業におけるセキュリティ運用支援およびインシデント対応の実務知見をもとに、一般的に公開されているセキュリティ運用の考え方を整理したものです。特定製品への依存を避け、組織運用の観点から解説しています。

運用を属人化させず、継続的に回すためには体制づくりが欠かせません。次の記事で詳しく解説します。
「セキュリティ運用体制の作り方属人化を防ぐための役割分担と外部活用の考え方」

BBSecでは

委託先が関係する情報漏えいでは、自社だけで完結する対応はほとんどありません。複数の関係者が絡むからこそ、事前の整理や体制づくりが結果を大きく左右します。ブロードバンドセキュリティ（BBSec）では、サプライチェーン全体を前提としたインシデント対応体制の整理や、外部起因の事故を想定した初動対応の支援を行っています。「起きてから考える」のではなく、「起きる前提で備える」ことが、これからの企業に求められる姿勢です。もし、委託先を含めた情報管理やインシデント対応に不安を感じている場合は、一度立ち止まって体制を見直すことが、将来のリスクを減らす確かな一歩になるでしょう。

セキュリティ運用サービス（BBSec）

慎重かつ堅実な継続的作業を求められるセキュリティ運用を、セキュリティのプロフェッショナルが24時間・365日体制で支援いたします。
詳細はこちら
※外部サイトへリンクします。

編集責任：木下

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

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

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

インシデント対応が遅れると被害が拡大する―「初動対応」の重要性

セキュリティインシデント対応の基本フロー

社内連携と報告体制

被害範囲の特定

被害の封じ込め・拡大防止

原因調査・ログ解析・フォレンジック調査

復旧対応

関係者への報告・情報共有

再発防止策の検討

BBSecでは

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

まとめ

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

セキュリティインシデントの定義

セキュリティインシデントの種類（例）

実際に発生した主なセキュリティインシデント事例

セキュリティインシデントが企業に与える影響

まとめ

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

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

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

代表的な感染経路

メールによる感染

VPN機器の脆弱性

リモートデスクトップ（RDP）の悪用

ソフトウェアの脆弱性

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

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

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

まとめ

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

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

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

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

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

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

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

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

まとめ

はじめに

ゼロデイ脆弱性とは何か

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

実際の被害事例

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

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

ゼロデイ攻撃の仕組み

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

ゼロデイ脆弱性への対策

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

まとめ

情報漏洩の多くは“想定外”で起きている

情報漏洩の主な原因とは？企業で多い5つのパターン

人的ミス

権限管理ミス

設定不備