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

ゼロトラスト実装の5ステップ（NSTACモデル）入門　～　第4回：ステップ4 ゼロトラストポリシーの作成

コメントをどうぞ

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

この回のねらい

第1回で守る対象（プロテクトサーフェス＝DAAS）を定義し、第2回でその周りのトランザクションフローを可視化し、第3回でPEP（ポリシー実施ポイント）を配置したアーキテクチャを設計した。配置したPEPは、まだ「何を通し、何を止めるか」というルールを持っていない。そのルールであるゼロトラストポリシーを作るのが、本編のステップ4である。

図1：ゼロトラスト導入の5ステップと、本稿が扱うステップ4（CSA文書の5段階プロセスを基に作成）

ステップ4のねらいは、ゼロトラストをアプリケーション層（L7）のポリシー文として具体化することである。第3回のPEPに、このプロテクトサーフェスへ「誰が・何に・どんな条件でアクセスできるか」を、細かい粒度で書き下ろしていく。

ゼロトラストポリシーとは

ゼロトラストポリシーは、セキュアなアーキテクチャの要石（cornerstone）である。ポイントは3つある。1つめは、プロテクトサーフェスにできるだけ近い場所（PEP）で適用すること。2つめは、最小特権・デフォルト拒否で、必要なアクセスだけを明示的に許可し、それ以外はすべて拒否する。3つめは、ポリシーは最初は静的でも、ZTAの成熟に合わせて動的に進化させることである。

また、ゼロトラストポリシーはアプリケーション層（OSI L7）で書く。IPアドレスやポート（L3/L4）だけでなく、「どのアプリの・どの操作を・どのアイデンティティに許すか」というアプリケーションの文脈で表現する点が、従来のファイアウォールルールとの違いである。

もう一つ大切なのが、ポリシーはまずビジネスの視点から出発し、それを技術的なルールに翻訳するという二段構えである点である。たとえば「営業担当は、勤務時間内なら自宅からでもCRMにアクセスしてよい」というのはビジネス上の方針（業務要件）である。これを、ファイアウォールやIdPが実際に強制できる形、つまりユーザーグループ、時間帯、場所の条件に落とし込む。翻訳のしやすさは使うツールに依存する。新しめのファイアウォールならユーザーグループのまま書けるが、古いものではIPアドレスに変換する必要があり、手間が増える。ビジネス要件の定義は業務オーナーが担い、技術ポリシーへの実装は、プロテクトサーフェスがきちんと定義されていれば、セキュリティ担当やSOCが引き受けられる。

プロテクトサーフェス、トランザクションフロー、ポリシーの関係

ポリシーを書く前に、これまでのステップとの関係を押さえておく。この3つは、次のような連鎖でつながっている。

図2：プロテクトサーフェス、トランザクションフロー、 ポリシー

  • プロテクトサーフェス＝ポリシーの「主語」：ポリシーは「このプロテクトサーフェスへ、誰が・何にアクセスできるか」を定める。守る対象（ステップ1）が決まって初めて、ポリシーの主語が決まる。
  • トランザクションフロー＝ポリシーの「材料・下書き」：ステップ2で可視化した「実際にどんなアクセスが・どの経路で流れているか」が、そのままポリシーの下書きになる。フローにある流れは許可の候補、フローにない流れは原則拒否する。
  • ポリシー＝許すものを明示：フローのうち、業務上正当なものだけをキプリングメソッドで許可として書き下ろし、それ以外はデフォルト拒否とする。

一言でいえば、守る対象（プロテクトサーフェス）への、実際の使われ方（トランザクションフロー）を、ポリシーとして書き下ろす、という関係である。だから、ステップ2のフローのマッピングが甘いと、ステップ4のポリシーも甘くなる。必要なアクセスを漏らして業務を止めるか、余計なアクセスを許してしまう。フローの精度が、そのままポリシーの精度になる。

ここで、ポリシーをめぐる3つの役割を、時間軸で分けて押さえておきたい。ここは混同しやすいところである。

  • 定義する（事前・人間）：業務オーナーとセキュリティ担当が、キプリングメソッドでポリシーを作る（ステップ4）。作ったポリシーはPDPに登録しておく。
  • 判断する（実行時・PDP）：アクセス要求のたびに、PDPが、その登録済みポリシーに、データソースから得た“今の状況”（本人性・端末状態・リスク等）を照らして、許可／拒否を判断する。
  • 強制する（実行時・PEP）：経路上に配置したPEP（ステップ3）が、PDPの判断結果を実行する。

つまり、第3回で「PDPは様々なデータソースから情報を得る」と述べたのは、PDPがポリシーを作っているのではなく、人間が作った登録済みポリシーを評価するために、その場の状況を集めている、という意味である。ポリシーを作るのは人間（ステップ4）、それを状況に照らして判断するのがPDP、判断を強制するのがPEP。この切り分けを押さえると、「PEPがPDPの判断に従って実行する」と「PDPは様々なソースから情報を得る」が、どちらも実行時の同じ動きを指していることが分かる。

キプリングメソッド — 5W1Hでポリシーを書く

では、ポリシー文はどう書くのか。ここで用いるのがキプリングメソッドである。作家ラドヤード・キプリングの「6人の召使い（Who・What・When・Where・Why・How）」になぞらえた方法で、この6つの問いに答えることで、プロテクトサーフェスへのアクセスを許すべきエンティティを、細かい粒度で定義できる。

図3：キプリングメソッド（5W1H）でゼロトラストポリシー文を組み立てる（CSAのゼロトラスト関連ガイダンスを基に作成）

問い何を決めるか属性の例
Who（誰が）どのエンティティにアクセスを許すか（人・非人間の両方）役割、ユーザー、サービスアカウント、ボット
What（何に）何にアクセスするか／どんな文脈（コンテキスト）でアクセスするか対象リソース、操作、機微度
When（いつ）アクセスを許可する時間帯・条件営業時間、期間、頻度
Where（どこから）許可する場所・ネットワーク・地理的範囲社内／VPN、国・拠点、既知の端末
Why（なぜ）そのエンティティがアクセスする正当な理由（業務上の根拠）業務プロセス、職務上の必要性
How（どうやって）5W を満たすための技術的統制MFA、mTLS、暗号化、最小特権

表1：キプリングメソッドの6つの問い

重要なのは、Whoに人だけでなく非人間（サービス・アプリ・ボット）も含めることである。ゼロトラストでは、ワークロード同士の通信も検証の対象になるため、「決済アプリが会員データにアクセスする」といった非人間のアクセスも、同じ6つの問いで定義する。CSA文書では、これに「どれだけの時間（for how long）」を加えて、アクセスの有効期間まで定めることを勧めている。

具体例：クレジットカードのポリシー文

ここで、ポリシーとPEPの関係を正しく押さえておく。ポリシーは「PEPに対して」ではなく、「プロテクトサーフェスへの各アクセスに対して」作る。そのうえで、判断はPDP（ポリシーエンジン）が行い、経路上のPEPが適用・強制する。つまり流れは「プロテクトサーフェスに対してポリシーを作る → PDPが評価する → PEPが実行する」である。

まず、クレジットカードのプロテクトサーフェスへのアクセスを、キプリングメソッドで2つ書き下ろす。人（引受担当者）と非人間（決済アプリ）の両方を示す。

