はじめに

  • こんにちは、エンタープライズクラウド事業部の新川です。今週は Oracle AI World 2026 に参加するため、ラスベガスに来ています。
  • 今回は「Trust No One, Manage Everything (Easily): OCI ZPR in Action [LRN2413]」のセッション内容をお伝えします。OCI のゼロトラストの仕組み「ZPR」について、考え方から最新の機能、導入の進め方までを扱ったセッションでした。
  • 最新機能として、複数 VCN への拡張、Network Path Analyzer（NPA）との統合、ZPR Visualizer、Private Service Access（PSA、OCI のサービスにプライベート IP でつなぐ機能）と ZPR の連携、ZPR Deny、Workbench が紹介されました。今後の予定として、リージョンやテナンシーをまたぐ拡張も説明されました。あわせて、ZPR と組み合わせて使う IAM Deny も扱います。

先に、用語をおさらい

  • ゼロトラスト：「社内だから安全」とは考えず、すべての通信を確かめて、許可されたものだけを通す考え方です。
  • ZPR（Zero Trust Packet Routing）：通信をIP アドレスではなく「どのリソースが、どのリソースにつながってよいか」で許可する、OCI の仕組みです。
  • VCN：OCI の仮想ネットワークです。
  • セキュリティリストと NSG：IP アドレス、ポート、プロトコルで通信を許可する、従来のルールです。
  • セキュリティ属性：ZPR で、リソースに付ける「タグ」です。「これはフロントの Web アプリ」「これはお客様データの DB」のように、役割を表します。

3 行まとめ

  • ZPR は、IP アドレスではなく「誰が何につながってよいか」という意図で、通信を許可する。
  • 既存の NSG やセキュリティリストと重ねて使い、評価の順番は「Deny が先、Allow があと」。
  • ZPR Deny、PSA との連携、IAM Deny、Workbench で、「止める」「絞る」「安全に導入する」ための部品がそろってきた。

なぜ、ネットワークのセキュリティは難しいのか

  • スライドの冒頭では、データ侵害の 68% に、人の関わる要因が絡んでいると示されていました。出典として、2024 年の Data Breach Investigations Report が記載されていました。
  • そのうえで、スライドは課題を次のように並べていました。
    • 数千の IP ルール
    • 分断された環境
    • 設定ミスのしやすさ
    • 絶え間ないネットワークの変更
  • その結果として、次のような影響が起きます。
    • 横展開（ラテラルムーブメント）：侵入された 1 台から、ほかのサーバーへ広がる。
    • データの持ち出し
    • コンプライアンス違反
    • ネットワーク障害
  • ルールが増えるほど、1 つの設定ミスが、攻撃者への入り口になりかねません。スライドの副題にもそのように書かれていました。

ZPR は「意図」でセキュリティを書く

ZPR とは

  • スライドの言葉では「Makes network security about intent – not IP addresses」。ネットワークのセキュリティをIP アドレスを中心にした設定ではなく、「誰が何につながってよいか」という意図を中心に書く、という意味です。次の 4 つが特長でした。
    • 人が読めるポリシー：「誰が何につながってよいか」を書く。
    • 明確な信頼の境界：ビジネス上の意図でリソースを守る。
    • ネットワーク設定から切り離す：セキュリティは、ワークロードについて回る。
    • 既存の制御と一緒に使う：PSA や IAM Deny と重ねられる。
  • ネットワークの構成が変わっても属性のポリシーは変わりません。これが、ZPR の大きな利点です。

3 ステップで始める

  • 導入の流れは、3 ステップです。
    • セキュリティモデルを決める：守りたい単位を属性として定義します。たとえば、アプリ、データ、VCN などです。
    • ZPR ポリシーを書く：どのリソース同士が通信してよいかを読みやすい文で書きます。
    • 属性をリソースに付ける：付けた属性をもとに、ZPR が通信を制御します。
  • スライドのポリシーの例は、次のものでした。
