Oracle Cloud Infrastructureドキュメント

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

ネットワーキング・サービスには、パケット・レベルでトラフィックを制御するために2つの仮想ファイアウォール機能が用意されています:

  • ネットワーク・セキュリティ・グループ: このトピックで説明します。ネットワーク・セキュリティ・グループは、特定のサービスに対してのみサポートされます。
  • セキュリティ・リスト: ネットワーキング・サービスが提供する元のタイプの仮想ファイアウォール。セキュリティ・リストを参照してください。

これらの機能はどちらもセキュリティ・ルールを使用します。セキュリティ・ルールの仕組みに関する重要な情報、およびセキュリティ・リストとネットワーク・セキュリティ・グループの一般的な比較については、セキュリティ・ルールを参照してください。

ハイライト

  • ネットワーク・セキュリティ・グループ(NSG)は、コンピュート・インスタンスや他の種類のリソースで仮想ファイアウォールとして機能します。NSGは、単一のVCN内で選択した一連のVNICにのみ適用されるイングレスおよびエグレス・セキュリティ・ルールのセットで構成されます(例: VCN内の複数層アプリケーションのWeb層にあるWebサーバーとして機能するすべてのコンピュート・インスタンス)。
  • NSGでは、セキュリティ・リストと比較して、VCNのサブネット・アーキテクチャをアプリケーションのセキュリティ要件から分離できます。セキュリティ・リストとネットワーク・セキュリティ・グループの比較を参照してください。
  • 特定のリソース・タイプでNSGを使用できます。詳細は、ネットワーク・セキュリティ・グループのサポートを参照してください。
  • NSGセキュリティ・ルールはセキュリティ・リスト・ルールと同様に機能します。ただし、NSGセキュリティ・ルールのソース(イングレス・ルールの場合)または宛先(エグレス・ルールの場合)では、CIDRのかわりにNSGを指定できます。つまり、セキュリティ・ルールを記述して、同じVCN内の2つのNSG間のトラフィック、または1つのNSG内のトラフィックを簡単に制御できます。セキュリティ・ルールの構成要素を参照してください。
  • セキュリティ・リストと異なり、VCNにはデフォルトのNSGはありません。また、作成する各NSGも最初は空です。デフォルトのセキュリティ・ルールはありません。
  • ネットワーク・セキュリティ・グループには、セキュリティ・リストと比較して異なる個別の制限があります。セキュリティ・リストの制限を参照してください。

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

NSGは、ユーザーが作成して使用できます。ただし、関連するすべてのOracle Cloud Infrastructureサービスで、まだサポートされていません。

現在、次のタイプの親リソースはNSGの使用をサポートしています:

  • コンピュート・インスタンス: インスタンスを作成する場合、インスタンスのプライマリVNICに1つ以上のNSGを指定できます。セカンダリVNICをインスタンスに追加する場合、そのVNICに1つ以上のNSGを指定できます。また、インスタンスにある既存のVNICを1つ以上のNSGに含まれるように更新することもできます。
  • ロード・バランサ: ロード・バランサを作成するときに、(バックエンド・セットではなく)ロード・バランサに対して1つ以上のNSGを指定できます。また、既存のロード・バランサを更新して、1つ以上のNSGを使用することもできます。
  • DBシステム: DBシステムを作成する場合、1つ以上のNSGを指定できます。また、既存のDBシステムを更新して、1つ以上のNSGを使用することもできます。
  • Autonomous Database: 専用ExadataインフラストラクチャにAutonomous Databaseを作成する場合、インフラストラクチャ・リソースに1つ以上のNSGを指定できます。また、既存の専用Exadataインフラストラクチャ・インスタンスを更新して、NSGを使用することもできます。
  • マウント・ターゲット: ファイル・システムのマウント・ターゲットを作成する場合、1つ以上のNSGを指定できます。また、既存のマウント・ターゲットを更新して、1つ以上のNSGを使用することもできます。
  • DNSリゾルバ・エンドポイント: プライベートDNSリゾルバのエンドポイントを作成する場合、1つ以上のNSGを指定できます。また、既存のエンドポイントを更新して、1つ以上のNSGを使用することもできます。
  • Kubernetesクラスタ: Container Engine for Kubernetesを使用してKubernetesクラスタを作成する場合、1つ以上のNSGを指定して、Kubernetes APIエンドポイントおよびワーカー・ノードへのアクセスを制御できます。クラスタのロード・バランサを定義するときにNSGを指定することもできます。
  • APIゲートウェイ: APIゲートウェイを作成する場合、1つ以上のNSGを指定して、APIゲートウェイへのアクセスを制御できます。
  • ファンクション: OCIファンクションでアプリケーションを設定する場合、1つ以上のNSGを指定して、その特定のアプリケーションのすべての機能に適用されるイングレスおよびエグレス・ルールを定義できます。
  • GoldenGateデプロイメント: GoldenGateデプロイメントを作成する場合、1つ以上のNSGを指定して、デプロイメントへのアクセスを制御できます。

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

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

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

