小規模組織のリモートアクセスをどう守るか

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担当者が見落としていた休眠アカウント」が発端であった。したがって、「うちは小さいから狙われない」は誤解であり、ランサムウェア攻撃の多くは組織の規模を問わず自動スキャンで脆弱な機器を探し出している。小規模組織は「狙いやすい標的」になりうる。

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

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

観点	大規模組織	小規模組織
IT専任担当	いる（チームで対応）	いない・兼任が多い
IdP整備状況	Entra ID等すでにある	Microsoft 365、Google Workspace導入済みなら実質整備済み。オンプレADのみの場合はクラウドIdPが未整備
ポリシー設計・維持	専任チームが担える	誰がやるか問題になる
予算	ある程度確保できる	限られることが多い
外部ベンダー管理	数十社。管理が複雑	数社。関係は密だが管理が属人化しやすい
リスクの特徴	攻撃対象になりやすい	パッチ対応、アカウント管理が遅れやすい

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

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

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

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

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

製品・サービス	特徴	小規模向けの適合性
Cloudflare Zero Trust	無料枠あり（50ユーザーまで）。セットアップが比較的容易。	◎　無料枠で試せる点が強み
Tailscale	WireGuardベースのL4型。 UIがシンプル・設定が少ない・無料プランあり	◎　IT担当が少ない組織に向く
Twingate	エージェントレス対応あり。SaaSライクな管理画面・中小向けプランあり	○　外部ベンダー管理に有効
Microsoft Entra ID + アプリプロキシ	Microsoft 365ユーザーなら追加コスト低い。IdP兼用できる	○　M365導入済みなら検討しやすい

これらの製品の共通点は「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のリスク三層を表にまとめると以下になる。

選択肢	三層対応	残存リスク
選択肢A（SaaS型ZTNA導入）	第1層◎ 第2層○ 第3層◎	IdP自体への攻撃、ポリシー設計の粗さ、移行期のハイブリッドリスク
選択肢B（外部ベンダーのみZTNA化）	第1層△ 第2層○ 第3層△	社員のVPNは残るため第1層・第3層の問題は社員アクセス部分で継続
選択肢C（VPN維持＋第2層の徹底）	第1層✕ 第2層○ 第3層✕	第1層・第3層は未解決のまま。CVE発見時の無防備期間とラテラルムーブメントリスクは継続
選択肢D（MSP経由のZTNA）	第1層◎ 第2層○ 第3層◎	MSPへの依存による責任分界点の不明確化、MSP自体が侵害された場合の影響拡大のリスク
SSE（ZTNA＋SWG＋CASB）	第1層◎ 第2層◎ 第3層◎	IdPへの攻撃、ポリシー形骸化、設定の複雑さが増大（MSP経由が代案）

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

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

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

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

「うちは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の現実性について

コメントをどうぞ

第5回SaaSセキュリティリーグ会議

「SaaSセキュリティリーグ」は、SaaSユーザー企業の実務者同士で情報交換を行う取り組みである。SaaS管理者やセキュリティ担当者を横串でつなぎ、知見交換を行うことで、セキュリティレベル向上に貢献していくことを目的としている。ここでは、「SaaSセキュリティリーグ」が行った第5回会議の内容をまとめて公開する。

問題点の概要

「VPNは危険だ」という言説が広まっている。ランサムウェア被害の報道でVPNが侵入経路として言及されることが増え、セキュリティベンダーはこぞって「脱VPN・ゼロトラスト移行」を訴えている。

このような状況を受けて、今回のSaaSセキュリティリーグでは、VPN利用の現状、ZTNAへの移行状況等についてディスカッションを行った。

ディスカッション内容

VPN利用状況の現状：VPNをどのような用途で使っているか
VPN自体は、現状各組織で使われている状況である。VPNの問題自体は認識されており、ZTNAへの移行に向けての作業、準備が進められている。
VPNの利用については、以下の3つのポイントで考える必要があり、この中で、VPNの廃止を進めているのは、リモートアクセスおよびサードベンダー用アクセスということである。
- 従業員のリモートアクセス
- サードベンダー用アクセス
- 拠点間アクセス
  
  また、お客様の方でVPNアクセスを求められることがあり、これはVPN接続せざるをえないという指摘があった。その際には、運用として会社のネットワークからは使わせないようにする対応を取っているとのことである。
SaaS/クラウドへのアクセスはVPN経由かどうか
リモートアクセスとSaaSアクセスは特に区別せず同じ扱いをしている。
一旦オンプレにつないでからクラウドにアクセスしている。
スプリットVPNも使われているが、あくまで限定した形での利用とている。特に、Zoom・Teams等のリアルタイム通信が必要とされる場合に利用している。

クラウドアクセスのパターンは以下の3つに分けられる:
- SASE/CASB経由
- 端末からダイレクトにクラウドサービスに接続（パフォーマンス、可用性の問題）。
- ZTNAであっても、一旦社内に持ってきてからインターネットに接続する（アクセス元を管理したいケースに利用）。IPアドレスでコントロールし、外に出るIPアドレスで経路を特定することができる。
VPN廃止の検討、計画の状況
従業員のリモートアクセスおよびベンダーアクセスVPNは全廃の方向で進めている。従業員のリモートアクセスについては、インターネット経由はすでに無くしているところもあり、ZTNAに移行している。リモートデスクトップに近いやり方で制御している。
ベンダーアクセスについては、なるべく無くす方向で進めている。主要な相手とは専用回線のVPNで対応している。
拠点間アクセスは、継続してVPNを利用している。
ZTNA（SASE）への移行の問題点
VPNを廃止する場合の問題点として、以下が上げられた：
- SIPがルーターを超えられないので、VPN接続せざるを得ないところがある。コールセンターの音声系など。
- SASEが高い。
- 子会社の一部などADドメインに参加していない独立したネットワークがある。ADドメインに参加していない子会社の端末でも、ZTNAエージェントをインストールしてIdPでログインできれば、同じポリシーで制御できるのではないか。
- SaaS製品の問題がネットワーク側の問題とされるケースがあるが、SASEとほかの製品との問題点の切り分けは特に問題にはなっていない。
その他
- 中小企業向けの対策としてZTNAはどうなのか、軽量な接続方法としてVPNは残るかという観点での検討が必要ではないかという指摘があった。Tailscale などの利用の検討する必要があるとのことである。また、SaaSを中心に業務を行っている小規模組織に対しては、SSEの利用も考えられるのではという指摘があった。
- 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」において、発注者（委託元）が取引先（受注者・委託先）に対してセキュリティ強化を依頼した場合に、セキュリティ対策コストの価格転嫁ができるとの意見があった。これにより、ZTNAへの移行が進められるかもしれないという指摘である。
参考資料

以上

　「AI脆弱性の嵐 (AI Vulnerability Storm)」：「Mythosレディ」なセキュリティプログラムの構築」を公開しました。

コメントをどうぞ

2026年4月19日
CSAジャパン　諸角昌宏

本ブログでは、「AI脆弱性の嵐 (AI Vulnerability Storm)」：「Mythosレディ」なセキュリティプログラムの構築」について記載します。

「AI脆弱性の嵐 (AI Vulnerability Storm)」：「Mythosレディ」なセキュリティプログラムの構築」は、CSA CISO Community, SANS, [un]prompted, the OWASP Gen AI Security Project,等のコミュニティが公開した「The “AI Vulnerability Storm”: Building a “Mythosready” Security Program」をCSA本部の承認のもとに翻訳して公開したものになります。
AIを活用した脆弱性発見とエクスプロイト開発は劇的に加速しています。脆弱性の公開から悪用されるまでの期間は短縮しており、セキュリティチームには、現在の運用モデルでは対応しきれないほどの迅速な対応が求められています。本ブリーフィングは、CISOおよび経営層向けの枠組みと実践的なガイダンスとして、AI主導の攻撃が新たな基準となった世界で活動するために必要な、即時の対応策、短期的な優先事項、そして長期的な変革の概要を解説しています。
なお、本資料は、16名の著者、約250名のCISOおよび実務家によるレビューア、CISA、NSA、ホワイトハウスの元幹部らによる驚くべき共同作業で作られています。

こちらからダウンロードしてご覧ください。

ゼロトラスト関連用語を整理する ~ ZT・ZTA・ZTNA・SDP の違い

2件の返信

2026年4月12日
CSAジャパン　ゼロトラストWG
CCZT(Certificate of Competence in Zero Trust)
諸角昌宏

はじめに

「ゼロトラスト」という言葉が広く使われるようになった一方で、ZT・ZTA・ZTNA・SDPという関連用語が混在して使われ、混乱を招くケースが増えている。これらは互いに密接に関連しているが、指し示す概念の範囲や性格はそれぞれ異なる。本ブログでは、各用語の定義・関係性・違いを整理し、正確な理解の助けとなることを目指す。

全体像：4つの用語の関係

4つの用語は以下のような階層関係にある。ZTが最も広い概念であり、ZTA・ZTNA・SDPはそれを具体化・実装化していく階層に位置する。

すなわち、ZTという概念をシステム設計として具現化したものがZTAであり、ZTAを実現する技術カテゴリの一つがZTNA、そしてZTNAの具体的な実装アプローチがSDPである。

ZT（Zero Trust：ゼロトラスト）

定義

ZTとは「すべてのアクセスを検証する（Never Trust, Always Verify）」というセキュリティの概念・原則である。ネットワークの内側・外側を問わず、いかなるユーザー・デバイス・アプリケーションも、明示的に認証・認可されるまでは信頼しないという考え方に基づく動的・継続的な信頼評価モデルである。2010年にForrester ResearchのアナリストJohn Kindervagが提唱したことが起源とされている。

主な原則（NIST SP 800-207より）

すべてのデータソースとコンピューティングサービスをリソースとみなす
ネットワークの場所に関係なく、すべての通信を保護する
企業リソースへのアクセスは、セッション単位で付与する
リソースへのアクセスは、ダイナミックなポリシーやその他の行動・環境属性によって決定する
すべての資産の完全性とセキュリティ動作を監視し、測定する
すべてのリソースの認証と認可を動的に行い、アクセスが許可される前に厳格に実施する
資産、ネットワークインフラストラクチャ、通信の現状について可能な限り多くの情報を収集し、セキュリティポスチャの改善に利用する

重要なポイント

ZTは製品でも技術でもなく、考え方である。「ゼロトラスト製品を導入した＝ゼロトラストを実現した」とはならない。ZTはあくまで組織のセキュリティ戦略の指針であり、その実現手段がZTAである。

ZTA（Zero Trust Architecture：ゼロトラストアーキテクチャ）

定義

ZTAとは、ZTの原則を組織のシステム・インフラ・ワークフローに適用するためのシステム設計・アーキテクチャである。NIST SP 800-207が最も権威ある技術ガイドラインとして広く参照されている。

主なコンポーネント

NIST SP 800-207はZTAの論理的なコンポーネントとして以下の3つを定義している。

コンポーネント	略称	役割
ポリシーエンジン	PE	アクセスの許可・拒否を最終決定する
ポリシーアドミニストレータ	PA	PEの決定をPEPに伝達・実行させる
ポリシー実施ポイント	PEP	実際にアクセス制御を執行するゲートキーパー

PEはトラストアルゴリズムを用いて、アイデンティティ・デバイス状態・脅威インテリジェンス・行動履歴などを総合的に評価し、動的にアクセス判断を行う。

ZTとZTAの違い

	ZT	ZTA
特徴	概念・原則	設計・構造
目的	「何を目指すか」	「どう設計するか」
具体性	抽象的	具体的（コンポーネント・データフローを定義）

ZTNA（Zero Trust Network Access：ゼロトラストネットワークアクセス）

定義

ZTNAはゼロトラスト原則に基づくアクセス制御のカテゴリであり、VPNの代替となるケースも多いが、すべてのユースケースを置き換えるものではない。現在はZTAを構成する重要な要素として、より広い役割を担うものと位置づけられている。

VPNとZTNAの比較

観点	VPN	ZTNA
アクセスの粒度	ネットワーク全体への接続	アプリケーション単位での接続
信頼モデル	ネットワーク内を信頼	常に検証（Never Trust）
可視性	限定的	継続的なモニタリング
リスク	侵害時にラテラルムーブメントが容易	最小権限によりラテラルムーブメントを制限
スケーラビリティ	アーキテクチャ変更が困難	クラウドネイティブで拡張が容易

