OCI Network Firewall

解決する課題

• VCN を出入りする通信や VCN 内の East-West 通信を一元的に検査・制御したい
• セキュリティリストやネットワークセキュリティグループ (NSG) だけでは難しい L7（アプリケーション層）の制御（FQDN/URL フィルタ、アプリ識別）を行いたい
• 仮想マシン上で自前のファイアウォール製品を運用する可用性・パッチ・スケールの負担を避けたい
• 侵入検知・防御 (IDS/IPS) や暗号化通信の中身の検査 (SSL インスペクション) をマネージドに実現したい
• 送信先 FQDN によるアウトバウンド制御でデータ持ち出しや不審な外部接続を抑止したい

主要概念と用語

• Network Firewall（ネットワークファイアウォール）: VCN のサブネット内に配置されるマネージドなファイアウォールリソース。OCI が冗長化・スケール・パッチを運用
• Network Firewall Policy（ポリシー）: 検査ルールの集合（ルール本体）。ファイアウォール本体（実行エンティティ）とポリシー（ルール定義）が分離され、1つのポリシーを複数のファイアウォールへ適用可能
• Security Rule（セキュリティルール）: 送信元/宛先・アプリケーション・サービス・URL などの条件にもとづき、通信を 許可 / ドロップ / 拒否 / 検査 するルール
• Application（アプリケーション）: プロトコルとポートで定義するアプリの種類。L7 のアプリ識別に用いる
• URL List / FQDN（URL リスト）: 許可・拒否する宛先 URL や FQDN の一覧。アウトバウンドのドメインフィルタに使う
• Decryption Rule / SSL インスペクション: TLS 通信を一旦復号して中身を検査する設定。Vault の証明書・鍵と連携
• Threat Intelligence / IPS シグネチャ: 既知の脅威や攻撃パターンを検出する署名ベースの検査機能
• ルーティング誘導: ファイアウォールは透過的に挟まるのではなく、ルートテーブルで対象トラフィックをファイアウォールの IP（プライベート IP）へ向けて検査させる

仕様・制限・クォータ

• リージョン内・VCN 内のリソースで、専用のファイアウォールサブネットに配置するのが基本構成
• 検査対象トラフィックはルートテーブルでの経路誘導により流す。ファイアウォール自身が経路上のネクストホップになる
• 1つの ポリシーを複数のファイアウォールに再利用でき、ルールの一元管理が可能
• 処理スループットには容量の上限があり、想定スループットに応じたサイジングが必要（大容量要件では設計時に見積もる）
• SSL インスペクションには **Vault（証明書・鍵）**との連携が必要で、復号対象が増えると CPU 負荷とレイテンシが増える
• 具体的なルール数やスループットの上限値は変動するため、最新のサービス制限はドキュメントとサービス制限ページで確認する

内部の仕組み

OCI Network Firewall はマネージドな実行基盤として提供されます。利用者はファイアウォール本体と、それに適用する**ポリシー（ルール定義）**を作成します。検査したいトラフィックは透過挿入ではなく、ルートテーブルのネクストホップをファイアウォールのプライベート IP に向けることで誘導します。たとえばインターネットへ出る通信を検査したい場合、サブネットのルートを「インターネットゲートウェイ」ではなく「ファイアウォール経由」に変更し、検査後にゲートウェイへ抜けるよう経路を組みます。

通信が到達すると、ファイアウォールはステートフルに L3/L4 から L7 まで評価します。送信元・宛先・ポートといった基本条件に加え、アプリケーション識別・URL/FQDN フィルタ・IPS シグネチャによる検査を行い、ルールにもとづいて許可・ドロップ・拒否します。TLS 通信は Decryption Rule により復号して中身を検査し、再暗号化して転送できます（このとき Vault に保管した証明書・鍵を用いる）。

冗長性・スケール・パッチ適用は OCI 側が担うため、利用者は仮想アプライアンスの運用を意識する必要がありません。検査ログやイベントは OCI Logging に出力でき、許可・ブロックの可視化に使えます。

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

