OCIセキュリティ実践Vol1｜5サービスゼロトラスト統制E2E

1. この記事について — 5サービス統合のゼロトラスト統制E2E

OCIのセキュリティ関連サービスは、個々に見ればAWSのKMS・SSM Session Manager・WAF・GuardDuty・SCP的な予防統制に近い役割を持つサービスです。暗号鍵を管理するVault、踏み台レスで接続できるBastion、境界防御を担うWAF、脅威を検出するCloud Guard、そして予防的にポリシーを強制するSecurity Zones——個々の機能だけを追うのであれば、AWSでこれらに相当するサービスを運用してきたエンジニアにとって理解は難しくありません。しかし、単体理解だけでは「ゼロトラスト統制」として機能せず、実際にはこれらのサービスを結線し、検出(Cloud Guard)と予防(Security Zones)を両輪として回すことで初めて統制として意味を持ちます。本記事は、「OCIセキュリティ実践」シリーズの第1弾として、Vault(暗号鍵管理)・Bastion(踏み台レス接続)・WAF(境界防御)・Cloud Guard(検出)・Security Zones(予防)の5サービスを実際に結線し、ゼロトラスト統制のE2Eを体験することを通じて、OCIにおけるセキュリティ実践の勘所を掴んでもらうことを目的としています。

ただし、上記の対応マップはあくまで「大まかな役割の近さ」を示したものであり、名前の対応だけを頼りに設計を進めると足元をすくわれます。特に、AWSのGuardDuty・Security Hub・Configが担う検出型の機能と、SCP的な予防統制の機能は、OCIではCloud GuardとSecurity Zonesという「検出」と「予防」で明確に役割が分かれた2つのサービスに割り当てられています。この構造差の詳細は§3で改めて整理します。

「OCI入門」シリーズが基礎を固める記事群であるのに対し、前作「OCI可観測性・運用監視実践 Vol1」および本記事は、その基礎の上に実践・運用レベルの深さを積み上げる位置づけの記事群です。運用監視(前作)の次にセキュリティ統制(本記事)を扱うのは、実際のシステム運用が「まず可観測性を確保し、その上でセキュリティ統制を固める」という順序で進むことが多いためでもあります。

1-1. 本記事のゴール

本記事は、「OCIセキュリティ実践」シリーズの第1弾として、Vault・Bastion・WAF・Cloud Guard・Security Zonesの5サービスを結線し、実際に動くゼロトラスト統制のE2Eを構築することをゴールとしています。具体的には、Vaultでマスター暗号鍵を作成しシークレットを保存/取得した上で、Bastionでprivateサブネットへセッション接続し、WAFでFlexible LBへの境界防御を設定、さらにCloud Guardで検出型統制を、Security Zonesで予防型統制を、それぞれ実演します。

本記事における「動いている状態」の定義は§2-3で改めて明確にしますが、大枠としては、Vaultで作成した鍵とシークレットが実際に取得できること、Bastion経由でprivateサブネットのインスタンスに接続できること、WAFのポリシーがFlexible LBにアタッチされ保護ルールが機能していること、Cloud Guardが問題を検出できること、Security Zonesが違反となる操作を実際にブロックすることを指します。

本記事の推奨環境をPay As You Go(PAYG)テナンシとしているのは、5サービスのうちCloud GuardとWAFが純粋なAlways Freeテナンシでは利用できないためです(詳細は§2-2・§9)。VaultとBastionは完全無償で利用できますが、Cloud Guardは公式に「有償テナンシでのみ無償」とされており、WAFはOracleが公開しているAlways Freeリソースの一覧に含まれていません。5サービスを結線したE2Eを最後まで実演するには、PAYGへの移行が事実上の前提になります。

本記事を読み終えると、次の状態になっていることを目指しています。

• Vaultでマスター暗号鍵を作成し、シークレットの保存・取得を自分の手で実演できる
• Bastionを使い、パブリックIPを持たないprivateサブネットのインスタンスへセッション接続できる
• WAFをFlexible LBへアタッチし、保護ルール・レート制限を設定できる
• Cloud Guardを有効化し、detector/responderレシピによる検出型統制を説明できる
• Security Zonesをコンパートメントへ適用し、レシピによる予防型統制と検出型統制(Cloud Guard)の違いを説明できる

1-2. 読者像

本記事は、前作「OCI可観測性・運用監視実践 Vol1」を完遂済みの読者、または前作を未読でも、AWSでKMS・SSM Session Manager・WAF・GuardDutyのいずれかを実務で運用した経験があり、OCIでの対応実装を実務レベルで知りたいエンジニアを主な想定読者としています。

前作を完遂済みの読者は、運用監視の基盤がすでに整った状態からセキュリティ統制の結線を確認できるため、本記事の§4以降をより実感を持って進められます。一方、前作を未読でもAWSでのセキュリティ運用経験があれば、本記事単体でも実践に支障はありません。なお、OCIそのものが初めての方(テナンシのサインアップすら済んでいない方)は、まず「OCI入門」シリーズVol1(テナンシ・コンパートメント・Always Free枠)から着手することをお勧めします。

逆に言えば、本記事はIAMポリシーの基礎(「OCI入門」シリーズVol2)や、NSG・セキュリティリストといったネットワーク層基礎(「OCI入門」シリーズVol3)までは前提としません。console(コンソール)操作を軸に、AWSでの経験を足がかりとしながらOCIのVault・Bastion・WAF・Cloud Guard・Security Zonesを理解できる構成としています。

特に、次のような疑問を持つ方に向けて、本記事は具体的な答えを用意しています。

• OCIのVaultは、AWSのKMSと同じ感覚でマスター鍵とシークレットを管理できるのか
• BastionはAWSのSSM Session Managerと比べて、踏み台レス接続としてどこまで同等の使い勝手なのか
• Cloud GuardとSecurity Zonesは何が違い、両方とも有効化すべきなのか
• 純粋なAlways Freeテナンシだけで、この記事の内容を最後まで実践できるのか
• OCI WAFには現行世代とレガシーのEdgeポリシーが併存すると聞いたが、どちらを使えばよいのか

こうした読者は、多くの場合「まずAWSで運用してきたセキュリティ統制構成をそのままOCIに置き換えられるか試したい」という動機で本記事にたどり着きます。その際、最初につまずきやすいのが、GuardDutyという検出型サービスの感覚のまま、OCI側でも検出と予防が一体化したサービスを探してしまうことです。本記事は、この「検出(Cloud Guard) vs 予防(Security Zones)」という設計思想の違いを早い段階で明示し、名前の類似に惑わされず実際の役割を基準にサービスを理解し直すことを狙いとしています。

