カテゴリー別アーカイブ: ゼロトラスト

ゼロトラストとCIA(後編) ~ 情報セキュリティはコントロール可能にすること 

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

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

「情報セキュリティとはCIAを維持すること」という定義は40年以上にわたり使われてきた。しかしCIAを詳細に理解するほど、一つの問いが浮かび上がる。CIAを「維持すること」は情報セキュリティの目的として本当に正しいのか。本ブログでは、ブログ「ゼロトラストとCIA」の後編として、この問いをより突っ込んで考察した。結論から言うと、情報セキュリティの本来の目的は「コントロール可能にすること」にあるのではないかということに至った。

はじめに:ブログ「ゼロトラストとCIA」からの問い

ブログ「ゼロトラストとCIA」では、CIAとは何か・なぜ3つなのか・CIAは万能かという3点を考察した。その中で以下の一つの重要な事実を示した。それは、「CIAを維持すること」は必要条件であるが、そもそも情報セキュリティに「十分条件」は存在しない。脅威は常に進化し、守る対象も変化し続けるためである。では、CIAとは情報セキュリティにおいて何なのか。「定義」なのか「評価軸」なのか「目的」なのか。この問いに答えることが本ブログの目的である。結論から先に示すと以下の表のようになると考える:

概念位置づけ何を問うているか
CIA(機密性・完全性・可用性)評価軸情報の状態がどうあるべきか
CIAを維持すること手段評価軸上の状態をどう保つか
コントロール可能にすること目的情報セキュリティは何のためにあるか
NIST CSF(Identify・Protect・Detect・Respond・Recover・Govern) *ISO/IEC 27002:2022もコントロール属性として採用プロセスの体系(何をするか)組織はセキュリティのために何をすべきか

第1章 ブログ「ゼロトラストとCIA」の要点確認

ブログ「ゼロトラストとCIA」で確認した要点を本ブログの出発点として以下に整理する。

要点内容
CIAとは何か機密性(C)・完全性(I)・可用性(A)の3要素。情報はそれ自体として価値を持ち、CIAはその価値が損なわれないための条件を3つの独立した評価軸で整理したもの
なぜ3つなのか情報への被害は「漏えい・改ざん・利用不能」の3種類に整理できる。攻撃者が情報システムに対してできることは「見る・変える・使えなくする」の3つに集約されるため、この3軸で被害の分類と対策の方向性が明確になる
CIAの歴史的位置づけ1972年のAnderson Reportに起源を持ち、1986年頃「CIA」という略語が命名された。設計当初は「安全なシステムの評価軸」として提示されており、「情報セキュリティの目的」として設計されたものではない。「CIAを維持すること=情報セキュリティ」という定義は後の標準化・教育化の過程で形成された
CIAは万能か必要条件だが十分条件にはなりえない。情報セキュリティに「十分条件」は存在しない。ISO/IEC 27000:2018はAuthenticity・Accountability・Non-repudiation・Reliabilityを追加し、NIST CSFはResilience・Governanceを体系化してCIAを補完している

これらの要点を踏まえた上で、本ブログでは「CIAを維持すること」という定義そのものを問い直し、情報セキュリティの本来の目的を考察する。

第2章 「CIAを維持すること」を問い直す

2.1 「維持すること」という動詞に潜む前提

「CIAを維持すること」という定義には「維持」という動詞に複数の前提が含まれている。これらの前提が現代では成立しにくくなっているといえるのではないだろうか。

「維持」が前提とすること現代の現実
守るべき状態が明確に定義できるAI・クラウド・OTの複合環境では守るべき境界が流動的。シャドーIT・SaaSが資産範囲を継続的に変化させる
状態への到達が確認できる侵害の検知自体が困難。侵害後の滞留時間は依然として長い
責任の境界が明確であるクラウド責任共有モデル・サプライチェーンの多層化で責任が分散・曖昧化している

2.2 CIAを維持していても攻撃にさらされる

「CIAを維持している企業がなぜサイバー攻撃にさらされるのか」という問いは、「CIAを維持すること」という目的設定の根本的な問題を示しているのではないだろうか。

