2026年5月15日
ゼロトラストWGリーダー　諸角昌宏

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

ゼロトラストに色々と触れていくうちに、情報セキュリティの定義である「CIAを維持すること」がゼロトラストの考え方と本当に合っているのかという疑問が生じてきた。この疑問に答えるには、まずCIAという概念を正確に理解することから始める必要がある。本ブログはその出発点として、CIAとは何か、なぜ3つなのか、どこまで有効でどこから先は別の概念が必要なのかを整理してみる。その上で、本ブログの続編として、ゼロトラストとCIA、さらに、ゼロトラスト環境において情報セキュリティをどのように捉えるかを考察してみる。

CIAとは何か

CIAとは、情報セキュリティにおける3つの基本要素を示す概念である。まずこの3要素を正確に理解しておくことが重要である。

情報システムは、この3要素が維持されることで安全かつ信頼可能とみなされる。ただし重要な前提がある。情報はそれ自体として価値を持つ。CIAはその価値が損なわれないための条件を3つの軸で整理したものであり、「CIAが整っていれば情報に価値が生まれる」のではなく、「CIAが損なわれると情報の価値が損なわれる」という関係にある。

機密性（Confidentiality）

機密性とは、許可された人だけが情報へアクセスできる状態を維持することを意味する。

代表的な対策：

• 認証・多要素認証（MFA）
• アクセス制御（IAM）
• 暗号化（通信・保存データ）
• 最小権限の原則（PoLP：Principle of Least Privilege）

機密性が失われると：

• 情報漏えい・不正閲覧
• 認証情報の窃取
• 競合他社・攻撃者による悪用

機密性が問うのは「誰に見せるか」というアクセスの選択性である。ただし「正規のアクセス者が情報を目的外に使用する」という問題は機密性の範囲外である。この「目的外利用」を扱う概念は対象によって異なる。対象が個人データであればプライバシーが扱う（GDPRの「目的制限の原則」等）。対象が組織情報・営業秘密であれば守秘義務やAccountability（説明責任）が扱う。いずれの場合も、「アクセスを許可するかどうか」という機密性とは別軸の問題である。

完全性（Integrity）

完全性とは、情報やシステムが正確であり、意図せず改ざんされていない状態を維持することを意味する。

代表的な対策：

• ハッシュ関数による改ざん検知
• デジタル署名
• 変更管理・バージョン管理
• 監査ログ

完全性が失われると：

• データ改ざん・不正送金
• 偽ソフトウェアの配布（サプライチェーン攻撃）
• 意思決定の誤り（改ざんされたデータに基づく判断）

「信頼できるシステム」において、完全性は重要な中核要素である。システムが動作していてもデータや処理結果が改ざんされていれば、そのシステムは信頼できない。

完全性が問うのは「情報が改ざんされていないか」という内容の正確性である。「誰が作ったか・送ったか」という発信者の同一性はAuthenticity（真正性）という別の観点が扱う。フィッシングメールやサプライチェーン攻撃は真正性の問題であり、完全性だけでは十分に捉えきれない。

可用性（Availability）

可用性とは、必要なときにシステムや情報を利用できる状態を維持することを意味する。「可用性」はavailabilityの訳語としてIBM系文脈で普及したとされる。日常会話では使われないが、IT・セキュリティ分野では標準的な用語として定着している。

代表的な対策：

• 冗長化（サーバー・ネットワーク・電源）
• バックアップ・災害対策（DR）
• DDoS対策
• 障害復旧計画（RTO・RPO の設定）

可用性が失われると：

• サービス停止・業務停止
• 社会インフラの停止（医療・電力・交通）
• ランサムウェアによる業務不能

情報自体の価値は存在しても、それを活用できなければ実質的な価値を発揮できない。そのため可用性は重要である。

可用性が問うのは「今、使えるか」という現在の状態である。「侵害後にいかに回復するか」という設計はレジリエンス（Resilience）という概念が扱う。NIST CSF 2.0はこのRecover機能を独立した柱として体系化している。

なぜCIAで「安全かつ信頼可能」が説明できるのか

情報システムへの主要な被害は、最終的に次の3種類に整理できる。

なぜ被害は3種類に整理できるのか。それは「情報が使われるとき、必ず3つの行為が関係する」という理解モデルとして整理できる。

情報が使われるとき、誰かが（アクセスする）・何かを（読み書きする）・いつか（使う）という3つの行為が必ず発生する。この3行為それぞれに対応する被害が「漏えい・改ざん・利用不能」であり、C・I・Aはこの3行為を保護対象とする評価軸として設計された。

