Azure Firewall e inspección de tráfico

Azure Firewall es un servicio de seguridad de red nativo de nube administrado que proporciona inspección y filtrado centralizados del tráfico para las redes virtuales de Azure. A diferencia de los grupos de seguridad de red que operan en la capa 4, Azure Firewall inspecciona el tráfico en las capas 3 a 7. Esta funcionalidad habilita el filtrado completo de nombres de dominio (FQDN), la inteligencia sobre amenazas, la detección y prevención de intrusiones (IDPS) y la inspección de TLS. Se implementa Azure Firewall en una subred dedicada dentro de la red virtual del hub y se enruta el tráfico de las cargas de trabajo de los spokes a través del firewall para su inspección antes de que llegue a su destino.

En este artículo se explica cómo seleccionar la SKU de Azure Firewall adecuada, colocar el firewall en una topología en estrella tipo hub-spoke, configurar tipos de reglas e integrarlos con servicios complementarios, como NAT Gateway y Route Server. Azure Firewall es uno de los tres servicios principales de seguridad de red de Azure, junto con Azure DDoS Protection y Azure Web Application Firewall.

Lo que trata este artículo

Este artículo trata sobre la inspección centralizada del tráfico de red mediante Azure Firewall. Obtendrá información sobre:

  • Selección del nivel de SKU en función de los requisitos de seguridad y de la sensibilidad de la carga de trabajo.
  • Patrones de ubicación del centro y ruta definida por el usuario (UDR) que fuerzan el tráfico a través del firewall.
  • Lógica de procesamiento de las reglas DNAT, de red y de aplicación.
  • Tunelización forzada para entornos que requieren una inspección en las instalaciones.
  • Inspección de TLS y funcionalidades de IDPS en la capa Premium.
  • Integración con NAT Gateway para el escalado de puertos SNAT y Route Server para el enrutamiento basado en BGP.

Quién necesita este artículo

Implemente Azure Firewall cuando las cargas de trabajo requieran una o varias de las siguientes funcionalidades:

  • Control de salida centralizado: necesita restringir los FQDN y las direcciones URL externas a los que pueden acceder sus cargas de trabajo, más allá de lo que permiten las reglas de NSG basadas en IP.
  • Inspección este-oeste: El tráfico entre redes virtuales spoke debe pasar por un punto de inspección con estado antes de que el firewall lo permita.
  • Registro exigido por el cumplimiento normativo: Los marcos normativos exigen una visibilidad completa de la capa 7 sobre las conexiones permitidas y denegadas, con granularidad a nivel de FQDN.
  • Protección contra amenazas: Necesitas una solución de detección y prevención de intrusiones basada en firmas para identificar patrones de tráfico malicioso, como llamadas de comando y control, intentos de explotación y movimiento lateral.
  • Inspección de TLS: debe descifrar e inspeccionar el tráfico cifrado (HTTPS) para detectar amenazas antes de que llegue a las cargas de trabajo o salga de la red.

Las organizaciones que solo necesitan filtrado de paquetes de nivel 4 sin reconocimiento de FQDN deben considerar NSG y ASG como una alternativa más sencilla y económica.

Enfoque lift-and-shift: Convierte tu base de reglas de firewall local en una Azure Policy Firewall. Comience con reglas de red para el tráfico no HTTP/S y reglas de aplicación para el filtrado basado en FQDN. Comience con directivas de permiso generales durante la migración y, a continuación, apriete las reglas después de revisar los registros de Azure Firewall.

Enfoque de modernización: Utilice Azure Firewall como punto centralizado de SNAT y DNAT en el concentrador. Inspeccione el tráfico entre las redes radiales de aplicación y entre las redes radiales y el tráfico de Internet, utilice reglas de aplicación y etiquetas FQDN para el tráfico de salida de AKS y Azure PaaS, y prevea la inspección de TLS cuando las capas de aplicación intercambien tráfico confidencial.

Enfoque entre nubes: Implemente Azure Firewall en un centro virtual protegido para inspeccionar el tráfico de tránsito entre nubes. Configure reglas de red para el tráfico de túnel IPSec desde AWS o Google Cloud y use IDPS para observar patrones de tráfico anómalos entre nubes conectadas.

