Oracle Cloud Infrastructureドキュメント

セキュリティ・ルール

「ネットワーキング」サービスは、両方とも「セキュリティ・ルール」を使用してパケット・レベルでトラフィックを制御する2つの仮想ファイアウォール機能を提供しています。 この2つの機能は次のとおりです:

  • セキュリティ・リスト: ネットワーキングサービスからの元の仮想ファイアウォール機能。
  • ネットワーク・セキュリティ・グループ (NSG): 異なるセキュリティ・ポストを持つアプリケーション・コンポーネント用に設計された後続の機能。

これら2つの機能は、仮想クラウド・ネットワーク(VCN)の一連の仮想ネットワーク・インタフェース・カード(VNIC)にセキュリティ・ルールを適用するためのさまざまな方法を提供しています。

このトピックでは、2つの機能の基本的な相違点について要約します。 また、理解しておく必要があるセキュリティ・ルールの重要な概念についても説明します。 セキュリティ・ルールの作成、管理、適用の方法は、セキュリティ・リストとネットワーク・セキュリティ・グループによって異なります。 実装の詳細は、次の関連トピックを参照してください:

セキュリティ・リストとネットワーク・セキュリティ・グループの比較

「セキュリティ・リスト」を使用すると、「サブネット」全体のすべてのVNICに適用される一連のセキュリティ・ルールを定義できます。 特定のサブネットのある特定のセキュリティ・リストを使用するには、サブネットの作成中またはそれ以降のいずれかのサブネットを使用した「関連付け」セキュリティ・リストを使用します。 サブネットは、最大5つのセキュリティ・リストに関連付けることができます。 そのサブネット内に作成されるVNICは、そのサブネットに関連付けられたセキュリティ・リストの対象になります。

「ネットワーク・セキュリティ・グループ」 (NSG)では、「選択したVNICのグループ」 (またはVNIC 「ロード・バランサやDBシステムなどの親リソース」)に適用する一連のセキュリティ・ルールを定義できます。 例えば: すべてが同じセキュリティ接尾辞を持つ「コンピュート」インスタンスのセットに属するVNIC。 特定のNSGを使用するには、目的のVNICをグループに追加します。 そのグループに追加されたVNICは、そのグループ・セキュリティ・ルールの対象になります。 VNICは、最大5つのNSGに追加できます。

次の図に、概念を示します。

ネットワーク・セキュリティ・グループとセキュリティ・リストの比較。

NSGsではアプリケーションのセキュリティ要件からVCNサブネット・アーキテクチャを分離できるため、Oracleでは、セキュリティ・リストではなくNSGsを使用することをお薦めします。

ただし、必要に応じて、セキュリティ・リストとNSGの両方を使用できます。 詳細は、「セキュリティ・リストとネットワーク・セキュリティ・グループの両方を使用する場合」を参照してください。

VNICと親リソースについて

VNICは、「コンピュート」インスタンスなどのネットワーク・リソースを仮想クラウド・ネットワーク(VCN)に接続できる「ネットワーキング」サービス・コンポーネントです。 VNICは、インスタンスがVCNの内外のエンドポイントとどのように接続するかを決定します。 各VNICは、VCN内のサブネットに存在します。

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

それ以外のタイプの親リソースを作成すると、VNICが自動的に作成されます。 例えば: ロード・バランサを作成すると、「ロード・バランシング」サービスはバックエンド・セット間でトラフィックを貸借一致させるためのVNICを自動的に作成します。 また、DBシステムを作成すると、「データベース」サービスによってVNICがDBシステム・ノードとして自動的に作成されます。 これらのサービスにより、それらの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でアクションを実行しません。 同様に、NSGからVNICを削除する場合は、NSGではなく親リソースを更新することによってこの処理を実行します。 たとえば、既存の「コンピュート」インスタンスVNICをNSGに追加するには、VNICプロパティを更新してNSGを指定します。 たとえば、REST APIでUpdateVnicをコールします。 コンソールで、インスタンスを表示して目的のVNICを表示し、VNICプロパティを編集します。

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

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

