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

この回のねらい

第1回では、ゼロトラストの出発点である「プロテクトサーフェスの定義」を扱い、守るべき対象をDAAS（データ・アプリケーション・資産・サービス）として業務単位で束ねる考え方を見た。すると自然に、次のような疑問が湧いてくる。

「ゼロトラストは、組織の情報セキュリティ全体の中でどこを担うのか。ISMSやCSFといったリスク管理の枠組みがあれば、それで十分ではないのか。」

今回（第1.5回）では、この問いについて考える。ここでは、ゼロトラストを情報セキュリティリスクマネジメントの国際規格 ISO/IEC 27005（および ISO/IEC 27001）と突き合わせ、役割分担を明らかにすることとする。結論を先に言えば、ゼロトラストはリスク管理に取って代わるものではなく、その中で「技術的な情報資産への防御」を担う実装である。

結論：リスク管理の枠組みとゼロトラスト・アーキテクチャは役割が異なる

まず全体像を押さえる。ISMS（ISO/IEC 27001、27005）やCSFは、「何を・どこまで守るか」を決める“傘”（計画・統治）である。組織のあらゆる資産である情報・業務プロセス・ソフト・ハード・ネットワーク・要員・拠点・組織を洗い出し、リスクを評価し、対応方針（修正・保有・共有・回避）を決める。いわば防犯計画にあたる。

一方、ゼロトラストは、その計画に基づいて「情報資産へのアクセスを実際に守る」実装の一つである。防犯計画に対する「各部屋の鍵と、入るたびの本人確認」にあたる。計画書だけでは侵入者は止まらない。止めるのは実際の鍵であるゼロトラストのような具体策である。

図1：ISMS／CSFという「傘」（計画・統治）の下で、ゼロトラストが技術層を担う。物理・人・組織は別の層が担い、重ね合わせて全体を守る

重要なのは、両者は競合せず重ねて使うという点である。ISMS／CSFだけでは、計画はあっても実際に守る手段が空く。ゼロトラストだけでは、守る手段はあっても全体を見渡す計画がない。両方そろって初めて、計画に沿ってアクセスを確実に守れることになる。

前提の共有：ISO/IEC 27005 の資産分類

ISO/IEC 27005:2022 は、リスク特定の方法として資産ベース（asset-based）とイベントベース（event-based）の2つのアプローチを示している。両者は排他的なものではなく、リスクシナリオの構築において組み合わせて用いることができる。本ブログでは、ゼロトラストのプロテクトサーフェスとの関係を説明しやすい資産ベースの捉え方を軸に取り上げる。

ISO/IEC 27005 は、守るべき資産を2種類に分けて捉える。

• 主要資産（primary assets） — 組織にとって価値の源泉。「情報」と「業務プロセス・活動」の2つからなる。
• 支援資産（supporting assets） — 主要資産が依存する構成要素。ソフトウェア、ハードウェア、ネットワーク、要員、拠点、組織体制など。

ここで大切なのは、ISO/IEC 27005は、人・物理・組織まで含めた「すべての資産」を洗い出すことを前提にしている点である。何があるか分からなければリスクも評価できない、という建て付けであり、NIST CSFも最初の機能が「識別（Identify）」であるように、網羅はリスク管理の出発点になる。つまり、組織全体の「網羅」を担保するのは、この傘（ISMS）側の役割である。

補足：リスクの捉え方 — 資産ベースとイベントベース

ISO/IEC 27005:2022 は、リスクを特定する方法として、性格の異なる2つのアプローチを認めている。

表1：ISO/IEC 27005:2022 の2つのリスク特定アプローチ

2022年版では、この2つは排他ではなく組み合わせて使える。本ブログが資産ベースに軸足を置くのは、恣意的な省略ではない。ゼロトラストのプロテクトサーフェス定義（DAASの洗い出し）が、まさに資産を起点に積み上げる資産ベースと対応するからである。一方、イベントベースの「どう攻撃されるか」というシナリオ視点は、ゼロトラストのアタックサーフェスやステップ2（トランザクションフローのマッピング）の発想と親和する。つまりゼロトラストは、資産ベースを土台にしつつ、イベントベース的な視点も部分的に取り込む、と整理できる。

