資源単位の接続と判断

社外にいるアリスが社内の請求書アプリAPP-1へ接続します。従来のVPNで社内サブネット全体へ接続させる構成と、APP-1だけへ条件付きでつなぐZTNAでは何が違うのでしょうか。SSE・SASEとの関係、IdP、端末状態、ポリシー、ログを一つのアクセスで学びます。

読む順序は、用語と配置→正常な処理→異常ログ→調査と対策→復旧→演習です。接続・検知・遮断・被害を別々の事実として扱います。以下の構成、時刻、アドレス、ログ、設定値は教材用の架空例です。

1. 用語と役割を構成に結び付ける

用語	この事例での意味と限界
ゼロトラスト	ネットワーク位置や端末所有だけで暗黙の信頼を与えず、資源へのアクセスごとに主体・端末・環境を評価する考え方。製品名や単一の認証方式ではない。
ZTNA	Zero Trust Network Access。定義したアプリ・サービスへのアクセスを、利用者と端末の条件に基づき仲介する構成。社内ネットワーク全体への広い接続を与えない。
SSE	Security Service Edge。ZTNA、SWG、CASB等のセキュリティ機能をサービスとしてまとめる分類。ネットワーク転送全体を指すわけではない。
SASE	Secure Access Service Edge。SSEのセキュリティ機能とSD-WAN等のネットワーク接続を統合するアーキテクチャの分類。実製品の範囲は確認が必要。
PDP/PEP	PDPは条件に基づくポリシー決定、PEPは接続の許可・拒否を実施する点。決定ログと実際の接続結果は別。
端末ポスチャ	EDR稼働、OS更新、管理状態などの端末属性。申告値や古い評価だけを信頼せず、取得元と有効期間を管理する。

2. 構成と信頼境界

アリスの管理端末WS-41は社外にあり、IdPでMFAを受けます。ZTNAゲートウェイPEP-1はAPP-1（10.20.8.7:443）への要求だけを仲介し、PDP-1がuser=alice、device=WS-41、role=accounting、posture=healthy、resource=APP-1で判断します。APP-1は請求書ごとの認可も行います。

資源単位の接続と判断

1. MFAで本人確認
2. 端末状態を提出
3. APP-1へ接続要求
4. 許可時だけ接続

IdP・端末状態を用い、PEPがAPP-1への接続だけを実施する。

PDPの決定をPEPが利用する関係は本文で説明します。図は端末から各要素への論理的な関係で、PDPへ端末が直接自由な値を送ればよいという意味ではありません。信頼できる端末管理・IdPから属性を取得します。

3. 正常な処理を順に追う

WS-41がIdPへ認証しMFAを完了する。IdPの本人確認とAPP-1での請求書認可は別。
PDP-1が利用者属性、端末管理状態、要求資源、時間などを評価し、APP-1への接続可否を決める。
PEP-1がその決定を実施し、許可されたAPP-1:443だけへの接続を仲介する。
APP-1はアリスが特定の請求書を閲覧してよいかを業務権限で再判定する。状態変化時はセッション更新・再評価を行う。

ZTNAがAPP-1への経路を制限しても、APP-1自体のIDORや過大権限は直りません。逆にIdP認証成功だけでネットワーク全体を許可すれば、アプリ単位の制限を実現していません。

4. 設定値・ログの読み方

項目	値の意味と判断の限界
principal/device_id	誰のどの端末か。IPアドレスだけを本人・管理状態の証明にしない。
resource/action	APP-1:443への接続と、APP-1内の請求書閲覧は別の操作。
posture/source/age	healthyという値の取得元と最終評価時刻。古い結果なら再評価が必要。
policy_id/decision	PDPがどの版の条件で許可したか。PEPに適用されたかは別ログで確認。
session/expiry	許可の有効期限と失効伝播。退職・端末紛失後の残存アクセスを調べる。

次の架空ログではAPP-1への接続が許可されますが、請求書5201はAPP-1が拒否します。

text

15:00:00 idp user=alice mfa=ok device=WS-41
15:00:01 pdp policy=ACC-41 posture=healthy age=30s
  resource=APP-1:443 decision=allow
15:00:02 pep session=Z-41 resource=APP-1 action=connect
15:00:03 app user=alice object=invoice-5201
  decision=deny reason=tenant_mismatch

`pdp decision=allow`はAPP-1への接続条件を満たしたことを示します。請求書5201の閲覧は拒否されています。PEPに接続しただけで業務データを取得したとは言えません。

5. 攻撃・障害時の差分

異常・攻撃条件	観測、成立条件、対策の位置
盗用アカウント	IdP資格情報だけでなくMFA・端末状態・異常サインインを検証。攻撃者が正規端末を奪えばなお危険。
古いポスチャ	EDR停止後もhealthyのキャッシュが残る。評価期限と継続確認を設計。
PEP迂回	APP-1の公開IPや旧VPN経路が残る。アプリ側FWでPEP以外を拒否する。
IdP障害	判断不能時の既定許可は危険。限定的な緊急手順と失効済みセッションの扱いを事前定義。
過大なポリシー	accounting全員へ全アプリを許可すると最小権限にならない。資源と操作を細分化。

SSEやSASEという契約名だけで、どのトラフィックが検査・制御されるかは決まりません。SWGは外向きWeb、CASBはクラウド利用、ZTNAは私設アプリへのアクセスと役割が異なります。例外や直通経路を調べます。

6. 切り分けに必要な証拠

IdPの認証とMFA、端末状態の取得元、PDPの決定、PEPの実接続を時刻順に揃える。
APP-1のアクセス・業務認可ログで実際に読めた請求書を確認する。
PEPを迂回する旧VPN、公開DNS/IP、管理用経路、サービスアカウントを洗い出す。
ポスチャの評価時刻と失効伝播を確認し、端末紛失後の要求を再現する。

