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

ゼロトラストと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層の関係を正しく理解することが、現代のセキュリティを議論する出発点となると考える。

以上

ゼロトラストとCIA(前編)

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

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

ゼロトラストに色々と触れていくうちに、情報セキュリティの定義である「CIAを維持すること」がゼロトラストの考え方と本当に合っているのかという疑問が生じてきた。この疑問に答えるには、まずCIAという概念を正確に理解することから始める必要がある。本ブログはその出発点として、CIAとは何か、なぜ3つなのか、どこまで有効でどこから先は別の概念が必要なのかを整理してみる。その上で、本ブログの続編として、ゼロトラストとCIA、さらに、ゼロトラスト環境において情報セキュリティをどのように捉えるかを考察してみる。

CIAとは何か

CIAとは、情報セキュリティにおける3つの基本要素を示す概念である。まずこの3要素を正確に理解しておくことが重要である。

記号英語日本語一言で言うと
CConfidentiality機密性見せるべき人だけが見られる
IIntegrity完全性正確な内容が保たれている
AAvailability可用性必要なときに使える

情報システムは、この3要素が維持されることで安全かつ信頼可能とみなされる。ただし重要な前提がある。情報はそれ自体として価値を持つ。CIAはその価値が損なわれないための条件を3つの軸で整理したものであり、「CIAが整っていれば情報に価値が生まれる」のではなく、「CIAが損なわれると情報の価値が損なわれる」という関係にある。

機密性(Confidentiality)

機密性とは、許可された人だけが情報へアクセスできる状態を維持することを意味する。

代表的な対策:

  • 認証・多要素認証(MFA)
  • アクセス制御(IAM)
  • 暗号化(通信・保存データ)
  • 最小権限の原則(PoLP:Principle of Least Privilege)

機密性が失われると:

  • 情報漏えい・不正閲覧
  • 認証情報の窃取
  • 競合他社・攻撃者による悪用

機密性が問うのは「誰に見せるか」というアクセスの選択性である。ただし「正規のアクセス者が情報を目的外に使用する」という問題は機密性の範囲外である。この「目的外利用」を扱う概念は対象によって異なる。対象が個人データであればプライバシーが扱う(GDPRの「目的制限の原則」等)。対象が組織情報・営業秘密であれば守秘義務やAccountability(説明責任)が扱う。いずれの場合も、「アクセスを許可するかどうか」という機密性とは別軸の問題である。

完全性(Integrity)

完全性とは、情報やシステムが正確であり、意図せず改ざんされていない状態を維持することを意味する。

代表的な対策:

  • ハッシュ関数による改ざん検知
  • デジタル署名
  • 変更管理・バージョン管理
  • 監査ログ

完全性が失われると:

  • データ改ざん・不正送金
  • 偽ソフトウェアの配布(サプライチェーン攻撃)
  • 意思決定の誤り(改ざんされたデータに基づく判断)

「信頼できるシステム」において、完全性は重要な中核要素である。システムが動作していてもデータや処理結果が改ざんされていれば、そのシステムは信頼できない。

完全性が問うのは「情報が改ざんされていないか」という内容の正確性である。「誰が作ったか・送ったか」という発信者の同一性はAuthenticity(真正性)という別の観点が扱う。フィッシングメールやサプライチェーン攻撃は真正性の問題であり、完全性だけでは十分に捉えきれない。

可用性(Availability)

可用性とは、必要なときにシステムや情報を利用できる状態を維持することを意味する。「可用性」はavailabilityの訳語としてIBM系文脈で普及したとされる。日常会話では使われないが、IT・セキュリティ分野では標準的な用語として定着している。

代表的な対策:

  • 冗長化(サーバー・ネットワーク・電源)
  • バックアップ・災害対策(DR)
  • DDoS対策
  • 障害復旧計画(RTO・RPO の設定)

可用性が失われると:

  • サービス停止・業務停止
  • 社会インフラの停止(医療・電力・交通)
  • ランサムウェアによる業務不能

