仮想ファイアウォール

Networkingサービスは、両方ともセキュリティ・ルールを使用してパケット・レベルでトラフィックを制御する、2つの仮想ファイアウォール機能を提供します。仮想ネットワーク・インタフェース・カード(VNIC)のセットにセキュリティ・ルールを適用する様々な方法を提供します。

セキュリティ・リスト:

セキュリティ・リストは、サブネット・レベルでセキュリティ・ルールを定義します。つまり、特定のサブネット内のすべてのVNICが同じルールに従います。各VCNには、必須トラフィックのデフォルト・ルールを含むデフォルト・セキュリティが付属しています。カスタム・セキュリティ・リストが指定されていないかぎり、デフォルト・セキュリティ・リストはすべてのサブネットで自動的に使用されます。 1つのサブネットは、最大5つのセキュリティ・リストを関連付けることができます。
ネットワーク・セキュリティ・グループ(NSG):

ネットワーク・セキュリティ・グループは、メンバーシップに基づいてセキュリティ・ルールを定義します。セキュリティ・ルールは、NSGに明示的に追加されたリソースに適用されます。 VNICは最大5つのNSGに追加できます。 NSGは、一連のクラウド・リソースに、同じセキュリティ状態を持つ仮想ファイアウォールを提供することを目的としています。たとえば: 同じタスクを実行するため、同じポート・セットを使用する必要があります。

NSGではVCNサブネット・アーキテクチャをアプリケーション・セキュリティ要件から分離できるため、Oracleではセキュリティ・リストではなくNSGを使用することをお薦めします。ただし、NSGは特定のサービスでのみサポートされます。セキュリティ・リストとNSGの両方を、特定のセキュリティ・ニーズに応じて組み合せて使用できます。

VCN内のすべてのVNICに対して適用するセキュリティ・ルールがある場合、最も簡単な解決策は、ルールを1つのセキュリティ・リストに入れ、そのセキュリティ・リストをVCN内のすべてのサブネットに関連付けることです。このようにして、組織内の誰がVCNにVNICを作成するかに関係なく、ルールが適用されるようにできます。または、必要なセキュリティ・ルールをVCNのデフォルト・セキュリティ・リストに追加できます。

セキュリティ・リストとネットワーク・セキュリティ・グループを結合することを選択した場合、特定のVNICに適用されるルールのセットは、次のアイテムを結合したものです:

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

関連するリストおよびグループのいずれかの「任意のルール」でトラフィックが許可されている場合、またはステートフル・ルールのためにトラフィックが追跡されている既存の接続の一部である場合、問題のパケットは許可されます。

セキュリティ・ルール

この項では、セキュリティ・リストまたはネットワーク・セキュリティ・グループの一部として実装するために理解する必要があるセキュリティ・ルールの重要な側面について説明します。セキュリティ・ルールを作成、管理および適用する方法は、セキュリティ・リストとネットワーク・セキュリティ・グループによって異なります。関連セクションには、各実装に関する詳細情報が表示されます。

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

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

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

方向(イングレスまたはエグレス): イングレスはVNICへのインバウンド・トラフィックで、エグレスはVNICからのアウトバウンド・トラフィックです。

セキュリティ・リストのREST APIモデルは、ネットワーク・セキュリティ・グループとは異なります。セキュリティ・リストでは、IngressSecurityRuleオブジェクトと個別のEgressSecurityRuleオブジェクトがあります。ネットワーク・セキュリティ・グループでは、SecurityRuleオブジェクトのみが存在し、オブジェクトのdirection属性によって、ルールがイングレス・トラフィック用かエグレス・トラフィック用かが決まります。
ステートフルまたはステートレス: ステートフルの場合、ルールに一致するトラフィックに接続トラッキングが使用されます。ステートレスの場合、接続トラッキングは使用されません。この項のステートフル・ルールおよびステートレス・ルールを参照してください。