また、AWSでKMS・Secrets Managerを別サービスとして運用してきた読者にとっては、OCIのVaultが鍵管理とシークレット管理を1サービスに統合している点も、実務での設計判断に影響する差分です。この違いは§3で改めて整理しますが、読者像としては、こうした「サービス境界の引き方の違い」に興味を持てる層を想定しています。

1-3. なぜ今これを書くか

本記事を今このタイミングで書く理由は、大きく3点あります。

1つ目は、5サービスをE2Eで結線し統制として実演する記事が、現時点のWeb検索では見当たらないことです。個々のサービスの単体チュートリアルは存在しても、Vault→Bastion→WAF→Cloud Guard→Security Zonesという5サービスを、AWS実務者向けの対応マップと料金の正確性の両面から一気通貫で扱う記事は稀であり、本記事はこの空白を埋めることを目指します。

2つ目——そして本記事の差別化の核となるのが、料金構造の正確性です。本シリーズは、前々作「OCI Functions & API Gatewayサーバーレス実践 Vol1」(課金必須・Functions/API GatewayともAlways Free対象外)、前作「OCI可観測性・運用監視実践 Vol1」(完全0円・Always Free枠内で完結)に続き、本記事を「PAYG推奨」の最終形として位置づける3部作対比構造を持っています(詳細は§9)。Vault・Bastionは確実に無料である一方、Cloud Guardは公式FAQで「純Always Freeテナンシでは利用不可・有償テナンシのみ無償」とされ、WAFも公式のAlways Freeリソース一覧には掲載されていません。この非対称性を正確に整理して伝えることが、本記事の価値の中核です。

3つ目は、「検出(Cloud Guard)vs予防(Security Zones)」という統制思想の対比軸です。GuardDuty・Security Hub・Configといった検出型の仕組みに慣れたAWS実務者にとって、Security Zonesのような予防型(違反となる操作自体をブロックする)統制は、感覚的に馴染みが薄いかもしれません。本記事は、この2つの統制思想の違いを、実際に両方を有効化して比較する形で明示します。

この3つの軸——空白の充足・料金構造の正確性・統制思想の対比——が、本記事を今このタイミングで書く理由です。

→ 前作はこちら: OCI可観測性・運用監視実践 Vol1 — Connector Hub(旧称:Service Connector Hub)実践

本記事は、次の範囲についてはあえて深掘りせず、既存記事・今後公開予定の記事に委譲します。いずれも本記事の§4以降(同一記事内)で扱う範囲ではなく、別記事に委譲する範囲である点をご留意ください。

• IAMポリシーの基礎: 「OCI入門」シリーズVol2を参照。
• NSG・セキュリティリスト(ネットワーク層基礎): 「OCI入門」シリーズVol3を参照。
• ストレージCMK適用の詳細: 「OCI入門」シリーズVol5を参照。
• Zero Trust Packet Routing(ZPR)・Certificates・Threat Intelligence・VSS: 将来の発展記事へ委譲。
• Instance Security(Cloud Guardの有償機能): 将来の発展記事へ委譲。

前提環境の整理から始め、§2で使用技術スタックとゴール状態の定義を押さえた上で、§3でAWSのGuardDuty/Security Hub/Config/KMS/SSM Session Manager/WAFとの対応関係を構造的に俯瞰し、§4以降で実際の構築に進みます。

2. 前提・環境・準備

2-1. 前提環境

本記事の実践には、次の前提が必要です。

• Pay As You Go(PAYG)へ移行済みのOCIテナンシ(§9で理由を詳述。Cloud Guard/WAFは純Always Freeでは利用不可の公算が高いため)
• Vault・Bastion・WAF・Cloud Guard・Security Zonesの各サービスを操作できるIAMポリシーが設定されたユーザーまたはグループ(IAMポリシー自体の基礎は「OCI入門」シリーズVol2に委譲します)
• WAFの実演対象となるFlexible LB(「OCIネットワーク実践(Production編)」で構築したものを流用可能。同記事§2-8で詳細未扱いとされたWAF連携の回収)
• Bastionのセッション接続対象となるprivateサブネットのコンピュートインスタンス(「OCI入門」シリーズVol4で構築したpublicサブネット+直接SSH構成からの本番昇格として位置づけます)

これらの前提を、チェックリストの形で整理すると次の通りです。

IAMポリシー: Vault/Bastion/WAF/Cloud Guard/Security Zonesの操作権限

本記事の実演には、次のリソースタイプ(集約タイプ)に対する権限が必要です。テナンシ全体で管理者権限を持つユーザーであれば追加設定は不要ですが、権限を絞ったグループで作業する場合は、次のようなポリシーを用意します。

Allow group <グループ名> to manage vault-family in compartment <対象コンパートメント名>
Allow group <グループ名> to manage keys in compartment <対象コンパートメント名>
Allow group <グループ名> to manage secret-family in compartment <対象コンパートメント名>
Allow group <グループ名> to manage bastion-family in compartment <対象コンパートメント名>
Allow group <グループ名> to manage waf-family in compartment <対象コンパートメント名>
Allow group <グループ名> to manage cloud-guard-family in tenancy
Allow group <グループ名> to manage security-zone in compartment <対象コンパートメント名>

waf-familyには、WAFポリシー本体(waf-policy)・Flexible LBへの適用単位(web-app-firewall)・許可アドレスリスト(waf-network-address-list)といった個別リソースタイプがまとめて含まれています。また、cloud-guard-familyという集約リソースタイプには、Security Zonesの個別リソースタイプ(security-recipe・security-zoneなど)も含まれており、cloud-guard-familyへの権限があればSecurity Zonesの操作にも権限が及びます。本記事では明示のためにsecurity-zoneを個別に記載していますが、実務ではcloud-guard-familyのみでまとめて権限付与するケースも一般的です。なお、Cloud Guardの作成・更新・削除操作はreporting region(レポートリージョン)でのみ実行できるという制約があり、テナンシ単位でのポリシー設計が必要になります。

なお、OCIのポリシー検証レベルは、権限の弱い順にinspect・read・use・manageの4段階です。本記事では実演の簡潔さを優先してmanageレベルで統一していますが、閲覧のみを目的とするユーザーにはreadレベルで十分な場面もあります。

PAYGテナンシへの移行が前提になる理由

