Planear e implementar grupos de seguridad de red (NSG) y grupos de seguridad de aplicaciones (ASG)

Completado

Puede usar el grupo de seguridad de red de Azure para filtrar el tráfico de red entre los recursos de Azure de una red virtual de Azure. Un grupo de seguridad de red contiene reglas de seguridad que permiten o deniegan el tráfico de red entrante o el tráfico de red saliente de varios tipos de recursos de Azure. Para cada regla, puede especificar el origen y el destino, el puerto y el protocolo.

Grupos de seguridad de red (NSG)

Reglas de seguridad

Un grupo de seguridad de red contiene tantas reglas como desee, dentro de los límites de suscripción de Azure. Cada regla especifica las siguientes propiedades:

Propiedad Explicación
Nombre Un nombre único dentro del grupo de seguridad de red. El nombre puede tener hasta 80 caracteres. Debe comenzar con un carácter de palabra y debe terminar con un carácter alfabético o con "_". El nombre puede contener caracteres alfabéticos o ".", "-", "_".
Prioridad Un número entre 100 y 4096. Las reglas se procesan en orden de prioridad. Se procesan primero las reglas con los números más bajos ya que estos tienen más prioridad. Cuando el tráfico coincide con una regla, el procesamiento se detiene. Como resultado, las reglas que existen con prioridades más bajas (números más altos) que tienen los mismos atributos que las reglas con prioridades más altas no se procesan.
Las reglas de seguridad predeterminadas de Azure reciben el número más alto con la prioridad más baja para asegurarse de que las reglas personalizadas siempre se procesan primero.
Origen o destino Cualquiera, una dirección IP individual, un bloque CIDR de enrutamiento entre dominios sin clases (10.0.0.0/24, por ejemplo), una etiqueta de servicio o un grupo de seguridad de aplicaciones. Si especifica una dirección para un recurso de Azure, especifique la dirección IP privada asignada al recurso. Los grupos de seguridad de red se procesan después de que Azure traduzca una dirección IP pública a una dirección IP privada para el tráfico entrante y antes de que Azure traduzca una dirección IP privada a una dirección IP pública para el tráfico saliente. Se necesitan menos reglas de seguridad cuando se especifica un rango, una etiqueta de servicio o un grupo de seguridad de aplicaciones. La capacidad de especificar múltiples direcciones IP y rangos individuales (no se pueden especificar múltiples etiquetas de servicio o grupos de aplicaciones) en una regla se conoce como reglas de seguridad aumentada. Las reglas de seguridad aumentada solo se pueden generar en los grupos de seguridad de red creados mediante el modelo de implementación de Resource Manager. No se pueden especificar varias direcciones IP ni intervalos de direcciones IP en grupos de seguridad de red creados a través del modelo de implementación clásica.
Protocolo TCP, UDP, ICMP, ESP, AH o cualquiera. Los protocolos ESP y AH no están disponibles actualmente a través de Azure Portal, pero se pueden usar a través de plantillas de Azure Resource Manager.
Dirección Si la regla se aplica al tráfico entrante o al saliente.
Intervalo de puertos Puede especificar un puerto individual o un intervalo de puertos. Por ejemplo, puede especificar 80 o 10000-10005. La especificación de intervalos le permite crear menos reglas de seguridad. Las reglas de seguridad aumentada solo se pueden generar en los grupos de seguridad de red creados mediante el modelo de implementación de Resource Manager. No puede especificar múltiples puertos o intervalos de puertos en la misma regla de seguridad dentro de los grupos de seguridad de red creados mediante el modelo de implementación clásica.
Acción Permitir o denegar

