Aplicar los principios de Confianza Cero a un despliegue de Azure Virtual WAN

  • Artículo

Con la evolución moderna de la nube, los dispositivos móviles y otros puntos de conexión, confiar solo en servidores de seguridad corporativos y redes perimetrales ya no es suficiente. Una estrategia de Confianza cero de un extremo a otro supone que las infracciones de seguridad son inevitables. Esto significa que debe comprobar cada solicitud como si se originase desde una red no controlada. Las redes siguen desempeñando un papel importante en Confianza cero para conectar y proteger la infraestructura, las aplicaciones y los datos. En el modelo de Confianza cero, hay tres objetivos clave a la hora de proteger las redes:

  • Debe prepararse para tratar con los ataques antes de que se produzcan.
  • Minimice los daños y la rapidez con la que se propagan.
  • Ponga más barreras para que su presencia en la nube no corra peligro.

Azure Virtual WAN permite una arquitectura de red de tránsito global al habilitar una conectividad ubicua universal entre conjuntos distribuidos globalmente de cargas de trabajo en la nube de redes virtuales (VNet), sitios de sucursales, aplicaciones SaaS y PaaS, y usuarios. La adopción de un enfoque de Confianza cero en Azure Virtual WAN es fundamental para asegurarse de que la red troncal es segura y protegida.

En este artículo se proporcionan pasos para aplicar los principios de Confianza cero a una implementación de Azure Virtual WAN de las siguientes maneras:

Principio de Confianza cero Definición Forma de cumplimiento
Comprobación explícita Autentique y autorice siempre en función de todos los puntos de datos disponibles. Utilice Azure Firewall con la inspección de seguridad de la capa de transporte (TLS) para comprobar el riesgo y las amenazas en función de todos los datos disponibles. Los controles de acceso condicional están diseñados para proporcionar autenticación y autorización por diversos puntos de datos y Azure Firewall no realiza la autenticación de usuario.
Uso del acceso con privilegios mínimos Limite el acceso de los usuarios con los modelos Just-in-Time y Just-in-Time (JIT/JEA), directivas que se adaptan al nivel de riesgo y protección de datos. El acceso de usuario está fuera del ámbito de las implementaciones de infraestructura de red de Azure. El uso de soluciones de pilar de identidad como Privileged Access Management, Acceso condicional y otros controles es la manera de ofrecer este principio.
Dar por hecho que habrá intrusiones al sistema Minimice el radio de explosión y el acceso a los segmentos. Compruebe el cifrado de un extremo a otro y use análisis para obtener visibilidad, impulsar la detección de amenazas y mejorar las defensas. Cada red virtual de radio no tiene acceso a otras redes virtuales de radio a menos que el tráfico se enrute a través del servidor de seguridad integrado en cada centro de conectividad de Azure Virtual WAN. El servidor de seguridad se establece en denegar de manera predeterminada, lo que permite solo el tráfico permitido por las reglas especificadas. En caso de que se produzca un riesgo o una vulneración de una aplicación o carga de trabajo, tiene una capacidad limitada de propagarse debido a que Azure Firewall realiza la inspección del tráfico y solo reenvía el tráfico permitido. Solo los recursos de la misma carga de trabajo se exponen a la vulneración en la misma aplicación.

Para más información sobre cómo aplicar los principios de Confianza cero en un entorno de IaaS de Azure, consulte Introducción a la aplicación de principios de Confianza cero a la infraestructura de Azure.

Para ver una discusión del sector sobre Confianza cero, consulte la Publicación especial de NIST 800-207.

Azure Virtual WAN

Azure Virtual WAN es un servicio de red que aporta muchas funciones de red, seguridad y enrutamiento para proporcionar una única interfaz operativa. Las principales características incluyen:

  • Características de enrutamiento avanzadas
  • Integración de seguridad de “aumento en la conexión” a través de Azure Firewall o aplicaciones virtuales de red (NVA) admitidas en el centro
  • Cifrado de ExpressRoute