ゼロトラストは「技術的に扱える情報資産」を守る

では、ゼロトラストのプロテクトサーフェス（DAAS）は、この資産のうちどこを守るのか。答えを一言でいうと、技術的に扱える情報資産である。ISO/IEC 27005 の各資産を、その観点で対応づけると次のようになる。

表2：ISO/IEC 27005 の資産と、ゼロトラスト（DAAS）での扱い。太字はプロテクトサーフェスに束ねて守る技術資産

この表から、2つのことが読み取れる。1つは、情報（データ）を中核に、ソフトウェア・ハードウェア／ネットワーク・サービスという技術系の支援資産が、DAASとしてプロテクトサーフェスに束ねられること。DNSやIAMのような基盤サービスも、それ自体が独立したプロテクトサーフェス（守る対象）として扱われる。ここは、ゼロトラストが漏れなく守る範囲である。

もう1つは、生身の人・純粋な物理（建物や環境そのもの）・組織や統治といった「非技術の領域」は、DAASには束ねられないこと。技術的なコントロール（検証・分離・暗号化・監視）で守る以上、守れる対象も技術的に扱える資産に限られるからである。これらはゼロトラストの範囲の外にあり、後述のとおり別の層が担う。 なお、この線引きは「技術資産か、非技術の領域か」で捉えるのが正確であると考える。たとえばIAMやDNSは、一見すると業務を下支えする補助的な存在に見えるが、技術的な実体をもつため、サービス（S）として守る対象に含まれる。見た目の役割ではなく、技術的に対象化できるかどうかが分かれ目になる。

業務プロセスは「束ねる軸」

2つある主要資産のうち、情報はプロテクトサーフェスに束ねられるが、もう一方の業務プロセスは、束ねられる中身ではなく、束ねる“軸”として働く。たとえば決済システムでは、カード会員データ（情報）は守る対象そのものだが、「支払いを処理する」という業務プロセスは、その周辺のデータ・アプリ・資産・サービスを1つのプロテクトサーフェスとしてまとめる基準になる。整理すると、業務プロセスを軸に、関連するDAASを束ねてプロテクトサーフェスを定義する、というのがいちばんシンプルな言い方になる。

図2：業務プロセスを軸に、関連するDAASを束ねてプロテクトサーフェスを定義する

非技術の領域は誰が守るのか — ISO/IEC 27002 の管理策

「ゼロトラストの範囲の外」と述べた人・物理・組織は、放置されるわけではない。ISO/IEC 27005 が参照する管理策の体系（ISO/IEC 27002:2022）は、管理策を4つのカテゴリに分けており、非技術の領域が、技術と並ぶ独立したカテゴリとして正面から扱われている。

表3：ISO/IEC 27002:2022 の4つの管理策カテゴリと、主な担い手

つまり ISO/IEC 27005／27002／27001 は、組織・人・物理・技術の4領域すべてを、「資産の洗い出し」と「管理策」の両面からカバーする。ゼロトラストが担うのは、このうち技術的管理策、得に情報資産へのアクセス防御である。人は人的管理策（教育・審査）とアイデンティティ管理で、物理は物理的管理策（入退管理）で、組織・統治は組織的管理策とガバナンス（ISO/IEC 27001・27014）で、それぞれ受け持つ。

それでもゼロトラストをやる理由

ここまでを踏まえると、「ゼロトラストは一部しか守らない。ならばISMSやCSFだけでよいのでは」という疑問が生じるかもしれない。しかし、これは計画と実装を同じ土俵で比べてしまう誤解である。ISMS／CSFは「アクセスを技術的に守れ」と指示するが、その具体的な設計・実装は別に用意しなければならない。ゼロトラストは、その最も効果的な答えの一つである。