ZTAとZTNAの違い

ZTAはゼロトラスト全体のアーキテクチャ設計であるのに対し、ZTNAはその中のネットワークアクセス制御に特化した市場カテゴリである。ZTNAはZTAを実現するための要素の一つであり、ZTAにはZTNA以外にも、アイデンティティ管理・エンドポイント管理・データセキュリティなど多くの要素が含まれる。

	ZTA	ZTNA
特徴	アーキテクチャ設計	技術カテゴリ
範囲	ゼロトラスト全体	ネットワークアクセス制御に特化
目的	どう設計するか	どうアクセスを制御するか

SDP（Software Defined Perimeter）

定義

SDPとは、ネットワークの境界をソフトウェアによって動的に定義するアーキテクチャアプローチである。SDPはZTNAを実現する一つのアーキテクチャであるが、ZTNAはプロキシ型など複数の実装方式を含む。

仕組みの特徴

SDPの核心は「接続前に認証する（Authenticate Before Connect）」という原則である。従来のファイアウォールが「まず接続を許可し、その後にフィルタリングする」のに対し、SDPはネットワーク接続そのものを確立する前にアイデンティティとデバイスの正当性を確認する。CSAが定義し、Google BeyondCorpと思想的に類似している。

主な構成要素は以下のとおりである。

構成要素	役割
SDPコントローラ	アクセスポリシーの管理・認証の決定
SDPクライアント	ユーザー側のエージェント。接続要求を送信
SDPゲートウェイ	リソース側のゲートキーパー。許可された接続のみを通過させる

単一パケット認証（SPA：Single Packet Authorization）という技術を用いて、正当なクライアントからのパケット以外にはゲートウェイの存在すら見えないよう設計されている。

ZTNAとSDPの違い

	ZTNA	SDP
特徴	技術カテゴリ・機能の定義	実装アーキテクチャ・設計アプローチ
策定主体	Gartner（市場定義）	CSA（技術仕様）
目的	何を実現するか（What）	どう実現するか（How）
関係	より広い概念	ZTNAを実現する手段の一つ

多くの場合、SDPはZTNAの選択形態の一つとして採用されており、両者は実質的に重なる部分が大きいが、概念の性格は異なる。

4つの用語の総合比較

観点	ZT	ZTA	ZTNA	SDP
特徴	概念・原則	アーキテクチャ設計	技術カテゴリ	実装アプローチ
範囲	最も広い	広い	ネットワークアクセス制御に特化	ZTNAの実現手段の１つ
策定主体	Kindervag/Forrester	NIST	Gartner	CSA
主な規格	—	NIST SP 800-207	Gartnerレポート	CSA SDP仕様書
考え方	何を目指すか	どう設計するか	どうアクセスを制御するか	どう境界を実装するか

真のゼロトラストを実現するには

ゼロトラストは製品を導入すれば完成するものではない。ZT・ZTA・ZTNA・SDPの各概念を正しく理解した上で、組織全体として段階的に取り組む必要がある。以下に、真のゼロトラスト実現に向けてやるべきこと・考慮すべき点を整理する。

ZTAの全体設計から始める
最初にやるべきことは製品の選定ではなく、ZTAの全体設計である。「何を守るか（プロテクトサーフェスの定義）」「誰が何にアクセスするか（トランザクションフローの把握）」を明確にした上で、必要な技術要素を選択する順序が重要である。ZTNAやSDPはその後に来る手段であり、目的ではない。
アイデンティティを中核に置く
ゼロトラストの根幹はアイデンティティの継続的な検証にある。ユーザーIDだけでなく、デバイス・アプリケーション・サービスアカウント（非人間アイデンティティ）を含むすべての主体を対象に、多要素認証（MFA）・最小権限の原則・継続的な認証・認可の仕組みを整備することが不可欠である。
5つの柱を横断的に整備する
CISAゼロトラスト成熟度モデルが示すとおり、ゼロトラストはアイデンティティ・デバイス・ネットワーク・アプリケーション／ワークロード・データという5つの柱を総合的に整備して初めて機能する。ZTNAによるネットワークアクセス制御だけを強化しても、デバイス管理やデータ保護が脆弱であれば、ゼロトラストの実効性は限定的となる。
段階的・反復的なアプローチをとる
すべてを一度に変えようとすることは現実的でなく、リスクも高い。NSTACモデルが示す5ステップを参照しつつ、まず取り組みやすいプロテクトサーフェスを1つ選んでパイロット的に実施し、そこで得た知見・経験を活かしながら段階的に最も重要な資産（プロテクトサーフェス）へと対象を広げていく反復アプローチが有効である。例えば、既存のISMSを基盤として活用することで移行コストを抑えつつゼロトラストを段階的に展開することも考えられる（参考：CSAジャパンゼロトラストWG「ISMSを基盤としたゼロトラストの展開」、2026年2月 [6]）。
継続的な監視とポリシーの更新
ゼロトラストは一度構築すれば終わりではなく、継続的な監視・評価・改善のサイクルが本質である。SIEM・UEBAなどのツールを活用してアクセスログを常時分析し、異常を検知したらポリシーを即座に見直す体制を整えることが求められる。静的なルールに依存したままではゼロトラストの「動的な信頼の評価」という核心を実現できない。
組織文化とガバナンスの整備
技術面の整備と同時に、経営層の理解・支援と組織文化の変革が不可欠である。「境界の内側は安全」という従来の前提を組織全体が捨て去ることが、ゼロトラストの出発点である。NIST CSF 2.0が「ガバナンス（GV）」を独立した機能として追加したように、サイバーセキュリティを経営リスクとして位置づけ、責任の所在を明確にする体制づくりが求められる。
ベンダーロックインへの注意
ゼロトラストを標榜する製品・サービスは数多く存在するが、特定ベンダーの製品体系に過度に依存することは長期的なリスクとなる。NIST SP 800-207が技術中立的な設計を意図しているように、オープンな標準・仕様に基づいたアーキテクチャ設計を心がけ、特定製品への過度な依存を避けることが望ましい。

以上の考慮点を整理すると、以下のとおりである。

やるべきこと・考慮点	要点
(1) ZTAの全体設計から始める	製品選定より先に何を守るかを定義する
(2) アイデンティティを中核に置く	人・デバイス・サービス全体をMFA・最小権限で管理する
(3) 5つの柱を横断的に整備する	ネットワークだけでなくデータ・デバイスなども含めて対処する
(4) 段階的・反復的なアプローチ	1つのプロテクトサーフェスから始め知見を積み上げる
(5) 継続的な監視とポリシー更新	静的なルールに依存せず動的に見直し続ける
(6) 組織文化とガバナンスの整備	経営層の理解と責任体制の明確化が前提となる
(7) ベンダーロックインへの注意	特定製品依存を避け標準ベースの設計を心がける

よくある誤解

誤解1：「ZTNA製品を導入すればゼロトラストが実現できる」

ZTNAはZTAの一要素である。ネットワークアクセス制御が改善されても、アイデンティティ管理・エンドポイントセキュリティ・データ保護が伴わなければ、ゼロトラストの実現とはいえない。

誤解2：「SDPとZTNAは同じものだ」

SDPはZTNAを実現する実装アプローチの一つであるが、ZTNAはSDP以外の技術（IDベースのプロキシ等）でも実現できる。両者は重なるが同義ではない。

誤解3：「ゼロトラストはVPNを完全に置き換えるものだ」

ZTNAはリモートアクセスにおけるVPNの有力な代替であるが、すべてのユースケースでVPNが不要になるわけではない。ZTNAはLayer 7（アプリケーション層）での制御を前提とするため、ネットワーク機器の管理やレガシーシステムへの低レイヤー接続、OT・ICS環境など、ネットワークレベルのアクセスが必要な場面ではVPNが引き続き有効である。また、既にVPNインフラを持つ組織では一度に全面移行することは現実的でない。当面はZTNAとVPNを用途に応じて使い分けながら段階的に移行していくアプローチが現実的である。

まとめ

4つの用語の関係を改めて整理する。

ZTは「すべてを検証する」というセキュリティの概念である
ZTAはその概念を実現するシステムアーキテクチャの設計である
ZTNAはZTAを構成する要素の一つで、ネットワークアクセス制御に特化した技術カテゴリである
SDPはZTNAを実現する具体的な実装アーキテクチャアプローチである

これらは階層的な関係にあり、上位の概念が下位を包含する。組織がゼロトラストを推進する際は、製品・技術の導入に先立ち、ZTの原則とZTAの設計思想を理解した上で取り組むことが重要であると考える。

参考文献

[1] NIST, “Special Publication 800-207: Zero Trust Architecture,” National Institute of Standards and Technology, 2020.

[2] CISA, “Zero Trust Maturity Model Version 2.0,” Cybersecurity and Infrastructure Security Agency, 2023.

[3] NSTAC, “NSTAC Report to the President on Zero Trust and Trusted Identity Management,” National Security Telecommunications Advisory Committee, 2022.

[4] Cloud Security Alliance, “SDP Specification v2.0,” 2022.

[5] J. Kindervag, “Build Security Into Your Network’s DNA: The Zero Trust Network Architecture,” Forrester Research, 2010.

[6] 諸角昌宏（CSAジャパンゼロトラストWG）, “ISMSを基盤としたゼロトラストの展開,” CSAジャパンブログ, 2026年2月16日. https://cloudsecurityalliance.jp/newblog/2026/02/16/isms%e3%82%92%e5%9f%ba%e7%9b%a4%e3%81%a8%e3%81%97%e3%81%9f%e3%82%bc%e3%83%ad%e3%83%88%e3%83%a9%e3%82%b9%e3%83%88%e3%81%ae%e5%b1%95%e9%96%8b/

以上

クラウドセキュリティ専門家はもはや不要か？～二方向への分化という視点

コメントをどうぞ

2026年4月6日
諸角　昌宏

以前のブログ「クラウドセキュリティは不要か？ ~ クラウドセキュリティは情報セキュリティの一部として整理すべきか」では、クラウドセキュリティが情報セキュリティに単純に吸収されて完結するのではなく、「情報セキュリティの基盤の上に専門的な理解が積み重なる」という構造を示した。今回はその続きとして、積み重なった専門的な理解はどこへ向かっているのか、そしてその先に、「クラウドセキュリティ専門家」という職種は存在し続けるのだろうか、という観点で考えてみたい。

結論から言えば、クラウドセキュリティ専門家は不要になる方向にあると考えている。ただしそれは、クラウドセキュリティの知識が当たり前になってきたからである。したがって、「不要か否か」という問いは、少し乱暴かもしれない。大切なのは「なぜ」「どのように」不要になっていくか、という点ではないだろうか。突然消えるわけではなく、独立した専門領域としての輪郭が、二方向からじわじわと溶けていく。それが今クラウドセキュリティに起きていることだと思う。以下、この2つの方向について考えてみる。

第一の方向：上位概念への統合

たとえば、アイデンティティセキュリティを語るとき、その実装基盤はクラウドである。AIセキュリティを語るとき、そのワークロードはクラウド上にある。ゼロトラストを語るとき、その実装環境はクラウドである。クラウドセキュリティの知識は、こうした上位概念の議論の中に自然と溶け込んでいく。この状況において、専門家の肩書きで言えば、「クラウドセキュリティ専門家」という看板を掲げる人は少なくなり、「AIセキュリティエンジニア」「ゼロトラストアーキテクト」「IDセキュリティアーキテクト」といった肩書きを持つ人が増えていくだろう。クラウドの知識はその人たちの中に前提として組み込まれているが、看板には出てこない。これが一つ目の力である。上から押し下げる力、と言えるかもしれない。

第二の方向：基盤層への沈降

もう一つの力は、下から押し上げてくる力である。クラウドセキュリティの考え方が広まるにつれ、その知識はインフラエンジニア、DevSecOpsエンジニア、SRE（Site Reliability Engineering）といった職種の当然の素養になっていく。ネットワークセキュリティの知識がネットワークエンジニアの前提になっているのと同じである。「クラウドセキュリティを専門とする」という言い方が成り立つためには、その知識がある程度希少である必要がある。しかし知識が現場に浸透し、エンジニアリングの常識になっていくと、その希少性は自然と薄れていく。クラウドネイティブ開発の普及、Infrastructure as Codeの標準化、プラットフォームエンジニアリングの成熟。こうした流れが、クラウドセキュリティの知識を現場に定着させ、専門家が個別に関わらなくても機能する状態へと少しずつ近づいていると考える。

