作成者別アーカイブ: 諸角昌宏

ゼロトラスト関連用語を整理する ~ 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以外にも、アイデンティティ管理・エンドポイント管理・データセキュリティなど多くの要素が含まれる。

	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で防げること・防げないこと

1件のフィードバック

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は本当に危ないのか

2件の返信

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」の方向性は正しく、いつ・どこから始めるかという段階的なアプローチが望ましいと考える。

以上

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

以上

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への対応も今後取り組んでいかなければならない課題である。

参考資料

以上

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

以上

クラウドファースト時代における特権アクセス管理解説

コメントをどうぞ

CSAジャパン　諸角　昌宏

特権的なアクセス権限は、ユーザーに異なる役割が割り当てられるあらゆる環境でセキュアに管理する必要がある。適切なコントロールが講じられていない場合に、組織は内部での不正利用や外部からの脅威に曝される。このような状況において、PAM（特権アクセス管理、Privileged access management）の重要性が高まっている。
本ブログでは、PAMの現在の位置づけを整理した上で、CSA本部が「クラウドファースト時代における特権アクセス管理、Managing Privileged Access In a Cloud-First World」として公開した資料に基づいて、クラウドファースト環境における特権アクセス管理のベストプラクティスについて解説する。

PAMとは？

まず、PAMの定義を明確にしたい。PAMというと、どうしても製品のイメージが強い。また、PAMの日本語訳である「特権アクセス管理」という言葉から考えられるのは、管理者が使用する特権アカウントをいかにセキュアにするか、つまり、特権を付与されているアイデンティティとアクセス管理を行う製品というイメージになる。しかしながら、WikipediaでPAMを検索すると、「Privileged access management（略称:PAM、別名:特権アクセス管理）は、組織内の特権アカウントの制御、監視、保護に焦点を当てたサイバーセキュリティ上重要なアイデンティティ管理である」としている。ここで「アイデンティティ管理」という部分については上記の特権アカウントの管理ということになるが、「組織内の特権アカウントの制御、監視、保護に焦点」を当てるという部分があり、単なる認証/認可だけではなく特権アクセスのセキュリティ統制を含んでいるといえる。そうすると、PAMを製品として捉えるのではなく、特権アクセスを付与・利用・監視・記録・不要になった場合の無効化を総合的に行うための統制モデルと考える必要がある。

また、Gartnerは、PAMが必要な機能としてJust-In-Time（JIT）や Zero Standing Privileges（ZSP）という用語を使っており、特権というのは常設されるべきでなく、必要な瞬間に付与し必要無くなったら直ちに削除するということを要件としている。

また、PAMと関連する用語としてIAM 、IGA、CIEMがあるが、これらとPAMとの違いは、IAM 、IGA、CIEMが「誰にどの権限を持たせるか」を管理するのに対して、PAMは「その権限をいつ、どのように使わせるか」を管理すると考える必要がある。以上のことから考えて、PAMは、特権アクセスに対して、最小特権、時間制限、制御および監視を適用するセキュリティ統制であると考えるのが妥当である。その上で、PAM製品はその概念を技術的に実装する手段という位置づけになる。

PAMの背景

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

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

このように、特権アカウントあるいは特権を持っていることがデータ侵害に大きく影響していることがわかる。では、特権というものが厳密に管理されていればデータ侵害は起こらないのだろうか？理論的には以下の4つの前提がすべて満たされれば外部攻撃によるデータ侵害は極めて成立しにくいと言える（ここでは、外部からのデータ侵害に絞って考える）。

アカウント侵害ができない
権限昇格が不可能である
過剰権限が存在しない
認可・設計・設定・運用が正しい