問い例1：引受担当者 → 引受審査アプリ（人）例2：決済アプリ → カード会員データ（非人間）
Who役割＝引受担当者サービスアカウント＝決済アプリのワークロード
What引受審査アプリで与信判定を行うカード会員データの該当レコードを読む
When営業時間内取引処理中（都度）
Where社内／VPN・管理端末想定された内部経路（同一PS内）
Why与信審査という業務上の必要決済処理に必要な参照
HowMFA＋準拠端末、セッション短時間・再評価mTLS＋最小権限（該当レコードのみ）

表2：キプリングメソッドによるポリシー文の例（クレジットカードのプロテクトサーフェス）

例1は「引受担当者が、社内の管理端末から、営業時間内に、与信審査のために、MFA付きで引受審査アプリを使う」という一文に相当する。例2は「決済アプリのワークロードが、取引処理中に、mTLSで、カード会員データの該当レコードだけを読む」という一文である。この条件を満たさないアクセスは、すべて拒否される。

同じ要領で、外部SaaSを使う人（営業担当）と、非人間（ATM）の例も書ける。

問い例3：営業担当 → CRM（人・外部SaaS）例4：ATM → 決済取引（非人間）
Who役割＝営業担当登録済みATM（証明書で識別）
What顧客訪問の記録をCRMに登録する現金引き出しの決済取引を実行する
When営業時間内営業時間内
Where自宅可（外出先）だが会社支給端末・SASE経由登録拠点のATM網からのみ
Why訪問記録という業務上の必要利用者の引き出し要求に応じる
HowSASE経由＋MFA、CRM側は自社経由のみ許可クライアント証明書＋EMV認証、限度内に制限

表3：キプリングメソッドによるポリシー文の例（つづき）

例3の営業担当は、外出先の自宅からでもCRMに記録できるが、会社支給端末でSASE経由に限る。CRM（SaaS）側は自社経由のアクセスだけを通す。例4のATMは、登録拠点・クライアント証明書・EMV認証・限度額という条件で、決済取引だけを許す。人か非人間か、内部か外部SaaSかで、5W1Hの埋め方が変わるのが分かる。

これらのポリシーが、第3回で配置したどのPEPで実行されるかを対応づけると、次のようになる。プロテクトサーフェスへの各アクセス（フロー）に対してポリシーを定義し、その経路上のPEPが適用・強制する、という関係が見て取れる。

プロテクトサーフェスへのアクセス（フロー）ポリシーの要点（許可する条件・それ以外は拒否）適用・強制するPEP
顧客／営業担当 → カードWebアプリ（入口）顧客＝MFA＋既知デバイス／営業担当＝SASE経由・会社支給端末・営業時間内入口のPEP
カードWebアプリ → 引受審査（内部）引受担当者＝社内／VPN＋管理端末＋MFA、営業時間内、与信判定のみアプリ手前のPEP
アプリ → カード会員データ（最重要データの手前）決済アプリのサービスアカウント＝mTLS＋該当レコードのみ。人間の直接アクセスは拒否データ手前のPEP
引受審査 → 信用調査機関（外部接続）与信照会のトランザクションのみ（想定プロトコル・宛先）外部接続のPEP
ATM → 決済取引（非人間の入口）登録済みATM＋クライアント証明書＋EMV認証、限度額内ATM経路のPEP

表4：プロテクトサーフェスへの各アクセスに対するポリシーと、それを実行するPEP

たとえば「アプリ → カード会員データ」のフローには、決済アプリのサービスアカウントがmTLSで該当レコードだけを読むというポリシーを定義し、データ手前のPEPがそれを強制する。人間が直接クエリしようとしても、このPEPで拒否される。ポリシーはあくまでプロテクトサーフェス（守る対象）を主語に作り、PEPはその実行場所である、という点がここでも確認できる。

1回のアクセスがどう実行されるか — 人と非人間で追う

「配置したPEPが、PDPの判断に従ってポリシーを実行する」を、実際の1回のアクセスで具体的に追ってみる。人（引受担当者）と非人間（決済アプリ）の2本を並べると、判断材料（データソース）が違っても、流れは同じであることが分かる。

図4：1回のアクセスが実行される流れ（人・非人間の2例）

【人】引受担当者が引受審査アプリにアクセスする1回：

  • ① 要求：引受担当者の要求が、アプリ手前のPEPに届く。
  • ②③ 照会・評価：PEPは自分で判断せず、PDPに照会。PDPはデータソースで本人性（IdP／MFA通過）、端末状態（管理端末か）、時間（営業時間内か）を確認する。
  • ④⑤ 判定：ポリシー『引受担当者＝社内／VPN＋管理端末＋MFA、与信判定のみ』に照らして許可と判定し、PEPに返す。
  • ⑥ 強制：PEPが許可を強制し、与信判定の操作だけを通す。

【非人間】決済アプリがカード会員データを読む1回：

  • ① 要求：決済アプリのサービスアカウント（SA）が、該当レコードの読取りを要求する。
  • ②③ 照会・評価：PEPがPDPに照会。PDPはSAの正当性とmTLS証明書の有効性、要求元が想定ワークロードかを確認する（ここでの判断材料は、人の場合のMFA・端末状態ではなく、証明書・ワークロードの正当性）。
  • ④⑤⑥ 判定・強制：ポリシー『決済アプリのSA＝mTLS＋該当レコードのみ』に照らして許可し、PEPが該当レコードだけを通す。

もし人間が同じカード会員データに直接クエリしようとすると、②〜⑤で条件（SA・mTLS・想定経路）を満たさないため、⑥のPEPで拒否される。同じデータでも、正規のワークロード経由なら通し、それ以外は止まる。これが「ポリシーをPDPが評価し、PEPが実行する」の具体像となる。

ステップ3（CBAC）とのつながり

第3回で見たCBAC（コンテキストベースアクセス制御）と、このステップ4は表裏一体である。キプリングメソッドで書いた5W1Hが、そのままCBACの評価属性になる。Whoは主体の役割、Whereは場所・ネットワーク、Whenは時間、Howは技術的統制。これらをPDPのポリシーエンジンが評価し、PEPが強制する。つまり、ステップ4で「ルールを言葉で定義」し、ステップ3のアーキテクチャで「そのルールを実行」する、という関係になる。

特権アクセス（管理者）のポリシー

ポリシー作成で、とりわけ慎重に扱うべきなのが管理者（特権）アクセスである。管理者は多くのシステムに広くアクセスできるため、攻撃者にとって格好の標的であり、ひとたび乗っ取られると内部を横移動され、影響範囲が一気に広がる。だからこそ、通常ユーザー以上に厳格なポリシーを敷く。CSA文書も特権アクセスの制御を重要な統制として挙げている。ここでも、ステップ1〜4の流れがそのまま効いてくる。

  • 踏み台を独立したプロテクトサーフェスにする（ステップ1）：管理作業は、隔離できる踏み台（jump host／bastion）からのみ行う。踏み台自体を1つのプロテクトサーフェスとして定義する。
  • アイデンティティの分離（ステップ2）：普段のアカウント（メール・チャット等）と管理用アカウントを完全に分ける。「山田」と「管理者・山田」は別ID・別環境とし、インターネットにつながる普段の端末から管理作業をしない。こうしないと許可すべきフローが増え、横移動が容易になる。
  • 踏み台への到達を最も固く（ステップ3・4）：まずネットワークで絞る（社内の限定IP／ユーザーIDからのみ）。ネットワーク到達が無ければ攻撃者は何もできない。認証は、ID・パスワードだけでは弱いため、クライアント証明書＋MFAトークンを重ねる。
  • PAM・短命セッション：特権アクセス管理（PAM）で、対象システムへの権限をその都度要求させ、短命の認証情報（短寿命のSSHトークン等）で、必要な間だけ付与する。踏み台から管理対象への接続も同様に絞る。
  • 踏み台の上でできることを絞る：メールもインターネットアクセスも不可。外部へは出させず、内部の必要な資源（ファイル共有、コンテナレジストリ等）だけに限定する。OS更新なども、ダウンロードをスキャン・ハッシュ検証するプロキシ経由で取り込み、時間帯も制限できる。最も避けたいのは、踏み台に遠隔操作ツールを仕込まれることである。
  • できれば映像のみ（KVM）：最も厳格にするなら、データ転送を伴わない映像（KVM）アクセスに限る。一般にはRDPで踏み台に入る運用が多い。

