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	与信審査という業務上の必要	決済処理に必要な参照
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はその実行場所である、という点がここでも確認できる。

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「監視と保守」を扱う。すべてのトラフィックをアプリケーション層まで検査・記録し、そのテレメトリを使って、プロテクトサーフェスを継続的に強くしていく。ゼロトラストを「作って終わり」にしないための最後のステップである。

以上