ルールのスプロールからゼロ・トラストまで: ZPR PSAとIAMが顧客のクラウド・セキュリティをどのように変革したか (2026/06/07)

ルールのスプロールからゼロ・トラストまで: ZPR PSAとIAMが顧客のクラウド・セキュリティをどのように変革したか (2026/06/07)

https://blogs.oracle.com/cloud-infrastructure/from-rule-sprawl-to-zero-trust

投稿者：Loy Evans | Consulting Member of Technical Staff

セキュリティルールが理解できる速度よりも速く増えていくと、セキュリティは確保されず、ある意味セキュリティがあるように見せかけているだけになってしまいます。これは、あるOracle Cloudの顧客がゼロトラストパケットルーティング（ZPR）とプライベートサービスアクセス（PSA）を採用する前に直面した課題でした。この記事では、彼らがどのようにして、広範で脆弱なセキュリティリストから、監査が容易で悪用されにくく、拡張性にも優れた、ワークロード中心のクリーンなポリシーモデルへと移行したのかを紹介します。

問題点：誰も説明できないセキュリティリスト

顧客の環境は、多くの成熟したクラウド導入事例に典型的なものでした。マルチリージョンアーキテクチャを採用し、制御プレーンとデータプレーンのVCNが分離されており、コンピューティング、ロードバランサー、スキャンツール、踏み台ホスト、およびオブジェクトストレージ、ログ記録、認証などのOracle Services Networkリソースにアクセスするためのサービスゲートウェイ接続を備えていました。

理論上は、構造は整っていた。しかし実際には、それを規定するセキュリティ規則は、維持管理上の負担となり、深刻なセキュリティ上の問題を引き起こしていた。

セキュリティリストの問題点

  • ルールの乱立と意図の不一致：説明のつかないCIDRソース、宛先、重複を含む150を超えるセキュリティルール
  • サブネット中心、ワークロード中心ではない：セグメンテーションはネットワークトポロジーに基づいており、ワークロード同士が通信する必要のある内容とは関係がなかった。
  • 監査の負担：最小権限アクセスを検証することは、時間のかかる手作業のプロセスであり、リソースを大量に消費し、エラーが発生しやすく、外部監査チームが意図を検証するのに通常数週間を要した。

OSNアクセスにおける課題

  • デフォルトで広範なアクセスが可能：標準パターンでは、ワークロードがすべてのOSNサービスにアクセスできるため、必要以上に多くのアクセス権限が付与されます。
  • ポートの曖昧さ：多くのOracleサービスはtcp/443を共有しているため、単一の許可ルールによって、ワークロードが決してアクセスすべきでないサービスへのアクセスが許可されてしまう可能性があります。
  • 情報漏洩の可能性：ローカル認証情報の適用なしにすべてのオンラインソーシャルネットワークサービスに広くアクセスできると、データ漏洩の経路となる可能性がある。

ソリューション：ワークロードの識別とポリシー主導の強制の融合

目標とするアーキテクチャでは、CIDRベースのルールと広範なSGWアクセスを、ネットワーク上の位置ではなくワークロード自体を記述するZPRセキュリティ属性をワークロードに適用するZPRおよびPSAモデルに置き換えた。

新モデル：ゼロトラストパケットルーティング、プライベートサービスアクセス、IAM拒否によるセキュリティ強化

新モデルでは以下の変更が導入されました。

  1. ワークロードにはID（セキュリティ属性）が割り当てられました。各リソースには、その役割を説明する属性（例：アプリケーション、データベース、踏み台）がタグ付けされました。
  2. サービスアクセスは明示的（PSA）に設定された。OSNへの広範なアクセスではなく、使用するサービス専用のPSAエンドポイントが作成された。その他のサービスへのアクセスは許可されなかった。
  3. ローカル認証情報による認証が必要です。PSAはデフォルトで厳格なローカル認証情報の使用を強制します。
  4. IAM拒否： PSAの使用を必須とし、サービスゲートウェイを介した広範なアクセスを事実上無効にした。
  5. 人間が読みやすいポリシーによって意図が明確化されました。ZPRポリシーは、CIDRベースのルールを属性に置き換え、監査が容易でより優れたセキュリティを提供しました。

