Grupos de seguridad de red

• Los grupos de seguridad de red (NSG) actúan como un firewall virtual para sus instancias informáticas y otros tipos de recursos. Un NSG consta de un juego de reglas de seguridad de entrada y salida que se aplican solo a un juego de VNIC que se puede elegir en una única VCN (por ejemplo, todas las instancias informáticas que actúan como servidores web en la capa web de una aplicación de varios niveles en VCN).
• En comparación con las listas de seguridad, los grupos de seguridad de red permiten separar la arquitectura de subred de la VCN de los requisitos de seguridad de su aplicación. Consulte Comparación de listas de seguridad y grupos de seguridad de red.
• Puede utilizar grupos de seguridad de red con determinados tipos de recursos. Para obtener más información, consulte Soporte para grupos de seguridad de red.
• Las reglas de seguridad NSG funcionan del mismo modo que las reglas de listas de seguridad. Sin embargo, para el origen de una regla de seguridad de un grupo de seguridad de red (para reglas de entrada) o el destino (para reglas de salida), puede especificar un grupo de seguridad de red en lugar de un CIDR. Esto significa que puede escribir con facilidad reglas de seguridad para controlar el tráfico entre dos grupos de seguridad de red en la misma VCN o el tráfico dentro de un solo grupo de seguridad de red. Consulte Partes de una regla de seguridad.
• A diferencia de las listas de seguridad, la VCN no tiene ningún grupo de seguridad de red por defecto. Además, cada NSG que cree se encuentra inicialmente vacío. No tiene reglas de seguridad por defecto.
• Los grupos de seguridad de red tienen límites diferentes e independientes en comparación con las listas de seguridad. Consulte Límites de lista de seguridad.

Existen grupos de seguridad de red disponibles para su creación y utilización. Sin embargo, aún no los admiten todos los servicios relevantes de Oracle Cloud Infrastructure.

Actualmente, los siguientes tipos de recursos principales admiten el uso de grupos de servicios de red:

• Autonomous Recovery Service (subredes para Recovery Service): al registrar una subred de Recovery Service, puede asociar uno o más NSG (cinco como máximo) que contengan las reglas de entrada para Recovery Service.
• Instancias de Compute: cuando crea una instancia, puede especificar uno o más grupos de servicios de red para la VNIC principal de la instancia. Si agrega una VNIC secundaria a una instancia, puede especificar uno o más grupos de servicios de red para esa VNIC. También puede actualizar VNIC existentes en una instancia para que se encuentren en uno o más NSG.
• Equilibrios de carga: al crear un equilibrador de carga, puede especificar uno o más grupos de servicios de red para el equilibrador de carga (no el conjunto de backends). También puede actualizar un equilibrador de carga existente para utilizar uno o más grupos de servicios de red.
• Sistemas de base de datos: cuando crea un sistema de base de datos, puede especificar uno o más grupos de servicios de red. También puede actualizar un sistema de base de datos existente para usar uno o más grupos de servicios de red.
• Bases de datos autónomas: cuando crea una instancia de Autonomous Database en una infraestructura de Exadata dedicada, puede especificar uno o varios grupos de seguridad de red para el recurso de infraestructura. También puede actualizar una instancia de infraestructura exclusiva de Exadata existente para que utilice grupos de seguridad de red.
• Destinos de montaje: cuando crea un destino de montaje para un sistema de archivos, puede especificar uno o más grupos de seguridad de red. También puede actualizar un destino de montaje existente para usar uno o más grupos de servicios de red.
• Punto final de solucionador de DNS: cuando crea un punto final para un solucionador de DNS privado, puede especificar uno o más NSG. También puede actualizar un punto final existente para usar uno o más NSG.
• Cluster de Kubernetes: cuando crea un cluster de Kubernetes mediante Kubernetes Engine, puede especificar uno o más NSG para controlar el acceso al punto final de API de Kubernetes y a los nodos de trabajador. También puede especificar los NSG al definir un equilibrador de carga para un cluster.
• Gateways de API: al crear un gateway de API, puede especificar uno o más NSG para controlar el acceso al gateway de API.
• Functions: al configurar una aplicación en OCI Functions, puede especificar uno o más NSG para definir reglas de entrada y salida que se aplican a todas las funciones de esa aplicación en particular.
• GoldenGate despliegues: al crear un despliegue de GoldenGate, puede especificar uno o más NSG para controlar el acceso al despliegue.
• Clusters de Redis: al crear un cluster de Redis, puede especificar uno o más NSG para controlar el acceso al cluster de Redis. También puede actualizar un cluster existente para usar uno o más NSG.

Para tipos de recursos que todavía no admiten grupos de servicios de red, continúe usando listas de seguridad para controlar el tráfico entrante y saliente de esos recursos principales.

Un grupo de seguridad de red (NSG) proporciona un firewall virtual para un conjunto de recursos en la nube que tienen la misma posición de seguridad. Por ejemplo, un grupo de instancias informáticas que realizan las mismas tareas y, por lo tanto, todas deben utilizar el mismo juego de puertos.

Un NSG consta de dos tipos de elementos:

• VNIC: una o más VNIC (por ejemplo, las VNIC asociadas al juego de instancias informáticas que tienen la misma posición de seguridad). Todas las VNIC deben estar en la misma VCN que el NSG. Consulte también Comparación de listas de seguridad y grupos de seguridad de red.
• Reglas de seguridad: las reglas de seguridad del NSG definen los tipos de tráfico permitidos de entrada y salida de las VNIC en el grupo. Por ejemplo: tráfico de shell seguro del puerto 22 TCP de entrada desde un origen concreto.

Si tiene recursos con posiciones de seguridad diferentes en la misma VCN, puede escribir reglas de seguridad del grupo de seguridad de red para controlar el tráfico entre los recursos con una posición frente a otra. Por ejemplo, en el siguiente diagrama, NSG1 tiene las VNIC que se ejecutan en un nivel de una aplicación de arquitectura de varios niveles. NSG2 tiene las VNIC en ejecución en un segundo nivel. Ambos grupos de seguridad de red deben pertenecer a la misma VCN. La suposición es que ambos grupos de seguridad de red necesitan iniciar las conexiones con otros grupos de seguridad de red.

Para NSG1, se configuran las reglas de seguridad de salida que especifican NSG2 como destino, así como las reglas de seguridad de entrada que especifican NSG2 como origen. Del mismo modo, para NSG2, se configuran las reglas de seguridad de salida que especifican NSG1 como destino, y las reglas de seguridad de entrada que especifican NSG1 como origen. Se supone que las reglas se encuentran con estado en este ejemplo.

El diagrama anterior supone que cada grupo de seguridad de red necesita iniciar conexiones con el otro.

En el siguiente diagrama se supone que en su lugar desea permitir conexiones iniciadas desde NSG1 a NSG2. Para ello, elimine la regla de entrada de NSG1 y la de salida de NSG2. Las reglas restantes no permiten conexiones iniciadas desde NSG2 a NSG1.

En el siguiente diagrama, se supone que se desea controlar el tráfico entre las VNIC en el mismo grupo de seguridad de red. Para ello, establezca el origen (para la entrada) o el destino (para la salida) de la regla como el grupo de seguridad de red propio.

Una VNIC puede tener un máximo de cinco grupos de seguridad de red. Se permite un paquete en cuestión si cualquier regla de cualquiera de los grupos de seguridad de red de las VNIC permite el tráfico (o si el tráfico forma parte de una conexión existente de la que se está realizando un seguimiento). Hay una excepción si resulta que las listas contienen reglas de seguridad con estado y sin estado que cubren el mismo tráfico. Para obtener más información, consulte Reglas con estado frente a sin estado.

Los grupos de seguridad de red son entidades regionales. Para conocer los límites relacionados con los grupos de seguridad de red, consulte Comparación de listas de seguridad y grupos de seguridad de red.

Consulte Límites de grupo de seguridad de red y Solicitud de aumento del límite de servicio para obtener información relacionada con los límites.

Si aún no está familiarizado con los conceptos básicos de las reglas de seguridad de un grupo de seguridad de red, consulte estas secciones en el tema sobre reglas de seguridad:

• Partes de una regla de seguridad
• Reglas con estado frente a sin estado

Para obtener más información sobre el uso de la API y la firma de solicitudes, consulte la documentación de la API de REST y Credenciales de seguridad. Para obtener información sobre los SDK, consulte Los SDK y la CLI.

Para obtener más información sobre el uso de la API y la firma de solicitudes, consulte la documentación de la API de REST y Credenciales de seguridad. Para obtener información sobre los SDK, consulte Los SDK y la CLI.

Existen algunas diferencias en el modelo de API de REST para los grupos de seguridad de red en comparación con las listas de seguridad:

• Con las listas de seguridad, hay un objeto IngressSecurityRule y otro objeto EgressSecurityRule independiente. Con los grupos de seguridad de red, solo hay un objeto SecurityRule y el atributo direction del objeto determina si la regla es para el tráfico de entrada o salida.
• Con las listas de seguridad, las reglas forman parte del objeto SecurityList y se trabaja con las reglas llamando a las operaciones de la lista de seguridad (como UpdateSecurityList). Con los grupos de seguridad de red, las reglas no forman parte del objeto NetworkSecurityGroup. En su lugar, se utilizan operaciones independientes para trabajar con las reglas para un grupo de seguridad de red determinado (por ejemplo: UpdateNetworkSecurityGroupSecurityRules).
• El modelo para actualizar reglas de seguridad existentes es diferente entre listas de seguridad y grupos de seguridad de red. Con los grupos de servicios de red, cada regla de un grupo determinado tiene un identificador único asignado por Oracle (por ejemplo: 04ABEC). Al llamar a UpdateNetworkSecurityGroupSecurityRules, proporciona los identificadores de las reglas específicas que desea actualizar. En comparación, con las listas de seguridad, las reglas no tienen ningún identificador único. Al llamar a UpdateSecurityList, debe transferir toda la lista de reglas, incluidas las reglas que no se están actualizando en la operación.
• Hay un límite de 25 reglas al ejecutar operaciones que agreguen, eliminen o actualicen reglas de seguridad.