ソース・タイプおよびソース: イングレス・ルールの場合のみ。指定するソースは、選択したソース・タイプによって異なります。次のソース・タイプを使用できます:

ソース・タイプ	許可されたソース
CIDR	トラフィックの発生元のCIDRブロック。すべてのIPアドレスを指定するには、0.0.0.0/0を使用します。プレフィクスは必須です。たとえば、個々のIPアドレスを指定する場合は、 /32を含めます。

宛先タイプと宛先: エグレス・ルールの場合のみ。指定する宛先は、選択した宛先タイプによって異なります。次の宛先タイプを使用できます:

宛先タイプ	許可される宛先
CIDR	トラフィックの宛先のCIDRブロック。すべてのIPアドレスを指定するには、0.0.0.0/0を使用します。プレフィクスは必須です。たとえば、個々のIPアドレスを指定する場合は、 /32を含めます。

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

ステートフルおよびステートレス・ルール

セキュリティ・ルールを作成する場合は、ステートフルかステートレスかを選択します。デフォルトはステートフルです。 HTTP/HTTPSトラフィックのインターネットに直接接続するwebサイトが大量にある場合、ステートレス・ルールをお薦めします。

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

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

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

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

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

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

Oracleでは、すべて同じセキュリティ体制を持つコンポーネントにNSGを使用することをお薦めします。たとえば、複数層アーキテクチャでは、層ごとに個別のNSGを使用します。特定の層VNICは、すべてその層NSGに属します。

特定の層内で、特別なセキュリティ要件が追加された層VNICの特定のサブセットを持つ場合があります。そのため、これらの追加ルール用に別のNSGを作成し、そのVNICのサブセットを追加のルールを持つ層NSGとNSGの両方に配置します。
デフォルト・セキュリティ・リスト・ルールの理解

各VCNには、ネットワーキング・サービスの使用を開始する際に役立ついくつかのデフォルト・セキュリティ・ルールを含むデフォルト・セキュリティ・リストが自動的に付属しています。これらのルールは、基本的な接続を有効にするため存在します。

セキュリティ・リストまたはデフォルト・セキュリティ・リストを使用しない場合でも、ネットワーク・クラウド・リソースが必要とするトラフィックのタイプをよく理解できるように、ルールについて理解してください。これらのルールは、NSGまたは設定したカスタム・セキュリティ・リストで使用できます。

pingリクエストを許可するデフォルト・ルールはありません。インスタンスをpingする場合は、ping元となる予定のソース・ネットワークからのICMPトラフィック・タイプ8を明示的に許可するステートフル・イングレス・ルールを追加します。インターネットからのpingアクセスを許可するには、ソースに0.0.0.0/0を使用します。 pingのこのルールは、デフォルト・セキュリティ・リストのデフォルトのICMP関連ルールとは異なります。これらのルールは削除しないでください。
デフォルト・セキュリティ・ルールを無条件に削除しない

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

pingリクエストを許可するデフォルト・ルールはありません。インスタンスをpingする場合は、ping元となる予定のソース・ネットワークからのICMPトラフィック・タイプ8を明示的に許可するステートフル・イングレス・ルールを追加します。インターネットからのpingアクセスを許可するには、ソースに0.0.0.0/0を使用します。 pingのこのルールは、デフォルト・セキュリティ・リストのデフォルトのICMP関連ルールとは異なります。これらのルールは削除しないでください。
必要に応じて、断片化されたUDPパケットを処理するルールを追加

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

Private Cloud Applianceで提供されるイメージを実行しているインスタンスには、インスタンスへのアクセスを制御するOSファイアウォール・ルールもあります。インスタンスへのアクセスのトラブルシューティングを行う際は、次のアイテムがすべて正しく設定されていることを確認してください:
- インスタンスが存在するネットワーク・セキュリティ・グループ内のルール
- インスタンス・サブネットに関連付けられたセキュリティ・リスト内のルール
- インスタンスOSファイアウォール・ルール

セキュリティ・リスト

