OCI Security Zones

解決する課題

• 公開バケット・非暗号化ボリューム・パブリックサブネットなど、危険な構成のリソースをそもそも作らせたくない
• 検知して直す（事後対応）だけでは、違反リソースが一時的にでも存在する隙が生まれる → 作成・更新の時点でブロックしたい
• 規制対象や本番の機密データを置くコンパートメントで、セキュリティ要件を技術的に強制したい（口頭ルールやレビュー任せにしない）
• 顧客管理鍵の利用、ゾーン外へのリソース移動禁止など、組織のセキュリティ標準を一律に効かせたい

主要概念と用語

• セキュリティゾーン（Security Zone）: コンパートメントとセキュリティゾーンレシピの関連付け。そのコンパートメント（および配下のサブコンパートメント）内のリソース操作が、レシピのポリシーで検証される。1つのコンパートメントに紐づけられるセキュリティゾーンは1つだけ
• セキュリティゾーンレシピ（Security Zone Recipe）: ゾーンに適用するセキュリティゾーンポリシーの集合。Oracle 管理の定義済みレシピをそのまま使うか、ポリシーを選んでカスタムレシピを作る
• Maximum Security Recipe: Oracle が用意する定義済みの最大セキュリティレシピ。厳選されたポリシー群を含み、変更不可。まずこれを当てるのが基本
• セキュリティゾーンポリシー（Security Zone Policy）: 「公開バケットを禁止」「ブロックボリュームは暗号化必須」「ゾーン外へリソースを移動しない」といった個々の要件。有効なポリシーに違反する操作は自動的に拒否される
• IAM ポリシーとの違い: IAM ポリシーは権限を付与するもの。セキュリティゾーンポリシーは権限ではなく、操作がセキュリティ要件に適合するかを検証するもので、目的が異なる
• 対象リソース種別: Compute、Networking、Object Storage、Block Volume、Database など、ポリシーが適用される OCI のリソース群

仕様・制限・クォータ

• セキュリティゾーンの利用には Cloud Guard の有効化が前提。両者は連携して動く
• 1コンパートメント = 1セキュリティゾーン。同じコンパートメントに複数のゾーンは紐づけられない
• Oracle 管理の Maximum Security Recipe は変更不可（読み取り専用）。要件を調整したい場合はカスタムレシピを作る
• ポリシーは作成・更新の時点で検証され、違反すると操作自体がエラーで拒否される（事前のブロック）
• ゾーン有効化以前から存在していた違反リソースは作成時にブロックできないため、Cloud Guard 側で検知する役割分担になる
• どのポリシーが利用可能か、どのリソース種別を対象にできるかはリージョンやサービスの対応状況で変わりうるため、最新は公式ドキュメントで確認する

内部の仕組み

セキュリティゾーンは「危険な操作を最初から拒否する」予防的（事前）の仕組みです。コンパートメントにセキュリティゾーンレシピを関連付けると、そのコンパートメント配下でのリソース作成・更新の操作が、レシピに含まれるポリシーのリストに照らして検証されます。

1. 対象コンパートメントにセキュリティゾーンレシピを関連付ける
2. ゾーン内でリソースの作成・更新が行われると、OCI が全ポリシーに対して操作を検証する
3. いずれかのポリシーに違反していれば、その操作は拒否され、エラーが返る（例: 公開バケットを作ろうとすると失敗する）
4. ゾーン作成時に Cloud Guard 上にセキュリティゾーン用のターゲットが自動作成され、既存リソースの違反は検知側で監視される

つまり「新規・変更は予防（拒否）でブロック」「既存は Cloud Guard が検知」という二段構えになっており、ゾーンを有効化した瞬間からの操作は通さず、過去に作られたものは可視化して直す流れになります。

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