しかも、従来の「社内ネットは信頼する（城と堀）」というやり方には、一度侵入されると内部を自由に横移動されてしまうという致命的な弱点があった。ISMSやCSFという計画は、この弱点そのものは直してくれない。ゼロトラストは、まさにこの「内部の暗黙の信頼」を解消するために生まれた具体策であり、クラウド・リモート・コンテナといった境界が消えた現代の環境に適合する。

また、ゼロトラストは「思想」だけの存在ではない。5ステップの後半、ステップ3（アーキテクチャの構築）やステップ4（ポリシーの作成）で、マイクロセグメンテーションやポリシーといった具体的な対策まで実装する。

要するに、「焦点を絞る」というゼロトラストの原則は、守る対象を賢く定める話（技術資産は漏れなく守る）であって、守備範囲を狭めて一部を見捨てる話ではない。足りない領域は他の層が担い、多層で重ねて全体をカバーする。これが設計思想である。

最後に、この位置づけは、ゼロトラストを最も強く推進する米国政府の施策にも表れている。ゼロトラスト導入を義務づけた大統領令14028（2021年）は、その実装を、NISTが標準・ガイダンスで示す移行ステップに沿って進めるよう定めており、ゼロトラストをリスク管理の一環として位置づけている。CISAのゼロトラスト成熟度モデルも、OMB（行政管理予算局）のゼロトラスト戦略を補完する「複数のロードマップの一つ」とされ、ゼロトラストを唯一の完全解ではなく、段階的に進める枠組みの要素として扱っている。本シリーズが土台とするNSTAC報告書は、ゼロトラスト導入を連邦のリスク管理報告（FISMA）と整合させるよう明確に勧告している。つまり、ゼロトラストを強力に進める政府自身が、それを既存のリスク管理と整合させながら実装する前提に立っているのである。

補足：CISA ゼロトラスト成熟度モデルとの関係

米国CISAのゼロトラスト成熟度モデル（ZTMM）は、ゼロトラストを5つの柱（アイデンティティ、デバイス、ネットワーク、アプリケーションとワークロード、データ）と、それらを横断する機能（可視化と分析・自動化とオーケストレーション・ガバナンス）で表している。これは本ブログの整理とよく噛み合うと考えられる。なお、以下に示すDAASとの対応づけは、CISA ZTMMが定める公式な1対1の対応ではなく、概念上の整理である点に留意してほしい。

• 5つの柱は、DAAS（守る対象）にほぼ対応する。データ→データ、アプリケーションとワークロード→アプリ、デバイス→資産、ネットワーク→通信経路、アイデンティティ→サービス（IAM）と人の扱い。
• 「人＝アイデンティティ」 は、人を守る資産ではなく“検証される主体”として扱うという、本ブログの整理を柱として明示したものである。
• 横断機能のガバナンス が、ISMS／CSFという傘との接続点になる。純粋な物理や組織統制は、ここでも主対象ではない。
• ZTMMは「成熟度モデル」 であり、各柱を段階的に高めていく。プロテクトサーフェスごとに成熟度を評価し、練習から本命へ反復的に進めるという第1回の考え方と同じ筋である。

まとめ

ゼロトラストは、組織の情報セキュリティ全体の中でどこを担うのか——この回の答えは次のとおりである。

• ISMS（ISO/IEC 27001・27005）／CSFが「傘」として、全資産（組織・人・物理・技術）を網羅し、何を・どこまで守るかを決める（計画・統治）。
• ゼロトラストは、その中の「技術的な情報資産への防御」を担う実装。DAASの範囲は漏れなく守り、ステップ3・4で具体的な対策まで実装する。
• 人・物理・組織は、ゼロトラストの範囲外。ISO/IEC 27002の人的・物理的・組織的管理策や、アイデンティティ・ガバナンスが担う。
• 両者は競合せず、重ねて使う。網羅はリスク管理（ISMS, CSF）が担保し、技術的な防御はゼロトラストが引き受ける、という補完関係である。