狙いは、万一、踏み台が侵害されても攻撃者に何もさせないこと、つまりデータを持ち出せず、指示（マルウェア等）も送り込めない状態にする。そして、踏み台にアクセスする全員を監査する。この監査こそ、次回のステップ5（監視と保守）につながる。なお、いまは管理用アカウントを分ける組織は増えたが、依然としてインターネットにつながる普段の端末から管理作業をしている例が多く、ここは改善の余地が大きい。

インシデントの検知と対応

ステップ4は、アクセスポリシーを定義するだけではない。CSA文書は、ステップ4の活動にインシデント検知・対応メカニズムの構築も含めている。ポリシーに反するアクセスや、正常な動作からの逸脱を検知したら、アラートを上げ、遮断や再認証などの対応につなげる。第2回でマッピングしたトランザクションフローが「正常の基準」となり、そこからの逸脱が検知の手がかりになる。

ファイアウォールだけではない — ポリシーの適用先

「ポリシー」と聞くとファイアウォールのルールを思い浮かべがちだが、ゼロトラストポリシーの適用先はそれだけではない。ステップ3で選んだ各コントロールに、それぞれポリシーを与えて初めて機能する。

  • SaaS／クラウド：クラウドは「誰でも扉を叩ける」のが弱点。SASE（クラウド上のファイアウォール）で通信を自社経由に集約し、SaaS側で「自社を経由した通信だけを許可する」よう設定する。その”自社経由である”ことを伝える手段として、大きめのSaaS（Microsoft 365・Google・Salesforce等）では通信に目印を差し込むヘッダー挿入、小さめのSaaSでは自社の出口IPだけを通すIP許可リストを使う。いずれも入口が自社経由に限定され、インターネットからの直アクセスを排除できるため、アタックサーフェスが大きく下がる。
  • エンドポイント（XDR）：コントロールがあっても、ポリシーがなければ何も止めない。たとえばカード会員データを扱うサーバーや引受担当者の端末で、ランサムウェア防御モジュールを有効化し、DBに触れてよいアプリを許可リストで限定する（未知のプロセスがカード会員データに触れたら遮断）。
  • アイデンティティ基盤（IdP）：条件付きアクセスで、場所・時間・デバイスまで絞る。たとえば引受担当者のログインは『社内／VPN＋管理端末＋営業時間内＋MFA』でのみ許可し、私物端末や深夜・国外からは追加認証か拒否とする。MFAも“ただ有効”では不十分で、設定を誤ると穴になる。
適用先クレジットカードでの具体例狙い
SaaS／SASE規制報告の提出ポータルや営業のCRMを、SASEで自社経由に集約し、SaaS側は『自社経由のみ許可』外部からの直接アクセスを排除
エンドポイント（XDR）カード会員データを扱うサーバーと引受担当者端末に、ランサム防御を有効化＋DBに触れるアプリを許可リスト化端末・サーバー側で不正を遮断
IdP（条件付きアクセス）引受担当者は社内／VPN＋管理端末＋営業時間＋MFAでのみログイン可。私物・深夜・国外は追加認証／拒否ログインの入口を状況で絞る

表5：ポリシーの適用先と、クレジットカードでの具体例

すべてに共通する原則は、具体的であること、そして業務上の正当性があることである。「全員がインターネットへ」のような広すぎるルールは避ける。理由（業務上の必要）がないポリシーは、そもそも作らない。

ポリシーの検証と見直し — 最も見落とされがち

ポリシーは作って終わりではない。むしろ検証（見直し）こそ最も見落とされがちな工程である。新しいアプリを動かすためにルールを足すのは自然に起きるが、アプリが廃止されてもルールは自動では消えないし、誰も困らないので放置され、ポリシーが腐敗（decay）していく。検証では、少なくとも次を確認する。

  • ステップ2と突き合わせる：そのフローは、ステップ2で「このプロテクトサーフェス間の通信は許す」と決めたものか。新たな要望なら、両プロテクトサーフェスの業務オーナー同士が合意して初めて許可する。
  • 具体的で、十分に厳格か：any/any のような広いルールを残さない。L4（ポート）ではなくL7（アプリケーション）で書き、必要ならスキャンや復号まで行う。
  • ツールの機能を使い切る：機器の自動更新で増えた新機能が未使用のまま眠りがち。たとえば新しいURLフィルタのカテゴリが追加されるとき、業務を止めないよう既定で「許可」で入ることが多い。ところがこの「許可」は、通信を通すだけでログも残さない設定になっていることが多く、その結果、該当する通信が起きていても管理者からは見えない（可視性が失われる）。更新のたびに、こうした新機能・カテゴリの設定を点検する。
  • 自動化する：PEPは多いので、変更のたび／毎日、構成を取得して整合を自動チェックするのが理想。難しければ、定期的に人が見直す。

この見直しは、5ステップを一度で終わらせず、繰り返し回していくことの一部でもある。業務オーナーの交代はステップ1、新たな通信要望はステップ2、新しいコントロールの必要はステップ3と、変化に応じて各ステップに戻る。ポリシーが「最初は静的でも、運用しながら動的に育つ」のは、この反復があるからである。まず1つのプロテクトサーフェスで作り込み、成熟させてから次へ広げる、という「練習台から本命へ」の考え方（第1回）も、ここで効いてくる。

ポリシー作成・検証の実務ポイント

  • デフォルト拒否から始め、必要なアクセスだけを明示的に足していく
  • 具体的に（広すぎる any/any を避け、L7・業務の言葉で書く）
  • 人と非人間（ワークロード・API・ボット・デバイス）の両方をWhoに含める
  • 業務上の正当性がないポリシーは作らない／廃止時はルールも消す
  • 自動で構成を点検し、更新で増えた機能・カテゴリの取りこぼしを防ぐ

まとめ

第4回では、配置したPEPにルールを与えるゼロトラストポリシーを作るステップ4を扱った。要点は次のとおりである。

  • ポリシーはアプリケーション層（L7）で、最小特権・デフォルト拒否を原則に、プロテクトサーフェスの近くで適用する
  • 書き方はキプリングメソッド（Who・What・When・Where・Why・How＋どれだけの時間）。人だけでなく非人間も対象にする
  • 5W1HはそのままCBACの評価属性になり、ステップ3のアーキテクチャが実行する
  • 適用先はファイアウォールだけでなくSaaS／SASE・エンドポイント・IdPにも及ぶ。管理者アクセスは踏み台・アイデンティティ分離で特に厳格にする
  • 作って終わりにせず検証・見直しを（自動で）繰り返す。廃止時はルールも消し、静的から動的へ育てる
  • ステップ4にはインシデント検知・対応の構築も含まれる

