Recomendaciones para redes y conectividad

Artículo
11/15/2023

Se aplica a esta recomendación de lista de comprobación de seguridad de Azure Well-Architected Framework:

SE:05	Aísle, filtre y controle el tráfico de red en los flujos de entrada y salida. Aplique principios de defensa en profundidad mediante el uso de controles de red localizados en todos los límites de red disponibles en el tráfico este-oeste y norte-sur.

En esta guía se describen las recomendaciones para el diseño de red. El enfoque se centra en los controles de seguridad que pueden filtrar, bloquear y detectar adversarios que cruzan los límites de red en varias profundidades de la arquitectura.

Puede reforzar los controles de identidad mediante la implementación de medidas de control de acceso basadas en red. Junto con el control de acceso basado en identidades, la seguridad de red es una prioridad alta para proteger los recursos. Los controles de seguridad de red adecuados pueden proporcionar un elemento de defensa en profundidad que pueda ayudar a detectar y contener amenazas y evitar que los atacantes obtengan entrada en la carga de trabajo.

Definiciones

Término	Definición
Tráfico horizontal de derecha a izquierda	Tráfico de red que se mueve dentro de un límite de confianza.
Flujo de salida	Tráfico de carga de trabajo saliente.
Red hostil	Una red que no se implementa como parte de la carga de trabajo. Una red hostil se considera un vector de amenaza.
Flujo de entrada	Tráfico de carga de trabajo entrante.
Filtrado de red	Mecanismo que permite o bloquea el tráfico de red en función de las reglas especificadas.
Segmentación o aislamiento de red	Una estrategia que divide una red en segmentos pequeños y aislados, con controles de seguridad aplicados en los límites. Esta técnica ayuda a proteger los recursos de redes hostiles, como Internet.
Transformación de red	Mecanismo que muta los paquetes de red para ocultarlos.
Tráfico norte-sur	Tráfico de red que pasa de un límite de confianza a redes externas potencialmente hostiles y viceversa.

Estrategias de diseño principales

La seguridad de red usa la oscuridad para proteger los recursos de carga de trabajo frente a redes hostiles. Los recursos que están detrás de un límite de red están ocultos hasta que los controles de límite marcan el tráfico como seguro para avanzar. El diseño de seguridad de red se basa en tres estrategias principales:

Segmento. Esta técnica aísla el tráfico en redes independientes mediante la adición de límites. Por ejemplo, el tráfico hacia y desde un nivel de aplicación pasa un límite para comunicarse con otros niveles, que tienen requisitos de seguridad diferentes. Las capas de segmentación realizan el enfoque de defensa en profundidad.

El límite de seguridad más importante es el perímetro de red entre la aplicación y las redes públicas. Es importante definir claramente este perímetro para establecer un límite para aislar redes hostiles. Los controles de este borde deben ser muy eficaces, ya que este límite es su primera línea de defensa.

Las redes virtuales proporcionan un límite lógico. Por diseño, una red virtual no puede comunicarse con otra red virtual a menos que el límite se haya interrumpido intencionadamente mediante el emparejamiento. La arquitectura debe aprovechar esta medida de seguridad sólida y proporcionada por la plataforma.

También puede usar otros límites lógicos, como subredes talladas dentro de una red virtual. Una ventaja de las subredes es que puede usarlas para agrupar los recursos que están dentro de un límite de aislamiento y tienen garantías de seguridad similares. Después, puede configurar controles en el límite para filtrar el tráfico.
Filtro. Esta estrategia ayuda a garantizar que se espera, permite y protege el tráfico que entra en un límite. Desde una perspectiva Zero-Trust, el filtrado comprueba explícitamente todos los puntos de datos disponibles en el nivel de red. Puede colocar reglas en el límite para comprobar si hay condiciones específicas.

Por ejemplo, en el nivel de encabezado, las reglas pueden comprobar que el tráfico se origina desde una ubicación esperada o que tiene un volumen esperado. Pero estas comprobaciones no son suficientes. Incluso si el tráfico presenta características esperadas, es posible que la carga no sea segura. Las comprobaciones de validación pueden revelar un ataque por inyección de código SQL.
Transformación. Muta los paquetes en el límite como medida de seguridad. Por ejemplo, puede quitar encabezados HTTP para eliminar el riesgo de exposición. O bien, puede desactivar la seguridad de la capa de transporte (TLS) en un momento dado y restablecerla en otro salto con un certificado administrado de forma más rigurosa.

Clasificación de los flujos de tráfico

