Grupos de seguridad de red

• Los grupos de seguridad de la red (NSG) actúan como un firewall virtual para instancias informticas 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 conjunto de VNIC que se puede seleccionar en una única VCN (por ejemplo, todas la instancias de Compute que actúan como servidores web en el nivel web de una aplicación de varios Niveles en una VCN).
• En comparación con las listas de seguridad, los NSG permiten separar una arquitectura de subred de la VCN de los requisitos del entorno de seguridad de la 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 lo que ocurre con las listas, la VCN no tiene un NSG 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 son compatibles con todos los servicios relevantes de Oracle Cloud Infrastructure.

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 encuentran en uno o más NSG.
• Equilibrios de cargas: al crear un equilibrador de cargas, puede especificar uno o más grupos de seguridad de seguridad de sistema para el equilibrador de cargas (no el juego de backends). También puede actualizar un equilibrador de cargamento existente para utilizar uno o más NSG.
• 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 NSG para el recurso del infraestructura.
• 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.
• Despliegues de GoldenGate: 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 aún no admiten grupos de seguridad de redes, continúe utilizando listas del sistema 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 de Compute que realizan las mismas tareas y, por lo tanto, todas deben utilizar el mismo conjunto de puertos.

Un NSG consta de dos tipos de elementos:

• VNIC: una o más VNIC (por ejemplo, las VNIC asociadas al conjunto de instancias de Compute que tienen la misma posición que la 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 posturas de seguridad diferentes en la misma VCN, puede escribir reglas de seguridad del NSG para controlar el tráfico entre los recursos con una postura frente a otra. Por ejemplo, en el siguiente diagrama, NSG1 tiene VNIC que se ejecutan en una capa de una aplicación en arquitectura de varios capas. 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 NSG necesitan iniciar las conexiones con otros NSG.

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 NSG necesita iniciar conexiones con el otro NSG.

En el siguiente diagrama se supone que, en su lugar, solo 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 de 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 NSG de la VNIC permite el tráfico (o si el tráfico es parte de una conexión existente de la que se está realizando un seguimiento), a menos que las listas contengan reglas de seguridad con estado y sin estado que cubran el mismo tráfico. Para obtener más información, consulte Stateful Compared to Stateless Rules.

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
• Con estado en comparación con las reglas 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.

Hay varias diferencias en el modelo del API de REST para el NSG, en comparación con las lista de seguridad:

• Con las listas de seguridad hay un objeto de IngressSecurityRule y un objeto de EgressSecurityRule independiente. Los grupos de seguridad de red solo tienen un objeto SecurityRule y el atributo direction del objeto muestra si la regla es para el tráfico de entrada o de 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 que forman parte del objeto NetworkSecurityGroup. En su lugar, se utilizan operaciones independientes para trabajar con las reglas para un NSG 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 concreto tiene un identificador asignado por Oracle único (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 aquellas reglas que no se estén actualizando en la operación.
• La seguridad establece un límite de 25 reglas al llamar a las operaciones para agregar, eliminar o actualizar.