Oracle Database@AWS: カスタム・ポートのセキュリティ・ルール (2026/05/08)

Oracle Database@AWS: カスタム・ポートのセキュリティ・ルール (2026/05/08)

https://www.ateam-oracle.com/oracle-databaseaws-security-rules-for-custom-ports

投稿者：Aditya Kulkarni | Senior Cloud Engineer

はじめに

Oracle Database@AWSの導入が拡大するにつれ、ネットワークセキュリティ構成は、お客様から最もよく寄せられる質問の一つとなっています。多くの場合、お客様は特定のアプリケーション接続要件をサポートするために、カスタムデータベースポートへのアクセスを許可する必要があります。

このブログでは、Oracle Database@AWSにおけるセキュリティルールの管理方法の概要を簡単に説明した後、OCI上でカスタムネットワークセキュリティグループ（NSG）を使用してカスタムポートを開く方法について説明します。

本格的に取り組む前に、このサービスにおけるネットワークの基本概念をしっかりと理解するために、以下のブログ記事を読んでおくことをお勧めします。

Oracle Database@AWSにおけるネットワークの基礎知識

ODB@AWS のネットワークセキュリティ管理

Oracle Database@AWS でネットワーク セキュリティ ルールがどのように管理されるかを詳しく見ていきましょう。ODB ネットワークが作成されると、次のネットワーク セキュリティ グループ (NSG) が自動的にプロビジョニングされます。

  • exa_1521_adjustable_nsgおよびexa_static_nsg はExadata デプロイメントをサポートします
  • exa_backup_adjustable_nsgおよびexa_backup_static_nsg は、Exadata デプロイメントのバックアップ操作をサポートします。
  • adb_1521_2484_adjustable_nsgおよびexa_static_nsg は、 Autonomous Database のデプロイメントをサポートします。
  • DNS解決のためのdns_nsg
  • リカバリーサービス用のzrcv_nsg

議論を絞り込むため、このブログでは、VMクラスタに関連付けられているExadataのデプロイメント、特にexa_1521_adjustable_nsgとexa_static_nsgに焦点を当てます。

これらのNSG内では、ODBネットワークのピアリングされたCIDRリストに含まれるCIDR範囲に対して、一連のルールが自動的に作成されます。

例えば、CIDR 10.13.0.0/25 を持つ ODB ネットワークを作成し、CIDR 範囲 10.13.1.0/24 を使用する VPC とピアリング接続しました。

exa_1521_adjustable_nsgは以下のように構成されています。

exa_static_nsgはクラスタ内通信に使用され、以下のエントリが含まれます。

ここで、SSHアクセス用にポート22など、追加のポートを開放する必要があるシナリオを考えてみましょう。

技術的には、自動化によって作成されたNSGに、選択した送信元IPアドレス範囲からのポート22へのアクセスを許可するカスタムルールを追加することは可能ですが、これは推奨される方法ではありません。

CIDR範囲がODBネットワークのピアリングされたCIDRリストに追加または削除される際に、これらのNSGがどのように管理されるかを見れば、その理由が明らかになります。

ODBネットワークのピアリングされたCIDRリストが変更された場合のNSGの自動動作

この動作を説明するために、自動化管理されたNSGに、ピアリングされたCIDR範囲10.13.1.0/24に対してポート22を開放するルールを追加してみましょう。

それでは、ODBネットワークがIPアドレス範囲10.13.2.0/24を使用する別のVPCとピアリングするように更新された場合に何が起こるかを見てみましょう。

VPCのCIDR範囲がピアリングされたCIDRリストに反映されました。次に、OCIのNSG構成を確認しましょう。

ご覧のとおり、NSGには新たにピアリングされたCIDR範囲10.13.2.0/24用の自動化ルールが含まれていますが、10.13.1.0/24のポート22用のカスタムルールは含まれていません。

この動作は設計上の仕様です。ODBネットワーク上のピアリングされたCIDRリストが変更されるたびに（CIDR範囲の追加または削除に関わらず）、自動化機能はリストを再スキャンし、NSGを元の自動化管理状態にリセットします。その結果、ピアリングされたCIDRに対して手動で追加されたカスタムルールはすべて削除されます。

そこで次の疑問が生じます。追加のアクセス要件を適切に処理するにはどうすればよいのでしょうか？

ソリューション：顧客管理型NSG

推奨される方法は、カスタムNSGを作成することです。

OCIコンソールで、自動化によってプロビジョニングされたVCNに移動し、[セキュリティ]タブを開いて、[ネットワークセキュリティグループ]を選択します。新しいNSGを作成し、必要な送信元CIDR範囲からポート22へのイングレスルールを追加します。

NSGを作成したら、クラスターのネットワークセクションに移動し、クライアントNSGリストにNSGを関連付けます。VMクラスターには、最大5つのNSGを関連付けることができます。

このアプローチでは、自動化によって管理されるNSGとは独立して、専用のNSGでカスタムルールを管理できます。

このブログではExadataに焦点を当てていますが、同じベストプラクティスはAutonomous Databaseの導入やその他のカスタムポート要件にも適用できます。

まとめ

Oracle Database@AWSでは、自動化管理型のNSGは必要な接続性を維持するように設計されており、ピアリングされたCIDRリストが変更されると自動的に更新されます。これらのNSGへの手動変更は上書きされる可能性があるため、追加のアクセス要件には専用のカスタムNSGを使用することをお勧めします。これにより、セキュリティを維持し、構成のずれを防ぎ、カスタムポートを安心して管理できます。

コメント

コメントを投稿

このブログの人気の投稿

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...
続きを読む

OCIのカスタム・ルート表を使用した詳細なルーティング制御 (2025/02/27)

イメージ
OCIのカスタム・ルート表を使用した詳細なルーティング制御 (2025/02/27) https://www.ateam-oracle.com/post/granular-routing-control-with-custom-route-tables-in-oci 投稿者： Achinthya Gopinath | Principal Cloud Architect OCIでは、カスタムVCNルート表をVNIC上の個々のVNICまたは特定のIPアドレスに割り当てることができるため、ルーティングの柔軟性を高める強力な新機能が導入されました。この更新により、異なるトラフィック・ルーティング・ポリシーを必要とするインスタンスに対して個別のサブネットを作成する必要がなくなります。 概要: 以前は、VCNルート表はサブネット・レベルでのみ割り当てられていました。つまり、同じサブネット内の異なるインスタンスで異なるルーティング・ルールが必要な場合は、別々のサブネットを作成し、ネットワーク設計に複雑さを加える必要がありました。 この機能により、次のことができるようになりました。 •    カスタムVCNルート表をVNICまたはVNICの特定のIPアドレスに割り当てます。 •    プライマリIPアドレスとセカンダリIPアドレスの両方にルーティング・ポリシーを適用します。 •    階層ルート表のプリファレンスを有効にします。このプリファレンスは、使用するルート表を決定する構造化アプローチに従います。 ルーティングに関する考慮事項: •    一度にトラフィック・ルーティングを決定するために使用されるルート表は1つのみです。 •    ルート表がIPアドレスに関連付けられている場合は、他のルート表よりも優先されます。 •    IPアドレス/VNICにルート表がない場合は、階層内の次に使用可能なルート表(VNICレベルまたはサブネット・レベル)が使用されます。 詳細の選択プロセス: 1.    VNICのIPアドレスにルート表が関連付けられている場合、その表はIPアドレスからのトラフィックのルーティングに使用されます。 2.  ...
続きを読む