Aplicación de principios de Confianza cero a una red virtual de radio con los servicios PaaS de Azure

  • Artículo

Este artículo le ayuda a aplicar los principios del modelo de seguridad de Confianza cero a una carga de trabajo de PaaS mediante redes virtuales de Azure (VNet) y puntos de conexión privados de las maneras siguientes:

Principio de Confianza cero Definición Forma de cumplimiento
Comprobación explícita Autentique y autorice siempre en función de todos los puntos de datos disponibles. Utilice la detección de amenazas en Azure Firewall y Azure Application Gateway para validar el tráfico y comprobar si el tráfico es aceptable.
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. Reduzca la entrada y salida de los servicios de Azure a las redes privadas. Utilice grupos de seguridad de red para permitir solo la entrada específica de la red virtual. Utilice una instancia central de Azure Firewall para conceder acceso al tráfico que no es de red virtual al servicio de Azure.
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 está registrando desde grupos de seguridad de red y que tiene una visibilidad adecuada del tráfico anómalo. Realice un seguimiento de los cambios realizados en los grupos de seguridad de red.

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

Red independiente o de radio de Confianza cero para los servicios PaaS de Azure

Muchos servicios PaaS contienen su propia funcionalidad de control de entrada y salida nativa del servicio. Puede utilizar estos controles para proteger el acceso de red a los recursos del servicio PaaS sin necesidad de infraestructura como redes virtuales. Por ejemplo:

  • La base de datos de Azure SQL tiene su propio firewall que se puede usar para permitir direcciones IP de cliente específicas que necesitan acceder al servidor de bases de datos.
  • Las cuentas de almacenamiento de Azure tienen una opción de configuración que permite conexiones desde una red virtual específica o bloquear el acceso a la red pública.
  • Azure App Service es compatible con las restricciones de acceso para definir una lista ordenada por prioridad de elementos permitidos o denegados con la que se controla el acceso de red a la aplicación.

Sin embargo, para implementaciones guiadas de Confianza cero, estos controles de acceso nativos del servicio a menudo no son suficientes. Esto crea una difusión de los controles de acceso y el registro que pueden aumentar la administración y disminuir la visibilidad.

Además, los servicios PaaS pueden usar nombres de dominio completos (FQDN) que se resuelven en una dirección IP pública asignada dinámicamente desde un grupo de direcciones IP públicas en una región específica para un tipo de servicio. Debido a esto, no podrá permitir el tráfico desde o a un servicio PaaS específico mediante su dirección IP pública, lo que puede cambiar.

Microsft recomienda que use un punto de conexión privado. Un punto de conexión privado es una interfaz de red virtual que usa una dirección IP privada de la red virtual. Esta interfaz de red le conecta de forma privada y segura a un servicio con la tecnología de Azure Private Link. AL habilitar un punto de conexión privado, incorpore el servicio a la red virtual.

En función del escenario de la solución, es posible que todavía necesite acceso de entrada público a los servicios PaaS. Pero a menos que lo haga, Microsoft recomienda que todo el tráfico permanezca privado para eliminar posibles riesgos de seguridad.

En esta guía se proporcionan instrucciones para una arquitectura de referencia específica, pero los principios y métodos se pueden aplicar a otras arquitecturas según sea necesario.

Arquitectura de referencia

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

Diagrama de la arquitectura de referencia para cargas de trabajo basadas en PaaS.

En el diagrama:

  • Una red virtual de radio incluye componentes para admitir una aplicación PaaS.
  • La aplicación PaaS es una aplicación de dos niveles que aprovecha los servicios de Aplicación de Azure para una aplicación web o front-end y una instancia de base de datos de Azure SQL para bases de datos relacionales.
  • Cada nivel está incluido en una subred dedicada para la entrada con un grupo de seguridad de red dedicado.
  • El nivel web contiene una subred dedicada para la salida.
  • El acceso a la aplicación se proporciona a través de una instancia de Application Gateway contenida en su propia subred.

En el diagrama siguiente se muestra la arquitectura lógica de estos componentes dentro de una suscripción de Azure.

Diagrama de componentes dentro de una suscripción de Azure.

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 (denominados como “NSG” en el diagrama) para la base de datos, la aplicación y los niveles de front-end
  • Dos grupos de seguridad de aplicaciones (denominados como “ASG” en el diagrama)
  • Dos puntos de conexión privados