Un enfoque de Confianza cero para Azure Virtual WAN requiere la configuración de varios servicios y componentes subyacentes de la tabla de principios de Confianza cero que se ha enumerado anteriormente. Esta es una lista de pasos y acciones:

  • Implemente azure Firewall o NVA compatibles con Firewall de próxima generación (NGFW) dentro de cada centro de conectividad de Virtual WAN.
  • Configure el enrutamiento entre redes virtuales y sucursales locales para crear un entorno de Confianza cero mediante el envío de todo el tráfico a dispositivos de seguridad en los centros de conectividad para su inspección. Configure el enrutamiento para proporcionar filtrado y protección para amenazas conocidas.
  • Asegúrese de que ningún recurso de los radios tenga acceso directo a Internet.
  • Proporcione la microsegmentación de aplicaciones en redes de radio, junto con una estrategia de micro-perímetros de entrada y salida.
  • Proporcione observabilidad para los eventos de seguridad de red.

Arquitectura de referencia

En el diagrama siguiente se muestra una arquitectura de referencia común que muestra un entorno implementado habitualmente y cómo aplicar los principios de Confianza cero a Azure Virtual WAN.

Diagrama de la arquitectura de referencia para Azure Virtual Desktop.

Azure Virtual WAN se puede implementar en tipos básico y estándar. La aplicación de los principios de Confianza cero para Azure Virtual WAN con Azure Firewall o NGFW requiere el tipo Estándar.

La arquitectura de referencia de Azure Virtual WAN con centros de conectividad protegidos incluye:

  • Una única instancia lógica de Virtual WAN.
  • Dos centros virtuales protegidos, uno por región.
  • Una instancia de Azure Firewall Premium implementada en cada centro de conectividad.
  • Al menos una directiva Premium de Azure Firewall.
  • VPN de punto a sitio (P2S) y VPN de sitio a sitio (S2S) y puertas de enlace de ExpressRoute.
  • Ramas conectadas a P2S, S2S y ExpressRoute.
  • Una red virtual de servicios compartidos que contiene recursos de infraestructura principales que no se pueden implementar en un centro de Virtual WAN, como máquinas virtuales DNS personalizadas o Azure DNS Private Resolver, Active Directory Domain Services [AD DS], Azure Bastion y otros recursos compartidos.
  • Redes virtuales de carga de trabajo con Azure Application Gateway, Azure Web Application Firewall (WAF) y puntos de conexión privados si es necesario.

Azure Virtual WAN admite la integración de un conjunto limitado de servidores de seguridad de terceros dentro de sus centros de conectividad como alternativa a Azure Firewall nativo. En este artículo solo se describe Azure Firewall. Lo que se incluye en los servicios compartidos de red virtual en la arquitectura de referencia es solo un ejemplo de lo que se puede implementar. Microsoft administra los centros de Azure Virtual WAN y no puede instalar nada más dentro de ellos, excepto lo que Azure Firewall y las NVA admitidas permiten explícitamente.

Esta arquitectura de referencia se alinea con los principios arquitectónicos descritos en el artículo de Cloud Adoption Framework para la topología de red de Virtual WAN.

Seguridad de enrutamiento

La protección de la propagación de rutas y el aislamiento en el entorno local es un elemento de seguridad crítico que se debe administrar.

Aparte de la segmentación de tráfico, la seguridad de enrutamiento es una parte fundamental de cualquier diseño de seguridad de red. Los protocolos de enrutamiento son una parte integral de la mayoría de las redes, incluida Azure. Debe proteger la infraestructura de los riesgos inherentes a los protocolos de enrutamiento, como configuraciones incorrectas o ataques malintencionados. El protocolo BGP usado para VPN o ExpressRoute ofrece métodos muy completos de proteger la red frente a cambios de enrutamiento no deseados, lo que podría incluir el anuncio de rutas demasiado específicas o rutas demasiado amplias.

