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

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以外にも、アイデンティティ管理・エンドポイント管理・データセキュリティなど多くの要素が含まれる。

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日
諸角　昌宏

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

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

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

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

以上

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

3件の返信

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の過剰公開

以上

SaaS 環境におけるPAM利用について

コメントをどうぞ

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

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

問題点の概要

CSAが公開した「クラウドファースト時代における特権アクセス管理」では、「特権アカウントは侵害において常に最も標的とされ最も深刻な被害をもたらす攻撃経路である」と指摘している。その理由として以下2点を上げている。

ガートナー社の調査：インシデントの50％以上が、アイデンティティ、アクセス、特権の管理不備に起因
ベライゾン社のData Breach Investigations Report（DBIR）：データセキュリティインシデントの80％が、侵害または悪用されたクレデンシャル（特権・非特権を含む）に関連している

現代のPAMの中核となる原則は最小特権であり、ユーザーは業務に必要な最小限のアクセス権のみを、必要な期間のみ保持すべきであるということで、ジャストインタイム（JIT）およびジャストイナフアクセス（JEA）モデルへの移行が求められている。また、特権アカウントや特権アクセスを慎重に管理するために監査で確認することが求められているが、それをさらに確実にしていくには自動化と継続的なモニタリングが必要であり、PAMはこれを支援することができる。

このような状況を受けて、今回のSaaSセキュリティリーグでは、PAMの利用状況の現状、問題点、考慮事項等についてディスカッションした。

ディスカッション内容

PAMの利用状況
現在は、PAMの利用を始めたという状況で、徐々に利用範囲を広げている状況である。したがって、対象範囲を絞って重要なシステムのサーバーにおける特権管理としてサーバーOS上のユーザーをまず対象として開始している。
PAMの利用方法としては、アカウント管理とログ・監視をメインにして利用している。利用方法の検討もまだ始まったばかりであり、今後の方向性について議論している状況である。SaaSへの利用についてはまだこれからである。また、監督官庁からPAMの利用を推奨されていたり、PCIDSSでPAM的なものを入れる要件があるため導入しているが、PAMの有効性についてはまだあまり感じていない。
このような状況の中ではあるが、PAMの機能としての特権の承認プロセスやログ管理機能に対する要求があり、この観点での利用が広がっていく可能性がある。
なお、JITはあまりやられていない状況である。
管理者にとって JITは現実的か？
JITは、特権を恒常的に付与しないことで攻撃に可能な時間と影響範囲を最小化できる一方、可用性、運用効率、ユーザーエクスペリエンスの問題が発生する。特に、緊急時対応時の対応が遅れる可能性があると考えられる。このような背景を受けて、JITがどのように利用できるかであるが、一般的な管理・運用としては有効と思われるが、運用上できるのかどうかの検討が必要と思われるということであった。また、システムの管理は特権アカウントを使って行うという既存の運用方法があり、JIT運用そのものが社内でも抵抗が強いことが分かった。
SaaSでの利用の観点で行くと、SaaS自体がJIT機能を持っていない状況では難しいということである。なお、IaaS/PaaSでは、JITの仕組みを使っているケースが多いので利用可能である。
NHI（サービスアカウント等）をどう扱うべきか？
NHIの利用としてSaaS間の連携は結構行われており、この部分において連携方法等を検討しているとのことである。agenticAIについては、まだ社内で使われている状況ではないので、NHI等の連携の問題はまだ明確ではない。
NHIのアイデンティティとアクセス管理は、台帳を用いた手動による管理を行っており、連携においてどのくらいの権限を与えるかについて検討が必要である。AIに関しては、付与する権限は情報収集的な読み取り権限のみとかシステムに影響を与えない権限のみを与えることで管理している。

まとめ