情報自体の価値は存在しても、それを活用できなければ実質的な価値を発揮できない。そのため可用性は重要である。

可用性が問うのは「今、使えるか」という現在の状態である。「侵害後にいかに回復するか」という設計はレジリエンス(Resilience)という概念が扱う。NIST CSF 2.0はこのRecover機能を独立した柱として体系化している。

なぜCIAで「安全かつ信頼可能」が説明できるのか

情報システムへの主要な被害は、最終的に次の3種類に整理できる。

被害の種類対応するCIA要素具体例
漏えい機密性(C)の侵害個人情報流出・営業秘密の盗取・認証情報窃取
改ざん完全性(I)の侵害データ改ざん・不正送金・偽ソフトウェア配布
利用不能可用性(A)の侵害DDoS攻撃・ランサムウェア・システム障害

なぜ被害は3種類に整理できるのか。それは「情報が使われるとき、必ず3つの行為が関係する」という理解モデルとして整理できる。

情報が使われるとき、誰かが(アクセスする)・何かを(読み書きする)・いつか(使う)という3つの行為が必ず発生する。この3行為それぞれに対応する被害が「漏えい・改ざん・利用不能」であり、C・I・Aはこの3行為を保護対象とする評価軸として設計された。

さらに「攻撃者が情報システムに対してできること」を整理しても、同じ3種類に行き着く。攻撃者にできることは「見る(C侵害)・変える(I侵害)・使えなくする(A侵害)」の3種類に集約される。例えば、近年の二重恐喝型ランサムウェアでは、データ窃取(C侵害)と暗号化による利用不能化(A侵害)が組み合わされる。なりすましは正規ユーザーのアクセス権を奪う(C侵害)ことで実現する。

3つの概念が互いに還元できない独立した軸であることも重要である。機密性が保たれていても完全性は失われうる(例:暗号化された通信が改ざんされた場合や、脆弱性を突いた外部攻撃者によるデータ書き換え)。完全性が保たれていても可用性は失われうる(例:正確なデータがシステム障害やDDoS攻撃で使えない場合)。この独立性により、被害の種類を明確に特定でき、対策の方向性を誤らない。多くのセキュリティ事故はこの3軸のいずれかへの侵害として分類できる。そのためCIAは膨大な脅威を整理するための共通モデルとして広く利用されている。CIAが有用である理由は、3つの概念がそれぞれ独立していることにある。機密性はアクセスの「誰に」を問い、完全性は内容の「何が」を問い、可用性はアクセスの「いつ」を問う。この独立性により、どの軸が侵害されたかを明確に特定でき、対策の優先順位をつけやすい。

CIAの問い侵害の特定対策の方向性
誰に見せるか(C)不正なアクセスがあったか認証強化・暗号化・アクセス制御
何が正確か(I)改ざんがあったかハッシュ・署名・監査ログ
いつ使えるか(A)使えない状態になったか冗長化・バックアップ・復旧計画

CIAはどのように形成されたか

CIAは単一の設計者・文書から生まれたのではなく、複数の文脈で独立に発展した概念が段階的に収束した。この経緯を知ることで、CIAが「情報セキュリティの唯一の真理」ではなく「当時の問題意識から収束した共通語彙」であることが分かる。

出来事意義
1972Anderson Report(米空軍)C・I・Aの3概念が安全なシステム設計の評価軸として登場
1975Saltzer & Schroeder論文(MIT)C・I・Aを安全なシステム設計の基本目標として公開文献に明示
1986頃Steve Lipner(米国防総省)「CIA」という略語を命名。3概念がトライアドとして固まる
1988Morrisワーム初期インターネットに大規模な可用性障害を引き起こした代表的事例
2005ISO/IEC 27001初版CIAを情報セキュリティ定義の核として国際標準に採用

C・I・Aはそれぞれ独立した問題意識から別々の研究者によって生まれ、後に収束したと考えられる。設計当初は「情報セキュリティの定義」として提示されたのではなく、「安全なシステムを設計するための評価軸」として使われていた。「情報セキュリティとはCIAを維持すること」という定義は、後の標準化・教育化の過程で形成されたものと考えられる。