La mejor manera de proteger la red es configurar los dispositivos en el entorno local con las directivas de ruta adecuadas y asignaciones de rutas para asegurarse de que solo los prefijos permitidos se propagan a la red desde Azure. Por ejemplo, puede hacer lo siguiente:

  • Bloquee los prefijos de entrada que son demasiado genéricos.

    Si debido a una configuración errónea, Azure comienza a enviar prefijos genéricos como 0.0.0.0/0 o 10.0.0.0/8, podría atraer tráfico que, de lo contrario, permanecer en la red en el entorno local.

  • Bloquee los prefijos de entrada que son demasiado específicos.

    En determinadas circunstancias, podría obtener algunos prefijos IPv4 largos de Azure (longitud de prefijo de red de 30 a 32), que normalmente se incluyen en otros prefijos menos específicos y, por lo tanto, no son necesarios. Quitar estos prefijos impide que las tablas de enrutamiento locales sean innecesariamente grandes.

  • Bloquee los prefijos de entrada que no están en Azure a menos que use Azure como red de tránsito.

    Si no usa Azure para transportar el tráfico entre las ubicaciones en el entorno local (por ejemplo, con tecnologías como Global Reach de ExpressRoute), un prefijo local que se anuncia desde Azure indicaría una repetición de enrutamiento. Solo tomar prefijos de Azure en los enrutadores en el entorno local le protegería de estos tipos de repeticiones de enrutamiento.

  • Bloquee los prefijos de salida que no están en el entorno local.

    Si no usa la red en el entorno local para el tránsito entre regiones de Azure, no debe estar publicitando en Azure ningún prefijo que no use en el entorno local. Si no lo hace, corre el riesgo de crear repeticiones de enrutamiento, especialmente dado el hecho de que las implementaciones de eBGP en la mayoría de los enrutadores vuelvan a anunciar todos los prefijos en vínculos no preferidos. Esto tiene el efecto de volver a enviar prefijos de Azure a Azure a menos que haya configurado eBGP multiruta.

Arquitectura lógica

Azure Virtual WAN es una colección de centros de conectividad y servicios que están disponibles en un centro de conectividad. Puede implementar tantas Virtual WAN como sea necesario. En un centro de Virtual WAN, hay varios servicios, como VPN, ExpressRoute, Azure Firewall o una NVA integrada de terceros.

En el diagrama siguiente se muestra la arquitectura lógica de la infraestructura de Azure para una implementación de Azure Virtual WAN, como se muestra en Cloud Adoption Framework.

Diagrama de los componentes de la topología de Azure Virtual WAN y las suscripciones de Azure.

La mayoría de los recursos están contenidos dentro de la suscripción de conectividad. Implementa todos los recursos de Virtual WAN en un único grupo de recursos de la suscripción de conectividad, incluido el momento de la implementación en varias regiones. Los radios de red virtual de Azure se encuentran en las suscripciones de la zona de aterrizaje. Si usa la directiva de Azure Firewall de herencia y jerarquía, la directiva primaria y la directiva secundaria deben encontrarse en la misma región. Puede seguir aplicando una directiva que creó en una región de un centro seguro desde otra región.

¿Cuál es el contenido de este artículo?

En este artículo se describen los pasos para aplicar los principios de Confianza cero en la arquitectura de referencia de Azure Virtual WAN.

Paso Tarea Principios de Confianza cero aplicados
1 Cree una directiva de Azure Firewall. Comprobación explícita
Dar por hecho que habrá intrusiones al sistema
2 Convierta los centros de Azure Virtual WAN en centros protegidos. Comprobación explícita
Dar por hecho que habrá intrusiones al sistema
3 Proteja el tráfico. Comprobación explícita
Dar por hecho que habrá intrusiones al sistema
4 Proteja las redes virtuales de radio. Dar por hecho que habrá intrusiones al sistema
5 Revise el uso del cifrado. Dar por hecho que habrá intrusiones al sistema
6 Protección de los usuarios de P2S. Dar por hecho que habrá intrusiones al sistema
7 Configure la supervisión, la auditoría y la administración. Dar por hecho que habrá intrusiones al sistema

Debe realizar los pasos 1 y 2 en orden. Los otros pasos se pueden realizar en cualquier orden.

Paso 1: Creación de una directiva de Azure Firewall

En el caso de las implementaciones independientes de Azure Firewall en una arquitectura clásica radial, se debe crear al menos una directiva de Azure en Azure Firewall Manager y asociarla a los centros de Azure Virtual WAN. Esta directiva debe crearse y estar disponible antes de la conversión de cualquier centro de conectividad. Una vez definida la directiva, se aplica a las instancias de Azure Firewall en el paso 2.

Las directivas de Azure Firewall se pueden organizar en una jerarquía de elementos primarios y secundarios. En el caso de un escenario clásico radial o una instancia administrada de Azure Virtual WAN, debe definir una directiva raíz con un conjunto común de reglas de seguridad para toda la TI para permitir o denegar el tráfico. A continuación, para cada centro de conectividad, se podría definir una directiva secundaria para implementar reglas específicas del centro a través de la herencia. Este paso es opcional. Si las reglas que se deben aplicar a cada centro son idénticas, se puede aplicar una sola directiva.