したがって、「ゼロトラストは何のためにやるのか」への答えは、ISMS／CSFが求める“アクセスを技術的に守る”を、現代の環境で最も効果的に実現する手段だから、となる。次回（第2回）は本編に戻り、ステップ2「トランザクションフローのマッピング」を扱う。守るべき対象が定まったら、次はそのデータやトランザクションがどこをどう流れているかを可視化していく。

以上

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

はじめに

「ゼロトラスト」という言葉は、いまやセキュリティの世界で組織の資産を守るための欠かせないフレームワークとして定着している。一方で、「結局、何から手をつければいいのか分からない」「壮大すぎて自社では無理だ」と感じている方も多いのではないだろうか。

本シリーズでは、ゼロトラストを「全部を一度にやる巨大プロジェクト」ではなく、順を追って小さく始められる5つのステップとして整理し、全5回にわたって解説していく。利用するのは、米国家安全保障通信諮問委員会（NSTAC）の大統領向け報告書が示した5ステップの実装プロセスと、Cloud Security Alliance（CSA）のゼロトラスト・ワーキンググループによる解説文書「Defining the Zero Trust Protect Surface（ゼロトラスト プロテクトサーフェスの定義）」である。 第1回となる今回は、まず5ステップの全体像をつかみ、その第1ステップである「プロテクトサーフェスの定義」を掘り下げる。

ゼロトラストと5ステップモデルの背景

ゼロトラストは、2010年にForrester ResearchのアナリストだったJohn Kindervag氏が提唱した戦略である。その根底にあるのは「決して信頼せず、常に検証する（never trust, always verify）」という考え方である。ネットワークの内側か外側かにかかわらず、あらゆる接続を暗黙に信頼しないことを前提とする。従来の「城と堀」型、つまり境界の内側を信頼するアーキテクチャは、資産やユーザーがもはや「城」の中に収まっていない分散・クラウド・リモートワークの時代には通用しない、というのが出発点である。

重要なのは、ゼロトラストが特定の製品ではなく「戦略」だという点である。技術は時代とともに変わるが、戦略そのものは変わらない。「製品を1つ買えば終わり」というものではなく、組織として段階的に作り上げていくものである。 この戦略を「どう実行するか」を5つのステップに落とし込んだのが、NSTACの報告書「Zero Trust and Trusted Identity Management」で示された実装プロセスである。

5ステップの全体像

ゼロトラスト実装プロセスは、次の5ステップで構成される。

1. プロテクトサーフェスの定義 — 何を守るべきか（DAAS要素）を特定する
2. トランザクションフローのマッピング — データやトランザクションがどこをどう流れているかを把握する
3. ゼロトラストアーキテクチャの構築 — リスクと露出を最小化する構成を設計する
4. ゼロトラストポリシーの作成 — 誰が・何にアクセスできるかを定義する
5. ネットワークの監視と保守 — 運用しながら継続的に改善する

このプロセスで押さえておきたいのは、一度きりで完結するものではなく、反復的（iterative）に回していくものだということである。1つの対象に対して5ステップを一巡させ、セキュリティ・ポスチャを一段引き上げたら、次の対象へ。これを繰り返すことで、組織全体のゼロトラスト化を「少しずつ、無理なく」進めていく。

図1：ゼロトラストは「プロテクトサーフェス→トランザクションフロー→アーキテクチャ構築→ポリシー→モニタリング」を回す反復サイクル

ステップ1：プロテクトサーフェスの定義

なぜ「アタックサーフェス」ではなく「プロテクトサーフェス」なのか

従来のセキュリティは、攻撃を受けうる範囲、すなわちアタックサーフェス（攻撃対象領域）全体を守ろうとしてきた。しかしアタックサーフェスは、クラウド化やリモートワークの進展とともに際限なく拡大し、組織が正確に把握しきることは事実上不可能である。「すべてを守る」は、裏を返せば「どこも守りきれない」になりかねない。