CIAは必要条件だが十分条件にはなりえない

情報セキュリティに「十分条件」は存在しない。脅威は常に進化し、守る対象も変化し続けるためである。CIAは当時の問題意識に対して有効な評価軸として形成されたが、時代とともにCIAの設計範囲を超えた脅威が顕在化してきた。CIAの設計範囲を超えた概念は、出所によって2つに整理できると考える。

ISO/IEC 27000:2018が明記する拡張概念

概念意味CIAでは捉えにくい事例
Authenticity(真正性)情報の送信者・作成者が主張通りの存在であることフィッシングメール自体は送信者真正性の問題として現れる。サプライチェーン攻撃(正規ルートからの侵害)
Accountability(説明責任)誰が何をしたかを追跡・証明できること内部不正(正規の権限で行われる不正行為の追跡・証明)
Non-repudiation(否認防止)事象・行動の発生とその起源を証明できること。「送っていない」と後から否定できない状態電子契約・電子署名・金融取引における否認
Reliability(信頼性)意図した動作および結果と一致する特性。システムが設計通りに一貫して正確に動作するか計算ロジックのバグで誤結果を一貫して返すシステム・AIの一貫した誤判断

NIST CSFが体系化した概念

概念出所意味CIAでは捉えにくい事例
Resilience(レジリエンス)NIST CSF 1.0(2014年)Recover機能侵害後に資産と業務を回復させる能力。可用性の「維持」とは設計思想が異なるランサムウェア感染後の復旧・Colonial Pipeline攻撃(復旧・事業継続能力の重要性を示した代表例)
Governance(ガバナンス)NIST CSF 2.0(2024年)Govern機能として独立サイバーセキュリティリスク管理の戦略・ポリシー・役割を組織全体で統括する機能。経営層の関与を含む経営層がリスクを把握せず投資判断を誤る・セキュリティと事業戦略が連動しない
Supply Chain SecurityNIST CSF 2.0(2024年)で強調第三者(ベンダー・パートナー・ソフトウェアプロバイダー)を通じたリスクの管理・検証SolarWinds攻撃(正規のソフトウェアアップデート経由でマルウェアが混入)

これらの追加概念も、最終的にはCIAを補強・拡張するものが多い。そのためCIAは現在でも情報セキュリティの基礎概念として維持されている。

「CIAを維持している企業がなぜサイバー攻撃にさらされるのか」という問いも、この文脈で理解できる。攻撃者は認証情報を盗む(これはC侵害であり、CIAで捕捉できる)。しかし盗んだ認証情報を使って正規ユーザーになりすましてアクセスする段階では、CIAのアクセス制御をすり抜ける。これはAuthenticity(真正性:本当に正規ユーザーか)の問題であり、CIAだけでは捕捉しにくい。さらに正規のツールで横展開し、サプライチェーン経由で正規ソフトウェアに混入するといった手法も同様に、CIAの設計範囲を超えた攻撃ベクターである。CIAが評価軸として有効であっても万能ではないことを示していると言える。

まとめ

問い答え
CIAとは何か情報セキュリティにおける3つの基本要素(機密性・完全性・可用性)を示す概念
なぜ3つなのか情報が使われるとき「誰が・何を・いつ」という3つの行為が必ず発生し、それぞれへの被害が「漏えい(C)・改ざん(I)・利用不能(A)」である。3つは互いに還元できない独立した評価軸
なぜCIAで「安全かつ信頼可能」が説明できるのか膨大な脅威を3軸で整理できるため、被害の特定・対策の方向性・優先順位づけが可能になる
CIAは万能か情報セキュリティに「十分条件」は存在しない。脅威は常に進化し、守る対象も変化し続けるため、固定した条件で「完全に安全」とは言えない。CIAはどの時代にも有効な評価軸。ISO/IEC 27000:2018はAuthenticity・Accountability・Non-repudiation・Reliabilityを追加。NIST CSF 1.0はResilience(Recover機能)を体系化。NIST CSF 2.0はGovernance・Supply Chain Securityをさらに強調
現代でも有効かゼロトラスト・クラウド・AI時代においても、CIAは情報セキュリティの評価軸として有効であり続ける。ただしCIAは「目的」ではなく「評価軸」として正しく位置づけることが重要