NSGのルールを作成する場合は、NSGをトラフィックのソース(イングレス・ルールの場合)またはトラフィック宛先(エグレス・ルールの場合)として指定できます。 このセキュリティ・リスト・ルールと対比して、CIDRをソースまたは宛先として指定します。

NSGを指定する機能は、2つの異なるNSG間のトラフィックを制御するルールを簡単に記述できることを意味します。 NSGは同じVCN内にある必要があります。

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

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

REST APIの相違点

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

デフォルト・ルール

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

制限

2つの機能には異なる制限があります。

セキュリティ・リストの制限
ネットワーク・セキュリティ・グループ制限

セキュリティ・ルールのベスト・プラクティス

ネットワーク・セキュリティ・グループの使用

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

Oracleは、将来の拡張機能を実装する際に、セキュリティ・リストの上でNSGに優先順位を付けるため、NSGを使用することもお薦めします。

デフォルトのセキュリティ・リスト・ルールについて

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

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

デフォルトのセキュリティ・ルールを自動的に削除しない

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

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

Oracleが提供するLinuxイメージまたはWindowsイメージを実行しているインスタンスにも、インスタンスへのアクセスを制御するOSファイアウォール・ルールがあります。 インスタンスへのアクセスをトラブルシューティングするときに、次のアイテムがすべて正しく設定されていることを確認します:

  • インスタンスが存在するネットワーク・セキュリティ・グループ内のルール
  • インスタンス・サブネットに関連付けられているセキュリティ・リスト内のルール
  • インスタンスのOSファイアウォール・ルール

詳細は、「Oracle提供のイメージ」を参照してください。

インスタンスがOracle Linux 7を実行している場合、firewalldを使用してiptablesルールと対話する必要があります。 参考までに、ポートを開くためのコマンドを以下に示します(この例では1521):

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

セキュリティ・ルールのために削除されたパケットをトラブルシューティングするには、VNICメトリックを使用

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

セキュリティ・リストとネットワーク・セキュリティ・グループの両方を使用する場合

セキュリティ・リストは単独またはネットワーク・セキュリティ・グループのみ、あるいはその両方を一緒に使用できます。 これは、特定のセキュリティ・ニーズに依存します。

VCNのすべてのVNICに適用するセキュリティ・ルールがある場合: 最も簡単な解決策は、ルールを1つのセキュリティ・リストに入れ、そのセキュリティ・リストをVCNのすべてのサブネットに関連付けることです。 このようにして、組織の誰がVCNにVNICを作成したかに関係なく、ルールを適用するようにできます。 必要に応じて、VCN 「デフォルト・セキュリティ・リスト」を使用できます。この「デフォルト・セキュリティ・リスト」にはVCNが自動的に付属し、デフォルトで一連の必須ルールが含まれています。

bothセキュリティ・リストおよびネットワーク・セキュリティ・グループの使用を選択すると、指定のVNICに適用される一連のルールが、次のアイテムの結合になります:

  • VNICサブネットに関連付けられているセキュリティ・リスト内のセキュリティ・ルール
  • VNIC内のすべてのNSG内のセキュリティ・ルール

次の図は、アイデアの単純な図です。

VNICは、含まれているすべてのネットワーク・セキュリティ・グループと、そのサブネットに関連付けられているすべてのセキュリティ・リストのルールに依存します。

「関連リストおよびグループ内の任意のルール」がトラフィックを許可する(またはトラフィックが既存の「接続を追跡中」の一部である)場合は、問題のパケットが許容されます。 リストに、同じトラフィックをカバーするステートフルとステートレスの両方のルールが含まれている場合は注意が必要です。 詳細は、「ステートフル対ステートレス・ルール」を参照してください。

セキュリティ・ルールの構成要素

セキュリティ・ルールallowsは、VNIC内の特定タイプのトラフィックまたはVNIC外のトラフィックです。 たとえば、一般的に使用されるセキュリティ・ルールでは、イングレスTCPポート22トラフィックによって、インスタンスへのSSH接続(具体的にはインスタンスVNICに)を確立できます。 セキュリティ・ルールを使用しないと、VCNのVNICの内外でトラフィックを使用できません。