そこでゼロトラストは発想を逆転させる。攻撃される範囲全体を追いかけるのではなく、本当に守るべきものは何かに焦点を絞る。この「本当に守るべきもの（DAAS要素）だけを対象とした領域」がプロテクトサーフェス（保護対象領域）であり、ゼロトラストポリシーによって保護される、組織の技術環境の一部分を指す。 プロテクトサーフェスの優れた点は2つある。1つは、アタックサーフェスよりも桁違いに小さいこと。もう1つは、常に把握可能（knowable）であることである。アタックサーフェスの全体像は誰にも描けなくても、「自社にとって最も重要な資産は何か」は、調べれば必ず分かる。

Protect Surface is much smaller and more knowable than the Attack Surface.（プロテクトサーフェスは、アタックサーフェスよりもはるかに小さく、はるかに把握しやすい。）
— John Kindervag

従来のセキュリティは、いわば「インターネット側にいる攻撃者」を見て、その攻撃を防ぐことに注力してきた。ゼロトラストはこの視点を反転させ、攻撃者ではなく「自分が何を守りたいのか」を起点に考える。攻撃の手口は無数にあり追いきれないが、守るべき対象は有限であり、必ず見定められる。では、何を守るべきか。その中身を整理する手がかりが、次に述べるDAASである。

守るべき対象「DAAS」

では、何をプロテクトサーフェスとして定義すればよいのか。その手がかりが、4つの頭文字をとったDAASである。

• D — Data（データ）：流出または悪用された場合に最大のリスクをもたらす機微なデータ。ペイメントカード情報（PCI）、保護された医療情報（PHI）、個人を特定できる情報（PII）、知的財産などが代表例である（政府機関であれば、機密情報や国家安全保障情報なども含まれる）。
• A — Applications（アプリケーション）：機微なデータを使用したり、重要な資産を管理したりするアプリケーション。SaaSとして提供されることも、オンプレミスやクラウド（IaaS／PaaS）で自社運用されることもある。
• A — Assets（資産）：組織のIT・OT・IoT機器。サーバーやノートPCだけでなく、医療機器、POS、センサー、プリンター、産業用ロボット、SCADA、ICS（産業制御システム）、BMS（ビル管理システム）まで幅広く含む。
• S — Services（サービス）：組織が最も依存する基盤サービス。DNS、DHCP、ディレクトリサービス、NTP、カスタマイズされたAPIなど。それ自体がプロテクトサーフェスであり、停止・悪用されれば広範囲に影響する。

DAASは、何かを厳密に分類するための枠ではなく、「データ・アプリケーション・資産・サービス」という4つの切り口で自社を見渡し、守るべきものを洗い出すための着眼点である。だから「DNSはアプリケーションかサービスか」といった分類に頭を悩ませる必要はない。大切なのは、一歩引いて全体を見渡し、業務にとって意味のあるまとまりを見つけることである。ゼロトラストは個々のサーバーだけを単独で守る発想ではなく、業務上意味のある単位（プロテクトサーフェス）を起点に保護を設計する。

具体例：架空の金融サービス組織の「決済システム」

CSAの文書は、架空の金融サービス組織を例として用いている。この組織には、ATM、決済（Payments）、SWIFTゲートウェイ、取引ポータル、メインフレーム、Active Directory、DNS／NTP、ローン、VDI、PKIなど、多数のプロテクトサーフェスが存在する。そのそれぞれに「関連度（重要度）スコア」と「現在のZTセキュリティ成熟度」が割り当てられ、次にどこへ取り組むかを判断する材料になる。

そのうちの1つ、「決済システム」というプロテクトサーフェスを取り出してみる。これは単一の要素ではなく、関連する複数のDAAS要素から構成される、1つの業務情報システムである。

1.  データ：カード会員データ（取得と支払い処理のためのデータ）。
2. アプリケーション：カード会員データを管理し、支払いを処理するWebアプリケーション。
3. 資産：そのカード会員データを保存するデータベースをホストするサーバー。
4. サービス：外部のクレジットカード決済処理サービス、およびDNS。