本記事の前提環境をPAYGテナンシとしているのは、Cloud GuardとWAFが、純粋なAlways Freeテナンシ(Pay As You Goへ一度も移行していないテナンシ)では利用できないためです。Cloud Guardは、Oracle公式の説明で「有償(PAYG)テナンシでのみ無償」と位置づけられており、Always Freeテナンシのままでは有効化そのものができません。WAFは、Oracleが公開しているAlways Freeリソースの一覧に含まれておらず、従量課金対象のサービスとして扱う必要があります。VaultとBastionはAlways Freeテナンシのままでも利用できますが、5サービスをすべて結線するE2Eを実演するには、PAYGへの移行が事実上の前提になります(詳細な料金構造は§2-2・§9)。

コンパートメント設計の考え方

本記事では、前作と同様、監視・統制対象リソースとセキュリティ関連リソース(Vault・Bastionの構成・WAFポリシー・Cloud Guard/Security Zonesのレシピ)を同一のコンパートメントにまとめる構成を前提とします。本番運用では、セキュリティ関連リソースを専用のコンパートメントに分離し、IAMポリシーで権限を最小化する構成が一般的ですが、本記事はVol1として構成をシンプルに保ち、コンパートメント分離の設計は今後公開予定の発展記事に委譲します。

Notificationsとの連携について

Cloud Guardのresponder recipeやWAFの一部アクションは、検出結果やイベントをNotifications経由で通知する構成に拡張できます。本記事のVol1では、Notificationsとの連携自体は扱わず、Cloud Guard・WAFそれぞれのコンソール上での検出・ブロック確認にとどめます。アラーム通知との結線は、前作「OCI可観測性・運用監視実践 Vol1」で扱ったAlarm/Notificationsの構成と組み合わせる形で、将来の発展記事のテーマとして位置づけます。

タグ付けの方針

本記事で作成するリソースには、フリーフォームタグとしてproject: oci-security-vol1を付与する方針とします。複数のセキュリティ関連リソースを横断的に検索・棚卸しする際、コンパートメント単位の絞り込みだけでなく、タグでの絞り込みも併用できるようにするための工夫です。タグ付けの基礎自体は「OCI入門」シリーズで扱い済みのため、本記事では適用方針のみを示します。

本記事で使用するリソース命名規則

本記事の§4以降で作成するリソースは、次の命名規則に統一します。読者が実際に手を動かす際、どのリソースがどの役割を持つか把握しやすくするための工夫です。

WAF実演対象のFlexible LBについて

本記事のWAF実演は、既存のFlexible LB(「OCIネットワーク実践(Production編)」で構築したもの)にWAFポリシーをアタッチする形で進めます。同記事の§2-8「WAFとの連携」では、WAF自体の詳細設定には踏み込まず、本番運用での検討事項として言及するにとどめていました。本記事は、その委譲されたWAF詳細設定を、Vault・Bastion・Cloud Guard・Security Zonesとあわせたゼロトラスト統制のE2Eの一部として回収します。

Bastion接続対象のprivateサブネットインスタンスについて

本記事のBastion実演は、「OCI入門」シリーズVol4で構築した「publicサブネット+直接SSH」構成のインスタンスを、privateサブネット+Bastion経由接続へ本番昇格させる形で進めます。同記事では、「本番運用を見据える場合はBastion経由が望ましい」という言及にとどめ、実際のBastion構築手順までは扱っていませんでした。

2-2. 使用技術スタック

本記事で使用する5サービスは、いずれもOCIのマネージド型サービスであり、インフラの管理・パッチ適用・スケーリングをOracle側が担う点で共通しています。一方で、各サービスが担う役割(暗号鍵管理・踏み台レス接続・境界防御・検出・予防)は明確に異なり、Always Free対応状況も5サービスの中で大きく分かれます。基盤と東京リージョン対応状況、本記事での役割、Always Free対応は、次の通りです(2026年8月時点の公式ドキュメント準拠)。

【重要】上記の通り、5サービスのうちVaultとBastionはAlways Freeテナンシのままでも利用できますが、WAF・Cloud Guard・Security Zonesの3サービスはPAYGテナンシへの移行が前提になります。PAYGへ移行さえすれば、Cloud GuardとSecurity Zonesは追加課金なしで利用できるため、本記事の規模(Vault1つ・Bastion1つ・WAFポリシー1つ・Cloud Guardターゲット1つ・Security Zonesレシピ1つ)であれば、WAFの月間1,000万リクエスト枠を除き、実質0円に近い形で完走できる可能性が高いといえます(詳細な料金試算は§9)。

Vault: software保護とHSM保護、Virtual Private Vaultの違い

Vaultには、デフォルトVault(software保護)・HSM保護の専用Vault・Virtual Private Vault(VPV)という3つの保護レベルがあります。デフォルトVaultのsoftware保護鍵は無料である一方、HSM(ハードウェアセキュリティモジュール)による保護は、20 key versionsまでがAlways Free対象で、それを超えると従量課金の対象になります。Virtual Private Vaultは、専用のHSMパーティションを占有する最上位プランで、$3.724/時という高額な料金がかかります。本記事では、コストと実演のしやすさを優先し、デフォルトVault(software保護)のみを使用します。

Bastion: セッションの種類と最大接続時間

Bastionのセッションには、SSHポートフォワーディングを行う「Port Forwarding Session」と、対象インスタンスへ直接SSH接続する「Managed SSH Session」の2種類があります。いずれのセッション種別も、Bastionの作成時に設定する「最大セッション存続時間(maximum session time-to-live)」の範囲内で利用でき、この値は30分から180分(3時間)の間で管理者が指定します。本記事では、Managed SSH Sessionを軸に実演します。

WAF: 現行世代とレガシーEdgeポリシーの2世代併存

OCI WAFには、現行世代のLBaaS向けWAF(Flexible LBへポリシーをアタッチする方式)と、旧世代のWAAS(Web Application Acceleration and Security)由来のEdgeポリシーという、2つの世代が併存しています。旧世代のEdgeポリシーは、エッジ(CDN的な配置)でのWAF機能を担っていた製品ラインで、現行世代のLBaaS向けWAFとは設定画面・課金体系ともに別物として扱われます。本記事では、現行世代のLBaaS向けWAF(Flexible LBへのアタッチ方式)のみを扱い、レガシーEdgeポリシーには言及にとどめます。

Cloud Guard: reporting regionとdetector/responderレシピ

Cloud Guardは、有効化時に「reporting region(レポートリージョン)」を1つ選択する必要があり、Cloud Guardの作成・更新・削除操作は、このレポートリージョンでのみ実行できます。有効化後は、detector recipe(検出ルールの集合)とresponder recipe(検出時の自動対応アクションの集合)を組み合わせて、テナンシ全体またはコンパートメント単位で監視を構成します。

Security Zones: レシピとコンパートメントへの適用

