セキュリティ
約22分

情報漏洩の原因とは?被害事例から見る侵入経路と対策

執筆・編集Malake株式会社
まず押さえたいこと

この記事は、外部からの不正侵入による情報漏洩とランサムウェア被害を扱います。原因は、「どこから入られたか(侵入口)」と「侵入後に被害を広げた要因」に分けて考えます。

この記事の要点

2025年の警察庁調査で、感染経路に有効回答があった92件のうち、VPN機器からの侵入は66.3%でした。ただし「VPNから侵入された」には、修正されていない脆弱性のほか、漏えいしたID・パスワードやMFAの未設定も含まれます。公表された4事例は、侵入につながった要因と判明している範囲が異なり、一つの対策で防げるものではありません。後半の14項目で、自社で確認が必要な点を洗い出せます。

この記事でわかること

  • 警察庁とVerizonの統計で多い侵入口と、数字を読むときの条件
  • KADOKAWA・Snowflake・LINEヤフー・MOVEitで公表されていること、公表されていないこと
  • 侵入後に被害を広げる構成と、防御を重ねる考え方
  • 自社で確認が必要な項目の洗い出し方

情報漏洩の原因は「侵入口」と「被害を広げる要因」に分けて考える

情報漏洩のニュースを見ると、「社員がフィッシングメールを開いたのだろう」「VPNの脆弱性を突かれたのだろう」と考えがちです。しかし、公表された事例と公的な統計を確かめると、原因はそれほど単純ではありません。

入口を一つ塞いでも、侵入後に重要なシステムまで届く構成が残っていれば、別の入口から入られたときに被害が大きくなります。メールの誤送信や端末の紛失、内部不正による漏洩は扱いません。VPN・SaaS・委託先・公開システムの事例から、自社で確認すべきポイントを整理します。

主な侵入口:統計ではVPN機器とリモートデスクトップが多い

国内のランサムウェア被害では、VPN機器とリモートデスクトップからの侵入が多く報告されています。2025年の警察庁調査で、感染経路に有効回答があった92件のうち、VPN機器からの侵入は66.3%、リモートデスクトップからの侵入は20.7%でした(図1)。2026年上半期は有効回答36件で、VPN機器50.0%、リモートデスクトップ25.0%、その他25.0%です。期間ごとの回答数は多くないため、割合の変化だけで増減の傾向や対策の効果は判断できません。

入口の守りにも課題が残ります。警察庁が無作為に抽出した企業・団体(回答588件)への調査では、VPN機器を利用している組織の52%が最新のパッチを適用しておらず、社外からの業務アクセスの認証が「ID・パスワードのみ」の組織は39.8%でした(図2)。

海外を含むデータ侵害では、Verizonの2026年の報告書で、最初の侵入手段が「脆弱性の悪用」だったものが31%となり、同報告書の19年の歴史で初めて、盗まれた認証情報の悪用を上回りました(図3)。対象はエラーと内部不正を除く約2万件で、主に2025年のデータです。認証情報の悪用(13%)の低下には集計方法の変更も影響しています。侵入後の段階まで含めると、認証情報の悪用は39%で最も多い手口です。

図1国内|ランサムウェア被害に遭った企業・団体

感染経路は、VPN機器とリモートデスクトップが大半

66.3%

VPN機器

20.7%

リモートデスクトップ

2025年、感染経路に有効回答があった92件に占める割合

2025年(令和7年)1〜12月有効回答92件

  • VPN機器66.3%(61件)
  • リモートデスクトップ20.7%(19件)
  • その他13.0%(12件)

2026年(令和8年)1〜6月有効回答36件

  • VPN機器50.0%(18件)
  • リモートデスクトップ25.0%(9件)
  • その他25.0%(9件)

調査対象:警察庁がランサムウェアの被害に遭った企業・団体等に行ったアンケートで、感染経路に有効な回答があったもの。2025年の「その他」には不審メールやその添付ファイル(2件)を含みます。警察庁のリーフレットに掲載された2025年上半期のみの集計(有効回答45件)は、VPN機器62.2%、リモートデスクトップ22.2%、その他15.6%です。

出典:警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」(2026年3月)統計編p.124、警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」(2026年9月)統計編p.143、警察庁「サイバー攻撃の被害に係る企業・団体を対象としたアンケート調査結果及び対策」(2026年1月)

図2国内|無作為に抽出した企業・団体