CSAの文書の「表1」には、このほかにもCRMシステム、文書リポジトリ（SharePoint Online）、産業制御システム（化学プラント）、スマートエネルギー計測・課金システムなど、業種をまたいだプロテクトサーフェスのサンプルが、それぞれのDAAS内訳とともに示されている。いずれも『関連するDAASを束ねた1つの業務情報システム』として定義されている点が共通している。

図2：決済システムのプロテクトサーフェスを構成するDAAS要素（「ゼロトラスト・プロテクトサーフェスの定義」表1を基に作成）

表1：プロテクトサーフェスのサンプル（「ゼロトラスト・プロテクトサーフェスの定義」表1の内容を基に作成）

こうしてプロテクトサーフェスを選んだら、その中身を具体的に書き出していく。手順は大きく2段階である。まず①として、そのプロテクトサーフェスを構成するDAAS要素（データ・アプリケーション・資産・サービス）を、責任者や業務上の重要度とあわせて洗い出す。決済システムなら、データ＝カード会員データ、アプリ＝決済Webアプリ、資産＝DBサーバー、サービス＝外部の決済処理サービスやDNS、責任者＝決済システムの担当リーダー、重要度＝最高（関連度スコア100点。止まれば売上に直結する）、といった具合である。次に②として、洗い出した各DAAS要素を、実際の技術的な実体に対応づける。ただし、その「実体」の捉え方は環境によって異なる。物理サーバーやVMなら特定のIPアドレスやホストになるが、コンテナのように動的な環境では、IPが頻繁に変わり物理サーバーとの対応も崩れるため、クラスタ・名前空間・サービス名やワークロードのアイデンティティ（ラベル、サービスアカウント等）で捉える。いずれにせよ、ネットワーク上の位置（IP）そのものではなく、その要素の“正体”に紐づけるのがゼロトラストの発想である。CSAの文書も、これらの情報を『プロテクトサーフェスを特徴づける重要なメタデータ』と位置づけている。ここまで具体化して初めて、後続のステップ（トランザクションフローの可視化やポリシー設計）で『実際に守る対象』として使えるようになる。

誰が、どこまで定義するのか

プロテクトサーフェスの定義は、技術担当者だけで決めてはならない。業務プロセスのオーナー、CISO、運用担当者など、立場の異なる人々を集めて「自社にとって重要な資産は何か」を議論する必要がある。業務オーナーだけに任せれば、Active Directoryのように『業務からは見えにくいが、極めて価値あるデータを保持するもの』を見落としかねない。逆にIT部門だけでは、業務側の重要度を捉えきれない。

そのため、ステップ1に入る前段として、「これからゼロトラストに取り組む」という組織的な合意形成が要る。いきなり業務オーナーを会議に呼んでも話は通らない。あわせて、後続ステップでは時間や新たな製品への投資が生じるため、経営層の理解と予算承認をあらかじめ得ておくことが望ましい。 進め方としては、業務プロセスやエンタープライズアーキテクチャ、アプリ一覧から降ろしていくトップダウンが理想である。それが難しければ、使用中のIPアドレスからサーバー、そしてアプリを辿るボトムアップでも網羅できる。いずれにせよ、まずは責任者・保有データ・重要度といったメタデータを書き出し、最終的にIPアドレス・サーバー・クラウドリソースへ対応づける。「定義のための定義」で終わらせず、実際に守るために使うことが肝心である。

「特定・分類・評価」する

CSAの文書では、プロテクトサーフェスの定義を、単なる棚卸しではなく、組織のDAAS・事業リスク・現在のセキュリティ成熟度を「特定し、分類し、評価する」プロセスとして位置づけている。

実務上のポイントは、DAAS要素を個別にバラバラに扱うのではなく、「業務情報システム」という意味のあるまとまりとして整理することである。たとえば架空の金融機関を例にとると、関連するデータ・アプリケーション・資産・サービスを業務システム単位でグルーピングし、それぞれの重要度を見極めていく。