CIAとは、「情報が漏れず・改ざんされず・必要時に利用できる状態」を評価するための基本的な軸である。この3要素を整理して理解した上で改めてゼロトラストを見ると、ゼロトラストはCIAという評価軸を否定するものではない。ゼロトラストは、CIAという評価軸ではなく、CIA実現の前提として広く用いられてきた「境界防御中心の信頼モデル」を再設計する考え方である。CIAはゼロトラスト下でも有効な評価軸として機能し続ける。ただしCIAだけでは捉えきれない問題(真正性・説明責任・レジリエンス等)が現代の脅威環境では重要性を増しており、これらを補完する概念と組み合わせて用いることが求められる。CIAを正確に理解することが、ゼロトラストを含む現代のセキュリティを正しく議論するための出発点となる。

次回のブログ(続編)では、この部分をさらに掘り下げ、情報セキュリティの目的の観点で考えてみることとする。

以上

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

以上

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上

ゼロトラストの2つの成熟度モデルを理解する

Understanding the Two Maturity Models of Zero Trust
ゼロトラストの2つの成熟度モデルを理解する

本ブログは、CSA本部のブログに公開されている「Understanding the Two Maturity Models of Zero Trust」の日本語訳となります。原文は、こちらを参照してください。本ブログは、著者の許可のもとに翻訳し公開するものです。原文と日本語版の内容に相違があった場合には、原文が優先されます。


Blog Article Published: 05/17/2023
Written by John Kindervag, Senior Vice President, Cybersecurity Strategy, ON2IT Cybersecurity.

ゼロトラストの世界における一番の間違いは、一枚岩的な思考です。一口で象全体を食べることが可能であると信じてしまっていることです。組織の最大の間違いは、すべてのゼロトラスト環境を同時に展開しようとすることです。規模が大きすぎるのです。その結果、すぐに失敗します。このような組織は、ゼロトラストについて考え、議論することにすべての時間を費やしていますが、実際に実行に移すことはできません。

2つ目の関連する間違いは、戦術的に考えすぎてしまうことです。製品や技術にのみ焦点が当たってしまっています。戦略を投げ捨てています。このような技術への過度の集中は、サイバーセキュリティの目的である「何を守る」ということを見失わせます。

このことは、進捗を測定することを難しくしています。私は、サイバーセキュリティの進歩を測る最適な方法は、成熟度であると確信しています。

Forrester Researchに在籍中、私は包括的な企業サイバーセキュリティ成熟度評価プロジェクトに携わりました。その後、私はそれをゼロトラストの最初の成熟度モデルに適応させ、報告書にまとめました: “Asses Your Network Security Architecture with Forrester’s Zero Trust Maturity Model “というレポートです。(注)私がレポートを執筆したのは2016年末ですが、出版されたのは私がForresterを退社した後の2017年です。筆者名のところに私が3番目に記載されているのはこのためです)。

“Asses Your Network Security Architecture with Forrester’s Zero Trust Maturity Model” レポートの最初のページが以下です。

図1

何年もかけて、実際の顧客との関わりの中で、このモデルを改良する機会を得ました。このモデルは、NSTACの報告書の中で体系化されています。Appendix Aをご覧になれば、より深く理解することができます。

簡略化した図が下の図です。これは、最近CSAで行ったプレゼンテーションも含め、モデルを説明する際に使用している図です。

図2

この成熟度モデルは、「ゼロトラスト」の5ステッププロセスに基づいており、プロテクトサーフェス単位でスコア付けされます。カーネギーメロン大学が開発した標準的な5段階の成熟度パラダイムを使用しています。