しかしながら、現実のシステムではこの前提がほぼ崩れることになる。その理由は、設計・運用が「常に」維持できるものではなく、システム・人間・環境が「時間とともに変化する」からだということができる。変化により「正しかった設計」が「不正確」になってしまう。緊急対応での一時設定、トラブル回避の例外措置、手作業の微調整などにより、設定が意図せずドリフトする。業務優先のショートカット、「今回はいいだろう」という対応、引き継ぎ漏れ・理解不足などにより人間は必ず逸脱を引き起こしてしまう。また、使われていないアカウント、放置されたAPIキー、シャドーアカウントなどにより、存在を認識していないものは管理できないという可視性の問題も起こる。このような設計・運用が「常に」維持できないという問題は、監査で確認することが求められているが、それをさらに確実にしていくには、自動化と継続的なモニタリングが必要であり、特権アカウントや特権アクセスが慎重に管理され、状況が認識されることが必要になる。これを支援するのがPAMの役割と考える。また、最小特権および時間制限という観点から、PAMは、ユーザーに業務に必要な最小限のアクセス権のみを、必要な期間のみ与えるための機能を提供することが必要になる。

効果的なPAMによるコントロール

PAMによるコントロールとして以下の点が必要となる。

最小特権（Least Privilege）
最小特権の原則をデフォルトで強制する。人/非人間の双方に、必要な権限のみを付与し、それ以上の権限は付与すべきではない。
必要な期間のみ（Just In Time、JIT）
特権は恒常的に付与せず、永続的な特権アカウントからジャストインタイム（JIT）や時間制限付きアクセスモードへ移行する。
ポリシー駆動（Policy-based Control）
特権アクセスは事前定義されたポリシーに基づいて制御する。裁量ではなく、ポリシーに基づいて制御する。
自動化（Automation）
特権の付与・剥奪・管理プロセスは自動化する。未使用または期限切れのアカウントには自動失効機能を適用する。
継続的モニタリング（Continuous Monitoring）
特権アクセスの利用状況は継続的に監視・記録する。継続的にモニタリングし、新たに作成された特権アカウント、役割の変更、または予期せぬ特権の昇格を検出する。

「特権は恒常的に付与しない」は可能か？

ここでは、「クラウドファースト時代における特権アクセス管理」には記述されていないが、PAMによるコントロールを整理する中で気になった点として「特権は恒常的に付与しない」ということが可能なのかという点について考察してみる。
特権を恒常的に付与しないことは、攻撃に可能な時間と影響範囲を最小化できるため重要である。恒常的な特権付与は、アカウント侵害時に即座に高権限を悪用されるリスクを内包するため、攻撃可能時間が無限になり、また特権取得を明確な監査イベントとして管理することができない。半面、特権を恒常的に付与せずJITとした場合、セキュリティが向上する代わりに、可用性、運用効率、ユーザーエクスペリエンスの問題が発生する。特に、緊急時の障害対応において時間がかかってしまう（JITの承認者がすぐに対応できないなど）ことになる。

PAM運用においては、特権付与の承認レベルに応じて以下のようなモデルが一般的に用いられる。

事前承認JIT
これは、特権の付与にあたって承認が必要となる。流れとしては、申請→承認→JIT付与→作業→自動失効となる。この場合、特権が必要な場合には常に事前承認が必要となるため、統制の観点では最強となる。したがって、高リスクの作業を必要とする場合に適している。ただし、緊急性が求められる場合には対応できないことが発生する可能性がある。
無承認JIT（自己承認/ポリシー自動）
これは、承認者が存在しない、別の言い方をすると自己承認JITというものである。流れとしては、本人要求→ポリシー判定→即JIT→作業→自動失効となる。この場合、承認者は存在しない。ガバナンスの観点では弱くなるが、ログが生成されるので監視・監査は可能である。したがって、これは低～中のリスクの作業に対して日常運用で用いることが考えられる。
事後承認（先に付与、後でレビュー）
これは、まず特権を付与し、使用した後でレビューする方式となる。流れとしては、JIT即時付与→作業→自動失効→後日レビュー（理由・操作内容）となる。承認なしで作業が行われるため、緊急対応や夜間対応の時に用いることが考えられる。