守る対象を定め（1）、流れを可視化し（2）、アーキテクチャを構築し（3）、ポリシーを作った（4）。最終回（第5回）は、ステップ5「監視と保守」を扱う。すべてのトラフィックをアプリケーション層まで検査・記録し、そのテレメトリを使って、プロテクトサーフェスを継続的に強くしていく。ゼロトラストを「作って終わり」にしないための最後のステップである。

以上

ゼロトラスト実装の5ステップ（NSTACモデル）入門　～　第3回：ステップ3 　ゼロトラストアーキテクチャの構築

コメントをどうぞ

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

この回のねらい

第1回で守る対象（プロテクトサーフェス＝DAAS）を定義し、第2回でその周りのトランザクションフローを可視化した。守るものと、その動きが見えたら、次はいよいよ実装である。ここでは、ステップ3「ゼロトラストアーキテクチャの構築」を扱う。

図1：ゼロトラスト導入の5ステップと、本ブログが扱うステップ3（CSA文書の5段階プロセスを基に作成）

ステップ3のねらいは、第2回でマッピングしたトランザクションフローを基盤に、ポリシー実施ポイント（PEP）を適切に配置したゼロトラスト環境を設計することである。「誰が・何に・どんな状況でアクセスできるか」を、各プロテクトサーフェスの出入口で実際に検証・制御できる形に落とし込んでいく。

おさらい：ゼロトラストの原則

アーキテクチャを設計する前に、拠り所となる原則を確認しておく。ゼロトラストは、次のような考え方に立っている。

  • 敵対的な環境を想定する／すでに侵害されていると想定する（assume breach）
  • 決して信頼せず、常に検証する（既定で拒否し、ユーザー・デバイス・アプリ・トランザクションを継続的に検証）
  • 明示的に精査する（複数の属性を用いて、安全な方法で一貫してアクセスさせる）
  • 統合的な分析を適用する（データ・アプリ・ネットワークに横断的な分析と挙動監視を効かせる）

これらを設計に落とすと、次の原則になる。認証・認可が済むまでアクセスを与えない（パケット1つに至るまで検査）／アクセスは一時的で再検証が必要／最小特権（必要最小限のアクセスだけを付与）／コントロールの有効性を継続的に監視する。

ゼロトラストアーキテクチャの中核 — PDPとPEP

アクセスの可否を判断するには、まず3つの中核要素、通信（アクセス要求）・アイデンティティ（要求する主体）・リソース（守る対象）が必要になる。さらに、判断を支える2つの要素として、ポリシー（誰が・何に・いつ・どのようにアクセスできるかを定める規則）と、データソース（ポリシーを動的に更新するための状況情報）がある。

NIST SP 800-207 は、これを2つの仕組みで表現している。判断を下すPDP（ポリシー定義ポイント）と、それを実際に強制するPEP（ポリシー実施ポイント）である。両者はトラフィックのアクセス経路上に置かれ、リソースへのアクセスを制御する。

図2：ゼロトラストアーキテクチャの中核（PDP／PEP）（NIST SP 800-207 の論理モデルを基に作成）

  • PDP（コントロールプレーン）：ポリシーエンジン（PE）とポリシー管理者からなる。データを分析してルールに変換し（PE）、そのルールをPEPに伝える（ポリシー管理者）。
  • PEP（データプレーン）：ゲートウェイ（関所）として働き、正しい主体に、正しいアクセスレベルで、承認されたリソースへのアクセスだけを許可する。

PDPの判断は、多様なデータソースから供給される状況情報（コンテキスト）に支えられる。IdP／Active Directory、IDS／IPS、脅威インテリジェンス、PKI（証明書失効リスト）、資産・デバイス管理（CDM＝継続的診断・対策など、資産のOS・ソフト構成や脆弱性・健全性を継続的に把握する仕組み）、SIEM、法令・規制要件などである。これらの情報が豊富なほど、より的確なアクセス判断ができる。

なお、ゼロトラストではPEPの数が大幅に増えるため、アクセスモデルを手作業で管理するのは現実的でない。自動化が、細かな制御と全体制御の両立に不可欠となる。

設計の柱 — 何を組み込むか

PDP／PEPという骨格の上に、以下のようなゼロトラストらしさを与える具体的な設計要素を組み込んでいく。

マイクロセグメンテーション

ネットワークをより小さな独立したセグメントに分割し、ワークロードやアプリ、デバイス単位で境界（マイクロペリメータ）を設ける。トランザクションフローの理解に基づいて論理的にグループ分けすることで、万一侵入されてもラテラルムーブメントを封じ込め、アタックサーフェスを縮小できる。

コンテキストベースのアクセス制御（動的ポリシー）（CBAC)

アクセス判断は静的ではなく、動的かつ状況依存で行う。ユーザーのアイデンティティ、デバイスの状態、場所、実行中のトランザクションといったコンテキストを評価して、その都度アクセスの可否を決める。第2回でマッピングしたトランザクションフローが、この判断材料になる。

最小特権

役割やアプリに不可欠なトランザクションだけを許可し、タスクの実行に必要な最小限のアクセスに制限する。トランザクションフローマッピングは「正常な動作の基準」を与えるため、そこからの逸脱や異常を検知し、アラートや対応につなげられる。

暗号化とデータ保護／監視とログ

通信・データを暗号化して保護する。あわせてデータ損失防止（DLP）で機微情報の持ち出しを防ぐが、暗号化された状態では中身を検査できないため、DLPは平文が現れる地点のエンドポイントや、通信を復号する検査ポイントで効かせる。また、集中型のログ記録と、SIEMによるリアルタイムのモニタリング・相関分析を導入し、コントロールの有効性を継続的に監視する。

実装パターン — アーキテクチャの選択肢

ゼロトラストアーキテクチャを実際に実現する方式には、代表的なものがいくつかある。いずれもPDP／PEPという共通の土台の上に立ち、相互に影響し合ってきた。用途に応じて選び、組み合わせることになる。

実装パターン特徴主な用途
SDP接続を事前検証（SPA等）し、認証・認可されるまで既定で全拒否。リソースを外部から隠すリソースの隠蔽、境界の動的生成
ZTNASDPとほぼ同じ発想。ユーザーとアプリのアクセスを検証し、必要なアプリだけに接続を許すリモートアクセス、VPN置き換え
BeyondCorpGoogleが自社向けに実装。所在地を信頼せず、デバイスとユーザーの状態で判断リモートアプリアクセス
NISTアプローチ（SP 800-207）PDP／PEPを中核とする論理アーキテクチャ。各方式に共通する土台設計の基本モデル

表1：代表的なゼロトラストアーキテクチャの実装パターン

プロテクトサーフェス単位で設計する

ゼロトラストアーキテクチャは、プロテクトサーフェスごとに、その出入口（マイクロペリメータ）へPEPを配置して設計する。第2回でマッピングした「どの主体が・どの経路で・どのDAAS要素にアクセスするか」を、そのままPEPの配置とポリシーに写し取るイメージである。

第1回・第2回で用いたクレジットカードサービスの例で示すと、次のようになる。

図3：クレジットカードのプロテクトサーフェスにPEPを配置する（CSA文書を基に作成）

顧客・営業担当・ATMからの入口、アプリとカード会員データの間、そして信用調査機関・規制報告・住宅ローン／預金といった外部・他システムとの接続点、それぞれにPEPを置き、マッピングしたフローに沿ったアクセスだけを許可する。組織によっては、まず粗い粒度のマクロセグメンテーションから始め、時間をかけてマイクロセグメンテーションへ進めるのが現実的な場合もある。

実際のアーキテクチャはどうなるのか