二方向から挟まれる構造

以上の2つの方向の力が同時に働いているのが今のクラウドセキュリティの状況と考える。上からはAI・アイデンティティ・ゼロトラストの専門家として吸収され、下からはインフラ・DevSecOpsエンジニアとして吸収されていく。「クラウドセキュリティ専門家」という独立した専門家像が成り立つ空間が、二方向からゆっくりと埋まっていくというのが、「不要」という意味合いになってくると思われる。

では、何が残るのか

クラウドセキュリティの知識が消えるわけではない。ゼロトラストアーキテクトもAIセキュリティエンジニアも、クラウドセキュリティの理解なしには成り立たない。CCMもISO/IEC 27017もなくなるわけではなく、監査やコンプライアンスの場面で参照され続けるであろう。ただ、その位置づけが変わる。クラウドセキュリティの知識はセキュリティ専門家全般の前提条件になっていくと考えられる。

ただ、一点付け加えたいことがある。前回のブログで「情報セキュリティの基盤の上に専門的な理解が積み重なる」と示したが、そうであれば、その積み重なった知識を次の世代や隣接領域の専門家に伝えていく仕事は、確かに残る。クラウドセキュリティ専門家の役割は「実装の最前線」から「知識の伝承と標準化」へと移っていくと考えられる。CSAのような組織が担ってきたのも、まさにその仕事である。

まとめ

専門家が必要なくなるのは、その知識が当たり前になるからである。概念が整理され、方法論が体系化され、標準や規制に組み込まれ、実装が現場の常識になっていく。ネットワークセキュリティがそうなったように、クラウドセキュリティも今その道を歩んでいる。この観点から、クラウドセキュリティ専門家に残される役割は、大きく二つあると考える。

一つ目は、「次のフロンティアへの参画」である。AIセキュリティ、アイデンティティセキュリティ、エージェントセキュリティといった領域は、まだ答えが出ていない問いに満ちている。クラウドセキュリティで積み上げた知識や経験は、こうした新たな領域を切り拓く上で確かな土台になる。クラウドセキュリティ専門家こそ、次のフロンティアで力を発揮できる存在である。

二つ目は、「知識の伝承と標準化」である。情報セキュリティの基盤の上に積み重なった専門的な知識を次の世代や隣接領域の専門家に伝えていく仕事は、確かに残る。概念が定着し当たり前になっていくからこそ、それを体系化し、標準として整理し、教育として伝えていく役割が必要になる。CSAのような組織が担ってきたのも、まさにその仕事である。

CSAは、既にこの方向に向かっている。最新のCSAのブローシャーにはこう書かれている。「forward-looking cybersecurity topics, including AI, cloud, and Zero Trust」。AIもゼロトラストも、クラウドと並列で挙げられている。クラウドセキュリティはCSAの原点であるが、CSAの活動はそこにとどまらない。クラウドセキュリティが当たり前になりつつある今、CSAは次の「まだ当たり前でない問い」に取り組みながら、その知識を体系化し社会に届ける役割を担っている。また、クラウドセキュリティで培った知識は、次のフロンティアへの確かな土台であり、次の世代へ受け継ぐべき財産でもある。

以上

VPNは本当に危ないのか（続編）　～　ダークIPで防げること・防げないこと

コメントをどうぞ

2026年4月3日
諸角　昌宏

本ブログは、3月26日に公開した「VPNは本当に危ないのか」の続編として、VPNの設計思想の問題に対してZTNAが提供している「ダークIP」について掘り下げてみる。なお、前のブログに対して「VPN対策はゼロトラストではないのか」という質問が寄せられた。ここでは、ゼロトラスト(ZT)とゼロトラストネットワークアクセス(ZTNA)の違いについての説明は行わないが、前のブログおよびこのブログで説明しているのは、ZTではなくZTNAであるということを述べておく。

まず、VPNのリスクについておさらいする。VPNのリスクは性質の異なる三つの層に分かれている。

第1層：製品脆弱性（CVE）のリスク——VPN製品自体に脆弱性が発見されるたびに、パッチ適用までの間が無防備な状態になる
第2層：認証情報管理のリスク——漏洩したパスワードやMFA未設定のアカウントが侵入口になる
第3層：設計思想の欠陥——公開ポートによるアタックサーフェスの恒常的な存在と、認証後のラテラルムーブメントを許容する構造

「ダークIP」は、主にこの第3層「設計思想の欠陥」を解決するアプローチである。第1層・第2層のリスクはパッチ管理やMFA強化で対処する一方、ダークIPは公開ポートによるアタックサーフェスを根本から排除することで第3層の問題に対処する。さらにその副次的な効果として、公開ポートが存在しなくなることにより第1層のCVE直接攻撃も成立しにくくなる。ただしダークIPの効果はすべての脅威に及ぶわけではなく、防げる脅威と防げない脅威がある。本ブログではその範囲を整理していきたい。

ダークIPの仕組み

ZTNAの重要な特徴としての「ダークIP」は、サーバーや内部リソースのIPアドレスをインターネット上から不可視化する仕組みである。

VPNではアプライアンスが常時インターネットに公開されたポートを持っている。攻撃者はスキャンエンジンを用いて公開されているポートを見つけ、脆弱性の有無を調べて攻撃を仕掛ける。「公開ポートが存在する＝攻撃の入口が常に存在する」という構造になる。 ZTNAのダークIPはこの構造を根本から変えている。内部リソースはZTNAのコネクタ（ゲートウェイ側に設置）を介してのみアクセス可能であり、サーバーのIPアドレス自体がインターネット上に露出しない。攻撃者がスキャンしても存在自体が見えず、直接攻撃の糸口をつかみにくくなる。つまり、以下のような関係になる。

VPN：　外部 → 公開ポート（常時露出）→ 内部ネットワーク
ZTNA：　外部 → ZTNAゲートウェイ（認証・ポリシー評価）→ 内部リソース（IPアドレス非公開）

なお、ダークIPはアタックサーフェスを大幅に削減することができるが、すべての攻撃を防ぐことができるわけではない。以下でその効果の範囲を整理してみる。

ダークIPで防げること

外部からの無差別スキャン・自動探索

攻撃者はスキャンツールを使い、インターネット上の脆弱なポートを探索する。VPNアプライアンスの公開ポートはこのスキャンに必ず引っかかり、ターゲットリストに載り続けるリスクがある。ダークIPではサーバーのIPアドレス自体がインターネット上に存在しないため、スキャンの対象にならない。AIによる自動スキャンが高度化している現在、この効果はより重要になっている。

VPNアプライアンス自体へのCVE直接攻撃（第3層対処の副次的効果）

IvantiやFortinetなどVPN製品に重大なCVEが発見されるたびに、公開ポートを持つアプライアンスが直接攻撃を受ける（第1層のリスク）。ダークIPは本来、第3層の設計思想の欠陥——公開ポートの恒常的な存在——を排除するためのアプローチだが、公開ポートがなくなることで攻撃者がCVEを突く糸口自体がなくなることになる。第3層への対処が第1層のリスクも連鎖的に軽減するという副次的な効果となる。

ビジネスサプライチェーン経由の侵入

取引先・委託先・子会社などを踏み台にして本体ネットワークに侵入する手口である。VPNでは委託先に広いネットワークアクセスを与えてしまうため、委託先が侵害されると本体にも被害が及びやすい。

ZTNAの最小権限アクセスと組み合わせることで、委託先のアクセスを特定のアプリのみに限定できる。侵入経路が限定されるため被害範囲を大幅に縮小できる。

VPNでは委託先にVPNアカウントを発行すると、ネットワーク全体への通路を開けることになる。委託先が侵害された場合、その通路を通じて攻撃者が内部を移動できてしまうリスクがある。ZTNAでは「ネットワーク全体ではなく、特定のアプリケーション・リソースへのアクセスのみ許可する」という設計のため、委託先が侵害されても攻撃者が到達できる範囲を許可されたアプリに限定できる可能性がある。

ZTNAでは以下のようなポリシーをアクセスごとに適用できる。なおZTNAの実装アーキテクチャの一形態であるSDP（Software Defined Perimeter）を採用することで、委託先のデバイスにエージェントをインストールしなくても、これらの制御を適用できる。

アクセス先の限定：　委託先Aは保守対象サーバーのポート22（SSH）のみ、委託先Bは特定の業務アプリのみ、といった粒度で制御できる
時間・コンテキストによる制御：　接続時間帯・接続元地域・デバイスの健全性（EDR導入済みか等）を条件にアクセスを制限できる
セッションの記録・監視：　委託先のアクセスセッションをログとして記録し、異常な操作を検知できる
退職・契約終了時の即時失効：　人事システムとの連携により、委託先の契約終了と同時にアクセス権を自動的に無効化できる（VPNで問題になるゾンビアカウントを防ぐ）

VPNが「委託先にネットワークへの扉を開ける」設計であるのに対し、ZTNAは「必要な窓口だけを、必要な期間だけ、必要な相手にだけ開ける」設計である。ビジネスサプライチェーン攻撃への対策として、ZTNAはVPNより構造的に優れているといえる。

ダークIPで防げないこと

認証通過後のアプリケーション層の脆弱性攻撃

ZTNAは「誰が・どのデバイスから・何に」アクセスするかを制御する。しかしアクセスを許可した後、そのアプリケーション内部にSQLインジェクションやバッファオーバーフロー等の脆弱性があれば、正規ユーザー経由で攻撃が成立してしまうリスクがある。これはダークIPの問題ではなく、アプリケーション層のセキュリティの問題である。WAF（Webアプリケーションファイアウォール）・SAST・DASTなどの別の対策が必要になる。

ソフトウェアサプライチェーン攻撃

正規のソフトウェアアップデートにマルウェアを混入させる手口として、SolarWinds事件（2020年）がその代表例である。正規の署名付きアップデートとして配布されたため受け取った組織には見分けがつかない。 ZTNAからは「正規デバイス・正規ユーザー・正規ソフトウェア」として認識されてしまうため、ネットワークアクセス制御では防げない。ソフトウェアの完全性の検証はZTNAの対象外であり、SBOM（ソフトウェア部品表）管理・コード署名検証・EDRとの組み合わせが必要である。

内部不正

正規ユーザーによる意図的な悪用はZTNAのポリシー評価を通過してしまう。ただし最小権限の設計により、アクセスできるリソースが限定されるため被害範囲を縮小できる可能性はある。内部不正の防止には、行動監視（UEBA）・職務分掌・定期的なアクセス権レビューなど別の対策が必要となる。

「攻撃対象面の消去」ではなく「削減」

ZTNAの説明でしばしば「攻撃対象面（アタックサーフェス）をゼロにする」という表現が使われるが、これは正確ではない。ダークIPが実現するのは「外部からのスキャン・直接攻撃に対するアタックサーフェスの根本的な削減」である。

認証を通過した後のアプリ層・ソフトウェアサプライチェーン・内部不正といった脅威には効果が及びにくい。ZTNAはセキュリティの万能薬ではなく、多層防御の重要な一層として位置づけるべきである。 WAF・EDR・UEBA・SBOM管理などとの組み合わせが、ZTNAの効果を最大化する。

まとめ：効果の一覧

ここでは、以上の内容をまとめて、ダークIPの効果について以下の表にまとめた。

その他、ZTNAとして別途考慮すべき課題

以上、ZTNAのダークIPについてその効果、課題について整理した。ZTNAについては、その他にも考慮すべき課題がある。それらについて、技術的課題と管理的課題に分けて、深刻度順に整理したので参考にしていただきたい。なお、深刻度は筆者の個人的な評価である。

技術的課題（深刻度順）