Las reglas de seguridad se evalúan y aplican en función de la información de la quintuple (1. origen, 2. puerto de origen, 3. destino, 4. puerto de destino y 5. protocolo). No puede crear dos reglas de seguridad con la misma prioridad y dirección. Se crea un registro de flujo para las conexiones existentes. Se permite o deniega la comunicación en función del estado de conexión del registro de flujo. El registro de flujo permite que un grupo de seguridad de red sea con estado. Por ejemplo, si especifica una regla de seguridad de salida para cualquier dirección a través del puerto 80, no será necesario especificar una regla de seguridad de entrada para la respuesta al tráfico saliente. Solo debe especificar una regla de seguridad de entrada si la comunicación se inicia de forma externa. Lo contrario también es cierto. Si se permite el tráfico entrante a través de un puerto, no es necesario especificar una regla de seguridad de salida para responder al tráfico a través del puerto.

Es posible que las conexiones existentes no se interrumpan cuando se elimina una regla de seguridad que permitía la conexión. Al modificar las reglas de grupo de seguridad de red, solo se verán afectadas las nuevas conexiones. Cuando se crea una nueva regla o se actualiza una regla existente en un grupo de seguridad de red, solo se aplicará a las nuevas conexiones. Las conexiones existentes no se reevaluarán con las nuevas reglas.

Cómo filtran el tráfico de red los grupos de seguridad de red

Puede implementar recursos de varios servicios de Azure en una red virtual de Azure. Puede asociar cero o un grupo de seguridad de red a cada subred de red virtual e interfaz de red en una máquina virtual. El mismo grupo de seguridad de red se puede asociar a tantas interfaces de red y subredes como se desee. En la siguiente imagen se muestran diferentes escenarios sobre cómo se pueden implementar los grupos de seguridad de red para permitir el tráfico de red hacia y desde Internet a través del puerto TCP 80:

Diagrama que muestra un ejemplo de cómo se pueden implementar los grupos de seguridad de red para permitir el tráfico de red hacia y desde Internet a través del puerto TCP 80.

Consulte la imagen, junto con el texto siguiente, para conocer la forma Azure procesa las reglas de entrada y salida para los grupos de seguridad de red:

Tráfico entrante

Para el tráfico entrante, Azure procesa las reglas de un grupo de seguridad de red asociadas a una subred en primer lugar, si hay alguna y, a continuación, las reglas de un grupo de seguridad de red asociadas a la interfaz de red, si hay alguna. Este proceso incluye también el tráfico dentro de la subred.

  • VM1: las reglas de seguridad de NSG1 se procesan, ya que está asociada a la subred 1 y VM1 se encuentra en la subred 1. A menos que haya creado una regla que permita el puerto 80 entrante, la regla de seguridad predeterminada DenyAllInbound deniega el tráfico. NSG2 no evalúa el tráfico porque está asociado con la interfaz de red. Si NSG1 permite el puerto 80 en su regla de seguridad, NSG2 procesa el tráfico. Para permitir el puerto 80 a la máquina virtual, NSG1 y NSG2 deben tener una regla que permita el puerto 80 desde Internet.
  • VM2: las reglas de NSG1 se procesan porque VM2 también está en la subred 1. Dado que VM2 no tiene un grupo de seguridad de red asociado a su interfaz de red, recibe todo el tráfico permitido a través de NSG1 o se deniega todo el tráfico denegado por NSG1. El tráfico se permite o deniega a todos los recursos de la misma subred cuando un grupo de seguridad de red está asociado a una subred.
  • VM3: dado que no hay ningún grupo de seguridad de red asociado a la subred 2, el tráfico se permite en la subred y se procesa mediante NSG2, ya que NSG2 está asociado a la interfaz de red conectada a VM3.
  • VM4: el tráfico se permite a VM4, ya que un grupo de seguridad de red no está asociado a la subred 3 o a la interfaz de red de la máquina virtual. Se permite todo el tráfico de red a través de una subred e interfaz de red si no tienen un grupo de seguridad de red asociado.

Tráfico saliente

