Reemplace los perfiles de service principal por service principals

Si la solución usa perfiles de entidad de servicio principal (SPP) y su identidad, gobernanza, API o limitaciones operativas restringen sus requisitos, esta guía le ayuda a evaluar e implementar un reemplazo basado en entidades de servicio principal de Microsoft Entra dedicadas. Si la solución basada en perfiles existente cumple sus requisitos, puede seguir usándola.

Para los clientes que eligen migrar, en esta guía se recomienda la identidad administrada y las credenciales federadas cuando se cumplen los requisitos de hospedaje y confianza. La autenticación directa de la entidad de seguridad de servicio sigue siendo una alternativa. Ambas rutas de acceso proporcionan identidades de clientes dedicadas para la gobernanza de directorios, la supervisión de inicio de sesión independiente y el acceso a los servicios admitidos más allá de las interfaces basadas en perfiles.

Nota

Si va a crear una nueva aplicación, comience con multiinquilinato con entidades de servicio principal dedicadas, luego siga el patrón de identidad y la guía de implementación. Las fases de inventario y retirada de perfiles solo se aplican a las aplicaciones basadas en perfiles existentes.

¿Por qué migrar desde perfiles?

Considere la posibilidad de reemplazar perfiles cuando las siguientes limitaciones limiten su solución:

• Los perfiles no se ajustan a los procedimientos recomendados de Microsoft Entra ID para las identidades de carga de trabajo que se pueden controlar. Un perfil no tiene ninguna representación en Microsoft Entra ID. No genera registros de inicio de sesión independientes, no puede llevar su propia directiva de acceso condicional y no puede regirse por las herramientas usadas para el resto del entorno de identidades.

Por ejemplo, no se puede configurar un perfil como la identidad de una conexión de Direct Lake desde un modelo semántico a un lakehouse o warehouse. Tampoco puede concederle acceso como una identidad independiente de Microsoft Entra a otros servicios posteriores a los que la aplicación o sus cargas de trabajo necesitan acceder. Una entidad de seguridad de servicio dedicada puede recibir esos permisos siempre que el servicio lo admita.

No puede usar perfiles con las API rest de Fabric. Los perfiles solo son compatibles con la API REST compatible con el perfil, su SDK de .NET y las interfaces XMLA/TOM compatibles. Las API rest de Fabric no admiten perfiles y no se planea la compatibilidad. Use una identidad admitida para esas llamadas API en lugar de un perfil. La creación de un service principal dedicado aborda el requisito de identidad, pero cada API y operación debe seguir admitiendo esa identidad y concederle los permisos necesarios.

• La autenticación permanece vinculada a la identidad principal. Cuando el elemento principal usa un secreto o certificado, proteja y rote esa credencial. El patrón de reemplazo recomendado evita las credenciales de aplicación del cliente almacenadas. Los perfiles también pueden usar un elemento primario con identidad administrada, por lo que la autenticación sin secretos por sí sola no requiere reemplazar perfiles. Una identidad administrada primaria no proporciona a los perfiles identidades de directorio independientes ni compatibilidad más amplia con API.

Los perfiles resuelven un problema de escalado, no un problema de identidades independientes. Una entidad de servicio principal primaria puede crear hasta 100 000 perfiles, y cada perfil puede acceder a o crear hasta 1000 áreas de trabajo. Una propia entidad de seguridad de servicio puede pertenecer a 1000 áreas de trabajo como máximo en este modelo. En su lugar, las identidades de cliente dedicadas consumen Microsoft Entra objetos de directorio. Valide los límites aplicables según su número de clientes antes de confirmar la migración.

Nota

Límite de seguridad: Un perfil no es un límite criptográfico para el cliente: su entidad de servicio puede actuar a través de cualquiera de sus perfiles. El patrón recomendado también permite que la identidad administrada en tiempo de ejecución se autentique como cualquier aplicación cliente que confíe en ella. Los permisos de área de trabajo y recursos siguen siendo el límite de autorización impuesto. Proteja el runtime y la asignación de cliente a identidad en cualquiera de los modelos.

Otras limitaciones de perfil que se deben tener en cuenta

Limitation	Impacto de la migración
Sin auditoría independiente ni identidad de política	Un perfil no tiene un registro de inicio de sesión independiente de Microsoft Entra ni un destino de acceso condicional de identidad de carga de trabajo. Las entidades de seguridad de servicio dedicadas proporcionan esas funcionalidades, según la elegibilidad de la directiva y la licencia.
Acoplamiento permanente entre el perfil y el padre	Los perfiles no se pueden transferir a otra entidad de servicio principal padre. Reemplazar el elemento principal requiere nuevos perfiles, nuevos permisos del espacio de trabajo y asociaciones de clientes actualizadas.
Sin portal de administración de identidades	Los perfiles son solo de API y no se representan en las herramientas de administración de Microsoft Entra. Las aplicaciones dedicadas y las entidades de seguridad de servicio tienen funciones de visibilidad y administración del directorio.

El patrón de identidad administrada y de credenciales federadas

Use este patrón para una nueva solución de principal dedicado o cuando elija reemplazar perfiles, siempre que el entorno de ejecución cumpla los requisitos de hospedaje de identidad administrada.

El modelo

Asigne a cada cliente una entidad de servicio real Microsoft Entra y use la identidad administrada de la aplicación como origen de aserción. Este enfoque reemplaza tanto la credencial de aplicación compartida como la abstracción del perfil. Puede registrar, controlar y evaluar la identidad de cada cliente para el acceso condicional de identidad de carga de trabajo, y puede llamar a las API REST de Fabric admitidas.