Security Zonesは、あらかじめ定義されたsecurity policy(禁止する操作の集合)をrecipe(レシピ)としてまとめ、そのレシピを特定のコンパートメント(Security Zone化されたコンパートメント)に適用する形で機能します。Security Zone化されたコンパートメント内では、レシピに違反する操作(例: パブリックIPを持つリソースの作成など)がAPIレベルでブロックされ、Cloud Guardのような「検出して通知する」のではなく、「そもそも実行させない」という予防型の統制になります。

本記事の§4以降で使用するOCI CLIコマンドグループ

本記事の各章で実際に使用するOCI CLIのコマンドグループを、あらかじめ一覧化しておきます。個別のコマンドオプションは各章で扱うため、ここでは「どの章でどのコマンドグループを使うか」の見取り図として押さえてください。

oci cloud-guard security-recipe・oci cloud-guard security-zoneというコマンドグループ名からも分かる通り、Security ZonesはCLI上でCloud Guardのコマンド階層(oci cloud-guard)の配下に位置づけられています。コンソール上は「Cloud Guard」と「Security Zones」という別々のメニューに見えても、IAMポリシーの集約タイプ(cloud-guard-family)とCLIのコマンド階層の両方で、Security ZonesがCloud Guard製品ファミリーの一部として扱われている点を押さえておいてください。

2-3. ゴール状態の定義

本記事における「動作している状態」とは、次の5つの要素がいずれも実際に機能し、期待した結果を得られる状態を指します。

• Vault: マスター暗号鍵が作成され、シークレットの保存と取得の両方が成功する
• Bastion: privateサブネットのインスタンスへセッション接続でき、SSHでログインできる
• WAF: WAFポリシーがFlexible LBへアタッチされ、保護ルール・レート制限が実際のリクエストに対して機能する
• Cloud Guard: detector/responderレシピが有効化され、意図的に発生させた問題を検出する
• Security Zones: レシピが適用されたコンパートメントで、違反となる操作が実際にブロックされる

この5つの状態を、それぞれ次の観点から確認できることをもって「動作している」と判定します。

この5つの状態を、本記事の§4以降で実際に構築しながら確認していきます。§4〜§8ではそれぞれの要素の構築手順とあわせて、上記の確認項目をどのように検証するかも扱います。

AWS実務者向けに、この「動作している状態」をSCP/GuardDuty中心の構成と対比すると、次のようになります。

この対比が示す通り、「確認する対象」自体はAWSとOCIで大きくは変わりません。異なるのは、AWSではSCPという1つの予防的統制の仕組みに慣れた感覚のまま、OCI側でも同様に1つのサービスを探してしまいやすい点です。OCIでは、検出(Cloud Guard)と予防(Security Zones)が明確に別サービスとして分かれており、この構造差を踏まえた画面遷移の勘所は、§7・§8で実際の操作とあわせて解説します。

前提環境の整理はここまでです。IAMポリシー・使用技術スタック・ゴール状態の定義という3つの観点を押さえたことで、§4以降で実際にリソースを作成していく準備が整いました。

次の§3では、ここまで整理した5サービスが、AWSのGuardDuty・Security Hub・Config・KMS・SSM Session Manager・WAFとどう対応するのかを構造的に俯瞰します。

3. AWS対応マップ全体像

AWSでは、暗号鍵管理・踏み台レス接続・境界防御・脅威検出・予防的ポリシー強制といったセキュリティ機能が、KMS・SSM Session Manager・WAF・GuardDuty/Security Hub/Config・SCPという複数のサービス・仕組みに分かれて提供されています。OCIでも同様に、Vault・Bastion・WAF・Cloud Guard・Security Zonesという5つの独立したサービスに分かれていますが、AWSとOCIでは「検出」と「予防」の分離のされ方が異なります。本章では、fig03の対応関係図に沿って、5つの対応関係を機能単位で整理します。

GuardDuty + Security Hub + Config ↔ Cloud Guard

AWSでは、GuardDuty(脅威検出)・Security Hub(セキュリティ状態の集約)・Config(構成変更の記録・コンプライアンス評価)という3つの独立したサービスを組み合わせて検出型の統制を構築しますが、OCIではこの範囲をCloud Guard1サービスが担います。Cloud Guardは、detector recipeによる検出とresponder recipeによる自動対応を1つのサービス内で完結できる点が、AWSの3サービス構成と異なります。

SCP的な予防統制 ↔ Security Zones

AWSでは、Service Control Policies(SCP)によって、Organizations配下のアカウントで実行できる操作をIAMポリシーとは別のレイヤーで制限します。OCIのSecurity Zonesは、コンパートメント単位でこれに近い予防型の統制を提供しますが、SCPが「どのAPIアクションを許可・拒否するか」を記述する汎用的なポリシー言語であるのに対し、Security Zonesは「あらかじめ定義されたセキュリティのベストプラクティス集(レシピ)」を適用する形式である点が異なります。

KMS ↔ Vault

AWSのKMSがカスタマーマネージドキー(CMK)を中心とした暗号鍵管理サービスであるのに対し、OCIのVaultは暗号鍵管理に加えてシークレット管理(AWSのSecrets Managerに近い機能)も1サービスの中に統合されています。KMSとSecrets Managerという2サービスに分かれているAWSと比べ、OCIでは鍵とシークレットが同じVaultサービスの中で管理される点が構造上の違いです。

SSM Session Manager ↔ Bastion

AWSのSSM Session Managerは、SSMエージェントをインスタンスにインストールすることで踏み台レス接続を実現しますが、OCIのBastionは、エージェントのインストールを必要とせず、Bastionサービス自体がセッションを仲介する形で接続します。この違いにより、Bastionはエージェント管理の手間がない一方、セッションの最大存続時間(30分〜180分)がSSM Session Managerより明確に短く設定されている点が実務上の違いです。

AWS WAF ↔ OCI WAF

AWS WAFとOCI WAFは、いずれもOWASP Top 10に基づく保護ルールでWebアプリケーションを防御する点で近い役割を持ちますが、OCI WAFには現行世代(LBaaS向け)と旧世代のEdgeポリシー(WAAS由来)という2世代が併存しており、AWS WAFのようにWeb ACLという単一の概念に統一されていない点に注意が必要です(詳細は§2-2・§6)。

この5つの対応関係が示す通り、AWSとOCIでは「検出」と「予防」、「鍵管理」と「シークレット管理」の分離のされ方が異なり、単純な1対1の名前対応だけでは実務上の設計判断を誤りやすい構造になっています。次の§4からは、実際にVaultでマスター暗号鍵を作成するところから、ゼロトラスト統制E2Eの構築を始めていきます。