Allow web:app endpoints in network:frontend VCN to connect to customer:db endpoints in network:backend VCN
  • 日本語にすると、「フロントエンド VCN の Web アプリは、バックエンド VCN のお客様データ DB につながってよい」です。スライドには「Security intent is readable before you ever inspect an IP address（IP アドレスを見る前に、意図が読める）」とありました。ZPR で保護したリソースは、ポリシーで許可していない通信を受け付けません。

複数の VCN をまたいで、1 つのポリシーで書く

  • 最初の ZPR は、1 つの VCN の中が境界でした。最新のリリースで、同じリージョンの複数の VCN をまたいで、1 つのポリシーで書けるようになった、と説明されました。
  • スライドでは、次のメリットが示されていました。
    • Unified enforcement：1 つのポリシーを複数の VCN に適用する。
    • Least-privilege access：境界をまたぐ通信を最小限に絞る。
    • Simpler management：重複したポリシー設定を減らす。
  • 構文は、送信元の属性と VCN、宛先の属性と VCN を並べるかたちです。＜ ＞の部分は、実際には自分の属性名に置き換えます。
Allow ＜source attribute＞ endpoints in ＜source VCN attribute＞ VCN to connect to ＜destination attribute＞ endpoints in ＜destination VCN attribute＞ VCN
  • フロント、中間、バックエンドの VCN に分けた場合でも許可した属性の組み合わせだけが通ります。ほかの VCN への横展開を止めやすくなります。

既存のセキュリティリスト・NSG に「重ねて」使う

ZPR で許可しているのに、つながらない場合

  • ZPR のポリシーで許可したのに、通信が通らない。そんなときの切り分けに、Network Path Analyzer（NPA、ネットワークの経路を調べる OCI の機能）との統合が紹介されました。NPA の分析結果に、ZPR のポリシーの評価結果が重ねて表示され、ネットワーク構成の問題なのか、ZPR のポリシーやセキュリティリスト・NSG による遮断なのかをすばやく特定できます。
  • 例のスライドは、次の状況でした。
    • 経路の結果は「Unreachable（到達不可）」、成功したホップは 0。
    • でも、「ZPR policy present: Permitting communication for this path（この経路を許可する ZPR ポリシーがある）」と出ている。
    • その下に「Security denied: Ingress access control」と出ている。
  • 付箋には、「ZPR のポリシーが許可していてもセキュリティリスト（SL）や NSG がブロックしている」とありました。
  • ここが、エンジニアにとって一番大事な点です。ZPR は、既存の SL / NSG を置き換えるのではなく、重ねて使うものです。通すには、両方で許可されている必要があります。NPA は、ポリシー、NSG、セキュリティリストのどれが止めているかを見つけるのに使えます。
  • そのほか、ZPR Visualizer が紹介されました。OCI コンソール上で、どのリソースにセキュリティ属性が付いているか、VCN の中や VCN 間の接続パスが、許可されているか拒否されているかを視覚的に追跡できる画面です。

出口を絞る：PSA との連携と IAM Deny

サービスゲートウェイは「全部か、なしか」

  • OCI のサービスに、インターネットを通さずにつなぐ方法として、サービスゲートウェイがあります。ただし、スライドの言葉では「provides broad access to the regional OSN」。同じリージョンの Oracle Services Network（OSN、Oracle のサービス群）の全体に、広くつながってしまいます。選べるのは、OSN 全体か、Object Storage のみという大きな区分だけで、サービスを 1 つずつ選んで絞ることはできません。
  • そこで、Private Service Access（PSA）が紹介されました。PSA は、ZPR とは別の OCI の機能で、ZPR の属性でアクセスを絞り込めます。スライドでは「Create a private endpoint for a specific OCI service」。特定の OCI サービスだけに、自分のネットワークの中のプライベート IP でつなぎます。
  • 要点は、次の 3 つです。
    • 自分の VCN のプライベート IP を割り当てる。
    • プライベート DNS で、サービスの名前をその IP に対応させる。
    • アプリは、いつも通りにリクエストを出せばよい（コードの変更が不要）。

