タグ別アーカイブ: ゼロトラスト

ゼロトラスト関連用語を整理する ~ 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/

以上

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

コメントをどうぞ

2026年4月3日
諸角　昌宏

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

本ブログは、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・個人情報保護法・金融規制等のコンプライアンス要件を満たすかを確認する必要がある。特に、金融・医療等の規制業種では深刻度が最上位になりうる。

以上

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

以上

Log4Shellとゼロトラスト

1件のフィードバック

本ブログは、CSA本部のブログを著者の許可を得て翻訳したものです。本ブログの内容とCSA本部のブログとに相違があった場合には、CSA本部のブログの内容が優先されます。

Log4Shellとゼロトラスト

このブログは、Appgateのこちらの記事を元にしています。
著者：Jason Garbis、Appgate

Log4Shellの脆弱性が発覚してからわずか数週間しか経っていませんが（関連する問題はまだいくつか残っています）、世界中のセキュリティチームは、診断、検証、更新、コミュニケーションのために奔走しています。一歩下がって振り返るにはまだ少し早いかもしれませんが、私はいくつかの考えをコミュニティと共有したいと思います。

Log4Shellは、悪用が容易であるだけでなく、一般的に攻撃対象がすべてのユーザーに利用可能であり、非常に陰湿な脆弱性です。多くの場合、そのユーザーは認証前の状態です。場合によっては、悪意ある者がウェブサイトのログインページから直接攻撃を仕掛けて成功させることも可能です。さらに、このエクスプロイトは、通常、信頼されたゾーンの企業ネットワーク上で動作するロギングサーバー自身によって実行されます。ロギングサーバーは、インターネット上の悪意のあるサイトにアウトバウンドのリクエストを行い、悪意のあるコードを取得し、ローカルで実行します。

この種の脆弱性に対しては、ゼロトラストセキュリティとその中心的な考え方である最小権限の原則を実施することの重要性を示しています。それは、不必要にインターネットにさらされているアプリケーションがあまりにも多いからです。ZTNA（Zero Trust Network Access）技術を使用すると、ユーザーがアクセスを許可され認証されない限り、すべてのリソースを見えなくし、攻撃対象を減らすことができます。

Log4Shellは、認証のみのセキュリティではあまりにも弱すぎることを示す好例で、悪意のあるアクターにログイン画面を見せるだけでも悪用されてしまいます。ゼロトラストの最小権限の原則は、プライベートなアプリケーションがネットワーク上に隠れていることを保証し、悪用される可能性を最小限にします。

もちろん、会社のWebサイトのように、公開しなければならないアプリケーションやWebサイトもあります。しかし、企業はセキュリティの考え方を変えることで、顧客専用のWebアプリケーションに対しては、実際の顧客にしかアクセスできないようにすることを検討すべきです。

例えば、ビジネス向けの出荷・物流サービスを提供している企業であれば、顧客のログインページをあらゆる攻撃者に公開する理由はありません。ゼロトラスト方式を採用すれば、正当なお客様だけがログインを試みることができ、攻撃者がログインサイトを悪用することを防ぐことができます。このような安全性の高いアクセス方法をお客様に要求することは、合理的であるだけでなく、お客様に対するビジネスのセールスポイントにもなり得ます。

一般に公開する必要のあるサーバーやサイトについては、組織はゼロトラストの原則である最小権限モデルを適用しなければなりません。これらのサーバーは、広い範囲の社内ネットワークにアクセスできないようにする必要があります。すべてのアクセスはデフォルトでは拒否され、定義されたポリシーに基づいて明示的に許可されたアクセスのみが許可されなければなりません。このモデルは、インターネットへのアウトバウンドアクセスにも適用する必要があります。

企業は、ネットワーク上で稼働しているリソースだけでなく、それらのリソースが何にアクセスすることを許可されているのかを明確に把握し、明確に定義されたゼロトラストポリシーによってアクセスを許可する必要があります。これは、内部のサーバー間のアクセスについても、正当かつ合理的な要件です。セキュリティチームは、必要なアクセスを許可するためのポリシーを文書化し設定する責任をITチームやアプリケーションチームに負わせなければなりません。また、セキュリティチームは、それ以外のすべてのアクセスを制限する責任も負わなければなりません。