VPNのパッチと、社外アクセスの認証に課題が残る

52%

VPN機器を利用している組織のうち、最新のパッチを適用していない

VPN機器を利用している組織が対象(警察庁リーフレットの表記)

39.8%

社外から業務でアクセスするときの認証が「ID・パスワードのみ」

この設問に回答した505件の複数回答。次いで電子証明書27.5%、認証アプリ23.2%

調査対象:警察庁が無作為に抽出した企業・団体等2,951件への調査(回答588件)。被害に遭った組織に限りません。

出典:警察庁「サイバー攻撃の被害に係る企業・団体を対象としたアンケート調査結果及び対策」(2026年1月)、警察庁「不正アクセス行為対策等の実態調査」(2025年12月)p.73・p.79

図3海外を含む|データ侵害

最初の侵入手段は、脆弱性の悪用が最多に

31%

最初の侵入手段が「脆弱性の悪用」だったデータ侵害(前年20%)

  • 脆弱性の悪用31%

  • フィッシング16%

  • 認証情報の悪用13%

横棒は0〜40%の尺度

認証情報の悪用は集計方法の変更でも低下しています(従来の数え方では16%)。侵入後の段階まで含めると39%で、最も多い手口です。

調査対象:Verizonが分析した世界のデータ侵害のうち、エラーと内部不正を除く約2万件(主に2025年のデータ)。日本国内の統計ではありません。

出典:Verizon「2026 Data Breach Investigations Report」(2026年5月)p.10・p.15〜16

図1〜3は、対象・期間・集計方法が異なる別々の調査です。数値を足し合わせたり、直接比べたりはできません。図1の割合は、公表された件数から算出しています(小数第2位を四捨五入)。確認日:2026年10月6日

主な侵入口と、複数の入口で使われる手口

図4は、主な侵入口と、複数の入口で使われる手口を分けて示したものです。たとえばフィッシングで盗まれたID・パスワードは、VPNにもSaaSにも使われます。フィッシング対策やVPNの更新など、一つの対策だけを行っても、ほかの入口は残ります。

図4

主な侵入口を5つのグループで整理した例

インターネット
  1. 01VPN機器・ファイアウォール

    悪用されるもの:未修正の脆弱性、漏えいしたID・パスワード

    国内統計で最多

  2. 02リモートデスクトップ(RDP)

    悪用されるもの:推測されやすいパスワード、不要なアカウント

    国内統計で2番目

  3. 03SaaS・クラウドのログイン

    悪用されるもの:盗まれたID・パスワード、MFAの未設定

    Snowflake

  4. 04公開しているWebアプリ・ファイル転送

    悪用されるもの:認証の前に悪用できる脆弱性

    MOVEit Transfer

  5. 05委託先・グループ会社からの接続

    悪用されるもの:委託先PCのマルウェア感染、共通の認証基盤

    LINEヤフー

社内のID・端末・サーバ・データ

複数の入口で使われる手口

  • 未修正の脆弱性
  • 漏えいしたID・パスワード
  • フィッシング
  • Infostealer(情報を盗むマルウェア)
  • 推測されやすいパスワード・不要なアカウント
  • 設定の不備
記事で扱う統計と事例に出てくる入口をまとめたもので、すべての攻撃経路を網羅する分類ではありません。下段の手口は、複数の入口で使われます。

「VPNから侵入された」は「VPN製品に脆弱性があった」と同じではない

警察庁は2025年上半期の分析で、VPNやリモートデスクトップ用の機器から侵入された原因として、機器のID・パスワードが非常に安易だったことや、不要なアカウントが管理されずに残っていたことを挙げています。VPN機器からの侵入には、機器の脆弱性に加えて、認証の弱さによるものも含まれます(図5)。

「VPNは危険だから廃止する」という結論も早すぎます。VPNを別の仕組みに置き換えても、弱い認証や、接続後に社内全体へ届く構成が残れば、同じ問題が起きます。VPNを使い続けるか、アプリ単位で接続する方式へ移るかの判断は、ゼロトラストの原則と導入ロードマップで整理しています。

図5

「VPN機器からの侵入」の主な原因と、被害を広げる要因

「VPNから侵入された」

は、次と同じ意味ではありません。

「VPN製品に脆弱性があった」

侵入の主な原因

機器の脆弱性

  • 修正版が公開されている既知の脆弱性が、まだ適用されていない
  • 修正版がまだない脆弱性を突かれる

