2026年4月25日
諸角　昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のない意見をいただければ幸いである。

CSAジャパン・ブログでは、「VPNは本当に危ないのか」というテーマで2回の投稿を行った。最初のブログでは、VPNをめぐるリスクの構造を三層に分けて整理し、国内の統計データの正確な読み方、よくある意見への答え、そして対策の方向性について考察した。続編では、VPNの設計思想の問題に対してZTNAが提供している「ダークIP」について掘り下げてみた。なお、これらについては、本ブログの最後に記述する参考資料から参照していただきたい。

これらの2回のブログで十分整理できたと考えていたが、先日の「SaaSセキュリティリーグ」において小規模組織の観点がカバーできていないと指摘された。確かに、「VPNは危ない、ZTNAに移行すべきだ」という議論において、多くの場合それは大規模組織を念頭に置いた話である。専任のセキュリティチームがあり、IdPが整備され、ある程度の予算がある組織を前提にしている。では、IT担当者が一人または兼任で、予算も限られた小規模組織はどうすればいいのか。

本ブログでは、小規模組織に合わせた現実的な選択肢を整理してみたい。なお、本ブログの作成にあたって、「SaaSセキュリティリーグ」の皆様に管理的・技術的な観点でのご教授をいただいた。この場を借りて感謝いたします。

小規模組織でも「リスクの構造」は同じ

まず認識しておくべきことは、VPNのリスク構造は組織の規模に関係なく同じであるということである。VPNのリスクの構造を三層に整理した以下の内容である。

• 第1層：製品脆弱性（CVE）：　パッチを当てていなければ規模に関係なく標的になる
• 第2層：認証情報管理：　漏洩パスワード・MFA未設定・ゾンビアカウントは小規模組織ほど放置されやすい
• 第3層：設計思想の欠陥：　公開ポートによるアタックサーフェスとラテラルムーブメントの許容は構造的な問題であり規模は関係しない

パッチ適用の遅れ、退職者アカウントの放置、外部ベンダーへのVPN発行後の管理不足等は、大企業より小規模組織で起きやすい。Colonial Pipeline事件も「IT担当者が見落としていた休眠アカウント」が発端であった。したがって、「うちは小さいから狙われない」は誤解であり、ランサムウェア攻撃の多くは組織の規模を問わず自動スキャンで脆弱な機器を探し出している。小規模組織は「狙いやすい標的」になりうる。

大規模組織と小規模組織の違い

以下にこの違いについて表でまとめてみる。完全な内容ではなくあくまで特徴的な点をまとめたものである。

大規模組織向けのZTNA移行論では「まずIdPを整備し、ポリシー設計チームを組んで…」という前提が当たり前のように語られる。しかし小規模組織にとってこれらは高いハードルになりうる。IdPについては、Microsoft 365やGoogle Workspaceをすでに導入している組織であれば実質的に整備済みであり、このハードルは低い。一方、オンプレADのみの組織では、クラウドIdPの整備が先行課題になる。いずれにせよ、VPNを使い続けることのリスクは規模に関係なく存在する。

したがって、「大規模組織と同じアーキテクチャを目指しながら、小規模組織の制約（人員、予算、IT成熟度）に合った現実的な進め方はないか」ということを考えてみたい。以下にその選択肢を示す。

小規模組織向けの現実的な選択肢

選択肢A：クラウドZTNA（SaaS型）の直接導入

小規模組織にとって最も現実的なアプローチは、SaaS型のZTNAを直接導入することであると考える。近年、以下に示すように中小向けの価格設定、シンプルな管理画面を持つ製品が増えているので、これを利用することを考えたい。

これらの製品の共通点は「IdPとしてGoogle WorkspaceやMicrosoft 365を使える」という点である。Microsoft 365やGoogle Workspaceを導入済みの組織であれば、ZTNAに必要なIdP機能はすでに手元にある。オンプレADのみの組織と異なり、IdP整備のためだけに新たな製品、費用が発生しない点でZTNA移行のハードルが低い。ただしライセンスプランによっては条件付きアクセスやデバイスポスチャ評価に必要な機能が含まれない場合があるため、事前に確認が必要だ。

【技術的な補足】三層への対応と残存リスク