現状、PAMの本格導入を行っているケースは少ないものと思われる。
攻撃に可能な時間と影響範囲を最小化できる特徴を持ったJITについては、まだ検討段階が多いようである。常時特権を持つアカウントによる管理に慣れている状況もあり、文化の変更も伴う。導入に向けては、ユースケースが広がることが必要であると思われる。
AIにどこまで権限を持たせるかはすでに問題になってきている。AIの利活用とデータ保護の問題は、今後大きな問題になってくると思われる。合わせて、NHIによるアプリ連携の課題やagenticAIへの対応も今後取り組んでいかなければならない課題である。

参考資料

以上

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

コメントをどうぞ

CSAジャパン関西支部では、「海外に学ぶSMBのクラウドセキュリティ基礎（AIセキュリティ編）(1)」（https://cloudsecurityalliance.jp/newblog/2025/07/14/smb_aisec_1/）および「海外に学ぶSMBのクラウドセキュリティ基礎（AIセキュリティ編）(2)」（https://cloudsecurityalliance.jp/newblog/2025/09/16/smb_aisec_2/）で、シンガポールサイバーセキュリティ庁のサイバーエッセンシャルズおよびサイバートラストマークに基づいて開発された人工知能（AI）セキュリティ固有のガイドを紹介したが、今回は、エージェンティックAIのガバナンスについて取り上げる。

シンガポール政府が世界初のエージェンティックAIガバナンス文書を発行

2026年1月19日、シンガポール情報通信メディア開発庁（IMDA）は、「エージェンティックAI向けモデルAIガバナンスフレームワーク」（https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf）を公開している。現時点で、エージェンティックAIに特化した包括的なガバナンス文書を発行したケースとしては、本書が世界初となる。

本文書は、エージェンティックAIの導入に伴う新たなリスクに対して、組織が信頼性と安全性を確保しながら活用できるように支援することを目的としており、以下のような構成になっている。

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

エージェンティックAIの紹介
1.1 エージェンティックAIとは？
1.1.1 エージェントの中核構成要素
1.1.2 マルチエージェント構成
1.1.3 エージェント設計がその限界と能力に与える影響
1.2 エージェンティックAIのリスク
1.2.1 リスクの発生源
1.2.2 リスクの種類
エージェンティックAI向けモデルAIガバナンスフレームワーク
2.1 リスクを事前に評価し、制限する
2.1.1 エージェント導入に適したユースケースの特定
2.1.2 エージェントの限界と権限を定義することで設計段階からリスクを制限
2.2 人間の意味ある責任を確保する
2.2.1 組織内外における責任の明確な割り当て
2.2.2 意味ある人間による監督を設計に組み込む
2.3 技術的な制御とプロセスを実装する
2.3.1 設計・開発段階における技術的制御の活用
2.3.2 導入前のエージェントのテスト
2.3.3 導入時の継続的な監視とテスト
2.4 エンドユーザーの責任を可能にする
2.4.1 ユーザーの多様性とニーズの違い
2.4.2 エージェントと直接やり取りするユーザー
2.4.3 エージェントを業務プロセスに統合するユーザー
附表A：参考資料 .
附表B：フィードバックと事例の募集

エージェンティックAIを構成する6つのコアコンポーネント

本フレームワークにおいて、エージェンティックAIシステムとは、AIエージェントを用いて、特定の目的を達成するために複数のステップにわたる計画を立てて実行できるシステムを指す。一般的に、エージェントは、ユーザーが定めた目標を達成するために、ある程度自律的に計画を立て、行動を実行する能力（例：ウェブ検索やファイルの作成など）を備えていることが多い。

エージェントは言語モデルの上に構築されており、以下のような6つの中核的要素により構成される。

