セキュリティ・ルール

VNICと親リソースについて

VNICは、Virtual Cloud Network (VCN)に接続するためにコンピュート・インスタンスなどのネットワーク・リソースに必要なネットワーキング・サービス・コンポーネントです。VNICは、VCN内外でインスタンスがエンドポイントに接続する方法に影響します。各VNICは、VCN内のサブネットに存在します。

コンピュート・インスタンスを作成すると、そのインスタンスのサブネット内のインスタンスにVNICが自動的に作成されます。インスタンスは、VNICの親リソースとみなされます。コンピュート・インスタンスにさらに(セカンダリ) VNICを追加できます。このため、インスタンスのVNICは、コンソール内のコンピュート・インスタンスの関連リソースの一部として目立つように表示されます。

他のタイプの親リソースでも、VNICが自動的に作成されます。たとえば、ロード・バランサを作成すると、ロード・バランサ・サービスによって、バックエンド・セット全体でトラフィックのバランシングを行うVNICが自動的に作成されます。また、DBシステムを作成すると、データベース・サービスによってVNICがDBシステム・ノードとして自動的に作成されます。これらのサービスにより、VNICが作成および管理されます。このため、これらのVNICは、VNICがコンピュート・インスタンスの場合と同じように、コンソールで明らかではありません。

NSGを使用するには、VNICをグループにアクティブに配置します。VNICは特定のサブネット内にあるため、NSGに含まれません。ただし、VNIC自体ではなく、グループにVNICを追加する場合、通常は親リソースを使用します。たとえば、コンピュート・インスタンスを作成するときに、オプションでそのインスタンスにNSGを指定できます。概念的にはインスタンスをグループに配置しますが、実際のインスタンスのプライマリVNICをネットワーク・セキュリティ・グループに配置します。グループのセキュリティ・ルールは、インスタンスではなくVNICに適用されます。また、セカンダリVNICをインスタンスに追加する場合、オプションでそのVNICにNSGを指定でき、ルールはインスタンスではなくそのVNICに適用されます。NSG内のすべてのVNICは、NSGが属する同じVCNにある必要があることに注意してください。

同様に、ネットワーク・セキュリティ・グループに負荷バランサを配置する場合、概念的には負荷バランサをグループに配置します。技術的には、ロード・バランサ・サービスによって管理されるVNICをネットワーク・セキュリティ・グループに配置します。

NSGのVNICメンバーシップは親リソースで管理し、NSG自体では管理しません。たとえば、親リソースをNSGに追加するには、(親リソースを追加するNSCを指定することで)親リソースに対してアクションを実行しますNSGではアクションを実行しません(NSGに追加するVNICまたは親リソースを指定)。同様に、NSGからVNICを削除するには、NSGではなく親リソースを更新してそのアクションを実行します。たとえば、既存のコンピューティング・インスタンスのVNICをNSJに追加する場合は、そのVNICのプロパティを更新し、NSGを指定します。たとえば、REST APIを使用して、UpdateVnicをコールします。コンソールで、インスタンスおよび目的のVNICを表示し、そこでVNICのプロパティを編集します。

NSGの使用をサポートする親リソースのリストについては、ネットワーク・セキュリティ・グループのサポートを参照してください。

ルールのソースまたは宛先としてのネットワーク・セキュリティ・グループ

セキュリティ・リストと比較してNSGのセキュリティ・ルールを記述する方法の1つの重要な違い: NSGのルールを記述する場合は、トラフィックのソース(イングレス・ルールの場合)またはトラフィックの宛先(エグレス・ルールの場合)として、NSGを指定できます。これとは対照的に、セキュリティ・リスト・ルールでは、ソースまたは宛先としてCIDRを指定します。

NSGを指定できるため、2つの異なるNSG間のトラフィックを制御するルールを容易に記述できます。各NSGは同じVCN内にある必要があります。

また、特定のNSG内のVNIC間のトラフィックを制御するために、ルール独自のNSGをソース(イングレス・ルールの場合)または宛先(エグレス・ルールの場合)として指定するルールを記述できます。

詳細は、ネットワーク・セキュリティ・グループの概要を参照してください。

REST APIの相違点

NSGのREST APIモデルには、セキュリティ・リストと比較して、いくつかの基本的な違いがあります。詳細は、APIの使用を参照してください。

デフォルト・ルール

VCNには、ネットワーク・サービスの使用を開始する際に役立つデフォルトのセキュリティ・ルールがいくつか含まれているデフォルト・セキュリティ・リストが自動的に付属しています。サブネットを作成するとき、VCNですでに作成したカスタム・セキュリティ・リストを指定しないかぎり、デフォルトのセキュリティ・リストがサブネットに関連付けられます。

比較すると、VCNにデフォルトのネットワーク・セキュリティ・グループはありません。

制限

2つの機能の制限は異なります。適用可能な制限の一覧と制限の引上げをリクエストする手順は、「サービス制限」を参照してください。

ネットワーク・セキュリティ・グループを使用します

すべてのコンポーネントに同じセキュリティ体制を持つNSGを使用することをお薦めします。たとえば、複数階層アーキテクチャでは、各層に対して個別のNSGを使用します。層のVNICは、すべてその層のNSGに属します。特定の層内に、特別なセキュリティー要件を持つ層のVNICの特定のサブセットが存在する場合があります。したがって、これらの追加ルール用に別のNSGを作成し、そのVNICのサブセットを階層のNSGと追加NSGの両方に配置します。

Oracle also recommends using NSGs because Oracle prioritizes NSGs over security lists when implementing future enhancements.

デフォルト・セキュリティ・リストのルールを理解します