第1層（CVE）：　VPNアプライアンスを廃止するためダークIPが実現し、CVEを突く直接攻撃の入口がなくなる。ただしIdP自体は外部公開されており、そこへの攻撃は別途対策が必要になる。
第2層（認証情報）：　IdP連携でMFAを必須化しやすく、アカウントの即時失効も容易になる。残存リスクはMFA疲労攻撃・AiTMフィッシングのようなセッション乗っ取りなどがある。
第3層（設計思想）：　「公開ポートをなくす」と「認証後のネットワーク全体アクセスを制限する」の両方が実現できる。残存リスクはポリシー設計が粗い場合の形骸化と、移行期にVPNとZTNAが並存することによるハイブリッドリスクが考えられる。

【補足】ADドメイン非参加の独立ネットワーク（子会社・グループ会社等）への適用

子会社やグループ会社が、親会社のADドメインに参加しておらず、IdPやZTNA基盤を含めて独立した環境を運用していることがある。このような場合でも、エージェント型ZTNAは各組織単位で独立して導入・運用できる。ZTNAの実装は必ずしも親会社とのIdP統合やディレクトリ統合を前提とするものではなく、各組織が自らのIdPとポリシー基盤を用いてアクセス制御を完結させる構成も技術的に成立する。
一方で、IdPとZTNA基盤が組織ごとに分離された構成では、アクセス制御ポリシーと認証・認可の判断が各組織内で完結するため、組織横断的なポリシーの一元適用や統合的なアクセス制御は実現されない。親会社と子会社の間でユーザー属性やデバイス状態に基づく統一したコントロール（条件付きアクセスやリスクベース認証など）を実現したい場合は、IdPの統合またはSAML・OIDCによるフェデレーションが前提条件になる。
整理すると、エージェント型ZTNAはIdP統合の有無にかかわらず導入できる。ただし「各組織が独立して運用する構成」と「組織横断的に統合して運用する構成」では実現できることが異なる。そこで、まず子会社単体でZTNAを導入し、その後グループ全体でのIdP統合・フェデレーションを段階的に進めるアプローチが現実的と思われる。
なお、グループ共通のIDaaS基盤が整備されていればスムーズだが、現実にはアカウント構成が組織ごとに異なるケースが多い。製品によって対応は様々だが、以下のようなパターンで環境に合わせた接続設計を検討することが考えられる。

• IDaaSとのSSO連携：　子会社が独自のIdPを持つ場合、SAML・OIDCによるフェデレーションでZTNA製品と連携させる（上記内容）
• インストーラへのユーザー情報埋め込み：　エージェントのインストーラにユーザー情報をあらかじめ組み込み、端末単位で設定を完結させる
• メール認証の利用：　IDaaS統合が難しい環境では、メールアドレスベースの認証で接続を許可する構成も選択肢になる

いずれのパターンも、組織単位、場合によっては端末単位での個別設計が必要になる。「まず動かせる構成で導入し、IdP統合は並行して進める」というような段階的なアプローチが現実的と考える。

選択肢B：外部ベンダーアクセスだけをZTNA化する

全社員のリモートアクセスをZTNAに切り替えるのが難しくても、「外部ベンダー・委託先のアクセスだけをZTNAに変える」という部分的なアプローチは小規模組織でも現実的である。
外部ベンダーへのVPN発行は、小規模組織でも特にリスクが高い部分である。保守ベンダーが退職しても誰も気づかずアカウントが残る、複数のベンダーが同じVPN認証情報を共有しているなど、こういった問題は小規模組織では起きやすい。
ZTNAで外部ベンダーのアクセスを管理することで、以下のような効果が得られる。

• アクセスを「必要なサーバー、ポートのみ」に限定できる（保守対象サーバーへのSSHのみ等）
• 契約終了時にアクセス権を即時削除できる（ゾンビアカウントの防止）
• アクセスログを記録し、不審な操作を把握できる

【技術的な補足】三層への対応と残存リスク