ZPR と PSA を組み合わせる

  • スライドのシナリオは、「データベースを決まった Object Storage のバケットにバックアップしたい。ただし、許可されていないアクセスは防ぎたい」でした。
  • 図に書かれていた ZPR のポリシーは、次の通りです。
in networks:back-end VCN allow apps:customer-db endpoints to connect to secure:storage endpoints
  • 属性の意味は、次の通りです。
    • networks:back-end：バックエンドの VCN の属性
    • apps:customer-db：DB（図の Database A）に付けた属性
    • secure:storage：Object Storage への PSA のエンドポイントに付けた属性
  • つまり、「バックエンドの VCN で、customer-db の DB は、Object Storage への PSA エンドポイントにつながってよい」というポリシーです。
  • 図の付箋には、「Access to object storage is only allowed via PSA（Object Storage へのアクセスは、PSA 経由のみ許可）」とありました。スライドの下の説明もZPR で許可されたリソースだけが Object Storage のバケットにアクセスでき、許可されていないアクセスを防げる、という内容でした。

公開エンドポイントをIAM Deny で塞ぐ

  • もう 1 つ、見逃しやすい穴があります。PSA を使っていてもObject Storage には公開エンドポイントがあります。デモでは、たとえば認証情報が漏れた場合に、公開側から入られる可能性がある、と説明されました。
  • スライドでは「IAM deny statements complement PSA and ZPR so ingress to your OCI resources can only originate from your PSA, not the public endpoint.」。IAM の Deny 文で、PSA 以外からのアクセスを拒否する形です。ZPR と PSA がネットワークの通り道を絞り、IAM Deny が、公開側の入り口を塞ぎます。
  • PSA の特長は、スライドでは次のように整理されていました。
    • サービス固有のプライベート IP
    • NSG と ZPR を適用できる
    • ゲートウェイが不要
    • データ持ち出しの防止
    • 可視化とトラブルシューティング
    • コード変更が不要
    • 高い性能（最大 8 Gbps。Object Storage は 25 Gbps）
    • 追加料金なし

リスクが変わったら、すぐ止める：ZPR Deny

Allow だけでは、足りない場面がある

  • これまでの ZPR は、許可（Allow）を書く方式でした。許可していないものは、暗黙に拒否されます。たとえば、正常だったリソースが侵害された場合や、インターネットから攻撃を受けている場合などは、特定の通信を明示的に止めたくなります。
  • そこで、ZPR Deny が紹介されました。
    • Precise targeting：IP アドレス、ポート、プロトコル、セキュリティ属性を指定して、明示的に拒否する。
    • Flexible enforcement：片方向か、双方向で拒否する。
    • Disrupt active threats：既存のルールで許可されている、通信中のフローも止める。
    • Built-in visibility：メトリクス、フローログ、NPA で調べられる。
  • 例のポリシーは、次の通りです。
in vcn:app-vcn VCN deny node:app endpoints to connect to node:db endpoints with protocol='tcp/1521'
  • アプリ側から DB 側への TCP 1521（Oracle Database の標準のリスナーポート）を止める例です。

評価の順番は、Deny が先

  • スライドの順番は、次の通りです。
    • 接続追跡テーブルのエントリ：一致すれば許可
    • ZPR の Deny ポリシー：一致すれば破棄
    • SL / NSG のルール：一致しなければ破棄。一致すれば、3a の ZPR の Allow ポリシーへ
    • デフォルトの拒否：破棄
  • 「ZPR evaluates deny before allow」のタイトル通り、Deny は、SL / NSG と ZPR の Allow より先に評価されます。侵害されたリソースの隔離や、不審な通信の遮断に使えます。ただし、図では、接続追跡テーブルの確認が Deny より前に置かれています。一方で、特長には「通信中のフローも止める」とあり、この 2 つの関係は、セッションでは詳しく説明されませんでした。