これらの機能をうまく運用することで、セキュリティの向上、緊急時の障害対応などを「特権を恒常的に付与しない」形で実現できる。ただし、運用方針をしっかり定めておくことが重要となる。

さて、上記の機能を使って「特権を恒常的に付与しない」運用をPAMを使って実現できるのであるが、常時特権を持ったアカウント（root等）は必要ないということにはならない。それは、非常事態として、PAMも認証基盤も壊れてしまった場合に最後に「必ず入れる道」を残す必要があるからである。いわゆる「Break-glass」である（注：Break-glassという考え方自体は「クラウドファースト時代における特権アクセス管理」に直接記載されているものではなく、実運用上一般的に用いられている設計パターンとして用いている）。認証基盤、PAM、管理プレーンなどが壊れた場合や緊急対応を必要とする重大インシデントへの対応などではどうしても「最後の管理者」が必要となる。そうすると、基本はPAMを使った「特権を恒常的に付与しない」運用を行い、緊急のためにBreak-glassで対応するという運用が必要となる。しかし、Break-glassを前提すべきではなく、あくまで基本はPAMを使った「特権を恒常的に付与しない」運用にすべきである。つまり、Break-glass は「存在させるが、通常は使わない」前提で設計する必要がある。

もう一つ、特権というか権限を常時付与することが求められることとして、部門/業務等で日常的に必要な権限の付与がある。これには、業務で必要となる権限、機械的に付与される権限などがあり、「必要な時だけ権限を付与」ということがそもそも成り立たない。しかしながら、この部門/業務等で常時付与される権限は、侵害の起点となることが多く、権限昇格やラテラルムーブメントを引き起こすことにもなりうる。これを考えると、PAMは「全体の権限を統合管理する基盤」ではなく、あくまで管理者権限、IAMの高権限ロールを対象にしていて、情報システムそのものを破壊できるような高権限を管理することを目的とし、部門/業務等で日常的に必要な権限はIAM/IGAの範囲と考えるのが妥当である。まとめると、PAMは「特権の専門管理ツール」であり、業務権限を含めた統合的アクセス管理はIAM/IGAの領域となる。

クラウドファースト環境における特権アクセス管理のベストプラクティス10選

「クラウドファースト時代における特権アクセス管理」では、クラウド環境における特権アクセス管理のベストプラクティスとして以下の10項目を挙げている。ここでは、その概要を説明する。