各プロテクトサーフェスは個別にスコア付けされます。このモデルでは、プロテクトサーフェスとDAASの両方の要素を特定することが必要です。このようにして、成熟度のスコアを管理しやすい一口サイズの塊に分割しています。プロテクトサーフェスとしてディレクトリサービスを使用した例は、NSTACの報告書のAppendix Aに記載されています。

つまり、プロテクトサーフェスが完全に最適化されていれば、最大25点というスコアで採点されることになります。ON2ITでは、このようなことはほとんどありません。

図3

次に、すべてのプロテクトサーフェスを集計して、組織の総合スコアとプロテクトサーフェスごとの平均スコアを定義することができます。この例では、平均成熟度スコアは3.8であることがわかります。また、すべてのプロテクトサーフェスにおける成熟度の分布も見ることができます。この情報をもとに、組織は成熟度の低い特定のプロテクトサーフェスを重点的に強化することができます。

図4

では、新しいCISAゼロトラスト成熟度モデルはどのようにフィットするのでしょうか。この成熟度モデルは、実は5ステップ成熟度モデルにうまく統合されています。両者は補完関係にあると考えたほうがよいでしょう。

図5

私は最近、CISAの本社に行き、CSA Zero Trustの運営委員会のメンバーであるSean ConnellyとJohn Simmsを含む、この文書を作成した数人の人物とこの話題について話し合う機会を得ました。私たちは、5ステッププロセスの各ステップで使用される適切なテクノロジーをどのように定義できるかについて議論しました。

プロテクトサーフェスごとの成熟度モデルとCISA成熟度モデルの間のほとんどのマッピングは、ステップ3:ゼロトラスト環境の構築で行われます。以下は、ON2IT AUXOマネージドサービスポータルでどのように表示されるかの例です。

図6

どのコントロールが実施され、どのコントロールがまだ必要なのかを確認することができます。ポータルサイトでは、プロテクトサーフェスをForrester ZTXフレームワークまたはCISA成熟度モデルにマッピングしたレポートを作成することができます。

ForresterのZTXフレームワークといえば、まさにPillar(柱)成熟度モデルの前身といえるでしょう。Chase Cunningham博士がフォレスター・リサーチに在籍していたときに作成したもので、「プロテクトサーフェスごとの成熟度モデル」を補完するために作られました。この歴史は失われてしまいましたが、フレームワークの意図と、それがどのように “柱” につながったかを理解することは重要です。ChaseとForresterの彼のチームは、称賛に値します。

図7

では、どちらの成熟度モデルを使うのが良いでしょうか?その答えは、両方です。なお、CISAの文書には、「CISAのZTMMは、ゼロトラストへの移行をサポートするための多くのパスの1つです」と記載されています。

多くの組織が「柱のモデル」を文字通りに受け取りすぎており、それが重大な実装の問題につながっています。例えば、ある組織は、左から右へ進めていく必要があると考え、アイデンティティの柱から始めます。組織内のすべてのアイデンティティの問題を解決してから、デバイスの柱に移らなければならないと考えています。しかし、これは不可能なことです。この組織は、ID のアップグレードが必要な数千のシステムがあることを認識します。また、多くの組織と同様に、組織全体で複数の異なるIDソリューションを使用する必要があります。そのため、たとえ 1つのシステムの ID ソリューションを最適化できたとしても(CISA モデルのレベル 4)、すべてのシス テムの成熟度レベルは 1 のままになります。これはおそらく永久に続くことでしょう。

よりシンプルで効果的なソリューションは、1つのプロテクトサーフェスを取り上げ、柱にまたがる既存のコントロールをマッピングし、成熟度のギャップを判断することです。その情報をもとに、組織はプロテクトサーフェスの成熟度を向上させるためのプロジェクトを立ち上げることができます。そして、プロテクトサーフェスの成熟度をCISAモデルにマッピングしたレポートを作成すれば、短期間で進捗を確認することができます。

以上

Log4Shellとゼロトラスト

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