NSGは、2つのタイプのアイテムで構成されます:

同じVCN内に異なるセキュリティ体制を持つリソースがある場合、NSGセキュリティ・ルールを記述して、ある体制と別の体制を使用してリソース間のトラフィックを制御できます。たとえば、次の図で、NSG1には複数層アーキテクチャ・アプリケーションの1つの層で実行されるVNICがあります。NSG2には、もう1つの層で実行されるVNICがあります。NSGはどちらも同じVCNに属する必要があります。前提として、NSGは両方とも他のNSGへの接続を開始する必要があるとします。

NSG1では、宛先としてNSG2を指定するエグレス・セキュリティ・ルールと、ソースとしてNSG2を指定するイングレス・セキュリティ・ルールを設定します。同様に、NSG2では、宛先としてNSG1を指定するエグレス・セキュリティ・ルールと、ソースとしてNSG1を指定するイングレス・セキュリティ・ルールを設定します。この例では、ルールはステートフルとみなされます。

2つのネットワーク・セキュリティ・グループ間のトラフィックを制御するセキュリティ・ルールを設定できます。

この図では、各NSGが他のNSGへの接続を開始する必要があると想定しています。

次の図では、NSG1からNSG2へ開始される接続のみを許可することを想定しています。これを行うには、NSG1からイングレス・ルールを削除し、NSG2からエグレス・ルールを削除します。残りのルールでは、NSG2からNSG1に開始される接続は許可されません。

これらのセキュリティ・ルールにより、NSG1からNSG2への1方向にのみ開始される接続が許可されます。

次の図では、同じNSG内のVNIC間のトラフィックを制御することを想定しています。これを行うには、ルールのソース(イングレスの場合)または宛先(エグレスの場合)をルール独自のNSGとして設定します。

セキュリティ・ルールを設定して、同じNSG内のVNIC間のトラフィックを制御できます。

VNICは、最大5つのNSGで使用できます。いずれかのVNICのNSGのルールでトラフィックを許可する場合(またはトラフィックがトラッキング対象の既存の接続の一部である場合)、目的のパケットは許可されます。同じトラフィックをカバーするステートフル・セキュリティ・ルールとステートレス・セキュリティ・ルールの両方がリストに含まれる場合は注意が必要です。詳細は、ステートフル・ルールとステートレス・ルールを参照してください。

ネットワーク・セキュリティ・グループはリージョナル・エンティティです。ネットワーク・セキュリティ・グループに関連する制限については、セキュリティ・リストとネットワーク・セキュリティ・グループの比較を参照してください。

制限関連の情報については、ネットワーク・セキュリティ・グループの制限およびサービス制限の引上げのリクエストを参照してください。

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

NSGの作業の一般的なプロセス

  1. NSGを作成します。
  2. セキュリティ・ルールをNSGに追加します。
  3. 親リソース(具体的にはVNIC)をNSGに追加します。親リソースを作成するときにこれを実行するか、または親リソースを更新して1つ以上のNSGに追加できます。コンピュート・インスタンスを作成してNSGに追加すると、インスタンスのプライマリVNICがNSGに追加されます。別に、セカンダリVNICを作成し、オプションでNSGに追加できます。