ジャストインタイムアクセス（JIT）およびジャストイナフアクセス（JEA）を活用し、常時付与された特権を排除する
- 永続的な管理者権限を廃止し、「必要な作業に必要な期間だけ最小権限」を動的に付与してアタックサーフェスを削減する。
- 攻撃者は「常時存在する管理者権限」を狙うことが多いため、これを排除することで侵害リスクが大きく減少する。
自動化による特権アクセスの検出とインベントリ
- シャドーアカウントを含むすべての特権アカウントを自動発見・棚卸しし、見えない特権（シャドー特権）を可視化し排除する。
- クラウドでは「誰も把握していない管理権限」が必ず増えるため、これを可視化し排除することが重要である。
きめ細かなアクセス制御と役割分担の導入
- RBAC/PBACにより職務の分離と最小特権を徹底し、単一アカウントへの過剰集中を防止する。
- 「管理者」という大雑把な権限をやめ、職務単位で分解し権限付与する。これにより、1アカウントを侵害することで全ての権限を持ってしまうという構造を壊すことができる。
権限付与、使用状況、および特権アクセス管理の行動パターンを分析する
- 特権の使われ方を継続的に分析し、異常行動・過剰権限・リスク傾向を早期検知する。
- 単にログを取るだけでなく、普段と違う操作、異常な時間帯、権限の使われ方の変化などを行動として分析する。クラウドでは、特に正規アカウントを使った侵害が起こるため、正規アカウントによる異常操作を見つける必要がある。
包括的な特権セッションのモニタリングおよび監査の有効化
- すべての特権操作を記録・可視化し、フォレンジック・説明責任・規制対応を可能にする。
- インシデント後に、誰が何をしたかを説明できるようにし、統制や復旧をスムーズに行えるようにする。
すべての重要な資産とアイデンティティにPAMを拡張する
- サーバーだけでなく、SaaS、業務アプリ、クラウド管理プレーンまでPAM対象に含める。
- PAMの対象をSaaS管理プレーン、業務アプリ、クラウド管理APIまで広げることで、SaaSや業務アプリ側の侵害を防ぐ。
非人間アイデンティティとワークロードアクセスをセキュアにする
- サービスアカウント、API、ボット、AIエージェントにもJIT・最小特権・監査を適用する。
- 人ではなく、サービスアカウントやAIエージェントにも適用することでセキュアにする。
セキュアなリモートおよびサードパーティアクセス
- ベンダーや外部委託先のアクセスも一時的・監査可能を前提として制御する。
- ベンダーや委託先に対しても、永続IDを渡さず時間限定や操作記録付きでアクセスさせるようにすることでセキュアにする。
PAMをDevOps、CI/CDのInfrastructure-as-Code（IaC）ワークフローに統合する
- PAMをDevOps、CI/CDのInfrastructure-as-Code（IaC）ワークフローに統合し、コード経由の特権漏洩や設定ミスを防止する。
- CI/CD、Terraform などの中の特権もPAM管理下に置くことで、コード内シークレットの問題を解決する。
強固なガバナンスとコンプライアンスの確立
- PAMログと統制をSOX／PCI DSS／NIST等の証跡として活用し、監査対応を自動化する。
- PAMログを、そのまま監査証跡、規制対応、経営報告に使えるようにする。これにより、PAMを経営統制のインフラとする。

まとめ

本ブログでは、PAMの定義、PAMの守備範囲について説明した。また、現代のデータ侵害の起点となる特権の扱いとして、「「特権は恒常的に付与しない」は可能か」という点について、PAMの機能を中心に考察した。さらに、クラウドファースト環境における特権アクセス管理のベストプラクティスについてその概要を説明した。

PAMは今後、必須の機能となるが、「全体の権限を統合管理する基盤」ではなく「特権の専門管理ツール」であり、業務権限を含めた統合的アクセス管理はIAM/IGAの領域となる点は理解しておく必要がある。

以上

SaaS 環境でよくあるセキュリティリスクと対策

コメントをどうぞ

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

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

2026年01月20日　18:30-20:00　開催

問題点の概要

BetterCloud社が公開した「Common SaaS security risks, horrifying recent breaches, and mitigation tips」において、SaaS 環境でよくあるセキュリティリスクと実際のインシデント事例、そしてそれらへの対策について解説している。第3回SaaSセキュリティリーグでは、ここで述べられている７つのセキュリティリスクについて、実際にSaaSのセキュリティ管理を行っている立場からディスカッションした。また、主なSaaSセキュリティリスクを軽減する方法（資料内の FAQ）の有効性についてディスカッションした。

SaaS 環境でよくあるセキュリティリスク

BetterCloud社が公開した資料で挙げられている7つのセキュリティリスクは以下である。

