Administración de identidades y acceso con servidores habilitados para Azure Arc

Administrar la identidad de los servidores tradicionalmente giraba en torno a Active Directory: los servidores están unidos a un dominio, los administradores reciben cuentas de dominio que se agregan a los administradores locales a través de grupos de dominios y la configuración de Windows se administra mediante la directiva de grupo. En el modelo de administración en la nube, Microsoft Entra se convierte en la piedra angular de la identidad y el acceso, mientras que Active Directory (AD) todavía se puede usar para la autenticación de aplicaciones y los protocolos heredados en máquinas Windows locales.

La identidad nativa de la nube en la administración del servidor se logra mediante Microsoft Entra para autenticar a los administradores y los propios servidores. Los dispositivos Windows (estación de trabajo) nativos de la nube pueden acceder a los servidores unidos a un dominio de AD local o a los usuarios de esos dispositivos. A través de Microsoft Entra, obtendrá credenciales unificadas, ya que microsoft Entra ID puede administrar máquinas virtuales (VM), servidores habilitados para Arc, Office 365, etc. Características como la autenticación multifactor (MFA) y el acceso condicional mejoran la seguridad. Los servidores del entorno híbrido pueden usar el sistema de identidad de Azure para acceder a los recursos de forma segura. Estas ventajas permiten reducir el tiempo invertido en mantener cuentas de servicio o conceder derechos de administrador locales por máquina. Es una transición en el pensamiento, pero una que se alinea con un ecosistema totalmente administrado en la nube.

Veamos cómo cambia el mundo de un administrador del sistema con las ventajas de Microsoft Entra.

Integración de Microsoft Entra

Microsoft Entra ID es un servicio de identidad basado en la nube. A diferencia de Active Directory Domain Services (AD DS), el identificador de Microsoft Entra no está estructurado en unidades organizativas y no se centra en la autenticación Kerberos. En su lugar, el identificador de Microsoft Entra administra las identidades de usuario, las aplicaciones y el acceso a los recursos de Microsoft, incluidos Azure, Microsoft 365 y otras aplicaciones y sistemas operativos que admiten el identificador de Microsoft Entra.

Los propios servidores no se "unen" al id. de Microsoft Entra de la forma en que se unen a un dominio. En su lugar, un servidor habilitado para Arc se une a un inquilino de Azure que se rige por el identificador de Entra de Microsoft cuando se conecta por primera vez a Azure. Con el identificador de Entra de Microsoft, los usuarios pueden asignar roles a un ámbito designado (o agregarse a un grupo con esos permisos) mediante el control de acceso basado en rol (Azure RBAC) de Azure. A continuación, los usuarios con los permisos adecuados pueden usar una conexión a Escritorio remoto para acceder a máquinas Windows Server o usar SSH para acceder a Linux.

La "cuenta de administrador" es la identidad de id. de Microsoft Entra (o una cuenta de AD sincronizada) con los roles adecuados en Azure. Por ejemplo, para administrar servidores habilitados para Arc, un usuario de Id. de Microsoft Entra podría tener el rol integrado de Inicio de sesión de máquina virtual de Azure o una asignación de roles personalizada que cree con los permisos adecuados. En lugar de tener una cuenta de administrador que permita el acceso total a todos los servidores, Microsoft Entra ID le permite definir el ámbito de los roles a un conjunto específico de cargas de trabajo de Azure, concediéndoles solo los permisos necesarios para realizar las tareas necesarias en servidores habilitados para Arc y recursos nativos de Azure.

Identidad administrada asignada por el sistema

