Aplicación de principios de Confianza cero a una red virtual de radio en Azure

Resumen: para aplicar principios de Confianza cero a una red virtual radial en Azure, debe aprovechar el control de acceso basado en rol (RBAC), aislar subredes y máquinas virtuales (grupos de recursos, grupos de seguridad de red y grupos de seguridad de aplicaciones), proteger el tráfico y los recursos dentro de la red virtual y las aplicaciones de máquina virtual, y habilitar la detección avanzada de amenazas, alertas y protección.

Este artículo le ayuda a aplicar los principios de Confianza cero a una red virtual de radio (VNet) para cargas de trabajo de IaaS en Azure 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. Use grupos de seguridad de aplicaciones para comprobar que las NIC individuales tienen permisos para comunicarse a través de canales específicos.
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. No habilite el acceso 3389/RDP de manera predeterminada en ningún canal. Utilice los permisos de rol correctos para el contexto de radio.
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. Limite la comunicación innecesaria entre los recursos. Asegúrese de que puede iniciar sesión en grupos de seguridad de red y de que tiene una visibilidad adecuada del tráfico anómalo. Realice un seguimiento de los cambios realizados en los grupos de seguridad de red.

Este artículo forma parte de una serie de artículos que muestran cómo aplicar los principios de Confianza cero en un entorno de Azure que incluye una VNet de radio que hospeda una carga de trabajo basada en máquina virtual. Para obtener más información, consulte Introducción a la aplicación de principios de Confianza cero a IaaS de Azure.

Arquitectura de referencia

En el diagrama siguiente se muestra una arquitectura de referencia común para cargas de trabajo basadas en IaaS.

Arquitectura de referencia para los componentes de una aplicación típica de tres niveles que se ejecuta en máquinas virtuales en una red virtual de radio de Azure.

En el diagrama:

  • Una red virtual de radio incluye componentes para admitir una aplicación IaaS formada por máquinas virtuales.
  • La aplicación IaaS es una aplicación de tres niveles formada por dos máquinas virtuales para cada nivel: front-end, aplicación y datos.
  • Cada nivel se incluye dentro de una subred dedicada con un grupo de seguridad de red dedicado.
  • Cada rol de máquina virtual se asigna a un grupo de seguridad de aplicaciones correspondiente a su rol.
  • El acceso a la aplicación se proporciona a través de una instancia de Application Gateway contenida en su propia subred.

La aplicación que se muestra en la arquitectura de referencia sigue el estilo de arquitectura de N niveles

En el diagrama siguiente se muestran los componentes de un grupo de recursos para una red virtual de radio en una suscripción de Azure independiente de la suscripción para la red virtual de centro.

La arquitectura lógica para aplicar Confianza cero a una red virtual del radio de Azure que muestra suscripciones, grupos de recursos y componentes de Azure dentro de un inquilino de Entra ID.

En el diagrama, todos los componentes de la red virtual de radio se encuentran en un grupo de recursos dedicado:

  • Una red virtual
  • Una Azure Application Gateway (APP GW), incluido Web Application Firewall (WAF)
  • Tres grupos de seguridad de red, uno para cada capa de aplicación
  • Tres grupos de seguridad de aplicación, uno para cada capa de aplicación

Contenido de este artículo

Los principios de Confianza cero se aplican en toda la arquitectura, desde el nivel de inquilino y directorio hasta la asignación de máquinas virtuales a grupos de seguridad de aplicaciones. En la tabla siguiente se describen las recomendaciones para proteger esta arquitectura.