Niveles de SKU de Azure Firewall

Azure Firewall está disponible en tres niveles de SKU. Cada nivel se basa en las funcionalidades del nivel anterior.

Capacidad Basic Standard Premium
Inspección de paquetes con estado ✔ ✔ ✔
Filtrado de FQDN (saliente) ✔ ✔ ✔
Reglas de red (IP, puerto, protocolo) ✔ ✔ ✔
Reglas de aplicación (FQDN, URL) ✔ ✔ ✔
Reglas de NAT (DNAT) ✔ ✔ ✔
Filtrado de inteligencia sobre amenazas Solo alerta ✔ (Alerta + Denegar) ✔ (Alerta + Denegar)
Proxy DNS ✗ ✔ ✔
Categorías web ✗ ✔ ✔
IDPS (detección y prevención de intrusiones) ✗ ✗ ✔
Inspección de TLS ✗ ✗ ✔
Filtrado de direcciones URL (ruta de acceso completa) ✗ ✗ ✔
Proxy explícito ✗ ✔ ✔
Disponibilidad en regiones Regiones limitadas Todas las regiones Todas las regiones
Más adecuado para Desarrollo y pruebas, cargas de trabajo pequeñas Producción estándar De alta seguridad y orientada al cumplimiento normativo

Cómo elegir la SKU

Use los siguientes criterios de decisión:

  • Elija Básico cuando tenga entornos de desarrollo/pruebas o cargas de trabajo pequeñas que necesiten filtrado de salida basado en FQDN sin filtrado de inteligencia sobre amenazas (modo de denegación) o inspección avanzada. La SKU Básica incluye inteligencia sobre amenazas en modo de solo alertas, pero no admite el modo de denegación, el proxy DNS ni las categorías web. La SKU Basic requiere un AzureFirewallManagementSubnet dedicado (/26 como mínimo) junto con AzureFirewallSubnet y solo está disponible en determinadas regiones.
  • Elija Estándar para cargas de trabajo de producción que necesitan filtrado basado en inteligencia sobre amenazas, proxy DNS para la resolución de reglas FQDN, filtrado de categorías web y administración centralizada de directivas a través de Azure Firewall Manager. La SKU Estándar proporciona el motor completo de inspección con estado, con fuentes de inteligencia sobre amenazas que bloquean las conexiones a direcciones IP y dominios maliciosos conocidos.
  • Elija la opción Premium cuando los requisitos normativos o de seguridad exijan la inspección TLS del tráfico cifrado, un IDPS basado en firmas con reglas actualizadas continuamente (más de 67 000 firmas en más de 50 categorías, actualizadas en tiempo real) o el filtrado de la ruta completa de la URL más allá del FQDN. Se requiere Premium para sectores como los servicios financieros, la atención sanitaria y la administración pública, donde la inspección del tráfico cifrado es obligatoria.

Note

Actualice de Estándar a Premium sin volver a implementar el firewall. La degradación de Premium a Estándar requiere la reimplementación.

Ubicación del hub y patrón de enrutamiento de UDR

Implemente Azure Firewall en una subred dedicada denominada exactamente AzureFirewallSubnet dentro de la red virtual del centro de conectividad. Esta subred requiere un tamaño mínimo de /26 (59 direcciones IP utilizables).

Arquitectura de enrutamiento

Diagrama de una topología hub-spoke en la que el tráfico de las subredes spoke se enruta a través de Azure Firewall en la red virtual hub antes de llegar a Internet o a otros spokes.

En una topología hub-spoke, las subredes de cargas de trabajo de los spokes no enrutan el tráfico directamente a Internet ni a otros spokes. En su lugar, los UDR de cada subred spoke establecen la ruta predeterminada (0.0.0.0/0) hacia la dirección IP privada de Azure Firewall. Este patrón garantiza que todo el tráfico, tanto el norte-sur (destinado a Internet) como el este-oeste (de spoke a spoke), pase por el firewall para su inspección.