NSGを削除する前に、すべてのVNICを削除する必要があります。

詳細は、次の各項を参照してください。

NSGの作成

各VCNには、基本的な接続を可能にするデフォルトのセキュリティ・ルールが含まれるデフォルト・セキュリティ・リストが付属しています。ただし、VCNにはデフォルトのNSGはありません。

NSGを作成すると、最初は空になり、セキュリティ・ルールもVNICも含まれません。コンソールを使用している場合は、作成中にセキュリティ・ルールをNSGに追加できます。

オプションとして、作成時にNSGにわかりやすい名前を割り当てることができます。一意である必要はなく、後で変更できます。Oracleは、Oracle Cloud ID (OCID)と呼ばれる一意の識別子をNSGに自動的に割り当てます。詳細は、リソース識別子を参照してください。

アクセス制御の目的のために、NSGを配置するコンパートメントを指定する必要があります。使用するコンパートメントが不明な場合は、組織の管理者に問い合せてください。詳細は、アクセス制御を参照してください。

セキュリティ・ルールおよびグループ・メンバーシップの更新

NSGを作成した後、グループ内のVNICが必要とするイングレス・トラフィックおよびエグレス・トラフィックのタイプを許可するセキュリティ・ルールを追加または削除できます。

セキュリティ・リストを熟知していて、REST APIを使用している場合、既存のセキュリティ・ルールを更新するためのモデルは、セキュリティ・リストとNSGでは異なることに注意してください。NSGを使用する場合、指定されたグループ内の各ルールには一意のOracle割当て識別子があります(例: 04ABEC)。UpdateNetworkSecurityGroupSecurityRulesをコールするときは、更新する特定のルールのIDを指定します。一方で、セキュリティ・リストを使用する場合、ルールに一意の識別子はありません。UpdateSecurityListをコールする場合、コールで更新されないルールも含め、ルールのリスト全体を渡す必要があります。

NSGのVNICメンバーシップを管理する場合、これはNSG自体ではなく親リソースの作業の一部として実行します。詳細は、セキュリティ・リストとネットワーク・セキュリティ・グループの比較を参照してください。

セキュリティ・ルールでのNSGの指定

前述のネットワーク・セキュリティ・グループの概要で説明したように、特定のNSGのセキュリティ・ルールでソース(イングレス・ルールの場合)または宛先(エグレス・ルールの場合)としてNSGを指定できます。2つのNSGが同じVCN内にある必要があります。たとえば、NSG1とNSG2の両方が同じVCNに属する場合は、NSG2をソースとしてリストするNSG1にイングレス・ルールを追加できます。他のユーザーがNSG2を削除すると、ルールは無効になります。REST APIでは、SecurityRuleオブジェクトでisValidブール値を使用してそのステータスを伝達しています。

NSGの削除

NSGを削除するには、それにVNICまたは親リソースが含まれていない必要があります。親リソース(またはコンピュート・インスタンスのVNIC)が削除されると、親リソースは含まれていたNSGから自動的に削除されます。特定の親リソースを削除する権限がないこともあります。管理者に連絡し、特定のリソースを所有するユーザーを確認してください。

コンソールに、NSGにある親リソースのリストが各親リソースへのリンクとともに表示されます。親リソースがコンピュート・インスタンスの場合、コンソールには、インスタンスのVNICまたはNSG内のVNICも表示されます。

リソースを削除せずにNSGから親リソースを削除するには、最初にコンソールで親リソースの詳細を表示してください。リソースが属するNSGのリストが表示されます。そこで「編集」をクリックして、すべてのNSGからリソースを削除できます。かわりにコンピュート・インスタンスの作業を行う場合は、NSGから削除する特定のVNICの詳細を表示してください。

REST APIを使用している場合、ListNetworkSecurityGroupVnicsにNSG内の親リソースとVNICがリストされます。リソースの更新操作を使用して、NSGからリソースを削除します。たとえば、コンピュート・インスタンスの場合は、UpdateVnic操作を使用します。ロード・バランサの場合は、UpdateNetworkSecurityGroups操作を使用します(他も同様です)。