• ファイアウォール専用のサブネットを分離し、検査対象サブネットからのルートをファイアウォールへ誘導するハブ&スポーク型を採る
• **North-South（インターネット出入り）**と **East-West（VCN/サブネット間）**で必要な検査を整理し、過剰検査による性能劣化を避ける
• アウトバウンドはFQDN/URL の許可リスト方式で最小化し、データ持ち出しや C2 通信を抑止する
• ポリシーを環境（本番/検証）や用途ごとに分割しつつ、共通ルールは1ポリシーに集約して再利用する
• セキュリティリスト / NSG（L3/L4 の基本制御）と役割分担し、ファイアウォールは L7 や IPS など付加価値の高い検査に集中させる
• SSL インスペクションは機微通信に限定し、復号対象を絞ってコストとレイテンシを管理する

運用・監視

• 検査ログ（許可・ドロップ・脅威検知）を OCI Logging に出力し、ブロック傾向や誤検知を継続監視する
• OCI Monitoring / Events と連携し、スループット逼迫や異常検知時に Notifications / Functions で自動対応する
• ポリシー変更は段階的に適用し、まずは検知（検査のみ）で影響を確認してから防御（ドロップ）へ移行する
• 通信不達のトラブル時は ルートテーブルの経路誘導・セキュリティリスト/NSG・ファイアウォールルールの3層を順に切り分ける
• SSL インスペクション利用時は証明書の有効期限を Vault と合わせて管理し、失効による通信断を防ぐ

コスト

セキュリティ

• L3/L4 だけでは捉えられない L7（アプリ識別・URL/FQDN）と IPS による多層防御を実現する
• アウトバウンドの FQDN/URL 許可リストでデータ持ち出しや不審な外部接続を制限する
• SSL インスペクションで暗号化通信内に潜む脅威も検査でき、Vault と連携して証明書・鍵を安全に扱う
• IAM ポリシーで最小権限を徹底し、ファイアウォール・ポリシーの管理権限を運用者に限定する
• セキュリティリスト / NSG と併用し、基本制御（L3/L4）と高度検査（L7/IPS）を役割分担する
• すべての管理操作は OCI Audit、通信検査は OCI Logging に記録して追跡可能にする

Well-Architected の観点

• セキュリティ: L7 検査・IPS・URL フィルタにより、ネットワーク境界とサブネット間の防御を強化。マネージドゆえにパッチ遅延のリスクを下げる
• 経路設計と最小権限を組み合わせ、検査されないバイパス経路を作らないことが境界防御の前提になる
• 運用面ではログとイベントで可視化し、検知から防御へ段階移行することで変更リスクを抑える

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1. ファイアウォールポリシー（ルール定義）を作成
oci network-firewall network-firewall-policy create \
  --compartment-id <compartment-ocid> \
  --display-name web-egress-policy

# 2. 許可する宛先 FQDN/URL のリストをポリシーに追加（アウトバウンド制御）
oci network-firewall url-list create \
  --network-firewall-policy-id <policy-ocid> \
  --name allowed-domains \
  --urls '[{"pattern":"*.example.com","type":"SIMPLE"}]'

# 3. ファイアウォール本体を専用サブネットに作成し、ポリシーを適用
oci network-firewall network-firewall create \
  --compartment-id <compartment-ocid> \
  --display-name vcn-fw \
  --network-firewall-policy-id <policy-ocid> \
  --subnet-id <firewall-subnet-ocid>

# 4. 作成したファイアウォールのプライベート IP を確認（ルート誘導先に使う）
oci network-firewall network-firewall get \
  --network-firewall-id <firewall-ocid> \
  --query 'data."ipv4-address"'

# 5. 検査したいサブネットのルートテーブルを更新し、
#    宛先 0.0.0.0/0 のネクストホップをファイアウォール IP に向ける
oci network route-table update \
  --rt-id <route-table-ocid> \
  --route-rules '[{"destination":"0.0.0.0/0","destinationType":"CIDR_BLOCK","networkEntityId":"<firewall-private-ip-ocid>"}]'