Este enfoque es la ruta de migración recomendada en la que sus requisitos de hospedaje en Azure y de confianza se ajustan a la solución. Quita las credenciales de aplicación del cliente almacenadas y sus procesos de rotación sin cambiar dónde se aplica la autorización del espacio de trabajo y de los recursos.

La arquitectura muestra las operaciones en tiempo de ejecución de la aplicación, tres identidades de aplicación de cliente y relaciones de confianza, y las relaciones uno a uno entre espacios de trabajo del cliente. Representa la disposición predeterminada del entorno de ejecución compartido, no un nuevo límite de aislamiento.

Figura 1. Una identidad administrada de aplicación se autentica como entidades de servicio de clientes dedicados.

Cómo funciona

1. Identidad administrada de la aplicación. Asigne una identidad administrada asignada por el usuario a la aplicación ISV que se ejecuta en servicios de proceso de Azure compatibles, como App Service, Container Apps, una carga de trabajo de AKS configurada correctamente o una máquina virtual. Use una identidad administrada para la aplicación, no una por cliente. No tiene permisos de área de trabajo de cliente ni de servicio de destino propios; su rol aquí es solo para proporcionar una aserción.

2. Entidades de seguridad de servicio por cliente, usuario o grupo. Para cada límite de autorización o cliente existente, cree un registro de aplicaciones de Microsoft Entra y una entidad de servicio en el inquilino de directorio del ISV. Un cliente lógico no significa necesariamente un inquilino de Microsoft Entra independiente y no se requiere una identidad por usuario final a menos que el diseño de acceso existente lo requiera.

3. Credencial de identidad federada. Configure una credencial de identidad federada en cada registro de aplicación cliente para confiar en la identidad administrada de la aplicación. Después, el entorno de ejecución puede usar su token de identidad administrada como aserción para obtener un token de acceso para esa aplicación cliente sin un secreto de cliente o un certificado.

4. Intercambio de tokens en tiempo de ejecución. Cuando el usuario A o un trabajo específico del cliente invoca la aplicación, identifique al cliente A a través de una asignación del lado del servidor de confianza. Adquiera el token de identidad administrada con audiencia api://AzureADTokenExchange; intercambielo para un token de acceso como SP-A; después llame a las API de destino mediante el token de SP-A para administrar áreas de trabajo, realizar operaciones de recursos o solicitar tokens específicos de la aplicación cuando sea necesario.

   Para el intercambio en el paso anterior, el .NET Azure Identity ClientAssertionCredential acepta el token de identidad administrada como aserción de cliente. Se trata de un tipo de credencial de identidad Azure, no una clase MSAL. El token de acceso debe tener como destino la audiencia de la API de recursos, no la audiencia de intercambio de tokens.

5. Acceso al espacio de trabajo. Conceda a cada miembro o administrador de entidad de seguridad de servicio acceso solo a sus áreas de trabajo designadas cuando se necesiten esos roles o al rol admitido con menos privilegios para las operaciones necesarias. Esa concesión delimita el acceso a los recursos. Dado que la identidad administrada de la aplicación se puede autenticar como todas las aplicaciones de cliente que confían en ella, debe tratarla a ella y a sus hosts de proceso como identidades e infraestructuras de alto valor.

Por qué se recomienda esta ruta de acceso

• Menos credenciales de larga duración. No es necesario almacenar, recuperar ni distribuir ningún secreto de aplicación de cliente ni clave privada de certificado al entorno de ejecución.

• Menos trabajo de rotación. Azure administra las credenciales de identidad administrada y emite tokens de corta duración. No necesita un proceso de renovación de certificados o secretos independiente para cada aplicación del cliente que use esta relación de confianza.

• Incorporación uniforme. Aprovisione una aplicación de cliente y un service principal, defina la confianza explícita y conceda acceso a los recursos del cliente. Los nuevos clientes no requieren nuevas credenciales de larga duración.

Estas ventajas no eliminan la necesidad de administración de confianza, autorización de clientes, supervisión de auditoría o planeamiento de la capacidad del directorio.

Alternativa: autenticación directa del service principal

Si no desea usar la identidad administrada y las credenciales federadas, cree los mismos registros de aplicaciones de cliente dedicados y entidades de servicio, pero autentíquelos directamente con certificados u otra credencial de aplicación compatible. Se prefieren los certificados a los secretos de cliente cuando sea compatible. Proteja las claves privadas y los secretos, restrinja el acceso a ellas y automatice la rotación.

La autenticación directa conserva la visibilidad del directorio, los registros de inicio de sesión por usuario y el acceso a las API admitidas. No requiere el alojamiento de identidad administrada ni el acuerdo de confianza, pero no elimina las credenciales de cliente almacenadas.

Conceptos clave

Distinga la credencial que establece la confianza de los tokens usados en tiempo de ejecución.

Credenciales de identidad federada

Configura una credencial de identidad federada (FIC) en el registro de aplicación de Microsoft Entra que respalda la entidad de servicio del cliente. Define una relación de confianza con un emisor de tokens y especifica qué aserción acepta la aplicación en lugar de un secreto de cliente o certificado.

En esta arquitectura, la identidad de destino es la aplicación del cliente y la entidad de seguridad de servicio; la identidad administrada de la aplicación es el origen de la aserción. Este es el motivo por el que configura la credencial de cliente en el registro de la aplicación en lugar de en el objeto de la entidad de servicio o en la identidad administrada de origen.

Nota