`allow`のログはその時点のポリシー判断であり、端末が本当に健全だったことやアプリ内部の権限まで証明しません。APP-1の拒否ログも他のAPI経路の安全性を保証しません。

6.1 判断を誤りやすい境界と詳しい確認

確認点	具体的な判断
対象資源	ZTNAはAPP-1など特定アプリへの接続を方針で許可する。『社内LANに入れたから全サーバへ到達』という前提を避け、アプリごとに権限を定義する。
PDP/PEP	PDPは認証・端末状態・資源・状況から方針を判定し、PEPは実通信に許可・拒否を適用する。判定ログだけでPEPが適用したと断定しない。
継続評価	端末が初回に健全でも、EDR停止や証明書失効が後で起こる。再評価間隔、既存セッションへの反映、失効通知の遅延を設計する。
旧VPNとの並走	旧VPNからAPP-1へ直接入れるならZTNAの条件を迂回する。FW、DNS、直接IP、サービスアカウント経路も棚卸しする。
SSE	クラウド提供のセキュリティ機能群として、ZTNAやSWG、CASBなどを含む文脈がある。個々の製品機能と実際の適用範囲を確認する。
SASE	ネットワーク接続機能とSSE等のセキュリティ機能を統合する設計・提供モデル。SASEという製品名だけで全拠点・全アプリが保護されたとは言えない。
障害時	IdP、端末状態収集、PDP/PEPのどれが止まったかを分ける。緊急アクセスの例外は対象・時間・承認・記録・事後失効を決める。

例えばWS-41がIdP認証に成功しても、端末のEDR停止をPDPが検知したらAPP-1への接続を拒否できます。逆にPDPがdenyでも旧VPN経由でAPP-1へ到達できるなら、実際の境界に抜け道があります。IdPログ、端末状態、PDPの決定、PEPの転送、APP-1のアクセスログを同じセッションで照合します。

ゼロトラストは信頼を永久に与えない設計原則です。すべてのパケットで完全に再認証するという意味ではありません。ポリシーの評価時点と有効期間、端末状態の鮮度、既存セッションの取消しを具体化してはじめて、端末隔離や資格情報失効が通信に反映されます。

移行では、先にアプリごとの利用者・端末・管理者・委託先を洗い出します。実際の必要通信を収集して方針を作り、並走中の旧VPNルールを期限付きで縮小します。APP-1の直接公開や管理ポートを残したままZTNAだけ導入すると、攻撃者は保護経路を通る必要がありません。

7. 設定変更と例外運用

変更・例外	失敗しやすい点と確認
新アプリ登録	資源ID、公開先、ポリシー、PEP経路、アプリ側認可を揃える。旧直通IPを残さない。
部署異動	IdPの属性変更、PDPキャッシュ、既存セッションの失効を確認。
端末紛失	device_idを無効化し、証明書・トークン・セッションを失効。位置情報だけで代用しない。
SASE移行	SD-WANの経路とSSEの検査範囲を別に棚卸しし、分割トンネルの直通先を確認。

段階移行中は旧VPNとZTNAが並存し、広い旧経路が残りやすいです。新しい経路が動くことに加え、旧経路からAPP-1へ到達できないことを試験します。

8. 封じ込めと復旧条件

疑わしいセッションZ-41とIdP・端末・PDP・PEP・APP-1ログを保全する。
利用者や端末を失効し、PEPのセッションを切る。APP-1のアプリセッションも別途失効する。
PEP迂回の公開経路と旧VPNを閉じ、不要なポリシーを縮小する。
正規アリスのWS-41だけがAPP-1へ接続でき、禁止端末や退職者は拒否されることを試験する。
APP-1内の請求書認可が正しく、監査ログがそろうことを確認して再開する。

ZTNA側の遮断だけでは、既に発行済みのアプリCookieやAPIトークンが有効なままの可能性があります。全てのセッション層を確認します。

9. 科目B（午後）での解答手順

ユーザー、端末、資源、判断主体PDP、実施点PEP、アプリ内部の権限を別の列に整理します。SASE・SSE・ZTNAの包含関係は機能の範囲で説明し、名称だけでセキュリティを断定しません。

ネットワーク位置を本人確認の根拠にしない。
PDP判断とPEP実施を分ける。
APP-1自身の認可と迂回経路を調べる。

10. 短答演習

演習1：MFA成功

条件：IdPでmfa=ok。質問：請求書5201を閲覧できるか。

解答：別の業務認可が必要。誤答の理由：認証と認可を混同している。

演習2：PEP迂回

条件：旧VPNからAPP-1へ到達可能。質問：ZTNAだけで保護完了か。

解答：いいえ。旧経路を閉じる。誤答の理由：保護点を迂回できる。

演習3：ポスチャ

条件：healthyは昨日の値。質問：現在も安全か。

解答：再評価が必要。誤答の理由：属性の鮮度を無視している。

演習4：SSE

条件：SWGとCASBとZTNAを導入。質問：SD-WANも自動で含むか。

解答：含まない。SASEのネットワーク部分は別。誤答の理由：SSEとSASEを同一視している。

演習5：PDP許可

条件：decision=allow。質問：APP-1に到達したか。

解答：PEPの実接続を確認する。誤答の理由：判断と実施を混同している。

演習6：失効

条件：ZTNAのZ-41を失効。質問：APP-1のCookieも無効か。

解答：別途確認する。誤答の理由：層ごとのセッションを同一視している。

11. 一次資料

NIST SP 800-207：ゼロトラストアーキテクチャ

CISA：SSE/SASE/ゼロトラストのアクセス指針

NIST SP 1800-35：実装例

ZTNA・SASE・SSEとゼロトラスト