修正版の適用で、対象となる既知の脆弱性を修正できます。修正版がない脆弱性には効かず、適用前に侵入されていた場合は、更新とは別に侵入の有無を調べます。

認証の弱さ

  • VPNアカウントのID・パスワードが漏えいしている
  • MFA(多要素認証)が設定されていない
  • 推測されやすいパスワードや、使われていないアカウントが残っている

機器を最新にしても防げません。MFA、漏えいした認証情報の確認、アカウントの棚卸しで対処します。

侵入後に被害を広げる要因(侵入の原因とは別)

VPN接続後に、社内ネットワークへ広くアクセスできる構成

接続先の限定と、ネットワーク・権限の分離で、届く範囲を狭めます(図6・図8)。

警察庁の統計の「VPN機器からの侵入」には、これらの原因が区別されずに含まれます。下段の構成は侵入の原因ではありませんが、どの原因で入られた場合にも被害を広げます。

公表された4つの事例を比べる

ここからは、公式に公表された4つの事例を見ます。4つの事例では、認証情報の窃取、委託先からの接続、公開システムの脆弱性など、侵入につながった要因と公表されている範囲が異なります。表1で概要を比べ、各社・調査機関の公表内容は次の節で確認します。

自社に同じ弱点がないかは、後半の14項目の簡易チェックで確認できます。

表1

4つの公表事例の概要

  • KADOKAWA2024年6月

    侵入口
    公表資料では詳細不明
    侵入のきっかけ(公表内容)
    従業員のアカウント情報の窃取(フィッシングなどと推測。窃取の経路・方法は不明)
    被害につながった要因(公表内容)
    公表資料では詳細不明
    確認すること
    • ID・MFA
    • 端末の監視
    • 権限とネットワークの分離
  • Snowflake利用企業2024年

    侵入口
    SaaSのログイン
    侵入のきっかけ(公表内容)
    Infostealerで盗まれた利用企業の認証情報。Snowflake社の環境の侵害を示す証拠はない
    被害につながった要因(公表内容)
    MFAの未設定、数年間変更されていない認証情報、接続元の制限なし
    確認すること
    • SaaSのMFA・SSO
    • 認証情報の失効
    • 接続元の制限
  • LINEヤフー2023年10月

    侵入口
    委託先・関係会社からの接続
    侵入のきっかけ(公表内容)
    委託先の従業者が所持するPCのマルウェア感染
    被害につながった要因(公表内容)
    関係会社と共通の認証基盤と、関係会社のシステムからのネットワーク接続の許可
    確認すること
    • 委託先の接続
    • 認証基盤の分け方
    • ネットワークの分離
  • MOVEit Transfer2023年5〜6月

    侵入口
    インターネットに公開したファイル転送サーバ
    侵入のきっかけ(公表内容)
    認証なしで悪用できるSQLインジェクションの脆弱性(CVE-2023-34362)
    被害につながった要因(公表内容)
    修正版が出る前から悪用された(当時は知られていなかった脆弱性)
    確認すること
    • 公開資産の把握
    • 脆弱性情報と修正
    • 修正までの公開停止
「公表資料では詳細不明」は、公表資料に記載がないことを示し、問題がなかったという意味ではありません。「確認すること」は公表内容を踏まえたMalakeとしての一般的な提案です。公表内容の詳細と出典は、次の節に記載しています。

4つの事例で公表されていること・公表されていないこと

各事例は、各社や調査機関が公表した内容だけを基に、「公表されていること」「公表されていないこと」「この事例から学べること」に分けて記載します。公表されていない事実は推測で補いません。「この事例から学べること」は、公表内容を踏まえたMalakeとしての一般的な提案です。

KADOKAWA:従業員のアカウント情報で社内ネットワークに侵入された

2024年6月8日、KADOKAWAグループの複数のサーバーにアクセスできない障害が発生しました。同社の調査で、ニコニコを中心としたサービス群を標的に、グループのデータセンター内にあるドワンゴ専用ファイルサーバーなどが、ランサムウェアを含む大規模なサイバー攻撃を受けたことが確認されています。同年8月5日、同社は情報漏洩の調査結果と原因を公表しました。