管理者からサーバーへのアクセス（アップデートや設定変更など）には、ITサービスマネジメント（ITSM）のビジネスプロセスに基づいてアクセスを制御するゼロトラストシステムを用いて、定義されたメンテナンスウィンドウを使用すべきです。さらに進んだ組織では、サーバーをペットではなく家畜のように扱うDevOpsのアプローチを検討する必要があります。つまり、サーバーのアップグレードやメンテナンスは行わず、マスターイメージを更新して新しいサーバーをデプロイすることになります。

サーバーからインターネットへのアクセスの場合、ほとんどのサーバーは任意のインターネットサイトにアクセスする正当な必要性はなく、むしろアクセスを許可することはセキュリティ上の弱点となります。組織は、このようなアクセスをブロックするか、許可された厳格なサイトに制限する必要があります。DNSやNTPなどのコアネットワークやインフラサービスは、企業が管理する内部システムに限定する必要があります。

Log4Shellはまた、ソフトウェアサプライチェーンのセキュリティと完全性に関するもっともな疑問を提起していますが、これについては別のブログ記事で取り上げます。ソフトウェアをどの程度信頼しているかにかかわらず、「侵害を想定する」というゼロトラストの原則に基づいて運用する必要があります。オープンソース、ベンダーから提供されたソフトウェア、または独自に作成したソフトウェアが危険にさらされていると想定する場合、最低限、ソフトウェアのインバウンドとアウトバウンドを制限し、すべてのアクセスがポリシーによって明示的に制御されていることを確認し、実際の動作を記録して監視する必要があります。

今日のリモートワークの世界における複雑な脅威の状況、脆弱性が発生する頻度、ハイブリッド環境の複雑さ、デバイスの急増を考慮すると、多くの企業や政府機関は、ゼロトラストへの移行に急速に乗り出しています。ZTNAソリューションは、以下の方法で移行をスムーズに行うことができます：

例えば、SPA（Single Packet Authorization）を使用して、ポートを積極的に隠蔽し、インターネットに接続されたサーバーを権限のないユーザーから見えないようにします。
デバイスとユーザーのリスクへの対応：きめ細かなZTNAポリシーは、限られたリスクに基づいてユーザーとデバイスに適切な権限を調整し付与することができます。
サーバーやユーザーデバイスとの間のトラフィックを制御します。多くのZTNAソリューションは、「アップルール」（例えば、ユーザーのモバイルデバイスがデータベースにアクセスする必要がある場合など）として知られる、リソースのやり取りに対するユーザー／デバイスのポリシーを必要とするユースケースでうまく機能します。しかし、「ダウンルール」、つまりサーバー、サービス、リソースから「下方向」のユーザーデバイスとのやりとりを扱うこともサポートされるべきです（例：リモートデスクトップのサポートやエンドポイントプロテクションの集中管理プラットフォーム）。この両方をサポートするZTNAプラットフォームを見てください。
幅広いITおよびセキュリティエコシステムの統合をサポートします。ZTNAは、脅威インテリジェンスツール、SIEM（Security Incident and Event Management）ソリューション、EDR（Endpoint Detection and Response）プラットフォーム、ITSMソリューションなどと統合する必要があります。
エンタープライズスケールとスピードでの運用。多くの組織は単一のユースケースからスタートしますが、最終的には、ZTNAソリューションは、組織全体のアクセスコントロールの全負荷に対応できなければならず、また、ネットワークやクラウドエコシステム全体のすべてのアプリケーションを含む、拡大するフットプリント内の負荷レベルの増加にも対応できなければなりません。

この数週間は、情報セキュリティに携わる多くの人々にとって困難な時期でした。あなたが実務者であれば、その献身的な努力に感謝します。もしあなたが組織のビジネスサイドにいるのであれば、企業を守るために夜も週末も働いているセキュリティチームやネットワークチームに、どうか辛抱強く対応していただきたいと思います。

Log4Shellは、これまでに見たことのない最悪の脆弱性であり、セキュリティに対するゼロトラストアプローチの必要性とその価値を明確に示しています。この事件をきっかけにして、ゼロトラストへの移行を始めたり、加速させたりしてください。無駄にする時間はありません。ゼロトラストの原則とアプローチは、明らかに優れたセキュリティを提供することが証明されており、あなたには組織をより良い場所へと導く責任があります。今こそ、始める時です。