Además, los recursos de la red virtual del centro se implementan en la suscripción de conectividad adecuada.

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
1 Sacar provecho de RBAC de Microsoft Entra o configurar roles personalizados para los recursos de red.
2 Aislar la infraestructura en su propio grupo de recursos.
3 Creación de un grupo de seguridad de red para cada subred.
4 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.
  • 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.
5 Protección de la entrada y salida para los servicios PaaS de Azure.
6 Acceso seguro a la red virtual y a la aplicación.
7 Habilitación de la detección avanzada de amenazas, las alertas y la protección.

En esta guía se da por supuesto que ya tiene un Servicio de aplicación de Azure y base de datos de Azure SQL implementados en sus propios grupos de recursos.

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

Puede sacar provecho de los roles integrados de RBAC de Microsoft Entra para los colaboradores de red. Sin embargo, otro enfoque consiste en aprovechar los 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. Un rol personalizado se puede usar para definir el ámbito del acceso 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 que se puede usar 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

Este rol se puede crear mediante los comandos del repositorio de GitHub arquitectura de referencia de zona de aterrizaje de Azure o se puede crear a través de Microsoft Entra ID con roles personalizados 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 de un grupo de recursos compartido, cree un grupo de recursos dedicado. En el siguiente diagrama de arquitectura se muestra esta configuración.

Diagrama de aislamiento de la infraestructura en su propio grupo de recursos.

En el diagrama, los recursos y los componentes de la arquitectura de referencia se dividen en grupos de recursos dedicados para servicios de aplicaciones, bases de datos de Azure SQL, 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 tutorial Concesión de acceso de usuario a los recursos de Azure mediante Azure Portal.

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 las prácticas 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 para el grupo de recursos:

  1. Vaya al grupo de recursos en Azure Portal.
  2. Vaya a Registro de actividad:> Exportar registros de actividad y, a continuación, seleccione + Agregar configuración de diagnóstico.
  3. 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. Este es un ejemplo:

Ejemplo de la configuración diagnóstico.

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

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.

Consulte los principios de diseño de la zona de aterrizaje de Azure para más información.

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. Esto se aplica a través de la Azure Policy de manera 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. Para cada regla, puede especificar direcciones IP de origen y destino, un protocolo (como TCP o UDP) y un puerto.

En el caso de las aplicaciones de niveles múltiples, la recomendación es crear un grupo de seguridad de red dedicado (“NSG” en el diagrama siguiente) para cada subred que hospeda un componente de red.

Diagrama de grupos de seguridad de red dedicados para cada subred.

En el diagrama:

  • Cada nivel de la aplicación tiene una subred de entrada dedicada, como una para el nivel web y otra para el nivel de datos.
  • Los servicios de aplicación de Azure tiene una subred de salida dedicada para un servicio de aplicación específico.
  • 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 a la del diagrama 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.

Consulte Crear, modificar o eliminar un grupo de seguridad de red de Azure para administrar la configuración de los grupos de seguridad de red.

Obtenga más información sobre los grupos de seguridad de red para comprender cómo se pueden usar para proteger los entornos.

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

En esta sección se describen 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
  • 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 de tipo permitir. 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.

Para ello, 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.

Ejemplo de reglas de seguridad de salida.

Repita este proceso con reglas de entrada, ajustando el nombre y la descripción según corresponda.

La pestaña Reglas de seguridad de entrada muestra el inicio de sesión de advertencia en la regla. Este es un ejemplo.

Ejemplo de reglas de seguridad de entrada.

Haga clic en la regla y desplácese hasta la parte inferior para ver más detalles. Este es un ejemplo:

Ejemplo de detalles de regla.

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 tendrá acceso inmediato a los recursos. Para cada patrón de tráfico, cree una regla explícitamente que se lo permita y debe hacerlo con la menor cantidad de permisos.

Si tiene conexiones salientes específicas para la administración, como controladores de dominio de Active Directory Domain Services (AD DS), máquinas virtuales DNS privadas o sitios web externos específicos, deben controlarse aquí.

Reglas de denegación alternativas

Nota:

Las recomendaciones de esta sección solo se aplican a la subred de salida web.

Si usa Azure Firewall para administrar las conexiones salientes, en lugar de realizar una denegación de salida, puede crear reglas alternativas para las conexiones salientes. 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. Esto controlará el tráfico fuera de la red virtual.