4. Vault実践 — マスター暗号鍵とシークレット管理

Vault実践は、①デフォルトVault(software保護)の作成 → ②マスター暗号鍵の作成 → ③シークレットの保存 → ④シークレットの取得、という4ステップで進めます。いずれもコンソール・CLIどちらからでも実行できますが、本章ではOCI CLIでの手順を軸に記述し、コンソールでの操作は画面遷移が直感的なため要点のみ触れます。

4-1. デフォルトVaultの作成

Vaultを作成する際、コンソールでは「Vaultの作成」ダイアログで「仮想プライベート・Vaultにする」というチェックボックスが表示されます。このチェックボックスにチェックを入れるとVirtual Private Vault(VPV)が作成され、チェックを入れなければデフォルトVault(software保護)が作成されます。CLIでは--vault-typeオプションで明示的に指定します。

oci kms management vault create \
  --compartment-id <対象コンパートメントOCID> \
  --display-name oci-security-vol1-vault \
  --vault-type DEFAULT

Vaultの作成には数分かかります。コンソールまたはoci kms management vault getでライフサイクル状態が「Active」になったことを確認してから次のステップに進みます。

4-2. マスター暗号鍵の作成

Vaultが作成されると、そのVault専用の管理エンドポイント(management endpoint)が払い出されます。マスター暗号鍵の作成には、このエンドポイントを明示的に指定する必要があります。

oci kms management key create \
  --compartment-id <対象コンパートメントOCID> \
  --display-name oci-security-vol1-key \
  --key-shape '{"algorithm": "AES", "length": 32}' \
  --protection-mode SOFTWARE \
  --endpoint <Vaultの管理エンドポイント>

--protection-modeにはSOFTWAREとHSMの2種類があります。software保護鍵は無制限に無料である一方、HSM保護は20 key versionsまでがAlways Free対象で、それを超えると従量課金の対象になることは§2-2で整理した通りです。本記事ではコストを確実にゼロに近づけるため、SOFTWAREを選択します。

作成後、コンソールのVault詳細画面またはCLIで、キーのステータスが「Enabled」になっていることを確認します。

4-3. シークレットの保存

マスター暗号鍵の作成が完了したら、その鍵でシークレットを暗号化して保存します。ここでは、DBの接続パスワードを想定したダミー値を保存します。

echo -n "dummy-secret-value" | base64
# → 出力されたbase64文字列を --secret-content-content に渡す

oci vault secret create-base64 \
  --compartment-id <対象コンパートメントOCID> \
  --secret-name oci-security-vol1-secret \
  --vault-id <VaultのOCID> \
  --key-id <マスター暗号鍵のOCID> \
  --secret-content-content <base64エンコード済みの値> \
  --secret-content-name oci-security-vol1-secret-content

作成直後のシークレットはステータスが「Creating」から始まり、数十秒〜数分で「Active」に遷移します。

4-4. シークレットの取得

保存したシークレットが正しく取得できることを確認します。シークレットの値そのものはVault APIではなく、専用のSecrets Retrieval APIから取得する構成になっている点がOCIの特徴です。

oci secrets secret-bundle get --secret-id <シークレットのOCID>

レスポンスに含まれるcontentフィールドはbase64エンコードされているため、デコードして元の値と一致することを確認します。

echo "<レスポンスのcontentフィールド>" | base64 --decode

4-5. ストレージCMK切替の伏線回収

「OCI入門」シリーズVol5(ストレージ)では、Object Storageバケットのデフォルト暗号化(Oracle管理キー)から、カスタマー管理キー(CMK)へ切替可能である点の言及にとどめ、Vault側の具体的な構築手順までは扱っていませんでした。ここで作成したVaultとマスター暗号鍵は、そのままそのCMKとして利用できます。Object Storageバケットの詳細画面(または作成時)の「暗号化」欄で「Vaultで管理するキーを使用して暗号化する」を選択し、今回作成したVault・鍵を指定するだけで、Oracle管理キーからCMKへの切替が完了します。Block Volumeについても同様の手順でVaultのキーを指定できます。

4-6. 削除時の安全弁について

誤って削除操作を行ってしまった場合でも、Vaultには猶予期間(スケジュール削除)の仕組みがあります。§2-2で確認した通り、シークレットの削除遅延日数は1日〜30日(既定30日)、Vault本体またはキーの削除遅延日数は7日〜30日(既定30日)です。この猶予期間中であれば、削除スケジュールをキャンセルして復旧できます。実践中に誤操作をしても即座にデータが消えるわけではない、という安心材料として押さえておいてください。

4-7. 動作確認

§2-3で定義した「動作している状態」の基準に沿って、次の2点を確認します。

• Vaultコンソールでマスター暗号鍵のステータスが「Enabled」と表示されていること
• 4-4で取得したシークレットの値が、4-3で保存した元の値と一致すること

両方が確認できれば、Vaultの実践は完了です。次章では、このVaultの実践と並行してよく使われるBastionによる踏み台レス接続を実演します。

5. Bastion実践 — privateサブネットへのセッション接続

「OCI入門」シリーズVol4では、コンピュートインスタンスをpublicサブネットに配置し、直接SSHで接続する構成を扱いました。同記事では、本番運用を見据える場合はprivateサブネット+Bastion経由の接続が望ましいという言及にとどめ、実際のBastion構築手順までは扱っていませんでした。本章では、この本番昇格を実際に手を動かして完了させます。

5-1. privateサブネットへの本番昇格

Bastion経由接続を実演するには、対象のコンピュートインスタンスがprivateサブネット(パブリックIPを持たないサブネット)に配置されている必要があります。「OCI入門」Vol4のpublicサブネット構成のインスタンスをそのまま使う場合は、次のいずれかの方法でprivateサブネットへ昇格させます。

• 既存インスタンスのパブリックIPを削除し、ルート表・セキュリティリストをprivateサブネット相当の設定に変更する
• 新規にprivateサブネットを作成し、そのサブネット内に新しいインスタンスを作成し直す

本記事では、実演の見通しを立てやすい後者(新規privateサブネットへのインスタンス再作成)を前提に手順を進めます。いずれの方法でも、最終的に対象インスタンスがパブリックIPを持たない状態になっていることが、Bastion実践の前提条件です。

5-2. Bastionの作成

Bastionは、接続対象のサブネットを指定して作成します。Bastion自体はサブネットに関連付けられたゲートウェイ的な存在で、セッション作成のたびにインスタンスを起動する必要はありません。