El primer paso para clasificar flujos es estudiar un esquema de la arquitectura de carga de trabajo. A partir del esquema, determine la intención y las características del flujo con respecto a la utilidad funcional y los aspectos operativos de la carga de trabajo. Use las siguientes preguntas para ayudar a clasificar el flujo:

Si la carga de trabajo necesita comunicarse con redes externas, ¿cuál debe ser el nivel necesario de proximidad a esas redes?
¿Cuáles son las características de red del flujo, como el protocolo esperado y el origen y la forma de los paquetes? ¿Hay algún requisito de cumplimiento en el nivel de red?

Hay muchas maneras de clasificar los flujos de tráfico. En las secciones siguientes se describen los criterios usados habitualmente.

Visibilidad de redes externas

Público. Una carga de trabajo es pública si su aplicación y otros componentes son accesibles desde la red pública de Internet. La aplicación se expone a través de una o varias direcciones IP públicas y servidores del Sistema de nombres de dominio público (DNS).
Privado. Una carga de trabajo es privada si solo se puede acceder a ella a través de una red privada, como una red privada virtual (VPN). Solo se expone a través de una o varias direcciones IP privadas y potencialmente a través de un servidor DNS privado.

En una red privada, no hay línea de visión desde la red pública de Internet a la carga de trabajo. Para la puerta de enlace, puede usar un equilibrador de carga o un firewall. Estas opciones pueden proporcionar garantías de seguridad.

Incluso con cargas de trabajo públicas, se esfuerza por mantener la mayor parte de la carga de trabajo privada posible. Este enfoque obliga a los paquetes a atravesar un límite privado cuando llegan desde una red pública. Una puerta de enlace de esa ruta de acceso puede funcionar como punto de transición actuando como proxy inverso.

Dirección del tráfico

Entrada. La entrada es el tráfico entrante que fluye hacia una carga de trabajo o sus componentes. Para ayudar a proteger la entrada, aplique el conjunto anterior de estrategias clave. Determine cuál es el origen del tráfico y si se espera, permite y es seguro. Los atacantes que examinan los intervalos de direcciones IP del proveedor de nube pública pueden penetrar correctamente en las defensas si no comprueba la entrada ni implementa medidas de seguridad de red básicas.
Salida. La salida es el tráfico saliente que fluye fuera de una carga de trabajo o sus componentes. Para comprobar la salida, determine dónde se dirige el tráfico y si el destino es esperado, permitido y seguro. El destino puede ser malintencionado o asociado a riesgos de filtración de datos.

También puede determinar el nivel de exposición considerando la proximidad de la carga de trabajo a la red pública de Internet. Por ejemplo, la plataforma de aplicaciones suele atender direcciones IP públicas. El componente de carga de trabajo es la cara de la solución.

Ámbito de influencia

Norte-sur. El tráfico que fluye entre una red de carga de trabajo y las redes externas es el tráfico norte-sur. Este tráfico cruza el borde de la red. Las redes externas pueden ser la red pública de Internet, una red corporativa o cualquier otra red que esté fuera del ámbito de control.

Tanto la entrada como la salida pueden ser tráfico norte-sur.

Por ejemplo, considere el flujo de salida de una topología de red en estrella tipo hub-and-spoke. Puede definir el perímetro de red de la carga de trabajo para que el centro sea una red externa. En ese caso, el tráfico saliente de la red virtual del radio es el tráfico norte-sur. Pero si considera la red de concentrador dentro de su esfera de control, el tráfico norte-sur se extiende al firewall en el centro, ya que el próximo salto es Internet, que es potencialmente hostil.
Este-oeste. El tráfico que fluye dentro de una red de carga de trabajo es el tráfico este-oeste. Este tipo de tráfico da como resultado cuando los componentes de la carga de trabajo se comunican entre sí. Un ejemplo es el tráfico entre los niveles de una aplicación de n niveles. En los microservicios, la comunicación entre servicios es el tráfico este-oeste.

Para proporcionar defensa en profundidad, mantenga el control completo de las prestaciones de seguridad que se incluyen en cada salto o que se usan cuando los paquetes cruzan segmentos internos. Los distintos niveles de riesgo requieren métodos de corrección de riesgos diferentes.

En el diagrama anterior se muestra la defensa de red en profundidad en la nube privada. En este diagrama, el borde entre los espacios de direcciones IP públicas y privadas está mucho más alejado de la carga de trabajo que en el diagrama de la nube pública. Varias capas separan las implementaciones de Azure del espacio de direcciones IP públicas.

Nota

La identidad siempre es el perímetro principal. La administración de acceso debe aplicarse a los flujos de red. Use identidades administradas al usar el control de acceso basado en rol (RBAC) de Azure entre los componentes de la red.