• 重要コンパートメントにまず Maximum Security Recipe を適用し、最大の保護から始める。要件と合わない点だけカスタムレシピで調整する
• 段階導入: いきなり本番全体に当てず、新規・小さなコンパートメントで挙動を確認してから広げる。既存リソースの違反が多いと正規の運用操作まで弾かれうるため
• ゾーン化前に既存リソースを棚卸し: 既存の違反を Cloud Guard で洗い出し、ゾーン適用後の運用が止まらないよう先に是正する
• 顧客管理鍵・暗号化必須などのポリシーをカスタムレシピで明示し、組織標準を技術的に強制する
• ゾーン外への移動禁止ポリシーで、保護下のリソースが非保護コンパートメントへ抜けるのを防ぐ
• Cloud Guard の検知と組み合わせ、予防（拒否）と検知（修復）の両輪でコンパートメントを守る

運用・監視

• 拒否されたリソース操作はエラーとして利用者に即時に返るため、なぜ作成・更新できないかは違反したポリシーを確認して切り分ける
• ゾーン化以前から存在する違反は **Cloud Guard の問題（Problem）**として上がるので、検知側のダッシュボードで追う
• 正規の運用が頻繁に弾かれる場合は、当てているレシピのポリシーが運用と整合しているかを見直し、必要ならカスタムレシピで調整する
• OCI Audit に操作が記録されるため、拒否された操作や設定変更の経緯を追跡できる
• レシピ変更の影響範囲は配下のサブコンパートメント全体に及ぶ点に注意し、変更は影響を見積もってから行う

コスト

セキュリティゾーンは Cloud Guard の機能の一部として提供され、追加料金なしで利用できます。前提となる Cloud Guard の標準機能も無料のため、まず有効化のハードルは低いのが特徴です。ただし、ゾーン内で稼働させるリソース自体（Compute、Block Volume、Database など）は通常どおり課金され、ポリシーで必須化した暗号化や顧客管理鍵を支える Vault などの関連サービスには、それぞれの料金が発生します。

セキュリティ

• 予防的ガードレール: 公開・非暗号化・パブリック露出などの危険な構成を作成時点でブロックし、違反リソースが存在する隙そのものを無くす
• 技術的な強制: レビューや口頭ルールに頼らず、コンパートメント単位でセキュリティ要件を機械的に適用する
• 多層防御の一部: IAM（誰が操作できるか）とは別軸で、操作の中身がセキュリティ標準に適合するかを検証し、IAM・Vault・Cloud Guard と補完しあう
• 機密データの保護: 規制対象や本番の機密データを置くコンパートメントを Security Zone 化し、暗号化や非公開を逸脱できない形で担保する
• 既存は検知で補完: ゾーン化以前の違反は予防できないため、Cloud Guard の検知と必ず併用する

関連サービス・比較

セキュリティゾーンは Cloud Guard と表裏一体です。Cloud Guard が「検知して直す（事後）」のに対し、Security Zone は「違反操作を拒否する（事前）」役割を担い、重要コンパートメントでは両方を組み合わせます。

ハンズオン / CLI例

# 0. 前提: Cloud Guard が有効化されていること

# 1. 利用可能なセキュリティゾーンレシピを確認（Maximum Security Recipe を含む）
oci cloud-guard security-recipe list \
  --compartment-id <tenancy-or-compartment-ocid>

# 2. コンパートメントにセキュリティゾーンを作成し、レシピを関連付ける
#    （Maximum Security Recipe の OCID を指定して最大保護から始める）
oci cloud-guard security-zone create \
  --compartment-id <protected-compartment-ocid> \
  --display-name prod-security-zone \
  --security-zone-recipe-id <maximum-security-recipe-ocid>

# 3. 作成したセキュリティゾーンの一覧と状態を確認
oci cloud-guard security-zone list \
  --compartment-id <protected-compartment-ocid>

# 4. 独自要件がある場合はカスタムレシピを作成し、
#    含めるポリシーの OCID を指定する
oci cloud-guard security-recipe create \
  --compartment-id <compartment-ocid> \
  --display-name custom-security-recipe \
  --security-policies '["<policy-ocid-1>","<policy-ocid-2>"]'