Editar

Consideraciones relativas a la seguridad para aplicaciones IaaS altamente confidenciales en Azure

Azure Disk Encryption
Azure Firewall
Azure Key Vault
Microsoft Defender for Cloud
Azure Virtual Network

Hay muchas consideraciones de seguridad para implementar aplicaciones de infraestructura como servicio (IaaS) en Azure. Este artículo parte de las arquitecturas de referencia de las cargas de trabajo basadas en máquinas virtuales y las infraestructuras de red híbridas para centrarse en la seguridad de cargas de trabajo de IaaS altamente confidenciales en Azure, basadas a su vez en aspectos básicos de seguridad de Azure.

Vea también Información general de seguridad de Azure Virtual Machines y Procedimientos de seguridad recomendados para cargas de trabajo de IaaS de Azure.

Máquinas virtuales de Azure

La plataforma de proceso de Azure se basa en la virtualización de las máquinas. Un hipervisor se ejecuta en el hardware físico de cada nodo o punto de conexión de red de Azure, y crea un número variable de máquinas virtuales de Hyper-V (VM) de invitado en el nodo. Todo el código de usuario se ejecuta en las máquinas virtuales. Para obtener instrucciones básicas sobre la implementación de máquinas virtuales de Azure, vea Ejecución de una máquina virtual Linux en Azure o Ejecución de una máquina virtual Windows en Azure. La mayoría de los procesos de implementación son los mismos para los dos sistemas operativos, pero las herramientas específicas del sistema operativo, como el cifrado de discos, pueden diferir.

Puede usar Microsoft Defender for Cloud para la administración de revisiones de máquinas virtuales, así como para implementar y supervisar herramientas antimalware. Como alternativa, puede administrar sus propias herramientas de revisión y antimalware, o de terceros, lo cual es común al extender o migrar las infraestructuras existentes a Azure.

Microsoft proporciona protección básica de denegación de servicio distribuido (DDoS) como parte de la plataforma Azure. Las aplicaciones que tienen puntos de conexión públicos pueden usar Azure DDoS Protection Estándar para obtener protección adicional. Sin embargo, las cargas de trabajo altamente confidenciales no suelen tener puntos de conexión públicos y solo se puede acceder a ellos desde ubicaciones específicas a través de una red privada virtual (VPN) o una línea concedida.

Arquitecturas de n niveles

Muchas aplicaciones de IaaS constan de varios niveles, como un nivel web, un nivel empresarial y un nivel de datos, que se hospedan en varias máquinas virtuales. Entre los aspectos clave de la implementación de arquitecturas de aplicaciones de n niveles en máquinas virtuales de Azure están los siguientes:

  • Alta disponibilidad (HA). Las aplicaciones de alta disponibilidad deben estar disponibles más del 99,9 % del tiempo. La colocación de máquinas virtuales en el nivel en distintas zonas de disponibilidad (AZ) de Azure garantiza la alta disponibilidad, porque las AZ abarcan uno o varios centros de datos, lo que proporciona resistencia ante los errores del centro de datos. Las regiones que no son compatibles con las AZ pueden usar conjuntos de disponibilidad (AS), que distribuyen máquinas virtuales entre varios nodos de hardware aislados.
  • Equilibrio de carga. Los equilibradores de carga distribuyen el tráfico entre las máquinas virtuales para equilibrar la carga y obtener resistencia cuando se produce un error en una máquina virtual. No necesita equilibradores de carga si la aplicación administra el equilibrio de carga y el autor de la llamada conoce las máquinas virtuales individuales.
  • Redes virtuales. Las redes virtuales y las subredes segmentan la red, lo que permite una administración de seguridad y un enrutamiento avanzado más sencillos.
  • Sistema de nombres de dominio (DNS) . Azure DNS proporciona un servicio DNS seguro y de alta disponibilidad. Una zona privada en Azure DNS permite usar dominios personalizados dentro de las redes virtuales.

Copia de seguridad y restauración

Para protegerse contra errores humanos, la eliminación malintencionada de datos y el ransomware, debe realizar una copia de seguridad de al menos las máquinas virtuales de nivel de datos. Azure Backup puede realizar copias de seguridad y restaurar máquinas virtuales cifradas si puede acceder a las claves de cifrado en Azure Key Vault.

En el caso de los niveles web y empresarial, es posible usar reglas de escalado automático de conjunto de escalado de máquinas virtuales para destruir las máquinas virtuales en peligro de forma automática e implementar instancias de máquinas virtuales nuevas a partir de una imagen base.