Para el tráfico saliente, Azure procesa las reglas de un grupo de seguridad de red asociadas a una interfaz de red en primer lugar, si hay alguna y, a continuación, las reglas de un grupo de seguridad de red asociadas a la subred, si hay alguna. Este proceso incluye también el tráfico dentro de la subred.

  • VM1: se procesan las reglas de seguridad de NSG2 . La regla de seguridad predeterminada AllowInternetOutbound en NSG1 y NSG2 permite el tráfico a menos que cree una regla de seguridad que deniega el puerto 80 saliente a Internet. Si NSG2 deniega el puerto 80 en su regla de seguridad, deniega el tráfico y NSG1 nunca lo evalúa. Para denegar el puerto 80 desde la máquina virtual, uno o ambos de los grupos de seguridad de red deben tener una regla que deniegue el puerto 80 a Internet.
  • VM2: todo el tráfico se envía a través de la interfaz de red a la subred, ya que la interfaz de red conectada a VM2 no tiene un grupo de seguridad de red asociado. Se procesan las reglas de NSG1.
  • VM3: si NSG2 deniega el puerto 80 en su regla de seguridad, deniega el tráfico. Si NSG2 no deniega el puerto 80, la regla de seguridad predeterminada AllowInternetOutbound en NSG2 permite el tráfico porque no hay ningún grupo de seguridad de red asociado a la subred 2.
  • VM4: todo el tráfico de red se permite desde VM4, ya que un grupo de seguridad de red no está asociado a la interfaz de red conectada a la máquina virtual o a la subred 3.

Tráfico dentro de la subred

Es importante tener en cuenta que las reglas de seguridad de un NSG asociado a una subred pueden afectar la conectividad entre las máquinas virtuales dentro de ella. De manera predeterminada, las máquinas virtuales de la misma subred pueden comunicarse en función de una regla de NSG predeterminada que permita el tráfico dentro de la subred. Si agrega una regla a NSG1 que deniega todo el tráfico entrante y saliente, VM1 y VM2 no podrán comunicarse entre sí.

Puede ver fácilmente las reglas de agregado aplicadas a una interfaz de red viendo las reglas de seguridad eficaces de una interfaz de red. También puede usar la funcionalidad de comprobación del flujo de IP en Azure Network Watcher para determinar si se permite la comunicación hacia o desde una interfaz de red. Puede usar la comprobación del flujo de IP para determinar si se permite o se deniega una comunicación. Además, use la comprobación del flujo de IP para exponer la identidad de la regla de seguridad de red responsable de permitir o denegar el tráfico.

Los grupos de seguridad de red están asociados a subredes o máquinas virtuales y servicios en la nube implementados en el modelo de implementación clásico, y a subredes o interfaces de red en el modelo de implementación de Resource Manager.

A menos que tenga un motivo concreto, se recomienda que asocie un grupo de seguridad de red a una subred o a una interfaz de red, pero no a ambas. Dado que las reglas de un grupo de seguridad de red asociado a una subred pueden entrar en conflicto con las reglas de un grupo de seguridad de red asociado a una interfaz de red, puede tener problemas de comunicación inesperados que requieran solución de problemas.

Grupos de seguridad de aplicaciones (ASG)

Los grupos de seguridad de aplicaciones le permiten configurar la seguridad de red como una extensión natural de la estructura de una aplicación, lo que le permite agrupar máquinas virtuales y directivas de seguridad de red basadas en esos grupos. Puede reutilizar la directiva de seguridad a escala sin mantenimiento manual de direcciones IP explícitas. La plataforma controla la complejidad de las direcciones IP explícitas y varios conjuntos de reglas, lo que le permite centrarse en la lógica de negocios. Para comprender mejor los grupos de seguridad de aplicaciones, considere el ejemplo siguiente:

Diagrama que muestra un ejemplo de grupos de seguridad de red de Azure y grupos de seguridad de aplicaciones.

