Planificación e implementación de grupos de seguridad de red (NSG) y grupos de seguridad de aplicaciones (ASG)
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. En todas las reglas, puede especificar un origen y destino, un puerto y un protocolo.
Grupos de seguridad de red
Reglas de seguridad
Un grupo de seguridad de red contiene tantas reglas como desee, siempre que esté dentro de los límites de la 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 de palabra o con "_". El nombre puede contener caracteres de palabra o ".", "-", "_". |
| Priority | 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. Si el tráfico coincide con una regla, se detiene el procesamiento. Como resultado, las reglas con menor prioridad (números más altos) que tengan los mismos atributos que las reglas con una prioridad mayor no se procesarán. 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. Las 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 de entrada y antes de que Azure traduzca una dirección IP privada a una dirección IP pública para el tráfico de salida. Se necesitan menos reglas de seguridad cuando se especifica un intervalo, una etiqueta de servicio o un grupo de seguridad de aplicaciones. La posibilidad de especificar varias direcciones IP individuales e intervalos (no puede especificar varias etiquetas de servicio ni 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 puede especificar varias direcciones IP ni intervalos de ellas en grupos de seguridad de red creados mediante el 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 varios puertos ni intervalos de ellos en la misma regla de seguridad 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 cinco tuplas (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.
No es posible interrumpir las conexiones existentes cuando se elimina una regla de seguridad que permitió 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 ya existente en un grupo de seguridad de red, solo se aplicará a las nuevas conexiones. Las conexiones ya existentes no se reevalúan 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 e interfaz de red de la red virtual 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. La siguiente imagen ilustra los diferentes escenarios de cómo se podrían implementar 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á asociado a Subnet 1 y VM1 está en Subnet 1. A menos que haya creado una regla que permita el puerto 80 entrante, la regla de seguridad predeterminada DenyAllInbound deniega el tráfico. El tráfico no se evalúa mediante NSG2 porque está asociado a 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 para la máquina virtual, tanto NSG1 como 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 Subnet 1. Puesto que VM2 no tiene un grupo de seguridad de red asociado a su interfaz de red, recibe todo el tráfico permitido por 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: al no haber ningún grupo de seguridad de red asociado a Subnet 2, se permite el tráfico en la subred y NSG2 lo procesa, ya que NSG2 está asociado a la interfaz de red conectada a VM3.
- VM4: se permite el tráfico a VM4, ya que un grupo de seguridad de red no está asociado a Subnet 3 ni a la interfaz de red de la máquina virtual. Si no tienen un grupo de seguridad de red asociado, se permite todo el tráfico de red a través de una subred y una interfaz de red.
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 permite el tráfico de NSG1 y NSG2, a menos que cree una regla de seguridad que deniegue el puerto 80 de salida 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 de NSG2 permite el tráfico, ya que no hay ningún grupo de seguridad de red asociado a Subnet2.
- VM4: se permite todo el tráfico desde VM4, porque un grupo de seguridad de red no está asociado a la interfaz de red conectada a la máquina virtual, ni a Subnet3.
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 agregadas que se aplican a una interfaz de red mediante la visualización de las reglas de seguridad vigentes de una interfaz de red. También puede usar la funcionalidad Comprobación del flujo de IP de Azure Network Watcher para determinar si se permite la comunicación hacia una interfaz de red o desde esta. 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 se asocian a las subredes o a las máquinas virtuales y a los servicios en la nube que se implementan en el modelo de implementación clásica, y en las subredes o interfaces de red del 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. Puesto 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 necesiten solución.
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 de varios conjuntos de reglas, lo que le permite centrarse en su lógica de negocios. Para entender mejor los grupos de seguridad de aplicaciones, considere el ejemplo siguiente:
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 solo es miembro de un grupo de seguridad de aplicaciones, 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 siguientes reglas:
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 desde Internet, no es necesaria ninguna regla extra para los grupos de seguridad de aplicaciones AsgLogic y AsgDb.
| Prioridad | Origen | Puertos de origen | Destino | Puertos de destino | Protocolo | Acceder |
|---|---|---|---|---|---|---|
| 100 | Internet | * | AsgWeb | 80 | TCP | Allow |
Deny-Database-All
Dado que la regla de seguridad predeterminada AllowVNetInBound permite todas las comunicaciones entre los recursos de la misma red virtual, se necesita esta regla para denegar el tráfico desde todos los recursos.
| Prioridad | Origen | Puertos de origen | Destino | Puertos de destino | Protocolo | Acceder |
|---|---|---|---|---|---|---|
| 120 | * | * | AsgDb | 1433 | Any | 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 que la regla Deny-Database-All, por lo que se permite el tráfico del grupo de seguridad de aplicaciones AsgLogic, mientras que el resto del tráfico es bloqueado.
| Prioridad | Origen | Puertos de origen | Destino | Puertos de destino | Protocolo | Acceder |
|---|---|---|---|---|---|---|
| 110 | AsgLogic | * | AsgDb | 1433 | TCP | Allow |
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 en 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 a dicho grupo. Por ejemplo, si la primera interfaz de red asignada a un grupo de seguridad de aplicaciones llamado AsgWeb está en la red virtual llamada VNet1, todas las sucesivas interfaces de red asignadas a ASGWeb deben existir en VNet1. No se pueden agregar interfaces de red de distintas redes virtuales al mismo grupo de seguridad de aplicaciones.
Si especifica grupos de seguridad de aplicaciones como origen y destino de una regla de seguridad, las interfaces de red de 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 tuviera 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 de 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.