Distinción de configuración: Las credenciales de identidad federada también se admiten en identidades administradas asignadas por el usuario en otros escenarios de federación. Esto no cambia el patrón aquí: configure la confianza en cada registro de la aplicación del cliente. Solo se admite una identidad administrada asignada por el usuario como origen de aserción de identidad administrada en el patrón de confianza de la aplicación descrito en esta guía.

Campo de confianza	Valor en la nube global
Issuer	https://login.microsoftonline.com/{directory-tenant-id}/v2.0
Subject	Identificador de entidad de seguridad (objeto) de la identidad administrada asignada por el usuario. No use el ID de cliente de este.
Público	api://AzureADTokenExchange

Cuando la aplicación presenta el token de identidad administrada y solicita un token de acceso para la aplicación cliente, Microsoft Entra ID valida la aserción con respecto a la credencial federada. El emisor, el asunto y la audiencia deben coincidir. Si la validación se realiza correctamente, emite un token de acceso que representa la entidad de servicio principal del cliente de destino para el recurso solicitado.

La identidad administrada y el registro de aplicaciones de confianza deben estar en el mismo tenant de Microsoft Entra. La audiencia de recursos es una opción independiente de la audiencia de aserción. Para Azure Identity, el ámbito global-cloud token-exchange es api://AzureADTokenExchange/.default; el ámbito de la API de destino suele ser el identificador de recursos seguido de /.default.

Flujo de intercambio de tokens: credenciales de cliente con una aserción federada

Este flujo implica tres participantes y seis pasos. SP-A es la aplicación y la entidad de servicio del cliente A. El token de aserción de identidad administrada y el token de acceso a recursos de SP-A devuelto sirven para diferentes propósitos.

Figura 2. Intercambio de tokens de credenciales de cliente respaldado por una aserción de identidad administrada.

1. Solicite el token de identidad administrada. La aplicación de Azure solicita un token de identidad administrada con la audiencia api://AzureADTokenExchange.

2. Devuelve el token de aserción. Microsoft Entra ID emite el token de identidad administrada, que la aplicación recibe a través de su mecanismo de identidad administrada del entorno de hospedaje Azure.

3. Envíe la solicitud de token de cliente. Envíe una solicitud al punto de conexión del inquilino de directorio /oauth2/v2.0/token con grant_type=client_credentials, client_id=<SP-A-client-id>, client_assertion=<MI-token>, y scope=<target-resource>/.default. La solicitud completa de OAuth también proporciona client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer; una biblioteca de identidades gestiona este parámetro.

4. Valide la afirmación. Microsoft Entra ID valida el token de identidad administrada con respecto a la credencial federada en el registro de aplicación de SP-A.

5. Devuelve el token de acceso del cliente. Microsoft Entra ID devuelve un token de acceso para SP-A con el recurso de destino como audiencia.

6. Llame a las API REST de destino. La aplicación envía el token de acceso de SP-A a la API de destino. No usa el token de aserción como token de acceso del recurso y no selecciona un perfil.

Comparación de arquitectura

La columna de reemplazo cubre las entidades de seguridad de servicio dedicadas por lo general. La identidad administrada y la federación son el método de autenticación recomendado, pero también es posible la autenticación directa mediante certificado u otros métodos de autenticación con credenciales admitidas.

Aspecto	Perfiles de service principal	Entidades de servicio dedicadas
Una identidad por cliente	Perfil lógico, no es un objeto de Microsoft Entra.	Registro de aplicaciones y entidad de seguridad de servicio que representa el límite de autorización del cliente.
Límite impuesto	Permisos de área de trabajo y recursos.	Permisos de área de trabajo y recursos.
Alcance de la identidad raíz	El service principal principal puede actuar como cualquiera de sus perfiles.	Un entorno de ejecución puede acceder a todas las identidades para las que tiene credenciales o aserciones de confianza; una MI puede autenticarse como cualquier aplicación que confíe en ella.
Rotación de secretos	Obligatorio cuando el elemento principal usa un secreto o certificado.	No es necesario para las credenciales de identidad administrada; necesario para certificados almacenados o secretos de cliente en la ruta de acceso directa.
Techo de escalado	Hasta 100 000 perfiles por SP primario; cada perfil hasta 1000 áreas de trabajo. La membresía propia del SP principal está limitada a 1.000 áreas de trabajo.	Registro de aplicaciones y service principal por cliente, sujeto a cuotas de objetos de directorio y límites de recursos de cada servicio de destino.
Registro de auditoría	Los identificadores de perfil pueden aparecer en los registros de recursos, pero los perfiles no tienen ningún registro de inicio de sesión independiente Microsoft Entra.	Microsoft Entra registros de inicio de sesión por service principal, correlacionados con los registros de auditoría de aplicaciones y recursos.
Acceso condicional	No hay ninguna directiva de identidad de carga de trabajo por perfil.	Disponible para entidades de servicio principales aptas con Id. de carga de trabajo de Microsoft Entra Premium; la directiva debe tener como destino cada entidad de servicio principal directamente.
Visibilidad del portal	No está representado en Microsoft Entra ID.	Registro de aplicaciones en Registros de aplicaciones; entidad de seguridad de servicio en aplicaciones empresariales.
compatibilidad con la API REST de Fabric	No es compatible; no está previsto ofrecer soporte.	Se admite donde la API y la operación específicas aceptan entidades de servicio administradas, con los permisos necesarios.
Transferencia de credenciales y acoplamiento con el elemento padre	No se puede transferir un perfil entre entidades de servicio principales primarias.	Se puede volver a configurar la confianza federada; las credenciales directas se pueden reemplazar sin volver a crear una abstracción de perfil.