ここまでの図は、役割（誰が判断し、誰が強制するか）を示す論理アーキテクチャである。では、これを実際の構成に落とすと何になるのか。ポイントは、論理的な役割を具体的なコンポーネント（製品・機能）に割り当てることである。

  • PEPの実体：単一の製品ではなく、守るDAASの各出入口に分散した実施点の集合。次世代ファイアウォール、マイクロセグメンテーション製品、ゲートウェイ／プロキシ、SDP／ZTNAゲートウェイ、APIゲートウェイ、サービスメッシュのサイドカー（コンテナ）、エンドポイントのエージェントなど。
  • PDPの実体：ポリシーエンジンとポリシー管理者を担うポリシー制御基盤（ゼロトラスト管理コンソール、ポリシーサーバー、IdP／IGA、SDPコントローラ等）。PEPは判断を持たず、PDPに問い合わせて判定に従う。
  • データソースの実体：IdP／AD、IDS／IPS、EDR、脅威インテリジェンス、PKI、資産管理、SIEM等が、PDPに状況（コンテキスト）を供給する。

そして、1回のアクセスがどう流れるかを追うと、実際の動作が見えてくる。クレジットカードの例で、顧客がカードWebアプリにアクセスする場面を示すと以下のようになる。

図4：1回のアクセスがゼロトラストで処理される流れ（NIST SP 800-207 のPDP／PEPモデルを基に作成）

要求はまずアプリ手前のPEPに届くが、PEPは自分では判断せず、PDPに照会する。PDPはデータソース（IdPで本人性、EDRで端末状態、脅威インテリジェンスでリスク）を評価してポリシーに照らし、判定をPEPに返す。PEPは許可／拒否を強制し、許可ならアプリへ通す。さらにアプリからカード会員データへ進む際には、その間の別のPEPが同じ手順を繰り返す。

この「各出入口で、要求ごとに、PDPへ照会して強制する」という反復こそが、ゼロトラストの実際のアーキテクチャの姿である。従来の境界防御のように「一度入れば中は自由」ではなく、どのPEPも毎回PDPに確認する。前掲の実装パターンでいえば、SDP／ZTNAはコントローラ（PDP役）とゲートウェイ（PEP役）、BeyondCorpはアクセス制御エンジン（PDP役）とアクセスプロキシ（PEP役）として、この構図を実現している。

具体例：SDPによるベンダーニュートラルな実装

ここではSDPを使ってアーキテクチャの実装をもう少し具体化してみる。CSAのSDPは、特定製品に依存しない標準仕様として構成要素が定義されており、ベンダーニュートラルな実装例として分かりやすい。SDPは次の3つの要素からなる。

  • IH（起動ホスト）：SDPクライアントを載せた接続元の端末（顧客・営業担当の端末、ATMなど）。暗号署名した接続要求を出す。
  • AH（受入ホスト）＋ドロップオール・ゲートウェイ：守るサービスをホストする側。既定ですべての通信を落とし（ドロップオール）、認可されるまで外部から見えない（cloaked）。つまり、PEPの実体。
  • コントローラ：コントロールプレーンで認証・認可を判断する頭脳。IAMなどのデータソースを参照する。つまり、PDPの実体。

これらを、クレジットカードサービスのプロテクトサーフェスに当てはめると、次のような構成になる。

図5：SDPによるベンダーニュートラルな実装例

顧客がカードWebアプリにアクセスするのは、次の順でつながる。

  1. ① IH → コントローラ：SDPクライアントが単一パケット認可（SPA）と認証情報を送り、本人性・デバイス状態を検証してもらう。（SPAの解説はこちらのブログを参照）。
  2. ②③ コントローラ → AH／IH：判断の結果、このIHが接続してよいAH（カードWebアプリ）をAH側に許可し、IHには接続先を通知する。
  3. ④ IH → AH：IHがAHにSPAを送ると、それまで全拒否だったドロップオール・ゲートウェイが、そのIHのためだけに開く。
  4. ⑤ IH ⇄ AH：相互TLS（mTLS）で暗号化された接続を直接確立し、はじめてデータが流れる。

ポイントは、認証・認可がすべて“接続の前”にコントロールプレーンで済むこと、そして許可されるまでリソースが存在すら見えない（ドロップオールで不可視）ことである。これにより、正体不明のトラフィックはそもそもリソースに到達できず、アタックサーフェスが大きく縮小する。コントローラ＝PDP、AH＋ゲートウェイ＝PEP、という役割対応も、この例で明確である。

なお、ここで挙げたIH・AH・コントローラ・SPA・mTLS・ドロップオールはいずれもSDP仕様の用語であって特定製品名ではない。実際には、SDP・ZTNA・BeyondCorpといった枠組み（コントローラ＝PDP、ゲートウェイ／プロキシ＝PEP）のいずれかを土台に選び、そこへIdPやEDRといったデータソースを接続して実装する。

PDPの中身：CBAC（コンテキストベースアクセス制御）をどう実装するか

SDPの例では、AH＋ゲートウェイ（PEP）が「どう強制するか」を具体化した。では、その判断を下すPDPの中身はどうなるのか。PDPはポリシーエンジン（PE）とポリシー管理者からなり、PEが「通す／通さない」を決め、ポリシー管理者がその判定をセッションとしてPEPに発行・失効させる。

PEの判断の核が、CBAC（コンテキストベースアクセス制御）である。従来のアクセス制御と並べると位置づけがはっきりする。

方式判断の基準特徴
RBAC（役割ベース）役割（ロール）だけで静的に許可を決めるシンプルだが状況を見ない
ABAC（属性ベース）主体・リソース・環境の属性を組み合わせて判断柔軟。ゼロトラストの土台
PBAC（ポリシーベース）属性を組み合わせたポリシー（ルール）で判断ルールとして表現・管理
★CBAC（コンテキストベース）PBACに加え、その場の状況（デバイス状態・場所・時刻・リスク）を入力として動的に評価アクセスのたびに評価し直す

表2：アクセス制御方式とCBACの位置づけ

CBACは、ABAC／PBACの一種と捉えられるが、環境・状況の属性（コンテキスト）を重視し、アクセスのたびに動的に評価し直す点が要である。PEは、集めた属性をポリシー（＝トラストアルゴリズム）に照らし、「許可／追加認証（step-up）／拒否」を決める。

図6：PDPによるCBACの判断（NIST SP 800-207 のトラストアルゴリズムを基に作成）

クレジットカードの例で、引受担当者が引受審査アプリにアクセスする場面のポリシーを、擬似的に書くと次のようになる。

CBACポリシーの例（引受審査アプリへのアクセス）

  • もし〔役割＝引受担当者〕かつ〔端末＝管理端末で準拠〕かつ〔場所＝社内／既知〕かつ〔MFA＝通過〕かつ〔リスクスコア＜しきい値〕ならば → 許可（セッションは短時間で失効。以後も再評価）
  • 端末が非準拠、または見知らぬ場所・時刻 → 追加認証（step-up）を要求
  • リスクスコアが高い、または権限外 → 拒否

重要なのは、この判断が一度きりではないことである。セッションの発行後も継続的に再評価し、途中で端末が非準拠になったり、リスクが上昇したりすれば、その場でアクセスを失効させる。これが「常に検証する」を実装レベルで成り立たせる仕組みであり、静的なRBACとの決定的な違いである。

なお、トラストアルゴリズムには、条件をすべて満たすかで判断する基準ベース（criteria-based）と、各属性に重みをつけてスコアで判断するスコアベース（score-based）がある。またリソースごとに独立して判断するか、主体の直近の行動履歴まで加味する（コンテキスト型）かでも設計が分かれる。組織のリスク許容度に応じて選ぶことになる。

