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

以上