IdPの外部公開エンドポイント問題（深刻度：高）
ZTNAのコントロールプレーンであるIdP（EntraID・Okta等）はインターネットに公開されており、ダークIPの保護対象外である。IdPが侵害されるとポリシー全体が書き換えられ、ZTNAのアクセス制御が根底から機能しなくなるリスクがある。被害範囲が組織全体に及ぶ深刻なリスクであり、IdPの冗長化・MFA強化・Conditional Accessの設計を別途行う必要がある。
移行期のハイブリッド運用リスク（深刻度：高）
VPNとZTNAの並行運用期間中は両方の攻撃面が同時に存在する。VPNの公開ポートは残り続け、ZTNAのポリシーはまだ未成熟という状態が生まれやすい。移行設計を誤ると一時的にリスクが増大する逆転現象が起きうるため、段階移行の計画において最も注意が必要な期間である。
デバイスポスチャ評価の限界（深刻度：中）
ZTNAはデバイスの健全性（EDR導入・パッチ状態等）をポリシー条件にできるが、ポスチャ評価は「既知の基準への適合」を確認するものであり、ゼロデイマルウェアに感染したデバイスが通過してしまう場合がありうる。「ポスチャチェックをしているから安全」という過信が最大のリスクとなる。最小権限設計で被害範囲は限定できるが、過信を防ぐことが重要である。
セッション継続検証の実装の差（深刻度：中）
ZTNAの原則は「継続的な検証」であるが、製品によってはセッション確立後の再検証頻度が低いものがある。長時間セッション中にデバイス状態が悪化しても検知されない場合がありうる。製品選定時に再検証の頻度・トリガー条件を評価基準に含めるべきである。

管理的課題（深刻度順）

ポリシー設計・維持の継続的負荷（深刻度：高）
最小権限ポリシーは「設計して終わり」ではなく、業務変化に合わせた継続的な見直しが必要である。放置されたポリシーはVPN同様の広範アクセスを許容することになりかねず、ZTNAを導入した意味が損なわれるリスクがある。さらに「ZTNAを入れているから安全だ」という誤った安心感を生みやすい点が深刻である。ポリシーレビューの頻度・体制・担当者スキルを運用設計に組み込む必要がある。
責任分界点の明確化（深刻度：高）
ZTNAをSaaSで利用する場合、セキュリティの責任がどこまでベンダー側にあるかを明確にする必要がある。インシデント発生時に責任の所在が不明確だと対応が遅れ被害が拡大するおそれがある。調査・対応における情報提供義務・ログへのアクセス権・SLAの内容を契約段階で確認すべきである。
ベンダーロックインとガバナンス（深刻度：中）
ZTNAは標準化が未成熟であり製品間の相互運用性が低い。特定ベンダーに依存した構成になると乗り換えコストが高くなりうる。ベンダー選定時に「標準プロトコルへの準拠度」「データのポータビリティ」を評価基準に含めるべきである。後からの対処が困難な点で長期的なリスクが高い。
ログの保全とコンプライアンス（深刻度：中・業種依存）
ZTNAのコントロールプレーンがSaaSで提供される場合、アクセスログがベンダーのクラウドに保存される。ログの保存期間・保存場所・アクセス権がISMS・個人情報保護法・金融規制等のコンプライアンス要件を満たすかを確認する必要がある。特に、金融・医療等の規制業種では深刻度が最上位になりうる。

以上

VPNは本当に危ないのか

1件のフィードバック

2026年3月26日
諸角　昌宏

「VPNは危険だ」という言説が広まっている。ランサムウェア被害の報道でVPNが侵入経路として言及されることが増え、セキュリティベンダーはこぞって「脱VPN・ゼロトラスト移行」を訴えている。しかし実際のところ、VPNの何が問題で、どこまでが誇張なのか、冷静に整理できている組織は少ないのではないかと考えている。本ブログでは、VPNをめぐるリスクの構造を三層に分けて整理し、国内の統計データの正確な読み方、よくある意見への答え、そして対策の方向性について考察する。

VPNのリスクは三層構造

VPNのリスクを「危ない」「危なくない」の二項で語ることには無理がある。問題は性質の異なる三つの層に分かれており、それぞれ対策も深刻度も異なる。

第一層：製品脆弱性（CVE）のリスク

Ivanti、Fortinet、Pulse Secure、NetScalerなど主要なVPN製品では、毎年複数の重大な脆弱性が報告されている。パッチが公開される前後の短期間に大規模な攻撃が観測されるケースも多く、このリスクの深刻さは「発生頻度」ではなく「防御困難性」にある。

ゼロデイ段階では組織側に取れる手段があまりない。さらに厄介なのは、パッチを適用した後でも安心できないケースがあることだ。2024年に確認されたCisco ASAへの「ArcaneDoor」攻撃では、攻撃者がファームウェアレベルにバックドアを仕込み、再起動後もアクセスを維持していたことが報告されている。英国NCSCはこの侵害の検出を「信じられないほど難しい」と評している。

国家支援型APTがこうした脆弱性の発見・悪用に多大なリソースを投じていることも、このリスクの性格を際立たせている。目的は金銭ではなく、長期潜伏・情報収集・将来の破壊活動の準備であることが多く、被害が表面化するのが数ヶ月後というケースもある。

第二層：認証情報管理のリスク

VPN経由の侵害としてよく引用されるColonial Pipeline事件（2021年）は、VPN製品の脆弱性が使われたわけではない。MFAが設定されていない休眠アカウントに、別の情報漏洩事案で入手したパスワードを使って侵入したケースであり、本質は「アカウント管理の失敗」である。

この区別は重要で、製品脆弱性への対策とアカウント管理の強化は、必要な対処が全く異なる。VPN経由の侵害を議論する際に両者が混同されると、対策の優先順位を誤ることになる。認証情報侵害の深刻度が製品脆弱性より「相対的に低い」理由は、防御手段が明確に存在するからである。MFAを適切に実装し、退職者・外部委託先のアカウントを定期的に棚卸しし、パスワードポリシーを徹底するだけで、このリスクは大幅に低減できる。

第三層：設計思想の欠陥

これが最も根本的な問題である。VPNの設計思想には、現代の脅威環境と相容れない構造が二つある。

一つは、VPNアプライアンスが常時インターネットに公開された「公開ポート」を持つ点である。VPNは外部からの接続を受け付けるためにポートを開き続けなければならず、これが攻撃者のスキャン対象となるアタックサーフェスを恒常的に生み出している。後述するZTNAが実現する「ダークIP」、すなわちサーバーをインターネット上から不可視化し攻撃者がスキャンしても存在自体が見えない状態と、根本的に異なっている。公開ポートが存在する限り、脆弱性が発見されるたびに「侵入の入口」が生まれ続けることになる。

もう一つは、「一度認証すれば内部ネットワークを自由に動ける」という暗黙の信頼モデルであることである。侵害後のラテラルムーブメントを止める仕組みがなく、製品脆弱性でも認証情報侵害でも、内部に入られた後の被害拡大を抑制することが難しい。Colonial Pipeline事件で侵入者が約100GBのデータを2時間で窃取できたのも、この構造があったからである。公開ポートによって「侵入される入口が常に存在する」こと、そして侵入後のラテラルムーブメントを許容してしまう設計が組み合わさることで、VPNは攻撃者にとって突破しやすく、突破後の被害も大きい構造になっている。この二点は、製品をより新しいものに替えたり、パッチを適切に当てたりするだけでは解決できない、アーキテクチャレベルの問題である。

「VPN問題」はVPN固有の問題か

ここで一度立ち止まって、「脱VPN」という議論はVPN特有の問題を論じているのか、それとも別の何かを論じているのかについて考えてみる。

結論から言うと後者の方に近いと言える。問題の本質は、「常時インターネットに公開され、内部ネットワークへの特権的なアクセスを持つ境界機器全般」に共通する構造的リスクである。ファイアウォール、ルーター、リモートデスクトップ、UTMなど、これらはすべて同じ構造を持っている。

2024年に複数の政府機関ネットワークへの侵入に使われた「ArcaneDoor」はCisco ASA（ファイアウォール）が標的だった。中国系APTのVolt Typhoonは、ルーターやファイアウォールを侵害してボットネット化し、他組織への攻撃の中継拠点として再利用するORB（Operational Relay Box）化の手法を用いている。これらはVPNとは別の機器だが、まったく同じ構造的問題を抱えている。 VPNが特に槍玉に挙がっているのは、第一にテレワークの普及でVPN機器の導入が急増し、アタックサーフェスが広がったこと、第二にランサムウェアの初期侵入経路として実績が積み重なり、報道での露出が増えたこと、第三に製品ベンダーが「脱VPN」をZTNA販売のマーケティングに活用していること、であると考えられる。つまり、「脱VPN」は正しい方向だが、VPNだけを替えれば終わりではなく、「境界機器に依存したアーキテクチャからどう脱却するか」が問題である。VPNはその最大かつ最も目立つ例に過ぎない。

国内統計データの正確な読み方

「ランサムウェア被害の63%がVPN機器経由」という数字は、セキュリティの議論で頻繁に引用されている。この数字の出所と正確な意味を確認しておきたい。

一次ソースは警察庁レポート

出所は警察庁「令和5年におけるサイバー空間をめぐる脅威の情勢等について」（2024年3月公表）である。ランサムウェア被害の有効回答115件を分析したもので、VPN機器からの侵入が73件（63%）、リモートデスクトップからが21件（18%）という結果が示されている。翌年の令和6年上半期版（2024年9月公表）では、VPN機器47%、リモートデスクトップ36%と変化しており、リモートデスクトップ経由の急増が目立っている。これはVPN対策が進む一方で攻撃者が侵入経路をシフトさせていることを示唆しているものと考えられる。

この数字で言えること・言えないこと

言えること：国内ランサムウェア被害において、VPN機器が初期侵入経路として最多であることは事実として裏付けられている。

言えないこと：この数字はVPN経由の侵害が「脆弱性悪用」と「認証情報侵害」のどちらによるものかを分離していない。警察庁レポートでは、「VPN機器のぜい弱性を悪用したり、強度の弱い認証情報等を利用して侵入」と両者を一括して記載している。

参考値として、侵入経路とされた機器のパッチ適用状況を尋ねたアンケートでは、令和5年データで約6割が「未適用のパッチがあった」、約4割が「最新パッチを適用済み」と回答している。後者はゼロデイ攻撃または認証情報侵害の可能性を示唆するが、断定はできない。IIJニュースでも「VPN機器からの侵入はブルートフォースや過去に漏洩したアカウント情報による不正利用が原因であることも多い」と述べており、認証情報侵害の割合も相当程度あると考えられる。

その他の意見

「IPsec VPNにすれば解決するのでは？」

SSL VPNではなくIPsec VPNを使えばよい、という反論はよく出てくる。答えは「実装は改善されるが、設計思想の問題は解決されない」となる。 IPsecにすることで、Ivanti等のSSL VPN製品固有の脆弱性リスクは低減できるが、「公開ポートによるアタックサーフェス」と「認証後のラテラルムーブメントを許容する設計」という第三層の問題は変わらない。IPsecはVPNをより堅牢にするアプローチであり、問題の所在が設計思想にある以上、IPsecへの切り替えは根本的な解にはならない。

「VPNを止めたらレガシーアプリが動かなくなる」

「VPNを止めたらレガシーアプリが動かなくなる」という懸念は、ZTNAの実装方式を選べば多くの場合解決できるが完全ではないと言える。

ZTNAには主に二種類の実装がある。主流の「L7プロキシ型」はHTTP/Sのヘッダーやセッション情報を読んでポリシー評価を行うため、独自TCP/UDPプロトコルに依存するレガシー基幹系・VoIP・映像伝送などは通信の解釈が難しく、対応が困難である。一方「L4トンネル型」（WireGuardベース等）はポート・IP単位で制コントロールするため、RDP・SSH・非HTTP/Sプロトコルにも対応しやすい。L7型と比べてポリシーの粒度は粗くなるが、VPNとは異なり認証後もネットワーク全体へのアクセスを許可するわけではなく、ラテラルムーブメントの抑制やダークIPの維持といったZTNAの本質的な利点は保たれる。

ただし実装方式にかかわらず対処できない領域が残る。OT機器・医療機器・産業用PLC等にはエージェントを導入できないため、ZTNAの管理下に置けない。この部分は「動かなくなる」のではなく「ZTNAで管理できない」という問題であり、VPNとのハイブリッド運用か別の手段を検討する必要がある。

結論として、「VPNを止めたらレガシーアプリが動かなくなる」は全体としては正しくなく、L4型ZTNAの選択と移行設計で大半は解決できることになる。残る課題はOT/IoT環境に限定されることになると考えられる。

「VPNを使い続けることは現状維持ではないのか？」

