「境界線」をなくせ！ゼロトラストの核心、PDPとPEPの役割分担を紐解く
ネットワークエンジニアの皆さん、こんにちは！
これまでのセキュリティの常識といえば、「社内のネットワークは安全、社外は危険」という、いわゆる境界型防御でした。しかし、テレワークが当たり前になった今、その「境界線」は霧のように消え去ってしまいましたよね。
そこで登場するのが「ゼロトラスト」という考え方。今回は、その中でも特に重要で、かつ少しややこしい「PDP」と「PEP」という役割について、郵便配達に例えながら、現場の目線で優しく解説していきます。
—
郵便配達でイメージする「アクセス制御」
まずは、難しい専門用語を一度忘れて、皆さんの手元に届く「書留郵便」を想像してみてください。
1. PDP（Policy Decision Point）：判断を下す人
郵便局の窓口で「この手紙は本人確認ができたから、配達してよし！」と許可を出す責任者のような存在です。手元の名簿（ポリシー）と照らし合わせ、「誰が、何を、どこへ送るのか」をじっくり吟味します。
2. PEP（Policy Enforcement Point）：実行する人
実際に自転車に乗って郵便物を届ける配達員さんです。PDPから「届けてOK」という指示を受けて初めて、その家（サーバー）のポストに手紙を投函します。
ゼロトラストにおけるセキュリティもこれと同じです。「判断する頭脳（PDP）」と「行動する手足（PEP）」を切り離しておくことこそが、攻撃者に付け入る隙を与えない、強固な守りの秘訣なんです。
—
なぜこの「分離」が最強の守りになるのか？
なぜわざわざ役割を分ける必要があるのでしょうか？ それは、万が一「配達員さん（PEP）」が脅迫されても、彼自身は「どの手紙を渡すべきか」という権限を持っていないからです。
PEPはPDPから送られてくる「許可証（トークンなど）」がないと、一歩も先へ進めません。もし悪意ある第三者がPEPを突破しようとしても、そこには「判断能力」がないため、何も盗み出せない。これが、ゼロトラストアーキテクチャの真骨頂です。
—
実践！PEPの設定イメージを覗いてみる
現場では、このPEPの役割を「リバースプロキシ」や「APIゲートウェイ」といった装置が担うことが多いです。
例えば、皆さんがよく目にする Nginx のようなWebサーバーでアクセス制御を行う場合、こんなイメージで設定を行います。
# 簡易的なPEP（実行ポイント）の設定例
location /secret-data {
# ここでPDP（認証サーバー）に問い合わせるイメージ
auth_request /auth-check;
# PDPからOKが出たら、裏側のサーバーへ中継する
proxy_pass http://backend-server;
}
location = /auth-check {
# 実際にはここでPDP（IDPサーバー等）と通信し、
# ユーザーが権限を持っているか判定します
internal;
proxy_pass http://identity-provider/verify;
}このように、proxy_pass（中継）をする前に、必ず auth_request（確認）を挟む。これが現場で最もよく使われる「PEPの基本動作」です。
—
初学者が押さえておくべきポイント
このアーキテクチャを理解する上で、以下の3つのキーワードだけは覚えて帰ってください。
- コンテキスト（文脈）: PDPが判断する材料です。「いつ、どこから、どの端末で、何のアプリにアクセスしようとしているか」。この情報が多ければ多いほど、判断は賢くなります。
- ゼロトラストプロトコル: PDPとPEPが会話するための言語です。代表的なものに
OIDC（OpenID Connect）やSAMLなどがあります。手紙の封筒に貼る「証明書」のようなものですね。 - 動的な判断: 境界型防御は「一度入ったら終わり」でしたが、ゼロトラストは違います。
1時間後に突然怪しい場所からアクセスがあったら、即座にアクセス権を剥奪する。これこそがPDPの真のパワーです。
—
最後に：ネットワークは「生き物」です
ネットワークセキュリティの世界は、教科書通りにはいきません。現場では「PDPの応答が遅くてPEPがタイムアウトした！」なんてトラブルも日常茶飯事です。
でも、まずは「判断する場所」と「実行する場所」が別々であるという原則さえ掴んでいれば、どんなに複雑なシステム構成図を見ても怖くありません。
「このパケットは今、どこで判断されて、どこで遮断されているのか？」
そんなふうに、ネットワーク上のパケットを「配達員さんが運ぶ手紙」のように想像してみてください。きっと、皆さんのエンジニアとしての視界が、ぐっとクリアになるはずですよ！
それでは、また次回の記事でお会いしましょう！
コメント