En la imagen anterior, NIC1 y NIC2 son miembros del grupo de seguridad de aplicaciones AsgWeb . NIC3 es miembro del grupo de seguridad de aplicaciones AsgLogic . NIC4 es miembro del grupo de seguridad de aplicaciones asgDb . Aunque cada interfaz de red (NIC) de este ejemplo es miembro de un solo grupo de seguridad de red, una interfaz de red puede ser miembro de varios grupos de seguridad de aplicaciones, hasta los límites de Azure. Ninguna de las interfaces de red tiene un grupo de seguridad de red asociado. NSG1 está asociado a ambas subredes y contiene las reglas siguientes:

Allow-HTTP-Inbound-Internet

Esta regla es necesaria para permitir el tráfico de Internet a los servidores web. Dado que la regla de seguridad predeterminada DenyAllInbound deniega el tráfico entrante de Internet, no se necesita ninguna regla adicional para los grupos de seguridad de aplicaciones AsgLogic o AsgDb .

Prioridad Fuente Puertos de origen Destino Puertos de destino Protocolo Acceso
100 Internet * AsgWeb 80 TCP Permitir

Deny-Database-All

Dado que la regla de seguridad predeterminada AllowVNetInBound permite toda la comunicación entre los recursos de la misma red virtual, esta regla es necesaria para denegar el tráfico de todos los recursos.

Prioridad Fuente Puertos de origen Destino Puertos de destino Protocolo Acceso
120 * * AsgDb 1433 Cualquiera Denegar

Allow-Database-BusinessLogic

Esta regla permite el tráfico desde el grupo de seguridad de aplicaciones asgLogic al grupo de seguridad de aplicaciones asgDb . La prioridad de esta regla es mayor que la prioridad de la regla Deny-Database-All . Como resultado, esta regla se procesa antes de la regla Deny-Database-All , por lo que se permite el tráfico del grupo de seguridad de la aplicación AsgLogic , mientras que el resto del tráfico está bloqueado.

Prioridad Fuente Puertos de origen Destino Puertos de destino Protocolo Acceso
110 AsgLogic * AsgDb 1433 TCP Permitir

Las interfaces de red que son miembros del grupo de seguridad de aplicaciones aplican las reglas que la especifican como origen o destino. Las reglas no afectan a otras interfaces de red. Si la interfaz de red no es miembro de un grupo de seguridad de aplicaciones, la regla no se aplica a la interfaz de red aunque el grupo de seguridad de red esté asociado a la subred.

Los grupos de seguridad de aplicaciones presentan las siguientes restricciones:

  • Hay límites para el número de grupos de seguridad de aplicaciones que puede tener en una suscripción y otros límites relacionados con los grupos de seguridad de aplicaciones.

  • Todas las interfaces de red asignadas a un grupo de seguridad de aplicaciones deben existir en la misma red virtual en la que se encuentra la primera interfaz de red asignada al grupo de seguridad de aplicaciones. Por ejemplo, si la primera interfaz de red asignada a un grupo de seguridad de aplicaciones denominado AsgWeb está en la red virtual denominada VNet1, todas las interfaces de red subsiguientes asignadas a ASGWeb deben existir en VNet1. No se pueden agregar interfaces de red de diferentes redes virtuales al mismo grupo de seguridad de aplicaciones.

  • Si especifica un grupo de seguridad de aplicaciones como origen y destino en una regla de seguridad, las interfaces de red en ambos grupos de seguridad de aplicaciones deben existir en la misma red virtual.

    • Un ejemplo sería si AsgLogic tuviera interfaces de red de VNet1 y AsgDb tenían interfaces de red de VNet2. En este caso, sería imposible asignar AsgLogic como origen y AsgDb como destino en una regla. Todas las interfaces de red para los grupos de seguridad de aplicaciones de origen y destino deben existir en la misma red virtual.

Para minimizar el número de reglas de seguridad que necesita y la necesidad de cambiar las reglas, planee los grupos de seguridad de aplicaciones que necesita y cree reglas mediante etiquetas de servicio o grupos de seguridad de aplicaciones en lugar de direcciones IP individuales o intervalos de direcciones IP siempre que sea posible.