Zero Trust Packet Routing

解決する課題

• セキュリティリストや NSG の CIDR/ポート規則が複雑化し、誰がどの通信を許可したのか追えなくなる
• サブネット分割やルート変更などの ネットワーク構成変更・誤設定で、意図しない経路が開いてしまう
• 機密データを持つリソースへの通信を、IP アドレスや経路ではなく「役割（意図）」で表現したい
• 「DB には App だけが届く」といった ゼロトラストの原則をネットワーク層で強制したい
• 監査時に「なぜこの通信が許可されているか」を、読みやすいポリシー文で説明したい

主要概念と用語

• Zero Trust Packet Routing（ZPR）: リソースに付けた属性どうしの通信可否を意図ベースのポリシーで宣言し、ネットワーク層で強制する OCI のサービス。経路設定とは独立に効く
• セキュリティ属性（Security Attribute）: リソースに付与するラベル（キーと値）。「役割」を表し、ZPR ポリシーが許可判定に使う最小単位
• セキュリティ属性ネームスペース（Security Attribute Namespace）: 複数のセキュリティ属性をまとめる入れ物。属性の管理境界と命名の単位になる
• ZPR ポリシー（ZPR Policy）: 「どの属性を持つリソースが、どの属性を持つリソースへ、どのプロトコル/ポートで通信できるか」を宣言する規則。許可を積み上げる方式
• 意図ベース（Intent-based）: IP/CIDR ではなく属性（役割）で通信を表現する考え方。アドレスやサブネットが変わってもポリシーは壊れない
• 強制点（Enforcement）: ZPR はアクセス要求のたびに属性とポリシーを照合して許可/拒否する。セキュリティリストや NSG とは別レイヤーで作用する
• デフォルト拒否: ZPR を適用したリソース間では、ポリシーで明示的に許可された通信のみが成立する（タグなしや非許可は通らない）

仕様・制限・クォータ

• ZPR は VCN 内のリソース間通信を対象にした制御で、対応リソースにセキュリティ属性を付与して使う
• セキュリティ属性は ネームスペース配下のキー/値として定義し、リソースへ付与する。属性はタグと似た付与モデルだが、ZPR 専用に判定へ使われる
• ZPR ポリシーは セキュリティリスト/NSG とは独立して評価される。両方が通信を許可して初めて通る（どちらかが拒否すればブロック）
• 適用範囲・対応リソース種別・属性数やポリシー数の 上限は変動するため、最新のサービス制限とリージョン提供状況はドキュメントとサービス制限ページで確認する
• ポリシー言語は 人間が読める宣言文で記述し、属性とプロトコル/ポートを指定する
• 具体的な対応サービスやクォータ値は拡張されていくため、断定せず最新情報を参照する

内部の仕組み

ZPR は 属性（ラベル）とポリシーという2つの要素で成り立ちます。まず保護したいリソース（例: データベースやアプリケーション層のリソース）に セキュリティ属性を付与します。属性は「db」「app」のような役割を表すラベルで、セキュリティ属性ネームスペースの下にキー/値として定義します。次に ZPR ポリシーで「app 属性を持つリソースは、db 属性を持つリソースへ指定ポート/プロトコルで通信できる」といった許可を宣言します。

通信が発生するたびに、ZPR は 送信元と宛先の属性を見てポリシーと照合し、許可されていれば通し、なければ拒否します。重要なのは、この判定が ルートテーブルやサブネット構成とは独立している点です。誰かがサブネットを足したり経路を変えたりしても、属性とポリシーが変わらない限り許可される通信は変わりません。これにより、ネットワーク構成の誤設定が「意図しない開通」につながりにくくなります。

ZPR は セキュリティリスト/NSG を置き換えるものではなく、上に重ねるレイヤーです。最終的に通信が成立するには、ZPR ポリシーとセキュリティリスト/NSG の 両方が許可している必要があります。どちらか一方でも拒否すれば通信はブロックされます。

設計パターン / ベストプラクティス

• まず 役割の棚卸しを行い、機密データを持つリソース（DB など）と、それにアクセスする層（App など）を属性で明確に分ける
• 属性の 命名規約とネームスペース設計を先に決め、チーム/環境ごとに一貫させて運用負荷を下げる
• 通信は 最小限の許可を積み上げる方針にし、広すぎる許可（全許可）を避ける
• ZPR とセキュリティリスト/NSG の 役割分担を決める。ZPR は意図（役割間）を、セキュリティリスト/NSG は基本の到達制御を担うと整理しやすい
• 本番投入前に 検証環境でポリシーを検証し、想定どおりの通信だけが通ることを確認してから広げる
• 機密リソースは デフォルト拒否を前提に、明示許可された通信以外を通さない設計にする

運用・監視

• ポリシーと属性の変更は OCI Audit に記録されるため、いつ誰が許可範囲を変えたかを追跡する
• 通信不達のトラブル時は、ZPR ポリシー・セキュリティリスト/NSG・ルートテーブルの3層を順に切り分ける（両レイヤーの許可が必要な点に注意）
• 属性の付与漏れがあると意図した通信が通らないため、リソース作成時に属性付与を組み込む（IaC/タグ運用に組み込む）
• ポリシー変更は 段階的に適用し、まず狭い範囲で挙動を確認してから本番へ展開する
• 機密データ経路は 定期的にポリシーをレビューし、不要になった許可を削除して許可範囲を最小に保つ

コスト

セキュリティ

• 機密リソースへの通信を 意図（役割）ベースで明示許可し、許可されない通信はデフォルト拒否にする
• ネットワーク構成の誤設定（サブネット追加・ルート変更）があっても、属性とポリシーが変わらなければ意図しない開通を防げる
• セキュリティリスト/NSG と 多層防御を構成し、両レイヤーの許可がそろって初めて通信を許す
• 属性とポリシーの管理権限は IAM の最小権限で運用者に限定し、許可範囲の不用意な拡大を防ぐ
• すべての管理操作は OCI Audit に記録し、許可範囲の変更を追跡可能にする
• ゼロトラスト原則（暗黙の信頼を置かない）を ネットワーク層で強制できる

関連サービス・比較

ハンズオン / CLI例

# 1. セキュリティ属性ネームスペースを作成（属性の入れ物）
oci zpr security-attribute-namespace create \
  --compartment-id <compartment-ocid> \
  --display-name app-tier \
  --description "ZPR security attributes for app and db tiers"

# 2. ネームスペース配下にセキュリティ属性（役割ラベル）を定義
oci zpr security-attribute create \
  --security-attribute-namespace-id <namespace-ocid> \
  --name role \
  --description "Resource role used by ZPR policies"

# 3. ZPR ポリシーを作成（属性間の許可を宣言）
#    実際のポリシー文は属性とプロトコル/ポートを指定して記述する
oci zpr zpr-policy create \
  --compartment-id <compartment-ocid> \
  --name app-to-db \
  --statements '["in VCN allow app-tier.role=app to connect to app-tier.role=db with protocol=tcp port=1521"]'

# 4. 作成済みの ZPR ポリシーを一覧で確認
oci zpr zpr-policy list \
  --compartment-id <compartment-ocid>