Cómo leer esta tabla: ninguna disposición proporciona aislamiento criptográfico de los clientes. Los permisos de recursos controlan el acceso, y es posible que el entorno de ejecución tenga alcance indirecto entre los clientes. Los perfiles ofrecen una escalabilidad ligera de identidad. Las entidades de servicio dedicadas mejoran la gobernanza de directorios, la visibilidad del inicio de sesión y la compatibilidad de API. La ruta de acceso de federación e identidad administrada recomendada también quita las credenciales almacenadas de las aplicaciones de los clientes.

Ruta de migración

La ruta de acceso siguiente reemplaza los perfiles por entidades de seguridad dedicadas al servicio de atención al cliente. Mantenga las decisiones de migración y reversión independientes para cada cliente.

De perfiles a identidad administrada y credenciales federadas

Utilice las siguientes fases de migración con una pequeña cohorte piloto y un interruptor de despliegue por cliente. Mantenga la ruta de perfil disponible hasta que se complete la validación y el período de reversión acordado.

Fase 0: Creación de la identidad administrada de la aplicación

• Cree la identidad administrada asignada por el usuario para la aplicación y asígnela al recurso de cómputo. La guía de implementación muestra los comandos de creación y asignación.

• Registre el identificador principal (objeto). Las credenciales federadas de cada aplicación cliente usan este valor como sujeto. Registre también el identificador de cliente, el identificador de inquilino de directorio y el identificador de recurso de Azure.

Use una identidad administrada para la aplicación, no una por cliente. Una MI independiente para cada cliente no es necesaria en este patrón: la identidad del cliente es el service principal, y la MI proporciona la aserción. En el caso de implementaciones más grandes o un ámbito de riesgo menor, particione a los clientes en un pequeño número de identidades en tiempo de ejecución, cada una en la que solo confía su subconjunto asignado de aplicaciones de cliente.

Fase 1: Inventario

Enumerar todos los perfiles existentes a través de la API de administración de perfiles:

GET {profile-api-base}/v1.0/myorg/profiles

Para cada perfil, registre:

• Id. de perfil y nombre para mostrar, entidad de servicio principal primaria y asignación de clientes.

• Áreas de trabajo asociadas y asignaciones de roles.

• Modelos semánticos asociados o conjuntos de datos, informes y otros recursos.

• Conexiones, credenciales de origen de datos, dependencias de propiedad, trabajos en segundo plano y operaciones de API que dependen del perfil.

Antes de cambiar la configuración de un cliente, registre los roles de área de trabajo existentes, la propiedad del modelo semántico, las identidades de conexión, la configuración de credenciales y la asignación de cliente a perfil necesarias para la reversión de cambios. Registre referencias seguras a credenciales, no a valores secretos.

Registre el número total de clientes y compare los objetos de aplicación y los objetos de entidad de servicio necesarios con la cuota de objetos de directorio de Microsoft Entra antes de continuar. Valide también el límite de pertenencia a 1000 áreas de trabajo y los límites específicos de los recursos. Si la población supera la cuota de un solo directorio, planifique un aumento de cuota autorizado o administre deliberadamente el diseño de varios directorios; este patrón no lo resuelve automáticamente.

Nota

Notación de punto de conexión:{profile-api-base} denota la dirección URL base de la API REST compatible con el perfil existente que ya usa la solución. Mantenga esa dirección URL en la configuración de implementación. Estos ejemplos conservan las rutas de acceso de operación; reemplace todos los marcadores de posición antes de ejecutarlos. El término con reconocimiento de perfil describe la compatibilidad de la API, no un estado de desuso.

Fase 2: Aprovisionar nuevas identidades

Para cada perfil o grupo de perfiles que pertenecen al mismo límite de autorización del cliente:

1. Cree un registro de aplicación y una entidad de servicio administrada. Registre el identificador de cliente de la aplicación, el identificador de objeto de aplicación y el identificador de objeto de la entidad de servicio principal por separado.

2. Configure una credencial de identidad federada en el registro de aplicaciones del cliente que confíe en la identidad administrada de la aplicación creada en la fase 0.

3. Conceda a la nueva entidad de seguridad de servicio acceso a las mismas áreas de trabajo y recursos del mismo cliente. Utilice Member donde las operaciones inventariadas lo requieran o el rol admitido con privilegios mínimos. Conceda privilegios de administrador solo cuando sea necesario.

Mantenga los identificadores de recursos y del área de trabajo existentes cuando sea compatible. Una concesión de área de trabajo no transfiere automáticamente la propiedad de los recursos, las identidades de conexión ni las credenciales de origen de datos. Completa esas actualizaciones específicas del servicio antes del cambio.

Fase 3: Actualización del código de la aplicación

• Reemplace el encabezado de selección de perfil y la configuración del perfil del SDK por el intercambio de tokens con respaldo de identidad administrada para la aplicación cliente seleccionada.

• Actualice la asociación entre cliente e identidad en la base de datos de la aplicación.

antes de	después de
customerId -> profileId con una credencial de SP compartida y un encabezado de perfil.	customerId -> spClientId con la autenticación de entidad de servicio (SP) por cliente a través del intercambio de tokens de identidad administrada. Conserve también el identificador del inquilino del directorio, la configuración de autenticación y los identificadores de recursos permitidos.

Los identificadores de cliente son identificadores lógicos de los clientes de ISV, no necesariamente identificadores de inquilino de Microsoft Entra. Valide la membresía del cliente del usuario autenticado antes de seleccionar una identidad. Cachés de tokens de clave por tenant de directorio, identificador de cliente y recurso o ámbito.