Después de clasificar los flujos, realice un ejercicio de segmentación para identificar puntos de inserción de firewall en las rutas de comunicación de los segmentos de red. Al diseñar la defensa de red en profundidad en todos los segmentos y todos los tipos de tráfico, suponga una infracción en todos los puntos. Use una combinación de varios controles de red localizados en todos los límites disponibles. Para obtener más información, vea Estrategias de segmentación.

Aplicación de firewalls en el perímetro

El tráfico perimetral de Internet es el tráfico norte-sur e incluye la entrada y salida. Para detectar o bloquear amenazas, una estrategia perimetral debe mitigar tantos ataques como sea posible hacia y desde Internet.

Para la salida, envíe todo el tráfico enlazado a Internet a través de un único firewall que proporcione supervisión, gobernanza y control mejorados del tráfico. Para la entrada, fuerce todo el tráfico de Internet para pasar por una aplicación virtual de red (NVA) o un firewall de aplicaciones web.

Los firewalls suelen ser singletons que se implementan por región en una organización. Como resultado, se comparten entre cargas de trabajo y son propiedad de un equipo central. Asegúrese de que todas las aplicaciones virtuales de red que use estén configuradas para satisfacer las necesidades de la carga de trabajo.
Se recomienda usar los controles nativos de Azure tanto como sea posible.

Además de los controles nativos, también puede considerar las aplicaciones virtuales de red asociadas que proporcionan características avanzadas o especializadas. Los productos de proveedor de firewall de aplicaciones web y firewall de asociados están disponibles en Azure Marketplace.

La decisión de usar características nativas en lugar de las soluciones de asociados debe basarse en la experiencia y los requisitos de su organización.

Compensación: las funcionalidades de asociados suelen proporcionar características avanzadas que pueden protegerse frente a ataques sofisticados, pero normalmente poco comunes. La configuración de las soluciones de asociados puede ser compleja y frágil, ya que estas soluciones no se integran con los controladores de tejido de la nube. Desde la perspectiva de los costos, se prefiere el control nativo porque es más barato que las soluciones de asociados.

Cualquier opción tecnológica que considere debe proporcionar controles de seguridad y supervisión para flujos de entrada y salida. Para ver las opciones disponibles para Azure, consulte la sección Seguridad de Edge de este artículo.

Diseño de la red virtual y la seguridad de subred

El objetivo principal de una nube privada es ocultar los recursos de la red pública de Internet. Hay varias maneras de lograr este objetivo:

Pase a espacios de direcciones IP privadas, que puede realizar mediante redes virtuales. Minimice la línea de visión de red incluso dentro de sus propias redes privadas.
Minimice el número de entradas DNS públicas que se usan para exponer menos de la carga de trabajo.
Agregue el control de flujo de red de entrada y salida. No permita el tráfico que no es de confianza.

Estrategia de segmentación

Para minimizar la visibilidad de la red, segmente la red y comience con controles de red con privilegios mínimos. Si un segmento no es enrutable, no se puede acceder a él. Amplíe el ámbito para incluir solo segmentos que necesiten comunicarse entre sí a través del acceso a la red.

Puede segmentar redes virtuales mediante la creación de subredes. Los criterios de división deben ser intencionados. Al intercalar servicios dentro de una subred, asegúrese de que esos servicios se puedan ver entre sí.

Puede basar la segmentación en muchos factores. Por ejemplo, puede colocar diferentes niveles de aplicación en segmentos dedicados. Otro enfoque consiste en planear las subredes en función de roles y funciones comunes que usan protocolos conocidos.

Para obtener más información, vea Estrategias de segmentación.

Firewalls de subred

Es importante inspeccionar el tráfico entrante y saliente de cada subred. Use las tres estrategias principales descritas anteriormente en este artículo, en Estrategias de diseño clave. Compruebe si el flujo es esperado, permitido y seguro. Para comprobar esta información, defina reglas de firewall basadas en el protocolo, el origen y el destino del tráfico.

En Azure, se establecen reglas de firewall en grupos de seguridad de red. Para más información, consulte la sección Grupos de seguridad de red de este artículo.

Para obtener un ejemplo de diseño de subred, consulte Azure Virtual Network subredes.

Uso de controles en el nivel de componente

Después de minimizar la visibilidad de la red, asigne los recursos de Azure desde una perspectiva de red y evalúe los flujos. Los siguientes tipos de flujos son posibles:

Tráfico planeado o comunicación intencionada entre servicios según el diseño de la arquitectura. Por ejemplo, ha planeado el tráfico cuando la arquitectura recomienda que Azure Functions extraiga mensajes de Azure Service Bus.
Tráfico de administración o comunicación que se produce como parte de la funcionalidad del servicio. Este tráfico no forma parte del diseño y no tiene control sobre él. Un ejemplo de tráfico administrado es la comunicación entre los servicios de Azure en la arquitectura y el plano de administración de Azure.