ノート

セキュリティ・ルールは、iSCSIやインスタンス・メタデータなどのサービスを含む169.254.0.0 /16 CIDRブロックを含むトラフィックに対しては強制されません。

各セキュリティ・ルールでは次のアイテムを指定します:

  • 方向(イングレスまたはエグレス): また、イングレスはVNICへのインバウンド・トラフィックであり、エグレスはVNICからのアウトバウンド・トラフィックです。 セキュリティ・リストのREST APIモデルは、ネットワーク・セキュリティ・グループとは異なります。 セキュリティ・リストには、IngressSecurityRuleオブジェクトと、別のEgressSecurityRuleオブジェクトがあります。 ネットワーク・セキュリティ・グループを使用する場合、SecurityRuleオブジェクトのみが存在し、オブジェクトdirection属性によって、ルールがイングレスまたはエグレスに使用されるトラフィックが決定されます。
  • ステートフルまたはステートレス: ステートフルの場合、ルールに一致するトラフィックに接続トラッキングが使用されます。 ステートレスの場合、接続トラッキングは使用されません。 「ステートフル対ステートレス・ルール」も参照してください。
  • ソース・タイプおよびソース(イングレス・ルールのみ): イングレス・ルールに指定するソースは、選択するソース・タイプによって異なります。

    許可されたソース・タイプ
  • 宛先タイプおよび宛先(エグレス・ルールのみ): エグレス・ルールに指定する宛先は、選択する宛先タイプによって異なります。

    許可された宛先タイプ
  • IPプロトコル: すべてのプロトコルをカバーする単一のIPv4プロトコルまたはall。
  • ソース・ポート: トラフィックが発生したポート。 TCPまたはUDPの場合は、すべてのソース・ポートを指定するか、オプションで単一のソース「ポート番号」または範囲を指定できます。
  • 宛先ポート: トラフィックの宛先ポート。 TCPまたはUDPの場合は、すべての宛先ポートを指定するか、オプションで、単一の宛先「ポート番号」または範囲を指定できます。
  • ICMPタイプとコード: ICMPの場合は、すべてのタイプとコードを指定するか、オプションで単一のtypeをオプションのコードで指定することができます。 タイプに複数のコードがある場合は、許可するコードごとに個別のルールを作成します。
  • 「説明」 (NSGルールのみ): NSGセキュリティ・ルールにはオプションの属性が含まれており、ルールにわかりやすい説明を入力できます。 これは現在、セキュリティ・リスト・ルールに対してはサポートされていません。

セキュリティ・ルールの例は、「ネットワークのシナリオ」を参照してください。

作成できるルールの数の制限については、「制限」を参照してください。

ノート

NSGsを使用していて、同じVCN内の2つのVNICが「パブリックIPアドレスの使用」と通信する必要がある場合、関連するセキュリティ・ルールのソース(イングレスの場合)または宛先(エグレスの場合)として、VNICのパブリックIPアドレスを使用し、VNIC NSGを使用しないでください。
パケットはVCNインターネット・ゲートウェイにルーティングされ、この時点ではVNIC NSG情報は使用できません。 したがって、ソースまたは宛先としてNSGを指定するセキュリティ・ルールは、その特定タイプのトラフィックを許可する場合に無効になります。

ステートフル対ステートレス・ルール

セキュリティ・ルールを作成する際には、それがstatefulstatelessかを選択します。 違いについては、次の各項で説明します。 デフォルトはステートフルです。 大量のインターネット対応Webサイト(HTTP/HTTPSトラフィック用)を使用している場合は、ステートレス・ルールが推奨されます。

この項では特に、「コンピュート」インスタンスおよびそれらのトラフィックを示します。 ただし、このディスカッションはVNICを持つすべてのタイプのリソースに適用できます。 「VNICと親リソースについて」も参照してください。

ステートフル・ルール

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