現状維持にもコストとリスクは発生する。アプライアンスのライセンス・運用・パッチコストの増大、侵害時の対応コストなどである。「今すぐ移行できないからVPNを続ける」という判断は、既知のリスクを可視化しないまま保有し続けることを意味する。

ZTNAへの移行は答えになるか

ZTNAがVPNの根本的な代替となりうる理由は、前述した設計思想の欠陥を直接解決するからである。その上で、この問いについて考えてみる。

ZTNAが解決するもの

ダークIP：ZTNAゲートウェイ経由でのみアクセスを許可し、サーバーのIPアドレス自体をインターネット上から不可視化する。公開ポートがなくなることでアタックサーフェスが根本から消える。
最小権限アクセス：ネットワーク全体ではなくアプリケーション・リソース単位でアクセスをコントロールする。侵害されてもラテラルムーブメントの被害を局所化できる。
継続的なコンテキスト認証：ユーザーIDだけでなく、デバイスの健全性・接続元・行動パターンをリアルタイムで評価し、リスクに応じてアクセスをコントロールする。
可視性の向上：誰が・何に・どこから・いつアクセスしたかを完全に記録できる。

ZTNAが解決が難しいもの

ZTNAを過信することも危険である。設計思想は優れていても、実装と運用が伴わなければ新たなリスクを生むことになる。

ポリシー設計の複雑さ：最小権限ポリシーの設計ミスは直接セキュリティホールに繋がる。VPNの「とりあえずつなぐ」運用から、精緻なポリシー管理への転換が必要である。
IdP依存：ZTNAはID基盤との連携が前提であり、IdPが単一障害点になりうる。ID基盤の整備が課題になることも多い。
ベンダーロックイン：標準化が未成熟でベンダーごとに実装が異なる。製品選定は長期的な視点が必要である。
レガシー環境の限界：ZTNAの主流であるL7プロキシ型はHTTP/Sと相性が良い一方、非HTTP/Sプロトコルへの対応は粒度が粗くなる。L4トンネル型（WireGuardベース等）はRDP・SSHなど非HTTP/Sにも対応しやすく、ラテラルムーブメントの抑制やダークIPの維持といったZTNAの本質的な利点は保たれる。OT機器・PLCなどエージェントを導入できないデバイスについても、SDPアーキテクチャではゲートウェイ側にネットワークコネクタを設置することで保護下に置くことができる。ただしOT環境特有のリアルタイム性・可用性要件への対応は設計段階で十分な検討が必要となる。

AIがVPN問題をどう変えるか

VPNをめぐる脅威環境は、AIの普及によって構造的に変化しつつある。攻撃側・防御側の双方でAIが使われるようになっており、その影響を把握しておくことは今後のセキュリティ戦略に不可欠である。AIは攻撃者にとって、これまで専門知識や時間を要していた作業を自動化・低コスト化するツールになっている。VPNをめぐる文脈で特に影響が大きい点は以下の三つであると考える。

第一は、マルウェアおよびエクスプロイトコードの自動生成である。警察庁は2024年に、生成AIを悪用してランサムウェアと思われる不正プログラムが作成された国内事例を公表している。従来、ランサムウェアの開発には高度な技術力が必要だったが、生成AIの登場でそのハードルが大幅に下がっている。RaaSのエコシステムと組み合わさることで、技術力の低い攻撃者でも洗練された攻撃が可能になりつつある。

第二は、脆弱性スキャンと初期侵入の自動化である。AIを使った自動スキャンツールは、インターネット上に公開されたVPNアプライアンスのバージョン情報や応答パターンから脆弱性の有無を高速に判定し、CVEが公開されたその日のうちに大量のターゲットへ攻撃を試みることができる。VPNの「公開ポートが常にアタックサーフェスになる」という設計上の問題は、AIによる自動スキャンの存在によってさらに深刻化している。かつては人間の攻撃者が手動で探索していた侵入口が、今や24時間自動で探索され続けている。

第三は、フィッシングと認証情報窃取の精度向上である。VPN経由の侵害の相当の割合が認証情報の漏洩を起点とすることは前述の通りであるが、AIを使ったフィッシングメールは文章の自然さ・ターゲティングの精度が飛躍的に向上しており、従来の「日本語が不自然なメール」という見分け方が通用しなくなってきている。また、AIによる音声・動画の偽造（ディープフェイク）を使って経営幹部になりすます攻撃も報告されており、ソーシャルエンジニアリングのリスクが全体的に高まっている。

まとめると、AIの普及は、VPNが持つ三つのリスクをいずれも悪化させる方向に作用する。製品脆弱性はAI自動スキャンによって即日悪用されるリスクが高まり、認証情報侵害はAI精度向上によるフィッシングで窃取しやすくなり、マルウェア展開は自動生成ツールの普及で参入障壁が下がる。「公開ポートが常にアタックサーフェスになる」という設計上の問題は、AI時代においてより高速・大規模に突かれる環境に変わりつつあるといえる。

まとめ

ここまでの内容を踏まえ、IT部門・情報システム担当が今取るべきアクションを、時間軸と優先度で整理してみたい。「脱VPN」は方向性として正しいが、すべてを同時に進める必要はない。重要なのは、リスクを可視化した上で、組織の状況に応じた順序で手を打つことである。

今すぐ着手すべきこと（製品・アーキテクチャを問わない基本対策）

これらはZTNAへの移行の有無にかかわらず、現時点で実施しなければならない最低限の対策である。AIによる攻撃の高度化を考慮すると、後回しにするほどリスクが増大することになる。

VPN機器のファームウェア・パッチ適用状況を棚卸しし、未適用のものを即時適用する。サポート終了機器が存在する場合は、更新計画を立てる
すべてのVPNアカウントにMFAを設定する。特に退職者・外部委託先・長期未使用のアカウントを優先的に無効化する（ゾンビアカウントの排除）
VPN接続ログの監視を強化する。通常と異なる接続元IP・時間帯・通信量の異常をアラートできる仕組みを整備する
IPA、JPCERTの脆弱性情報にサブスクライブし、使用中のVPN・ファイアウォール製品に関するCVEを即座に検知できる体制を作る

中期的に進めること（ZTNAへの移行の準備と段階的実施）

ZTNA移行の前提条件を整えながら、リスクの高い部分から順に置き換えていく。完璧な計画を待つより、部分的にでも移行を始めることの方が重要である。

ID基盤の整備：ZTNAはIdPとの連携が前提となる。Active Directoryのクラウドへのリフト、Entra ID等の整備を先行させる必要がある
外部委託先・サードパーティのリモートアクセスをVPNからZTNAに置き替える。ゾンビアカウントリスクが最も集中する領域であり、効果が出やすい
SaaSアクセスにZTNA/SWGの要素を導入し、クラウドへのバックホール問題を解消しながらゼロトラストの経験を蓄積する
VPN機器が担っている機能（拠点間通信等）を棚卸しし、ZTNA、SD-WAN、SASEのどの組み合わせで代替するとかの設計を行う

長期的な目標（アーキテクチャの完全転換）

テレワーク、全社員のリモートアクセスをZTNAに完全移行し、物理的なVPNアプライアンスを廃止する
「インターネットに公開されたポートを持つ境界機器」をネットワーク設計から排除し、ダークIPアーキテクチャを実現する
継続的なポスチャ評価（デバイス健全性・コンテキスト認証）を全アクセスに適用し、AIを活用した異常検知と組み合わせる

経営層への説明

IT部門から経営層へのエスカレーションでは、技術的な詳細より「リスクの受容判断を経営として行う必要がある」という点を明示することが重要である。

「VPNを維持することはゼロコストの現状維持ではない。既知のリスクを保有し続けるという意思決定だ」と明示する
インシデント発生時の対応コスト（調査・復旧・賠償・事業停止損失）とZTNA移行投資を比較したROI試算を提示する
「今すぐ全廃」ではなく「段階移行ロードマップ」として提示することで、意思決定のハードルを下げる
AIによる攻撃の高度化を根拠として、「従来より速いスピードで脆弱性が突かれる環境になっている」という脅威環境の変化を説明する

VPNは問題のない技術ではなく、既知のリスクを抱えたまま動いているインフラである。製品脆弱性・認証情報管理・設計思想の三層すべてに問題があり、AIの普及がその脅威を加速させている。「脱VPN」の方向性は正しく、いつ・どこから始めるかという段階的なアプローチが望ましいと考える。

以上

開発者向けクラウドネイティブセキュリティの基礎（アプリケーションセキュリティ編）(2)

コメントをどうぞ

前回のアプリケーションセキュリティ編(1)（https://cloudsecurityalliance.jp/newblog/2026/02/22/apsec_1/）では、AIシステムのうちエージェンティックAI固有のセキュリティ課題や対策について取り上げた。今回は、AIシステムの橋渡し役を担うAPIのセキュリティに焦点を当てる。

LLMアプリケーションを支えるAPIセキュリティ

クラウドセキュリティアライアンス（CSA）の2021年5月11日付ブログ記事「OWASP APIセキュリティ Top 10の理解」（関連情報（https://cloudsecurityalliance.org/blog/2021/05/11/understanding-the-owasp-api-security-top-10/））では、CSAとグローバルレベルで連携するOWASPのドキュメントの中で、アプリケーション・プログラミング・インターフェース（API）特有の脆弱性やセキュリティリスクを理解し、それらを軽減するための戦略とソリューションに焦点を当てた「OWASP APIセキュリティ Top 10」初版（2019年12月公開）を紹介している（関連情報（https://owasp.org/API-Security/editions/2019/en/0x11-t10/）。その後2023年6月、OWASPは「OWASP APIセキュリティ Top 10」第２版を公開している（関連情報（https://owasp.org/API-Security/editions/2023/en/0x11-t10/））。第２版のAPIセキュリティTop 10各項目は、以下の通りである。

・API1:2023 BOLA (オブジェクトレベルの認可不備) ：
IDを指定してデータを得る際、他人のデータにアクセスできてしまう問題（最重要）。
・API2:2023 認証の不備：
パスワードやトークンの管理、JWTの検証ミスなど。
・API3:2023 オブジェクトプロパティレベルの認可不備：
特定のフィールド（例：管理用フラグ）の読み取りや書き換えを許してしまう問題。
・API4:2023 制限のないリソース消費：
呼び出し回数やデータ量の制限がなく、DoS状態や高額請求を招く問題。
・API5:2023 機能レベルの認可不備：
一般ユーザーが管理者用APIエンドポイントを実行できてしまう問題。
・API6:2023 機密性の高いビジネスフローへの無制限アクセス：
買い占めやスパムなど、正規の機能でも自動化されるとビジネスに害を及ぼすケース。
・API7:2023 SSRF (サーバーサイドリクエストフォージェリ) ：
APIサーバーを踏み台にして、内部ネットワークに攻撃を仕掛けられる問題。
・API8:2023 セキュリティ設定のミス：
不要な機能の有効化、古いパッチ、不適切なCORS設定など。
・API9:2023 不適切なインベントリ管理：
放置された旧バージョン（ゾンビAPI）や未把握のAPI（シャドウAPI）の放置。
・API10:2023 APIの安全でない利用：
連携先のサードパーティAPIから届くデータを盲信し、検証せず処理してしまう問題。

　さらにCSAは、2025年5月9日付で、「LLMのためのOWASP Top 10：CSAによる戦略的防御プレイブック」（関連情報（https://cloudsecurityalliance.org/blog/2025/05/09/the-owasp-top-10-for-llms-csa-s-strategic-defense-playbook））と題するブログ記事を公開している。ここでは、OWASPの「LLMアプリケーションのためのOWASP Top 10 (2025年版)」（2024年11月17日公開、関連情報（https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/））を紹介している。LLMアプリケーションのためのOWASP Top 10各項目は、以下の通りである。