• Actualice la generación de tokens específicos de la aplicación para usar el token de acceso del service principal del cliente. Si la solución inserta informes u otro contenido, actualice también esa generación de tokens; la inserción ya es una carga de trabajo que debe migrarse, no un requisito previo para esta guía.

• Actualice la administración del área de trabajo, las conexiones descendentes, el aprovisionamiento, los trabajos programados y todos los demás puntos de entrada mediante la configuración de perfil anterior.

Fase 4: Verificar

Para cada cliente, compruebe:

• El acceso al área de trabajo y a los recursos se realiza correctamente a través del nuevo service principal.

• La adquisición de tokens de identidad administrada y el intercambio de tokens federados se realizan correctamente para la aplicación del cliente prevista.

• Los tokens específicos de la aplicación se generan correctamente cuando se usan y los informes existentes u otro contenido incrustado se representan correctamente cuando corresponda.

• Los nuevos inicios de sesión de service principal aparecen en Microsoft Entra ID y se pueden correlacionar con los registros de auditoría de aplicaciones y recursos.

• Se deniega el acceso entre clientes: un llamante no puede seleccionar la identidad de aplicación o los identificadores de recursos de otro cliente.

Antes de la transición de producción, documente y pruebe el procedimiento de reversión para un cliente piloto. Incluya la restauración de la titularidad de cualquier modelo semántico, identidades de conexión, credenciales de origen de datos y permisos modificados durante la migración. Compruebe que el perfil anterior puede realizar sus operaciones necesarias después de la reversión, incluida la configuración de recarga y las actualizaciones de parámetros.

Cambie la ruta de la solicitud del cliente solo después de que se superen los criterios de aceptación. Supervise los fallos, el rendimiento y los permisos antes de expandir el despliegue.

Si la validación falla, detenga los trabajos en segundo plano afectados y restaure la configuración anterior mediante los procedimientos admitidos para cada servicio. Cambiar la ruta de la aplicación solo al perfil podría no restaurar operaciones que dependan de la propiedad o las credenciales. Después de restaurar la configuración necesaria, vuelva a la ruta basada en perfiles y compruebe el acceso a los recursos y las operaciones dependientes antes de reanudar los trabajos. Conserve los perfiles originales y los permisos necesarios durante el período de reversión.

Fase 5: Retirar perfiles

• Después del período de reversión, quite los permisos obsoletos del área de trabajo principal original y del perfil, después de confirmar que las entidades de servicio administradas del cliente dedicadas tienen el acceso necesario.

Elimine cada perfil migrado a través de la API de administración de perfiles:

DELETE {profile-api-base}/v1.0/myorg/profiles/{profileId}

• Opcionalmente, elimine el registro de aplicación compartido original y la entidad de servicio si ningún cliente, trabajo o carga de trabajo no relacionada los sigue usando. Retire las credenciales obsoletas y conserve las asignaciones de migración y los registros de auditoría según los requisitos de retención.

Nota

Migración alternativa sin MI o federación: Se recomienda la identidad administrada y las credenciales federadas, no obligatorias. Si no quiere usarlos, omita la fase 0. En la fase 2, configure un certificado u otra credencial admitida en cada aplicación cliente en lugar de una credencial federada. En las fases 3 y 4, obtenga y valide los tokens de acceso directamente como dicha aplicación. Mantenga el mismo inventario, asignaciones de recursos, autorización del cliente, implementación y retirada, y opere el almacenamiento y la rotación de credenciales seguras.

Guía de implementación

En esta guía se implementa la identidad administrada recomendada y el enfoque de credenciales federadas. La alternativa de autenticación directa sigue la misma configuración de identidad y permisos y se describe después de los pasos principales. CLI de Azure ejemplos usan la sintaxis de Bash; reemplace los marcadores de posición e inicie sesión en el directorio y la suscripción previstos antes de ejecutarlos.

Prerequisites

• Una suscripción y permisos de Azure para crear y asignar identidades administradas para la ruta de acceso recomendada.

• Permisos en Microsoft Entra ID para crear registros de aplicaciones y entidades de servicio y actualizar las credenciales de aplicación. Los permisos de recursos de Azure y los permisos de directorio son independientes.

• Una aplicación hospedada en servicios de proceso de Azure compatibles, como App Service, Container Apps, una carga de trabajo de AKS configurada correctamente o una máquina virtual. El origen de aserción respaldado por MI en este patrón depende de esa configuración de hospedaje de Azure.

• Permisos administrativos para conceder acceso a recursos y área de trabajo del cliente, configurar las opciones de servicio necesarias y conceder permisos de API o consentimiento cuando el servicio de destino los requiera.

• CLI de Azure está instalado y se ha iniciado sesión en el inquilino del directorio correcto. Confirme el contexto de la suscripción antes de crear recursos de Azure.

Configuración del entorno del desarrollador

Revise la configuración pertinente en la interfaz de administración del servicio en la configuración del arrendatario y la configuración del desarrollador. Limite el acceso de la entidad de servicio a un grupo de seguridad permitido que contiene las entidades de servicio del cliente. Para ver las etiquetas exactas y el comportamiento actual, consulte configuración del tenant de desarrollador.

Para cada configuración con ámbito de grupo requerida por la solución, agregue todas las entidades de servicio de cliente de reemplazo a un grupo de seguridad permitido antes de probar o realizar el cambio. El acceso concedido a la entidad de servicio principal original no autoriza automáticamente las entidades de seguridad de reemplazo. La configuración de acceso a la API pública se aplica tanto a las API REST compatibles con el perfil existentes como a las API rest de Fabric; la migración solo de la identidad no quita este requisito previo.

