シリーズで投稿しました「ゼロトラスト実装の5ステップ（NSTACモデル）入門」、全6回が揃いましたのでここにまとめてリンクを貼ります。
以上
2026年9月4日
ゼロトラストWGリーダー 諸角昌宏
第1回で守る対象（プロテクトサーフェス）を定義し、第2回で流れを可視化し、第3回でアーキテクチャを構築し、第4回でポリシーを作った。これで一通りの実装は終わる。では、なぜまだステップ5「監視と保守」があるのか。答えは、ゼロトラストは「作って終わり」ではないからである。
図1：ゼロトラスト導入の5ステップ。ステップ5は、変化を検知したらステップ1へ戻る「反復」の入口でもある
ステップ5には2つの部分がある。監視（モニター）：防御が正しく働いているか、異常が起きていないかを継続的に確かめることと、保守（メンテナンス）：ポリシーや設定を、変化する環境に合わせて健全に保つことである。以下、順に見ていく。
ステップ5はとかく忘れられがちだが、逆にステップ5から始めてしまう組織も多い。「とにかくログを全部集めて、何か悪いことが起きていないか探す」というやり方、いわゆるMDR的なアプローチである。だが、ログをすべてSIEMやデータレイクに放り込んで、そこから何かを見つけようとするのは骨が折れるうえ、それ自体は“防御”ではない。
MDRは検知と対応（Detection & Response）であって、防御・予防（Prevention）がない。したがって常に後手に回ることが多い。つまり、「侵害されて、どこで何が起きたかは分かったが、すでに侵害されてしまっている」という事態になりやすい。ゼロトラストが目指すのは、侵害はいずれ起きるという前提に立ちながらも、それが実際の被害に広がる前に、できるだけ手前で食い止めることである。まずステップ1〜4で防御を築き、そのうえでステップ5の監視で「まだ健全か、対応が要るか」を確かめる。この順序が肝心である。
ゼロトラストの原則の一つに、「すべてのトラフィックを検査し、記録せよ（inspect and log all traffic）」がある。監視が要であることを示す言葉である。プロテクトサーフェスを小さく切り分けたことで、一つひとつについて「いま何が起きているか」という多くの情報（ログ）が得られる。配置したコントロール（ファイアウォールやEDRなど）が、その動作結果を、こちらに知らせてくれるようになる。
まず、ログとイベントを区別したい。監視で主役になるのはイベントである。
| ログ | イベント | |
| 中身 | 見えたことの記録そのもの | セキュリティ機器が「意味のある出来事」を検知したもの |
| 例 | IP AがIP Bにアクセス／プロセスが起動／ボタン押下 | ブルートフォース検知、マルウェア検知、普段と違う国からのログイン、大量アップロード |
| 扱い | 調査（根本原因の追跡）に使う。全部を長期保存はしない | 監視の主役。1件ずつ検査する。より長く保持できる |
表1：ログとイベントの違い（Threat Talksを基に作成）（注：本ブログで参照しているThreat Talksは、Threat Talks（ON2IT × AMS-IX）の解説動画である）
なお、ここでいう「イベント」は、セキュリティ機器がフィルタして「意味がある」と判定したものを指す（無害な状態変化のログは含まない）。一般的な情報セキュリティの用語では、サービスの起動・停止や設定変更といった無害な状態変化も含めて「イベント」と呼ぶ、より広い使い方をすることが多い。本稿では、そのうち監視の対象として意味を持つものに絞って「イベント」と呼んでいる。
トラフィックのログをすべて7年間も保存する必要はない（保存コストばかりかさむ）。一方、セキュリティ機器が検知したイベントは、1件ずつ確かめる価値がある。ログは、イベントが起きたときに根本原因をたどるための材料として効いてくる。
ここでステップ1が効いてくる。ファイアウォールのイベントは、そのままではIPアドレスしか教えてくれない。だが、そのIPが「どのプロテクトサーフェスか」に翻訳できれば、第1回で記録したメタデータ（所有者・重要度・扱うデータ）が結びつき、「Active DirectoryからCRMへのアクセス」といった業務の文脈が見えてくる。
同じイベントでも、文脈が違えば対応が変わる。たとえば「ブルートフォース攻撃をブロックした」という同じイベントでも、インターネットから顧客向けWebへの攻撃ならよくあることでブロック済みなら無視してよいと考えられる。しかし、もしそれが社内のActive Directoryから発生していたら、たとえブロックされていても調査すべきである。すでに誰かが侵入して横移動を試みているのかもしれない（あるいは、サービスアカウントのパスワード期限切れによる誤検知かもしれない）。いずれにせよ、起きてはならないことなので確かめる必要がある。
では、大量のイベントをどうさばくか。有効なのは、イベントを3つに振り分ける考え方である。文脈を足すことで、この振り分けができる。
図2：イベントに文脈を足して、IoG／IoC／Unknown に振り分ける（Threat Talks「監視」回を基に作成）
多くのツールは、機器が出す「中身（コンテンツ）」だけを見るため、良い判断が難しい。ゼロトラストは、ここにステップ1の文脈を足せる点が強い。おすすめしたいのは、「ログを全部ためて、その中から怪しいものを拾う」のではなく、機器が出すイベントを1件ずつ、順に検査していくという発想である。コントロールはそれぞれ意味があって置かれているものなので、本来は良いイベントを上げてきてくれるはずである。もし何も上がってこないようなら、ツールの選び方や設定を見直すサインかもしれない。イベントの数は膨大になるため自動化が前提になるが、その自動化を支えるのが、いま述べた文脈「そのイベントがどのプロテクトサーフェスのものか（所有者・重要度・扱うデータ）」という背景情報である。同じイベントでも、文脈があれば振り分けやすくなるが、なければ判断がつきにくい。AIも助けにはなるが、この文脈を与えて初めて、より的確に働いてくれると思われる。
振り分けの先には、対応の自動化（Rules of Engagement）がある。プロテクトサーフェスの重要度に応じて、どこまで自動で対応するかを決めておく。たとえば、ERPのような重要なプロテクトサーフェスで、EDRがランサムウェアだと判定したプログラムが動き出したら、そのプロテクトサーフェスをネットワークから隔離（キルスイッチ）して影響範囲（ブラスト半径）を抑える。
この隔離は、完全に自動化することも、人が承認する形にすることもできる。確度の高い脅威（明らかなIoC）で、かつランサムウェアのように広がる速度が速いものは、人の判断を待つ時間自体が被害を広げてしまうため、全自動で即座に遮断する運用が現実的である。一方、誤検知の影響が大きい場面などでは、自動化が「これを実行してよいか」という提案だけを整え、SOCが承認ボタンを押して実行する中間形（半自動）も取れる。どちらか一方に決める必要はなく、全自動が不安なら、まず承認を挟む形から始め、信頼度が上がったら段階的に自動化を広げる、という進め方もできる。ただし承認を待つ間にもランサムウェアは広がるため、承認フローを選ぶ場合でも、できるだけ素早く判断できる体制にしておく必要がある。
そして基本姿勢は防御優先（prevention first）である。IPS等は検知モードではなくブロックモードで使う。最良の対応ルールは「防いでブロックする」ことであり、最悪は「侵害されてから原因を探す」ことである。ブロックできたら、その結果をイベントとして受け取り、検査する。
あるプロテクトサーフェスを丸ごと遮断しようとすると、実はネットワークが十分に分離されておらず、「遮断したらネットワークの半分が止まる」と判明することがある。この予期しない巻き添えの大きさ（ブラスト半径の大きさ）は、次の2つのどちらか、あるいは両方が不十分だったことを教えてくれる。
つまり、「これを止めたら他も止まる」と分かった瞬間は、分けたつもりで実は分かれていなかったことの証拠であり、実地で見落としを発見できる機会でもある。だからキルスイッチの検討は、なぜプロテクトサーフェスをきちんと分けるべきかを組織に示す良い材料にもなる。
監視と並ぶもう一つの柱が保守である。作った防御は、放っておくと質が下がっていく。それに抗う仕組みが保守である。主な観点は次のとおりである。
ここでいうポリシーは、いわゆる情報セキュリティ方針のたぐいのものではなく、実際に機器で動いている運用ポリシー、つまりファイアウォールのアクセス規則、EDRの設定などである。とくにファイアウォールでは、新しいアクセスは足されるが、不要になったアクセスは消えずに残りがちである。サーバーを撤去しても何も壊れないので誰も申告せず、「壊すのが怖い」ため規則は何年も放置される。今はネットワークセキュリティポリシー管理（NSPM）ツール（Tufin、AlgoSec、FireMon など）や、ファイアウォール自体に組み込まれた分析機能（例：Palo Alto NetworksのPanoramaが持つセキュリティポリシーオプティマイザ）を使えば、使われていない・重複した規則を検出できるので、変更のたび（少なくとも定期的）に、ポリシーが今も正しいかを点検する。ログが無効になっていないか、EDRでディスク全体をスキャン除外していないか、消し忘れの一時規則がないか、構成管理に近い実際に動いている設定の点検である。
ファイアウォール等は、クラウド経由で自動更新される。シグネチャだけでなく、新機能が配信されることもある。典型的なのは、新しいURLカテゴリ（例：登録されたばかりのドメイン）の追加である。ところがベンダーは、更新で通信を突然止めて障害を出さないよう、新機能を既定で「許可（＝素通り）」にして配信することが多い。そのため多くの人が新機能に気づかず、有効化しないまま眠らせてしまう。すでに料金を払っている機能なので、更新のたびに点検し、そのプロテクトサーフェスに使えるものは有効化する。機器を新調したときも、古い設定をそのままコピーせず、新機能を評価し直すことが必要である。
第2回で「どのプロテクトサーフェス同士が通信してよいか」を（業務オーナーの合意のもとで）定義した。運用フェーズでは、定義したフローと、実際に観測されるフローを突き合わせる。定義したのに見えないフローがあれば、ステップ2の誤りか設定ミスを疑う。逆に、定義していないのに流れているフローがあれば、なぜかを調べる。つまり、正当なものか、それとも横移動の兆候かである。ステップ2〜4を正しくやれていれば、本来ここはきれいに一致するはずで、ずれはこれまでの仕事を検算する良い機会になる。
ここで、監視の節との関係を整理しておきたい。両者は矛盾しているように見えて、実は役割が異なる、補完し合う仕組みである。
つまり、「全部のログを人間が精査する」というやり方には、どちらの仕組みでも戻らない。同じログという材料を、機器が1件ずつその場で判定する（イベント検査）か、機械学習が蓄積してから傾向として判定する（挙動分析）かの違いであり、いずれも人間が最終的に目にするのは、絞り込まれた結果だけである。
挙動分析が拾えるのは、単発のイベント検査では見えない、じわじわとした変化や、複数の小さな兆候の積み重ねである。やり方は、ログをXDR（あるいは次世代SIEM・SIEM 2.0とも呼ばれる仕組み）に集約し、機械学習にかける。すると「自分たちの環境では、ふだんこういう挙動が普通だ」という平常時の姿（ベースライン）を学習できる。そのうえで、ベースラインと大きくかけ離れた挙動、つまり普段と違う量・普段と違う相手・普段と違う時間帯のトラフィックなどが現れたら、アラートを上げる。
ただし、誤検知（false positive）が多くなりやすいという弱点も認識しておきたい。たとえば小売業なら、繁忙期（セール・年末商戦など）に通信量が跳ね上がるのは正常な変化だが、対策をしていなければベースラインから外れた「異常」として大量にアラートが出てしまう。同様に、システムの一部がフェイルオーバー（切り替え）しただけでも、普段と違うトラフィックパターンとして検知され、誤検知につながりやすい。
こうした誤検知を抑えるには、季節性やイベントごとの例外をあらかじめ調整しておく必要があり、ある程度の運用の作り込みが求められる。そのため挙動分析は、監視・保守の他の要素（イベントの振り分け、ポリシー検証、フロー突合）が一通り運用に乗ってから取り組む、成熟度の高い最後の一手として位置づけるのが現実的であると考える。
クラウド移行、VMからコンテナへ、オンプレのKubernetesからクラウドへ、サービスメッシュのサイドカー廃止など、こうしたアーキテクチャの変化は、可視性を変えてしまう。たとえばサイドカーがあれば見えていた通信が、廃止で見えなくなる。ネットワーク的には分離しているつもりでも、すべてが一つのプラットフォームに集約されれば、もはや分離ではなくなる。
怖いのは、クラウドチームが移行を進め、ネットワークチームが気づかないうちに「見えなくなる」ことである。監視で「これまで見えていた2つのプロテクトサーフェス間の通信が、急に見えなくなった」と気づいたら、それは大きな合図である。こうした変化を検知したら、ステップ1に戻ってやり直す。5ステップは反復であり、ステップ5は次の反復の引き金である。ただし大枠はできているので、多くの場合は所有者や一部のコントロールなど、変わるのはわずかな部分だけである。だからこそ、ゼロトラストの考え方をCISOの上まで含め、組織のあらゆる層に根づかせ、開発者が「クラウドネイティブな機能を使うと、セキュリティに影響するかもしれない」と気づける状態にしておくことが大切になる。
最終回では、作った防御を健全に保つステップ5を扱った。要点は次のとおりである。
そして、ここまでの5ステップを、最初から全システムに広げる必要はない。第1回で示した「練習台から本命へ」がここでも効いてくる。まずは重要度の低い1つのプロテクトサーフェスで、定義・可視化・構築・ポリシー・監視保守という一連の流れを小さく回してみる。そこで運用を成熟させ、勘所をつかんでから、優先度の高いシステムへと広げていく。小さく始めて、回しながら育てるのが、5ステップを無理なく定着させる進め方である。
プロテクトサーフェスを定義し（1）、流れを可視化し（2）、アーキテクチャを構築し（3）、ポリシーを作り（4）、監視と保守で守り続ける（5）。そして、環境が変われば、また1に戻る。ゼロトラストは、一度きりのプロジェクトではなく、回し続ける取り組みである。この5ステップという実践的な地図があれば、その歩みを、着実に、そして繰り返し進めていける。全5回（＋第1.5回）にわたる本シリーズを、実装の一助としていただければ幸いである。
以上
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：プロテクトサーフェス、トランザクションフロー、 ポリシー
一言でいえば、守る対象（プロテクトサーフェス）への、実際の使われ方（トランザクションフロー）を、ポリシーとして書き下ろす、という関係である。だから、ステップ2のフローのマッピングが甘いと、ステップ4のポリシーも甘くなる。必要なアクセスを漏らして業務を止めるか、余計なアクセスを許してしまう。フローの精度が、そのままポリシーの精度になる。
ここで、ポリシーをめぐる3つの役割を、時間軸で分けて押さえておきたい。ここは混同しやすいところである。
つまり、第3回で「PDPは様々なデータソースから情報を得る」と述べたのは、PDPがポリシーを作っているのではなく、人間が作った登録済みポリシーを評価するために、その場の状況を集めている、という意味である。ポリシーを作るのは人間（ステップ4）、それを状況に照らして判断するのがPDP、判断を強制するのがPEP。この切り分けを押さえると、「PEPがPDPの判断に従って実行する」と「PDPは様々なソースから情報を得る」が、どちらも実行時の同じ動きを指していることが分かる。
では、ポリシー文はどう書くのか。ここで用いるのがキプリングメソッドである。作家ラドヤード・キプリングの「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 | 与信審査という業務上の必要 | 決済処理に必要な参照 |
| How | MFA＋準拠端末、セッション短時間・再評価 | mTLS＋最小権限（該当レコードのみ） |
表2：キプリングメソッドによるポリシー文の例（クレジットカードのプロテクトサーフェス）
例1は「引受担当者が、社内の管理端末から、営業時間内に、与信審査のために、MFA付きで引受審査アプリを使う」という一文に相当する。例2は「決済アプリのワークロードが、取引処理中に、mTLSで、カード会員データの該当レコードだけを読む」という一文である。この条件を満たさないアクセスは、すべて拒否される。
同じ要領で、外部SaaSを使う人（営業担当）と、非人間（ATM）の例も書ける。
| 問い | 例3：営業担当 → CRM（人・外部SaaS） | 例4：ATM → 決済取引（非人間） |
| Who | 役割＝営業担当 | 登録済みATM（証明書で識別） |
| What | 顧客訪問の記録をCRMに登録する | 現金引き出しの決済取引を実行する |
| When | 営業時間内 | 営業時間内 |
| Where | 自宅可（外出先）だが会社支給端末・SASE経由 | 登録拠点のATM網からのみ |
| Why | 訪問記録という業務上の必要 | 利用者の引き出し要求に応じる |
| How | SASE経由＋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はその実行場所である、という点がここでも確認できる。
「配置したPEPが、PDPの判断に従ってポリシーを実行する」を、実際の1回のアクセスで具体的に追ってみる。人（引受担当者）と非人間（決済アプリ）の2本を並べると、判断材料（データソース）が違っても、流れは同じであることが分かる。
図4：1回のアクセスが実行される流れ（人・非人間の2例）
【人】引受担当者が引受審査アプリにアクセスする1回：
【非人間】決済アプリがカード会員データを読む1回：
もし人間が同じカード会員データに直接クエリしようとすると、②〜⑤で条件（SA・mTLS・想定経路）を満たさないため、⑥のPEPで拒否される。同じデータでも、正規のワークロード経由なら通し、それ以外は止まる。これが「ポリシーをPDPが評価し、PEPが実行する」の具体像となる。
第3回で見たCBAC（コンテキストベースアクセス制御）と、このステップ4は表裏一体である。キプリングメソッドで書いた5W1Hが、そのままCBACの評価属性になる。Whoは主体の役割、Whereは場所・ネットワーク、Whenは時間、Howは技術的統制。これらをPDPのポリシーエンジンが評価し、PEPが強制する。つまり、ステップ4で「ルールを言葉で定義」し、ステップ3のアーキテクチャで「そのルールを実行」する、という関係になる。
ポリシー作成で、とりわけ慎重に扱うべきなのが管理者（特権）アクセスである。管理者は多くのシステムに広くアクセスできるため、攻撃者にとって格好の標的であり、ひとたび乗っ取られると内部を横移動され、影響範囲が一気に広がる。だからこそ、通常ユーザー以上に厳格なポリシーを敷く。CSA文書も特権アクセスの制御を重要な統制として挙げている。ここでも、ステップ1〜4の流れがそのまま効いてくる。
狙いは、万一、踏み台が侵害されても攻撃者に何もさせないこと、つまりデータを持ち出せず、指示（マルウェア等）も送り込めない状態にする。そして、踏み台にアクセスする全員を監査する。この監査こそ、次回のステップ5（監視と保守）につながる。なお、いまは管理用アカウントを分ける組織は増えたが、依然としてインターネットにつながる普段の端末から管理作業をしている例が多く、ここは改善の余地が大きい。
ステップ4は、アクセスポリシーを定義するだけではない。CSA文書は、ステップ4の活動にインシデント検知・対応メカニズムの構築も含めている。ポリシーに反するアクセスや、正常な動作からの逸脱を検知したら、アラートを上げ、遮断や再認証などの対応につなげる。第2回でマッピングしたトランザクションフローが「正常の基準」となり、そこからの逸脱が検知の手がかりになる。
「ポリシー」と聞くとファイアウォールのルールを思い浮かべがちだが、ゼロトラストポリシーの適用先はそれだけではない。ステップ3で選んだ各コントロールに、それぞれポリシーを与えて初めて機能する。
| 適用先 | クレジットカードでの具体例 | 狙い |
| SaaS／SASE | 規制報告の提出ポータルや営業のCRMを、SASEで自社経由に集約し、SaaS側は『自社経由のみ許可』 | 外部からの直接アクセスを排除 |
| エンドポイント（XDR） | カード会員データを扱うサーバーと引受担当者端末に、ランサム防御を有効化＋DBに触れるアプリを許可リスト化 | 端末・サーバー側で不正を遮断 |
| IdP（条件付きアクセス） | 引受担当者は社内／VPN＋管理端末＋営業時間＋MFAでのみログイン可。私物・深夜・国外は追加認証／拒否 | ログインの入口を状況で絞る |
表5：ポリシーの適用先と、クレジットカードでの具体例
すべてに共通する原則は、具体的であること、そして業務上の正当性があることである。「全員がインターネットへ」のような広すぎるルールは避ける。理由（業務上の必要）がないポリシーは、そもそも作らない。
ポリシーは作って終わりではない。むしろ検証（見直し）こそ最も見落とされがちな工程である。新しいアプリを動かすためにルールを足すのは自然に起きるが、アプリが廃止されてもルールは自動では消えないし、誰も困らないので放置され、ポリシーが腐敗（decay）していく。検証では、少なくとも次を確認する。
この見直しは、5ステップを一度で終わらせず、繰り返し回していくことの一部でもある。業務オーナーの交代はステップ1、新たな通信要望はステップ2、新しいコントロールの必要はステップ3と、変化に応じて各ステップに戻る。ポリシーが「最初は静的でも、運用しながら動的に育つ」のは、この反復があるからである。まず1つのプロテクトサーフェスで作り込み、成熟させてから次へ広げる、という「練習台から本命へ」の考え方（第1回）も、ここで効いてくる。
第4回では、配置したPEPにルールを与えるゼロトラストポリシーを作るステップ4を扱った。要点は次のとおりである。
守る対象を定め（1）、流れを可視化し（2）、アーキテクチャを構築し（3）、ポリシーを作った（4）。最終回（第5回）は、ステップ5「監視と保守」を扱う。すべてのトラフィックをアプリケーション層まで検査・記録し、そのテレメトリを使って、プロテクトサーフェスを継続的に強くしていく。ゼロトラストを「作って終わり」にしないための最後のステップである。
以上
2026年8月29日
ゼロトラストWGリーダー 諸角昌宏
第1回で守る対象（プロテクトサーフェス＝DAAS）を定義し、第2回でその周りのトランザクションフローを可視化した。守るものと、その動きが見えたら、次はいよいよ実装である。ここでは、ステップ3「ゼロトラストアーキテクチャの構築」を扱う。
図1：ゼロトラスト導入の5ステップと、本ブログが扱うステップ3（CSA文書の5段階プロセスを基に作成）
ステップ3のねらいは、第2回でマッピングしたトランザクションフローを基盤に、ポリシー実施ポイント（PEP）を適切に配置したゼロトラスト環境を設計することである。「誰が・何に・どんな状況でアクセスできるか」を、各プロテクトサーフェスの出入口で実際に検証・制御できる形に落とし込んでいく。
アーキテクチャを設計する前に、拠り所となる原則を確認しておく。ゼロトラストは、次のような考え方に立っている。
これらを設計に落とすと、次の原則になる。認証・認可が済むまでアクセスを与えない（パケット1つに至るまで検査）／アクセスは一時的で再検証が必要／最小特権（必要最小限のアクセスだけを付与）／コントロールの有効性を継続的に監視する。
アクセスの可否を判断するには、まず3つの中核要素、通信（アクセス要求）・アイデンティティ（要求する主体）・リソース（守る対象）が必要になる。さらに、判断を支える2つの要素として、ポリシー（誰が・何に・いつ・どのようにアクセスできるかを定める規則）と、データソース（ポリシーを動的に更新するための状況情報）がある。
NIST SP 800-207 は、これを2つの仕組みで表現している。判断を下すPDP（ポリシー定義ポイント）と、それを実際に強制するPEP（ポリシー実施ポイント）である。両者はトラフィックのアクセス経路上に置かれ、リソースへのアクセスを制御する。
図2：ゼロトラストアーキテクチャの中核（PDP／PEP）（NIST SP 800-207 の論理モデルを基に作成）
PDPの判断は、多様なデータソースから供給される状況情報（コンテキスト）に支えられる。IdP／Active Directory、IDS／IPS、脅威インテリジェンス、PKI（証明書失効リスト）、資産・デバイス管理（CDM＝継続的診断・対策など、資産のOS・ソフト構成や脆弱性・健全性を継続的に把握する仕組み）、SIEM、法令・規制要件などである。これらの情報が豊富なほど、より的確なアクセス判断ができる。
なお、ゼロトラストではPEPの数が大幅に増えるため、アクセスモデルを手作業で管理するのは現実的でない。自動化が、細かな制御と全体制御の両立に不可欠となる。
PDP／PEPという骨格の上に、以下のようなゼロトラストらしさを与える具体的な設計要素を組み込んでいく。
ネットワークをより小さな独立したセグメントに分割し、ワークロードやアプリ、デバイス単位で境界（マイクロペリメータ）を設ける。トランザクションフローの理解に基づいて論理的にグループ分けすることで、万一侵入されてもラテラルムーブメントを封じ込め、アタックサーフェスを縮小できる。
アクセス判断は静的ではなく、動的かつ状況依存で行う。ユーザーのアイデンティティ、デバイスの状態、場所、実行中のトランザクションといったコンテキストを評価して、その都度アクセスの可否を決める。第2回でマッピングしたトランザクションフローが、この判断材料になる。
役割やアプリに不可欠なトランザクションだけを許可し、タスクの実行に必要な最小限のアクセスに制限する。トランザクションフローマッピングは「正常な動作の基準」を与えるため、そこからの逸脱や異常を検知し、アラートや対応につなげられる。
通信・データを暗号化して保護する。あわせてデータ損失防止（DLP）で機微情報の持ち出しを防ぐが、暗号化された状態では中身を検査できないため、DLPは平文が現れる地点のエンドポイントや、通信を復号する検査ポイントで効かせる。また、集中型のログ記録と、SIEMによるリアルタイムのモニタリング・相関分析を導入し、コントロールの有効性を継続的に監視する。
ゼロトラストアーキテクチャを実際に実現する方式には、代表的なものがいくつかある。いずれもPDP／PEPという共通の土台の上に立ち、相互に影響し合ってきた。用途に応じて選び、組み合わせることになる。
| 実装パターン | 特徴 | 主な用途 |
| SDP | 接続を事前検証（SPA等）し、認証・認可されるまで既定で全拒否。リソースを外部から隠す | リソースの隠蔽、境界の動的生成 |
| ZTNA | SDPとほぼ同じ発想。ユーザーとアプリのアクセスを検証し、必要なアプリだけに接続を許す | リモートアクセス、VPN置き換え |
| BeyondCorp | Googleが自社向けに実装。所在地を信頼せず、デバイスとユーザーの状態で判断 | リモートアプリアクセス |
| NISTアプローチ（SP 800-207） | PDP／PEPを中核とする論理アーキテクチャ。各方式に共通する土台 | 設計の基本モデル |
表1：代表的なゼロトラストアーキテクチャの実装パターン
ゼロトラストアーキテクチャは、プロテクトサーフェスごとに、その出入口（マイクロペリメータ）へPEPを配置して設計する。第2回でマッピングした「どの主体が・どの経路で・どのDAAS要素にアクセスするか」を、そのままPEPの配置とポリシーに写し取るイメージである。
第1回・第2回で用いたクレジットカードサービスの例で示すと、次のようになる。
図3：クレジットカードのプロテクトサーフェスにPEPを配置する（CSA文書を基に作成）
顧客・営業担当・ATMからの入口、アプリとカード会員データの間、そして信用調査機関・規制報告・住宅ローン／預金といった外部・他システムとの接続点、それぞれにPEPを置き、マッピングしたフローに沿ったアクセスだけを許可する。組織によっては、まず粗い粒度のマクロセグメンテーションから始め、時間をかけてマイクロセグメンテーションへ進めるのが現実的な場合もある。
ここまでの図は、役割（誰が判断し、誰が強制するか）を示す論理アーキテクチャである。では、これを実際の構成に落とすと何になるのか。ポイントは、論理的な役割を具体的なコンポーネント（製品・機能）に割り当てることである。
そして、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を使ってアーキテクチャの実装をもう少し具体化してみる。CSAのSDPは、特定製品に依存しない標準仕様として構成要素が定義されており、ベンダーニュートラルな実装例として分かりやすい。SDPは次の3つの要素からなる。
これらを、クレジットカードサービスのプロテクトサーフェスに当てはめると、次のような構成になる。
図5：SDPによるベンダーニュートラルな実装例
顧客がカードWebアプリにアクセスするのは、次の順でつながる。
ポイントは、認証・認可がすべて“接続の前”にコントロールプレーンで済むこと、そして許可されるまでリソースが存在すら見えない（ドロップオールで不可視）ことである。これにより、正体不明のトラフィックはそもそもリソースに到達できず、アタックサーフェスが大きく縮小する。コントローラ＝PDP、AH＋ゲートウェイ＝PEP、という役割対応も、この例で明確である。
なお、ここで挙げたIH・AH・コントローラ・SPA・mTLS・ドロップオールはいずれもSDP仕様の用語であって特定製品名ではない。実際には、SDP・ZTNA・BeyondCorpといった枠組み（コントローラ＝PDP、ゲートウェイ／プロキシ＝PEP）のいずれかを土台に選び、そこへIdPやEDRといったデータソースを接続して実装する。
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 のトラストアルゴリズムを基に作成）
クレジットカードの例で、引受担当者が引受審査アプリにアクセスする場面のポリシーを、擬似的に書くと次のようになる。
重要なのは、この判断が一度きりではないことである。セッションの発行後も継続的に再評価し、途中で端末が非準拠になったり、リスクが上昇したりすれば、その場でアクセスを失効させる。これが「常に検証する」を実装レベルで成り立たせる仕組みであり、静的なRBACとの決定的な違いである。
なお、トラストアルゴリズムには、条件をすべて満たすかで判断する基準ベース（criteria-based）と、各属性に重みをつけてスコアで判断するスコアベース（score-based）がある。またリソースごとに独立して判断するか、主体の直近の行動履歴まで加味する（コンテキスト型）かでも設計が分かれる。組織のリスク許容度に応じて選ぶことになる。
CBACの勘所は、同じ人でも状況で結果が変わる／人間とワークロードで扱いが違うことにある。クレジットカードの例で、リソースごとにポリシーを並べると、その違いが具体的に見えてくる。
| リソース | 状況（コンテキスト） | 判定 | 備考 |
| 引受審査アプリ（内部・機微） | 引受担当者＋管理端末（準拠）＋社内／VPN＋MFA＋低リスク | 許可 | セッション短時間・再評価 |
| 引受審査アプリ | 同じ担当者だが私物端末・自宅から | step-up＋読取のみ | 権限を状況で縮小 |
| カード会員データ（最重要・PII） | 決済アプリのサービスアカウント＋mTLS＋想定経路 | 許可（該当レコードのみ） | 正規ワークロード |
| カード会員データ | 人間ユーザーが直接クエリ／大量エクスポート | 拒否＋アラート | アプリ経由のみ許可 |
| カード申込（外部・B2C） | 顧客＋MFA＋既知デバイス＋低リスク | 許可 | — |
| カード申込 | 新規デバイス／不可能移動（地理的に不自然） | step-up（追加認証） | — |
| ATM（非人間） | 登録済みATM＋証明書＋EMV認証＋営業時間内 | 許可（限度内） | — |
| ATM | 証明書失効／未登録端末 | 拒否 | — |
表3：クレジットカードの各リソースに対するCBACポリシーの例
同じ「引受担当者」でも、管理端末・社内なら通し、私物・自宅なら追加認証のうえ読み取り拒否だけに絞る。カード会員データは、正規のワークロード（決済アプリ）からは許可するが、人間の直接アクセスや大量エクスポートは拒否する。誰か（役割）だけでなく、どこから・どの端末で・どんなパターンかまで見て判断するのがCBACである。
では、こうしたポリシーを実際に動かすのは何か。CBACは単一の製品ではなく、次のような技術・仕組みの組み合わせで実装される。
実装の型としては、判定を毎回外部のポリシーエンジンに問い合わせる型（PEP↔PDP分離）と、各サービスにポリシーを配布して手元で評価する型（サイドカー等）がある。前者は一元管理しやすく、後者は低遅延で大規模な環境に向いている。いずれも「属性を集め、ポリシーで評価し、動的に判定し、継続的に再評価する」という流れは同じである。
なお、ここで挙げたXACML・OPA・条件付きアクセス・UEBAなどは実装手段の代表例であり、特定製品の推奨ではない。自組織の環境（クラウド／オンプレ、コンテナの有無など）に応じて選択、および組み合わせることになる。
ゼロトラストアーキテクチャは、既存の仕組みを一度に置き換える「入れ替え」ではなく、段階的な移行として進める。次のような考え方が必要である。
実装後は、トランザクションフローに照らしたアーキテクチャのレビュー、テスト、継続的改善を回していく。ここは次回のステップ4・5（ポリシー、監視と保守）にもつながる。
第3回では、マッピングした流れを土台に、ゼロトラスト環境を設計するステップ3を扱った。要点は次のとおりである。
守る対象を定め（ステップ1）、流れを可視化し（ステップ2）、アーキテクチャを構築した（ステップ3）。次回（第4回）は、ステップ4「ゼロトラストポリシーの作成」を扱う。配置したPEPに、実際にどのようなルール（誰に・何を・どの条件で許すか）を持たせるか。アクセスポリシーを具体的に定義していく。
以上
2026年8月25日
ゼロトラストWGリーダー 諸角昌宏
第1回では、ゼロトラストの出発点である「プロテクトサーフェスの定義」を扱い、守るべき対象をDAAS（データ、アプリケーション、資産、サービス）として業務単位で束ねる考え方を扱った。守る対象が定まったら、次は何をするか。それが本編のステップ2「トランザクションフローのマッピング」である。
図1：ゼロトラスト導入の5ステップと、本稿が扱うステップ2（CSA文書を基に作成）
ステップ2のねらいを一言でいえば、プロテクトサーフェスの周りを、データやトランザクションがどこをどう流れているかを可視化・文書化することである。これにより、業務システムが実際にどう動くかを理解し、後続のステップ3（アーキテクチャ構築）とステップ4（ポリシー作成）でコントロールをどこに置くかを判断できるようになる。ここでは、CSAが公開した「ゼロトラストのためのトランザクションフローのマッピング」（以降、CSA文書と略称）の内容を元に説明する。
トランザクションとは、アプリケーションやサービスを通じたデータへのインターフェースであり、データの取得・処理・移動・永続化を含んでいる。ここでいうトランザクションフローは、金融取引や特定の機密情報だけを指すのではなく、あらゆる情報・データのフローを意図している。データは複数のプラットフォーム・サービスプロバイダ・地理的領域・ユーザーを横断して流れるため、その全体像を捉えるのは複雑な作業になる。
ステップ2で理解・文書化するのは、たとえば次のような事項である。
これらを可視化・文書化することで、組織は次のような知見を得られる。いずれも後続のステップに直接つながる。
CSA文書は、ステップ2の活動を次のように整理している。ステップ1で作った「守る対象の一覧」を、動きの面から検証・精緻化していくイメージである。
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文書 基に作成）
マッピングの進め方は、環境によって大きく異なる。クラウドでは、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を扱った。要点は次のとおりである。
守る対象が定まり、その周りの流れが見えたら、次はいよいよ実装である。次回（第3回）は、ステップ3「ゼロトラストアーキテクチャの構築」を扱う。マッピングしたトランザクションフローを基盤に、ポリシー実施ポイント（PEP）を配置し、マイクロセグメンテーションやコンテキストベースのアクセス制御、最小特権を設計していく。
以上
「ISO/IEC 27017:2026役割の位置付けと管理策の変更点」を公開しました（2026年8月18日）。本書は、2026年7月30日にガイダンスWGが公開した「ISO/IEC 27017:2026 における役割の位置付けと管理策の対応関係」V1.1に「管理策別 変更点一覧」を追加し、新たにV2.0として公開したものになります。
本書は、2026年7月27日に公開されたISO/IEC 27017:2026について、以下の2つを扱っています。第1に、CSU（クラウドサービスユーザー）、CSN（クラウドサービスパートナー）、およびシステムインテグレータ（SIer）の位置付けと、新設管理策5.39の内容を整理します。第2に、ISO/IEC 27017:2015からの変更点を、クラウドサービス固有の手引きについて管理策単位で示し、その背景を分類します。なお、本書はISO/IEC 27017:2026及びISO/IEC 27017:2015を参照して作成した独自の分析・要約文書であり、両規格の発行元とは無関係です。両規格本文の複製を目的とするものではなく、変更点の要約及び分析にとどめています。正確な文言及び規格の全体構成を要する場合は、正規の販売経路から購入し、使用許諾を得た規格書原本を参照してください。
資料はこちらからダウンロードしてください。
本資料の内容についてのコメントをこちらのブログに書き込んでください。
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:2022 は、リスク特定の方法として資産ベース（asset-based）とイベントベース（event-based）の2つのアプローチを示している。両者は排他的なものではなく、リスクシナリオの構築において組み合わせて用いることができる。本ブログでは、ゼロトラストのプロテクトサーフェスとの関係を説明しやすい資産ベースの捉え方を軸に取り上げる。
ISO/IEC 27005 は、守るべき資産を2種類に分けて捉える。
ここで大切なのは、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 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のゼロトラスト成熟度モデル（ZTMM）は、ゼロトラストを5つの柱（アイデンティティ、デバイス、ネットワーク、アプリケーションとワークロード、データ）と、それらを横断する機能（可視化と分析・自動化とオーケストレーション・ガバナンス）で表している。これは本ブログの整理とよく噛み合うと考えられる。なお、以下に示すDAASとの対応づけは、CISA ZTMMが定める公式な1対1の対応ではなく、概念上の整理である点に留意してほしい。
ゼロトラストは、組織の情報セキュリティ全体の中でどこを担うのか——この回の答えは次のとおりである。
したがって、「ゼロトラストは何のためにやるのか」への答えは、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ステップである「プロテクトサーフェスの定義」を掘り下げる。
ゼロトラストは、2010年にForrester ResearchのアナリストだったJohn Kindervag氏が提唱した戦略である。その根底にあるのは「決して信頼せず、常に検証する（never trust, always verify）」という考え方である。ネットワークの内側か外側かにかかわらず、あらゆる接続を暗黙に信頼しないことを前提とする。従来の「城と堀」型、つまり境界の内側を信頼するアーキテクチャは、資産やユーザーがもはや「城」の中に収まっていない分散・クラウド・リモートワークの時代には通用しない、というのが出発点である。
重要なのは、ゼロトラストが特定の製品ではなく「戦略」だという点である。技術は時代とともに変わるが、戦略そのものは変わらない。「製品を1つ買えば終わり」というものではなく、組織として段階的に作り上げていくものである。 この戦略を「どう実行するか」を5つのステップに落とし込んだのが、NSTACの報告書「Zero Trust and Trusted Identity Management」で示された実装プロセスである。
ゼロトラスト実装プロセスは、次の5ステップで構成される。
このプロセスで押さえておきたいのは、一度きりで完結するものではなく、反復的（iterative）に回していくものだということである。1つの対象に対して5ステップを一巡させ、セキュリティ・ポスチャを一段引き上げたら、次の対象へ。これを繰り返すことで、組織全体のゼロトラスト化を「少しずつ、無理なく」進めていく。
図1：ゼロトラストは「プロテクトサーフェス→トランザクションフロー→アーキテクチャ構築→ポリシー→モニタリング」を回す反復サイクル
なぜ「アタックサーフェス」ではなく「プロテクトサーフェス」なのか
従来のセキュリティは、攻撃を受けうる範囲、すなわちアタックサーフェス（攻撃対象領域）全体を守ろうとしてきた。しかしアタックサーフェスは、クラウド化やリモートワークの進展とともに際限なく拡大し、組織が正確に把握しきることは事実上不可能である。「すべてを守る」は、裏を返せば「どこも守りきれない」になりかねない。
そこでゼロトラストは発想を逆転させる。攻撃される範囲全体を追いかけるのではなく、本当に守るべきものは何かに焦点を絞る。この「本当に守るべきもの（DAAS要素）だけを対象とした領域」がプロテクトサーフェス（保護対象領域）であり、ゼロトラストポリシーによって保護される、組織の技術環境の一部分を指す。 プロテクトサーフェスの優れた点は2つある。1つは、アタックサーフェスよりも桁違いに小さいこと。もう1つは、常に把握可能（knowable）であることである。アタックサーフェスの全体像は誰にも描けなくても、「自社にとって最も重要な資産は何か」は、調べれば必ず分かる。
Protect Surface is much smaller and more knowable than the Attack Surface.（プロテクトサーフェスは、アタックサーフェスよりもはるかに小さく、はるかに把握しやすい。）
— John Kindervag
従来のセキュリティは、いわば「インターネット側にいる攻撃者」を見て、その攻撃を防ぐことに注力してきた。ゼロトラストはこの視点を反転させ、攻撃者ではなく「自分が何を守りたいのか」を起点に考える。攻撃の手口は無数にあり追いきれないが、守るべき対象は有限であり、必ず見定められる。では、何を守るべきか。その中身を整理する手がかりが、次に述べるDAASである。
守るべき対象「DAAS」
では、何をプロテクトサーフェスとして定義すればよいのか。その手がかりが、4つの頭文字をとったDAASである。
DAASは、何かを厳密に分類するための枠ではなく、「データ・アプリケーション・資産・サービス」という4つの切り口で自社を見渡し、守るべきものを洗い出すための着眼点である。だから「DNSはアプリケーションかサービスか」といった分類に頭を悩ませる必要はない。大切なのは、一歩引いて全体を見渡し、業務にとって意味のあるまとまりを見つけることである。ゼロトラストは個々のサーバーだけを単独で守る発想ではなく、業務上意味のある単位（プロテクトサーフェス）を起点に保護を設計する。
具体例：架空の金融サービス組織の「決済システム」
CSAの文書は、架空の金融サービス組織を例として用いている。この組織には、ATM、決済（Payments）、SWIFTゲートウェイ、取引ポータル、メインフレーム、Active Directory、DNS／NTP、ローン、VDI、PKIなど、多数のプロテクトサーフェスが存在する。そのそれぞれに「関連度（重要度）スコア」と「現在のZTセキュリティ成熟度」が割り当てられ、次にどこへ取り組むかを判断する材料になる。
そのうちの1つ、「決済システム」というプロテクトサーフェスを取り出してみる。これは単一の要素ではなく、関連する複数のDAAS要素から構成される、1つの業務情報システムである。
CSAの文書の「表1」には、このほかにもCRMシステム、文書リポジトリ（SharePoint Online）、産業制御システム（化学プラント）、スマートエネルギー計測・課金システムなど、業種をまたいだプロテクトサーフェスのサンプルが、それぞれのDAAS内訳とともに示されている。いずれも『関連するDAASを束ねた1つの業務情報システム』として定義されている点が共通している。
図2：決済システムのプロテクトサーフェスを構成するDAAS要素（「ゼロトラスト・プロテクトサーフェスの定義」表1を基に作成）
| 業務情報システム | データ | アプリケーション | 資産 | サービス |
| CRMシステム | 顧客データ（製品・サービス・連絡先・イベント等） | CRMアプリ（SaaS） | CRM SaaS事業者のCRMサーバー | 顧客・組織のアイデンティティサービス、DNS |
| 文書リポジトリ | ファイルとメタデータ | SharePoint Online | Microsoftのインフラ | IDaaS（Azure Active Directory） |
| 決済システム | カード会員データ | 決済処理を行うWebアプリ | DBをホストするサーバー | 外部クレジットカード決済処理、DNS |
| 産業制御システム | 化学プロセスの制御・センサーデータ | 化学プロセス制御アプリ | プラントのセンサーとPLC | HVAC（空調） |
| スマートエネルギー計測・課金 | 電力消費量・顧客データ | 顧客モニタリング・請求システム | スマートメーター | スマートメーター無線ネットワーク |
表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つである。
次回（第1.5回）は、ISO/IEC27005の資産管理の考え方である主要資産と支援資産と、プロテクトサーフェスの考え方を検討し、ISMSでの資産の考え方とプロテクトサーフェスの関係を明確にしてみる。
そのうえで、次々回（第2回）で、ステップ2「トランザクションフローのマッピング」を取り上げる。守るべき対象が決まったら、次はそのデータやリソースが「どこから来て、どこへ流れているのか」を可視化していく。
以上
2026年7月26日
SaaSセキュリティリーグ 諸角昌宏
第7回SaaSセキュリティリーグ会議
「SaaSセキュリティリーグ」は、SaaSユーザー企業の実務者同士で情報交換を行う取り組みである。SaaS管理者やセキュリティ担当者を横串でつなぎ、知見交換を行うことで、セキュリティレベル向上に貢献していくことを目的としている。ここでは、「SaaSセキュリティリーグ」が行った第7回会議の内容をまとめて公開する。なお、今回は会議の内容をベースに情報セキュリティの基本対策について筆者の考えとしてまとめた。
フロンティアAI（高性能AI）がシステムの脆弱性を短期間・大量に自動発見する能力を持ち始め、サイバー攻撃の質と速度が根本的に変容しつつある。大量パッチが一斉提供される事態を想定した早期対応が急務と判断。金融庁と日本銀行が連名で金融機関等に緊急要請を発出した（https://www.fsa.go.jp/news/r7/sonota/20260522-5/01.pdf）。
今回のSaaSセキュリティリーグでは、この要請の内容をもとに、フロンティアAI脅威対応を検討する情報システム部門の方々でディスカッションを行った。
以下、9項目について、おおむね1か月以内に対応することが求められた。
ここでは、SaaSセキュリティリーグでディスカッションされた内容をリストアップする。
ここからは、ディスカッションの内容をベースに筆者としての見解として整理してみたい。
9項目について、何故対応が進まないかについて整理すると以下のようになると考えられる。あくまで、筆者としての意見であり、すべての組織に通じるものではないことを述べておく。
まとめると、効果が目に見えにくい、何かあったときの責任が特定の人にのしかかる、古いシステムや知識が特定の人に頼りきりになっている、という3つの構造的な事情が根っこにあるものと考える。
ここでは、9項目の要請に対する筆者が考える代表的な実装例として以下を上げる。今後の対策、検討の参考としていただきたい。
金融機関等への緊急要請の中で触れられている「AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について ～Project YATA-Shield～」では、「重要インフラ事業者等においては、高性能AIの悪用リスクに備えたサイバーセキュリティ対策の実施や、より高速かつ大量に脆弱性が発見・修正されることを前提とした対策強化を行うとともに、ベンダ等においては、高性能AIの活用を含め、より早期の脆弱性の発見・修正等の実施」を求めている。あくまで重要インフラ・防衛産業に限定された要請であるが、筆者は、一般企業へは①サプライチェーン圧力、②ベンダー主導の標準化、③インシデント報道による自主対応という経路で広がる可能性があると考える。
このような要請が一般企業に広まるかどうかに関わらず、情報セキュリティ部門にとって、この緊急要請の9項目はいままでやりたくてもなかなかできなかった基本対策やセキュリティハイジーンであるといえる。今回の要請は、これまで優先順位を上げにくかった基本対策を経営課題として位置付ける契機となり得る。セキュリティの基本対策の整備から、継続的に改善するセキュリティハイジーンに取り組むことで、組織のセキュリティレベルを大きく向上させることができるチャンスと捉えることが重要であると考える。
以上
2026年7月15日
AIWGメンバー 諸角昌宏
本ブログは、CSAI FoundationとCSA本部が2026年7月8日に公開したリサーチノート「BioShocking: Fictional Framing Breaks AI Browser Guardrails」の内容を、日本語で要約したものである。本ブログの内容と原文とで差異があった場合には原文が優先される。
セキュリティ企業LayerXの研究者が、「BioShocking」と名付けた手法を公表した。これは、AIブラウザの「エージェントモード」に対してフィクションのゲーム設定を装った文脈を与えることでガードレールによる安全判断を迂回させ、ユーザーのログイン済み認証情報を持ち出させる攻撃手法である。
検証対象となった6つのエージェント型ブラウザ・拡張機能（OpenAIのChatGPT Atlas、PerplexityのComet、AnthropicのClaude Chrome拡張機能、Fellou、Genspark Browser、Sigma Browser）のすべての製品で概念実証（PoC）による攻撃成立が確認された。
この攻撃は攻撃者による追加のコード実行や脆弱性悪用を必要としない、自然言語による文脈操作のみで成立する。そのため、既知の悪意あるコードやシグネチャを検知する従来型のコンテンツフィルタリングやマルウェアスキャンでは、この手法を検知することは困難とみられる。
ベンダーの対応は一貫していない。OpenAIはChatGPT Atlasを修正済み、AnthropicはClaude Chrome拡張機能への修正を試みたが回避手法が依然として報告されている、Perplexityは対策を講じずに報告をクローズ、残る3社（Fellou、Genspark、Sigma）は開示に対して一切応答していない。 CSAは、この問題を個別実装ではなくアーキテクチャ上の課題と評価している。エージェント型ブラウザは、メール、コードリポジトリ、クラウドコンソール、パスワードマネージャーなど、ユーザーの認証済みセッション状態を引き継ぐ一方で、その認証済みコンテキストを、攻撃者が自由に書き換え可能な周囲の会話コンテキストよりも機密性が高いものとして扱う仕組みを、一般的に備えていない。
エージェント型AIブラウザ、つまりLLMがWebページを操作し、リンクをクリックし、フォームに入力し、ユーザーに代わってページ内容を読み取る製品は、この1年で実験的機能から主要AIベンダーの正式製品へと移行した。ChatGPT Atlas、Perplexity Comet、Anthropicの Claude for Chrome拡張機能はいずれも、単にユーザーが読み込んだページを要約するだけでなく、有効な認証済みブラウザセッション内でモデルが自律的に行動する権限を与えている。
この能力拡張こそが、間接的プロンプトインジェクションを危険にしている要因である。モデルはもはやユーザーが貼り付けたテキストについて質問に答えるだけの存在ではなく、リンクの追跡、フォームの送信、非公開データの読み取りといった、実質的な影響を伴う判断を、訪問先のあらゆるページ上に存在するテキスト（攻撃者が完全に制御するページを含む）に基づいて行っている。
LayerXの主任研究員Roy Paz氏は、この手法をビデオゲーム『BioShock』にちなんで「BioShocking」と命名した。同作では、プレイヤーキャラクターが「Would you kindly」という言葉で始まる指示に無条件で従うよう条件付けされており、それらの指示が単にゲームの内部ロジックの一部にすぎないと、本人が気づかぬまま信じ込まされている。
Paz氏の見立てでは、攻撃者がモデルに対して「フィクションあるいはルールが変更された文脈に入った」と信じ込ませることができれば、モデルは現実世界の安全訓練ではなく、そのフィクション文脈のロジックを適用してしまう可能性がある。この傾向は、検証対象となった6つのブラウザすべてにおいて、実際の認証情報を用いて実システムに対して操作している最中であっても確認された。LayerXは2025年10月から2026年1月にかけて影響を受ける6社に開示を行い、2026年6月下旬に技術詳細を公表。The Hacker News、Malwarebytes、SecurityWeekなど複数のメディアが2026年7月上旬にかけて追随報道を行った。
これは、悪意ある指示がWebページや文書、コードコメントなど、モデルが処理するコンテンツの中に隠され、ユーザーが直接入力したものではない「間接的プロンプトインジェクション」として広く議論されている弱点に合致するものである。CSAの見解では、BioShockingが注目に値するのは注入経路そのものよりも、隠しテキストや難読化されたUnicode、エンコードされたペイロードを一切用いない「純粋な物語的フレーミング」だけで、LayerXが検証したすべてのエージェント型ブラウザのガードレールを突破できることを示した点にある。 この違いは防御側にとって重要な意味を持つ。間接的プロンプトインジェクション対策に関する公開議論の多くは、モデルに届く前のページコンテンツを無害化・検知すること（隠しテキストのフィルタリング、異常な書式の除去、既知のジェイルブレイク表現の検出）に焦点を当ててきた。しかしBioShockingのパズルページにはそうした兆候が一切なく、すべての指示は平文で可視、かつ一見ゲームの内容として自然なテキストだった。したがってLayerXが明らかにした脆弱性は、コンテンツフィルタリングよりも下流、すなわち「認証済みコンテキストの中で、その要求を実行してよいか」というエージェント自身の判断に存在しており、これがより優れたコンテンツフィルタだけでは解決できない理由である。
LayerXのPoCは、BioShock風のディストピア的パズルゲームを模したWebページを作成し、エージェントモードで動作するAIエージェントにゲームへの参加を促す形で構成された。序盤のパズルでは意図的に客観的に誤った回答（例：「2＋2＝5」を正解とする）を報酬付けし、そのセッション内でエージェントに「外の世界の通常のルールはこのゲーム内では適用されない」と受け入れさせるよう仕向けた。
この逆転ロジックをエージェントが受け入れた後、最終段階のパズルは、ユーザーが既に認証済みのGitHubリポジトリ内の認証情報（例：SSH鍵）のような機密情報を取得し、それを「解答」として報告するよう指示するものだった。逆転ロジックのフレーミングにセッションが誘導された結果、エージェントは通常であれば拒否するはずの、機密認証情報の抽出・送信という要求にゲーム外の文脈では応じないはずの要求に従ってしまった。
この攻撃連鎖は、現行のエージェント型ブラウザのアーキテクチャにおける3つの複合的な弱点を露呈している。
第一に、これらのエージェントは一般に、メール、ソースコードリポジトリ、クラウドダッシュボード、パスワードマネージャーなど、ユーザーの認証済みセッション全体を、人間ではなくエージェント自身が機密性の高い読み取り・操作を開始する際に、多くの製品では追加確認なしに引き継いでいる。
第二に、モデルの安全訓練は文脈の再フレーミングに対して脆弱であるとみられる。検証された6システムのいずれも、フィクションやゲーム的な設定であっても、実際に有効な認証済みデータに触れる操作である限り、現実世界の結果が停止されるわけではないことを認識できなかった。
第三に、この攻撃全体が通常の外見のページコンテンツに埋め込まれた普通の自然言語で表現されているため、Webセキュリティツールが一般的に依拠するパターンマッチングやマルウェアシグネチャによる防御を回避してしまう。最終的な情報持ち出しの段階まで、悪意あるコードも、注入スクリプトも、異常なネットワーク要求も存在しない。
CSAの見解では、ベンダー対応のばらつきは、エージェント型ブラウザ市場全体でガードレール実装の成熟度に大きな差があることを示唆している。LayerXの報告によれば、OpenAIはChatGPT Atlasに有効な修正を提供した一方、AnthropicによるClaude Chrome拡張機能への修正は回避手法を軽減したものの完全には排除できておらず、Perplexityは修正を実施せずにCometに関する報告をクローズした。小規模な新興ベンダーであるFellou、Genspark、Sigmaは、公表時点でLayerXの開示に一切応答していない。 この差は重要である。なぜなら、これらの製品は「ユーザーに代わって認証済みセッション内で行動できるエージェント」という同一の価値提案で競合しており、特定ベンダーのPoCが修正されていても、根本的なアーキテクチャ上の露出はカテゴリ全体で共有されている可能性が高いためである。
| 製品 | ベンダー | 開示への対応 | 修正状況 |
| ChatGPT Atlas | OpenAI | 受領し修正を実施 | LayerXが修正を確認済み |
| Comet | Perplexity AI | 報告をクローズ(未対応) | 修正未実施 |
| Claude for Chrome | Anthropic | 修正を試行 | 回避手法が依然として存在するとの報告 |
| Fellou | Fellou | 無応答 | 不明 |
| Genspark Browser | Genspark | 無応答 | 不明 |
| Sigma Browser | Sigmabrowser OÜ | 無応答 | 不明 |
この対応状況の広がりは、単一ベンダーの修正内容の発表だけでは、この攻撃クラス全体が業界横断的に解決済みであるとみなせない理由を示している。各製品は、認証済みセッションへの広範かつ常時アクセスをエージェントに付与するという同一の一般的パターンの上に、それぞれ独自のガードレールロジックを実装しているにすぎない。
BioShockingは、セキュリティ研究企業によって責任ある形で開示された概念実証であり、実際のユーザーに対して野放しで悪用が観測された攻撃ではない。LayerXは攻撃コードを公開していない。
この手法は、エージェントが自律的なブラウジング権限を既に付与された明示的な「エージェントモード」で動作し、かつ認証済みセッションが既に確立されていることを前提としている。すなわち、認証そのものを回避する手法ではなく、機密性の高いアカウントにエージェント権限を付与していないユーザーは、この特定の手法によるリスクにはさらされない。 それでもリスクが重大である理由は、エージェントモードの採用こそが市場が向かっている方向であること、そしてこの攻撃が、ユーザーのエージェントが自律的に閲覧している最中にたまたま訪問するWebページ以上の高度な仕掛けを何ら必要としないことにある。
BioShockingは、LLMそのものの脆弱性というよりも、LLMに認証済みブラウザ操作権限を付与したエージェントアーキテクチャにおける認可境界（authorization boundary）の設計課題を示した研究である。
エージェントモードや自律ブラウジング機能を有効化している組織のセキュリティチームは、ChatGPT Atlas、Comet、Claude for Chromeなど、対象となる製品において現在エージェントが常時アクセス可能な認証済みアカウント・セッションを洗い出すべきである。ソースコードリポジトリ、パスワードマネージャー、管理コンソールは、エージェントモードが監督なしに立ち入るべきではない高機密コンテキストとして扱う必要がある。各ベンダーに対し、BioShocking固有の修正、および文脈再フレーミング攻撃全般への対策が実装済みかどうかを確認すべきである。ベンダーが開示に応答していない、または修正の確認が取れていない場合は、機密性の高い認証済みセッションに対するエージェントモードのブラウジングを、ベンダーの対応状況が明確になるまで無効化することを検討すべきである。
組織は、セッション全体に対する包括的なエージェントモード権限を付与するのではなく、認証情報・ソースコード・金融システムに触れる認証済みセッション内での読み取り・操作の前に、明示的な人間による都度確認を必須とすべきである。大規模にエージェント型ブラウザを導入する企業は、人間ユーザーアカウントやサービスアカウントに既に適用している最小権限の原則に倣い、エージェントがアクセス可能なドメイン・アプリケーション・認証済みセッションをできる限り狭く限定すべきである。この種の攻撃はマルウェアシグネチャを残さない一方で、観測可能な異常な操作シーケンス（エージェントが想定外のドメインにセッション中に移動する、認証情報ストアの読み取りを試みるなど）を生じさせるため、セキュリティチームはそうした異常挙動の監視体制も構築すべきである。
BioShocking系攻撃に対する恒久的な解決策は、モデルレベルのパッチではなくアーキテクチャ上の対応である。エージェントシステムには、攻撃者が自由に操作できる会話・タスクの文脈と、エージェントに許可される認証済みの高権限操作との間に、強固な認可境界が必要であり、会話内でのいかなる物語的な再フレーミングも、それ単独では機密操作を認可できない構造にすべきである。エージェント型ブラウザを開発するベンダーは、「エージェントが通常のルールは適用されないと思い込んでいる」こと自体を、単に内容を評価すべき一つの指示としてではなく、人間へのエスカレーションを要する検知可能なシグナルとして扱うべきである。エージェント型AIブラウジング製品を評価・調達する企業は、LayerXが記録した6製品中6製品という失敗率が、特定ベンダーに限定された実装上の欠陥ではなく、現時点でカテゴリ全体に及ぶ構造的な課題であることを踏まえ、文脈操作への耐性をベンダーのセキュリティ評価基準に組み込むべきである。
CSAの「Identity and Access Gaps in the Age of Autonomous AI」は、本リサーチノートが取り上げるアーキテクチャ上のパターン、つまりエージェントが独立したエンティティとして管理されるのではなく、人間や共有アイデンティティを借用することで権限の継承と攻撃対象領域の拡大が生じるを、まさにBioShockingがすべてのブラウザで成功した「常時アクセス」の問題として描いている。
CSAの「Securing LLM Backed Systems: Essential Authorization Practices」は、LayerXが特定した根本原因、すなわち信頼された高権限システムが攻撃者の意図通りに動かされる間接的プロンプトインジェクションおよび「confused deputy（混乱した代理人）」攻撃に直接言及し、外部の認可チェックポイント、最小権限のスコーピング、人間参加型の統制を正しいアーキテクチャ上の対応として提示している。
CSAの「The AI Security Gap: Why Protecting Prompts Isn’t Enough」は上記の戦略的提言を裏付けるものであり、プロンプトレベルの防御だけでは実世界への影響力を持つAIシステムを安全にできないとし、モデル自身の判断に依拠するのではなく、モデルを取り巻くランタイムでの検査・強制レイヤーの必要性を訴えている。これはまさに、物語的な再フレーミングによってエージェントに自らの安全訓練を無視させたBioShockingが突いた隙間である。
最後に、CSAの「AI Controls Matrix（AICM）v1.1」は、エージェント型ブラウザの導入範囲を検討する際に組織が適用すべきガバナンス・統制の基準を提供しており、特にそのID・アクセス管理領域は、本リサーチノートが短期的な緩和策として推奨する最小権限・認可境界の実践を体系化している。
以上