理由CIAが問うこと実際に起きること
CIAは結果の評価軸であり攻撃への対応設計ではない現在この情報は漏れていないか・改ざんされていないか・使えるか(現状評価)攻撃者は、どこから侵入できるか・どう横展開するか、という攻撃設計を考えている
CIA評価の時点と攻撃の時点がずれるリスクアセスメントは定期的。評価時点での評価。攻撃者は継続的・動的に動く。侵害後の滞留時間は長い。
攻撃者は「正規に見せる」手法を使う不正なアクセス・改ざん・停止を評価する認証情報の窃取はC侵害で捕捉できるが、盗んだ認証情報でなりすましてアクセスする段階ではCIAのアクセス制御をすり抜ける(Authenticity問題)

「CIAを維持していること」は必要条件であるが、そもそも情報セキュリティに十分条件は存在しない。CIAの設計範囲外の問いに対してCIAで答えようとしてきたことが、この矛盾を生んでいると言える。

2.3 CIAは「状態の評価軸」であり「目的」ではない

ここで重要な概念的区別を確認してみる。CIAが「情報の状態を評価する軸」であることと、「情報セキュリティの目的」であることは異なる。

観点CIAとして正確な記述誤った記述
概念の性格情報の属性(C・I・Aの状態)を評価する軸情報セキュリティの目的そのもの
問いの構造この情報は機密性・完全性・可用性を満たしているか?情報を守るために何をするか
侵害後の設計評価軸の設計範囲外(Resilienceが扱う)「維持」という概念に含まれるかのように扱われる

第3章 情報セキュリティは何をすることか

3.1 3つの定義の層

情報セキュリティの定義は時代とともに進化してきた。3つの層として整理できる。

定義の層内容限界
古典的定義 (CIAベース)情報の機密性・完全性・可用性を維持すること静的・状態記述的。「維持」の前提が現代では成立しにくい。侵害後の回復・Authenticity・Privacyなどを扱えない
拡張定義 (ISO 27000:2018 +NIST CSFベース)CIA+Authenticity・Accountability・Non-repudiation・Reliability:ISO/IEC 27000:2018。

Identify・Protect・Detect・Respond・Recover:NIST CSF 1.0(2014年)が体系化。ISO/IEC 27002:2022もコントロール属性として採用

Govern:NIST CSF 2.0が追加
より網羅的。NIST CSFはプロセス(何をするか)を体系化した点でISOの状態記述を補完するが、「コントロール可能にすること」という目的は明示していない
現代的定義 (本ブログの考察)情報・情報システム・それを取り巻く人・組織・社会に対して生じうるあらゆる事象を、把握し・対処し・回復し・説明できる状態を継続的に保ち続けること確定した定説ではない

3.2 情報セキュリティの本来の目的:コントロール可能にすること

CIAの歴史的形成過程・各フレームワークの方向・拡張概念の性質を考察すると、情報セキュリティの本来の目的は「CIAという状態の維持」ではなく「コントロール可能にすること」にあったのではないかと考える。つまり、情報セキュリティの目的  = 「コントロール可能にすること」 ── 何が起きても、把握し・対処し・戻れる状態を保ち続けること

この定義はCIAを否定していない。CIAはコントロール可能性を評価するために有効であり続ける。ただしCIAの維持それ自体は目的ではなく、コントロール可能性という目的を達成するための評価軸として考えるのが良いと思われる。

観点「CIAを維持すること」「コントロール可能にすること」
構造C・I・Aを満たしているかいかなる事象が起きても対処できる状態にある
時間軸現在の状態の評価過去・現在・未来にわたる継続的な能力
侵害後評価軸の設計範囲外回復・説明・再発防止を含む
一般への伝わり方技術的概念として受け取られやすい「コントロールできているか」は経営判断・日常感覚に近い
関係評価軸目的

3.2b 具体的に何をすればよいか

「コントロール可能にすること」は5つの能力として具体化できる。これらの能力を継続的に維持・向上させることが、情報セキュリティの実践であると考える。