La siguiente configuración de la API pública usa una etiqueta neutral del producto; la interfaz de administración puede incluir el nombre del servicio.

Setting	Predeterminado publicado	Obligatorio cuando
Los service principals pueden llamar a las API públicas	Habilitado para nuevos clientes.	Las entidades de servicio llaman a las API REST compatibles con el perfil existentes o a las API REST de Fabric. Incluya cada entidad de seguridad suplente en el grupo de seguridad permitido cuando la configuración esté en el ámbito de grupo.
Las entidades de servicio pueden crear áreas de trabajo, conexiones e canalizaciones de implementación	Deshabilitado para los nuevos clientes.	La aplicación aprovisiona estos recursos.
Insertar contenido en aplicaciones	Habilitado en configuraciones existentes; compruebe su tenant.	La aplicación existente inserta contenido a través de las API REST aplicables.
Permitir que las entidades de servicio creen y usen perfiles	No asuma un valor predeterminado.	Solo mientras los clientes siguen usando la ruta de perfil; no es necesario para los clientes migrados.

Compruebe los valores reales en lugar de asumir los valores predeterminados. Los tenants nuevos y existentes pueden diferir, y los administradores pueden cambiar la configuración. Mantenga la configuración del perfil hasta que se migren todos los clientes y trabajos dependientes. No habilite la configuración de embedding para una carga de trabajo que no sea de embedding.

Paso 1: Crear y asignar la identidad administrada asignada por el usuario

Esta identidad administrada representa la aplicación ISV, no un cliente individual. Use un grupo de recursos existente:

az identity create \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --location "<azure-region>"

Registre su identificador de cliente, el identificador de entidad de seguridad (objeto), el identificador del inquilino del directorio y el identificador de recurso de Azure. Asígnelo al recurso de computación. Para una aplicación de App Service existente:

az webapp identity assign \
  --resource-group "<resource-group>" \
  --name "<web-app-name>" \
  --identities "<managed-identity-resource-id>"

Utilice el procedimiento de asignación de identidad correspondiente para otros servicios de proceso. Seleccione explícitamente esta identidad asignada por el usuario en el entorno de ejecución. Dado que la identidad es independiente del recurso de host, volver a implementar un host no requiere reemplazar todas las relaciones de confianza del cliente.

Paso 2: Crear un service principal para cada cliente

Para cada límite de seguridad de cliente, usuario o grupo que representan los perfiles existentes, cree un registro de aplicaciones y su entidad de seguridad de servicio. En este ejemplo se crea una aplicación de un solo tenant en el directorio del ISV:

APP_CLIENT_ID=$(az ad app create \
  --display-name "customer-a-application" \
  --sign-in-audience AzureADMyOrg \
  --query appId --output tsv)

az ad sp create --id "$APP_CLIENT_ID"

APP_OBJECT_ID=$(az ad app show \
  --id "$APP_CLIENT_ID" --query id --output tsv)

SP_OBJECT_ID=$(az ad sp show \
  --id "$APP_CLIENT_ID" --query id --output tsv)

Identificador	Uso
ID de cliente de la aplicación	Identifique la aplicación del cliente al solicitar un token de acceso.
Id. de objeto de aplicación	Configure la credencial federada en el registro de la aplicación.
Id. de objeto de la entidad de servicio	Conceda roles de área de trabajo o de recursos cuando la API requiera el identificador de objeto de la entidad de seguridad.

Nota

Credenciales de ruta de acceso recomendadas: No cree un secreto de cliente ni un certificado para esta ruta de autenticación. La confianza federada de la aplicación cliente proporciona el mecanismo de autenticación.

Paso 3: Configura las credenciales de identidad federada

Recupere el identificador de entidad de servicio de la identidad administrada y su identificador del tenant del directorio. Utilice el tenant de la identidad en lugar de asumir que una suscripción actual diferente tiene el mismo tenant:

MI_PRINCIPAL_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query principalId --output tsv)

DIRECTORY_TENANT_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query tenantId --output tsv)

Agregue una credencial de identidad federada a cada registro de aplicación de cliente. El siguiente comando global-cloud usa el identificador de objeto de aplicación del paso 2 y los valores de MI que acaba de recuperar:

az ad app federated-credential create \
  --id "$APP_OBJECT_ID" \
  --parameters "{
    \"name\": \"trust-application-mi\",
    \"issuer\": \"https://login.microsoftonline.com/$DIRECTORY_TENANT_ID/v2.0\",
    \"subject\": \"$MI_PRINCIPAL_ID\",
    \"audiences\": [\"api://AzureADTokenExchange\"],
    \"description\": \"Trust the ISV application managed identity\"
  }"

Como alternativa, guarde el mismo JSON con valores sustituidos en un archivo local credential.json y pase --parameters credential.json. Repita la configuración de confianza en cada aplicación del cliente. Permita la propagación de configuración antes de validar el intercambio de tokens.

Paso 4: Conceder a cada service principal acceso al área de trabajo

Agregue la entidad de seguridad del servicio al cliente como miembro o administrador solo a sus áreas de trabajo designadas en las que se requiera ese rol. Prefiere un rol admitido inferior si cumple los requisitos de operación. Esta concesión es lo que realmente determina el alcance del acceso del cliente a los recursos.

Use la interfaz de administración del área de trabajo o la operación REST de asignación de roles del área de trabajo. En el ejemplo siguiente se usan identificadores de recursos y API configurables. Requiere una identidad de aprovisionamiento autorizada; La propia instancia de MI en tiempo de ejecución no tiene permisos de recursos de cliente para el intercambio de tokens.