必須IAMポリシー

Oracle Cloud Infrastructureを使用するには、管理者からポリシーでセキュリティ・アクセス権が付与されている必要があります。コンソールまたは(SDK、CLIまたはその他のツールを使用した) REST APIのどれを使用しているかにかかわらず、このアクセス権が必要です。権限がない、または認可されていないというメッセージが表示された場合は、自分がどのタイプのアクセス権を持っているか、およびどのコンパートメントで作業するかを管理者に確認してください。

管理者用: ネットワーク管理者によるクラウド・ネットワークの管理のポリシーは、NSGを含むすべてのネットワーキング・コンポーネントの管理をカバーします。

NSGを管理する必要があるが、ネットワーキング・サービスの他のコンポーネントは管理する必要がないセキュリティ管理者がいる場合は、より制限的なポリシーを作成できます: 

Allow group NSGAdmins to manage network-security-groups in tenancy
			
Allow group NSGAdmins to manage vcns in tenancy 
      where ANY {request.operation = 'CreateNetworkSecurityGroup',
                 request.operation = 'DeleteNetworkSecurityGroup'}

Allow group NSGAdmins to read vcns in tenancy

Allow group NSGAdmins to use VNICs in tenancy

最初のステートメントにより、NSGAdminsグループはNSGとそのセキュリティ・ルールを作成および管理できます。

NSGの作成または削除は、NSGが存在するVCNに影響するため、2番目のステートメントは必須です。このステートメントは、VCN関連の権限を、NSGの作成または削除に必要な権限のみに制限します。このステートメントでは、NSGAdminsグループがVCNを作成または削除したり、NSGを除くVCN内のリソースを操作したりすることは許可されません。

3番目のステートメントは、VCNをリストするために必須であり、VCNでNSGを作成または削除するための前提条件です。2番目と3番目のステートメントの両方が必須である理由の詳細は、条件を参照してください。

NSGAdminsがVNICをNSGに配置する必要がある場合は、4番目のステートメントが必要です。VNICの親リソース(たとえば、コンピュート・インスタンス)を作成するユーザーには、親リソースを作成するためのこのレベルの権限がすでに付与されている必要があります。

ネットワーキング・サービス・ポリシーの詳細は、ネットワーキングに対するIAMポリシーを参照してください。

コンソールの使用

NSGのセキュリティ・ルールおよびリソースを表示するには
  1. ナビゲーション・メニューを開き、「ネットワーキング」、「仮想クラウド・ネットワーク」の順にクリックします。
  2. 関心のあるVCNをクリックします。
  3. 「リソース」で、「ネットワーク・セキュリティ・グループ」をクリックします。

  4. 目的のNSGをクリックして詳細を表示します。

    NSGのセキュリティ・ルールがページに表示されます。ここで、ルールを追加、編集または削除できます。

  5. 「リソース」で、「VNIC」をクリックし、NSGに属する親リソースを表示します。

    親リソースがコンピュート・インスタンスである場合は、そのインスタンスの対応するVNICもページにリストされます。

    その他のタイプの親リソースでは、関連サービスが自動的にVNICを管理します。したがって、親リソースのみ(対応するVNIC以外)がページにリストされます。

NSGを作成するには