Después, puede crear una regla de denegación de todas las redes virtuales o permitir todas las reglas de salida, pero proteger los elementos con sus reglas de entrada.

Consulte Azure Firewall y tablas de enrutamiento para comprender cómo se pueden usar para aumentar aún más la seguridad del entorno.

Implementación de reglas específicas de la aplicación

Defina patrones de tráfico con la menor cantidad de permisos y solo siga las rutas de acceso permitidas explícitamente. Al utilizar subredes como orígenes, defina patrones de red en los grupos de seguridad de red. Este es un ejemplo.

Diagrama de patrones de red en grupos de seguridad de red.

Use el proceso de Administrar grupos de seguridad de red: cree un proceso de regla de seguridad para agregar reglas a los grupos de seguridad de red.

Para proteger este escenario, agregue las siguientes reglas:

Grupo de seguridad de red para subred Dirección Source Detalles del origen Puerto de origen Destino Detalles del destino Service Nombre del grupo de seguridad de red Descripción del grupo de seguridad de red
Subred de App Service Entrada Direcciones IP Intervalo de direcciones IP privadas de la subred de Application Gateway 443 Direcciones IP La dirección IP explícita de su punto de conexión privado de App Service MS SQL AllowGWtoAppInbound Permite el acceso entrante a App Service desde Application Gateway.
Subred de integración de App Services Salida Direcciones IP Intervalo de direcciones IP de la subred de integración de App Service 1433 Direcciones IP La dirección IP explícita de su punto de conexión privado de la base de datos SQL MS SQL AllowApptoSQLDBOutbound Permite el acceso saliente al punto de conexión privado de SQL desde la subred de integración de App Service.
Subred de Azure SQL Entrada Direcciones IP Intervalo de direcciones IP de la subred de integración de App Service 1433 Direcciones IP La dirección IP explícita de su punto de conexión privado de la base de datos SQL MS SQL AllowApptoSQLDBInbound Permite el acceso entrante al punto de conexión privado de SQL desde la subred de integración de App Service.

Nota:

A veces, el tráfico de origen puede provenir de puertos diferentes y, si este patrón se produce, 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 siempre deben usar “*” para el puerto de origen.

Nota:

Para prioridad, utilice un valor entre 100 y 4000. Puede empezar en 105.

Esto se suma a las reglas del grupo de seguridad de red en la subred de Application Gateway.

Con estas 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, planee el tráfico de administración. Sin embargo, dado que el tráfico de administración se origina normalmente fuera de la red virtual de radio, se requieren más reglas. En primer lugar, sea consciente de qué puertos y orígenes específicos de los que provendrá el tráfico de administración. Normalmente, todo el tráfico de administración debe fluir desde un servidor de seguridad u otra aplicación virtual de red (NVA) ubicado en la red de centro para el radio.

Consulte Introducción a la aplicación de principios de Confianza cero a IaaS de Azure para obtener una visión completa de la arquitectura de referencia.

La configuración variará en función de sus necesidades de administración específicas. Sin embargo, debe usar reglas en dispositivos de servidor de seguridad y reglas en el grupo de seguridad de red para permitir explícitamente las conexiones en las redes de la plataforma y las redes de cargas de trabajo.

Planeamiento de implementaciones

Dado que los servicios de aplicación y las bases de datos ahora usan redes privadas, planee cómo funcionan las implementaciones de código y datos en estos recursos. Agregue reglas para permitir que los servidores de compilación privados accedan a estos puntos de conexión.

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. Para detectar un ataque, debe observar el tráfico que se está produciendo fuera de los patrones explícitos.

El tráfico a los puntos de conexión privados no se registra, pero si otros servicios se implementan en las subredes más adelante, este registro le ayudará a detectar las actividades.

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 para los puntos de conexión privados.

Nota:

Tenga en cuenta estas recomendaciones:

  • Debe restringir el acceso a los registros según sea necesario.

  • Los registros deben fluir hacia Log Analytics y Microsoft Sentinel según sea necesario.

Paso 5: Protección de la entrada y salida para los servicios PaaS de Azure

Esta sección contiene dos pasos necesarios para proteger la entrada y salida de los servicios PaaS:

  • Implementar puntos de conexión privados para la entrada a los servicios.
  • Implementar la integración con red virtual para permitir que el servicio de aplicaciones hable con la red virtual.

Además, también debe tener en cuenta la configuración de DNS para permitir la resolución de nombres.