モデル（Model）：
- SLM（小規模言語モデル）、LLM（大規模言語モデル）、またはMLLM（マルチモーダル大規模言語モデル）で構成され、エージェントの中核となる推論・計画エンジンとして機能する。指示を処理し、ユーザーの入力を解釈し、文脈に応じた応答を生成する。
指示（Instructions）：
- エージェントの役割、能力、行動上の制約を定義する自然言語によるコマンド。たとえば、LLMに与えるシステムプロンプトなどが該当する。
3メモリ（Memory）：
- LLMがアクセス可能な情報で、短期記憶または長期記憶として保存されるデータ。過去のユーザーとのやり取りや外部知識ソースからの情報を取得できるようにするために追加されることがある。
計画と推論（Planning and Reasoning）：
- モデルは通常、推論と計画を行うように訓練されており、タスクを達成するために必要な一連のステップを出力できる。
ツール（Tools）：
- エージェントがファイルやデータベースへの書き込み、デバイスの制御、取引の実行など、他のシステムとやり取りしながら行動を実行するための手段です。モデルはタスクを完了するためにツールを呼び出す。
プロトコル（Protocols）：
- エージェントがツールや他のエージェントと通信するための標準化された方法。たとえば、Model Context Protocol（MCP）はエージェントがツールと通信するためのプロトコルであり、Agent2Agent Protocol（A2A）はエージェント同士が通信するための標準を定義している。

エージェンティック AI向けモデルAIガバナンス・フレームワーク（MGF）は、エージェント型AIに関するリスクと、それらのリスクを管理するための新たなベストプラクティスを、組織が体系的に把握できるようにするための枠組みである。リスクが適切に管理されれば、組織はより安心してエージェンティックAIを導入することができるとしている。

エージェンティックAI実装に際して考慮すべき4つの領域

このMGFは、自社でAIエージェントを開発する場合でも、外部のエージェントソリューションを利用する場合でも、エージェンティックAIの導入を検討している組織を対象としている。これまでのモデルガバナンス・フレームワークを基盤として、エージェントに関して組織が考慮すべき4つの主要な領域を以下のように整理している。

リスクを事前に評価し、制限する
・組織は、エージェントによって新たに生じるリスクを考慮し、内部の構造やプロセスを適応させる必要がある。その第一歩は、エージェントの行動によってもたらされるリスクを理解することであり、エージェントが取り得る行動の範囲、行動の可逆性、エージェントの自律性の度合いなどが関係する。
・リスクを早期に管理するために、組織は計画段階でエージェントの影響範囲を制限する設計（例：ツールや外部システムへのアクセス制限）を行うことが推奨される。また、エージェントの行動が追跡可能かつ制御可能であるように、堅牢なID管理やアクセス制御を導入することも重要である。
人間の意味ある責任を確保する
・エージェンティックAIの導入に「ゴーサイン」が出た後は、人間の責任を確保するための措置を講じる必要がある。ただし、エージェントの自律性が高まることにより、従来の静的なワークフローに基づく責任の割り当てが複雑化する可能性がある。さらに、エージェントのライフサイクルには複数のステークホルダーが関与するため、責任の所在が分散するリスクもある。
・組織内外の関係者の責任範囲を明確に定義し、技術の進化に応じて迅速に対応できるよう、適応的なガバナンス体制を整備することが重要である。特に、ヒューマン・イン・ザ・ループ（HITL：Human-in-the-Loop）の設計は、自動化バイアスへの対処を含めて再考する必要がある。たとえば、重大な判断や不可逆な行動には人間の承認を必須とするチェックポイントを設けることや、人間による監督が時間とともに有効に機能しているかを定期的に監査することが求められる。
技術的な制御とプロセスを実装する
・エージェントを安全かつ信頼性の高い形で運用するために、ライフサイクル全体にわたって技術的な対策を講じる必要がある。
・開発段階では、計画機能、ツール、成熟途上のプロトコルなど、エージェンティック AI特有の新しい構成要素に対して、技術的制御を組み込むことが重要である。これにより、新たな攻撃対象領域から生じるリスクに対応できる。
・導入前には、エージェントの基本的な安全性と信頼性（実行精度、ポリシー遵守、ツール使用の適切性など）を検証する必要がある。これには、従来とは異なる新しいテスト手法が求められる。
・導入時および導入後には、エージェントが環境と動的に相互作用するため、すべてのリスクを事前に予測することは困難である。そのため、段階的な導入と継続的なモニタリングが推奨される。
エンドユーザーの責任を可能にする
・エージェントの信頼性ある導入は、開発者だけでなく、それを使用するエンドユーザーの責任ある利用にも依存する。
・責任ある利用を促すために、最低限として、ユーザーにはエージェントの行動範囲、アクセス可能なデータ、ユーザー自身の責任について明確に伝える必要がある。
・組織は、人間とエージェントの相互作用を適切に管理し、効果的な監督を行うための知識を従業員に提供するトレーニングを実施することも検討すべきである。これは、従業員が自身の専門性や基本的なスキルを維持しながら、エージェントと協働できるようにするためである。　シンガポールサイバーセキュリティ庁のサイバーセキュリティ認証プログラムに準拠したAIセキュリティガイドラインが、AIシステム全般（モデル、データ、インフラ）を対象とし、セキュリティ・バイ・デザイン、攻撃耐性、アクセス制御の観点から、技術的セキュリティ対策（設計・運用）に焦点を当てているのに対して、本フレームワークは、エージェンティックAIを対象とし、リスク評価、責任分担、技術制御、ヒューマン・イン・ザ・ループの観点から、ガバナンス、責任、リスク管理、ユーザー教育に焦点を当てている。