前提条件: セキュリティ・ルールの構成要素について理解します。

  1. ナビゲーション・メニューを開き、「ネットワーキング」、「仮想クラウド・ネットワーク」の順にクリックします。
  2. 関心のあるVCNをクリックします。
  3. 「リソース」で、「ネットワーク・セキュリティ・グループ」をクリックします。
  4. 「ネットワーク・セキュリティ・グループの作成」をクリックします。

  5. 次を入力します:

    1. 名前: ネットワーク・セキュリティ・グループのわかりやすい名前。名前は一意である必要はなく、後で変更できます。機密情報の入力は避けてください。
    2. コンパートメントで作成: ネットワーク・セキュリティ・グループを作成するコンパートメント(現在作業しているコンパートメントと異なる場合)。
    3. タグ付けオプションの表示: リソースの作成権限がある場合、そのリソースにフリーフォーム・タグを適用する権限もあります。定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。タグ付けの詳細は、リソース・タグを参照してください。タグを適用するかどうかがわからない場合は、このオプションをスキップするか(後でタグを適用できます)、管理者に問い合せてください。

  6. 「次」をクリックします。

    ルールを使用せずにNSGを作成する場合は、「作成」をクリックして終了します。それ以外の場合は、次のステップに進みます。

  7. 最初のセキュリティ・ルールについては、次の項目を入力します(ルールの例は、ネットワーキング・シナリオを参照してください):

    • ステートフルまたはステートレス: ステートフルの場合は、ルールに一致するトラフィックに接続トラッキングが使用されます。ステートレスの場合、接続トラッキングは使用されません。デフォルトでは、特に指定しないかぎりルールはステートフルです。ステートフル・ルールとステートレス・ルールを参照してください。
    • 方向(イングレスまたはエグレス): イングレスはVNICへのインバウンド・トラフィックで、エグレスはVNICからのアウトバウンド・トラフィックです。

    • ソース・タイプおよびソース(イングレス・ルールの場合のみ):

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

      サービス・ゲートウェイを介してOracleサービスから受信するパケットのみ。

      ソース・サービスは、目的のサービスCIDRラベルです。
      ネットワーク・セキュリティ・グループ

      このルールのNSGと同じVCN内にあるNSG。

    • 宛先タイプおよび宛先(エグレス・ルールの場合のみ):

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

      サービス・ゲートウェイを介してOracleサービスに送信するパケットのみ。

      宛先サービスは、目的のサービスCIDRラベルです。
      ネットワーク・セキュリティ・グループ

      このルールのNSGと同じVCN内にあるNSG。
    • IPプロトコル: 単一のIPv4プロトコル(TCP、ICMPなど)、またはすべてのプロトコルをカバーする場合は「all」。
    • ソース・ポート範囲: トラフィックの発生元のポート。TCPまたはUDPの場合、すべてのソース・ポートを指定するか、オプションで単一のソース・ポート番号または範囲を指定できます。
    • 宛先ポート範囲: トラフィックの宛先のポート。TCPまたはUDPの場合、すべての宛先ポートを指定するか、オプションで単一の宛先ポート番号または範囲を指定できます。
    • ICMPタイプおよびコード: ICMPの場合、すべてのタイプおよびコードを指定することも、オプションで単一のタイプとオプション・コードを指定することもできます。タイプに複数のコードがある場合は、許可するコードごとに別々のルールを作成します。
  8. 別のセキュリティ・ルールを追加するには、「+別のルール」をクリックしてルールの情報を入力します。追加するルールごとに繰り返します。
  9. 終了したら、「作成」をクリックします。

NSGが作成され、選択したコンパートメントの「ネットワーク・セキュリティ・グループ」ページに表示されます。インスタンスまたは他のタイプの親リソースを作成または管理する際に、このNSGを指定できるようになりました。

NSGのすべてのセキュリティ・ルールを表示する場合は、イングレスまたはエグレスでリストをフィルタできます。

NSGに対してリソースを追加または削除するには

一般に、NSGのリソース・メンバーシップは親リソースで管理し、NSG自体では管理しません。つまり、親リソースをNSGに追加するには、(親リソースを追加するNSGを指定することで)親リソースに対してアクションを実行します。(NSGに追加するVNICまたは親リソースを指定することで) NSGに対してアクションを実行しません。同様に、VNICをNSGから削除するには、NSGではなく親リソースを更新してそのアクションを実行します。NSGの使用をサポートする親リソースのリストについては、ネットワーク・セキュリティ・グループのサポートを参照してください。