PROFILE_API_BASE="<existing-profile-aware-api-base-url>"
PROFILE_RESOURCE="<existing-api-resource-identifier>"
WORKSPACE_ID="<customer-workspace-id>"

TOKEN=$(az account get-access-token \
  --resource "$PROFILE_RESOURCE" \
  --query accessToken --output tsv)

curl --fail-with-body --request POST \
  "$PROFILE_API_BASE/v1.0/myorg/groups/$WORKSPACE_ID/users" \
  --header "Authorization: Bearer $TOKEN" \
  --header "Content-Type: application/json" \
  --data "{
    \"identifier\": \"$SP_OBJECT_ID\",
    \"groupUserAccessRight\": \"Member\",
    \"principalType\": \"App\"
  }"

Use el endpoint y la estructura de la solicitud documentados para el servicio que posee el área de trabajo existente. La operación mostrada se aplica a la API del área de trabajo compatible con el perfil; Otras API pueden usar esquemas de asignación de roles diferentes. No sustituya un identificador de cliente cuando la operación espera un identificador de objeto de service principal. Evite registrar tokens Bearer y permita la propagación de permisos.

Paso 5: Autentíquese y llame a las API en tiempo de ejecución

1. Obtenga el identificador de cliente de la aplicación del cliente autenticado y los recursos permitidos de la configuración del lado servidor de confianza.

2. Adquiera un token de aserción mediante la identidad administrada asignada por el usuario seleccionada y el ámbito api://AzureADTokenExchange/.default en la nube global.

3. Utilice el token de MI como aserción de cliente para la aplicación cliente. Solicite un token de acceso con el ámbito de la aplicación de la API de recursos, no con la audiencia de aserción.

4. Llame a la API de destino mediante ese token de acceso de aplicación de cliente y sin configuración de selección de perfil. Administre áreas de trabajo, solicite los tokens específicos de la aplicación necesarios y realice otras operaciones inventariadas a través de la identidad de cliente.

Para .NET, use Azure Identity ClientAssertionCredential con el token de identidad administrada como callback de aserción. El flujo de seis pasos y los ejemplos de configuración oficiales muestran el intercambio sin necesidad de un ejemplo de código de aplicación específico para integración.

Automatiza la incorporación y la retirada

Agrupe las cuatro operaciones de incorporación en la canalización de aprovisionamiento: cree el registro de la aplicación, cree su entidad de servicio, configure su confianza federada y conceda el rol de área de trabajo. Cree la ruta de baja correspondiente al mismo tiempo: quite las asignaciones de recursos, revoque la confianza o las credenciales obsoletas y elimine las identidades de aplicación solo después de comprobar las dependencias.

Implementación alternativa: Autenticar principales de servicio directamente

Si no desea usar MI y federación, omita los pasos 1 y 3. Complete el paso 2 para cada inquilino y configure una credencial de aplicación compatible en lugar de confianza federada.

Utilice un certificado donde se admita y siga las instrucciones de configuración de credenciales de aplicación. Cargue el certificado público, proteja la clave privada en un almacén de credenciales adecuado y automatice la renovación. Si es necesario un secreto de cliente, protéjalo y renuevelo antes de la expiración.

Complete el paso 4 con las mismas autorizaciones del cliente con privilegios mínimos. En el paso 5, use el ID de cliente del cliente y su credencial para solicitar directamente un token de acceso con credenciales de cliente. Mantenga el mismo enrutamiento de clientes, separación de caché de tokens, validación y controles de limpieza de migración.

Seguridad, limitaciones y consideraciones

Aplique los siguientes controles a la ruta de autenticación que seleccione y planee sus límites operativos.

Recomendaciones de seguridad

• Use una identidad administrada estable asignada por el usuario. Esto evita perder las relaciones de confianza de los clientes simplemente porque se reemplaza un recurso de computación. No use una identidad asignada por el sistema como origen de aserción para este patrón de confianza de aplicaciones.

• Trate la aplicación MI como una identidad con privilegios elevados. Puede autenticarse como cada aplicación de cliente que confíe en ella. Restrinja los derechos de implementación de procesos de cómputo, la asignación de identidad administrada, los propietarios de la aplicación y la administración de credenciales. Crear particiones de identidades en tiempo de ejecución si es necesario para reducir el alcance de una vulneración.

• No conceda a MI ningún permiso propio de atención al cliente. Es un origen de aserción; las entidades de seguridad del servicio al cliente reciben permisos del espacio de trabajo y del servicio descendente.

• Limite la configuración del inquilino con un grupo de seguridad. Incluya todos los service principals de cliente pertinentes en el grupo permitido en lugar de habilitar el acceso al service principal para toda la organización.

• Supervise y alerte sobre los inicios de sesión de cada entidad de servicio. Correlacione con los registros de aplicaciones y recursos. La recopilación de registros sin investigación ni alertas específicas del cliente no proporciona la ventaja operativa.

• Automatice la incorporación y la desvinculación de forma conjunta. La eliminación de roles de área de trabajo, la retirada de credenciales o confianzas, y la eliminación de entidades de servicio obsoletas debe ser tan controlada y repetible como su aprovisionamiento.

Mantenga los mapeos de clientes del lado del servidor, valide la pertenencia antes de seleccionar una identidad y rechace identificadores de recursos o identidades arbitrarios proporcionados por el cliente. La reutilización de tokens significa que un registro de inicio de sesión no es un registro de cada llamada API. No registre secretos, aserciones, tokens de acceso ni claves privadas de certificado.

Limitaciones y requisitos operativos