公表されていること
  • 外部への漏洩が確認された個人情報は254,241人分。取引先、N中等部・N高等学校・S高等学校の在校生や保護者などの一部、従業員などの情報が含まれる(2024年8月5日時点)。
  • 社外のセキュリティ専門企業の調査によると、フィッシングなどの攻撃で従業員のアカウント情報が窃取されたことが、根本原因と推測されている。
  • 窃取されたアカウント情報によって社内ネットワークに侵入され、ランサムウェアの実行と個人情報の漏洩につながった。
公表されていないこと
  • アカウント情報が窃取された経路と方法。同社は「現時点ではその経路および方法は不明」としており、フィッシングは推測にとどまる。
  • どのシステムのアカウントだったか、多要素認証(MFA)の設定状況、侵入後にどのように権限や範囲を広げたかといった技術的な詳細は、この公表では示されていない。
この事例から学べること
  • 社員がフィッシングにだまされないことだけに頼ると、アカウント情報が盗まれた時点で防ぐ手段がなくなる。アカウント情報が盗まれても、MFA、会社が管理する端末かの確認、権限やネットワークの分離で、その先へ進ませない構成になっているかを確認する。

Snowflake:盗まれた認証情報で、MFAのないSaaSアカウントへ

2024年、クラウド型のデータ基盤であるSnowflakeを利用する複数の企業で、データが盗まれ、恐喝される事案が相次ぎました。調査にあたったMandiant(Google Cloud)は、攻撃者グループをUNC5537と名付け、2024年6月11日に調査結果を公表しています。

公表されていること
  • Mandiantの調査では、Snowflake社の企業環境が侵害されたことを示す証拠は見つかっていない。Mandiantが対応したすべての事案は、利用企業側の認証情報の窃取にさかのぼる。
  • 認証情報は主に、Snowflakeの管理下にない端末に感染したInfostealer(情報を盗むマルウェア)から流出していた。攻撃に使われたアカウントの少なくとも79.7%は、以前に認証情報が流出していた。
  • 複数の調査では、Infostealerの最初の感染が、ゲームや違法コピーのソフトのダウンロードなど私的な用途にも使われていた、委託先の端末で起きていた。
  • 被害を許した主な要因として、MandiantはMFAが設定されていなかったこと、盗まれた認証情報が長いものでは4年間変更されず有効だったこと、信頼できる接続元だけに限定する設定(ネットワーク許可リスト)がなかったことの3点を挙げている。
  • MandiantとSnowflakeは、影響を受けた可能性のある約165の組織に通知した。
公表されていないこと
  • Mandiantの報告は被害企業を特定しておらず、各社でどのデータがどの範囲で盗まれたかは含まれていない。個別の被害は、各社の公表による。
この事例から学べること
  • 守る対象は社内ネットワークに限らない。SaaSも、MFA、端末の管理、接続元などのアクセス条件、ログの監視まで含めて管理する。委託先や退職者、長く使われていないアカウントも対象になる。SaaSのアカウントと権限を棚卸しする方法は、SaaSアカウント管理の実務で扱っている。

LINEヤフー:委託先PCのマルウェア感染から、共通の認証基盤を経由して

2023年11月27日、LINEヤフーは、第三者による不正アクセスを受け、ユーザー情報・取引先情報・従業者等に関する情報が漏えいしたと公表しました。2024年2月14日には、原因と再発防止策を公表しています。

公表されていること
  • 契機は、同社の関係会社である韓国NAVER Cloud社の委託先で、LINEヤフーの委託先でもある企業の従業者が所持するPCのマルウェア感染。
  • NAVER Cloud社と共通の認証基盤で管理されていた旧LINE社の社内システムへ、ネットワーク接続を許可していたことから、NAVER Cloud社のシステムを介して、2023年10月9日に不正アクセスが行われた。
  • 2023年11月27日時点で、漏えい(可能性を含む)が確認された個人情報は、ユーザーに関する情報302,569件、取引先等に関する情報86,105件、従業者等に関する情報51,353件。
  • 同社は原因を「委託先企業への安全管理措置」「NAVERと旧LINE社間のシステム・ネットワークのあり方」「旧LINE社における従業員システムのセキュリティ」の課題と捉え、認証基盤とネットワークの分離、従業員向けシステムでの二要素認証の標準化、委託先管理の強化を再発防止策として示した。
公表されていないこと
  • 感染したマルウェアの種類や、感染から不正アクセスに至るまでの技術的な手順の詳細は、これらの公表には含まれていない。
この事例から学べること
  • 「委託先だから」「グループ会社だから」「社内ネットワークの中だから」と信頼する考え方では、つながっている組織の一つが侵害されると影響が自社に及ぶ。委託先からの接続にも、会社が管理する端末の利用、MFA、アクセス先の限定を適用する。

