クラウドインテグレーション事業部の小谷です。

2025年10月13日〜16日の4日間で開催された「Oracle AI World 2025」に現地参加してきました。最新情報を皆さんにお届けするために随時ブログをアップしていきますので、よろしければご覧ください。

今回ご紹介するセッションは、OCIのSecureLanding Zone についての技術セッションとなります。

セッション名:Build a Secure Landing Zone on Oracle Cloud Infrastructure

このセッションでは、Center for Internet Security (CIS) ベンチマークに基づいた OCI Landing Zoneが、いかにしてこれらの課題を解決するかが語られました。あらかじめセキュリティ設定が構成された標準的なプラットフォームを使うことで 、クラウド移行を加速し 、NISTやHIPAA、PCI-DSSといった主要なフレームワークへの対応も容易になる という内容です。

本記事では、このセッションで何が語られたのか、その要点をレポートします。

セッションの概要

このセッションで語られた「OCI ランディングゾーン」の最も重要なポイントは、以下の通りです。

  • 安全な「土台」を自動で構築

クラウド上に、セキュリティやネットワーク設定が最適化された「土台(=ランディングゾーン)」を、Terraformを使って数分で自動構築できます。

  • CISベンチマークに準拠

セキュリティの業界標準である「CISベンチマーク」に準拠 。さらにOracle自身のベストプラクティスも組み込まれています 。

  • 基本コストは「無料」

ランディングゾーンを構成する基盤的なセキュリティやネットワークのコンポーネント自体には、追加の利用料がかかりません 。

  • 柔軟なカスタマイズ

GitHubで公開されており 、自社の要件に合わせて自由にカスタマイズが可能です 。

セッション内容の詳細

セッションは3つのパートに分かれていました。それぞれの登壇者が語った内容を詳しくご紹介します。

1. Brian Eidelman氏(Oracle): “ランディングゾーン”の基本理念

最初の登壇者であるBrian氏は、まず「ランディングゾーンとは何か?」という基本概念を説明しました。

  • ランディングゾーン = 安全でスケーラブルな「土台」

ランディングゾーンとは、ワークロード(アプリケーションやデータベース)を安全かつ効率的に展開するための、セキュアでスケーラブルなOCIテナンシー(利用環境)のことです 。

これがあるおかげで、新しいアプリを追加するたびに、ゼロからセキュリティやネットワークを設計し直す必要がなくなります 。

  • アーキテクチャの解説

Brian氏は、ランディングゾーンがどのように構築されるかを、スライドで順を追って解説しました。

・コンパートメント(箱)の分離: まず、リソースを「ネットワーク用」「セキュリティ用」「アプリ用」「データベース用」といった「コンパートメント」と呼ばれる箱に分離します 。

・ポリシー(ルール)の設定: 次に、管理者グループを追加し 、ポリシー(権限ルール)を設定します 。これが「秘伝のタレ」だとBrian氏は語ります 。

・最小権限の原則: 例えば、「アプリ開発者」はネットワーク(VCN)を「使う」ことはできますが、「変更」することはできません 。これにより、開発者が誤って(あるいは意図的に)セキュリティホールを開けてしまうのを防ぎます 。

・セキュリティサービスの標準装備: OCI Vault(鍵管理)やロギング機能、通知フレームワークなども、最初から適切な場所に配備されます 。

・このランディングゾーンのアーキテクチャ全体が、CIS認定を受けているという点も、安心材料として強調されました 。

2. Josh Hammer氏(Oracle): “モジュール”で実現する柔軟なデプロイ

続いてJosh氏は、このランディングゾーンをどうやってデプロイし、管理していくかについて解説しました。

  • 空港のアナロジー

Josh氏は、家ではなく「空港」に例えました 。OCIランディングゾーンは、政府が整備する「滑走路」や「セキュリティチェックポイント」のようなもの 。航空会社(=ワークロード)は、その安全な基盤の上で自社のビジネス(フライト)を運営する、というイメージです 。

  • デプロイ = (1)設計図 → (2)コード化 → (3)デプロイ

(1) 設計図: まず、公開されている設計図(SVGファイルで編集可能 )をベースに、自社の構成を決めます 。

(2) コード化: 次に、それをTerraformのコードに落とし込みます 。パラメータはJSONやYAMLで管理するのがオススメとのこと(Excelは非推奨だそうです )。

(3) デプロイ: Oracle Resource ManagerやGitHub Actionsなど、好きなツールでデプロイします 。

  • 「コア・モジュール」という考え方

ランディングゾーンは、機能ごとに「モジュール」という小さな部品の集まりで構成されています 。

各モジュールは「API契約」のように、明確な「入力」と「出力」が定義されています 。

