Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se describen las consideraciones de seguridad y los controles disponibles al usar servidores habilitados para Azure Arc. Tanto si es un profesional de seguridad como un operador de TI, la información de este artículo le permite configurar Con confianza Azure Arc de una manera que cumpla los requisitos de seguridad de su organización.
Responsabilidades
La seguridad de la implementación de servidores habilitados para Azure Arc es una responsabilidad compartida entre usted y Microsoft. Microsoft es responsable de lo siguiente:
- Protección del servicio en la nube que almacena los metadatos del sistema y organiza las operaciones de los agentes que se conectan al servicio.
- Proteger la privacidad de los metadatos del sistema almacenados en Azure.
- Documentar las características de seguridad opcionales para comprender las ventajas y desventajas de las opciones de implementación.
- Publicar las actualizaciones periódicas del agente con mejoras de seguridad, calidad, rendimiento y características.
Usted es responsable de lo siguiente:
- Administrar y supervisar el acceso de RBAC a los recursos habilitados para Azure Arc en su suscripción de Azure.
- Proteger y rotar periódicamente las credenciales de las cuentas usadas para administrar servidores habilitados para Azure Arc. Esto incluye los secretos o credenciales de la entidad de servicio que se usan para incorporar nuevos servidores.
- Determinar si se deben aplicar las características de seguridad descritas en este documento (por ejemplo, listas de permitidos para extensiones) a los agentes de Azure Connected Machine que usted implemente y cómo se deben aplicar.
- Mantener actualizado el agente y las extensiones de Azure Connected Machine.
- Determinar el cumplimiento de Azure Arc con las obligaciones legales y normativas de su organización y directivas internas.
- Proteger el propio servidor, incluida la infraestructura de proceso, almacenamiento y red que se usa para ejecutar el servidor.
Información general sobre la arquitectura
Los servidores habilitados para Azure Arc son un servicio basado en agente. La interacción con Azure Arc se realiza principalmente a través de las API, el portal y las experiencias de administración de Azure. Los datos que ve y las acciones que realiza en Azure se retransmiten a través del agente de Azure Connected Machine instalado en cada servidor administrado. Azure es la fuente de la verdad para el agente. La única manera de indicar al agente que haga algo (por ejemplo, instalar una extensión) es realizar una acción en la representación de Azure del servidor. Esto ayuda a garantizar que las asignaciones de directivas y RBAC de la organización puedan evaluar la solicitud antes de realizar los cambios.
El agente de Azure Connected Machine es principalmente una plataforma de habilitación para otros servicios de Azure y de terceros. Sus funcionalidades principales incluyen:
- Establecer una relación entre la máquina y la suscripción de Azure
- Proporcionar una identidad administrada para que el agente y otras aplicaciones la usen al autenticarse con Azure
- Habilitar otras funcionalidades (agentes, scripts) con extensiones
- Evaluar y aplicar la configuración en el servidor
Una vez instalado el agente de Azure Connected Machine, puede habilitar otros servicios de Azure en el servidor para satisfacer la supervisión, la administración de revisiones, el acceso remoto u otras necesidades. El rol de Azure Arc es ayudar a permitir que esos servicios funcionen fuera de los propios centros de datos de Azure.
Puede usar Azure Policy para limitar lo que los usuarios de la organización pueden hacer con Azure Arc. Las restricciones basadas en la nube, como Azure Policy, son una excelente manera de aplicar controles de seguridad a escala, a la vez que conservan la flexibilidad para ajustar las restricciones en cualquier momento. Sin embargo, a veces necesita controles aún más fuertes para protegerse frente a una cuenta con privilegios legítimos que se usa para eludir las medidas de seguridad (por ejemplo, deshabilitar directivas). Para abordar esto, el agente de Azure Connected Machine también tiene controles de seguridad propios que tienen prioridad sobre las restricciones establecidas en la nube.
Para descargar diagramas de arquitectura en alta resolución, visite Jumpstart Gems.
Servicios del agente
El agente de Azure Connected Machine es una combinación de cuatro servicios o demonios que se ejecutan en tu servidor y ayudan a conectarlo con Azure. Se instalan juntos como una sola aplicación y se administran de forma centralizada mediante la interfaz de la línea de comandos azcmagent.
Servicio de metadatos de instancia híbrida
Hybrid Instance Metadata Service (HIMDS) es el “servicio principal” del agente y es responsable de registrar el servidor con Azure, la sincronización continua de metadatos (latidos), las operaciones de identidad administrada y el hospedaje de la API de REST local que otras aplicaciones pueden consultar para obtener información sobre la conexión del dispositivo con Azure. Este servicio no tiene privilegios y se ejecuta como una cuenta virtual (NT SERVICE\himds con SID S-1-5-80-4215458991-2034252225-2287069555-1155419622-2701885083) en Windows o en una cuenta de usuario estándar (himds) en sistemas operativos Linux.
Administrador de extensiones
El administrador de extensiones es responsable de instalar, configurar, actualizar y quitar software adicional en la máquina. De por sí, Azure Arc no sabe cómo hacer cosas como supervisar o aplicar revisiones a la máquina. En su lugar, cuando elija utilizar esas características, el administrador de extensiones descargará y habilitará dichas capacidades. El administrador de extensiones se ejecuta como sistema local en Windows y raíz en Linux porque el software que instala puede requerir acceso completo al sistema. Si no quiere usar extensiones, puede limitar por completo las extensiones que el administrador de extensiones puede instalar o deshabilitar.
Configuración de invitado
El servicio de configuración de invitado evalúa y aplica las directivas de configuración del equipo de Azure (invitado) en el servidor. Estas son directivas especiales de Azure escritas en PowerShell Desired State Configuration para comprobar la configuración de software en un servidor. El servicio de configuración de invitado evalúa periódicamente e informa sobre el cumplimiento de estas políticas y, si la política está configurada en modo forzado, cambiará la configuración del sistema para que la máquina vuelva a cumplir con las políticas si es necesario. El servicio de configuración de invitado se ejecuta como sistema local en Windows y raíz en Linux para asegurarse de que tiene acceso a todas las opciones del sistema. Puede deshabilitar la característica de configuración de invitado si no pretende usar directivas de configuración de invitado.
Proxy de Azure Arc
El servicio proxy de Azure Arc es responsable de agregar tráfico de red desde los servicios del agente de Azure Connected Machine y las extensiones que haya instalado y decidir dónde enrutar esos datos. Si usa la puerta de enlace de Azure Arc para simplificar los puntos de conexión de red, el servicio proxy de Azure Arc es el componente local que reenvía las solicitudes de red a través de la puerta de enlace de Azure Arc en lugar de la ruta predeterminada. El proxy de Azure Arc se ejecuta como servicio de red en Windows y una cuenta de usuario estándar (arcproxy) en Linux. Está deshabilitado de forma predeterminada hasta que configure el agente para que use la puerta de enlace de Azure Arc.
Modelo de cuenta de servicio
El agente de Azure Connected Machine está diseñado para ejecutarse en identidades locales administradas por el sistema. En Windows, los servicios principales del agente se ejecutan con una cuenta de servicio virtual y en Linux se ejecutan en cuentas de usuario estándar y sin privilegios.
El agente de Azure Arc no admite el uso de cuentas de servicio unidas a un dominio ni identidades de usuario alternativas proporcionadas por el usuario y no hay ningún método admitido para cambiar esta configuración.
Este diseño es intencionado y se alinea con el modelo operativo y de seguridad de servidores habilitados para Azure Arc:
Independencia de la infraestructura de dominio: El agente está diseñado para funcionar de forma coherente en entornos unidos a un dominio, grupo de trabajo y desconectados. Evitar identidades administradas por dominio garantiza que el agente no dependa de la disponibilidad de Active Directory, relaciones de confianza o directivas específicas del dominio.
Exposición reducida de credenciales: Las cuentas de servicio virtual locales están administradas por el sistema y no requieren administración de contraseñas, rotación ni inicio de sesión interactivo. Esto minimiza el riesgo de robo, reutilización o configuración incorrecta de credenciales en comparación con las cuentas de servicio de dominio.
Límite de seguridad con ámbito de máquina: el agente opera mediante identidades con ámbito en la máquina local en lugar de identidades de nivel de dominio. Esto aplica un límite claro entre el agente y los sistemas de identidades administradas por el cliente, lo que reduce el riesgo de acceso no deseado a los recursos de dominio.
Comportamiento coherente entre entornos : la estandarización de las identidades de servicio locales garantiza un comportamiento predecible y compatible entre implementaciones locales, multinube y perimetrales, sin introducir variabilidad de las configuraciones de identidad específicas del cliente.
Este modelo de cuenta de servicio es una parte fundamental del diseño de seguridad del agente y no es configurable.
Consideraciones de seguridad para los recursos de nivel 0
Los recursos de nivel 0 (como un controlador de Dominio de Active Directory, un servidor de entidad de certificación o un servidor de aplicaciones empresariales altamente confidenciales) se pueden conectar a Azure Arc con cuidado adicional para asegurarse de que solo las funciones de administración deseadas y los usuarios autorizados puedan administrar los servidores. Estas recomendaciones no son necesarias, pero se recomienda encarecidamente mantener la posición de seguridad de los recursos de nivel 0.
Suscripción de Azure dedicada
El acceso a servidores habilitados para Azure Arc suele estar determinado por la jerarquía organizativa a la que pertenece en Azure. Debe tratar cualquier administrador de grupo de administración o suscripción como equivalente a un administrador local en recursos de nivel 0, ya que podrían usar sus permisos para agregar nuevas asignaciones de roles al recurso de Azure Arc. Además, las políticas aplicadas en el nivel de suscripción o grupo de administración también pueden estar autorizadas para efectuar modificaciones en el servidor.
Para minimizar el número de cuentas y directivas con acceso a los recursos de nivel 0, considere la posibilidad de usar una suscripción de Azure dedicada que se pueda supervisar y configurar con tan pocos administradores persistentes como sea posible. Revise las directivas de Azure en cualquier grupo de administración primario para asegurarse de que están alineadas con la intención de estos servidores.
Deshabilitar las características de administración innecesarias
Para un recurso de nivel 0, debe usar los controles de seguridad del agente local para restringir o deshabilitar cualquier funcionalidad no utilizado en el agente para evitar el uso intencionado o accidental de esas características para realizar cambios en el servidor. Esto incluye:
- Deshabilitar las funcionalidades de acceso remoto
- Establecer una lista de permitidos de extensiones para las extensiones que desea utilizar o deshabilitar el gestor de extensiones si no utiliza extensiones
- Deshabilitar el agente de configuración de la máquina si no pretende usar directivas de configuración de máquina
Por ejemplo, a menos que quiera usar una extensión de script personalizada para la ejecución remota de código, es mejor deshabilitar su uso, ya que los atacantes podrían usarlo para ejecutar comandos remotamente y colocar malware u otro código malintencionado en la máquina virtual. Puede usar el mecanismo allowlist para deshabilitar el uso de la extensión de script personalizado si su uso no cumple los requisitos de seguridad.
En el ejemplo siguiente se muestra cómo bloquear el agente de Azure Connected Machine para un controlador de dominio que necesita usar el agente de Azure Monitor para recopilar registros de seguridad para Microsoft Sentinel y Microsoft Defender para servidores, con el fin de protegerse frente a amenazas de malware:
azcmagent config set incomingconnections.enabled false
azcmagent config set guestconfiguration.enabled false
azcmagent config set extensions.allowlist "Microsoft.Azure.Monitor/AzureMonitorWindowsAgent,Microsoft.Azure.AzureDefenderForServers/MDE.Windows"