能力意味具体的な実践例関連するCIA・拡張概念
把握する (Visibility)何が起きているかを見えるようにする。資産・通信・ユーザー行動・脅威を可視化する資産台帳の整備(何があるか知る)
ログ収集、SIEM
継続的な脆弱性スキャン、ネットワーク通信の監視
C(誰がアクセスしているか) I(何が変更されたか) Accountability(誰が何をしたか)
対処する (Control)侵害の影響を制限・封じ込める。攻撃者が自由に動ける範囲を最小化するアクセス制御、最小権限の原則
ネットワーク分割(マイクロセグメンテーション)
ゼロトラストの実装(常に検証・最小権限)
エンドポイント保護(EDR)
C(許可された人だけがアクセスできるか) Authenticity(本当に正規ユーザーか)
戻れる (Resilience)侵害後に資産と業務を回復できる設計をする。「防げなかった後」を前提に組み込むバックアップ、オフライン保管(3-2-1ルール)
RTO/RPOの設定と定期的な復旧訓練
インシデント対応手順(IRP)の整備
Assume Breachの設計思想を取り込む
A(使えない状態からの回復) Resilience(NIST CSF Recover機能)
説明できる (Accountability)何が・なぜ起きたかを後から証明できる。監査・法的対応・再発防止に不可欠監査ログの保全(改ざん不可の形で)
インシデント記録、タイムライン整備
デジタルフォレンジックの準備
Non-repudiation(電子署名・タイムスタンプ)
Accountability、Non-repudiation
適応できる (Adaptability)新たな脅威・技術・法令の変化に継続的に対応できる。「現時点で完璧」は存在しない継続的なリスクアセスメント(年1回から常時評価へ)
脅威インテリジェンスの活用
PDCAの仕組みの整備
NIST CSF Govern機能による経営層の関与
NIST CSF Govern機能 継続的改善(ISO/IEC 27001 PDCAサイクル)

これら5つの能力は独立しているのではなく相互に支え合っている。「把握する」なしに「対処する」はできない。「戻れる」設計なしに「Assume Breach」は実現しない。「説明できる」なしに再発防止はできない。5つを一体として継続的に維持・向上させることが「コントロール可能にすること」の実践である。

3.3 先行研究は?

「コントロール可能性」を情報セキュリティの目的として明示的に定義した文献について調べてみた。この方向性を示唆する先行研究が以下のように見つかった。

文献主張していること本考察との関係
Lundgren & Möller (2019) “Defining Information Security” Science and Engineering Ethics, 25(2): 419-441 Division of Philosophy, Royal Institute of Technology (KTH)CIAは定義として「広すぎかつ狭すぎる(too broad and too narrow)」と論証。またCIAを「目標(goals)」とみなす立場も「CIAの特性は必要条件ですらないため目標としても機能しない」と退けている。代替定義として「Appropriate Access(適切なアクセス)」を提案している。CIAを目的から評価軸へ変更させる先行的根拠を与えていると考える
Yin et al. (2020) “Hierarchically defining IoT security: From CIA to CACA” International Journal of Distributed Sensor NetworksCACA(Confidentiality・Availability・Controllability・Authentication)を提案。CIAにControllabilityを加えた点が本ブログの考察との接点。なおYin et al.はIntegrityをAuthenticationに置き換えているが、特に言及しない。「Controllability」を情報セキュリティの定義に明示的に組み込んだ最も直接的な先行文献である。ただしCIAの代替特性として提案しており本ブログの上位目的概念とは異なっている。
NIST CSF 2.0(2024年)Identify・Protect・Detect・Respond・RecoverはNIST CSF 1.0(2014年)が体系化した。ISO/IEC 27002:2022も同5概念をコントロール属性として採用している。GoverはNIST CSF 2.0(2024年)で追加されている。2014年版(CSF 1.0)でRecover機能を独立した柱として体系化。2024年版(CSF 2.0)でGovern機能を追加しサプライチェーンセキュリティも強調。「侵害後に回復できるか」と「ガバナンス(誰が責任を持つか)」をセキュリティの核心に置いている。コントロール可能性という目的概念に最も近接したフレームワークと言える。

第4章 コントロール可能にすることとゼロトラスト

4.1 ゼロトラストはCIAを否定するか

ゼロトラストはCIAという評価軸を否定しない。ゼロトラストはネットワーク上の境界防御モデルを置き換えるにとどまらず、アイデンティティ・デバイス・アプリケーション・データを含むすべてのアクセスに「常に検証・最小権限・侵害前提(Assume Breach)」という原則を適用する広い設計思想である。CIAはゼロトラスト下でも有効な評価軸として機能し続ける。