Los servidores habilitados para Arc requieren una identidad administrada asignada por el sistema. Se trata de un tipo de aplicación empresarial que representa la identidad de un recurso de máquina en Azure. En lugar de almacenar credenciales, las aplicaciones que se ejecutan en el servidor pueden usar la identidad administrada del servidor para autenticarse en Azure. El agente de máquina conectada de Azure Arc expone un punto de conexión que la aplicación puede usar para solicitar un token. La aplicación no necesita autenticarse en el servicio web no enrutable que proporciona tokens que no tengan el formato correcto de la solicitud (incluido un encabezado de metadatos), por lo que el límite de seguridad esperado es la máquina virtual. El servidor local puede acceder directamente a los servicios de Azure sin necesidad de credenciales codificadas de forma rígida, ya que Azure sabe que la solicitud procede de ese servidor y la autoriza solo en función de las asignaciones de roles que establezca.

Para un administrador del sistema, un escenario común podría estar ejecutando un comando de la CLI de Azure en el servidor (que tiene instalada la CLI de Azure) que llama a Azure Storage para recuperar un artefacto usado por un script de automatización. Dado que el servidor tiene un acceso autorizado de identidad a esa cuenta de almacenamiento, la solicitud se completa sin necesidad de una cuenta de servicio o un token de acceso personal (PAT).

Control de acceso basado en rol (RBAC)

El modelo de Azure fomenta RBAC pormenorizado. Dado que los distintos roles integrados habilitan distintos tipos de acceso, puede asignar roles con permisos muy limitados. Por ejemplo, un usuario podría tener un rol que solo conceda la capacidad de usar Ejecutar comando en servidores habilitados para Arc o permitir el acceso de solo lectura a una configuración y nada más.

Un rol integrado común que se usa con Azure Arc es el rol de incorporación de máquinas conectadas de Azure. Los usuarios con este rol pueden incorporar servidores a Azure Arc, pero no pueden realizar la mayoría de otras tareas de administración a menos que se concedan roles adicionales. Del mismo modo, puede conceder roles a los propietarios de aplicaciones que les permitan implementar revisiones en sus servidores a través de Azure Automation sin proporcionarles acceso de inicio de sesión del sistema operativo real. Este nivel de ajuste adecuado admite principios de administración "just-enough".

Acceso oportuno

Para controlar aún más el acceso elevado a los servidores habilitados para Arc y a otros recursos de Azure, puede habilitar Microsoft Entra Privileged Identity Management (PIM). PIM se puede usar para el acceso Just-In-Time (JIT), por lo que puede requerir que alguien eleva explícitamente a un rol específico para realizar tareas que requieran mayores niveles de acceso. Puede requerir que un administrador apruebe este acceso y establezca períodos de expiración automática para el rol con privilegios elevados. PIM también incluye un historial de auditoría para ver todas las asignaciones de roles y las activaciones de todos los roles con privilegios en los últimos 30 días (o un período más largo que configure).

El uso de PIM ayuda a reducir el acceso de administrador continuo y admite el principio de privilegios mínimos. Por ejemplo, podría usar PIM para conceder a determinados usuarios la capacidad de elevar su rol al administrador de recursos de Azure Connected Machine, lo que les permite realizar tareas de administración más avanzadas en servidores habilitados para Arc.

Configuraciones de identidad híbrida

En la práctica, muchas empresas ejecutan servidores habilitados para Arc que también están unidos a un dominio a AD. Estos no son mutuamente excluyentes; se complementan entre sí. Puede iniciar sesión en el servidor a través de AD cuando sea necesario, pero realizar tareas de administración en Azure.

En servidores individuales, es posible que siga administrando cuentas locales a través de AD, como el uso de la solución de contraseñas de administrador local (LAPS) para rotar la contraseña de administrador local. Dado que Azure Arc no administra cuentas locales, es posible que quiera seguir usando ese proceso. Incluso puede usar Azure Policy para asegurarse de que LAPS está habilitado y almacenar contraseñas en Microsoft Entra.

Hay mucha flexibilidad para usar las funcionalidades de Microsoft Entra y Azure, a la vez que mantiene soluciones de identidad locales que funcionan automáticamente. Con el tiempo, encontrará que necesita interactuar menos con el mantenimiento de cuentas de servicio o conceder derechos de administrador local, ya que puede tener opciones de administración de identidades en la nube.