MOVEit Transfer:パスワードやMFAでは防げない、公開システムの脆弱性

2023年5月から6月にかけて、Progress Software社のファイル転送製品MOVEit Transferの脆弱性(CVE-2023-34362)が悪用され、多くの組織でデータが盗まれました。米国のCISA(サイバーセキュリティ・インフラストラクチャセキュリティ庁)とFBIの共同勧告は、公開情報をもとに、ランサムウェアグループCL0P(TA505)が2023年5月27日から悪用を始めたとしています。

公表されていること
  • CVE-2023-34362は、MOVEit TransferのWebアプリケーションにあるSQLインジェクションの脆弱性で、認証されていない攻撃者がデータベースにアクセスできる。CVSS v3.1の基本値は9.8(緊急)。
  • 当時は知られていなかった脆弱性として悪用された。インターネットに公開されたMOVEit Transferに「LEMURLOOT」と呼ばれるWebシェルが設置され、データベースからデータが盗まれた。
  • CISAは、悪用が確認された脆弱性の一覧(KEV)に、2023年6月2日に追加した。
  • Progress社は、修正版を適用する前の最初の手順として、MOVEit TransferへのHTTP・HTTPSの通信をすべて遮断するよう案内した。
公表されていないこと
  • 被害を受けた組織の一覧や、組織ごとに盗まれたデータの範囲は、CISAの勧告やNVDの情報には含まれていない。個別の被害は、各組織の公表による。
この事例から学べること
  • パスワードを強くしても、MFAを導入しても、認証の手前で悪用される脆弱性は防げない。インターネットに公開している資産を把握し、ベンダーの勧告やCISAのKEVなどの脆弱性情報を確認して、修正版を適用する。
  • 修正版を適用するまでの措置は、ベンダーの勧告に従って判断する。公開停止やアクセス制限を検討し、WAFによる緩和は、対象の脆弱性に有効な対策が確認できる場合に限って利用する。WAFは修正版の代わりにはならない。修正版を適用した後も、適用前に侵入されていなかったかは別に確認する。
  • 修正には時間がかかりやすい。Verizonの2026年の報告書は、1万3,000以上の組織の環境でスキャナーが見つけた、KEV掲載の脆弱性の修正状況を集計している。2025年中にすべての該当箇所が修正されたのはそのうち26%で、修正完了までの日数の中央値は43日だった。

侵入後に被害を広げる要因と、防御の考え方

侵入口とは別に、侵入後にどこまで届くかが被害の大きさを左右します。警察庁は、ランサムウェア攻撃の代表的な流れを次のように説明しています。攻撃者は、未修正の脆弱性、漏えいした認証情報や簡易なパスワード、設定の不備などを悪用してネットワークに侵入し、管理者権限の奪取やセキュリティの無効化を試みながら、重要なデータやバックアップを探します。データを持ち出した後に暗号化を実行し、復旧を妨げるため、バックアップも一緒に暗号化される場合が多いとしています。

図6は、内部の通信と権限が広く許可された構成の例です。このような構成では、VPNなどの入口を通過して管理者権限を奪われると、ファイルサーバやバックアップまで同じ権限で届くおそれがあります。実際の構成は企業ごとに異なるため、自社の環境でどこまで届くかを確認します。

図6

内部の通信・権限が広く許可された構成の例

  1. 盗まれたID・パスワード、または機器の脆弱性

    起点。どの入口から入られた場合も同じ

  2. VPN

    ID・パスワードだけで通過できる設定の場合

  3. 社内ネットワーク

    PC、サーバ、バックアップの間の通信を広く許可している場合

  4. Active Directory(社内のID管理)

    管理者権限を奪われると、同じ権限で多くのサーバに入れる場合がある

侵入後に届く範囲(この例では、同じネットワーク・同じ権限で到達できる)

  • ファイルサーバ
  • NAS
  • バックアップ
  • 業務システム
  • 管理系システム

琥珀色の枠:入口を通過した後、追加の確認なしに届く範囲

構成の一例で、実際の構成は企業ごとに異なります。この例では、VPNを一度通過すると社内の広い範囲へ届き、管理者権限まで奪われると、バックアップも同じ権限で削除・暗号化されるおそれがあります。

ウイルス対策ソフトとバックアップがあっても、被害を防げなかった組織