例: コンピュート・インスタンス
  • インスタンスの作成時: 「ネットワーキング」セクションの拡張オプションで、「ネットワーク・セキュリティ・グループを使用してトラフィックを制御」のチェック・ボックスを選択します。次に、1つ以上のNSGを指定します。インスタンスのプライマリVNICがNSGに追加されます。インスタンスの作成の手順を参照してください。
  • 既存のインスタンスの場合: NSGに既存のインスタンスを追加するということは、そのプライマリVNICをNSGに追加することを意味します。また、NSGにセカンダリVNICを追加することもできます。ネットワーク・セキュリティ・グループに対してVNICを追加または削除するにはを参照してください。
例: Exadata Cloud VMクラスタ
  • Exadata Cloud VMクラスタの作成時: 「ネットワーク情報」セクションで、クライアント・ネットワークおよびバックアップ・ネットワークを設定します。ネットワークごとに、「ネットワーク・セキュリティ・グループを使用してトラフィックを制御」チェック・ボックスを選択して、特定のネットワークに1つ以上のNSGを指定します。クラウドVMクラスタ・リソースを作成するにはを参照してください。Exadata Cloud Serviceインスタンスのネットワーク設定も参照してください。
  • 既存のExadata Cloud Serviceインスタンスの場合: Exadata Cloud VMクラスタの詳細には、クライアント・ネットワークが属するNSGのリスト(ある場合)、およびバックアップ・ネットワークが属するNSGのリスト(ある場合)が含まれます。関連するネットワーク・セキュリティ・グループの横にある「編集」をクリックして、リストを変更します。
NSGを削除するには

前提条件: セキュリティ・リストを削除するには、サブネットに関連付けられていない必要があります。VCNのデフォルト・セキュリティ・リストは削除できません。

  1. ナビゲーション・メニューを開き、「ネットワーキング」、「仮想クラウド・ネットワーク」の順にクリックします。
  2. 関心のあるVCNをクリックします。
  3. 「リソース」で、「ネットワーク・セキュリティ・グループ」をクリックします。
  4. 削除するネットワーク・セキュリティ・グループについて、「アクション」メニューをクリックし、「終了」をクリックします。
  5. プロンプトが表示されたら確認します。
NSGのセキュリティ・ルールを管理するには
  1. ナビゲーション・メニューを開き、「ネットワーキング」、「仮想クラウド・ネットワーク」の順にクリックします。
  2. 関心のあるVCNをクリックします。
  3. 「リソース」で、「ネットワーク・セキュリティ・グループ」をクリックします。

  4. 目的のNSGをクリックして詳細を表示します。

    NSGのセキュリティ・ルールがページに表示されます。ここで、ルールを追加、編集または削除できます。

NSGのタグを管理するには
  1. ナビゲーション・メニューを開き、「ネットワーキング」、「仮想クラウド・ネットワーク」の順にクリックします。
  2. 関心のあるVCNをクリックします。
  3. 「リソース」で、「ネットワーク・セキュリティ・グループ」をクリックします。
  4. 目的のNSGをクリックします。
  5. 既存のタグを表示または編集するには、「タグ」タブをクリックします。または、「タグの追加」をクリックして新しいタグを追加します。

詳細は、リソース・タグを参照してください。

NSGを別のコンパートメントに移動するには

NSGは、コンパートメント間で移動できます。NSGを新しいコンパートメントに移動すると、固有のポリシーがただちに適用されます。

  1. ナビゲーション・メニューを開き、「ネットワーキング」、「仮想クラウド・ネットワーク」の順にクリックします。
  2. 関心のあるVCNをクリックします。
  3. 「リソース」で、「ネットワーク・セキュリティ・グループ」をクリックします。
  4. NSGの「アクション」メニューをクリックし、「リソースの移動」をクリックします。
  5. リストから宛先コンパートメントを選択します。
  6. 「リソースの移動」をクリックします。

コンパートメントとポリシーを使用したクラウド・ネットワークへのアクセスの制御の詳細は、アクセス制御を参照してください。コンパートメントに関する一般情報は、コンパートメントの管理を参照してください。

APIの使用

APIの使用およびリクエストの署名の詳細は、REST APIのドキュメントおよびセキュリティ資格証明を参照してください。SDKの詳細は、SDKおよびCLIを参照してください。

VCNのネットワーク・セキュリティ・グループを管理するには、次の操作を使用します:

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

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