導入は 2 通り

  • 初めて ZPR を使う場合：これまでの SL / NSG をそのまま使いながら、簡単な ZPR の Allow ポリシーを足します。準備ができたら、止めたい通信の Deny だけを追加します。スライドの例では、192.168.1.16/32 から Web 層への TCP/22 を止めています。
  • すでに ZPR の Allow を使っている場合：Deny のルールを足すだけで、1 つのポリシーにまとまります。

  • 既存のネットワークセキュリティを設計し直さなくても明示的な Deny を足せる、という点がポイントです。
  • ZPR Deny は、限定提供（Limited Availability）の段階で、一般提供は 2026 年 11 月ごろを予定している、と説明されました。将来の予定は、変更される可能性があります。

安全に導入する：ZPR Workbench

  • ZPR を本番環境に入れるときの不安に応える機能として、Workbench が紹介されました。

4 ステップで進める

  • コンソール上の「プロジェクトのサンドボックス」で、次の 4 ステップで進めます。
    • 対象のアプリの範囲を選ぶ（VCN とサブネット）
    • 提案された属性を確認する（リソースのグループと割り当て）
    • 提案されたポリシーを調整する（各文をアプリの必要に合わせる）
    • 評価して、書き出す（カバーの範囲を確認して、確認済みの設定をエクスポート）

使いどころは 3 つのライフサイクル

  • スライドでは、次の 3 つの使いどころが示されていました。
    • ZPR を採用する：既存の NSG とセキュリティリストを提案の出発点にする。
    • 新しいアプリを作る：つなぎたい通信に合わせて、属性とポリシーを定義する。
    • 動いているワークロードを変える：既存の ZPR の設定を取り込み、デプロイ前にポリシー変更を評価する。
  • 書き出す設定は JSON で、「Reuse your existing infrastructure change process」。いつもの変更の手順で、本番に適用します。

AI 推奨とプレビューモード

  • 既存の NSG やセキュリティリストの構成を分析して、ZPR の属性とポリシーを提案する、AI ベースの推奨エンジンがあります。最終的に決めるのは人です。本番に適用する前に、評価のログを確認できるプレビューモードも提供されます。

今後のロードマップ

  • リージョンをまたぐ（Cross-Region）、テナンシーをまたぐ（Cross-Tenancy）、グローバルな ZPR の制御への拡張が計画されている、と説明されました。将来の機能は、変更される可能性があります。

まとめ

  • ZPR は、IP アドレスとポートで書いていたセキュリティを「誰が何につながってよいか」という意図で書き直す仕組みです。既存の SL / NSG の上に重ねて使えるため、段階的に導入できます。
  • 今回のセッションで学んだことを3 点にまとめます。
    • 意図で書く：セキュリティ属性とポリシーで通信を許可する。複数の VCN をまたいでも 1 つのポリシーで書け、ネットワークの構成が変わっても意図は変わらない。
    • 重ねて、絞る：SL / NSG の上に ZPR を重ねて使う。PSA と IAM Deny で出口も塞ぐ。「ZPR で許可したのに通らない」ときの切り分けは NPA で行う。
    • 安全に入れる：Deny は Allow より先に評価される。ZPR Deny が使えるようになったら、止めたい通信だけ先に Deny を足す入り方もできる。Workbench のプレビューで確かめてから、本番に入れる。

おわりに

  • これまでの OCI のネットワークセキュリティは、IP アドレスやポート単位でアクセスを制御する Security List（SL）や Network Security Group（NSG）が中心でした。システムの規模が大きくなり、インスタンスが増えるほど、ルールも増え続けて複雑になりがちです。
  • ZPR は、属性をもとに通信を制御することで、「誰が何につながってよいか」を読める形で管理できる仕組みです。今回のセッションは、基本の考え方に加えて、複数 VCN への対応、PSA や IAM Deny との組み合わせ、ZPR Deny、Workbench まで、ZPR の基本と最新アップデートをまとめて学べる内容でした。
  • 特に印象に残ったのは、SL / NSG を置き換えずに重ねて使えることです。ZPR Deny が使えるようになれば、止めたい通信の Deny だけを先に足したり、Workbench のプレビューで確かめてから本番に入れたりと、既存の環境を作り直さずに段階的に始められます。