La distinción entre el tráfico planeado y de administración le ayuda a crear controles localizados o de nivel de servicio. Comprenda bien el origen y el destino en cada salto. En especial, comprenda cómo se expone el plano de datos.

Como punto de partida, determine si cada servicio se expone a Internet. Si es así, planee cómo restringir el acceso. Si no es así, colóquelo en una red virtual.

Firewalls de servicio

Si espera que un servicio se exponga a Internet, aproveche las ventajas del firewall de nivel de servicio que está disponible para la mayoría de los recursos de Azure. Al usar este firewall, puede establecer reglas basadas en patrones de acceso. Para más información, consulte la sección Firewalls de servicio de Azure de este artículo.

Nota

Cuando el componente no es un servicio, use un firewall basado en host además de los firewalls de nivel de red. Una máquina virtual (VM) es un ejemplo de un componente que no es un servicio.

Conectividad con servicios de plataforma como servicio (PaaS)

Considere la posibilidad de usar puntos de conexión privados para ayudar a proteger el acceso a los servicios de PaaS. A un punto de conexión privado se le asigna una dirección IP privada desde la red virtual. El punto de conexión permite que otros recursos de la red se comuniquen con el servicio PaaS a través de la dirección IP privada.

La comunicación con un servicio PaaS se logra mediante la dirección IP pública del servicio y el registro DNS. Esa comunicación se produce a través de Internet. Puede hacer que esa comunicación sea privada.

Un túnel del servicio PaaS en una de las subredes crea un canal privado. Toda la comunicación tiene lugar desde la dirección IP privada del componente a un punto de conexión privado de esa subred, que luego se comunica con el servicio PaaS.

En este ejemplo, la imagen de la izquierda muestra el flujo de puntos de conexión expuestos públicamente. A la derecha, ese flujo se protege mediante puntos de conexión privados.

Para más información, consulte la sección Puntos de conexión privados de este artículo.

Nota

Se recomienda usar puntos de conexión privados junto con firewalls de servicio. Un firewall de servicio bloquea el tráfico entrante de Internet y, a continuación, expone el servicio de forma privada a los usuarios internos que usan el punto de conexión privado.

Otra ventaja de usar puntos de conexión privados es que no es necesario abrir los puertos en el firewall para el tráfico saliente. Los puntos de conexión privados bloquean todo el tráfico saliente en el puerto para la red pública de Internet. La conectividad se limita a los recursos dentro de la red.

Compensación: Azure Private Link es un servicio de pago que tiene medidores para los datos entrantes y salientes que se procesan. También se le cobra por los puntos de conexión privados.

Protección contra ataques de denegación de servicio distribuido (DDoS)

Un ataque DDoS intenta agotar los recursos de una aplicación para que la aplicación no esté disponible para los usuarios legítimos. Los ataques DDoS pueden dirigirse a cualquier punto de conexión accesible públicamente a través de Internet.

Un ataque DDoS suele ser un abuso masivo, generalizado y disperso geográficamente de los recursos del sistema que dificulta la identificación y el bloqueo del origen.

Para obtener Soporte técnico de Azure para ayudar a protegerse contra estos ataques, consulte la sección Azure DDoS Protection de este artículo.

Facilitación de Azure

Puede usar los siguientes servicios de Azure para agregar funcionalidades de defensa en profundidad a la red.

Azure Virtual Network

Virtual Network ayuda a los recursos de Azure a comunicarse de forma segura entre sí, con Internet y con redes locales.

De forma predeterminada, todos los recursos de una red virtual pueden interactuar con la comunicación saliente con Internet. Pero la comunicación entrante está restringida de forma predeterminada.

Virtual Network ofrece características para filtrar el tráfico. Puede restringir el acceso en el nivel de red virtual mediante una ruta definida por el usuario (UDR) y un componente de firewall. En el nivel de subred, puede filtrar el tráfico mediante grupos de seguridad de red.

Seguridad perimetral

De forma predeterminada, tanto la entrada como la salida fluyen a través de direcciones IP públicas. En función del servicio o la topología, establezca estas direcciones o Azure las asigne. Otras posibilidades de entrada y salida incluyen pasar el tráfico a través de una puerta de enlace de traducción de direcciones de red (NAT) o un equilibrador de carga. Pero estos servicios están diseñados para la distribución del tráfico y no necesariamente para la seguridad.

Se recomiendan las siguientes opciones tecnológicas:

Azure Firewall. Puede usar Azure Firewall en el perímetro de red y en topologías de red populares, como redes en estrella tipo hub-and-spoke y REDES WAN virtuales. Normalmente, se implementan Azure Firewall como un firewall de salida que actúa como la puerta de seguridad final antes de que el tráfico vaya a Internet. Azure Firewall puede enrutar el tráfico que usa protocolos que no son HTTP y no HTTPS, como protocolo de escritorio remoto (RDP), protocolo de Secure Shell (SSH) y protocolo de transferencia de archivos (FTP). El conjunto de características de Azure Firewall incluye:
- Traducción de direcciones de red de destino (DNAT) o reenvío de puertos.
- Detección de intrusiones y detección de firmas del sistema de prevención (IDPS).
- Reglas de red de nivel 3, capa 4 y nombre de dominio completo (FQDN).
Nota

La mayoría de las organizaciones tienen una directiva de tunelización forzada que obliga al tráfico a fluir a través de una aplicación virtual de red.

Si no usa una topología de VIRTUAL WAN, debe implementar una UDR con una NextHopType de Internet en la dirección IP privada de la NVA. Las UDR se aplican en el nivel de subred. De forma predeterminada, el tráfico de subred a subred no fluye a través de la NVA.

También puede usar Azure Firewall simultáneamente para la entrada. Puede enrutar el tráfico HTTP y HTTPS. En las SKU de nivel superior, Azure Firewall ofrece terminación TLS para que pueda implementar inspecciones de nivel de carga.

Se recomiendan los procedimientos siguientes:
- Habilite la configuración de diagnóstico en Azure Firewall para recopilar registros de flujo de tráfico, registros IDPS y registros de solicitudes DNS.
- Sea lo más específico posible en las reglas.
- Donde es práctico, evite etiquetas de servicio FQDN. Pero cuando los use, use la variante regional, que permite la comunicación con todos los puntos de conexión del servicio.
- Use grupos de IP para definir orígenes que deben compartir las mismas reglas durante la vida útil del grupo de IP. Los grupos de IP deben reflejar la estrategia de segmentación.
- Invalide la regla de permiso de FQDN de infraestructura solo si la carga de trabajo requiere control de salida absoluto. La invalidación de esta regla incluye un equilibrio de confiabilidad, ya que los requisitos de la plataforma Azure cambian en los servicios.
Compensación: Azure Firewall pueden afectar al rendimiento. El orden de las reglas, la cantidad, la inspección de TLS y otros factores pueden provocar una latencia significativa.

También puede afectar a la confiabilidad de la carga de trabajo. Puede experimentar el agotamiento de puertos de traducción de direcciones de red de origen (SNAT). Para ayudar a solucionar este problema, agregue direcciones IP públicas según sea necesario.

Riesgo: para el tráfico de salida, Azure asigna una dirección IP pública. Esta asignación puede tener un impacto descendente en la puerta de seguridad externa.
Azure Web Application Firewall. Este servicio admite el filtrado entrante y solo tiene como destino el tráfico HTTP y HTTPS.

Ofrece seguridad básica para ataques comunes, como amenazas que identifica el proyecto open worldwide Application Security Project (OWASP) en el documento OWASP Top 10. Azure Web Application Firewall también proporciona otras características de seguridad que se centran en la capa 7, como la limitación de velocidad, las reglas de inyección de código SQL y el scripting entre sitios.

Con Azure Web Application Firewall, se requiere la terminación TLS, ya que la mayoría de las comprobaciones se basan en cargas.

Puede integrar Azure Web Application Firewall con enrutadores, como Azure Application Gateway o Azure Front Door. Las implementaciones de Azure Web Application Firewall para esos tipos de enrutadores pueden variar.

Azure Firewall y Azure Web Application Firewall no son opciones mutuamente excluyentes. Para la solución de seguridad perimetral, hay varias opciones disponibles. Para obtener ejemplos, consulte Firewall y Application Gateway para redes virtuales.

Grupos de seguridad de red

Un grupo de seguridad de red es un firewall de nivel 3 y nivel 4 que se aplica en el nivel de subred o tarjeta de interfaz de red (NIC). Los grupos de seguridad de red no se crean ni aplican de forma predeterminada.

Las reglas del grupo de seguridad de red actúan como firewall para detener el tráfico que fluye dentro y fuera en el perímetro de una subred. Un grupo de seguridad de red tiene un conjunto de reglas predeterminado que es excesivamente permisivo. Por ejemplo, las reglas predeterminadas no establecen un firewall desde la perspectiva de salida. Para la entrada, no se permite ningún tráfico entrante de Internet.