観点ネットワーク境界防御モデル(従来の主流実装)ゼロトラスト(新しい実装)CIAトライアド(評価軸)
信頼の前提内部ネットワークは信頼する内部・外部を問わず信頼しない内部・外部という概念を持たない
侵害への取り組み侵害を防ぐことを前提とする侵害を前提として設計する(Assume Breach)CIAは侵害前提を否定していない
アクセス制御境界で一括制御セッション単位で動的に検証アクセスのC(誰に)を問う(動的・静的を問わない)
置き換え関係ゼロトラストに置き換えられるアイデンティティ・デバイス・アプリ・データ全体に「常に検証」を適用するどちらの実装モデル下でも有効

4.2 3層構造で整理する

CIAとゼロトラストの関係が混乱する根本原因は、「目的・評価軸・実装」という異なる層に属する概念が混同されてきたことにあると考える。これは、3層に整理すると関係が明確になる。

概念問い役割
目的層コントロール可能にすることなぜ守るのか何が起きても把握・対処・回復できる状態を保ち続けること
評価軸層CIA+拡張概念 (Authenticity・Non-repudiation等)何を守るのか守るべき情報の属性を評価する
実装層ゼロトラストどう実現するのかコントロール可能性を達成するための設計原則・アーキテクチャ

この3層構造において:

  • ゼロトラストはCIAの「上位互換」でも「否定」でもない。実装層の概念であり、評価軸層のCIAとは層が異なる
  • CIAはゼロトラスト下でも評価軸として機能する。「このアクセスは機密性を守れているか」という問いはゼロトラスト環境でも有効
  • コントロール可能性はCIAもゼロトラストも包含する上位目的として機能する

4.3 3層構造の根拠

なぜこの3層で整理できるのか。以下の4つの根拠があると考える。

根拠内容
概念カテゴリの区別「何のために(目的)」「何を評価するか(評価軸)」「どう実現するか(実装)」は概念的に異なるカテゴリであり互いに還元できない。
混同が生んだ問題の実証CIAを「目的」として扱った結果「CIAが問題なし=安全」という誤った等式が生まれた。
先行研究との整合Lundgren & Möller (2019) は「CIAは目標ではなく特性」と論証。NIST CSFはResilience・Governanceを体系化しコントロール可能性に最も近接。ISO/IEC 27000:2018はCIAの並列拡張で評価軸層の網羅を試みている。
エンジニアリングとの整合実装が変わっても(ネットワーク境界防御→ゼロトラスト)、評価軸(CIA)は維持され、目的(コントロール可能性)は不変であるという安定した構造が得られる

まとめ

情報セキュリティとは何をすることか

ブログ「ゼロトラストとCIA」からの問いを辿っていくと、以下の結論に至る。

  • CIAは情報セキュリティの「評価軸」として有効な基礎概念である。しかし「目的」ではない
  • 「CIAを維持すること」という定義は、評価軸を目的として扱ってきた歴史的経緯の産物である
  • 情報セキュリティに「十分条件」は存在しない。脅威は常に進化し、守る対象も変化し続ける
  • ゼロトラストはCIAという評価軸を否定しない。ゼロトラストはネットワーク境界防御モデルを起点に、すべてのアクセスに「常に検証・最小権限・侵害前提」を適用する広い設計思想である
  • CIAの歴史・各フレームワークの収束方向・拡張概念の性質を考察すると、情報セキュリティの本来の目的は「コントロール可能にすること」にあったのではないかと考えられる

以上の観点から、本ブログでは、「情報セキュリティとは、コントロール可能にすること」と結論づける。 すなわち、何が起きても、把握し・対処し・戻れる状態を保ち続けることが情報セキュリティの目的である。CIAはその目的を達成するための評価軸であり、ゼロトラストはその目的を実現するための設計思想である。この3層の関係を正しく理解することが、現代のセキュリティを議論する出発点となると考える。

以上

ゼロトラスト関連用語を整理する ~ 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アクセスの許可・拒否を最終決定する
ポリシーアドミニストレータPAPEの決定をPEPに伝達・実行させる
ポリシー実施ポイントPEP実際にアクセス制御を執行するゲートキーパー

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

ZTとZTAの違い

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

ZTNA(Zero Trust Network Access:ゼロトラストネットワークアクセス)

定義

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

VPNとZTNAの比較

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

ZTAとZTNAの違い

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

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

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の違い

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

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

4つの用語の総合比較

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

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

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

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

以上