AIセキュリティ認証プログラムは、エージェンティックAIを含むAIシステム全般の技術的な安全性と堅牢性を担保するための基盤を提供する一方、エージェンティック AI向けモデルAIガバナンスフレームワークは、エージェンティックAIの設計・導入・運用におけるリスク管理と責任の明確化を通じて、信頼性ある社会実装を支援する。両者は、技術とガバナンスの両輪として、シンガポールにおけるAIの安全・信頼・倫理的な活用を支える枠組みとなっている。

エージェンティックAI固有のセキュリティ課題

　シンガポールのエージェンティックAI向けモデルAIガバナンスフレームワークは、クラウドセキュリティアライアンス（CSA）の公開情報の中で、「エージェンティックAI: その進化、リスク、セキュリティ課題の理解」（2025年5月12日公開、https://cloudsecurityalliance.org/blog/2025/05/12/agentic-ai-understanding-its-evolution-risks-and-security-challenges）と、「エージェンティックAIにおけるアイデンティティ／アクセス管理：新たなアプローチ」（2025年8月18日公開、https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach）を参照している。

前者の「エージェンティックAI: その進化、リスク、セキュリティ課題の理解」では、エージェンティックAIのセキュリティ課題として、安全性（エージェントが有害な行動を取らないようにする）およびセキュリティ（悪意ある攻撃者による悪用を防ぐ）を挙げた上で、以下のような脅威例を挙げている。

・意図の破壊・目標の操作：プロンプトインジェクションなどにより、エージェントの目的を誤認させる。
・メモリポイズニング：履歴やデータストアを改ざんし、意思決定を誤らせる。
・連鎖的なハルシネーション：LLMが誤情報を生成し、それがシステム全体に波及する。

そして、エージェンティックAIのセキュリティが重要な理由として、以下のような点を挙げている。

・データやシステムの悪用リスク：アクセス権限を持つエージェントが乗っ取られると深刻な被害に遭う
・予期せぬ結果：モデルの非決定性により、意図しない行動が発生する可能性がある
・自律性のリスク：人間の関与が減ることで、過剰な自律性が暴走する恐れがある
・規制・コンプライアンス対応：将来的にはエージェンティックAIにも特有の法的要件が課される見込みである

エージェンティックAIは、自律性・適応性・複雑なタスク処理能力を備えた次世代AIとして期待される一方で、新たなセキュリティリスクやガバナンス課題をもたらす。これに対応するには、従来のサイバーセキュリティに加え、以下の通りAI特有のリスクに対応した新しいフレームワークとプロアクティブな対策が不可欠だとしている。

・新たなガバナンス基準やフレームワークが必要（例：OWASP Top 10 for LLM Apps、MITRE OCCULTなど）。
・設計段階からのセキュリティ重視、エージェントの認証・認可・監視の強化が求められる