次の図は、HTTPトラフィックを受信して応答する必要があるインスタンスのステートフルなイングレス・ルールを示しています。 インスタンスAとホストBは通信しています(ホストBはインスタンスであろうとなかろうと、どのホストでもかまいません)。 ステートフルなイングレス・ルールは、任意の送信元IPアドレス(0.0.0.0/0)から宛先ポート80のみ(TCPプロトコル)へのトラフィックを許可します。 レスポンス・トラフィックを許可するには、エグレス・ルールは必要ありません。

着信HTTPトラフィックとレスポンスを許可するステートフルなイングレス・ルール

ステートレス・ルール

セキュリティ・ルールをステートレスとしてマークすると、そのルールに一致するトラフィックの接続トラッキングを使用しないことを示します。 つまり、レスポンス・トラフィックは自動的に許可されません。 ステートレス・イングレス・ルールのレスポンス・トラフィックを許可するには、対応するステートレス・エグレス・ルールを作成する必要があります。

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

着信HTTPトラフィックおよびレスポンスを許可するステートレスのイングレスおよびエグレス・ルール

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

インスタンスがHTTPトラフィックを開始してレスポンスを得ることを可能にするステートレスのイングレスおよびエグレス・ルール

インスタンスAでポート・バインディングを使用してHTTPトラフィックがどのポートから来るのかを正確に指定する場合は、エグレス・ルールのソース・ポートとイングレス・ルールの宛先ポートとして指定できます。

ノート

なんらかの理由でステートレス・ルールとステートレス・ルールの両方を使用すると、ステートフル・ルールとステートレス・ルールの両方に特定の方向(たとえば、イングレス)で一致するトラフィックがある場合、ステートレス・ルールが優先され、接続は追跡されません。 レスポンス・トラフィックを許可するには、対応するルールが他の方向(たとえば、エグレス、ステートレスまたはステートフル)で必要です。

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

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

TCP、UDP、およびICMPのレスポンス・トラフィックを判別するために、Oracleは次のアイテムについてパケットの接続トラッキングを実行します:

  • プロトコル
  • 送信元および宛先IPアドレス
  • 送信元ポートと宛先ポート(TCPとUDPのみ)
ノート

他のプロトコルの場合、OracleではプロトコルとIPアドレスのみが追跡され、ポートは追跡されません。 つまり、インスタンスが別のホストへのトラフィックを開始し、そのトラフィックがエグレス・セキュリティ・ルールによって許可される場合、そのインスタンスが後で期間においてそのホストから受信するトラフィックはレスポンス・トラフィックとみなされ、許可されます。

ステートレス・ルールのパスMTUディスカバリ・メッセージのイネーブル化

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

Pingを有効にするルール

VCN 「デフォルト・セキュリティ・リスト」には、複数のデフォルト・ルールが含まれていますが、pingリクエストを許可するものではありません。 インスタンスにpingを実行する場合は、インスタンスに適用可能なセキュリティ・リストまたはNSGにadditionalのステートフル・イングレス・ルールが含まれていることを確認して、ping対象のソース・ネットワークからICMPトラフィック・タイプ8を具体的に許可してください。 インターネットからのpingアクセスを許可する場合は、ソースに対して0.0.0.0/0を使用します。 このpingのルールはデフォルト・セキュリティ・リストのデフォルトのICMP関連のルールとは別のものです。 これらのルールは削除しないでください。

フラグメントされたUDPパケットを処理するルール

インスタンスはUDPトラフィックを送受信できます。 UDPパケットが接続には大きすぎると、フラグメント化されます。 ただし、パケットの最初のフラグメントだけがプロトコルとポート情報を含んでいます。 このイングレスまたはエグレス・トラフィックを許可するセキュリティ・ルールで特定のポート番号(ソースまたは宛先)を指定すると、最初のポートまたは宛先の後のフラグメントが削除されます。 インスタンスで大規模なUDPパケットを送受信することが予想される場合は、該当するセキュリティ・ルールのソース・ポートと宛先ポートの両方を(特定のポート番号ではなく)すべてに設定してください。