Aislamiento de proceso

En cada punto de conexión de la red o el nodo de Azure, el hipervisor y un sistema operativo raíz especial garantizan que las máquinas virtuales invitadas no puedan acceder al servidor de host físico, y el código de usuario solo se ejecuta en las máquinas virtuales invitadas. Este aislamiento impide que los usuarios obtengan acceso de lectura, escritura o ejecución sin procesar en el sistema, y reduce el riesgo de compartir recursos. Azure protege frente a todos los ataques de canal lateral y vecinos ruidosos conocidos a través del hipervisor y de un algoritmo avanzado de selección de ubicación de máquinas virtuales. Para obtener más información, vea Aislamiento de proceso.

En el caso de las cargas de trabajo altamente confidenciales, se puede agregar protección adicional frente a ataques de canal lateral con máquinas virtuales aisladas o hosts dedicados.

Máquinas virtuales aisladas

Las máquinas virtuales aisladas son máquinas virtuales de gran tamaño que están aisladas de un tipo de hardware específico y dedicadas a un solo cliente. Usar un tamaño de máquina virtual aislado garantiza que la máquina virtual será la única que se ejecute en una instancia de servidor específica. Puede subdividir aún más los recursos de las máquinas virtuales aisladas mediante el soporte técnico de Azure para máquinas virtuales anidadas.

El tamaño mínimo de una máquina virtual aislada es de 64 núcleos de CPU virtuales y de 256 GiB de memoria. Estas máquinas virtuales son mucho más grandes que lo que requieren la mayoría de aplicaciones de n niveles y pueden crear una gran sobrecarga en los costos. Para reducir tal sobrecarga, puede ejecutar varios niveles de aplicación en una sola máquina virtual con la virtualización anidada, o en diferentes procesos o contenedores. Todavía tiene que implementar máquinas virtuales diferentes en AZ para lograr resistencia y ejecutar dispositivos de red perimetral (DMZ) en máquinas virtuales independientes. La combinación de varias aplicaciones en una infraestructura por motivos económicos también puede entrar en conflicto con las directivas de segregación de aplicaciones organizativas.

A medida que las capacidades de la región de Azure se expandan con el tiempo, Azure también puede quitar garantías de aislamiento de ciertos tamaños de máquina virtual, previo aviso de un año.

Hosts dedicados de Azure

Azure Dedicated Host es la solución de aislamiento de proceso preferida para cargas de trabajo altamente confidenciales. Un host dedicado es un servidor físico dedicado a un cliente para hospedar varias máquinas virtuales. Además de aislar las máquinas virtuales, los hosts dedicados permiten controlar el mantenimiento y la ubicación de la máquina virtual para evitar vecinos ruidosos.

Hosts dedicados

Los hosts dedicados tienen el mismo tamaño mínimo y muchas de las mismas consideraciones de tamaño que las máquinas virtuales aisladas. Sin embargo, un host dedicado puede hospedar máquinas virtuales ubicadas en diferentes redes virtuales para cumplir con las directivas de segregación de aplicaciones. Todavía debería ejecutar máquinas virtuales de DMZ en un host diferente, para evitar cualquier ataque de canal lateral de una máquina virtual en peligro en la DMZ.

Cifrado

El cifrado de datos es un componente importante de la protección de cargas de trabajo. El cifrado codifica la información para que solo los destinatarios autorizados puedan descodificarla mediante una clave o un certificado. El cifrado incluye cifrado de disco para el cifrado en reposo y Seguridad de la capa de transporte (TLS) para el cifrado en tránsito a través de redes.

Azure Key Vault

Se pueden proteger las claves de cifrado y los certificados almacenándolos en Azure Key Vault, una solución de módulo de seguridad de hardware (HSM) en la nube validada para los Estándares federales de procesamiento de información (FIPS) 140-2 de nivel 2. Para ver los procedimientos recomendados con el fin de permitir que solo las aplicaciones y los usuarios autorizados accedan a Key Vault, vea Protección del acceso a un almacén de claves.

Para proteger las claves en Key Vault, puede habilitar la eliminación temporal, lo que garantiza que las claves eliminadas se puedan recuperar. Para obtener protección adicional, puede realizar copias de seguridad de claves individuales en un archivo cifrado que se puede usar para restaurar las claves, potencialmente en otra región de Azure de la misma geografía.