エージェンティックAIで進化するアイデンティティ／アクセス管理

　次に、後者の「エージェンティックAIにおけるアイデンティティ／アクセス管理：新たなアプローチ」では、エージェンティックAIにおけるアイデンティティ／アクセス管理（IAM）が、従来のID管理システムとは根本的に異なるパラダイムシフトを示している点を強調している。従来のIAMプロトコルは、予測可能な人間のユーザーや静的なアプリケーションを対象に設計されていたが、エージェンティックAIシステムは自律的に動作し、動的な意思決定を行い、リアルタイムで適応可能なきめ細かなアクセス制御を必要とする。

しかしながら、OAuth 2.1やSAMLといった従来のプロトコルは、粗い粒度の静的な性質や、マシンレベルの高速な認証処理への非対応、そして自律的なAIの運用に必要な文脈認識の欠如といった理由から、エージェンティックAIには適していない。

この課題に対する解決策としては、以下の機能を統合した包括的なフレームワークが求められる。

・ゼロトラスト・アーキテクチャ
・分散型ID管理
・動的なポリシーベースのアクセス制御
・継続的な監視

これにより、安全性・説明責任・コンプライアンスを確保したAIエージェントの導入が可能になるとしている。

従来のIAMシステムは、主に人間のユーザーや静的なマシンIDを対象に、OAuth、OpenID Connect（OIDC）、SAMLなどのプロトコルを通じて設計されてきた。しかし、これらのシステムは、複数の知的エージェントが相互に連携して動作するマルチエージェントシステム（MAS）のような、動的・相互依存的・一時的な性質を持つAIエージェントのスケーラブルな運用には本質的に不十分である。

CSAは、以下の通り新たなエージェンティックAI向けアイデンティティ／アクセス管理（IAM）フレームワークの必要性を提唱している。

既存プロトコルの限界の分析：
まず、マルチエージェントシステム（MAS）に既存のプロトコルを適用した際の限界を分解し、粗い粒度の制御、単一エンティティへの最適化、文脈認識の欠如がなぜ効果的でないのかを具体例を交えて説明する。
新たなIAMフレームワークの提案：
エージェントの能力、出自、行動範囲、セキュリティ姿勢を包括的に表現できる、検証可能なリッチなエージェントアイデンティティ（ID）に基づいたフレームワークを提案する。これには、分散型識別子（DID）と検証可能な資格情報（VC）を活用する。

このフレームワークには以下の要素が含まれる。

・Agent Naming Service（ANS）：
エージェントの安全かつ能力認識に基づく発見（ディスカバリ）を可能にする命名サービス。
・動的かつきめ細かなアクセス制御メカニズム：
属性ベースアクセス制御（ABAC）、ポリシーベースアクセス制御（PBAC）、ジャストインタイム（JIT）アクセスなどを活用する。
・統合されたグローバルセッション管理とポリシー強制レイヤー：
リアルタイム制御と一貫したアクセス権の取り消しを、異種のエージェント通信プロトコル間で実現する。

さらに、ゼロ知識証明（ZKP）を活用することにより、プライバシーを保護しながら属性情報を開示し、ポリシー準拠を検証可能にする方法についても検討するとしている。

CSAは、この新しいIAMパラダイムのアーキテクチャ、運用ライフサイクル、革新的な貢献点、セキュリティ上の考慮事項を概説し、エージェンティックAIとその複雑なエコシステムに必要な信頼性・説明責任・セキュリティの基盤構築を目指すとしている。

このようにみていくと、シンガポールは、エージェンティックAIの社会実装に向けたガバナンスとセキュリティの両面で世界をリードしている。シンガポールサイバーセキュリティ庁のAIセキュリティガイドラインとシンガポール情報通信メディア開発庁のエージェンティックAI向けフレームワークは、相互補完的に機能し、信頼性あるAI活用の基盤構築に寄与している。その中で、クラウドセキュリティアライアンスのクラウドセキュリティおよびAIセキュリティ関連文書も有効活用されている。

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