Para Confianza cero, se requiere una directiva premium de Azure Firewall y debe incluir la siguiente configuración:

  • Proxy DNS: debe configurar Azure Firewall como un servidor DNS personalizado para redes virtuales de radio que protejan el DNS real que reside en un radio de servicio compartido o en el entorno local. Los servidores de seguridad de Azure actúan como proxy DNS, escuchan en el puerto UDP 53 y reenvían las solicitudes DNS a los servidores DNS especificados en la configuración de directiva. Para cada radio, debe configurar un servidor DNS en el nivel de red virtual que apunte a la dirección IP interna de Azure Firewall en el centro de Virtual WAN. No debe conceder acceso de red desde radios y ramas al DNS personalizado.

  • La inspección de TLS debe estar habilitada para estos escenarios:

    • Inspección de TLS saliente para proteger contra el tráfico malintencionado que se envía desde un cliente interno hospedado en Azure a Internet.

    • Inspección de TLS horizontal, de derecha a izquierda para incluyir el tráfico que va desde o hacia una red en el entorno local y entre Virtual WAN de radio, que protege las cargas de trabajo de Azure frente al tráfico malintencionado que se pueda enviar desde dentro de Azure.

  • El sistema de detección y prevención de intrusiones (IDPS) debe estar habilitado en el modo “Alerta y denegación”.

  • La inteligencia contra amenazas tendría que estar habilitada en modo de Alerta y Denegar.

Como parte de la creación de la directiva, debe crear las reglas de traducción de direcciones de red (DNAT) de destino necesarias, reglas de red y reglas de aplicación para habilitar solo los flujos de red para el tráfico permitido explícitamente. Para habilitar la inspección de TLS para destinos seleccionados, la regla de aplicación correspondiente debe tener habilitada la configuración “Inspección de TLS”. Al crear reglas en colecciones de reglas, debe utilizar el “Destino” más restrictivo y “Tipo de destino”.

Paso 2: Conversión de los centros de Azure Virtual WAN en centros protegidos

En el núcleo del enfoque de Confianza cero para Azure Virtual WAN, se trata del centro de conectividad de Virtual WAN protegido (centro seguro). Un centro de conectividad protegido es un centro de Azure Virtual WAN con Azure Firewall integrado. La utilización de dispositivos de seguridad admitidos de terceros se admite como alternativa a Azure Firewall, pero no se describe en este artículo. Puede usar estas aplicaciones virtuales para inspeccionar todo el tráfico de vertical de arriba abajo, horizontal de derecha a izquierda y de Internet

Se recomienda Azure Firewall Premium para Confianza cero y configurarlo con la directiva Premium que se describe en el paso 1.

Nota:

La utilización de protección contra DDoS no se admite con un centro seguro.

Para obtener más información, consulte Instalación de Azure Firewall en un centro de conectividad de Virtual WAN.

Paso 3: Proteger el tráfico

Una vez que haya actualizado todos los centros de Azure Virtual WAN a centros seguros, debe configurar las directivas y la intención de enrutamiento para principios de Confianza cero. Esta configuración permite que Azure Firewall en cada centro atraiga e inspeccione el tráfico entre radios y ramificaciones en el mismo centro y entre centros de conectividad remotos. Debe configurar las directivas para enviar “Tráfico de Internet” y “Tráfico privado” a través de Azure Firewall o la aplicación virtual de red de terceros. La opción “entre centros” también debe estar habilitada. Este es un ejemplo.

Ejemplo de la directiva de enrutamiento de Azure Firewall.

Cuando la directiva de enrutamiento “Tráfico privado” está habilitada, el tráfico de red virtual dentro y fuera del centro de conectividad de Virtual WAN, incluido el tráfico entre centros, se reenvía al Azure Firewall o AVA de próximo salto que se especificó en la directiva. Los usuarios con privilegios de control de acceso basado en roles (RBAC) podrían invalidar la programación de rutas de Virtual WAN para redes virtuales radiales y asociar una ruta definida por el usuario (UDR) personalizada para omitir el servidor de seguridad de centro. Para evitar esta vulnerabilidad, los permisos de RBAC para asignar UDR a subredes de red virtual de radio deben restringirse a los administradores de red central y no delegarlos a los propietarios de la zona de aterrizaje de las redes virtuales de radio. Para asociar una UDR a una red virtual o subred, un usuario debe tener el rol Colaborador de red o un rol personalizado con la acción o permiso “Microsoft.Network/routeTables/join/action”.