警察庁が2025年にランサムウェアの被害に遭った企業・団体等に行ったアンケートでは、多くの組織がウイルス対策ソフト等とバックアップを用意していました(図7)。ウイルス対策ソフト等を導入していたのは119件中105件ですが、検出状況に回答した89件のうち64件は検出がありませんでした。バックアップを取得していたのは116件中105件ですが、復元結果に回答した99件のうち79件は復元できず、その理由(有効回答72件)は「バックアップの暗号化・消去」が48件で最も多くなっています。

製品やバックアップがあるかだけでは、被害を止められるかは判断できません。攻撃者が管理者権限を奪った場合に、検知の仕組みやバックアップまで同じ権限で止められたり消されたりしない構成かを確認します。

図7国内|ランサムウェア被害に遭った企業・団体(2025年)

ウイルス対策ソフトとバックアップがあっても、被害を防げなかった組織が多い

  • 71.9%

    ウイルス対策ソフト等による検出がなかった

    64件 / 有効回答89件

    ウイルス対策ソフト等を導入していた組織は、119件中105件

  • 79.8%

    バックアップから復元できなかった

    79件 / 有効回答99件

    バックアップを取得していた組織は、116件中105件

  • 66.7%

    復元できなかった理由が「バックアップの暗号化・消去」

    48件 / 有効回答72件

    ほかの理由は、運用不備19件、その他5件

調査対象:警察庁が、2025年にランサムウェアの被害に遭った企業・団体等に行ったアンケート。設問ごとに有効回答数が異なります。割合は件数から算出しています。

出典:警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」(2026年3月)統計編p.128〜130・p.135〜136

1つの防御が破られても、次で止める構成

侵入を100%防ぐことはできません。そのため、認証情報が1つ盗まれても、公開しているシステムが1台侵害されても、それだけでは重大な事故にならない構成を目指します。図8は、利用者がアプリケーションに届くまでに確認を重ね、内部も用途ごとに分けた構成の例です。

この考え方の土台になるのが、ゼロトラストです。NISTのSP 800-207は、物理的な場所やネットワーク上の場所だけを理由に、端末や利用者のアカウントを暗黙に信頼しないことを前提としています。ゼロトラストは特定の製品を指す言葉ではなく、VPNをZTNA(アプリ単位で接続を許可する仕組み)の製品に置き換えれば完成するものでもありません。原則と段階的な進め方は、ゼロトラストの解説記事にまとめています。

どの層にも限界があります。MFAは、盗まれたパスワードだけでのログインを防ぐ効果の大きい対策ですが、MOVEitのような認証の手前で悪用される脆弱性には効きません。また、MFAでも、ワンタイムパスワードなど認証コードを入力する方式は、偽のサイトにコードを中継されると突破される場合があります。NISTのSP 800-63B-4も、認証コードを手入力する方式をフィッシング耐性のある方式とはみなしていません。パスキーなど、フィッシング耐性のある認証方式の検討も必要です。具体的な導入と運用は、管理者と従業員のランサムウェア対策で扱っています。

図8

多層防御の構成の例:1つの層が破られても、次の層で止める

  1. 1ID基盤

    Identity Provider

    確認すること
    誰のアカウントか。退職・異動が反映されているか
    止められる例
    退職者や使われていないアカウントでのログイン
  2. 2MFA・パスキー

    MFA / Passkey

    確認すること
    本人が操作しているか。方式によりフィッシングへの強さが異なる
    止められる例
    盗まれたパスワードだけでのログイン
  3. 3端末の確認

    Device Trust

    確認すること
    会社が管理する端末か。OSの更新やEDRは有効か
    止められる例
    管理されていない端末からのアクセス
  4. 4条件付きアクセス

    Conditional Access

    確認すること
    接続元、時間帯、サインインの危険度
    止められる例
    普段と異なる国や環境からの不審なサインイン
  5. 5アプリ単位の接続

    ZTNA / Application Access

    確認すること
    そのアプリを使う権限があるか
    止められる例
    社内ネットワーク全体への到達
必要なアプリケーションにだけ接続する

内部も用途ごとに分ける(ゾーンの間は、必要な通信だけを許可)

  • 利用者のPC
  • 業務サーバ
  • 管理系
  • バックアップ本番と別の認証・権限
  • IoT・カメラ