Consideration	Qué planificar
Límite máximo de escala en comparación con perfiles	Los perfiles permiten 100 000 por entidad de servicio principal primaria, con hasta 1000 áreas de trabajo por perfil. Los registros de aplicaciones dedicados y las entidades de servicio consumen objetos de directorio. Compruebe las cuotas de directorio, los límites del área de trabajo del service principal y el rendimiento de aprovisionamiento antes de confirmar.
Límite de credenciales federadas	Un registro de aplicación admite como máximo 20 credenciales de identidad federada. Normalmente, esta arquitectura necesita una por cada identidad administrada del entorno de ejecución de confianza en cada aplicación cliente, no una por cliente en una aplicación compartida.
Requisito del mismo tenant	La identidad administrada y cada registro de aplicación de confianza debe pertenecer al mismo tenant de Microsoft Entra. Además, el acceso a los recursos de otro tenant requiere una configuración de aplicación compatible, consentimiento y permisos de recursos.
Sin intercambio de tokens entre nubes	No intercambie tokens entre nubes de Azure diferentes, como la nube global y Gobierno de EE. UU. Use los puntos de conexión correctos de audiencia y autoridad dentro de la nube de destino.
requisito de cálculo de Azure	El flujo de aserción respaldado por identidad administrada requiere el mecanismo de identidad administrada de un entorno de hospedaje de Azure compatible. Si la aplicación se ejecuta en otro lugar o no desea usar este patrón, use la alternativa de autenticación directa u otro diseño de federación compatible.
Acceso condicional	Id. de carga de trabajo de Microsoft Entra Premium es necesario para crear o modificar directivas de acceso condicional de Workload ID. Las políticas cubren los principales de servicio aptos de un solo inquilino propiedad de la organización y deben dirigirse directamente a ellos. No cubren identidades administradas ni surten efecto simplemente a través de la pertenencia a grupos.
Configuración del entorno del desarrollador	Todas las entidades de servicio que usen una configuración de ámbito de grupo deben estar en su grupo de seguridad permitido. Revise los cuatro ajustes en los requisitos previos de implementación; no asuma los valores predeterminados.
Automation	La administración manual de cientos o miles de identidades de clientes no es práctica. Automatice el aprovisionamiento, los cambios de permisos, la supervisión, la rotación, las actualizaciones de confianza y la desvinculación. Controle la limitación con reintentos limitados y un intervalo de espera creciente.
Las experiencias exclusivas para delegados permanecen fuera del ámbito	Reemplazar perfiles no habilita la autenticación de solo aplicación cuando una carga de trabajo requiere tokens de usuario delegados. En la versión preliminar de inserción del panel de Real-Time, solo se admite ese tipo de elemento y la autenticación de usuario delegada; no se admiten tokens de solo aplicación ni de datos propios de la aplicación. La inserción de informes existente usa su mecanismo específico del servicio aplicable.

Consulte Microsoft Entra límites de servicio y la compatibilidad con la identidad de API del servicio de destino antes de finalizar la capacidad y los permisos.

Para conocer los límites de confianza actuales y el comportamiento de propagación, consulte consideraciones sobre las credenciales de identidad federada.

Para consultar la idoneidad actual de la directiva y las licencias, consulte Acceso condicional para identidades de carga de trabajo.

Use la audiencia api://AzureADTokenExchangeglobal de intercambio de tokens en la nube, la audiencia api://AzureADTokenExchangeUSGovdel Gobierno de EE. UU. o la audiencia api://AzureADTokenExchangeChinade China, según corresponda. Haga coincidir el extremo de autoridad con la nube. En los ejemplos de este artículo se usa la nube global.

Use las bibliotecas de identidades admitidas para el almacenamiento en caché y la actualización de tokens. Permita la propagación de confianza y permisos, vuelva a intentar errores transitorios con espera limitada e investigue los errores de coincidencia persistentes del emisor, el sujeto o la audiencia. Para la autenticación directa, rote los certificados y las claves secretas con un período de superposición y supervise la expiración.

No suponga que eliminar un perfil, quitar una credencial o cambiar una relación de confianza invalida instantáneamente los tokens emitidos anteriormente. Tenga en cuenta la duración del token y el comportamiento de autorización y revocación de cada servicio de recursos al planear la migración y retirada.

Contenido relacionado

Utilice estas referencias para permisos específicos de API, restricciones de identidad actuales y configuración de carga de trabajo existente.

Perfiles, entidades de seguridad de servicio y cargas de trabajo existentes

• Multitenencia con entidades de servicio dedicadas
• Perfiles de entidad de servicio: una solución multiarrendatario opcional
• Perfiles de entidad de seguridad de servicio para aplicaciones multiinquilinato
• Configurar una aplicación de contenido existente para usar una entidad de servicio
• Configuración del tenant del desarrollador
• Descripción general de la inserción de análisis existente
• Vista previa de inserción del panel de control en tiempo real para usuarios delegados

Federación de identidades de carga de trabajo e identidades administradas

• Información general sobre la federación de identidades de carga de trabajo
• Consideraciones y restricciones importantes para las credenciales de identidad federada
• Configuración de una aplicación para confiar en una identidad administrada
• Identidades administradas para recursos de Azure
• Ejemplos de configuración de federación

SDKs, APIs y límites de servicio

• Azure Identity ClientAssertionCredential para .NET
• Referencia de generación de tokens específica de la aplicación para cargas de trabajo de embeddings existentes
• Microsoft Entra límites y restricciones del servicio
• Identidades de aplicación admitidas para las API REST de Fabric
• Identidad de conexión y seguridad de Direct Lake
• Acceso condicional para identidades de tareas
• Operación de asignación de roles del área de trabajo
• API de administración de perfiles