Paso Tarea Principios de Confianza cero aplicados
1 Utilizar el control de acceso basado en rol (RBAC) de Microsoft Entra o configurar roles personalizados para los recursos de red. Uso del acceso con privilegios mínimos
2 Aislar la infraestructura en su propio grupo de recursos. Dar por hecho que habrá intrusiones al sistema
3 Creación de un grupo de seguridad de red para cada subred. Utilizar el acceso con privilegios mínimos
Dar por hecho que habrá intrusiones al sistema
4 Creación un grupo de seguridad de aplicaciones para cada máquina virtual. Comprobación explícita
Utilizar el acceso con privilegios mínimos
Dar por hecho que habrá intrusiones al sistema
5 Protección del tráfico y los recursos dentro de la red virtual:
  • Implementación de reglas de denegación de línea base para grupos de seguridad de red
  • Implementación de reglas específicas de la aplicación para grupos de seguridad de aplicaciones
  • Planificación del tráfico de administración en la red virtual
  • Implementación de los registros de flujo de grupo de seguridad de red
  • Comprobación explícita
    Utilizar el acceso con privilegios mínimos
    Dar por hecho que habrá intrusiones al sistema
    6 Acceso seguro a la red virtual y a la aplicación. Utilizar el acceso con privilegios mínimos
    Dar por hecho que habrá intrusiones al sistema
    7 Habilitación de la detección avanzada de amenazas, las alertas y la protección. Dar por hecho que habrá intrusiones al sistema

    Paso 1: Utilizar de RBAC de Microsoft Entra o configurar roles personalizados para los recursos de red

    Puede utilizar los roles integrados de RBAC de Microsoft Entra para los colaboradores de red. Sin embargo, otra opción puede consistir en usar roles personalizados. Los administradores de red de radio no necesitan acceso total a los recursos de red concedidos por el rol Colaborador de red RBAC de Microsoft Entra, pero necesitan más permisos que otros roles comunes. Puede usar un rol personalizado para limitar el acceso solo a lo que se necesita.

    Una manera sencilla de implementar esto es implementar los roles personalizados que se encuentran en la arquitectura de referencia de zona de aterrizaje de Azure.

    El rol específico es el rol personalizado Administración de redes, que tiene los permisos siguientes:

    • Leer todo en el ámbito
    • Cualquier acción con el proveedor de red
    • Cualquier acción con el proveedor de soporte técnico
    • Cualquier acción con el proveedor de recursos

    Puede crear este rol mediante los scripts de los roles personalizados o a través de Microsoft Entra ID con el proceso descrito en Roles personalizados de Azure: RBAC de Azure.

    Paso 2: Aislar la infraestructura en su propio grupo de recursos

    Al aislar los recursos de red de los recursos de proceso, datos o almacenamiento, se reduce la probabilidad de que se produzcan errores de permisos. Además, al asegurarse de que todos los recursos relacionados están en un grupo de recursos, puede realizar una asignación de seguridad y administrar mejor el registro y la supervisión en estos recursos.

    En lugar de tener los recursos de red de radio disponibles en varios contextos en un grupo de recursos compartido, cree un grupo de recursos dedicado para ello. La arquitectura de referencia que admite este artículo ilustra este concepto.

    La arquitectura lógica que muestra un grupo de recursos dedicado y sus componentes para una red virtual de radio con principios de Confianza cero aplicados.

    En la figura, los recursos y los componentes de la arquitectura de referencia se dividen en grupos de recursos dedicados para máquinas virtuales, cuentas de almacenamiento, recursos de red virtual de centro y recursos de red virtual de radio.

    Con un grupo de recursos dedicado, puede asignar un rol personalizado mediante el proceso siguiente:Tutorial: Concesión de acceso de usuario a los recursos de Azure mediante Azure Portal: Azure RBAC.

    Recomendaciones adicionales:

    • Haga referencia a un grupo de seguridad para el rol en lugar de a individuos con nombre.
    • Administre el acceso al grupo de seguridad a través de los patrones de administración de identidades empresariales.

    Si no usa directivas que aplican el reenvío de registros en grupos de recursos, configúrelo en el registro de actividad del grupo de recursos: Vaya a Registros de actividad > Exportar registros de actividad y, a continuación, seleccione + Agregar configuración de diagnóstico.

    En la pantalla Configuración de diagnóstico, seleccione todas las categorías de registro (especialmente Seguridad) y envíelas a los orígenes de registro adecuados, como un área de trabajo de Log Analytics para observar o una cuenta de almacenamiento para el almacenamiento a largo plazo.

    Democratización de las suscripciones

    Aunque no está relacionado directamente con las redes, debe planear el RBAC de su suscripción de forma similar. Además de aislar los recursos lógicamente por grupo de recursos, también debe aislar la suscripción en función de las áreas de negocio y los propietarios de carteras. La suscripción como unidad de administración debe tener un ámbito limitado.

    Para más información sobre la democratización de la suscripción, consulte Principios de diseño de zona de aterrizaje de Azure: Cloud Adoption Framework.

    Puede configurar diagnósticos desde la categoría Seguridad de la configuración de diagnóstico en Azure Monitor, como se muestra aquí.

    Captura de pantalla de la configuración de diagnóstico para la seguridad en Azure Monitor.

    Consulte Configuración de diagnóstico para comprender cómo revisar estos registros y generar una alerta.

    Paso 3: Creación de un grupo de seguridad de red para cada subred

    Los grupos de seguridad de red de Azure se usan para ayudar a filtrar el tráfico de red entre los recursos de Azure en la red virtual de Azure. Se recomienda aplicar un grupo de seguridad de red a cada subred, que se aplica a través de azure policy de forma predeterminada al implementar las zonas de aterrizaje de Azure. Un grupo de seguridad de red contiene reglas de seguridad que permiten o deniegan el tráfico de red entrante o el tráfico de red saliente de varios tipos de recursos de Azure. En todas las reglas, puede especificar un origen y destino, un puerto y un protocolo.

    Para una aplicación basada en máquinas virtuales de varios niveles, la recomendación es crear un grupo de seguridad de red dedicado (NSG en la ilustración siguiente) para cada subred que hospeda un rol de máquina virtual.

    Arquitectura de referencia de ejemplo para grupos de seguridad de red dedicados para cada subred que hospeda un rol de máquina virtual.

    En el diagrama:

    • Cada nivel de la aplicación se hospeda en una subred dedicada, como, por ejemplo, el nivel de front-end, el nivel de aplicación y el nivel de datos.
    • Se configura un grupo de seguridad de red para cada una de estas subredes.

    La configuración de grupos de seguridad de red de una manera diferente de la que se muestra en la ilustración puede dar lugar a una configuración incorrecta de algunos o todos los grupos de seguridad de red y puede crear problemas en la solución de problemas. También puede dificultar la supervisión y el registro.

    Cree un grupo de seguridad de red con este proceso: Crear, cambiar o eliminar un grupo de seguridad de red de Azure.

    Consulte grupos de seguridad de red para comprender cómo puede usarlos para proteger el entorno.

    Paso 4: Creación un grupo de seguridad de aplicaciones para cada rol de máquina virtual

    Los grupos de seguridad de aplicaciones le permiten configurar la seguridad de red como una extensión natural de la estructura de una aplicación, lo que le permite agrupar máquinas virtuales y directivas de seguridad de red basadas en esos grupos. Puede reutilizar la directiva de seguridad a escala sin mantenimiento manual de direcciones IP explícitas. La plataforma controla la complejidad de las direcciones IP explícitas y de varios conjuntos de reglas, lo que le permite centrarse en su lógica de negocios.

    Dentro de la carga de trabajo, identifique los roles de máquina virtual específicos. A continuación, cree un grupo de seguridad de aplicaciones para cada rol. En la arquitectura de referencia, se representan tres grupos de seguridad de aplicaciones.

    Arquitectura de referencia de ejemplo para grupos de seguridad de aplicaciones independientes para distintos roles de máquina virtual.

    En el diagrama:

    • Se crean tres grupos de seguridad de aplicaciones para admitir esta aplicación, una para cada nivel: front-end, aplicación y datos.
    • Cada máquina virtual se asigna al grupo de seguridad de aplicaciones correspondiente para su rol (texto rojo en el diagrama).

    Para más información sobre los grupos de seguridad de aplicaciones y cómo asignarlos a máquinas virtuales, consulte Introducción a los grupos de seguridad de aplicaciones de Azure.

    Nota:

    Si usa equilibradores de carga, el uso de la dirección IP del equilibrador de carga en los grupos de seguridad de red es necesario, ya que los grupos de seguridad de aplicaciones no pueden limitar el ámbito de un equilibrador de carga.

    Paso 5: Protección del tráfico y los recursos dentro de la red virtual

    En esta sección, se mencionan las siguientes recomendaciones:

    • Implementación de reglas de denegación de línea base para grupos de seguridad de red
    • Implementación de reglas específicas de la aplicación para grupos de seguridad de aplicaciones
    • Planificación para el tráfico de administración en la red virtual
    • Implementación de los registros de flujo de grupo de seguridad de red

    Implementación de reglas de denegación de línea base para grupos de seguridad de red

    Un elemento clave de Confianza cero usa el menor nivel de acceso necesario. De forma predeterminada, los grupos de seguridad de red tienen reglas permitidas. Al agregar una línea base de reglas de denegación, puede aplicar el menor nivel de acceso.

    Una vez aprovisionado, cree una regla Denegar todo en cada una de las reglas de entrada y salida con una prioridad de 4096. Esta es la última prioridad personalizada disponible, lo que significa que todavía tiene el ámbito restante para configurar las acciones permitidas.

    En el grupo de seguridad de red, vaya a Reglas de seguridad de salida y seleccione Agregar. Rellene lo siguiente:

    • Origen: Cualquiera
    • Intervalos de puertos de origen: *
    • Destino: Cualquiera
    • Servicio: personalizado
    • Intervalos de puertos de destino: *
    • Protocolo: Cualquiera
    • Acción: Denegar
    • Prioridad: 4096
    • Nombre: DenyAllOutbound
    • Descripción: deniega todo el tráfico saliente a menos que se permita específicamente.

    Este es un ejemplo.

    Captura de pantalla de una regla de seguridad de salida de ejemplo.

    Repita este proceso con reglas de entrada, ajustando el nombre y la descripción según corresponda. Observará que, en la pestaña Reglas de seguridad de entrada, hay un inicio de sesión de advertencia en la regla, como se muestra aquí.

    Captura de pantalla de reglas de seguridad de entrada de ejemplo.

    Si hace clic en la regla y se desplaza hasta la parte inferior, verá más detalles, como se muestra aquí.

    Captura de pantalla de detalles de la regla de ejemplo.

    Este mensaje comunica las dos advertencias siguientes:

    • Azure Load Balancers no podrá acceder a los recursos mediante este grupo de seguridad de red de manera predeterminada.
    • De manera predeterminada, otros recursos de esta red virtual no podrán acceder a los recursos mediante este grupo de seguridad de red.

    Para nuestro propósito en Confianza cero, así es como debe ser. Esto significa que, solo porque algo está en esta red virtual, no significa que tenga acceso inmediato a los recursos. Para cada patrón de tráfico, tendrá que crear una regla explícitamente que se lo permita y debe hacerlo con la menor cantidad de permisos. Por lo tanto, si tiene conexiones salientes específicas para la administración, como controladores de dominio Active Directory Domain Services (AD DS), máquinas virtuales de DNS privadas o sitios web externos específicos, deben controlarse aquí.

    Reglas de denegación alternativas

    Si usa Azure Firewall para administrar las conexiones salientes, en lugar de realizar una denegación de salida, puede dejar abierta toda la salida saliente. Como parte de la implementación de Azure Firewall, configurará una tabla de rutas que envía el tráfico de ruta predeterminado (0.0.0.0/0) al servidor de seguridad, que gestiona el tráfico fuera de la red virtual.

    Después, puede crear una denegación de todas las redes virtuales salientes o, en su lugar, permitir todos los elementos salientes (pero proteger los elementos con sus reglas de entrada).

    Obtenga más información sobre Azure Firewall y tablas de rutas para comprender cómo puede usarlas para aumentar aún más la seguridad del entorno.

    Reglas de administración de máquinas virtuales

    Para configurar máquinas virtuales con el inicio de sesión de Microsoft Entra, Anti-Malware y actualizaciones automáticas habilitadas, deberá permitir las siguientes conexiones salientes. Muchos de estos son los FQDN, lo que significa que Azure Firewall es necesario para las reglas de FQDN o creará un plan más complejo. Se recomienda Azure Firewall.

    Las conexiones salientes son:

    • En el puerto 443:
      • enterpriseregistration.windows.net
      • settings-win.data.microsoft.com
      • sls.update.microsoft.com
      • v10.events.data.microsoft.com
      • login.microsoftonline.com
      • pas.windows.net
      • 169.254.169.254
    • En el puerto 80:
    • En el puerto 123:
      • 40.119.6.228
    • En el puerto 1688:
      • 40.83.235.53

    Implementación de reglas específicas de la aplicación para grupos de seguridad de aplicaciones

    Defina patrones de tráfico con la menor cantidad de permisos y solo siga las rutas de acceso permitidas explícitamente. Este es un diagrama de ejemplo del uso de grupos de seguridad de aplicaciones para definir patrones de tráfico de red en los grupos de seguridad de red para una red virtual de radio que se usa junto con una red virtual de centro. Esta es la configuración recomendada.

    Configuración recomendada de patrones de red para una aplicación web de tres niveles en una configuración en estrella tipo centro y radio.

    Como otro ejemplo, esta es una configuración para una red virtual de radio independiente en la que el Web Application Firewall se coloca en la subred de Application Gateway de la red virtual de radio.

    Configuración recomendada de patrones de red para una aplicación web de tres niveles en una configuración de radio independiente.

    Necesita las siguientes reglas de grupo de seguridad de red:

    1. Permitir el tráfico de Internet a la subred APP GW (HTTPS 443).
    2. Permitir el tráfico desde la subred de APP GW a las máquinas virtuales de nivel de front-end (HTTPS 433).
    3. Permitir el tráfico de las máquinas virtuales de nivel de front-end al equilibrador de carga del nivel de aplicación (HTTPS 443).
    4. Permitir el tráfico desde el equilibrador de carga del nivel de aplicación a las máquinas virtuales del nivel de aplicación (HTTPS 443).
    5. Permitir el tráfico de las máquinas virtuales de capa de aplicación al equilibrador de carga del nivel de datos (SQL 1433).
    6. Permitir el tráfico desde el equilibrador de carga del nivel de datos a las máquinas virtuales de capa de datos (SQL 1433).
    7. Permitir el tráfico entre máquinas virtuales de capa de datos (SQL 1433)

    Configure primero el patrón SQL y, a continuación, repita el proceso con los niveles restantes. Las secciones siguientes son las configuraciones de las reglas que limitan el tráfico de red para un único nivel de aplicación.

    Regla 5: Permitir el tráfico de máquinas virtuales de capa de aplicación al equilibrador de carga de capa de datos (SQL 1433)

    En el grupo de seguridad de red de la subred de nivel de aplicación, vaya a Reglas de seguridad de entrada y seleccione Agregar. Rellene la lista con lo siguiente:

    • Origen: grupo de seguridad de aplicaciones
    • Grupos de seguridad de aplicaciones de origen: seleccione el grupo de seguridad de aplicaciones de nivel empresarial.
    • Intervalos de puertos de origen: 1433 (A veces el tráfico de origen puede provenir de puertos diferentes y, si se produce este patrón, puede agregar intervalos de puertos de origen a * para permitir cualquier puerto de origen. El puerto de destino es más significativo y algunas recomendaciones son usar siempre * para el puerto de origen)
    • Destino: Direcciones IP
    • Direcciones IP de destino/intervalos CIDR: la dirección IP explícita del equilibrador de carga
      • Debe utilizar la dirección IP explícita aquí porque no puede asociar un equilibrador de carga a un grupo de seguridad de aplicaciones.
      • Puede planear el esquema IP o implementar el equilibrador de carga y hacer referencia a la dirección IP asignada.
    • Servicio: MS SQL
    • Intervalos de puertos de destino: se rellena automáticamente para el puerto 1433.
    • Protocolo: se selecciona automáticamente para TCP.
    • Acción: Permitir
    • Prioridad: un valor entre 100 y 4096. Puede empezar con 105.
    • Nombre: Allow-App-Tier-to-Data-LB-Inbound
    • Descripción: permite el acceso entrante desde el equilibrador de carga de capa de datos a las máquinas virtuales de capa de aplicación.

    Después de la finalización, observará que hay un icono azul para las alertas informativas en la regla. Al hacer clic en la regla, se proporciona el siguiente mensaje:

    • “Las reglas que usan grupos de seguridad de aplicaciones solo se pueden aplicar cuando los grupos de seguridad de aplicaciones están asociados a interfaces de red en la misma red virtual”.

    Este es un ejemplo.

    Captura de pantalla de una alerta informativa de ejemplo.

    La regla solo se aplica cuando se usa este grupo de seguridad de aplicaciones en esta red.

    Por último, en el mismo grupo de seguridad de red, vaya a Reglas de seguridad de salida y seleccione Agregar. Rellene la lista similar al ejemplo, cambiando Entrante a Saliente.

    Regla 6: Permitir el tráfico del equilibrador de carga de capa de datos a máquinas virtuales de capa de datos (SQL 1433)

    En el grupo de seguridad de red de la subred de nivel de datos, vaya a Reglas de seguridad de entrada y seleccione Agregar. Rellene la lista con lo siguiente:

    • Origen: Dirección IP
    • Dirección IP de origen: la dirección IP del equilibrador de carga
    • Intervalos de puertos de origen: 1433
    • Destino: Grupo de seguridad de aplicación
    • Grupos de seguridad de aplicaciones de destino: seleccione el grupo de seguridad de aplicaciones de capa de datos.
    • Servicio: MS SQL
    • Intervalos de puertos de destino: se rellena automáticamente para el puerto 1433.
    • Protocolo: se selecciona automáticamente para TCP.
    • Acción: Permitir
    • Prioridad: un valor entre 100 y 4096. Puede empezar con 105.
    • Nombre: Allow-SQL-LB-to-SQL-VMs-Inbound
    • Descripción: permite el acceso entrante a las máquinas virtuales de capa de datos basadas en SQL desde el equilibrador de carga del nivel de datos.

    En el mismo grupo de seguridad de red, vaya a Reglas de seguridad de salida y seleccione Agregar. Rellene la lista como se ha hecho en el ejemplo, cambiando Entrante a Saliente.

    Regla 7: Permitir el tráfico entre máquinas virtuales de nivel de datos (SQL 1433)

    En el grupo de seguridad de red de la subred de nivel de datos, vaya a Reglas de seguridad de entrada y seleccione Agregar. Rellene la lista con lo siguiente:

    • Origen: grupo de seguridad de aplicaciones
    • Grupos de seguridad de aplicaciones de destino: seleccione el grupo de seguridad de aplicaciones de capa de datos.
    • Intervalos de puertos de origen: 1433
    • Destino: Grupos de seguridad de aplicaciones
    • Grupos de seguridad de aplicaciones de destino: seleccione el grupo de seguridad de aplicaciones de capa de datos.
    • Servicio: MS SQL
    • Intervalos de puertos de destino: se rellena automáticamente para el puerto 1433.
    • Protocolo: se selecciona automáticamente para TCP.
    • Acción: Permitir
    • Prioridad: un valor entre 100 y 4096. Puede empezar con 105.
    • Nombre: Allow-SQL-VM-to-SQL-VM-Inbound
    • Descripción: permite el acceso entrante entre máquinas virtuales de capa de datos basadas en SQL.

    En el mismo grupo de seguridad de red, vaya a Reglas de seguridad de salida y seleccione Agregar. Rellene la lista como la lista anterior y cambie Entrante a Saliente.

    Con estas tres reglas, ha definido el patrón de conectividad de Confianza cero para una única capa de aplicación. Puede repetir este proceso cuando haga falta con otros flujos.

    Planificación para el tráfico de administración en la red virtual

    Además del tráfico específico de la aplicación, debe planear el tráfico de administración. Sin embargo, el tráfico de administración generalmente se origina fuera de la red virtual de radio. Se requieren reglas adicionales. En primer lugar, deberá ser consciente de qué puertos y orígenes específicos de los que provendrá el tráfico de administración. Generalmente, todo el tráfico de administración debe fluir desde un servidor de seguridad u otra NVA ubicado en la red de centro para el radio.

    Para obtener una visión completa de la arquitectura de referencia, consulte el artículo Introducción a la aplicación de principios de Confianza cero a IaaS de Azure.

    Esto varía en función de sus necesidades de administración específicas. Sin embargo, las reglas en dispositivos de servidor de seguridad y reglas en el grupo de seguridad de red deben usarse para permitir explícitamente en las conexiones en las redes de la plataforma y en las redes de cargas de trabajo.

    Implementación de los registros de flujo de grupo de seguridad de red

    Incluso si el grupo de seguridad de red está bloqueando el tráfico innecesario no significa que se cumplan los objetivos. Todavía tiene que observar el tráfico que se produce fuera de los patrones explícitos, de modo que sepa si se está produciendo un ataque.

    Para habilitar el registro de flujo del grupo de seguridad de red, siga el Tutorial: Registro del flujo de tráfico de red hacia y desde una máquina virtual para el grupo de seguridad de red existente que se crea.

    Nota:

    • La cuenta de almacenamiento debe seguir las guía sobre la cuenta de almacenamiento de Confianza cero.
    • El acceso a los registros debe restringirse según sea necesario.
    • También deben fluir a los análisis de registros y Sentinel según sea necesario.

    Paso 6: Acceso seguro a la red virtual y a la aplicación

    La protección del acceso a la red virtual y la aplicación incluye:

    • Protección del tráfico dentro del entorno de Azure a la aplicación.
    • Utilización de la autenticación multifactor y las directivas de acceso condicional para que los usuarios accedan a la aplicación.

    En el diagrama siguiente se muestran ambos modos de acceso en la arquitectura de referencia.

    La arquitectura de referencia que muestra las formas en que se protege el acceso en una red virtual radial.

    Protección del tráfico dentro del entorno de Azure para la red virtual y la aplicación

    Gran parte del trabajo del tráfico de seguridad dentro del entorno de Azure ya está completo. Las conexiones seguras entre los recursos de almacenamiento y las máquinas virtuales se configuran en Aplicación de principios de Confianza cero a Azure Storage.

    Para proteger el acceso desde los recursos de centro a la red virtual, consulte Aplicación de principios de Confianza cero a una red virtual de centro en Azure.

    Uso de la autenticación multifactor y las directivas de acceso condicional para el acceso de usuario a la aplicación

    El artículo Aplicación de principios de Confianza cero a las máquinas virtuales recomienda cómo proteger las solicitudes de acceso directamente a las máquinas virtuales con la autenticación multifactor y acceso condicional. Estas solicitudes son más probables de los administradores y desarrolladores. El siguiente paso es proteger el acceso a la aplicación con autenticación multifactor y acceso condicional. Esto se aplica a todos los usuarios que acceden a la aplicación.

    En primer lugar, si la aplicación aún no está integrada con Microsoft Entra ID, consulte Tipos de aplicación para la Plataforma de identidad de Microsoft.

    A continuación, agregue la aplicación al ámbito de las directivas de acceso de identidad y dispositivo.

    Al configurar la autenticación multifactor con el acceso condicional y las directivas relacionadas, use el conjunto de directivas recomendado para Confianza cero como guía. Esto incluye directivas como “punto de partida” que no requieren la administración de dispositivos. Idealmente, los dispositivos que acceden a las máquinas virtuales se administran y puede implementar las directivas empresariales, cosa que se recomienda para Confianza cero. Para obtener más información, consulte Confianza cero directivas habituales de identidad y de acceso a dispositivos.

    En el diagrama siguiente se muestran las directivas recomendadas para Confianza cero.

    Directivas de acceso a dispositivos e identidades de Confianza cero para tres niveles de protección: Punto inicial, Enterprise y Seguridad especializada.

    Paso 7: Habilitación de la protección y detección avanzada de amenazas

    La red virtual de radio basada en Azure ya puede estar protegida por Microsoft Defender for Cloud (MDC), ya que otros recursos del entorno empresarial de TI que se ejecuta en Azure o en el entorno local también se pueden proteger.

    Como se mencionó en los otros artículos de esta serie, Microsoft Defender for Cloud es una herramienta de administración de la posición de seguridad en la nube (CSPM) y protección de cargas de trabajo en la nube (CWP) que ofrece recomendaciones de seguridad, alertas y funciones avanzadas, como la protección de red adaptable para ayudarle a medida que progresa en el recorrido de seguridad en la nube. Para visualizar mejor dónde encaja Defender for Cloud en el mayor panorama de seguridad de Microsoft, consulte Arquitecturas de referencia de ciberseguridad de Microsoft.

    En este artículo no se describe Microsoft Defender for Cloud en detalle, pero es importante comprender que Microsoft Defender for Cloud funciona según las directivas de Azure y los registros ingeridos en un área de trabajo de Log Analytics. Una vez habilitada en la suscripción (o suscripciones) con la red virtual de radio y los recursos asociados, podrá ver recomendaciones para mejorar su posición de seguridad. Puede filtrar aún más las Recomendaciones gracias a la táctica de MITRE, grupo de recursos, etc. Considere la posibilidad de priorizar la resolución de Recomendaciones que tienen un mayor impacto en la puntuación de seguridad de su organización.

    Este es un ejemplo en el portal de Microsoft Defender for Cloud.

    Captura de pantalla del ejemplo de recomendaciones de Microsoft Defender for Cloud.

    Si decide incorporar uno de los planes de Defender for Cloud que ofrecen Protección avanzada de cargas de trabajo, incluye Recomendaciones de protección de red adaptable para mejorar las reglas existentes del grupo de seguridad de red. Este es un ejemplo.

    Captura de pantalla de recomendaciones de protección de red de ejemplo.

    Puede aceptar la recomendación seleccionando Aplicar, que crea una nueva regla de grupo de seguridad de red o modifica una existente.

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

    Pasos siguientes

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

    Ilustraciones técnicas

    Este póster de una página proporciona una vista de un solo vistazo de los componentes de IaaS de Azure como referencia y arquitecturas lógicas, junto con los pasos para asegurarse de que estos componentes tienen los principios “nunca confiar, siempre verificar” del modelo de Confianza cero aplicados.

    Elemento Descripción
    Ilustración en miniatura del póster Aplicar la Confianza cero a la infraestructura de IaaS de Azure.
    PDF | Visio
    Actualizado en marzo de 2024
    Utilice esta ilustración junto con este artículo: Introducción a la aplicación de principios de Confianza cero a IaaS de Azure

    Guías de soluciones relacionadas

    Este póster muestra las arquitecturas lógicas y de referencia, y las configuraciones detalladas de los componentes independientes de Confianza cero para IaaS de Azure. Utilice las páginas de este póster para departamentos independientes o especialidades de TI o, con la versión de Microsoft Visio del archivo, personalice los diagramas de la infraestructura.

    Elemento Descripción
    Ilustración en miniatura del póster Diagramas para aplicar la Confianza cero a la infraestructura de IaaS de Azure.
    PDF | Visio
    Actualizado en marzo de 2024
    Use estos diagramas junto con los artículos que comienzan aquí: Introducción a la aplicación de principios de Confianza cero a IaaS de Azure

    Guías de soluciones relacionadas

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

    Referencias