例えば、「IAM(ID管理)モジュール」の出力(コンパートメント情報)を、「ネットワークモジュール」の入力として渡すことができます 。

これにより、IAMチームとネットワークチームが、お互いを待つことなく、独立したパイプラインで作業を進められるようになります 。これは大企業にとって非常に重要です。

  • 継続的なコンプライアンス・チェック

「デプロイして終わり」ではありません 。Josh氏のチームは、デプロイ後の環境がCISベンチマークに準拠し続けているかを確認するためのPythonスクリプトも提供しています 。

このスクリプトは、CISのチェック項目 だけでなく、「FastConnect(専用線)がちゃんと冗長化されているか?」 「ログは全て中央に集約されているか?」 といったOracle独自のベストプラクティスもチェックしてくれます 。

3. Herman Slange氏(Accenture): 顧客事例と実践的なカスタマイズ

最後に、AccentureのHerman氏が、実際のお客様の導入事例や、より実践的な活用法を紹介しました 。

  • 現実の課題:技術 vs プロセス

Herman氏の顧客であるオランダ政府は「セキュリティ・パラノイア」と表現されるほど要件が厳しいそうです 。

彼は「家の鍵」の例えを使いました 。ランディングゾーンは「高性能な鍵(技術的な統制)」を提供しますが 、それを「ちゃんと掛ける(プロセス的な統制)」のは人間です 。両方が揃って初めて安全だと言えます。

  • Accentureによる実践的なカスタマイズ
    • ワークロード・モジュールの追加: お客様は「土台(LZ)」だけではなく、その上で動く「家(ワークロード)」まで含めたフルスタックを求めます 。そこでHerman氏のチームは、KubernetesやAutonomous Databaseなど、ワークロード用のTerraformモジュールを追加開発しているそうです 。
    • コンプライアンスチェックの「除外リスト」機能: Josh氏の準拠性チェックツール は便利ですが、時には「意図的に非準拠にしている項目(=承認済みの例外)」もエラーとして検出してしまいます 。そこで彼らは、承認済みの例外を「除外リスト」に追加し、アラート対象から外す機能を追加しました 。
  • 印象的だった顧客事例
    • グローバル通信会社: 15以上の事業会社を持つ巨大企業で、各社を「完全に分離」した環境が必要でした 。
      • レイテンシ問題の解決: ある顧客が、オンプレのアプリとフランクフルト(OCI)のDBを接続したところ、レイテンシ(遅延)がひどく、性能が劇的に悪化しました 。
      • 解決策: そこで、オンプレ環境に近いアムステルダムのリージョンに、Terraformの設定を少し変えて再実行するだけで、フランクフルトと「全く同じランディングゾーン環境」を即座にコピー 。これにより、レイテンシ問題を見事に解決したそうです。

まとめ

今回のセッションでは、OCI Landing Zoneが単なるテンプレートではなく、CIS認定を受けた 自動化された 柔軟なフレームワークであることが強調されていました。
安全な「土台」を素早く提供するだけでなく、「モジュール」という考え方によって 、大規模組織の複雑なデプロイフローにも対応できます 。

ここで、他のクラウドと比較したOCI Landing Zoneの特徴を、マルチクラウドベンダー(Accenture)の視点も踏まえて補足します。
最大の特徴は、TerraformベースのIaC(Infrastructure as Code)を全面的に採用している点です。
例えば、同様のサービスを他パブリッククラウドではGUIベースのマネージドサービスとして規範的な環境を提供するのに対し、OCIはTerraformのコードを直接カスタマイズすることを前提としています。

これにより、AccentureのHerman氏がセッションで語ったように、自社の要件に合わせてワークロード用モジュール(Autonomous DatabaseやKubernetesなど)を追加開発するといった、パートナーによる柔軟なカスタマイズが非常に容易になっています。
また、セッションで強調されていたように、ランディングゾーンを構成する基盤的なセキュリティコンポーネントが追加コストなしで利用できる点 も、他のクラウドと比較する上で大きな魅力です。

マルチクラウドを検討する際、Terraformによるインフラ管理をすでに標準としている企業や、柔軟なカスタマイズを重視する企業にとって、OCIのこのアプローチは非常に親和性が高いと言えるでしょう。
これらのランディングゾーンのプロビジョニングと管理を容易にするために、OCI Fleet Application Management (FAM) というサービスも用意されています。

 

  • 参考URL(OCI Landing Zone の概要 )

https://docs.oracle.com/ja-jp/iaas/Content/cloud-adoption-framework/oci-landing-zones-overview.htm

  • 参考URL(Github OCI Landig Zone)

https://github.com/oci-landing-zones

  • 参考URL(OCI Fleet Application Management (FAM) )

https://www.oracle.com/jp/cloud/fleet-application-management/