ここで重要なのは、CSA文書がこの業務情報システムを1つのプロテクトサーフェスと等価とみなしている点である。すなわち、1つのプロテクトサーフェスは複数の関連するDAAS要素から構成され、それらがまとまって1つの業務システムを形づくる。そのうちの1つが、事業上・リスク上の観点で「主要な要素（primary element）」と位置づけられることが多い。なお、すべてのプロテクトサーフェスがDAASの4種別すべてを備えるとは限らず、大規模で複雑な業務情報システムは、リスクレベルの異なる技術が混在する場合に、相互に関連する複数のサブシステム（＝別個のプロテクトサーフェス）へ分割されることもある。

文書の図4では、同じ組織の中に複数のプロテクトサーフェスが定義され、互いに連携する様子が描かれている。たとえば、カード会員データを扱う決済システム（高リスクの主要な業務情報システム）、プライバシー要件のある内部向けのHRMS（人事）システム、内部・外部向けで商業的要件をもつCRM、そして全体を支えるIAM（Active Directory）やDNSといったサポートサービスが、それぞれ独立したプロテクトサーフェスとなり、相互に影響し合う。1つのプロテクトサーフェスは孤立して存在するのではなく、他とインターフェースをもつ点が重要である。 粒度の取り方も重要である。アプリケーションとそのデータのように一体として守るべき関連DAASは、まとめて1つのプロテクトサーフェスとする。逆に、大規模で複雑な業務情報システムは、リスクレベルの異なる技術が混在する場合、サブシステムに分割する。たとえばCSAの文書では、大きな「サービス監視・課金業務システム」の一部であるOTのスマートメーター測定システムを、別個のサブシステム（プロテクトサーフェス）として扱う例を挙げている。完璧な区分けを最初から求めず、反復のなかで適切な粒度に整えていけばよい。

優先順位をどうつけるか

すべてのプロテクトサーフェスを同時に守ろうとすれば、結局は最初の壮大なプロジェクトに逆戻りである。そこで欠かせないのが優先順位づけである。ただし注意したいのは、ゼロトラストには性質の異なる2つの順序があることだ。1つは、各プロテクトサーフェスが事業にとってどれだけ重要かを測る「重要度のランク付け」。もう1つは、実際にどこから手をつけるかという「着手の順番」である。この2つはしばしば一致しない。まずは重要度のランク付けから見ていく。判断軸は、リスク・重要度（クリティカリティ）・組織の現在のセキュリティ成熟度であり、ビジネスインパクト分析（BIA）があればそれを起点に、なければ資産の棚卸しを行って、価値の高い順にランク付けする。

CSAの文書では、この重要度のランク付けを「関連度（重要度）スコア」による相対評価として示している。先の金融サービス組織の例では、決済（Payments）やSWIFTゲートウェイ、ATMといった中核業務は100点、取引ポータルは95点、VDIやローンは88点、PKIは80点、というように相対的な点数が与えられている。ここで「うちは全部100点だ」となりがちだが、まさにその議論こそが必要である。すべてが最優先なら、何も優先していないのと同じだからである。

点数化の材料としては、関わるデータの分類（規制・法令の対象か、PCI／PHI／PIIや知的財産にあたるかなど）やコンプライアンス要件、そして機密性・完全性・可用性（CIAトライアド）の要件と、侵害・停止が起きた場合の潜在的な影響を考慮する。たとえば文書の浄水場の例では、フッ化物濃度を制御する資産が侵害されれば水質、すなわち完全性（インテグリティ）が損なわれうる。このようにCIAの観点から、各プロテクトサーフェスのリスクを見立てていく。

では、この重要度のランク付けどおりに、重要なものから着手すればよいのか。実はそうではない。ここで2つめの「着手の順番」が関わってくる。ゼロトラスト実装で繰り返し強調されるのは、最初から組織全体を網羅する完璧なアーキテクチャを目指さないことである。対象を1つ（あるいは数個）に絞って起点とし、1つずつ積み上げていく。「一口サイズ」に分割して反復的に進める。そして着手の順番としては、いきなり最重要の本命に挑むのではなく、まず重要度の低いもので練習して経験を積み、その後に本命へ進むのが定石である（次節で詳述）。つまり、重要度のランク付けと着手の順番は別物であり、両者を切り分けて考えることが、矛盾なく進めるコツである。