Nota:

En este artículo, Azure Firewall se considera principalmente para el tráfico de Internet y el control de tráfico privado. Para el tráfico de Internet, se puede usar una aplicación virtual de red de seguridad admitida de terceros o un proveedor de seguridad como servicio (SECaaS). En el caso del tráfico privado, las aplicaciones virtuales de red de seguridad admitidas por terceros se pueden usar como alternativa a Azure Firewall.

Nota:

Las tablas de rutas personalizadas en Azure Virtual WAN no se pueden usar junto con la intención y las directivas de enrutamiento y no deben considerarse como una opción de seguridad.

Paso 4: Protección de las redes virtuales de radio

Cada centro de Azure Virtual WAN puede tener una o más redes virtuales conectadas con el emparejamiento de VNet. En función del modelo de zona de aterrizaje de Cloud Adoption Framework, cada red virtual contiene una carga de trabajo de zona de aterrizaje, aplicaciones y servicios que admiten una organización. Azure Virtual WAN administra la conexión, la propagación de rutas y la asociación, y el enrutamiento saliente y entrante, pero no puede afectar a la seguridad dentro de la red virtual. Los principios de Confianza cero deben aplicarse dentro de cada red virtual de radio según las instrucciones publicadas en Aplicación de principios de Confianza cero a una red virtual de radio y otros artículos en función del tipo de recurso, como máquinas virtuales y almacenamiento. Considere los elementos siguientes:

Dado que el centro de conectividad de Azure Virtual WAN está bloqueado y administrado por Azure, los componentes personalizados no se pueden instalar ni habilitar allí. Algunos recursos que normalmente se implementan dentro de centro, en un modelo clásico radial, deben colocarse en uno o varios radios que actúan como redes de recursos compartidos. Por ejemplo:

  • Azure Bastion:Azure Bastion admite Azure Virtual WAN, pero debe implementarse dentro de una red virtual de radio porque Azure restringe y administra el centro de conectividad. Desde el radio de Azure Bastion, los usuarios pueden acceder a los recursos de otras redes virtuales, pero requiere una conexión basada en IP disponible con la SKU estándar de Azure Bastion.
  • Servidores DNS personalizados: el software de servidor DNS se puede instalar en cualquier máquina virtual y actuar como servidor DNS para todos los radios de Azure Virtual WAN. El servidor DNS debe instalarse en una red virtual de radio que sirva directamente a todos los demás radios, o a través de la característica de proxy DNS que ofrece Azure Firewall que se integra dentro del centro de Virtual WAN.
  • Resolución de Azure DNS privado: se admite la implementación de una resolución de Azure DNS privado dentro de una de las redes virtuales de radio conectadas a centros de conectividad de Virtual WAN. Azure Firewall integrado dentro del centro de conectividad de Virtual WAN puede usar este recurso como DNS personalizado al habilitar la característica proxy DNS.
  • Puntos de conexión privados: este tipo de recurso es compatible con Virtual WAN, pero debe implementarse dentro de una red virtual de radio. Esto proporciona conectividad a cualquier otra red virtual o rama conectada a la misma Virtual WAN, si el Azure Firewall integrado permite dicho flujo. Si quiere saber cómo proteger el tráfico destinado a puntos de conexión privados con Azure Firewall en un centro de conectividad de Virtual WAN, vea Protección del tráfico destinado a puntos de conexión privados en Azure Virtual WAN.
  • Zona de Azure DNS privado (vínculos): este tipo de recurso no se encuentra dentro de una red virtual, pero debe estar vinculado a una para que funcione correctamente. Las zonas DNS privadas no se pueden vincular a centros de Virtual WAN. En su lugar, deben conectarse a la red virtual de radio que contiene servidores DNS personalizados o una Azure Private DNS Resolver (recomendado) o directamente a las redes virtuales de radio que requieren los registros DNS de esa zona.

Paso 5: Revisar el cifrado

