セキュリティ・ルール

VNICと親リソースについて

VNICは、ネットワーキング・サービス・コンポーネントであり、コンピュート・インスタンスなどのネットワーク・リソースがVirtual Cloud Network (VCN)に接続できるようにします。VNICは、インスタンスがVCNの内外のエンドポイントと接続する方法を決定します。各VNICは、VCN内のサブネットに存在します。

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

他にも、VNICが自動的に作成される、ユーザーが作成可能な親リソースのタイプがあります。たとえば、ロード・バランサを作成すると、ロード・バランサ・サービスによって、バックエンド・セット間のトラフィックを分散するためにVNICが自動的に作成されます。また、DBシステムを作成すると、データベース・サービスによって、DBシステム・ノードとしてVNICが自動的に作成されます。これらのサービスにより、VNICが作成および管理されます。そのため、これらのVNICは、コンピュート・インスタンスのVNICと同じようにわかりやすくコンソール内に表示されません。

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

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

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

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

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

セキュリティ・リストと比較して、NSGのセキュリティ・ルールを記述する方法には、重要な違いがあります。

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では、将来の拡張機能を実装するときに、セキュリティ・リストよりもNSGを優先する予定のため、NSGの使用が推奨されます。

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

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およびICMPのレスポンス・トラフィックを特定するために、Oracleはパケットについて次の項目の接続トラッキングを実行します:

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

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

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

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