ターゲットアーキテクチャにおける主な変更点

  • コントロールプレーンとデータプレーンの両方のVCNにおいて、各ワークロードに対して定義された名前空間とセキュリティ属性が、リソースタイプ別に整理されています。
  • PSAエンドポイントを使用すると、ワークロードは必要な規定サービスとのみ通信でき、それ以外のサービスとは通信できません。
  • IAMの拒否ポリシーはサービスゲートウェイへのアクセスをブロックし、すべてのトラフィックをPSAエンドポイント経由で強制的に通過させます。
  • ZPRポリシーは、セキュリティリストを自然言語属性を使用した明示的な許可ルールに置き換えるもので、許可されるすべての通信経路には名前が付けられ、意図的なものとなります。
  • PSAエンドポイントは本質的にローカル認証情報を必要とするため、テナント間における認証情報の悪用という脅威を無効化します。

このモデルの最も強力な特性の一つは、ZPR SAとポリシーが設定されると、IPアドレスの変更やサブネットの再構成など、基盤となるネットワークトポロジーをポリシー規則に一切手を加えることなく再構成できることです。セキュリティモデルはネットワークではなく、ワークロードのIDとともに移動します。

実際に改善された点

最大の変化は、単に規則が減ったことだけではなく、システムが再び説明可能になったことだった。

  • ポリシーを見れば、どのようなコミュニケーションが許可されているかを正確に理解できます。
  • サービスへのアクセスは、サービスネットワーク全体ではなく、特定のエンドポイントに限定されます。
  • 認証情報の使用は、設計上、ローカルテナント内に限定されています。
  • セキュリティはもはやネットワーク上のどこにデータが存在するかに依存しません。ワークロードを移動したり、アドレスを変更したりしても、セキュリティポリシーを書き換える必要はありません。

変更前（セキュリティリスト＋サービスゲートウェイ）

セキュリティリストとNSG構成では、使用されていないサービスも含め、すべてのOracleサービスへのアクセスを特定のIPアドレスのブロックにのみ許可するようになっています。

無邪気だが問題あり

見た目は問題なさそうですが、実際には、アプリのサブネットからすべての OSN サービスへの送信アクセスが許可されています。この例を見て、アプリが IAM、ログ記録、監査、証明書サービスのみにアクセスできるようにしたい場合、オブジェクト ストレージや関数へのアクセスをブロックする方法はありません。

攻撃ベクトル

攻撃者がアプリケーションサーバーのいずれかにアクセスできる場合、その同じOSNアクセスを使用してリモート関数を実行したり、他のテナントの外部認証情報を使用して任意のオブジェクトストレージバケットにアクセスしたりすることができ、任意のバケットにデータを流出させることができます。

（ZPR + PSA）後

ZPR属性、PSA、およびZPRポリシーは、OCIテナントのセキュリティ強化に役立ちます。

より具体的なポリシーとアクセス

ZPRでは、ポリシーは人間が読みやすい形式で、ワークロードIDに紐付けられます。PSAとIAMの拒否では、Oracleサービスへのアクセスは明示的かつ必須であり、明示的に許可されたサービス以外にアクセスすることはできません。例ではすべてのPSAが同じセキュリティ属性（ポリシー規則の最適化のためにグループ化）を持つように示されていますが、各PSAは、その特定のサービスへのサービス呼び出しのみを許可する制限付きアクセスパスを提供します。

同じ攻撃ベクトル - データ流出なし

攻撃者がアプリケーションサーバーのいずれかにアクセスできたとしても、そのOSNアクセス権限を使ってリモートFunctionsを実行したり、オブジェクトストレージバケットにアクセスしたりすることはできません。また、許可されている特定のサービスにアクセスするには、ローカル認証情報が必要となります。したがって、脆弱性を利用してコンピューティングインスタンスのいずれかへのルートアクセス権限を取得できたとしても、オブジェクトストレージに直接アクセスするためのローカル認証情報がないため、外部バケットへのデータ漏洩は失敗します。これにより、サービスアクセスに対するセキュリティ境界が、ベストエフォート型ではなく、確固たるものとなります。

同様に、従来は広範なサブネットベースのルールによって意図しない横方向の移動が許容されていました。ZPRでは、通信はワークロードの役割に限定され、明示的に定義された相互作用のみが可能になります。

旅：今後の道筋を描くための卓上演習

旧モデルから新モデルへの移行には、体系的なプロセスが必要でした。チームは、本番環境のワークロードを中断することなく、安全に移行を計画するための机上演習手法を開発しました。

ステップ1：在庫情報の自動抽出