CBACポリシーの具体例 — リソースごとに判断が変わる

CBACの勘所は、同じ人でも状況で結果が変わる／人間とワークロードで扱いが違うことにある。クレジットカードの例で、リソースごとにポリシーを並べると、その違いが具体的に見えてくる。

リソース状況（コンテキスト）判定備考
引受審査アプリ（内部・機微）引受担当者＋管理端末（準拠）＋社内／VPN＋MFA＋低リスク許可セッション短時間・再評価
引受審査アプリ同じ担当者だが私物端末・自宅からstep-up＋読取のみ権限を状況で縮小
カード会員データ（最重要・PII）決済アプリのサービスアカウント＋mTLS＋想定経路許可（該当レコードのみ）正規ワークロード
カード会員データ人間ユーザーが直接クエリ／大量エクスポート拒否＋アラートアプリ経由のみ許可
カード申込（外部・B2C）顧客＋MFA＋既知デバイス＋低リスク許可—
カード申込新規デバイス／不可能移動（地理的に不自然）step-up（追加認証）—
ATM（非人間）登録済みATM＋証明書＋EMV認証＋営業時間内許可（限度内）—
ATM証明書失効／未登録端末拒否—

表3：クレジットカードの各リソースに対するCBACポリシーの例

同じ「引受担当者」でも、管理端末・社内なら通し、私物・自宅なら追加認証のうえ読み取り拒否だけに絞る。カード会員データは、正規のワークロード（決済アプリ）からは許可するが、人間の直接アクセスや大量エクスポートは拒否する。誰か（役割）だけでなく、どこから・どの端末で・どんなパターンかまで見て判断するのがCBACである。

CBACをどんな技術で実装するか

では、こうしたポリシーを実際に動かすのは何か。CBACは単一の製品ではなく、次のような技術・仕組みの組み合わせで実装される。

  • ポリシー言語／ポリシーエンジン：ABAC／PBACを表現・評価する仕組み。標準としてはXACML、軽量なものではOPA（Open Policy Agent）／Regoなどのポリシーエンジンで、属性と条件からなるルールを評価する。
  • IdPの条件付きアクセス：多くのアイデンティティ基盤が、ログイン時に場所・デバイス状態・リスクを評価してMFAや拒否を出す「条件付きアクセス」機能を持つ。CBACの一部を担う。
  • リスクエンジン（継続的評価）：UEBA（利用者・端末の挙動分析）やリスクスコアリングが、脅威・不審度をリアルタイムに算出してPEに供給する。
  • 属性・信号のソース：デバイスのポスチャーはEDR／MDMから、本人性はIdPから、機微度はデータ分類から。これらが判断材料（属性）になる。
  • 実施点（PEP）：ZTNA／SDPゲートウェイ、APIゲートウェイ、サービスメッシュ、リバースプロキシなどが、PEの判定を実際に強制する。

実装の型としては、判定を毎回外部のポリシーエンジンに問い合わせる型（PEP↔PDP分離）と、各サービスにポリシーを配布して手元で評価する型（サイドカー等）がある。前者は一元管理しやすく、後者は低遅延で大規模な環境に向いている。いずれも「属性を集め、ポリシーで評価し、動的に判定し、継続的に再評価する」という流れは同じである。

なお、ここで挙げたXACML・OPA・条件付きアクセス・UEBAなどは実装手段の代表例であり、特定製品の推奨ではない。自組織の環境（クラウド／オンプレ、コンテナの有無など）に応じて選択、および組み合わせることになる。

既存環境からどう移行するか

ゼロトラストアーキテクチャは、既存の仕組みを一度に置き換える「入れ替え」ではなく、段階的な移行として進める。次のような考え方が必要である。

  • ギャップ分析：現状のアーキテクチャと、目指すゼロトラストの状態との差を洗い出す。
  • 既存アーキテクチャからの移行：一斉ではなく、プロテクトサーフェス単位で少しずつ移行する（重要資産＝クラウンジュエルは、練習を積んでから）。
  • 情報セキュリティポリシーとの整合：既存のポリシーやガバナンス（ISMS等）と齟齬がないように揃える。
  • マネージドサービスか内製か：自組織の体制・スキルに応じて、外部サービスの活用と内製を選択する。

実装後は、トランザクションフローに照らしたアーキテクチャのレビュー、テスト、継続的改善を回していく。ここは次回のステップ4・5（ポリシー、監視と保守）にもつながる。

まとめ

第3回では、マッピングした流れを土台に、ゼロトラスト環境を設計するステップ3を扱った。要点は次のとおりである。

  • 中核はPDP（判断＝ポリシーエンジン＋ポリシー管理者）とPEP（強制＝関所）。データソースが判断を支え、自動化が前提になる
  • 設計の柱はマイクロセグメンテーション・コンテキストベースのアクセス制御・最小特権・暗号化・監視／ログ
  • 実装パターンはSDP・ZTNA・BeyondCorp・NISTアプローチなど。用途に応じて選び、組み合わせる
  • 設計はプロテクトサーフェス単位でPEPを配置し、既存環境からは段階的に移行する

守る対象を定め（ステップ1）、流れを可視化し（ステップ2）、アーキテクチャを構築した（ステップ3）。次回（第4回）は、ステップ4「ゼロトラストポリシーの作成」を扱う。配置したPEPに、実際にどのようなルール（誰に・何を・どの条件で許すか）を持たせるか。アクセスポリシーを具体的に定義していく。

以上

ゼロトラスト実装の5ステップ（NSTACモデル）入門　～　第2回：ステップ2　トランザクションフローのマッピング

1件のフィードバック

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

この回のねらい

第1回では、ゼロトラストの出発点である「プロテクトサーフェスの定義」を扱い、守るべき対象をDAAS（データ、アプリケーション、資産、サービス）として業務単位で束ねる考え方を扱った。守る対象が定まったら、次は何をするか。それが本編のステップ2「トランザクションフローのマッピング」である。

図1：ゼロトラスト導入の5ステップと、本稿が扱うステップ2（CSA文書を基に作成）

ステップ2のねらいを一言でいえば、プロテクトサーフェスの周りを、データやトランザクションがどこをどう流れているかを可視化・文書化することである。これにより、業務システムが実際にどう動くかを理解し、後続のステップ3（アーキテクチャ構築）とステップ4（ポリシー作成）でコントロールをどこに置くかを判断できるようになる。ここでは、CSAが公開した「ゼロトラストのためのトランザクションフローのマッピング」（以降、CSA文書と略称）の内容を元に説明する。

トランザクションフローとは何か

トランザクションとは、アプリケーションやサービスを通じたデータへのインターフェースであり、データの取得・処理・移動・永続化を含んでいる。ここでいうトランザクションフローは、金融取引や特定の機密情報だけを指すのではなく、あらゆる情報・データのフローを意図している。データは複数のプラットフォーム・サービスプロバイダ・地理的領域・ユーザーを横断して流れるため、その全体像を捉えるのは複雑な作業になる。

ステップ2で理解・文書化するのは、たとえば次のような事項である。

  • アプリ、データ、インフラにアクセスするリソース（ユーザー、API、Webサービスなど）
  • 各アプリケーションとそのデータの関係（取得、転送、移動、永続化を含む）
  • DAAS要素が、相互に、またプロテクトサーフェス外の資源とどう相互作用・通信するか
  • トラフィックがネットワークをどう通過し、異なるセグメントや境界を越えて流れるか
  • 各インタラクションやデータフローの背景にある業務上の文脈と根拠