ISMSを基盤としたゼロトラストの展開

コメントをどうぞ

CSAジャパン　ゼロトラストWG　諸角昌宏

ゼロトラストに取り組んでいる組織が増えている中、ゼロトラストの戦略を曖昧にしたままセキュリティ製品の導入に走っているケースが見受けられる。ゼロトラストは、今までのセキュリティの考え方、特にリスク管理の延長線上にある考え方である。すべてのアクセスを検証する、最小権限の原則、継続的な監視とログ分析など、今までのどちらかというと静的なセキュリティ対策に対して、動的なセキュリティ対策にしていくことにより、現在のITシステムの環境に適合させていこうというものである。したがって、ゼロトラストの考え方や戦略を正しく理解し、自組織に適用していくことが求められる。

本ブログのベースになっている「ISMSを基盤としたゼロトラストの展開」資料では、ゼロトラストの考え方を理解するために3つのゼロトラスト導入戦略（NIST SP800-207、CISA成熟度モデル、NSTACモデル）を説明し、ゼロトラストの考え方や戦略の理解を深めたうえで、ISMSフレームワークにゼロトラストを採用する方法について考察している。したがって、ゼロトラストの戦略についてはそちらの資料を参照していただくこととし、本ブログではISMSフレームワークにゼロトラストを採用する方法についての考察を説明する。

なぜISMSフレームワークにゼロトラストを採用する方法を考えたか？

まず、ISMSフレームワークにゼロトラストを採用する方法を考察した理由について説明する。

ゼロトラストは、セキュリティ対策としては適切なものであるが、リスク管理として重要である情報資産の重要性について言及されていない。特定非営利活動法人デジタル・フォレンジック研究会のコラム第８９６号：「ゼロトラストアプローチとリスク論的アプローチ」（https://digitalforensic.jp/2025/10/20/column896/）において佐々木良一理事（東京電機大学　名誉教授　兼同大学サイバーセキュリティ研究所　客員教授）が以下のように述べている。「ゼロトラストの考え方自体は適切なものであるが、同時にリスクアセスメントを中心とするリスク論的アプローチも併用しないと適切な対策にならない」。リスクについて、上記コラムでは「リスク＝損害の大きさ×損害の発生確率」という工学分野の確率論的リスク評価の定義を使っている。情報セキュリティにおいてリスクは、「リスク＝影響度ｘ発生確率」と表現されるが、概念的には同じであり、ここでは影響の方が損害より広い概念として捉え、「損害の大きさ＝影響度」と捉えることとする。ここで、ゼロトラストは、「損害の発生確率」と結び付けることができるが、「損害の大きさ」（対象システムの重要性）についてはカバーされていない。したがって、ゼロトラストにおいてリスク論的アプローチを併用することが重要であるということになる。そこで、「ISMSを基盤としたゼロトラストの展開」資料では、リスク管理プロセスにゼロトラストを統合させることでこれを実現することを考察した。さらに、リスク管理プロセス（ISO 31000 / ISO 27005）にゼロトラストを統合させるという概念的な話よりは、リスク管理プロセスを中核に据えているISMS（ISO/IEC27001）のプロセスにゼロトラストを統合することで、より実際に利用できる方法となると考えた。ISMSは、日本では約60%の組織が認証を取得しているように広く普及しており、このフレームワークにゼロトラストを統合させることが有効であると考えた。なお、リスク管理プロセスにゼロトラストを統合させるには、NISTのサイバーセキュリティフレームワーク（CSF）などをベースにすることも考えられるので、ISMSに限定する話ではないことは述べておく。

ISMSフレームワークにゼロトラストを統合させる方法

「ISMSを基盤としたゼロトラストの展開」資料では、以下の仮想のインターネットオーダーシステムを用いて、これに必要となるISMSのプロセスとそれに統合するゼロトラストについて説明している（本ブログの図は、すべてこの資料より引用している）。詳細については、そちらの資料を参照していただくとして、ここではそのポイントとなる以下の点について説明する。