oci bastion bastion create \
  --compartment-id <対象コンパートメントOCID> \
  --name oci-security-vol1-bastion \
  --bastion-type STANDARD \
  --target-subnet-id <privateサブネットのOCID> \
  --client-cidr-block-allow-list '["0.0.0.0/0"]' \
  --max-session-ttl-in-seconds 10800

--max-session-ttl-in-secondsには、§2-2で確認した「30分〜180分(3時間)」の範囲内の秒数を指定します。上記では上限値の180分(10800秒)を指定していますが、実務ではセッション時間を必要最小限に絞る運用が推奨されます。--client-cidr-block-allow-listは、Bastionへの接続を許可するクライアント側IPレンジです。実務では自組織のグローバルIPレンジに絞り込むべきですが、本記事の検証環境では簡便のため全許可(0.0.0.0/0)としています。

5-3. Managed SSH Sessionの作成

Bastionには「Port Forwarding Session」と「Managed SSH Session」の2種類があることは§2-2で整理しました。本記事では、対象インスタンスへ直接SSHログインできるManaged SSH Sessionを作成します。

oci bastion session create-managed-ssh \
  --bastion-id <BastionのOCID> \
  --display-name oci-security-vol1-session \
  --key-details '{"publicKeyContent": "<接続に使うSSH公開鍵の内容>"}' \
  --target-resource-id <対象インスタンスのOCID> \
  --target-resource-operating-system-user-name opc \
  --target-resource-port 22 \
  --session-ttl-in-seconds 1800

--session-ttl-in-secondsはセッション個別の存続時間で、5-2で設定したBastion側の--max-session-ttl-in-secondsを超える値は指定できません。作成直後のセッションはステータスが「Creating」から始まり、数十秒で「Active」に遷移します。

5-4. セッション経由でのSSH接続

セッションがActiveになったら、コンソールの「SSHコマンドのコピー」機能、またはCLIのレスポンスから接続コマンドを取得します。接続コマンドは、BastionをProxyCommand(踏み台)として経由し、対象インスタンスへ直接SSHする形式です。

ssh -i <SSH秘密鍵のパス> \
  -o ProxyCommand="ssh -i <SSH秘密鍵のパス> -W %h:%p -p 22 <セッションOCID>@host.bastion.<リージョン識別子>.oci.oraclecloud.com" \
  opc@<対象インスタンスのプライベートIP>

このコマンドを実行し、対象インスタンスへSSHでログインできることを確認します。エージェントのインストールが不要な点、接続経路がBastionサービス自体によって仲介される点は、§3で整理したAWSのSSM Session Managerとの構造上の違いです。

5-5. 完全無償である点の確認

Bastionは、§2-2で確認した通り、無料/有料いずれのアカウントでも完全無償で利用できます。本記事の5サービスの中で、Vaultのデフォルト保護と並び、料金面で最も気兼ねなく実演できるサービスです。

5-6. 動作確認

§2-3で定義した基準に沿って、Managed SSH Sessionでのログインが成功することをもって、Bastionの実践は完了です。セッションの存続時間(本記事では180分)を超過すると自動的に切断されるため、長時間作業する場合は、事前にセッションを作成し直す運用を想定しておく必要があります(この落とし穴は§10でも改めて整理します)。

6. WAF実践 — Flexible LBへのポリシーアタッチ

「OCIネットワーク実践(Production編)」§2-8「WAFとの連携」では、Flexible LBの構築を扱いながら、WAF自体の詳細設定には踏み込まず、本番運用での検討事項として言及するにとどめていました。本章では、その委譲されたWAF詳細設定を実際に構築し、伏線を回収します。

6-1. WAFポリシーの作成

OCI WAFは、まずWAFポリシー(保護ルールの集合)を作成し、そのポリシーをFlexible LBへアタッチするという2段階の構成になっています。

oci waf web-app-firewall-policy create \
  --compartment-id <対象コンパートメントOCID> \
  --display-name oci-security-vol1-waf-policy \
  --actions '[{"name": "BLOCK_403", "type": "RETURN_HTTP_RESPONSE", "code": 403}]'

actionsには、保護ルールに違反したリクエストに対して実行するアクション(この例では403エラーを返してブロックする)をあらかじめ名前付きで定義しておきます。個々の保護ルールからは、この名前付きアクションを参照する形で挙動を指定します。

6-2. Flexible LBへのアタッチ

作成したWAFポリシーを、既存のFlexible LB(「ネットワーク実践(Production編)」で構築したもの)へアタッチします。

oci waf web-app-firewall create \
  --backend-type LOAD_BALANCER \
  --compartment-id <対象コンパートメントOCID> \
  --display-name oci-security-vol1-waf \
  --load-balancer-id <Flexible LBのOCID> \
  --waf-policy-id <WAFポリシーのOCID>

アタッチが完了すると、そのFlexible LBへのすべての受信トラフィックが、まずWAFポリシーの保護ルールを通過するようになります。

6-3. 保護ルールの設定

OCI WAFの保護ルールは、CRS(Core Rule Set)3.0以降をベースとした約490個のルールで構成され、OWASP Top 10と主要なCVEをカバーするようOracle WAFセキュリティチームが選定しています(2026年8月時点の公式ドキュメント準拠)。ここで押さえておくべき重要な設計思想は、これらのルールが作成直後から全て有効化されているわけではないという点です。OCI WAFは「どの保護機能を有効化するかは利用者が決める」というパッシブ(受動的)な設計を採用しており、ポリシー作成直後の時点では保護ルールは何も有効化されていません。

WAFポリシー作成からおよそ24時間後、コンソールの「推奨事項(Recommendations)」タブには、OWASP Top 10をカバーするようOracleのWAFエキスパートによって選定されたおすすめルールが表示されます。これらは誤検知(false positive)が少なく、かつ保護効果の高いルールとして選定されたものです。実務での推奨運用は、まずこれらの推奨ルールを検知のみ行うDETECTモードで有効化し、一定期間誤検知が発生しないことを確認した上で、実際にブロックするBLOCKモードへ切り替える、という段階的な移行です。

oci waf web-app-firewall-policy request-protection-add-protection-rules \
  --web-app-firewall-policy-id <WAFポリシーのOCID> \
  --protection-rules '[{"id": "941100", "action": "BLOCK_403"}]'

なお、Web Application Firewall policyでは、Oracleがキュレーションしたルールの有効化・調整(チューニング)のみが可能で、AWS WAFのような自作のカスタムルール(Web ACL上のカスタムステートメント)は提供されていません。この点は、AWS実務者が構成を移行する際に見落としやすい差分です。

6-4. レート制限の設定

保護ルールとは別に、特定の送信元からの過剰なリクエストを制限するレート制限(Rate Limiting)を設定できます。