第1層（CVE）：　外部ベンダー向けのVPNアプライアンスをなくすことができるが、社員向けVPNが残る場合は第1層のリスクが継続する。
第2層（認証情報）：　外部ベンダーのゾンビアカウント、アクセス過剰という最も典型的な第2層のリスクを効果的に抑制できる。SDPアーキテクチャを採用することで、ベンダーデバイスにエージェントなしで制御を適用できる。
第3層（設計思想）：　外部ベンダーの部分ではラテラルムーブメントを抑制できるが、社員向けVPNが残る限りそちらの設計思想の欠陥は解消されない。部分的な対処にとどまる点を認識した上で、段階移行の第一歩として位置づけるのが現実的と思われる。

選択肢C：VPNを維持しながら第2層を徹底する

今すぐZTNAに移れない場合でも、認証情報管理（第2層）を徹底するだけでリスクを大幅に低減できる。これは予算がほぼかからない対策でもあるし、「VPNを使い続けながらできる最低限の対策」と考えられる。ZTNAへの移行計画と並行して、今日から実施できるものである。

• 全VPNアカウントにMFAを設定する
• 退職者・外部委託先の未使用アカウントを今すぐ棚卸しして無効化する
• パスワードポリシーを強化し、過去に漏洩したパスワードが使われていないか確認する。Have I Been Pwned等のサービスで自社ドメインのメールアドレス漏洩を確認するのも有効である。

【技術的な補足】三層への対応と残存リスク

第1層（CVE）：　VPNを維持するため第1層のリスクはそのまま残る。パッチ未適用の期間が「無防備な状態」であることは変わらない。
第2層（認証情報）：　MFA徹底とアカウント棚卸しで最も頻度の高いリスクを直接低減できる。コストがほぼかからない割に効果が大きいと思われる。残存リスクはMFA疲労攻撃・AiTMフィッシングなどがある。
第3層（設計思想）：　VPNの設計思想の欠陥は解消されない。公開ポートは残り続け、認証後のラテラルムーブメントも許容されたままである。

選択肢D：MSP（マネージドサービスプロバイダ）の活用

IT担当者が一人または兼任の組織では、ZTNAの導入・運用を自社でやりきることが難しい場合がある。その場合、ZTNAの導入・運用をMSPに委託するアプローチが現実解になりうる。
日本国内でもZTNAの導入支援・運用代行を提供するMSPが増えつつある。ポリシー設計・監視・インシデント対応を含めて委託することで、「担当者が一人でも動かせる」体制を作れる可能性がある。

ただし、MSPに委託する場合は、責任分界点、ログへのアクセス権、インシデント発生時の対応などのSLAを契約段階で明確にしておくことが重要である。「任せきり」にすることは、問題が起きたときの対応が遅れるリスクになる。

【技術的な補足】三層への対応と残存リスク

第1層・第3層（CVE・設計思想）：　選択肢Aと同様の効果が得られる。MSPがZTNAを運用することでVPNアプライアンスを廃止でき、ダークIPと最小権限アクセスを実現できる。
第2層（認証情報）：　MSPがアカウント管理・棚卸しを代行することで、属人化リスクを軽減できる。

残存リスクとして、MSP自体が侵害された場合に自組織のZTNA環境に影響が及ぶ可能性がある。また責任分界点が不明確なままだとインシデント対応が遅れるリスクがある。MSP選定時にはSLAの確認が重要である。

発展形としてのSSE（Security Service Edge）

選択肢ではないが、SSE（Security Service Edge）がある。GartnerがSASEのセキュリティ機能部分として定義したもので、以下の機能をクラウドで統合して提供する。

• SWG：　Webトラフィックのフィルタリング・マルウェア検査
• CASB：　SaaS/クラウドアクセスの可視化・制御・データ漏洩防止
• FWaaS：　クラウド型ファイアウォール

SaaSを中心に業務を行っている小規模組織では、ZTNAだけでは「誰がどのSaaSに接続しているか」「シャドーITが発生していないか」「SaaS上のデータが外部に持ち出されていないか」といった可視性・制御の課題が残りやすい。SSEはこれらをZTNAと一体で解決できる点で、SaaSセキュリティに課題を抱える組織に特に適している。
SSE導入について、小規模組織にとっての現実的な進め方としては、まずZTNA（選択肢A）から始め、SaaSの可視性・制御の課題が顕在化した段階でSSEに発展させる段階的なアプローチが適切と考える。Zscaler、Netskope、Cloudflare One等の主要SSE製品は中小向けのプランを提供している。

