この記事はAditya KulkarniによるOracle Database@AWS: Security Rules for Custom Portsを日本語に翻訳したものです。
2026年05月08日
はじめに
Oracle Database@AWSの採用が拡大するにつれて、ネットワーク・セキュリティ構成は、お客様から最も多く寄せられるトピックの1つであり続けています。多くの場合、お客様は特定のアプリケーション接続要件をサポートするために、カスタム・データベース・ポートへのアクセスを許可する必要があります。
このブログでは、Oracle Database@AWSでセキュリティ・ルールがどのように管理されるかを簡単に概説し、そのうえで、OCI上のカスタムNetwork Security Group（NSG）を使用してカスタム・ポートを開く方法を説明します。
本題に入る前に、このサービスの基礎となるネットワーク概念をしっかり理解するため、次のブログを確認することをお勧めします。
ODB@AWSのネットワーク・セキュリティ管理
Oracle Database@AWSでネットワーク・セキュリティ・ルールがどのように管理されるかを詳しく見ていきましょう。ODBネットワークが作成されると、次のNetwork Security Group（NSG）が自動的にプロビジョニングされます。
- exa_1521_adjustable_nsgおよびexa_static_nsg: Exadataデプロイメントをサポート
- exa_backup_adjustable_nsgおよびexa_backup_static_nsg: Exadataデプロイメントのバックアップ操作をサポート
- adb_1521_2484_adjustable_nsgおよびadb_static_nsg: Autonomous Databaseデプロイメントをサポート
- dns_nsg: DNS解決用
- zrcv_nsg: Recovery Service用
議論の焦点を絞るため、このブログではExadataデプロイメント、特にVMクラスタに関連付けられる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へのアクセスを許可するカスタム・ルールを追加することは、技術的には可能です。しかし、これは推奨される方法ではありません。
その理由は、ODBネットワークのピアリング済みCIDRリストにCIDR範囲が追加または削除されたときに、これらのNSGがどのように管理されるかを見ると明らかになります。
ODBネットワークのピアリング済みCIDRリストが変更された場合の自動NSG動作
この動作を説明するために、自動化管理のNSGに、ピアリング済みCIDR範囲10.13.1.0/24に対してポート22を開くルールを追加してみます。
次に、IP範囲10.13.2.0/24を使用する別のVPCとピアリングするようにODBネットワークを更新した場合に、何が起こるかを見てみましょう。
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に移動し、「Security」タブを開いて、「Network Security Groups」を選択します。新しいNSGを作成し、必要な送信元CIDR範囲からポート22へのイングレス・ルールを追加します。
NSGを作成したら、クラスタの「Network」セクションに移動し、それをクライアントNSGリストにアタッチします。1つのVMクラスタには、最大5つのNSGを関連付けることができます。
この方法により、自動化管理のNSGとは独立して、専用NSG内でカスタム・ルールを管理できます。
このブログではExadataに焦点を当てていますが、同じベスト・プラクティスはAutonomous Databaseデプロイメントや、その他のカスタム・ポート要件にも適用されます。
まとめ
Oracle Database@AWSでは、自動化管理のNSGは必要な接続性を維持するように設計されており、ピアリング済みCIDRリストの変更に応じて自動的に更新されます。これらのNSGに対する手動変更は上書きされる可能性があるため、追加のアクセス要件には専用のカスタムNSGを使用することが推奨されます。これにより、セキュリティを維持し、構成ドリフトを避け、カスタム・ポートを安心して管理できます。