設定ミス（Misconfigurations）
- 誤った設定により脆弱点が露出。
- 例：認証不要のページに内部データが公開された Salesforce サイト。設定ミスが侵害につながった典型例。
オフボーディングの遅延（Delayed offboarding）
- 退職者アカウントが削除されずに残ると、データへの不正アクセスや情報窃取につながる危険性。
- 例： Cash Appでの退職者によるデータ抜き出し事件を紹介。
管理者権限の過剰付与（Excessive admin privileges）
- 権限の過剰なユーザーがいると、侵害時の被害拡大リスクが高まる
- 例：Verkada の内部カメラ映像が暴露された事件。
認証情報の漏洩（Compromised credentials）
- フィッシングや盗難によるアカウント侵害が依然として主要なリスク。
- 例：Okta 社のサポートチケット情報にアクセスされた事例。
過剰なアプリ権限（Overly permissive app data access）
- サードパーティアプリに対して不要なデータアクセスを許可してしまうと、意図せぬ情報漏洩につながる。
- 例： OneDriveで、アプリ連携（OAuth権限/スコープ）により過剰なデータアクセスが起こり得るリスクが指摘されているケース。
不十分な第三者統合（Insecure third-party integrations）
- 連携サービス側の脆弱性が本体システムへ影響を与える可能性。
- 例：Okta 侵害 → Cloudflare の Atlassian への不正アクセスに波及。
不適切なファイル共有（Improper file sharing practices）
- 誰でもアクセス可能な公開リンクなどにより、機密データが漏洩する危険性。
- 例：日本のゲーム会社 Ateam が Google Drive の公開リンクを誤設定し、長期間データ公開状態となった事件。

セキュリティリスクに対するディスカッション

上記SaaS 環境でよくあるセキュリティリスクについて、実際にどのように問題点として捉えているか、既に解決済みなのか、あるいは、どのような検討が行われているかについてディスカッションを行った。

設定ミス（Misconfigurations）
組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。
組織全体で利用するSaaSの場合は、情報システム部門が直接対応しているので対策が取れている。部門等で利用するSaaSの場合は、情報システム部門が助言はするが直接対応はしていない。部門と委託先（SaaSの調達・管理を委託）が協力して対応できているところはできているが、部門が独自にやっている場合は難しい。情報システム部門としてチェックをしているが、数が多いため難しい場合がある。したがって、基本的な運用としては、監査において定期的なチェックを行うこととしている。
オフボーディングの遅延（Delayed offboarding）
退職者アカウントについては管理できている。作業漏れの対策として、棚卸を定期的に実施している。部門で管理しているSaaSアカウントは、手動で管理するのは限界であり、人事システムとの連携が行えるようにIGA（Identity Governance and Administration）を利用することを検討している。人事システムとの連携ができるIGAは有効なツールになると考えている。その上で棚卸を実施し、定期的にチェックする。
管理者権限の過剰付与（Excessive admin privileges）
過剰権限、過剰設定を確認するチェックシートを作って管理している。チェックシートの中で最小権限等の指示を行っている。管理者権限の付与に対する対応は、どうしてもアナログにならざるを得ない。というのは、誰に対してどのような権限を付与するかについてはシステムオーナーしか分からないため、どうしても個別の対応になってしまう。したがって、情報システム部門としては、過剰権限になっていないかどうかのチェックを行うことで対応している。
SSPMが過剰な権限を指摘してくれるので、SSPMを利用して管理を行うのは有効であるが、以前から指摘されているSSPMのコストの問題がある。
管理者権限等の特権の管理としてPAM（Privileged Access Management）があり、これを利用することも考えられるが、現状はIaaSで一部利用している程度でSaaSでは利用していない。
認証情報の漏洩（Compromised credentials）
この問題も、組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。組織全体で利用するSaaSでは、情報システム部門が管理しているため、条件付きアクセスの設定を付けることでアカウント侵害を防いでいる。しかしながら、部門等で利用するSaaSでは、どこまで徹底できているかは不明な部分がある。
認証情報については、アクセス元のチェック、端末認証等を導入して対応している。これにより、モニタリングができているので、もしアカウントの漏洩が発生すれば、情報システム部門から注意するという運用ができている。
過剰なアプリ権限（Overly permissive app data access）
API連携の申請が来るケースがあり、情報システム部門でチェックしている。サードパーティアプリから不要なデータアクセスをされるケースには、APIアクセスキーのローテーションで対応している。最近課題として出てきているのは、Microsoft graphAPIに対する連携の依頼が多くなっていることである。組織全体にアクセスできる権利を要求されることがあり、他の部門のデータも見られてしまう可能性があり注意が必要である。
以前（第１回SaaSセキュリティリーグ）指摘されたが、AIが社内の見えないところを見てしまう、つまり、AIが社内の機密データを見つけて公開してしまう問題がある。自律型AIの権限をどうするのかは今後課題となる。
不十分な第三者統合（Insecure third-party integrations）
上記5で検討した内容と同様。
不適切なファイル共有（Improper file sharing practices）
ファイル共有については、ルール化をどう定義するかが難しいポイントである。Microsoft 365では、外部DLP製品に頼らず、自社クラウドの標準機能として DLP を公式に提供している。このDLP機能を使ってクラウドストレージサービスの共有問題に対応している。Google Driveについては、ダウンロードはOKにしているが、アップロードはNGとする対応を取っている。これは、CASB/SGWでコントロールしている。また、クラウドストレージに外部公開する場合には申請が必要で、申請があれば特定領域を共有できるようにするという運用でカバーしている。