セキュリティ・リストは、インスタンスの仮想ファイアウォールとして機能し、送受信を許可するトラフィック・タイプを指定するイングレスおよびエグレス・ルールを使用します。各セキュリティ・リストは、VNICレベルで適用されます。ただし、サブネット・レベルでセキュリティ・リストを構成します。つまり、特定のサブネット内のすべてのVNICが同じセキュリティ・リストのセットに従います。セキュリティ・リストは、VCN内の別のインスタンスと通信しているか、VCN外のホストと通信しているかに関係なく、特定のVNICに適用されます。各サブネットには複数のセキュリティ・リストを関連付けることができ、各リストには複数のルールを含めることができます。

各VCNにはデフォルトのセキュリティ・リストが付属しています。サブネットのカスタム・セキュリティ・リストを指定しない場合、そのサブネットではデフォルト・セキュリティ・リストが自動的に使用されます。デフォルト・セキュリティ・リストでルールを追加または削除できます。ステートフル・ルールの初期セットがあり、ほとんどの場合、認可されたサブネットからのインバウンド・トラフィックのみを許可するように変更する必要があります。デフォルトのルールは次のとおりです:

ステートフル・イングレス: 認可されたソースIPアドレスおよび任意のソース・ポートからの宛先ポート22 (SSH)でのTCPトラフィックを許可します。

このルールを使用すると、新しいクラウド・ネットワークおよびパブリック・サブネットを簡単に作成でき、Linuxインスタンスを起動し、ただちにSSHを使用してそのインスタンスに接続できます。セキュリティ・リスト・ルールは自分で記述する必要はありません。

デフォルトのセキュリティ・リストには、リモート・デスクトップ・プロトコル(RDP)アクセスを許可するルールは含まれていません。 Microsoft Windowsイメージを使用している場合は、認可されたソースIPアドレスおよび任意のソース・ポートから宛先port 3389のTCPトラフィックのステートフル・イングレス・ルールを追加してください。
ステートフル・イングレス: 承認されたソースIPアドレスからのICMPトラフィック・タイプ3コード4を許可します。

このルールにより、インスタンスはPath MTU Discoveryフラグメンテーション・メッセージを受信できます。
ステートフル・イングレス: VCN CIDRブロックからのICMPトラフィック・タイプ3 (すべてのコード)を許可します。

このルールにより、インスタンスがVCN内の他のインスタンスから接続エラー・メッセージを受信しやすくなります。
ステートフル・エグレス: すべてのトラフィックを許可します。

これにより、インスタンスは任意の宛先への任意の種類のトラフィックを開始できます。これは、パブリックIPアドレスを持つインスタンスが、VCNに構成済のインターネット・ゲートウェイがある場合、任意のインターネットIPアドレスと通信できることを意味します。また、ステートフル・セキュリティ・ルールでは接続トラッキングが使用されるため、イングレス・ルールに関係なくレスポンス・トラフィックが自動的に許可されます。

セキュリティ・リストを使用する一般的なプロセスは次のとおりです:

セキュリティ・リストを作成します。
セキュリティ・リストにセキュリティ・ルールを追加します。
セキュリティ・リストを1つ以上のサブネットに関連付けます。
サブネット内にコンピュート・インスタンスなどのリソースを作成します。

セキュリティ・ルールは、そのサブネット内のすべてのVNICに適用されます。

サブネットを作成する場合、少なくとも1つのセキュリティ・リストを関連付ける必要があります。これは、VCNデフォルト・セキュリティ・リストか、すでに作成した1つ以上の他のセキュリティ・リストのいずれかです。サブネットが使用するセキュリティ・リストは、いつでも変更できます。セキュリティ・リストでルールを追加または削除できます。セキュリティ・リストにルールが含まれていない可能性があります。

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