・LLM01:2025 プロンプトインジェクション：
ユーザー入力によってモデルの挙動が意図せず変更される。ジャイルブレイク(脱獄)も含む。
・LLM02:2025 機密情報の漏えい：
モデルが学習・出力する内容により、個人情報や知的財産が漏えいする可能性。
・LLM03:2025 サプライチェーンの脆弱性：
トレーニングデータや外部モデルの改ざん・汚染によるリスク。
・LLM04:2025 データおよびモデルのポイズニング：
故意に不正なデータを混入させて、モデルの出力を操作する攻撃。
・LLM05:2025 出力の不適切な取り扱い：
モデルの出力を無検証で使用することにより、誤情報や有害な結果を招く。
・LLM06:2025 過剰なエージェンシー：
モデルが過度に自律的に判断・行動することで、制御不能なリスクが生じる。
・LLM07:2025 システムプロンプトの漏えい：
内部設定や指示が外部に漏れることで、攻撃者に悪用される可能性。
・LLM08:2025 過剰なリソース消費：
LLMが過剰な計算資源を消費し、サービス停止やDoSにつながる。
・LLM09:2025 不適切なアクセス制御：
モデルや関連システムへのアクセス制御が不十分で、情報漏洩や改ざんのリスクがある。
・LLM10:2025 ガバナンスとコンプライアンスの欠如：
法規制や倫理的枠組みに対する配慮が不足し、企業リスクを高める。

CSAは、「LLMアプリケーションのためのOWASP Top 10」を実行可能なセキュリティファーストの指針へと対応づけることにより、組織が責任を持って、かつレジリエントにAIを導入できるよう支援することを目指すとしている。

なお、LLMアプリケーションのためのOWASP Top 10では、LLMアプリケーションにおけるAPIの役割を、以下のように位置付けている。

・APIは外部アプリケーションがLLMの機能を利用するためのゲートウェイである。
・APIは外部アプリケーションとLLMとの通信のルールを定めている。
・APIはアプリケーションからのリクエストをLLMに渡し、生成されたコンテンツを再びアプリケーションに返す仲介役である。
・APIキーやトークンによる認証を通じて、アクセス制御を行うことにより、不正利用やデータ漏えいのリスクを軽減する。

AIで急増するM2MトラフィックがもたらすAPIの変容

次に、CSAのブログ記事「AI時代におけるAPIセキュリティ」（関連情報（https://cloudsecurityalliance.org/blog/2025/09/09/api-security-in-the-ai-era））では、API（アプリケーション・プログラミング・インターフェース）の利用形態の変容について触れている。かつてAPIは、主にWebやモバイルアプリの舞台裏で機能する統合レイヤーであったが、現在ではAIシステム、クラウドサービス、そして分散型アプリケーションにとっての「主要なゲートウェイ」となっている。

このようなAPIの変容は、単なる規模の変化にとどまらず、脅威モデルそのものに変化をもたらしている。大規模言語モデル（LLM）を搭載したAIシステムは、膨大な量のデータを消費・生成する。そのデータの多くは、従来のネットワーク・インターフェースに比べて監視が不十分になりがちなAPIを通じて流れている。事実上、APIは企業の機密データにおける「正面玄関」であり、「配送トラック」であり、時には「金庫」そのものになっているのが実情である。

セキュリティ企業Traceableの報告書（関連情報（https://www.traceable.ai/2025-state-of-api-security））によると、APIに関連するデータ侵害は増加傾向にあり、その検知も不十分である。さらに、AIによるAPI利用の導入が、攻撃の量と種類の両面を拡大させている。

かつてAPIの呼び出しの多くは、ポータルへのログイン、データのリクエスト、フォームの送信といった「人間による操作」がトリガーとなっていた。しかし現在では、マシン・ツー・マシン（M2M）トラフィックを介して、AIシステムが自律的かつ大規模なスケールでAPIの呼び出しを行っている。かつては1日に数百回程度だったAPIへのアクセスが、AI駆動のワークロードによって、今や1分間に数千回ものリクエストが発生するようになっている。

また、AIエージェントは複数のAPIを連鎖させ、次にどのエンドポイントにアクセスすべきかを複雑に判断することも可能である。これらのツールは、ユーザーのプロンプトや環境データに基づいて多様なリクエストを生成するため、比較対象となる固定されたベースライン（基準）のパターンが存在せず、異常検知をより困難なものにしている。

攻撃者はAIを悪用してペイロード（データ本体）を改ざんし、悪意のあるコードを難読化したり、単純なシグネチャベースのルールを回避する「合成（synthetic）」リクエストシーケンスを生成したりする。数百ものAPIを抱える組織にとって、露出したすべてのエンドポイントをカバーできるよう検知ルールを迅速に修正・更新し続けることは困難である。WAF（Web Application Firewall）のルールやOWASP Top 10の対策だけに依存していては、大きなセキュリティギャップが残ることになる。

生成AIツールは、公開されているAPIドキュメントを自動的に解析し、即座に実行可能な攻撃シナリオを生成できるため、攻撃側の手作業を劇的に削減する。また、モデルの学習、知的財産の窃盗、あるいは競合情報の収集といった目的のために、公開APIからのデータ収集を自動化することも可能になっている。

AI主導の統合が進むことにより、APIの採用は加速している。コンテンツAPI、データAPI、サービスAPI、ストリーミングAPI、さらにはその他の派生形が、多くのチームが追跡や保護を行える速度を超えて次々と登場している。この急速な拡大従って、以下のようなリスクが顕在化しつつある。

・シャドウAPI（Shadow APIs）: セキュリティレビューを回避して公開された、ドキュメント化されていないエンドポイント。
・ゾンビAPI（Zombie APIs）: 更新が停止しているにもかかわらず、アクセス可能な状態で放置された古いAPI。
・孤立したAPI（Orphaned APIs）: 組織内に明確な所有者が存在しないエンドポイント。

特に、社内のAI実験のために開発されたAPIは、適切なドキュメント化やバージョン管理が欠如していることが多く、結果として長期的な「セキュリティ上の負債」となる。さらに、AIシステムはサードパーティAPIの連鎖（チェイン）に依存する場合があり、組織が直接制御できない外部の脆弱性が持ち込まれるリスクもある。ベンダー側でのAPI変更により、通知なくセキュリティ上の退行（リグレッション）が発生する可能性も否定できない。

そこでこのブログでは、以下の通り、11の実行可能な推奨事項とベストプラクティスを提示している。

1.リアルタイムのAPIインベントリの構築と維持：
クラウド、オンプレミス、コンテナ、エッジの全環境をスキャンし、APIを自動検出するツールを導入する。それらを「公開」「パートナー用」「内部用」に分類し、AIシステムに関連するものはタグ付けする。インベントリチェックをCI/CDに統合し、デプロイ前に新しいAPIが登録されるようにする。また、ネットワークやアプリの目録と定期的に照合し、シャドウAPIや放置されたAPIを特定しておく。

AI統合APIへの「ポジティブセキュリティモデル」の採用：
OpenAPIやSwaggerの仕様書を使用して、「正当な」トラフィックの定義を明確に行う。APIゲートウェイでスキーマ検証を強制し、仕様に一致しないリクエストは拒否する。AIによる過剰なリクエストを防ぐためにレート制限を適用する。また、振る舞い検知を導入してAIエージェントの標準的なパターンを学習させ、逸脱をリアルタイムで検知する。このモデルは固定せず、APIの変更に合わせて更新し続ける生きたプロセスとして扱うこと。
APIの認証と認可の保護：
自動期限切れ機能を持つ短命トークンを導入し、キーを定期的にローテーションする。認証情報はシークレット管理プラットフォームで安全に保管しておく。マシン・ツー・マシン（M2M）のAPIコールにはmTLS（相互認証TLS）を必須とする。OAuth 2.0のスコープやABAC（属性ベースアクセス制御）ルールを適用し、トークンの権限を制限しておく。特にAIエンドポイントでは、権限過剰を防ぐため、学習データのアップロード、推論、モデル管理などの機能ごとに権限を分離する。
APIドリフト（仕様乖離）と不正な変更の監視：
稼働中のAPIの挙動と承認済み仕様を比較する、自動化された「ドリフト検知」をセットアップしておく。すべてのAPI仕様にバージョン管理を導入し、特にAI関連の変更にはコードレビューを義務付ける。ドリフト監視とエンドポイントのフィンガープリント（指紋認証）を組み合わせることにより、ガバナンス外で追加された新しい機能やパラメータを迅速に発見できるようにする。
データ漏えいの検知と遮断：
APIゲートウェイにDLP（データ損失防止）ルールを実装し、外部へのレスポンスに個人識別情報（PII）、APIキー、知的財産などの機密パターンが含まれていないかスキャンする。正規表現やAIベースのコンテンツフィルタを用いて、より深い検査を行っておく。異常に大きなレスポンスペイロード、特にAIエンドポイントからのものには警告を発する。「LLMに接続されたAPI経由で財務データが流出する場合にフラグを立てる」といったコンテキストに基づくルールを適用し、漏えいが確認された場合はリアルタイムで遮断することを検討しておく。
敵対的AI（Adversarial AI）の脅威への備え：
プロンプトインジェクション、不正な形式のデータ、モデル回避の試みなど、悪意のある入力を用いてAPIをテストする。AIモデルに到達する前に、すべてのテキスト、ファイル、画像入力に対して無害化を行う。ポイズニング（学習データ汚染）が検知された場合に備え、安全なモデルバージョンに巻き戻すためのロールバック計画を維持しておく。開発者が敵対的なパターンを認識し、AIの出力を信頼する前に検証できるようトレーニングを行い、開発ライフサイクルに「AI安全性の視点」を組み込む。
API主導の侵害に対するインシデントレスポンスの強化：
IP、トークンID、リクエストのフィンガープリントを含む詳細なAPIログをSIEM（セキュリティ情報イベント管理）に集約する。連絡先、封じ込め手順、復旧プロセスを詳述したAPI専用のランブックを整備しておく。APIの連鎖攻撃やAI関連の不正利用を含むシミュレーションを実施し、対応ワークフローの有効性を検証して、検知から対応までの時間を短縮する。
DevSecOpsへのAPIセキュリティの組み込み：
CI/CDパイプラインにおいて、静的・動的テストによるAPIスキャンを自動化する。安全でないエンドポイントの導入や認証のバイパスを許すビルドは避ける。AI向けAPIを本番公開する前には、セキュリティ部門の承認を必須とする。依存関係スキャンを利用して、AI関連ライブラリにパッチが適用されていることを確認する。仕様検証やファジーテストは、定期的なレビューだけでなく、継続的インテグレーションの一部として組み込む。
組織内におけるAPIセキュリティ専門知識の育成：
OWASP API Top 10、AI APIのリスク、敵対的機械学習の脅威に関するターゲットを絞ったトレーニングを実施する。開発者、セキュリティエンジニア、AIスペシャリストが定期的に知見を共有する場を作っておく。セキュリティ会議やワークショップへの参加を奨励し、社内ハッカソンでAPIの攻防シナリオをシミュレートすることにより、実践的なスキルを向上させる。
初日からの「最小権限の原則」の適用：
すべてのAPIに対して、ロールベース（RBAC）および属性ベース（ABAC）のアクセス制御を使用する。「推論用」と「モデル学習用」でトークンを分けるなど、きめ細かなスコープを割り当てておく。機密性の高いAPIエンドポイントへのアクセスを、承認されたIP範囲やデバイスに制限する。管理者アクションには一時的な認証情報を発行し、使用後は直ちに失効させます。権限がビジネスニーズと一致しているか、定期的に監査を行っておく。
データ・サプライチェーンの保護：
デプロイ前にすべてのAIモデル資産（アーティファクト）に署名し、検証を行っておく。すべてのデータパイプラインを保護し、転送中のデータは暗号化する。リリース前にAIライブラリを含むすべての依存関係に脆弱性がないかスキャンする。データセットとモデルのバージョン管理を徹底しておく。APIの統合においてもソフトウェア部品構成表（SBOM）の原則を適用し、すべてのコンポーネントを追跡・検証できるようにする。

APIはもはや、単なるバックエンドの利便性のためのツールではない。AI時代において、APIはデジタルビジネスの「中枢を担う動脈」である。その露出度、複雑性、そして変化の速度は劇的に増大しており、それらを標的とする脅威も同様に高度化している。継続的な可視化（継続的なモニタリング）と、適応型の「AIを考慮したセキュリティプラクティス」を組み合わせることのできるITおよびセキュリティの専門家こそが、組織を保護するための最善のポジションを確保することになるだろうと結論付けている。

米国NISTがクラウドネイティブシステムのAPI保護ガイドライン更新版を公開