本当のSDPよ立ち上がれ！ ~ Will the real SDP please stand up?

コメントをどうぞ

本ブログは、Optiv Security Inc.が公開している “Will the real SDP please stand up?” の日本語版になります。本ブログは、著者およびOptiv Security Inc.の許可を得て翻訳し、公開するものです。本ブログの内容と原文の間で相違があった場合には、原文が優先されます。

本当のSDPよ立ち上がれ！

原文：　2019年7月10日
日本語版：　2019年7月23日

Software Defined Perimeter（SDP）という用語は、ゼロトラスト（Zero Trust）モデルで安全なアクセスを提供するための新たなアジャイルな方法として最近普及してきています。SDPは、クラウドセキュリティアライアンス（CSA）によって定義された要件で、VPN /ファイアウォール/ NACの組み合わせよりも効果的で安全な方法でリモートアクセス機能を提供します。

ただし、SDPはアーキテクチャ的に異なる点があるため、多少新たな考え方が必要です。SDPは、データプレーンとコントロールプレーンを分離するネットワークの概念に基づいて作られています。これは、認証コンポーネントを拡張したポリシー決定ポイント（PDP）とポリシー実行ポイント（PEP）モデルになります。SDPの認証プロセスにおいては、「コントローラ（Controller）」はアクセスを認証するためのポリシー決定ポイントであり、「ゲートウエイ（Gateway）」はサービスへのアクセスに許可または拒否を与えるポイントになります。ゲートウェイから分離されたPDPトラフィックを使用することで、ハイブリッドクラウド環境全体でユーザーが同時にアクセスを許可される集中型のポリシーモデルと認証をサポートしているため、この機能は他のアプローチとの大きな違いになります。接続が確立され、ゲートウェイがユーザーに対して識別されると、ゲートウェイは、コントローラからの変更を定期的に確認しながら、デバイスの状態(device posture)や定義された条件に基づいてリアルタイムで決定を行うというハイブリッドな役割を果たします。これにより、コントローラが停止した場合の可用性が向上するだけでなく、障害ゾーンの分離とコントーラ/ゲートウェイのスケールアウトによりパフォーマンスも向上します。

SDPモデルは包括的で、アーキテクチャ的に異なる点があるため、従来のアクセスメカニズムやトンネリングには依存しません。つまり、SDPに加えてVPNやファイアウォールを必要とするものがあるとすれば、パフォーマンス、セキュリティ、アジリティに制限をかけるようなものであり、今日のリモートアクセスやハイブリッドクラウドにおけるワークロードの要求を満たさない可能性があります。

通信前の認証

SDPのもう1つのユニークな要素はSingle Packet Authorization（SPA）です。これは、すべてのネットワークセッションの最初のパケットで暗号化認証を要求し、許可されたクライアントだけがネットワークにアクセスできるようにします。

もともと2007年に作成されたSPAは、最初のネットワークパケットを暗号検証することで、DDoSに対する認証メカニズムを提供します。また、許可されたデバイスのみにサービスが公開されるため、エクスプロイトに対する保護も提供します。SPAで開始されていないTCPストリームはSDPによってドロップされ、コントローラまたはゲートウェイによって処理されることはないため、DDoSの影響を軽減します。SPAは、なりすまし防止や不正なデバイスによる保護されたリソースへのアクセスの防止など、DDoS防止以外の追加のセキュリティ対策を提供します。これにより、ユーザー名とパスワードが危険にさらされた場合に、資格情報を再利用する攻撃から保護されます。

SDPはどのくらい強力ですか？

2014年2月、CSAはSoftware Defined Perimeter ハッカソンのスポンサーとして、Black HatとDEFCONにSDPセキュリティを破ろうと挑戦する人のため環境を提供しました。世界全体で100億パケットを突破しましたが、攻撃は成功せず、賞品は求められませんでした。これは、SDPアプローチの長所をよく示しています。

私たちは、CSAのSDPワーキンググループに深く参加し、SDPソリューションをまとめることを経験しているSDP分野のリーダーです。ForresterとGartnerの業界調査の専門家が、今後数年間で安全なアクセス環境を大きく変えるであろうと予測しているゼロトラスト・ジャーニーにご参加ください。

原文 “Will the real SDP please stand up?” は、こちらを参照してください。