ネットワーク・セキュリティ・グループ(NSG)は、単一のVCN内で、すべて同じセキュリティ体制を持つ一連のクラウド・リソースに対して仮想ファイアウォールを提供します。たとえば: すべて同じタスクを実行するコンピュート・インスタンスのグループで、すべて同じポート・セットを使用する必要があります。

NSGのルールはVNICに適用されますが、NSGメンバーシップは親リソースを介して決定されます。すべてのクラウド・サービスがNSGをサポートしているわけではありません。現在、次のタイプの親リソースはNSGの使用をサポートしています:

コンピュート・インスタンス: インスタンスを作成する際、インスタンスのプライマリVNICに1つ以上のNSGを指定できます。セカンダリVNICをインスタンスに追加する場合、そのVNICに1つ以上のNSGを指定できます。既存のVNICのNSGメンバーシップを変更することもできます。
マウント・ターゲット: ファイル・システムのマウント・ターゲットを作成する場合は、1つ以上のNSGを指定できます。 1つ以上のNSGを使用するように既存のマウント・ターゲットを更新することもできます。

NSGをまだサポートしていないリソース・タイプについては、セキュリティ・リストを引き続き使用して、それらの親リソースとの間のトラフィックを制御します。

NSGには、次の2つのタイプの要素があります:

VNICs: 1つ以上のVNIC(すべてのセキュリティ状態が同じコンピュート・インスタンスのセットにアタッチされているVNICなど)。すべてのVNICは、NSGが属するVCN内にある必要があります。 VNICは最大5つのNSG内にできます。
セキュリティ・ルール: グループ内のVNICとの間で許可されるトラフィックのタイプを定義するルール。たとえば: 特定のソースからのイングレスTCPポート22 SSHトラフィック。

NSGを使用する一般的なプロセスは次のとおりです:

NSGを作成します。

NSGを作成すると、セキュリティ・ルールまたはVNICを使用せずに、最初は空になります。 NSGの作成後、セキュリティ・ルールを追加または削除して、グループ内のVNICに必要なイングレス・トラフィックおよびエグレス・トラフィックのタイプを許可します。
セキュリティ・ルールをNSGに追加します。
親リソース(特にVNIC)をNSGに追加します。

NSG VNICメンバーシップを管理する場合、NSG自体ではなく親リソースの操作の一部として行います。親リソースの作成時にこれを実行することも、親リソースを更新して1つ以上のNSGに追加することもできます。

コンピュート・インスタンスを作成してNSGに追加すると、インスタンスのプライマリVNICがNSGに追加されます。セカンダリVNICは個別に作成でき、オプションでNSGに追加できます。

セキュリティ・リストと比較して、NSGのREST APIモデルにはいくつかの違いがあります:

セキュリティ・リストでは、IngressSecurityRuleオブジェクトと個別のEgressSecurityRuleオブジェクトがあります。ネットワーク・セキュリティ・グループでは、SecurityRuleオブジェクトのみが存在し、オブジェクトのdirection属性によって、ルールがイングレス・トラフィック用かエグレス・トラフィック用かが決まります。
セキュリティ・リストでは、ルールはSecurityListオブジェクトの一部であり、たとえばセキュリティ・リスト操作をコールしてルールを使用: UpdateSecurityList。 NSGでは、ルールはNetworkSecurityGroupオブジェクトの一部ではありません。かわりに、別の操作を使用して、特定のNSGのルールを操作します。たとえば、: UpdateNetworkSecurityGroupSecurityRules。
既存のセキュリティ・ルールを更新するモデルは、セキュリティ・リストとNSGで異なります。 NSGでは、特定のグループ内の各ルールに一意の識別子があります。 UpdateNetworkSecurityGroupSecurityRulesをコールするときに、更新する特定のルールのIDを指定します。セキュリティ・リストでは、ルールに一意の識別子はありません。 UpdateSecurityListをコールする場合、コールで更新されていないルールを含め、ルールのリスト全体を渡す必要があります。
セキュリティ・ルールを追加、削除または更新する操作をコールする場合、ルールは25に制限されています。