さらに「攻撃者が情報システムに対してできること」を整理しても、同じ3種類に行き着く。攻撃者にできることは「見る（C侵害）・変える（I侵害）・使えなくする（A侵害）」の3種類に集約される。例えば、近年の二重恐喝型ランサムウェアでは、データ窃取（C侵害）と暗号化による利用不能化（A侵害）が組み合わされる。なりすましは正規ユーザーのアクセス権を奪う（C侵害）ことで実現する。

3つの概念が互いに還元できない独立した軸であることも重要である。機密性が保たれていても完全性は失われうる（例：暗号化された通信が改ざんされた場合や、脆弱性を突いた外部攻撃者によるデータ書き換え）。完全性が保たれていても可用性は失われうる（例：正確なデータがシステム障害やDDoS攻撃で使えない場合）。この独立性により、被害の種類を明確に特定でき、対策の方向性を誤らない。多くのセキュリティ事故はこの3軸のいずれかへの侵害として分類できる。そのためCIAは膨大な脅威を整理するための共通モデルとして広く利用されている。CIAが有用である理由は、3つの概念がそれぞれ独立していることにある。機密性はアクセスの「誰に」を問い、完全性は内容の「何が」を問い、可用性はアクセスの「いつ」を問う。この独立性により、どの軸が侵害されたかを明確に特定でき、対策の優先順位をつけやすい。

CIAはどのように形成されたか

CIAは単一の設計者・文書から生まれたのではなく、複数の文脈で独立に発展した概念が段階的に収束した。この経緯を知ることで、CIAが「情報セキュリティの唯一の真理」ではなく「当時の問題意識から収束した共通語彙」であることが分かる。

C・I・Aはそれぞれ独立した問題意識から別々の研究者によって生まれ、後に収束したと考えられる。設計当初は「情報セキュリティの定義」として提示されたのではなく、「安全なシステムを設計するための評価軸」として使われていた。「情報セキュリティとはCIAを維持すること」という定義は、後の標準化・教育化の過程で形成されたものと考えられる。

CIAは必要条件だが十分条件にはなりえない

情報セキュリティに「十分条件」は存在しない。脅威は常に進化し、守る対象も変化し続けるためである。CIAは当時の問題意識に対して有効な評価軸として形成されたが、時代とともにCIAの設計範囲を超えた脅威が顕在化してきた。CIAの設計範囲を超えた概念は、出所によって2つに整理できると考える。

ISO/IEC 27000:2018が明記する拡張概念

NIST CSFが体系化した概念

これらの追加概念も、最終的にはCIAを補強・拡張するものが多い。そのためCIAは現在でも情報セキュリティの基礎概念として維持されている。

「CIAを維持している企業がなぜサイバー攻撃にさらされるのか」という問いも、この文脈で理解できる。攻撃者は認証情報を盗む（これはC侵害であり、CIAで捕捉できる）。しかし盗んだ認証情報を使って正規ユーザーになりすましてアクセスする段階では、CIAのアクセス制御をすり抜ける。これはAuthenticity（真正性：本当に正規ユーザーか）の問題であり、CIAだけでは捕捉しにくい。さらに正規のツールで横展開し、サプライチェーン経由で正規ソフトウェアに混入するといった手法も同様に、CIAの設計範囲を超えた攻撃ベクターである。CIAが評価軸として有効であっても万能ではないことを示していると言える。

まとめ

CIAとは、「情報が漏れず・改ざんされず・必要時に利用できる状態」を評価するための基本的な軸である。この3要素を整理して理解した上で改めてゼロトラストを見ると、ゼロトラストはCIAという評価軸を否定するものではない。ゼロトラストは、CIAという評価軸ではなく、CIA実現の前提として広く用いられてきた「境界防御中心の信頼モデル」を再設計する考え方である。CIAはゼロトラスト下でも有効な評価軸として機能し続ける。ただしCIAだけでは捉えきれない問題（真正性・説明責任・レジリエンス等）が現代の脅威環境では重要性を増しており、これらを補完する概念と組み合わせて用いることが求められる。CIAを正確に理解することが、ゼロトラストを含む現代のセキュリティを正しく議論するための出発点となる。

次回のブログ（続編）では、この部分をさらに掘り下げ、情報セキュリティの目的の観点で考えてみることとする。

以上

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経由のサイバーインシデントを未然に防ぐための包括的セキュリティマネジメント：現代の脅威分析と組織的防衛戦略」記事

以上