Para crear reglas, comience con el conjunto de reglas predeterminado:

Para el tráfico entrante o la entrada:
- Se permite el tráfico de red virtual desde orígenes directos, emparejados y de puerta de enlace de VPN.
- Azure Load Balancer se permiten sondeos de estado.
- El resto del tráfico está bloqueado.
Para el tráfico saliente o la salida:
- Se permite el tráfico de red virtual a destinos directos, emparejados y vpn Gateway.
- Se permite el tráfico a Internet.
- El resto del tráfico está bloqueado.

Después, tenga en cuenta los cinco factores siguientes:

Protocolo
Dirección IP de origen
Puerto de origen
Dirección IP de destino
Puerto de destino

La falta de compatibilidad con el FQDN limita la funcionalidad del grupo de seguridad de red. Debe proporcionar intervalos de direcciones IP específicos para la carga de trabajo y es difícil de mantener.

Sin embargo, para los servicios de Azure, puede usar etiquetas de servicio para resumir los intervalos de direcciones IP de origen y destino. Una ventaja de seguridad de las etiquetas de servicio es que son opacos para el usuario y la responsabilidad se descarga en Azure. También puede asignar un grupo de seguridad de aplicaciones como un tipo de destino al que enrutar el tráfico. Este tipo de grupo con nombre contiene recursos que tienen necesidades de acceso entrante o saliente similares.

Riesgo: los intervalos de etiquetas de servicio son muy amplios para que se adapten a la gama más amplia posible de clientes. Novedades a las etiquetas de servicio retrasan los cambios en el servicio.

En la imagen anterior, los grupos de seguridad de red se aplican en la NIC. Se deniega el tráfico de Internet y el tráfico de subred a subred. Los grupos de seguridad de red se aplican con la VirtualNetwork etiqueta . Por lo tanto, en este caso, las subredes de redes emparejadas tienen una línea directa de visión. La definición general de la etiqueta puede tener un impacto significativo en la VirtualNetwork seguridad.

Cuando use etiquetas de servicio, use versiones regionales siempre que sea posible, como Storage.WestUS en lugar de Storage. Al adoptar este enfoque, se limita el ámbito a todos los puntos de conexión de una región determinada.

Algunas etiquetas son exclusivamente para el tráfico entrante o saliente . Otros son para ambos tipos. Normalmente, las etiquetas entrantes permiten el tráfico de todas las cargas de trabajo de hospedaje, como AzureFrontDoor.Backend, o desde Azure para admitir entornos de ejecución de servicio, como LogicAppsManagement. De forma similar, las etiquetas salientes permiten el tráfico a todas las cargas de trabajo de hospedaje o desde Azure para admitir entornos de ejecución de servicio.

Ámbito de las reglas tanto como sea posible. En el ejemplo siguiente, la regla se establece en valores específicos. Se deniega cualquier otro tipo de tráfico.

Información de	Ejemplo
Protocolo	Protocolo de control de transmisión (TCP), UDP
Dirección IP de origen	Permitir la entrada a la subred desde el intervalo> de <direcciones IP de origen: 4575/UDP
Puerto de origen	Permitir la entrada a la subred desde la etiqueta> de <servicio: 443/TCP
Dirección IP de destino	Permitir la salida de la subred al <intervalo> de direcciones IP de destino: 443/TCP
Puerto de destino	Permitir la salida de la subred a <la etiqueta> de servicio: 443/TCP

En resumen:

Sea preciso al crear reglas. Permitir solo el tráfico necesario para que la aplicación funcione. Deniegue todo lo demás. Este enfoque limita la línea de visión de red a los flujos de red necesarios para admitir el funcionamiento de la carga de trabajo. Admitir más flujos de red de los necesarios conduce a vectores de ataque innecesarios y amplía el área expuesta.

Restringir el tráfico no implica que los flujos permitidos estén fuera del ámbito de un ataque. Dado que los grupos de seguridad de red funcionan en las capas 3 y 4 de la pila de interconexión de sistemas abiertos (OSI), solo contienen información de forma y dirección. Por ejemplo, si la carga de trabajo necesita permitir el tráfico DNS a Internet, usaría un grupo de seguridad de red de Internet:53:UDP. En este caso, un atacante podría ser capaz de filtrar datos a través de UDP en el puerto 53 a otro servicio.
Comprenda que los grupos de seguridad de red pueden diferir ligeramente entre sí. Es fácil pasar por alto la intención de las diferencias. Para tener filtrado pormenorizados, es más seguro crear grupos de seguridad de red adicionales. Configure al menos un grupo de seguridad de red.
- Al agregar un grupo de seguridad de red, se desbloquean muchas herramientas de diagnóstico, como los registros de flujo y el análisis de tráfico de red.
- Use Azure Policy para ayudar a controlar el tráfico en subredes que no tienen grupos de seguridad de red.
Si una subred admite grupos de seguridad de red, agregue un grupo, incluso si tiene un impacto mínimo.