米国立標準技術研究所（NIST）は、2026年3月16日、「NIST SP 800-228-upd1クラウドネイティブシステムにおけるAPI保護のためのガイドライン」（関連情報（https://csrc.nist.gov/pubs/sp/800/228/upd1/final））を公開した。本書は、2025年6月27日に公開された同ガイドライン初版（関連情報（https://csrc.nist.gov/News/2025/nist-releases-sp-800-228））の更新版である。

現代のエンタープライズITシステムは、組織のビジネスプロセスを支える統合手段として、一連のAPIに依存している。APIを安全にデプロイするためには、APIライフサイクルの各フェーズにおけるリスク要因や脆弱性の特定、および管理策や保護措置の開発が必要となる。今回の更新版ガイドラインでは、この目的を達成するために以下の側面を扱っている。

(a) APIの開発およびランタイムにおける様々なアクティビティ中のリスク要因、または脆弱性の特定と分析
(b) APIのプリランタイム（実行前）およびランタイム（実行時）の各段階において推奨される、基本的および高度な管理策と保護措置
(c) セキュリティ実務者が、リスクに基づいた段階的なアプローチで自社のAPIを保護できるよう、これらの管理策を実現するための様々な実装オプションに関する長所と短所の分析

　本更新版ガイドラインは、以下のような構成になっている。

エグゼクティブ・サマリー

はじめに
1.1. ゼロトラストとAPI：消失する境界
1.2. APIライフサイクル
1.3. 本文書の目的
1.4. 他のNIST文書との関係
1.5. 本文書の構成
APIのリスク：脆弱性とエクスプロイト（攻撃）
2.1. 企業インベントリにおけるAPIの可視性の欠如
2.2. 認可の欠如、誤り、または不十分な認可
2.3. 認証の不備（Broken Authentication）
2.4. 制限のないリソース消費
2.4.1. 制限のないコンピューティングリソースの消費
2.4.2. 制限のない物理リソースの消費
2.5. 権限のない呼び出し元への機密情報の漏えい
2.6. 入力データの検証不十分
2.6.1. 入力バリデーション
2.6.2. 悪意のある入力からの保護
2.7. クレデンシャルの正規化：管理策のための準備段階
2.7.1. 境界をまたぐゲートウェイ
2.7.2. サービスIDはあるがユーザーIDがないリクエスト
2.7.3. ユーザーIDはあるがサービスIDがないリクエスト
2.7.4. ユーザーIDとサービスIDの両方を持つリクエスト
2.7.5. 他システムへのアウトリーチ
2.7.6. 「混乱した代理人（Confused Deputy）」問題の緩和
2.7.7. アイデンティティの正規化
APIに推奨される管理策
3.1. プリランタイム（実行前）保護
3.1.1. 基本的なプリランタイム保護
3.1.2. 高度なプリランタイム保護
3.2. ランタイム（実行時）保護
3.2.1. 基本的なランタイム保護
3.2.2. 高度なランタイム保護
API保護の実装パターンとトレードオフ
4.1. 中央集約型APIゲートウェイ
4.2. ハイブリッドデプロイメント
4.3. 分散型ゲートウェイパターン
4.4. 関連技術
4.4.1. Webアプリケーションファイアウォール（WAF）
4.4.2. ボット検知
4.4.3. 分散型サービス拒否（DDoS）攻撃の緩和
4.4.4. APIエンドポイント保護
4.4.5. Web Application and API Protection (WAAP)
結論とまとめ
参考文献
附表A. API分類の体系
A.1. 公開度に基づくAPI分類
A.2. 通信パターンに基づくAPI分類
A.3. アーキテクチャスタイルまたはパターンに基づくAPI分類（APIタイプ）
A.4. データの機密性に基づくAPI分類
附表B. DevSecOpsのフェーズと関連するAPI管理策のクラス
附表C. ランタイム中に設定される制限のタイプ
附表D. リスクカテゴリ別のAPIリスク一覧
附表E. APIライフサイクル段階別の推奨セキュリティ管理策一覧
附表F. 変更履歴

APIは、企業のデジタルインフラにアプリケーションを統合する上で極めて重要な役割を果たしている。物理的・論理的なアプリケーションがいずれも高度に分散している現状を踏まえ、NISTは、APIが外部に公開されているか、あるいは企業インフラ内の他のアプリケーションによって消費されるものであるかにかかわらず、ゼロトラスト原則に基づいて運用することを推奨している。すべてのソフトウェアと同様に、APIは反復的なライフサイクル（開発、構築、デプロイ、運用）を経て、これらは大きく「プリランタイム（実行前）」と「ランタイム（実行時）」の段階に分類される。

APIデプロイメントの急激な拡散、それらが動作する異種混合のインフラ、そしてAPIが可能にする貴重な企業データへのアクセスは、これらが攻撃の標的になる背景となっている。APIセキュリティを確保するために適切な保護手段や管理策を特定するには、脆弱性とそれらを悪用する可能性のある攻撃ベクトルの詳細な分析が前提条件となる。このNIST文書では、正式なスキーマの欠如、不適切なインベントリ管理、堅牢な認証・認可サポートの欠如、リソース消費の不適切な監視、機密情報の漏洩に対する不十分な制御など、脆弱性を引き起こすさまざまなリスク要因を分析している。

本ガイドラインで推奨される管理策は、「プリランタイム保護」と「ランタイム保護」に分類されている。さらに、企業がリスクに基づいた段階的なアプローチでデジタル資産を保護できるよう、これらは「基本保護」と「高度な保護」に細分化されている。プリランタイム保護はAPI仕様のパラメータ（構文的および意味的側面）に焦点を当て、ランタイム保護はAPIのリクエストおよびレスポンス操作（暗号化された通信チャネル、適切な認証・認可など）に焦点を当てている。

このガイドラインは、各タイプの保護、デプロイ、またはパターンの利点と欠点を説明することにより、推奨される管理策を構成・適用するための実用的かつ標準的な実装オプションを提示している。NISTは、これにより、実務者が情報に基づいた意思決定を行い、自社にとって堅牢でコスト効率の高いAPIセキュリティインフラを実現することを可能にするとしている。

APIは今やビジネスの中枢を担う動脈となりつつある。従来の境界型防御に頼るのではなく、継続的な可視化とAIの特性を考慮した適応型セキュリティへのシフトが不可欠となっている。

CSAジャパン関西支部メンバー
DevSecOps／サーバーレスWGリーダー
笹原英司

CSAIについて

コメントをどうぞ

2026年3月24日
CSAジャパン　理事　諸角昌宏

RSAC2026でアナウンスのあったCSAI Foundationについて、公開されている情報を元にまとめてみました。

目的

AIが、単なる支援ツールから、ワークフローを調整し、デジタルインフラ全体で連携し、意思決定を行うことができる自律システムへと急速に進化しています。そのような状況を受けて、CSAIは、AIのセキュリティ、セーフティ、トラストを推進することを使命としてクラウドセキュリティアライアンス（CSA）によって、設立されました。

CSAIは、商業主導の取り組みでは提供できない、AIセキュリティにおける不可欠なリーダーシップを提供します。それは、エコシステム全体が依拠できる、中立的かつ標準に基づいたガードレールです。この独立した研究は、実世界のエージェンティックAIシステムをセキュアに保つために必要な運用上のトラストインフラを構築するというCSAIの役割に直接反映されます。

CSAI、2026年ミッション

以下の6つの戦略プログラムを行います：

AIリスクオブザバトリー　エージェントの実環境における動作・障害・リスクをリアルタイムで可視化。次世代CVE Numbering Authority（CNA）の運営も含む。
エージェンティックベストプラクティス　企業向けのセキュアなエージェント実施ガイドライン、ID優先のアクセス制御、ランタイム認可ガバナンスなど。
教育・資格認定　TAISE資格のCxO向け・エージェント専門家向け・高校生向けへの拡充。エージェンティックAIサミットシリーズの開催。
CxOtrust　CISOs・CIOs・CAIOsを対象とした経営層向けラウンドテーブルや取締役会向けリスク報告フレームワークの提供。
グローバルアシュアランス＆トラスト　CSA STARのAIシステムへの拡張（ISO 42001・SOC 2準拠）、AIを活用した自動監査エンジン「Valid-AI-ted」の開発。
フューチャーフォワード　エージェント向けTAISE資格認定、エージェント相互作用のテスト環境「CSA Pod」、そして将来のAIによる壊滅的リスクを研究する「Catastrophic Risk Annex」。

これらの取り組みは、独立した研究を実践的なプログラムへと転換し、エージェンティックコントロールプレーンをリアルタイムのリスクインテリジェンス、実施可能なベストプラクティス、および継続的なアシュアランスにわたって実際に保護するものとなります。

以上

クラウドセキュリティは不要か？ ~ クラウドセキュリティは情報セキュリティの一部として整理すべきか

6件の返信

2026年3月23日
諸角　昌宏

クラウドが企業のインフラとして本格的に普及し始めた2000年代後半、セキュリティは最大の懸念事項として繰り返し取り上げられた。「データをどこに置くかわからない」「自分でコントロールできない」。そうした不安を背景に、CSAの設立（2009年）、ISO/IEC 27017の策定（2015年）、各CSPによるセキュリティフレームワークの整備など、クラウドセキュリティのベストプラクティスを積み上げるための取り組みが業界全体で重ねられてきた。
そうした積み重ねを経た今、「クラウドセキュリティは情報セキュリティの一部として整理すればよい」という意見を耳にするようになった。ある意味では成熟の証とも言える。ただ、この意見には「概ね妥当だが、そのまま受け入れるには少し注意が必要」と筆者は考えている。クラウド環境ではリスクの発生メカニズムが変わり、責任の所在が分断され、従来の情報セキュリティだけでは見落としが生まれやすい構造がある。「一部である」ことは正しい。しかし「だから特別な考慮は不要」とはならないと考える。本ブログでは、その理由を整理し、具体的にどのようなリスクを念頭に置くべきかを示していきたいと考えている。

命題の構造

「クラウドセキュリティは情報セキュリティの一部として整理すればよい」という主張には、以下の2つの前提が埋め込まれていると考えられる。

前提①　クラウドセキュリティの原則は情報セキュリティと共通している
前提②　共通しているなら、情報セキュリティとして一括して扱えばよい

前提①は「概ね妥当」と言えそうである。CIAの三要素（機密性・完全性・可用性）はクラウドにも適用される。リスク評価・インシデントレスポンスの考え方も情報セキュリティの原則がそのまま使える。その意味では「一部である」という捉え方に一定の合理性がある。
ただし、前提②は必ずしも自明ではないように思われる。「同じ原則が適用できる」ことと「同じ対策で十分である」こととは、少し異なる話ではないだろうか。では、なぜ同じ対策では十分でないのか。その理由を考えるには、クラウド環境におけるリスクの性格を少し丁寧に見ておく必要がある。

クラウド環境でリスクはどう変わるか

ここで、「同じ対策では不十分」という感覚の背景には、クラウド環境がリスクの発生メカニズムを変えているという事実がある。ここで少し立ち止まって、「クラウド固有のリスク」という言葉自体を問い直してみたい。設定ミス・過剰権限・データの不適切な公開・認証の不備など、これらはいずれもクラウド以前から存在していたリスクであり、クラウドが新たに生み出したものではない。より実態に近い言い方は「クラウドで特に考慮が必要なリスク」であると言える。リスクの種類が固有なのではなく、リスクの顕在化しやすさ・影響規模・発生メカニズムが、クラウド環境において特殊な形をとる、ということだと考える。以下に、同じリスクがクラウドで増幅されやすい4つの構造的な理由を上げる。

スケール：APIひとつの設定ミスが数百万件規模のデータに即時影響しうる
速度：IaCの導入などによりミスが複製・展開される速度が人間の確認速度を超えやすい
境界の曖昧さ：「内側は安全」という境界が流動的で自明でなくなっている
責任の分断：CSPと利用者の責任分断により「誰が対処するか」が見えにくくなる

こうした増幅のメカニズムを理解すると、「情報セキュリティの一部として扱えば十分か」という問いへの答えが少し見えてくる。この点について、国際規格の体系はひとつの示唆を与えてくれる。

ISO/IEC 27001と27017が示す規格上のヒント

ISO/IEC 27001の改訂の歴史と、27017との関係を辿ると、「情報セキュリティの一部ではあるが、専門的な深さは別途必要」という考え方が、規格の構造としても反映されてきたように見える。