Implementar puntos de conexión privados para entrada

Aunque muchos servicios permiten crear puntos de conexión privados a partir de la hoja específica del recurso en Azure Portal, una experiencia más coherente consiste en crear un punto de conexión privado a partir de su propia creación de recursos. Para ello, los recursos ya deberían implementarse. Una vez implementado, puede crear el punto de conexión privado.

Al implementar los puntos de conexión privados, configúrelos de la siguiente manera:

  • Colóquelos en el grupo de recursos específico que aloja los recursos primarios para mantener juntos los recursos con un ciclo de vida similar y proporcionar acceso central.
  • Colóquelos en la subred adecuada en la red virtual en función de su rol.
  • Para el servicio de aplicación de Azure, puede configurar puntos de conexión privados tanto para su front-end normal como para su punto de conexión SCM, que se usa para implementaciones y administración.

Además, como parte de esta implementación, debe asegurarse de que el servidor de seguridad específico del servicio esté establecido en denegar el tráfico entrante. Esto denegará los intentos de entrada pública.

Para la base de datos de Azure SQL, administre las reglas de firewall de IP de nivel de servidor. Asegúrese de que el acceso a la red pública esté establecido en Deshabilitar desde el panel de redes de Azure Portal.

Para el servicio de aplicación de Azure, al agregar el punto de conexión privado se establece su servidor de seguridad de nivel de servicio para bloquear el acceso entrante de manera predeterminada. Para obtener más información, consulte Uso de puntos de conexión privados para las aplicaciones de App Service.

Implementación de la integración con red virtual para la salida

Además de los puntos de conexión privados para la entrada, habilite la integración con red virtual. Cada plan de App Service puede tener habilitada la integración con red virtual y hacerlo asigna una subred completa para App Service. Para más información, consulte Integración de una aplicación con una red virtual de Azure.

Para configurar App Service, consulte Habilitación de la integración con red virtual en Azure App Service. Asegúrese de colocarlo en la subred designada para la salida.

Consideraciones DNS

Como parte de la utilización de puntos de conexión privados, habilite la resolución DNS de los FQDN de los recursos en sus nuevas direcciones IP privadas. Para obtener instrucciones para implementar esto de varias maneras, consulte Configuración de DNS del punto de conexión privado.

Nota:

La resolución DNS debe aplicarse a todo el tráfico. Los recursos de la misma red virtual no podrán resolverse a menos que usen las zonas DNS correctas.

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

La protección del acceso a la red virtual y las aplicaciones incluyen:

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

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

Diagrama de modos de acceso en la arquitectura de referencia.

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. Consulte Aplicación de principios de Confianza cero a Azure Storage para configurar conexiones seguras entre los recursos de almacenamiento y las máquinas virtuales.

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

Utilización de la MFA y las directivas de acceso condicional para que los usuarios accedan a las aplicaciones

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 MFA y acceso condicional. Estas solicitudes son más probables de los administradores y desarrolladores. El siguiente paso es proteger el acceso a las aplicaciones con MFA 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 MFA 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 pueden implementar el nivel empresarial, 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.

Diagrama de directivas de acceso a dispositivos e identidad recomendadas para Confianza cero.

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

La red virtual de radio basada en Azure puede estar protegida por Microsoft Defender for Cloud, 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, 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.

En este artículo no se describe Defender for Cloud en detalle, pero es importante comprender que Defender for Cloud funciona según las directivas de Azure y los registros ingeridos en un área de trabajo de Log Analytics. Una vez habilitadas en las suscripciones con la red virtual de radio y los recursos asociados, puede ver recomendaciones para mejorar su posición de seguridad. Puede filtrar estas recomendaciones aún más por la táctica de MITRE, el grupo de recursos y otros. Considere la posibilidad de priorizar para resolver recomendaciones que tengan un mayor impacto en la puntuación de seguridad de su organización. Este es un ejemplo.

Ejemplo de recomendaciones de Microsoft Defender for Cloud.

Hay planes de Defender for Cloud que ofrecen protecciones avanzadas para cargas de trabajo que incluyen recomendaciones de protección de red adaptables para mejorar las reglas existentes del grupo de seguridad de red. Este es un ejemplo.

Ejemplo de recomendaciones de protección de red.

Para aceptar la recomendación, seleccione Aplicar, que creará una nueva regla de grupo de seguridad de red o modificará una existente.

Pasos siguientes

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

Referencias