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 de su elección 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 la 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:

• Servicio de recuperación autónoma (subredes para el servicio de recuperación): al registrar una subred de servicio de recuperación, puede asociar uno o más NSG (cinco como máximo) que contengan las reglas de entrada para el servicio de recuperación.
• 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.
• Autonomous Database: cuando crea una Autonomous Database en una infraestructura exclusiva de Exadata, 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.
• Clusters de Kubernetes: cuando crea un cluster de Kubernetes mediante Container Engine for Kubernetes, 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 grupos de servicios de red

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 NSG de la VNIC permite el tráfico (o si el tráfico forma parte de una conexión existente cuyo seguimiento se está realizando). 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 llamada.
• Hay un límite de 25 reglas al ejecutar operaciones que agreguen, eliminen o actualicen reglas de seguridad.

Proceso general para trabajar con grupos de seguridad de red

1. Cree un grupo de seguridad de red.
2. Agregue reglas de seguridad al grupo de seguridad de red.
3. Agregue recursos principales (o más específicamente, VNIC) a los grupos de seguridad de red. Puede hacerlo cuando crea el recurso principal, o bien puede actualizar el recurso principal y agregarlo a uno o más grupos de seguridad de red. Cuando crea una instancia de Compute y la agrega a un grupo de seguridad de red, la VNIC principal de la instancia se agrega al grupo de seguridad de red. Por separado, puede crear VNIC secundarias y, opcionalmente, agregarlas a grupos de seguridad de red.

Supresión de grupos de seguridad de red

Para suprimir un NSG, no debe contener ninguna VNIC ni recursos principales. Cuando se suprime un recurso principal (o una VNIC de instancia informática), se suprime automáticamente de los NSG en los que se encontraba. Puede que no tenga permiso para suprimir un recurso principal concreto. Póngase en contacto con el administrador para determinar quién es el propietario de un recurso determinado.

Política de IAM necesaria

Para que pueda utilizar Oracle Cloud Infrastructure, un administrador le debe otorgar acceso de seguridad en una política . Este acceso es necesario tanto si utiliza la Consola como la API de REST con un SDK, una CLI u otra herramienta. Si obtiene un mensaje que indica que no tiene permiso o no está autorizado, verifique con el administrador el tipo de acceso que posee y en qué compartimento  debería trabajar.

Para administradores: la política para permitir a los administradores de red gestionar una red en la nube abarca la gestión de todos los componentes de Networking, incluidos los grupos de seguridad de red.

Si tiene administradores de seguridad que necesitan gestionar grupos de seguridad de red, pero no otros componentes del servicio de Networking, puede crear una política más restrictiva:

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

La primera sentencia permite al grupo NSGAdmins crear y gestionar los grupos de seguridad de red y sus reglas de seguridad.

La segunda sentencia es necesaria porque la creación o supresión de un grupo de seguridad de red afecta a la VCN en la que se encuentra dicho grupo. La sentencia restringe los permisos relacionados con la VCN a únicamente aquellos requeridos para crear o suprimir un grupo de seguridad de red. La sentencia no permite que el grupo NSGAdmins cree o suprima ninguna VCN ni que trabaje con ningún recurso en una VCN, a excepción de los grupos de seguridad de red.

La tercera sentencia es necesaria para mostrar las VCN, que es un requisito previo para crear o suprimir un grupo de seguridad de red de una VCN. Para obtener información sobre por qué son necesarias tanto la segunda como la tercera sentencia, consulte Condiciones.

La cuarta sentencia es necesaria si NSGAdmins debe colocar las VNIC en un grupo de seguridad de red. Quien quiera que cree el recurso principal de VNIC (por ejemplo, una instancia de Compute) debe tener este nivel de permiso para crear el recurso principal.

Para obtener más información sobre las políticas del servicio de redes, consulte Políticas de IAM para Networking.