はじめに

OCIのネットワークセキュリティには、IPアドレスやPortレベルでアクセス制御を行うSecurity List（SL）や
Network Security Group（NSG）があります。

これらはL3/L4レイヤにおける通信制御として広く利用されていますが、
システム規模の拡大やインスタンス数の増加に伴い、ルールが増え続けて複雑化するケースも少なくありません。

そのような背景のもと、OCIではZero Trust Packet Routing（ZPR）という
属性ベースの通信制御機能が提供されています。

ZPRでは、IPアドレスではなくセキュリティ属性（namespace.key:value 形式のラベル）を
エンドポイントに付与し、その属性をポリシーで参照することで通信を制御します。

大規模構成や拡張性を考慮した設計においては、

  • IP変更の影響を受けにくい
  • スケールアウトに強い
  • 設計時に整理した通信用件を、そのままポリシーとして表現できる

といった利点があります。

本記事では、ZPRの構築手順について確認していきます。

デモ環境設定

事前に以下を構築済み

  • VCN: demovcn
  • Subnet: PublicSubnet, PrivateSubnet
  • SL: デフォルト
  • NSG: なし
  • Compute:
    • web(10.0.1.155)
    • appA(10.0.0.137)
    • appB(10.0.0.108)

検証用の通信要件

  • web → app A(通る)
  • web → app B(通らない)

SL(Default)

イングレス: SSH,ICMP許可

エグレス: 全て許可

今回はZPRでのアクセス制御を確認する目的のためNSGはアタッチせずSSH接続で確認します。

検証

まずはZPRを設定する前に確認します。

webからappAおよびappB、appAからappBにssh接続してみます。

[opc@web ~]$ ssh 10.0.0.137
Activate the web console with: systemctl enable --now cockpit.socket
Last login: Sat Feb 21 07:00:10 2026 from 10.0.1.155
[opc@appa ~]$
[opc@web ~]$ ssh 10.0.0.108
Activate the web console with: systemctl enable --now cockpit.socket
Last login: Sat Feb 21 06:59:54 2026 from 10.0.1.155
[opc@appb ~]$
[opc@appa ~]$ ssh 10.0.0.108
Activate the web console with: systemctl enable --now cockpit.socket
Last login: Sat Feb 21 07:04:27 2026 from 10.0.1.155
[opc@appb ~]$
[opc@appb ~]$ ssh 10.0.0.137
Activate the web console with: systemctl enable --now cockpit.socket
Last login: Sat Feb 21 07:07:13 2026 from 10.0.0.108
[opc@appa ~]$

全て問題なくアクセスできました。

セキュリティ属性ネームスペース作成


ではZPRの設定をしていきます。
テナンシで初めて利用する場合はZPRを有効化する必要がありますのでご留意ください。
ZPRが有効化されている状態でセキュリティ属性ネームスペースを作成します。

今回はdemo-zpr-nsという名前で作成しています。

セキュリティ属性作成


セキュリティ属性を作成します。

Compute用にList形式で作成しました。
そしてVCN用にも必要なので合わせて作成しておきます。

ポリシー作成


ポリシーを作成します。
ここで注意が必要なのですが、ポリシー作成前にセキュリティ属性をリソースにアタッチしてしまうとデフォルトdenyの挙動によって全ての通信が遮断されてしまいます。
そのためセキュリティ属性アタッチ前に必ずポリシーを作成しましょう。

IAMポリシーと形式が異なるので慣れるまでは少し戸惑うかもしれません。
基本構文は以下のようになります。

<src-location> <command> <endpoint> to <verb> <endpoint>

そのため今回作成したポリシーは以下のようになります。

in demo-zpr-ns.Network:demovcn VCN allow demo-zpr-ns.compute:web endpoints to connect to demo-zpr-ns.compute:appA endpoints with protocol='tcp/22'
in demo-zpr-ns.Network:demovcn VCN allow 'ローカルPCのIP/32' to connect to demo-zpr-ns.compute:web endpoints with protocol='tcp/22'

ここで2行めのローカルPCからアクセスを許可する設定を入れないとwebにアクセス出来なくなりますので注意してください。

セキュリティ属性付与


では各リソースに属性を付与していきます。
VCN、Computeどちらも詳細画面にセキュリティタブから設定します。
参考にCompute画面は下記のようになります。

確認

[opc@web ~]$ ssh 10.0.0.137
Activate the web console with: systemctl enable --now cockpit.socket
Last login: Sat Feb 21 08:26:38 2026 from 10.0.1.155
[opc@appa ~]$
[opc@web ~]$ ssh 10.0.0.108
ssh: connect to host 10.0.0.108 port 22: Connection timed out
[opc@web ~]$

webからappA以外のssh接続は出来なくなりました。

まとめ

今回はOCIのZPRを用いて、セキュリティ属性に基づく以下の通信制御の挙動を確認しました。

  • セキュリティ属性を付与したエンドポイントはZPRの評価対象となる
  • ポリシーで明示的に許可されていない通信は成立しない
  • 外部からのSSH通信も、属性が付与されている場合はZPRで評価される

特に印象的だったのは、webインスタンスにセキュリティ属性を付与したところ、
外部からのSSH接続ができなくなる点でした。

これはZPRが「内部通信のみ」を対象とするのではなく、
属性が付与されたエンドポイントに対する通信を評価する仕組みであることを示しています。

今後はSLやNSGと適切に役割分担しながら、より実践的で安全性の高いネットワークセキュリティ設計を検討していきたいと考えています。