なぜマッピングするのか — 何が分かるか

これらを可視化・文書化することで、組織は次のような知見を得られる。いずれも後続のステップに直接つながる。

  • 各プロテクトサーフェスを効果的に囲むネットワークセグメンテーションの方法
  • セキュリティコントロールとポリシー実施ポイント（PEP）を戦略的に配置すべき場所
  • ポリシーに基づき明示的に認可・拒否すべきトラフィックパターンと通信チャネル
  • DAAS要素の機能や相互作用に整合したZTアーキテクチャの設計方法
  • アイデンティティ・デバイス・ネットワークの要素を反映した、プロテクトサーフェスごとのアクセスポリシー

何を可視化するか — ステップ2の活動

CSA文書は、ステップ2の活動を次のように整理している。ステップ1で作った「守る対象の一覧」を、動きの面から検証・精緻化していくイメージである。

  • DAAS要素を検証し、そのメタデータを精緻化する
  • ユーザーと、使用するエンドポイント端末の種類を特定・文書化する
  • 依存関係（関連する業務システムや外部サービス）を特定する
  • DAAS要素間・ユーザー・他システム・外部サービスとのトランザクションを特定する
  • データフローをマッピングし、システムの動作を文書化する
  • 本番／バックアップ・災害復旧／単一障害点（SPOF）／開発・テストのどれに当たるかを見極める

マッピングの進め方 — 2つのアプローチ

DAAS要素の機能と相互作用を理解し文書化するには、大きく2つのアプローチがある。両者は互いに補い合う形になる。

① 包括的なシステム分析（既存アーティファクトの活用）

ネットワーク図、アプリケーションアーキテクチャ図、データフロー図、ユーザーインタラクション図、脅威モデル、事業継続／災害復旧計画といった既存の資料を持ち寄り、足りなければ新たに作成する。そのうえで、業務システムオーナーやネットワーク・アプリ・エンタープライズの各アーキテクト、データ管理者などのステークホルダーと連携し、システムの動作・目的・主要リスクを理解する。現代のアプリケーションはモノリシックから、マイクロサービス・コンテナ・サーバーレスといったモジュール化・分散化へと変化しているため、マルチティア（N層）構成での層内・層間のデータフローにも注意する。

② スキャン・モニタリングツールの活用

既存資料だけでは実態と食い違うことがあるため、実際のトラフィックを観測するツールを組み合わせる。これらは直接トランザクションをマッピングするわけではないが、収集情報を突き合わせることでフローの理解を深められる。

ツールの種類（例）取得できる主なデータ
アプリ可観測性（Jaeger、OpenTelemetry等）トレースデータ、パフォーマンス指標
ログ分析（Splunk、ELK等）ユーザー活動（認証・アクセス・データ変更）、各種ログ
APIモニタリング（Postman、Apigee等）API呼び出し・ステータス・利用状況（利用パターン、トラフィック）
ネットワーク（Wireshark、Nagios等）トラフィック（ヘッダー・ペイロード・プロトコル）、機器状態
コンテナ（Cilium、Calico等）コンテナのトレース、トラフィック種別、サービス定義・ラベル

表1：トランザクション把握に使うスキャン・モニタリングツールの例（CSA文書 を基に作成）

なお、暗号化はメタデータや内容を隠すためマッピングを難しくしてしまう。その場合は、パケットサイズ・タイミング・方向などのメタデータ分析（復号せず、通信の外形から推測）、管理された環境でのTLS検査（通信路で復号して直接見る）、あるいはアプリログ・テレメトリを用いたアプリケーション層の可視性（通信路ではなく、アプリの記録から見る）で補う必要がある。

具体例：クレジットカードサービスのトランザクションフロー

CSA文書は、第1回と同じ架空の金融サービス組織を例に用いている。ここでは重要な業務システムとしてクレジットカードサービスを取り上げ、そのトランザクションフローをたどる。まず、このプロテクトサーフェスを構成するDAAS要素を検証する。

DAAS要素クレジットカードサービスでの内容（例）
データカード会員データ、個人識別情報（PII）
アプリケーションクレジットカードWebアプリ、引受審査アプリ
資産アプリケーションとデータベースをホストするサーバー
サービスカード申請・決済取引・カード審査・カード照合・カード印刷・レポート生成、DNS、アイデンティティサービス

表2：クレジットカードサービスのDAAS要素（CSA文書 を基に作成）

次に、このシステムに関わる人間ユーザーと非人間ユーザー（APIや外部インターフェースのアイデンティティ）を特定する。人間ユーザーは、内部・外部の全関係者を、それぞれの情報源から洗い出す。

人間ユーザー例情報源
内部ユーザー従業員、契約社員、派遣社員、システム管理者、特権ユーザーIAM、従業員ディレクトリ、人事記録、アクセスログ
外部ユーザー顧客、パートナー、サプライヤー、ベンダー、第三者サービス、ゲスト顧客データベース、パートナーポータル、ベンダー管理システム

表3：プロテクトサーフェスの人間ユーザー（CSA文書を基に作成）

続いて依存関係を特定する。内部依存（他のプロテクトサーフェスやライブラリ）、プロセス依存（ワークフロー、バッチ処理）、外部依存（サードパーティ、外部データソース、規制・契約）を洗い出す。クレジットカードサービスでは、信用調査機関・連邦規制報告・ATMといった外部サービスや、Active Directory・住宅ローン／預金サービス・DNS・アイデンティティサービスといった他の保護対象が関わってくる。

これらを踏まえてトランザクションフローをマッピングすると、次のように可視化できる。

図2：取引をマッピングしたクレジットカード・プロテクトサーフェス（CSA文書を基に作成）

各トランザクションは、送信元・宛先・通信方法（プロトコル、暗号化）・認証・サービスといった属性まで具体的に文書化する。抜粋すると次のようになる。

送信元トランザクション通信（プロトコル等）宛先サービス
顧客新規申込（PIIを含む）HTTPS、JSON、TLSカードWebアプリカードの申し込み
ATM現金引き出し・カード情報XML/JSON、EMVチップ認証ATM決済取引
カードWebアプリ新規カード判定（PIIを含む）HTTPS、RESTful、OAuth2.0、TLS引受審査アプリカード審査
引受審査アプリ与信照会（顧客の詳細）HTTPS、RESTful、OAuth、JWT信用調査機関信用調査API
引受審査アプリ規制報告（PIIを含む）HTTPS、XML、TLS連邦政府規制報告
住宅ローンローン詳細の確認SOAP、JSON、JWT引受審査アプリローンサービス

表4：クレジットカード・プロテクトサーフェスの取引詳細（抜粋。CSA文書 基に作成）

環境ごとの違い — クラウドとOT／IoT

マッピングの進め方は、環境によって大きく異なる。クラウドでは、IaaSの仮想マシン、PaaSのFunction、コンテナ（K8s）ワークロード、SaaS APIで性質が違うため、資産の重要度と望ましいコントロールレベルを設定する。CSPが提供するモニタリング・分析ツール（CloudWatch、Azure Monitor等）やクラウド固有のログを活用して可視化する。

OT／IoTでは、産業用制御システム（ICS）、SCADA、ビル管理、PLCといった対象があり、センサー／アクチュエーター（エッジ）、IoTゲートウェイ、IoTプラットフォーム、クラウド／リモートサービスの相互作用を確実に含める。デジタル環境全体でトランザクションを統一的に把握するには、オンプレ・クラウド・OT/IoTのデータを統合した一元的なビューを作ることが鍵になる。