Al hospedar SQL Server en una máquina virtual, se puede usar el Conector de SQL Server para Microsoft Azure Key Vault a fin de obtener claves para el cifrado de datos transparente (TDE) , el cifrado de nivel de columna (CLE) y el de copia de seguridad. Para obtener información detallada, vea Configuración de la integración de Azure Key Vault para SQL Server en Azure Virtual Machines.

Azure Disk Encryption

Azure Disk Encryption usa un protector de claves externas BitLocker para proporcionar cifrado de volumen tanto a los discos de datos como a los del sistema operativo de máquinas virtuales de Azure, y se puede integrar con Azure Key Vault para ayudar a controlar y administrar las claves, así como los secretos del cifrado de disco. Cada máquina virtual genera sus propias claves de cifrado y las almacena en Azure Key Vault. Para configurar Azure Key Vault a fin de habilitar Azure Disk Encryption, vea Creación y configuración de un almacén de claves para Azure Disk Encryption.

En el caso de cargas de trabajo altamente confidenciales, también se debe usar una clave de cifrado de claves (KEK) para obtener un nivel adicional de seguridad. Cuando se especifica una clave de cifrado de claves, Azure Disk Encryption usa esa clave para encapsular los secretos de cifrado antes de escribirlos en Key Vault. Puede generar una clave de cifrado de claves en Azure Key Vault, pero existe un método más seguro que consiste en generar una clave en el HSM local e importarla a Azure Key Vault. Con frecuencia este escenario se conoce también como Aportar tu propia clave, o BYOK. Dado que las claves importadas no pueden abandonar el límite de HSM, la generación de la clave en el HSM garantiza el control total de las claves de cifrado.

Cifrado protegido con HSM

Para obtener más información sobre las claves protegidas con HSM, vea Generación y transferencia de claves protegidas con HSM para Azure Key Vault.

Cifrado de tráfico

Los protocolos de red como HTTPS cifran los datos en tránsito con certificados. El tráfico de cliente a aplicación suele usar un certificado de una entidad de certificación (CA) de confianza. Las aplicaciones internas pueden usar un certificado de una CA interna o de una pública, como DigiCert o GlobalSign. La comunicación de nivel a nivel normalmente utiliza un certificado que emite una CA interna o un certificado autofirmado. Azure Key Vault puede adaptar cualquiera de estos tipos de certificado. Para obtener más información sobre la creación de distintos tipos de certificados, vea Métodos de creación de certificados.

Azure Key Vault puede actuar como una CA de certificado autofirmado para el tráfico de nivel a nivel. La extensión de máquina virtual de Key Vault proporciona supervisión y actualización automática de los certificados especificados en máquinas virtuales, con la clave privada o sin ella, en función del caso de uso. Para usar la extensión de máquina virtual de Key Vault, vea Extensión de máquina virtual de Key Vault para Linux o Extensión de máquina virtual de Key Vault para Windows.

Key Vault también puede almacenar claves para los protocolos de red que no usen certificados. Las cargas de trabajo personalizadas pueden requerir crear el scripting de una extensión de script personalizado que recupere una clave de Key Vault y la almacene para que las usen las aplicaciones. Las aplicaciones también pueden usar la identidad administrada de una máquina virtual para recuperar los secretos directamente de Key Vault.

Seguridad de las redes

Los grupos de seguridad de red (NSG) filtran el tráfico entre los recursos de las redes virtuales de Azure. Las reglas de seguridad de NSG permiten o deniegan el tráfico hacia los recursos de Azure, o desde estos, en función de las direcciones IP y los puertos. De forma predeterminada, los NSG bloquean el tráfico entrante desde Internet, pero permiten las conexiones salientes desde las máquinas virtuales a Internet. Para evitar el tráfico saliente accidental, agregue una regla personalizada con la prioridad más baja posible, 4096, para bloquear todo el tráfico entrante y saliente. Después, puede agregar reglas de prioridad superior para permitir tráfico específico.

Los NSG crean registros de flujo para las conexiones existentes, y permiten o deniegan la comunicación según el estado de conexión del registro de flujo. El registro de flujo permite que un NSG sea de tipo con estado. Por ejemplo, si especifica una regla de seguridad de salida para cualquier dirección a través del puerto 443, no será necesario especificar también una regla de seguridad de entrada para la respuesta. Solo debe especificar una regla de seguridad de entrada si la comunicación se inicia de forma externa.