顧客の既存のTerraformステートファイルを基に、決定論的なLLMベースの分析ツールが、すべてのVCN、サブネット、IPアドレス、コンピューティングインスタンス、およびサービスの構造化されたインベントリを作成しました。

ステップ2：セキュリティ属性の割り当て

在庫の検証が完了すると、チームは規定の命名規則を用いて各リソースにシステム管理者（SA）を割り当てた。この割り当ては手動で行うことも、自動化によって行うこともでき、規定のSA名によってチーム間での一貫性が確保される。

ステップ3：政策の翻訳

このツールは、既存のセキュリティリストとNSGルールをすべてZPRポリシーステートメントに直接1対1で変換します。これは最適化前の便利な第一歩です。チームは、以前許可されていた内容を新しいZPR言語で正確に表現したポリシーセットを入手しました。これにより、セキュリティリストの本来の意図を反映した、包括的（ただし冗長）なポリシーセットが完成します。

ステップ4：最適化と抽象化

真の価値は翻訳後のレビューで発揮されます。そこでは、共通点のあるSAとポリシーを最適化によって組み合わせることができます。各リソースに独自のルールが割り当てられたスキャンサブネットルールを考えてみましょう。

  • app-dp-prod.network:cp vcn で、'10.0.128.0/24' がプロトコル='tcp' で app-cp-prod.app:cp エンドポイントに接続できるようにします。
  • app-dp-prod.network:cp vcn で、'10.0.128.0/24' がプロトコル='tcp'を使用して app-dp-prod.app:dp エンドポイントに接続できるようにします。
  • app-dp-prod.network:cp vcn で、'10.0.128.0/24' が app-tool-prod.app:tool エンドポイントにプロトコル='tcp' で接続することを許可する。

スキャンが必要なすべてのものに対して単一の SA app-ccommon.scan:target を導入することで、これらのルールを統合できます。

  • app-dp-prod.network:dp vcn を許可'10.0.128.0/24'app-ccommon.scan:targetエンドポイントにプロトコル='tcp'で接続する

同様の最適化は、PSAやバスティオンなどの一般的なコンポーネントにも適用できます。

結果：ZPRが実際にもたらした成果

この顧客との演習を通じて達成された成果は以下のとおりです。

  • より少なく、より読みやすい意図
    • 79個の人間が読めるZPRポリシーステートメントに含まれる同等のセキュリティルールと、IPアドレスのみを含む151個のセキュリティリストルール。
  • OSNサービスへの明示的なアクセス
    • PSAがない場合、顧客は通常、すべてのプロトコルに対してすべてのOSNへの広範なアクセスを許可してしまうため、セキュリティ体制が著しく低下する。
    • PSAの導入により、OSNへのアクセスは処方箋に基づいてサービスごとに提供されるようになり、衛生管理の向上と情報漏出のリスク低減につながります。
  • 外国の認証情報の使用とオブジェクトストレージからの情報漏洩を排除しました。
    • PSAではサービスごとに規定されたアクセス権限が提供されるため、攻撃者がオブジェクトストレージを介してデータを抜き出す機会はありません。
    • PSAでは、サービスへのアクセスにローカルテナント専用の認証情報が必要です。攻撃者は自身の認証情報を持ち込んで、外部の認証情報で外部オブジェクトストレージにアクセスすることはできません。
  • 簡潔で読みやすいポリシー監査
    • ZPRルール構造により、セキュリティポリシーが人間にとって読みやすくなり、一目で監査しやすくなります。
  • セキュリティポリシーはネットワークトポロジーに依存しない

これがあなたの環境に及ぼす影響とは

この顧客事例は重要なことを示しています。クラウド環境で蓄積されるセキュリティの複雑さは、必ずしも避けられないものではありません。ZPRとPSAを併用することで、複雑さを生み出す要因を妥協なく排除し、意図しない権限の過剰付与と意図的な悪用を劇的に困難にすることができます。

詳細については、以下の資料を参照してください。

コメント

コメントを投稿

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