Patrón de configuración de UDR:

Tabla de rutas (aplicada a) Prefijo de dirección Tipo del próximo salto Dirección del próximo nodo
Subred de ramal A 0.0.0.0/0 Aplicación virtual Dirección IP privada del firewall
Subred de ramal A 10.1.0.0/16 (otro nodo periférico) Aplicación virtual Dirección IP privada del firewall
Subred de ramal B 0.0.0.0/0 Aplicación virtual Dirección IP privada del firewall
Subred de ramal B 10.0.0.0/16 (otro ramal) Aplicación virtual Dirección IP privada del firewall

El propio AzureFirewallSubnet no requiere UDR en la mayoría de los escenarios, porque el firewall utiliza rutas del sistema para llegar a las redes spoke a través del emparejamiento de red virtual. Al integrar con Azure Route Server, la subred de firewall aprende las rutas a través de BGP. Este enfoque elimina la necesidad de mantenimiento manual de rutas a medida que crece la red.

Sugerencia

Azure Virtual Network Manager puede automatizar la configuración de las tablas de rutas para utilizar Azure Firewall como siguiente salto, lo que reduce la administración manual de las UDR en numerosas suscripciones spoke.

Requisitos de subred

Subred Tamaño mínimo propósito Notes
AzureFirewallSubnet /26 Hospeda instancias de Azure Firewall Debe llamarse exactamente AzureFirewallSubnet
AzureFirewallManagementSubnet /26 Tráfico de administración (solo SKU Básico) Obligatorio para la SKU básica; opcional para la tunelización forzada en otras SKU

Para obtener más información sobre el diseño de redes virtuales hub y la planificación de subredes, consulta Topología hub-spoke.

Tipos de reglas y lógica de procesamiento

Azure Firewall procesa las reglas a través de Azure Firewall Policy. Las reglas se organizan en colecciones de reglas, que se agrupan en grupos de recopilación de reglas. El firewall evalúa las reglas en el orden de prioridad siguiente:

  1. Reglas DNAT (traducción de direcciones de red de destino): Se procesan primero. Traduzca el tráfico entrante de una dirección IP pública a una dirección IP privada detrás del firewall.
  2. Reglas de red: Se procesa en segundo lugar. Permitir o denegar el tráfico en función de la dirección IP de origen, la IP de destino, el puerto y el protocolo (nivel 3/4).
  3. Reglas de aplicación: procesadas por última vez. Permitir o denegar el tráfico saliente en función del FQDN, la dirección URL o la categoría web (nivel 7).

Dentro de cada tipo de regla, los grupos de recopilación de reglas se evalúan por prioridad (el número más bajo = prioridad más alta). Dentro de un grupo, las recopilaciones de reglas se evalúan por prioridad. La primera regla coincidente determina la acción (Permitir o Denegar) y detiene la evaluación adicional.

Reglas DNAT

Use reglas DNAT para publicar servicios internos a través de la dirección IP pública del firewall. El firewall traduce la dirección de destino de su dirección IP pública a la dirección IP privada del servicio back-end. Entre los escenarios habituales se incluyen los siguientes:

  • Exposición de un servidor web interno a través de la dirección IP pública del firewall en el puerto 443
  • Proporcionar acceso RDP o SSH controlado a un jump box sin asignar una dirección IP pública a la máquina virtual
  • Publicación de servicios que no son HTTP/S que requieren acceso entrante desde Internet
Example: Translate inbound TCP 443 on firewall public IP → 10.1.2.4:443 (internal web server)

Las reglas DNAT añaden implícitamente una regla de red correspondiente para permitir el tráfico traducido. Una vez que una regla DNAT coincide, el tráfico se traduce y se permite sin procesamiento adicional de reglas de red. Por motivos de seguridad, restrinja la dirección IP de origen en las reglas dnaT a orígenes de Internet específicos en lugar de usar caracteres comodín.

Reglas de red