主なSaaSセキュリティリスクを軽減する方法

以下の12個が、BetterCloud社が公開した資料でSaaSセキュリティリスクを軽減する方法の概要をFAQとして記述したものである。

Q1. SaaS ベンダーのセキュリティリスク評価はどのように行うべきか？
SaaS ベンダー評価では、次の点を確認する必要がある：
- SaaS プラットフォームの運用するデータセンターやインフラのセキュリティ体制データ暗号化（保存時／移動時）の仕組みアクセス制御（認証・認可）の方式実施済みのセキュリティ監査や認証（たとえばSOC 2など）
- サードパーティ連携や API のセキュリティ設計・権限付与の仕組み
  これらの評価を自動化ツールで継続的にチェックすると、ベンダー変更や構成変化にも適応しやすくなる。
Q2. 多要素認証（MFA）をどのように強制するか？
- できる限りすべてのユーザーに MFA を必須化する
- MFA未設定のユーザーにはログインを拒否するルールを設ける
- 権限レビューを定期的に実施し、認証強度を維持する
Q3. 従業員向けにはどんなセキュリティ教育をすべきか？
- 最新のフィッシング手法の理解
  → フィッシング攻撃による認証情報漏洩防止
- ファイル共有の責任ある利用法
  → 過度に公開リンクを作らない／意図しない共有範囲を避ける
Q4. SaaS 全体のセキュリティを常に把握する方法？
「可視性の欠如」がSaaSリスクの根底にある。自動化された可視化／監視ツールの導入が有効。これによって次が可能になる：
- 新規・非承認アプリの検出（シャドーIT）
- ユーザーアクセスログとファイル共有状況の自動監視
- 外部共有や不正アクセスのリアルタイムアラート
Q5. 「Super Admin（管理者権限）」の数を制限する方法？
- セキュリティポリシーとしてアプリ毎に許容する最大Super Admin数を定め、しきい値を超えたらアラートを出す仕組みを設定
- 単純な管理者数の制御だけでなく、不適切な権限拡大を未然に検知する
Q6. ユーザーのオフボーディング（退職時処理）はどう自動化するか？
- SaaS 管理プラットフォームでは、退職者やロールチェンジの際にアカウントを自動無効化・権限削除するワークフローを設定可能。
- これにより「幽霊アカウント」問題や放置されたアクセス権限のリスクを抑制できる。
Q7. 定期的なコンテンツスキャンをどのように実行するか？
ファイルやデータをスキャンして以下を特定する：
- 機密データ（PII、顧客情報、知的財産など）の所在
- 過剰な共有設定ファイル
- 不適切なアクセス権限が付与されたファイル
  これも自動化ツールが必要で、人手ベースでは難しい。
Q8. どのようなファイル共有モニタリングが必要か？
- 外部共有の過剰検出
- 許可範囲の過度な広さ（過剰権限）
- 非アクティブ共有の把握と削除
  これらのモニタリングにより、ファイル共有に起因する漏洩リスクを削減可能。