規格	クラウドセキュリティの扱い
ISO/IEC 27001:2013	クラウドを独立して扱っていない。供給者関係（A.15）の中にクラウド利用が包含される形にとどまり、クラウド固有の考慮事項は規定されていない。
ISO/IEC 27001:2022	新たに「A.5.23 クラウドサービスの利用における情報セキュリティ」を独立した管理策として追加。クラウドサービスの取得・利用・管理・終了のライフサイクル全体にわたるポリシーとプロセスの確立を求めている。ただし「何をすべきか」の入口レベルの規定にとどまっている。
ISO/IEC 27017	27001の補完規格（ガイダンス規格）。クラウド固有のセキュリティ管理策を実装レベルで規定。CSPとCSCそれぞれの責任を明示し、仮想環境の分離・管理者権限の制限・クラウド環境の監視・データ削除の確認など、27001では扱われないクラウド固有の管理策を追加している。

27001:2022でA.5.23が独立した管理策として追加されたことは、ISO/IECがクラウドを「供給者関係の延長」として扱うだけでは不十分と判断した結果と見ることができる。同時に、A.5.23が「入口レベル」にとどまることで、27017との役割分担がより明確になったとも言えそうだ。27001:2022が「クラウドを使う組織が最低限押さえるべきこと」を示し、27017が「実装レベルの詳細なコントロール」を補うという二層構造となっている。加えて27017の特徴として、CSPとCSC双方に対して異なる管理策を定めている点が挙げられる。これは27001:2022にはない視点であり、「クラウドにおけるセキュリティ責任は一者に帰属しない」という責任共有モデルの考え方を、規格レベルで反映したものと捉えることができる。

27001:2013の時点では「27001だけでは不十分だから27017が生まれた」という話であったが、27001:2022でA.5.23が追加された。しかしながら、27001本体がクラウドを取り込んだにもかかわらず、それでも27017は廃止されず、補完規格として併存し続けている。つまり「27001にクラウドが入れば27017は不要になる」とはならなかった。これは「入口レベルの要求事項」と「実装レベルの詳細なコントロール」は、同一のフレームワークでは代替できないということを示していると考えられる。

ベンダーニュートラルな概念はまだ必要か

AWS、Azure、GCPといったCSPは、自社サービスに特化した詳細なセキュリティ文書を継続的に更新している。また、CSAガイダンスは、V4まではクラウドセキュリティの概念を中心とした内容であったが、V5ではより具体的な実装レベルの内容にシフトしている。こうした状況の中で、ベンダーニュートラルにクラウドセキュリティの概念を説明することに、まだ意味はあるのだろうか。筆者は、意味はあると考えるが、「誰にとっての意味か」は以前より明確に問われるようになってきているように感じる。

立場	ベンダーニュートラルな概念の必要性
実装担当者（単一CSP）	CSPの文書で実装が回る場面は多い。ただし、概念の裏付けなく手順だけを習得している場合、「設定は文書通りにやったはずなのになぜ問題が起きたか」という状況につながる可能性がある。
実装担当者（マルチクラウド）	マルチクラウドの横断的リスク管理にはCSP固有の知識だけでは不十分と考えられる。ベンダーニュートラルな概念が明示的に求められる場面と言える。
設計・アーキテクト	CSPの選定・評価・責任境界の設計は、特定CSPの操作知識よりも概念的な基盤が判断の軸になる。
セキュリティ評価・監査	複数CSPを横断して評価するには、共通の基準軸が必要になる。
経営・ガバナンス層	投資判断・リスク許容・規制対応は、概念レベルの理解が前提になる。

CSAガイダンス v5が具体策にシフトした背景には、CSPの文書との競合というより、「概念だけでは実務で参照されにくくなった」という現実への対応があると思われる。ただし逆説的に、具体策の詳細が増すほど、その具体策をどのCSPに、どの優先順位で適用するかを判断するための概念的基盤の価値は相対的に高まるものと考えられる。

まとめ

ここまでの内容を振り返ると、「クラウドセキュリティは情報セキュリティの一部として整理すればよい」という考え方には、一定の合理性があることがわかる。クラウドセキュリティの原則は情報セキュリティと共通しており、CIA三要素やリスク評価の考え方はクラウド環境にもそのまま適用できる。

ただし、「原則が共通している」ことと「同じ対策で十分である」こととは、少し異なる話ではないかと考える。クラウド環境では、同じリスクがスケール・速度・責任の分断・境界の曖昧さという4つの構造的な特性によって増幅されやすい。この点を踏まえると、「情報セキュリティの一部ではあるが、クラウド特有の深さは別途必要」というのが、この問いへのひとつの答えではないかと考える。 ISO/IEC 27001:2022がA.5.23としてクラウドを独立コントロールに加えたこと、27017がCSPとCSC双方への管理策を別途定めていること、そしてベンダーニュートラルな概念が設計・評価・ガバナンスの立場では依然として必要とされていること。これらはいずれも、クラウドセキュリティが「情報セキュリティに吸収されて完結する」のではなく、「情報セキュリティの基盤の上に専門的な理解が積み重なる」という構造を示唆しているのではないかと考えられる。

付録：クラウドで特に考慮が必要なリスク

以下は「クラウドで特に考慮が必要なリスク」をまとめたものである。ISO/IEC 27017が定めるクラウド固有の管理策領域を骨格にしつつ、実務・インシデント事例・規制の観点を加えて整理した。各リスクはクラウド固有というよりも、オンプレミスでも存在するリスクがクラウドの構造的特性（スケール・速度・責任分断・動的変化）によって増幅・複雑化したものとして捉えるとわかりやすい。

データセキュリティ領域

データの所在地・主権（Data Residency / Sovereignty）
- 意図せぬリージョンへのデータ複製・分散リスク、SaaSでは制御できないリスク
- CSPのレプリケーション設定により意図せず越境移転が発生するリスク
- 国ごとのデータローカライゼーション規制（ロシア、中国P等）との抵触
- マルチリージョン構成時の法的管轄の競合
データの残存性（Data Remanence）
- クラウドストレージ削除後、実際にデータが消去されたかを確認できない
- スナップショット・バックアップの削除漏れ
- CSPが同一物理メディアを別テナントに再割り当てする際のデータ残存
- ログ・一時ファイルへ機微データ等が意図せず記録されるケース
暗号化鍵管理
- CSP管理の鍵を使う場合、CSPによるデータアクセスを完全には排除できない
- BYOK（Bring Your Own Key）とHYOK（Hold Your Own Key）の選択とトレードオフ
- 鍵のローテーション失敗による大規模な復号不能リスク
- HSM（Hardware Security Module）のクラウド実装における信頼性評価
データ分類とラベリング
- 複数クラウドサービス間でのデータ分類ポリシーの一貫性維持が困難
- 非構造化データ（S3オブジェクト等）への分類適用の難しさ
- 開発環境への本番データのコピーにおける漏洩のリスク

インフラ・プラットフォーム領域

ハイパーバイザーセキュリティ
- VMエスケープ攻撃
- サイドチャネル攻撃によるテナント間情報漏洩
- ハイパーバイザー自体の脆弱性は利用者側で対処不能
コンテナセキュリティ
- コンテナイメージの脆弱なベースイメージへの依存
- コンテナランタイムの脆弱性によるホスト侵害
- Kubernetesのデフォルト設定の甘さ（etcdのピア認証がデフォルト無効、保存データの暗号化が非デフォルト）
- コンテナ間のネットワーク分離不備によるラテラルムーブメント
- 特権コンテナの不適切な使用
サーバーレスセキュリティ
- 関数の実行環境が短命なためフォレンジックが困難
- イベントインジェクション（悪意あるイベントソースによるファンクション・トリガー）
- 依存パッケージの脆弱性管理が見えにくい
- タイムアウト設定の不備によるDoS
ストレージセキュリティ
- オブジェクトストレージの公開設定ミス（S3バケット等）
- 署名付きURL（Pre-signed URL）の有効期限管理不備
- ブロックストレージのスナップショット共有設定ミス
- バックアップストレージへのランサムウェア感染の波及
ネットワークセキュリティ
- クラウドリソースのネットワークアクセス制御設定ミスによる意図しない公開
- VPCピアリングの推移的ルーティングの設計誤解によるリスク
- パブリックIPアドレスの意図しない割り当て
- クラウドネイティブなDDoS攻撃（コスト増大を狙った攻撃）
- サービスエンドポイントの設定漏れによるインターネット経由のアクセスのリスク

IAM・アクセス管理領域

IAMポリシーの複雑性
- ポリシーの組み合わせによる意図しない権限の継承
- インラインポリシーと管理ポリシーの混在による可視化困難
- 条件付きポリシー（IP制限等）の設定ミス
- リソースベースポリシーとIDベースポリシーの競合
過剰権限
- 「とりあえず管理者権限」による最小権限原則の形骸化
- 使われていないロール・ユーザーの放置
- 長期アクセス鍵の放置（ローテーションなし）
- クロスアカウントロールの過剰な信頼関係設定
認証情報の露出
- ハードコードされたAPIキー
- EC2インスタンスメタデータエンドポイント経由の認証情報窃取
- CI/CDパイプラインへのシークレットのハードコード
- ログへの認証情報の誤出力
フェデレーション・シングルサインオン
- IdPの侵害によるクラウド環境全体への影響波及
- SAMLレスポンスの署名検証不備
- OAuthのオープンリダイレクト悪用
- JWTの署名アルゴリズム混乱攻撃

アプリケーション・DevSecOps領域

CI/CDパイプラインのセキュリティ
- パイプラインへの悪意あるコードの注入
- ビルド環境の汚染によるサプライチェーン攻撃
- アーティファクトリポジトリへの不正アクセス
- デプロイ権限の過剰付与
IaC（Infrastructure as Code）
- TerraformやCloudFormationの設定ミスが大量環境に一括展開される
- IaCテンプレートへのシークレットの埋め込み
- ドリフト（実環境とIaC定義のずれ）による設定管理の崩壊
- モジュール・プロバイダの脆弱性（サプライチェーンリスク）
APIセキュリティ
- クラウドサービス間通信のAPIキー管理不備
- APIゲートウェイの認証バイパス
- レートリミットの不備によるDoS
- GraphQLの過剰なデータ露出

可視性・運用領域

ログ・モニタリング
- CloudTrail・Audit Logのデフォルト無効による証跡の欠如
- ログの保存コストを理由にした無効化・期間短縮
- マルチクラウド環境でのログの集約困難
- 攻撃者によるCloudTrailの無効化（検知回避）
- ログの改ざん防止設定の欠如
設定管理の継続的監視
- リソースの動的な増減による設定管理対象の常時変化
- 管理されていないクラウドリソースの把握困難
- 設定変更の速度がレビューの速度を超える問題
- CSPのサービス仕様変更による既存設定の無効化
インシデントレスポンスの困難性
- 揮発性環境（コンテナ・サーバーレス）でのフォレンジック証拠の消失
- CSPへの証拠保全要請の手続き的複雑さ
- マルチリージョン・マルチクラウドでの攻撃経路の追跡困難
- メモリフォレンジックがクラウド環境では原則不可能

法的・コンプライアンス領域

責任共有モデルの誤解
- CSPと利用者の責任境界をサービスモデルごとに正確に把握していない
- 「CSPが対応してくれると思っていた」という認識齟齬
- 契約上の責任と技術的な責任の乖離
クロスボーダー規制
- GDPRのSCC（標準契約条項）要件を満たさないデータ移転
- 各国当局によるCSPへのデータ開示要求への対応義務（CLOUD法）
- 規制ごとに異なる「個人データ」の定義の適用困難
監査・証拠保全
- マルチテナント環境での監査証跡の独立性確保
- 米国をはじめとする訴訟制度における電子証拠開示（eDiscovery）でのクラウドデータの収集手続き
- CSPのSOC2レポートの評価能力の欠如（読めても解釈できない問題）

その他のリスク

マルチクラウド固有のリスク
- クラウド間のID連携の複雑性
- セキュリティポリシーの一貫した適用が困難
- 最も弱いクラウド環境が全体の侵入口になる
AIワークロードのリスク
- クラウド上のLLM基盤へのプロンプトインジェクション経由のデータ抽出
- 学習データへの不正アクセスによるモデル汚染
- 推論APIの過剰公開

以上