oci waf web-app-firewall-policy request-rate-limiting-add-rules \
  --web-app-firewall-policy-id <WAFポリシーのOCID> \
  --request-rate-limiting-rules '[{
 "name": "rate-limit-per-ip",
 "action": "BLOCK_403",
 "condition": "true",
 "period-in-seconds": 60,
 "requests-limit": 100,
 "action-duration-in-seconds": 300
  }]'

上記の例では、60秒間に100リクエストを超えた送信元に対し、以降5分間(300秒)にわたって403エラーを返す設定にしています。実際の許容リクエスト数は、対象アプリケーションの通常トラフィック量に応じて調整が必要です。

6-5. 現行世代とレガシーEdgeポリシーの世代差

§2-2で整理した通り、OCI WAFには現行世代(LBaaS向け、本章で扱っているoci wafコマンドグループ)と、旧世代のWAAS(Web Application Acceleration and Security)由来のEdgeポリシー(oci waasコマンドグループ)という2つの世代が併存しています。Edgeポリシーは、エッジ(CDN的な配置)でのWAF機能を担っていた旧世代の製品ラインで、設定画面・APIともに現行世代とは完全に別物です。本記事で扱うのは、Flexible LBへのアタッチ方式である現行世代のみであり、レガシーのEdgeポリシーは対象外です。既存の構築済み環境でEdgeポリシーが使われている場合、本章の手順をそのまま適用できない点に注意してください。

6-6. 動作確認

保護ルールをBLOCKモードで有効化した状態から、意図的に攻撃的なリクエストを送信し、実際にブロックされることを確認します。例えば、クエリパラメータにSQLインジェクションを模した文字列を含むリクエストを送ると、WAFポリシーで有効化した保護ルール(SQLインジェクション検知ルール)に該当し、403エラーが返されることを確認できます。

curl -i "https://<Flexible LBのパブリックIP>/?id=1' OR '1'='1"

正常なリクエストは通過し、攻撃的なリクエストのみが403でブロックされることを確認できれば、WAFの実践は完了です。

7. Cloud Guard実践 — 検出型統制

7-1. Cloud Guardの有効化(reporting regionの選択)

Cloud Guardは、テナンシ単位で1度だけ有効化します。有効化時には、Cloud Guardの作成・更新・削除操作を実行するreporting region(レポートリージョン)を1つ選択する必要があります。

oci cloud-guard configuration update \
  --compartment-id <テナンシOCID> \
  --status ENABLED \
  --reporting-region ap-tokyo-1 \
  --self-manage-resources true

--reporting-regionには、本記事の前提である東京リージョン(ap-tokyo-1)を指定します。一度選択したreporting regionは、Cloud Guardを無効化して再度有効化しない限り変更できないため、複数リージョンを運用している組織では、どのリージョンをreporting regionにするかを事前に検討しておく必要があります。

7-2. detector/responderレシピの設定

Cloud Guardを有効化すると、Oracle管理のデフォルトdetector recipe(Activity Detector・Configuration Detector・Threat Detectorなど)とresponder recipeが自動的に用意されます。これらのレシピを、監視対象とするコンパートメント(ターゲット)に関連付けます。

oci cloud-guard target create \
  --compartment-id <対象コンパートメントOCID> \
  --display-name oci-security-vol1-cloudguard-target \
  --target-resource-type COMPARTMENT \
  --target-resource-id <対象コンパートメントOCID> \
  --target-detector-recipes '[{"detectorRecipeId": "<ConfigurationDetectorレシピのOCID>"}]' \
  --target-responder-recipes '[{"responderRecipeId": "<デフォルトResponderレシピのOCID>"}]'

Detector recipeは検出ルールの集合、responder recipeは検出時の自動対応アクション(通知・自動修復など)の集合です。本記事では、まずOracle管理のデフォルトレシピをそのまま使い、検出の挙動を確認することを優先します。カスタムレシピの作成・チューニングは、実運用でアラートの精度を高めていく段階で取り組むテーマとして、本記事の範囲外とします。

7-3. 検出の実演

detector/responderレシピが有効化された状態で、意図的にConfiguration Detectorが検知するはずの問題(例: パブリックIPを持つセキュリティリストルールの追加、暗号化されていないブロックボリュームの作成など)を発生させます。Cloud Guardの検出には数分〜数十分のタイムラグがあるため、即座には結果が表示されない点に注意してください。

oci cloud-guard problem list \
  --compartment-id <対象コンパートメントOCID> \
  --lifecycle-state ACTIVE

しばらく待った後、上記コマンド(またはコンソールのproblemsリスト)で、意図的に発生させた問題が検出結果として表示されることを確認します。

7-4. 動作確認

§2-3で定義した基準に沿って、Cloud Guardのproblemsリストに、意図的に発生させた問題が実際に検出結果として表示されることをもって、Cloud Guardの実践は完了です。Cloud Guardはあくまで「検出して通知する」統制であり、問題となる操作自体を止めることはできません。この点は、次章で扱うSecurity Zones(予防型統制)との対比の軸になります。

8. Security Zones実践 — 予防型統制

8-1. レシピの選択

Security Zonesは、あらかじめ定義されたセキュリティポリシーの集合であるレシピを、コンパートメントに適用する形で機能します。レシピには、Oracle管理で変更不可の「Maximum Security Zone」レシピと、利用者が個別のポリシーを取捨選択できるカスタムレシピの2種類があります。本記事では、実演の見通しを立てやすいOracle管理の「Maximum Security Zone」レシピをそのまま使います。

oci cloud-guard security-recipe list \
  --compartment-id <対象コンパートメントOCID> \
  --display-name "Maximum Security Zone"

8-2. コンパートメントへの適用

取得したレシピのOCIDを使い、対象コンパートメントをSecurity Zone化します。

oci cloud-guard security-zone create \
  --compartment-id <対象コンパートメントOCID> \
  --display-name oci-security-vol1-sz-zone \
  --security-recipe-id <Maximum Security ZoneレシピのOCID>

8-3. Maximum Security Zoneレシピの内容

Maximum Security Zoneレシピは、2026年8月時点の公式ドキュメントに基づくと、次の7つのカテゴリに分類された合計約77個のポリシーで構成されています。

代表的なポリシーをいくつか具体的に見ると、「パブリックサブネットの作成禁止」「インターネットゲートウェイの追加禁止」「暗号化なしのブロックボリューム作成禁止」など、いずれも本記事の§4(Vault)・前作以前の記事で扱った構成のベストプラクティスをAPIレベルで強制する内容になっています。ポリシーの正確な一覧・最新の数は、コンソールの「Maximum Security Zoneレシピの詳細」画面、または公式ドキュメントで随時確認することをお勧めします。

