クラウドインテグレーション事業部の片山です。
2026年10月26日〜28日（現地時間）にラスベガスで開催されたイベント、Oracle AI World 2026に今年も現地参加してきました！

今回は、展示会場「Oracle AI World Hub」のオープンシアターで行われた20分のHub Theaterセッションから、「The Future Is Deny: Rethinking Cloud Security with OCI ZPR」のレポートをお届けします。

セッション表紙スライド「The Future is Deny — Rethinking Cloud Security with OCI ZPR」

セッション概要

OracleのVirtual Networking製品管理部門でLead Principal Core Infrastructure Engineerを務めるTroy Levin氏が登壇しました。本セッションは、小売企業「ACME Retail」（セッションでは明言されなかったものの恐らく架空の企業）の決済API（Checkout API）を題材に、ZPR（Zero Trust Packet Routing）、ZPR Deny、Private Service Access（PSA）、IAM Denyの4つの制御を順に重ね、「業務上の理由を説明できる通信経路だけを残す」までのストーリーを解説する内容でした。

本セッションは、会期初日のLearning Session「Trust No One, Manage Everything (Easily): OCI ZPR in Action」（LRN2413）の要約版にあたります。LRN2413は弊社新川がこちらの記事で詳しくレポートしています。ZPRの仕組みやポリシーの書き方、評価の順番、Workbenchはそちらに譲り、本記事では4つの制御を「侵害後の問い」に沿ってどう組み合わせるかに絞ってお伝えします。

セッション内容：侵害後の「通り道」を4つの問いで消していく

出発点：ルールは「どこへ通れるか」は示すが「なぜ通すのか」は示さない

「When security rules outgrow understanding, ACME Retail’s security becomes an illusion」。BROAD REACHABILITYとRULE SPRAWLの2つの問題

Levin氏は冒頭、ルールの増え方が理解できる速度を超えると、守れているように見えて実は守れていない「セキュリティの幻想」になると指摘しました。ACME Retailはアプリケーションが数百に増え、ルールも同じように増えました。導入時には意味のあったルールも時間とともに説明できなくなり、監査やインシデント対応のたびに調べ直すことになります。

スライドでは課題が2つに整理されていました。

  • BROAD REACHABILITY：Checkoutが業務上の役割を超えたシステムに届いてしまう
  • RULE SPRAWL：セキュリティリストやルートは「どこへ通れるか」は示すが、「なぜ通すのか」は示さない

ACME Retailのベースライン構成。必要な経路（Orders DB、Object Storage）と不要な経路（Payroll DB、NAT Gateway経由の公開経路）が両方開いている

Checkout APIが必要とするのはOrders DB（取引）とObject Storage（レシートの保存）だけです。しかし、Orders DBとPayroll DB（給与）が同じサブネットにあるためPayroll DBへの経路も開き、サービスゲートウェイ経由でOracle Services Network全体にも届いていました。「問題は通信が流れるかどうかではなく、なぜ流れているのかを説明できるかだ」という言葉が印象的でした。

侵害されたCheckoutは、どこへ行けるか

「After compromise, where can Checkout go?」。Orders＝必要、Payroll＝不要だが届く、Oracle Services NetworkとObject Storage＝広すぎる

セッションの軸になっていたのが「Checkout APIが侵害された、あるいは認証情報が漏れたとき、足がかりはどこまで広がるか」という問いです。スライドでは届き先が4つに分類されていました。

  • Orders：必要。Checkoutが業務で使う経路
  • Payroll：不要。それでも届いてしまう
  • Oracle Services Network：広すぎる。必要以上のサービスに届く
  • Object Storage：広すぎる。公開インターネット経由でも届く

ここから、4つの制御で不要な経路を1本ずつ消していきます。

ZPRとZPR Deny：意図した相手にだけ届け、届いてはならない相手を明示する

「When default deny is not enough」。Orders DBは名前付きのAllow、未分類のDBはデフォルトの拒否、Payroll DBは広いAllowがあっても明示的なDenyが優先

1つ目の制御のZPRで、CheckoutとOrdersにセキュリティ属性を付け、「checkoutはordersに接続してよい」という意図をポリシーとして書きます。ZPRはデフォルトで拒否なので、ポリシーに無い接続は通りません。

2つ目のZPR Denyは、既存の広いAllowが残っていても、Checkout→Payrollのように決して許可してはならない経路を明示的に止めるためのものです。スライドの「Default deny protects what was never allowed. Explicit deny protects what must never be allowed.」（デフォルトの拒否は一度も許可しなかったものを守り、明示的な拒否は決して許可してはならないものを守る）という一文が、2つの違いを端的に表していました。ZPR Denyは現在限定提供（Limited Availability）で、数か月以内のリリースを予定していると語られました。2026年11月6日時点では、ZPRのリリースノートにはまだ掲載されていません。