La mayoría de los servicios de Azure permiten usar una etiqueta de servicio de red virtual en lugar de un NSG. Una etiqueta de servicio representa un grupo de prefijos de dirección IP de un servicio de Azure y permite minimizar la complejidad de las actualizaciones frecuentes de reglas de seguridad de red. Una etiqueta de servicio de Azure Key Vault puede permitir que una máquina virtual recupere certificados, claves y secretos de Azure Key Vault.

Otra manera de controlar la seguridad de la red es a través del enrutamiento de tráfico de redes virtuales y la tunelización forzada. Azure crea automáticamente rutas del sistema y las asigna a todas las subredes de una red virtual. No puede crear ni eliminar rutas del sistema, pero puede reemplazar algunas de ellas por rutas personalizadas. El enrutamiento personalizado permite enrutar el tráfico a través de una aplicación virtual de red (NVA) , como un firewall o un proxy, o eliminar el tráfico no deseado, lo que tiene un efecto similar al del bloqueo del tráfico con un NSG.

Puede usar NVA como Azure Firewall para permitir, bloquear e inspeccionar el tráfico. Azure Firewall es un servicio de firewall de plataforma administrado y de alta disponibilidad. También puede implementar NVA de terceros desde Azure Marketplace. Para hacer que estas NVA sean de alta disponibilidad, vea Implementación de aplicaciones virtuales de red de alta disponibilidad.

Grupos de seguridad de aplicaciones

Para filtrar el tráfico entre capas de aplicación de una red virtual, use los grupos de seguridad de aplicaciones (ASG). Los grupos de seguridad de aplicaciones permiten configurar la seguridad de red como una extensión de la estructura de una aplicación, lo que permite a su vez agrupar máquinas virtuales y definir directivas de seguridad de red basadas en esos grupos. Puede reutilizar la directiva de seguridad a gran escala sin mantenimiento manual de direcciones IP explícitas.

Grupos de seguridad de aplicaciones

Dado que los ASG se aplican a una interfaz de red en lugar de a una subred, habilitan la microsegmentación. Puede controlar estrechamente qué máquinas virtuales pueden comunicarse entre sí, incluso bloquear el tráfico entre las máquinas virtuales del mismo nivel y facilitar la cuarentena de una máquina virtual mediante la eliminación de los ASG de esa máquina virtual.

Redes híbridas

Las arquitecturas híbridas conectan redes locales con nubes públicas como Azure. Hay varias maneras de conectar redes locales a aplicaciones que se ejecutan en Azure:

  • Punto de conexión público a través de Internet. Puede confiar en la identidad, la seguridad de nivel de transporte (HTTPS) y la puerta de enlace de aplicaciones para proteger la aplicación, potencialmente en combinación con un firewall. Sin embargo, para las cargas de trabajo altamente confidenciales, no se recomienda exponer un punto de conexión público a través de Internet.
  • Puerta de enlace de VPN de Azure o de terceros. Se puede conectar una red local a Azure mediante una puerta de enlace de VPN de Azure. El tráfico se transmite a través de Internet, pero por un túnel cifrado que usa TLS. También se puede ejecutar una puerta de enlace de terceros en una máquina virtual, si tiene requisitos específicos que no son compatibles con la puerta de enlace de VPN de Azure.
  • ExpressRoute. Las conexiones de ExpressRoute utilizan una conexión privada y dedicada a través de un proveedor de conectividad de terceros. La conexión privada amplía su red local a Azure y proporciona escalabilidad y un contrato de nivel de servicio (SLA) fiable.
    • ExpressRoute con conmutación por error de VPN. Esta usa ExpressRoute en condiciones normales, pero realiza una conmutación por error en una conexión VPN si se produce una pérdida de conectividad en el circuito de ExpressRoute, proporcionando mayor disponibilidad.
    • VPN a través de ExpressRoute. Esta opción es la más adecuada para cargas de trabajo altamente confidenciales. ExpressRoute proporciona un circuito privado con escalabilidad y fiabilidad, y VPN proporciona una capa adicional de protección que finaliza la conexión cifrada en una red virtual de Azure específica.

Para obtener más instrucciones sobre cómo elegir entre diferentes tipos de conectividad híbrida, vea Elección de una solución para conectar una red local a Azure.

Implementación de una DMZ

La conexión de entornos locales y de Azure proporciona a los usuarios locales acceso a las aplicaciones de Azure. Una subred filtrada o red perimetral (DMZ) proporciona protección adicional para cargas de trabajo altamente confidenciales.