よくある落とし穴と反復ロードマップ

最大の落とし穴は、最初から全部をやろうとすることである。よほど小さな組織でない限り、すべてを一度にマッピングしようとすれば必ず頓挫する。まず思いつくものを10〜15個書き出し、そのうえで5つほどに絞って作り込むのがよい。5という数は、達成可能で「やり切った」という区切りも得やすい、ちょうどよい目安である。

最初の1〜2個は、あえて重要度の低いものを「練習台」に選ぶとよい。後続のステップで実装作業に入った際、万一障害が起きても業務影響が小さく、落ち着いて手順を習得できるからである。腕が上がったところで、本命である「企業の重要資産（クラウンジュエル）」へ進めば、セキュリティ・ポスチャを大きく前進させられる。この「学習→練習→重要資産」という進み方は、John Kindervag氏（Palo Alto）による『ゼロトラストの学習曲線（The Zero Trust Learning Curve）』として知られ、CSAの文書でも図として引用されている。

そして重要なのが、ステップ1を全対象で終えてからステップ2へ、という進め方をしないことである。選んだ5つ（あるいは1つ）について5ステップを通しで回し、それを反復する。全部を一度に進めようとすれば、いつまでもステップ5にたどり着けない。さらに、発見の過程で役割が不明なDAAS要素が出てきても、慌てて削除・廃止してはならない。一見不要に見えて、実は業務運営上の重要な役割を担っていることが少なくない。 最終的には、このプロセスを業務の「第二の習慣」として根付かせる。新しいプロジェクトが立ち上がるたびに「これはどのプロテクトサーフェスか」を問い、5ステップを回す。そして、「最初の5つを2か月で完了させ、次の5つへ」というようにロードマップを持って進める。こうすると、限られたセキュリティ予算が「ファイアウォールの定期更新」ではなく、本当に守るべき業務へと向かう。既存のファイアウォールやエンドポイントを活かしながらでも、この順序で取り組むこと自体に価値がある。

まとめと次回予告

第1回では、ゼロトラスト実装の5ステップ全体を俯瞰し、その出発点である「プロテクトサーフェスの定義」を見てきた。要点は次の4つである。

• ゼロトラストは製品ではなく戦略であり、5ステップを反復的に回して育てるものである
• 守る対象を絞ったプロテクトサーフェスは、アタックサーフェスより小さく、常に把握できる
• DAASを業務情報システム（＝プロテクトサーフェス）単位で特定・分類・評価し、リスクと成熟度に応じて優先順位をつける（決済＝100点、PKI＝80点のように相対評価する）
• 最初から全部をやろうとせず、5つ程度に絞り、低リスクのもので練習してから本命へ。対象ごとに5ステップを通しで回し、ロードマップを持って反復する

次回（第1.5回）は、ISO/IEC27005の資産管理の考え方である主要資産と支援資産と、プロテクトサーフェスの考え方を検討し、ISMSでの資産の考え方とプロテクトサーフェスの関係を明確にしてみる。

そのうえで、次々回（第2回）で、ステップ2「トランザクションフローのマッピング」を取り上げる。守るべき対象が決まったら、次はそのデータやリソースが「どこから来て、どこへ流れているのか」を可視化していく。

以上

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1　3つの定義の層

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

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

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

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

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

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

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

3.3　先行研究は？

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

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

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

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

4.2　3層構造で整理する

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

この3層構造において：

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

4.3　3層構造の根拠

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

まとめ

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

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

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

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

以上

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

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

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

CIAとは何か

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

情報システムは、この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種類に整理できる。

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

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

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

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

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

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

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

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

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

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

NIST CSFが体系化した概念

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

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

まとめ

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

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

以上

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モデルにマッピングしたレポートを作成すれば、短期間で進捗を確認することができます。

以上