Aspectos básicos de la administración de recursos de Azure
Es importante comprender la estructura y los términos específicos de los recursos de Azure. En la imagen siguiente, se muestra un ejemplo de los cuatro niveles de ámbito proporcionados por Azure:
Terminología
Estos son algunos de los términos con los que debe estar familiarizado:
Recurso: elemento administrable que está disponible mediante Azure. Las máquinas virtuales, cuentas de almacenamiento, aplicaciones web, bases de datos y redes virtuales son ejemplos de recursos.
Grupo de recursos: un contenedor que contiene recursos relacionados para una solución de Azure, como una colección de máquinas virtuales, las redes virtuales asociadas y los equilibradores de carga, que requieren administración por parte de equipos específicos. El grupo de recursos incluye los recursos que se desean administrar como un grupo. Decida qué recursos pertenecen a un grupo de recursos según lo que más convenga a su organización. Los grupos de recursos también se pueden usar para ayudar con la administración del ciclo de vida, mediante la eliminación al mismo tiempo de todos los recursos que tienen la misma duración. Este enfoque también proporciona ventajas de seguridad al no dejar fragmentos cuyas vulnerabilidades de seguridad se pudieran aprovechar.
Suscripción: desde una perspectiva de jerarquía organizativa, una suscripción es un contenedor de facturación y administración de recursos y grupos de recursos. Las suscripciones de Azure tienen una relación de confianza con Microsoft Entra ID. Una suscripción confía en Microsoft Entra ID para autenticar usuarios, servicios y dispositivos.
Nota:
Una suscripción solo puede confiar en un inquilino de Microsoft Entra. Sin embargo, cada inquilino puede confiar en varias suscripciones y las suscripciones se pueden mover entre inquilinos.
Grupo de administración: los grupos de administración de Azure proporcionan un método jerárquico de aplicación de directivas y cumplimiento en distintos ámbitos por encima de las suscripciones. Puede estar en el grupo de administración raíz del inquilino (el ámbito más alto) o en niveles inferiores de la jerarquía. Las suscripciones se organizan en contenedores llamados "grupos de administración" y aplican sus condiciones de gobernanza a los grupos de administración. Todas las suscripciones dentro de un grupo de administración heredan automáticamente las condiciones que se aplican al grupo de administración. Tenga en cuenta que las definiciones de directiva se pueden aplicar a un grupo de administración o a una suscripción.
Proveedor de recursos: un servicio que proporciona recursos de Azure. Por ejemplo, un proveedor de recursos común es Microsoft. Compute, que proporciona el recurso de máquina virtual. Microsoft. Storage es otro proveedor de recursos común.
Plantilla de Resource Manager: archivo de notación de objetos JavaScript (JSON) que define uno o más recursos para implementar en un grupo de recursos, una suscripción, un inquilino o un grupo de administración. La plantilla se puede usar para implementar los recursos de manera repetida y uniforme. Consulte Información general de la implementación de plantillas. Además, se puede usar el lenguaje Bicep en lugar de JSON.
Modelo de administración de recursos de Azure
Cada suscripción de Azure está asociada con los controles que usa Azure Resource Manager. Resource Manager es el servicio de implementación y administración de Azure, tiene una relación de confianza con Microsoft Entra ID para la administración de identidades de organizaciones y con la cuenta de Microsoft (MSA) para usuarios individuales. Azure Resource Manager proporciona una capa de administración que le permite crear, actualizar y eliminar recursos de la suscripción de Azure. Las características de administración, como el control de acceso, los bloqueos y las etiquetas, se utilizan para proteger y organizar los recursos después de la implementación.
Nota:
Antes de ARM, había otro modelo de implementación llamado Azure Service Manager (ASM) o "clásico". Para más información, consulte Implementación mediante Azure Resource Manager frente a la implementación clásica: Conozca los modelos de implementación y el estado de los recursos. La administración de entornos con el modelo de ASM está fuera del ámbito de este contenido.
Azure Resource Manager es el servicio de front-end que hospeda las API REST que usan PowerShell, Azure Portal y otros clientes para administrar recursos. Cuando un cliente realiza una solicitud para administrar un recurso específico, Resource Manager reenvía la solicitud al proveedor de recursos para completar la solicitud. Por ejemplo, si un cliente realiza una solicitud para administrar un recurso de máquina virtual, Resource Manager reenvía la solicitud al proveedor de recursos Microsoft. Compute. Resource Manager requiere que el cliente especifique un identificador de suscripción y de grupo de recursos para administrar el recurso de máquina virtual.
Antes de que Resource Manager pueda ejecutar cualquier solicitud de administración de recursos, se comprueban un conjunto de controles.
Comprobación de usuario válido: el usuario que solicita administrar el recurso debe tener una cuenta en el inquilino de Microsoft Entra asociado a la suscripción del recurso administrado.
Comprobación de los permisos del usuario: los permisos se asignan a los usuarios con el control de acceso basado en rol (RBAC). Un rol de RBAC especifica un conjunto de permisos que un usuario puede tener en un recurso específico. RBAC ayuda a administrar quién tiene acceso a los recursos de Azure, qué se puede hacer con esos recursos y a qué áreas se tiene acceso.
Comprobación de directivas de Azure: las directivas de Azure especifican las operaciones permitidas o denegadas explícitamente para un recurso específico. Por ejemplo, una directiva puede especificar que los usuarios solo pueden implementar (o que no lo tienen permitido) un tipo específico de máquina virtual.
En el diagrama siguiente, se resume el modelo de recursos que acabamos de describir.
Azure Lighthouse: Azure Lighthouse permite la administración de recursos entre inquilinos. Las organizaciones pueden delegar roles en el nivel de suscripción o de grupo de recursos a identidades de otro inquilino.
Las suscripciones que habilitan la administración delegada de recursos con Azure Lighthouse tienen atributos que indican los identificadores de inquilino que pueden administrar suscripciones o grupos de recursos, y la asignación entre el rol RBAC integrado del inquilino de los recursos a las identidades del inquilino del proveedor de servicios. En tiempo de ejecución, Azure Resource Manager consumirá estos atributos para autorizar los tokens procedentes del inquilino del proveedor de servicios.
Merece la pena tener en cuenta que Azure Lighthouse se ha modelado como un proveedor de recursos de Azure, lo que significa que los aspectos de la delegación en un inquilino se pueden tratar mediante directivas de Azure.
Microsoft 365 Lighthouse: Microsoft 365 Lighthouse es un portal de administración que ayuda a los proveedores de servicios administrados (MSP) a proteger y administrar dispositivos, datos y usuarios a gran escala para clientes de pequeñas y medianas empresas (PYMES) que usen Microsoft 365 Business Premium, Microsoft 365 E3 o Windows 365 Business.
Administración de recursos en Azure con Microsoft Entra ID
Ahora que conoce mejor el modelo de administración de recursos en Azure, examinaremos brevemente algunas de las características de Microsoft Entra ID que pueden proporcionar administración de identidades y acceso para los recursos de Azure.
Facturación
La facturación es importante para la administración de recursos porque algunos roles de facturación interactúan con recursos o pueden administrarlos. La facturación funciona de forma diferente en función del tipo de contrato que tenga con Microsoft.
Contratos Enterprise de Azure
Los clientes de Contrato Enterprise de Azure (Azure EA) se incorporan a Microsoft Azure Enterprise Portal tras la ejecución de su contrato comercial con Microsoft. Tras la incorporación, se asocia una identidad a un rol de facturación de administrador de empresa "raíz". El portal proporciona una jerarquía de funciones de administración:
Los departamentos ayudan a segmentar los costos en agrupaciones lógicas y permiten establecer un presupuesto o una cuota en el nivel de departamento.
Las cuentas se usan para segmentar aún más los departamentos. Puede usar las cuentas para administrar las suscripciones y obtener acceso a los informes. EA Portal puede autorizar cuentas de Microsoft (MSA) o cuentas de Microsoft Entra (identificadas en el portal como "Cuenta profesional o educativa"). Las identidades con el rol "Propietario de la cuenta" en Enterprise Portal pueden crear suscripciones de Azure.
Facturación empresarial e inquilinos de Microsoft Entra
Cuando un propietario de la cuenta crea una suscripción de Azure dentro de un contrato Enterprise, la administración de identidades y acceso de la suscripción se configura de la siguiente manera:
La suscripción de Azure está asociada al mismo inquilino de Microsoft Entra del propietario de la cuenta.
Al propietario de la cuenta que creó la suscripción se le asignarán los roles Administrador de servicios y Administrador de cuenta. (Enterprise Portal asigna roles de Azure Service Manager (ASM) o "clásico" para administrar suscripciones. Para más información, consulte Implementación mediante Azure Resource Manager frente a la implementación clásica: Conozca los modelos de implementación y el estado de los recursos.
Un contrato Enterprise se puede configurar para admitir varios inquilinos estableciendo el tipo de autenticación "Cuenta profesional o educativa entre inquilinos" en Azure Enterprise Portal. Según la información anterior, las organizaciones pueden establecer varias cuentas para cada inquilino y varias suscripciones para cada cuenta, como se muestra en el diagrama siguiente.
Es importante tener en cuenta que la configuración predeterminada descrita anteriormente concede privilegios de propietario de la cuenta de Contrato Enterprise de Azure para administrar los recursos de las suscripciones que se hayan creado. En el caso de las suscripciones que contienen cargas de trabajo de producción, considere la posibilidad de desacoplar la facturación y la administración de recursos cambiando el administrador de servicios de la suscripción justo después de la creación.
Para desacoplar aún más y evitar que el propietario de la cuenta recupere el acceso del administrador de servicios a la suscripción, el inquilino de la suscripción se puede cambiar después de la creación. Si el propietario de la cuenta no tiene un objeto de usuario en el inquilino de Microsoft Entra al que se mueve la suscripción, no puede recuperar el rol de propietario del servicio.
Para obtener más información, consulte Roles de Azure, roles de Microsoft Entra y roles de administrador de la suscripción clásica.
Contrato de cliente de Microsoft
Los clientes inscritos con un Contrato de cliente de Microsoft (MCA) tienen un sistema de administración de facturación diferente con sus propios roles.
Una cuenta de facturación para el Contrato de cliente de Microsoft contiene uno o más perfiles de facturación que permiten administrar las facturas y los métodos de pago. Cada perfil de facturación contiene una o más secciones de factura para organizar los costos en la factura del perfil de facturación.
En un Contrato de cliente de Microsoft, los roles de facturación proceden de un único inquilino de Microsoft Entra. Para aprovisionar suscripciones para varios inquilinos, las suscripciones se deben crear inicialmente en el mismo inquilino de Microsoft Entra que el contrato MCA y cambiarse a continuación. En el diagrama siguiente, las suscripciones del entorno de preproducción de TI corporativa se han movido al inquilino ContosoSandbox después de la creación.
RBAC y asignaciones de roles en Azure
En la sección de aspectos básicos de Microsoft Entra, ha aprendido que RBAC de Azure es el sistema de autorización que proporciona una administración de acceso pormenorizada para los recursos de Azure e incluye muchos roles integrados. Puede crear roles personalizados y asignar roles en distintos ámbitos. Los permisos se aplican mediante la asignación de roles RBAC a los objetos que solicitan acceso a los recursos de Azure.
Los roles de Microsoft Entra operan con conceptos similares al control de acceso basado en rol de Azure. La diferencia entre estos dos sistemas de control de acceso basado en rol es que RBAC de Azure usa la administración de recursos de Azure para controlar el acceso a los recursos de Azure (como máquinas virtuales o almacenamiento), mientras que los roles de Microsoft Entra controlan el acceso a Microsoft Entra ID, aplicaciones y servicios de Microsoft (como Office 365).
Tanto los roles de Microsoft Entra como los roles RBAC de Azure se integran con Microsoft Entra Privileged Identity Management para habilitar directivas de activación Just-In-Time, como el flujo de trabajo de aprobación y MFA.
ABAC y asignaciones de roles en Azure
El control de acceso basado en atributos (ABAC) es un sistema de autorización que define el acceso en función de los atributos asociados a las entidades de seguridad, los recursos y el entorno. Con ABAC, puede conceder a una entidad de seguridad acceso a un recurso en función de los atributos. Azure ABAC hace referencia a la implementación del control de acceso basado en atributos para Azure.
Azure ABAC se basa en Azure RBAC con la adición de condiciones de asignación de roles basadas en atributos en el contexto de acciones específicas. Una condición de asignación de roles es una comprobación adicional que puede agregar opcionalmente a la asignación de roles para proporcionar un control de acceso más preciso. Una condición filtra los permisos concedidos como parte de la definición de roles y la asignación de roles. Por ejemplo, puede agregar una condición que requiera que un objeto tenga una etiqueta específica para leer el objeto. No se puede denegar explícitamente el acceso a recursos específicos mediante condiciones.
Acceso condicional
El acceso condicional de Microsoft Entra puede utilizarse para administrar el acceso a los puntos de conexión de administración de Azure. Las directivas de acceso condicional pueden aplicarse a la aplicación en la nube de Windows Azure Service Management API para proteger los puntos de conexión de administración de recursos de Azure, como:
Proveedor de Azure Resource Manager (servicios)
API de Azure Resource Manager:
Azure PowerShell
Azure CLI
Azure portal
Por ejemplo, un administrador puede configurar una directiva de acceso condicional, que permite a un usuario iniciar sesión en Azure Portal solo desde las ubicaciones aprobadas y también requiere la autenticación multifactor (MFA) o un dispositivo unido a un dominio de Microsoft Entra híbrido.
Identidades administradas de Azure
Un desafío común al compilar aplicaciones en la nube consiste en el modo de administrar las credenciales del código para autenticar los servicios en la nube. Proteger las credenciales es una tarea esencial. Lo ideal sería que nunca aparecieran en las estaciones de trabajo de los desarrolladores y que no se controlaran en el código fuente. Las identidades administradas para recursos Azure proporcionan a los servicios de Azure una identidad administrada automáticamente en Microsoft Entra ID. Puede usar esta identidad para autenticarse en cualquier servicio que admita la autenticación de Microsoft Entra, sin necesidad de tener credenciales en el código.
Hay dos tipos de identidades administradas:
Una identidad administrada asignada por el sistema se habilita directamente en un recurso de Azure. Cuando el recurso está habilitado, Azure crea una identidad para el recurso en el inquilino de Microsoft Entra de confianza de la suscripción asociada. Una vez creada la identidad, se aprovisionan las credenciales en el recurso. El ciclo de vida de una identidad asignada por el sistema está vinculado directamente al recurso de Azure. Si se elimina el recurso, Azure limpia automáticamente las credenciales y la identidad en Microsoft Entra ID.
Las identidades administrada asignadas por el usuario se crean como recursos de Azure independientes. Azure crea una identidad en el inquilino de Microsoft Entra de confianza de la suscripción a la que está asociado el recurso. Una vez creada la identidad, esta se puede asignar a uno o varios recursos de Azure. El ciclo de vida de una identidad asignada por el usuario se administra de forma independiente al ciclo de vida de los recursos de Azure a los que se haya asignado.
Internamente, las identidades administradas son entidades de servicio de un tipo especial, para su uso solo por parte de recursos específicos de Azure. Cuando se elimina la identidad administrada, se quita automáticamente la entidad de servicio correspondiente. Tenga en cuenta que la autorización de los permisos de Graph API solo se puede realizar mediante PowerShell, por lo que no todas las características de la identidad administrada son accesibles mediante la interfaz de usuario del portal.
Servicios de dominio de Microsoft Entra
Microsoft Entra Domain Services proporciona un dominio administrado para facilitar la autenticación para las cargas de trabajo de Azure que usan protocolos heredados. Los servidores admitidos se mueven de un bosque de AD DS local y se unen a un dominio administrado de Microsoft Entra Domain Services, y siguen usando protocolos heredados para la autenticación (por ejemplo, la autenticación Kerberos).
Directorios de Azure AD B2C y Azure
Un inquilino de Azure AD B2C está vinculado a una suscripción de Azure con fines de facturación y comunicación. Los inquilinos de Azure AD B2C tienen una estructura de roles autocontenida en el directorio, que es independiente de los roles con privilegios de RBAC de Azure de la suscripción de Azure.
Cuando se aprovisiona inicialmente el inquilino de Azure AD B2C, el usuario que crea el inquilino de B2C debe tener permisos de colaborador o propietario en la suscripción. Más adelante pueden crear otras cuentas y asignarlas a roles de directorio. Para obtener más información sobre el ámbito, vea Información general sobre el control de acceso basado en rol (RBAC) en Microsoft Entra ID.
Es importante tener en cuenta que los propietarios y colaboradores de la suscripción de Microsoft Entra vinculada pueden quitar el vínculo entre la suscripción y el directorio, lo que afecta a la facturación en curso del uso de Azure AD B2C.
Consideraciones de identidad para las soluciones IaaS en Azure
En este escenario, se tratan los requisitos de aislamiento de identidad que tienen las organizaciones para las cargas de trabajo de infraestructura como servicio (IaaS).
Hay tres opciones principales relacionadas con la administración del aislamiento de cargas de trabajo de IaaS:
Máquinas virtuales unidas a instancias independientes de Active Directory Domain Services (AD DS)
Máquinas virtuales unidas a Microsoft Entra Domain Services
Inicio de sesión en máquinas virtuales en Azure usando la autenticación de Microsoft Entra
Un concepto clave para abordar las dos primeras opciones es que hay dos dominios de identidad implicados en estos escenarios.
Cuando inicia sesión en una máquina virtual de Azure con Windows Server mediante el Protocolo de escritorio remoto (RDP), normalmente inicia sesión en el servidor con las credenciales de dominio, que realiza una autenticación Kerberos en un controlador de dominio de AD DS local o en Microsoft Entra Domain Services. Como alternativa, si el servidor no está unido a un dominio, se puede usar una cuenta local para iniciar sesión en las máquinas virtuales.
Cuando inicia sesión en Azure Portal para crear o administrar una máquina virtual, se autentica en Microsoft Entra ID (posiblemente con las mismas credenciales, si ha sincronizado las cuentas correctas) y esto puede dar lugar a una autenticación en los controladores de dominio si usa los Servicios de federación de Active Directory (AD FS) o la autenticación transferida.
Máquinas virtuales unidas a instancias independientes de Active Directory Domain Services
AD DS es el servicio de directorio basado en Windows Server que han adoptado en gran medida las organizaciones para los servicios de identidad locales. Se puede implementar AD DS cuando exista un requisito para implementar cargas de trabajo de IaaS en Azure que requieran aislamiento de identidad de los administradores y usuarios de AD DS de otro bosque.
En este escenario, se deben tener en cuenta las siguientes consideraciones:
Controladores de dominio de AD DS: se deben implementar un mínimo de dos controladores de dominio de AD DS para garantizar que los servicios de autenticación sean de alta disponibilidad y rendimiento. Para más información, consulte Diseño y planeamiento de AD DS.
Diseño y planeamiento de AD DS: se debe crear un nuevo bosque de AD DS con los siguientes servicios configurados correctamente:
Servicios de nombres de dominio (DNS) de AD DS: se debe configurar DNS de AD DS en las zonas pertinentes de AD DS para asegurarse de que la resolución de nombres funcione correctamente para servidores y aplicaciones.
Sitios y servicios de AD DS: se deben configurar estos servicios para garantizar que las aplicaciones tengan baja latencia y acceso eficaz a los controladores de dominio. Se deben configurar en sitios y servicios las redes virtuales, subredes y ubicaciones del centro de datos pertinentes en las que se encuentran los servidores.
FSMO de AD DS: se deben revisar y asignar a los controladores de dominio de AD DS adecuados los roles de Operación maestra única flexible (FSMO) que sean necesarios.
Unión a un dominio de AD DS: se deben unir al bosque aislado todos los servidores (excepto los "jumpboxes") que requieran AD DS para la autenticación, configuración y administración.
Directiva de grupo (GPO) de AD DS: se deben configurar GPO de AD DS para asegurarse de que la configuración cumpla los requisitos de seguridad y que la configuración esté estandarizada en el bosque y las máquinas unidas al dominio.
Unidades organizativas (OU) de AD DS: se deben definir unidades organizativas de AD DS para garantizar la agrupación de recursos de AD DS en silos lógicos de configuración y administración con fines de administración y aplicación de la configuración.
Control de acceso basado en roles: se debe definir RBAC para la administración y el acceso a los recursos unidos a este bosque. Esto incluye:
Grupos de AD DS: se deben crear grupos para aplicar los permisos adecuados para los usuarios a los recursos de AD DS.
Cuentas de administración: como se mencionó al principio de esta sección, hay dos cuentas de administración necesarias para administrar esta solución.
Una cuenta de administración de AD DS con acceso con los privilegios mínimos necesarios para realizar la administración requerida en AD DS y los servidores unidos a un dominio.
Una cuenta de administración de Microsoft Entra para el acceso a Azure Portal con el fin de conectarse, administrar y configurar máquinas virtuales, redes virtuales, grupos de seguridad de red y otros recursos de Azure necesarios.
Cuentas de usuario de AD DS: se deben aprovisionar y agregar a los grupos correctos las cuentas de usuario pertinentes para permitir el acceso de los usuarios a las aplicaciones hospedadas por esta solución.
Redes virtuales (VNet): guía de configuración
Dirección IP del controlador de dominio de AD DS: los controladores de dominio no se deben configurar con direcciones IP estáticas dentro del sistema operativo. Se deben reservar las direcciones IP en la red virtual de Azure para asegurarse de que siempre permanezcan iguales y el controlador de dominio se debe configurar para usar DHCP.
Servidor DNS de red virtual: se deben configurar servidores DNS en las redes virtuales que forman parte de esta solución aislada para que apunten a los controladores de dominio. Esto es necesario para garantizar que las aplicaciones y los servidores puedan resolver los servicios de AD DS necesarios u otros servicios unidos al bosque de AD DS.
Grupos de seguridad de red (NSG): los controladores de dominio deben estar ubicados en su propia red virtual o subred con grupos de seguridad de red definidos para permitir solo el acceso a los controladores de dominio desde los servidores necesarios (por ejemplo, las máquinas unidas a un dominio o los jumpboxes). Los jumpboxes se deben agregar a un grupo de seguridad de aplicaciones (ASG) para simplificar la creación y administración de los NSG.
Desafíos: en la lista siguiente, se resaltan los desafíos clave en el uso de esta opción para el aislamiento de identidad:
Un bosque de AD DS adicional que se debe administrar y supervisar, lo que da lugar a más trabajo a realizar para el equipo de TI.
Es posible que se requiera más infraestructura para la administración de las implementaciones de aplicación de revisiones y software. Las organizaciones deben considerar la posibilidad de implementar Azure Update Management, una directiva de grupo (GPO) o System Center Configuration Manager (SCCM) para administrar estos servidores.
Credenciales adicionales que los usuarios deben recordar y usar para acceder a los recursos.
Importante
Para este modelo aislado, se supone que no hay conectividad hacia ni desde los controladores de dominio desde la red corporativa del cliente y que no hay confianzas configuradas con otros bosques. Se debe crear un jumpbox o un servidor de administración para permitir un punto desde el que se puedan administrar los controladores de dominio de AD DS.
Máquinas virtuales unidas a Microsoft Entra Domain Services
Cuando existe un requisito para implementar cargas de trabajo de IaaS en Azure que requieren el aislamiento de la identidad de los administradores y usuarios de AD DS en otro bosque, se puede implementar un dominio administrado de Microsoft Entra Domain Services. Microsoft Entra Domain Services es un servicio que proporciona un dominio administrado para facilitar la autenticación para las cargas de trabajo de Azure que usan protocolos heredados. Esto proporciona un dominio aislado sin las complejidades técnicas de la creación y administración de su propia instancia de AD DS. Se deben tener en cuenta las siguientes consideraciones.
Dominio administrado de Microsoft Entra Domain Services: solo se puede implementar un dominio administrado de Microsoft Entra Domain Services por inquilino de Microsoft Entra y se enlaza a una sola red virtual. Se recomienda que esta red virtual sea el "centro" de autenticación de Microsoft Entra Domain Services. Desde este concentrador, se pueden crear y vincular "radios" para permitir la autenticación heredada para servidores y aplicaciones. Los radios son redes virtuales adicionales donde hay servidores unidos a Microsoft Entra Domain Services que están vinculados al centro por medio de puertas de enlace de red de Azure o emparejamiento de VNet.
Ubicación del dominio administrado: debe establecerse una ubicación al implementar un dominio administrado de Microsoft Entra Domain Services. La ubicación es una región física (centro de datos) en la que se implementa el dominio administrado. Se recomienda lo siguiente:
Considere la posibilidad de usar una ubicación que esté geográficamente cerrada a los servidores y aplicaciones que requieren servicios de Microsoft Entra Domain Services.
Considere el uso de regiones que proporcionen funcionalidades de Availability Zones para los requisitos de alta disponibilidad. Para obtener más información, consulte Regiones y zonas de disponibilidad en Azure.
Aprovisionamiento de objetos: Microsoft Entra Domain Services sincroniza las identidades de Microsoft Entra ID asociadas a la suscripción donde está implementado Microsoft Entra Domain Services. También hay que tener en cuenta que, si la instancia de Microsoft Entra ID asociada tiene la sincronización configurada con Microsoft Entra Connect (escenario de bosque de usuarios), el ciclo de vida de estas identidades también se puede reflejar en Microsoft Entra Domain Services. Este servicio tiene dos modos que se pueden usar para aprovisionar objetos de usuario y de grupo desde Microsoft Entra ID.
Todos: todos los usuarios y grupos de Microsoft Entra ID se sincronizan con Microsoft Entra Domain Services.
Con ámbito: solo los usuarios del ámbito de un grupo de Microsoft Entra ID se sincronizan con Microsoft Entra Domain Services.
Cuando se implementa Microsoft Entra Domain Services por primera vez, se configura una sincronización unidireccional automática para replicar los objetos de Microsoft Entra ID. Esta sincronización unidireccional continúa ejecutándose en segundo plano para mantener actualizado el dominio administrado de Microsoft Entra Domain Services con los cambios de Microsoft Entra ID. No se produce ninguna sincronización de nuevo entre Microsoft Entra Domain Services y Microsoft Entra ID. Para obtener más información, consulte Procedimiento para sincronizar objetos y credenciales en un dominio administrado de Microsoft Entra Domain Services.
Tenga en cuenta que, si tiene que cambiar el tipo de sincronización de Todos a Con ámbito (o viceversa), el dominio administrado de Microsoft Entra Domain Services se debe eliminar, volver a crear y configurar. Además, como procedimiento recomendado, las organizaciones deben considerar el uso del aprovisionamiento "con ámbito" para reducir las identidades a solo aquellas que necesitan acceso a los recursos de Microsoft Entra Domain Services.
Objetos de directiva de grupo (GPO): para configurar GPO en un dominio administrado de Microsoft Entra Domain Services, debe usar herramientas de administración de directivas de grupo en un servidor unido al dominio administrado de Microsoft Entra Domain Services. Para obtener más información, consulte Administrar directiva de grupo en un dominio administrado de Microsoft Entra Domain Services.
LDAP seguro: Microsoft Entra Domain Services proporciona un servicio LDAP seguro que pueden usar las aplicaciones que lo requieran. Esta configuración está deshabilitada de forma predeterminada y, para habilitar LDAP seguro, es necesario cargar un certificado. Además, el NSG que protege la red virtual en la que se ha implementado Microsoft Entra Domain Services debe permitir la conectividad a través del puerto 636 con los dominios administrados de Microsoft Entra Domain Services. Para obtener más información, consulte Configuración de LDAP seguro para un dominio administrado de Microsoft Entra Domain Services.
Administración: para realizar tareas de administración en Microsoft Entra Domain Services (por ejemplo, unir máquinas virtuales a un dominio o editar GPO), la cuenta que se usa para esta tarea debe formar parte del grupo de administradores del controlador de dominio de Microsoft Entra. Las cuentas que son miembros de este grupo no pueden iniciar sesión directamente en controladores de dominio para realizar tareas de administración. En su lugar, cree una máquina virtual de administración unida al dominio administrado de Microsoft Entra Domain Services y, a continuación, instale las herramientas de administración de AD DS habituales. Para obtener más información, consulte Conceptos de administración para cuentas de usuario, contraseñas y administración en Microsoft Entra Domain Services.
Hash de contraseña: para que funcione la autenticación con Microsoft Entra Domain Services, los valores hash de contraseña de todos los usuarios deben tener un formato adecuado para la autenticación Kerberos y el Administrador de NT LAN (NTLM). Para asegurarse de que la autenticación con Microsoft Entra Domain Services funciona según lo previsto, es necesario cumplir los siguientes requisitos previos.
Usuarios sincronizados con Microsoft Entra Connect (desde AD DS): deben sincronizarse los valores hash de contraseña heredados de la instancia local de AD DS en Microsoft Entra ID.
Usuarios creados en Microsoft Entra ID: es necesario restablecer su contraseña para que se generen los valores hash correctos para usarlos con Microsoft Entra Domain Services. Para obtener más información, consulte Tutorial: Habilitación de la sincronización de contraseñas en Azure Active Directory Domain Services para entornos híbridos.
Red: Microsoft Entra Domain Services se implementa en una red virtual de Azure, por lo que es necesario tener en cuenta diferentes aspectos para asegurarse de que los servidores y las aplicaciones estén protegidos y puedan acceder correctamente al dominio administrado. Para obtener más información, consulte Consideraciones de diseño y opciones de configuración de red virtual para Microsoft Entra Domain Services.
Microsoft Entra Domain Services debe implementarse en su propia subred. No use una subred actual ni una subred de puerta de enlace.
Grupo de seguridad de red (NSG): se crea durante la implementación de un dominio administrado de Microsoft Entra Domain Services. Dicho grupo de seguridad de red contiene las reglas necesarias para la correcta comunicación del servicio. No cree ni use un grupo de seguridad de red existente con sus propias reglas personalizadas.
Microsoft Entra Domain Services requiere entre 3 y 5 direcciones IP: asegúrese de que el intervalo de direcciones IP de la subred puede proporcionar este número de direcciones. La restricción de las direcciones IP disponibles puede impedir que Microsoft Entra Domain Services mantenga dos controladores de dominio.
Servidor DNS de red virtual: como se ha explicado antes acerca del modelo de "concentrador y radio", es importante tener el DNS configurado correctamente en las redes virtuales para asegurarse de que los servidores unidos al dominio administrado de Microsoft Entra Domain Services tienen la configuración de DNS correcta para resolver el dominio administrado de Microsoft Entra Domain Services. Cada red virtual tiene una entrada de servidor DNS que se pasa a los servidores a medida que obtienen una dirección IP, y estas entradas DNS deben ser las direcciones IP del dominio administrado de Microsoft Entra Domain Services. Para más información, consulte Actualización de la configuración de DNS para la red virtual de Azure.
Desafíos: en la lista siguiente, se resaltan los desafíos clave en el uso de esta opción para el aislamiento de identidad.
Algunas opciones de configuración de Microsoft Entra Domain Services solo se pueden administrar desde un servidor unido a Microsoft Entra Domain Services.
Solo se puede implementar un dominio administrado de Microsoft Entra Domain Services por inquilino de Microsoft Entra. Como se explica en esta sección, se recomienda el modelo de concentrador y radio para proporcionar la autenticación de Microsoft Entra Domain Services a servicios de otras redes virtuales.
Es posible que se requiera más infraestructura para la administración de las implementaciones de aplicación de revisiones y software. Las organizaciones deben considerar la posibilidad de implementar Azure Update Management, una directiva de grupo (GPO) o System Center Configuration Manager (SCCM) para administrar estos servidores.
Para este modelo aislado, se da por supuesto que no hay conectividad con la red virtual que hospeda el dominio administrado de Microsoft Entra Domain Services desde la red corporativa del cliente y que no hay confianzas configuradas con otros bosques. Debe crearse un jumpbox o un servidor de administración para permitir un punto desde el que se pueda administrar Microsoft Entra Domain Services.
Inicio de sesión en máquinas virtuales de Azure usando la autenticación de Microsoft Entra
Cuando hay algún requisito para implementar cargas de trabajo de IaaS en Azure que requieren aislamiento de identidad, la última opción es usar Microsoft Entra ID para iniciar sesión en servidores en este escenario. Esto proporciona la capacidad de convertir Microsoft Entra ID en el dominio de identidad para fines de autenticación y el aislamiento de identidad se puede lograr aprovisionando servidores en la suscripción pertinente, que está vinculada al inquilino de Microsoft Entra ID necesario. Se deben tener en cuenta las siguientes consideraciones.
Sistemas operativos compatibles: actualmente se admite el inicio de sesión en máquinas virtuales de Azure usando la autenticación de Microsoft Entra en Windows y Linux. Para obtener más detalles sobre los sistemas operativos compatibles, consulte la documentación para Windows y Linux.
Credenciales: una de las principales ventajas de iniciar sesión en máquinas virtuales de Azure usando la autenticación de Microsoft Entra es la capacidad de iniciar sesión en las máquinas virtuales con las mismas credenciales federadas o administradas de Microsoft Entra que normalmente se usan para acceder a los servicios de Microsoft Entra.
Nota:
El inquilino de Microsoft Entra que se usa para el inicio de sesión en este escenario es el que está asociado a la suscripción en la que se ha aprovisionado la máquina virtual. Este inquilino de Microsoft Entra puede ser uno que tenga identidades sincronizadas desde la instancia local de AD DS. Las organizaciones deben tomar una decisión informada que esté en línea con sus entidades de seguridad de aislamiento cuando eligen la suscripción y el inquilino de Microsoft Entra que desean usar para iniciar sesión en estos servidores.
Requisitos de red: estas máquinas virtuales tendrán que acceder a Microsoft Entra ID para la autenticación, por lo que debe asegurarse de que la configuración de red de las máquinas virtuales permite el acceso de salida a los puntos de conexión de Microsoft Entra en el puerto 443. Consulte la documentación correspondiente a Windows y Linux para obtener más información.
Control de acceso basado en roles (RBAC): hay dos roles RBAC disponibles para proporcionar el nivel de acceso adecuado a estas máquinas virtuales. Estos roles RBAC se pueden configurar mediante Azure Portal o mediante la experiencia de Azure Cloud Shell. Para más información, consulte Configuración de asignaciones de roles para la máquina virtual.
Inicio de sesión de administrador de máquina virtual: los usuarios que tienen asignado este rol pueden iniciar sesión en una máquina virtual de Azure con privilegios de administrador.
Inicio de sesión de usuario de máquina virtual: los usuarios que tienen asignado este rol pueden iniciar sesión en una máquina virtual de Azure con los privilegios de un usuario normal.
Acceso condicional: una ventaja principal del uso de Microsoft Entra ID para iniciar sesión en máquinas virtuales de Azure es la capacidad de exigir el acceso condicional como parte del proceso de inicio de sesión. Esto proporciona la capacidad de que las organizaciones requieran que se cumplan las condiciones antes de permitir el acceso a la máquina virtual y usar la autenticación multifactor para proporcionar una autenticación sólida. Para más información, consulte Inicio de sesión en una máquina virtual Windows en Azure mediante Azure AD.
Nota:
La conexión remota a máquinas virtuales unidas a Microsoft Entra ID solo se permite desde equipos con Windows 10, Windows 11 y PC en la nube que estén unidos a Microsoft Entra o tengan una unión híbrida a Microsoft Entra en el mismo directorio que la máquina virtual.
Desafíos: en la lista siguiente, se resaltan los desafíos clave en el uso de esta opción para el aislamiento de identidad.
No hay administración ni configuración centralizada de los servidores. Por ejemplo, no hay ningún directiva de grupo que se pueda aplicar a un grupo de servidores. Las organizaciones deben considerar la posibilidad de implementar Update Management en Azure para administrar la aplicación de revisiones y las actualizaciones de estos servidores.
No es adecuado para aplicaciones de varios niveles que tienen requisitos para autenticarse con mecanismos locales, como la autenticación integrada de Windows, en estos servidores o servicios. Si este es un requisito de la organización, se recomienda explorar la opción de Active Directory Domain Services independiente o los escenarios de Microsoft Entra Domain Services descritos en esta sección.
Para este modelo aislado, se supone que no hay conectividad con la red virtual que hospeda las máquinas virtuales desde la red corporativa del cliente. Se debe crear un jumpbox o un servidor de administración para permitir un punto desde el que se puedan administrar estos servidores.