Díganos qué opina sobre la experiencia de descarga del PDF.

Documentación de Virtual Network

Aprenda a usar Azure Virtual Network. Guías de inicio rápido, tutoriales, ejemplos, etc,
que muestran cómo implementar una red virtual, controlar el filtrado y el enrutamiento
de tráfico y conectar una red virtual a otras redes virtuales.

Acerca de Virtual Network

ｅ INFORMACIÓN GENERAL

¿Qué es Azure Virtual Network?

ｐ CONCEPTO

Preguntas más frecuentes acerca de Virtual Network

ｄ CURSOS

Introducción a las redes virtuales de Azure

｀ IMPLEMENTAR

Aprovisionamiento de una zona de aterrizaje de red

Aprovisionamiento de una nueva aplicación en una red existente

Aprovisionamiento de una infraestructura secundaria en una región de Azure

Implementación de la seguridad de red de Azure

Introducción

ｆ INICIO RÁPIDO

Creación de una red virtual

ｃ GUÍA PASO A PASO

Crear, cambiar o eliminar una red virtual

Adición, cambio o eliminación de una subred

Protegen el tráfico de red.

ｐ CONCEPTO

Grupos de seguridad de red

Grupos de seguridad de aplicaciones

Puntos de conexión de servicio de red virtual

Preguntas más frecuentes sobre seguridad de red virtual

Acceso de salida predeterminado

Cifrado de la red virtual

ｇ TUTORIAL

Filtrado del tráfico de red con grupos de seguridad de red

Restricción del acceso de red mediante puntos de conexión de servicio

Trabajar con grupos de seguridad de aplicaciones

ｃ GUÍA PASO A PASO

Creación de una red virtual con cifrado

ｄ CURSOS

Protección y aislamiento del acceso a los recursos de Azure

Conexión de redes virtuales

ｐ CONCEPTO

Emparejamiento de redes virtuales de Azure

Preguntas frecuentes sobre el emparejamiento de redes virtuales

ｇ TUTORIAL

Conexión de redes virtuales con emparejamiento de redes virtuales

ｃ GUÍA PASO A PASO

Mismo modelo de implementación, misma suscripción

Mismo modelo de implementación, diferentes suscripciones

Diferentes modelos de implementación, misma suscripción

Diferentes modelos de implementación, diferentes suscripciones

ｄ CURSOS

Comunicación entre redes virtuales con emparejamiento

Enrutado del tráfico de red

ｐ CONCEPTO

Enrutamiento del tráfico de red con tablas de rutas

ｇ TUTORIAL

Enrutamiento del tráfico de red: Portal

ｄ CURSOS

Administración y control del flujo de tráfico en la implementación de Azure con rutas

Creación de direcciones IP

ｐ CONCEPTO

Tipos de direcciones IP y métodos de asignación

ｃ GUÍA PASO A PASO

Creación, modificación o eliminación de una dirección IP pública

Adición de una dirección IP pública a una máquina virtual

Creación de una máquina virtual con una dirección IP estática

Configuración de una dirección IP privada estática para una máquina virtual

Asignación de varias direcciones IP a una máquina virtual

Creación de IPv6 para redes virtuales

ｐ CONCEPTO

¿Qué es IPv6 para Azure Virtual Network?

｀ IMPLEMENTAR

Implementación de una aplicación de pila doble IPV6 con Standard Load Balancer

Supervisión de redes virtuales

ｐ CONCEPTO

Punto de acceso de terminal de red virtual (TAP)

Preguntas frecuentes sobre un punto de acceso de terminal de red virtual

ｃ GUÍA PASO A PASO

Creación de un punto de acceso de terminal de red virtual

Administración de servicios de IP

ｐ CONCEPTO

Tipos de direcciones IP y métodos de asignación

¿Qué es IPv6 para Azure Virtual Network?

Prefijo de dirección IP pública

ｃ GUÍA PASO A PASO

Creación, modificación o eliminación de una dirección IP pública

Implementación de una aplicación de pila doble IPV6

Creación, modificación o eliminación del prefijo de una dirección IP pública

Información sobre la arquitectura de Virtual Network

ｅ INFORMACIÓN GENERAL

Diseño de la arquitectura de redes

ｄ CURSOS

Arquitectura de la infraestructura de red en Azure

ｉ REFERENCIA

Conexión de una red local a Azure

Implementación de una red híbrida segura

Topología de red en estrella tipo hub-and-spoke en Azure

Escenarios de alta disponibilidad y recuperación ante desastres para aplicaciones IaaS

Referencia

ｉ REFERENCIA

Azure CLI

Azure PowerShell

REST
¿Qué es Azure Virtual Network?
Artículo • 04/09/2023

Azure Virtual Network es un servicio que proporciona el bloque de compilación

fundamental para su red privada en Azure. Una instancia del servicio (una red virtual)
permite que muchos tipos de recursos de Azure se comuniquen de forma segura entre
sí, Internet y redes locales. Estos recursos de Azure incluyen máquinas virtuales (VM).

Una red virtual es similar a una red tradicional con la que trabajaría en su propio centro
de datos. Pero aporta ventajas adicionales de la infraestructura Azure, como escala,
disponibilidad y aislamiento.

¿Por qué usar una red virtual Azure?

Entre los escenarios clave que puede lograr con una red virtual se incluyen:

Comunicación de los recursos Azure con Internet.

Comunicación entre los recursos de Azure.

Comunicación con recursos locales.

Filtrado del tráfico de red.

Enrutamiento del tráfico de red.

Integración con servicios de Azure.

Comunicación con internet

De manera predeterminada, todos los recursos de una red virtual pueden comunicarse
con Internet. También puede utilizar una dirección IP pública, una puerta de enlace NAT
o un equilibrador de carga pública para administrar sus conexiones salientes. Puede
comunicarse de entrada con un recurso asignándole una dirección IP pública o un
equilibrador de carga pública.

Si está utilizando únicamente un equilibrador de carga estándar interno, la conectividad

saliente no estará disponible hasta que defina cómo desea que funcionen las
conexiones salientes con una dirección IP pública a nivel de instancia o un equilibrador
de carga público.

Comunicación entre recursos de Azure

Los recursos de Azure se comunican de manera segura entre sí de una de las maneras
siguientes:

Red virtual: puede implementar VM y otros tipos de recursos de Azure en una red
virtual. Algunos ejemplos de recursos son App Service Environments, Azure
Kubernetes Service (AKS) y Azure Virtual Machine Scale Sets. Para ver una lista
completa de los recursos de Azure que puede implementar en una red virtual,
consulte Implementar servicios de Azure dedicados en redes virtuales.

Punto de conexión de servicio de red virtual: puede ampliar el espacio de

direcciones privado de su red virtual y la identidad de su red virtual a los recursos
de servicio Azure a través de una conexión directa. Algunos ejemplos de recursos
son las cuentas Azure Storage y Azure SQL Database. Los puntos de conexión de
los servicios permiten proteger los recursos críticos de los servicios de Azure
únicamente en una red virtual. Para más información, consulte Puntos de conexión
de servicio de red virtual.

Emparejamiento de red virtual: puede conectar redes virtuales entre sí mediante

el emparejamiento de redes virtuales. Los recursos de ambas redes virtuales
pueden comunicarse entre sí. Las redes virtuales que conecte pueden estar en la
misma región de Azure o en regiones diferente. Para más información, consulte
Emparejamiento de redes virtuales de Azure.

Comunicación con recursos locales

Puede conectar los equipos y redes locales a una red virtual usando cualquiera de las
siguientes opciones:

Red privada virtual (VPN) de punto a sitio: se establece entre una red virtual y un
único equipo de la red. Cada equipo que desea establecer conectividad con una
red virtual debe configurar su conexión. Este tipo de conexión es muy útil si está
empezando a utilizar Azure, o para desarrolladores, dado que requiere pocos o
ningún cambio en una red existente. La comunicación entre el equipo y una red
virtual se envía mediante un túnel cifrado a través de internet. Para más
información, consulte Acerca de VPN de punto a sitio.

VPN de sitio a sitio: Se establece entre su dispositivo VPN local y una puerta de
enlace VPN de Azure desplegada en una red virtual. Este tipo de conexión permite
que cualquier recurso local que autorice acceda a una red virtual. La comunicación
entre un dispositivo VPN local y una puerta de enlace de VPN de Azure se envía
mediante un túnel cifrado a través de internet. Para más información, consulte VPN
de sitio a sitio.
 Azure ExpressRoute: se establece entre la red y Azure mediante un asociado de
ExpressRoute. Esta conexión es privada. El tráfico no pasa por Internet. Para
obtener más información, consulte ¿Qué es Azure ExpressRoute?.

Filtrado del tráfico de red

Puede filtrar el tráfico de red entre subredes mediante una o ambas de las siguientes
opciones:

Grupos de seguridad de red: los grupos de seguridad de red y los grupos de

seguridad de aplicaciones pueden contener varias reglas de seguridad de entrada
y de salida. Estas reglas permiten filtrar el tráfico desde y hacia los recursos por
dirección IP de origen y destino, puerto y protocolo. Para obtener más
información, consulte Grupos de seguridad de red y Grupos de seguridad de
aplicaciones.

Aplicaciones virtuales de red: una aplicación virtual de red es una máquina virtual
que realiza una función de red, como un firewall o la optimización de una WAN.
Para ver una lista de las aplicaciones virtuales de red que se pueden implementar
en una red virtual, vaya a Azure Marketplace .

Enrutado del tráfico de red

De forma predeterminada Azure enruta el tráfico entre subredes, redes virtuales
conectadas, redes locales e Internet. Puede implementar una o ambas de las siguientes
opciones para invalidar las rutas predeterminadas que crea Azure:

Tablas de enrutamiento: puede crear tablas de enrutamiento personalizadas que

controlen hacia dónde se enruta el tráfico de cada subred.

Rutas del protocolo de puerta de enlace de borde (BGP): si conecta una red
virtual a una red local mediante una puerta de enlace de Azure VPN o
ExpressRoute, puede propagar las rutas BGP locales a sus redes virtuales.

Integración con servicios de Azure

La integración de servicios de Azure en una red virtual de Azure permite el acceso
privado al servicio desde las máquinas virtuales o los recursos de proceso de la red
virtual. Puede usar las siguientes opciones para esta integración:

Implementar instancias dedicadas del servicio en una red virtual. Luego se puede
acceder de forma privada a los servicios dentro de la red virtual y desde redes
 locales.

Use Azure Private Link para acceder de forma privada a una instancia específica del
servicio desde su red virtual y desde redes locales.

Acceder al servicio a través de puntos de conexión públicos extendiendo una red

virtual al servicio, a través de puntos de conexión de servicio. Los puntos de
conexión de servicio permiten que los recursos de servicio se protejan en la red
virtual.

Límites
Hay ciertos límites en torno al número de recursos de Azure que puede implementar. La
mayoría de los límites de redes de Azure están en los valores máximos. Sin embargo,
puede aumentar determinados límites de red. Para más información, consulte Límites de
red.

Redes virtuales y zonas de disponibilidad

Las redes virtuales y las subredes abarcan todas las zonas de disponibilidad de una
región. No es necesario dividirlas por zonas de disponibilidad para dar cabida a los
recursos de zona. Por ejemplo, si configura una máquina virtual de zona, no tiene que
tener en cuenta la red virtual al seleccionar la zona de disponibilidad de la máquina
virtual. Lo mismo sucede con otros recursos de zona.

Precios
El uso de Azure Virtual Network es gratuito. No tiene coste alguno. Se aplican tarifas
estándar para recursos como máquinas virtuales y otros productos. Para más
información, consulte Precios de Virtual Network y la Calculadora de precios de
Azure.

Pasos siguientes
Obtenga más información sobre los conceptos y procedimientos recomendados
de Azure Virtual Network.

Empiece a usar una red virtual mediante la creación de una, la implementación de

algunas máquinas virtuales en ella y la comunicación entre las máquinas virtuales.
Para obtener información sobre cómo hacerlo, consulte el inicio rápido Uso de
Azure Portal para crear una red virtual.

Siga un módulo de entrenamiento sobre cómo diseñar e implementar la

infraestructura de red principal de Azure, incluidas las redes virtuales: Introducción
a las redes virtuales de Azure.
Inicio rápido: Uso de Azure Portal para
crear una red virtual
Artículo • 22/08/2023

Esta guía rápida le muestra cómo crear una red virtual utilizando Azure Portal. A
continuación, cree dos máquinas virtuales (VM) en la red, implemente Azure Bastion
para conectarse de forma segura a las máquinas virtuales desde Internet y comunicarse
de forma privada entre las máquinas virtuales.

Una red virtual es el bloque de compilación fundamental para las redes privadas en
Azure. Azure Virtual Network permite que los recursos de Azure, como las máquinas
virtuales, se comuniquen de manera segura entre sí y con Internet.

Prerrequisitos
Una cuenta de Azure con una suscripción activa. También puede crear una cuenta
de forma gratuita .

Inicio de sesión en Azure

Inicie sesión en Azure Portal con su cuenta de Azure.

Creación de una red virtual y un host bastión

El procedimiento siguiente crea una red virtual con una subred de recursos, una subred
de Azure Bastion y un host de Azure Bastion.

1. En el portal, busque y seleccione Redes virtuales.

2. En la página Redes virtuales, seleccione y Crear.

3. En la pestaña Datos básicos de Crear una red virtual, introduzca o seleccione la
siguiente información:

Configuración Valor

Detalles del proyecto

Suscripción Seleccione su suscripción.

Resource group Seleccione Crear nuevo.

Escriba test-rg en Nombre.
Seleccione
.

Detalles de instancia

Nombre Escriba vnet-1.

Region Seleccione Este de EE. UU. 2.

4. Seleccione Siguiente para ir a la pestaña Seguridad.

5. Seleccione Habilitar Bastion en la sección Azure Bastion de la pestaña Seguridad.

 Azure Bastion usa el explorador para conectarse a las máquinas virtuales de la red
virtual a través del shell seguro (SSH) o el protocolo de escritorio remoto (RDP)
mediante sus direcciones IP privadas. Las máquinas virtuales no necesitan
direcciones IP públicas, software cliente ni configuración especial. Para más
información sobre Azure Bastion, consulte Azure Bastion

７ Nota

Los precios por hora comienzan desde el momento en que se implementa

Bastion, independientemente del uso de datos salientes. Para más
información, consulte Precios y SKU. Si va a implementar Bastion como
parte de un tutorial o prueba, se recomienda eliminar este recurso una vez
que haya terminado de usarlo.

6. Escriba o seleccione la información siguiente en Azure Bastion:

Configuración Valor

Nombre de host de Azure Bastion Escriba bastión.

Dirección IP pública de Azure Bastion Seleccione Crear una dirección IP pública.

Escriba public-ip-1 en Nombre.
Seleccione
.
7. Seleccione Siguiente para continuar a la pestaña Direcciones IP.

8. En el cuadro espacio de direcciones de Subredes, seleccione la subred

predeterminada.

9. En Agregar subred, escriba o seleccione la información siguiente:

Configuración Valor

Detalles de subred

Plantilla de subred Deje el valor predeterminado.

Nombre Escriba subnet-1.

Dirección inicial Deje el valor predeterminado de 10.0.0.0.

 Configuración Valor

Tamaño de la subred Deje el valor predeterminado de /24(256 direcciones).

10. Seleccione Guardar.

11. Seleccione Revisar y crear en la parte inferior de la pantalla y, cuando se supere la

validación, seleccione Crear.

Creación de máquinas virtuales

El procedimiento siguiente crea dos máquinas virtuales (VM) denominadas vm-1 y vm-2
en la red virtual.

1. En el portal, busque y seleccione Máquinas virtuales.

2. En Máquinas virtuales, seleccione + Crear y, después, Máquina virtual de Azure.

3. En la pestaña Datos básicos de Crear una máquina virtual, escriba o seleccione la

siguiente información:

Configuración Value

Detalles del proyecto

Suscripción Seleccione su suscripción.

Resource group Seleccione test-rg.

Detalles de instancia

Nombre de la máquina Escriba vm-1.

virtual

Region Seleccione Este de EE. UU. 2.

Opciones de disponibilidad Seleccione No se requiere redundancia de la

infraestructura.

Tipo de seguridad Deje el valor predeterminado Estándar.

Imagen Seleccione Ubuntu Server 22.04 LTS: x64 Gen2.

Arquitectura VM Deje el valor predeterminado, x64.

Size Seleccione un tamaño.

Cuenta de administrador

Tipo de autenticación Seleccione Contraseña.

Nombre de usuario escriba usuarioazure.

Contraseña Escriba una contraseña.

Confirmar contraseña Reescriba la contraseña.

Reglas de puerto de entrada

Puertos de entrada públicos Seleccione Ninguno.

4. Seleccione la pestaña Redes en la parte superior de la página.

5. En la pestaña Redes, escriba o seleccione la siguiente información:

Parámetro Valor

Interfaz de red
 Parámetro Valor
Virtual network Seleccione vnet-1.

Subnet Seleccione subnet-1 (10.0.0.0/24).

Dirección IP pública Seleccione Ninguno.

Grupo de seguridad de red de NIC Seleccione Advanced (Avanzadas).

Configuración del grupo de Seleccione Crear nuevo.

seguridad de red Escriba nsg-1 como nombre.
Deje el resto de los valores predeterminados y
seleccione Aceptar.

6. Deje el resto de las opciones en sus valores predeterminados y luego seleccione

Revisar + crear.

7. Revise la configuración y seleccione Crear.

8. Repita los pasos anteriores para crear una segunda máquina virtual con la
siguiente configuración:

Configuración Valor

Nombre de la máquina virtual Escriba vm-2.

Virtual network Seleccione vnet-1.

Subnet Seleccione subnet-1 (10.0.0.0/24)

Dirección IP pública Seleccione Ninguno.

Grupo de seguridad de red de NIC Seleccione Advanced (Avanzadas).

Configuración del grupo de seguridad de red Seleccione nsg-1

７ Nota

Las máquinas virtuales de una red virtual con un host bastión no necesitarán
direcciones IP públicas. Bastion proporcionará la dirección IP pública y las máquinas
virtuales usarán direcciones IP privadas para comunicarse dentro de la red. Es
posible quitar las direcciones IP públicas de cualquier máquina virtual en redes
virtuales hospedadas por Bastion. Para obtener más información, consulte
Desasociación de una dirección IP pública de una máquina virtual de Azure.

７ Nota
 Azure proporciona una dirección IP de acceso de salida predeterminado para las
máquinas virtuales que no tienen asignada una dirección IP pública o que se
encuentran en el grupo de back-end de una instancia de Azure Load Balancer del
nivel Básico interna. El mecanismo de dirección IP de acceso de salida
predeterminado proporciona una dirección IP de salida que no se puede
configurar.

La IP de acceso de salida predeterminada está deshabilitada cuando se asigna una

IP pública a la máquina virtual, la máquina virtual se coloca en el grupo de back-
end de un equilibrador de carga estándar (con o sin reglas de salida) o si se asigna
un recurso de puerta de enlace de Azure Virtual Network NAT a la subred de la
máquina virtual.

Las máquinas virtuales creadas por conjuntos de escalado de máquinas virtuales en

modo de orquestación flexible no tienen acceso de salida predeterminado.

Para obtener más información sobre las conexiones de salida en Azure, vea Acceso
de salida predeterminado y Uso de traducción de direcciones de red (SNAT) de
origen para conexiones de salida.

Conexión a una máquina virtual

1. En el portal, busque y seleccione Máquinas virtuales.

2. En la página Máquinas virtuales, seleccione vm-1.

3. En la Información generalde vm-1, seleccione Conectar.

4. En la página Conectar a la máquina virtual, seleccione la pestaña Bastion.

5. Seleccione Usar Bastion.

6. Escriba el nombre de usuario y la contraseña que creó al crear la máquina virtual y,

a continuación, seleccione Conectar.

Comunicarse entre máquinas virtuales

1. En el símbolo del sistema de Bash para vm-1, escriba ping -c 4 vm-2 .

Recibirá una respuesta similar al siguiente mensaje:

Resultados
 azureuser@vm-1:~$ ping -c 4 vm-2
PING vm-2.3bnkevn3313ujpr5l1kqop4n4d.cx.internal.cloudapp.net
(10.0.0.5) 56(84) bytes of data.
64 bytes from vm-2.internal.cloudapp.net (10.0.0.5): icmp_seq=1 ttl=64
time=1.83 ms
64 bytes from vm-2.internal.cloudapp.net (10.0.0.5): icmp_seq=2 ttl=64
time=0.987 ms
64 bytes from vm-2.internal.cloudapp.net (10.0.0.5): icmp_seq=3 ttl=64
time=0.864 ms
64 bytes from vm-2.internal.cloudapp.net (10.0.0.5): icmp_seq=4 ttl=64
time=0.890 ms

2. Cierre la conexión de Bastion a VM1.

3. Repita los pasos descritos en Conectar a una máquina virtual para conectarse a
VM2.

4. En el símbolo del sistema de Bash para vm-2, escriba ping -c 4 vm-1 .

Recibirá una respuesta similar al siguiente mensaje:

Resultados

azureuser@vm-2:~$ ping -c 4 vm-1

PING vm-1.3bnkevn3313ujpr5l1kqop4n4d.cx.internal.cloudapp.net
(10.0.0.4) 56(84) bytes of data.
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=1 ttl=64
time=0.695 ms
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=2 ttl=64
time=0.896 ms
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=3 ttl=64
time=3.43 ms
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=4 ttl=64
time=0.780 ms

5. Cierre la conexión de Bastion a VM2.

Limpieza de recursos
Cuando haya terminado de utilizar los recursos creados, puede eliminar el grupo de
recursos y todos sus recursos.

1. En Azure Portal, busque y seleccione Grupos de recursos.

2. En la página Grupos de recursos, seleccione el grupo de recursos test-rg.

3. En la página test-rg, elija Eliminar grupo de recursos.

 4. Escriba test-rg en Introducir nombre del grupo de recursos para confirmar la
eliminación y seleccione Eliminar.

Pasos siguientes
En este inicio rápido, ha creado una red virtual con dos subredes, una que contiene dos
máquinas virtuales y la otra para Azure Bastion. Implementó Azure Bastion y lo usó para
conectarse a las máquinas virtuales y comunicarse de forma segura entre ellas. Para más
información sobre la configuración de red virtual, consulte Crear, cambiar o eliminar una
red virtual.

La comunicación privada entre máquinas virtuales no está restringida en una red virtual.
Continúe con el siguiente artículo para obtener más información sobre cómo configurar
distintos tipos de comunicaciones de red de VM.

Filtrado del tráfico de red

Inicio rápido: usar Azure PowerShell
para crear una red virtual
Artículo • 20/06/2023

En este inicio rápido, se muestra cómo crear una red virtual mediante Azure PowerShell.
A continuación, creará dos máquinas virtuales (VM) en la red, se conectará de forma
segura a las máquinas virtuales desde Internet y se comunicará de forma privada entre
las máquinas virtuales.

Una red virtual es el bloque de compilación fundamental de las redes privadas en Azure.
Azure Virtual Network permite que los recursos de Azure, como las máquinas virtuales,
se comuniquen de manera segura entre sí y con Internet.

Requisitos previos
Una cuenta de Azure con una suscripción activa. También puede crear una cuenta
de forma gratuita .

Azure Cloud Shell o Azure PowerShell.

Los pasos de este inicio rápido ejecutarán los cmdlet de Azure PowerShell de
forma interactiva en Azure Cloud Shell. Para ejecutar los comandos en Cloud Shell,
seleccione Abrir CloudShell en la esquina superior derecha de un bloque de
código. Seleccione Copiar para copiar el código y péguelo, a continuación, en
Cloud Shell para ejecutarlo. También podrá ejecutar Cloud Shell desde Azure
Portal.

También podrá instalar Azure PowerShell localmente para ejecutar los cmdlet. Los
pasos descritos en este artículo requieren el módulo Azure PowerShell versión
5.4.1 o posterior. Ejecute Get-Module -ListAvailable Az para buscar la versión
instalada. Si necesitase actualizarlo, consulte Instalación del módulo Azure
PowerShell.
 Si ejecutase PowerShell localmente, ejecute Connect-AzAccount para conectarse a
Azure.

Crear un grupo de recursos

1. Use New-AzResourceGroup para crear un grupo de recursos para hospedar la red
virtual. Ejecute el código siguiente para crear un grupo de recursos denominado
test-rg en la región de Azure eastus2.

Azure PowerShell

$rg = @{
Name = 'test-rg'
Location = 'eastus2'
}
New-AzResourceGroup @rg

Creación de una red virtual

1. Use New-AzVirtualNetwork para crear una red virtual denominada vnet-1 con el
prefijo de dirección IP 10.0.0.0/16 en el grupo de recursostest-rg y la ubicación
eastus2.

Azure PowerShell

$vnet = @{
Name = 'vnet-1'
ResourceGroupName = 'test-rg'
Location = 'eastus2'
AddressPrefix = '10.0.0.0/16'
}
$virtualNetwork = New-AzVirtualNetwork @vnet

2. Azure implementa recursos en una subred dentro de una red virtual. Use Add-
AzVirtualNetworkSubnetConfig para crear una configuración de subred
denominada subnet-1 con el prefijo de dirección 10.0.0.0/24.

Azure PowerShell

$subnet = @{
Name = 'subnet-1'
VirtualNetwork = $virtualNetwork
AddressPrefix = '10.0.0.0/24'
}
$subnetConfig = Add-AzVirtualNetworkSubnetConfig @subnet
 3. A continuación, asocie la configuración de subred a la red virtual con Set-
AzVirtualNetwork.

Azure PowerShell

$virtualNetwork | Set-AzVirtualNetwork

Implementación de Azure Bastion

Azure Bastion usa el explorador para conectarse a las máquinas virtuales de la red
virtual a través del shell seguro (SSH) o el protocolo de escritorio remoto (RDP)
mediante sus direcciones IP privadas. Las máquinas virtuales no necesitan direcciones IP
públicas, software cliente ni configuración especial. Para más información sobre
Azure Bastion, consulte Azure Bastion.

Los precios por hora comienzan desde el momento en que se implementa Bastion,
independientemente del uso de datos salientes. Para más información, consulte
Precios y SKU. Si va a implementar Bastion como parte de un tutorial o prueba, se
recomienda eliminar este recurso una vez que haya terminado de usarlo.

1. Configure la subred de Azure Bastion en la red virtual. Esta subred se reservará

exclusivamente para los recursos de Azure Bastion y deberá denominarse
AzureBastionSubnet.

Azure PowerShell

$subnet = @{
Name = 'AzureBastionSubnet'
VirtualNetwork = $virtualNetwork
AddressPrefix = '10.0.1.0/26'
}
$subnetConfig = Add-AzVirtualNetworkSubnetConfig @subnet

2. Establezca la configuración.

Azure PowerShell

$virtualNetwork | Set-AzVirtualNetwork

3. Cree una dirección IP pública para Azure Bastion. El host bastión usará la dirección
IP pública para acceder al shell seguro (SSH) y al protocolo de escritorio remoto
(RDP) a través del puerto 443.
 Azure PowerShell

$ip = @{
ResourceGroupName = 'test-rg'
Name = 'public-ip'
Location = 'eastus2'
AllocationMethod = 'Static'
Sku = 'Standard'
Zone = 1,2,3
}
New-AzPublicIpAddress @ip

4. Use el comando New-AzBastion para crear un nuevo host de Azure Bastion de SKU
estándar en AzureBastionSubnet.

Azure PowerShell

$bastion = @{
Name = 'bastion'
ResourceGroupName = 'test-rg'
PublicIpAddressRgName = 'test-rg'
PublicIpAddressName = 'public-ip'
VirtualNetworkRgName = 'test-rg'
VirtualNetworkName = 'vnet-1'
Sku = 'Basic'
}
New-AzBastion @bastion

Los recursos de Bastion tardarán aproximadamente 10 minutos en implementarse. En la

siguiente sección, podrá crear una máquina virtual mientras Bastion se implementa en la
red virtual.

Creación de máquinas virtuales

Use New-AzVM para crear dos máquinas virtuales denominadas vm-1 y vm-2 en la
subred subnet-1 de la red virtual. Cuando se le pidan credenciales, escriba los nombres
de usuario y las contraseñas de las máquinas virtuales.

1. Para crear la primera máquina virtual, use el código siguiente:

Azure PowerShell

# Set the administrator and password for the VMs. ##

$cred = Get-Credential

## Place the virtual network into a variable. ##

$vnet = Get-AzVirtualNetwork -Name 'vnet-1' -ResourceGroupName 'test-
 rg'

## Create network interface for virtual machine. ##

$nic = @{
Name = "nic-1"
ResourceGroupName = 'test-rg'
Location = 'eastus2'
Subnet = $vnet.Subnets[0]
}
$nicVM = New-AzNetworkInterface @nic

## Create a virtual machine configuration for VMs ##

$vmsz = @{
VMName = "vm-1"
VMSize = 'Standard_DS1_v2'
}
$vmos = @{
ComputerName = "vm-1"
Credential = $cred
}
$vmimage = @{
PublisherName = 'Canonical'
Offer = '0001-com-ubuntu-server-jammy'
Skus = '22_04-lts-gen2'
Version = 'latest'
}
$vmConfig = New-AzVMConfig @vmsz `
| Set-AzVMOperatingSystem @vmos -Linux `
| Set-AzVMSourceImage @vmimage `
| Add-AzVMNetworkInterface -Id $nicVM.Id

## Create the virtual machine for VMs ##

$vm = @{
ResourceGroupName = 'test-rg'
Location = 'eastus2'
VM = $vmConfig
}
New-AzVM @vm

2. Para crear la segunda máquina virtual, use el código siguiente:

Azure PowerShell

# Set the administrator and password for the VMs. ##

$cred = Get-Credential

## Place the virtual network into a variable. ##

$vnet = Get-AzVirtualNetwork -Name 'vnet-1' -ResourceGroupName 'test-
rg'

## Create network interface for virtual machine. ##

$nic = @{
Name = "nic-2"
 ResourceGroupName = 'test-rg'
Location = 'eastus2'
Subnet = $vnet.Subnets[0]
}
$nicVM = New-AzNetworkInterface @nic

## Create a virtual machine configuration for VMs ##

$vmsz = @{
VMName = "vm-2"
VMSize = 'Standard_DS1_v2'
}
$vmos = @{
ComputerName = "vm-2"
Credential = $cred
}
$vmimage = @{
PublisherName = 'Canonical'
Offer = '0001-com-ubuntu-server-jammy'
Skus = '22_04-lts-gen2'
Version = 'latest'
}
$vmConfig = New-AzVMConfig @vmsz `
| Set-AzVMOperatingSystem @vmos -Linux `
| Set-AzVMSourceImage @vmimage `
| Add-AzVMNetworkInterface -Id $nicVM.Id

## Create the virtual machine for VMs ##

$vm = @{
ResourceGroupName = 'test-rg'
Location = 'eastus2'
VM = $vmConfig
}
New-AzVM @vm

 Sugerencia

Puede usar la opción -AsJob para crear una máquina virtual en segundo plano
mientras continúa con otras tareas. Por ejemplo, ejecute New-AzVM @vm1 -AsJob .
Cuando Azure comience a crear la máquina virtual en segundo plano, obtendrá
algo como el siguiente resultado:

PowerShell

Id Name PSJobTypeName State HasMoreData

Location Command
-- ---- ------------- ----- ----------- --
------ -------
1 Long Running... AzureLongRun... Running True
localhost New-AzVM
Azure tardará unos minutos en crear las máquinas virtuales. Cuando Azure termine de
crear las máquinas virtuales, devolverá la salida a PowerShell.

７ Nota

Las máquinas virtuales de una red virtual con un host bastión no necesitarán
direcciones IP públicas. Bastion proporcionará la dirección IP pública y las máquinas
virtuales usarán direcciones IP privadas para comunicarse dentro de la red. Es
posible quitar las direcciones IP públicas de cualquier máquina virtual en redes
virtuales hospedadas por Bastion. Para obtener más información, consulte
Desasociación de una dirección IP pública de una máquina virtual de Azure.

７ Nota

Azure proporciona una dirección IP de acceso de salida predeterminado para las

máquinas virtuales que no tienen asignada una dirección IP pública o que se
encuentran en el grupo de back-end de una instancia de Azure Load Balancer del
nivel Básico interna. El mecanismo de dirección IP de acceso de salida
predeterminado proporciona una dirección IP de salida que no se puede
configurar.

La IP de acceso de salida predeterminada está deshabilitada cuando se asigna una

IP pública a la máquina virtual, la máquina virtual se coloca en el grupo de back-
end de un equilibrador de carga estándar (con o sin reglas de salida) o si se asigna
un recurso de puerta de enlace de Azure Virtual Network NAT a la subred de la
máquina virtual.

Las máquinas virtuales creadas por conjuntos de escalado de máquinas virtuales en

modo de orquestación flexible no tienen acceso de salida predeterminado.

Para obtener más información sobre las conexiones de salida en Azure, vea Acceso
de salida predeterminado y Uso de traducción de direcciones de red (SNAT) de
origen para conexiones de salida.

Conexión a una máquina virtual

1. En el portal, busque y seleccione Máquinas virtuales.

2. En la página Máquinas virtuales, seleccione vm-1.

3. En la Información generalde vm-1, seleccione Conectar.

 4. En la página Conectar a la máquina virtual, seleccione la pestaña Bastion.

5. Seleccione Usar Bastion.

6. Escriba el nombre de usuario y la contraseña que creó al crear la máquina virtual y,

a continuación, seleccione Conectar.

Comunicarse entre máquinas virtuales

1. En el símbolo del sistema de Bash para vm-1, escriba ping -c 4 vm-2 .

Recibirá una respuesta similar al siguiente mensaje:

Resultados

azureuser@vm-1:~$ ping -c 4 vm-2

PING vm-2.3bnkevn3313ujpr5l1kqop4n4d.cx.internal.cloudapp.net
(10.0.0.5) 56(84) bytes of data.
64 bytes from vm-2.internal.cloudapp.net (10.0.0.5): icmp_seq=1 ttl=64
time=1.83 ms
64 bytes from vm-2.internal.cloudapp.net (10.0.0.5): icmp_seq=2 ttl=64
time=0.987 ms
64 bytes from vm-2.internal.cloudapp.net (10.0.0.5): icmp_seq=3 ttl=64
time=0.864 ms
64 bytes from vm-2.internal.cloudapp.net (10.0.0.5): icmp_seq=4 ttl=64
time=0.890 ms

2. Cierre la conexión de Bastion a VM1.

3. Repita los pasos descritos en Conectar a una máquina virtual para conectarse a
VM2.

4. En el símbolo del sistema de Bash para vm-2, escriba ping -c 4 vm-1 .

Recibirá una respuesta similar al siguiente mensaje:

Resultados

azureuser@vm-2:~$ ping -c 4 vm-1

PING vm-1.3bnkevn3313ujpr5l1kqop4n4d.cx.internal.cloudapp.net
(10.0.0.4) 56(84) bytes of data.
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=1 ttl=64
time=0.695 ms
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=2 ttl=64
time=0.896 ms
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=3 ttl=64
time=3.43 ms
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=4 ttl=64
time=0.780 ms
 5. Cierre la conexión de Bastion a VM2.

Limpieza de recursos
Cuando haya terminado con la red virtual y las máquinas virtuales, use Remove-
AzResourceGroup para quitar el grupo de recursos y todos sus recursos.

Azure PowerShell

Remove-AzResourceGroup -Name 'test-rg' -Force

Pasos siguientes
En este inicio rápido, creó una red virtual con una subred predeterminada que contenía
dos máquinas virtuales. Implementó Azure Bastion y lo usó para conectarse a las
máquinas virtuales y comunicarse de forma segura entre ellas. Para más información
sobre la configuración de red virtual, consulte Crear, cambiar o eliminar una red virtual.

La comunicación privada entre máquinas virtuales en una red virtual no está restringida.
Continúe con el siguiente artículo para obtener más información sobre cómo configurar
distintos tipos de comunicaciones de red de VM.

Filtrado del tráfico de red

Inicio rápido: usar la CLI de Azure para
crear una red virtual
Artículo • 20/06/2023

En este inicio rápido se muestra cómo crear una red virtual mediante la CLI de Azure, la
interfaz de la línea de comandos de Azure. A continuación, creará dos máquinas
virtuales (VM) en la red, se conectará de forma segura a las máquinas virtuales desde
Internet y se comunicará de forma privada entre las máquinas virtuales.

Una red virtual es el bloque de compilación fundamental de las redes privadas en Azure.
Azure Virtual Network permite que los recursos de Azure, como las máquinas virtuales,
se comuniquen de manera segura entre sí y con Internet.

Si no tiene una suscripción a Azure, cree una cuenta gratuita de Azure antes de
empezar.

Requisitos previos
Use el entorno de Bash en Azure Cloud Shell. Para más información, consulte Inicio
rápido para Bash en Azure Cloud Shell.

Si prefiere ejecutar comandos de referencia de la CLI localmente, instale la CLI de

Azure. Si utiliza Windows o macOS, considere la posibilidad de ejecutar la CLI de
Azure en un contenedor Docker. Para más información, vea Ejecución de la CLI de
Azure en un contenedor de Docker.

Si usa una instalación local, inicie sesión en la CLI de Azure mediante el

comando az login. Siga los pasos que se muestran en el terminal para
completar el proceso de autenticación. Para ver otras opciones de inicio de
sesión, consulte Inicio de sesión con la CLI de Azure.
 En caso de que se le solicite, instale las extensiones de la CLI de Azure la
primera vez que la use. Para más información sobre las extensiones, consulte
Uso de extensiones con la CLI de Azure.

Ejecute az version para buscar cuál es la versión y las bibliotecas dependientes

que están instaladas. Para realizar la actualización a la versión más reciente,
ejecute az upgrade.

Crear un grupo de recursos

1. Use az group create para crear un grupo de recursos para hospedar la red virtual.
Use el código siguiente para crear un grupo de recursos denominado test-rg en la
región de Azure eastus2.

Azure CLI

az group create \
--name test-rg \
--location eastus2

Creación de una red virtual y una subred

1. Use az network vnet create para crear una red virtual denominada vnet-1 con una
subred denominada subnet-1 en el grupo de recursos test-rg.

Azure CLI

az network vnet create \

--name vnet-1 \
--resource-group test-rg \
--address-prefix 10.0.0.0/16 \
--subnet-name subnet-1 \
--subnet-prefixes 10.0.0.0/24

Implementación de Azure Bastion

Azure Bastion usa el explorador para conectarse a las máquinas virtuales de la red
virtual a través del shell seguro (SSH) o el protocolo de escritorio remoto (RDP)
mediante sus direcciones IP privadas. Las máquinas virtuales no necesitan direcciones IP
públicas, software cliente ni configuración especial.
Los precios por hora comienzan desde el momento en que se implementa Bastion,
independientemente del uso de datos salientes. Para más información, consulte
Precios y SKU. Si va a implementar Bastion como parte de un tutorial o prueba, se
recomienda eliminar este recurso una vez que haya terminado de usarlo. Para más
información sobre Azure Bastion, consulte Azure Bastion.

1. Use az network vnet subnet create para crear una subred de Azure Bastion en la
red virtual. Esta subred se reservará exclusivamente para los recursos de
Azure Bastion y deberá denominarse AzureBastionSubnet.

Azure CLI

az network vnet subnet create \

--name AzureBastionSubnet \
--resource-group test-rg \
--vnet-name vnet-1 \
--address-prefix 10.0.1.0/26

2. Cree una dirección IP pública para Azure Bastion. Esta dirección IP se usa para
conectarse al host bastión desde Internet. Utilice az network public-ip create para
crear una dirección IP pública denominada public-ip en el grupo de recursos test-
rg.

Azure CLI

az network public-ip create \

--resource-group test-rg \
--name public-ip \
--sku Standard \
--location eastus2 \
--zone 1 2 3

3. Use az network bastion create para crear un host de Azure Bastion en la subred
AzureBastionSubnet de la red virtual.

Azure CLI

az network bastion create \

--name bastion \
--public-ip-address public-ip \
--resource-group test-rg \
--vnet-name vnet-1 \
--location eastus2

Los recursos de Bastion tardarán aproximadamente 10 minutos en implementarse. En la

siguiente sección, podrá crear una máquina virtual mientras Bastion se implementa en la
red virtual.

Creación de máquinas virtuales

Use az vm create para crear dos máquinas virtuales denominadas VM1 y VM2 en la
subred subnet-1 de la red virtual. Cuando se le pidan credenciales, escriba los nombres
de usuario y las contraseñas de las máquinas virtuales.

1. Para crear la primera máquina virtual, use el comando siguiente:

Azure CLI

az vm create \
--resource-group test-rg \
--admin-username azureuser \
--authentication-type password \
--name vm-1 \
--image Ubuntu2204 \
--public-ip-address ""

2. Para crear la segunda máquina virtual, use el comando siguiente:

Azure CLI

az vm create \
--resource-group test-rg \
--admin-username azureuser \
--authentication-type password \
--name vm-2 \
--image Ubuntu2204 \
--public-ip-address ""

 Sugerencia

También puede usar la opción --no-wait para crear una máquina virtual en
segundo plano mientras continúa con otras tareas.

Las máquinas virtuales tardan unos minutos en crearse. Una vez que Azure cree cada
máquina virtual, la CLI de Azure devuelve un resultado similar al siguiente mensaje:

Resultados

{
"fqdns": "",
"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/test-
rg/providers/Microsoft.Compute/virtualMachines/vm-2",
"location": "eastus2",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "10.0.0.5",
"publicIpAddress": "",
"resourceGroup": "test-rg"
"zones": ""
}

７ Nota

Las máquinas virtuales de una red virtual con un host bastión no necesitarán
direcciones IP públicas. Bastion proporcionará la dirección IP pública y las máquinas
virtuales usarán direcciones IP privadas para comunicarse dentro de la red. Es
posible quitar las direcciones IP públicas de cualquier máquina virtual en redes
virtuales hospedadas por Bastion. Para obtener más información, consulte
Desasociación de una dirección IP pública de una máquina virtual de Azure.

７ Nota

Azure proporciona una dirección IP de acceso de salida predeterminado para las

máquinas virtuales que no tienen asignada una dirección IP pública o que se
encuentran en el grupo de back-end de una instancia de Azure Load Balancer del
nivel Básico interna. El mecanismo de dirección IP de acceso de salida
predeterminado proporciona una dirección IP de salida que no se puede
configurar.

La IP de acceso de salida predeterminada está deshabilitada cuando se asigna una

IP pública a la máquina virtual, la máquina virtual se coloca en el grupo de back-
end de un equilibrador de carga estándar (con o sin reglas de salida) o si se asigna
un recurso de puerta de enlace de Azure Virtual Network NAT a la subred de la
máquina virtual.

Las máquinas virtuales creadas por conjuntos de escalado de máquinas virtuales en

modo de orquestación flexible no tienen acceso de salida predeterminado.

Para obtener más información sobre las conexiones de salida en Azure, vea Acceso
de salida predeterminado y Uso de traducción de direcciones de red (SNAT) de
origen para conexiones de salida.
Conexión a una máquina virtual
1. En el portal, busque y seleccione Máquinas virtuales.

2. En la página Máquinas virtuales, seleccione vm-1.

3. En la Información generalde vm-1, seleccione Conectar.

4. En la página Conectar a la máquina virtual, seleccione la pestaña Bastion.

5. Seleccione Usar Bastion.

6. Escriba el nombre de usuario y la contraseña que creó al crear la máquina virtual y,

a continuación, seleccione Conectar.

Comunicarse entre máquinas virtuales

1. En el símbolo del sistema de Bash para vm-1, escriba ping -c 4 vm-2 .

Recibirá una respuesta similar al siguiente mensaje:

Resultados

azureuser@vm-1:~$ ping -c 4 vm-2

PING vm-2.3bnkevn3313ujpr5l1kqop4n4d.cx.internal.cloudapp.net
(10.0.0.5) 56(84) bytes of data.
64 bytes from vm-2.internal.cloudapp.net (10.0.0.5): icmp_seq=1 ttl=64
time=1.83 ms
64 bytes from vm-2.internal.cloudapp.net (10.0.0.5): icmp_seq=2 ttl=64
time=0.987 ms
64 bytes from vm-2.internal.cloudapp.net (10.0.0.5): icmp_seq=3 ttl=64
time=0.864 ms
64 bytes from vm-2.internal.cloudapp.net (10.0.0.5): icmp_seq=4 ttl=64
time=0.890 ms

2. Cierre la conexión de Bastion a VM1.

3. Repita los pasos descritos en Conectar a una máquina virtual para conectarse a
VM2.

4. En el símbolo del sistema de Bash para vm-2, escriba ping -c 4 vm-1 .

Recibirá una respuesta similar al siguiente mensaje:

Resultados
 azureuser@vm-2:~$ ping -c 4 vm-1
PING vm-1.3bnkevn3313ujpr5l1kqop4n4d.cx.internal.cloudapp.net
(10.0.0.4) 56(84) bytes of data.
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=1 ttl=64
time=0.695 ms
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=2 ttl=64
time=0.896 ms
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=3 ttl=64
time=3.43 ms
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=4 ttl=64
time=0.780 ms

5. Cierre la conexión de Bastion a VM2.

Limpieza de recursos
Cuando haya terminado con la red virtual y las máquinas virtuales, use az group delete
para quitar el grupo de recursos y todos sus recursos.

Azure CLI

az group delete \
--name test-rg \
--yes

Pasos siguientes
En este inicio rápido, creó una red virtual con una subred predeterminada que contenía
dos máquinas virtuales. Implementó Azure Bastion y lo usó para conectarse a las
máquinas virtuales y comunicarse de forma segura entre ellas. Para más información
sobre la configuración de red virtual, consulte Crear, cambiar o eliminar una red virtual.

La comunicación privada entre máquinas virtuales en una red virtual no está restringida
de manera predeterminada. Continúe con el siguiente artículo para obtener más
información sobre cómo configurar distintos tipos de comunicaciones de red de VM.

Filtrado del tráfico de red

Inicio rápido: Uso de plantillas de Bicep
para crear una red virtual
Artículo • 20/03/2023

En este inicio rápido se muestra cómo crear una red virtual con dos máquinas virtuales
(VM) y, a continuación, implementar Azure Bastion en la red virtual mediante plantillas
de Bicep. A continuación, se conecta de forma segura a las máquinas virtuales desde
Internet mediante Azure Bastion y se comunica de forma privada entre las máquinas
virtuales.

Una red virtual es el bloque de compilación fundamental de las redes privadas en Azure.
Azure Virtual Network permite que los recursos de Azure, como las máquinas virtuales,
se comuniquen de manera segura entre sí y con Internet.

Bicep es un lenguaje específico de dominio (DSL) que usa una sintaxis declarativa para
implementar recursos de Azure. Brinda sintaxis concisa, seguridad de tipos confiable y
compatibilidad con la reutilización de código. Bicep ofrece la mejor experiencia de
creación para sus soluciones de infraestructura como código en Azure.

Requisitos previos
Una cuenta de Azure con una suscripción activa. También puede crear una cuenta
de forma gratuita .

Para implementar los archivos de Bicep, se instaló la CLI de Azure o PowerShell.

CLI

1. Instalar la CLI de Azure localmente para ejecutar los comandos. Necesita

la versión 2.0.28 o posterior de la CLI de Azure. Ejecute az version para
encontrar la versión instalada y las bibliotecas dependientes, y ejecute az
upgrade para actualizar.

2. Inicie sesión en Azure con el comando az login.

Crear la red virtual y las máquinas virtuales

Este inicio rápido utiliza la plantilla de Bicep de Dos máquinas virtuales en VNET a
partir de las Plantillas de inicio rápido de Azure para crear la red virtual, la subred de
recursos y las máquinas virtuales. La plantilla de Bicep define los siguientes recursos de
Azure:

Microsoft.Network virtualNetworks: crea una red virtual de Azure.

Microsoft.Network virtualNetworks/subnets: crea una subred para las máquinas
virtuales.
Microsoft.Compute virtualMachines: crea las máquinas virtuales.
Microsoft.Compute availabilitySets: crea un conjunto de disponibilidad.
Microsoft.Network networkInterfaces: crea interfaces de red.
Microsoft.Network loadBalancers: crea un equilibrador de carga interno.
Microsoft.Storage StorageAccounts: crea una cuenta de almacenamiento.

Revisar el archivo de Bicep:

Bicep

@description('Admin username')
param adminUsername string

@description('Admin password')
@secure()
param adminPassword string

@description('Prefix to use for VM names')

param vmNamePrefix string = 'BackendVM'

@description('Location for all resources.')

param location string = resourceGroup().location

@description('Size of the virtual machines')

param vmSize string = 'Standard_D2s_v3'

var availabilitySetName = 'AvSet'

var storageAccountType = 'Standard_LRS'
var storageAccountName = uniqueString(resourceGroup().id)
var virtualNetworkName = 'vNet'
var subnetName = 'backendSubnet'
var loadBalancerName = 'ilb'
var networkInterfaceName = 'nic'
var subnetRef = resourceId('Microsoft.Network/virtualNetworks/subnets',
virtualNetworkName, subnetName)
var numberOfInstances = 2

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-08-01' = {

name: storageAccountName
location: location
sku: {
name: storageAccountType
 }
kind: 'StorageV2'
}

resource availabilitySet 'Microsoft.Compute/availabilitySets@2021-11-01' = {

name: availabilitySetName
location: location
sku: {
name: 'Aligned'
}
properties: {
platformUpdateDomainCount: 2
platformFaultDomainCount: 2
}
}

resource virtualNetwork 'Microsoft.Network/virtualNetworks@2021-05-01' = {

name: virtualNetworkName
location: location
properties: {
addressSpace: {
addressPrefixes: [
'10.0.0.0/16'
]
}
subnets: [
{
name: subnetName
properties: {
addressPrefix: '10.0.2.0/24'
}
}
]
}
}

resource networkInterface 'Microsoft.Network/networkInterfaces@2021-05-01' =

[for i in range(0, numberOfInstances): {
name: '${networkInterfaceName}${i}'
location: location
properties: {
ipConfigurations: [
{
name: 'ipconfig1'
properties: {
privateIPAllocationMethod: 'Dynamic'
subnet: {
id: subnetRef
}
loadBalancerBackendAddressPools: [
{
id:
resourceId('Microsoft.Network/loadBalancers/backendAddressPools',
loadBalancerName, 'BackendPool1')
}
 ]
}
}
]
}
dependsOn: [
virtualNetwork
loadBalancer
]
}]

resource loadBalancer 'Microsoft.Network/loadBalancers@2021-05-01' = {

name: loadBalancerName
location: location
sku: {
name: 'Standard'
}
properties: {
frontendIPConfigurations: [
{
properties: {
subnet: {
id: subnetRef
}
privateIPAddress: '10.0.2.6'
privateIPAllocationMethod: 'Static'
}
name: 'LoadBalancerFrontend'
}
]
backendAddressPools: [
{
name: 'BackendPool1'
}
]
loadBalancingRules: [
{
properties: {
frontendIPConfiguration: {
id:
resourceId('Microsoft.Network/loadBalancers/frontendIpConfigurations',
loadBalancerName, 'LoadBalancerFrontend')
}
backendAddressPool: {
id:
resourceId('Microsoft.Network/loadBalancers/backendAddressPools',
loadBalancerName, 'BackendPool1')
}
probe: {
id: resourceId('Microsoft.Network/loadBalancers/probes',
loadBalancerName, 'lbprobe')
}
protocol: 'Tcp'
frontendPort: 80
backendPort: 80
 idleTimeoutInMinutes: 15
}
name: 'lbrule'
}
]
probes: [
{
properties: {
protocol: 'Tcp'
port: 80
intervalInSeconds: 15
numberOfProbes: 2
}
name: 'lbprobe'
}
]
}
dependsOn: [
virtualNetwork
]
}

resource vm 'Microsoft.Compute/virtualMachines@2021-11-01' = [for i in

range(0, numberOfInstances): {
name: '${vmNamePrefix}${i}'
location: location
properties: {
availabilitySet: {
id: availabilitySet.id
}
hardwareProfile: {
vmSize: vmSize
}
osProfile: {
computerName: '${vmNamePrefix}${i}'
adminUsername: adminUsername
adminPassword: adminPassword
}
storageProfile: {
imageReference: {
publisher: 'MicrosoftWindowsServer'
offer: 'WindowsServer'
sku: '2019-Datacenter'
version: 'latest'
}
osDisk: {
createOption: 'FromImage'
}
}
networkProfile: {
networkInterfaces: [
{
id: networkInterface[i].id
}
]
 }
diagnosticsProfile: {
bootDiagnostics: {
enabled: true
storageUri: storageAccount.properties.primaryEndpoints.blob
}
}
}
}]

Implementar la plantilla de Bicep

1. Guarde el archivo de Bicep en el equipo local como main.bicep.

2. Implemente el archivo de Bicep utilizando la CLI de Azure o Azure PowerShell.

CLI

Azure CLI

az group create --name TestRG --location eastus

az deployment group create --resource-group TestRG --template-file
main.bicep

Cuando la implementación finaliza, un mensaje indica que se ha realizado

correctamente.

Implementación de Azure Bastion

Azure Bastion usa el explorador para conectarse a las máquinas virtuales de la red
virtual a través del shell seguro (SSH) o el protocolo de escritorio remoto (RDP)
mediante sus direcciones IP privadas. Las máquinas virtuales no necesitan direcciones IP
públicas, software cliente ni configuración especial. Para más información sobre
Azure Bastion, consulte Azure Bastion.

７ Nota

Los precios por hora comienzan desde el momento en que se implementa Bastion,
independientemente del uso de datos salientes. Para más información, consulte
Precios y SKU. Si va a implementar Bastion como parte de un tutorial o prueba,
se recomienda eliminar este recurso una vez que haya terminado de usarlo.
Use la plantilla de Bicep de Azure Bastion como servicio a partir de las Plantillas de
inicio rápido de Azure para implementar y configurar Azure Bastion en la red virtual.
Esta plantilla de Bicep define los siguientes recursos de Azure:

Microsoft.Network virtualNetworks/subnets: crea una subred AzureBastionSubnet.

Microsoft.Network bastionHosts: crea el host bastión.
Microsoft.Network publicIPAddresses: crea una dirección IP pública para el host de
Azure Bastion.
Microsoft Network networkSecurityGroups: controla la configuración del grupo de
seguridad de red (NSG).

Revisar el archivo de Bicep:

Bicep

@description('Name of new or existing vnet to which Azure Bastion should be

deployed')
param vnetName string = 'vnet01'

@description('IP prefix for available addresses in vnet address space')

param vnetIpPrefix string = '10.1.0.0/16'

@description('Specify whether to provision new vnet or deploy to existing

vnet')
@allowed([
'new'
'existing'
])
param vnetNewOrExisting string = 'new'

@description('Bastion subnet IP prefix MUST be within vnet IP prefix address

space')
param bastionSubnetIpPrefix string = '10.1.1.0/26'

@description('Name of Azure Bastion resource')

param bastionHostName string

@description('Azure region for Bastion and virtual network')

param location string = resourceGroup().location

var publicIpAddressName = '${bastionHostName}-pip'

var bastionSubnetName = 'AzureBastionSubnet'

resource publicIp 'Microsoft.Network/publicIPAddresses@2022-01-01' = {

name: publicIpAddressName
location: location
sku: {
name: 'Standard'
}
properties: {
publicIPAllocationMethod: 'Static'
 }
}

// if vnetNewOrExisting == 'new', create a new vnet and subnet

resource newVirtualNetwork 'Microsoft.Network/virtualNetworks@2022-01-01' =
if (vnetNewOrExisting == 'new') {
name: vnetName
location: location
properties: {
addressSpace: {
addressPrefixes: [
vnetIpPrefix
]
}
subnets: [
{
name: bastionSubnetName
properties: {
addressPrefix: bastionSubnetIpPrefix
}
}
]
}
}

// if vnetNewOrExisting == 'existing', reference an existing vnet and create

a new subnet under it
resource existingVirtualNetwork 'Microsoft.Network/virtualNetworks@2022-01-
01' existing = if (vnetNewOrExisting == 'existing') {
name: vnetName
}
resource subnet 'Microsoft.Network/virtualNetworks/subnets@2022-01-01' = if
(vnetNewOrExisting == 'existing') {
parent: existingVirtualNetwork
name: bastionSubnetName
properties: {
addressPrefix: bastionSubnetIpPrefix
}
}

resource bastionHost 'Microsoft.Network/bastionHosts@2022-01-01' = {

name: bastionHostName
location: location
dependsOn: [
newVirtualNetwork
existingVirtualNetwork
]
properties: {
ipConfigurations: [
{
name: 'IpConf'
properties: {
subnet: {
id: subnet.id
}
 publicIPAddress: {
id: publicIp.id
}
}
}
]
}
}

Implementar la plantilla de Bicep

1. Guarde el archivo de Bicep en su equipo local como bastion.bicep.

2. Use un editor de texto o código para realizar los siguientes cambios en el archivo:

Línea 2: cambie param vnetName string de 'vnet01' a 'VNet' .

Línea 5: cambie param vnetIpPrefix string de '10.1.0.0/16' a
'10.0.0.0/16' .

Línea 12: cambie param vnetNewOrExisting string de 'new' a 'existing' .

Línea 15: cambie param bastionSubnetIpPrefix string de '10.1.1.0/26' a
'10.0.1.0/26' .

Línea 18: cambie param bastionHostName string a param bastionHostName =

'VNet-bastion' .

Las primeras 18 líneas del archivo de Bicep ahora deben tener este aspecto:

Bicep

@description('Name of new or existing vnet to which Azure Bastion

should be deployed')
param vnetName string = 'VNet'

@description('IP prefix for available addresses in vnet address space')

param vnetIpPrefix string = '10.0.0.0/16'

@description('Specify whether to provision new vnet or deploy to

existing vnet')
@allowed([
'new'
'existing'
])
param vnetNewOrExisting string = 'existing'

@description('Bastion subnet IP prefix MUST be within vnet IP prefix

address space')
param bastionSubnetIpPrefix string = '10.0.1.0/26'

@description('Name of Azure Bastion resource')

 param bastionHostName = 'VNet-bastion'

3. Guarde el archivo bastion.bicep.

4. Implemente el archivo de Bicep utilizando la CLI de Azure o Azure PowerShell.

CLI

Azure CLI

az deployment group create --resource-group TestRG --template-file

bastion.bicep

Cuando la implementación finaliza, un mensaje indica que se ha realizado

correctamente.

７ Nota

Las máquinas virtuales de una red virtual con un host bastión no necesitarán
direcciones IP públicas. Bastion proporcionará la dirección IP pública y las máquinas
virtuales usarán direcciones IP privadas para comunicarse dentro de la red. Es
posible quitar las direcciones IP públicas de cualquier máquina virtual en redes
virtuales hospedadas por Bastion. Para obtener más información, consulte
Desasociación de una dirección IP pública de una máquina virtual de Azure.

Revisión de los recursos implementados

Use la CLI de Azure, Azure PowerShell o Azure Portal para revisar los recursos
implementados.

CLI

Azure CLI

az resource list --resource-group TestRG

Conexión a una máquina virtual

 1. En el portal, busque y seleccione Máquinas virtuales.

2. En la página Máquinas virtuales, seleccione BackendVM1.

3. En la parte superior de la página BackendVM1, seleccione la flecha desplegable

situada junto a Conectar y, a continuación, seleccione Bastion.

4. En la página Bastion, escriba el nombre de usuario y la contraseña que creó para la

máquina virtual y, a continuación, seleccione Conectar.

Comunicarse entre máquinas virtuales

1. En el escritorio de BackendVM1, abra PowerShell.

2. Escriba ping BackendVM0 . Recibirá una respuesta similar al siguiente mensaje:

PowerShell

PS C:\Users\BackendVM1> ping BackendVM0

Pinging BackendVM0.ovvzzdcazhbu5iczfvonhg2zrb.bx.internal.cloudapp.net
with 32 bytes of data
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.0.0.5:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Se producirá un error de ping porque usa el protocolo de mensajes de control de

Internet (ICMP). De manera predeterminada, no se permite que el protocolo ICMP
atraviese el firewall de Windows.

3. Para permitir que el protocolo ICMP entre a través del firewall de Windows en esta
máquina virtual, escriba el siguiente comando:
 PowerShell

New-NetFirewallRule –DisplayName "Allow ICMPv4-In" –Protocol ICMPv4

4. Cierre la conexión de Bastion a BackendVM1.

5. Repita los pasos descritos en Conexión a una máquina virtual para conectarse a
BackendVM0.

6. Desde PowerShell en BackendVM0, introduzca ping BackendVM1 .

Esta vez obtendrá una respuesta exitosa similar al siguiente mensaje, ya que
permitió al protocolo ICMP a través del firewall en VM1.

Símbolo del sistema de Windows

PS C:\Users\BackendVM0> ping BackendVM1

Pinging BackendVM1.e5p2dibbrqtejhq04lqrusvd4g.bx.internal.cloudapp.net
[10.0.0.4] with 32 bytes of data:
Reply from 10.0.0.4: bytes=32 time=2ms TTL=128
Reply from 10.0.0.4: bytes=32 time<1ms TTL=128
Reply from 10.0.0.4: bytes=32 time<1ms TTL=128
Reply from 10.0.0.4: bytes=32 time<1ms TTL=128

Ping statistics for 10.0.0.4:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 2ms, Average = 0ms

7. Cierre la conexión de Bastion a BackendVM0.

Limpieza de recursos
Cuando haya terminado con la red virtual, use la CLI de Azure, Azure PowerShell o Azure
Portal para eliminar el grupo de recursos y todos sus recursos.

CLI

Azure CLI

az group delete --name TestRG

Pasos siguientes
En este inicio rápido, ha creado una red virtual con dos subredes, una que contiene dos
máquinas virtuales y la otra para Azure Bastion. Implementó Azure Bastion y lo usó para
conectarse a las máquinas virtuales y comunicarse de forma segura entre ellas. Para más
información sobre la configuración de red virtual, consulte Crear, cambiar o eliminar una
red virtual.

La comunicación privada entre máquinas virtuales no está restringida en una red virtual.
Continúe con el siguiente artículo para obtener más información sobre cómo configurar
distintos tipos de comunicaciones de red de VM.

Filtrado del tráfico de red

Inicio rápido: Creación de una red
virtual: plantilla de Resource Manager
Artículo • 09/03/2023

En este inicio rápido aprenderá a crear una red virtual con dos subredes mediante la
plantilla de Resource Manager. Una red virtual es el bloque de creación básico de una
red privada en Azure. Permite que los recursos de Azure, como las máquinas virtuales, se
comuniquen de manera segura entre sí y con Internet.

Una plantilla de Resource Manager es un archivo JSON (notación de objetos JavaScript)

que define tanto la infraestructura como la configuración de un proyecto. La plantilla
usa sintaxis declarativa. En la sintaxis declarativa, se describe la implementación deseada
sin escribir la secuencia de comandos de programación para crearla.

También se puede completar este inicio rápido mediante Azure Portal, Azure PowerShell
o la CLI de Azure.

Requisitos previos
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Revisión de la plantilla
La plantilla usada en este inicio rápido forma parte de las plantillas de inicio rápido de
Azure .

JSON

{
"$schema": "https://schema.management.azure.com/schemas/2019-04-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"metadata": {
"_generator": {
"name": "bicep",
"version": "0.6.18.56646",
"templateHash": "10806234693722113459"
}
},
"parameters": {
"vnetName": {
"type": "string",
"defaultValue": "VNet1",
 "metadata": {
"description": "VNet name"
}
},
"vnetAddressPrefix": {
"type": "string",
"defaultValue": "10.0.0.0/16",
"metadata": {
"description": "Address prefix"
}
},
"subnet1Prefix": {
"type": "string",
"defaultValue": "10.0.0.0/24",
"metadata": {
"description": "Subnet 1 Prefix"
}
},
"subnet1Name": {
"type": "string",
"defaultValue": "Subnet1",
"metadata": {
"description": "Subnet 1 Name"
}
},
"subnet2Prefix": {
"type": "string",
"defaultValue": "10.0.1.0/24",
"metadata": {
"description": "Subnet 2 Prefix"
}
},
"subnet2Name": {
"type": "string",
"defaultValue": "Subnet2",
"metadata": {
"description": "Subnet 2 Name"
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
}
},
"resources": [
{
"type": "Microsoft.Network/virtualNetworks",
"apiVersion": "2021-08-01",
"name": "[parameters('vnetName')]",
"location": "[parameters('location')]",
"properties": {
"addressSpace": {
 "addressPrefixes": [
"[parameters('vnetAddressPrefix')]"
]
},
"subnets": [
{
"name": "[parameters('subnet1Name')]",
"properties": {
"addressPrefix": "[parameters('subnet1Prefix')]"
}
},
{
"name": "[parameters('subnet2Name')]",
"properties": {
"addressPrefix": "[parameters('subnet2Prefix')]"
}
}
]
}
}
]
}

En la plantilla se han definido los siguientes recursos de Azure:

Microsoft.Network/virtualNetworks: cree una red virtual de Azure.

Microsoft.Network/virtualNetworks/subnets: cree una subred.

Implementación de la plantilla
Implementación de la plantilla de Resource Manager en Azure:

1. Seleccione Implementar en Azure para iniciar sesión en Azure y abrir la plantilla.

La plantilla crea una red virtual con dos subredes.

2. En el portal, en la página Create a Virtual Network with two Subnets (Crear una
red virtual con dos subredes), escriba o seleccione los valores siguientes:

Grupo de recursos: seleccione Crear nuevo, escriba CreateVNetQS-rg como

nombre del grupo de recursos y seleccione Aceptar.
Nombre de la red virtual: escriba el nombre de la nueva red virtual.

3. Seleccione Revisar y crear y, luego, Crear.

4. Cuando se complete la implementación, seleccione el botón Ir al recurso para

revisar los recursos implementados.
Revisión de los recursos implementados
Explore los recursos que se crearon con la red virtual examinando las hojas de
configuración de VNet1.

1. En la pestaña Información general, verá el espacio de direcciones definido de

10.0.0.0/16.

2. En la pestaña Subredes, verá las subredes implementadas de Subnet1 y Subnet2

con los valores adecuados de la plantilla.

Para obtener información sobre la sintaxis y las propiedades de JSON de una red virtual
en una plantilla, consulte Microsoft.Network/virtualNetworks.

Limpieza de recursos
Cuando ya no necesite los recursos que ha creado con la red virtual, elimine el grupo de
recursos. Así se quitan tanto la red virtual como todos los recursos relacionados.

Para eliminar el grupo de recursos, llame al cmdlet Remove-AzResourceGroup :

Azure PowerShell

Remove-AzResourceGroup -Name <your resource group name>

Pasos siguientes
En este inicio rápido, ha implementado una red virtual de Azure con dos subredes. Para
más información sobre las redes virtuales de Azure, pase al tutorial de redes virtuales.

Filtrado del tráfico de red

Tutorial: Filtrado del tráfico de red con
un grupo de seguridad de red en Azure
Portal
Artículo • 27/07/2023

Puede usar un grupo de seguridad de red de Azure para filtrar el tráfico de red que
entra y sale de los recursos de Azure en una red virtual de Azure.

Los grupos de seguridad de red contienen reglas de seguridad que filtran el tráfico de
red por dirección IP, puerto y protocolo. Cuando un grupo de seguridad de red está
asociado a una subred, se aplican reglas de seguridad a los recursos implementados en
esa subred.

En este tutorial aprenderá a:

＂ Crear un grupo de seguridad de red y reglas de seguridad

＂ Creación de grupos de seguridad de aplicaciones
＂ Crear una red virtual y asociar un grupo de seguridad de red a una subred
 ＂ Implementar máquinas virtuales y asociar sus interfaces de red a los grupos de
seguridad de aplicación.

Prerrequisitos
Una cuenta de Azure con una suscripción activa. También puede crear una cuenta
de forma gratuita .

Inicio de sesión en Azure

Inicie sesión en Azure Portal .

Creación de una red virtual

El siguiente procedimiento crea una red virtual con una subred de recurso.

1. En el portal, busque y seleccione Redes virtuales.

2. En la página Redes virtuales, seleccione Crear.

3. En la pestaña Datos básicos de Crear una red virtual, introduzca o seleccione la

siguiente información:

Configuración Valor

Detalles del proyecto

Suscripción Seleccione su suscripción.

Resource group Seleccione Crear nuevo.

Escriba test-rg en Nombre.
Seleccione
.

Detalles de instancia

Nombre Escriba vnet-1.

Region Seleccione Este de EE. UU. 2.

4. Seleccione Siguiente: Direcciones IP en la parte inferior de la página.

5. En la pestaña Direcciones IP en Espacio de direcciones IPv4, seleccione el icono

de papelera para quitar los espacios de direcciones que ya aparezcan y, a
continuación, escriba 10.0.0.0/16.

6. Haga clic en + Agregar subred.

7. En + Agregar subred, escriba o seleccione la información siguiente:

Configuración Value

Nombre de subred Escriba subnet-1.

Intervalo de direcciones de subred Escriba 10.0.0.0/24.

 8. Seleccione Agregar.

9. Seleccione Siguiente: Seguridad en la parte inferior de la página.

10. Seleccione Revisar y crear en la parte inferior de la pantalla y, cuando se supere la

validación, seleccione Crear.

Creación de grupos de seguridad de

aplicaciones
Un grupo de seguridad de aplicaciones (ASG) permite agrupar servidores con funciones
similares, como servidores web.

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba

Grupo de seguridad de aplicaciones. Seleccione Grupos de seguridad de
aplicaciones en los resultados de la búsqueda.
 2. Seleccione + Create (+ Crear).

3. En la pestaña Aspectos básicos de Crear un grupo de seguridad de aplicación,

escriba o seleccione esta información:

Configuración Valor

Detalles del proyecto

Suscripción Seleccione su suscripción.

Resource group Seleccione test-rg.

Detalles de instancia

Nombre Escriba asg-web.

Region Seleccione Este de EE. UU. 2.

4. Seleccione Revisar + crear.

5. Seleccione + Create (+ Crear).

6. Repita los pasos anteriores, pero especifique los valores siguientes:

Configuración Valor

Detalles del proyecto

Suscripción Seleccione su suscripción.

Resource group Seleccione test-rg.

Detalles de instancia

Nombre Escriba asg-mgmt.

Region Seleccione Este de EE. UU. 2.

7. Seleccione Revisar + crear.

8. Seleccione Crear.

Crear un grupo de seguridad de red

Un grupo de seguridad de red (NSG) protege el tráfico de red de una red virtual.

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba

Grupo de seguridad de red. En los resultados de la búsqueda, seleccione Grupos
 de seguridad de red.

７ Nota

En los resultados de la búsqueda de grupos de seguridad de red, es posible

que vea Grupos de seguridad de red (clásico). Seleccione Grupos de
seguridad de red.

2. Seleccione + Create (+ Crear).

3. En la pestaña Aspectos básicos de Crear grupo de seguridad de red, escriba o

seleccione esta información:

Configuración Valor

Detalles del proyecto

Suscripción Seleccione su suscripción.

Resource group Seleccione test-rg.

Detalles de instancia

Nombre Escriba nsg-1.

Location Seleccione Este de EE. UU. 2.

4. Seleccione Revisar + crear.

5. Seleccione Crear.

Asociación del grupo de seguridad de red a la

subred
En esta sección, asociará el grupo de seguridad de red con la subred de la red virtual
que creó anteriormente.

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba

Grupo de seguridad de red. En los resultados de la búsqueda, seleccione Grupos
de seguridad de red.

2. Seleccione nsg-1.

3. Seleccione Subredes en la sección Configuración de nsg-1.

 4. En la página Subredes, seleccione +Asociar:

5. En Asociar subred, seleccione vnet-1 (test-rg) en Red virtual.

6. En subnet-1, seleccione Subred y, luego, elija Aceptar.

Creación de reglas de seguridad

1. Seleccione Reglas de seguridad de entrada en la sección Configuración de nsg-1.

2. En la página Reglas de seguridad de entrada, seleccione +Agregar.

3. Cree una regla de seguridad que permita a los puertos 80 y 443 para el grupo de
seguridad de la aplicación asg-web. En la página Agregar regla de seguridad de
entrada, especifique o seleccione los siguientes datos:

Configuración Valor

Source Deje el valor predeterminado, Cualquiera.

Source port ranges Deje el valor predeterminado de (*).

Destination Seleccione Grupo de seguridad de

aplicación.

Grupos de seguridad de aplicaciones de Seleccione asg-web.

destino

Servicio Deje el valor predeterminado,

Personalizado.
 Configuración Valor

Intervalos de puertos de destino Escriba 80 443.

Protocolo seleccione TCP.

Acción Deje el valor predeterminado, Permitir.

Priority Deje el valor predeterminado, 100.

Nombre Escriba allow-web-all.

4. Seleccione Agregar.

5. Complete los pasos anteriores con la siguiente información:

Configuración Valor

Source Deje el valor predeterminado, Cualquiera.

Source port ranges Deje el valor predeterminado de (*).

Destination Seleccione Grupo de seguridad de

aplicación.

Grupo de seguridad de aplicación de Seleccione asg-mgmt.

destino

Servicio Seleccione RDP.

Acción Deje el valor predeterminado, Permitir.

Priority Deje el valor predeterminado, 110.

Nombre Escriba allow-rdp-all.

6. Seleccione Agregar.

Ｕ Precaución

En este artículo, RDP (puerto 3389) está expuesto a Internet para la máquina
virtual asignada al grupo de seguridad de aplicaciones asg-mgmt.

En entornos de producción, en lugar de exponer el puerto 3389 a Internet, es

conveniente que se conecte a los recursos de Azure que desee administrar
utilizando una VPN, una conexión de red privada o Azure Bastion.

Para más información, consulte ¿Qué es Azure Bastion?

Creación de máquinas virtuales
Cree dos máquinas virtuales (VM) en la red virtual.

1. En el portal, busque y seleccione Máquinas virtuales.

2. En Máquinas virtuales, seleccione + Crear y, después, Máquina virtual de Azure.

3. En Crear una máquina virtual, escriba o seleccione los datos siguientes en la

pestaña Conceptos básicos:

Configuración Valor

Detalles del proyecto

Suscripción Seleccione su suscripción.

Resource group Seleccione test-rg.

Detalles de instancia

Nombre de la máquina Escriba vm-1.

virtual

Region Seleccione (EE. UU.) Este de EE. UU. 2.

Opciones de Deje el valor predeterminado No se requiere redundancia de

disponibilidad la infraestructura.

Tipo de seguridad Seleccione Estándar.

Imagen Seleccione Windows Server 2022 Datacenter - x64 Gen2.

Instancia de Azure Spot Deje esta casilla desactivada, tal y como está de forma
predeterminada.

Size Seleccione un tamaño.

Cuenta de administrador

Nombre de usuario Especifique un nombre de usuario.

Contraseña Escriba una contraseña.

Confirmación de la Vuelva a escribir la contraseña.

contraseña

Reglas de puerto de
entrada

Selección de puertos de Seleccione Ninguno.

 Configuración Valor

entrada

4. Seleccione Siguiente: Discos y, luego, Siguiente: Redes.

5. En la pestaña Redes, escriba o seleccione la siguiente información:

Parámetro Valor

Interfaz de red

Virtual network Seleccione vnet-1.

Subnet Seleccione subnet-1 (10.0.0.0/24).

Dirección IP pública Deje el valor predeterminado, que es una nueva dirección

IP pública.

Grupo de seguridad de red de Seleccione Ninguno.

NIC

6. Seleccione la pestaña Revisar y crear o el botón azul Revisar y crear en la parte

inferior de la página.

7. Seleccione Crear. La máquina virtual puede tardar unos minutos en implementarse.

8. Repita los pasos anteriores para crear una segunda máquina virtual denominada
vm-2.

Asociación de interfaces de red a un ASG

Cuando se crearon las máquinas virtuales, Azure creó una interfaz de red para cada una
y la asoció a estas.

Agregue la interfaz de red de cada máquina virtual a uno de los grupos de seguridad de
aplicaciones que creó anteriormente:

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba

Máquina virtual. En los resultados de la búsqueda, seleccione Máquinas virtuales.

2. Seleccione vm-1.

3. Seleccione Redes en la sección Configuración de la máquina virtual vm-1.

4. Seleccione la pestaña Grupos de seguridad de aplicación y Configurar grupos de

seguridad de aplicación.
 5. En Configurar los grupos de seguridad de aplicaciones, seleccione asg-web en el
menú desplegable Grupos de seguridad de aplicaciones y, a continuación,
seleccione Guardar.

6. Repita los pasos anteriores para vm-2 y seleccione asg-mgmt en el menú

desplegable Grupos de seguridad de aplicaciones.

Probar los filtros de tráfico

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba
Máquina virtual. En los resultados de la búsqueda, seleccione Máquinas virtuales.

2. Seleccione vm-2.

3. En la página Información general, seleccione el botón Conectar y, luego, elija RDP

nativo.

4. Seleccione Descargar archivo RDP.

5. Abra el archivo RDP descargado y seleccione Conectar. Escriba el nombre de

usuario y la contraseña que especificó al crear la VM.

6. Seleccione Aceptar.

7. Puede recibir una advertencia sobre el certificado durante el proceso de conexión.

Si aparece esta advertencia, seleccione Sí o Continuar para continuar con la
conexión.

La conexión se realiza correctamente, ya que se permite la entrada de tráfico de

Internet al grupo de seguridad de aplicaciones asg-mgmt en el puerto 3389.

La interfaz de red de vm-2 está asociada con el grupo de seguridad de

aplicaciones asg-mgmt y permite la conexión.
 8. Abra una sesión de PowerShell en vm-2. Conéctese a vm-1 mediante lo siguiente:

PowerShell

mstsc /v:vm-1

La conexión RDP entre vm-2 y vm-1 se realiza correctamente, ya que, de forma

predeterminada, las máquinas virtuales de la misma red pueden comunicarse entre
sí por cualquier puerto.

No se puede crear una conexión RDP con la máquina virtual vm-1 desde Internet.
La regla de seguridad de asg-web impide la conexión con el puerto 3389 de
entrada desde Internet. De forma predeterminada, se deniega el tráfico de entrada
de Internet en todos los recursos.

9. Para instalar Microsoft IIS en la máquina virtual vm-1, escriba el siguiente comando
desde una sesión de PowerShell de la máquina virtual vm-1:

PowerShell

Install-WindowsFeature -name Web-Server -IncludeManagementTools

10. Una vez completada la instalación de IIS, desconecte la sesión de la máquina

virtual vm-1, lo que le deja en la conexión de escritorio remoto de la máquina
virtual vm-2.

11. Desconéctese de la máquina virtual vm-2.

12. Busque vm-1 en el cuadro de búsqueda del portal.

13. En la página Información general de vm-1, anote la dirección IP pública de la

máquina virtual. La dirección que aparece en el ejemplo siguiente es 20.230.55.178,
pero su dirección será diferente:
 14. Para confirmar que tiene acceso al servidor web vm-1 desde Internet, abra un
explorador de Internet en el equipo y vaya a http://<public-ip-address-from-
previous-step> .

Aparece la página predeterminada de IIS, ya que se permite la entrada de tráfico de

Internet al grupo de seguridad de aplicaciones asg-web en el puerto 80.

La interfaz de red asociada a vm-1 está asociada con el grupo de seguridad de

aplicaciones asg-web y permite la conexión.

Limpieza de recursos
Cuando haya terminado de utilizar los recursos creados, puede eliminar el grupo de
recursos y todos sus recursos.

1. En Azure Portal, busque y seleccione Grupos de recursos.

2. En la página Grupos de recursos, seleccione el grupo de recursos test-rg.

3. En la página test-rg, elija Eliminar grupo de recursos.

4. Escriba test-rg en Introducir nombre del grupo de recursos para confirmar la

eliminación y seleccione Eliminar.

Pasos siguientes
En este tutorial ha:

Creado un grupo de seguridad de red y lo ha asociado a una subred de red virtual.

 Creado grupos de seguridad de aplicaciones para la Web y las tareas de
administración.
Creado dos máquinas virtuales y ha asociado sus interfaces de red con los grupos
de seguridad de aplicaciones.
Probado el filtrado de redes de los grupos de seguridad de aplicaciones.

Para más información acerca de los grupos de seguridad de red, consulte Introducción a
los grupos de seguridad de red y Administración de un grupo de seguridad de red.

De forma predeterminada, Azure enruta el tráfico entre subredes. En su lugar, puede

elegir enrutar el tráfico entre subredes a través de una máquina virtual, que actúa como
un firewall, por ejemplo.

Para aprender a crear una tabla de rutas, avance al siguiente tutorial.

Creación de una tabla de rutas

Tutorial: Enrutamiento del tráfico de red
con una tabla de rutas mediante Azure
Portal
Artículo • 24/08/2023

De forma predeterminada, Azure enruta el tráfico entre todas las subredes de una red
virtual. Sin embargo, puede crear sus propias rutas para invalidar las predeterminadas
de Azure. Las rutas personalizadas resultan de utilidad si, por ejemplo, quiere enrutar el
tráfico entre subredes por medio de una aplicación virtual de red (NVA).

En este tutorial, aprenderá a:

＂ Creación de una red virtual y subredes

＂ Creación de una aplicación virtual de red para enrutar el tráfico
＂ Implementación de máquinas virtuales (VM) en subredes diferentes
＂ Creación de una tabla de rutas
＂ Creación de una ruta
＂ Asociación de una tabla de rutas a una subred
＂ Enrutamiento del tráfico desde una subred a otra a través de una aplicación virtual
de red

Requisitos previos
Una cuenta de Azure con una suscripción activa. También puede crear una cuenta
de forma gratuita .

Inicio de sesión en Azure

Inicie sesión en Azure Portal .

Creación de una red virtual y un host bastión

El procedimiento siguiente crea una red virtual con una subred de recursos, una subred
de Azure Bastion y un host de Azure Bastion.

1. En el portal, busque y seleccione Redes virtuales.

2. En la página Redes virtuales, seleccione y Crear.

3. En la pestaña Datos básicos de Crear una red virtual, introduzca o seleccione la
siguiente información:

Configuración Valor

Detalles del proyecto

Subscription Seleccione su suscripción.

Resource group Seleccione Crear nuevo.

Escriba test-rg en Nombre.
Seleccione
.

Detalles de instancia

Nombre Escriba vnet-1.

Region Seleccione Este de EE. UU. 2.

4. Seleccione Siguiente para continuar a la pestaña Seguridad.

5. Seleccione Habilitar Bastion en la sección Azure Bastion de la pestaña Seguridad.

 Azure Bastion usa el explorador para conectarse a las máquinas virtuales de la red
virtual a través del shell seguro (SSH) o el protocolo de escritorio remoto (RDP)
mediante sus direcciones IP privadas. Las máquinas virtuales no necesitan
direcciones IP públicas, software cliente ni configuración especial. Para más
información sobre Azure Bastion, consulte Azure Bastion

７ Nota

Los precios por hora comienzan desde el momento en que se implementa

Bastion, independientemente del uso de datos salientes. Para más
información, consulte Precios y SKU. Si va a implementar Bastion como
parte de un tutorial o prueba, se recomienda eliminar este recurso una vez
que haya terminado de usarlo.

6. Escriba o seleccione la información siguiente en Azure Bastion:

Configuración Valor

Nombre de host de Azure Bastion Escriba bastión.

Dirección IP pública de Azure Bastion Seleccione Crear una dirección IP pública.

Escriba public-ip-1 en Nombre.
Seleccione
.
7. Seleccione Siguiente para continuar a la pestaña Direcciones IP.

8. En el cuadro espacio de direcciones de Subredes, seleccione la subred

predeterminada.

9. En Agregar subred, escriba o seleccione la información siguiente:

Configuración Valor

Detalles de subred

Plantilla de subred Deje el valor predeterminado.

Nombre Escriba subnet-1.

Dirección inicial Deje el valor predeterminado de 10.0.0.0.

 Configuración Valor

Tamaño de la subred Deje el valor predeterminado de /24(256 direcciones).

10. Seleccione Guardar.

11. Seleccione Revisar y crear en la parte inferior de la pantalla y, cuando se supere la

validación, seleccione Crear.

Creación de las subredes

Para este tutorial se necesita una red perimetral y una subred privada. La subred DMZ
es donde se implementa la NVA y la subred Privada es donde se implementan las
máquinas virtuales a las que desea enrutar el tráfico. La subred-1 es la subred creada en
los pasos anteriores. Use subnet-1 para la máquina virtual pública.

1. En el cuadro de búsqueda de la parte superior del portal, escriba Red virtual. En

los resultados de la búsqueda, seleccione Redes virtuales.

2. En Redes virtuales, seleccione vnet-1.

3. En vnet-1, seleccione Subredes en la sección Configuración.

4. En la lista de subredes de la red virtual, elija + Subred.

5. En Agregar subred, escriba o seleccione la información siguiente:

Configuración Value

Nombre Escriba subnet-private.

Intervalo de direcciones de subred Escriba 10.0.2.0/24.

6. Seleccione Guardar.

7. Seleccione +Subred.

8. En Agregar subred, escriba o seleccione la información siguiente:

 Parámetro Value

Nombre Escriba subnet-dmz.

Intervalo de direcciones de subred Escriba 10.0.3.0/24.

9. Seleccione Guardar.

Creación de una máquina virtual de NVA

Las aplicaciones virtuales de red (NVA) son máquinas virtuales que ayudan con las
funciones de red, como la optimización del enrutamiento y del firewall. En esta sección,
cree una NVA mediante una máquina virtual Ubuntu 22.04.

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba

Máquina virtual. En los resultados de la búsqueda, seleccione Máquinas virtuales.

2. Seleccione + Crear y, después, Máquina virtual de Azure.

3. En Crear una máquina virtual, escriba o seleccione la siguiente información en la

pestaña Datos básicos:

Configuración Valor

Detalles del proyecto

 Configuración Valor

Subscription Seleccione su suscripción.

Resource group Seleccione test-rg.

Detalles de instancia

Nombre de la máquina Escriba vm-nva.

virtual

Region Seleccione (EE. UU.) Este de EE. UU. 2.

Opciones de disponibilidad Seleccione No se requiere redundancia de la

infraestructura.

Tipo de seguridad Seleccione Estándar.

Imagen Seleccione Ubuntu Server 22.04 LTS: x64 Gen2.

Arquitectura VM Deje el valor predeterminado, x64.

Size Seleccione un tamaño.

Cuenta de administrador

Tipo de autenticación Seleccione Contraseña.

Nombre de usuario Especifique un nombre de usuario.

Contraseña Escriba una contraseña.

Confirmación de la Vuelva a escribir la contraseña.

contraseña

Reglas de puerto de entrada

Puertos de entrada públicos Seleccione Ninguno.

4. Seleccione Siguiente: Discos y, luego, Siguiente: Redes.

5. En la pestaña Redes, escriba o seleccione la siguiente información:

Configuración Value

Interfaz de red

Virtual network Seleccione vnet-1.

Subnet Seleccione subred-dmz (10.0.3.0/24).

Dirección IP pública Seleccione Ninguno.

 Configuración Value

Grupo de seguridad de red de NIC Seleccione Advanced (Avanzadas).

Configuración del grupo de seguridad de red Seleccione Crear nuevo.

En Nombre escriba nsg-nva.
Seleccione Aceptar.

6. Deje el resto de las opciones en sus valores predeterminados y luego seleccione

Revisar y crear.

7. Seleccione Crear.

Creación de máquinas virtuales públicas y

privadas
Cree dos máquinas virtuales en la red virtual vnet-1. Una máquina virtual está en la
subred subnet-1 y la otra máquina virtual está en la subred privada de la subnet. Use la
misma imagen de máquina virtual para ambas máquinas virtuales.

Creación de una máquina virtual pública

La máquina virtual pública se usa para simular una máquina en la red pública de
Internet. La máquina virtual pública y privada se usa para probar el enrutamiento del
tráfico de red a través de la máquina virtual de NVA.

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba

Máquina virtual. En los resultados de la búsqueda, seleccione Máquinas virtuales.

2. Seleccione + Crear y, después, Máquina virtual de Azure.

3. En Crear una máquina virtual, escriba o seleccione la siguiente información en la

pestaña Datos básicos:

Configuración Valor

Detalles del proyecto

Subscription Seleccione su suscripción.

Resource group Seleccione test-rg.

Detalles de instancia
 Configuración Valor

Nombre de la máquina Escriba vm-public.

virtual

Region Seleccione (EE. UU.) Este de EE. UU. 2.

Opciones de disponibilidad Seleccione No se requiere redundancia de la

infraestructura.

Tipo de seguridad Seleccione Estándar.

Imagen Seleccione Ubuntu Server 22.04 LTS: x64 Gen2.

Arquitectura VM Deje el valor predeterminado, x64.

Size Seleccione un tamaño.

Cuenta de administrador

Tipo de autenticación Seleccione Contraseña.

Nombre de usuario Especifique un nombre de usuario.

Contraseña Escriba una contraseña.

Confirmación de la Vuelva a escribir la contraseña.

contraseña

Reglas de puerto de entrada

Puertos de entrada públicos Seleccione Ninguno.

4. Seleccione Siguiente: Discos y, luego, Siguiente: Redes.

5. En la pestaña Redes, escriba o seleccione la siguiente información:

Configuración Value

Interfaz de red

Virtual network Seleccione vnet-1.

Subnet Seleccione subnet-1 (10.0.0.0/24).

Dirección IP pública Seleccione Ninguno.

Grupo de seguridad de red de NIC Seleccione Ninguno.

6. Deje el resto de las opciones en sus valores predeterminados y luego seleccione

Revisar y crear.
 7. Seleccione Crear.

Creación de una máquina virtual privada

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba
Máquina virtual. En los resultados de la búsqueda, seleccione Máquinas virtuales.

2. Seleccione + Crear y, después, Máquina virtual de Azure.

3. En Crear una máquina virtual, escriba o seleccione la siguiente información en la

pestaña Datos básicos:

Configuración Valor

Detalles del proyecto

Subscription Seleccione su suscripción.

Resource group Seleccione test-rg.

Detalles de instancia

Nombre de la máquina Escriba vm-private.

virtual

Region Seleccione (EE. UU.) Este de EE. UU. 2.

Opciones de disponibilidad Seleccione No se requiere redundancia de la

infraestructura.

Tipo de seguridad Seleccione Estándar.

Imagen Seleccione Ubuntu Server 22.04 LTS: x64 Gen2.

Arquitectura VM Deje el valor predeterminado, x64.

Size Seleccione un tamaño.

Cuenta de administrador

Tipo de autenticación Seleccione Contraseña.

Nombre de usuario Especifique un nombre de usuario.

Contraseña Escriba una contraseña.

Confirmación de la Vuelva a escribir la contraseña.

contraseña

Reglas de puerto de entrada

 Configuración Valor

Puertos de entrada públicos Seleccione Ninguno.

4. Seleccione Siguiente: Discos y, luego, Siguiente: Redes.

5. En la pestaña Redes, escriba o seleccione la siguiente información:

Configuración Valor

Interfaz de red

Virtual network Seleccione vnet-1.

Subnet Seleccione subnet-private (10.0.2.0/24).

Dirección IP pública Seleccione Ninguno.

Grupo de seguridad de red de NIC Seleccione Ninguno.

6. Deje el resto de las opciones en sus valores predeterminados y luego seleccione

Revisar y crear.

7. Seleccione Crear.

Habilitación del reenvío IP

Para enrutar el tráfico mediante la NVA, active el reenvío de IP en Azure y en el sistema
operativo de la máquina virtual vm-nva. Una vez habilitado el reenvío de IP, el tráfico
recibido por la máquina virtual vm-nva destinado a una dirección IP diferente no se
quitará y se reenviará al destino correcto.

Habilitación del reenvío IP en Azure

En esta sección, activará el reenvío de IP para la interfaz de red de la máquina virtual
vm-nva.

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba

Máquina virtual. En los resultados de la búsqueda, seleccione Máquinas virtuales.

2. En Máquinas virtuales, seleccione vm-nva.

3. En vm-nva, seleccione Redes en la sección Configuración.

 4. Seleccione el nombre de la interfaz de red junto a Interfaz de red:. El nombre
comienza con vm-nva y tiene un número aleatorio asignado a la interfaz. El
nombre de la interfaz de este ejemplo es vm-nva124.

5. En la página de información general de la interfaz de red, en Configuración,

seleccione Configuraciones de IP.

6. En Configuraciones de IP, seleccione el cuadro situado junto a Habilitar reenvío

IP.

7. Seleccione Aplicar.

Activar el reenvío IP en el sistema operativo

En esta sección, activará el reenvío de IP para el sistema operativo de la máquina virtual
vm-nva para reenviar el tráfico de red. Use el servicio Azure Bastion para conectarse a la
máquina virtual vm-nva.

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba

Máquina virtual. En los resultados de la búsqueda, seleccione Máquinas virtuales.

2. En Máquinas virtuales, seleccione vm-nva.

3. Seleccione Bastion en la sección Operaciones.

4. Escriba el nombre de usuario y la contraseña que especificó al crear la máquina

virtual.

5. Seleccione Conectar.

6. Escriba la siguiente información en el símbolo del sistema de la máquina virtual

para habilitar el reenvío IP:

Bash

sudo vim /etc/sysctl.conf

7. En el editor Vim, quite # de la línea net.ipv4.ip_forward=1 :

Presione la tecla Insertar.

Bash

# Uncomment the next line to enable packet forwarding for IPv4

net.ipv4.ip_forward=1

Presione la tecla Esc.

Escriba :wq y presione ENTRAR.

8. Cierre la sesión de Bastion.

9. Reinicie la máquina virtual.

Creación de una tabla de rutas

En esta sección, cree una tabla de rutas para definir la ruta del tráfico a través de la
máquina virtual de NVA. La tabla de rutas está asociada a la subred subnet-1 donde se
implementa la máquina virtual vm-public.
 1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba
Tabla de rutas. Seleccione Tablas de rutas en los resultados de la búsqueda.

2. Seleccione + Create (+ Crear).

3. En Crear tabla de rutas, escriba o seleccione la siguiente información:

Configuración Valor

Detalles del proyecto

Subscription Seleccione su suscripción.

Resource group Seleccione test-rg.

Detalles de instancia

Region Seleccione Este de EE. UU. 2.

Nombre Escriba route-table-public.

Propagar las rutas de la puerta de enlace Deje el valor predeterminado de Sí.

4. Seleccione Revisar + crear.

5. Seleccione Crear.

Creación de una ruta

En esta sección, cree una ruta en la tabla de rutas que creó en los pasos anteriores.

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba

Tabla de rutas. Seleccione Tablas de rutas en los resultados de la búsqueda.

2. Seleccione route-table-public.

3. En Configuración, seleccione Rutas.

4. Seleccione + Agregar en Rutas.

5. En Agregar ruta, escriba o seleccione la información siguiente:

Configuración Value

Nombre de ruta Escriba to-private-subnet.

Tipo de destino Seleccione Direcciones IP.

Configuración Value

Intervalos de direcciones IP de Escriba 10.0.2.0/24.

destino y CIDR

Tipo de próximo salto Seleccione Aplicación virtual.

Siguiente dirección de salto Escriba 10.0.3.4.

Esta es la dirección IP de vm-nva que creó en los
pasos anteriores..
 6. Seleccione Agregar.

7. Seleccione Subredes en Configuración.

8. Seleccione + Asociar.

9. En Asociar subred, escriba o seleccione la información siguiente:

Configuración Value

Virtual network Seleccione vnet-1 (test-rg).

Subnet Seleccione subnet-1.

10. Seleccione Aceptar.

Prueba del enrutamiento del tráfico de red

Pruebe el enrutamiento del tráfico de red de vm-public a vm-private. Prueba de
enrutamiento de la red tráfico de vm-private a vm-public.

Prueba del tráfico de red de vm-public a vm-private

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba
Máquina virtual. En los resultados de la búsqueda, seleccione Máquinas virtuales.

2. En Máquinas virtuales, seleccione vm-public.

3. Seleccione Bastion en la sección Operaciones.

4. Escriba el nombre de usuario y la contraseña que especificó al crear la máquina

virtual.

5. Seleccione Conectar.

6. En el símbolo del sistema, escriba el siguiente comando para realizar un

seguimiento del enrutamiento del tráfico de red de vm-public a vm-private:

Bash

tracepath vm-private

La respuesta es similar al siguiente ejemplo:

Resultados
 azureuser@vm-public:~$ tracepath vm-private
1?: [LOCALHOST] pmtu 1500
1: vm-nva.internal.cloudapp.net 1.766ms
1: vm-nva.internal.cloudapp.net 1.259ms
2: vm-private.internal.cloudapp.net 2.202ms
reached
Resume: pmtu 1500 hops 2 back 1

Puede ver que hay dos saltos en la respuesta anterior para el tráfico ICMP de
tracepath desde la máquina virtual vm-public a vm-private. El primer salto es vm-

nva. El segundo salto es vm-private de destino.

Azure envió el tráfico desde subnet-1 a través del NVA y no directamente a

subnet-private porque previamente ha añadido la ruta to-private-subnet a route-
table-public y lo asoció a subnet-1.

7. Cierre la sesión de Bastion.

Prueba del tráfico de red de vm-private a vm-public

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba
Máquina virtual. En los resultados de la búsqueda, seleccione Máquinas virtuales.

2. En Máquinas virtuales, seleccione vm-public.

3. Seleccione Bastion en la sección Operaciones.

4. Escriba el nombre de usuario y la contraseña que especificó al crear la máquina

virtual.

5. Seleccione Conectar.

6. En el símbolo del sistema, escriba el siguiente comando para realizar un

seguimiento del enrutamiento del tráfico de red de vm-private a vm-public:

Bash

tracepath vm-public

La respuesta es similar al siguiente ejemplo:

Resultados

azureuser@vm-private:~$ tracepath vm-public

1?: [LOCALHOST] pmtu 1500
 1: vm-public.internal.cloudapp.net 2.584ms
reached
1: vm-public.internal.cloudapp.net 2.147ms
reached
Resume: pmtu 1500 hops 1 back 2

Puede ver que hay un salto en la respuesta anterior, que es el destino de la

máquina virtual vm-public.

Azure envió el tráfico directamente desde la subred privada a la subred 1. De

forma predeterminada, Azure enruta el tráfico directamente entre subredes.

7. Cierre la sesión de Bastion.

Limpieza de recursos
Cuando haya terminado de utilizar los recursos creados, puede eliminar el grupo de
recursos y todos sus recursos.

1. En Azure Portal, busque y seleccione Grupos de recursos.

2. En la página Grupos de recursos, seleccione el grupo de recursos test-rg.

3. En la página test-rg, elija Eliminar grupo de recursos.

4. Escriba test-rg en Introducir nombre del grupo de recursos para confirmar la

eliminación y seleccione Eliminar.

Pasos siguientes
En este tutorial ha:

Creado una tabla de rutas y la ha asociado a una subred.

Creado una aplicación virtual de red sencilla que enrutó el tráfico desde una
subred pública hasta una subred privada.

Ahora puede implementar diferentes aplicaciones virtuales de red preconfiguradas

desde Azure Marketplace , que proporcionan muchas funciones de red útiles.

Para más información acerca del enrutamiento, consulte Introducción al enrutamiento y

Administración de una tabla de rutas.

Para aprender a restringir el acceso de red a los recursos de PaaS mediante puntos de
conexión de servicio de red virtual, avance al siguiente tutorial.
Restricción del acceso de red mediante puntos de conexión de servicio
Tutorial: Restricción del acceso de la red
a los recursos de PaaS mediante puntos
de conexión de servicio de red virtual
mediante Azure Portal.
Artículo • 11/08/2023

Los puntos de conexión de servicio de red virtual permiten que el acceso de la red a
algunos recursos de servicio de Azure esté restringido a una subred de la red virtual.
También se puede quitar el acceso de Internet a los recursos. Los puntos de conexión de
servicio proporcionan a la red virtual conexión directa con los servicios de Azure
compatibles, de modo que se puede usar el espacio de direcciones privadas de la red
virtual para acceder a los servicios de Azure. El tráfico destinado a los recursos de Azure
a través de los puntos de conexión de servicio siempre se mantiene en la red troncal de
Microsoft Azure.

En este tutorial, aprenderá a:

＂ Crear una red virtual con una subred

＂ Agregar una subred y habilitar un punto de conexión de servicio
＂ Crear un recurso de Azure y permitir que la red solo pueda acceder a él desde una
subred
＂ Implementar una máquina virtual en cada subred
＂ Confirmar el acceso a un recurso desde una subred
＂ Confirmar que se ha denegado el acceso a un recurso desde una subred e Internet

Este tutorial usa Azure Portal. También puede completarlo mediante la CLI de Azure o
PowerShell.

Prerrequisitos
Una cuenta de Azure con una suscripción activa. cree una de forma gratuita .

Inicio de sesión en Azure

Inicie sesión en Azure Portal .

Creación de una red virtual y un host bastión

El procedimiento siguiente crea una red virtual con una subred de recursos, una subred
de Azure Bastion y un host de Azure Bastion.

1. En el portal, busque y seleccione Redes virtuales.

2. En la página Redes virtuales, seleccione y Crear.

3. En la pestaña Datos básicos de Crear una red virtual, introduzca o seleccione la

siguiente información:

Configuración Valor

Detalles del proyecto

Suscripción Seleccione su suscripción.

Resource group Seleccione Crear nuevo.

Escriba test-rg en Nombre.
Seleccione
.

Detalles de instancia

Nombre Escriba vnet-1.

Region Seleccione Este de EE. UU. 2.

4. Seleccione Siguiente para continuar a la pestaña Seguridad.

5. Seleccione Habilitar Bastion en la sección Azure Bastion de la pestaña Seguridad.

Azure Bastion usa el explorador para conectarse a las máquinas virtuales de la red
virtual a través del shell seguro (SSH) o el protocolo de escritorio remoto (RDP)
mediante sus direcciones IP privadas. Las máquinas virtuales no necesitan
direcciones IP públicas, software cliente ni configuración especial. Para más
información sobre Azure Bastion, consulte Azure Bastion

７ Nota

Los precios por hora comienzan desde el momento en que se implementa

Bastion, independientemente del uso de datos salientes. Para más
información, consulte Precios y SKU. Si va a implementar Bastion como
parte de un tutorial o prueba, se recomienda eliminar este recurso una vez
que haya terminado de usarlo.

6. Escriba o seleccione la información siguiente en Azure Bastion:

 Configuración Valor

Nombre de host de Azure Bastion Escriba bastión.

Dirección IP pública de Azure Bastion Seleccione Crear una dirección IP pública.

Escriba public-ip-1 en Nombre.
Seleccione
.

7. Seleccione Siguiente para continuar a la pestaña Direcciones IP.

8. En el cuadro espacio de direcciones de Subredes, seleccione la subred

predeterminada.

9. En Agregar subred, escriba o seleccione la información siguiente:

 Configuración Valor

Detalles de subred

Plantilla de subred Deje el valor predeterminado.

Nombre Escriba subnet-1.

Dirección inicial Deje el valor predeterminado de 10.0.0.0.

Tamaño de la subred Deje el valor predeterminado de /24(256 direcciones).

10. Seleccione Guardar.

11. Seleccione Revisar y crear en la parte inferior de la pantalla y, cuando se supere la

validación, seleccione Crear.
Habilitación de un punto de conexión de
servicio
Los punto de conexión de servicio están habilitados por servicio, por subred.

1. En el cuadro de búsqueda de la parte superior de la página portal, escriba Red

virtual. En los resultados de la búsqueda, seleccione Redes virtuales.

2. En Redes virtuales, seleccione vnet-1.

3. En la sección Configuración de vnet-1, seleccione Subredes.

4. Seleccione +Subred.

5. En la página Agregar subred, escriba o seleccione la siguiente información:

Configuración Value

Nombre subnet-private

Intervalo de direcciones de subred Deje el valor predeterminado de 10.0.2.0/24.

PUNTOS DE CONEXIÓN DE SERVICIO

Servicios Seleccione Microsoft.Storage

6. Seleccione Guardar.

Ｕ Precaución

Antes de habilitar un punto de conexión de servicio para una subred existente que
tenga recursos, consulte Modificación de la configuración de subred.

Restricción del acceso de la red para una

subred
De forma predeterminada, todas las instancias de máquina virtual de una subred se
pueden comunicar con cualquier recurso. Puede limitar la comunicación hacia y desde
todos los recursos de una subred mediante la creación de un grupo de seguridad de red
y su asociación a la subred.

1. En el cuadro de búsqueda que aparece en la parte superior de la página del portal,

busque Grupo de seguridad de red. En los resultados de la búsqueda, seleccione
 Grupos de seguridad de red.

2. En Grupos de seguridad de red, seleccione + Crear.

3. En la pestaña Conceptos básicos de la opción Crear un grupo de seguridad de

red, escriba o seleccione la siguiente información:

Configuración Valor

Detalles del proyecto

Suscripción Seleccione su suscripción.

Resource group Seleccione test-rg.

Detalles de instancia

Nombre Escriba nsg-storage.

Region Seleccione Este de EE. UU. 2.

4. Seleccione Revisar y crear y, luego, Crear.

Creación de reglas de NSG de salida

1. En el cuadro de búsqueda que aparece en la parte superior de la página del portal,
busque Grupo de seguridad de red. En los resultados de la búsqueda, seleccione
Grupos de seguridad de red.

2. Seleccione nsg-storage.

3. En Configuración, seleccione Reglas de seguridad de salida.

4. Seleccione +Agregar.

5. Cree una regla que permita la comunicación saliente con el servicio Azure Storage.
En Agregar regla de seguridad de entrada, escriba o seleccione la siguiente
información:

Configuración Value

Source Seleccione Service Tag (Etiqueta de servicio).

Etiqueta de servicio de Seleccione VirtualNetwork.

origen

Source port ranges Deje el valor predeterminado, * .

Configuración Value

Destination Seleccione Service Tag (Etiqueta de servicio).

Etiqueta de servicio de Seleccione Storage.

destino

Servicio Deje el valor predeterminado de Personalizado.

Intervalos de puertos de Escriba 445. El protocolo SMB

destino se usa para la conexión a un recurso compartido de archivos
creado en un paso posterior.

Protocolo Seleccione Cualquiera.

Acción seleccione Permitir.

Priority Deje el valor predeterminado, 100.

Nombre Escriba allow-storage-all.

6. Seleccione +Agregar.

7. Cree otra regla de seguridad de salida que deniegue la comunicación a Internet.

Esta regla invalida una regla predeterminada en todos los grupos de seguridad de
red que permite la comunicación saliente de Internet. Complete los pasos
anteriores con los siguientes valores en Agregar regla de seguridad de salida:

Configuración Value

Source Seleccione Service Tag (Etiqueta de servicio).

Etiqueta de servicio de origen Seleccione VirtualNetwork.

Source port ranges Deje el valor predeterminado, * .

Destination Seleccione Service Tag (Etiqueta de servicio).

Etiqueta de servicio de destino seleccione Internet.

Servicio Deje el valor predeterminado de Personalizado.

Intervalos de puertos de destino Escriba *.

Protocolo Seleccione Cualquiera.

Acción Seleccione Denegar.

Priority Deje el valor predeterminado 110.

Nombre Escriba deny-internet-all.

 8. Seleccione Agregar.

Asocie el grupo de seguridad de red con una subred

1. En el cuadro de búsqueda que aparece en la parte superior de la página del portal,
busque Grupo de seguridad de red. En los resultados de la búsqueda, seleccione
Grupos de seguridad de red.

2. Seleccione nsg-storage.

3. Seleccione Subredes en Configuración.

4. Seleccione + Asociar.

5. En Asociar subred, seleccione vnet-1 en Red virtual. Seleccione subred-private en

Subred.

6. Seleccione Aceptar.

Restricción del acceso de la red a un recurso

Los pasos que deben seguirse para restringir el acceso de la red a los recursos creados a
través de los servicios de Azure, que se habilitan para los puntos de conexión del
servicio, varían de un servicio a otro. Consulte en la documentación de cada servicio
concreto los pasos necesarios para dicho servicio. Como ejemplo, de aquí en adelante
se explican los pasos necesarios para restringir el acceso de red en una cuenta de Azure
Storage.

Crear una cuenta de almacenamiento

Cree una cuenta de almacenamiento de Azure para los pasos descritos en este artículo.
Si ya tiene una cuenta de almacenamiento, puede usarla.

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba

Cuenta de almacenamiento. En los resultados de la búsqueda, seleccione Cuentas
de almacenamiento.

2. Seleccione + Create (+ Crear).

3. En la pestaña Aspectos básicos de la página Crear cuenta de almacenamiento,

escriba o seleccione la información siguiente:

Configuración Valor

Detalles del proyecto

Suscripción Seleccione su suscripción a Azure.

Grupo de recursos Seleccione test-rg.

Detalles de instancia

Nombre de la cuenta de Escriba storage1. Si el nombre no está disponible,

almacenamiento escriba un nombre único.

Location Seleccione (EE. UU.) Este de EE. UU. 2.

Rendimiento Deje el valor predeterminado Estándar.

Redundancia Seleccione Almacenamiento con redundancia local

(LRS) .

4. Seleccione Review (Revisar).

5. Seleccione Crear.

Creación de un recurso compartido de archivos en la

cuenta de almacenamiento
1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba
Cuenta de almacenamiento. En los resultados de la búsqueda, seleccione Cuentas
 de almacenamiento.

2. En Cuentas de almacenamiento, seleccione la cuenta de almacenamiento que creó

en el paso anterior.

3. En Almacenamiento de datos, seleccione Recursos compartidos de archivos.

4. Seleccione + Recurso compartido de archivos.

5. En Nuevo recurso compartido de archivos, escriba o seleccione la información

siguiente:

Configuración Value

Nombre Escriba file-share.

Nivel Deje el valor predeterminado de Optimizado para transacciones.

6. Seleccione Siguiente: Copia de seguridad.

7. Anule la selección de Habilitar copia de seguridad.

8. Seleccione Revisar y crear y, luego, Crear.

Restricción del acceso de la red a una subred

De forma predeterminada, las cuentas de almacenamiento aceptan conexiones de red
procedentes de clientes de cualquier red, incluido Internet. Puede restringir tanto el
acceso a la red desde Internet como a las demás subredes de todas las redes virtuales
(excepto a la subred subnet-private de la red virtual vnet-1).

Para restringir acceso de la red a una subred:

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba

Cuenta de almacenamiento. En los resultados de la búsqueda, seleccione Cuentas
de almacenamiento.

2. Seleccione la cuenta de almacenamiento.

3. En Seguridad y redes, seleccione Redes.

4. En la pestaña Firewalls y redes virtuales, en Habilitado desde redes virtuales y

direcciones IP seleccionadas en Acceso a la red pública.

5. En Redes virtuales, seleccione + Agregar red virtual existente.

6. En Agregar redes, escriba o seleccione la información siguiente:

 Configuración Valor

Suscripción Seleccione su suscripción.

Redes virtuales Seleccione vnet-1.

Subredes Seleccione subnet-private.

7. Seleccione Agregar.

8. Seleccione Guardar para guardar las configuraciones de la red virtual.

Creación de máquinas virtuales

Para probar el acceso de la red a una cuenta de almacenamiento, implemente una
máquina virtual en cada subred.

Creación de una máquina virtual de prueba

El procedimiento siguiente crea una máquina virtual (VM) de prueba denominada vm-1
en la red virtual.

1. En el portal, busque y seleccione Máquinas virtuales.

2. En Máquinas virtuales, seleccione + Crear y, después, Máquina virtual de Azure.

3. En la pestaña Datos básicos de Crear una máquina virtual, escriba o seleccione la

siguiente información:

Configuración Value

Detalles del proyecto

Suscripción Seleccione su suscripción.

Resource group Seleccione test-rg.

Detalles de instancia

Nombre de la máquina Escriba vm-1.

virtual

Region Seleccione Este de EE. UU. 2.

Opciones de disponibilidad Seleccione No se requiere redundancia de la

infraestructura.

Tipo de seguridad Deje el valor predeterminado Estándar.

Imagen Seleccione Windows Server 2022 Datacenter - x64 Gen2.

Arquitectura VM Deje el valor predeterminado, x64.

Size Seleccione un tamaño.

Cuenta de administrador

Tipo de autenticación Seleccione Contraseña.

Nombre de usuario escriba usuarioazure.

Contraseña Escriba una contraseña.

Confirmar contraseña Reescriba la contraseña.

 Configuración Value

Reglas de puerto de entrada

Puertos de entrada públicos Seleccione Ninguno.

4. Seleccione la pestaña Redes en la parte superior de la página.

5. En la pestaña Redes, escriba o seleccione la siguiente información:

Parámetro Value

Interfaz de red

Virtual network Seleccione vnet-1.

Subnet Seleccione subnet-1 (10.0.0.0/24).

Dirección IP pública Seleccione Ninguno.

Grupo de seguridad de red de NIC Seleccione Advanced (Avanzadas).

Configuración del grupo de Seleccione Crear nuevo.

seguridad de red Escriba nsg-1 como nombre.
Deje el resto de los valores predeterminados y
seleccione Aceptar.

6. Deje el resto de las opciones en sus valores predeterminados y luego seleccione

Revisar + crear.

7. Revise la configuración y seleccione Crear.

７ Nota

Las máquinas virtuales de una red virtual con un host bastión no necesitarán
direcciones IP públicas. Bastion proporcionará la dirección IP pública y las máquinas
virtuales usarán direcciones IP privadas para comunicarse dentro de la red. Es
posible quitar las direcciones IP públicas de cualquier máquina virtual en redes
virtuales hospedadas por Bastion. Para obtener más información, consulte
Desasociación de una dirección IP pública de una máquina virtual de Azure.

７ Nota

Azure proporciona una dirección IP de acceso de salida predeterminado para las

máquinas virtuales que no tienen asignada una dirección IP pública o que se
 encuentran en el grupo de back-end de una instancia de Azure Load Balancer del
nivel Básico interna. El mecanismo de dirección IP de acceso de salida
predeterminado proporciona una dirección IP de salida que no se puede
configurar.

La IP de acceso de salida predeterminada está deshabilitada cuando se asigna una

IP pública a la máquina virtual, la máquina virtual se coloca en el grupo de back-
end de un equilibrador de carga estándar (con o sin reglas de salida) o si se asigna
un recurso de puerta de enlace de Azure Virtual Network NAT a la subred de la
máquina virtual.

Las máquinas virtuales creadas por conjuntos de escalado de máquinas virtuales en

modo de orquestación flexible no tienen acceso de salida predeterminado.

Para obtener más información sobre las conexiones de salida en Azure, vea Acceso
de salida predeterminado y Uso de traducción de direcciones de red (SNAT) de
origen para conexiones de salida.

Creación de la segunda máquina virtual

1. Repita los pasos de la sección anterior para crear una segunda máquina virtual.
Reemplace los valores siguientes en Creación de una máquina virtual:

Configuración Valor

Nombre de la máquina virtual Escriba vm-private.

Subnet Seleccione subnet-private.

Dirección IP pública Seleccione Ninguno.

Grupo de seguridad de red de NIC Seleccione Ninguno.

２ Advertencia

No continúe con el paso siguiente hasta que la implementación haya

finalizado.

Confirmación del acceso a la cuenta de

almacenamiento
La máquina virtual que creó anteriormente que se asigna a la subred subnet-private se
usa para confirmar el acceso a la cuenta de almacenamiento. La máquina virtual que
creó en la sección anterior que se asigna a la subred subned-1 se usa para confirmar
que el acceso a la cuenta de almacenamiento está bloqueado.

Obtener clave de acceso de la cuenta de almacenamiento

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba
Cuenta de almacenamiento. En los resultados de la búsqueda, seleccione Cuentas
de almacenamiento.

2. En Cuentas de almacenamiento, seleccione la cuenta de almacenamiento.

3. En Seguridad y redes, seleccione Claves de acceso.

4. Copie el valor de key1. Es posible que tenga que seleccionar el botón Mostrar para
mostrar la clave.

5. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba

Máquina virtual. En los resultados de la búsqueda, seleccione Máquinas virtuales.

6. Seleccione vm-private.

7. Seleccione Bastion en Operaciones.

 8. Escriba el nombre de usuario y la contraseña que especificó al crear la máquina
virtual. Seleccione Conectar.

9. Abra Windows PowerShell. Use el siguiente script para asignar el recurso

compartido de archivos de Azure a la unidad Z.

Reemplace <storage-account-key> con el nombre de la clave que copió en el

paso anterior.

Reemplace <storage-account-name> por el nombre de la cuenta de

almacenamiento. En este ejemplo, es storage8675.

PowerShell

$key = @{
String = "<storage-account-key>"
}
$acctKey = ConvertTo-SecureString @key -AsPlainText -Force

$cred = @{
ArgumentList = "Azure\<storage-account-name>", $acctKey
}
$credential = New-Object System.Management.Automation.PSCredential
@cred

$map = @{
Name = "Z"
PSProvider = "FileSystem"
Root = "\\<storage-account-name>.file.core.windows.net\file-share"
Credential = $credential
}
New-PSDrive @map

PowerShell devuelve una salida similar a la del ejemplo siguiente:

Resultados

Name Used (GB) Free (GB) Provider Root

---- --------- --------- -------- ----
Z FileSystem
\\storage8675.file.core.windows.net\f...

El recurso compartido de archivos de Azure se ha asignado correctamente a la

unidad Z.

10. Cierre la conexión de Bastion a vm-private.

Confirmación de la denegación del acceso a la
cuenta de almacenamiento

De vm-1
1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba
Máquina virtual. En los resultados de la búsqueda, seleccione Máquinas virtuales.

2. Seleccione vm-1.

3. Seleccione Bastion en Operaciones.

4. Escriba el nombre de usuario y la contraseña que especificó al crear la máquina

virtual. Seleccione Conectar.

5. Repita el comando anterior para intentar asignar la unidad al recurso compartido

de archivos en la cuenta de almacenamiento. Es posible que tenga que volver a
copiar la clave de acceso de la cuenta de almacenamiento para este
procedimiento:

PowerShell

$key = @{
String = "<storage-account-key>"
}
$acctKey = ConvertTo-SecureString @key -AsPlainText -Force

$cred = @{
ArgumentList = "Azure\<storage-account-name>", $acctKey
}
$credential = New-Object System.Management.Automation.PSCredential
@cred

$map = @{
Name = "Z"
PSProvider = "FileSystem"
Root = "\\<storage-account-name>.file.core.windows.net\file-share"
Credential = $credential
}
New-PSDrive @map

6. Debería recibir el siguiente mensaje de error:

Resultados

New-PSDrive : Access is denied

At line:1 char:5
 + New-PSDrive @map
+ ~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Z:PSDriveInfo) [New-
PSDrive], Win32Exception
+ FullyQualifiedErrorId :
CouldNotMapNetworkDrive,Microsoft.PowerShell.Commands.NewPSDriveCommand

7. Cierre la conexión de Bastion a vm-1.

Desde una máquina local:

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba
Cuenta de almacenamiento. En los resultados de la búsqueda, seleccione Cuentas
de almacenamiento.

2. En Cuentas de almacenamiento, seleccione la cuenta de almacenamiento.

3. En Almacenamiento de datos, seleccione Recursos compartidos de archivos.

4. Seleccione file-share.

5. Seleccione Examinar en el menú de la izquierda.

6. Debería recibir el siguiente mensaje de error:

 ７ Nota

El acceso se deniega porque el equipo no se encuentra en la subred subnet-private

de la red virtual vnet-1.

Limpieza de recursos
Cuando haya terminado de utilizar los recursos creados, puede eliminar el grupo de
recursos y todos sus recursos.

1. En Azure Portal, busque y seleccione Grupos de recursos.

2. En la página Grupos de recursos, seleccione el grupo de recursos test-rg.

3. En la página test-rg, elija Eliminar grupo de recursos.

4. Escriba test-rg en Introducir nombre del grupo de recursos para confirmar la

eliminación y seleccione Eliminar.
Pasos siguientes
En este tutorial:

Ha habilitado un punto de conexión de servicio para una subred de red virtual.

Ha aprendido que puede habilitar puntos de conexión de servicio para los recursos
implementados desde varios servicios de Azure.

Ha creado una cuenta de Azure Storage y ha restringido el acceso de la red a la

cuenta de almacenamiento que se encuentra en una subred de la red virtual.

Para más información acerca de los puntos de conexión de servicio, consulte

Introducción a los puntos de conexión de un servicio y Administración de subredes.

Si tiene varias redes virtuales en su cuenta, puede establecer conectividad entre ellas
para que los recursos puedan comunicarse entre sí. Para aprender a conectar redes
virtuales, pase al siguiente tutorial.

Conexión de redes virtuales

Tutorial: Conexión de redes virtuales
con emparejamiento de redes virtuales
usando Azure Portal
Artículo • 23/10/2023

Puede conectar redes virtuales entre sí con el emparejamiento de redes virtuales. Estas
redes virtuales pueden estar en la misma región o en regiones diferentes (también
conocidas como emparejamiento de red virtual global). Una vez emparejadas las redes
virtuales, los recursos de ambas redes virtuales pueden comunicarse entre sí a través de
una conexión de ancho de banda alto y baja latencia mediante la red troncal de
Microsoft.

En este tutorial, aprenderá a:

＂ Creación de redes virtuales

＂ Conectar dos redes virtuales con el emparejamiento de redes virtuales
＂ Implementar una máquina virtual (VM) en cada red virtual
＂ Comunicarse entre máquinas virtuales

Requisitos previos
Una cuenta de Azure con una suscripción activa. También puede crear una cuenta
de forma gratuita .
Inicio de sesión en Azure
Inicie sesión en Azure Portal .

Creación de una red virtual y un host bastión

El procedimiento siguiente crea una red virtual con una subred de recursos, una subred
de Azure Bastion y un host de Azure Bastion.

1. En el portal, busque y seleccione Redes virtuales.

2. En la página Redes virtuales, seleccione y Crear.

3. En la pestaña Datos básicos de Crear una red virtual, introduzca o seleccione la

siguiente información:

Configuración Value

Detalles del proyecto

Subscription Seleccione su suscripción.

Resource group Seleccione Crear nuevo.

Escriba test-rg en Nombre.
Seleccione
.

Detalles de instancia

Nombre Escriba vnet-1.

Region Seleccione Este de EE. UU. 2.

4. Seleccione Siguiente para ir a la pestaña Seguridad.

5. Seleccione Habilitar Bastion en la sección Azure Bastion de la pestaña Seguridad.

Azure Bastion usa el explorador para conectarse a las máquinas virtuales de la red
virtual a través del shell seguro (SSH) o el protocolo de escritorio remoto (RDP)
mediante sus direcciones IP privadas. Las máquinas virtuales no necesitan
direcciones IP públicas, software cliente ni configuración especial. Para más
información sobre Azure Bastion, consulte Azure Bastion

７ Nota

Los precios por hora comienzan desde el momento en que se implementa

Bastion, independientemente del uso de datos salientes. Para más
información, consulte Precios y SKU. Si va a implementar Bastion como
parte de un tutorial o prueba, se recomienda eliminar este recurso una vez
que haya terminado de usarlo.

6. Escriba o seleccione la información siguiente en Azure Bastion:

 Configuración Valor

Nombre de host de Azure Bastion Escriba bastión.

Dirección IP pública de Azure Bastion Seleccione Crear una dirección IP pública.

Escriba public-ip-1 en Nombre.
Seleccione Aceptar.

7. Seleccione Siguiente para continuar a la pestaña Direcciones IP.

8. En el cuadro espacio de direcciones de Subredes, seleccione la subred

predeterminada.

9. En Agregar subred, escriba o seleccione la información siguiente:

 Configuración Valor

Detalles de subred

Plantilla de subred Deje el valor predeterminado.

Nombre Escriba subnet-1.

Dirección inicial Deje el valor predeterminado de 10.0.0.0.

Tamaño de la subred Deje el valor predeterminado de /24(256 direcciones).

10. Seleccione Guardar.

11. Seleccione Revisar y crear en la parte inferior de la pantalla y, cuando se supere la

validación, seleccione Crear.
Repita los pasos anteriores para crear una segunda red virtual con los valores siguientes:

７ Nota

La segunda red virtual puede estar en la misma región que la primera red virtual o
en otra región. Puede omitir la pestaña Seguridad y la implementación de Bastion
para la segunda red virtual. Después del par de red, puede conectarse a ambas
máquinas virtuales con la misma implementación de Bastion.

Configuración Value

Nombre vnet-2

Espacio de direcciones 10.1.0.0/16

Resource group test-rg

Nombre de subred subnet-1

Intervalo de direcciones de subred 10.1.0.0/24

Crear par de red virtual

Siga estos pasos para crear un par de red bidireccional entre vnet1 y vnet2.

1. En el cuadro de búsqueda de la parte superior del portal, escriba Red virtual. En

los resultados de la búsqueda, seleccione Redes virtuales.

2. Seleccione vnet-1.

3. En Configuración, seleccione Emparejamientos.

4. Seleccione +Agregar.

5. En Agregar emparejamiento, escriba o seleccione la información siguiente:

Configuración Valor

Esta red virtual

Nombre del vínculo de emparejamiento Escriba vnet-1-to-vnet-2.

Permitir que "vnet-1" acceda a "vnet-2" Deje el valor predeterminado de

seleccionado.
Configuración Valor

Permitir que "vnet-1" reciba tráfico reenviado de Seleccionar la casilla.

"vnet-2"

Permitir que la puerta de enlace de "vnet-1" Deje el valor predeterminado de

reenvíe el tráfico a "vnet-2" Desactivado.

Habilitar "vnet-1" para usar la puerta de enlace Deje el valor predeterminado de

remota "vnet-2" Desactivado.

Red virtual remota

Nombre del vínculo de emparejamiento Escriba vnet-2-to-vnet-1.

Modelo de implementación de red virtual Deje el valor predeterminado,

Administrador de recursos.

Suscripción Seleccione su suscripción.

Virtual network Seleccione vnet-2.

Permitir que "vnet-2" acceda a "vnet-1" Deje el valor predeterminado de

seleccionado.

Permitir que "vnet-2" reciba tráfico reenviado de Seleccionar la casilla.

"vnet-1"

Permitir que la puerta de enlace en "vnet-2" Deje el valor predeterminado de

reenvíe el tráfico a "vnet-1" Desactivado.

Habilitar "vnet-2" para usar la puerta de enlace Deje el valor predeterminado de

remota "vnet-1" Desactivado.
 6. Seleccione Agregar.

Creación de máquinas virtuales

Cree una máquina virtual en cada red virtual para probar la comunicación entre ellas.

Creación de una máquina virtual de prueba

El procedimiento siguiente crea una máquina virtual (VM) de prueba denominada vm-1
en la red virtual.
1. En el portal, busque y seleccione Máquinas virtuales.

2. En Máquinas virtuales, seleccione + Crear y, después, Máquina virtual de Azure.

3. En la pestaña Datos básicos de Crear una máquina virtual, escriba o seleccione la

siguiente información:

Configuración Value

Detalles del proyecto

Subscription Seleccione su suscripción.

Resource group Seleccione test-rg.

Detalles de instancia

Nombre de la máquina Escriba vm-1.

virtual

Region Seleccione Este de EE. UU. 2.

Opciones de disponibilidad Seleccione No se requiere redundancia de la

infraestructura.

Tipo de seguridad Deje el valor predeterminado Estándar.

Imagen Seleccione Ubuntu Server 22.04 LTS: x64 Gen2.

Arquitectura VM Deje el valor predeterminado, x64.

Size Seleccione un tamaño.

Cuenta de administrador

Tipo de autenticación Seleccione Contraseña.

Nombre de usuario escriba usuarioazure.

Contraseña Escriba una contraseña.

Confirmar contraseña Reescriba la contraseña.

Reglas de puerto de entrada

Puertos de entrada públicos Seleccione Ninguno.

4. Seleccione la pestaña Redes en la parte superior de la página.

5. En la pestaña Redes, escriba o seleccione la siguiente información:

 Parámetro Valor

Interfaz de red

Virtual network Seleccione vnet-1.

Subnet Seleccione subnet-1 (10.0.0.0/24).

Dirección IP pública Seleccione Ninguno.

Grupo de seguridad de red de NIC Seleccione Advanced (Avanzadas).

Configuración del grupo de Seleccione Crear nuevo.

seguridad de red Escriba nsg-1 como nombre.
Deje el resto de los valores predeterminados y
seleccione Aceptar.

6. Deje el resto de las opciones en sus valores predeterminados y luego seleccione

Revisar + crear.

7. Revise la configuración y seleccione Crear.

７ Nota

Las máquinas virtuales de una red virtual con un host bastión no necesitarán
direcciones IP públicas. Bastion proporcionará la dirección IP pública y las máquinas
virtuales usarán direcciones IP privadas para comunicarse dentro de la red. Es
posible quitar las direcciones IP públicas de cualquier máquina virtual en redes
virtuales hospedadas por Bastion. Para obtener más información, consulte
Desasociación de una dirección IP pública de una máquina virtual de Azure.

７ Nota

Azure proporciona una dirección IP de acceso de salida predeterminado para las

máquinas virtuales que no tienen asignada una dirección IP pública o que se
encuentran en el grupo de back-end de una instancia de Azure Load Balancer del
nivel Básico interna. El mecanismo de dirección IP de acceso de salida
predeterminado proporciona una dirección IP de salida que no se puede
configurar.

La dirección IP de acceso de salida predeterminada está deshabilitada cuando se

produce uno de los siguientes eventos:

Se asigna una dirección IP pública a la máquina virtual.

 La máquina virtual se coloca en el grupo de back-end de un equilibrador de
carga estándar con reglas de salida definidas.
Se asigna un recurso de puerta de enlace de Azure Virtual Network NAT a la
subred de la máquina virtual.

Las máquinas virtuales creadas mediante conjuntos de escalado de máquinas

virtuales en modo de orquestación flexible no tienen acceso de salida
predeterminado.

Para más información sobre las conexiones de salida en Azure, vea Acceso de
salida predeterminado en Azure y Uso de traducción de direcciones de red
(SNAT) de origen para conexiones de salida.

Repita los pasos anteriores para crear una segunda máquina virtual en la segunda red
virtual con los siguientes valores:

Configuración Value

Nombre de la máquina virtual vm-2

Region Este de EE. UU. 2 o la misma región que vnet-2.

Virtual network Seleccione vnet-2.

Subnet Seleccione subnet-1 (10.1.0.0/24).

Dirección IP pública Ninguna

Nombre del grupo de seguridad de red nsg-2

Espere a que se creen las máquinas virtuales antes de continuar con los pasos
siguientes.

Conexión a una máquina virtual

Use ping para probar la comunicación entre las máquinas virtuales.

1. En el portal, busque y seleccione Máquinas virtuales.

2. En la página Máquinas virtuales, seleccione vm-1.

3. En la Información generalde vm-1, seleccione Conectar.

4. En la página Conectar a la máquina virtual, seleccione la pestaña Bastion.

 5. Seleccione Usar Bastion.

6. Escriba el nombre de usuario y la contraseña que creó al crear la máquina virtual y,

a continuación, seleccione Conectar.

Comunicarse entre máquinas virtuales

1. En el símbolo del sistema de Bash para vm-1, escriba ping -c 4 vm-2 .

Recibirá una respuesta similar al siguiente mensaje:

Resultados

azureuser@vm-1:~$ ping -c 4 vm-2

PING vm-2.3bnkevn3313ujpr5l1kqop4n4d.cx.internal.cloudapp.net
(10.1.0.4) 56(84) bytes of data.
64 bytes from vm-2.internal.cloudapp.net (10.1.0.4): icmp_seq=1 ttl=64
time=1.83 ms
64 bytes from vm-2.internal.cloudapp.net (10.1.0.4): icmp_seq=2 ttl=64
time=0.987 ms
64 bytes from vm-2.internal.cloudapp.net (10.1.0.4): icmp_seq=3 ttl=64
time=0.864 ms
64 bytes from vm-2.internal.cloudapp.net (10.1.0.4): icmp_seq=4 ttl=64
time=0.890 ms

2. Cierre la conexión de Bastion a vm-1.

3. Repita los pasos descritos en Conectar a una máquina virtual para conectarse a
vm-2.

4. En el símbolo del sistema de Bash para vm-2, escriba ping -c 4 vm-1 .

Recibirá una respuesta similar al siguiente mensaje:

Resultados

azureuser@vm-2:~$ ping -c 4 vm-1

PING vm-1.3bnkevn3313ujpr5l1kqop4n4d.cx.internal.cloudapp.net
(10.0.0.4) 56(84) bytes of data.
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=1 ttl=64
time=0.695 ms
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=2 ttl=64
time=0.896 ms
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=3 ttl=64
time=3.43 ms
64 bytes from vm-1.internal.cloudapp.net (10.0.0.4): icmp_seq=4 ttl=64
time=0.780 ms
 5. Cierre la conexión de Bastion a vm-2.

Limpieza de recursos
Cuando haya terminado de utilizar los recursos creados, puede eliminar el grupo de
recursos y todos sus recursos.

1. En Azure Portal, busque y seleccione Grupos de recursos.

2. En la página Grupos de recursos, seleccione el grupo de recursos test-rg.

3. En la página test-rg, elija Eliminar grupo de recursos.

4. Escriba test-rg en Introducir nombre del grupo de recursos para confirmar la

eliminación y seleccione Eliminar.

Pasos siguientes
En este tutorial, hizo lo siguiente:

Creó un emparejamiento de redes virtuales entre dos redes virtuales.

Ha probado la comunicación entre dos máquinas virtuales a través del

emparejamiento de red virtual mediante ping .

Para más información acerca del emparejamiento de una red virtual:

Interconexión de red virtual

Conceptos y procedimientos
recomendados de Azure Virtual
Network
Artículo • 13/05/2023

En este artículo, se describen los conceptos clave y los procedimientos recomendados

de Azure Virtual Network.

Conceptos de redes virtuales

Espacio de direcciones: al crear una red virtual tiene que especificar un espacio de
direcciones IP privadas personalizado mediante direcciones públicas y privadas
(RFC 1918). Azure asigna a los recursos de una red virtual una dirección IP privada
desde el espacio de direcciones que asigne. Por ejemplo, si implementa una
máquina virtual en una red virtual con el espacio de direcciones, 10.0.0.0/16, la
máquina virtual se asignará a una dirección IP privada como 10.0.0.4.

Subredes: las subredes le permiten segmentar la red virtual en una o varias

subredes y asignar una parte del espacio de direcciones de la red virtual para cada
subred. A continuación, puede implementar los recursos de Azure en una subred
específica. Al igual que en una red tradicional, las subredes permiten segmentar el
espacio de direcciones de red virtual en segmentos que sean adecuados para la
red interna de la organización. La segmentación mejora la eficacia de la asignación
de direcciones. Puede proteger los recursos dentro de las subredes mediante
grupos de seguridad de red. Para más información, consulteGrupo de seguridad
de red.

Regiones: el ámbito de una red virtual es una sola región o ubicación; sin
embargo, se pueden conectar entre sí varias redes virtuales de diferentes regiones
mediante el emparejamiento de red virtual.

Suscripción: una red virtual tiene como ámbito una suscripción. Puede
implementar varias redes virtuales dentro de cada suscripción y región de Azure.

Procedimientos recomendados
Al crear la red en Azure, es importante tener en cuenta los siguientes principios
universales de diseño:
 Asegúrese de que los espacios de direcciones no se superpongan. Asegúrese de
que el espacio de direcciones de su red virtual (bloque CIDR) no se solape con
otros intervalos de red de su organización.

Las subredes no deberían cubrir el espacio de direcciones completo de la red

virtual. Planee con antelación y reserve algún espacio de direcciones para el futuro.

Se recomienda tener menos redes virtuales grandes en lugar de varias redes

virtuales pequeñas para evitar la sobrecarga de administración.

Asegure las redes virtuales mediante la asignación de grupos de seguridad de red

(NSG) a sus subredes. Para obtener más información sobre los conceptos de
seguridad de red, vea Introducción a la seguridad de red de Azure.

Pasos siguientes
Para empezar a usar una red virtual, créela, implemente en ella varias máquinas virtuales
y establezca comunicación entre las máquinas virtuales. Para aprender a hacerlo,
consulte la guía de inicio rápido Creación de una red virtual.
Virtual Network: continuidad del
negocio
Artículo • 27/03/2023

Información general
Una Virtual Network es una representación lógica de la red en la nube. Permite definir
su propio espacio de direcciones IP privadas y segmentar la red en subredes. Las redes
virtuales actúan como un límite de confianza para hospedar los recursos de proceso,
como Azure Virtual Machines y equilibradores de carga. Una red virtual permite la
comunicación IP privada directa entre los recursos hospedados en ella. Puede vincular
una red virtual a una red local mediante una instancia de VPN Gateway o por medio de
ExpressRoute.

Una red virtual se crea dentro del ámbito de una región. Puede crear redes virtuales con
el mismo espacio de direcciones en dos regiones diferentes, pero no se pueden
conectar entre sí porque tienen el mismo espacio de dirección.

Continuidad empresarial
La aplicación puede sufrir diferentes formas de interrupción. Por ejemplo, es posible que
el servicio se corte por completo en una región determinada como consecuencia de un
desastre natural o que se produzca un desastre parcial debido a un error en varios
dispositivos o servicios. El efecto en el servicio de red virtual es diferente en cada una de
estas situaciones.

P: ¿Qué se puede hacer si se produce una interrupción en una región entera? Por
ejemplo, ¿y si debido a un desastre natural el servicio se ha cortado por completo en
una región? ¿Qué ocurre con las redes virtuales hospedadas en la región?

A. La red virtual y los recursos de la región afectada permanecen inaccesibles durante el

tiempo que dure la interrupción del servicio.
P: ¿Qué se puede hacer para volver a crear la misma red virtual en una región
distinta?

A. Las redes virtuales son recursos bastante ligeros. Puede invocar las API de Azure para
crear una red virtual con el mismo espacio de direcciones en una región distinta. Para
volver a crear el mismo entorno que estaba presente en la región afectada, vuelva a
implementar las máquinas virtuales y otros recursos. Si tiene conectividad local, como
una implementación híbrida, tendrá que implementar una nueva instancia de VPN
Gateway y conectarse a su red local.

Para crear una red virtual, consulte Creación de una red virtual.

P: ¿Es posible volver a crear una réplica de una red virtual de una región determinada
en otra región de antemano?

R: Sí, puede crear dos redes virtuales con el mismo espacio de direcciones IP privadas y
los recursos en dos regiones diferentes de antemano. Si hospedaba servicios orientados
a Internet en la red virtual, podría haber configurado Traffic Manager para distribuir
geográficamente el tráfico en la región que está activa. Sin embargo, dos redes virtuales
que tengan el mismo espacio de direcciones no se pueden conectar con la red local, ya
que se producirían problemas de enrutamiento. Si se produjera un desastre y la pérdida
de una red virtual en una región, podría conectar la otra red virtual en la región
disponible, con el espacio de direcciones coincidente con la red local.

Para crear una red virtual, consulte Creación de una red virtual.
Enrutamiento del tráfico de redes
virtuales
Artículo • 29/05/2023

Aprenda la forma en que Azure enruta el tráfico entre los recursos locales y de Internet
de Azure. Azure crea automáticamente una tabla de rutas para cada subred de una red
virtual de Azure y agrega las rutas predeterminadas del sistema a la tabla. Para más
información acerca de las redes y subredes virtuales, consulte Red virtual. Puede
reemplazar algunas de las rutas del sistema de Azure por rutas personalizadas y agregar
más rutas personalizadas a las tablas de rutas. Azure enruta el tráfico saliente desde una
subred en función de las rutas de la tabla de rutas de una subred.

Rutas del sistema

Azure crea automáticamente rutas del sistema y las asigna a todas las subredes de una
red virtual. No puede crear ni eliminar rutas del sistema, pero puede reemplazar algunas
de ellas por rutas personalizadas. Azure crea rutas del sistema predeterminadas para
cada subred y agrega más rutas predeterminadas opcionales a determinadas subredes,
o a todas las subredes, al usar funcionalidades específicas de Azure.

Valor predeterminado
Cada ruta contiene un prefijo de dirección y el tipo de próximo salto. Cuando el tráfico
que sale de una subred se envía a una dirección IP que está dentro del prefijo de la
dirección de ruta, la ruta que contiene el prefijo es la que utiliza Azure. Obtenga más
información acerca de la selección de rutas por parte de Azure cuando varias rutas
contienen los mismos prefijos o cuando los prefijos se solapan. Cuando se crea una red
virtual, Azure crea automáticamente los siguientes rutas del sistema predeterminadas
para cada subred de la red virtual:

Source Prefijos de dirección Tipo de próximo salto

Valor predeterminado Único para la red virtual Virtual network

Valor predeterminado 0.0.0.0/0 Internet

Valor predeterminado 10.0.0.0/8 None

Valor predeterminado 172.16.0.0/12 Ninguno

Valor predeterminado 192.168.0.0/16 None

 Source Prefijos de dirección Tipo de próximo salto

Valor predeterminado 100.64.0.0/10 None

Los tipos de próximo salto enumerados en la tabla anterior representan la forma en que
Azure enruta el tráfico destinado al prefijo de dirección enumerado. Estas son las
explicaciones de los tipos de próximo salto:

Red virtual: enruta el tráfico entre los intervalos de direcciones del espacio de
direcciones de una red virtual. Azure crea una ruta con un prefijo de dirección que
corresponde a cada intervalo de direcciones definido en el espacio de direcciones
de una red virtual. Si el espacio de direcciones de la red virtual tiene varios
intervalos de direcciones definidos, Azure crea una ruta individual para cada
intervalo de direcciones. Azure automáticamente enruta el tráfico entre subredes
mediante las rutas que se crea para cada intervalo de direcciones. No es preciso
definir las puertas de enlace de Azure para enrutar el tráfico entre subredes.
Aunque una red virtual contiene subredes y cada una de ellas tiene un intervalo de
direcciones definido, Azure no crea rutas predeterminadas para los intervalos de
direcciones de subred. Cada intervalo de direcciones de subred está dentro de un
intervalo de direcciones del espacio de direcciones de una red virtual.

Internet: enruta a Internet el tráfico que especifica el prefijo de dirección. La ruta

predeterminada del sistema especifica el prefijo de dirección 0.0.0.0/0. Si no se
invalidan las rutas predeterminadas de Azure, Azure enruta a Internet el tráfico de
todas las direcciones que no se hayan especificado en un intervalo de direcciones
dentro de una red virtual. Hay una excepción a este enrutamiento. Si la dirección
de destino es para uno de los servicios de Azure, este enruta el tráfico
directamente al servicio a través de la red troncal de Azure, en lugar de enrutarlo a
Internet. El tráfico entre los servicios de Azure no atraviesa Internet,
independientemente de la región de Azure en que exista la red virtual o de la
región de Azure en que se implemente una instancia del servicio de Azure. Puede
reemplazar la ruta del sistema predeterminada de Azure predeterminado para el
prefijo de dirección 0.0.0.0/0 por un ruta personalizada.

Ninguna: el tráfico que se enruta al tipo de próximo salto Ninguno se elimina, en

lugar de enrutarlo fuera de la subred. Azure crea automáticamente las rutas
predeterminadas para los siguientes prefijos de dirección:

10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16: reservadas para el uso privado en el

RFC 1918.

100.64.0.0/10: reservada en RFC 6598.

 Si asigna cualquiera de los intervalos de direcciones anteriores del espacio de
direcciones de una red virtual, Azure cambia automáticamente el tipo de próximo
salto de la ruta de No a Red virtual. Si asigna un intervalo de direcciones al
espacio de direcciones de una red virtual que incluya uno de los cuatro prefijos de
direcciones reservadas, pero no es lo mismo que ellas, Azure quita la ruta del
prefijo y agrega una ruta para el prefijo de dirección que agregó, con Virtual red
como el tipo de próximo salto.

Rutas predeterminadas opcionales

Azure agrega más rutas del sistema predeterminadas para diferentes funcionalidades de
Azure, pero solo si se habilitan las funcionalidades. En función de la funcionalidad, Azure
agrega las rutas predeterminadas opcionales a subredes concretas de la red virtual o a
todas las subredes de una red virtual. Las otras rutas del sistema y tipos de próximo
salto que Azure puede agregar al habilitar diferentes funcionalidades son los siguientes:

Source Prefijos de dirección Tipo de próximo salto La

subred
de red
virtual a
la que
se
agrega
la ruta

Valor Único para la red virtual, por Emparejamiento de VNET All

predeterminado ejemplo: 10.1.0.0/16

Puerta de Prefijos anunciados desde el Puerta de enlace de red virtual All

enlace de red entorno local a través de BGP, o
virtual bien configurados en la puerta de
enlace de red local

Valor Múltiple VirtualNetworkServiceEndpoint Solo la

predeterminado subred
para la
que se
habilita
un
punto
de
conexión
de
servicio.
Emparejamiento de red virtual (VNet): al crear un emparejamiento de red virtual
entre dos redes virtuales, el sistema agrega una ruta para cada intervalo de
direcciones en el espacio de direcciones de cada red virtual para la que se crea un
emparejamiento. Más información acerca del emparejamiento de red virtual.

Puerta de enlace de red virtual: cuando una puerta de enlace de red virtual se
agrega a una red virtual, se agregan también una o varias rutas en las que Puerta
de enlace de red virtual aparece como el tipo de próximo salto. El origen es
también una puerta de enlace de red virtual, ya que la puerta de enlace agrega las
rutas a la subred. Si la puerta de enlace de red local intercambia las rutas del
protocolo de puerta de enlace de borde (BGP) con una puerta de enlace de red
virtual, el sistema agrega una ruta por cada ruta. Estas rutas se propagan desde la
puerta de enlace de red local. Se recomienda resumir las rutas locales para los
intervalos de direcciones más grandes posibles, con el fin de que se propague el
menor número de rutas a una puerta de enlace de red virtual de Azure. Hay límites
en el número de rutas que se pueden propagar a una puerta de enlace de red
virtual de Azure. Para más información, consulte el artículo acerca de los límites de
Azure.

VirtualNetworkServiceEndpoint: Azure agrega las direcciones IP públicas de

determinados servicios a la tabla de rutas cuando se habilita un punto de conexión
para el servicio. Los puntos de conexión de servicio se habilitan para las subredes
individuales de una red virtual, por lo que la ruta solo se agrega a la tabla de rutas
de una subred para la que haya algún punto de conexión de servicio habilitado.
Las direcciones IP públicas de los servicios de Azure cambian periódicamente.
Azure administra automáticamente las direcciones en la tabla de rutas cuando
cambian. Obtenga más información acerca de los puntos de conexión de servicio
de red virtual y los servicios para los que se pueden crear puntos de conexión de
servicio.

７ Nota

El tipos de próximo salto Emparejamiento de VNet y

VirtualNetworkServiceEndpoint solo se agregan a las tablas de rutas de las
subredes de las redes virtuales creadas a través del modelo de
implementación de Azure Resource Manager. Los tipos de próximo salto no
se agregan a las tablas de rutas asociadas a las subredes de red virtual
creadas mediante el modelo de implementación clásica. Obtenga más
información acerca de los modelos de implementación de Azure.
Rutas personalizadas
Para crear rutas personalizadas, cree rutas definidas por el usuario o intercambie rutas
del protocolo Border Gateway Protocol (BGP) entre su puerta de enlace de red local y
una puerta de enlace de red virtual de Azure.

Definidas por el usuario

En Azure se pueden crear rutas personalizadas o definidas por el usuario (estáticas) para
reemplazar las rutas del sistema predeterminadas de Azure o para agregar rutas
adicionales a una tabla de rutas de la subred. En Azure, cree una tabla de rutas y
asóciela a cero o más subredes de red virtual. Cada subred puede tener cero o una ruta
de tablas de ruta asociada. Para obtener información acerca del número máximo de
rutas que puede agregar a una tabla de rutas y del número máximo de tablas de rutas
definidas por el usuario que se pueden crear por suscripción de Azure, consulte el
artículo acerca de los límites de Azure. Si crea una tabla de rutas y la asocia a una
subred, las rutas de la tabla se combinan con las rutas predeterminadas de la subred. Si
hay asignaciones de rutas en conflicto, las rutas definidas por el usuario invalidarán las
rutas predeterminadas.

Puede especificar los siguientes tipos de próximo salto al crear una ruta definida por el
usuario:

Aplicación virtual: una aplicación virtual es una máquina virtual que ejecuta
normalmente una aplicación de red como, por ejemplo, un firewall. Para más
información sobre las aplicaciones virtuales de red preconfiguradas que se pueden
implementar en una red virtual, visite Azure Marketplace . Al crear una ruta con el
tipo de salto de aplicación virtual, especifique también una dirección IP del
próximo salto. La dirección IP puede ser:

La dirección IP privada de una interfaz de red conectada a una máquina virtual.

Cualquier interfaz de red conectada a una máquina virtual que reenvíe el tráfico
de red a una dirección que no sea la suya propia debe tener la opción Habilitar
reenvío de IP habilitada. El valor deshabilita la comprobación que realiza Azure
del origen y destino en una interfaz de red. Obtenga más información acerca de
cómo habilitar el reenvío IP en una interfaz de red. Aunque Habilitar reenvío de
IP es un valor de Azure, es posible que también necesite habilitar el reenvío IP
en el sistema operativo de la máquina virtual para que el dispositivo desvíe el
tráfico entre las direcciones IP privadas asignadas a interfaces de red de Azure.
Si el dispositivo necesita enrutar el tráfico a una dirección IP pública, debe
redirigir mediante proxy el tráfico o realizar la traducción de direcciones de red
 (NAT) desde la dirección IP privada del origen hasta su propia dirección IP
privada. Después, Azure realiza la NAT en una dirección IP pública antes de
enviar el tráfico a Internet. Para determinar la configuración necesaria en la
máquina virtual, consulte la documentación del sistema operativo o la
aplicación de red. Para obtener información acerca de las conexiones salientes
en Azure, consulte Información acerca de las conexiones salientes.

７ Nota

Implemente una aplicación virtual en una subred diferente la que se

encuentran los recursos que enrutan a través de la aplicación virtual. La
implementación de la aplicación virtual en la misma subred y la posterior
aplicación de una tabla de rutas en la subred que enruta el tráfico a través
de la aplicación virtual pueden provocar bucles de enrutamiento, en los
que el tráfico nunca sale de la subred.

Una dirección IP privada del próximo salto debe tener conexión directa sin
tener que enrutar a través de la puerta de enlace de ExpressRoute o Virtual
WAN. Al establecer el próximo salto en una dirección IP sin conexión
directa, resulta en una configuración de enrutamiento definida por el
usuario no válida.

La dirección IP privada de un equilibrador de carga interno de Azure. A menudo

se usa un equilibrador de carga como parte de una estrategia de alta
disponibilidad para aplicaciones virtuales de red.

Puede definir una ruta usando 0.0.0.0/0 como prefijo de la dirección y un tipo de
próximo salto de aplicación virtual. Esta configuración permite al dispositivo
inspeccionar el tráfico y determinar si se reenvía o se anula el tráfico. Si tiene
intención de crear una definida por el usuario que contenga el prefijo de dirección
0.0.0.0/0, consulte antes el apartado 0.0.0.0/0 address prefix (Prefijo de dirección
0.0.0.0/0).

Puerta de enlace de red virtual: se especifica cuando se desea que el tráfico

destinado a prefijos de dirección específicos se enrute a una puerta de enlace de
red virtual. La puerta de enlace de red virtual debe crearse con el tipo VPN. No se
puede especificar una puerta de enlace de red virtual creada con el tipo
ExpressRoute en una ruta definida por el usuario, ya que con ExpressRoute es
preciso usar BGP para las rutas personalizadas. Tampoco puede especificar puertas
de red virtuales si tiene conexiones VPN y ExpressRoute coexistentes. Puede definir
una ruta que dirige el tráfico destinado al prefijo de dirección 0.0.0.0/0 a una
 puerta de enlace de red virtual basada en ruta. En un entorno local, puede tener un
dispositivo que compruebe el tráfico y determine si se reenvía o se elimina. Si tiene
intención de crear una definida por el usuario para el prefijo de dirección 0.0.0.0/0,
consulte antes el apartado 0.0.0.0/0 address prefix (Prefijo de dirección 0.0.0.0/0).
En lugar de configurar una ruta definida por el usuario para el prefijo de dirección
0.0.0.0/0, es posible anunciar una ruta con el prefijo 0.0.0.0/0 a través de BGP, si ha
habilitado BGP para una puerta de enlace de red virtual de VPN.

Ninguna: se especifica cuando se desea colocar tráfico en un prefijo de dirección,

en lugar de reenviar el tráfico a un destino. Si no ha configurado completamente
una funcionalidad, Azure puede enumerar No para algunas de las rutas de
opcional del sistema. Por ejemplo, si ve No en Dirección IP del próximo salto con
un Tipo de próximo salto de Puerta de enlace de red virtual o Aplicación virtual,
puede deberse a que el dispositivo no funciona o no está completamente
configurado. Azure crea rutas predeterminadas del sistema para los prefijos de
direcciones reservados con No como tipo de próximo salto.

Red virtual: especifique la opción de red virtual si desea reemplazar el

enrutamiento predeterminado en una red virtual. Consulte Ejemplo de
enrutamiento, para ver un ejemplo de por qué puede crear una ruta con el tipo de
salto Red virtual.

Internet: especifique la opción de Internet si desea enrutar explícitamente el

tráfico destinado a un prefijo de dirección a Internet o si desea que el tráfico
destinado a los servicios de Azure con direcciones IP públicas se conserve dentro
de la red troncal de Azure.

En las rutas definidas por el usuario, no se puede especificar emparejamiento de red

virtual o VirtualNetworkServiceEndpoint como tipo de próximo salto. Las rutas con los
tipos de próximo salto emparejamiento de red virtual o
VirtualNetworkServiceEndpoint solo las crea Azure al configurar un emparejamiento de
red virtual o un punto de conexión de servicio.

Etiquetas de servicio para rutas definidas por el usuario

Ahora puede especificar una etiqueta de servicio como prefijo de dirección de una ruta
definida por el usuario en lugar de un intervalo IP explícito. Una etiqueta de servicio
representa un grupo de prefijos de direcciones IP de un servicio de Azure determinado.
Microsoft administra los prefijos de direcciones que la etiqueta de servicio incluye y
actualiza automáticamente dicha etiqueta a medida que las direcciones cambian. Así se
minimiza la complejidad de las actualizaciones frecuentes de las rutas definidas por el
usuario y se reduce el número de rutas que hay que crear. Actualmente, puede crear
hasta 25 rutas con etiquetas de servicio en cada tabla de rutas. Con esta versión,
también se admite el uso de etiquetas de servicio en escenarios de enrutamiento para
contenedores.

Coincidencia exacta
El sistema da preferencia a la ruta con el prefijo explícito cuando hay una coincidencia
exacta de prefijo entre una ruta con un prefijo de IP explícito y una ruta con una
etiqueta de servicio. Cuando varias rutas con etiquetas de servicio tienen prefijos de IP
que coinciden, las rutas se evalúan en el orden siguiente:

1. Etiquetas regionales (por ejemplo, Storage.EastUS, AppService.AustraliaCentral)

2. Etiquetas de nivel superior (por ejemplo, Storage, AppService)

3. Etiquetas regionales de AzureCloud (por ejemplo, AzureCloud.canadacentral,

AzureCloud.eastasia)

4. La etiqueta de AzureCloud

Para usar esta característica, especifique un nombre de etiqueta de servicio para el

parámetro de prefijo de dirección en los comandos de la tabla de rutas. Por ejemplo, en
PowerShell puede crear una ruta para dirigir el tráfico enviado a un prefijo de IP de
Azure Storage a un dispositivo virtual usando:

Azure PowerShell

$param = @{
Name = 'StorageRoute'
AddressPrefix = 'Storage'
NextHopType = 'VirtualAppliance'
NextHopIpAddress = '10.0.100.4'
}
New-AzRouteConfig @param

El mismo comando para la CLI es el siguiente:

Azure CLI

az network route-table route create \

--resource-group MyResourceGroup \
--route-table-name MyRouteTable \
--name StorageRoute \
--address-prefix Storage \
 --next-hop-type VirtualAppliance \
--next-hop-ip-address 10.0.100.4

Tipos de próximo salto en las herramientas de

Azure
El nombre que se muestra y al que hace referencia en los tipos de próximo salto es
diferente entre Azure Portal y las herramientas de línea de comandos y los modelos de
implementación clásico y mediante Azure Resource Manager. En la siguiente tabla se
enumeran los nombres que se usan para hacer referencia a cada tipo de próximo salto
con las diferentes herramientas y los modelos de implementación:

Tipo de próximo CLI de Azure y PowerShell CLI clásica de Azure y PowerShell

salto (Resource Manager) (clásico)

Puerta de enlace de VirtualNetworkGateway VPNGateway

red virtual

Virtual network VNetLocal VNETLocal (no disponible en la CLI

clásica en modo de administración de
servicios)

Internet Internet Internet (no disponible en la CLI

clásica en modo de administración de
servicios)

Aplicación virtual VirtualAppliance VirtualAppliance

None None Nulo (no disponible en la CLI clásica

en modo de administración de
servicios)

Emparejamiento de Emparejamiento de VNET No aplicable

redes virtuales de
Azure

Puntos de conexión de VirtualNetworkServiceEndpoint No aplicable

servicio de red virtual

Border Gateway Protocol

Una puerta de enlace de red local puede intercambiar rutas con una puerta de enlace de
red virtual de Azure mediante el protocolo Border Gateway Protocol (BGP). El uso del
BGP con una puerta de enlace de red virtual de Azure depende del tipo seleccionado al
crear la puerta de enlace:
 ExpressRoute: debe usar BGP para anunciar rutas locales para el enrutador de
Microsoft Edge. No puede crear rutas definidas por el usuario para forzar el tráfico
hacia la puerta de enlace de red virtual de ExpressRoute si implementa una puerta
de enlace de red virtual con el tipo: ExpressRoute. Puede usar las rutas definidas
por el usuario para forzar el tráfico de Express Route a, por ejemplo, una aplicación
virtual de red.

VPN: opcionalmente, puede usar BGP. Para más información, consulte Información
general de BGP con puertas de enlace de VPN de Azure.

Al intercambiar rutas con Azure mediante BGP, se agrega una ruta independiente a la
tabla de rutas de todas las subredes de una red virtual para cada prefijo anunciado. La
ruta se agrega con Puerta de enlace de red virtual como origen y tipo de próximo salto.

La propagación del enrutamiento de ER y VPN Gateway se puede deshabilitar en una

subred mediante una propiedad en una tabla de rutas. Al deshabilitar la propagación de
rutas, el sistema no agrega rutas a la tabla de rutas de todas las subredes que tengan la
propagación de rutas de puerta de enlace de red virtual deshabilitada. Este proceso se
aplica tanto a rutas estáticas como a rutas de BGP. La conectividad con las conexiones
VPN se logra mediante rutas personalizadas con un próximo salto de tipo Puerta de
enlace de red virtual. La propagación de rutas no debe deshabilitarse en
GatewaySubnet. La puerta de enlace no funcionará con este parámetro deshabilitado.
Para más información, consulte How to disable Virtual network gateway route
propagation (Deshabilitar la propagación de rutas de la puerta de enlace de red virtual).

Selección de rutas por parte de Azure

Cuando se envía tráfico saliente desde una subred, Azure selecciona una ruta en función
de la dirección IP de destino y se usa el algoritmo de coincidencia de prefijo más largo.
Por ejemplo, una tabla de rutas tiene dos rutas: una ruta especifica el prefijo de
dirección 10.0.0.0/24, mientras que la otra ruta especifica el prefijo de dirección
10.0.0.0/16. Azure dirige el tráfico destinado a 10.0.0.5 al tipo de próximo salto
especificado en la ruta con el prefijo de dirección 10.0.0.0/24. Este proceso se produce
porque 10.0.0.0/24 es un prefijo más largo que 10.0.0.0/16, aunque 10.0.0.5 se
encuentre dentro de ambos prefijos de dirección. Azure dirige el tráfico destinado a
10.0.1.5 al tipo de próximo salto especificado en la ruta con el prefijo de dirección
10.0.0.0/16. Este proceso se produce porque 10.0.1.5 no se incluye en el prefijo de
dirección 10.0.0.0/24, lo que hace que la ruta con el prefijo de dirección 10.0.0.0/16 sea
el prefijo con coincidencia más larga.

Si varias rutas contienen el mismo prefijo de dirección, Azure selecciona el tipo de ruta,
en función de la siguiente prioridad:
 1. Ruta definida por el usuario

2. Ruta BGP

3. Ruta del sistema

７ Nota

Las rutas de sistema para el tráfico relacionado con la red virtual, los
emparejamientos de la red virtual o los puntos de conexión de servicio de red
virtual son las rutas preferidas, aunque las rutas BGP sean más específicas.

Por ejemplo, una tabla de rutas contiene las rutas siguientes:

Source Prefijos de dirección Tipo de próximo salto

Valor predeterminado 0.0.0.0/0 Internet

Usuario 0.0.0.0/0 Puerta de enlace de red virtual

Cuando el destino del tráfico es una dirección IP que está fuera de los prefijos de
dirección de las otras rutas de la tabla de rutas, Azure selecciona la ruta con el origen
Usuario, porque las rutas definidas por el usuario tienen mayor prioridad que las rutas
predeterminadas del sistema.

Para ver una tabla de enrutamiento completa con explicaciones de las rutas, consulte el
ejemplo de enrutamiento.

Prefijo de dirección 0.0.0.0/0

Una ruta con el prefijo de dirección 0.0.0.0/0 proporciona instrucciones a Azure. Azure
usa estas instrucciones para enrutar el tráfico destinado a una dirección IP que no está
dentro del prefijo de dirección de ninguna otra ruta en una tabla de rutas de una
subred. Cuando se crea una subred, Azure crea un ruta predeterminada para el prefijo
de dirección 0.0.0.0/0, con el tipo de próximo salto Internet. Si no reemplaza esta ruta,
Azure enruta a Internet todo el tráfico destinado a direcciones IP no incluidas en el
prefijo de dirección de otra ruta. La excepción es que el tráfico dirigido a las direcciones
IP públicas de los servicios de Azure permanece en la red troncal de Azure y no se
enruta a Internet. Al invalidar esta ruta con una ruta personalizada, se dirige el tráfico
destinado a direcciones que no están dentro de los prefijos de dirección de cualquier
otra ruta de la tabla de rutas. El destino depende de si especifica una aplicación virtual
de red o una puerta de enlace de red virtual en la ruta personalizada.
Si se reemplaza el prefijo de dirección 0.0.0.0/0, además del tráfico de salida de la
subred que fluye a través de la puerta de enlace de red virtual o de la aplicación virtual,
se producen también los siguientes cambios en el enrutamiento predeterminado de
Azure:

Azure envía todo el tráfico al tipo de próximo salto especificado en la ruta, lo que
incluye el tráfico destinado a las direcciones IP públicas de los servicios de Azure.
Cuando el tipo de próximo salto de la ruta con el prefijo de dirección 0.0.0.0/0 es
Internet, el tráfico de la subred destinado a las direcciones IP públicas de los
servicios de Azure no sale de la red troncal de Azure, independientemente de la
región de Azure en que existan la red virtual o un recurso de servicio de Azure. Sin
embargo, cuando se crea una ruta BGP o definida por el usuario con un tipo de
próximo salto de puerta de enlace de red virtual o aplicación virtual, todo el
tráfico, lo que incluye el tráfico enviado a las direcciones IP públicas de los
servicios de Azure en el que no se hayan habilitado puntos de conexión de
servicio, se envía al tipo de próximo salto especificado en la ruta. Al habilitar un
punto de conexión de servicio para un servicio, Azure crea una ruta con prefijos de
dirección para el servicio. El tráfico al servicio no enruta al tipo de próximo salto en
una ruta con el prefijo de dirección 0.0.0.0/0. Los prefijos de dirección para el
servicio son más largos que 0.0.0.0/0.

Ya no se puede acceder directamente a los recursos de la subred desde Internet.

Puede acceder a los recursos de la subred desde Internet indirectamente. El
dispositivo especificado por el tipo de próximo salto para una ruta con el prefijo
de dirección 0.0.0.0/0 debe procesar el tráfico entrante. Una vez que el tráfico
atraviesa el dispositivo, el tráfico llega al recurso de la red virtual. Si la ruta
contiene los siguientes valores del tipo de salto próximo:

Aplicación virtual: la aplicación debe:

Ser accesible desde Internet.

Tener una dirección IP pública asignada.

No tener una regla del grupo de seguridad de red asociada a él que impide
la comunicación con el dispositivo.

No denegar la comunicación.

Poder traducir y reenviar direcciones de red, o desviar el tráfico a través de

un servidor proxy al recurso de destino de la subred y devolver el tráfico a
Internet.
 Puerta de enlace de red virtual: si la puerta de enlace es una puerta de enlace
de red virtual ExpressRoute, un dispositivo local conectado a Internet puede
traducir y reenviar direcciones de red, o bien desviar el tráfico a través de un
servidor proxy al recurso de destino de la subred mediante emparejamiento
privado de ExpressRoute.

Si la red virtual está conectada a una instancia de Azure VPN Gateway, no asocie una
tabla de rutas a la subred de puerta de enlace que incluya una ruta con un destino
0.0.0.0/0. Si lo hace, puede que la puerta de enlace no funcione correctamente. Para más
información, consulte la pregunta ¿Por qué hay algunos puertos abiertos en mi puerta de
enlace de VPN? en las Preguntas más frecuentes sobre VPN Gateway.

Para obtener información sobre la implementación al usar puertas de enlace de redes

virtuales entre Internet y Azure, consulte Red perimetral entre Azure y un centro de
datos local.

Ejemplo de enrutamiento
Para ilustrar los conceptos de este artículo, en las siguientes secciones se describen:

Un escenario con requisitos.

Las rutas personalizadas necesarias para cumplir los requisitos.

La tabla de rutas que existe para una subred que incluye las rutas predeterminadas
y personalizadas necesarias para cumplir los requisitos.

７ Nota

Este ejemplo no pretende ser una implementación aconsejable ni unos

procedimientos recomendados. Más bien se proporciona únicamente para ilustrar
los conceptos de este artículo.

Requisitos
1. Implementar dos redes virtuales en la misma región de Azure y habilitar los
recursos necesarios para la comunicación entre las redes virtuales.

2. Habilitar una red local para comunicarse de forma segura con ambas redes
virtuales mediante un túnel VPN a través de Internet. Como alternativa, puede
utilizarse una conexión ExpressRoute, pero en este ejemplo se usa una conexión VPN.
 3. Para una subred de una red virtual:

Forzar que todo el tráfico saliente de la subred, excepto el que va a Azure

Storage y el de dentro de la subred, fluya a través de una aplicación virtual de
red, para su inspección y registro.

No inspeccionar el tráfico entre las direcciones IP privadas de la subred;

permitir que el tráfico fluya directamente entre todos los recursos.

Eliminar todo el tráfico saliente destinado a la otra red virtual.

Habilitar el tráfico saliente a Azure Storage para que fluya directamente al

almacenamiento, sin hacerle pasar por una aplicación virtual de red.

4. Permitir todo el tráfico entre las restantes subredes y las redes virtuales.

Implementación
La siguiente imagen muestra una implementación a través del modelo de
implementación de Azure Resource Manager que cumple los requisitos anteriores:

Las flechas muestran el flujo de tráfico.

Tablas de ruta

Subnet1
La tabla de rutas de Subnet1 en la imagen contiene las rutas siguientes:

id Source State Prefijos de Tipo de próximo salto Dirección Nombre

dirección IP de de ruta
siguiente definida
salto por el
usuario

1 Valor No 10.0.0.0/16 Virtual network

predeterminado válida

2 Usuario Active 10.0.0.0/16 Aplicación virtual 10.0.100.4 Within-

VNet1

3 Usuario Active 10.0.0.0/24 Virtual network Within-

Subnet1

4 Valor No 10.1.0.0/16 Emparejamiento de VNET

predeterminado válida

5 Valor No 10.2.0.0/16 Emparejamiento de VNET

predeterminado válida

6 Usuario Active 10.1.0.0/16 None ToVNet2-

1-Drop

7 Usuario Active 10.2.0.0/16 None ToVNet2-

2-Drop

8 Valor No 10.10.0.0/16 Puerta de enlace de red virtual [X.X.X.X]

predeterminado válida

9 Usuario Active 10.10.0.0/16 Aplicación virtual 10.0.100.4 To-On-

Prem

10 Valor Active [X.X.X.X] VirtualNetworkServiceEndpoint

predeterminado

11 Valor No 0.0.0.0/0 Internet

predeterminado válida

12 Usuario Active 0.0.0.0/0 Aplicación virtual 10.0.100.4 Default-

NVA

A continuación encontrará una explicación de cada identificador de ruta:

ID1: Azure agregó automáticamente esta ruta a todas las subredes de Virtual-
network-1, ya que 10.0.0.0/16 es el único intervalo de direcciones definido en el
espacio de direcciones de la red virtual. Si no crea la ruta definida por el usuario en
la ruta ID2, el tráfico enviado a cualquier dirección entre 10.0.0.1 y 10.0.255.254 se
enruta dentro de la red virtual. Este proceso se debe a que el prefijo es más largo
que 0.0.0.0/0 y no se encuentra dentro de los prefijos de dirección de ninguna otra
ruta. Azure ha cambiado automáticamente el estado de Activo a No válido, cuando
se ha agregado ID2, una ruta definida por el usuario, puesto que tiene el mismo
prefijo que la ruta predeterminada y las rutas definidas por el usuario reemplazan
a las rutas predeterminadas. El estado de esta ruta sigue siendo Activo en Subnet2,
ya que la tabla de rutas en la que se encuentra la ruta definida por el usuario, ID2,
no está asociada a Subnet2.

ID2: Azure agregó esta ruta cuando una ruta definida por el usuario para el prefijo
de red 10.0.0.0/16 se asoció a la subred Subnet1 de la red virtual Virtual-network-1.
La ruta definida por el usuario especifica 10.0.100.4 como dirección IP de la
aplicación virtual, porque la dirección es la dirección IP privada asignada a la
máquina virtual de la aplicación virtual. La tabla de rutas en la que existe esta ruta
no está asociada a Subnet2, por lo que no aparece en la tabla de rutas de Subnet2.
Esta ruta reemplaza la ruta predeterminada del prefijo 10.0.0.0/16 (ID1), que enruta
automáticamente el tráfico dirigido a 10.0.0.1 y 10.0.255.254 dentro de la red
virtual a través del tipo de próximo salto de la red virtual. Esta ruta existe para
cumplir el requisito 3, para forzar que todo el tráfico de salida pase por una
aplicación virtual.

ID3: Azure agregó esta ruta cuando una ruta definida por el usuario para el prefijo
de red 10.0.0.0/24 se asoció a la subred Subnet1. El tráfico destinado a las
direcciones entre 10.0.0.1 y 10.0.0.254 permanece dentro de la subred, en lugar de
enrutarse a la aplicación virtual especificada en la regla anterior (ID2), ya que su
prefijo es más largo que la ruta ID2. La tabla de rutas no estaba asociada a
Subnet2, por lo que la ruta no aparece en la tabla de rutas de Subnet2. Esta ruta
reemplaza eficazmente la ruta ID2 para el tráfico de Subnet1. Esta ruta existe para
cumplir el requisito 3.

ID4: Azure agregó automáticamente las rutas de las ID 4 y 5 de todas las subredes
de Virtual-network-1, cuando la red virtual se emparejó con Virtual-network-
2.Virtual-network-2 tiene dos intervalos de direcciones en su espacio de
direcciones: 10.1.0.0/16 y 10.2.0.0/16, por lo que Azure agregó una ruta a cada
intervalo. Si no crea rutas definidas por el usuario en los ID de ruta 6 y 7, el tráfico
enviado a cualquier dirección entre 10.1.0.1-10.1.255.254 y 10.2.0.1-10.2.255.254 se
enruta a la red virtual del mismo nivel. Este proceso se debe a que el prefijo es más
largo que 0.0.0.0/0 y no se encuentra dentro de los prefijos de dirección de
ninguna otra ruta. Cuando agregó las rutas en los ID 6 y 7, Azure cambió
automáticamente el estado de Activo a No válido. Este proceso se debe a que
tienen los mismos prefijos que las rutas en los ID 4 y 5, y las rutas definidas por el
usuario invalidan las rutas predeterminadas. El estado de las rutas de los ID 4 y 5
sigue siendo Activo en Subnet2, ya que la tabla de rutas en la que se encuentran la
rutas definidas por el usuario en los ID 6 y 7 no está asociada a Subred2. Se ha
creado un emparejamiento de red virtual para cumplir el requisito 1.

ID5: la misma explicación que para ID4.

ID6: Azure agregó esta ruta y la ruta de ID7 cuando las rutas definidas por el
usuario para los prefijos de dirección 10.1.0.0/16 y 10.2.0.0/16 se asociaron a la
subred Subnet1. Azure anula el tráfico destinado a direcciones entre 10.1.0.1-
10.1.255.254 y 10.2.0.1-10.2.255.254, en lugar de enrutarlas a la red virtual
emparejada, porque las rutas definidas por el usuario reemplazan a las rutas
predeterminadas. Las rutas no están asociadas a Subnet2, por lo que no aparecen
en la tabla de rutas de Subnet2. Las rutas reemplazan las rutas ID4 y ID5 en el caso
del tráfico que sale del Subnet1. Las rutas ID6 y ID7 existen para satisfacer el
requisito 3 de eliminación del tráfico destinado a la otra red virtual.

ID7: la misma explicación que para ID6.

ID8: Azure agregó automáticamente esta ruta para todas las subredes de Virtual-
network-1 cuando se creó una puerta de enlace de red virtual de tipo VPN en la
red virtual. Azure agregó la dirección IP pública de la puerta de enlace de red
virtual a la raba de rutas. El tráfico enviado a cualquier dirección entre 10.10.0.1 y
10.10.255.254 se enruta a la puerta de enlace de red virtual. El prefijo es más largo
que 0.0.0.0/0 y no está dentro de los prefijos de dirección de las restantes rutas. Se
ha creado una puerta de enlace de red virtual para cumplir el requisito 2.

ID9: Azure agregó esta ruta cuando una ruta definida por el usuario para el prefijo
de red 10.10.0.0/16 se agregó a la tabla de rutas asociada a Subnet1. Esta ruta
reemplaza ID8. La ruta envía todo el tráfico destinado a la red local a una NVA para
su inspección, en lugar de enrutarlo directamente al entorno local. Esta ruta se ha
creado para cumplir el requisito 3.

ID10: Azure agregó automáticamente esta ruta a la subred cuando un punto de

conexión de servicio a un servicio de Azure se habilitó para la subred. Azure enruta
el tráfico de la subred a una dirección IP pública del servicio, a través de la red de
la infraestructura de Azure. El prefijo es más largo que 0.0.0.0/0 y no está dentro
de los prefijos de dirección de las restantes rutas. Se ha creado un punto de
conexión de servicio para cumplir el requisito 3, con el fin de habilitar que el tráfico
destinado a Azure Storage que fluya directamente a dicho servicio.
 ID11: Azure agregó automáticamente esta ruta a la tabla de rutas de todas las
subredes de Virtual-network-1 y Virtual-network-2. El prefijo de dirección 0.0.0.0/0
es el más corto. Todo el tráfico enviado a direcciones de un prefijo de dirección
más largo se enrutan en función de otras rutas. De forma predeterminada, Azure
enruta todo el tráfico destinado a aquellas direcciones que no sean las
especificadas en una de las otras rutas a Internet. Azure ha cambiado
automáticamente el estado de Activo a No válido para la subred Subnet1 cuando
una ruta definida por el usuario para el prefijo de dirección 0.0.0.0/0 (ID12) se ha
asociado a la subred. El estado de esta ruta sigue siendo Activo para las restantes
subredes de ambas redes virtuales, ya que la ruta no está asociada a otras
subredes de otras redes virtuales.

ID12: Azure agregó esta ruta cuando una ruta definida por el usuario para el prefijo
de dirección 0.0.0.0/0 se asoció a la subred Subnet1. La ruta definida por el usuario
especifica 10.0.100.4 como dirección IP de la aplicación virtual. Esta ruta no está
asociada a Subnet2, por lo que no aparece en la tabla de rutas de Subnet2. Todo el
tráfico de cualquier dirección no incluida en los prefijos de dirección de cualquiera
de las otras rutas se envía a la aplicación virtual. La adición de esta ruta ha
cambiado el estado de la ruta predeterminada para el prefijo de dirección 0.0.0.0/0
(ID11) de Activo a No válido para Subnet1, porque una ruta definida por el usuario
reemplaza a una ruta predeterminada. Esta ruta existe para cumplir el tercer
requisito.

Subnet2

La tabla de rutas de Subnet2 en la imagen contiene las rutas siguientes:

Source State Prefijos de Tipo de próximo salto Dirección IP de

dirección siguiente salto

Valor Active 10.0.0.0/16 Virtual network

predeterminado

Valor Active 10.1.0.0/16 Emparejamiento de redes

predeterminado virtuales de Azure

Valor Active 10.2.0.0/16 Emparejamiento de redes

predeterminado virtuales de Azure

Valor Active 10.10.0.0/16 Puerta de enlace de red [X.X.X.X]

predeterminado virtual

Valor Active 0.0.0.0/0 Internet

predeterminado
 Source State Prefijos de Tipo de próximo salto Dirección IP de
dirección siguiente salto

Valor Activo 10.0.0.0/8 None

predeterminado

Valor Active 100.64.0.0/10 None

predeterminado

Valor Activo 192.168.0.0/16 None

predeterminado

La tabla de rutas de Subnet2 contiene todas las rutas predeterminadas creadas por
Azure y el emparejamiento de red virtual opcional y las rutas opcionales de la puerta de
enlace de red virtual. Azure ha agregado las rutas opcionales a todas las subredes de la
red virtual cuando tanto la puerta de enlace como el emparejamiento se han agregado
a la red virtual. Azure ha quitado las rutas de los prefijos de dirección 10.0.0.0/8,
192.168.0.0/16 y 100.64.0.0/10 de la tabla de rutas de Subnet1 cuando la ruta definida
por el usuario del prefijo de dirección 0.0.0.0/0 se ha agregado a Subnet1.

Pasos siguientes
Creación de una ruta definida por el usuario - Azure Portal

Configuración de BGP para Azure VPN Gateway con PowerShell

Uso de BGP con ExpressRoute

Solución de problemas de rutas mediante Azure Portal. Las tablas de rutas

definidas por el usuario solo muestran las rutas definidas por el usuario, no las
rutas predeterminada y de BGP de una subred. La visualización de todas las rutas
muestra las rutas predeterminada, de BGP y definidas por el usuario de la subred
en que se encuentra una interfaz de red.

Determine el tipo de próximo salto entre una máquina virtual y una dirección IP de
destino. La característica de próximo salto de Azure Network Watcher permite
determinar si el tráfico sale de una subred y se enruta al lugar en que cree que
debería estar.
Interoperabilidad en Azure: Análisis del
plano de control
Artículo • 29/06/2023

En este artículo se describe el análisis del plano de control de la configuración de la

prueba. También puede revisar la configuración de la prueba y el análisis del plano de
control de la configuración de la prueba.

En esencia, el análisis del plano de control examina las rutas que se intercambian entre
las redes dentro de una topología. El análisis del plano de control puede ayudar a
entender la forma en la que cada red ve la topología.

Perspectiva de red virtual de concentrador y de

radios
La siguiente figura muestra la red desde la perspectiva de una red virtual de
concentrador y una red virtual de radios (destacada en azul). En la ilustración también se
muestra el número de sistema autónomo (ASN) de las redes y rutas que se intercambian
entre las distintas redes:
Tenga en cuenta que el ASN de la puerta de enlace de Azure ExpressRoute de la red
virtual difiere del ASN de los enrutadores de Microsoft Enterprise Edge (MSEE).
Generalmente, la puerta de enlace de ExpressRoute usa un ASN privado (con valor
65515) y los MSEE, uno público (12076). Al configurar el emparejamiento de
ExpressRoute, como MSEE es del mismo nivel, se usa 12076 como ASN del mismo nivel.
Del lado de Azure, MSEE establece emparejamiento de BGP externo con la puerta de
enlace de ExpressRoute. El emparejamiento BGP externo dual que el MSEE establece
para cada emparejamiento de ExpressRoute es transparente en el nivel del plano de
control. Por tanto, al visualizar una tabla de enrutamiento de ExpressRoute, se ve el valor
de ASN de la puerta de enlace de ExpressRoute de la red virtual para los prefijos de esta.

En la siguiente ilustración se muestra una tabla de enrutamiento de ExpressRoute de

ejemplo:

En Azure, el valor de ASN solo es significativo para el emparejamiento. De forma

predeterminada, el valor de ASN de la puerta de enlace tanto de ExpressRoute como de
VPN en Azure VPN Gateway es 65515.

Perspectiva de la ubicación local 1 y la red

virtual remota a través de ExpressRoute 1
Tanto la ubicación local 1 como la red virtual remota están conectadas a la red virtual de
concentrador a través de ExpressRoute 1. Comparten la misma perspectiva de la
topología, como se muestra en el siguiente diagrama:
Perspectiva de la ubicación local 1 y de la red
virtual de sucursal a través de la VPN de sitio a
sitio
Tanto la ubicación local 1 como la red virtual de sucursal están conectadas a la puerta
de enlace VPN de la red virtual de concentrador mediante una conexión VPN de sitio a
sitio. Comparten la misma perspectiva de la topología, como se muestra en el siguiente
diagrama:
Perspectiva de la ubicación 2 local
La ubicación local 2 está conectada a una red virtual de concentrador a través del
emparejamiento privado de ExpressRoute 2:

Uso simultáneo de ExpressRoute y la

conectividad VPN de sitio a sitio

VPN de sitio a sitio con ExpressRoute

Puede configurar una VPN de sitio a sitio mediante el emparejamiento de Microsoft
para ExpressRoute para intercambiar datos de forma privada entre la red local y las
redes virtuales de Azure. Esta configuración le asegura un intercambio de datos con
confidencialidad, autenticidad, integridad y antirreproducción. Para más información
acerca de cómo configurar una VPN IPsec de sitio a sitio en modo de túnel con
emparejamiento de Microsoft de ExpressRoute, consulte Configuración de una VPN de
sitio a sitio a través del emparejamiento de Microsoft de ExpressRoute.

La limitación principal de la configuración de una VPN de sitio a sitio que use el

emparejamiento de Microsoft es el rendimiento. El rendimiento a través del túnel IPsec
está limitado por la capacidad de la puerta de enlace de VPN. El rendimiento de la
puerta de enlace de VPN es menor que el de ExpressRoute. En este escenario, el uso del
túnel IPsec para el tráfico de seguridad alta y con emparejamiento privado para el
tráfico restante ayuda a optimizar el uso de ancho de banda de ExpressRoute.
VPN de sitio a sitio como ruta de acceso de conmutación
por error para ExpressRoute
ExpressRoute sirve como par de circuito redundante para garantizar la alta
disponibilidad. Puede configurar la conectividad de ExpressRoute con redundancia
geográfica en diferentes regiones de Azure. Además, como se ha demostrado en la
configuración de prueba, dentro de una región de Azure puede usar una VPN de sitio a
sitio para crear una ruta de acceso de conmutación por error para la conectividad de
ExpressRoute. Cuando se anuncian los mismos prefijos a través de ExpressRoute y VPN
de sitio a sitio, Azure da prioridad a ExpressRoute. Para evitar el enrutamiento asimétrico
entre ExpressRoute y VPN de sitio a sitio, la configuración de la red local también debe
tener prioridad mediante el uso de la conectividad ExpressRoute antes de VPN de sitio a
sitio.

Para más información acerca de cómo configurar conexiones coexistentes de

ExpressRoute y una VPN de sitio a sitio, consulte el artículo sobre la coexistencia de
conexiones de ExpressRoute y de sitio a sitio.

Ampliación de la conectividad de back-end a

redes virtuales de radios y ubicaciones de rama

Conectividad de red virtual de radios mediante el

emparejamiento de redes virtuales
La arquitectura de red virtual de concentrador y de radios es ampliamente utilizada. El
concentrador es una red virtual en Azure que se desempeña como punto central de
conectividad entre las redes virtuales de radios y la red local de su organización. Los
radios son redes virtuales que se emparejan con el concentrador y sirven para aislar las
cargas de trabajo. El tráfico fluye entre el centro de datos local y el concentrador a
través de una conexión de ExpressRoute o VPN. Para más información acerca de la
arquitectura, consulte Implementación de una topología de red en estrella tipo hub-
and-spoke en Azure.

En el emparejamiento de redes virtuales dentro de una región, las redes virtuales de

radios pueden usar puertas de enlace de red virtual de concentrador (tanto puertas de
enlace de VPN como de ExpressRoute) para comunicarse con redes remotas.

Conectividad de red virtual de rama mediante VPN de

sitio a sitio
Es posible que quiera redes virtuales de rama, que están en regiones diferentes, y redes
locales para comunicarse entre sí a través de una red virtual de concentrador. La
solución de Azure nativa para esta configuración es la conectividad VPN de sitio a sitio
mediante una VPN. Una alternativa es usar una aplicación virtual de red (NVA) para el
enrutamiento en el centro de conectividad.

Para más información, consulte ¿Qué es VPN Gateway? e Implementación de

aplicaciones virtuales de red de alta disponibilidad.

Pasos siguientes
Más información acerca del análisis del plano de datos de la configuración de prueba y
de las vistas de las características de supervisión de red de Azure.

Consulte las preguntas más frecuentes de ExpressRoute para información acerca de:

Cuántos circuitos de ExpressRoute puede conectar a una puerta de enlace de

ExpressRoute.

Cuántas puertas de enlace de ExpressRoute puede conectar a un circuito de

ExpressRoute.

Los límites de escala de ExpressRoute.

Habilitación de contenedores para que
usen las funcionalidades de Azure
Virtual Network
Artículo • 29/03/2023

Incorpore el amplio conjunto de funcionalidades de red de Azure a los contenedores

mediante el uso de la misma pila de redes que se utiliza en las máquinas virtuales. El
complemento de interfaz de red de contenedores (CNI) de Azure Virtual Network se
instala en una máquina virtual de Azure. El complemento asigna direcciones IP de una
red virtual a los contenedores en la máquina virtual, adjuntándolos a dicha red y
conectándolos directamente a otros contenedores y recursos de red virtual. El
complemento no se basa en las rutas o redes de superposición para la conectividad, y
proporciona el mismo rendimiento que las máquinas virtuales. En un nivel alto, el
complemento proporciona las siguientes funcionalidades:

Se asigna una dirección IP de red virtual a cada pod, que puede constar de uno o
varios contenedores.

Los pods pueden conectarse a redes virtuales emparejadas y al entorno local

mediante ExpressRoute o de una VPN de sitio a sitio. Los pods también son
accesibles desde redes locales y emparejadas.

Los pods pueden acceder a servicios como Azure Storage y Azure SQL Database,
que están protegidos por los puntos de conexión de servicio de red virtual.

Las rutas y los grupos de seguridad de red se pueden aplicar directamente a los
pods.

Los pods se pueden colocar directamente detrás de un equilibrador de carga

interno o público de Azure, igual que las máquinas virtuales

Los pods se pueden asignar a una dirección IP pública, lo que hace que sean
directamente accesibles desde Internet. Los pods también pueden ellos mismos
acceder a Internet.

Funciona perfectamente con los recursos de Kubernetes como Services, los

controladores de Ingress y DNS Kube. Un servicio de Kubernetes también se puede
exponer de forma externa o interna mediante Azure Load Balancer.

La siguiente imagen muestra cómo el complemento proporciona funcionalidades de

Azure Virtual Network a los pods:
El complemento admite las plataformas Windows y Linux.

Conexión de los pods a una red virtual

Los pods se muestran en una máquina virtual que sea parte de una red virtual. En la
interfaz de red de una máquina virtual se configuran, como direcciones secundarias, un
grupo de direcciones IP para los pods. Azure CNI configura la conectividad de red
básica para los pods y administra el uso de las direcciones IP en el grupo. Cuando un
pod aparece en la máquina virtual, Azure CNI asigna una dirección IP disponible del
grupo y se conecta el pod a un puente de software en la máquina virtual. Cuando el pod
finaliza, la dirección IP se vuelve a agregar al grupo. En la siguiente imagen se muestra
cómo se conectan los pod a una red virtual:
Acceso a Internet
Para habilitar los pods para que tengan acceso a Internet, el complemento configura las
reglas iptables para la traducción de direcciones de red (NAT) del tráfico ligado a
Internet desde los pods. La dirección IP de origen del paquete se traduce a la dirección
IP principal en la interfaz de red de la máquina virtual. Las máquinas virtuales Windows
aplican el modo Source NAT (SNAT) automáticamente al tráfico destinado a direcciones
IP fuera de la subred a la que pertenece la máquina virtual. Normalmente, se traduce
todo el tráfico destinado a una dirección IP fuera del intervalo IP de la red virtual.

límites
El complemento admite hasta 250 pods por máquina virtual y un máximo de 16 000
Pods en una red virtual. Estos límites son diferentes para Azure Kubernetes Service.

Uso del complemento

El complemento se puede usar de las siguientes maneras para proporcionar conexión
de red virtual básica para contenedores de Docker o Pods:

Azure Kubernetes Service: el complemento está integrado en Azure Kubernetes

Service (AKS) y puede usarse eligiendo la opción de Redes avanzadas. La opción de
 redes avanzadas le permite implementar un clúster de Kubernetes en una red
virtual nueva o existente. Para más información acerca de la opción de redes
avanzadas y los pasos para configurarla, consulte Configuración de red en Azure
Kubernetes Service (AKS).

AKS-Engine: AKS-Engine es una herramienta que genera una plantilla de Azure

Resource Manager para la implementación de un clúster de Kubernetes en Azure.
Para obtener instrucciones detalladas, consulte Implementación del complemento
para un clúster de Kubernetes con AKS-Engine.

Creación de su propio clúster de Kubernetes en Azure: el complemento se puede

usar para proporcionar prestaciones de red básicas para los pods en clústeres de
Kubernetes que implemente usted mismo, sin tener que depender de AKS, o de
herramientas como AKS-Engine. En este caso, el complemento se instala y habilita
en todas las máquinas virtuales en un clúster. Para instrucciones detalladas,
consulte Implementación del complemento para un clúster de Kubernetes que
usted mismo haya implementado.

Conexión de una red virtual para contenedores de Docker en Azure: el

complemento se puede usar en casos donde no quiera crear un clúster de
Kubernetes y desee crear contenedores de Docker con conexión de red virtual en
máquinas virtuales. Para instrucciones detalladas, consulte Implementación del
complemento para contenedores de Docker.

Pasos siguientes
Implementación de redes de contenedor para un host de Docker de Linux
independiente

Implementación de redes de contenedor para un host de Docker de Windows

independiente

Implementación del complemento para clústeres de Kubernetes o contenedores

de Docker
Emparejamiento de redes virtuales de
Azure
Artículo • 28/05/2023

El emparejamiento de red virtual permite conectar sin problemas dos o más redes
virtuales en Azure. A efectos de conectividad las redes virtuales aparecen como una sola.
El tráfico entre las máquinas virtuales de la red virtual emparejada usa la infraestructura
de la red troncal de Microsoft. Al igual que el tráfico entre las máquinas virtuales de la
misma red, el tráfico solo se enruta a través de la red privada de Microsoft.

La directiva admite los siguientes tipos de emparejamiento:

Emparejamiento de red virtual: conexión de redes virtuales que se encuentren en

la misma región de Azure.

Emparejamiento global de redes virtuales: conexión de redes virtuales en distintas

regiones de Azure.

Las ventajas del uso del emparejamiento de redes virtuales, ya sean locales o globales,
son las siguientes:

Baja latencia, conexión de gran ancho de banda entre los recursos de redes
virtuales diferentes.

La capacidad de los recursos de una red virtual para comunicarse con los de otra
red virtual.

La capacidad de transferir datos entre redes virtuales de distintas suscripciones de

Azure, inquilinos de Azure Active Directory, modelos de implementación y
regiones de Azure.

La capacidad de emparejar redes virtuales creadas mediante Azure Resource

Manager.

La capacidad de emparejar una red virtual creada mediante Resource Manager con
otra creada mediante el modelo de implementación clásica. Para más información
sobre los modelos de implementación de Azure, consulte Descripción de los
modelos de implementación de Azure.

No tienen tiempo de inactividad ni los recursos de la red virtual al crear el

emparejamiento, o después.
El tráfico de red entre redes virtuales emparejadas es privado. El tráfico entre las redes
virtuales se mantiene en la red troncal de Microsoft. No se requieren ninguna red
pública de Internet, puertas de enlace o cifrado en la comunicación entre las redes
virtuales.

Conectividad
En el caso de las redes virtuales emparejadas, los recursos de cualquiera de ellas se
pueden conectar directamente con los de la red virtual emparejada.

La latencia de red entre las máquinas virtuales de redes virtuales emparejadas en la

misma región es la misma que la de una única red virtual. El rendimiento de la red se
basa en el ancho de banda que se permite para la máquina virtual, en proporción a su
tamaño. No hay restricciones adicionales con respecto al ancho de banda en el
emparejamiento.

El tráfico entre las máquinas virtuales en las redes virtuales emparejadas se enruta
directamente a través de la infraestructura de red troncal de Microsoft, no de una puerta
de enlace ni de una red Internet pública.

En cualquier red virtual, se pueden aplicar grupos de seguridad de red para bloquear el
acceso a otras redes o subredes virtuales. Al configurar el emparejamiento de red
virtual, abra o cierre las reglas del grupo de seguridad de red entre las redes virtuales. Si
abre la conectividad completa entre redes virtuales emparejadas, puede aplicar grupos
de seguridad de red a subredes o máquinas virtuales concretas para bloquear o denegar
el acceso específico. La opción predeterminada es la conectividad total. Para obtener
más información sobre los grupos de seguridad de red, consulte Grupos de seguridad.

Cambio de tamaño del espacio de direcciones

de las redes virtuales de Azure emparejadas
Puede cambiar el tamaño del espacio de direcciones de las redes virtuales de Azure
emparejadas sin incurrir en ningún tiempo de inactividad en el espacio de direcciones
actualmente emparejado. Esta característica es útil cuando necesita cambiar el tamaño
del espacio de direcciones de las redes virtuales después de escalar las cargas de
trabajo. Una vez que se cambie el tamaño del espacio de direcciones, los nodos del
mismo nivel deberán sincronizarse con los nuevos cambios en el espacio de direcciones.
El cambio de tamaño funciona para los espacios de direcciones IPv4 e IPv6.

El tamaño de la direcciones puede cambiarse de las formas siguientes:

 Modificación del prefijo del intervalo de direcciones de un intervalo de direcciones
existente (por ejemplo, cambio de 10.1.0.0/16 a 10.1.0.0/18)

Incorporación de intervalos de direcciones a una red virtual

Eliminación de intervalos de direcciones de una red virtual

Se admite el cambio de tamaño del espacio de direcciones entre inquilinos.

La sincronización de elementos del mismo nivel de red virtual se puede realizar a través
de Azure Portal o con Azure PowerShell. Se recomienda ejecutar la sincronización
después de cada operación de espacio de direcciones de cambio de tamaño, en lugar
de realizar varias operaciones de cambio de tamaño y, posteriormente, ejecutar la
operación de sincronización. Para obtener información sobre cómo actualizar el espacio
de direcciones de una red virtual emparejada, consulte Actualización del espacio de
direcciones de una red virtual emparejada.

） Importante

Esta característica no admite los siguientes escenarios si la red virtual que se va a

actualizar está emparejada con:

Una red virtual clásica.

Una red virtual administrada, como el centro de Azure VWAN.

Encadenamiento de servicios
El encadenamiento de servicios permite dirigir el tráfico de una red virtual a una
aplicación virtual o puerta de enlace de una red emparejada a través de rutas definidas
por el usuario.

Para habilitar el encadenamiento de servicios, configure las rutas definidas por el

usuario que apuntan a máquinas virtuales de redes virtuales emparejadas como la
dirección IP del próximo salto. Las rutas definidas por el usuario también pueden
apuntar a puertas de enlace de redes virtuales para habilitar el encadenamiento de
servicios.

Puede implementar redes del tipo de concentrador y radio, en los que la red virtual del
concentrador hospeda componentes de la infraestructura, como una aplicación virtual
de red o una puerta de enlace de VPN. Todas las redes virtuales de radio se pueden
emparejar con la red virtual de concentrador. El tráfico fluye por las aplicaciones
virtuales de red o las puertas de enlace de VPN de la red virtual del concentrador.
El emparejamiento de red virtual permite que el próximo salto de una ruta definida por
el usuario sea la dirección IP de una máquina virtual de la red virtual emparejada o en
una puerta de enlace de VPN. No puede realizar el enrutamiento entre redes virtuales
con una ruta definida por el usuario que especifique una puerta de enlace de Azure
ExpressRoute como del tipo de próximo salto. Para obtener más información sobre las
rutas definidas por el usuario, consulte Introducción a las rutas definidas por el usuario.
Para aprender a crear una topología de red en estrella tipo hub-and-spoke, consulte
Topología en estrella tipo hub-and-spoke en Azure.

Puertas de enlace y conectividad local

Cada red virtual, incluidas las redes virtuales emparejadas, puede tener su propia puerta
de enlace. Las redes virtuales pueden usar su puerta de enlace para conectarse a una
red local. También puede configurar conexiones entre redes virtuales mediante puertas
de enlace, incluso para redes virtuales emparejadas.

Cuando se configuran las dos opciones para la interconectividad de redes virtuales, el

tráfico entre las redes virtuales se propaga a través de la configuración del
emparejamiento. El tráfico usa la red troncal de Azure.

La puerta de enlace de la red virtual emparejada también se puede configurar como un

punto de tránsito a una red local. En ese caso, la red virtual que usa una puerta de
enlace remota no puede tener su propia puerta de enlace. Una red virtual puede tener
solo una puerta de enlace, que debe ser local o remota en la red virtual emparejada,
como se muestra en el diagrama siguiente:
Tanto el emparejamiento de red virtual como el emparejamiento de red virtual global
admiten el tránsito de puerta de enlace.

Se admite el tránsito de puerta de enlace entre redes virtuales creadas mediante

diferentes modelos de implementación. La red virtual debe estar en la red virtual del
modelo de Resource Manager. Para más información sobre el uso de una puerta de
enlace de tránsito, consulte Configure a VPN gateway for transit in a virtual network
peering (Configuración de una puerta de enlace de VPN de tránsito en un
emparejamiento de red virtual).

Si se emparejan redes virtuales que comparten la misma conexión de Azure

ExpressRoute, el tráfico entre ellas pasa por la relación de emparejamiento. Ese tráfico
usa la red troncal de Azure. Puede seguir usando las puertas de enlace locales de cada
red virtual para conectarse al circuito local. De lo contrario, puede utilizar una puerta de
enlace compartida y configurar el tránsito para una conectividad local.

Solución de problemas
Para confirmar que las redes virtuales están emparejadas, puede comprobar las rutas
eficaces. Las rutas de una interfaz de red se comprueban en cualquier subred de una red
virtual. Si el emparejamiento de redes virtuales existe, todas las subredes de la red
virtual tienen rutas con próximo salto del tipo emparejamiento de VNet, para cada
espacio de direcciones en cada red virtual emparejada. Para más información, consulte
Diagnóstico de problemas de enrutamiento en una máquina virtual.

En una red virtual emparejada, los problemas de conectividad con una máquina virtual
se pueden solucionar mediante Azure Network Watcher. Una comprobación de
conectividad permite ver cómo se enruta el tráfico desde la interfaz de red de una
máquina virtual de origen a la de una máquina virtual de destino. Para más información,
consulte Solución de problemas en las conexiones con Azure Network Watcher desde
Azure Portal.

También puede probar la solución de problemas de emparejamiento de red virtual.

Restricciones de las redes virtuales

emparejadas
Cuando las redes virtuales están emparejadas globalmente, se aplican las siguientes
restricciones:
 Los recursos de una red virtual no pueden comunicarse con la dirección IP de
front-end de un equilibrador de carga básico (interno o público) en una red virtual
emparejada globalmente.

Algunos servicios que usan un equilibrador de carga básico no funcionan en el

emparejamiento de red virtual global. Para más información, consulte ¿Cuáles son
las restricciones relacionadas con el emparejamiento de red virtual global y los
equilibradores de carga?.

Para más información, consulte Requisitos y restricciones. Para más información sobre el
número de emparejamientos que se admiten, consulte Límites de la red.

Permisos
Para más información sobre los permisos necesarios para crear un emparejamiento de
red virtual, consulte Permisos.

Precios
Hay un cargo nominal para el tráfico de entrada y salida que usa una conexión de
emparejamiento de red virtual. Para más información, consulte Precios de redes
virtuales .

El tránsito de puerta de enlace es una propiedad del emparejamiento que permite a las
redes virtuales utilizar una puerta de enlace de VPN o ExpressRoute de una red virtual
emparejada. El tránsito de puerta de enlace funciona tanto para la conectividad entre
entornos locales como para la conectividad entre redes. El tráfico a la puerta de enlace
(de entrada o salida) en la red virtual emparejada incurre en cargos de emparejamiento
de red virtual en la red virtual radial (o red virtual sin una puerta de enlace VPN). Para
más información, consulte Precios de VPN Gateway , donde podrá ver los cargos que
supone una puerta de enlace de red privada virtual y los precios de la puerta de enlace
de ExpressRoute, donde podrá ver los costos de la puerta de enlace de ExpressRoute.

７ Nota

En una versión anterior de este documento se indicaba que no se aplicarían cargos

de emparejamiento de red virtual a la red virtual de radio (o la red virtual que no
sea de puerta de enlace) con el tránsito de puerta de enlace. Ahora se refleja un
precio preciso en la página de precios.
Pasos siguientes
Puede crear un emparejamiento entre dos redes virtuales. Las redes pueden
pertenecer a la misma suscripción, a diferentes modelos de implementación de la
misma suscripción o a diferentes suscripciones. Realice el tutorial para uno de los
siguientes escenarios:

Modelo de implementación de Azure Subscription

Ambas mediante Resource Manager La misma

Diferente

Una mediante Resource Manager y la otra clásica La misma

Diferente

Para aprender a crear una topología de red en estrella tipo hub-and-spoke,

consulte Topología en estrella tipo hub-and-spoke en Azure.

Para obtener información acerca de la configuración del emparejamiento de red

virtual, consulte Creación, cambio o eliminación de un emparejamiento de red
virtual.

Para conocer las respuestas a las preguntas habituales acerca del emparejamiento
de red virtual y del emparejamiento de red virtual global, consulteEmparejamiento
de red virtual.
Integración de servicios de Azure con
redes virtuales para el aislamiento de
red
Artículo • 11/05/2023

La integración de Virtual Network para un servicio de Azure le permite bloquear el

acceso al servicio únicamente a la infraestructura de red virtual. La infraestructura de red
virtual también incluye redes virtuales del mismo nivel y redes locales.

La integración de red virtual proporciona a los servicios de Azure las ventajas del
aislamiento de red con uno o varios de los métodos siguientes:

Implementación de instancias dedicadas del servicio en una red virtual. Luego se

puede acceder de forma privada a los servicios dentro de la red virtual y desde
redes locales.

Usando un punto de conexión privado que le conecta de forma privada y segura a

un servicio con la tecnología de Azure Private Link. Los puntos de conexión
privados emplean una dirección IP privada de la red virtual, lo que hace que el
servicio se incluya en la red virtual.

Accediendo al servicio mediante puntos de conexión públicos mediante la

ampliación de una red virtual al servicio a través de los puntos de conexión de
servicio. Los puntos de conexión de servicio permiten que los recursos de servicio
se protejan en la red virtual.

Usando etiquetas de servicio para permitir o denegar el tráfico a los recursos de

Azure hacia y desde puntos de conexión de dirección IP pública.

Implementación de servicios de Azure

dedicados en las redes virtuales
Al implementar servicios de Azure dedicados en una red virtual, puede comunicarse con
los recursos de los servicios de forma privada mediante direcciones IP privadas.
La implementación de un servicio de Azure dedicado en una red virtual ofrece las
siguientes funcionalidades:

Los recursos dentro de la red virtual pueden comunicarse entre sí de forma privada
a través de direcciones IP privadas. Ejemplo: transferencia directa de datos entre
HDInsight y SQL Server que se ejecutan en una máquina virtual, en la red virtual.

Los recursos locales pueden acceder a recursos de una red virtual mediante
direcciones IP privadas a través de VPN de sitio a sitio (VPN Gateway) o
ExpressRoute.

Las redes virtuales pueden estar emparejadas para habilitar que los recursos de las
redes virtuales se comuniquen entre sí mediante direcciones IP privadas.

El servicio de Azure administra completamente las instancias de servicio en una red

virtual. Esta administración incluye la supervisión del estado de los recursos y el
escalado con carga.

Las instancias de los servicios se implementan en una subred de una red virtual. El
acceso de red entrante y saliente para la subred se debe abrir a través de grupos
de seguridad de red, siguiendo las instrucciones proporcionadas por el servicio.
 Determinados servicios imponen restricciones en la subred en la que están
implementados. Estas restricciones limitan la aplicación de directivas, rutas o la
combinación de máquinas virtuales y recursos de servicio dentro de la misma
subred. Compruebe las restricciones específicas de cada servicio porque podrían
cambiar con el tiempo. Algunos ejemplos de estos servicios son Azure NetApp
Files, Dedicated HSM, Azure Container Instances y App Service.

Opcionalmente, los servicios pueden requerir una subred delegada como un

identificador explícito de que una subred puede hospedar un servicio
determinado. Los servicios de Azure tienen permiso explícito para crear recursos
específicos del servicio en la subred delegada con delegación.

Vea un ejemplo de una respuesta de API REST en una red virtual con una subred
delegada. Puede ver una lista completa de los servicios que usan el modelo de
subred delegada a través de la API de Available Delegations.

Para obtener una lista de los servicios que se pueden implementar en una red virtual,
consulte Implementación de servicios de Azure dedicados en las redes virtuales.

Private Link con puntos de conexión privados

Los puntos de conexión privados permiten la entrada de tráfico desde la red virtual a un
recurso de Azure de forma segura. Este vínculo privado se establece sin que sean
necesarias las direcciones IP públicas. Un punto de conexión privado es una interfaz de
red especial para un servicio de Azure en la red virtual. Cuando se crea un punto de
conexión privado para el recurso, dicho punto de conexión privado proporciona
conectividad segura entre los clientes de la red virtual y el recurso de Azure. Al punto de
conexión privado se le asigna una dirección IP del intervalo de direcciones IP de su red
virtual. La conexión entre el punto de conexión privado y el servicio de Azure es un
vínculo privado.

En el diagrama, el lado derecho muestra una instancia de Azure SQL Database como
servicio PaaS de destino. El destino puede ser cualquier servicio que admita puntos de
conexión privados. Hay varias instancias de SQL Server lógico para varios clientes, a las
que se puede acceder a través de direcciones IP públicas.

En este caso, está expuesta una instancia de SQL Server lógico con un punto de
conexión privado. El punto de conexión hace que SQL Server sea accesible a través de
una dirección IP privada en la red virtual del cliente. Debido al cambio en la
configuración de DNS, la aplicación cliente ahora envía su tráfico directamente a ese
punto de conexión privado. El servicio de destino ve el tráfico que se origina desde una
dirección IP privada de la red virtual.
La flecha verde representa un vínculo privado. Todavía puede existir una dirección IP
pública para el recurso de destino junto con el punto de conexión privado. La aplicación
cliente ya no usa la dirección IP pública. El firewall ahora puede no permitir el acceso a
esa dirección IP pública, de modo que solo sea accesible a través de puntos de conexión
privados. Las conexiones a una instancia de SQL Server sin un punto de conexión
privado desde la red virtual se originan desde una dirección IP pública. La flecha azul
representa este flujo.

Normalmente, la aplicación cliente usa un nombre de host DNS para comunicarse con el
servicio de destino. No se necesita ningún cambio en la aplicación. La resolución DNS
de la red virtual debe configurarse para resolver ese mismo nombre de host en la
dirección IP privada del recurso de destino, en lugar de en la dirección IP pública
original. Con una ruta de acceso privada entre el cliente y el servicio de destino, el
cliente no depende de la dirección IP pública. El servicio de destino puede desactivar el
acceso público.

La exposición de instancias individuales permite evitar el robo de datos. Un actor

malintencionado no podrá recopilar información de la base de datos y cargarla en otra
base de datos pública o cuenta de almacenamiento. Puede impedir el acceso a las
direcciones IP públicas de todos los servicios PaaS. Todavía puede permitir el acceso a
instancias de PaaS a través de sus puntos de conexión privados.

Para obtener más información sobre el vínculo privado y una lista de los servicios de
Azure admitidos, consulte ¿Qué es Azure Private Link?

Puntos de conexión del servicio

Los puntos de conexión de servicio proporcionan conectividad segura y directa a los
servicios de Azure a través de la red troncal de Azure. Los puntos de conexión permiten
proteger los recursos de Azure únicamente para las redes virtuales. Los puntos de
conexión de servicio permiten que las direcciones IP privadas de la red virtual se
comuniquen con un servicio de Azure sin necesidad de una dirección IP pública saliente.

Sin los puntos de conexión de servicio, restringir el acceso solo a la red virtual puede ser
complicado. La dirección IP de origen podría cambiar o podría compartirse con otros
clientes. Por ejemplo, los servicios PaaS con direcciones IP salientes compartidas. Con
los puntos de conexión de servicio, la dirección IP de origen que ve el servicio de
destino se convierte en una dirección IP privada de la red virtual. Este cambio de tráfico
de entrada permite identificar fácilmente el origen y usarlo para configurar las reglas de
firewall adecuadas. Por ejemplo, para permitir solo el tráfico desde una subred
específica dentro de esa red virtual.

Con los puntos de conexión de servicio, las entradas DNS para los servicios de Azure
permanecen tal cual y siguen resolviendo las direcciones IP públicas asignadas al
servicio de Azure.

En el diagrama siguiente, el lado derecho es el mismo servicio PaaS de destino. A la

izquierda, está la red virtual de un cliente con dos subredes: la subred A, que tiene un
punto de conexión de servicio hacia Microsoft.Sql , y la subred B, que no tiene definido
ningún punto de conexión de servicio.

Cuando un recurso de la subred B intente comunicarse con cualquier instancia de

SQL Server, este usa una dirección IP pública para la comunicación saliente. La flecha
azul representa este tráfico. El firewall de SQL Server debe usar esa dirección IP pública
para permitir o bloquear el tráfico de red.

Cuando un recurso de la subred A intente llegar a un servidor de bases de datos, se ve

como una dirección IP privada desde dentro de la red virtual. Las flechas verdes
representan este tráfico. El firewall de SQL Server ahora puede permitir o bloquear
específicamente la subred A. No es necesario conocer la dirección IP pública del servicio
de origen.
Los puntos de conexión de servicio se aplican a todas las instancias del servicio de
destino. Por ejemplo, todas las instancias de SQL Server de los clientes de Azure, no solo
la instancia del cliente.

Para obtener más información, vea Puntos de conexión de servicio de red virtual.

Etiquetas de servicio
Una etiqueta de servicio representa un grupo de prefijos de direcciones IP de un servicio
de Azure determinado. Con las etiquetas de servicio, puede definir controles de acceso
a la red en grupos de seguridad de red o Azure Firewall. Puede permitir o denegar el
tráfico del servicio. Para permitir o denegar el tráfico, especifique la etiqueta de servicio
en el campo de origen o destino de una regla.
Logre el aislamiento de red y proteja los recursos de Azure de la red de Internet
mientras accede a los servicios de Azure que tienen puntos de conexión públicos. Cree
reglas de grupo de seguridad de red entrantes y salientes para denegar el tráfico hacia y
desde Internet y permitir el tráfico hacia y desde AzureCloud. Para más etiquetas de
servicio, consulte las etiquetas de servicio disponibles de los servicios específicos de
Azure.

Para más información sobre las etiquetas de servicio y los servicios de Azure
compatibles con ellas, consulte Etiquetas de servicio de red virtual.

Comparación de puntos de conexión privados y

puntos de conexión de servicio

７ Nota

Microsoft recomienda usar Azure Private Link. Private Link ofrece mejores
funcionalidades en términos de acceso privado a PaaS desde el entorno local, la
protección contra la filtración de datos integrada y el servicio de asignación a la
dirección IP privada en su propia red. Para más información, consulte Azure Private
Link.

En lugar de mirar solo sus diferencias, vale la pena señalar que tanto los puntos de
conexión de servicio como los puntos de conexión privados tienen características en
común.
Ambas características se usan para lograr control más detallado del firewall en el
servicio de destino. Por ejemplo, restringir el acceso a las bases de datos o cuentas de
almacenamiento de SQL Server. Sin embargo, cada uno se opera de manera diferente,
como se describe con más detalle en las secciones anteriores.

Ambos enfoques superan el problema del agotamiento de puertos de traducción de

direcciones de red de origen (SNAT). Puede que el agotamiento se presente al realizar la
tunelización del tráfico a través de una aplicación virtual de red (NVA) o un servicio con
limitaciones de puerto SNAT. Cuando se usan puntos de conexión de servicio o puntos
de conexión privados, el tráfico toma una ruta de acceso optimizada directamente al
servicio de destino. Ambos enfoques pueden beneficiar a las aplicaciones que
consumen mucho ancho de banda, ya que se reducen la latencia y el costo.

En ambos casos, todavía puede garantizar que el tráfico que entra en el servicio de
destino pasará a través de un firewall de red o NVA. Este procedimiento es diferente
para ambos enfoques. Cuando use puntos de conexión de servicio, debe configurar el
punto de conexión de servicio en la subred de firewall, en lugar de la subred en la que
está implementado el servicio de origen. Cuando se usan puntos de conexión privados,
se coloca una ruta definida por el usuario (UDR) para la dirección IP del punto de
conexión privado en la subred de origen. No en la subred del punto de conexión
privado.

Para comparar y comprender las diferencias, consulte la siguiente tabla.

Consideración Puntos de conexión de servicio Puntos de

conexión
privados

Ámbito de servicio en el Servicio completo (por ejemplo, todas las Instancia

que se aplica la instancias de SQL Server o las cuentas de individual (por
configuración almacenamiento de todos los clientes) ejemplo, una
instancia de SQL
Server o una
cuenta de
almacenamiento
de su
propiedad)
Consideración Puntos de conexión de servicio Puntos de
conexión
privados

Protección contra la No Sí
filtración de datos
integrada: capacidad de
que mover o copiar datos
desde un recurso de PaaS
protegido a otro recurso
de PaaS sin protección
por parte de un infiltrado
malintencionado.

Acceso privado al recurso No Sí

de PaaS desde el entorno
local

Configuración de NSG Sí (mediante etiquetas de servicio) No

necesaria para el acceso
al servicio

Se puede acceder al No Sí
servicio sin usar ninguna
dirección IP pública

El tráfico de Azure a Sí Sí
Azure permanece en la
red troncal de Azure

El servicio puede No Sí
deshabilitar su dirección
IP pública

Puede restringir Sí (permita el acceso desde subredes específicas o Sí

fácilmente el tráfico use NSG)
procedente de una
instancia de Azure Virtual
Network

Puede restringir N/D** Sí

fácilmente el tráfico
procedente de un
servidor local
(VPN/ExpressRoute)

Requiere cambios de No Sí (consulte la

DNS configuración
de DNS)
 Consideración Puntos de conexión de servicio Puntos de
conexión
privados

Afecta el costo de la No Sí (consulte los

solución precios del
vínculo
privado )

Afecta al Acuerdo de No Sí (el propio

Nivel de Servicio servicio del
compuesto de la solución vínculo privado
tiene un
Acuerdo de
Nivel de Servicio
del 99,99 % )

Configuración y Facilidad de configuración con menos sobrecarga Se requiere un

mantenimiento de administración. esfuerzo
adicional

Límites No hay límite en el número total de puntos de Sí (consulte los

conexión de servicio que puede tener una red límites de
virtual. Los servicios de Azure pueden aplicar Private Link )
límites en el número de subredes que se usan
para proteger el recurso. (consulte [preguntas más
frecuentes sobre redes virtuales](virtual-networks-
faq.md#are-there-any-limits-on-how-many-virtual
network-service-endpoints-i-can-set-up-from-my-
virtual network))

**No se puede acceder desde redes locales a los recursos de los servicios de Azure
protegidos en las redes virtuales. Si quiere permitir el tráfico desde el entorno local,
permita las direcciones IP públicas (normalmente NAT) desde el entorno local o
ExpressRoute. Estas direcciones IP se pueden agregar a través de la configuración del
firewall de IP para los recursos de los servicios de Azure. Para más información, consulte
preguntas más frecuentes sobre redes virtuales.

Pasos siguientes
Obtenga información sobre cómo integrar la aplicación con una red de Azure.

Obtenga información sobre cómo restringir el acceso a los recursos mediante

etiquetas de servicio.

Obtenga información sobre cómo conectarse de forma privada a una cuenta de

Azure Cosmos DB mediante Azure Private Link.
Implementación de servicios de Azure
dedicados en las redes virtuales
Artículo • 08/11/2023

Al implementar servicios de Azure dedicados en una red virtual, puede comunicarse con
los recursos de los servicios de forma privada mediante direcciones IP privadas.

La implementación de servicios dentro de una red virtual ofrece las siguientes

funcionalidades:

Los recursos dentro de la red virtual pueden comunicarse entre sí de forma privada
a través de direcciones IP privadas. Ejemplo: transferencia directa de datos entre
HDInsight y SQL Server que se ejecutan en una máquina virtual, en la red virtual.

Los recursos locales pueden acceder a recursos de una red virtual mediante
direcciones IP privadas a través de VPN de sitio a sitio (VPN Gateway) o
ExpressRoute.
 Las redes virtuales pueden estar emparejadas para habilitar que los recursos de las
redes virtuales se comuniquen entre sí mediante direcciones IP privadas.

Las instancias de los servicios se implementan en una subred de una red virtual. El
acceso de red entrante y saliente para la subred se debe abrir a través de grupos
de seguridad de red, siguiendo las instrucciones proporcionadas por el servicio.

Algunos servicios imponen restricciones en la subred en la que se implementan.

Esta restricción limita la aplicación de directivas, rutas o la combinación de
máquinas virtuales y recursos de servicio dentro de la misma subred. Compruebe
las restricciones específicas de cada servicio porque podrían cambiar con el
tiempo. Algunos ejemplos de servicios son Azure NetApp Files, Dedicated HSM,
Azure Container Instances, App Service.

Opcionalmente, los servicios pueden requerir una subred delegada como un

identificador explícito de que una subred puede hospedar un servicio
determinado. Con la delegación, los servicios reciben permisos explícitos para
crear recursos específicos del servicio en la subred delegada.

Vea un ejemplo de una respuesta de API REST en una red virtual con una subred
delegada. Puede ver una lista completa de los servicios que usan el modelo de
subred delegada a través de la API de Available Delegations.

Servicios que pueden implementarse en una red virtual

Category Servicio Subred

dedicada1

Proceso Máquinas virtuales: Linux o Windows No

Conjuntos de escalado de máquinas virtuales No
Servicio en la nube: solo red virtual (clásica) No
Azure Batch No2
Azure Baremetal Infrastructure No

Red Application Gateway - WAF Sí

Azure Bastion Sí
Azure Firewall Sí
Azure Route Server Sí
Puerta de enlace de ExpressRoute Sí
Aplicaciones virtuales de red No
VPN Gateway Sí
Azure DNS Private Resolver No

Data RedisCache Sí
Azure SQL Managed Instance Sí
 Category Servicio Subred
dedicada1

Azure Database for MySQL: servidor flexible Sí

Azure Database for PostgreSQL: servidor flexible Sí

Análisis HDInsight de Azure No2

Azure Databricks No2

Identidad Servicios de dominio de Microsoft Entra No

Contenedores Azure Kubernetes Service (AKS) No2

Instancia de Azure Container (ACI) Sí
Motor de Azure Container Service con el No
complemento CNI de Azure Virtual Network Sí
Funciones de Azure

Web API Management Sí

Aplicaciones web Sí
entorno de App Service Sí
Azure Logic Apps Sí
Entornos de Azure Container Apps Sí

Hospedada Azure Dedicated HSM Sí

Azure NetApp Files Sí

Azure Spring Apps Implementación en una red virtual de Azure Sí

(inserción de red virtual)

Infraestructura de Azure Lab Services Sí

escritorio virtual

DevOps Azure Load Testing Sí

1 El término "dedicada" significa que en esta subred solo se pueden implementar los
recursos específicos del servicio y no se pueden combinar con VM/VMSS del cliente
2
Se recomienda que estos servicios estén en una subred dedicada, pero no un requisito
obligatorio impuesto por el servicio.
¿Qué es Azure Private Link?
Artículo • 25/03/2023

Azure Private Link le permite acceder a los servicios PaaS de Azure (por ejemplo, Azure
Storage y SQL Database) y a los servicios hospedados en Azure que son propiedad de
los clientes, o a los servicios de asociados, a través de un punto de conexión privado de
la red virtual.

El tráfico entre la red virtual y el servicio viaja por la red troncal de Microsoft. Ya no es
necesario exponer el servicio a la red pública de Internet. Puede crear su propio servicio
de vínculo privado en la red virtual y enviarlo a los clientes. La configuración y el
consumo mediante Azure Private Link es coherente entre los servicios de asociados
compartidos y propiedad del cliente de PaaS de Azure.

） Importante

Azure Private Link ya está disponible con carácter general. Tanto el punto de
conexión privado como el servicio Private Link (servicio detrás del equilibrador de
carga estándar) están disponibles con carácter general. La incorporación de los
diferentes Azure PaaS a Azure Private Link se realizará en diferentes
programaciones. Consulte Disponibilidad de Private Link para ver un estado
preciso de PaaS de Azure en Private Link. Para obtener información sobre las
limitaciones conocidas, consulte Punto de conexión privado y Servicio Private
Link.
Ventajas principales
Azure Private Link proporciona las ventajas siguientes:

Acceso privado a los servicios de la plataforma Azure: conecte una red virtual
mediante puntos de conexión privados a todos los servicios que se pueden usar
como componentes de aplicación en Azure. Los proveedores de servicios pueden
representar los servicios en su propia red virtual y los consumidores pueden
acceder a ellos en su red virtual local. La plataforma Private Link administrará la
conectividad entre el consumidor y los servicios a través de la red troncal de Azure.

Redes locales y emparejadas: acceda a los servicios que se ejecutan en Azure

desde el entorno local a través del emparejamiento privado de ExpressRoute, los
túneles VPN y las redes virtuales emparejadas mediante puntos de conexión
privados. No es necesario configurar el emparejamiento de Microsoft para
 ExpressRoute ni atravesar Internet para llegar hasta el servicio. Private Link
proporciona una manera segura de migrar cargas de trabajo a Azure.

Protección contra la pérdida de datos: un punto de conexión privado se asigna a

una instancia de un recurso de PaaS en lugar de al servicio entero. Los
consumidores solo pueden conectarse al recurso específico. Se bloquea el acceso a
cualquier otro recurso del servicio. Este mecanismo proporciona protección contra
los riesgos de pérdida de datos.

Alcance global: conéctese de forma privada a los servicios que se ejecutan en

otras regiones. La red virtual del consumidor podría estar en la región A y puede
conectarse a los servicios que hay detrás de Private Link en la región B.

Ampliación de los propios servicios: habilite la misma experiencia y funcionalidad

para representar su servicio de forma privada para los consumidores de Azure. Al
colocar el servicio detrás de una instancia de Azure Load Balancer estándar, puede
habilitarlo para Private Link. Después, el consumidor puede conectarse
directamente al servicio mediante un punto de conexión privado en su propia red
virtual. Puede administrar las solicitudes de conexión mediante un flujo de
llamadas de aprobación. Azure Private Link funciona también para los
consumidores y servicios que pertenecen a distintos inquilinos de
Azure Active Directory.

７ Nota

Azure Private Link, junto con Azure Virtual Network, se extienden por Azure
Availability Zones y, por tanto, son resistentes a la zona. Para proporcionar alta
disponibilidad para el recurso de Azure mediante un punto de conexión privado,
asegúrese de que el recurso sea resistente a la zona.

Disponibilidad
Para información sobre los servicios de Azure que admiten Private Link, consulte
Disponibilidad de Azure Private Link.

Para ver las notificaciones más actualizadas, diríjase a la página de actualizaciones de

Azure Private Link .

Registro y supervisión
Azure Private Link está integrado con Azure Monitor. Esta combinación permite:
 El archivado de registros en una cuenta de almacenamiento.

Transmisión de eventos a Event Hubs.

El registro de Azure Monitor.

Puede tener acceso a la siguiente información sobre Azure Monitor:

Punto de conexión privado:

datos procesados por el punto de conexión privado (ENTRADA/SALIDA)

Servicio Private Link:

datos procesados por el servicio Private Link (ENTRADA/SALIDA)

Disponibilidad del puerto NAT

Precios
Para más información sobre los precios, consulte Precios de Azure Private Link .

Preguntas más frecuentes

Para ver las preguntas más frecuentes, consulte Preguntas más frecuentes sobre Azure
Private Link.

Límites
Para conocer los límites, consulte Límites de Azure Private Link.

Acuerdo de Nivel de Servicio

Para ver el Acuerdo de Nivel de Servicio, consulte SLA para Azure Private Link .

Pasos siguientes
Inicio rápido: Creación de un punto de conexión privado mediante Azure Portal

Inicio rápido: Creación de un servicio de Private Link mediante Azure Portal

Módulo de aprendizaje: Introducción a Azure Private Link

Puntos de conexión de servicio de red
virtual
Artículo • 27/10/2023

El punto de conexión de servicio de red virtual (VNet) proporciona conectividad directa

y segura con los servicios de Azure por medio de una ruta optimizada a través de la red
troncal de Azure. Los puntos de conexión permiten proteger los recursos de servicio de
Azure críticos únicamente para las redes virtuales. Los puntos de conexión de servicio
permiten a las direcciones IP privadas de la red virtual alcanzar el punto de conexión de
un servicio de Azure sin necesidad de una dirección IP pública en la red virtual.

７ Nota

Microsoft recomienda el uso de Azure Private Link y puntos de conexión privados

para el acceso seguro y privado a los servicios hospedados en la plataforma Azure.
Azure Private Link aprovisiona una interfaz de red en una red virtual de su elección
para los servicios de Azure, como Azure Storage o Azure SQL. Para obtener más
información, consulte Azure Private Link y ¿Qué es un punto de conexión
privado?.

Los puntos de conexión de servicio están disponibles para los servicios y las regiones
siguientes de Azure. El recurso Microsoft.* está entre paréntesis. Habilítelo desde la
subred mientras configura los puntos de conexión del servicio:

Disponibilidad general

Azure Storage (Microsoft.Storage): disponibilidad general en todas las regiones de

Azure.
Puntos de conexión de servicio entre regiones de Azure Storage
(Microsoft.Storage.Global): disponible con carácter general en todas las regiones de
Azure.
Azure SQL Database (Microsoft.Sql): disponibilidad general en todas las regiones
de Azure.
Azure Synapse Analytics (Microsoft.Sql): disponibilidad general en todas las
regiones de Azure para grupos de SQL dedicados (anteriormente, SQL DW).
Servidor de Azure Database for PostgreSQL (Microsoft.Sql): disponibilidad general
en las regiones de Azure en las que el servicio de base de datos esté disponible.
Servidor de Azure Database for MySQL (Microsoft.Sql): disponibilidad general en
las regiones de Azure en las que el servicio de base de datos esté disponible.
 Azure Database for MariaDB (Microsoft.Sql): disponibilidad general en las regiones
de Azure en las que el servicio de base de datos esté disponible.
Azure Cosmos DB (Microsoft.AzureCosmosDB): disponibilidad general en todas las
regiones de Azure.
Azure Key Vault (Microsoft.KeyVault): disponibilidad general en todas las regiones
de Azure.
Azure Service Bus (Microsoft.ServiceBus): disponibilidad general en todas las
regiones de Azure.
Azure Event Hubs (Microsoft.EventHub): disponibilidad general en todas las
regiones de Azure.
Azure Data Lake Store Gen 1 (Microsoft.AzureActiveDirectory): Disponible con
carácter general en todas las regiones de Azure donde ADLS Gen1 está disponible.
Azure App Service (Microsoft.Web): disponible con carácter general en todas las
regiones de Azure en que App Service esté disponible.
Azure Cognitive Services (Microsoft.CognitiveServices): Generalmente disponible en
todas las regiones Azure en las que están disponibles los servicios Azure AI.

Versión preliminar pública

Azure Container Registry (Microsoft.ContainerRegistry): Hay una versión preliminar

disponible en algunas de las regiones de Azure en que está disponible Azure
Container Registry.

Para conocer las notificaciones más actualizadas sobre, consulte la página

Actualizaciones de Azure Virtual Network .

Ventajas principales
Los puntos de conexión de servicio proporcionan las siguientes ventajas:

Seguridad mejorada para los recursos de servicio de Azure: Los espacios de

direcciones privadas de una red virtual pueden superponerse. No se pueden usar
espacios superpuestos para identificar de forma exclusiva el tráfico que parte de
una red virtual. Los puntos de conexión de servicio permiten proteger los recursos
de los servicios de Azure en la red virtual al ampliar la identidad de la red virtual al
servicio. Una vez que habilita puntos de conexión de servicio en su red virtual,
puede agregar una regla de red virtual para proteger los recursos de los servicios
de Azure en la red virtual. La adición de la regla proporciona una mayor seguridad,
ya que elimina totalmente el acceso público de Internet a los recursos y solo
permite el tráfico que procede de la red virtual.
 Enrutamiento óptimo para el tráfico del servicio de Azure desde la red virtual:
hoy, las rutas de la red virtual que fuerzan el tráfico de Internet a las aplicaciones
virtuales o locales también fuerzan al tráfico del servicio de Azure a que realice la
misma ruta que el tráfico de Internet. Los puntos de conexión de servicio
proporcionan un enrutamiento óptimo al tráfico de Azure.

Los puntos de conexión siempre llevan el tráfico del servicio directamente de la

red virtual al servicio en la red troncal de Microsoft Azure. Mantener el tráfico en la
red troncal de Azure permite seguir auditando y supervisando el tráfico saliente de
Internet desde las redes virtuales, a través de la tunelización forzada, sin que afecte
al tráfico del servicio. Para más información sobre las rutas definidas por el usuario
y la tunelización forzada, consulte Enrutamiento del tráfico de redes virtuales de
Azure.

Fácil de configurar con menos sobrecarga de administración: ya no necesita

direcciones IP públicas y reservadas en sus redes virtuales para proteger los
recursos de Azure a través de una dirección IP del firewall. No hay ningún
dispositivo NAT (traducción de direcciones de red) o de puerta de enlace necesario
para configurar los puntos de conexión de servicio. Estos se pueden configurar con
una selección individual en una subred. El mantenimiento de los puntos de
conexión no supone una sobrecarga adicional.

Limitaciones
Esta característica solo está disponible en las redes virtuales implementadas con el
modelo de implementación de Azure Resource Manager.
Los puntos de conexión están habilitados en subredes configuradas en redes
virtuales de Azure. No se pueden usar los puntos de conexión para el tráfico desde
los servicios locales a los servicios de Azure. Para más información, consulte
Protección del acceso de servicio de Azure desde el entorno local
Para Azure SQL, un punto de conexión de servicio solo se aplica al tráfico del
servicio de Azure dentro de la región de una red virtual.
En el caso de Azure Data Lake Storage (ADLS) Gen 1, la funcionalidad de
integración de red virtual solo está disponible para las redes sociales que se
encuentran dentro de la misma región. Tenga también en cuenta que la
integración de la red virtual en ADLS Gen1 usa la seguridad del punto de conexión
de servicio de red virtual entre la red virtual y Microsoft Entra ID para generar
notificaciones de seguridad adicionales en el token de acceso. Estas notificaciones
se usan entonces para autenticar la red virtual en la cuenta de Data Lake Storage
Gen1 y permitir el acceso. La etiqueta Microsoft.AzureActiveDirectory que aparece
debajo de los servicios que admiten puntos de conexión de servicios se usa solo
 para admitir puntos de conexión de servicios en ADLS Gen 1. Microsoft Entra id. no
admite puntos de conexión de servicio de forma nativa. Para más información
acerca de la integración de redes virtuales en Azure Data Lake Store Gen 1,
consulte Seguridad de red en Azure Data Lake Storage Gen1.
Una red virtual se puede asociar a hasta 200 suscripciones y regiones diferentes
por cada servicio admitido con reglas de red virtual activas configuradas.

Protección de servicios de Azure en redes

virtuales
Un punto de conexión de servicio de red virtual proporciona la identidad de la red
virtual al servicio de Azure. Una vez que habilita puntos de conexión de servicio en
su red virtual, puede agregar una regla de red virtual para proteger los recursos de
los servicios de Azure en la red virtual.

Actualmente, el tráfico del servicio de Azure desde una red virtual usa direcciones
IP públicas como direcciones IP de origen. Con los puntos de conexión de servicio,
el tráfico del servicio cambia para usar direcciones privadas de red virtual como la
direcciones IP de origen al acceder al servicio de Azure desde una red virtual. Este
modificador permite acceder a los servicios sin necesidad de direcciones IP
públicas y reservadas utilizadas en los firewalls IP.

７ Nota

Con los puntos de conexión de servicio, las direcciones IP de origen de las

máquinas virtuales en la subred para el tráfico de servicio pasan de utilizar
direcciones IPv4 públicas a utilizar direcciones IPv4 privadas. Las reglas
existentes de firewall de servicio de Azure que utilizan direcciones IP públicas
Azure dejarán de funcionar con este cambio. Asegúrese de que las reglas de
firewall del servicio de Azure permiten este cambio antes de configurar los
puntos de conexión de servicio. También es posible que experimente una
interrupción temporal del tráfico de servicio desde esta subred mientras
configura los puntos de conexión de servicio.

Protección del acceso de servicio de Azure

desde el entorno local
De forma predeterminada, a los recursos de los servicios de Azure protegidos en las
redes virtuales no se puede acceder desde redes locales. Si quiere permitir el tráfico
desde el entorno local, también debe permitir las direcciones IP públicas (normalmente
NAT) desde el entorno local o ExpressRoute. Estas direcciones IP se pueden agregar
mediante la configuración del firewall de IP para los recursos de los servicios de Azure.

ExpressRoute: Si usa ExpressRoute para el emparejamiento público o el emparejamiento

de Microsoft desde un entorno local, tendrá que identificar las direcciones IP de NAT
que va a usar. En el caso del emparejamiento público, cada circuito ExpressRoute usa de
forma predeterminada dos direcciones IP de NAT que se aplican al tráfico del servicio de
Azure cuando entra en la red troncal de Microsoft Azure. En el caso del emparejamiento
de Microsoft, las direcciones IP de NAT que se utilizan las proporcionan el cliente o el
proveedor de servicios. Para permitir el acceso a los recursos de servicio, tiene que
permitir estas direcciones IP públicas en la configuración del firewall de IP de
recursos. Para encontrar las direcciones de IP de circuito de ExpressRoute de los pares
públicos, abra una incidencia de soporte técnico con ExpressRoute a través de Azure
Portal. Para más información sobre NAT tanto para el emparejamiento de Microsoft
como para el emparejamiento público de ExpresRoute, consulte Requisitos de NAT de
ExpressRoute.
Configuración
Configure los puntos de conexión de servicio en una subred de una red virtual. Los
puntos de conexión funcionan con cualquier tipo de instancias de proceso que se
ejecute en esa subred.
Puede configurar varios puntos de conexión de servicio para todos los servicios de
Azure admitidos (por ejemplo, Azure Storage o Azure SQL Database) en una
subred.
Para Azure SQL Database, las redes virtuales deben estar en la misma región que el
recurso de servicio de Azure. En el caso de los restantes servicios, los recursos de
servicio de Azure se pueden proteger en las redes virtuales de cualquier región.
La red virtual donde se ha configurado el punto de conexión puede estar en la
misma suscripción o en otra distinta del recurso de servicio de Azure. Para más
información sobre los permisos necesarios para configurar los puntos de conexión
y proteger los servicios de Azure, consulte Aprovisionamiento.
Para los servicios compatibles, puede proteger los nuevos recursos o los recursos
existentes a las redes virtuales con puntos de conexión de servicio.

Consideraciones
Después de habilitar un punto de conexión de servicio, las direcciones IP de origen
pasan de utilizar las direcciones IPv4 públicas a usar su dirección IPv4 privada,
cuando se comunican con el servicio desde dicha subred. Las conexiones TCP
abiertas existentes en el servicio se cierran durante este cambio. Asegúrese de que
no se esté ejecutando ninguna tarea crítica al habilitar o deshabilitar un punto de
conexión de servicio en un servicio para una subred. Además, asegúrese de que las
aplicaciones pueden conectarse automáticamente a los servicios de Azure después
del cambio de dirección IP.

El cambio de dirección IP solo afecta el tráfico del servicio desde la red virtual. No
afecta a ningún otro tráfico entrante o saliente de las direcciones IPv4 públicas
asignadas a las máquinas virtuales. Para los servicios de Azure, si tiene reglas de
firewall existentes que usan direcciones IP públicas de Azure, estas reglas dejan de
funcionar con el cambio a las direcciones privadas de red virtual.

Con los puntos de conexión de servicio, las entradas DNS para los servicios de
Azure permanecen tal cual en la actualidad y siguen resolviendo las direcciones IP
públicas asignadas al servicio de Azure.

Grupos de seguridad de red (NSG) con puntos de conexión de servicio:

De forma predeterminada, los grupos de seguridad de red no solo permiten el
tráfico de Internet saliente, sino también el tráfico de su red virtual a los
 servicios de Azure. Este tráfico sigue funcionando con puntos de conexión de
servicio tal cual.
Si desea denegar todo el tráfico de Internet saliente y permitir únicamente el
tráfico a servicios de Azure concretos, puede hacerlo mediante las etiquetas de
servicio de sus grupos de seguridad de red. Puede especificar los servicios de
Azure compatibles como destino en las reglas de grupos de seguridad de red y
Azure también proporciona el mantenimiento de las direcciones IP subyacentes
en cada etiqueta. Para más información, consulte las etiquetas de servicio de
Azure para grupos de seguridad de red.

Escenarios
Redes virtuales emparejadas, conectadas o múltiples: para proteger los servicios
de Azure de varias subredes dentro de una red virtual o entre varias redes
virtuales, puede habilitar los puntos de conexión de servicio en cada una de las
subredes de manera independiente y proteger los recursos del servicio de Azure a
todas las subredes.
Filtrado de tráfico saliente desde una red virtual a los servicios de Azure: Si
desea inspeccionar o filtrar el tráfico enviado a un servicio de Azure desde una red
virtual, puede implementar una aplicación virtual de red dentro de la red virtual.
Después, puede aplicar los puntos de conexión de servicio a la subred donde se
implementa la aplicación virtual de red y se protegen los recursos de servicio de
Azure solo para esta subred. Este escenario puede resultar útil si desea usar el
filtrado de la aplicación virtual de red para restringir el acceso de los servicios de
Azure desde la red virtual solo a recursos concretos de Azure. Para más
información, consulte el artículo sobre la salida con las aplicaciones de redes
virtuales.
Protección de recursos de Azure con los servicios implementados directamente
en redes virtuales: puede implementar directamente varios servicios de Azure en
subredes concretas de una red virtual. Puede proteger los recursos de servicio de
Azure para subredes de servicio administrado mediante la configuración de un
punto de conexión de servicio en la subred de servicio administrada.
Tráfico de disco procedente de una máquina virtual de Azure: el tráfico de disco
de máquina virtual, tanto en discos administrados como no administrados, no
resulta afectado por los puntos de conexión de servicio que enrutan los cambios
en Azure Storage. Este tráfico no solo incluye la E/S de disco, sino también el
montaje y desmontaje. Puede limitar el acceso de REST a los blobs en páginas para
determinadas redes mediante puntos de conexión de servicio y reglas de red de
Azure Storage.
Registro y solución de problemas
Una vez que configure los puntos de conexión de servicio en un servicio concreto,
asegúrese de que la ruta del punto de conexión de servicio está en vigor de la forma
siguiente:

Valide la dirección IP de origen de todas las solicitudes de servicio en los

diagnósticos del servicio. Todas las nuevas solicitudes con puntos de conexión de
servicio muestran la dirección IP de origen de la solicitud como la dirección de red
virtual privada, asignada al cliente que realiza la solicitud desde la red virtual. Sin el
punto de conexión, la dirección es una dirección IP pública de Azure.
Visualice las rutas eficaces en cualquier interfaz de red de una subred. La ruta al
servicio:
Muestra una ruta predeterminada más específica a los intervalos de prefijos de
la dirección de cada servicio
Tiene una clase nextHopType de VirtualNetworkServiceEndpoint
Indica que está en vigor una conexión más directa al servicio, en comparación
con cualquier ruta de tunelización forzada

７ Nota

Las rutas del punto de conexión de servicio invalidan las rutas BGP para la
coincidencia del prefijo de dirección de un servicio de Azure. Para más información,
consulte el artículo en el que se indica cómo se solucionan problemas con redes
eficaces.

Aprovisionamiento
Un usuario con acceso de escritura a una red virtual puede configurar puntos de
conexión de servicio en redes virtuales de forma independiente. Para proteger los
recursos de los servicios de Azure en una red virtual, el usuario debe tener permiso en
Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action para las
subredes agregadas. Los roles de administrador de servicios integrados incluyen este
permiso de manera predeterminada. El permiso se puede modificar mediante la
creación de roles personalizados.

Para obtener más información sobre los roles integrados, consulte Roles integrados en
Azure. Para obtener más información sobre la asignación de permisos concretos a roles
personalizados, consulte Roles personalizados de Azure.
Las redes virtuales y los recursos de servicio de Azure pueden encontrarse en la misma o
en diferentes suscripciones. Algunos servicios de Azure (no todos), como Azure Storage
y Azure Key Vault, también admiten puntos de conexión de servicio en distintos
inquilinos de Active Directory (AD). Esto significa que la red virtual y el recurso del
servicio de Azure pueden estar en distintos inquilinos de Active Directory (AD). Para más
información, consulte la documentación del servicio individual.

Precios y límites
No se realiza ningún cargo adicional por el uso de puntos de conexión de servicio. El
modelo de precios vigente para los servicios de Azure (Azure Storage, Azure SQL
Database, etc.) se aplica tal cual.

No hay límite en el número total de puntos de conexión de servicio que puede tener
una red virtual.

Para determinados servicios de Azure (por ejemplo, cuentas de Azure Storage), puede
aplicar límites en el número de subredes que se usan para proteger el recurso. Para más
información, consulte la documentación de varios servicios en la sección Pasos
siguientes.

Directivas de punto de conexión de servicio de

una red virtual
Las directivas de punto de conexión de servicio de una red virtual permiten filtrar el
tráfico de la red virtual a los servicios de Azure. Este filtro solo permite determinados
recursos de servicio de Azure a través de puntos de conexión de servicio. Las directivas
de punto de conexión de servicio ofrecen un control de acceso pormenorizado para el
tráfico de red virtual a los servicios de Azure. Para más información, consulte Directivas
de punto de conexión de servicio de red virtual.

Preguntas más frecuentes

Consulte las preguntas más frecuentes acerca de los puntos de conexión de servicio de
red virtual.

Pasos siguientes
Configuración de los puntos de conexión de servicio de red virtual
Protección de una cuenta de Azure Storage para una red virtual
Protección de una instancia de Azure SQL Database para una red virtual
Establecimiento de una instancia de Azure Synapse Analytics a una red virtual
Comparación de puntos de conexión privados y puntos de conexión de servicio
Directivas de puntos de conexión de servicio de red virtual
Plantilla de Azure Resource Manager
Etiquetas de servicio de red virtual
Artículo • 25/03/2023

Una etiqueta de servicio representa un grupo de prefijos de direcciones IP de un servicio de

Azure determinado. Microsoft administra los prefijos de direcciones que la etiqueta de
servicio incluye y actualiza automáticamente dicha etiqueta a medida que las direcciones
cambian, lo que minimiza la complejidad de las actualizaciones frecuentes en las reglas de
seguridad de red.

Puede usar etiquetas de servicio para definir controles de acceso a la red en grupos de
seguridad de red, Azure Firewall y rutas definidas por el usuario. Use etiquetas de servicio en
lugar de direcciones IP específicas cuando cree reglas de seguridad y rutas. Al especificar el
nombre de la etiqueta de servicio, como ApiManagement, en el campo de origen o destino
apropiados de una regla de seguridad, puede permitir o denegar el tráfico del servicio
correspondiente. Si especifica el nombre de la etiqueta de servicio en el prefijo de dirección
de una ruta, puede enrutar el tráfico destinado a cualquiera de los prefijos encapsulados por
la etiqueta de servicio a un tipo de próximo salto deseado.

７ Nota

A partir de marzo de 2022, el uso de etiquetas de servicio en lugar de prefijos de

dirección explícitos en rutas definidas por el usuario está fuera de la versión preliminar y
tiene disponibilidad general.

Puede usar etiquetas de servicio para lograr el aislamiento de red y proteger los recursos de
Azure de Internet general mientras accede a los servicios de Azure que tienen puntos de
conexión públicos. Cree reglas de grupo de seguridad de red de entrada y salida para
denegar el tráfico hacia y desde Internet y permitir el tráfico desde y hacia AzureCloud u
otras etiquetas de servicio disponibles de servicios específicos de Azure.
Etiquetas de servicio disponibles
En la tabla siguiente se incluyen todas las etiquetas de servicio disponibles que se pueden
usar en reglas de grupos de seguridad de red.

Las columnas indican si la etiqueta:

Es adecuada para reglas que cubren el tráfico entrante o saliente.

Es compatible con el ámbito regional .
Se puede usar en las reglas de Azure Firewall como una regla de destino solo para el
tráfico entrante o saliente.

De forma predeterminada, las etiquetas de servicio reflejan los intervalos de toda la nube.
Algunas etiquetas de servicio también permiten un control más preciso, ya que restringen los
intervalos de direcciones IP correspondientes a una región especificada. Por ejemplo, la
etiqueta de servicio Storage representa a Azure Storage para toda la nube, pero
Storage.WestUS limita el rango solo a los intervalos de direcciones IP de almacenamiento de
la región Oeste de EE. UU. En la tabla siguiente se indica si cada etiqueta de servicio admite
este ámbito regional y la dirección que se indica para cada etiqueta es una recomendación.
Por ejemplo, la etiqueta AzureCloud se puede usar para permitir el tráfico de entrada. En la
mayoría de los escenarios, no se recomienda permitir el tráfico de todas las direcciones IP de
Azure, ya que las que usan otros clientes de Azure se incluyen como parte de la etiqueta de
servicio.
Etiqueta Propósito ¿Se ¿Puede ¿Se
puede ser puede
usar regional? usar con
para Azure
tráfico Firewall?
entrante
o
saliente?

ActionGroup Grupo de acciones. Entrada No Sí

ApiManagement Tráfico de administración para Entrada Sí Sí

implementaciones dedicadas de
Azure API Management.

Nota: Esta etiqueta representa

el punto de conexión de
servicio de API Management de
Azure para el plano de control
por región. Esta etiqueta
permite a los clientes realizar
operaciones de administración
en las API, operaciones,
directivas o valores con nombre
configurados en el servicio de
API Management.

ApplicationInsightsAvailability Disponibilidad de Application Entrada No Sí

Insights.

AppConfiguration App Configuration. Salida No Sí

AppService Azure App Service. Esta etiqueta Salida Sí Sí

se recomienda para reglas de
seguridad de salida a
aplicaciones de funciones y
aplicaciones web.

Nota: Esta etiqueta no incluye

direcciones IP asignadas al usar
SSL basado en IP (dirección
asignada por la aplicación).

AppServiceManagement Tráfico de administración para Ambos No Sí

las implementaciones dedicadas
a App Service Environment.

AutonomousDevelopmentPlatform Plataforma de desarrollo Ambos Sí Sí

autónomo

AzureActiveDirectory Azure Active Directory. Salida No Sí

AzureActiveDirectoryDomainServices Tráfico de administración para Ambos No Sí
las implementaciones dedicadas
a Azure Active Directory
Domain Services.

AzureAdvancedThreatProtection Azure Advanced Threat Salida No Sí

Protection

AzureArcInfrastructure Servidores habilitados para Salida No Sí

Azure Arc, Kubernetes
habilitado para Azure Arc y
tráfico de configuración de
invitado.

Nota: Esta etiqueta tiene una

dependencia de las etiquetas
AzureActiveDirectory,
AzureTrafficManager y
AzureResourceManager.

AzureAttestation Azure Attestation. Salida No Sí

AzureBackup Azure Backup. Salida No Sí

Nota: Esta etiqueta tiene una

dependencia de las etiquetas
Storage y
AzureActiveDirectory.

AzureBotService Azure Bot Service. Salida No Sí

AzureCloud Todos las direcciones IP Ambos Sí Sí

públicas del centro de
recursos . No incluye IPv6.
AzureCognitiveSearch Azure Cognitive Search. Entrada No Sí

Esta etiqueta o las direcciones

IP que cubre esta etiqueta se
pueden usar para conceder a
los indexadores un acceso
seguro a los orígenes de datos.
Para más información sobre los
indexadores, consulte la
documentación de conexión del
indexador.

Note: La IP del servicio de

búsqueda no se incluye en la
lista de intervalos IP para esta
etiqueta de servicio y también
se debe agregar al firewall de IP
de los orígenes de datos.

AzureConnectors Esta etiqueta representa las Ambos Sí Sí

direcciones IP que se usan para
los conectores administrados
que realizan devoluciones de
llamada de webhook entrantes
al servicio de Azure Logic Apps
y a las llamadas salientes a sus
servicios respectivos, por
ejemplo, Azure Storage o Azure
Event Hubs.

AzureContainerAppsService Servicio Azure Container Apps Ambos Sí No

AzureContainerRegistry Azure Container Registry. Salida Sí Sí

AzureCosmosDB Azure Cosmos DB. Salida Sí Sí

AzureDatabricks Azure Databricks. Ambos No Sí

AzureDataExplorerManagement Administración de Azure Data Entrada No Sí

Explorer.

AzureDataLake Azure Data Lake Storage Gen1. Salida No Sí

AzureDeviceUpdate Device Update for IoT Hub. Ambos No Sí

AzureDevSpaces Azure Dev Spaces. Salida No Sí

AzureDevOps Azure DevOps. Entrada Sí Sí

AzureDigitalTwins Azure Digital Twins. Entrada No Sí

Nota: Esta etiqueta o las

direcciones IP que abarca se
pueden utilizar para restringir el
acceso a los puntos de conexión
configurados para rutas de
eventos.

AzureEventGrid Azure Event Grid. Ambos No Sí

AzureFrontDoor.Frontend Azure Front Door. Ambos Sí Sí

AzureFrontDoor.Backend
AzureFrontDoor.FirstParty

AzureHealthcareAPIs Las direcciones IP cubiertas por Ambos No Sí

esta etiqueta se pueden usar
para restringir el acceso a Azure
Health Data Services.

AzureInformationProtection Azure Information Protection. Salida No Sí

Nota: Esta etiqueta tiene una

dependencia de las etiquetas
AzureActiveDirectory,
AzureFrontDoor.Frontend y
AzureFrontDoor.FirstParty.

AzureIoTHub Azure IoT Hub. Salida Sí Sí

AzureKeyVault Azure Key Vault. Salida Sí Sí

Nota: Esta etiqueta tiene una

dependencia de la etiqueta
AzureActiveDirectory.
AzureLoadBalancer Equilibrador de carga de la Ambos No No
infraestructura de Azure. La
etiqueta se traduce en la
dirección IP virtual del host
(168.63.129.16) donde se
originan los sondeos de
mantenimiento de Azure. Aquí
solo se incluye el tráfico de
sondeo, no el tráfico real al
recurso de back-end. Si no usa
Azure Load Balancer, puede
reemplazar esta regla.

AzureLoadTestingInstanceManagement Esta etiqueta de servicio se usa Entrada No Sí

para la conectividad entrante
desde el servicio Azure Load
Testing a las instancias de
generación de carga insertadas
en la red virtual del escenario
privado de prueba de carga.

Nota: Esta etiqueta está

pensada para usarse en Azure
Firewall, grupos de seguridad
de red, UDR y todas las demás
puertas de enlace de
conectividad entrante.

AzureMachineLearning Azure Machine Learning. Ambos No Sí

AzureManagedGrafana Punto de conexión de una Salida No Sí

instancia de Azure
Managed Grafana.
AzureMonitor Log Analytics, Application Salida No Sí
Insights, AzMon y métricas
personalizadas (puntos de
conexión GiG).

Nota: En Log Analytics, también

se requiere la etiqueta Storage.
Si se usan agentes de Linux,
también se requiere la etiqueta
GuestAndHybridManagement.

AzureOpenDatasets Azure Open Datasets. Salida No Sí

Nota: Esta etiqueta tiene una

dependencia de las etiquetas
AzureFrontDoor.Frontend y
Storage.

AzurePlatformDNS El servicio DNS de Salida No No

infraestructura básica
(predeterminado).

Puede usar esta etiqueta para

deshabilitar el DNS
predeterminado. Tenga cuidado
al usar esta etiqueta. Se
recomienda leer las
consideraciones sobre la
plataforma Azure. También se
recomienda realizar pruebas
antes de usar esta etiqueta.
AzurePlatformIMDS Azure Instance Metadata Salida No No
Service (IMDS), que es un
servicio de infraestructura
básico.

Puede usar esta etiqueta para

deshabilitar el IMDS
predeterminado. Tenga cuidado
al usar esta etiqueta. Se
recomienda leer las
consideraciones sobre la
plataforma Azure. También se
recomienda realizar pruebas
antes de usar esta etiqueta.

AzurePlatformLKM Servicio de administración de Salida No No

claves o licencias de Windows.

Puede usar esta etiqueta para

deshabilitar los valores
predeterminados para licencias.
Tenga cuidado al usar esta
etiqueta. Se recomienda leer las
consideraciones sobre la
plataforma Azure. También se
recomienda realizar pruebas
antes de usar esta etiqueta.

AzureResourceManager Azure Resource Manager. Salida No Sí

AzureSentinel Microsoft Sentinel. Entrada No Sí

AzureSignalR Azure SignalR. Salida No Sí

AzureSiteRecovery Azure Site Recovery. Salida No Sí

Nota: Esta etiqueta tiene una

dependencia de las etiquetas
AzureActiveDirectory,
AzureKeyVault, EventHub,
GuestAndHybridManagement
y Storage.
AzureSphere Esta etiqueta o las direcciones Ambos No Sí
IP que abarca se pueden utilizar
para restringir el acceso a los
servicios de seguridad de Azure
Sphere.

AzureSpringCloud Permitir el tráfico a las Salida No Sí

aplicaciones hospedadas en
Azure Spring Apps.

AzureStack Servicios de Azure Stack Bridge. Salida No Sí

Esta etiqueta representa el
punto de conexión de servicio
de Azure Stack Bridge por
región.

AzureTrafficManager Direcciones IP de sondeo de Entrada No Sí

Azure Traffic Manager.

En Preguntas más frecuentes

sobre Azure Traffic Manager,
puede encontrar más
información acerca de las
direcciones IP de sondeo de
Traffic Manager.
AzureUpdateDelivery Para acceder a Windows Salida No Sí
Update.

Nota: Esta etiqueta proporciona

acceso a los servicios de
metadatos de Windows Update.
Para descargar correctamente
las actualizaciones, también
debe habilitar la etiqueta de
servicio
AzureFrontDoor.FirstParty y
configurar las reglas de
seguridad de salida con el
protocolo y el puerto definidos
de la siguiente manera:

AzureUpdateDelivery:
TCP, puerto 443
AzureFrontDoor.FirstParty:
TCP, puerto 80

AzureWebPubSub AzureWebPubSub Ambos Sí Sí

BatchNodeManagement Tráfico de administración para Ambos Sí Sí

implementaciones dedicadas de
Azure Batch.

ChaosStudio Azure Chaos Studio. Ambos No Sí

Nota: Si ha habilitado la
integración de Application
Insights en el agente de Chaos,
también se requiere la etiqueta
AzureMonitor.

CognitiveServicesFrontend Los intervalos de direcciones Ambos No Sí

para el tráfico de los portales
frontend de Cognitive Services.

CognitiveServicesManagement Los intervalos de direcciones Ambos No Sí

para el tráfico para Azure
Cognitive Services.
DataFactory Azure Data Factory Ambos No Sí

DataFactoryManagement Tráfico de administración para Salida No Sí

Azure Data Factory.

Dynamics365ForMarketingEmail Los intervalos de direcciones del Ambos Sí Sí

servicio de correo electrónico
de marketing de Dynamics 365.

Dynamics365BusinessCentral Esta etiqueta o las direcciones Ambos No Sí

IP que abarca se pueden utilizar
para restringir el acceso a los
servicios de
Dynamics 365 Business Central
y desde aquí.

EOPExternalPublishedIPs Esta etiqueta representa las Ambos No Sí

direcciones IP usadas para
PowerShell del Centro de
seguridad y cumplimiento.
Consulte el módulo Conectarse
a PowerShell del Centro de
seguridad y cumplimiento
mediante el módulo EXO V2
para obtener más detalles.

EventHub Azure Event Hubs. Salida Sí Sí

GatewayManager Tráfico de administración para Entrada No No

implementaciones dedicadas a
Azure VPN Gateway y
Application Gateway.

GuestAndHybridManagement Azure Automation y Salida No Sí

Configuración de invitado

HDInsight HDInsight de Azure. Entrada Sí Sí

Internet Espacio de direcciones IP que se Ambos No No
encuentra fuera de la red virtual
y es accesible a través de la red
pública de Internet.

El intervalo de direcciones
incluye el espacio de
direcciones IP públicas
propiedad de Azure .

KustoAnalytics Kusto Analytics. Ambos No No

LogicApps Logic Apps. Ambos No Sí

LogicAppsManagement Tráfico de administración para Entrada No Sí

Logic Apps.

Marketplace Representa todo el conjunto de Ambos No Sí

servicios "Experiencias de
Marketplace comercial" de
Azure.

M365ManagementActivityApi La API de actividad de Salida Sí Sí

administración de Office 365
proporciona información sobre
varias acciones y eventos de
usuario, administrador, sistema
y directiva de los registros de
actividad de Office 365 y Azure
Active Directory. Los clientes y
asociados pueden usar esta
información para crear o
mejorar las soluciones de
supervisión de cumplimiento,
seguridad y operaciones
existentes para la empresa.

Nota: Esta etiqueta tiene una

dependencia de la etiqueta
AzureActiveDirectory.
M365ManagementActivityApiWebhook Las notificaciones se envían al Entrada Sí Sí
webhook configurado para una
suscripción a medida que el
nuevo contenido está
disponible.

MicrosoftAzureFluidRelay Esta etiqueta representa las Salida No Sí

direcciones IP usadas para
Azure Microsoft Fluid Relay
Server.
Nota: Esta etiqueta tiene
dependencia en la etiqueta
AzureFrontDoor.Frontend.

MicrosoftCloudAppSecurity Microsoft Defender for Cloud Salida No Sí

Apps.

MicrosoftContainerRegistry Registro de contenedor para Salida Sí Sí

imágenes de contenedor de
Microsoft.

Nota: Esta etiqueta tiene una

dependencia de la etiqueta
AzureFrontDoor.FirstParty.

MicrosoftDefenderForEndpoint Microsoft Defender para punto Ambos No Sí

de conexión

Tenga en cuenta que esta

etiqueta de servicio no está
disponible actualmente, se
encuentra en proceso. Lo
actualizaremos una vez que
esté lista para su uso.

MicrosoftPurviewPolicyDistribution Esta etiqueta debe usarse Salida No No

dentro de las reglas de
seguridad de salida para un
origen de datos (por ejemplo,
Azure SQL MI) configurado con
un punto de conexión privado
para recuperar directivas de
Microsoft Purview
PowerBI Power BI. Ambos No Sí

PowerPlatformInfra Esta etiqueta representa las Salida Sí Sí

direcciones IP usadas por la
infraestructura para hospedar
los servicios de Power Platform.

PowerPlatformPlex Esta etiqueta representa las Entrada Sí Sí

direcciones IP usadas por la
infraestructura para hospedar la
ejecución de la extensión de
Power Platform en nombre del
cliente.

PowerQueryOnline Power Query Online. Ambos No Sí

Service Bus Tráfico de Azure Service Bus que Salida Sí Sí

usa el nivel de servicio Premium.

ServiceFabric Azure Service Fabric. Ambos No Sí

Nota: Esta etiqueta representa

el punto de conexión de
servicio de Service Fabric para el
plano de control por región.
Esto permite a los clientes
realizar operaciones de
administración para sus
clústeres de Service Fabric
desde el punto de conexión de
su red virtual. (Por ejemplo,
https://
westus.servicefabric.azure.com).
Sql Azure SQL Database, Azure Salida Sí Sí
Database for MySQL, Azure
Database for PostgreSQL, Azure
Database for MariaDB y Azure
Synapse Analytics.

Nota: Esta etiqueta representa

el servicio, no instancias
específicas del mismo. Por
ejemplo, la etiqueta representa
el servicio Azure SQL Database,
pero no una cuenta de un
servidor o base de datos SQL
específicos. Esta etiqueta no se
aplica a SQL Managed Instance.

SqlManagement Tráfico de administración para Ambos No Sí

implementaciones dedicadas de
SQL.

Storage Azure Storage. Salida Sí Sí

Nota: Esta etiqueta representa

el servicio, no instancias
específicas del mismo. Por
ejemplo, la etiqueta representa
el servicio Azure Storage, pero
no una cuenta de específica de
este.

StorageSyncService Servicio de sincronización de Ambos No Sí

almacenamiento.

WindowsAdminCenter Permita que el servicio back- Salida No Sí

end de Windows Admin Center
se comunique con la instalación
de Windows Admin Center de
los clientes.

WindowsVirtualDesktop Azure Virtual Desktop Ambos No Sí

(anteriormente, Windows Virtual
Desktop).
VirtualNetwork El espacio de direcciones de red Ambos No No
virtual (todos los intervalos de
direcciones IP definidos para la
red virtual), todos los espacios
de direcciones locales
conectados, las redes virtuales
del mismo nivel, las redes
virtuales conectadas a una
puerta de enlace de red virtual,
la dirección IP virtual del host y
los prefijos de dirección usados
en las rutas definidas por el
usuario. Esta etiqueta también
puede contener rutas
predeterminadas.

７ Nota

Al usar etiquetas de servicio con Azure Firewall, solo puede crear reglas de destino
en el tráfico entrante y saliente. No se admiten reglas de origen. Para más
información, consulte el documento Etiquetas de servicio de Azure Firewall.

Las etiquetas de servicios de los servicios de Azure indican los prefijos de dirección
de la nube específica que se va a usar. Por ejemplo, los intervalos de direcciones IP
subyacentes que se corresponden con el valor de la etiqueta de Sql en la nube
pública de Azure serán distintos de los intervalos subyacentes en la nube de Azure
China.

Si implementa un punto de conexión de servicio de red virtual para un servicio,

como Azure Storage o Azure SQL Database, Azure agrega una ruta a una subred de
red virtual para el servicio. Los prefijos de dirección de la ruta son los mismos
prefijos de dirección, o intervalos CIDR, que los de la etiqueta de servicio
correspondiente.

Etiquetas admitidas en el modelo de implementación clásica

El modelo de implementación clásica (antes de Azure Resource Manager) admite un
subconjunto reducido de las etiquetas enumeradas en la tabla anterior. Las etiquetas del
modelo de implementación clásica se escriben de forma diferente, como se muestra en la
tabla siguiente:

Etiqueta de Resource Etiqueta correspondiente en el modelo de implementación

Manager clásica

AzureLoadBalancer AZURE_LOADBALANCER

Internet INTERNET

VirtualNetwork VIRTUAL_NETWORK

Etiquetas no admitidas para rutas definidas por el usuario

(UDR)
A continuación, se muestra una lista de etiquetas no admitidas actualmente para su uso con
rutas definidas por el usuario (UDR).

AzurePlatformDNS

AzurePlatformIMDS

AzurePlatformLKM

VirtualNetwork

AzureLoadBalancer

Internet

Etiquetas de servicio en un entorno local

Puede obtener información de intervalo y la etiqueta de servicio actual para incluirla como
parte de las configuraciones del firewall local. Esta información es la lista actual en un
momento dado de los intervalos de direcciones IP que corresponden a cada etiqueta de
servicio. Puede obtener la información mediante programación o a través de la descarga de
un archivo JSON, tal y como se describe en las secciones siguientes.

Uso de la API de detección de etiquetas de servicio

Puede recuperar mediante programación la lista actual de etiquetas de servicio, junto con los
detalles del intervalo de direcciones IP:

REST
 Azure PowerShell

CLI de Azure

Por ejemplo, para recuperar todos los prefijos de la etiqueta de servicio de Storage, puede
usar los siguientes cmdlets de PowerShell:

Azure PowerShell

$serviceTags = Get-AzNetworkServiceTag -Location eastus2

$storage = $serviceTags.Values | Where-Object { $_.Name -eq "Storage" }
$storage.Properties.AddressPrefixes

７ Nota

Los datos de la API representan las etiquetas que se pueden usar con reglas de
grupo de seguridad de red en su región. Use los datos de la API como origen de
verdad para las etiquetas de servicio disponibles, ya que pueden diferir del archivo
descargable JSON.
Los nuevos datos de la etiqueta de servicio tardan hasta 4 semanas en propagarse
en los resultados de la API en todas las regiones de Azure. Debido a este proceso,
los resultados de los datos de la API pueden no estar sincronizados con el archivo
JSON descargable, ya que los primeros representan un subconjunto de las
etiquetas que se encuentran actualmente en el archivo JSON descargable.
Debe estar autenticado y tener un rol con permisos de lectura para la suscripción
actual.

Detección de etiquetas de servicio mediante archivos JSON

descargables
Puede descargar archivos JSON que contengan la lista actual de etiquetas de servicio, junto
con los detalles del intervalo de direcciones IP. Estas listas se actualizan y publican
semanalmente. Las ubicaciones de cada nube son:

Azure público

Azure US Government

Azure China 21Vianet

Azure Alemania

Los intervalos de direcciones IP de estos archivos están en notación CIDR.

Las siguientes etiquetas de AzureCloud no tienen nombres regionales con formato según el
esquema normal:

AzureCloud.centralfrance (FranceCentral)

AzureCloud.southfrance (FranceSouth)

AzureCloud.germanywc (GermanyWestCentral)

AzureCloud.germanyn (GermanyNorth)

AzureCloud.norwaye (NorwayEast)

AzureCloud.norwayw (NorwayWest)

AzureCloud.switzerlandn (SwitzerlandNorth)

AzureCloud.switzerlandw (SwitzerlandWest)

AzureCloud.usstagee (EastUSSTG)

AzureCloud.usstagec (SouthCentralUSSTG)

 Sugerencia

Puede detectar actualizaciones de una publicación a la siguiente si observa los

valores changeNumber en aumento en el archivo JSON. Cada subsección (por
ejemplo, Storage.WestUS) tiene su propio changeNumber que se incrementa a
medida que se producen cambios. El nivel superior de changeNumber del archivo
aumenta cuando alguna de las subsecciones ha cambiado.

Para ver ejemplos de cómo analizar la información de la etiqueta de servicio (por

ejemplo, obtener todos los intervalos de direcciones para Storage en Oeste de EE.
UU.), consulte la documentación de PowerShell de Service Tag Discovery API.

Cuando se agreguen nuevas direcciones IP a las etiquetas de servicio, no se usarán

en Azure durante al menos una semana. Esto le proporciona tiempo para actualizar
cualquier sistema que pueda necesitar para realizar un seguimiento de las
direcciones IP asociadas a las etiquetas de servicio.

Pasos siguientes
Aprenda a crear un grupo de seguridad de red.
Base de referencia de seguridad de
Azure para Virtual Network
Artículo • 20/09/2023

Esta línea de base de seguridad aplica instrucciones de la versión 1.0 del banco de
pruebas de seguridad en la nube de Microsoft a Virtual Network. El punto de referencia
de seguridad en la nube de Microsoft proporciona recomendaciones sobre cómo puede
proteger sus soluciones de nube en Azure. El contenido se agrupa mediante los
controles de seguridad definidos por la prueba comparativa de seguridad de la nube de
Microsoft y las instrucciones relacionadas aplicables a Virtual Network.

Puede supervisar esta línea de base de seguridad y sus recomendaciones mediante

Microsoft Defender for Cloud. Azure Policy definiciones se mostrarán en la sección
Cumplimiento normativo de la página Microsoft Defender for Cloud Portal.

Cuando una característica tiene definiciones de Azure Policy relevantes, se muestran en

esta línea de base para ayudarle a medir el cumplimiento de los controles y
recomendaciones de las pruebas comparativas de seguridad en la nube de Microsoft.
Algunas recomendaciones pueden requerir un plan de Microsoft Defender de pago para
habilitar determinados escenarios de seguridad.

７ Nota

Se han excluido las características no aplicables a Virtual Network. Para ver cómo
Virtual Network se asigna completamente a la prueba comparativa de seguridad en
la nube de Microsoft, consulte el archivo completo de asignación de línea de base
de seguridad Virtual Network .

Perfil de seguridad
El perfil de seguridad resume los comportamientos de alto impacto de Virtual Network,
lo que puede dar lugar a un aumento de las consideraciones de seguridad.

Atributo de comportamiento del servicio Value

Categoría de productos Redes

El cliente puede acceder a HOST/OS. Sin acceso

El servicio se puede implementar en la red virtual del cliente. True

 Atributo de comportamiento del servicio Value

Almacena el contenido del cliente en reposo False

Seguridad de red
Para más información, consulte la prueba comparativa de seguridad en la nube de
Microsoft: Seguridad de red.

NS-1: Establecimiento de límites de segmentación de red

Características

Compatibilidad con grupos de seguridad de red

Descripción: el tráfico de red de servicio respeta la asignación de reglas de grupos de

seguridad de red en sus subredes. Más información.

Compatible Habilitado de forma predeterminada Responsabilidad de configuración

True True Microsoft

Guía de configuración: no se requieren configuraciones adicionales, ya que está

habilitada en una implementación predeterminada.

Referencia: Restricción del acceso de red a los recursos

Supervisión de Microsoft Defender for Cloud

Definiciones integradas de Azure Policy: Microsoft.Network:

Nombre Descripción Efectos Versión

(Azure Portal) (GitHub)

Las subredes Proteja la subred de posibles amenazas AuditIfNotExists, 3.0.0

deben estar mediante la restricción del acceso con un Disabled
asociadas con un grupo de seguridad de red (NSG). Estos
grupo de grupos contienen las reglas de la lista de
seguridad de red. control de acceso (ACL) que permiten o
deniegan el tráfico de red a la subred.
Administración de identidades
Para obtener más información, consulte La prueba comparativa de seguridad en la nube
de Microsoft: Administración de identidades.

IM-1: Uso de una identidad centralizada y un sistema de

autenticación

Características

Autenticación de Azure AD necesaria para el acceso al plano de

datos

Descripción: el servicio admite el uso de la autenticación de Azure AD para el acceso al

plano de datos. Más información.

Compatible Habilitado de forma predeterminada Responsabilidad de configuración

False No es aplicable No es aplicable

Guía de configuración: esta característica no se admite para proteger este servicio.

Acceso con privilegios

Para obtener más información, consulte la prueba comparativa de seguridad en la nube
de Microsoft: Acceso con privilegios.

PA-7: Seguimiento del principio de administración

suficiente (privilegios mínimos)

Características

RBAC de Azure para el plano de datos

Descripción: Azure Role-Based Access Control (Azure RBAC) se puede usar para
administrar el acceso a las acciones del plano de datos del servicio. Más información.
 Compatible Habilitado de forma predeterminada Responsabilidad de configuración

False No es aplicable No es aplicable

Guía de configuración: esta característica no se admite para proteger este servicio.

Protección de los datos

Para obtener más información, consulte La prueba comparativa de seguridad en la nube
de Microsoft: Protección de datos.

DP-3: Cifrado de datos confidenciales en tránsito

Características

Cifrado de los datos en tránsito

Descripción: el servicio admite el cifrado de datos en tránsito para el plano de datos.

Más información.

Compatible Habilitado de forma predeterminada Responsabilidad de configuración

False No es aplicable No es aplicable

Guía de configuración: esta característica no se admite para proteger este servicio.

Administración de recursos
Para obtener más información, consulte La prueba comparativa de seguridad en la nube
de Microsoft: Administración de recursos.

AM-2: Uso exclusivo de los servicios aprobados

Características

Compatibilidad con Azure Policy

Descripción: las configuraciones del servicio se pueden supervisar y aplicar a través de

Azure Policy. Más información.
 Compatible Habilitado de forma predeterminada Responsabilidad de configuración

True False Customer

Guía de configuración: use Microsoft Defender for Cloud para configurar Azure Policy
auditar y aplicar configuraciones de los recursos de Azure. Use Azure Monitor para crear
alertas cuando se detecte una desviación de la configuración en los recursos. Use Azure
Policy efectos [deny] e [deploy if not exists] para aplicar la configuración segura en los
recursos de Azure.

Referencia: Azure Policy definiciones integradas para Azure Virtual Network

Registro y detección de amenazas

Para obtener más información, consulte la prueba comparativa de seguridad en la nube
de Microsoft: Registro y detección de amenazas.

LT-4: Habilitación del registro para la investigación de

seguridad

Características

Registros de recursos de Azure

Descripción: el servicio genera registros de recursos que pueden proporcionar métricas

y registros específicos del servicio mejorados. El cliente puede configurar estos registros
de recursos y enviarlos a su propio receptor de datos, como una cuenta de
almacenamiento o un área de trabajo de Log Analytics. Más información.

Compatible Habilitado de forma predeterminada Responsabilidad de configuración

True False Customer

Guía de configuración: habilite los registros de recursos para el servicio. Por ejemplo,
Key Vault admite registros de recursos adicionales para acciones que obtienen un
secreto de un almacén de claves o Azure SQL tiene registros de recursos que realizan un
seguimiento de las solicitudes a una base de datos. El contenido de estos registros de
recurso varía según el servicio de Azure y el tipo de recurso.

Copia de seguridad y recuperación

Para obtener más información, consulte la prueba comparativa de seguridad en la nube
de Microsoft: Copia de seguridad y recuperación.

BR-1: Garantía de copias de seguridad automáticas

periódicas

Características

Azure Backup

Descripción: el servicio puede realizar una copia de seguridad del servicio Azure Backup.
Más información.

Compatible Habilitado de forma predeterminada Responsabilidad de configuración

False No es aplicable No es aplicable

Guía de configuración: esta característica no se admite para proteger este servicio.

Pasos siguientes
Consulte la introducción al banco de pruebas de seguridad en la nube de
Microsoft.
Obtenga más información sobre las líneas de base de seguridad de Azure.
Línea base de seguridad de Azure para
Azure NAT Gateway
Artículo • 20/09/2023

Esta línea base de seguridad aplica instrucciones de la versión 1.0 de La prueba

comparativa de seguridad en la nube de Microsoft a Azure NAT Gateway. El punto de
referencia de seguridad en la nube de Microsoft proporciona recomendaciones sobre
cómo puede proteger sus soluciones de nube en Azure. El contenido se agrupa
mediante los controles de seguridad definidos por la prueba comparativa de seguridad
en la nube de Microsoft y las instrucciones relacionadas aplicables a Azure NAT
Gateway.

Puede supervisar esta línea de base de seguridad y sus recomendaciones mediante

Microsoft Defender for Cloud. Azure Policy definiciones se mostrarán en la sección
Cumplimiento normativo de la página Microsoft Defender for Cloud Portal.

Cuando una característica tiene definiciones de Azure Policy relevantes, se muestran en

esta línea de base para ayudarle a medir el cumplimiento de los controles y
recomendaciones de las pruebas comparativas de seguridad en la nube de Microsoft.
Algunas recomendaciones pueden requerir un plan de Microsoft Defender de pago para
habilitar determinados escenarios de seguridad.

７ Nota

Se han excluido las características no aplicables a Azure NAT Gateway. Para ver
cómo Azure NAT Gateway se asigna por completo a la prueba comparativa de
seguridad en la nube de Microsoft, consulte el archivo completo de asignación de
línea de base de seguridad de Azure NAT Gateway .

Perfil de seguridad
El perfil de seguridad resume los comportamientos de alto impacto de Azure NAT
Gateway, lo que puede dar lugar a mayores consideraciones de seguridad.

Atributo de comportamiento del servicio Value

Categoría de productos Redes

El cliente puede acceder a HOST/OS. Sin acceso

 Atributo de comportamiento del servicio Value

El servicio se puede implementar en la red virtual del cliente. True

Almacena el contenido del cliente en reposo False

Seguridad de red
Para más información, consulte la prueba comparativa de seguridad en la nube de
Microsoft: Seguridad de red.

NS-1: Establecimiento de límites de segmentación de red

Características

Integración de Virtual Network

Descripción: el servicio admite la implementación en el Virtual Network privado (VNet)

del cliente. Más información.

Compatible Habilitado de forma predeterminada Responsabilidad de configuración

True False Customer

Guía de configuración: implemente el servicio en una red virtual. Asigne direcciones IP

privadas al recurso (si procede), a menos que haya un motivo seguro para asignar
direcciones IP públicas directamente al recurso.

Referencia: Inicio rápido: Creación de una puerta de enlace NAT mediante el Azure
Portal

Supervisión de Microsoft Defender for Cloud

Definiciones integradas de Azure Policy: Microsoft.Network:

Nombre Descripción Efectos Versión

(Azure Portal) (GitHub)

Las subredes Proteja la subred de posibles amenazas AuditIfNotExists, 3.0.0

deben estar mediante la restricción del acceso con un Disabled
asociadas con un grupo de seguridad de red (NSG). Estos
grupo de grupos contienen las reglas de la lista de
seguridad de red.
 Nombre control de acceso (ACL) que permiten o
Descripción Efectos Versión
(Azure Portal) deniegan el tráfico de red a la subred. (GitHub)

Administración de identidades
Para obtener más información, consulte La prueba comparativa de seguridad en la nube
de Microsoft: Administración de identidades.

IM-1: Uso de una identidad centralizada y un sistema de

autenticación

Características

Autenticación de Azure AD necesaria para el acceso al plano de

datos

Descripción: el servicio admite el uso de la autenticación de Azure AD para el acceso al

plano de datos. Más información.

Compatible Habilitado de forma predeterminada Responsabilidad de configuración

False No es aplicable No es aplicable

Guía de configuración: esta característica no se admite para proteger este servicio.

Administración de recursos
Para obtener más información, consulte La prueba comparativa de seguridad en la nube
de Microsoft: Administración de recursos.

AM-2: Uso exclusivo de los servicios aprobados

Características

Compatibilidad con Azure Policy

Descripción: las configuraciones de servicio se pueden supervisar y aplicar a través de

Azure Policy. Más información.
 Compatible Habilitado de forma predeterminada Responsabilidad de configuración

True False Customer

Guía de configuración: no hay ninguna guía actual de Microsoft para esta configuración
de características. Revise y determine si su organización quiere configurar esta
característica de seguridad.

Referencia: Directivas integradas- Red

Registro y detección de amenazas

Para más información, consulte la prueba comparativa de seguridad en la nube de
Microsoft: Registro y detección de amenazas.

LT-4: Habilitación del registro para la investigación de

seguridad

Características

Registros de recursos de Azure

Descripción: el servicio genera registros de recursos que pueden proporcionar métricas

y registros mejorados específicos del servicio. El cliente puede configurar estos registros
de recursos y enviarlos a su propio receptor de datos, como una cuenta de
almacenamiento o un área de trabajo de Log Analytics. Más información.

Compatible Habilitado de forma predeterminada Responsabilidad de configuración

False No es aplicable No es aplicable

Notas de características: el servicio proporciona otras funcionalidades de registro, como

métricas y registros de Insights.

Para más información, visite Métricas y alertas de Azure NAT Gateway.

Guía de configuración: esta característica no se admite para proteger este servicio.

Pasos siguientes
Consulte la introducción a la prueba comparativa de seguridad en la nube de
Microsoft.
Obtenga más información sobre las líneas de base de seguridad de Azure.
Integración de servicios de Azure con
redes virtuales para el aislamiento de
red
Artículo • 11/05/2023

La integración de Virtual Network para un servicio de Azure le permite bloquear el

acceso al servicio únicamente a la infraestructura de red virtual. La infraestructura de red
virtual también incluye redes virtuales del mismo nivel y redes locales.

La integración de red virtual proporciona a los servicios de Azure las ventajas del
aislamiento de red con uno o varios de los métodos siguientes:

Implementación de instancias dedicadas del servicio en una red virtual. Luego se

puede acceder de forma privada a los servicios dentro de la red virtual y desde
redes locales.

Usando un punto de conexión privado que le conecta de forma privada y segura a

un servicio con la tecnología de Azure Private Link. Los puntos de conexión
privados emplean una dirección IP privada de la red virtual, lo que hace que el
servicio se incluya en la red virtual.

Accediendo al servicio mediante puntos de conexión públicos mediante la

ampliación de una red virtual al servicio a través de los puntos de conexión de
servicio. Los puntos de conexión de servicio permiten que los recursos de servicio
se protejan en la red virtual.

Usando etiquetas de servicio para permitir o denegar el tráfico a los recursos de

Azure hacia y desde puntos de conexión de dirección IP pública.

Implementación de servicios de Azure

dedicados en las redes virtuales
Al implementar servicios de Azure dedicados en una red virtual, puede comunicarse con
los recursos de los servicios de forma privada mediante direcciones IP privadas.
La implementación de un servicio de Azure dedicado en una red virtual ofrece las
siguientes funcionalidades:

Los recursos dentro de la red virtual pueden comunicarse entre sí de forma privada
a través de direcciones IP privadas. Ejemplo: transferencia directa de datos entre
HDInsight y SQL Server que se ejecutan en una máquina virtual, en la red virtual.

Los recursos locales pueden acceder a recursos de una red virtual mediante
direcciones IP privadas a través de VPN de sitio a sitio (VPN Gateway) o
ExpressRoute.

Las redes virtuales pueden estar emparejadas para habilitar que los recursos de las
redes virtuales se comuniquen entre sí mediante direcciones IP privadas.

El servicio de Azure administra completamente las instancias de servicio en una red

virtual. Esta administración incluye la supervisión del estado de los recursos y el
escalado con carga.

Las instancias de los servicios se implementan en una subred de una red virtual. El
acceso de red entrante y saliente para la subred se debe abrir a través de grupos
de seguridad de red, siguiendo las instrucciones proporcionadas por el servicio.
 Determinados servicios imponen restricciones en la subred en la que están
implementados. Estas restricciones limitan la aplicación de directivas, rutas o la
combinación de máquinas virtuales y recursos de servicio dentro de la misma
subred. Compruebe las restricciones específicas de cada servicio porque podrían
cambiar con el tiempo. Algunos ejemplos de estos servicios son Azure NetApp
Files, Dedicated HSM, Azure Container Instances y App Service.

Opcionalmente, los servicios pueden requerir una subred delegada como un

identificador explícito de que una subred puede hospedar un servicio
determinado. Los servicios de Azure tienen permiso explícito para crear recursos
específicos del servicio en la subred delegada con delegación.

Vea un ejemplo de una respuesta de API REST en una red virtual con una subred
delegada. Puede ver una lista completa de los servicios que usan el modelo de
subred delegada a través de la API de Available Delegations.

Para obtener una lista de los servicios que se pueden implementar en una red virtual,
consulte Implementación de servicios de Azure dedicados en las redes virtuales.

Private Link con puntos de conexión privados

Los puntos de conexión privados permiten la entrada de tráfico desde la red virtual a un
recurso de Azure de forma segura. Este vínculo privado se establece sin que sean
necesarias las direcciones IP públicas. Un punto de conexión privado es una interfaz de
red especial para un servicio de Azure en la red virtual. Cuando se crea un punto de
conexión privado para el recurso, dicho punto de conexión privado proporciona
conectividad segura entre los clientes de la red virtual y el recurso de Azure. Al punto de
conexión privado se le asigna una dirección IP del intervalo de direcciones IP de su red
virtual. La conexión entre el punto de conexión privado y el servicio de Azure es un
vínculo privado.

En el diagrama, el lado derecho muestra una instancia de Azure SQL Database como
servicio PaaS de destino. El destino puede ser cualquier servicio que admita puntos de
conexión privados. Hay varias instancias de SQL Server lógico para varios clientes, a las
que se puede acceder a través de direcciones IP públicas.

En este caso, está expuesta una instancia de SQL Server lógico con un punto de
conexión privado. El punto de conexión hace que SQL Server sea accesible a través de
una dirección IP privada en la red virtual del cliente. Debido al cambio en la
configuración de DNS, la aplicación cliente ahora envía su tráfico directamente a ese
punto de conexión privado. El servicio de destino ve el tráfico que se origina desde una
dirección IP privada de la red virtual.
La flecha verde representa un vínculo privado. Todavía puede existir una dirección IP
pública para el recurso de destino junto con el punto de conexión privado. La aplicación
cliente ya no usa la dirección IP pública. El firewall ahora puede no permitir el acceso a
esa dirección IP pública, de modo que solo sea accesible a través de puntos de conexión
privados. Las conexiones a una instancia de SQL Server sin un punto de conexión
privado desde la red virtual se originan desde una dirección IP pública. La flecha azul
representa este flujo.

Normalmente, la aplicación cliente usa un nombre de host DNS para comunicarse con el
servicio de destino. No se necesita ningún cambio en la aplicación. La resolución DNS
de la red virtual debe configurarse para resolver ese mismo nombre de host en la
dirección IP privada del recurso de destino, en lugar de en la dirección IP pública
original. Con una ruta de acceso privada entre el cliente y el servicio de destino, el
cliente no depende de la dirección IP pública. El servicio de destino puede desactivar el
acceso público.

La exposición de instancias individuales permite evitar el robo de datos. Un actor

malintencionado no podrá recopilar información de la base de datos y cargarla en otra
base de datos pública o cuenta de almacenamiento. Puede impedir el acceso a las
direcciones IP públicas de todos los servicios PaaS. Todavía puede permitir el acceso a
instancias de PaaS a través de sus puntos de conexión privados.

Para obtener más información sobre el vínculo privado y una lista de los servicios de
Azure admitidos, consulte ¿Qué es Azure Private Link?

Puntos de conexión del servicio

Los puntos de conexión de servicio proporcionan conectividad segura y directa a los
servicios de Azure a través de la red troncal de Azure. Los puntos de conexión permiten
proteger los recursos de Azure únicamente para las redes virtuales. Los puntos de
conexión de servicio permiten que las direcciones IP privadas de la red virtual se
comuniquen con un servicio de Azure sin necesidad de una dirección IP pública saliente.

Sin los puntos de conexión de servicio, restringir el acceso solo a la red virtual puede ser
complicado. La dirección IP de origen podría cambiar o podría compartirse con otros
clientes. Por ejemplo, los servicios PaaS con direcciones IP salientes compartidas. Con
los puntos de conexión de servicio, la dirección IP de origen que ve el servicio de
destino se convierte en una dirección IP privada de la red virtual. Este cambio de tráfico
de entrada permite identificar fácilmente el origen y usarlo para configurar las reglas de
firewall adecuadas. Por ejemplo, para permitir solo el tráfico desde una subred
específica dentro de esa red virtual.

Con los puntos de conexión de servicio, las entradas DNS para los servicios de Azure
permanecen tal cual y siguen resolviendo las direcciones IP públicas asignadas al
servicio de Azure.

En el diagrama siguiente, el lado derecho es el mismo servicio PaaS de destino. A la

izquierda, está la red virtual de un cliente con dos subredes: la subred A, que tiene un
punto de conexión de servicio hacia Microsoft.Sql , y la subred B, que no tiene definido
ningún punto de conexión de servicio.

Cuando un recurso de la subred B intente comunicarse con cualquier instancia de

SQL Server, este usa una dirección IP pública para la comunicación saliente. La flecha
azul representa este tráfico. El firewall de SQL Server debe usar esa dirección IP pública
para permitir o bloquear el tráfico de red.

Cuando un recurso de la subred A intente llegar a un servidor de bases de datos, se ve

como una dirección IP privada desde dentro de la red virtual. Las flechas verdes
representan este tráfico. El firewall de SQL Server ahora puede permitir o bloquear
específicamente la subred A. No es necesario conocer la dirección IP pública del servicio
de origen.
Los puntos de conexión de servicio se aplican a todas las instancias del servicio de
destino. Por ejemplo, todas las instancias de SQL Server de los clientes de Azure, no solo
la instancia del cliente.

Para obtener más información, vea Puntos de conexión de servicio de red virtual.

Etiquetas de servicio
Una etiqueta de servicio representa un grupo de prefijos de direcciones IP de un servicio
de Azure determinado. Con las etiquetas de servicio, puede definir controles de acceso
a la red en grupos de seguridad de red o Azure Firewall. Puede permitir o denegar el
tráfico del servicio. Para permitir o denegar el tráfico, especifique la etiqueta de servicio
en el campo de origen o destino de una regla.
Logre el aislamiento de red y proteja los recursos de Azure de la red de Internet
mientras accede a los servicios de Azure que tienen puntos de conexión públicos. Cree
reglas de grupo de seguridad de red entrantes y salientes para denegar el tráfico hacia y
desde Internet y permitir el tráfico hacia y desde AzureCloud. Para más etiquetas de
servicio, consulte las etiquetas de servicio disponibles de los servicios específicos de
Azure.

Para más información sobre las etiquetas de servicio y los servicios de Azure
compatibles con ellas, consulte Etiquetas de servicio de red virtual.

Comparación de puntos de conexión privados y

puntos de conexión de servicio

７ Nota

Microsoft recomienda usar Azure Private Link. Private Link ofrece mejores
funcionalidades en términos de acceso privado a PaaS desde el entorno local, la
protección contra la filtración de datos integrada y el servicio de asignación a la
dirección IP privada en su propia red. Para más información, consulte Azure Private
Link.

En lugar de mirar solo sus diferencias, vale la pena señalar que tanto los puntos de
conexión de servicio como los puntos de conexión privados tienen características en
común.
Ambas características se usan para lograr control más detallado del firewall en el
servicio de destino. Por ejemplo, restringir el acceso a las bases de datos o cuentas de
almacenamiento de SQL Server. Sin embargo, cada uno se opera de manera diferente,
como se describe con más detalle en las secciones anteriores.

Ambos enfoques superan el problema del agotamiento de puertos de traducción de

direcciones de red de origen (SNAT). Puede que el agotamiento se presente al realizar la
tunelización del tráfico a través de una aplicación virtual de red (NVA) o un servicio con
limitaciones de puerto SNAT. Cuando se usan puntos de conexión de servicio o puntos
de conexión privados, el tráfico toma una ruta de acceso optimizada directamente al
servicio de destino. Ambos enfoques pueden beneficiar a las aplicaciones que
consumen mucho ancho de banda, ya que se reducen la latencia y el costo.

En ambos casos, todavía puede garantizar que el tráfico que entra en el servicio de
destino pasará a través de un firewall de red o NVA. Este procedimiento es diferente
para ambos enfoques. Cuando use puntos de conexión de servicio, debe configurar el
punto de conexión de servicio en la subred de firewall, en lugar de la subred en la que
está implementado el servicio de origen. Cuando se usan puntos de conexión privados,
se coloca una ruta definida por el usuario (UDR) para la dirección IP del punto de
conexión privado en la subred de origen. No en la subred del punto de conexión
privado.

Para comparar y comprender las diferencias, consulte la siguiente tabla.

Consideración Puntos de conexión de servicio Puntos de

conexión
privados

Ámbito de servicio en el Servicio completo (por ejemplo, todas las Instancia

que se aplica la instancias de SQL Server o las cuentas de individual (por
configuración almacenamiento de todos los clientes) ejemplo, una
instancia de SQL
Server o una
cuenta de
almacenamiento
de su
propiedad)
Consideración Puntos de conexión de servicio Puntos de
conexión
privados

Protección contra la No Sí
filtración de datos
integrada: capacidad de
que mover o copiar datos
desde un recurso de PaaS
protegido a otro recurso
de PaaS sin protección
por parte de un infiltrado
malintencionado.

Acceso privado al recurso No Sí

de PaaS desde el entorno
local

Configuración de NSG Sí (mediante etiquetas de servicio) No

necesaria para el acceso
al servicio

Se puede acceder al No Sí
servicio sin usar ninguna
dirección IP pública

El tráfico de Azure a Sí Sí
Azure permanece en la
red troncal de Azure

El servicio puede No Sí
deshabilitar su dirección
IP pública

Puede restringir Sí (permita el acceso desde subredes específicas o Sí

fácilmente el tráfico use NSG)
procedente de una
instancia de Azure Virtual
Network

Puede restringir N/D** Sí

fácilmente el tráfico
procedente de un
servidor local
(VPN/ExpressRoute)

Requiere cambios de No Sí (consulte la

DNS configuración
de DNS)
 Consideración Puntos de conexión de servicio Puntos de
conexión
privados

Afecta el costo de la No Sí (consulte los

solución precios del
vínculo
privado )

Afecta al Acuerdo de No Sí (el propio

Nivel de Servicio servicio del
compuesto de la solución vínculo privado
tiene un
Acuerdo de
Nivel de Servicio
del 99,99 % )

Configuración y Facilidad de configuración con menos sobrecarga Se requiere un

mantenimiento de administración. esfuerzo
adicional

Límites No hay límite en el número total de puntos de Sí (consulte los

conexión de servicio que puede tener una red límites de
virtual. Los servicios de Azure pueden aplicar Private Link )
límites en el número de subredes que se usan
para proteger el recurso. (consulte [preguntas más
frecuentes sobre redes virtuales](virtual-networks-
faq.md#are-there-any-limits-on-how-many-virtual
network-service-endpoints-i-can-set-up-from-my-
virtual network))

**No se puede acceder desde redes locales a los recursos de los servicios de Azure
protegidos en las redes virtuales. Si quiere permitir el tráfico desde el entorno local,
permita las direcciones IP públicas (normalmente NAT) desde el entorno local o
ExpressRoute. Estas direcciones IP se pueden agregar a través de la configuración del
firewall de IP para los recursos de los servicios de Azure. Para más información, consulte
preguntas más frecuentes sobre redes virtuales.

Pasos siguientes
Obtenga información sobre cómo integrar la aplicación con una red de Azure.

Obtenga información sobre cómo restringir el acceso a los recursos mediante

etiquetas de servicio.

Obtenga información sobre cómo conectarse de forma privada a una cuenta de

Azure Cosmos DB mediante Azure Private Link.
¿Qué es el cifrado de Azure Virtual
Network? (versión preliminar)
Artículo • 19/07/2023

El cifrado de Azure Virtual Network es una característica de las instancias de Azure

Virtual Network. El cifrado de red virtual permite cifrar y descifrar el tráfico sin
problemas entre Azure Virtual Machines.

Cada vez que el tráfico del cliente de Azure se mueve entre centros de datos, Microsoft
aplica un método de cifrado de capa de vínculo de datos con los estándares de
seguridad MACsec IEEE 802.1AE. Este cifrado se implementa para proteger el tráfico
fuera de los límites físicos no controlados por Microsoft o en nombre de Microsoft. Este
método se aplica desde un punto a otro en el hardware de red subyacente. El cifrado de
red virtual permite cifrar el tráfico entre Virtual Machines y Virtual Machine Scale Sets
dentro de la misma red virtual. También cifra el tráfico entre redes virtuales emparejadas
de forma regional y global. El cifrado de red virtual mejora el cifrado existente en las
funcionalidades de tránsito en Azure.

Para más información sobre el cifrado en Azure, consulte Introducción al cifrado de

Azure.

） Importante

Actualmente, el cifrado de Azure Virtual Network se encuentra en versión

preliminar pública. Esta versión preliminar se ofrece sin Acuerdo de Nivel de
Servicio y no se recomienda para cargas de trabajo de producción. Es posible que
algunas características no sean compatibles o que tengan sus funcionalidades
limitadas. Para más información, consulte Términos de uso complementarios de
las Versiones Preliminares de Microsoft Azure .

Requisitos
El cifrado de Virtual Network tiene los siguientes requisitos:

El cifrado de Virtual Network se admite en tamaños de instancia de máquina

virtual optimizados para memoria y de uso general, entre los que se incluyen:

Serie de VM SKU de la máquina virtual

Serie D Serie Dv4 y Dsv4, serie Ddv4 y Ddsv4, serie Dav4 y Dasv4
 Serie
Serie Ede VM SKU
Seriede
Ev4laymáquina virtual
Esv4, serie Edv4 y Edsv4, serie Eav4 y Easv4

Serie M Serie Mv2

Las redes aceleradas deben estar habilitadas en la interfaz de red de la máquina

virtual. Para más información sobre las redes aceleradas, consulte ¿Qué son las
redes aceleradas?

El cifrado solo se aplica al tráfico entre máquinas virtuales de una red virtual. El
tráfico se cifra desde una dirección IP privada a una dirección IP privada.

El emparejamiento global se admite en regiones en las que se admite el cifrado de

red virtual.

El tráfico a instancias de Virtual Machines no admitidas no es cifrado. Use los

registros de flujo de Virtual Network para confirmar el cifrado de flujo entre
máquinas virtuales. Para más información sobre los registros de flujo de
Virtual Network, consulte registros de flujo de Virtual Network.

Puede ser necesario iniciar o detener las máquinas virtuales existentes después de
habilitar el cifrado en una red virtual.

Disponibilidad
El cifrado de Azure Virtual Network está disponible en las siguientes regiones durante la
versión preliminar:

EUAP de Este de EE. UU. 2

EUAP del centro de EE. UU.

Centro-Oeste de EE. UU.

Este de EE. UU.

Este de EE. UU. 2

Oeste de EE. UU.

Oeste de EE. UU. 2

Para registrarse y obtener acceso a la versión preliminar pública, consulte Cifrado de

Virtual Network: registro en versión preliminar pública .
Limitaciones
El cifrado de Azure Virtual Network tiene las siguientes limitaciones durante la versión
preliminar pública:

En escenarios en los que interviene PaaS, la máquina virtual en la que se hospeda

PaaS determina si se admite el cifrado de red virtual. La máquina virtual debe
cumplir los requisitos enumerados.

Para el equilibrador de carga interno, todas las máquinas virtuales detrás del
equilibrador de carga deben ser un SKU de máquina virtual compatible.

Pasos siguientes
Para más información sobre las redes virtuales de Azure, vea ¿Qué es Azure Virtual
Network?
Preguntas frecuentes sobre el
cifrado de Azure Virtual Network
Preguntas más frecuentes

Aquí encontrará algunas respuestas a las preguntas comunes sobre el uso del cifrado de
Azure Virtual Network.

¿Puedo habilitar el cifrado de red virtual

en una red virtual existente, una
máquina virtual, una interfaz de red o
un grupo de seguridad de red?
Sí.

¿Cómo compruebo si mis datos están

cifrados?
La comprobación de cifrado se limita al estado del recurso de la interfaz de red,
vnetEncryptionSupported y las redes aceleradas durante la versión preliminar pública.
Después de la versión preliminar pública, los registros de flujo de red virtual se pueden
usar para ver los flujos cifrados y sin cifrar entre las máquinas virtuales.

¿Hay datos no cifrados?

Los paquetes fragmentados no se descargan en hardware y no se cifran. Use una MTU
de 1500 en la configuración de red de las máquinas virtuales.

¿Qué certificado se usa para el

establecimiento de DTLS en el host de
Azure?
Microsoft administra y ha creado certificados para cada región. Los certificados
proporcionados por el cliente son una característica en la hoja de ruta.
¿Cuál es el efecto de rendimiento?
Hay un efecto de rendimiento mínimo sobre el rendimiento o el ancho de banda. Las
operaciones criptográficas se descargan en una FPGA especializada en criptografía. El
efecto sobre una conexión inicial entre dos máquinas virtuales es mínimo porque es
necesario establecer un túnel.

¿Admite puerta de enlace VPN , puerta

de enlace de aplicación, Azure Firewall o
PaaS?
Depende del tamaño de la máquina virtual subyacente que usa PaaS y requiere que las
redes aceleradas estén habilitadas.

¿Dónde finaliza el cifrado?

El cifrado finaliza en SmartNIC/FPGA en el host de Azure.
Grupos de seguridad de red
Artículo • 27/10/2023

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 un
origen y destino, un puerto y un protocolo.

En este artículo se abordan las propiedades de una regla de grupo de seguridad de red,
las reglas de seguridad predeterminadas que se aplican y las propiedades de regla que
se pueden modificar para crear una regla de seguridad aumentada.

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 Cualquiera, una dirección IP individual, un bloque CIDR de enrutamiento entre

destino 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
 Propiedad Explicación

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 en Azure Portal, pero se pueden usar mediante plantillas
de ARM.

Dirección Si la regla se aplica al tráfico entrante o al saliente.

Intervalo Puede especificar un puerto individual o un intervalo de puertos. Por ejemplo,

de puertos 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 (origen, puerto de origen, destino, puerto de destino y 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.

Hay límites en el número de reglas de seguridad que puede crear en un grupo de

seguridad de red. Para más información, consulte el artículo acerca de los límites de
Azure.

Reglas de seguridad predeterminadas

Azure crea las siguientes reglas predeterminadas en cada grupo de seguridad de red
que cree:

Entrada

AllowVNetInBound

Priority Source Puertos de Destination Puertos de Protocolo Acceso

origen destino

65000 VirtualNetwork 0-65535 VirtualNetwork 0-65535 Any Allow

AllowAzureLoadBalancerInBound

Priority Source Puertos de Destination Puertos de Protocolo Acceso

origen destino

65001 AzureLoadBalancer 0-65535 0.0.0.0/0 0-65535 Any Allow

DenyAllInbound

Priority Source Puertos de Destination Puertos de Protocolo Acceso

origen destino

65500 0.0.0.0/0 0-65535 0.0.0.0/0 0-65535 Any Denegar

Salida

AllowVnetOutBound

Priority Source Puertos de Destination Puertos de Protocolo Acceso

origen destino

65000 VirtualNetwork 0-65535 VirtualNetwork 0-65535 Any Allow

AllowInternetOutBound
 Priority Source Puertos de Destination Puertos de Protocolo Acceso
origen destino

65001 0.0.0.0/0 0-65535 Internet 0-65535 Any Allow

DenyAllOutBound

Priority Source Puertos de Destination Puertos de Protocolo Acceso

origen destino

65500 0.0.0.0/0 0-65535 0.0.0.0/0 0-65535 Any Denegar

En las columnas Origen y Destino, VirtualNetwork, AzureLoadBalancer e Internet son

etiquetas de servicios, en lugar de direcciones IP. En la columna de protocolos,
Cualquiera abarca TCP, UDP e ICMP. Al crear una regla, puede especificar TCP, UDP,
ICMP o Cualquiera. 0.0.0.0/0 en las columnas Origen y Destino representa todas las
direcciones. Los clientes, como Azure Portal, la CLI de Azure o PowerShell, pueden usar *
o any en esta expresión.

Las reglas predeterminadas no se pueden quitar, pero puede reemplazarlas con reglas
de prioridad más alta.

Reglas de seguridad aumentada

Las reglas de seguridad aumentada permiten simplificar la definición de seguridad para
las redes virtuales, lo que le permitirá definir directivas de seguridad de red más grandes
y complejas, con menos reglas. Puede combinar varios puertos y varias direcciones IP
explícitas e intervalos en una única regla de seguridad de fácil comprensión. Use reglas
aumentadas en los campos de origen, destino y puerto de una regla. Para simplificar el
mantenimiento de la definición de la regla de seguridad, combine las reglas de
seguridad aumentada con etiquetas de servicio o grupos de seguridad de aplicaciones.
Hay límites en el número de direcciones, intervalos y puertos que se pueden especificar
en una regla. Para más información, consulte el artículo acerca de los límites de Azure.

Etiquetas de servicio

Una etiqueta de servicio representa un grupo de prefijos de direcciones IP de un servicio

de Azure determinado. Ayuda a minimizar la complejidad de las actualizaciones
frecuentes de las reglas de seguridad de red.

Para más información, consulte Etiquetas de servicio de Azure. Para ver un ejemplo de
cómo usar la etiqueta del servicio Storage para restringir el acceso a la red, consulte
Restricción del acceso de red a los recursos de PaaS.

Grupos de seguridad de aplicaciones

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. Para más información, consulte Grupos de seguridad de
aplicaciones.

Consideraciones de la plataforma Azure

Dirección IP virtual del nodo de host: los servicios de infraestructura básica, como
DHCP, DNS, IMDS y seguimiento de estado se proporcionan mediante las
direcciones IP de host virtualizadas 168.63.129.16 y 169.254.169.254. Estas
direcciones IP pertenecen a Microsoft y son la únicas direcciones IP virtualizadas
que se usarán en todas las regiones con este fin. De forma predeterminada, estos
servicios no están sujetos a los grupos de seguridad de red configurados a menos
que estén dirigidos por las etiquetas de servicio específicas de cada servicio. Para
invalidar esta comunicación de la infraestructura básica, puede crear una regla de
seguridad para denegar el tráfico usando las siguientes etiquetas de servicio en las
reglas del grupo de seguridad de red: AzurePlatformDNS, AzurePlatformIMDS,
AzurePlatformLKM. Aprenda sobre el diagnóstico del filtrado de tráfico de red y el
diagnóstico del enrutamiento de red.

Licencias (Servicio de administración de claves) : las imágenes de Windows que

se ejecutan en máquinas virtuales deben tener licencia. Para garantizar que se usen
licencias, se envía una solicitud a los servidores host del Servicio de administración
de claves que administran dichas consultas. La solicitud de salida se realiza a través
del puerto 1688. Para implementaciones que usan la configuración de la ruta
predeterminada 0.0.0.0/0, se deshabilitará esta regla de plataforma.

Máquinas virtuales en grupos de carga equilibrada: el puerto y el intervalo de

direcciones de origen aplicados proceden del equipo de origen, no del
equilibrador de carga. El puerto y el intervalo de direcciones de destino son los del
equipo de destino, no los del equilibrador de carga.

Instancias de servicio de Azure: instancias de varios servicios de Azure, como

HDInsight, App Service Environment y Virtual Machine Scale Sets, implementados
en subredes de la red virtual. Para ver una lista completa de los servicios que
puede implementar en redes virtuales, consulte el artículo sobre la Red virtual para
los servicios de Azure. Antes de aplicar un grupo de seguridad de red a la subred,
familiarícese con los requisitos de puerto para cada servicio. Si deniega los puertos
que el servicio requiere, este no funcionará correctamente.

Envío de correo electrónico saliente: Microsoft recomienda usar servicios de

retransmisión SMTP autenticados (que normalmente se conectan a través del
puerto TCP 587, pero a menudo también de otros) para enviar correo electrónico
desde Azure Virtual Machines. Los servicios de retransmisión SMTP se especializan
en la reputación del remitente, con el fin de minimizar la posibilidad de que
proveedores de correo electrónico de terceros rechacen los mensajes. Estos
servicios de retransmisión de SMTP incluyen Exchange Online Protection y
SendGrid, pero no se limitan a ellos. El uso de servicios de retransmisión de SMTP
no tiene ninguna restricción en Azure, independientemente del tipo de suscripción.

Si ha creado la suscripción a Azure antes del 15 de noviembre de 2017, además de

poder usar los servicios de retransmisión de SMTP, puede enviar el correo
electrónico directamente a través del puerto TCP 25. Si ha creado la suscripción
después del 15 de noviembre de 2017, es posible que no pueda enviar correo
electrónico directamente a través del puerto 25. El comportamiento de la
comunicación saliente a través del puerto 25 depende del tipo de suscripción que
tenga, como se indica a continuación:

Contrato Enterprise: en el caso de las máquinas virtuales implementadas en

suscripciones de Contrato Enterprise estándar, las conexiones SMTP salientes en
el puerto TCP 25 no se bloquearán. Sin embargo, no existen garantías de que
los dominios externos acepten los correos electrónicos entrantes de las
máquinas virtuales. Si los dominios externos rechazan o filtran los correos
electrónicos, tiene que ponerse en contacto con los proveedores de servicios de
correo electrónico de los dominios externos para resolver los problemas. Estos
problemas no están cubiertos por el Soporte técnico de Azure.

En el caso de las suscripciones de Desarrollo/pruebas - Enterprise, el puerto 25

está bloqueado de manera predeterminada. Es posible quitar el bloqueo. Para
solicitar que se quite el bloqueo, vaya a la sección No se puede enviar correo
(puerto SMTP 25) de la página de configuración Diagnosticar y solucionar de
un recurso de Azure Virtual Network en Azure Portal y ejecute el diagnóstico.
Esto excluirá automáticamente las suscripciones de desarrollo/pruebas
empresariales calificadas.

Después de que la suscripción quede exenta de este bloqueo y se hayan

detenido y reiniciado las VM, todas las VM de esa suscripción estarán exentas
 en el futuro. La exención solo se aplica a la suscripción solicitada, y al tráfico de
la VM que se enruta directamente a Internet.

Pago por uso: la comunicación saliente a través del puerto 25 está bloqueada
en todos los recursos. No se pueden realizar solicitudes para quitar la
restricción, ya que no se conceden solicitudes. Si necesita enviar correo
electrónico desde la máquina virtual, debe usar un servicio de retransmisión
SMTP.

MSDN, Pase para Azure, Azure bajo licencia Open, Education y evaluación
gratuita: La comunicación del puerto de salida 25 se bloquea en todos los
recursos. No se pueden realizar solicitudes para quitar la restricción, ya que no
se conceden solicitudes. Si necesita enviar correo electrónico desde la máquina
virtual, debe usar un servicio de retransmisión SMTP.

Proveedor de servicios en la nube: la comunicación saliente en el puerto 25

está bloqueada en todos los recursos. No se pueden realizar solicitudes para
quitar la restricción, ya que no se conceden solicitudes. Si necesita enviar correo
electrónico desde la máquina virtual, debe usar un servicio de retransmisión
SMTP.

Pasos siguientes
Para obtener información acerca de qué recursos de Azure se pueden implementar
en una red virtual y pueden tener grupos de seguridad de red asociados, consulte
Integración de redes virtuales para los servicios de Azure.
Para obtener información sobre cómo se evalúa el tráfico con grupos de seguridad
de red, consulte Funcionamiento de los grupos de seguridad de red.
Si nunca ha creado un grupo de seguridad de red, puede seguir un tutorial rápido
para obtener alguna experiencia en la creación de uno.
Si está familiarizado con los grupos de seguridad de red y necesita administrarlos,
consulte Administración de un grupo de seguridad de red.
Si tiene problemas con las comunicaciones y necesita solucionar problemas de los
grupos de seguridad de red, consulte Diagnóstico de un problema de filtro de
tráfico de red de una máquina virtual.
Aprenda a habilitar los registros de flujo de los grupos de seguridad de red para
analizar el tráfico de red hacia y desde los recursos que tienen un grupo de
seguridad de red asociado.
Cómo filtran el tráfico de red los grupos
de seguridad de red
Artículo • 04/05/2023

Puede usar el grupo de seguridad de red de Azure para filtrar el tráfico de red hacia y
desde 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 un origen y destino, un puerto y un protocolo.

Puede implementar recursos de varios servicios de Azure en una red virtual de Azure.
Para obtener una lista completa, consulte Servicios que se pueden implementar en una
red virtual. 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:

Observe la imagen anterior, junto con el siguiente texto, para entender cómo procesa
Azure las reglas entrantes y salientes 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 Subnet1
y VM1 está en Subnet1. 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 Subnet1.
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: dado que no hay ningún grupo de seguridad de red asociado a Subnet2, se
permite el tráfico en la subred y NSG2 lo procesa, porque NSG2 está asociado a la
interfaz de red conectada a VM3.

VM4: se permite el tráfico a VM4, porque no hay un grupo de seguridad de red

asociado a Subnet3 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: se envía todo el tráfico 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 porque no hay ningún grupo
de seguridad de red asociado a Subnet2.

VM4: se permite todo el tráfico de red desde VM4, porque no hay un grupo de
seguridad de red 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.

７ Nota

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. Para más información sobre los modelos de implementación de
Azure, consulte Descripción de los modelos de implementación de Azure.

 Sugerencia
 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.

Pasos siguientes
Para obtener información acerca de qué recursos de Azure se pueden implementar
en una red virtual y pueden tener grupos de seguridad de red asociados, consulte
Integración de redes virtuales para los servicios de Azure.

Si nunca ha creado un grupo de seguridad de red, puede seguir un tutorial rápido

para obtener alguna experiencia en la creación de uno.

Si está familiarizado con los grupos de seguridad de red y necesita administrarlos,

consulte Administración de un grupo de seguridad de red.

Si tiene problemas con las comunicaciones y necesita solucionar problemas de los

grupos de seguridad de red, consulte Diagnóstico de un problema de filtro de
tráfico de red de una máquina virtual.

Aprenda a habilitar los registros de flujo de los grupos de seguridad de red para
analizar el tráfico de red hacia y desde los recursos que tienen un grupo de
seguridad de red asociado.
Grupos de seguridad de aplicaciones
Artículo • 11/04/2023

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.

Priority Source Puertos de Destination Puertos de Protocolo Acceso

origen destino

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.

Priority Source Puertos de Destination Puertos de Protocolo Acceso

origen destino

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.

Priority Source Puertos de Destination Puertos de Protocolo Acceso

origen destino

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. Para más información, consulte el artículo acerca de los límites de
Azure.

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.

 Sugerencia

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.

Pasos siguientes
Aprenda a crear un grupo de seguridad de red.
Etiquetas de servicio de red virtual
Artículo • 25/03/2023

Una etiqueta de servicio representa un grupo de prefijos de direcciones IP de un servicio de

Azure determinado. Microsoft administra los prefijos de direcciones que la etiqueta de
servicio incluye y actualiza automáticamente dicha etiqueta a medida que las direcciones
cambian, lo que minimiza la complejidad de las actualizaciones frecuentes en las reglas de
seguridad de red.

Puede usar etiquetas de servicio para definir controles de acceso a la red en grupos de
seguridad de red, Azure Firewall y rutas definidas por el usuario. Use etiquetas de servicio en
lugar de direcciones IP específicas cuando cree reglas de seguridad y rutas. Al especificar el
nombre de la etiqueta de servicio, como ApiManagement, en el campo de origen o destino
apropiados de una regla de seguridad, puede permitir o denegar el tráfico del servicio
correspondiente. Si especifica el nombre de la etiqueta de servicio en el prefijo de dirección
de una ruta, puede enrutar el tráfico destinado a cualquiera de los prefijos encapsulados por
la etiqueta de servicio a un tipo de próximo salto deseado.

７ Nota

A partir de marzo de 2022, el uso de etiquetas de servicio en lugar de prefijos de

dirección explícitos en rutas definidas por el usuario está fuera de la versión preliminar y
tiene disponibilidad general.

Puede usar etiquetas de servicio para lograr el aislamiento de red y proteger los recursos de
Azure de Internet general mientras accede a los servicios de Azure que tienen puntos de
conexión públicos. Cree reglas de grupo de seguridad de red de entrada y salida para
denegar el tráfico hacia y desde Internet y permitir el tráfico desde y hacia AzureCloud u
otras etiquetas de servicio disponibles de servicios específicos de Azure.
Etiquetas de servicio disponibles
En la tabla siguiente se incluyen todas las etiquetas de servicio disponibles que se pueden
usar en reglas de grupos de seguridad de red.

Las columnas indican si la etiqueta:

Es adecuada para reglas que cubren el tráfico entrante o saliente.

Es compatible con el ámbito regional .
Se puede usar en las reglas de Azure Firewall como una regla de destino solo para el
tráfico entrante o saliente.

De forma predeterminada, las etiquetas de servicio reflejan los intervalos de toda la nube.
Algunas etiquetas de servicio también permiten un control más preciso, ya que restringen los
intervalos de direcciones IP correspondientes a una región especificada. Por ejemplo, la
etiqueta de servicio Storage representa a Azure Storage para toda la nube, pero
Storage.WestUS limita el rango solo a los intervalos de direcciones IP de almacenamiento de
la región Oeste de EE. UU. En la tabla siguiente se indica si cada etiqueta de servicio admite
este ámbito regional y la dirección que se indica para cada etiqueta es una recomendación.
Por ejemplo, la etiqueta AzureCloud se puede usar para permitir el tráfico de entrada. En la
mayoría de los escenarios, no se recomienda permitir el tráfico de todas las direcciones IP de
Azure, ya que las que usan otros clientes de Azure se incluyen como parte de la etiqueta de
servicio.
Etiqueta Propósito ¿Se ¿Puede ¿Se
puede ser puede
usar regional? usar con
para Azure
tráfico Firewall?
entrante
o
saliente?

ActionGroup Grupo de acciones. Entrada No Sí

ApiManagement Tráfico de administración para Entrada Sí Sí

implementaciones dedicadas de
Azure API Management.

Nota: Esta etiqueta representa

el punto de conexión de
servicio de API Management de
Azure para el plano de control
por región. Esta etiqueta
permite a los clientes realizar
operaciones de administración
en las API, operaciones,
directivas o valores con nombre
configurados en el servicio de
API Management.

ApplicationInsightsAvailability Disponibilidad de Application Entrada No Sí

Insights.

AppConfiguration App Configuration. Salida No Sí

AppService Azure App Service. Esta etiqueta Salida Sí Sí

se recomienda para reglas de
seguridad de salida a
aplicaciones de funciones y
aplicaciones web.

Nota: Esta etiqueta no incluye

direcciones IP asignadas al usar
SSL basado en IP (dirección
asignada por la aplicación).

AppServiceManagement Tráfico de administración para Ambos No Sí

las implementaciones dedicadas
a App Service Environment.

AutonomousDevelopmentPlatform Plataforma de desarrollo Ambos Sí Sí

autónomo

AzureActiveDirectory Azure Active Directory. Salida No Sí

AzureActiveDirectoryDomainServices Tráfico de administración para Ambos No Sí
las implementaciones dedicadas
a Azure Active Directory
Domain Services.

AzureAdvancedThreatProtection Azure Advanced Threat Salida No Sí

Protection

AzureArcInfrastructure Servidores habilitados para Salida No Sí

Azure Arc, Kubernetes
habilitado para Azure Arc y
tráfico de configuración de
invitado.

Nota: Esta etiqueta tiene una

dependencia de las etiquetas
AzureActiveDirectory,
AzureTrafficManager y
AzureResourceManager.

AzureAttestation Azure Attestation. Salida No Sí

AzureBackup Azure Backup. Salida No Sí

Nota: Esta etiqueta tiene una

dependencia de las etiquetas
Storage y
AzureActiveDirectory.

AzureBotService Azure Bot Service. Salida No Sí

AzureCloud Todos las direcciones IP Ambos Sí Sí

públicas del centro de
recursos . No incluye IPv6.
AzureCognitiveSearch Azure Cognitive Search. Entrada No Sí

Esta etiqueta o las direcciones

IP que cubre esta etiqueta se
pueden usar para conceder a
los indexadores un acceso
seguro a los orígenes de datos.
Para más información sobre los
indexadores, consulte la
documentación de conexión del
indexador.

Note: La IP del servicio de

búsqueda no se incluye en la
lista de intervalos IP para esta
etiqueta de servicio y también
se debe agregar al firewall de IP
de los orígenes de datos.

AzureConnectors Esta etiqueta representa las Ambos Sí Sí

direcciones IP que se usan para
los conectores administrados
que realizan devoluciones de
llamada de webhook entrantes
al servicio de Azure Logic Apps
y a las llamadas salientes a sus
servicios respectivos, por
ejemplo, Azure Storage o Azure
Event Hubs.

AzureContainerAppsService Servicio Azure Container Apps Ambos Sí No

AzureContainerRegistry Azure Container Registry. Salida Sí Sí

AzureCosmosDB Azure Cosmos DB. Salida Sí Sí

AzureDatabricks Azure Databricks. Ambos No Sí

AzureDataExplorerManagement Administración de Azure Data Entrada No Sí

Explorer.

AzureDataLake Azure Data Lake Storage Gen1. Salida No Sí

AzureDeviceUpdate Device Update for IoT Hub. Ambos No Sí

AzureDevSpaces Azure Dev Spaces. Salida No Sí

AzureDevOps Azure DevOps. Entrada Sí Sí

AzureDigitalTwins Azure Digital Twins. Entrada No Sí

Nota: Esta etiqueta o las

direcciones IP que abarca se
pueden utilizar para restringir el
acceso a los puntos de conexión
configurados para rutas de
eventos.

AzureEventGrid Azure Event Grid. Ambos No Sí

AzureFrontDoor.Frontend Azure Front Door. Ambos Sí Sí

AzureFrontDoor.Backend
AzureFrontDoor.FirstParty

AzureHealthcareAPIs Las direcciones IP cubiertas por Ambos No Sí

esta etiqueta se pueden usar
para restringir el acceso a Azure
Health Data Services.

AzureInformationProtection Azure Information Protection. Salida No Sí

Nota: Esta etiqueta tiene una

dependencia de las etiquetas
AzureActiveDirectory,
AzureFrontDoor.Frontend y
AzureFrontDoor.FirstParty.

AzureIoTHub Azure IoT Hub. Salida Sí Sí

AzureKeyVault Azure Key Vault. Salida Sí Sí

Nota: Esta etiqueta tiene una

dependencia de la etiqueta
AzureActiveDirectory.
AzureLoadBalancer Equilibrador de carga de la Ambos No No
infraestructura de Azure. La
etiqueta se traduce en la
dirección IP virtual del host
(168.63.129.16) donde se
originan los sondeos de
mantenimiento de Azure. Aquí
solo se incluye el tráfico de
sondeo, no el tráfico real al
recurso de back-end. Si no usa
Azure Load Balancer, puede
reemplazar esta regla.

AzureLoadTestingInstanceManagement Esta etiqueta de servicio se usa Entrada No Sí

para la conectividad entrante
desde el servicio Azure Load
Testing a las instancias de
generación de carga insertadas
en la red virtual del escenario
privado de prueba de carga.

Nota: Esta etiqueta está

pensada para usarse en Azure
Firewall, grupos de seguridad
de red, UDR y todas las demás
puertas de enlace de
conectividad entrante.

AzureMachineLearning Azure Machine Learning. Ambos No Sí

AzureManagedGrafana Punto de conexión de una Salida No Sí

instancia de Azure
Managed Grafana.
AzureMonitor Log Analytics, Application Salida No Sí
Insights, AzMon y métricas
personalizadas (puntos de
conexión GiG).

Nota: En Log Analytics, también

se requiere la etiqueta Storage.
Si se usan agentes de Linux,
también se requiere la etiqueta
GuestAndHybridManagement.

AzureOpenDatasets Azure Open Datasets. Salida No Sí

Nota: Esta etiqueta tiene una

dependencia de las etiquetas
AzureFrontDoor.Frontend y
Storage.

AzurePlatformDNS El servicio DNS de Salida No No

infraestructura básica
(predeterminado).

Puede usar esta etiqueta para

deshabilitar el DNS
predeterminado. Tenga cuidado
al usar esta etiqueta. Se
recomienda leer las
consideraciones sobre la
plataforma Azure. También se
recomienda realizar pruebas
antes de usar esta etiqueta.
AzurePlatformIMDS Azure Instance Metadata Salida No No
Service (IMDS), que es un
servicio de infraestructura
básico.

Puede usar esta etiqueta para

deshabilitar el IMDS
predeterminado. Tenga cuidado
al usar esta etiqueta. Se
recomienda leer las
consideraciones sobre la
plataforma Azure. También se
recomienda realizar pruebas
antes de usar esta etiqueta.

AzurePlatformLKM Servicio de administración de Salida No No

claves o licencias de Windows.

Puede usar esta etiqueta para

deshabilitar los valores
predeterminados para licencias.
Tenga cuidado al usar esta
etiqueta. Se recomienda leer las
consideraciones sobre la
plataforma Azure. También se
recomienda realizar pruebas
antes de usar esta etiqueta.

AzureResourceManager Azure Resource Manager. Salida No Sí

AzureSentinel Microsoft Sentinel. Entrada No Sí

AzureSignalR Azure SignalR. Salida No Sí

AzureSiteRecovery Azure Site Recovery. Salida No Sí

Nota: Esta etiqueta tiene una

dependencia de las etiquetas
AzureActiveDirectory,
AzureKeyVault, EventHub,
GuestAndHybridManagement
y Storage.
AzureSphere Esta etiqueta o las direcciones Ambos No Sí
IP que abarca se pueden utilizar
para restringir el acceso a los
servicios de seguridad de Azure
Sphere.

AzureSpringCloud Permitir el tráfico a las Salida No Sí

aplicaciones hospedadas en
Azure Spring Apps.

AzureStack Servicios de Azure Stack Bridge. Salida No Sí

Esta etiqueta representa el
punto de conexión de servicio
de Azure Stack Bridge por
región.

AzureTrafficManager Direcciones IP de sondeo de Entrada No Sí

Azure Traffic Manager.

En Preguntas más frecuentes

sobre Azure Traffic Manager,
puede encontrar más
información acerca de las
direcciones IP de sondeo de
Traffic Manager.
AzureUpdateDelivery Para acceder a Windows Salida No Sí
Update.

Nota: Esta etiqueta proporciona

acceso a los servicios de
metadatos de Windows Update.
Para descargar correctamente
las actualizaciones, también
debe habilitar la etiqueta de
servicio
AzureFrontDoor.FirstParty y
configurar las reglas de
seguridad de salida con el
protocolo y el puerto definidos
de la siguiente manera:

AzureUpdateDelivery:
TCP, puerto 443
AzureFrontDoor.FirstParty:
TCP, puerto 80

AzureWebPubSub AzureWebPubSub Ambos Sí Sí

BatchNodeManagement Tráfico de administración para Ambos Sí Sí

implementaciones dedicadas de
Azure Batch.

ChaosStudio Azure Chaos Studio. Ambos No Sí

Nota: Si ha habilitado la
integración de Application
Insights en el agente de Chaos,
también se requiere la etiqueta
AzureMonitor.

CognitiveServicesFrontend Los intervalos de direcciones Ambos No Sí

para el tráfico de los portales
frontend de Cognitive Services.

CognitiveServicesManagement Los intervalos de direcciones Ambos No Sí

para el tráfico para Azure
Cognitive Services.
DataFactory Azure Data Factory Ambos No Sí

DataFactoryManagement Tráfico de administración para Salida No Sí

Azure Data Factory.

Dynamics365ForMarketingEmail Los intervalos de direcciones del Ambos Sí Sí

servicio de correo electrónico
de marketing de Dynamics 365.

Dynamics365BusinessCentral Esta etiqueta o las direcciones Ambos No Sí

IP que abarca se pueden utilizar
para restringir el acceso a los
servicios de
Dynamics 365 Business Central
y desde aquí.

EOPExternalPublishedIPs Esta etiqueta representa las Ambos No Sí

direcciones IP usadas para
PowerShell del Centro de
seguridad y cumplimiento.
Consulte el módulo Conectarse
a PowerShell del Centro de
seguridad y cumplimiento
mediante el módulo EXO V2
para obtener más detalles.

EventHub Azure Event Hubs. Salida Sí Sí

GatewayManager Tráfico de administración para Entrada No No

implementaciones dedicadas a
Azure VPN Gateway y
Application Gateway.

GuestAndHybridManagement Azure Automation y Salida No Sí

Configuración de invitado

HDInsight HDInsight de Azure. Entrada Sí Sí

Internet Espacio de direcciones IP que se Ambos No No
encuentra fuera de la red virtual
y es accesible a través de la red
pública de Internet.

El intervalo de direcciones
incluye el espacio de
direcciones IP públicas
propiedad de Azure .

KustoAnalytics Kusto Analytics. Ambos No No

LogicApps Logic Apps. Ambos No Sí

LogicAppsManagement Tráfico de administración para Entrada No Sí

Logic Apps.

Marketplace Representa todo el conjunto de Ambos No Sí

servicios "Experiencias de
Marketplace comercial" de
Azure.

M365ManagementActivityApi La API de actividad de Salida Sí Sí

administración de Office 365
proporciona información sobre
varias acciones y eventos de
usuario, administrador, sistema
y directiva de los registros de
actividad de Office 365 y Azure
Active Directory. Los clientes y
asociados pueden usar esta
información para crear o
mejorar las soluciones de
supervisión de cumplimiento,
seguridad y operaciones
existentes para la empresa.

Nota: Esta etiqueta tiene una

dependencia de la etiqueta
AzureActiveDirectory.
M365ManagementActivityApiWebhook Las notificaciones se envían al Entrada Sí Sí
webhook configurado para una
suscripción a medida que el
nuevo contenido está
disponible.

MicrosoftAzureFluidRelay Esta etiqueta representa las Salida No Sí

direcciones IP usadas para
Azure Microsoft Fluid Relay
Server.
Nota: Esta etiqueta tiene
dependencia en la etiqueta
AzureFrontDoor.Frontend.

MicrosoftCloudAppSecurity Microsoft Defender for Cloud Salida No Sí

Apps.

MicrosoftContainerRegistry Registro de contenedor para Salida Sí Sí

imágenes de contenedor de
Microsoft.

Nota: Esta etiqueta tiene una

dependencia de la etiqueta
AzureFrontDoor.FirstParty.

MicrosoftDefenderForEndpoint Microsoft Defender para punto Ambos No Sí

de conexión

Tenga en cuenta que esta

etiqueta de servicio no está
disponible actualmente, se
encuentra en proceso. Lo
actualizaremos una vez que
esté lista para su uso.

MicrosoftPurviewPolicyDistribution Esta etiqueta debe usarse Salida No No

dentro de las reglas de
seguridad de salida para un
origen de datos (por ejemplo,
Azure SQL MI) configurado con
un punto de conexión privado
para recuperar directivas de
Microsoft Purview
PowerBI Power BI. Ambos No Sí

PowerPlatformInfra Esta etiqueta representa las Salida Sí Sí

direcciones IP usadas por la
infraestructura para hospedar
los servicios de Power Platform.

PowerPlatformPlex Esta etiqueta representa las Entrada Sí Sí

direcciones IP usadas por la
infraestructura para hospedar la
ejecución de la extensión de
Power Platform en nombre del
cliente.

PowerQueryOnline Power Query Online. Ambos No Sí

Service Bus Tráfico de Azure Service Bus que Salida Sí Sí

usa el nivel de servicio Premium.

ServiceFabric Azure Service Fabric. Ambos No Sí

Nota: Esta etiqueta representa

el punto de conexión de
servicio de Service Fabric para el
plano de control por región.
Esto permite a los clientes
realizar operaciones de
administración para sus
clústeres de Service Fabric
desde el punto de conexión de
su red virtual. (Por ejemplo,
https://
westus.servicefabric.azure.com).
Sql Azure SQL Database, Azure Salida Sí Sí
Database for MySQL, Azure
Database for PostgreSQL, Azure
Database for MariaDB y Azure
Synapse Analytics.

Nota: Esta etiqueta representa

el servicio, no instancias
específicas del mismo. Por
ejemplo, la etiqueta representa
el servicio Azure SQL Database,
pero no una cuenta de un
servidor o base de datos SQL
específicos. Esta etiqueta no se
aplica a SQL Managed Instance.

SqlManagement Tráfico de administración para Ambos No Sí

implementaciones dedicadas de
SQL.

Storage Azure Storage. Salida Sí Sí

Nota: Esta etiqueta representa

el servicio, no instancias
específicas del mismo. Por
ejemplo, la etiqueta representa
el servicio Azure Storage, pero
no una cuenta de específica de
este.

StorageSyncService Servicio de sincronización de Ambos No Sí

almacenamiento.

WindowsAdminCenter Permita que el servicio back- Salida No Sí

end de Windows Admin Center
se comunique con la instalación
de Windows Admin Center de
los clientes.

WindowsVirtualDesktop Azure Virtual Desktop Ambos No Sí

(anteriormente, Windows Virtual
Desktop).
VirtualNetwork El espacio de direcciones de red Ambos No No
virtual (todos los intervalos de
direcciones IP definidos para la
red virtual), todos los espacios
de direcciones locales
conectados, las redes virtuales
del mismo nivel, las redes
virtuales conectadas a una
puerta de enlace de red virtual,
la dirección IP virtual del host y
los prefijos de dirección usados
en las rutas definidas por el
usuario. Esta etiqueta también
puede contener rutas
predeterminadas.

７ Nota

Al usar etiquetas de servicio con Azure Firewall, solo puede crear reglas de destino
en el tráfico entrante y saliente. No se admiten reglas de origen. Para más
información, consulte el documento Etiquetas de servicio de Azure Firewall.

Las etiquetas de servicios de los servicios de Azure indican los prefijos de dirección
de la nube específica que se va a usar. Por ejemplo, los intervalos de direcciones IP
subyacentes que se corresponden con el valor de la etiqueta de Sql en la nube
pública de Azure serán distintos de los intervalos subyacentes en la nube de Azure
China.

Si implementa un punto de conexión de servicio de red virtual para un servicio,

como Azure Storage o Azure SQL Database, Azure agrega una ruta a una subred de
red virtual para el servicio. Los prefijos de dirección de la ruta son los mismos
prefijos de dirección, o intervalos CIDR, que los de la etiqueta de servicio
correspondiente.

Etiquetas admitidas en el modelo de implementación clásica

El modelo de implementación clásica (antes de Azure Resource Manager) admite un
subconjunto reducido de las etiquetas enumeradas en la tabla anterior. Las etiquetas del
modelo de implementación clásica se escriben de forma diferente, como se muestra en la
tabla siguiente:

Etiqueta de Resource Etiqueta correspondiente en el modelo de implementación

Manager clásica

AzureLoadBalancer AZURE_LOADBALANCER

Internet INTERNET

VirtualNetwork VIRTUAL_NETWORK

Etiquetas no admitidas para rutas definidas por el usuario

(UDR)
A continuación, se muestra una lista de etiquetas no admitidas actualmente para su uso con
rutas definidas por el usuario (UDR).

AzurePlatformDNS

AzurePlatformIMDS

AzurePlatformLKM

VirtualNetwork

AzureLoadBalancer

Internet

Etiquetas de servicio en un entorno local

Puede obtener información de intervalo y la etiqueta de servicio actual para incluirla como
parte de las configuraciones del firewall local. Esta información es la lista actual en un
momento dado de los intervalos de direcciones IP que corresponden a cada etiqueta de
servicio. Puede obtener la información mediante programación o a través de la descarga de
un archivo JSON, tal y como se describe en las secciones siguientes.

Uso de la API de detección de etiquetas de servicio

Puede recuperar mediante programación la lista actual de etiquetas de servicio, junto con los
detalles del intervalo de direcciones IP:

REST
 Azure PowerShell

CLI de Azure

Por ejemplo, para recuperar todos los prefijos de la etiqueta de servicio de Storage, puede
usar los siguientes cmdlets de PowerShell:

Azure PowerShell

$serviceTags = Get-AzNetworkServiceTag -Location eastus2

$storage = $serviceTags.Values | Where-Object { $_.Name -eq "Storage" }
$storage.Properties.AddressPrefixes

７ Nota

Los datos de la API representan las etiquetas que se pueden usar con reglas de
grupo de seguridad de red en su región. Use los datos de la API como origen de
verdad para las etiquetas de servicio disponibles, ya que pueden diferir del archivo
descargable JSON.
Los nuevos datos de la etiqueta de servicio tardan hasta 4 semanas en propagarse
en los resultados de la API en todas las regiones de Azure. Debido a este proceso,
los resultados de los datos de la API pueden no estar sincronizados con el archivo
JSON descargable, ya que los primeros representan un subconjunto de las
etiquetas que se encuentran actualmente en el archivo JSON descargable.
Debe estar autenticado y tener un rol con permisos de lectura para la suscripción
actual.

Detección de etiquetas de servicio mediante archivos JSON

descargables
Puede descargar archivos JSON que contengan la lista actual de etiquetas de servicio, junto
con los detalles del intervalo de direcciones IP. Estas listas se actualizan y publican
semanalmente. Las ubicaciones de cada nube son:

Azure público

Azure US Government

Azure China 21Vianet

Azure Alemania

Los intervalos de direcciones IP de estos archivos están en notación CIDR.

Las siguientes etiquetas de AzureCloud no tienen nombres regionales con formato según el
esquema normal:

AzureCloud.centralfrance (FranceCentral)

AzureCloud.southfrance (FranceSouth)

AzureCloud.germanywc (GermanyWestCentral)

AzureCloud.germanyn (GermanyNorth)

AzureCloud.norwaye (NorwayEast)

AzureCloud.norwayw (NorwayWest)

AzureCloud.switzerlandn (SwitzerlandNorth)

AzureCloud.switzerlandw (SwitzerlandWest)

AzureCloud.usstagee (EastUSSTG)

AzureCloud.usstagec (SouthCentralUSSTG)

 Sugerencia

Puede detectar actualizaciones de una publicación a la siguiente si observa los

valores changeNumber en aumento en el archivo JSON. Cada subsección (por
ejemplo, Storage.WestUS) tiene su propio changeNumber que se incrementa a
medida que se producen cambios. El nivel superior de changeNumber del archivo
aumenta cuando alguna de las subsecciones ha cambiado.

Para ver ejemplos de cómo analizar la información de la etiqueta de servicio (por

ejemplo, obtener todos los intervalos de direcciones para Storage en Oeste de EE.
UU.), consulte la documentación de PowerShell de Service Tag Discovery API.

Cuando se agreguen nuevas direcciones IP a las etiquetas de servicio, no se usarán

en Azure durante al menos una semana. Esto le proporciona tiempo para actualizar
cualquier sistema que pueda necesitar para realizar un seguimiento de las
direcciones IP asociadas a las etiquetas de servicio.

Pasos siguientes
Aprenda a crear un grupo de seguridad de red.
Directivas de punto de conexión de
servicio de red virtual para Azure
Storage
Artículo • 14/04/2023

Las directivas de punto de conexión de servicio de red virtual permiten filtrar el tráfico
de red virtual de salida a cuentas de Azure Storage a través de un punto de conexión de
servicio y habilitan la filtración de datos únicamente a cuentas específicas de Azure
Storage. Las directivas de punto de conexión ofrecen un control de acceso
pormenorizado para el tráfico de red virtual a Azure Storage al conectarse a través de
un punto de conexión de servicio.

Esta característica está disponible con carácter general para Azure Storage en todas las
regiones globales de Azure.

Ventajas principales
Las directivas de puntos de conexión de servicio de red virtual proporcionan las ventajas
siguientes:

Seguridad mejorada para el tráfico de red virtual a Azure Storage

 Las etiquetas de servicio de Azure para grupos de seguridad de red permiten
restringir el tráfico de salida de red virtual a regiones concretas de Azure Storage.
Sin embargo, este proceso permite el tráfico a cualquier cuenta dentro de la región
de Azure Storage seleccionada.

Las directivas de punto de conexión permiten especificar las cuentas de Azure

Storage a las que se permite el acceso de salida de red virtual y restringir el acceso
a todas las demás cuentas de almacenamiento. Este proceso proporciona un
control de seguridad mucho más pormenorizado para proteger el filtrado de datos
de la red virtual.

Directivas escalables y altamente disponibles para filtrar el tráfico del servicio de

Azure

Las directivas de punto de conexión proporcionan una solución horizontal

escalable y de alta disponibilidad para filtrar el tráfico de servicio de Azure desde
las redes virtuales, a través de los puntos de extremo de servicio. No se requiere
ninguna sobrecarga adicional para mantener los dispositivos de red central para
este tráfico en las redes virtuales.

Objeto JSON para directivas de punto de

conexión de servicio
Vamos a echar un vistazo rápido al objeto de directiva de punto de conexión de servicio.

JSON

"serviceEndpointPolicyDefinitions": [
{
"description": null,
"name": "MySEP-Definition",
"resourceGroup": "MySEPDeployment",
"service": "Microsoft.Storage",
"serviceResources": [

"/subscriptions/subscriptionID/resourceGroups/MySEPDeployment/providers/Micr
osoft.Storage/storageAccounts/mystgacc"
],
"type":
"Microsoft.Network/serviceEndpointPolicies/serviceEndpointPolicyDefinitions"
}
]

Configuración
Puede configurar las directivas de punto de conexión de modo que se restrinja el
tráfico de red virtual a cuentas específicas de Azure Storage.

La directiva de puntos de conexión se configura en una subred de una red virtual.

Los puntos de conexión de servicio de Azure Storage deben estar habilitados en la
subred para aplicar la directiva.

La directiva de punto de conexión permite agregar cuentas concretas de Azure

Storage a una lista de permitidos mediante el formato resourceID. Puede restringir
el acceso a:

Todas las cuentas de almacenamiento de una suscripción

E.g. /subscriptions/subscriptionId

Todas las cuentas de almacenamiento de un grupo de recursos

E.g. subscriptions/subscriptionId/resourceGroups/resourceGroupName

Una cuenta de almacenamiento individual al indicar el resourceId

correspondiente de Azure Resource Manager. Esto trata el tráfico a blobs,
tablas, colas, archivos y a Azure Data Lake Storage Gen2.
E.g.

/subscriptions/subscriptionId/resourceGroups/resourceGroupName/providers/Mi
crosoft.Storage/storageAccounts/storageAccountName

De forma predeterminada, si no hay directivas asociadas a una subred con puntos

de conexión, puede acceder a todas las cuentas de almacenamiento del servicio.
Una vez configurada una directiva en esa subred, solo se puede acceder a los
recursos especificados en la directiva desde las instancias de proceso de esa
subred. Se deniega el acceso a todas las demás cuentas de almacenamiento.

Al se aplican directivas de punto de conexión de servicio en una subred, el ámbito

del punto de conexión de servicio de Azure Storage se actualiza de regional a
global. Este proceso significa que todo el tráfico a Azure Storage se protege a
través del punto de conexión de servicio a partir de entonces. Las directivas de
punto de conexión de servicio también son aplicables globalmente. Se deniega el
acceso a las cuentas de almacenamiento que no están permitidas explícitamente.

Puede aplicar varias directivas a una subred. Cuando hay varias directivas
asociadas a la subred, se permite el tráfico de red virtual a los recursos
especificados en cualquiera de estas directivas. Se deniega el acceso a todos los
demás recursos del servicio, que no se estén especificados en ninguna de las
directivas.
 ７ Nota

Las directivas de punto de conexión de servicio son directivas de permiso, por lo

que, aparte de los recursos especificados, se restringen todos los demás recursos.
Asegúrese de que todas las dependencias de recursos de servicio de las
aplicaciones estén identificadas e indicadas en la directiva.

Solo las cuentas de almacenamiento que utilizan el modelo de recursos de Azure

pueden especificarse en la directiva de punto de conexión. Las cuentas de Azure
Storage clásicas no son compatibles con las directivas de punto de conexión de
servicio de Azure.

El acceso secundario a RA-GRS se permite automáticamente si la cuenta principal

aparece en la lista.

Las cuentas de almacenamiento pueden estar en la misma suscripción o en una

diferente o en un inquilino de Azure Active Directory que la red virtual.

Escenarios
Redes virtuales emparejadas, conectadas o múltiples: para filtrar el tráfico en
redes virtuales emparejadas, las directivas de punto de conexión deben aplicarse
individualmente a estas redes virtuales.

Filtrado del tráfico de Internet con dispositivos de red o Azure Firewall: filtre el
tráfico del servicio Azure con directivas, mediante puntos de conexión, y filtre el
resto del tráfico de Internet o Azure a través de dispositivos o de Azure Firewall.

Filtrado del tráfico en los servicios de Azure implementados en redes virtuales:

en este momento, las directivas de punto de conexión de servicio no son
compatibles con ningún servicio administrado de Azure que se implemente en la
red virtual.

Filtrado del tráfico a los servicios de Azure desde el entorno local: las directivas
de punto de conexión de servicio solo se aplican al tráfico de las subredes
asociadas a las directivas. Para permitir el acceso a recursos de servicio específicos
de Azure desde el entorno local, el tráfico debe filtrarse utilizando aplicaciones de
redes virtuales o firewalls.

Registro y solución de problemas

No se dispone de un registro centralizado para las directivas de punto de conexión de
servicio. Para los registros de recursos de servicio, consulte Registro de puntos de
conexión de servicio.

Escenarios de solución de problemas

Acceso denegado a las cuentas de almacenamiento que funcionaban en la versión
preliminar (no en región emparejada geográficamente)

Al actualizar Azure Storage para usar etiquetas de servicio globales, el ámbito

del punto de conexión de servicio y, por tanto, las directivas de punto de
conexión de servicio, ahora es Global. Por lo tanto, todo el tráfico a Azure
Storage se cifra mediante puntos de conexión de servicio y solo se permite el
acceso a las cuentas de almacenamiento que aparecen explícitamente en la
directiva.

Agregue a la lista de permitidos de forma explícita todas las cuentas de

almacenamiento necesarias para restaurar el acceso.

Póngase en contacto con el equipo de soporte técnico de Azure.

Se niega el acceso a las cuentas enumeradas en las directivas de punto de

conexión.

Los grupos de seguridad de red o el filtrado de firewall podrían estar

bloqueando el acceso.

Si al quitar o volver a aplicar la directiva se produce una pérdida de

conectividad:

Valide si el servicio Azure está configurado para permitir el acceso desde la

red virtual a través de puntos de conexión, o que la directiva predeterminada
del recurso esté establecida en Permitir todo.

Valide que los diagnósticos de servicio muestran el tráfico sobre los puntos
de conexión.

Compruebe si los registros de flujo de grupo de seguridad de red muestran

el acceso y que los registros de almacenamiento muestran el acceso, como
se esperaba, a los puntos de conexión de servicio.

Póngase en contacto con el equipo de soporte técnico de Azure.

Se niega el acceso a las cuentas no enumeradas en las directivas de punto de

conexión.
 Valide si Azure Storage está configurado para permitir el acceso desde la red
virtual a través de puntos de conexión, o si la directiva predeterminada del
recurso está establecida en Permitir todo.

Asegúrese de que las cuentas no sean cuentas de almacenamiento clásicas con

directivas de punto de conexión de servicio en la subred.

Un servicio de Azure administrado ha dejado de funcionar después de aplicar una

directiva de punto de conexión de servicio a través de la subred
Los servicios administrados que no son Azure SQL Managed Instance no se
admiten actualmente con puntos de conexión de servicio.

El acceso a las cuentas de almacenamiento administradas dejó de funcionar

después de aplicar una directiva de punto de conexión de servicio a través de la
subred
Las cuentas de almacenamiento administradas no son compatibles con las
directivas de punto de conexión de servicio. Si está configurado, las directivas
deniegan el acceso a todas las cuentas de almacenamiento administradas de
forma predeterminada. Si la aplicación necesita acceso a las cuentas de
almacenamiento administradas, no se deben usar directivas de punto de
conexión para este tráfico.

Aprovisionamiento
Un usuario con acceso de escritura a una red virtual configura directivas de punto de
conexión de servicio en subredes. Obtenga más información sobre los roles integrados
de Azure y la asignación de permisos específicos a roles personalizados.

Las redes virtuales y las cuentas de Azure Storage pueden encontrarse en la misma o en
diferentes suscripciones, o en inquilinos de Azure Active Directory.

Limitaciones
Solo puede implementar las directivas de punto de conexión de servicio en las
redes virtuales implementadas con el modelo de implementación de Azure
Resource Manager.

Las redes virtuales deben estar en la misma región que la directiva de punto de
conexión de servicio.

Solo puede aplicar la directiva de punto de conexión de servicio en una subred si

los puntos de conexión de servicio están configurados para los servicios de Azure
 enumerados en la directiva.

No puede utilizar las directivas de punto de conexión de servicio para el tráfico de

la red local a los servicios de Azure.

Los servicios administrados de Azure que no son Azure SQL Managed Instance no
admiten actualmente directivas de punto de conexión. Esta limitación incluye los
servicios administrados implementados en las subredes compartidas (como Azure
Batch, Azure AD DS, Azure Application Gateway, Azure VPN Gateway y Azure
Firewall) o en las subredes dedicadas (como Azure App Service Environment, Azure
Redis Cache, Azure API Management y los servicios administrados clásicos).

２ Advertencia

Los servicios de Azure implementados en la red virtual, como Azure HDInsight,

acceden a otros servicios de Azure, como Azure Storage, para saber los requisitos
de infraestructura. Restringir la directiva de punto de conexión a recursos
específicos podría interrumpir el acceso a estos recursos de infraestructura para los
servicios de Azure implementados en la red virtual.

No se admiten las cuentas de almacenamiento clásicas en las directivas de punto

de conexión. Las directivas deniegan el acceso a todas las cuentas de
almacenamiento clásicas de forma predeterminada. Si su aplicación necesita
acceso a Azure Resource Manager y a las cuentas de almacenamiento clásicas, las
directivas de punto de conexión no deben usarse para este tráfico.

Precios y límites
No se realiza ningún cargo adicional por el uso de directivas de puntos de conexión de
servicio. El modelo de precios vigente para los servicios de Azure (como Azure Storage)
se aplica tal cual, sobre los punto de conexión de servicio.

Los límites siguientes se aplican en las directivas de punto de conexión de servicio:

Resource Límite predeterminado

ServiceEndpointPoliciesPerSubscription 500

ServiceEndpointPoliciesPerSubnet 100

ServiceEndpointPoliciesPerVirtualNetwork 100

ServiceResourcesPerServiceEndpointPolicyDefinition 200
Pasos siguientes
Aprenda a configurar las directivas de puntos de conexión de servicio de red
virtual.

Aprenda más sobre los puntos de conexión de servicio de red virtual.

Directivas de red de Azure Kubernetes
Artículo • 29/03/2023

Las directivas de red proporcionan microsegmentación para pods del mismo modo que
los grupos de seguridad de red (NSG) proporcionan microsegmentación para máquinas
virtuales. La implementación de Azure Network Policy Manager admite la especificación
de directiva de red de Kubernetes estándar. Puede usar etiquetas para seleccionar un
grupo de pods y definir una lista de reglas de entrada y salida para filtrar tanto el tráfico
que llega a estos pods como el que sale de ellos. Obtenga más información sobre las
directivas de red de Kubernetes en la documentación de Kubernetes .

La implementación de Azure Network Policy Management funciona con Azure CNI que
proporciona integración de red virtual para contenedores. Network Policy Manager es
compatible con Linux y Windows Server. La implementación aplica el filtrado del tráfico
mediante la configuración de reglas de IP de permiso y denegación basadas en las
directivas definidas en Linux IPTables o ACLPolicies del servicio de red de host (HNS)
para Windows Server.

Planeación de seguridad para el clúster de

Kubernetes
Al implementar la seguridad del clúster, utilice grupos de seguridad red para filtrar el
tráfico que entra y sale de la subred del clúster (tráfico de norte a sur). Use Azure
Network Policy Manager para el tráfico entre los pods del clúster (tráfico de este a
oeste).

Usar Azure Network Policy Manager

Azure Network Policy Manager puede usarse de las siguientes formas para proporcionar
microsegmentación para los pods.

Azure Kubernetes Service (AKS)

Network Policy Manager está disponible de forma nativa en AKS y se puede habilitar en
el momento de la creación del clúster.

Para más información, consulte Protección del tráfico entre pods mediante directivas de
red en Azure Kubernetes Service (AKS).

Clústeres de Kubernetes personales (DIY) en Azure

En el caso de los clústeres DIY, en primer lugar, debe instalar el complemento de CNI y
habilitarlo en todas las máquinas virtuales de un clúster. Para instrucciones detalladas,
consulte Implementación del complemento para un clúster de Kubernetes que usted
mismo haya implementado.

Una vez implementado el clúster, ejecute el siguiente comando kubectl para descargar
y aplicar el daemonset de Azure Network Policy Manager en el clúster.

Para Linux:

kubectl apply -f https://raw.githubusercontent.com/Azure/azure-container-

networking/master/npm/azure-npm.yaml

Para Windows:

kubectl apply -f https://raw.githubusercontent.com/Azure/azure-container-

networking/master/npm/examples/windows/azure-npm.yaml

La solución también es de código abierto y el código está disponible en el repositorio

de redes de Azure Container .
Supervisión y visualización de configuraciones
de red con Azure NPM
Azure Network Policy Manager incluye métricas informativas de Prometheus que
permiten supervisar y comprender mejor las configuraciones. Proporciona
visualizaciones integradas en Azure Portal o en Grafana Labs. Puede empezar a recopilar
estas métricas mediante Azure Monitor o un servidor de Prometheus.

Ventajas de las métricas de Azure Network Policy

Manager
Anteriormente, los usuarios solo podían obtener información sobre su configuración de
red con los comandos iptables y ipset , que se ejecutaban en un nodo de clúster, lo
que genera una salida detallada y difícil de entender.

En general, las métricas proporcionan:

Recuentos de directivas, reglas de ACL, ipsets, entradas de ipset y entradas en

cualquier ipset determinado

Tiempos de ejecución para llamadas individuales del sistema operativo y para

controlar eventos de recursos de Kubernetes (mediana, percentil 90 y percentil 99)

Información de error para controlar eventos de recursos de Kubernetes (estos

eventos de recursos generarán un error cuando se produzca un error en una
llamada del sistema operativo)

Casos de uso de métricas de ejemplo

Alertas a través de AlertManager de Prometheus

Consulte una configuración para estas alertas a continuación.

1. Alerta cuando Network Policy Manager tiene un error con una llamada de sistema
operativo o al traducir una directiva de red.

2. Alerta cuando el tiempo medio de aplicación de cambios para un evento de

creación ha sido de más de 100 milisegundos.

Visualizaciones y depuración a través de nuestro panel de Grafana

o libro de Azure Monitor
 1. Vea cuántas reglas de IPTables crean las directivas (tener un gran número de reglas
de IPTables puede aumentar ligeramente la latencia).

2. Correlacione los recuentos de clústeres (por ejemplo, ACL) con los tiempos de
ejecución.

3. Obtenga el nombre descriptivo de un ipset en una regla IPTables determinada (por

ejemplo, azure-npm-487392 representa podlabel-role:database ).

Todas las métricas compatibles

A continuación se muestra una lista de métricas admitidas. Cualquier etiqueta quantile
tiene los valores posibles 0.5 , 0.9 y 0.99 . Cualquier etiqueta had_error tiene los
valores posibles false y true , que representa si la operación se realizó correctamente o
no.

Nombre de la métrica Descripción Tipo de Etiquetas

métrica de
Prometheus

npm_num_policies número de Indicador -

directivas
de red

npm_num_iptables_rules número de Indicador -

reglas de
IPTables

npm_num_ipsets número de Indicador -

IPSets

npm_num_ipset_entries número de Indicador -

entradas de
dirección IP
en todos los
IPSets

npm_add_iptables_rule_exec_time runtime Resumen quantile

para
agregar una
regla
IPTables

npm_add_ipset_exec_time runtime Resumen quantile

para
agregar un
IPSet
 Nombre de la métrica Descripción Tipo de Etiquetas
métrica de
Prometheus

npm_ipset_counts (avanzado) número de GaugeVec set_name & set_hash

entradas
dentro de
cada IPSet
individual

npm_add_policy_exec_time runtime Resumen quantile & had_error

para
agregar una
directiva de
red

npm_controller_policy_exec_time runtime Resumen quantile & had_error & operation

para (con valores update o delete )
actualizar o
eliminar una
directiva de
red

npm_controller_namespace_exec_time runtime Resumen quantile & had_error & operation

para crear, (con valores create , update o
actualizar o delete )
eliminar un
espacio de
nombres

npm_controller_pod_exec_time runtime Resumen quantile & had_error & operation

para crear, (con valores create , update o
actualizar o delete )
eliminar un
pod

Hay también las métricas "exec_time_count" y "exec_time_sum" para cada métrica de

resumen "exec_time".

Las métricas se pueden extraer mediante Azure Monitor para contenedores o mediante
Prometheus.

Configuración de Azure Monitor

El primer paso es habilitar Azure Monitor para contenedores para un clúster de
Kubernetes. Los pasos se pueden encontrar en Introducción a Azure Monitor para
contenedores. Una vez que Azure Monitor para contenedores está habilitado, configure
ConfigMap de Azure Monitor para contenedores para habilitar la integración de
Network Policy Manager y la recopilación de métricas de Network Policy Manager de
Prometheus.

ConfigMap Azure Monitor para contenedores tiene una sección integrations con la
configuración para recopilar métricas de Network Policy Manager.

Esta configuración está deshabilitada de forma predeterminada en ConfigMap. La

habilitación de la configuración básica collect_basic_metrics = true recopila métricas
básicas de Network Policy Manager. La habilitación de la configuración avanzada
collect_advanced_metrics = true recopila métricas avanzadas, además de las métricas
básicas.

Después de editar ConfigMap, guárdelo localmente y aplique ConfigMap al clúster

como se indica a continuación.

kubectl apply -f container-azm-ms-agentconfig.yaml

El siguiente fragmento de código de ConfigMap de Azure Monitor para contenedores

muestra la integración de Network Policy Manager habilitada con la recopilación de
métricas avanzadas.

integrations: |-
[integrations.azure_network_policy_manager]
collect_basic_metrics = false
collect_advanced_metrics = true

Las métricas avanzadas son opcionales y al activarlas, se activa automáticamente la

recopilación de métricas básicas. Actualmente, las métricas avanzadas solo incluyen
Network Policy Manager_ipset_counts .

Más información acerca de la configuración de la colección de la recopilación de Azure

Monitor para contenedores en ConfigMap.

Opciones de visualización para Azure Monitor

Una vez habilitada la recopilación de métricas de Network Policy Manager, estas se
pueden ver en Azure Portal mediante Container Insights o en Grafana.

Visualización en Azure Portal en la sección Información del clúster

Abra Azure Portal. Una vez en la sección Información del clúster, vaya a Libros y abra
Configuración de Network Policy Manager (NPM).

Además de ver el libro, también puede consultar directamente las métricas de

Prometheus en "Registros", en la sección Información. Por ejemplo, esta consulta
devuelve todas las métricas que se recopilan.

query

| where TimeGenerated > ago(5h)

| where Name contains "npm_"

También puede consultar las métricas directamente en Log Analytics. Para más
información, vea Introducción a las consultas de Log Analytics.

Visualización en un panel de Grafana

Configure un servidor de Grafana y un origen de datos de Log Analytics como se

describe aquí . Luego, importe el panel de Grafana con un back-end de Log
Analytics en Grafana Labs.

El panel tiene objetos visuales similares al libro de Azure. Puede agregar paneles para
crear gráficos & visualizar métricas de Network Policy Manager desde la tabla
InsightsMetrics.

Configuración del servidor de Prometheus

Algunos usuarios pueden optar por recopilar métricas con un servidor de Prometheus,
en lugar de con Azure Monitor para contenedores. Basta con agregar dos trabajos a la
configuración de rechazo para recopilar métricas de Network Policy Manager.

Para instalar un servidor de Prometheus, agregue este repositorio de Helm al clúster:

helm repo add stable https://kubernetes-charts.storage.googleapis.com

helm repo update

luego agregue un servidor

helm install prometheus stable/prometheus -n monitoring \

--set pushgateway.enabled=false,alertmanager.enabled=false, \
 --set-file extraScrapeConfigs=prometheus-server-scrape-config.yaml

donde prometheus-server-scrape-config.yaml consta de:

- job_name: "azure-npm-node-metrics"
metrics_path: /node-metrics
kubernetes_sd_configs:
- role: node
relabel_configs:
- source_labels: [__address__]
action: replace
regex: ([^:]+)(?::\d+)?
replacement: "$1:10091"
target_label: __address__
- job_name: "azure-npm-cluster-metrics"
metrics_path: /cluster-metrics
kubernetes_sd_configs:
- role: service
relabel_configs:
- source_labels: [__meta_kubernetes_namespace]
regex: kube-system
action: keep
- source_labels: [__meta_kubernetes_service_name]
regex: npm-metrics-cluster-service
action: keep
# Comment from here to the end to collect advanced metrics: number of
entries for each IPSet
metric_relabel_configs:
- source_labels: [__name__]
regex: npm_ipset_counts
action: drop

También puede reemplazar el trabajo azure-npm-node-metrics por el contenido que

aparece a continuación, o bien incorporarlo a un trabajo existente para pods de
Kubernetes:

- job_name: "azure-npm-node-metrics-from-pod-config"
metrics_path: /node-metrics
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_namespace]
regex: kube-system
action: keep
- source_labels: [__meta_kubernetes_pod_annotationpresent_azure_Network
Policy Manager_scrapeable]
action: keep
 - source_labels: [__address__]
action: replace
regex: ([^:]+)(?::\d+)?
replacement: "$1:10091"
target_label: __address__

Configuración de alertas para AlertManager

Si usa un servidor de Prometheus, puede configurar AlertManager de este modo. Esta es
una configuración de ejemplo para las dos reglas de alertas descritas anteriormente:

groups:
- name: npm.rules
rules:
# fire when Network Policy Manager has a new failure with an OS call or
when translating a Network Policy (suppose there's a scraping interval of
5m)
- alert: AzureNetwork Policy ManagerFailureCreatePolicy
# this expression says to grab the current count minus the count 5
minutes ago, or grab the current count if there was no data 5 minutes ago
expr: (npm_add_policy_exec_time_count{had_error='true'} -
(npm_add_policy_exec_time_count{had_error='true'} offset 5m)) or
npm_add_policy_exec_time_count{had_error='true'}
labels:
severity: warning
addon: azure-npm
annotations:
summary: "Azure Network Policy Manager failed to handle a policy
create event"
description: "Current failure count since Network Policy Manager
started: {{ $value }}"
# fire when the median time to apply changes for a pod create event is
more than 100 milliseconds.
- alert: AzurenpmHighControllerPodCreateTimeMedian
expr: topk(1,
npm_controller_pod_exec_time{operation="create",quantile="0.5",had_error="fa
lse"}) > 100.0
labels:
severity: warning
addon: azure-Network Policy Manager
annotations:
summary: "Azure Network Policy Manager controller pod create time
median > 100.0 ms"
# could have a simpler description like the one for the alert above,
# but this description includes the number of pod creates that were
handled in the past 10 minutes,
# which is the retention period for observations when calculating
quantiles for a Prometheus Summary metric
description: "value: [{{ $value }}] and observation count: [{{ printf
`(npm_controller_pod_exec_time_count{operation='create',pod='%s',had_error='
 false'} -
(npm_controller_pod_exec_time_count{operation='create',pod='%s',had_error='f
alse'} offset 10m)) or
npm_controller_pod_exec_time_count{operation='create',pod='%s',had_error='fa
lse'}` $labels.pod $labels.pod $labels.pod | query | first | value }}] for
pod: [{{ $labels.pod }}]"

Opciones de visualización para Prometheus

Cuando se usa un servidor de Prometheus, solo se admite el panel de Grafana.

Si aún no lo ha hecho, configure el servidor de Grafana y, después, un origen de datos

de Prometheus. Luego, importe nuestro panel de Grafana con un back-end de
Prometheus en Grafana Labs.

Los objetos visuales de este panel son idénticos los del panel con back-end de
información de Container Insights o Log Analytics.

Paneles de ejemplo
A continuación, encontrará un panel de ejemplo para las métricas de Network Policy
Manager en Container Insights (CI) y Grafana.

Resumen de recuentos de CI

Recuentos de CI con el paso del tiempo

 

Entradas de IPSet de CI

Cuantiles en tiempo de ejecución de CI

Resumen de recuentos del panel de Grafana

Recuentos del panel de Grafana a lo largo del tiempo

Entradas de IPSet del panel de Grafana


Cuantiles en tiempo de ejecución del panel de Grafana

Pasos siguientes
Obtenga más información acerca de Azure Kubernetes Service.

Obtenga más información acerca de redes de contenedores.

Implemente el complemento para clústeres de Kubernetes o contenedores de

Docker.
¿Qué es Azure DDoS Protection?
Artículo • 08/11/2023

Los ataques por denegación de servicio distribuido (DDoS) son uno de los problemas de
seguridad y disponibilidad más extendidos a los que se enfrentan los clientes que
mueven sus aplicaciones a la nube. Un ataque DDoS intenta agotar los recursos de una
aplicación haciendo que esta no esté disponible para los usuarios legítimos. Los ataques
DDoS pueden ir dirigidos a cualquier punto de conexión que sea públicamente
accesible a través de Internet.

Azure DDoS Protection, junto con los procedimientos recomendados de diseño de

aplicaciones, proporciona características mejoradas de mitigación DDoS para protegerse
de los ataques DDoS. Se ajusta automáticamente para proteger los recursos específicos
de Azure de una red virtual. La protección se puede habilitar fácilmente en cualquier red
virtual nueva o existente y no requiere cambios en las aplicaciones ni los recursos.

Azure DDoS Protection protege en capas de red de capa 3 y 4. Para la protección de

aplicaciones web en el nivel 7, deberá agregar protección en el nivel de aplicación
mediante una oferta de WAF. Para más información, consulte Protección contra DDoS
para aplicaciones.

Niveles

Protección de red contra DDoS

Protección de red contra DDoS de Azure, junto con los procedimientos recomendados
de diseño de aplicaciones, proporciona características mejoradas de mitigación DDoS
para protegerse de los ataques DDoS. Se ajusta automáticamente para proteger los
recursos específicos de Azure de una red virtual. Para más información sobre cómo
habilitar DDoS Network Protection, consulte Inicio rápido: Creación y configuración de
Azure DDoS Network Protection mediante Azure Portal.

Protección de IP contra DDoS

Protección de IP contra DDoS es un modelo de IP de pago por protección. Protección
de IP contra DDoS contiene las mismas características de ingeniería principales que
Protección de red contra DDoS, pero variará en los siguientes servicios de valor añadido:
compatibilidad con respuesta rápida de DDoS, protección de costos y descuentos en
WAF. Para más información sobre cómo habilitar Protección de IP contra DDoS, consulte
Inicio rápido: Creación y configuración de Protección de IP contra DDoS mediante Azure
PowerShell.

Para más información sobre los niveles, consulte Comparación de niveles de DDoS
Protection.

Principales características
Supervisión continua del tráfico: los patrones de tráfico de la aplicación se
supervisan de forma ininterrumpida en busca de indicadores de ataques DDoS.
Azure DDoS Protection mitiga instantánea y automáticamente el ataque, una vez
detectado.

Optimización en tiempo real adaptable: la generación de perfiles de tráfico

inteligente va conociendo con el tiempo el tráfico de la aplicación y selecciona y
actualiza el perfil que resulta más adecuado para el servicio. El perfil se ajusta a
medida que el tráfico cambia con el tiempo.

Análisis, métricas y alertas de DDoS Protection: Azure DDoS Protection aplica tres
políticas de mitigación autoajustadas (TCP SYN, TCP y UDP) para cada IP pública
del recurso protegido en la red virtual que tiene habilitado el DDoS. Los umbrales
de las directivas se configuran automáticamente con el sistema de generación de
perfiles de tráfico de red basado en aprendizaje automático. La mitigación de
DDoS se produce para una dirección IP que está siendo atacada solo cuando se
supera el umbral de la directiva.

Análisis de ataques: ofrece informes detallados en incrementos de cinco

minutos durante un ataque y un resumen completo después de que el ataque
termine. Transmita los registros del flujo de mitigación a Microsoft Sentinel o a
un sistema de administración de eventos e información de seguridad (SIEM) sin
 conexión para supervisar el sistema casi en tiempo real durante un ataque.
Consulte Visualización y configuración del registro de diagnóstico de DDoS para
obtener más información.

Métricas de ataques: con Azure Monitor se puede acceder a un resumen de

métricas de cada ataque. Consulte Visualización y configuración de la telemetría
de protección contra DDoS para más información.

Alertas de ataques: las alertas se pueden configurar en el inicio y la detención

de un ataque y a lo largo de la duración del ataque mediante métricas de
ataque integradas. Las alertas se integran en el software operativo, como los
registros de Microsoft Azure Monitor, Splunk, Azure Storage, el correo
electrónico y Azure Portal. Consulte Visualización y configuración de alertas de
protección contra DDoS para obtener más información.

Respuesta rápida de Azure DDoS: Durante un ataque activo, los clientes tienen
acceso al equipo de Respuesta rápida de DDoS (DRR), que puede ayudar con la
investigación de ataques durante un ataque y con el análisis posterior al ataque.
Para más información, consulte Respuesta rápida de Azure DDoS.

Integración de plataforma nativa: integrado de forma nativa en Azure. Incluye la

configuración a través de Azure Portal. Azure DDoS Protection entiende sus
recursos y la configuración de los mismos.

Protección inmediata: La configuración simplificada protege de inmediato todos

los recursos de una red virtual desde el momento en que se habilita la Protección
de red de DDoS. No se requiere intervención ni definición del usuario. De forma
similar, la configuración simplificada protege inmediatamente un recurso de
DIRECCIÓN IP pública cuando DDoS IP Protection está habilitado para él.

Protección de varias capas: Cuando se implementa con un firewall de aplicaciones

web (WAF), Azure DDoS Protection protege tanto en la capa de red (Capas 3 y 4,
que ofrece Azure DDoS Protection) como en la capa de la aplicación (Capa 7, que
ofrece un WAF). Entre las ofertas de WAF se incluyen la SKU de WAF de Application
Gateway de Azure, y ofertas de firewall de aplicaciones web de terceros
disponibles en Azure Marketplace .

Escala de mitigación amplia: Se pueden mitigar todos los vectores de ataque

L3/L4 con capacidad global para protegerse contra los ataques DDoS más
conocidos.

Garantía de costo: reciba crédito de servicio de escalabilidad horizontal de

aplicaciones y transferencia de datos para los costos de recursos en los que se
 incurre como resultado de ataques DDoS documentados.

Architecture
Azure DDoS Protection se ha diseñado para los servicios que se implementan en una
red virtual. Para otros servicios, se aplica la protección contra DDoS de nivel de
infraestructura predeterminada, que se defenderá frente a ataques comunes de nivel de
red. Para obtener más información sobre las arquitecturas admitidas, consulte
Arquitecturas de referencia de DDoS Protection.

Precios
En el caso de la protección de redes DDoS, bajo un inquilino, un único plan de
protección DDoS puede utilizarse en varias suscripciones, por lo que no es necesario
crear más de un plan de protección DDoS. Para DDoS IP Protection, no es necesario
crear un plan de protección contra DDoS. Los clientes pueden habilitar Protección de IP
contra DDoS en cualquier recurso de IP pública.

Para conocer los precios de Azure DDoS Protection, consulte los precios de Azure DDoS
Protection .

Procedimientos recomendados
Maximice la eficacia de la estrategia de protección contra DDoS y mitigación siguiendo
estos procedimientos recomendados:

Diseñe las aplicaciones y la infraestructura teniendo en cuenta la redundancia y la

resistencia.
Implemente un enfoque de seguridad multicapa, incluida la red, la aplicación y la
protección de datos.
Prepare un plan de respuesta a incidentes para garantizar una respuesta
coordinada a los ataques DDoS.

Para más información sobre los procedimientos recomendados, consulte

Procedimientos recomendados fundamentales.

Preguntas más frecuentes

Para ver las preguntas más frecuentes, consulte las preguntas más frecuentes de DDoS
Protection.
Pasos siguientes
Inicio rápido: Creación de un plan de protección contra DDoS
Módulo de Learn: Introducción a Azure DDoS Protection
Más información sobre la seguridad de red de Azure
TAP de red virtual
Artículo • 30/03/2023

） Importante

La versión preliminar de TAP de red virtual actualmente está en espera en todas las
regiones de Azure. Puede enviarnos un correo electrónico a
[email protected] con su identificador de suscripción y le
notificaremos las actualizaciones futuras sobre la versión preliminar. Mientras tanto,
puede usar soluciones basadas en agentes o NVA que proporcionen funcionalidad
de visibilidad de red o TAP a través de las soluciones de partners de agentes de
paquetes disponibles en las ofertas de Azure Marketplace .

Azure Virtual Network TAP (punto de acceso del terminal) permite transmitir
continuamente el tráfico de red de la máquina virtual a un recopilador de paquetes de
red o a una herramienta de análisis. Un asociado de la aplicación virtual de red
proporciona el recopilador o la herramienta de análisis de la herramienta. Para ver una
lista de soluciones de asociados que estén validadas para funcionar con Virtual Network
TAP, consulte las soluciones de asociados.

En el siguiente diagrama se muestra cómo funciona TAP de red virtual. Puede agregar
una configuración de TAP en una interfaz de red adjunta a una máquina virtual
implementada en la red virtual. El destino es una dirección IP de red virtual en la misma
red virtual que la interfaz de red supervisada o una red virtual emparejada. La solución
del recopilador para el punto de acceso de terminal de red virtual se puede
implementar detrás de un equilibrador de carga interno de Azure para lograr alta
disponibilidad.
Prerrequisitos
Para poder crear una red virtual TAP, asegúrese de que recibió el correo electrónico de
confirmación que está inscrito en la versión preliminar. Debe tener una o más máquinas
virtuales creadas con Azure Resource Manager y una solución asociada para agregar el
tráfico TAP en la misma región de Azure. Si no tiene ninguna solución de asociado en la
red virtual, consulte soluciones de asociados para implementar una.

Puede usar el mismo recurso de Virtual Red TAP para agregar tráfico de diferentes
interfaces de red en la misma suscripción o en suscripciones distintas. Si las interfaces
de red supervisadas se encuentran en suscripciones distintas, ambas suscripciones
deben estar asociadas al mismo inquilino de Azure Active Directory. Además, las
interfaces de red supervisadas y el punto de conexión de destino para agregar tráfico
del TAP pueden estar en redes virtuales emparejadas en la misma región. Si usa este
modelo de implementación, asegúrese de que el emparejamiento de red virtual está
habilitado antes de configurar un TAP de red virtual.

Permisos
Las cuentas que utiliza para aplicar la configuración del TAP en interfaces de red deben
estar asignadas al rol de colaborador de red o a un rol personalizado que tenga
asignadas las acciones necesarias de la tabla siguiente:

Acción Nombre

Microsoft.Network/virtualNetworkTaps/* Necesaria para crear, actualizar, leer y eliminar un

recurso de Virtual Network TAP

Microsoft.Network/networkInterfaces/read Necesaria para leer el recurso de interfaz de red en

el que está configurado el TAP.

Microsoft.Network/tapConfigurations/* Necesaria para crear, actualizar, leer y eliminar la

configuración del TAP en una interfaz de red

Soluciones de los partners de Virtual Network

TAP

Agentes de paquetes de red

GigaVUE Cloud Suite for Azure

CloudLens de Ixia

Prisms de Nubeva

Big Monitoring Fabric de Big Switch

Análisis de seguridad, administración del rendimiento de

red o de la aplicación
Awake Security

Cisco Stealthwatch Cloud

Darktrace

Reveal(x) de ExtraHop

Cybersecurity de Fidelis

Flowmon

NetFort LANGuardian
 vSTREAM de Netscout

Seguridad de Noname

Riverbed SteelCentral AppResponse

NetWitness® Platform de RSA

Cognito de Vectra

Pasos siguientes
Obtenga información sobre cómo crear un Virtual Network TAP.
Controles de cumplimiento normativo de
Azure Policy para Azure Virtual Network
Artículo • 02/01/2024

Cumplimiento normativo de Azure Policy proporciona definiciones de iniciativas creadas y

administradas por Microsoft, conocidas como integraciones, para los dominios de
cumplimiento y los controles de seguridad relativos a distintos estándares de
cumplimiento. En esta página se enumeran los dominios de cumplimiento y los controles
de seguridad para Azure Virtual Network. Para que los recursos de Azure sean compatibles
con el estándar específico, puede asignar las integraciones a un control de seguridad de
manera individual.

El título de cada definición de directiva integrada se vincula a la definición de directiva en

Azure Portal. Use el vínculo de la columna Versión de directiva para ver el origen en el
repositorio de GitHub de Azure Policy .

） Importante

Cada control está asociado a una o varias definiciones de Azure Policy. Estas directivas
pueden ayudarle a evaluar el cumplimiento con el control. Sin embargo, con
frecuencia no hay una correspondencia completa o exacta entre un control y una o
varias directivas. Como tal, el término cumplimiento en Azure Policy solo se refiere a
las propias directivas. Esto no garantiza una compatibilidad total con todos los
requisitos de un control. Además, el estándar de cumplimiento incluye controles que
no se abordan con las definiciones de Azure Policy en este momento. Por lo tanto, el
cumplimiento en Azure Policy es solo una vista parcial del estado general de
cumplimiento. Las asociaciones entre los controles y las definiciones de cumplimiento
normativo de Azure Policy para estos estándares de cumplimiento pueden cambiar con
el tiempo.

Australian Government ISM PROTECTED

Para revisar el modo en que las integraciones de Azure Policy disponibles para todos los
servicios de Azure se asignan a este estándar de cumplimiento, consulte Cumplimiento
normativo de Azure Policy: Australian Government ISM PROTECTED. Para obtener más
información sobre este estándar de cumplimiento, vea Australian Government ISM
PROTECTED .

ﾉ Expandir tabla
 Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la directiva
(GitHub)

Instrucciones para las 1431 Estrategias de Azure DDoS 3.0.0

redes: continuidad del denegación de Protection Standard
servicio para servicios en servicio: 1431 debe estar habilitado
línea

Canada Federal PBMM

Para revisar cómo las integraciones de Azure Policy disponibles de todos los servicios de
Azure se asignan a este estándar de cumplimiento, consulte Cumplimiento normativo de
Azure Policy: Canada Federal PBMM. Para más información sobre este estándar de
cumplimiento, consulte Canada Federal PBMM .

ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión de

control (Azure Portal) la directiva
(GitHub)

Protección del sistema y SC-5 Protección ante la Azure DDoS Protection 3.0.0
de las comunicaciones denegación de Standard debe estar
servicio habilitado

CIS Microsoft Azure Foundations Benchmark 1.1.0

Para revisar el modo en que las integraciones de Azure Policy disponibles para todos los
servicios de Azure se corresponden a este estándar de cumplimiento, consulte
Cumplimiento normativo de Azure Policy: CIS Microsoft Azure Foundations Benchmark
1.1.0. Para más información sobre este estándar de cumplimiento, consulte CIS Microsoft
Azure Foundations Benchmark .

ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión de

control (Azure Portal) la
directiva
(GitHub)

2 Security 2.9 Asegúrese de que la configuración de Las subredes deben 3.0.0

Center la directiva predeterminada de ASC estar asociadas con
"Habilitar la supervisión de firewalls de un grupo de
seguridad de red.
 Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la
directiva
(GitHub)

última generación (NGFW)" no sea

"Deshabilitado".

6 Redes 6.5 Asegúrese de que Network Watcher Network Watcher 3.0.0

está "Habilitado". debe estar habilitado

CIS Microsoft Azure Foundations Benchmark 1.3.0

Para consultar la correspondencia que existe entre las integraciones de Azure Policy
disponibles para todos los servicios de Azure y este estándar de cumplimiento, consulte
este artículo sobre el cumplimiento normativo de Azure Policy: CIS Microsoft Azure
Foundations Benchmark 1.3.0. Para más información sobre este estándar de cumplimiento,
consulte CIS Microsoft Azure Foundations Benchmark .

ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión de la

control (Azure Portal) directiva
(GitHub)

6 Redes 6.5 Asegúrese de que Network Network Watcher debe 3.0.0

Watcher está "Habilitado". estar habilitado

CIS Microsoft Azure Foundations Benchmark 1.4.0

Para revisar el modo en que las integraciones de Azure Policy disponibles para todos los
servicios de Azure se asignan a este estándar de cumplimiento, vea Detalles del
cumplimiento normativo de Azure Policy de CIS v1.4.0. Para más información sobre este
estándar de cumplimiento, consulte CIS Microsoft Azure Foundations Benchmark .

ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión de la

control (Azure Portal) directiva
(GitHub)

6 Redes 6.5 Asegúrese de que Network Network Watcher debe 3.0.0

Watcher está "Habilitado". estar habilitado
CIS Microsoft Azure Foundations
Benchmark 2.0.0
A fin de revisar el modo en que las integraciones de Azure Policy disponibles para todos los
servicios de Azure se asignan a esta norma de cumplimiento, vea Detalles del cumplimiento
normativo de Azure Policy de CIS v2.0.0. Para más información sobre este estándar de
cumplimiento, consulte CIS Microsoft Azure Foundations Benchmark .

ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión de

control (Azure Portal) la directiva
(GitHub)

5,1 5.1.6 Asegúrese de que los registros de Todos los recursos del 1.0.1
flujo del grupo de seguridad de registro de flujo deben
red se capturan y envían a Log estar en estado habilitado
Analytics

5,1 5.1.6 Asegúrese de que los registros de Los registros de flujo se 1.1.0
flujo del grupo de seguridad de deben configurar para cada
red se capturan y envían a Log grupo de seguridad de red.
Analytics

5,1 5.1.6 Asegúrese de que los registros de Los registros de flujo se 1.0.0
flujo del grupo de seguridad de deben configurar para cada
red se capturan y envían a Log grupo de red virtual
Analytics

6 6.6 Asegúrese de que Network Network Watcher debe 3.0.0

Watcher está "Habilitado". estar habilitado

CMMC nivel 3
Para ver cómo se corresponden las integraciones de Azure Policy disponibles para todos los
mapas de servicio de Azure con este estándar de cumplimiento, consulte Detalles de la
iniciativa integrada de cumplimiento normativo CMMC nivel 3. Para más información sobre
este estándar de cumplimiento, consulte Certificación del modelo de madurez de
ciberseguridad (CMMC) .

ﾉ Expandir tabla
Domain Id. de Título de control Directiva Versión
control (Azure Portal) de la
directiva
(GitHub)

Control de acceso AC.1.003 Verifica, controla y limita las [Vista previa]: Todo el 3.0.0-
conexiones a sistemas de tráfico de Internet preview
información externos y el uso debe enrutarse
de estos. mediante la instancia
de Azure Firewall
implementada

Control de acceso AC.2.013 Supervisa y controla las Network Watcher debe 3.0.0
sesiones de acceso remoto. estar habilitado

Control de acceso AC.2.016 Controla el flujo de CUI de [Vista previa]: Todo el 3.0.0-
acuerdo con las tráfico de Internet preview
autorizaciones aprobadas. debe enrutarse
mediante la instancia
de Azure Firewall
implementada

Administración CM.2.064 Establece y aplica la [Vista previa]: Todo el 3.0.0-

de la configuración de seguridad tráfico de Internet preview
configuración de los productos de debe enrutarse
tecnología de la información mediante la instancia
empleados en los sistemas de de Azure Firewall
la organización. implementada

Administración CM.2.064 Establece y aplica la Azure Web Application 1.0.2

de la configuración de seguridad Firewall debe estar
configuración de los productos de habilitado para los
tecnología de la información puntos de entrada de
empleados en los sistemas de Azure Front Door
la organización.

Administración CM.2.064 Establece y aplica la El firewall de 2.0.0

de la configuración de seguridad aplicaciones web
configuración de los productos de (WAF) debe estar
tecnología de la información habilitado para
empleados en los sistemas de Application Gateway
la organización.

Administración CM.2.064 Establece y aplica la El firewall de 1.0.0

de la configuración de seguridad aplicaciones web
configuración de los productos de (WAF) debe usar el
tecnología de la información modo especificado
empleados en los sistemas de para Application
la organización. Gateway

Administración CM.2.064 Establece y aplica la El firewall de 1.0.0

de la configuración de seguridad aplicaciones web
Domain Id. de Título de control Directiva Versión
control (Azure Portal) de la
directiva
(GitHub)

configuración de los productos de (WAF) debe usar el

tecnología de la información modo especificado
empleados en los sistemas de para Azure Front Door
la organización. Service

Administración CM.3.068 Restringe, deshabilita o Las subredes deben 3.0.0

de la impide el uso de programas, estar asociadas con un
configuración funciones, puertos, grupo de seguridad de
protocolos y servicios no red.
esenciales.

Respuesta a los IR.2.093 Detecta y notifica eventos. [Vista previa]: Todo el 3.0.0-
incidentes tráfico de Internet preview
debe enrutarse
mediante la instancia
de Azure Firewall
implementada

Respuesta a los IR.2.093 Detecta y notifica eventos. Azure Web Application 1.0.2
incidentes Firewall debe estar
habilitado para los
puntos de entrada de
Azure Front Door

Respuesta a los IR.2.093 Detección y notificación de Los registros de flujo 1.1.0

incidentes eventos. se deben configurar
para cada grupo de
seguridad de red.

Respuesta a los IR.2.093 Detecta y notifica eventos. El firewall de 2.0.0

incidentes aplicaciones web
(WAF) debe estar
habilitado para
Application Gateway

Respuesta a los IR.2.093 Detecta y notifica eventos. El firewall de 1.0.0

incidentes aplicaciones web
(WAF) debe usar el
modo especificado
para Application
Gateway

Respuesta a los IR.2.093 Detecta y notifica eventos. El firewall de 1.0.0

incidentes aplicaciones web
(WAF) debe usar el
modo especificado
Domain Id. de Título de control Directiva Versión
control (Azure Portal) de la
directiva
(GitHub)

para Azure Front Door

Service

Protección del SC.1.175 Supervisa, controla y protege Azure Web Application 1.0.2
sistema y de las las comunicaciones (es decir, Firewall debe estar
comunicaciones la información transmitida o habilitado para los
recibida por los sistemas de puntos de entrada de
la organización) en los límites Azure Front Door
externos y los límites internos
clave de los sistemas de la
organización.

Protección del SC.1.175 Supervisa, controla y protege Los registros de flujo 1.1.0
sistema y de las las comunicaciones (es decir, se deben configurar
comunicaciones la información transmitida o para cada grupo de
recibida por los sistemas de seguridad de red.
la organización) en los límites
externos y los límites internos
clave de los sistemas de la
organización.

Protección del SC.1.175 Supervisa, controla y protege Network Watcher debe 3.0.0
sistema y de las las comunicaciones (es decir, estar habilitado
comunicaciones la información transmitida o
recibida por los sistemas de
la organización) en los límites
externos y los límites internos
clave de los sistemas de la
organización.

Protección del SC.1.175 Supervisa, controla y protege El firewall de 2.0.0

sistema y de las las comunicaciones (es decir, aplicaciones web
comunicaciones la información transmitida o (WAF) debe estar
recibida por los sistemas de habilitado para
la organización) en los límites Application Gateway
externos y los límites internos
clave de los sistemas de la
organización.

Protección del SC.1.175 Supervisa, controla y protege El firewall de 1.0.0

sistema y de las las comunicaciones (es decir, aplicaciones web
comunicaciones la información transmitida o (WAF) debe usar el
recibida por los sistemas de modo especificado
la organización) en los límites para Application
externos y los límites internos Gateway
clave de los sistemas de la
organización.
Domain Id. de Título de control Directiva Versión
control (Azure Portal) de la
directiva
(GitHub)

Protección del SC.1.175 Supervisa, controla y protege El firewall de 1.0.0

sistema y de las las comunicaciones (es decir, aplicaciones web
comunicaciones la información transmitida o (WAF) debe usar el
recibida por los sistemas de modo especificado
la organización) en los límites para Azure Front Door
externos y los límites internos Service
clave de los sistemas de la
organización.

Protección del SC.1.176 Implementa subredes para Las subredes deben 3.0.0
sistema y de las componentes del sistema estar asociadas con un
comunicaciones accesibles públicamente que grupo de seguridad de
están física o lógicamente red.
separados de las redes
internas.

Protección del SC.3.180 Emplea diseños Las subredes deben 3.0.0

sistema y de las arquitectónicos, técnicas de estar asociadas con un
comunicaciones desarrollo de software y grupo de seguridad de
principios de ingeniería de red.
sistemas que fomentan la
seguridad de la información
en los sistemas de la
organización.

Protección del SC.3.183 Deniega el tráfico de las [Vista previa]: Todo el 3.0.0-
sistema y de las comunicaciones de red de tráfico de Internet preview
comunicaciones forma predeterminada y solo debe enrutarse
permite el tráfico de las mediante la instancia
comunicaciones de red de de Azure Firewall
forma excepcional (es decir, implementada
deniega todo el tráfico y
permite las excepciones).

Protección del SC.3.183 Deniega el tráfico de las Azure Web Application 1.0.2
sistema y de las comunicaciones de red de Firewall debe estar
comunicaciones forma predeterminada y solo habilitado para los
permite el tráfico de las puntos de entrada de
comunicaciones de red de Azure Front Door
forma excepcional (es decir,
deniega todo el tráfico y
permite las excepciones).

Protección del SC.3.183 Deniega el tráfico de las Los registros de flujo 1.1.0
sistema y de las comunicaciones de red de se deben configurar
comunicaciones forma predeterminada y solo para cada grupo de
permite el tráfico de las seguridad de red.
Domain Id. de Título de control Directiva Versión
control (Azure Portal) de la
directiva
(GitHub)

comunicaciones de red de
forma excepcional (es decir,
deniega todo el tráfico y
permite las excepciones).

Protección del SC.3.183 Deniega el tráfico de las Network Watcher debe 3.0.0
sistema y de las comunicaciones de red de estar habilitado
comunicaciones forma predeterminada y solo
permite el tráfico de las
comunicaciones de red de
forma excepcional (es decir,
deniega todo el tráfico y
permite las excepciones).

Protección del SC.3.183 Deniega el tráfico de las Las subredes deben 3.0.0
sistema y de las comunicaciones de red de estar asociadas con un
comunicaciones forma predeterminada y solo grupo de seguridad de
permite el tráfico de las red.
comunicaciones de red de
forma excepcional (es decir,
deniega todo el tráfico y
permite las excepciones).

Protección del SC.3.183 Deniega el tráfico de las El firewall de 2.0.0

sistema y de las comunicaciones de red de aplicaciones web
comunicaciones forma predeterminada y solo (WAF) debe estar
permite el tráfico de las habilitado para
comunicaciones de red de Application Gateway
forma excepcional (es decir,
deniega todo el tráfico y
permite las excepciones).

Protección del SC.3.183 Deniega el tráfico de las El firewall de 1.0.0

sistema y de las comunicaciones de red de aplicaciones web
comunicaciones forma predeterminada y solo (WAF) debe usar el
permite el tráfico de las modo especificado
comunicaciones de red de para Application
forma excepcional (es decir, Gateway
deniega todo el tráfico y
permite las excepciones).

Protección del SC.3.183 Deniega el tráfico de las El firewall de 1.0.0

sistema y de las comunicaciones de red de aplicaciones web
comunicaciones forma predeterminada y solo (WAF) debe usar el
permite el tráfico de las modo especificado
comunicaciones de red de para Azure Front Door
forma excepcional (es decir, Service
Domain Id. de Título de control Directiva Versión
control (Azure Portal) de la
directiva
(GitHub)

deniega todo el tráfico y

permite las excepciones).

Integridad del SI.2.216 Supervisa los sistemas de la [Vista previa]: Todo el 3.0.0-
sistema y de la organización, incluido el tráfico de Internet preview
información tráfico entrante y saliente de debe enrutarse
las comunicaciones, para mediante la instancia
detectar ataques e de Azure Firewall
indicadores de posibles implementada
ataques.

Integridad del SI.2.216 Supervisa los sistemas de la Azure Web Application 1.0.2
sistema y de la organización, incluido el Firewall debe estar
información tráfico entrante y saliente de habilitado para los
las comunicaciones, para puntos de entrada de
detectar ataques e Azure Front Door
indicadores de posibles
ataques.

Integridad del SI.2.216 Supervisa los sistemas de la Los registros de flujo 1.1.0
sistema y de la organización, incluido el se deben configurar
información tráfico entrante y saliente de para cada grupo de
las comunicaciones, para seguridad de red.
detectar ataques e
indicadores de posibles
ataques.

Integridad del SI.2.216 Supervisa los sistemas de la Network Watcher debe 3.0.0
sistema y de la organización, incluido el estar habilitado
información tráfico entrante y saliente de
las comunicaciones, para
detectar ataques e
indicadores de posibles
ataques.

Integridad del SI.2.216 Supervisa los sistemas de la El firewall de 2.0.0

sistema y de la organización, incluido el aplicaciones web
información tráfico entrante y saliente de (WAF) debe estar
las comunicaciones, para habilitado para
detectar ataques e Application Gateway
indicadores de posibles
ataques.

Integridad del SI.2.216 Supervisa los sistemas de la El firewall de 1.0.0

sistema y de la organización, incluido el aplicaciones web
información tráfico entrante y saliente de (WAF) debe usar el
las comunicaciones, para modo especificado
detectar ataques e
 Domain Id. de Título de control Directiva Versión
control (Azure Portal) de la
directiva
(GitHub)

indicadores de posibles para Application

ataques. Gateway

Integridad del SI.2.216 Supervisa los sistemas de la El firewall de 1.0.0

sistema y de la organización, incluido el aplicaciones web
información tráfico entrante y saliente de (WAF) debe usar el
las comunicaciones, para modo especificado
detectar ataques e para Azure Front Door
indicadores de posibles Service
ataques.

Integridad del SI.2.217 Identifica el uso no Network Watcher debe 3.0.0

sistema y de la autorizado de los sistemas de estar habilitado
información la organización.

FedRAMP High
Para revisar el modo en que las iniciativas integradas disponibles de Azure Policy de todos
los servicios de Azure se asignan a este estándar de cumplimiento, consulte Cumplimiento
normativo de Azure Policy: FedRAMP High. Para más información sobre este estándar de
cumplimiento, consulte FedRAMP High .

ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión de

control (Azure Portal) la directiva
(GitHub)

Control de acceso AC-4 Aplicación del flujo de [Vista previa]: Todo el tráfico 3.0.0-
información de Internet debe enrutarse preview
mediante la instancia de
Azure Firewall
implementada

Control de acceso AC-4 Aplicación del flujo de Las subredes deben estar 3.0.0
información asociadas con un grupo de
seguridad de red.

Auditoría y AU-6 Revisión, análisis e Network Watcher debe estar 3.0.0

responsabilidad informes de auditoría habilitado

Auditoría y AU-6 (4) Revisión y análisis Network Watcher debe estar 3.0.0
responsabilidad centralizados habilitado
Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la directiva
(GitHub)

Auditoría y AU-6 (5) Funcionalidades de Network Watcher debe estar 3.0.0

responsabilidad integración o habilitado
exploración y
supervisión

Auditoría y AU-12 Generación de Network Watcher debe estar 3.0.0

responsabilidad auditoría habilitado

Auditoría y AU-12 Registro de auditoría Network Watcher debe estar 3.0.0

responsabilidad (1) de todo el sistema o habilitado
en correlación con el
tiempo

Protección del SC-5 Protección ante la Azure DDoS Protection 3.0.0

sistema y de las denegación de servicio Standard debe estar
comunicaciones habilitado

Protección del SC-5 Protección ante la Azure Web Application 1.0.2

sistema y de las denegación de servicio Firewall debe estar
comunicaciones habilitado para los puntos
de entrada de Azure Front
Door

Protección del SC-5 Protección ante la El firewall de aplicaciones 2.0.0

sistema y de las denegación de servicio web (WAF) debe estar
comunicaciones habilitado para Application
Gateway

Protección del SC-7 Protección de límites [Vista previa]: Todo el tráfico 3.0.0-
sistema y de las de Internet debe enrutarse preview
comunicaciones mediante la instancia de
Azure Firewall
implementada

Protección del SC-7 Protección de límites Azure Web Application 1.0.2

sistema y de las Firewall debe estar
comunicaciones habilitado para los puntos
de entrada de Azure Front
Door

Protección del SC-7 Protección de límites Las subredes deben estar 3.0.0
sistema y de las asociadas con un grupo de
comunicaciones seguridad de red.

Protección del SC-7 Protección de límites El firewall de aplicaciones 2.0.0

sistema y de las web (WAF) debe estar
comunicaciones habilitado para Application
Gateway
 Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la directiva
(GitHub)

Protección del SC-7 (3) Puntos de acceso [Vista previa]: Todo el tráfico 3.0.0-
sistema y de las de Internet debe enrutarse preview
comunicaciones mediante la instancia de
Azure Firewall
implementada

Protección del SC-7 (3) Puntos de acceso Azure Web Application 1.0.2
sistema y de las Firewall debe estar
comunicaciones habilitado para los puntos
de entrada de Azure Front
Door

Protección del SC-7 (3) Puntos de acceso Las subredes deben estar 3.0.0
sistema y de las asociadas con un grupo de
comunicaciones seguridad de red.

Protección del SC-7 (3) Puntos de acceso El firewall de aplicaciones 2.0.0

sistema y de las web (WAF) debe estar
comunicaciones habilitado para Application
Gateway

Integridad del SI-4 Supervisión del [Vista previa]: Todo el tráfico 3.0.0-
sistema y de la sistema de de Internet debe enrutarse preview
información información mediante la instancia de
Azure Firewall
implementada

Integridad del SI-4 Supervisión del Network Watcher debe estar 3.0.0
sistema y de la sistema de habilitado
información información

FedRAMP Moderate
Para revisar el modo en que las iniciativas integradas disponibles de Azure Policy de todos
los servicios de Azure se asignan a este estándar de cumplimiento, consulte Cumplimiento
normativo de Azure Policy: FedRAMP Moderate. Para más información sobre este estándar
de cumplimiento, consulte FedRAMP Moderate .

ﾉ Expandir tabla
Domain Id. de Título de Directiva Versión de
control control (Azure Portal) la directiva
(GitHub)

Control de acceso AC-4 Aplicación del [Vista previa]: Todo el tráfico de 3.0.0-
flujo de Internet debe enrutarse preview
información mediante la instancia de Azure
Firewall implementada

Control de acceso AC-4 Aplicación del Las subredes deben estar 3.0.0
flujo de asociadas con un grupo de
información seguridad de red.

Auditoría y AU-6 Revisión, análisis Network Watcher debe estar 3.0.0

responsabilidad e informes de habilitado
auditoría

Auditoría y AU-12 Generación de Network Watcher debe estar 3.0.0

responsabilidad auditoría habilitado

Protección del SC-5 Protección ante Azure DDoS Protection Standard 3.0.0
sistema y de las la denegación debe estar habilitado
comunicaciones de servicio

Protección del SC-5 Protección ante Azure Web Application Firewall 1.0.2
sistema y de las la denegación debe estar habilitado para los
comunicaciones de servicio puntos de entrada de Azure
Front Door

Protección del SC-5 Protección ante El firewall de aplicaciones web 2.0.0

sistema y de las la denegación (WAF) debe estar habilitado
comunicaciones de servicio para Application Gateway

Protección del SC-7 Protección de [Vista previa]: Todo el tráfico de 3.0.0-

sistema y de las límites Internet debe enrutarse preview
comunicaciones mediante la instancia de Azure
Firewall implementada

Protección del SC-7 Protección de Azure Web Application Firewall 1.0.2

sistema y de las límites debe estar habilitado para los
comunicaciones puntos de entrada de Azure
Front Door

Protección del SC-7 Protección de Las subredes deben estar 3.0.0

sistema y de las límites asociadas con un grupo de
comunicaciones seguridad de red.

Protección del SC-7 Protección de El firewall de aplicaciones web 2.0.0

sistema y de las límites (WAF) debe estar habilitado
comunicaciones para Application Gateway

Protección del SC-7 (3) Puntos de [Vista previa]: Todo el tráfico de 3.0.0-
sistema y de las acceso Internet debe enrutarse preview
 Domain Id. de Título de Directiva Versión de
control control (Azure Portal) la directiva
(GitHub)

comunicaciones mediante la instancia de Azure

Firewall implementada

Protección del SC-7 (3) Puntos de Azure Web Application Firewall 1.0.2
sistema y de las acceso debe estar habilitado para los
comunicaciones puntos de entrada de Azure
Front Door

Protección del SC-7 (3) Puntos de Las subredes deben estar 3.0.0
sistema y de las acceso asociadas con un grupo de
comunicaciones seguridad de red.

Protección del SC-7 (3) Puntos de El firewall de aplicaciones web 2.0.0

sistema y de las acceso (WAF) debe estar habilitado
comunicaciones para Application Gateway

Integridad del SI-4 Supervisión del [Vista previa]: Todo el tráfico de 3.0.0-
sistema y de la sistema de Internet debe enrutarse preview
información información mediante la instancia de Azure
Firewall implementada

Integridad del SI-4 Supervisión del Network Watcher debe estar 3.0.0
sistema y de la sistema de habilitado
información información

HIPAA/HITRUST 9.2
Con el fin de revisar el modo en que las integraciones de Azure Policy disponibles para los
servicios de Azure siguen este estándar de cumplimiento, consulte Cumplimiento normativo
de Azure Policy: HIPAA/HITRUST 9.2. Para más información acerca de este estándar de
cumplimiento, consulte HIPAA/HITRUST 9.2 .

ﾉ Expandir tabla

Domain Id. de control Título de control Directiva Versión

(Azure Portal) de la
directiva
(GitHub)

Protección 0805.01m1Organizational.12-01 0805.01m1Organizational.12- Las subredes 1.0.0

de red - 01.m 01.m 01.04 Control de acceso a de la puerta
redes de enlace no
se deben
configurar
con un grupo
Domain Id. de control Título de control Directiva Versión
(Azure Portal) de la
directiva
(GitHub)

de seguridad
de red

Protección 0805.01m1Organizational.12-01 0805.01m1Organizational.12- Las subredes 3.0.0

de red - 01.m 01.m 01.04 Control de acceso a deben estar
redes asociadas
con un grupo
de seguridad
de red.

Protección 0805.01m1Organizational.12-01 0805.01m1Organizational.12- Las máquinas 1.0.0

de red - 01.m 01.m 01.04 Control de acceso a virtuales
redes deben estar
conectadas a
una red
virtual
aprobada

Protección 0806.01m2Organizational.12356- 0806.01m2Organizational.12356- Las subredes 1.0.0

de red 01 - 01.m 01.m 01.04 Control de acceso a de la puerta
redes de enlace no
se deben
configurar
con un grupo
de seguridad
de red

Protección 0806.01m2Organizational.12356- 0806.01m2Organizational.12356- Las subredes 3.0.0

de red 01 - 01.m 01.m 01.04 Control de acceso a deben estar
redes asociadas
con un grupo
de seguridad
de red.

Protección 0806.01m2Organizational.12356- 0806.01m2Organizational.12356- Las máquinas 1.0.0

de red 01 - 01.m 01.m 01.04 Control de acceso a virtuales
redes deben estar
conectadas a
una red
virtual
aprobada

Protección 0809.01n2Organizational.1234- 0809.01n2Organizational.1234- Las subredes 3.0.0

de red 01.n 01.n 01.04 Control de acceso a deben estar
redes asociadas
con un grupo
Domain Id. de control Título de control Directiva Versión
(Azure Portal) de la
directiva
(GitHub)

de seguridad
de red.

Protección 0809.01n2Organizational.1234- 0809.01n2Organizational.1234- Las máquinas 1.0.0

de red 01.n 01.n 01.04 Control de acceso a virtuales
redes deben estar
conectadas a
una red
virtual
aprobada

Protección 0810.01n2Organizational.5-01.n 0810.01n2Organizational.5-01.n Las subredes 3.0.0

de red 01.04 Control de acceso a redes deben estar
asociadas
con un grupo
de seguridad
de red.

Protección 0810.01n2Organizational.5-01.n 0810.01n2Organizational.5-01.n Las máquinas 1.0.0

de red 01.04 Control de acceso a redes virtuales
deben estar
conectadas a
una red
virtual
aprobada

Protección 0811.01n2Organizational.6-01.n 0811.01n2Organizational.6-01.n Las subredes 3.0.0

de red 01.04 Control de acceso a redes deben estar
asociadas
con un grupo
de seguridad
de red.

Protección 0811.01n2Organizational.6-01.n 0811.01n2Organizational.6-01.n Las máquinas 1.0.0

de red 01.04 Control de acceso a redes virtuales
deben estar
conectadas a
una red
virtual
aprobada

Protección 0812.01n2Organizational.8-01.n 0812.01n2Organizational.8-01.n Las subredes 3.0.0

de red 01.04 Control de acceso a redes deben estar
asociadas
con un grupo
de seguridad
de red.
Domain Id. de control Título de control Directiva Versión
(Azure Portal) de la
directiva
(GitHub)

Protección 0812.01n2Organizational.8-01.n 0812.01n2Organizational.8-01.n Las máquinas 1.0.0

de red 01.04 Control de acceso a redes virtuales
deben estar
conectadas a
una red
virtual
aprobada

Protección 0814.01n1Organizational.12-01.n 0814.01n1Organizational.12-01.n Las subredes 3.0.0

de red 01.04 Control de acceso a redes deben estar
asociadas
con un grupo
de seguridad
de red.

Protección 0814.01n1Organizational.12-01.n 0814.01n1Organizational.12-01.n Las máquinas 1.0.0

de red 01.04 Control de acceso a redes virtuales
deben estar
conectadas a
una red
virtual
aprobada

Protección 0837.09.n2Organizational.2-09.n 0837.09.n2Organizational.2-09.n Network 3.0.0

de red 09.06 Administración de Watcher
seguridad de red debe estar
habilitado

Protección 0860.09m1Organizational.9-09.m 0860.09m1Organizational.9-09.m Implementar 2.0.1

de red 09.06 Administración de la
seguridad de red configuración
de
diagnóstico
para grupos
de seguridad
de red

Protección 0886.09n2Organizational.4-09.n 0886.09n2Organizational.4-09.n Network 3.0.0

de red 09.06 Administración de Watcher
seguridad de red debe estar
habilitado

Protección 0888.09n2Organizational.6-09.n 0888.09n2Organizational.6-09.n Network 3.0.0

de red 09.06 Administración de Watcher
seguridad de red debe estar
habilitado
 Domain Id. de control Título de control Directiva Versión
(Azure Portal) de la
directiva
(GitHub)

Protección 0894.01m2Organizational.7-01 - 0894.01m2Organizational.7-01.m Implementar 1.0.0

de red 01.m 01.04 Control de acceso a redes Network
Watcher al
crear redes
virtuales .

Protección 0894.01m2Organizational.7-01 - 0894.01m2Organizational.7-01.m Las subredes 1.0.0

de red 01.m 01.04 Control de acceso a redes de la puerta
de enlace no
se deben
configurar
con un grupo
de seguridad
de red

Protección 0894.01m2Organizational.7-01 - 0894.01m2Organizational.7-01.m Las subredes 3.0.0

de red 01.m 01.04 Control de acceso a redes deben estar
asociadas
con un grupo
de seguridad
de red.

Protección 0894.01m2Organizational.7-01 - 0894.01m2Organizational.7-01.m Las máquinas 1.0.0

de red 01.m 01.04 Control de acceso a redes virtuales
deben estar
conectadas a
una red
virtual
aprobada

IRS 1075, septiembre de 2016

Para revisar cómo las integraciones de Azure Policy disponibles para todos los servicios de
Azure se asignan a este estándar de cumplimiento, consulte Cumplimiento normativo de
Azure Policy: IRS 1075, septiembre de 2016. Para más información sobre este estándar de
cumplimiento, consulte este artículo acerca de IRS 1075, septiembre de 2016 .

ﾉ Expandir tabla
 Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la directiva
(GitHub)

Protección del sistema y 9.3.16.4 Protección ante la Azure DDoS Protection 3.0.0
de las comunicaciones denegación de Standard debe estar
servicio (SC-5) habilitado

Pruebas comparativas de seguridad de

Microsoft Cloud
El punto de referencia de seguridad en la nube de Microsoft proporciona recomendaciones
sobre cómo puede proteger sus soluciones de nube en Azure. Para ver la asignación
completa de este servicio al punto de referencia de seguridad en la nube de Microsoft,
consulte Archivos de asignación de Azure Security Benchmark .

Para revisar el modo en que las integraciones de Azure Policy disponibles para todos los
servicios de Azure se corresponden a este estándar de cumplimiento, consulte
Cumplimiento normativo de Azure Policy: punto de referencia de seguridad en la nube de
Microsoft.

ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión de

control (Azure Portal) la directiva
(GitHub)

Seguridad de NS-1 Establecimiento de Las subredes deben estar 3.0.0

redes límites de asociadas con un grupo de
segmentación de red seguridad de red.

Seguridad de NS-3 Implementación de un [Vista previa]: Todo el tráfico de 3.0.0-

redes firewall en el Internet debe enrutarse preview
perímetro de la red mediante la instancia de Azure
empresarial Firewall implementada

Seguridad de NS-5 Implementación de Azure DDoS Protection 3.0.0

redes DDOS Protection Standard debe estar habilitado

Seguridad de NS-6 Implementación del Azure Web Application Firewall 1.0.2

redes firewall de debe estar habilitado para los
aplicaciones web puntos de entrada de Azure
Front Door

Seguridad de NS-6 Implementación del El firewall de aplicaciones web 2.0.0

redes firewall de (WAF) debe estar habilitado
aplicaciones web para Application Gateway
 Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la directiva
(GitHub)

Administración IM-1 Uso de una identidad Las puertas de enlace de VPN 1.0.0
de identidades centralizada y un solo deben usar la
sistema de autenticación de Azure Active
autenticación Directory (Azure AD) para los
usuarios de punto a sitio

Respuesta a los IR-4 Detección y análisis: Network Watcher debe estar 3.0.0
incidentes investigación de habilitado
incidentes

Respuesta a los IR-4 Detección y análisis: Network Watcher debe estar 3.0.0
incidentes investigación de habilitado
incidentes

ISM restringido en Nueva Zelanda

Para consultar la correspondencia que existe entre las integraciones de Azure Policy
disponibles para todos los servicios de Azure y este estándar de cumplimiento, consulte
este artículo sobre el cumplimiento normativo de Azure Policy y la restricción de ISM en
Nueva Zelanda. Para más información acerca de este estándar de cumplimiento, consulte
ISM restringido de Nueva Zelanda .

ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión de

control (Azure Portal) la
directiva
(GitHub)

Seguridad de NS-5 18.3.19 Contenido de un plan de Azure DDoS Protection 3.0.0

red respuesta frente a ataques por Standard debe estar
denegación de servicio (DoS) habilitado

Seguridad de NS-7 18.4.8 IDS/IPS en puertas de El firewall de aplicaciones 2.0.0

red enlace web (WAF) debe estar
habilitado para
Application Gateway

Seguridad de NS-7 18.4.8 IDS/IPS en puertas de El firewall de aplicaciones 1.0.0

red enlace web (WAF) debe usar el
modo especificado para
Application Gateway

Seguridad de NS-7 18.4.8 IDS/IPS en puertas de El firewall de aplicaciones 1.0.0

red enlace web (WAF) debe usar el
 Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la
directiva
(GitHub)

modo especificado para

Azure Front Door Service

Seguridad de GS-3 19.1.12 Configuración de Las subredes deben estar 3.0.0

puertas de puertas de enlace asociadas con un grupo
enlace de seguridad de red.

NIST SP 800-171 R2
Para revisar el modo en que las integraciones de Azure Policy disponibles para todos los
servicios de Azure se corresponden a este estándar de cumplimiento, consulte
Cumplimiento normativo de Azure Policy: NIST SP 800-171 R2. Para más información acerca
de este estándar normativo, consulte NIST SP 800-171 R2 .

ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión

control (Azure Portal) de la
directiva
(GitHub)

Control de acceso 3.1.3 Controla el flujo de CUI de [Vista previa]: Todo el 3.0.0-
acuerdo con las autorizaciones tráfico de Internet preview
aprobadas. debe enrutarse
mediante la instancia
de Azure Firewall
implementada

Control de acceso 3.1.3 Controla el flujo de CUI de Las subredes deben 3.0.0
acuerdo con las autorizaciones estar asociadas con un
aprobadas. grupo de seguridad de
red.

Protección del 3.13.1 Supervisa, controla y protege [Vista previa]: Todo el 3.0.0-
sistema y de las las comunicaciones (es decir, tráfico de Internet preview
comunicaciones la información transmitida o debe enrutarse
recibida por los sistemas de la mediante la instancia
organización) en los límites de Azure Firewall
externos y los límites internos implementada
clave de los sistemas de la
organización.

Protección del 3.13.1 Supervisa, controla y protege Azure Web Application 1.0.2
sistema y de las las comunicaciones (es decir, Firewall debe estar
comunicaciones la información transmitida o habilitado para los
Domain Id. de recibida
Título depor los sistemas de la
control puntos
Directivade entrada de Versión
control organización) en los límites Azure
(Azure Portal) Door
Front de la
externos y los límites internos directiva
clave de los sistemas de la (GitHub)
organización.

Protección del 3.13.1 Supervisa, controla y protege Las subredes deben 3.0.0
sistema y de las las comunicaciones (es decir, estar asociadas con un
comunicaciones la información transmitida o grupo de seguridad de
recibida por los sistemas de la red.
organización) en los límites
externos y los límites internos
clave de los sistemas de la
organización.

Protección del 3.13.1 Supervisa, controla y protege El firewall de 2.0.0

sistema y de las las comunicaciones (es decir, aplicaciones web (WAF)
comunicaciones la información transmitida o debe estar habilitado
recibida por los sistemas de la para Application
organización) en los límites Gateway
externos y los límites internos
clave de los sistemas de la
organización.

Protección del 3.13.2 Emplea diseños [Vista previa]: Todo el 3.0.0-

sistema y de las arquitectónicos, técnicas de tráfico de Internet preview
comunicaciones desarrollo de software y debe enrutarse
principios de ingeniería de mediante la instancia
sistemas que fomentan la de Azure Firewall
seguridad de la información implementada
en los sistemas de la
organización.

Protección del 3.13.2 Emplea diseños Azure Web Application 1.0.2

sistema y de las arquitectónicos, técnicas de Firewall debe estar
comunicaciones desarrollo de software y habilitado para los
principios de ingeniería de puntos de entrada de
sistemas que fomentan la Azure Front Door
seguridad de la información
en los sistemas de la
organización.

Protección del 3.13.2 Emplea diseños Las subredes deben 3.0.0

sistema y de las arquitectónicos, técnicas de estar asociadas con un
comunicaciones desarrollo de software y grupo de seguridad de
principios de ingeniería de red.
sistemas que fomentan la
seguridad de la información
en los sistemas de la
organización.
Domain Id. de Título de control Directiva Versión
control (Azure Portal) de la
directiva
(GitHub)

Protección del 3.13.2 Emplea diseños El firewall de 2.0.0

sistema y de las arquitectónicos, técnicas de aplicaciones web (WAF)
comunicaciones desarrollo de software y debe estar habilitado
principios de ingeniería de para Application
sistemas que fomentan la Gateway
seguridad de la información
en los sistemas de la
organización.

Protección del 3.13.5 Implementa subredes para [Vista previa]: Todo el 3.0.0-
sistema y de las componentes del sistema tráfico de Internet preview
comunicaciones accesibles públicamente que debe enrutarse
están física o lógicamente mediante la instancia
separados de las redes de Azure Firewall
internas. implementada

Protección del 3.13.5 Implementa subredes para Azure Web Application 1.0.2
sistema y de las componentes del sistema Firewall debe estar
comunicaciones accesibles públicamente que habilitado para los
están física o lógicamente puntos de entrada de
separados de las redes Azure Front Door
internas.

Protección del 3.13.5 Implementa subredes para Las subredes deben 3.0.0
sistema y de las componentes del sistema estar asociadas con un
comunicaciones accesibles públicamente que grupo de seguridad de
están física o lógicamente red.
separados de las redes
internas.

Protección del 3.13.5 Implementa subredes para El firewall de 2.0.0

sistema y de las componentes del sistema aplicaciones web (WAF)
comunicaciones accesibles públicamente que debe estar habilitado
están física o lógicamente para Application
separados de las redes Gateway
internas.

Protección del 3.13.6 Deniega el tráfico de las [Vista previa]: Todo el 3.0.0-
sistema y de las comunicaciones de red de tráfico de Internet preview
comunicaciones forma predeterminada y solo debe enrutarse
permite el tráfico de las mediante la instancia
comunicaciones de red de de Azure Firewall
forma excepcional (es decir, implementada
deniega todo el tráfico y
permite las excepciones).
Domain Id. de Título de control Directiva Versión
control (Azure Portal) de la
directiva
(GitHub)

Protección del 3.13.6 Deniega el tráfico de las Azure Web Application 1.0.2
sistema y de las comunicaciones de red de Firewall debe estar
comunicaciones forma predeterminada y solo habilitado para los
permite el tráfico de las puntos de entrada de
comunicaciones de red de Azure Front Door
forma excepcional (es decir,
deniega todo el tráfico y
permite las excepciones).

Protección del 3.13.6 Deniega el tráfico de las Las subredes deben 3.0.0
sistema y de las comunicaciones de red de estar asociadas con un
comunicaciones forma predeterminada y solo grupo de seguridad de
permite el tráfico de las red.
comunicaciones de red de
forma excepcional (es decir,
deniega todo el tráfico y
permite las excepciones).

Protección del 3.13.6 Deniega el tráfico de las El firewall de 2.0.0

sistema y de las comunicaciones de red de aplicaciones web (WAF)
comunicaciones forma predeterminada y solo debe estar habilitado
permite el tráfico de las para Application
comunicaciones de red de Gateway
forma excepcional (es decir,
deniega todo el tráfico y
permite las excepciones).

Integridad del 3.14.6 Supervisa los sistemas de la [Vista previa]: Todo el 3.0.0-
sistema y de la organización, incluido el tráfico de Internet preview
información tráfico entrante y saliente de debe enrutarse
las comunicaciones, para mediante la instancia
detectar ataques e indicadores de Azure Firewall
de posibles ataques. implementada

Integridad del 3.14.6 Supervisa los sistemas de la Network Watcher debe 3.0.0
sistema y de la organización, incluido el estar habilitado
información tráfico entrante y saliente de
las comunicaciones, para
detectar ataques e indicadores
de posibles ataques.

Integridad del 3.14.7 Identifica el uso no autorizado [Vista previa]: Todo el 3.0.0-
sistema y de la de los sistemas de la tráfico de Internet preview
información organización. debe enrutarse
mediante la instancia
de Azure Firewall
implementada
 Domain Id. de Título de control Directiva Versión
control (Azure Portal) de la
directiva
(GitHub)

Integridad del 3.14.7 Identifica el uso no autorizado Network Watcher debe 3.0.0
sistema y de la de los sistemas de la estar habilitado
información organización.

Auditoría y 3.3.1 Crear y conservar registros de Network Watcher debe 3.0.0

responsabilidad auditoría y registros del estar habilitado
sistema en la medida
necesaria para permitir la
supervisión, el análisis, la
investigación y la generación
de informes de actividad del
sistema ilegal o no autorizada

Auditoría y 3.3.2 Garantiza que solo se pueda Network Watcher debe 3.0.0
responsabilidad realizar el seguimiento de las estar habilitado
acciones de usuarios
individuales del sistema hasta
esos usuarios, de modo que se
les pueda responsabilizar de
sus acciones.

NIST SP 800-53 Rev. 4

Para revisar el modo en que las iniciativas integradas disponibles de Azure Policy de todos
los servicios de Azure se asignan a este estándar de cumplimiento, consulte Detalles de la
iniciativa integrada del cumplimiento normativo de NIST SP 800-53 R4. Para más
información sobre este estándar de cumplimiento, consulte NIST SP 800-53 Rev. 4 .

ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión de

control (Azure Portal) la directiva
(GitHub)

Control de acceso AC-4 Aplicación del flujo de [Vista previa]: Todo el tráfico 3.0.0-
información de Internet debe enrutarse preview
mediante la instancia de
Azure Firewall
implementada

Control de acceso AC-4 Aplicación del flujo de Las subredes deben estar 3.0.0
información asociadas con un grupo de
seguridad de red.
Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la directiva
(GitHub)

Auditoría y AU-6 Revisión, análisis e Network Watcher debe estar 3.0.0

responsabilidad informes de auditoría habilitado

Auditoría y AU-6 (4) Revisión y análisis Network Watcher debe estar 3.0.0
responsabilidad centralizados habilitado

Auditoría y AU-6 (5) Funcionalidades de Network Watcher debe estar 3.0.0

responsabilidad integración o habilitado
exploración y
supervisión

Auditoría y AU-12 Generación de Network Watcher debe estar 3.0.0

responsabilidad auditoría habilitado

Auditoría y AU-12 Registro de auditoría Network Watcher debe estar 3.0.0

responsabilidad (1) de todo el sistema o habilitado
en correlación con el
tiempo

Protección del SC-5 Protección ante la Azure DDoS Protection 3.0.0

sistema y de las denegación de servicio Standard debe estar
comunicaciones habilitado

Protección del SC-5 Protección ante la Azure Web Application 1.0.2

sistema y de las denegación de servicio Firewall debe estar
comunicaciones habilitado para los puntos
de entrada de Azure Front
Door

Protección del SC-5 Protección ante la El firewall de aplicaciones 2.0.0

sistema y de las denegación de servicio web (WAF) debe estar
comunicaciones habilitado para Application
Gateway

Protección del SC-7 Protección de límites [Vista previa]: Todo el tráfico 3.0.0-
sistema y de las de Internet debe enrutarse preview
comunicaciones mediante la instancia de
Azure Firewall
implementada

Protección del SC-7 Protección de límites Azure Web Application 1.0.2

sistema y de las Firewall debe estar
comunicaciones habilitado para los puntos
de entrada de Azure Front
Door

Protección del SC-7 Protección de límites Las subredes deben estar 3.0.0
sistema y de las asociadas con un grupo de
comunicaciones seguridad de red.
Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la directiva
(GitHub)

Protección del SC-7 Protección de límites El firewall de aplicaciones 2.0.0

sistema y de las web (WAF) debe estar
comunicaciones habilitado para Application
Gateway

Protección del SC-7 (3) Puntos de acceso [Vista previa]: Todo el tráfico 3.0.0-
sistema y de las de Internet debe enrutarse preview
comunicaciones mediante la instancia de
Azure Firewall
implementada

Protección del SC-7 (3) Puntos de acceso Azure Web Application 1.0.2
sistema y de las Firewall debe estar
comunicaciones habilitado para los puntos
de entrada de Azure Front
Door

Protección del SC-7 (3) Puntos de acceso Las subredes deben estar 3.0.0
sistema y de las asociadas con un grupo de
comunicaciones seguridad de red.

Protección del SC-7 (3) Puntos de acceso El firewall de aplicaciones 2.0.0

sistema y de las web (WAF) debe estar
comunicaciones habilitado para Application
Gateway

Integridad del SI-4 Supervisión del [Vista previa]: Todo el tráfico 3.0.0-
sistema y de la sistema de de Internet debe enrutarse preview
información información mediante la instancia de
Azure Firewall
implementada

Integridad del SI-4 Supervisión del [Vista previa]: Todo el tráfico 3.0.0-
sistema y de la sistema de de Internet debe enrutarse preview
información información mediante la instancia de
Azure Firewall
implementada

Integridad del SI-4 Supervisión del [Vista previa]: Todo el tráfico 3.0.0-
sistema y de la sistema de de Internet debe enrutarse preview
información información mediante la instancia de
Azure Firewall
implementada

Integridad del SI-4 Supervisión del [Vista previa]: Todo el tráfico 3.0.0-
sistema y de la sistema de de Internet debe enrutarse preview
información información mediante la instancia de
 Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la directiva
(GitHub)

Azure Firewall
implementada

Integridad del SI-4 Supervisión del [Vista previa]: Todo el tráfico 3.0.0-
sistema y de la sistema de de Internet debe enrutarse preview
información información mediante la instancia de
Azure Firewall
implementada

Integridad del SI-4 Supervisión del Network Watcher debe estar 3.0.0
sistema y de la sistema de habilitado
información información

Integridad del SI-4 Supervisión del Network Watcher debe estar 3.0.0
sistema y de la sistema de habilitado
información información

Integridad del SI-4 Supervisión del Network Watcher debe estar 3.0.0
sistema y de la sistema de habilitado
información información

Integridad del SI-4 Supervisión del Network Watcher debe estar 3.0.0
sistema y de la sistema de habilitado
información información

Integridad del SI-4 Supervisión del Network Watcher debe estar 3.0.0
sistema y de la sistema de habilitado
información información

NIST SP 800-53 Rev. 5

Para revisar el modo en que las iniciativas integradas disponibles de Azure Policy de todos
los servicios de Azure se asignan a este estándar de cumplimiento, consulte Detalles de la
iniciativa integrada del cumplimiento normativo de NIST SP 800-53 R5. Para más
información sobre este estándar de cumplimiento, consulte NIST SP 800-53 Rev. 5 .

ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión de

control (Azure Portal) la directiva
(GitHub)

Control de acceso AC-4 Aplicación del flujo [Vista previa]: Todo el tráfico 3.0.0-
de información de Internet debe enrutarse preview
mediante la instancia de
Azure Firewall implementada
Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la directiva
(GitHub)

Control de acceso AC-4 Aplicación del flujo Las subredes deben estar 3.0.0
de información asociadas con un grupo de
seguridad de red.

Auditoría y AU-6 Revisión, análisis e Network Watcher debe estar 3.0.0

responsabilidad informes de los habilitado
registros de
auditoría

Auditoría y AU-6 (4) Revisión y análisis Network Watcher debe estar 3.0.0
responsabilidad centralizados habilitado

Auditoría y AU-6 (5) Análisis integrado de Network Watcher debe estar 3.0.0
responsabilidad registros de habilitado
auditoría

Auditoría y AU-12 Generación de Network Watcher debe estar 3.0.0

responsabilidad registros de habilitado
auditoría

Auditoría y AU-12 Registro de auditoría Network Watcher debe estar 3.0.0

responsabilidad (1) de todo el sistema y habilitado
en correlación con el
tiempo

Protección del SC-5 Protección ante la Azure DDoS Protection 3.0.0

sistema y de las denegación de Standard debe estar
comunicaciones servicio habilitado

Protección del SC-5 Protección ante la Azure Web Application 1.0.2

sistema y de las denegación de Firewall debe estar habilitado
comunicaciones servicio para los puntos de entrada
de Azure Front Door

Protección del SC-5 Protección ante la El firewall de aplicaciones 2.0.0

sistema y de las denegación de web (WAF) debe estar
comunicaciones servicio habilitado para Application
Gateway

Protección del SC-7 Protección de límites [Vista previa]: Todo el tráfico 3.0.0-
sistema y de las de Internet debe enrutarse preview
comunicaciones mediante la instancia de
Azure Firewall implementada

Protección del SC-7 Protección de límites Azure Web Application 1.0.2

sistema y de las Firewall debe estar habilitado
comunicaciones para los puntos de entrada
de Azure Front Door
 Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la directiva
(GitHub)

Protección del SC-7 Protección de límites Las subredes deben estar 3.0.0
sistema y de las asociadas con un grupo de
comunicaciones seguridad de red.

Protección del SC-7 Protección de límites El firewall de aplicaciones 2.0.0

sistema y de las web (WAF) debe estar
comunicaciones habilitado para Application
Gateway

Protección del SC-7 (3) Puntos de acceso [Vista previa]: Todo el tráfico 3.0.0-
sistema y de las de Internet debe enrutarse preview
comunicaciones mediante la instancia de
Azure Firewall implementada

Protección del SC-7 (3) Puntos de acceso Azure Web Application 1.0.2
sistema y de las Firewall debe estar habilitado
comunicaciones para los puntos de entrada
de Azure Front Door

Protección del SC-7 (3) Puntos de acceso Las subredes deben estar 3.0.0
sistema y de las asociadas con un grupo de
comunicaciones seguridad de red.

Protección del SC-7 (3) Puntos de acceso El firewall de aplicaciones 2.0.0

sistema y de las web (WAF) debe estar
comunicaciones habilitado para Application
Gateway

Integridad del SI-4 Supervisión del [Vista previa]: Todo el tráfico 3.0.0-
sistema y de la sistema de Internet debe enrutarse preview
información mediante la instancia de
Azure Firewall implementada

Integridad del SI-4 Supervisión del Network Watcher debe estar 3.0.0
sistema y de la sistema habilitado
información

Tema de la nube de NL BIO

Para revisar cómo se asignan los complementos de Azure Policy disponibles para todos los
servicios de Azure a esta norma de cumplimiento, consulte Detalles del cumplimiento
normativo de Azure Policy para Tema de la nube de NL BIO. Para obtener más información
sobre esta norma de cumplimiento, consulte Base de referencia de la seguridad de la
información de ciberseguridad de Administración pública: Gobierno digital
(digitaleoverheid.nl) .
 ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión

control (Azure Portal) de la
directiva
(GitHub)

U.07.1 Separación U.07.1 El aislamiento permanente Azure Web Application 1.0.2

de datos: aislado de los datos es una Firewall debe estar
arquitectura multiinquilino. habilitado para los
Las revisiones se realizan de puntos de entrada de
forma controlada. Azure Front Door

U.07.1 Separación U.07.1 El aislamiento permanente Las subredes deben 3.0.0

de datos: aislado de los datos es una estar asociadas con un
arquitectura multiinquilino. grupo de seguridad de
Las revisiones se realizan de red.
forma controlada.

Separación de U.07.1 El aislamiento permanente El firewall de 2.0.0

datos de U.07.1: de los datos es una aplicaciones web (WAF)
aislado arquitectura multiinquilino. debe estar habilitado
Las revisiones se realizan de para Application
forma controlada. Gateway

U.09.3 Protección U.09.3 La protección contra Azure DDoS Protection 3.0.0

contra malware: malware se ejecuta en Standard debe estar
detección, diferentes entornos. habilitado
prevención y
recuperación

U.09.3 Protección U.09.3 La protección contra Azure Web Application 1.0.2

contra malware: malware se ejecuta en Firewall debe estar
detección, diferentes entornos. habilitado para los
prevención y puntos de entrada de
recuperación Azure Front Door

U.09.3 Protección U.09.3 La protección contra El firewall de 2.0.0

contra malware: malware se ejecuta en aplicaciones web (WAF)
detección, diferentes entornos. debe estar habilitado
prevención y para Application
recuperación Gateway

U.12.1 Interfaces: U.12.1 En puntos de conexión con Azure DDoS Protection 3.0.0
conexiones de red zonas externas o que no Standard debe estar
son de confianza, se toman habilitado
medidas contra ataques.

U.12.1 Interfaces: U.12.1 En puntos de conexión con Azure Web Application 1.0.2
conexiones de red zonas externas o que no Firewall debe estar
son de confianza, se toman habilitado para los
medidas contra ataques.
 Domain Id. de Título de control Directiva Versión
control (Azure Portal) de la
directiva
(GitHub)

puntos de entrada de
Azure Front Door

U.12.1 Interfaces: U.12.1 En puntos de conexión con El firewall de 2.0.0

conexiones de red zonas externas o que no aplicaciones web (WAF)
son de confianza, se toman debe estar habilitado
medidas contra ataques. para Application
Gateway

U.12.2 Interfaces: U.12.2 Los componentes de red Azure DDoS Protection 3.0.0
conexiones de red son tales que las conexiones Standard debe estar
de red entre redes de habilitado
confianza y que no son de
confianza son limitadas.

U.12.2 Interfaces: U.12.2 Los componentes de red Azure Web Application 1.0.2
conexiones de red son tales que las conexiones Firewall debe estar
de red entre redes de habilitado para los
confianza y que no son de puntos de entrada de
confianza son limitadas. Azure Front Door

U.12.2 Interfaces: U.12.2 Los componentes de red El firewall de 2.0.0

conexiones de red son tales que las conexiones aplicaciones web (WAF)
de red entre redes de debe estar habilitado
confianza y que no son de para Application
confianza son limitadas. Gateway

U.15.1 Registro y U.15.1 El CSP y el CSC registran la Network Watcher debe 3.0.0
supervisión: eventos infracción de las reglas de estar habilitado
registrados directiva.

Restricción de ISM en NZ v3.5

Para consultar la correspondencia que existe entre las integraciones de Azure Policy
disponibles para todos los servicios de Azure y este estándar de cumplimiento, consulte
este artículo sobre el cumplimiento normativo de Azure Policy y la restricción de ISM en
NZ v3.5. Para más información acerca de este estándar de cumplimiento, consulte ISM
restringido de NZ v3.5 .

ﾉ Expandir tabla
 Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la
directiva
(GitHub)

Seguridad de GS-3 19.1.12 Configuración de Las subredes deben estar 3.0.0

puertas de puertas de enlace asociadas con un grupo
enlace de seguridad de red.

Seguridad de NS-5 18.3.19 Contenido de un plan Azure DDoS Protection 3.0.0

red de respuesta frente a ataques Standard debe estar
por denegación de servicio habilitado
(DoS)

Seguridad de NS-8 18.4.8 IDS/IPS en puertas de Azure Web Application 1.0.2

red enlace Firewall debe estar
habilitado para los puntos
de entrada de Azure
Front Door

Seguridad de NS-8 18.4.8 IDS/IPS en puertas de El firewall de aplicaciones 2.0.0

red enlace web (WAF) debe estar
habilitado para
Application Gateway

Seguridad de NS-8 18.4.8 IDS/IPS en puertas de El firewall de aplicaciones 1.0.0

red enlace web (WAF) debe usar el
modo especificado para
Application Gateway

Seguridad de NS-8 18.4.8 IDS/IPS en puertas de El firewall de aplicaciones 1.0.0

red enlace web (WAF) debe usar el
modo especificado para
Azure Front Door Service

Banco de la Reserva de la India: marco

informático para NBFC
Para revisar la correspondencia entre las integraciones de Azure Policy disponibles para
todos los servicios de Azure y este estándar de cumplimiento, vea Cumplimiento normativo
de Azure Policy: Banco de la Reserva de la India: marco informático para NBFC. Para obtener
más información sobre este estándar de cumplimiento, consulte Banco de la Reserva de la
India: marco informático para NBFC .

ﾉ Expandir tabla
Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la directiva
(GitHub)

Gobernanza de 1.1 Gobernanza de TI-1.1 [Vista previa]: Todo el tráfico de 3.0.0-

TI Internet debe enrutarse preview
mediante la instancia de Azure
Firewall implementada

Información y 3.1.g Trails-3.1 Todos los recursos del registro 1.0.1

ciberseguridad de flujo deben estar en estado
habilitado

Información y 3.1.g Senderos-3.1 Los registros de flujo se deben 1.1.0

ciberseguridad configurar para cada grupo de
seguridad de red.

Información y 3.1.g Senderos-3.1 Los registros de flujo de 1.0.1

ciberseguridad Network Watcher deben tener
habilitado el análisis de tráfico

Auditoría de IS 5 Directiva para la [Vista previa]: Todo el tráfico de 3.0.0-

auditoría del sistema Internet debe enrutarse preview
de información mediante la instancia de Azure
(auditoría de IS)-5 Firewall implementada

Auditoría de IS 5 Directiva para la Todos los recursos del registro 1.0.1

auditoría del sistema de flujo deben estar en estado
de información habilitado
(auditoría de IS)-5

Auditoría de IS 5 Directiva para la Azure Web Application Firewall 1.0.2

auditoría del sistema debe estar habilitado para los
de información puntos de entrada de Azure
(auditoría de IS)-5 Front Door

Auditoría de IS 5 Directiva para la Los registros de flujo se deben 1.1.0

auditoría del sistema configurar para cada grupo de
de información seguridad de red.
(auditoría de IS)-5

Auditoría de IS 5 Directiva para la Las subredes deben estar 3.0.0

auditoría del sistema asociadas con un grupo de
de información seguridad de red.
(auditoría de IS)-5

Auditoría de IS 5 Directiva para la El firewall de aplicaciones web 2.0.0

auditoría del sistema (WAF) debe estar habilitado
de información para Application Gateway
(auditoría de IS)-5

Auditoría de IS 5 Directiva para la El firewall de aplicaciones web 1.0.0

auditoría del sistema (WAF) debe usar el modo
 Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la directiva
(GitHub)

de información especificado para Application

(auditoría de IS)-5 Gateway

Auditoría de IS 5 Directiva para la El firewall de aplicaciones web 1.0.0

auditoría del sistema (WAF) debe usar el modo
de información especificado para Azure Front
(auditoría de IS)-5 Door Service

Banco de la Reserva de la India: marco

informático para bancos, v2016
Para revisar el modo en que las integraciones de Azure Policy disponibles para todos los
servicios de Azure se asignan a este estándar de cumplimiento, consulte Cumplimiento
normativo de Azure Policy: RBI ITF Banks v2016. Para obtener más información sobre este
estándar de cumplimiento, consulte: RBI ITF Banks v2016 (PDF) .

ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión de

control (Azure Portal) la
directiva
(GitHub)

Administración y Inventario de red-4.2 [Vista previa]: Todo el tráfico 3.0.0-

seguridad de red de Internet debe enrutarse preview
mediante la instancia de
Azure Firewall implementada

Administración y Administración de [Vista previa]: Todo el tráfico 3.0.0-

seguridad de red configuración de de Internet debe enrutarse preview
dispositivos de red- mediante la instancia de
4.3 Azure Firewall implementada

Administración y Administración y [Vista previa]: Todo el tráfico 3.0.0-

defensa ante defensa ante de Internet debe enrutarse preview
amenazas amenazas avanzadas mediante la instancia de
avanzadas en en tiempo real-13.4 Azure Firewall implementada
tiempo real

Administración y Administración y [Vista previa]: Todo el tráfico 3.0.0-

defensa ante defensa ante de Internet debe enrutarse preview
amenazas amenazas avanzadas mediante la instancia de
avanzadas en en tiempo real-13.3 Azure Firewall implementada
tiempo real
Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la
directiva
(GitHub)

Administración y Detección y [Vista previa]: Todo el tráfico 3.0.0-

seguridad de red protección de Internet debe enrutarse preview
perimetrales: 4.10 mediante la instancia de
Azure Firewall implementada

Administración y Detección de [Vista previa]: Todo el tráfico 3.0.0-

seguridad de red anomalías-4.7 de Internet debe enrutarse preview
mediante la instancia de
Azure Firewall implementada

Estrategia de Estrategia de Todos los recursos del 1.0.1

prevención de prevención de fugas registro de flujo deben estar
fugas de datos de datos-15.1 en estado habilitado

Mantenimiento, Mantenimiento, Todos los recursos del 1.0.1

supervisión y supervisión y análisis registro de flujo deben estar
análisis de registros de registros de en estado habilitado
de auditoría auditoría-16.1

Mantenimiento, Mantenimiento, Todos los recursos del 1.0.1

supervisión y supervisión y análisis registro de flujo deben estar
análisis de registros de registros de en estado habilitado
de auditoría auditoría-16.1

Mantenimiento, Mantenimiento, Todos los recursos del 1.0.1

supervisión y supervisión y análisis registro de flujo deben estar
análisis de registros de registros de en estado habilitado
de auditoría auditoría-16.1

Estrategia de Estrategia de Todos los recursos del 1.0.1

prevención de prevención de fugas registro de flujo deben estar
fugas de datos de datos-15.1 en estado habilitado

Datos forenses Análisis forense-22.1 Azure DDoS Protection 3.0.0

Standard debe estar
habilitado

Administración y Recuperación de Azure DDoS Protection 3.0.0

respuesta frente a incidentes Standard debe estar
incidentes cibernéticos-19.6b habilitado

Administración y Administración de La directiva de Azure Firewall 1.0.0

seguridad de redes configuración de debe habilitar la inspección
dispositivos de red- de TLS dentro de las reglas de
4.3 aplicación

Administración y Detección de Azure Web Application 1.0.2

seguridad de red anomalías-4.7 Firewall debe estar habilitado
Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la
directiva
(GitHub)

para los puntos de entrada de

Azure Front Door

Administración y Administración y Azure Web Application 1.0.2

defensa ante defensa ante Firewall debe estar habilitado
amenazas amenazas avanzadas para los puntos de entrada de
avanzadas en en tiempo real-13.4 Azure Front Door
tiempo real

Administración y Detección y Azure Web Application 1.0.2

seguridad de red protección Firewall debe estar habilitado
perimetrales: 4.10 para los puntos de entrada de
Azure Front Door

Administración y Administración de Azure Web Application 1.0.2

seguridad de red configuración de Firewall debe estar habilitado
dispositivos de red- para los puntos de entrada de
4.3 Azure Front Door

Mantenimiento, Mantenimiento, Los registros de flujo se 1.1.0

supervisión y supervisión y análisis deben configurar para cada
análisis de registros de registros de grupo de seguridad de red.
de auditoría auditoría-16.1

Mantenimiento, Mantenimiento, Los registros de flujo se 1.1.0

supervisión y supervisión y análisis deben configurar para cada
análisis de registros de registros de grupo de seguridad de red.
de auditoría auditoría-16.1

Mantenimiento, Mantenimiento, Los registros de flujo se 1.1.0

supervisión y supervisión y análisis deben configurar para cada
análisis de registros de registros de grupo de seguridad de red.
de auditoría auditoría-16.1

Mantenimiento, Mantenimiento, Los registros de flujo de 1.0.1

supervisión y supervisión y análisis Network Watcher deben tener
análisis de registros de registros de habilitado el análisis de tráfico
de auditoría auditoría-16.1

Mantenimiento, Mantenimiento, Los registros de flujo de 1.0.1

supervisión y supervisión y análisis Network Watcher deben tener
análisis de registros de registros de habilitado el análisis de tráfico
de auditoría auditoría-16.1

Administración y Inventario de red-4.2 Los registros de flujo de 1.0.1

seguridad de red Network Watcher deben tener
habilitado el análisis de tráfico
Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la
directiva
(GitHub)

Mantenimiento, Mantenimiento, Los registros de flujo de 1.0.1

supervisión y supervisión y análisis Network Watcher deben tener
análisis de registros de registros de habilitado el análisis de tráfico
de auditoría auditoría-16.1

Administración y Centro de Network Watcher debe estar 3.0.0

seguridad de red operaciones de habilitado
seguridad-4.9

Administración y Administración de Las subredes deben estar 3.0.0

seguridad de redes configuración de asociadas con un grupo de
dispositivos de red- seguridad de red.
4.3

Administración y Administración y Las subredes deben estar 3.0.0

defensa ante defensa ante asociadas con un grupo de
amenazas amenazas avanzadas seguridad de red.
avanzadas en en tiempo real-13.4
tiempo real

Sistemas de Sistemas de Las subredes deben estar 3.0.0

mensajería y correo mensajería y correo asociadas con un grupo de
seguros seguros-10.2 seguridad de red.

Administración y Administración y Las subredes deben estar 3.0.0

defensa ante defensa ante asociadas con un grupo de
amenazas amenazas avanzadas seguridad de red.
avanzadas en en tiempo real-13.3
tiempo real

Sistemas de Sistemas de Las subredes deben estar 3.0.0

mensajería y correo mensajería y correo asociadas con un grupo de
seguros seguros-10.1 seguridad de red.

Administración y Detección de Las subredes deben estar 3.0.0

seguridad de red anomalías-4.7 asociadas con un grupo de
seguridad de red.

Administración y Detección y Las subredes deben estar 3.0.0

seguridad de red protección asociadas con un grupo de
perimetrales: 4.10 seguridad de red.

Administración y Administración y El firewall de aplicaciones web 2.0.0

defensa ante defensa ante (WAF) debe estar habilitado
amenazas amenazas avanzadas para Application Gateway
avanzadas en en tiempo real-13.4
tiempo real
Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la
directiva
(GitHub)

Ciclo de vida de Ciclo de vida de El firewall de aplicaciones web 2.0.0

seguridad de las seguridad de las (WAF) debe estar habilitado
aplicaciones (ASLC) aplicaciones para Application Gateway
(ASLC)-6.7

Administración y Detección y El firewall de aplicaciones web 2.0.0

seguridad de red protección (WAF) debe estar habilitado
perimetrales: 4.10 para Application Gateway

Ciclo de vida de Ciclo de vida de El firewall de aplicaciones web 2.0.0

seguridad de las seguridad de las (WAF) debe estar habilitado
aplicaciones (ASLC) aplicaciones para Application Gateway
(ASLC)-6.7

Administración y Administración de El firewall de aplicaciones web 2.0.0

seguridad de red configuración de (WAF) debe estar habilitado
dispositivos de red- para Application Gateway
4.3

Administración y Detección de El firewall de aplicaciones web 2.0.0

seguridad de red anomalías-4.7 (WAF) debe estar habilitado
para Application Gateway

Ciclo de vida de Ciclo de vida de Web Application Firewall 1.0.1

seguridad de las seguridad de las (WAF) debe habilitar todas las
aplicaciones (ASLC) aplicaciones reglas de firewall para
(ASLC)-6.7 Application Gateway

Administración y Administración de Web Application Firewall 1.0.1

seguridad de red configuración de (WAF) debe habilitar todas las
dispositivos de red- reglas de firewall para
4.3 Application Gateway

Ciclo de vida de Ciclo de vida de Web Application Firewall 1.0.1

seguridad de las seguridad de las (WAF) debe habilitar todas las
aplicaciones (ASLC) aplicaciones reglas de firewall para
(ASLC)-6.7 Application Gateway

Ciclo de vida de Ciclo de vida de El firewall de aplicaciones web 1.0.0

seguridad de las seguridad de las (WAF) debe usar el modo
aplicaciones (ASLC) aplicaciones especificado para Application
(ASLC)-6.7 Gateway

Ciclo de vida de Ciclo de vida de El firewall de aplicaciones web 1.0.0

seguridad de las seguridad de las (WAF) debe usar el modo
aplicaciones (ASLC) aplicaciones especificado para Application
(ASLC)-6.7 Gateway
RMIT Malasia
Para revisar la correspondencia entre las integraciones de Azure Policy disponibles para
todos los servicios de Azure y este estándar de cumplimiento, consulte Cumplimiento
normativo de Azure Policy: RMIT Malasia. Para más información sobre este estándar de
cumplimiento, vea RMIT Malasia .

ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión de

control (Azure Portal) la
directiva
(GitHub)

Resistencia de la 10.33 Resistencia de la Todos los recursos del registro 1.0.1

red red: 10.33 de flujo deben estar en estado
habilitado

Resistencia de la 10.33 Resistencia de la Las instancias de Azure VPN 1.0.0

red red: 10.33 Gateway no deben usar la SKU
"básica" .

Resistencia de la 10.33 Resistencia de la Los registros de flujo se deben 1.1.0

red red: 10.33 configurar para cada grupo de
seguridad de red.

Resistencia de la 10.33 Resistencia de la Las subredes deben estar 3.0.0

red red: 10.33 asociadas con un grupo de
seguridad de red.

Resistencia de la 10.33 Resistencia de la Las máquinas virtuales deben 1.0.0

red red: 10.33 estar conectadas a una red
virtual aprobada

Resistencia de la 10.33 Resistencia de la Las redes virtuales deben usar 1.0.0

red red: 10.33 la puerta de enlace de red
virtual especificada

Resistencia de la 10.35 Resistencia de la Network Watcher debe estar 3.0.0

red red: 10.35 habilitado

Resistencia de la 10,39 Resistencia de la Se debe aplicar una directiva 1.0.0

red red: 10.39 IPsec/IKE personalizada a
todas las conexiones de
puerta de enlace de red virtual
de Azure .

Denegación de 11.13 Denegación de Azure Web Application 1.0.2

servicio distribuido servicio distribuido Firewall debe estar habilitado
(DDoS) (DDoS): 11.13 para los puntos de entrada de
Azure Front Door
Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la
directiva
(GitHub)

Centro de 11.18 Centro de Azure DDoS Protection 3.0.0

operaciones de operaciones de Standard debe estar habilitado
seguridad (SOC) seguridad (SOC):
11.18

Centro de 11.18 Centro de Azure DDoS Protection 3.0.0

operaciones de operaciones de Standard debe estar habilitado
seguridad (SOC) seguridad (SOC):
11.18

Medidas de Apéndice Medidas de control Se debe aplicar una directiva 1.0.0

control sobre 5.5 sobre IPsec/IKE personalizada a
ciberseguridad ciberseguridad: todas las conexiones de
anexo 5.5 puerta de enlace de red virtual
de Azure .

Medidas de Apéndice Medidas de control El firewall de aplicaciones web 2.0.0

control sobre 5.6 sobre (WAF) debe estar habilitado
ciberseguridad ciberseguridad: para Application Gateway
anexo 5.6

Medidas de Apéndice Medidas de control El firewall de aplicaciones web 1.0.0

control sobre 5.6 sobre (WAF) debe usar el modo
ciberseguridad ciberseguridad: especificado para Application
anexo 5.6 Gateway

Medidas de Apéndice Medidas de control El firewall de aplicaciones web 1.0.0

control sobre 5.6 sobre (WAF) debe usar el modo
ciberseguridad ciberseguridad: especificado para Azure Front
anexo 5.6 Door Service

Medidas de Apéndice Medidas de control Todos los recursos del registro 1.0.1
control sobre 5.7 sobre de flujo deben estar en estado
ciberseguridad ciberseguridad: habilitado
anexo 5.7

Medidas de Apéndice Medidas de control Azure DDoS Protection 3.0.0

control sobre 5.7 sobre Standard debe estar habilitado
ciberseguridad ciberseguridad:
anexo 5.7

Medidas de Apéndice Medidas de control Los registros de flujo se deben 1.1.0

control sobre 5.7 sobre configurar para cada grupo de
ciberseguridad ciberseguridad: seguridad de red.
anexo 5.7

Medidas de Apéndice Medidas de control Las subredes deben estar 3.0.0

control sobre 5.7 sobre asociadas con un grupo de
 ciberseguridad
Domain Id. de ciberseguridad:
Título de control seguridad
Directiva de red. Versión de
control anexo 5.7 la
(Azure Portal)
directiva
(GitHub)

SWIFT CSP-CSCF v2021

Para revisar cómo las funciones integradas de Azure Policy disponibles para todos los
mapas de servicio de Azure se asignan a este estándar de cumplimiento, consulte los
detalles del cumplimiento normativo de Azure Policy para SWIFT CSP-CSCF v2021. Para
obtener más información sobre este estándar de cumplimiento, consulte SWIFT CSP CSCF
v2021 .

ﾉ Expandir tabla

Domain Id. de Título de Directiva Versión de

control control (Azure Portal) la directiva
(GitHub)

Protección del entorno 1.1 Protección [Vista previa]: Todo el tráfico de 3.0.0-
SWIFT del entorno Internet debe enrutarse preview
SWIFT mediante la instancia de Azure
Firewall implementada

Protección del entorno 1.1 Protección Azure DDoS Protection Standard 3.0.0
SWIFT del entorno debe estar habilitado
SWIFT

Protección del entorno 1.1 Protección Network Watcher debe estar 3.0.0
SWIFT del entorno habilitado
SWIFT

Protección del entorno 1.1 Protección Las subredes deben estar 3.0.0
SWIFT del entorno asociadas con un grupo de
SWIFT seguridad de red.

Detectar actividad 6.5A Detección de Network Watcher debe estar 3.0.0

anómala en sistemas o intrusiones habilitado
registros de
transacciones

SWIFT CSP CSCF v2022

Para revisar cómo las funciones integradas de Azure Policy disponibles para todos los
mapas de servicio de Azure se asignan a este estándar de cumplimiento, consulte los
detalles del cumplimiento normativo de Azure Policy para SWIFT CSP-CSCF v2022. Para más
información sobre este estándar de cumplimiento, consulte SWIFT CSP CSCF v2022 .
 ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión de

control (Azure Portal) la
directiva
(GitHub)

1. Restricción del 1.1 Garantice la protección de [Vista previa]: Todo el 3.0.0-

acceso a Internet & la infraestructura SWIFT tráfico de Internet debe preview
protección de los local del usuario de los enrutarse mediante la
sistemas críticos del elementos potencialmente instancia de Azure
entorno general de comprometidos del Firewall implementada
TI entorno de TI general y del
entorno externo.

1. Restricción del 1.1 Garantice la protección de Network Watcher debe 3.0.0

acceso a Internet & la infraestructura SWIFT estar habilitado
protección de los local del usuario de los
sistemas críticos del elementos potencialmente
entorno general de comprometidos del
TI entorno de TI general y del
entorno externo.

1. Restricción del 1.1 Garantice la protección de Las subredes deben 3.0.0

acceso a Internet & la infraestructura SWIFT estar asociadas con un
protección de los local del usuario de los grupo de seguridad de
sistemas críticos del elementos potencialmente red.
entorno general de comprometidos del
TI entorno de TI general y del
entorno externo.

1. Restricción del 1.4 Controle o proteja el [Vista previa]: Todo el 3.0.0-

acceso a Internet & acceso a Internet desde los tráfico de Internet debe preview
protección de los equipos y sistemas del enrutarse mediante la
sistemas críticos del operador dentro de la zona instancia de Azure
entorno general de segura. Firewall implementada
TI

1. Restricción del 1.5A Garantice la protección de [Vista previa]: Todo el 3.0.0-

acceso a Internet & la infraestructura de tráfico de Internet debe preview
protección de los conectividad del cliente enrutarse mediante la
sistemas críticos del contra el entorno externo y instancia de Azure
entorno general de los elementos Firewall implementada
TI potencialmente peligrosos
del entorno general de TI.

1. Restricción del 1.5A Garantice la protección de Azure DDoS Protection 3.0.0

acceso a Internet & la infraestructura de Standard debe estar
protección de los conectividad del cliente habilitado
sistemas críticos del contra el entorno externo y
entorno general de los elementos
TI
Domain Id. de Título de control Directiva Versión de
control (Azure Portal) la
directiva
(GitHub)

potencialmente peligrosos
del entorno general de TI.

1. Restricción del 1.5A Garantice la protección de Network Watcher debe 3.0.0

acceso a Internet & la infraestructura de estar habilitado
protección de los conectividad del cliente
sistemas críticos del contra el entorno externo y
entorno general de los elementos
TI potencialmente peligrosos
del entorno general de TI.

1. Restricción del 1.5A Garantice la protección de Las subredes deben 3.0.0

acceso a Internet & la infraestructura de estar asociadas con un
protección de los conectividad del cliente grupo de seguridad de
sistemas críticos del contra el entorno externo y red.
entorno general de los elementos
TI potencialmente peligrosos
del entorno general de TI.

6. Detectar 6.4 Registre eventos de Todos los recursos del 1.0.1

actividad anómala seguridad y detecte registro de flujo deben
en sistemas o acciones y operaciones estar en estado
registros de anómalas en el entorno habilitado
transacciones local SWIFT.

6. Detectar 6.4 Registre eventos de Los registros de flujo se 1.1.0

actividad anómala seguridad y detecte deben configurar para
en sistemas o acciones y operaciones cada grupo de
registros de anómalas en el entorno seguridad de red.
transacciones local SWIFT.

6. Detectar 6.4 Registre eventos de Los registros de flujo de 1.0.1

actividad anómala seguridad y detecte Network Watcher deben
en sistemas o acciones y operaciones tener habilitado el
registros de anómalas en el entorno análisis de tráfico
transacciones local SWIFT.

6. Detectar 6.5A Detecte y contenga Network Watcher debe 3.0.0

actividad anómala actividad de red anómala estar habilitado
en sistemas o dentro del entorno SWIFT
registros de local o remoto.
transacciones

UK OFFICIAL y UK NHS
Para revisar cómo las integraciones de Azure Policy disponibles para todos los servicios de
Azure se asignan a este estándar de cumplimiento, consulte Cumplimiento normativo de
Azure Policy: UK OFFICIAL y UK NHS. Para más información sobre este estándar de
cumplimiento, consulte UK OFFICIAL .

ﾉ Expandir tabla

Domain Id. de Título de control Directiva Versión de la

control (Azure Portal) directiva
(GitHub)

Seguridad 5.3 Supervisión de Azure DDoS Protection Standard 3.0.0

operativa protección debe estar habilitado

Pasos siguientes
Obtenga más información sobre el cumplimiento normativo de Azure Policy.
Los elementos integrados se pueden encontrar en el repositorio de GitHub de Azure
Policy .
Extensión de subred
Artículo • 06/04/2023

La migración de cargas de trabajo a la nube pública requiere una cuidadosa planeación

y coordinación. Una de las consideraciones clave puede ser la capacidad de conservar
las direcciones IP. Esto puede ser importante especialmente si las aplicaciones tienen
dependencias de dirección IP o si tiene requisitos de cumplimiento para usar
direcciones IP específicas. Azure Virtual Network resuelve este problema, ya que le
permite crear redes virtuales y subredes con el intervalo de direcciones IP que usted
prefiera.

Las migraciones pueden llegar a ser un reto cuando el requisito anterior se combina con
un requisito adicional para mantener algunas aplicaciones en el entorno local. En tal
caso, tendrá que dividir las aplicaciones entre Azure y el entorno local, sin tener que
volver a numerar las direcciones IP en ambos lados. Además, tendrá que permitir que las
aplicaciones se comuniquen como si estuvieran en la misma red.

Una solución al problema anterior es la extensión de subred. La extensión de una red

permite a las aplicaciones comunicarse en el mismo dominio de difusión cuando existen
en diferentes ubicaciones físicas, lo que elimina la necesidad de rediseñar la topología
de red.

Aunque la extensión de la red no es una buena práctica en general, los casos de uso
siguientes pueden hacer que sea necesario.

Migración por fases: el escenario más común es que desee escalonar la migración.
Desea llevar algunas aplicaciones primero y, con el tiempo, migrar el resto de las
aplicaciones a Azure.

Latencia: los requisitos de baja latencia pueden ser otro motivo para mantener
algunas aplicaciones en el entorno local con el fin de asegurarse de que están lo
más cerca posible del centro de recursos.

Cumplimiento: otro caso de uso es que podría tener requisitos de cumplimiento

para mantener algunas de sus aplicaciones en el entorno local.

７ Nota

No debe extender las subredes a menos que sea necesario. En los casos en que
extienda las subredes, debe intentar que sea un paso intermedio. Con el tiempo,
debe intentar volver a numerar las aplicaciones en la red local y migrarlas a Azure.
En la siguiente sección analizaremos cómo puede extender las subredes a Azure.

Extensión de la subred a Azure

Puede extender las subredes locales a Azure con una solución basada en la red de
superposición de nivel 3. La mayoría de las soluciones usan una tecnología de
superposición, como VXLAN, para extender la red de nivel 2 mediante una red de
superposición de nivel 3. En el diagrama siguiente se muestra una solución
generalizada. En esta solución, la misma subred existe en ambos lados, es decir, en
Azure y en el entorno local.

Las direcciones IP de la subred se asignan a las máquinas virtuales en Azure y en el

entorno local. Tanto Azure como el entorno local tienen un NVA insertado en sus redes.
Cuando una máquina virtual de Azure intenta comunicarse con una máquina virtual en
una red local, el NVA de Azure captura el paquete, lo encapsula y lo envía a través de
VPN/ExpressRoute a la red local. El NVA local recibe el paquete, lo desencapsula y lo
reenvía al destinatario previsto en su red. El tráfico de retorno utiliza una ruta y lógica
similares.

En el ejemplo anterior, el NVA de Azure y el NVA local se comunican y aprenden sobre

las direcciones IP que tienen detrás de ellos. Las redes más complejas también pueden
tener un servicio de asignación, que mantiene la asignación entre los NVA y las
direcciones IP detrás de ellos. Cuando un NVA recibe un paquete, consulta el servicio de
asignación para averiguar la dirección del NVA que tiene la dirección IP de destino
detrás de él.

En la sección siguiente, encontrará información sobre las soluciones de extensión de

subred que hemos probado en Azure.
Pasos siguientes
Ampliación de las subredes locales a Azure mediante Azure Extended Network.
¿Qué es la delegación de subred?
Artículo • 10/05/2023

La delegación de subred permite designar una subred concreta para el servicio PaaS de
Azure que se prefiera e insertarla en una red virtual. La delegación de subred
proporciona al cliente control total al cliente de la administración de la integración de
los servicios de Azure en sus redes virtuales.

Al delegar una subred en un servicio de Azure, se permite que el servicio establezca

algunas reglas básicas de configuración de red para la subred, lo que facilita que las
instancias del servicio de Azure funcionen de manera estable. Como resultado, el
servicio de Azure puede establecer algunas de las siguientes condiciones previas o
posteriores a la implementación:

Implementar el servicio en una subred compartida, en lugar de una dedicada.

Agregar al servicio un conjunto de directivas de intenciones de red después de la

implementación que se requiere para que el servicio funcione correctamente.

Ventajas de la delegación de subred

La delegación de una subred a servicios concretos aporta las siguientes ventajas:

Ayuda a designar una subred para uno o varios servicios de Azure y a administrar
las instancias de la subred en función de los requisitos. Por ejemplo, el propietario
de la red virtual puede definir las siguientes directivas y opciones para una subred
delegada, con el fin de administrar mejor los recursos:

Directivas de tráfico de filtrado de red con grupos de seguridad de red.

Directivas de enrutamiento con rutas definidas por el usuario.

Integración de servicios con configuraciones de puntos de conexión de servicio.

Ayuda a los servicios insertados a integrarse mejor con la red virtual mediante la
definición de las condiciones previas de las implementaciones, en forma de
directivas de intenciones de red. Esta directiva garantiza que cualquier acción que
pueda afectar al funcionamiento del servicio insertado se puede bloquear en PUT.

¿Quién puede delegar?

La delegación de subred es un ejercicio que los propietarios de redes virtuales deben
realizar para designar una de las subredes para un servicio de Azure concreto. A su vez,
el servicio de Azure implementa las instancias en esta subred para que las consuman las
cargas de trabajo de los clientes.

Efecto de la delegación de subred en una

subred
Cada servicio de Azure define su propio modelo de implementación, en el que se puede
especificar las propiedades que admite, o no, en una subred delegada a la hora de la
inserción, tal como se indica a continuación:

Subred compartida con otros servicios de Azure o con un conjunto de escalado de

máquinas virtuales o máquinas virtuales que estén en la misma subred, o bien solo
admite una subred dedicada que tenga únicamente instancias de este servicio.

Admite la asociación de grupos de seguridad de red con la subred delegada.

Admite que un grupo de seguridad de red que esté asociado a la subred delegada
también pueda estarlo a cualquier otra subred.

Permite la asociación de la tabla de rutas con la subred delegada.

Permite que la tabla de rutas asociada con la subred delegada se asocie con
cualquier otra subred.

Dicta el número mínimo de direcciones IP en la subred delegada.

Dicta que el espacio de direcciones IP de la subred delegada sea del espacio de

direcciones IP privadas (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12).

Dicta que la configuración de DNS personalizada tenga una entrada Azure DNS.

Requiere quitar la delegación antes de que se pueda eliminar la subred o la red

virtual.

No se puede usar con un punto de conexión privado si se delega la subred.

Los servicios insertados también pueden agregar sus propias directivas, como las
siguientes:

Directivas de seguridad: colección de reglas de seguridad necesarias para el

funcionamiento de un servicio determinado.
 Directivas de rutas: colección de rutas necesarias para el funcionamiento de un
servicio dado.

Qué es lo que no hace la delegación de subred

Los servicios de Azure que se insertan en una subred delegada tienen el conjunto básico
de propiedades, que está disponible para las subredes no delegadas, como:

Los servicios de Azure pueden insertar instancias en las subredes de los clientes,
pero no pueden afectar a las cargas de trabajo existentes.

Las directivas o rutas que aplican estos servicios son flexibles y las pueden
reemplazar el cliente.

Pasos siguientes
Delegación de una subred
Redes virtuales y máquinas virtuales en
Azure
Artículo • 25/05/2023

Al crear una máquina virtual, hay que crear una red virtual o usar una ya existente.
Decida la forma en que pretende acceder a las máquinas virtuales de la red virtual. Es
importante planear antes de crear recursos y asegurarse de que se conocen los límites
de los recursos de red.

En la siguiente imagen, las máquinas virtuales se representan como servidores web y

servidores de aplicaciones. Cada conjunto de máquinas virtuales se asigna a subredes
independientes en la red virtual.

Se puede crear una red virtual antes de crear una máquina virtual o mientras se crea.

Para que se pueda establecer comunicación con una máquina virtual, hay que crear
estos recursos:

Interfaces de red

Direcciones IP

Red virtual y subredes

Considere igualmente estos recursos opcionales:

 Grupos de seguridad de red

Equilibradores de carga

Interfaces de red
Una interfaz de red (NIC) es la interconexión entre una máquina virtual y una red virtual.
Una máquina virtual debe tener como mínimo una NIC, y puede tener más de una en
función del tamaño de la máquina virtual que se cree. Para obtener información sobre el
número de NIC aceptable en cada tamaño de máquina virtual, consulte Tamaños de las
máquinas virtuales.

Puede crear una máquina virtual con varias NIC y agregarlas o quitarlas a lo largo del
ciclo de vida de una máquina virtual. Cuando hay varias NIC, una máquina virtual se
puede conectar a diferentes subredes.

Todas las NIC conectadas a una máquina virtual deben existir en la misma ubicación y
suscripción que esta. Cada NIC debe estar conectada a una red virtual que exista en la
misma ubicación y suscripción de Azure en la que se encuentre la NIC. Puede cambiar la
subred a la que una máquina virtual está conectada después de crearla. La red virtual no
se puede cambiar. A cada NIC conectada a una máquina virtual se le asigna una
dirección MAC que no cambia hasta que se elimine la máquina virtual.

En esta tabla se enumeran los métodos que se pueden usar para crear una interfaz de
red.

Método Descripción

Azure Cuando se crea una máquina virtual en Azure Portal, se crea automáticamente una
Portal interfaz de red. El portal crea una máquina virtual con una sola NIC. Si desea crear
una máquina virtual con más de una, debe usar otro método para hacerlo.

Azure Use New-AzNetworkInterface con el parámetro -PublicIpAddressId para

PowerShell proporcionar el identificador de la dirección IP pública que creó anteriormente.

CLI de Para proporcionar el identificador de la dirección IP pública que creó anteriormente,

Azure use az network nic create con el parámetro --public-ip-address .

Plantilla Para obtener información sobre cómo implementar una interfaz de red usando una
plantilla, consulte Interfaz de red en una red virtual con dirección IP pública .

Direcciones IP
En Azure, estos tipos de direcciones IP se pueden asignar a una NIC:
 Direcciones IP públicas: se usan para la comunicación entrante y saliente (sin
traducción de direcciones de red, o NAT) con Internet y otros recursos de Azure no
conectados a una red virtual. La asignación de una dirección IP pública a una NIC
es opcional. Las direcciones IP públicas tienen un cargo nominal y se puede usar
un número máximo de ellas por suscripción.

Direcciones IP privadas: se usan para la comunicación dentro de una red virtual,

una red local e Internet (con NAT). Una máquina debe tener asignada al menos
una dirección IP privada. Para más información acerca de NAT en Azure, lea
Información sobre las conexiones salientes en Azure.

Se pueden asignar direcciones IP públicas a lo siguiente:

Máquinas virtuales

Equilibradores de carga públicos

Se pueden asignar direcciones IP privadas a lo siguiente:

Máquinas virtuales

Equilibradores de carga internos

Las direcciones IP se asignan a una máquina virtual mediante una interfaz de red.

Existen dos métodos en los que una dirección IP se asigna a un recurso: dinámico o
estático. El método predeterminado con el que Azure asigna direcciones IP es el
dinámico. Una dirección IP no se asigna cuando se crea, sino al crear una máquina
virtual o al iniciar una máquina virtual detenida. La dirección IP se libera cuando se
detiene o se elimina la máquina virtual.

Para asegurarse de que la dirección IP de la máquina virtual no cambia, puede

establecer explícitamente el método de asignación en estático. En este caso, se asigna
de inmediato una dirección IP. Solo se libera cuando se elimina la máquina virtual o
cuando se cambia su método de asignación a dinámico.

En esta tabla se enumeran los métodos que se pueden usar para crear una dirección IP.

Método Descripción

Azure Las direcciones IP públicas son dinámicas de forma predeterminada. La dirección IP

Portal puede cambiar cuando la máquina virtual se detiene o elimina. Para garantizar que
la máquina virtual siempre usa la misma dirección IP pública, cree una dirección IP
pública estática. De manera predeterminada, el portal asigna una dirección IP
privada dinámica a una NIC al crear una máquina virtual. Una vez creada esta, puede
cambiar la dirección IP a estática.
 Método Descripción

Azure Se usa New-AzPublicIpAddress con el parámetro -AllocationMethod como

PowerShell "Dynamic" o "Static".

CLI de Se usa az network public-ip create con el parámetro --allocation-method como

Azure "Dynamic" o "Static".

Plantilla Para obtener más información sobre cómo implementar una dirección IP pública
usando una plantilla, consulte Interfaz de red en una red virtual con dirección IP
pública .

Después de crear una dirección IP pública, se puede asociar a una máquina virtual. Para
ello, es preciso asignarla a una NIC.

７ Nota

Azure proporciona una dirección IP de acceso de salida predeterminado para las

máquinas virtuales que no tienen asignada una dirección IP pública o que se
encuentran en el grupo de back-end de una instancia de Azure Load Balancer del
nivel Básico interna. El mecanismo de dirección IP de acceso de salida
predeterminado proporciona una dirección IP de salida que no se puede
configurar.

La IP de acceso de salida predeterminada está deshabilitada cuando se asigna una

IP pública a la máquina virtual, la máquina virtual se coloca en el grupo de back-
end de un equilibrador de carga estándar (con o sin reglas de salida) o si se asigna
un recurso de puerta de enlace de Azure Virtual Network NAT a la subred de la
máquina virtual.

Las máquinas virtuales creadas por conjuntos de escalado de máquinas virtuales en

modo de orquestación flexible no tienen acceso de salida predeterminado.

Para obtener más información sobre las conexiones de salida en Azure, vea Acceso
de salida predeterminado y Uso de traducción de direcciones de red (SNAT) de
origen para conexiones de salida.

Red virtual y subredes

Una subred es un intervalo de direcciones IP en la red virtual. Una red virtual se puede
dividir en varias subredes para facilitar su organización o por motivos de seguridad.
Cada una de las NIC de una máquina virtual está conectada a una subred de una red
virtual. Las NIC conectadas a subredes (iguales o distintas) dentro de una red virtual
pueden comunicarse entre sí sin ninguna configuración adicional.

Al configurar una red virtual, especifique la topología, incluidos los espacios de

direcciones y las subredes disponibles. Si la red virtual está conectada a otras redes
virtuales o redes locales, seleccione intervalos de direcciones que no se solapen. Las
direcciones IP son privadas y no se puede acceder a ellas desde Internet. Azure trata
cualquier intervalo de direcciones como parte del espacio de direcciones IP de la red
virtual privada. El intervalo de direcciones solo es accesible dentro de la red virtual,
dentro de redes virtuales interconectadas y desde la ubicación local.

Si trabaja en una organización en la que otra persona es responsable de las redes

internas, póngase en contacto con ella antes de seleccionar el espacio de direcciones.
Asegúrese de que no hay solapamientos en el espacio de direcciones e indique el
espacio que quiere usar para que no intenten usar el mismo intervalo de direcciones IP.

De forma predeterminada, no hay límites de seguridad entre subredes. Las máquinas

virtuales de cada una de estas subredes pueden comunicarse. Si la implementación
necesita límites de seguridad, use grupos de seguridad de red (NSG) , que controlan el
flujo de tráfico que llega y sale tanto de las subredes como de las máquinas virtuales.

En esta tabla se muestran los métodos que se pueden usar para crear una red virtual y
subredes.

Método Descripción

Azure Si deja que Azure cree una red virtual cuando cree una máquina virtual, el nombre
Portal será una combinación del nombre del grupo de recursos que contiene la red virtual
y -vnet . El espacio de direcciones será 10.0.0.0/24, el nombre de subred requerida
será default y el intervalo de direcciones de la subred será 10.0.0.0/24.

Azure Para crear una subred y una red virtual se usan New-AzVirtualNetworkSubnetConfig
PowerShell y New-AzVirtualNetwork. También se puede usar Add-
AzVirtualNetworkSubnetConfig para agregar una subred a una red virtual existente.

CLI de La subred y la red virtual se crean al mismo tiempo. Especifique un parámetro --

Azure subnet-name en az network vnet create con el nombre de la subred.

Plantilla Para obtener más información sobre cómo usar una plantilla para crear una red
virtual y subredes, consulte Red virtual con dos subredes .

Grupos de seguridad de red

Un grupo de seguridad de red (NSG) contiene una lista de reglas de la lista de control
de acceso (ACL) que permiten o deniegan el tráfico de red a subredes, NIC, o ambas.
Los grupos de seguridad de red se pueden asociar con subredes o con NIC individuales
conectadas a una subred. Si un grupo de seguridad de red está asociado a una subred,
las reglas de la ACL se aplican a todas las máquinas virtuales de dicha subred. El tráfico
que llega a una NIC individual se puede restringir asociando un grupo de seguridad de
red directamente a la NIC.

Los grupos de seguridad de red contienen dos tipos de reglas: entrada y salida. La
prioridad de una regla debe ser única dentro de cada conjunto.

Cada regla tiene propiedades relativas a lo siguiente:

Protocolo

Intervalos de puertos de origen y destino

Prefijos de dirección

Dirección del tráfico

Prioridad

Tipo de acceso

Todos los grupos de seguridad de red contienen un conjunto de reglas

predeterminadas. No puede eliminar ni invalidar estas reglas predeterminadas, ya que
tienen la prioridad más baja y las reglas que se creen no pueden reemplazarlas.

Al asociar un grupo de seguridad de red a una NIC, las reglas de acceso de red del
grupo de seguridad de red se aplican solo a esa NIC. Si se asigna un grupo de seguridad
de red a una sola NIC en una máquina virtual con varias NIC, el tráfico de las restantes
no se verá afectado. Se pueden asociar distintos grupos de seguridad de red a una NIC
(o a una máquina virtual, según el modelo de implementación) y a la subred a la que
una NIC o una máquina virtual están enlazadas. La prioridad depende de la dirección del
tráfico.

Procure planear los grupos de seguridad de red al planear las máquinas virtuales y la
red virtual.

En esta tabla se enumeran los métodos que se pueden usar para crear un grupo de
seguridad de red.

Método Descripción
 Método Descripción

Azure Cuando se crea una máquina virtual en Azure Portal, se crea automáticamente un
Portal grupo de seguridad de red, que se asocia a la NIC que crea el portal. El nombre de
dicho grupo es una combinación del nombre de la máquina virtual y -nsg .
Este grupo de seguridad de red contiene una regla de entrada:
con una prioridad de 1000.
El servicio está establecido en RDP.
El protocolo está establecido en TCP.
El puerto está establecido en 3389.
La acción está establecida en Permitir.
Si quiere permitir algún otro tráfico entrante en la máquina virtual, cree otra regla o
reglas.

Azure Use New-AzNetworkSecurityRuleConfig y especifique la información de las reglas

PowerShell requerida. Use New-AzNetworkSecurityGroup para crear el grupo de seguridad de
red. Use Set-AzVirtualNetworkSubnetConfig para configurar el grupo de seguridad
de red para la subred. Use Set-AzVirtualNetwork para agregar el grupo de seguridad
de red a la red virtual.

CLI de Use az network nsg create para crear inicialmente el grupo de seguridad de red. Use
Azure az network nsg rule create para agregar reglas al grupo de seguridad de red. Use az
network vnet subnet update para agregar el grupo de seguridad de red a la subred.

Plantilla Use Create a Network Security Group (Creación de un grupo de seguridad de red)
como guía para la implementación de un grupo de seguridad de red mediante una
plantilla.

Equilibradores de carga
Azure Load Balancer proporciona una alta disponibilidad y un elevado rendimiento de
red a las aplicaciones. Se puede configurar un equilibrador de carga para equilibrar el
tráfico entrante de Internet a las máquinas virtuales o equilibrar el tráfico entre las
máquinas virtuales de una red virtual. Un equilibrador de carga también puede
equilibrar el tráfico entre los equipos locales y las máquinas virtuales de una red entre
entornos, o reenviar el tráfico externo a una máquina virtual concreta.

El equilibrador de carga asigna tráfico entrante y saliente entre lo siguiente:

La dirección IP pública y el puerto en el equilibrador de carga

La dirección IP privada y el puerto de la máquina virtual

Al crear un equilibrador de carga, también es preciso tener en cuenta estos elementos

de configuración:
 Configuración de IP de front-end: un equilibrador de carga puede incluir una o
varias direcciones IP de front-end. Estas direcciones IP sirven como entrada para el
tráfico.

Grupo de direcciones de back-end: direcciones IP que están asociadas a la NIC a

la que se distribuye la carga.

Enrutamiento de puerto : define el flujo de tráfico entrante a través de la

dirección IP de front-end y su distribución a la dirección IP de back-end mediante
reglas NAT de entrada.

Reglas del equlibrador de carga: asigna una combinación dada de IP de front-end

y puerto a una combinación de un conjunto de direcciones IP de back-end y
puerto. Un solo equilibrador de carga puede tener varias reglas de equilibrio de
carga. Cada regla tiene una combinación de una IP de front-end y un puerto y una
IP de back-end asociados a las máquinas virtuales.

Sondeos : supervisa el estado de las máquinas virtuales. Si un sondeo no

responde, el equilibrador de carga deja de enviar nuevas conexiones a la máquina
virtual que no funciona correctamente. Las conexiones existentes no se ven
afectadas y las nuevas conexiones se envían a las máquinas virtuales que están en
buen estado.

Reglas de salida : una regla de salida configura una traducción de direcciones de

red (NAT) de salida para todas las máquinas virtuales o instancias identificadas por
el grupo de back-end de la instancia de Standard Load Balancer que se van a
traducir para el front-end.

En esta tabla se enumeran los métodos que se pueden usar para crear un equilibrador
de carga con acceso a Internet.

Método Descripción

Portal de Puede equilibrar la carga del tráfico de Internet en máquinas virtuales mediante
Azure Azure Portal.

Azure Para proporcionar el identificador de la dirección IP pública que creó anteriormente,

PowerShell use New-AzLoadBalancerFrontendIpConfig con el parámetro -PublicIpAddress . Use
New-AzLoadBalancerBackendAddressPoolConfig para crear la configuración del
grupo de direcciones de back-end. Use New-AzLoadBalancerInboundNatRuleConfig
para crear reglas NAT de entrada asociadas a la configuración de la IP de front-end
que ha creado. Use New-AzLoadBalancerProbeConfig para crear los sondeos que
necesite. Use New-AzLoadBalancerRuleConfig para crear la configuración del
equilibrador de carga. Use New-AzLoadBalancer para crear el equilibrador de carga.
 Método Descripción

CLI de Use az network lb create para crear la configuración inicial del equilibrador de carga.
Azure Use az network lb frontend-ip create para agregar la dirección IP pública que creó
anteriormente. Use az network lb address-pool create para agregar la configuración
del grupo de direcciones de back-end. Use az network lb inbound-nat-rule create
para agregar reglas NAT. Use az network lb rule create para agregar las reglas del
equilibrador de carga. Use az network lb probe create para agregar los sondeos.

Plantilla Use tres máquinas virtuales en una instancia de Load Balancer como guía para
implementar un equilibrador de carga mediante una plantilla.

En esta tabla se enumeran los métodos que se pueden usar para crear un equilibrador
de carga interno.

Método Descripción

Portal de Puede equilibrar la carga de tráfico interno con un equilibrador de carga en Azure
Azure Portal.

Azure Para proporcionar una dirección IP privada en la subred de la red, use New-
PowerShell AzLoadBalancerFrontendIpConfig con el parámetro -PrivateIpAddress . Use New-
AzLoadBalancerBackendAddressPoolConfig para crear la configuración del grupo de
direcciones de back-end. Use New-AzLoadBalancerInboundNatRuleConfig para
crear reglas NAT de entrada asociadas a la configuración de la IP de front-end que
ha creado. Use New-AzLoadBalancerProbeConfig para crear los sondeos que
necesite. Use New-AzLoadBalancerRuleConfig para crear la configuración del
equilibrador de carga. Use New-AzLoadBalancer para crear el equilibrador de carga.

CLI de Use el comando az network lb create para crear la configuración inicial del
Azure equilibrador de carga. Para definir la dirección IP privada, use az network lb
frontend-ip create con el parámetro --private-ip-address . Use az network lb
address-pool create para agregar la configuración del grupo de direcciones de
back-end. Use az network lb inbound-nat-rule create para agregar reglas NAT. Use
az network lb rule create para agregar las reglas del equilibrador de carga. Use az
network lb probe create para agregar los sondeos.

Plantilla Use dos máquinas virtuales en una instancia de Load Balancer como guía para
implementar un equilibrador de carga mediante una plantilla.

Máquinas virtuales
Las máquinas virtuales se pueden crear en la misma red virtual, y se pueden conectar
entre sí mediante direcciones IP privadas. También pueden conectarse entre sí si están
en subredes diferentes. Se conectan sin que sea necesario configurar una puerta de
enlace ni usar direcciones IP públicas. Para colocar máquinas virtuales en una red virtual,
hay que crear la red virtual. Al ir creando cada máquina virtual, se asigna a la red virtual
y a la subred. Las máquinas virtuales obtienen su configuración de red durante la
implementación o el inicio.

Las máquinas virtuales reciben una dirección IP cuando se implementan. Si se

implementan varias máquinas virtuales en una red virtual o una subred, se les asignarán
direcciones IP cuando se inicien. También les puede asignar una dirección IP estática. Si
lo hace, conviene plantearse la posibilidad de usar una subred específica para evitar
reutilizar una dirección IP estática en otra máquina virtual por error.

Si crea una máquina virtual y, posteriormente, quiere migrarla a una red virtual, esto no
es un simple cambio de configuración. Vuelva a implementar la máquina virtual en la
red virtual. La manera más fácil de volver a implementarla es eliminar la máquina virtual,
pero no los discos conectados a ella y, después, volver a crear la máquina virtual con los
discos originales en la red virtual.

En esta tabla se enumeran los métodos que se pueden usar para crear una máquina
virtual en una red virtual.

Método Descripción

Azure Utiliza la configuración de red predeterminada que se mencionó anteriormente para

Portal crear una máquina virtual con una NIC única. Para crear una máquina virtual con
varias NIC, es preciso usar otro método.

Azure Incluye el uso de Add-AzVMNetworkInterface para agregar la NIC que creó

PowerShell anteriormente a la configuración de la VM.

CLI de Cree una máquina virtual y conéctela a una red virtual, subred y NIC creadas
Azure mediante pasos individuales.

Plantilla Use Very simple deployment of a Windows VM (Implementación muy simple de

una máquina virtual Windows) como guía para la implementación de una máquina
virtual mediante una plantilla.

NAT Gateway
Azure NAT Gateway simplifica la conectividad a Internet que sea solo de salida para
redes virtuales. Cuando se configura en una subred, todas las conexiones salientes usan
las direcciones IP públicas estáticas que se hayan especificado. La conectividad saliente
es posible sin que el equilibrador de carga ni las direcciones IP públicas estén
conectados directamente a máquinas virtuales. La NAT está totalmente administrada y
es muy resistente.

Se puede definir la conectividad de salida para todas las subredes con NAT. Distintas
subredes dentro de la misma red virtual pueden tener diferentes NAT. Para configurar
una subred, es preciso especificar qué recurso de puerta de enlace de NAT se debe usar.
Los flujos de salida UDP y TCP de todas las instancias de máquina virtual usan una
puerta de enlace NAT. NAT es compatible con los recursos de dirección IP pública o los
recursos de prefijos IP públicos, o una combinación de ambos de una SKU estándar.
Puede usar un prefijo de IP pública directamente o distribuir las direcciones IP públicas
del prefijo entre varios recursos de puerta de enlace de NAT. NAT limpia todo el tráfico
hacia el intervalo de direcciones IP del prefijo. Ahora, filtrar direcciones IP de las
implementaciones es más fácil.

NAT Gateway procesa automáticamente todo el tráfico saliente sin ninguna

configuración del cliente. No se necesitan rutas definidas por el usuario. NAT tiene
prioridad sobre otros escenarios de salida y reemplaza el destino de Internet
predeterminado de una subred.

Los conjuntos de escalado de máquinas virtuales que crean máquinas virtuales con el
modo de orquestación flexible no tienen acceso de salida predeterminado. Azure NAT
Gateway es el método de acceso de salida recomendado para el modo de orquestación
flexible de los conjuntos de escalado de máquinas virtuales.

Para más información sobre Azure NAT Gateway, consulte ¿Qué es Azure NAT Gateway?.

En esta tabla se muestran los métodos que se pueden usar para crear un recurso de
puerta de enlace NAT.

Método Descripción

Azure Crea una red virtual, una subred, una dirección IP pública, una puerta de enlace NAT
Portal y una máquina virtual para probar el recurso de puerta de enlace NAT.

Azure Incluye el uso de New-AzNatGateway para crear un recurso de puerta de enlace

PowerShell NAT. Crea una red virtual, una subred, una dirección IP pública, una puerta de enlace
NAT y una máquina virtual para probar el recurso de puerta de enlace NAT.

CLI de Incluye el uso de az network nat gateway create para crear un recurso de puerta de
Azure enlace NAT. Crea una red virtual, una subred, una dirección IP pública, una puerta de
enlace NAT y una máquina virtual para probar el recurso de puerta de enlace NAT.

Plantilla Crea una red virtual, una subred, una dirección IP pública y un recurso de puerta de
enlace NAT.

Azure Bastion
Azure Bastion se implementa para proporcionar conectividad de administración segura
a las máquinas virtuales de una red virtual. El servicio Azure Bastion permite conectarse
sin fisuras y de forma segura mediante RDP y SSH a las máquinas virtuales de la red
virtual. Asimismo, permite conectarse sin exponer una dirección IP pública en la
máquina virtual. Las conexiones se realizan directamente desde Azure Portal, sin
necesidad de un software o un cliente/agente adicional. Azure Bastion admite
direcciones IP públicas de SKU estándar.

Los precios por hora comienzan desde el momento en que se implementa Bastion,
independientemente del uso de datos salientes. Para más información, consulte
Precios y SKU. Si va a implementar Bastion como parte de un tutorial o prueba, se
recomienda eliminar este recurso una vez que haya terminado de usarlo.

Para más información sobre Azure Bastion, consulte ¿Qué es Azure Bastion?

En esta tabla se muestran los métodos que se pueden usar para crear una
implementación de Azure Bastion.

Método Descripción

Azure Crea una red virtual, subredes, una dirección IP pública, un host bastión y máquinas
Portal virtuales.

Azure Crea una red virtual, subredes, una dirección IP pública y un host bastión. Incluye el
PowerShell uso de New-AzBastion para crear un host bastión.

CLI de Crea una red virtual, subredes, una dirección IP pública y un host bastión. Incluye el
Azure uso de az network bastion create para crear un host bastión.

Plantilla Para ver un ejemplo de una implementación de plantilla que integra un host de
Azure Bastion con una implementación de ejemplo, consulte Inicio rápido: Creación
de un equilibrador de carga público para equilibrar la carga de las máquinas
virtuales mediante una plantilla de Resource Manager.

Pasos siguientes
Para conocer los pasos específicos para máquinas virtuales sobre cómo administrar
redes virtuales de Azure en máquinas virtuales, consulte los tutoriales de Windows o
Linux.

También hay guías de inicio rápido sobre cómo equilibrar la carga de las máquinas
virtuales y crear aplicaciones mediante la CLI o PowerShell

Aprenda a configurar conexión de red virtual a red virtual.

Aprenda a solucionar problemas de rutas.

Más información sobre Ancho de banda de la red de máquinas virtuales.

Planear redes virtuales
Artículo • 25/03/2023

Crear una red virtual con la cual experimentar es bastante sencillo, pero es probable
que, con el tiempo, implemente varias redes virtuales para satisfacer las necesidades de
producción que tiene su organización. Con cierto planeamiento, podrá implementar
redes virtuales y conectar los recursos que necesita de manera más eficaz. La
información de este artículo es más útil si ya está familiarizado con las redes virtuales y
tiene cierta experiencia al trabajar con ellas. Si no está familiarizado con las redes
virtuales, le recomendamos que lea la información general sobre Virtual Network.

Nomenclatura
Todos los recursos de Azure tienen un nombre. El nombre debe ser único dentro de un
ámbito, que puede variar para cada tipo de recurso. Por ejemplo, el nombre de una red
virtual debe ser único dentro de un grupo de recursos, pero puede haber duplicados del
nombre dentro de una suscripción o región de Azure. Definir una convención de
nomenclatura que pueda usar de forma consistente al asignar nombres a recursos le
será de utilidad al administrar varios recursos de red con el tiempo. Consulte Naming
conventions (Convenciones de nomenclatura) para obtener sugerencias.

Regions
Todos los recursos de Azure se crean en una suscripción y una región de Azure. Un
recurso solo se puede crear en una red virtual que exista en la misma región y
suscripción de ese recurso. No obstante, puede conectar redes virtuales que ya existan a
diferentes suscripciones y regiones. Para obtener más información,
consulteConectividad. Al decidir en qué regiones implementar los recursos, debe tener
en cuenta dónde se encuentran físicamente los consumidores de esos recursos:

Los consumidores de recursos normalmente quieren obtener la latencia de red

más baja para sus recursos. Para determinar las latencias relativas entre una
ubicación específica y las regiones de Azure, consulte View relative latencies (Ver
latencias relativas).
¿Debe cumplir con requisitos de residencia, soberanía, cumplimiento o resistencia
de datos? Si es así, es fundamental elegir la región que mejor se ajuste a sus
requisitos. Para obtener más información, consulte Zonas geográficas de Azure .
¿Necesita configurar la resistencia en Azure Availability Zones dentro de la misma
región de Azure para los recursos que está implementando? Puede implementar
 recursos como máquinas virtuales (VM) en diferentes zonas de disponibilidad
dentro de la misma red virtual. Sin embargo, no todas las regiones de Azure
admiten zonas de disponibilidad. Para obtener más información sobre las zonas de
disponibilidad y las regiones que las admiten, consulte Zonas de disponibilidad.

Suscripciones
Puede implementar tantas redes virtuales como sea necesario en cada suscripción, hasta
el límite que se haya establecido. Por ejemplo, algunas organizaciones tienen
suscripciones distintas para diferentes departamentos. Para obtener más información y
detalles en torno a las suscripciones, consulte Gobernanza de suscripción.

Segmentación
Puede crear varias redes virtuales por suscripción y por región. Puede crear varias
subredes en cada red virtual. Los detalles siguientes le ayudarán a determinar cuántas
redes virtuales y subredes necesita:

Redes virtuales
Una red virtual es una parte virtual y aislada de la red pública de Azure. Cada red virtual
está dedicada a su suscripción. Qué debe tener en cuenta al decidir si quiere crear una o
varias redes virtuales en una suscripción:

¿Hay algún requisito de seguridad en la organización para aislar el tráfico en redes

virtuales diferentes? Puede elegir conectar la redes virtuales o no. Si conecta las
redes virtuales, puede implementar una aplicación virtual de red (como un firewall)
para controlar el flujo de tráfico entre las redes virtuales. Para obtener más
información, consulte seguridad y conectividad.
¿Hay algún requisito en la organización para aislar las redes virtuales en diversas
suscripciones o regiones?
Una interfaz de red permite que una máquina virtual se comunique con otros
recursos. Cada interfaz de red puede tener una o varias direcciones IP privadas
asignadas. ¿Cuántas interfaces de red y direcciones IP privadas se necesitan en una
red virtual? Hay límites en el número de interfaces de red y direcciones IP privadas
que se pueden tener en una red virtual.
¿Quiere conectar la red virtual a otra red virtual o red local? Puede conectar
algunas redes virtuales entre sí o a redes locales, pero no a otras redes. Para
obtener más información, consulteConectividad. Cada red virtual que se conecta a
otra red virtual o local debe tener un espacio de direcciones único. Cada red virtual
 tiene uno o más intervalos de direcciones públicas o privadas asignados a su
espacio de direcciones. Un intervalo de direcciones se especifica en un formato
propio del enrutamiento de interdominios sin clases (CIDR), como 10.0.0.0/16.
Obtenga más información sobre los intervalos de direcciones para redes virtuales.
¿Tiene algún requisito de administración de la organización para recursos en
diferentes redes virtuales? De ser así, puede separar los recursos en una red virtual
a parte para simplificar la asignación de permisos a los usuarios de la organización,
o para asignar diferentes directivas a diferentes redes virtuales.
Cuando implementa algunos recursos del servicio de Azure en una red virtual,
estos se encargan de crear su propia red virtual. Para determinar si un servicio de
Azure ha creado su propia red virtual, consulte la información de cada servicio de
Azure que se puede implementar en una red virtual.

Subredes
Una red virtual se puede segmentar en una o más subredes hasta el límite que se haya
establecido. Qué debe tener en cuenta al decidir si quiere crear una subred o varias
redes virtuales en una suscripción:

Cada subred debe tener un intervalo de direcciones único, especificado en formato

CIDR, en el espacio de direcciones de la red virtual. Este intervalo de direcciones no
puede superponerse con otras subredes de la red virtual.
Si planea implementar algunos recursos del servicio de Azure en una red virtual,
seguramente necesiten crear su propia subred, por lo que debe haber suficiente
espacio no asignado para que puedan hacerlo. Para determinar si un servicio de
Azure ha creado su propia subred, consulte la información de cada servicio de
Azure que se puede implementar en una red virtual. Por ejemplo, si conecta una
red virtual a una red local mediante Azure VPN Gateway, la red virtual debe tener
una subred dedicada para la puerta de enlace. Obtenga más información sobre las
subredes de puerta de enlace.
De forma predeterminada, Azure enruta el tráfico de red entre todas las subredes
de una red virtual. Por ejemplo, puede invalidar el enrutamiento predeterminado
de Azure para evitar el enrutamiento de Azure entre subredes, o para enrutar el
tráfico entre subredes a través de una aplicación virtual de red. Si necesita que el
tráfico entre recursos de la misma red virtual fluya a través de una aplicación
virtual de red (NVA), implemente los recursos en diferentes subredes. Obtenga
más información en el apartado Seguridad.
Puede limitar el acceso a recursos de Azure como, por ejemplo, una cuenta de
almacenamiento de Azure o Azure SQL Database, a subredes específicas con un
punto de conexión de servicio de red virtual. Además, puede denegar el acceso a
los recursos desde Internet. Puede crear varias subredes y habilitar un punto de
 conexión de servicio para algunas subredes, pero no para otras. Obtenga más
información sobre los puntos de conexión de servicio y los recursos de Azure
puede habilitar.
Puede asociar un grupo de seguridad de red o ninguno, a cada subred de una red
virtual. Puede asociar el mismo grupo de seguridad de red u otro diferente a cada
subred. Cada grupo de seguridad de red contiene reglas que permiten o niegan el
paso del tráfico hacia y desde los orígenes y destinos. Más información sobre los
grupos de seguridad de red.

Seguridad
Puede filtrar el tráfico de red hacia y desde los recursos en una red virtual mediante los
grupos de seguridad de red y las aplicaciones virtuales de red. Puede controlar la
manera en que Azure enruta el tráfico de subredes. Asimismo, también puede limitar en
su organización quién puede trabajar con los recursos en redes virtuales.

Filtrado de tráfico
Puede filtrar el tráfico de red entre recursos de una red virtual mediante un grupo
de seguridad de red, una NVA que filtra el tráfico de red o ambos. Para
implementar una NVA como un cortafuegos para filtrar el tráfico de red, consulte
Azure Marketplace . Al usar una NVA, también crea rutas personalizadas para
enrutar el tráfico de las subredes a la NVA. Obtenga más información acerca el
enrutamiento del tráfico.
Un grupo de seguridad de red contiene varias reglas de seguridad
predeterminadas que permiten o deniegan el tráfico hacia o desde los recursos. Un
grupo de seguridad de red se puede asociar a una interfaz de red, a la subred que
se encuentra en ella o a ambas. Siempre que sea posible y para simplificar la
administración de reglas de seguridad, le recomendamos que asocie un grupo de
seguridad de red a las subredes individuales, en lugar de asociarlo a las interfaces
de red individuales de la subred.
Si debe aplicar reglas de seguridad a varias máquinas virtuales de una subred,
puede asociar la interfaz de red en la máquina virtual a uno o varios grupos de
seguridad de aplicaciones. Una regla de seguridad puede especificar un grupo de
seguridad de aplicaciones en el origen, en el destino o en ambos. A continuación,
solo se aplica dicha regla a las interfaces de red que forman parte del grupo de
seguridad de aplicaciones. Obtenga más información sobre los grupos de
seguridad de red y los grupos de seguridad de aplicaciones.
Cuando un grupo de seguridad de red está asociado en el nivel de subred, se
aplica a todas las NIC de la subred, no solo al tráfico procedente de fuera de la
 subred. Esto significa que el tráfico entre las máquinas virtuales contenidas en la
subred también puede verse afectado.
Azure crea de forma predeterminada varias reglas de seguridad en cada grupo de
seguridad de red. Una regla predeterminada permite que todo el tráfico fluya
entre todos los recursos de una red virtual. Para invalidar este comportamiento,
use los grupos de seguridad de red, el enrutamiento personalizado para enrutar el
tráfico a una NVA o ambas opciones. Le recomendamos que se familiarice con
todas las reglas de seguridad predeterminadas de Azure, y con la forma de aplicar
las reglas del grupo de seguridad de red a un recurso.

Puede ver los diseños de ejemplo para implementar una red perimetral (también
conocida como DMZ) entre Azure e Internet mediante NVA.

Enrutamiento del tráfico

Azure crea varias rutas predeterminadas para el tráfico saliente desde una subred.
Puede invalidar el enrutamiento predeterminado de Azure si crea una tabla de rutas y la
asocia a una subred. Los motivos más comunes para invalidar el enrutamiento
predeterminado de Azure son:

Porque quiere que el tráfico entre subredes fluya a través de una NVA. Más
información sobre cómo configurar las tablas de rutas para forzar el tráfico a través
de una NVA.
Porque quiere forzar todo el tráfico de Internet a través de una NVA o de forma
local, a través de Azure VPN Gateway. Forzar el tráfico de Internet de forma local
para su inspección y registro a menudo se conoce como "tunelización forzada".
Obtenga más información sobre la configuración de la tunelización forzada.

Si tiene que implementar el enrutamiento personalizado, le recomendamos que se

familiarice con el enrutamiento en Azure.

Conectividad
Puede conectar una red virtual a otras redes virtuales mediante el emparejamiento de
redes virtuales, o puede conectarla a una red local mediante Azure VPN Gateway.

Emparejamiento
Al usar el emparejamiento de redes virtuales, las redes virtuales pueden estar en las
mismas regiones de Azure compatibles o en diferentes regiones. Las redes virtuales
pueden estar en las mismas suscripciones de Azure (incluso suscripciones que
pertenezcan a diferentes inquilinos de Azure Active Directory), o en otras diferentes. Le
recomendamos que se familiarice con los requisitos y restricciones de emparejamiento
antes de crear un emparejamiento. El ancho de banda entre recursos de redes virtuales
emparejadas en la misma región es el mismo que si los recursos estuvieran en la misma
red virtual.

puerta de enlace de VPN

Puede usar Azure VPN Gateway para conectar una red virtual a la red local mediante un
VPN de sitio a sitio, o mediante una conexión dedicada con Azure ExpressRoute.

Puede combinar el emparejamiento y una puerta de enlace de VPN para crear redes de
tipo hub-and-spoke, donde las redes virtuales denominadas "radios" (spoke) se
conectan a una red virtual denominada "concentrador" (hub) y, a su vez, ese
concentrador se conecta a una red local, por ejemplo.

Resolución de nombres
Los recursos de una red virtual no pueden resolver los nombres de los recursos de una
red virtual emparejada mediante el DNS integrado de Azure. Para resolver nombres en
una red virtual emparejada, despliegue su propio servidor DNS, o use los dominios
privados de Azure DNS. Recuerde que la resolución de nombres entre recursos en una
red virtual y en redes locales también requiere que implemente su propio servidor DNS.

Permisos
Azure usa el control de acceso basado en rol de Azure (RBAC de Azure) para los
recursos. Se asignan permisos a un ámbito según la siguiente jerarquía: grupo de
administración, suscripción, grupo de recursos y recurso individual. Para obtener más
información acerca de la jerarquía, consulte Organización de los recursos. Para trabajar
con redes virtuales de Azure y todas sus capacidades relacionadas, como el
emparejamiento, los grupos de seguridad de red, los puntos de conexión de servicio y
las tablas de rutas, puede asignar miembros de la organización a los roles integrados
Propietario, Colaborador o Colaborador de red y, a continuación, asignar uno de esos
roles a un ámbito adecuado. Si quiere asignar permisos específicos para un subconjunto
de capacidades de red virtual, cree un rol personalizado y asigne al rol los permisos
específicos necesarios para redes virtuales, subredes y puntos de conexión de servicio,
interfaces de red, emparejamientos, grupos de seguridad de aplicaciones y red o tablas
de rutas.
Directiva
Azure Policy le permite crear, asignar y administrar las definiciones de directivas. Las
definiciones de directivas aplican distintas reglas en los recursos, para que estos sigan
siendo compatibles con los estándares de la organización y los contratos de nivel de
servicio. Azure Policy ejecuta una evaluación de los recursos, para detectar los que no
son compatibles con las definiciones de directivas que tiene. Por ejemplo, puede definir
y aplicar una directiva que permita la creación de redes virtuales en un solo grupo de
recursos o región específicos. Otra directiva puede requerir que cada subred tenga un
grupo de seguridad de red asociado a ella. Estas directivas se evalúan al crear y
actualizar los recursos.

Igualmente, las directivas se aplican según la jerarquía siguiente: grupo de

administración, suscripción y grupo de recursos. Obtenga más información sobre Azure
Policy o acerca de cómo implementar algunas definiciones de Azure Policy.

Pasos siguientes
Obtenga información acerca de todas las tareas, configuración y opciones para una red
virtual, subred y punto de conexión de servicio, interfaz de red, emparejamiento, grupo
de seguridad de red y aplicaciones o tabla de rutas.
Resolución de nombres de recursos en
redes virtuales de Azure
Artículo • 08/05/2023

Azure se puede usar para hospedar soluciones híbridas, IaaS. y PaaS. Para facilitar la
comunicación entre las máquinas virtuales (VM) y otros recursos implementados en una
red virtual, puede ser necesario permitirles comunicarse entre sí. El uso de nombres
inmutables y que se pueden recordar fácilmente simplifica el proceso de comunicación,
en lugar de depender de direcciones IP.

Si los recursos implementados en redes virtuales necesitan resolver nombres de

dominio en direcciones IP internas, pueden usar uno de cuatro métodos:

Zonas privadas de Azure DNS

Resolución de nombres de Azure

Resolución de nombres con su propio servidor DNS (que puede reenviar consultas
a los servidores DNS proporcionados por Azure)

Azure DNS Private Resolver

El tipo de resolución de nombres que tenga que usar dependerá de cómo se

comuniquen los recursos entre sí. En la siguiente tabla se muestran los escenarios y las
soluciones de resolución de nombre correspondientes:

７ Nota

Las zonas privadas de Azure DNS son la solución preferida y proporcionan

flexibilidad para la administración de los registros y las zonas DNS. Para obtener
más información, vea Uso de Azure DNS para dominios privados.

７ Nota

Si usa un DNS proporcionado por Azure, el sufijo DNS adecuado se aplicará

automáticamente a las máquinas virtuales. Para todas las demás opciones, debe
usar nombres de dominio completos (FQDN) o aplicar manualmente el sufijo DNS
adecuado a las máquinas virtuales.
Escenario Solución Sufijo
DNS

Resolución de nombres entre Zonas privadas de Azure DNS o resolución de Nombre

máquinas virtuales ubicadas nombres proporcionada por Azure de host
en la misma red virtual, o o FQDN
instancias de rol de Azure
Cloud Services en el mismo
servicio en la nube.

Resolución de nombres entre Zonas privadas de Azure DNS, Azure DNS Private Solo
máquinas virtuales en redes Resolver, o servidores DNS administrados por el FQDN
virtuales diferentes o cliente que reenvían consultas entre las redes
instancias de rol en diferentes virtuales para la resolución mediante Azure (proxy
servicios en la nube. DNS). Consulte Resolución de nombres mediante su
propio servidor DNS.

Resolución de nombres de Azure DNS Private Resolver o servidores DNS Solo

Azure App Service (aplicación administrados por el cliente que reenvían consultas FQDN
web, función o bot) mediante entre redes virtuales para la resolución mediante
la integración de red virtual Azure (proxy DNS). Consulte Resolución de nombres
con instancias de rol o mediante su propio servidor DNS.
máquinas virtuales en la
misma red virtual.

Resolución de nombres entre Azure DNS Private Resolver o servidores DNS Solo
instancias de App Service Web administrados por el cliente que reenvían consultas FQDN
Apps en máquinas virtuales en entre redes virtuales para la resolución mediante
la misma red virtual. Azure (proxy DNS). Consulte Resolución de nombres
mediante su propio servidor DNS.

Resolución de nombres de Azure DNS Private Resolver o servidores DNS Solo

App Service Web Apps de una administrados por el cliente que reenvían consultas FQDN
máquina virtual a las máquinas entre redes virtuales para la resolución mediante
virtuales de otra red virtual. Azure (proxy DNS). Consulte Resolución de nombres
mediante su propio servidor DNS.

Resolución de nombres de Azure DNS Private Resolver o servidores DNS Solo

servicios y de equipos locales administrados por el cliente (controlador de dominio FQDN
de máquinas virtuales o local, controlador de dominio de solo lectura local o
instancias de rol en Azure. un DNS secundario sincronizado mediante
transferencias de zona, por ejemplo). Consulte
Resolución de nombres mediante su propio servidor
DNS.

Resolución de nombres de Reenvío de consultas a un servidor proxy DNS Solo

host de Azure desde equipos administrado por el cliente en la red virtual FQDN
locales. correspondiente: el servidor proxy reenvía consultas
a Azure para su resolución. Consulte Resolución de
nombres mediante su propio servidor DNS.
 Escenario Solución Sufijo
DNS

DNS inverso para direcciones Zonas privadas de Azure DNS, resolución de No

IP internas. nombres proporcionada por Azure, Azure DNS aplicable
Private Resolver, o resolución de nombres mediante
su propio servidor DNS.

Resolución de nombres entre No aplicable. La conectividad entre máquinas No

máquinas virtuales o instancias virtuales e instancias de rol de diferentes servicios en aplicable
de rol ubicadas en diferentes la nube no se admite fuera de una red virtual.
servicios en la nube y no en
una red virtual.

Resolución de nombres de Azure

La resolución de nombres proporcionada por Azure solo ofrece las funcionalidades
autoritativas básicas de DNS. Azure administra los nombres y registros de la zona DNS si
usa el DNS proporcionado por Azure. No puede controlar los nombres de zona DNS ni
el ciclo de vida de los registros DNS. Si necesita una solución de DNS completa para sus
redes virtuales, puede usar zonas privadas de Azure DNS con servidores DNS
administrados por el cliente o una instancia de Azure DNS Private Resolver.

Junto con la resolución de nombres DNS públicos, Azure proporciona una resolución de
nombres interna para máquinas virtuales e instancias de rol que residen dentro de la
misma red virtual o servicio en la nube. Las máquinas virtuales y las instancias en un
servicio en la nube comparten el mismo sufijo DNS (por lo que el nombre de host por sí
solo es suficiente). No obstante, en las redes virtuales implementadas con el modelo de
implementación clásica, diferentes servicios en la nube tienen distintos sufijos DNS. En
esta situación, es necesario el FQDN para resolver los nombres entre diferentes servicios
en la nube. En las redes virtuales implementadas con el modelo de implementación de
Azure Resource Manager, el sufijo DNS es coherente entre todas las máquinas virtuales
de una red virtual, de modo que no es necesario el FQDN. Los nombres DNS se pueden
asignar a máquinas virtuales y a interfaces de red. Aunque la resolución de nombres que
proporciona Azure no necesita ningún tipo de configuración, no es la opción más
adecuada para todos los escenarios de implementación, como se detalla en la tabla
anterior.

７ Nota

En el caso de los roles web y de trabajo de servicios en la nube, puede acceder a las
direcciones IP internas de las instancias de rol mediante la API de REST de
administración de servicios de Azure. Para obtener más información, consulte la
 Referencia de la API REST de administración de servicios. La dirección se basa en
el nombre de rol y el número de instancia.

Características
La resolución de nombres proporcionada por Azure incluye las siguientes características:

Facilidad de uso. No se requiere ninguna configuración.

Alta disponibilidad. No es necesario crear clústeres de sus propios servidores DNS

ni administrarlos.

Puede utilizar el servicio junto con sus propios servidores DNS para resolver
nombres de host de Azure y locales.

Puede usar la resolución de nombres entre las máquinas virtuales y las instancias
de rol del mismo servicio en la nube, sin necesidad de un nombre de dominio
completo.

Puede usar la resolución de nombres entre las máquinas virtuales en redes

virtuales que usan el modelo de implementación de Azure Resource Manager, sin
necesidad de un nombre de dominio completo. En el modelo de implementación
clásica, las redes virtuales requieren un FQDN cuando se resuelven nombres en
diferentes servicios en la nube.

Puede usar los nombres de host que describan mejor las implementaciones, en
lugar de trabajar con nombres generados automáticamente.

Consideraciones
Puntos que deben tenerse en cuenta cuando se utiliza la resolución de nombres de
Azure:

El sufijo DNS creado por Azure no se puede modificar.

La búsqueda de DNS está en el ámbito de una red virtual. Los nombres DNS
creados para una red virtual no se pueden resolver desde otras redes virtuales.

No puede registrar manualmente sus propios registros.

No se admiten ni WINS ni NetBIOS. No puede ver sus máquinas virtuales en el

Explorador de Windows.
 Los nombres de host deben ser compatibles con DNS. Los nombres solo pueden
contener los caracteres 0-9, a-z y "-", y no pueden empezar ni terminar por "-".

El tráfico de consultas de DNS está limitado por cada máquina virtual. La limitación
no debería afectar a la mayoría de las aplicaciones. Si se observa una limitación de
solicitudes, asegúrese de que está habilitado el almacenamiento en caché del lado
cliente. Para más información, consulte Configuración de cliente DNS.

Use un nombre diferente para cada máquina virtual de una red virtual para evitar
problemas de resolución de DNS.

En un modelo de implementación clásico, solo se registran las máquinas virtuales

de los 180 primeros servicios en la nube para cada red virtual clásica. Este límite no
se aplica a las redes virtuales en Azure Resource Manager.

La dirección IP de Azure DNS es 168.63.129.16. Esta dirección es una dirección IP

estática y no cambia.

Consideraciones sobre el DNS inverso

Se admite DNS inverso para las máquinas virtuales en todas las redes virtuales basadas
en Azure Resource Manager. Los registros de DNS inverso (PTR) administrados por
Azure con el formato [nombre_de_vm].internal.cloudapp.net se agregan
automáticamente al iniciar una máquina virtual y se quitan cuando la máquina virtual se
detiene (desasigna). Observe el ejemplo siguiente:

Símbolo del sistema de Windows

C:\>nslookup -type=ptr 10.11.0.4

Server: UnKnown
Address: 168.63.129.16

Non-authoritative answer:
4.0.11.10.in-addr.arpa name = myeastspokevm1.internal.cloudapp.net

Azure administra la zona DNS inversa internal.cloudapp.net y no se puede ver ni editar

directamente. La búsqueda directa por FQDN con el formato
[nombre_de_vm].internal.cloudapp.net también se resuelve con la dirección IP
asignada a la máquina virtual.

Si una zona privada de Azure DNS está vinculada a la red virtual con un vínculo de red
virtual y el registro automático está habilitado en ese vínculo, las consultas de DNS
inverso devuelven dos registros. Un registro tiene el formato [nombre_de_vm].
[nombre_de_zona_dns_privada] y el otro tiene el formato
[nombre_de_vm].internal.cloudapp.net. Observe el ejemplo siguiente:

Símbolo del sistema de Windows

C:\>nslookup -type=ptr 10.20.2.4

Server: UnKnown
Address: 168.63.129.16

Non-authoritative answer:
4.2.20.10.in-addr.arpa name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa name = mywestvm1.azure.contoso.com

Cuando se devuelven dos registros PTR como hemos visto antes, la búsqueda directa de
cualquier FQDN devuelve la dirección IP de la máquina virtual.

La búsqueda de DNS inverso tiene el ámbito de una red virtual determinada, aunque
esté emparejada con otras redes virtuales. Las consultas de DNS inverso para
direcciones IP de máquinas virtuales que se encuentran en redes virtuales emparejadas
devuelven NXDOMAIN.

７ Nota

Los registros de DNS inverso (PTR) no se almacenan en una zona DNS privada de
reenvío. Los registros de DNS inverso se almacenan en una zona DNS inversa (in-
addr.arpa). La zona DNS inversa predeterminada asociada a una red virtual no se
puede ver ni editar.

Si desea desactivar la función de DNS inverso en una red virtual, cree su propia zona de
búsqueda inversa con zonas privadas de Azure DNS y vincule esta zona a la red virtual.
Por ejemplo, si el espacio de direcciones IP de la red virtual es 10.20.0.0/16, puede crear
una zona DNS privada vacía 20.10.in-addr.arpa y vincularla a la red virtual. Esta zona
invalida las zonas de búsqueda inversa predeterminadas para la red virtual. Esta zona
está vacía. DNS inverso devuelve NXDOMAIN a menos que cree manualmente estas
entradas.

No se admite el registro automático de registros PTR. Si desea crear entradas, escríbalas

manualmente. Debe deshabilitar el registro automático en la red virtual si está
habilitado para otras zonas. Esta limitación se debe a restricciones que permiten que
solo se vincule una zona privada si el registro automático está habilitado. Consulte Inicio
rápido: Creación de una zona DNS privada de Azure con Azure Portal para obtener más
información sobre cómo crear una zona DNS privada y vincularla a una red virtual.
 ７ Nota

Dado que las zonas privadas de Azure DNS son globales, puede crear una
búsqueda de DNS inversa que abarque varias redes virtuales. Para ello, cree una
zona privada de Azure DNS para búsquedas inversas (una zona in-addr.arpa) y
vincúlela a las redes virtuales. Deberá administrar manualmente los registros de
DNS inverso para las máquinas virtuales.

Configuración del cliente DNS

Esta sección trata los intentos del lado cliente y el almacenamiento en caché del cliente.

Almacenamiento en caché del lado cliente

No todas las consultas DNS deben enviarse a través de la red. El almacenamiento en
caché del cliente ayuda a reducir la latencia y a mejorar la resistencia a la señalización
visual de la red mediante la resolución de las consultas DNS periódicas desde una
memoria caché local. Los registros DNS contienen un mecanismo para contabilizar el
período de vida (TTL), lo que permite a la memoria caché almacenar el registro el
máximo tiempo posible sin afectar a la actualización de registros. Por ello, el
almacenamiento en caché del cliente es adecuado para la mayoría de las situaciones.

El cliente DNS de Windows predeterminado tiene una memoria caché DNS integrada.
Algunas distribuciones de Linux no incluyen el almacenamiento en caché de forma
predeterminada. Si comprueba que aún no hay una memoria caché local, agregue una
memoria caché DNS a cada máquina virtual Linux.

Hay muchos paquetes de almacenamiento en caché de DNS disponibles; por ejemplo,

dnsmasq. Aquí se indica cómo instalar dnsmasq en las distribuciones más habituales:

RHEL, CentOS

RHEL/CentOS (usa NetworkManager):

1. Instale el paquete dnsmasq con el siguiente comando:

Bash

sudo yum install dnsmasq

2. Habilite el servicio dnsmasq con el siguiente comando:

 Bash

systemctl enable dnsmasq.service

3. Inicie el servicio dnsmasq con el siguiente comando:

Bash

systemctl start dnsmasq.service

4. Use un editor de texto para agregar prepend domain-name-servers 127.0.0.1;

a /etc/dhclient-eth0.conf:

5. Use el siguiente comando para reiniciar el servicio de red:

Bash

service network restart

７ Nota

El paquete dnsmasq constituye solo una de las muchas memorias cachés DNS
disponibles para Linux. Antes de usarlo, compruebe su idoneidad para sus
necesidades concretas y que no esté instalada ninguna otra memoria caché.

Reintentos del cliente

DNS es principalmente un protocolo UDP. Como el protocolo UDP no garantiza la
entrega de mensajes, la lógica de reintento se controla en el mismo protocolo DNS.
Cada cliente DNS (sistema operativo) puede presentar una lógica de reintento diferente
en función de la preferencia del creador:

Los sistemas operativos Windows realizan un reintento tras un segundo y después

tras otros dos, cuatro y otros cuatro segundos.
El programa de instalación predeterminado de Linux lo intenta después de cinco
segundos. Se recomienda cambiar las especificaciones de reintento a cinco veces,
en intervalos de un segundo.

Compruebe la configuración actual en una VM de Linux con cat /etc/resolv.conf . Mire

la línea options, por ejemplo:
 Resultados

options timeout:1 attempts:5

El archivo resolv.conf se genera automáticamente y no se debe editar. Los pasos

específicos para agregar la línea options varían según la distribución:

RHEL, CentOS

RHEL/CentOS (usa NetworkManager):

1. Use un editor de texto para agregar la línea RES_OPTIONS="options timeout:1

attempts:5" al archivo /etc/sysconfig/network-scripts/ifcfg-eth0.

2. Use el siguiente comando para reiniciar el servicio de NetworkManager:

Bash

systemctl restart NetworkManager.service

Resolución de nombres con su propio servidor

DNS
En esta sección se tratan las máquinas virtuales, las instancias de rol y las aplicaciones
web.

７ Nota

Azure DNS Private Resolver reemplaza la necesidad de usar servidores DNS

basados en máquinas virtuales en una red virtual. En la sección siguiente se
proporciona si quiere usar una solución DNS basada en máquinas virtuales, pero
hay muchas ventajas para usar Azure DNS Private Resolver, incluida la reducción de
costos, la alta disponibilidad integrada, la escalabilidad y la flexibilidad.

Máquinas virtuales e instancias de rol

Puede que sus necesidades de resolución de nombres superen las posibilidades de las
características de Azure. Por ejemplo, es posible que necesite utilizar dominios de
Microsoft Windows Server Active Directory y resolver nombres DNS entre redes
virtuales. Para admitir estos escenarios, Azure le permite usar sus propios servidores
DNS.

Los servidores DNS dentro de una red virtual pueden reenviar consultas DNS a las
resoluciones recursivas en Azure. Este procedimiento le permite resolver los nombres de
host dentro de esa red virtual. Por ejemplo, un controlador de dominio (DC) que se
ejecute en Azure puede responder a las consultas DNS referidas a sus dominios y
reenviar todas las demás consultas a Azure. El reenvío de consultas permite que las
máquinas virtuales vean sus recursos locales (mediante el controlador de dominio) y los
nombres de host proporcionados por Azure (mediante el reenviador). El acceso a las
resoluciones recursivas de Azure se proporciona mediante la IP virtual 168.63.129.16.

） Importante

Si VPN Gateway se usa en esta configuración junto con la dirección IP del servidor
DNS personalizada en la red virtual, la dirección IP de Azure DNS (168.63.129.16)
debe agregarse también en la lista para mantener el servicio sin interrumpir.

El reenvío de DNS también habilita la resolución de DNS entre redes virtuales y permite
que los equipos locales resuelvan nombres de host proporcionados por Azure. Para
resolver el nombre de host de una máquina virtual, la máquina virtual del servidor DNS
debe residir en la misma red virtual y debe configurarse para reenviar consultas de
nombre de host a Azure. Dado que el sufijo DNS es diferente en cada red virtual, puede
usar las reglas de desvío condicional para enviar consultas de DNS a la red virtual
correcta para su resolución. En la imagen siguiente se muestran dos redes virtuales y
una red local que está realizando resolución DNS entre redes virtuales con este método.
Puede encontrar un reenviador DNS de ejemplo disponible en la galería de plantillas de
inicio rápido de Azure y en GitHub .

７ Nota

Una instancia de rol puede realizar la resolución de nombres de máquinas virtuales

dentro de la misma red virtual. Para ello, use el FQDN, que consta del nombre de
host de la máquina virtual y el sufijo DNS internal.cloudapp.net. Sin embargo, en
este caso, la resolución de nombres solo es correcta si la instancia de rol tiene el
nombre de máquina virtual definido en el esquema Role (archivo .cscfg). <Role
name="<role-name>" vmName="<vm-name>">

Las instancias de rol que tienen que realizar la resolución de nombres de máquinas
virtuales en otra red virtual (FQDN utilizando el sufijo internal.cloudapp.net) tienen
 que hacerlo con el método descrito en esta sección (reenvío de servidores DNS
personalizados entre las dos redes virtuales).

Cuando se utiliza la resolución de nombres proporcionada por Azure, el Protocolo de

configuración dinámica de host (DHCP) de Azure proporciona un sufijo DNS interno
(.internal.cloudapp.net) a cada máquina virtual. Este sufijo permite la resolución de
nombres de host, dado que los registros de nombre de host están en la zona
internal.cloudapp.net. Si utiliza su propia solución de resolución de nombres, no se
proporciona este sufijo a las máquinas virtuales, ya que interfiere con otras arquitecturas
DNS (como en el caso de los escenarios con unión a un dominio). En su lugar, Azure
proporciona un marcador de posición no funcional (reddog.microsoft.com).

Si es necesario, el sufijo DNS interno se puede determinar con PowerShell o la API:

En el caso de redes virtuales en modelos de implementación de Azure Resource

Manager, el sufijo está disponible con el recurso de la API REST de interfaz de red
o del cmdlet Get-AzNetworkInterface de PowerShell y del comando de la CLI de
Azure az network nic show.

Si el reenvío de consultas a Azure no se ajusta a sus necesidades, proporcione su propia

solución de DNS o implemente una instancia de Azure DNS Private Resolver.

Si proporciona su propia solución de DNS, debe:

 Proporcionar la resolución adecuada de nombres de host, por ejemplo, mediante
DDNS. Si utiliza DDNS, puede que tenga que deshabilitar la limpieza de registros
de DNS. Las concesiones DHCP de Azure son muy largas y la limpieza puede
eliminar registros DNS de forma prematura.

Proporcionar la resolución recursiva adecuada para permitir la resolución de

nombres de dominio externos.

Estar accesible (TCP y UDP en el puerto 53) desde los clientes a los que sirve y
poder acceder a Internet.

Tener protección contra el acceso desde Internet para mitigar las amenazas que
suponen los agentes externos.

７ Nota

Para obtener un rendimiento óptimo, cuando se usan máquinas virtuales de

Azure como servidores DNS, debe deshabilitarse IPv6.
Los NSG actúan como firewalls para los puntos de conexión de resolución
DNS. Debe modificar o invalidar las reglas de seguridad de NSG para permitir
el acceso del puerto UDP 53 (y, opcionalmente, el puerto TCP 53) a los puntos
de conexión del agente de escucha DNS. Una vez que los servidores DNS
personalizados se establecen en una red, el tráfico a través del puerto 53
omitirá los NSG de la subred.

Aplicaciones web
Supongamos que necesita realizar la resolución de nombres de una aplicación web
integrada con App Service y vinculada a una red virtual, a las máquinas virtuales en la
misma red virtual. Además de configurar un servidor DNS personalizado que tenga un
reenviador DNS que reenvíe las consultas a Azure (dirección IP virtual 168.63.129.16),
realice los pasos siguientes:

1. Habilite la integración de red virtual de la aplicación web, si aún no lo ha hecho, tal

y como se describe en Integración de su aplicación con una instancia de Azure
Virtual Network.

2. En Azure Portal, para el plan de App Service que hospeda la aplicación web,
seleccione Sincronizar red en Redes, Integración de Virtual Network.
Si necesita llevar a cabo la resolución de nombres desde una aplicación web vinculada a
la red virtual (creada con App Service) en máquinas virtuales de otra red virtual que no
está vinculada a la misma zona privada, use servidores DNS personalizados o Azure
DNS Private Resolver en las dos redes virtuales.

Para usar servidores DNS personalizados:

Configure un servidor DNS en la red virtual de destino en una máquina virtual que
también pueda reenviar consultas a la resolución recursiva de Azure (dirección IP
virtual 168.63.129.16). Puede encontrar un reenviador DNS de ejemplo disponible
en la galería de plantillas de inicio rápido de Azure y en GitHub .

Configure un reenviador DNS en la red virtual de origen en una máquina virtual.

Configure este reenviador DNS para que reenvíe consultas al servidor DNS de la
red virtual de destino.

Configure el servidor DNS de origen en la configuración de su red virtual de

origen.

Habilite la integración de red virtual para la aplicación web para vincular a la red
virtual de origen, siguiendo las instrucciones de Integración de su aplicación con
una instancia de Azure Virtual Network.

En Azure Portal, para el plan de App Service que hospeda la aplicación web,
seleccione Sincronizar red en Redes, Integración de Virtual Network.

Para usar Azure DNS Private Resolver, consulte Vínculos del conjunto de reglas.
Especificación de los servidores DNS
Si usa sus propios servidores DNS, Azure permite especificar varios servidores DNS por
cada red virtual. También puede especificar varios servidores DNS por interfaz de red
(para Azure Resource Manager) o por servicio en la nube (para el modelo de
implementación clásica). Los servidores DNS especificados para una interfaz de red o un
servicio en la nube tienen prioridad sobre los servidores DNS especificados para la red
virtual.

７ Nota

Las propiedades de conexión de red, como las direcciones IP del servidor DNS, no
deben editarse directamente dentro de las máquinas virtuales. Esto se debe a que
podrían borrarse durante el servicio de reparación cuando se reemplaza el
adaptador de la red virtual. Esto se aplica a las máquinas virtuales Windows y Linux.

Si utiliza el modelo de implementación de Azure Resource Manager, puede especificar

servidores DNS para una red virtual y una interfaz de red. Para obtener más información,
consulte Administración de una red virtual y Administración de una interfaz de red.

７ Nota

Si opta por el servidor DNS personalizado para la red virtual, debe especificar al
menos una dirección IP de servidor DNS; en caso contrario, la red virtual omitirá la
configuración y usará en su lugar el DNS proporcionado por Azure.

７ Nota

Si cambia la configuración de DNS de una máquina o red virtual que ya está

implementada, para que la nueva configuración de DNS surta efecto, debe realizar
una renovación de la concesión de DHCP en todas las máquinas virtuales afectadas
de la red virtual. En el caso de las máquinas virtuales que ejecutan el sistema
operativo Windows, puede hacerlo escribiendo ipconfig /renew directamente en la
máquina virtual. Los pasos varían en función del sistema operativo. Consulte la
documentación correspondiente para su tipo de sistema operativo.

Pasos siguientes
Modelo de implementación de Azure Resource Manager:
Administración de una red virtual

Administración de una interfaz de red

Uso de DNS dinámico para registrar
nombres de host en su propio servidor
DNS
Artículo • 30/04/2023

Azure ofrece resolución de nombres para las máquinas virtuales (VM) y las instancias de
rol. Sin embargo, cuando la resolución de nombres tiene que ir más allá de lo que el
servicio DNS predeterminado de Azure ofrece, puede proporcionar sus propios
servidores DNS. El uso de sus propios servidores DNS le ofrece la capacidad de
personalizar su solución DNS para satisfacer sus propias necesidades específicas. Por
ejemplo, puede que necesite acceder a los recursos locales a través del controlador de
dominio de Active Directory.

Si los servidores DNS personalizados se hospedan como máquinas virtuales de Azure,

puede reenviar consultas de nombre de host de la misma red virtual a Azure para
resolver los nombres de host. Si no desea usar esta opción, puede registrar los nombres
de host de las máquinas virtuales en el servidor DNS usando para ello DNS dinámico
(DDNS). Azure no tiene las credenciales para crear directamente los registros en los
servidores DNS, por lo que a menudo se necesitan medidas alternativas. Aquí
presentamos algunos escenarios comunes con alternativas:

Clientes Windows
Los clientes Windows no unidos a dominio intentan realizar actualizaciones de DDNS no
seguras cuando arrancan o cuando su dirección IP cambia. El nombre DNS es el nombre
de host más el sufijo DNS primario. Azure deja en blanco el sufijo DNS principal, pero
puede establecerlo en la VM con la interfaz de usuario o mediante PowerShell.

Los clientes Windows unidos a dominio registran sus direcciones IP con el controlador
de dominio mediante DDNS seguro. El proceso de unión a dominio establece el sufijo
DNS primario en el cliente y crea y mantiene la relación de confianza.

Clientes Linux
Por lo general, los clientes Linux no se registran con el servidor DNS al iniciarse, dado
que asumen que esto lo hace el servidor DHCP. Los servidores DHCP de Azure no tienen
las credenciales para realizar registros en el servidor DNS. Puede usar una herramienta
denominada nsupdate , que se incluye en el paquete Bind, para enviar las actualizaciones
de DDNS. Dado que el protocolo DDNS está estandarizado, puede usar nsupdate
aunque no use Bind en el servidor DNS.

Puede usar los enlaces que proporciona el cliente DHCP para crear y mantener la
entrada del nombre de host en el servidor DNS. Durante el ciclo de DHCP, el cliente
ejecuta los scripts que aparecen en /etc/dhcp/dhclient-exit-hooks.d/ . Puede usar los
enlaces para registrar la nueva dirección IP mediante nsupdate . Por ejemplo:

Bash

#!/bin/sh
requireddomain=mydomain.local

# only execute on the primary nic

if [ "$interface" != "eth0" ]
then
return
fi

# When you have a new IP, perform nsupdate

if [ "$reason" = BOUND ] || [ "$reason" = RENEW ] ||
[ "$reason" = REBIND ] || [ "$reason" = REBOOT ]
then
host=`hostname`
nsupdatecmds=/var/tmp/nsupdatecmds
echo "update delete $host.$requireddomain a" > $nsupdatecmds
echo "update add $host.$requireddomain 3600 a $new_ip_address" >>
$nsupdatecmds
echo "send" >> $nsupdatecmds

nsupdate $nsupdatecmds
fi

También puede usar el comando nsupdate para realizar actualizaciones de DDNS

seguras. Por ejemplo, cuando usa un servidor Bind DNS, se genera un par de claves
pública-privada ( http://linux.yyz.us/nsupdate/ ). El servidor DNS está configurado
( http://linux.yyz.us/dns/ddns-server.html ) con la parte pública de la clave, de manera
que se puede comprobar la firma en la solicitud. Para proporcionar el par de claves para
nsupdate , use la opción -k . El objetivo es la firma de la solicitud de actualización DDNS.

Si usa un servidor DNS de Windows, puede usar la autenticación Kerberos con el

parámetro -g en nsupdate , pero no está disponible en la versión de nsupdate para
Windows. Para usar Kerberos, utilice kinit para cargar las credenciales. Por ejemplo,
puede cargar las credenciales de un archivo keytab y nsupdate -g extraer las
credenciales de la memoria caché.
En caso de ser necesario, puede agregar un sufijo de búsqueda DNS a las máquinas
virtuales. El sufijo DNS se especifica en el archivo /etc/resolv.conf . La mayoría de las
distribuciones de Linux administran automáticamente el contenido de este archivo, por
lo que normalmente no se puede editar. Sin embargo, puede reemplazar el sufijo
mediante el comando supersede del cliente DHCP. Para invalidar el sufijo, agregue la
línea siguiente al archivo /etc/dhcp/dhclient.conf:

supersede domain-name <required-dns-suffix>;

Optimización del rendimiento de red en
las máquinas virtuales de Azure
Artículo • 29/03/2023

Las máquinas virtuales (VM) de Azure tienen una configuración de red predeterminada
que se puede optimizar para mejorar aún más el rendimiento de la red. En este artículo
se describe cómo optimizar el rendimiento de la red de las máquinas virtuales Windows
y Linux de Microsoft Azure, incluidas las distribuciones principales como Ubuntu,
CentOS y Red Hat.

Máquinas virtuales Windows

Si la máquina virtual Windows admite redes aceleradas, habilite esa característica para
lograr un rendimiento óptimo. Para más información, consulte Creación de una máquina
virtual Windows con redes aceleradas.

En el caso de otras máquinas virtuales Windows, el uso de escalado en la

recepción (RSS) puede logar un rendimiento máximo y mayor que en el caso de
máquinas que no usan RSS. En las máquinas virtuales Windows, RSS se puede
deshabilitar de forma predeterminada. Para determinar si RSS está habilitado y para
habilitarlo si no lo está en la actualidad, complete los siguientes pasos:

1. Compruebe si RSS está habilitado para un adaptador de red con el comando Get-
NetAdapterRss de PowerShell. En la siguiente salida de ejemplo que devuelve Get-
NetAdapterRss , RSS no está habilitado.

PowerShell

Name : Ethernet
InterfaceDescription : Microsoft Hyper-V Network Adapter
Enabled : False

2. Para habilitar RSS escriba el siguiente comando:

PowerShell

Get-NetAdapter | % {Enable-NetAdapterRss -Name $_.Name}

Este comando no tiene ninguna salida. El comando cambia la configuración de la

NIC. Provoca una pérdida temporal de conectividad durante aproximadamente un
 minuto. Durante la pérdida de conectividad, aparece un cuadro de diálogo
Reconectando. La conectividad se suele restaurar al tercer intento.

3. Confirme que RSS está habilitado en la máquina virtual, para lo que debe volver a
escribir el comando Get-NetAdapterRss . Si se realiza correctamente, se devuelve la
siguiente salida de ejemplo:

PowerShell

Name : Ethernet
InterfaceDescription : Microsoft Hyper-V Network Adapter
Enabled : True

Máquinas virtuales Linux

De manera predeterminada, en las máquinas virtuales Linux de Azure RSS está siempre
habilitado. Los kernels de Linux lanzados desde octubre de 2017 incluyen nuevas
opciones de optimización de red que permiten que las máquinas virtuales Linux logren
un mayor rendimiento de la red.

Ubuntu para las nuevas implementaciones

El kernel de Azure de Ubuntu es que mejor rendimiento de red ofrece en Azure. Para
obtener las optimizaciones más recientes, primero instale la última versión compatible
18.04-LTS, tal como se indica a continuación:

JSON

"Publisher": "Canonical",
"Offer": "UbuntuServer",
"Sku": "18.04-LTS",
"Version": "latest"

Una vez que la creación finaliza, escriba los siguientes comandos para obtener el
actualizaciones más recientes. Estos pasos también funcionan en las máquinas virtuales
que ejecutan actualmente el kernel de Azure de Ubuntu.

Bash

#run as root or preface with sudo

sudo apt-get -y update
sudo apt-get -y upgrade
sudo apt-get -y dist-upgrade
Si una implementación de Ubuntu existente ya tiene el kernel de Azure, pero no se
puede actualizar y aparecen errores, este conjunto de comandos opcional podría ser
útil.

Bash

#optional steps might be helpful in existing deployments with the Azure

kernel
#run as root or preface with sudo
sudo apt-get -f install
sudo apt-get --fix-missing install
sudo apt-get clean
sudo apt-get -y update
sudo apt-get -y upgrade
sudo apt-get -y dist-upgrade

Actualización del kernel de Azure de Ubuntu para las máquinas

virtuales existentes

Al actualizar al kernel de Linux de Azure, se puede lograr un rendimiento significativo.

Para comprobar si tienen este kernel, compruebe la versión del kernel. Debe ser el
mismo o posterior al del ejemplo.

Bash

#Azure kernel name ends with "-azure"

uname -r

#sample output on Azure kernel:

#4.13.0-1007-azure

En caso de que la máquina virtual no tenga el kernel de Azure, el número de versión

generalmente empieza con "4.4." Si esto ocurre, ejecuta los siguientes comandos como
raíz:

Bash

#run as root or preface with sudo

sudo apt-get update
sudo apt-get upgrade -y
sudo apt-get dist-upgrade -y
sudo apt-get install "linux-azure"
sudo reboot

CentOS
Para obtener las optimizaciones más recientes, se recomienda crear una máquina virtual
con la versión más reciente compatible mediante la especificación de los siguientes
parámetros:

JSON

"Publisher": "OpenLogic",
"Offer": "CentOS",
"Sku": "7.7",
"Version": "latest"

Tanto las máquinas virtuales nuevas como las existentes se pueden beneficiar de la
versión más reciente de Linux Integration Services (LIS). La optimización del rendimiento
se realiza en LIS a partir de la versión 4.2.2-2. Las versiones posteriores contienen
mejoras adicionales. Escriba los siguientes comandos para instalar el LIS más reciente:

Bash

sudo yum update

sudo reboot
sudo yum install microsoft-hyper-v

Red Hat
Para obtener las optimizaciones, se recomienda crear una máquina virtual con la versión
más reciente compatible mediante la especificación de los siguientes parámetros:

JSON

"Publisher": "RedHat"
"Offer": "RHEL"
"Sku": "7-RAW"
"Version": "latest"

Las máquinas virtuales nuevas y existentes pueden beneficiarse de la instalación de LIS

más reciente. La optimización del rendimiento se realiza en LIS a partir de la versión 4.2.
Escriba los siguientes comandos para descargar e instalar LIS:

Bash

wget https://aka.ms/lis
tar xvf lis
cd LISISO
sudo ./install.sh #or upgrade.sh if prior LIS was previously installed
Para más información sobre la versión 4.3 de Linux Integration Services para Hyper-V,
consulte la página de descarga .

Pasos siguientes
Implemente las VM próximas entre sí para obtener una latencia baja con los
grupos con ubicación por proximidad.
Vea el resultado con las pruebas de ancho de banda y rendimiento para su
escenario.
Aprenda cómo el ancho de banda se asigna a las máquinas virtuales.
Obtenga más información con las preguntas más frecuentes acerca de Azure
Virtual Network.
Visión y modificación de nombres de
host
Artículo • 11/04/2023

El nombre de host identifica la máquina virtual (VM) en la interfaz de usuario y las

operaciones de Azure. En primer lugar, asigne el nombre de host de una VM en el
campo Nombre de la máquina virtual durante el proceso de creación en Azure Portal.
Después de crear una VM, puede ver y modificar el nombre de host a través de una
conexión remota o en Azure Portal.

Visión de los nombres de host

Puede ver el nombre de host de la VM en un servicio en la nube mediante cualquiera de
las siguientes herramientas.

Azure portal
En Azure Portal, vaya a la VM y seleccione Propiedades en el panel de navegación
izquierdo. En la página Propiedades, puede ver el nombre de host en Nombre de
equipo.
Escritorio remoto
Puede conectarse a la VM mediante una herramienta de escritorio remoto como
Escritorio remoto (Windows), Comunicación remota de Windows PowerShell (Windows),
SSH (Linux y Windows) o Bastion (Azure Portal). A continuación, puede ver el nombre de
host de varias maneras:

Escriba hostname en PowerShell, en el símbolo del sistema o en un terminal SSH.

Escriba ipconfig /all en el símbolo del sistema (solo Windows).
Consulte el nombre del equipo en la configuración del sistema (sólo Windows).
API de Azure
Desde un cliente REST, siga estas instrucciones:

1. Asegúrese de que tiene una conexión autenticada con Azure Portal. Siga los pasos
indicados en Creación de una aplicación de Azure Active Directory y una entidad
de servicio con acceso a los recursos.

2. Envíe una solicitud con el formato siguiente:

HTTP

GET
https://management.azure.com/subscriptions/{subscriptionId}/resourceGro
ups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachines/{vm
Name}?api-version=2022-11-01`.

Para obtener más información sobre las solicitudes GET para máquinas virtuales,
consulte Máquinas virtuales: Get.

3. Busque osProfile y, a continuación, el elemento computerName para encontrar el

nombre de host.

２ Advertencia

También puede ver el sufijo de dominio interno correspondiente a su servicio en la

nube si ejecuta ipconfig /all desde un símbolo del sistema en una sesión de
Escritorio remoto (Windows) o si ejecuta cat /etc/resolv.conf desde un terminal
de SSH (Linux).

Modificación de un nombre de host

Puede modificar el nombre de host de cualquier VM cambiando el nombre del equipo
desde una sesión de Escritorio remoto o mediante Ejecutar comando en Azure Portal.

Desde una sesión remota:

Para Windows, puede cambiar el nombre de host de PowerShell mediante el

comando Rename-Computer.
Para Linux, puede cambiar el nombre de host mediante hostnamectl .

También puede ejecutar estos comandos para buscar el nombre de host de la VM desde
Azure Portal mediante Ejecutar comando. En Azure Portal, vaya a la VM y seleccione
Ejecutar comando en el panel de navegación izquierdo. En la página Ejecutar comando
de Azure Portal:

Para Windows, seleccione RunPowerShellScript y use Rename-Computer en el panel

Ejecutar script de comandos.
Para Linux, seleccione RunShellScript y use hostnamectl en el panel Ejecutar script
de comandos.

En la imagen siguiente se muestra la página Ejecutar comando en Azure Portal de una

VM de Windows.

Después de ejecutar Rename-Computer o hostnamectl en la VM, debe reiniciar la VM para

que cambie el nombre de host.

modelo de implementación clásica de Azure

El modelo de implementación clásica de Azure usa un archivo de configuración que
puede descargar y cargar para cambiar el nombre de host. Para permitir que el nombre
de host haga referencia a las instancias de rol, debe establecer el valor del nombre de
host en el archivo de configuración de servicio de cada rol. Para hacer esto, agregue el
nombre de host que quiera al atributo vmName del elemento Rol. El valor del atributo
vmName se usa como base para el nombre de host de cada instancia de rol.

Por ejemplo, si el atributo vmName es webrole y hay tres instancias de ese rol, los
nombres de host de las instancias son webrole0, webrole1 y webrole2. No es necesario
especificar un nombre de host para máquinas virtuales en el archivo de configuración,
porque el nombre de host de una VM se rellena según el nombre de esa máquina
virtual. Para obtener más información sobre cómo configurar un servicio de Microsoft
Azure, consulte Esquema de configuración del servicio de Azure (archivo de .cscfg)

Archivo de configuración de servicio

En el modelo de implementación clásica de Azure, puede descargar el archivo de
configuración de servicio de un servicio implementado desde el panel Configurar del
servicio en Azure Portal. Después, puede buscar el atributo vmName del elemento
Nombre de rol para ver el nombre de host. Tenga en cuenta que ese nombre de host se
usa como base para cada nombre de host de cada instancia de rol. Por ejemplo, si el
atributo vmName es webrole y hay tres instancias de ese rol, los nombres de host de las
instancias son webrole0, webrole1 y webrole2. Para obtener más información, consulte
Esquema de configuración de Azure Virtual Network.

Pasos siguientes
resolución de nombres DNS
Especificación de la configuración de DNS usando los archivos de configuración de
red
Registro de recursos de un grupo de
seguridad de red
Artículo • 29/03/2023

Los grupos de seguridad de red (NSG) incluyen reglas que permiten o deniegan el tráfico a una
subred de red virtual, a una interfaz de red, o a ambas.

Al habilitar el registro para un grupo de seguridad de red, puede recopilar los siguientes tipos de
información del registro de recursos:

Evento: se registran las entradas en las que se aplican reglas de NSG a máquinas virtuales en
función de la dirección MAC.
Contador de regla: contiene entradas para el número de veces que se aplica cada regla de
NSG para permitir o denegar el tráfico. El estado de estas reglas se recopila cada 300 segundos.

Los registros de diagnóstico solo están disponibles para los grupos de seguridad de red
implementados con el modelo de implementación de Azure Resource Manager. No se puede
habilitar el registro de diagnóstico para los grupos de seguridad de red implementados con el
modelo de implementación clásica. Consulte Descripción de los modelos de implementación para
obtener más información.

El registro de recursos se habilita por separado para cada grupo de seguridad de red para el que
desee recopilar datos de diagnóstico. En caso contrario, si le interesan los registros de actividad u
operativos, consulte Introducción a los registros de plataforma Azure. Si le interesa el flujo de tráfico
IP a través de los grupos de seguridad de red, consulte Registros de flujo para grupos de seguridad
de red.

Habilitar registro
Para habilitar el registro de recursos