Una arquitectura como la que hay en la red perimetral entre Azure y un centro de datos local implementa todos los servicios de aplicación y de DMZ en la misma red virtual, con reglas de NSG y rutas definidas por el usuario para aislar las subredes de DMZ y de aplicaciones. Esta arquitectura puede hacer que la subred de administración esté disponible a través de la red pública de Internet para administrar las aplicaciones, incluso aunque la puerta de enlace local no esté disponible. Sin embargo, en el caso de cargas de trabajo altamente confidenciales, solo se debe permitir la omisión de la puerta de enlace en un escenario excepcional. Una solución mejor consiste en usar Azure Bastion, que permite el acceso directo desde Azure Portal a la vez que se limita la exposición de las IP públicas.

También se puede usar el acceso a la máquina virtual Just-In-Time (JIT) para la administración remota mientras se limita la exposición de las IP públicas. Con el acceso a la máquina virtual JIT, un NSG bloquea puertos de administración remotos, como el protocolo de escritorio remoto (RDP) y Secure Shell (SSH) de forma predeterminada. Previa solicitud, el acceso a la máquina virtual JIT habilita el puerto solo durante un período de tiempo especificado, y potencialmente para un rango o una dirección IP específicos. El acceso JIT también funciona para las máquinas virtuales que solo tienen direcciones IP privadas. Se puede usar Azure Bastion para bloquear el tráfico a una máquina virtual hasta que se habilite el acceso a la máquina virtual JIT.

Para implementar más aplicaciones, puede usar una topología en estrella tipo hub-and-spoke en Azure, con la red perimetral en la red virtual de centro y las aplicaciones en redes virtuales de radios. La red virtual de centro puede contener una puerta de enlace de VPN o ExpressRoute, firewalls de NVA, hosts de administración, infraestructura de identidades y otros servicios compartidos. Las redes virtuales de radios están conectadas al centro con el emparejamiento de red virtual. Una red virtual de Azure no permite el enrutamiento transitivo a través del centro de un radio a otro. El tráfico de radio a radio solo es posible a través de los dispositivos de firewall en el centro. Esta arquitectura aísla de forma eficaz las aplicaciones entre sí.

Implementación en varias regiones

La continuidad empresarial y la recuperación ante desastres pueden requerir la implementación de la aplicación en varias regiones de Azure, lo que puede afectar a la seguridad y residencia de datos de los datos. Para obtener una arquitectura de referencia para implementaciones en varias regiones, vea Ejecución de una aplicación de n niveles en varias regiones de Azure para lograr alta disponibilidad.

Pares regionales

Una geografía de Azure es un área del mundo definida que contiene al menos una región de Azure, cada una con uno o más centros de datos. Cada región de Azure se empareja con otra región de la misma geografía en un par regional. Los pares regionales no se actualizan al mismo tiempo y, si se produce un desastre en ambas regiones, se le da prioridad a una de las regiones para que vuelva a ponerse en línea en primer lugar. Para lograr la continuidad empresarial, las aplicaciones altamente confidenciales las debe implementar al menos en pares regionales, si realiza la implementación en varias regiones.

Para obtener información detallada, vea Continuidad empresarial y recuperación ante desastres (BCDR): Regiones emparejadas de Azure. En las notas del producto Alcanzar la seguridad y residencia de datos compatibles con Azure se describe la residencia de datos y qué hacer para cumplir con los requisitos de residencia de datos.

Replicación entre regiones

En las arquitecturas de IaaS, la replicación de datos entre regiones es responsabilidad de la aplicación. El escenario de replicación más común usa tecnologías de replicación de base de datos integradas en el producto de servidor de base de datos, como Grupos de disponibilidad Always On de SQL Server, Protección de datos de Oracle o Replicación de MySQL.

La configuración de la replicación entre servidores de bases de datos IaaS no es sencilla y debe tener en cuenta los requisitos de continuidad empresarial. Los servicios de base de datos de Azure, como Azure SQL Database, Azure Database for MySQL y Azure Cosmos DB, facilitan la replicación entre regiones, pero es posible que no cumplan los requisitos de seguridad para cargas de trabajo altamente confidenciales.

Para obtener más información e instrucciones para las implementaciones de SQL Server y Oracle de varias regiones, vea lo siguiente:

Emparejamiento entre varias regiones