「Acme Retail moved policy closer to the workload」。2つのVCNをDRGでつないだ構成で、Checkout→Ordersは許可、Payrollと未承認の公開経路は拒否

Levin氏は、ZPRのポリシーは属性で書くため「ポリシーがワークロードと一緒に移動する」点も強調していました。ワークロードを別のサブネットに再デプロイしても、ポリシーが付いていきます。ZPRのポリシー構文、Denyの評価順序、複数VCNへの対応は、LRN2413のレポートで詳しく解説しています。

PSA：Object Storageへの入口を1本に絞る

「Object Storage needs one private service path」。BEFOREはサービスゲートウェイ経由でOracle Services Network全体に届く。AFTERはObject Storage PSAの1本だけ

3つ目のPSAは、どのObject Storageの入口を使ってよいかに答える制御です。BEFOREではFunctionsやLoggingなど、Checkoutが使わないサービスにまで届いていました。AFTERではObject Storage用のPSA（プライベートエンドポイント）1本だけを残し、そこにもZPRのポリシーをかけます。

セッション内で強調されていたのは、PSAが通信の宛先だけでなく認証情報も確認する点です。悪意のある社員が自分で作った別テナンシーのバケットにデータを持ち出そうとしても、経路がPSAしかなければ、PSAは既定で自テナンシーの認証情報しか通さないため拒否されます。PSAは2026年1月に一般提供が始まっています。

IAM Deny：同じ認証情報でも、通り道で結果が変わる

「IAM Deny requires the approved request path」。PSA経由なら通常のIAM評価で許可、公開エンドポイント経由ならIAM Denyでブロック

最後の穴は、盗まれた認証情報を社外から公開エンドポイント経由で使われる経路です。4つ目のIAM Denyで、「PSAを通らないObject Storageへのリクエストは拒否する」とIAMポリシーに書きます。スライドのとおり、同じ有効な認証情報でも、PSA経由なら許可され、公開エンドポイント経由なら拒否されます。「A valid credential alone is not enough」（有効な認証情報だけでは不十分）という一文がこのパートの結論でした。

IAM Denyは2026年1月に一般提供が始まり、利用前に管理者が有効化する必要があります。2026年7月の公式ブログでは、拒否時にバケットの存在を悟られないよう404を返すと説明されています。

4つの制御は、それぞれ別の問いに答える

「After compromise, every request must earn its path」。ZPR、ZPR Deny（PLANNED GUARDRAIL）、PSA、IAM Denyが答える問いの一覧

締めくくりでは、4つの制御が答える問いが1枚に整理されていました。設計や棚卸しの判断軸としてそのまま使えます。

  1. ZPR：Checkoutは意図したワークロードに届くか（WORKLOAD INTENT。名前付きのAllowで許可）
  2. ZPR Deny：広いAllowがあっても、Checkout→Payrollを止められるか（SENSITIVE-FLOW GUARDRAIL。明示的なDenyがAllowに優先）
  3. PSA：どのObject Storageの入口を使ってよいか（PRIVATE SERVICE ENTRY。名前付きのプライベート経路1本）
  4. IAM Deny：リクエストはその入口から来たか（APPROVED REQUEST PATH。公開経路からは有効な認証情報でも拒否）

組み合わせることで「説明できない経路」がなくなる、というのがセッションの結論でした。

おわりに

以上、「The Future Is Deny: Rethinking Cloud Security with OCI ZPR」に現地参加してのセッションレポートをお届けしました。

関連セッションLRN2413「Trust No One, Manage Everything (Easily): OCI ZPR in Action」の案内スライド

20分の短いセッションでしたが、ZPRとZPR Denyでワークロード間の通信を、PSAでサービスへの入口を、IAM Denyでリクエストの経路を絞る流れが、1つのシナリオで整理されていました。Allowを積み上げてきた設計に、ネットワークとIAMの両方の層で「通してはならないもの」を明示するDenyがそろいつつあることが、タイトルの「The Future Is Deny」に込められていると感じました。

私としては、この4つの問いを既存のOCI環境の棚卸しのチェックリストとして使えると考えています。サービスゲートウェイ経由で開いている範囲、同じサブネットに同居するデータベース、公開エンドポイントで使える認証情報を洗い出し、一般提供済みのPSAとIAM Denyから導入し、ZPR Denyは一般提供後に足す、という段階的な提案がしやすくなります。プライベートエンドポイントとアクセス元を条件にしたポリシーの組み合わせは他のクラウドでも定番の考え方なので、マルチクラウドを支援する立場としても、お客様と共通の言葉で議論できる点に価値があると感じています。

ZPRの機能の詳細は、ぜひLRN2413のレポート記事もあわせてご覧ください。引き続き、Oracle AI World 2026の深掘りレポートをお届けします。

最後までお読みいただきありがとうございました！