VCNには、ネットワーク・サービスの使用を開始する際に役立つデフォルトのセキュリティ・ルールがいくつか含まれているデフォルト・セキュリティ・リストが自動的に付属しています。これらのルールは、基本的な接続を可能にするために存在します。セキュリティ・リストまたはデフォルト・セキュリティ・リストを使用しない場合でも、ネットワーク・クラウド・リソースが必要とするトラフィックのタイプをよく理解できるように、ルールを精通します。このようなルールは、NSGで、または設定したカスタム・セキュリティ・リストで使用できます。

デフォルトのセキュリティ・リストには、pingを有効にするルールは含まれません。pingを使用する必要がある場合は、Pingを有効化するルールを参照してください。

デフォルト・セキュリティ・ルールを無計画に削除しないでください

VCNに、デフォルトのセキュリティ・リストをデフォルトで使用するサブネットがある場合があります。リストのデフォルト・セキュリティ・ルールは、VCN内のリソースで必要とされないことを最初に確認しないかぎり、削除しないでください。そうしないと、VCNの接続が中断される可能性があります。

OSファイアウォール・ルールがセキュリティ・ルールと一致していることの確認

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo firewall-cmd --reload

セキュリティ・ルールのためにドロップされたパケットのトラブルシューティングにはVNICメトリックを使用します

ネットワーキング・サービスは、VNICトラフィックのレベル(パケットおよびバイト)を示すVNICのメトリックを提供します。2つのメトリックは、セキュリティ・ルールに違反してドロップされるイングレス・パケットおよびエグレス・パケット用です。これらのメトリックを使用すると、セキュリティー規則に関連する問題のトラブルシューティングや、VNICが適切なトラフィックを受信しているかどうかのトラブルシューティングに役立ちます。

ステートフル・ルール

セキュリティ・ルールをステートフルとしてマークすることは、そのルールに一致するトラフィックに対して接続トラッキングを使用することを示します。これは、インスタンスがステートフル・イングレス・ルールに一致するトラフィックを受け取ると、インスタンスに適用されるエグレス・ルールに関係なく、レスポンスがトラッキングされ、元のホストに自動的に戻されることを意味します。また、インスタンスがステートフル・エグレス・ルールに一致するトラフィックを送信すると、イングレス・ルールに関係なく、受信レスポンスが自動的に許可されます。

たとえば、ホストBからHTTPトラフィックを受信して応答する必要があるインスタンス(インスタンスA)に対して、ステートフル・イングレス・セキュリティ・ルールを設定できます。ホストBは、インスタンスかどうかにかかわらず、任意のホストです。ステートフル・イングレス・ルールにより、任意のソースIPアドレス(0.0.0.0/0)から宛先ポート80のみ(TCPプロトコル)へのトラフィックが許可されているため、インスタンスAとホストBは通信を行います。レスポンスは自動的にトラッキングおよび許可されるため、レスポンス・トラフィックを許可するエグレス・ルールは必要ありません。

ステートレス・ルール

次の図は、インスタンスAとホストBを前のように示していますが、ステートレス・セキュリティ・ルールが使用されています。前の項のステートフル・ルールと同様に、ステートレス・イングレス・ルールでは、宛先ポート80のみで、すべてのIPアドレスおよび任意のポートからの(TCPプロトコルを使用した)トラフィックが許可されます。レスポンス・トラフィックを許可するには、対応するステートレス・エグレス・ルールが必要です。このルールでは、ソース・ポート80のみから任意の宛先IPアドレス(0.0.0.0/0)および任意のポートへの(TCPプロトコルを使用した)トラフィックを許可します。

インスタンスAでHTTPトラフィックを開始してレスポンスを取得する必要がある場合は、別のステートレス・ルールのセットが必要です。次の図に示すように、エグレス・ルールには、ソース・ポート = allおよび宛先ポート = 80 (HTTP)が含まれます。イングレス・ルールには、ソース・ポート80および宛先ポート = allが含まれます。

インスタンスAでポート・バインディングを使用してHTTPトラフィックの発生元のポートを正確に指定する場合は、エグレス・ルールのソース・ポートおよびイングレス・ルールの宛先ポートとしてそれを指定できます。

ステートフル・ルールの接続トラッキングの詳細

Oracleは接続トラッキングを使用して、ステートフル・ルールと一致するトラフィックに対するレスポンスを許可する(ステートフル・ルールおよびステートレス・ルールとの比較を参照)。各インスタンスには、インスタンスのシェイプに基づいてトラッキングできる同時接続の最大数があります。

TCP、UDPおよびICNPのレスポンス・トラフィックを決定するために、Oracleはパケットについて次の項目の接続トラッキングを実行します:

• プロトコル
• ソースおよび宛先のIPアドレス
• ソースおよび宛先のポート(TCPおよびUDPの場合のみ)

追跡された接続は、接続のトラフィックが受信されるかぎり保持されます。接続が十分にアイドル状態になると、タイムアウトして削除されます。接続が削除されると、ステートフル・セキュリティ・ルールのレスポンスが削除されます。次の表に、デフォルトのアイドル・タイムアウトを示します:

ステートレス・ルールでのPath MTU Discoveryメッセージの有効化

ステートレス・セキュリティ・ルールを使用してVCN外部のエンドポイント間のトラフィックを許可する場合、ソース0.0.0.0/0および任意のソース・ポートからのイングレスICMPトラフィック・タイプ3のコード4を許可するセキュリティ・ルールを追加することが重要です。このルールを使用すると、コンピュート・インスタンスがPath MTU Discoveryフラグメンテーション・メッセージを受信できるようになります。このルールは、インスタンスとの接続を確立するために重要です。これがない場合、接続性の問題が発生する可能性があります。詳細は、接続のハングを参照してください。