Se puede habilitar la comunicación segura entre redes virtuales en regiones distintas mediante el uso del emparejamiento de red virtual global. El emparejamiento global funciona igual que el emparejamiento dentro de la región. El tráfico entre regiones se lleva a cabo a través de la red troncal de Microsoft, no atraviesa Internet y está aislado de otro tráfico. Para obtener más seguridad, puede implementar NVA de VPN en ambas regiones y usar rutas definidas por el usuario para forzar el tráfico entre regiones a través de NVA, de forma similar a implementar una DMZ.

Enrutamiento de tráfico de conmutación por error

Con los puntos de conexión públicos, puede usar Traffic Manager o Azure Front Door para dirigir el tráfico a la región activa o a la región más cercana en una configuración de conmutación por error activa-activa. Sin embargo, Traffic Manager y Azure Front Door requieren puntos de conexión públicos para supervisar la disponibilidad y sus entradas DNS correspondientes son públicas. En el caso de cargas de trabajo altamente confidenciales, la solución alternativa consiste en implementar DNS en el entorno local y cambiar las entradas a la región activa para la conmutación por error.

Administración y gobernanza

La protección de las aplicaciones de IaaS altamente confidenciales requiere algo más que la mera implementación de las arquitecturas correctas y de reglas de seguridad de red. Dado que los entornos de nube se cambian fácilmente, es especialmente importante asegurarse de que los cambios solo se pueden realizar con determinados permisos y dentro de los límites de las directivas de seguridad. Por ejemplo, debe evitar que un actor malintencionado pueda cambiar una regla de seguridad de red para permitir el tráfico desde Internet.

Para implementar cargas de trabajo en Azure, necesita una o varias cuentas de administración. La protección de las cuentas de administración es fundamental para proteger las cargas de trabajo. Para obtener más información, consulte Protección del acceso con privilegios para las implementaciones híbridas y en la nube en Microsoft Entra ID.

Use los recursos de la subred de administración para conceder acceso al nivel de aplicación solo a las personas que necesitan administrar dicho nivel. Por ejemplo, puede usar Microsoft Identity Manager con Microsoft Entra ID. Sin embargo, para los escenarios nativos de nube, es preferible Microsoft Entra Privileged Identity Management (PIM).

Hay varias maneras de controlar los roles y las directivas de Azure:

  • El control de acceso basado en roles de Azure (RBAC de Azure) para recursos de Azure permite asignar roles integrados o personalizados a los usuarios, para que solo tengan los privilegios que necesitan. Puede combinar RBAC de Azure con PIM para implementar un flujo de trabajo de aprobación auditado que eleve los privilegios durante un período de tiempo limitado.
  • Las directivas aplican reglas, estándares y Acuerdos de Nivel de Servicio corporativos. Azure Policy es un servicio de Azure que crea, asigna y administra directivas, y evalúa los recursos para el cumplimiento de las directivas.
  • Azure Blueprints combina asignaciones de roles, asignaciones de directivas y plantillas de implementación para definir un conjunto de recursos de Azure replicables que implementen y sigan los estándares, patrones y requisitos de una organización. Los planos técnicos son una manera declarativa de organizar la implementación de plantillas de recursos y de otros artefactos. Puede crear planos técnicos por su cuenta o aprovechar los existentes. Por ejemplo, el Plano técnico de servicios compartidos ISO 27001 implementa un centro de servicios compartidos que se puede modificar y ampliar a los requisitos de su organización.

Supervisión

Microsoft Defender for Cloud proporciona supervisión y alertas que ayudan a mantener la seguridad de su entorno. El servicio gratuito realiza una comprobación automática en busca de vulnerabilidades como, por ejemplo, revisiones del sistema operativo que falten, una configuración incorrecta de seguridad y la seguridad de red básica. La versión de pago Estándar proporciona características adicionales, como análisis de comportamiento, protección de red adaptable y acceso a la máquina virtual JIT. Para obtener una lista completa de características, vea Cobertura de características para las máquinas. Defender for Cloud también proporciona protección contra amenazas para otros recursos como Azure Key Vault.

Puede usar Azure Monitor para la supervisión y el análisis posteriores. Para supervisar la identidad y el acceso, se pueden enrutar los registros de actividad de Microsoft Entra a Azure Monitor. También se pueden supervisar máquinas virtuales, redes y Azure Firewall, así como analizar los registros importados con una capacidad de consulta de registros potente. Puede integrar Azure Monitor con la Administración de eventos e información de seguridad (SIEM), que puede ser una SIEM de terceros o Microsoft Sentinel.