【技術的な補足】三層への対応と残存リスク

第1層・第3層（CVE・設計思想）：　ZTNAを前提とするため、VPNアプライアンスを廃止でき、ダークIPと最小権限アクセスが実現する。
第2層（認証情報）：　ZTNAのMFA必須化・アカウント管理に加え、CASBによりSaaS上の異常なデータアクセスの検知も可能になる。
残存リスクはZTNA単体と同様で、IdPへの攻撃、ポリシー形骸化、ハイブリッド移行期のリスクがある。加えてSSEは機能が多い分、設定の複雑さが増す点は考慮が必要かもしれない。

以上の4つの選択肢とSSEについて、VPNのリスク三層を表にまとめると以下になる。

（注：◎＝根本的に対処、○＝対処できる、△＝部分的、✕＝対処できない）

小規模組織が陥りやすい落とし穴

「外部ベンダーと長い付き合いだから大丈夫」

信頼関係がある外部ベンダーだからこそ、アクセス権の見直しが後回しになりやすい。しかし攻撃者はベンダーの認証情報を狙ってくる。ベンダーとの信頼関係とアクセス権の適切な管理は別の話として考える。

「うちはSaaSしか使っていないからVPNは関係ない」

SaaS中心の組織でもVPNを使っているケースは多い。バックオフィスシステム、社内ファイルサーバー、クラウド管理コンソールへのアクセスにVPNを使っていないか等、今一度確認することが必要と考える。

「無料プランのZTNAで十分」

無料プランはスタートに最適だが、ユーザー数、ログ保存期間、サポートに制限がある場合が多い。特にログ保存はインシデント発生時の調査に不可欠であり、無料プランの制限を把握した上で判断する必要がある。

「スプリットVPNで設定したから大丈夫」

スプリットVPNは、通信先によってVPN経由と直接インターネット経由を使い分ける設定である。たとえば「社内リソース宛てはVPN経由、Microsoft 365やYouTubeは直接インターネットへ」という形で通信経路を分割する。SaaSアクセス時のバックホール問題（遅延・帯域圧迫）を軽減できるため、テレワーク環境で広く使われている。
課題としては、VPN外に出るトラフィック（SaaS・クラウド宛て）には、社内のセキュリティポリシーが適用されなくなる。シャドーITが発生しても可視化できず、社外からの通信がそのままエンドポイントに届く状態になる。またスプリットVPNはVPNの第3層の設計思想の問題（公開ポートによるアタックサーフェスとラテラルムーブメントの許容）は残るので、利用にあたってはこのような点を注意する必要がある。

小規模組織が今日から始められること（優先順位順）

小規模組織が取れる行動を、コストと緊急度で整理すると以下のようになると考える。

• 【今すぐ・コストほぼゼロ】VPNアカウントの棚卸し：　退職者・外部委託先の未使用アカウントを洗い出して無効化する
• 【今すぐ・コストほぼゼロ】MFAの全アカウントへの設定：　Microsoft 365やGoogle Workspaceの認証機能を使えばほぼ無料で実現できる
• 【今すぐ・コストほぼゼロ】VPN機器のパッチ確認：　使用中のVPN製品の最新CVEと適用状況を確認する
• 【短期・低コスト】外部ベンダーアクセスをZTNAに移行：　Cloudflare Zero TrustやTailscaleの無料プランで試験導入できる
• 【中期・要予算検討】全社員のリモートアクセスのZTNA化：　Microsoft 365等のIdPを活用し、段階的に移行する

まとめ

小規模組織には、小規模組織向けの方法がある。「VPNは危ない」という問題は規模に関係なく当てはまるが、解決策は大規模組織と同じである必要はない。SaaS型ZTNAの活用、外部ベンダーアクセスからの部分的移行、MSPの活用など、規模に合った現実的な選択肢が存在する。まず今日できることから始め、段階的にアーキテクチャを近代化することが重要であると考える。

参考資料

• ブログ「VPNは本当に危ないのか」
• ブログ「VPNは本当に危ないのか（続編）　～　ダークIPで防げること・防げないこと」
• 「VPN経由のサイバーインシデントを未然に防ぐための包括的セキュリティマネジメント：現代の脅威分析と組織的防衛戦略」記事

以上