Azure Virtual WAN proporciona algunas funcionalidades de cifrado de tráfico a través de sus propias puertas de enlace para el tráfico que entra en la red de Microsoft. Siempre que sea posible, se debe habilitar el cifrado en función del tipo de puerta de enlace. Tenga en cuenta el siguiente comportamiento de cifrado predeterminado:

  • Virtual WAN S2S VPN Gateway proporciona cifrado cuando se usa la conexión VPN IPsec/IKE (IKEv1 y IKEv2).

  • Virtual WAN P2S VPN Gateway proporciona cifrado cuando se usa la conexión VPN de usuario a través de OpenVPN o IPsec/IKE (IKEv2).

  • La puerta de enlace de ExpressRoute de Virtual WAN no proporciona cifrado, por lo que se aplican las mismas consideraciones de ExpressRoute independiente.

    • Solo para circuitos ExpressRoute aprovisionados sobre ExpressRoute Direct, es posible aprovechar el cifrado MACsec proporcionado por la plataforma para proteger las conexiones entre los enrutadores perimetrales y los enrutadores perimetrales de Microsoft.

    • Se puede cifrar al utilizar una conexión VPN de IPsec/IKE desde la red en el entorno local a Azure por medio del emparejamiento privado de un circuito Azure ExpressRoute. La intención de enrutamiento y las directivas ahora admiten esta configuración con pasos de configuración adicionales necesarios, como se explica en Cifrado de ExpressRoute.

  • En el caso de dispositivos WAN definidos por software (SD-WAN) y NVA integrados de terceros en el centro de Virtual WAN, se deben comprobar y configurar funcionalidades de cifrado específicas según la documentación del proveedor.

Una vez que el tráfico ha entrado en la infraestructura de red de Azure a través de una de las puertas de enlace o una NVA de SD-WAN, no hay ningún servicio o funcionalidad específicos de Virtual WAN que proporcione cifrado de red. Si el tráfico entre un centro de conectividad y su red virtual y el centro a centro están sin cifrar, debe usar el cifrado de nivel de aplicación si es necesario.

Nota:

Los radios de Virtual WAN no admiten el cifrado de red virtual a red virtual mediante Azure VPN Gateway porque se requiere un radio para usar la puerta de enlace remota del centro de Conectividad de Virtual WAN.

Paso 6: Protección de los usuarios de P2S

Azure Virtual WAN es un servicio de red que aporta muchas funciones de red, seguridad y enrutamiento para proporcionar una única interfaz operativa. Desde la perspectiva de la identidad de usuario, el único punto de contacto con Virtual WAN se encuentra en el método de autenticación que se usa para permitir una VPN de un usuario de P2S. Hay varios métodos de autenticación disponibles, pero se recomienda seguir los principios generales de Confianza cero en la autenticación de Microsoft Entra. Con Microsoft Entra ID, puede requerir Multi-Factor Authentication (MFA) y aplicar el acceso condicional y los principios de Confianza cero a los dispositivos cliente e identidades de usuario.

Nota:

La autenticación de Microsoft Entra solo está disponible para puertas de enlace que utilizan el protocolo de OpenVPN, que solo es compatible con las conexiones del protocolo OpenVPN y requiere el cliente VPN de Azure.

Azure Virtual WAN y Azure Firewall no proporcionan enrutamiento y filtrado del tráfico en función de nombres de grupo o cuenta de usuario, pero es posible asignar diferentes grupos de usuarios diferentes grupos de direcciones IP. Después, puede definir reglas en Azure Firewall integrado para restringir usuarios o grupos en función de su grupo de direcciones IP P2S asignado.

Si divide los usuarios de P2S en grupos diferentes en función de los requisitos de acceso a la red, se recomienda diferenciarlos en el nivel de red y asegurarse de que solo pueden acceder a un subconjunto de la red interna. Puede crear varios grupos de direcciones IP para Azure Virtual WAN. Para más información, consulte Configuración de los grupos de usuarios y los grupos de direcciones IP para VPN de usuario P2S.

Paso 7: Configuración de la supervisión y administración

Azure Virtual WAN proporciona amplias funcionalidades de supervisión y diagnóstico con Azure Monitor. Se pueden obtener detalles y topologías adicionales mediante un panel centrado, precompilado y de supervisión en Azure Portal denominado Azure Monitor Insights para Virtual WAN. Estas herramientas de supervisión no son específicas de la seguridad. Azure Firewall implementado dentro de cada centro de conectividad de Virtual WAN proporciona el punto de integración para Confianza cero y supervisión de seguridad. Debe configurar Diagnósticos y registro para Azure Firewall igual que Azure Firewall fuera de Virtual WAN.