どの層も、単独では侵入を100%は防げません。パスワードが盗まれてもMFAで、MFAを通過されても端末の確認や接続先の限定で、それも越えられた場合はネットワークの分離とバックアップの保護で、被害を重大事故に至る前に止めることを目指します。

よくある質問

Q. VPNは廃止した方がよいのですか?

一律には言えません。VPN経由の侵入には、パッチの未適用、弱い認証、不要なアカウントなどが含まれ、接続後に社内全体へ届く構成があると被害が広がります。VPNを使い続ける場合は、これらを確認して改善します。アプリ単位で接続する方式へ移る場合も、認証と接続後の範囲を設計し直さなければ、同じ問題が残ります。

Q. MFAを導入すれば、侵入されないのですか?

MFAは、盗まれたID・パスワードだけでのログインを防ぐうえで効果の大きい対策ですが、それだけで侵入を防げるわけではありません。認証の手前で悪用される脆弱性には効かず、認証コードを入力する方式は、偽のサイトにコードを中継されると突破される場合があります。パスキーなどフィッシング耐性のある方式を検討し、端末の確認、パッチの管理、ネットワークの分離と組み合わせます。

Q. 従業員が50名ほどの会社でも、同じ確認が必要ですか?

必要です。警察庁の統計では、ランサムウェア被害の約6割を中小企業が占めています(2025年、2026年上半期)。確認する対象や負担は、従業員数だけでなく、利用するサービス・機器・委託先の構成によって異なります。まずは、インターネットに公開している機器、管理者アカウント、バックアップなど、被害への影響が大きい箇所から確認します。

自社で確認する:14項目の簡易チェック

4つの事例と統計を踏まえ、自社で確認しておきたい項目を14にまとめました。確認できた項目にチェックを入れると、チェックが付いていない項目が「確認が必要な項目」として一覧になります。

チェックが付かない項目は、未実施とは限りません。担当者に聞かないと分からない項目も、確認が必要な項目として扱います。

セキュリティ簡易チェック(14項目)

確認できた項目にチェックを入れます。分からない項目は、チェックせずに残します。

確認できた項目を選択

確認できた項目0 / 14

チェックを入れると、チェックが付いていない項目が「確認が必要な項目」としてここに表示されます。

チェックの数は、確認できた項目の数です。安全性や対策の成熟度を表すものではなく、14項目すべてにチェックが付いても、十分な対策であることを保証しません。MFAの適用範囲やバックアップの保護のように、1つの項目が未確認なだけでも、優先して確認が必要になる場合があります。この簡易チェックは正式なセキュリティ評価ではなく、入力した内容は送信も保存もされません。

セキュリティ対策は「製品選び」より現在地の把握から

簡易チェックの中には、自社だけでは判断しにくい項目があります。たとえば「クライアントPCから重要なサーバへ自由にアクセスできない」かどうかは、ネットワーク機器の設定、Active Directoryの権限、サーバ側の制限を合わせて確認しなければ分かりません。「バックアップが本番環境と異なる認証・権限で保護されている」かどうかも、バックアップ製品の画面だけでは判断できない場合があります。

企業のIT環境は、Microsoft 365やGoogle Workspace、Active DirectoryやEntra ID、VPN・ファイアウォール、クラウド、NASやファイルサーバ、各種SaaS、端末、拠点のネットワークと、組み合わせが企業ごとに異なります。EDRの導入やVPNの廃止といった個別の対策を決める前に、侵入口から侵入後に届く範囲までを順に確認し、優先順位を付けます。Malakeでは、特定の製品の販売を前提とせず、現状把握、リスク評価、優先順位付け、改善案の順で企業のIT環境を確認しています。

自社で対策を進める場合は、次の記事も参考になります。

PHPを利用するサイトの影響や保守先への確認は、PHPの脆弱性対応の進め方で整理しています。

貴社のセキュリティ環境を、構成全体から確認します。

VPN・ファイアウォール、ID管理(Active Directory・Entra ID、Microsoft 365、Google Workspace)、端末、社内ネットワーク、SaaS、バックアップについて、侵入口と、侵入後に届く範囲の両面から現状を確認し、優先して見直す項目を整理します。特定の製品の導入を前提にはしません。初回相談(無料)では、現状と気になっている点を伺い、支援の範囲を確認します。

IT環境・セキュリティ診断について相談する

診断の後の改善や、日々のIT運営まで継続して任せたい場合は、外部IT責任者・IT顧問の支援内容をご覧ください。