イメージ
Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20) https://mikedietrichde.com/2024/11/20/important-update-to-oracle-database-19c-support-timelines/ 長い沈黙は、私が隠れているという意味ではありません。つまり、今はとても忙しいということです。そして、より少ない旅行で、私はあなたのコメントにもブログと返信するより多くの時間を持っていることを願っています。それでも、Oracle Database 19cサポート・タイムラインの非常に重要な更新について説明します。 * 更新された内容 2024年11月19日現在、Oracle Database 19cのサポート・タイムラインが調整されています。 MOSノート: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールを見ると、新しい日付が表示されます。 Premier Support、2029年12月31日まで 2030年1月1日から2032年12月31日までの拡張サポート 2033年1月1日から2034年12月31日までのアップグレード・サポート これは知ることがとても大切です。 他のリリースの更新はありますか。 MOSノートの終わりにある変更ログ: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールでは、Oracle Database 21cの最新の更新も確認できます。このリリースのPremier Support期間は、2027年7月31日まで延長されました。 また、Oracle Database 23aiのパッチ適用終了日は2032年12月31日に設定されています。 Lifetime Support Policy 更新は、Oracle Technology Productsの Oracle Lifetime Support Policy (6ページ)でも確認できます。 From: Oracle Lifetime Support Policy for Oracle Technology Product s – page 6 – Nov 19, 2024 特に、次の表に示す制限事項に注意してください。 Oracle Database 1...
続きを読む

ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13)

イメージ
ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13) https://blogs.oracle.com/cloud-infrastructure/post/milliseconds-matter-bcc-group-and-oci-vs-aws 投稿者： Steven Riley | Senior Cloud Architect William Bierds | Business Analyst and Systems Engineer - BCC Group International Travis Liles | Master Principal Cloud Architect Puru Patel | Cloud Architect - FSI これは、BCC グループと Oracle Cloud Infrastructure (OCI) 間の市場データ パートナーシップを紹介するブログ シリーズの第 2 部です。   はじめに 金融市場データアプリケーションは、トレーダー、金融機関、そして市場参加者が情報に基づいた意思決定を行えるよう、リアルタイムデータを提供することで、取引エコシステムにおいて重要な役割を果たしています。 前回のブログ で述べたように、取引環境において最適なパフォーマンスを確保するには、市場データを超低レイテンシかつ高い信頼性で配信する必要があります。 今日の急速に変化する金融市場において、クラウドは市場データ・アプリケーションにとって強力な推進力として台頭しています。適切なネットワークとインフラストラクチャがあれば、企業は実行時間の短縮、可用性の向上、そして堅牢なセキュリティを実現できます。しかし、企業によるクラウド導入は遅れており、ワークロードのクラウド移行計画を中止しているケースもあります。そこで、BCCグループとOracle Cloud Infrastructure（OCI）のパートナーシップが注目されています。 BCCグループは、主力市場データアプリケーションであるONE PlatformをOCI上に導入しました。このブログでは、以下の点について説明します。 このパートナーシップがなぜこれほど相乗効果をもたらすのかを探る OC...
続きを読む

Oracle Enterprise Manager 24aiの概要 (2024/12/18)

イメージ
Oracle Enterprise Manager 24aiの概要 (2024/12/18) https://blogs.oracle.com/observability/post/oracle-enterprise-manager-24 投稿者： David Le Roy | Senior Director of Product Management 本日、Oracle Enterprise Manager 24ai(EM 24ai)を発表します。これは、最新のAIを活用した管理テクノロジのパワーを活用して、データ・センターとクラウド全体にOracle Databaseとエンジニアド・システムをさらに充実させる画期的なリリースです。ソフトウェアの ダウンロード が可能になりました。この新しいリリースについてさらに学習するには、2024年12月17日から19日に開催されるOracle Enterprise Manager Technology Forumの年次開催にご 参加 ください。 図1: Oracle Enterprise Manager 24aiの概要 この新しいリリースについてさらに学習するには、2024年12月17日から19日に開催されるOracle Enterprise Manager Technology Forumの年次開催にご参加ください。12月17日午前9時に、エンジニアリング担当エグゼクティブ・バイスプレジデントのWim Coekaerts氏と製品管理担当シニア・バイスプレジデントのMughees Minhas氏が率いるイベント基調講演をご覧ください。基調講演に続き、データベース・パフォーマンス、エンジニアド・システム管理、可用性、セキュリティ、コンプライアンスなどに関するベストプラクティスと新製品機能をカバーする25のテクニカル・セッションが追加されました。オラクルのセッションでは、Oracle製品のエキスパートがお客様の技術的な質問にお答えできるよう、Oracle製品マネージャーや主要なお客様が主導しています。 本日 登録 ! Oracle Enterprise Manager 24aiの新機能 EM 24aiリリースは、お客様がオンプレミスおよびクラウドにデプロイされたOracle DatabaseおよびOracle Exadataフ...
続きを読む