Q9. ファイル共有方針を強制する方法？
- 教育に加え、自動化された定期的なファイル権限のクリーニングやポリシー例外を検出する仕組みを運用することで、方針遵守を強制する。
Q10. SaaS セキュリティポスチャを高める最良の方法？
- 強力なSSPM機能を持つ管理プラットフォームを使い、継続的な可視化、監査、ポリシー施行、自動リメディエーションを実施する。
Q11. インシデント発生時の即時対応（IR）計画はなぜ重要か？
- 侵害疑いを検知したら、影響範囲の隔離、パスワード変更、侵害アカウントの停止、ファイル共有のブロックなどを迅速に行うIR計画が必要である。
- これはインシデントの被害拡大を防ぐうえで極めて重要である。
Q12. ルート原因分析（Root-Cause Analysis）はいつ行うべきか？
侵害の封じ込め後に実施。分析の対象は以下：
- 初期侵入経路
- 誤設定や脆弱性
- データ抽出・ラテラルムーブメントのプロセス
- 影響した他 SaaS との関連
  これらにより恒久的な改善策が設計できる。

主なSaaSセキュリティリスクを軽減する方法に関するディスカッション

上記の12個の対策に対して、ディスカッションした内容を以下に記述する。

MFAの強制について
機密情報等を扱うSaaSについては、MFAは必須である。また、SSOへの対応も有効であり、SAMLで管理を行っている。これは、部門等で利用するSaaSで機密情報を扱う場合においても強制している。
また、MFAができない場合には、グローバルIP等で制限を掛けることでSaaSへのアクセスを制限している。グローバルIPによる制限は、完全ではないが、想定外の国やネットワークからの直接アクセスが防げるということで有効である。
また、業務に合わせて端末レベルでの制御も行っている。
従業員向けのセキュリティ教育
従業員教育は必ず実施しているが、きちんと理解されているかどうかは疑問なところもある。今後の対策として、教育を超えてシステム的な対策が必要であると考える。例として、一般的な内容ではなく、自分が直面するような問題・危機感を持たせるような（シナリオ的）教育を進めることが有効である。
また、日常的な観点に基づいてコンテンツ化することも有効である。
SaaS セキュリティポスチャを高める方法
これには、SSPMが有効であるが、実際にはコストの観点から広め切れていない。セキュリティの可視化ができないとリスクが分からないので、うまくSSPMを使う方法を考えていきたいし、ベンダー側の対応も期待したい。
インシデント対応
SaaSのインシデントレスポンスでは、インシデントの検知の報告が、SaaS側ではなく利用者側からの報告ベースになることが多い。あるいは、代理店が検知して対応してくれるケースがある。これは、SaaS側からのインシデントの報告が十分でないことを意味しており、特に部門で利用するSaaSの場合この傾向が顕著である。

まとめ

今回は、SaaS 環境でよくあるセキュリティリスクと実際のインシデント事例とそれらへの対策について、BetterCloud社が公開した資料をベースにディスカッションを行った。「あるある」的な内容ではあるが、実際にディスカッションしてみて以下の点が明確になった。

あらためて、組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。情報システム部門が直接対応しきれない部門等で利用するSaaSへの対応をチェックリストや監査を通してうまく進めていくことが求められる。
特権アカウントおよび権限付与の扱いが、SaaS利用においても重要になっている。これは、人手による対応では厳しい状況となっており、IGAやPAM等を効果的に使っていくことが求められる。
API連携の問題がクローズアップされてきている。これは、自組織側の管理だけではなく、連携元の管理にも依存してくるため、どのように連携して対応していくかを検討する必要がある。
SaaSのインシデント対応が重要になる。インシデントの報告がSaaS側からきちんと行われないと、利用者側で対応することができない。しかしながら、現状は、SaaS側からの報告があまり行われていないようである。利用者とSaaS側とのより良い連携が求められている。
いつも話題となるが、SSPMのカバレッジとコストの高さが導入に向けてのハードルとなっている。ベンダー側の対応が期待される。

以上