Las reglas de red filtran el tráfico en la capa 3 y la capa 4. Use reglas de red cuando necesite permitir o denegar el tráfico en función de la dirección IP de origen, la dirección IP de destino, el puerto de destino y el protocolo. Las reglas de red no realizan la resolución de FQDN. Funcionan estrictamente en direcciones IP. Entre los casos de uso comunes se incluyen:

  • Permitir la comunicación entre spoke y spoke para puertos específicos (por ejemplo, SQL Server en el puerto TCP 1433).
  • Permitir NTP (UDP 123) a servidores de hora específicos.
  • Bloquear el tráfico a intervalos IP malintencionados conocidos mediante reglas de denegación.
  • Permitir ICMP para diagnósticos de red entre subredes específicas.

Las reglas de red admiten tipos de protocolo TCP, UDP, ICMP y Any. Puede especificar direcciones IP, intervalos IP, etiquetas de servicio y grupos IP como origen y destino.

Reglas de aplicación

Las reglas de aplicación filtran el tráfico HTTP/S y MSSQL salientes en función de FQDN, direcciones URL y categorías web. Las reglas de aplicación requieren la característica de proxy DNS para la resolución FQDN. Use reglas de aplicación cuando:

  • Debe permitir el acceso a FQDN específicos (por ejemplo, *.microsoft.com o storage.blob.core.windows.net).
  • Quieres filtrar por ruta de URL (solo para SKU Premium), por ejemplo, permitir github.com/myorg/* pero bloquear otras rutas de GitHub.
  • Debe permitir o bloquear categorías web completas (por ejemplo, permitir "Herramientas de desarrollo" y bloquear "Juegos de azar").

Las reglas de aplicación proporcionan etiquetas FQDN para servicios de Azure comunes (como Windows Update, Azure Backup y HDInsight) que simplifican la creación de reglas mediante la agrupación de los FQDN necesarios en una sola etiqueta.

Importante

Al habilitar el proxy DNS en Azure Firewall, el firewall actúa como solucionador DNS para cargas de trabajo. Configura la configuración de DNS de la red virtual para que apunte a la IP privada del cortafuegos, de modo que las reglas basadas en FQDN se resuelvan correctamente. Para más información sobre la arquitectura DNS, consulte Seguridad dns y resolución de nombres privados.

Comportamiento de SNAT

De forma predeterminada, Azure Firewall aplica SNAT (traducción de direcciones de red de origen) al tráfico saliente destinado a direcciones IP públicas. El firewall no realiza tráfico SNAT cuando el destino es un intervalo IP privado (RFC 1918) o un espacio de direcciones compartido (RFC 6598). El firewall traduce la dirección IP de origen de las conexiones enlazadas a Internet a una de sus direcciones IP públicas. Cada dirección IP pública proporciona 2496 puertos SNAT por instancia de back-end.

Para las cargas de trabajo con altas tasas de conexiones salientes, intégrelas con NAT Gateway para escalar hasta 64.512 puertos por IP pública (hasta 16 direcciones IP públicas, aproximadamente un millón de puertos SNAT en total).

Al asociar NAT Gateway con AzureFirewallSubnet, todo el tráfico saliente de Internet usa automáticamente las direcciones IP públicas de la puerta de enlace NAT. El firewall sigue inspeccionando el tráfico, pero NAT Gateway controla la traducción de SNAT. No se produce ninguna NAT doble.

Note

La puerta de enlace NAT con Azure Firewall con redundancia de zona requiere la SKU de puerta de enlace NAT EstándarV2. NAT Gateway no es compatible con las arquitecturas de concentrador protegido de Virtual WAN.

Firewall Manager y herencia de directivas

Azure Firewall Manager proporciona una directiva de seguridad centralizada y una administración de rutas en varias instancias de Azure Firewall. Entre las funcionalidades clave se incluyen las siguientes:

  • Jerarquía de directivas: Crea una directiva base (principal) con reglas para toda la organización y permite que los equipos subordinados creen directivas secundarias que hereden de la principal. Las reglas principales siempre tienen prioridad, independientemente de los valores de prioridad de las directivas secundarias.
  • Administración multirregional: Una directiva de cortafuegos es un recurso global que puede asociarse a cortafuegos de cualquier región o suscripción.
  • Gobernanza de varios firewalls: aplique una posición de seguridad coherente entre los firewalls del centro de conectividad en diferentes regiones o entre centros de Virtual WAN protegidos.

Las reglas NAT son específicas del firewall y no se heredan de las directivas primarias. El modo de inteligencia de amenazas se hereda, pero solo se puede anular con un modo más estricto en las directivas secundarias. Se incluye una directiva con cero o una asociación de firewall sin coste adicional. Las asociaciones adicionales conllevan cargos.

Tunelización forzada

En algunos entornos normativos, todo el tráfico enlazado a Internet debe enrutar primero a través de un punto de inspección local antes de llegar a Internet. Azure Firewall admite la tunelización forzada para adaptarse a este requisito.

Al habilitar la tunelización forzada:

  • AzureFirewallManagementSubnet lleva el tráfico de administración del firewall directamente a Internet. Esta subred debe tener una ruta a 0.0.0.0/0 con Internet como siguiente salto. No se puede forzar el tráfico de administración a pasar por la inspección local.
  • El AzureFirewallSubnet redirige el tráfico de las cargas de trabajo con destino a Internet a un firewall local o a un NVA de terceros a través de ExpressRoute o una puerta de VPN Gateway.
  • Las reglas DNAT no se admiten en el modo de tunelización forzada porque el tráfico entrante no puede acceder directamente a la dirección IP pública del firewall.
  • El firewall no requiere una dirección IP pública en el AzureFirewallSubnet cuando se configura la tunelización forzada, ya que todo el tráfico saliente se enruta a través de la ruta local.

Use la tunelización forzada cuando los mandatos de cumplimiento requieran visibilidad local de todo el tráfico enlazado a Internet o cuando necesite encadenar Azure Firewall con una pila de seguridad local existente. Entre los escenarios comunes se incluyen entornos de servicios financieros sujetos a normativas de residencia de datos y redes gubernamentales con requisitos centralizados de interrupción de Internet.

Importante

En el modo de tunelización forzada, AzureFirewallManagementSubnet requiere su propia dirección IP pública y una UDR con 0.0.0.0/0 apuntando a Internet como próximo salto. Esta configuración garantiza que Azure pueda mantener el canal de administración en el firewall.

Inspección TLS (Premium)

Azure Firewall Premium intercepta las conexiones HTTPS salientes, descifra el tráfico, la inspecciona con las firmas IDPS y las reglas de aplicación y, a continuación, vuelve a cifrarlo y lo reenvía. Este proceso requiere un certificado de CA intermedia almacenado en Azure Key Vault.

Requisitos de certificados

Requirement Especificación
Tipo de certificado Autoridad de certificación intermedia
Tamaño de la clave RSA mínimo de 2048 bits
Indicador de autoridad de certificación VERDADERO
Uso de las claves KeyCertSign
Validez Al menos 1 año de avance
Storage Azure Key Vault (debe ser exportable)

El firewall usa el certificado de entidad de certificación intermedio para generar dinámicamente certificados de servidor para las conexiones interceptadas. Los exploradores y aplicaciones del usuario final deben confiar en la CA raíz de la organización o en la CA intermedia en su almacén de certificados para evitar advertencias de confianza.

Sistema de Detección y Prevención de Intrusiones (IDPS)

La SKU Premium incluye un motor IDPS totalmente administrado con más de 67 000 reglas en más de 50 categorías. Las firmas se actualizan continuamente con entre 20 y más de 40 reglas nuevas que se publican cada día. IDPS funciona en dos modos:

  • Modo de alerta: registra coincidencias de firma sin bloquear el tráfico. Úselo durante el despliegue inicial y ajuste.
  • Modo de alerta y denegación: registra y bloquea el tráfico que coincide con las firmas IDPS. Utilizar en producción tras el ajuste.

Las categorías de IDPS incluyen malware de mando y control, phishing, troyanos, botnets, kits de explotación, vulnerabilidades y protocolos SCADA/ICS.

Caution

La inspección de TLS presenta latencia y tiene implicaciones de privacidad. Asegúrese de que los equipos legales y de cumplimiento de su organización aprueban la inspección del tráfico cifrado. Excluya las categorías confidenciales (atención sanitaria, banca) según sea necesario mediante reglas de omisión.

Filtrado de salida de AKS

Cuando los clústeres de Azure Kubernetes Service (AKS) requieren salida controlada, Azure Firewall proporciona filtrado de salida basado en FQDN para los nodos del clúster. Sin el filtrado de salida, los nodos de AKS pueden llegar a cualquier punto de conexión de Internet, lo que aumenta la superficie expuesta a ataques de cadena de suministro y filtración de datos.

Para implementar este patrón:

  1. Implemente AKS con outboundType establecido en userDefinedRouting y una tabla de rutas personalizada en la subred del nodo.
  2. Establezca la ruta predeterminada (0.0.0.0/0) en la dirección IP privada de Azure Firewall.
  3. Cree reglas de aplicación en la directiva del firewall que permitan el acceso a los FQDN necesarios de AKS (registros de contenedores, puntos de conexión del servidor API y repositorios de paquetes de Microsoft).
  4. Cree reglas de red para los puntos de conexión no HTTP/S necesarios (NTP, DNS, conectividad de túnel).

Este patrón proporciona a los equipos de seguridad visibilidad y control sobre qué puntos de conexión externos pueden alcanzar los nodos de AKS, al tiempo que permite que el clúster funcione correctamente. Los FQDN necesarios varían según el conjunto de características de AKS. Los clústeres que usan nodos de GPU, Azure Monitor o Azure Policy requieren entradas de lista aprobadas adicionales.

Para obtener ejemplos detallados de requisitos y reglas de FQDN, consulte Uso de Azure Firewall para proteger las implementaciones de AKS.

Note

El filtrado de salida de AKS con Azure Firewall requiere una coordinación cuidadosa entre los equipos de plataforma y aplicación. La ausencia de reglas de FQDN provoca errores al programar pods y al descargar imágenes. Comience con una política permisiva y restrínjala después de revisar los patrones de tráfico en los registros del cortafuegos.

Consideraciones de diseño

Enfoque de diseño de firewall lift-and-shift

  • Convierta las reglas del firewall local en la directiva de Azure Firewall: use reglas de red para protocolos que no sean HTTP/S y reglas de aplicación para destinos HTTP/S o MSSQL que requieran filtrado por FQDN.
  • Comience con reglas de permiso amplias que reflejen la posición de seguridad actual y, a continuación, aprietelas después de la migración mediante el uso de registros de Azure Firewall para identificar los destinos y puertos necesarios.
  • Use grupos de IP para modelar zonas de origen y destino, por lo que el mantenimiento de reglas sigue los límites de segmentación existentes.
  • Habilite la configuración de diagnóstico el día uno para poder comparar Azure patrones de tráfico con la línea base local antes de restringir el acceso.

Modernización del enfoque de diseño del firewall

  • Utilizar el firewall central como punto centralizado de SNAT y DNAT para los radios de las aplicaciones, de modo que las directivas de entrada y salida permanezcan en el centro administrado por TI.
  • Habilita Azure Firewall Premium cuando se requiera la inspección TLS este-oeste o la aplicación de IDPS en producción entre los niveles de aplicaciones.
  • Use etiquetas FQDN y reglas de aplicación para permitir las dependencias de AKS y Azure PaaS sin mantener listas IP de destino grandes.
  • Revisa los requisitos de DNAT en el diseño de Front Door o Application Gateway para que los flujos entrantes lleguen a los spokes del backend únicamente a través de rutas de inspección aprobadas.

Enfoque del diseño de firewall multinube

  • Implemente Azure Firewall en un centro virtual protegido cuando Azure sea el punto de tránsito de la rama, Azure y otras redes en la nube.
  • Utilice reglas de red para inspeccionar el tráfico de los túneles IPSec desde AWS Transit Gateway, puertas de enlace privadas virtuales de AWS o conexiones de Google Cloud VPN después de que las rutas lleguen a Azure.
  • Habilite IDPS para detectar patrones anómalos de tráfico este-oeste y entre nubes que pueden indicar el movimiento lateral entre entornos de nube.
  • Activa el filtrado de inteligencia de amenazas para bloquear destinos maliciosos conocidos en todas las nubes conectadas con una única directiva.

Prerequisites

Antes de implementar Azure Firewall:

  • AzureFirewallSubnet: la red virtual del centro de conectividad debe incluir una subred dedicada denominada AzureFirewallSubnet con un tamaño mínimo de /26. Consulte Diseño de red virtual y subred para obtener instrucciones de planeamiento de subredes.
  • Topología hub-spoke o Virtual WAN: implementa Azure Firewall en un hub central que enrute el tráfico procedente de las redes spoke. Consulte Topología hub-spoke o Virtual WAN para ver las opciones de topología.
  • Plan de direcciones IP: reserve el espacio de direcciones para la subred del firewall, la subred de administración (si usa la tunelización forzada) y las direcciones IP públicas. Consulte Planeamiento de direcciones IP.
  • Azure Firewall Manager: use Azure Firewall Manager si necesita una jerarquía de directivas que comparta reglas base entre varias instancias de firewall.
  • Área de trabajo de Log Analytics: cree un área de trabajo para los registros de diagnóstico del firewall antes de la implementación para poder supervisar el tráfico y solucionar problemas con las reglas desde el primer día.

Consideraciones de seguridad

  • Registro: Habilite la configuración de diagnóstico para enviar los registros de Azure Firewall a un área de trabajo de Log Analytics. Los registros estructurados proporcionan visibilidad a nivel de FQDN de todas las conexiones permitidas y denegadas, lo que facilita la auditoría y el análisis forense.
  • Disponibilidad: implemente Azure Firewall entre zonas de disponibilidad para maximizar su Acuerdo de Nivel de Servicio de disponibilidad. Para ver los porcentajes actuales del Acuerdo de Nivel de Servicio, consulte Acuerdo de Nivel de Servicio para Azure Firewall.
  • Defensa por capas: Azure Firewall complementa a los NSG, pero no los sustituye. Aplique NSG en los niveles de subred y NIC para la microsegmentación. Use el firewall para la directiva centralizada, la inteligencia sobre amenazas y la inspección de nivel 7.
  • Dimensiona adecuadamente lo que inspeccionas: forzar cada flujo a pasar por el firewall, incluidas las capas internas de la aplicación, como de web a aplicación y de aplicación a base de datos, añade latencia y costes de procesamiento por gigabyte. Utilice NSG y ASG para el tráfico este-oeste entre capas de confianza, y reserve la inspección del firewall para el tráfico que cruce un límite de confianza: dirigido a Internet, entre radios, híbrido o entre nubes. Este enfoque mantiene el firewall centrado en el tráfico que se beneficia de la inspección y evita costos innecesarios.
  • Protección contra DDoS: proteja las direcciones IP públicas asociadas a Azure Firewall mediante Azure DDoS Protection. Consulte Protección contra DDoS.
  • Tráfico de ExpressRoute: cuando utilices ExpressRoute, configura las UDR para dirigir el tráfico de emparejamiento privado a través de Azure Firewall con el fin de inspeccionar los flujos de tráfico híbridos.

Aprende más

Pasos siguientes

Sugerencia

¿Explorando por su cuenta? Vuelva al navegador de información general para encontrar el siguiente artículo por funcionalidad.

A continuación, en el itinerario de lift-and-shift:

Configuración de la supervisión de la red migrada: valide la conectividad y el rendimiento con Network Watcher después de configurar el firewall.

A continuación en su proceso de modernización:

Proteger las aplicaciones web con WAF: agregue Web Application Firewall en Front Door o Application Gateway para las aplicaciones web orientadas al cliente.

A continuación, en el itinerario entre nubes:

Configure la supervisión multinube: los entornos multinube son más difíciles de diagnosticar y resolver a nivel operativo. La supervisión es esencial, no opcional.

  • Last updated on