8-4. 検出(Cloud Guard)と予防(Security Zones)の対比

§7で実践したCloud Guardは、問題を検出してproblemsリストに表示する「検出型」の統制でした。これに対しSecurity Zonesは、レシピに違反するAPIコールそのものをエラーで拒否する「予防型」の統制です。両者の違いを実際に比較すると、次のようになります。

この対比が示す通り、Cloud Guardは「すでに起きてしまった問題に気づく」ための仕組み、Security Zonesは「そもそも問題を起こさせない」ための仕組みという、補完関係にあります。予防ルールでカバーしきれない振る舞い(例: 正規の権限を使った不審なAPIコールのパターンなど)はCloud Guardが検出で補い、予防でブロックできる既知の危険な構成(パブリックなリソース作成など)はSecurity Zonesが未然に防ぐ、という二段構えの統制が、ゼロトラスト統制E2Eの骨格になります。

8-5. 動作確認

レシピに違反する操作、例えばSecurity Zone化されたコンパートメント内でパブリックサブネットを作成しようとする操作を試み、APIエラーで拒否されることを確認します。

oci network subnet create \
  --compartment-id <Security Zone化されたコンパートメントOCID> \
  --vcn-id <VCNのOCID> \
  --cidr-block 10.0.99.0/24 \
  --display-name test-public-subnet \
  --prohibit-public-ip-on-vnic false

上記のように--prohibit-public-ip-on-vnic false(パブリックIPを許可する設定)でサブネット作成を試みると、Security Zoneのポリシー違反としてAPIエラーが返され、サブネットが作成されないことを確認できます。これをもって、Security Zonesの実践は完了です。

9. 料金構造の正確性 — 3部作対比構造のまとめ

本記事の差別化の核である料金構造の正確性を、ここで改めて整理します。§1-3で触れた通り、本シリーズはこれまで公開した「OCI実践」系記事群の中で、料金構造の異なる3つの記事が対比構造を成しています。

前々作「OCI Functions & API Gatewayサーバーレス実践 Vol1」は、Functions・API GatewayのいずれもAlways Free対象外(API Gatewayは無料レンジなし)であり、実演にPAYG移行または課金の許容が前提となる「課金必須」記事でした。前作「OCI可観測性・運用監視実践 Vol1」は、Connector Hub・Notificationsなど、Always Free枠内で完結する構成を選び、「完全0円」で最後まで実践できる記事として設計しました。そして本記事は、この2記事の中間にあたる「PAYG推奨」という第3の位置づけです。

本記事が「PAYG推奨」である理由を、5サービス単位で改めて整理すると次の通りです。

5サービスのうち2サービス(Vault・Bastion)はAlways Freeテナンシのままでも利用できますが、残る3サービス(WAF・Cloud Guard・Security Zones)は、有効化操作そのものにPAYGテナンシへの移行が前提となります。この非対称性こそが、前作「完全0円」との決定的な違いであり、本記事を「課金必須」でも「完全0円」でもない「PAYG推奨」という第3の位置づけとして整理する理由です。

一方で、いったんPAYGへ移行してしまえば、WAF・Cloud Guard・Security Zonesの3サービス自体の有効化・利用に、追加課金は発生しません。唯一課金の可能性があるのはWAFで、最初のWAFインスタンスと月間1,000万リクエストまでは追加課金なしとされていますが(§2-2)、これを超えるトラフィックが発生した場合は従量課金の対象になります。本記事の規模(検証用の少数リクエストによる実演)であれば、この上限に達することはまずありません。

まとめると、「PAYGテナンシへの移行」という一段構えのハードルさえ越えてしまえば、本記事で構築する5サービスの構成は、WAFの月間1,000万リクエスト枠を除き、実質0円に近い形で完走できる可能性が高いといえます。この「移行さえすればほぼ無料」という構造こそが、前々作(課金必須)・前作(完全0円)とは異なる、本記事ならではの料金構造上の落としどころです。

10. 落とし穴・まとめ・次のステップ

10-1. 本記事全体の落とし穴

本記事の§4〜§9で扱った実践を通じて見えてきた落とし穴を、表形式で整理します。

10-2. まとめ

本記事では、Vault(暗号鍵・シークレット管理)・Bastion(踏み台レス接続)・WAF(境界防御)・Cloud Guard(検出型統制)・Security Zones(予防型統制)という5サービスを、実際に結線してゼロトラスト統制のE2Eを構築しました。個々のサービスの単体理解だけでは見えてこない、「検出(Cloud Guard)と予防(Security Zones)の両輪で統制を回す」という設計思想の勘所を、実際に両方を有効化して比較する形で確認できたはずです。

AWS実務者向けの対応マップ(§3)を振り返ると、AWSではGuardDuty・Security Hub・Configという3サービスに分かれていた検出型の機能がCloud Guard1サービスに統合され、逆にKMSという1サービスだった暗号鍵管理は、OCIのVaultではシークレット管理まで含めて1サービスに統合されるなど、「まとめられ方」がAWSとOCIで異なる構造を持っています。この構造差を理解した上で名前の対応だけに頼らず実際の挙動を確認することが、AWSからOCIへの移行・比較検討における実務上の要点です。

料金構造の面では、本記事は前々作(課金必須)・前作(完全0円)に続く「PAYG推奨」という第3の位置づけであり、Vault・Bastionは確実に無料、WAF・Cloud Guard・Security ZonesはPAYGテナンシへの移行さえ済ませればほぼ無料、という非対称性を正確に整理しました(§9)。この正確性こそが、本記事のシリーズ内での差別化の核です。

10-3. 次のステップ — 将来の発展記事へ

本記事では、Cloud Guardの有償機能であるInstance Securityや、Zero Trust Packet Routing(ZPR)・Certificates・Threat Intelligence・VSS(Vulnerability Scanning Service)といった、より発展的なセキュリティサービスへは踏み込みませんでした。これらは、本記事で構築したVault・Bastion・WAF・Cloud Guard・Security Zonesの基盤の上に、さらに統制を深化させるテーマとして、将来の発展記事で扱う予定です。

• Zero Trust Packet Routing(ZPR) — ネットワーク層でのゼロトラストポリシー強制
• Certificates — TLS証明書のライフサイクル管理
• Threat Intelligence — 脅威インテリジェンスとCloud Guardとの連携
• VSS(Vulnerability Scanning Service) — インスタンス・コンテナの脆弱性スキャン
• Instance Security(Cloud Guardの有償機能) — ワークロード保護の高度化