Firewalls de servicio de Azure

La mayoría de los servicios de Azure ofrecen un firewall de nivel de servicio. Esta característica inspecciona el tráfico de entrada al servicio desde intervalos de enrutamiento entre dominios (CIDR) sin clases especificados. Estos firewalls ofrecen ventajas:

Proporcionan un nivel básico de seguridad.
Hay un impacto tolerable en el rendimiento.
La mayoría de los servicios ofrecen estos firewalls sin costo adicional.
Los firewalls emiten registros a través de diagnósticos de Azure, lo que puede ser útil para analizar patrones de acceso.

Pero también hay problemas de seguridad asociados a estos firewalls y hay limitaciones asociadas con el suministro de parámetros. Por ejemplo, si usa agentes de compilación hospedados por Microsoft, debe abrir el intervalo de direcciones IP para todos los agentes de compilación hospedados por Microsoft. A continuación, el intervalo está abierto para el agente de compilación, otros inquilinos y adversarios que podrían abusar del servicio.

Si tiene patrones de acceso para el servicio, que se pueden configurar como conjuntos de reglas de firewall de servicio, debe habilitar el servicio. Puede usar Azure Policy para habilitarla. Asegúrese de no habilitar la opción de servicios de Azure de confianza si no está habilitada de forma predeterminada. Al hacerlo, se incluyen todos los servicios dependientes que están en el ámbito de las reglas.

Para más información, consulte la documentación del producto de servicios individuales de Azure.

Puntos de conexión privados

Private Link proporciona una manera de proporcionar a una instancia de PaaS una dirección IP privada. A continuación, el servicio no es accesible a través de Internet. Los puntos de conexión privados no se admiten para todas las SKU.

Tenga en cuenta las siguientes recomendaciones al usar puntos de conexión privados:

Configure servicios enlazados a redes virtuales para ponerse en contacto con los servicios de PaaS a través de puntos de conexión privados, incluso si esos servicios PaaS también necesitan ofrecer acceso público.
Promueva el uso de grupos de seguridad de red para puntos de conexión privados para restringir el acceso a las direcciones IP del punto de conexión privado.
Use siempre firewalls de servicio cuando use puntos de conexión privados.
Cuando sea posible, si tiene un servicio que solo es accesible a través de puntos de conexión privados, quite la configuración de DNS para su punto de conexión público.
Tenga en cuenta los problemas de línea de visión en tiempo de ejecución al implementar puntos de conexión privados. Pero también considere los problemas de DevOps y supervisión.
Use Azure Policy para aplicar la configuración de recursos.

Compensación: las SKU de servicio con puntos de conexión privados son costosas. Los puntos de conexión privados pueden complicar las operaciones debido a la oscuridad de la red. Debe agregar agentes autohospedados, jump boxes, una VPN y otros componentes a la arquitectura.

La administración de DNS puede ser compleja en topologías de red comunes. Es posible que tenga que introducir reenviadores DNS y otros componentes.

Inserción de red virtual

Puede usar el proceso de inserción de red virtual para implementar algunos servicios de Azure en la red. Algunos ejemplos de estos servicios son Azure App Service, Functions, Azure API Management y Azure Spring Apps. Este proceso aísla la aplicación de Internet, los sistemas de redes privadas y otros servicios de Azure. El tráfico entrante y saliente de la aplicación se permite o deniega en función de las reglas de la red.

Azure Bastion

Puede usar Azure Bastion para conectarse a una máquina virtual mediante el explorador y el Azure Portal. Azure Bastion mejora la seguridad de las conexiones RDP y SSH. Un caso de uso típico incluye la conexión a un jump box en la misma red virtual o en una red virtual emparejada. El uso de Azure Bastion quita la necesidad de que la máquina virtual tenga una dirección IP pública.

Azure DDoS Protection

Cada propiedad de Azure está protegida por la protección de la infraestructura de DDoS de Azure sin costo adicional y sin configuración agregada. El nivel de protección es básico, pero la protección tiene umbrales altos. Tampoco proporciona telemetría ni alertas y es independiente de la carga de trabajo.

Las SKU de nivel superior de DDoS Protection están disponibles, pero no son gratuitas. La escala y la capacidad de la red de Azure implementada globalmente ofrece protección contra ataques comunes de capa de red. Las tecnologías como la supervisión del tráfico siempre activa y la mitigación en tiempo real proporcionan esta funcionalidad.