Azure Firewall proporciona las siguientes herramientas de supervisión que debe utilizar para garantizar la seguridad y la aplicación correcta de los principios de Confianza cero:

  • Policy Analytics de Azure Firewall proporciona información, visibilidad centralizada y control para Azure Firewall. La seguridad requiere que las reglas de firewall adecuadas estén en vigor y sean eficaces para proteger la infraestructura interna. Azure Portal resume los detalles sobre “Posibles orígenes malintencionados” generados por las características IDPS del motor de firewall e inteligencia contra amenazas

  • El libro de Azure Firewall proporciona un lienzo flexible para el análisis de datos de Azure Firewall. Puede obtener información sobre los eventos de Azure Firewall, conocer las reglas de la aplicación y de la red, y ver las estadísticas de las actividades de firewall en direcciones URL, puertos y direcciones. Se recomienda encarecidamente revisar periódicamente las estadísticas de registro de IDPS y, en la pestaña Investigaciones, comprobar el tráfico denegado, los flujos de origen y de destino, y el informe de inteligencia contra amenazas para revisar y optimizar las reglas de firewall.

Azure Firewall también integra Microsoft Sentinel con Microsoft Defender for Cloud. Se recomienda encarecidamente configurar correctamente ambas herramientas y utilizarlas activamente para Confianza cero de las siguientes maneras:

  • Con la integración de Microsoft Defender for Cloud, puede visualizar el estado completo de la infraestructura de red y la seguridad de red en un solo lugar, incluida la seguridad de red de Azure en todas las redes virtuales y centros virtuales distribuidos entre diferentes regiones de Azure. Con un solo vistazo, puede ver el número de Azure Firewalls, directivas de firewall y regiones de Azure en las que se implementan Azure Firewalls.
  • Una solución de Microsoft Sentinel para una integración sin problemas de Azure Firewall que brinda detección y prevención de amenazas. Una vez implementada, la solución permite la detección de amenazas personalizable integrada sobre Microsoft Sentinel. La solución también incluye un libro, detecciones, consultas de búsqueda y cuadernos de estrategia.

Formación para administradores

Los siguientes módulos de entrenamiento ayudan a su equipo con las aptitudes necesarias para aplicar Confianza cero principios a la implementación de Azure Virtual WAN.

Introducción a Azure Virtual WAN

Cursos Introducción a Azure Virtual WAN
Describa cómo considerar la posibilidad de construir una red de área extensa (WAN) con servicios de red de Azure Virtual WAN definidos por software.

Inicio >

Introducción a Azure Firewall

Cursos Introducción a Azure Firewall
Se describe cómo Azure Firewall protege los recursos de Azure VNet, incluidas las características de Azure Firewall, las reglas, las opciones de implementación y la administración con Azure Firewall Manager.

Inicio >

Introducción a Azure Firewall Manager

Cursos Introducción a Azure Firewall Manager
Se describe si puede usar Azure Firewall Manager para proporcionar una directiva de seguridad central y administración de rutas para perímetros de seguridad basados en la nube. Evalúe si Azure Firewall Manager puede ayudarle a proteger los perímetros de la nube.

Inicio >

Diseño e implementación de la seguridad de red

Cursos Diseño e implementación de la seguridad de red
Aprenderá a diseñar e implementar soluciones de seguridad de red como Azure DDoS, grupos de seguridad de red, Azure Firewall y Web Application Firewall.

Inicio >

Para más entrenamiento sobre seguridad en Azure, consulte estos recursos en el catálogo de Microsoft:
Seguridad en Azure

Pasos siguientes

Consulte estos artículos adicionales para aplicar principios de Confianza cero a Azure:

Referencias

Consulte estos vínculos para obtener información sobre los distintos servicios y tecnologías mencionados en este artículo.

Azure Virtual WAN

Líneas base de seguridad

Revisión del marco de buena arquitectura

Seguridad de Azure

Ilustraciones técnicas

Puede descargar las ilustraciones que se usan en este artículo. Use el archivo de Visio para modificar estas ilustraciones para su propio uso.

PDF | Visio

Para obtener ilustraciones técnicas adicionales, haga clic aquí.