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を使用することもできます。

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

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

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

NSGは、2つのタイプのアイテムで構成されます(次の図を参照):

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

ネットワーク・セキュリティ・グループには、VNICおよびセキュリティ・ルールが含まれます。

同じ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セキュリティ・ルールの基本をまだ把握していない場合は、セキュリティ・ルールのトピックで次の項を参照してください:

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

警告

Oracle Cloud Infrastructureコンソール、APIまたはCLIを使用して、クラウド・リソースに説明、タグまたはわかりやすい名前を割り当てる場合、機密情報を入力することは避けてください。

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自体ではなく親リソースの作業の一部として実行します。詳細は、VNICと親リソースについてを参照してください。

セキュリティ・ルールでの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のセキュリティ・ルールおよびリソースを表示するには
NSGを作成するには
NSGに対してリソースを追加または削除するには
NSGを削除するには
NSGのセキュリティ・ルールを管理するには
NSGのタグを管理するには
NSGを別のコンパートメントに移動するには

APIの使用

APIの使用およびリクエストの署名の詳細は、REST APIおよびセキュリティ資格証明を参照してください。SDKの詳細は、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。

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

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

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