Para más información, consulte Introducción a Azure DDoS Protection.

Ejemplo

Estos son algunos ejemplos que muestran el uso de controles de red recomendados en este artículo.

Entorno de TI

Este ejemplo se basa en el entorno de tecnología de la información (TI) establecido en la línea de base de seguridad (SE:01). Este enfoque proporciona una amplia comprensión de los controles de red aplicados en varios perímetros para restringir el tráfico.

Roles de ataque de red. Se pueden considerar varios roles en un ataque de red, incluidos administradores, empleados, clientes del cliente y atacantes anónimos.
Acceso VPN. Un actor incorrecto puede acceder al entorno local a través de una VPN o un entorno de Azure conectado al entorno local a través de una VPN. Configure con el protocolo IPSec para habilitar la comunicación segura.
Acceso público a la aplicación. Tener un firewall de aplicaciones web (WAF) delante de la aplicación para protegerlo en la capa 7 de la capa de OSI de red.
Acceso de operador. El acceso remoto a través de la capa 4 de las capas de OSI de red debe protegerse. Considere la posibilidad de usar Azure Firewall con características de IDP/IDS.
DDoS Protection. Tenga protección contra DDoS para toda la red virtual.
Topología de red. Una topología de red, como el radio concentrador, es más segura y optimiza los costos. La red de concentrador proporciona protección de firewall centralizada a todos los radios emparejados.
Puntos de conexión privados: considere la posibilidad de agregar servicios expuestos públicamente a la red privada mediante puntos de conexión privados. Estos crean una tarjeta de red (NIC) en la red virtual privada y se enlazan con el servicio de Azure.
Comunicación TLS. Proteja los datos en tránsito mediante la comunicación a través de TLS.
Grupo de seguridad de red (NSG): proteja segmentos dentro de una red virtual con NSG, un recurso libre que filtre la comunicación entrante y saliente TCP/UDP teniendo en cuenta los intervalos de ip y puerto. Parte de NSG es el grupo de seguridad de aplicaciones (ASG) que permite crear etiquetas para reglas de tráfico para facilitar la administración.
Log Analytics. Los recursos de Azure emiten telemetría que se ingiere en Log Analytics y, a continuación, se usan con una solución SIEM como Microsoft Sentinel para su análisis.
Integración de Microsoft Sentinel. Log Analytics se integra con Microsoft Sentinel y otras soluciones como Microsoft Defender for Cloud.
Microsoft Defender for Cloud. Microsoft Defender for Cloud ofrece muchas soluciones de protección de cargas de trabajo, incluidas las recomendaciones de red para su entorno.
Análisis de tráfico: supervise los controles de red con Análisis de tráfico. Esto se configura a través de Network Watcher, parte de Azure Monitor y agrega aciertos entrantes y salientes en las subredes recopiladas por el grupo de seguridad de red.

Arquitectura para una carga de trabajo en contenedor

En esta arquitectura de ejemplo se combinan los controles de red que se describen en este artículo. En el ejemplo no se muestra la arquitectura completa. En su lugar, se centra en los controles de entrada en la nube privada.

Application Gateway es un equilibrador de carga de tráfico web que puede usar para administrar el tráfico a las aplicaciones web. Implemente Application Gateway en una subred dedicada que tenga controles de grupo de seguridad de red y controles de firewall de aplicaciones web implementados.

La comunicación con todos los servicios PaaS se realiza a través de puntos de conexión privados. Todos los puntos de conexión se colocan en una subred dedicada. DDoS Protection ayuda a proteger todas las direcciones IP públicas configuradas para un nivel básico o superior de protección de firewall.

El tráfico de administración está restringido a través de Azure Bastion, lo que ayuda a proporcionar conectividad RDP y SSH segura y sin problemas a las máquinas virtuales directamente desde el Azure Portal a través de TLS. Los agentes de compilación se colocan en la red virtual para que tengan una vista de red para los recursos de carga de trabajo, como recursos de proceso, registros de contenedor y bases de datos. Este enfoque ayuda a proporcionar un entorno seguro y aislado para los agentes de compilación, lo que aumenta la protección del código y los artefactos.

Los grupos de seguridad de red en el nivel de subred de los recursos de proceso restringen el tráfico de salida. La tunelización forzada se usa para enrutar todo el tráfico a través de Azure Firewall. Este enfoque ayuda a proporcionar un entorno seguro y aislado para los recursos de proceso, lo que aumenta la protección de los datos y las aplicaciones.

Lista de comprobación de seguridad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de seguridad

Recomendaciones para redes y conectividad