マッピングの成熟度モデル

CSA文書は、トランザクションフローマッピングのプロセス成熟度を評価・改善するための5段階モデル（TFMPMM）を示している。臨機応変な段階から、自動化・リアルタイム化へと段階的に高めていく。

図3：トランザクションフローマッピングの成熟度モデル（CSA文書を基に作成）

マッピングでプロテクトサーフェスを精緻化する

トランザクションフローマッピングは、データフローの全体像を与え、すべてのユーザーとDAAS要素を特定できるようにする。その結果、理解されていない・冗長な・廃止された・業務に不可欠でなくなったフローを見つけ出せる。不要なDAAS要素を除去し、不足している要素を追加して、当初のプロテクトサーフェスを精緻化する。

注意：重要なサービスを止める前には、業務中断・セキュリティ課題・データ損失を避けるための備えが要る。関係部門（IT・セキュリティ・コンプライアンス・業務・アプリ所有者）と影響を確認し、依存関係をマッピングし、少なくとも1年分のログ・利用パターンを確認して利用頻度や役割を判断する。停止がセキュリティに与える影響も評価し、問題が起きたときに素早く戻せるロールバック計画を用意しておく。

こうして公開サービスを最小限に抑え、明確に定義され保護された境界を確立することで、アタックサーフェスを効果的に削減できる。精緻化を自動化すれば、削除・制限したサービスやプロトコルが再出現しても事前に検知・緩和でき、アタックサーフェスを長期にわたり最小に保つことができる。

まとめ

第2回では、守るべき対象（プロテクトサーフェス）の周りを、データとトランザクションがどう流れるかを可視化するステップ2を扱った。要点は次のとおりである。

  • 目的は、業務システムの動作を理解し、コントロールをどこに置くかを後続ステップに示すこと
  • 活動は、DAASの検証・ユーザーと依存関係の特定・トランザクションとデータフローのマッピング・本番／バックアップ等の区別
  • 進め方は、既存アーティファクトの分析とスキャン・モニタリングツールの組み合わせ（暗号化はメタデータ分析等で補う）
  • 成果として、プロテクトサーフェスを精緻化し、アタックサーフェスを削減できる

守る対象が定まり、その周りの流れが見えたら、次はいよいよ実装である。次回（第3回）は、ステップ3「ゼロトラストアーキテクチャの構築」を扱う。マッピングしたトランザクションフローを基盤に、ポリシー実施ポイント（PEP）を配置し、マイクロセグメンテーションやコンテキストベースのアクセス制御、最小特権を設計していく。

以上

ゼロトラスト実装の5ステップ（NSTACモデル）入門　～　第1.5回：ゼロトラストの位置づけ — 情報セキュリティ全体の中でどこを担うのか

コメントをどうぞ

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つのアプローチを認めている。

アプローチ起点・向き特徴
資産ベース（asset-based）資産を起点に積み上げる（ボトムアップ）資産 → 脅威・脆弱性 → 影響、と評価する。網羅的だが、資産が多いと粒度が細かくなり工数がかかる
イベントベース（event-based）リスクシナリオを起点にする（トップダウン）脅威源・望ましくない事象 → 影響する資産、と評価する。重要シナリオや脅威インテリジェンス・インシデント事例を取り込みやすい

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

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

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

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

ISO/IEC 27005 の資産種別性質ゼロトラストでの扱い
情報主要資産技術資産データ（D）＝守る対象の中核
業務プロセス・活動主要資産—束ねる基準・守る理由（DAASを括る軸）
ソフトウェア支援資産技術資産アプリケーション（A）
ハードウェア・ネットワーク支援資産技術資産資産（A）／通信経路
サービス（DNS・IAM等）支援資産技術資産サービス（S）＝それ自体もプロテクトサーフェス
要員（人）支援資産非技術検証される主体（アイデンティティ）として扱う
拠点（サイト）支援資産技術＋非技術機器は資産（A）／所在地はコンテキスト／建物は範囲外
組織（体制）支援資産非技術ガバナンスが担う（範囲外）

表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つのカテゴリに分けており、非技術の領域が、技術と並ぶ独立したカテゴリとして正面から扱われている。

ISO/IEC 27002:2022 の管理策扱う領域・例主な担い手
技術的管理策アクセス制御・暗号化・ネットワーク・ログ・監視ゼロトラスト（情報資産への防御）
物理的管理策入退管理・施設と装置の保護・電源・災害対策物理セキュリティ
人的管理策教育・訓練・審査・雇用／退職の手続き人事・教育（ZTでは人＝検証主体）
組織的管理策方針・役割と責任・委託先管理・順守ガバナンス（ISO/IEC 27001／27014）

表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「トランザクションフローのマッピング」を扱う。守るべき対象が定まったら、次はそのデータやトランザクションがどこをどう流れているかを可視化していく。

以上

ゼロトラスト実装の5ステップ（NSTACモデル）入門　～　第1回：5ステップの全体像と「プロテクトサーフェスの定義」

6件の返信

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を基に作成）

業務情報システムデータアプリケーション資産サービス
CRMシステム顧客データ（製品・サービス・連絡先・イベント等）CRMアプリ（SaaS）CRM SaaS事業者のCRMサーバー顧客・組織のアイデンティティサービス、DNS
文書リポジトリファイルとメタデータSharePoint OnlineMicrosoftのインフラIDaaS（Azure Active Directory）
決済システムカード会員データ決済処理を行うWebアプリDBをホストするサーバー外部クレジットカード決済処理、DNS
産業制御システム化学プロセスの制御・センサーデータ化学プロセス制御アプリプラントのセンサーとPLCHVAC（空調）
スマートエネルギー計測・課金電力消費量・顧客データ顧客モニタリング・請求システムスマートメータースマートメーター無線ネットワーク

表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「トランザクションフローのマッピング」を取り上げる。守るべき対象が決まったら、次はそのデータやリソースが「どこから来て、どこへ流れているのか」を可視化していく。

以上

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

1件のフィードバック

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（前編）

2件の返信

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

2件の返信

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の実現手段の１つ
策定主体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フレームワークにゼロトラストを採用する方法を考察した理由について説明する。

ゼロトラストは、セキュリティ対策としては適切なものであるが、リスク管理として重要である情報資産の重要性について言及されていない。特定非営利活動法人デジタル・フォレンジック研究会のコラム第８９６号：「ゼロトラストアプローチとリスク論的アプローチ」（https://digitalforensic.jp/2025/10/20/column896/）において佐々木良一 理事（東京電機大学　名誉教授　兼同大学サイバーセキュリティ研究所　客員教授）が以下のように述べている。「ゼロトラストの考え方自体は適切なものであるが、同時にリスクアセスメントを中心とするリスク論的アプローチも併用しないと適切な対策にならない」。リスクについて、上記コラムでは「リスク＝損害の大きさ×損害の発生確率」という工学分野の確率論的リスク評価の定義を使っている。情報セキュリティにおいてリスクは、「リスク＝影響度ｘ発生確率」と表現されるが、概念的には同じであり、ここでは影響の方が損害より広い概念として捉え、「損害の大きさ＝影響度」と捉えることとする。ここで、ゼロトラストは、「損害の発生確率」と結び付けることができるが、「損害の大きさ」（対象システムの重要性）についてはカバーされていない。したがって、ゼロトラストにおいてリスク論的アプローチを併用することが重要であるということになる。 そこで、「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モデルにマッピングしたレポートを作成すれば、短期間で進捗を確認することができます。

以上