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

• ネットワーク・セキュリティ・グループ(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ゲートウェイへのアクセスを制御できます。
• Functions: OCI Functionsでアプリケーションを設定する場合、1つ以上のNSGを指定して、その特定のアプリケーション内のすべての関数に適用されるイングレスおよびエグレス・ルールを定義できます。
• GoldenGateデプロイメント: GoldenGateデプロイメントを作成する場合、1つ以上のNSGを指定して、デプロイメントへのアクセスを制御できます。
• クラスタの再定義: Redisクラスタを作成するときに、1つ以上のNSGを指定してRedisクラスタへのアクセスを制御できます。また、既存のクラスタを更新して、1つ以上のNSGを使用することもできます。

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

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

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

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

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

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

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

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

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

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

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

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

NSGセキュリティ・ルールの基本をまだ把握していない場合は、セキュリティ・ルールのトピックで次の項を参照してください:

• セキュリティ・ルールの構成要素
• ステートフル・ルールとステートレス・ルール

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

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

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

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

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

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

NSGの削除

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

必須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ポリシーを参照してください。