資産特定の考え方
リスクアセスメントにおけるリスクスコアの考え方
適用宣言書の考え方
モニタリングおよびレビューの考え方

1.　資産特定の考え方
資産特定として、ゼロトラストで説明されているプロテクトサーフェスを用いた。プロテクトサーフェスは、ビジネス情報システムとして資産の集まりとして管理する方法で、理解しやすく、関連する一連のトランザクションフロー、アーキテクチャ要素、アクセスポリシーの作成が容易となる。したがって、プロテクトサーフェスごとに管理することで、従来の資産ごとに比べて管理しやすいことになる。また、ゼロトラストの段階的な導入をこのプロテクトサーフェスごとに行うことができるため、既存の資産はISMSで管理しながら、定義できたプロテクトサーフェスから順次ゼロトラスト化していくことが可能になる。もちろん、対象となる資産を従来ISMSで用いたものをそのまま扱うことも可能であるが、プロテクトサーフェスとして管理することの方がメリットがあると考えている。
以下が、オンラインオーダーシステムを想定したプロテクトサーフェスの例である。

2.　リスクアセスメントにおけるリスクスコアの考え方
リスクスコアとして、CISAのゼロトラスト成熟度モデルの成熟度を使用し、以下の観点でリスクスコアを計算する。

影響度：資産の重要性に基づいてプロテクトサーフェスの重要度を評価

発生確率：ゼロトラスト成熟度で評価

ここで、発生確率として成熟度を使用する理由であるが、CISA成熟度モデル（従来 → 初歩 → 高度 → 最適）を「セキュリティコントロールの強度」とみなし、成熟度が上がるほど発生確率が低下するとして評価に利用することができると考える。また、成熟度の向上に応じてリスクスコアがどう下がるかを定量的に評価することが可能になると考える。

以下が、オンラインオーダーシステムを想定したリスクスコアの例である。なお、発生確率は同じレベルにおいても振れ幅を考慮して数値化している。なお、ここではプロテクトサーフェス単位でリスクスコア化しているが、プロテクトサーフェスに含まれるトランザクションフロー単位、あるいは、プロテクトサーフェスに含まれるそれぞれの柱単位にリスクスコアすることも可能である。

3.　適用宣言書の考え方
ISMSでは管理策に基づいた適用宣言書が必須となる。ここは、ISO/IEC27001の管理策に対してプロテクトサーフェスとしてどのような管理になるかを記述し作成することができると考える。
以下が、オンラインオーダーシステムを想定した適用宣言書の例の一部である。

4.　モニタリングおよびレビューの考え方
ここでは、ゼロトラストの特徴であるリアルタイム性を持たせたリアルタイム/継続的なモニタリングと自動化による改善を行うことを考える。ログ、テレメトリ、ユーザー行動分析（UEBA）などを用いて、リアルタイムにアクセスを監視し、継続的評価とポリシーの調整を繰り返すことで、ゼロトラストの成熟度を高めるように進める。これにより、ISMSを動的かつ継続的に補完することができるものと考える。
以下が、オンラインオーダーシステムを想定したモニタリングおよび改善の例である。

まとめ：ISMSフレームワークにゼロトラストを統合させるメリット

ここで述べた方法によるメリットをまとめると以下の3点になる。

ゼロトラスト化においてリスク論的アプローチを併用することを実現できる。
ISMSの延長線上にゼロトラストを統合させていくことで、ゼロトラストを1から始めることによる労力、投資を抑えることができる。
リモートワークの普及、クラウドサービスの普及拡大など、ゼロトラストの導入は組織の喫緊の課題であり、ISMSフレームワークをベースとすることでスムーズな移行およびスモールスタートが可能である。既存のISMSはそのまま維持・継続しながら、プロテクトサーフェスごとにできるところからやり、ステップアップしていくという方法が取れる。

このような点から、ISMSという既存のフレームワークを利用することで、ゼロトラストへの効果的な移行が可能になると考えられる。今後は、これを実際にユースケース化していくことを考えていきたい。

以上