Control de acceso basado en rol para Microsoft Foundry

En este artículo, aprenderá los conceptos básicos del control de acceso basado en roles (RBAC) para Microsoft Foundry, incluidos los ámbitos, los roles integrados y los patrones de asignación de empresa comunes.

Para obtener más información sobre la autenticación y autorización en Microsoft Foundry, consulte Authentication and Authorization.

Asignaciones de roles mínimas para comenzar

Para los nuevos usuarios de Azure y Microsoft Foundry, comiencen con estas asignaciones mínimas para que el principal de usuario y la identidad administrada del proyecto puedan acceder a las funcionalidades de Foundry.

Puede comprobar las asignaciones actuales mediante Verificar acceso para un usuario a un único recurso de Azure.

• Asigne el rol de Usuario de Foundry en su recurso de Foundry a su entidad de seguridad de usuario.

  Importante

  Recientemente se cambió el nombre de los roles RBAC de Foundry. Foundry User, Foundry Owner, Foundry Account Owner y Foundry Project Manager se llamaban anteriormente Usuario de Azure AI, Propietario de Azure AI, Propietario de la cuenta de Azure AI y Administrador de proyectos de Azure AI. Es posible que siga viendo los nombres anteriores en algunos lugares mientras se implementa el cambio de nombre. El cambio de nombre no modifica los identificadores de rol y los permisos principales.

• Asigne el rol Usuario de Foundry del recurso de Foundry a la identidad administrada del proyecto.

Si el usuario que creó el proyecto puede asignar roles (por ejemplo, si tiene el Azure Owner rol en el ámbito de suscripción o grupo de recursos), ambas asignaciones se agregan automáticamente.

Para asignar estos roles manualmente, siga estos pasos rápidos.

Asignar un rol a la entidad de servicio de usuario

En el portal de Azure, abra el recurso Foundry y vaya a Control de acceso (IAM). Cree una asignación de rol para Foundry User, configure Miembros como Usuario, grupo o entidad de servicio, seleccione su usuario y, a continuación, seleccione Revisar y asignar.

Asignación de un rol a la identidad administrada del proyecto

En el portal de Azure, abra el proyecto Foundry y vaya a Control de acceso (IAM). Cree una asignación de roles para Foundry User, establezca Miembros en Identidad administrada, seleccione la identidad administrada del proyecto y, a continuación, seleccione Revisar y asignar.

Terminología del control de acceso basado en rol en Foundry

Para comprender el control de acceso basado en rol en Microsoft Foundry, considere dos preguntas para su empresa.

• ¿Qué permisos quiero que tenga mi equipo al compilar en Microsoft Foundry?
• ¿En qué ámbito quiero asignar permisos a mi equipo?

Para ayudar a responder a estas preguntas, estas son descripciones de cierta terminología que se usa en este artículo.

• Permisos: acciones permitidas o denegadas que una identidad puede realizar en un recurso, como leer, escribir, eliminar o administrar las operaciones del plano de control y del plano de datos.
• Scope: conjunto de recursos de Azure a los que se aplica una asignación de roles. Entre los ámbitos típicos se incluyen la suscripción, el grupo de recursos, el recurso Foundry o el proyecto Foundry.
• Role: una colección nominada de permisos que define qué acciones se pueden realizar en los recursos de Azure en un ámbito determinado.

Una identidad obtiene un rol con permisos específicos en un ámbito seleccionado en función de los requisitos empresariales.

En Microsoft Foundry, considere dos ámbitos al completar las asignaciones de roles.

• Recurso de Foundry: ámbito de nivel superior que define el límite administrativo, de seguridad y de monitorización de un entorno de Microsoft Foundry.
• Proyecto foundry: un sub-ámbito dentro de un recurso Foundry usado para organizar el trabajo y aplicar el control de acceso para las API, herramientas y flujos de trabajo de desarrollador de Foundry.

Roles integrados

Un rol integrado en Foundry es un rol creado por Microsoft que cubre escenarios comunes de acceso que puedes asignar a los miembros de tu equipo. Entre los roles integrados clave que se usan en Azure se incluyen Propietario, Colaborador y Lector. Estos roles no son específicos de los permisos de recursos de Foundry.

En el caso de los recursos de Foundry, utilice roles integrados adicionales para seguir los principios de acceso de privilegio mínimo. En la tabla siguiente se enumeran los roles integrados clave para Foundry con enlaces a las definiciones exactas de estos roles en roles integrados de IA + Machine Learning.

Permisos para cada rol integrado

Use la tabla siguiente para ver los permisos permitidos para cada rol integrado en Microsoft Foundry.

Utilice la tabla siguiente para ver los permisos para cada uno de los roles clave integrados de Azure (Propietario, Colaborador, Lector).

Para publicar agentes, necesitas el rol Foundry Project Manager como mínimo en el ámbito de recursos de Foundry. Para obtener más información, consulte Agent applications in Microsoft Foundry.

Use estas pestañas para explorar las diferencias entre los roles integrados, asignados en el nivel de recursos de Foundry (excepto el propietario, que se asigna en el nivel de suscripción).

Ejemplos de asignaciones de RBAC empresarial para proyectos

Este es un ejemplo de cómo implementar el control de acceso basado en rol (RBAC) para un recurso de Enterprise Foundry.

Administrar asignaciones de roles

Para administrar roles en Foundry, debe tener permiso para asignar y quitar roles en Azure. El rol integrado Azure Owner incluye ese permiso. Puede asignar roles a través del portal de Foundry (página Administrador), Azure IAM del portal o CLI de Azure. Puede quitar roles mediante Azure portal IAM o CLI de Azure.

En el portal de Foundry, administre los permisos mediante:

1. Abra la página Administrador en Foundry y, a continuación, seleccione Operar>administrador.
2. Seleccione el nombre del proyecto.
3. Seleccione Agregar usuario para administrar el acceso al proyecto. Esta acción solo está disponible si tiene permisos de asignación de roles.
4. Aplique el mismo flujo para el acceso a nivel de recurso en Foundry.

Puede administrar permisos en el portal Azure en Access Control (IAM) o mediante CLI de Azure.

Por ejemplo, el siguiente comando asigna el rol de usuario de Foundry a [email protected] en el grupo de recursos this-rg de la suscripción 00000000-0000-0000-0000-000000000000:

az role assignment create --role "53ca6127-db72-4b80-b1b0-d745d6d5456d" --assignee "[email protected]" --scope /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/this-rg 

Creación de roles personalizados para proyectos

Si los roles integrados no cumplen los requisitos empresariales, cree un rol personalizado que permita un control preciso sobre las acciones y ámbitos permitidos. Esta es una definición de rol personalizada de nivel de suscripción de ejemplo:

{
  "properties": {
    "roleName": "My Enterprise Foundry User",
    "description": "Custom role for Foundry at my enterprise to only allow building Agents. Assign at subscription level.",
    "assignableScopes": ["/subscriptions/<your-subscription-id>"],
    "permissions": [ { 
        "actions": ["Microsoft.CognitiveServices/*/read", "Microsoft.Authorization/*/read", "Microsoft.CognitiveServices/accounts/listkeys/action","Microsoft.Resources/deployments/*"], 
        "notActions": [], 
        "dataActions": ["Microsoft.CognitiveServices/accounts/AIServices/agents/*"], 
        "notDataActions": []     
    } ]
  }
}

Para obtener más información sobre cómo crear un rol personalizado, consulte los artículos siguientes.

• Azure Portal
• CLI de Azure
• Azure PowerShell
• Desactivar características en versión preliminar en Microsoft Foundry. En este artículo se proporcionan más detalles sobre los permisos específicos de Foundry en el control y el plano de datos que puede usar al crear roles personalizados.

Notas y limitaciones

• Para ver y purgar las cuentas de Foundry eliminadas, debe tener asignado el rol Colaborador en el ámbito de la suscripción.

• Los usuarios con el rol Colaborador pueden implementar modelos en Foundry.

• Necesita el rol Propietario en el permiso del recurso para crear roles personalizados en el recurso.

• Si tienes permisos para asignar roles en Azure (por ejemplo, el rol Propietario asignado en el ámbito de la cuenta) a tu identidad de usuario, y implementas un recurso de Foundry desde Azure Portal o desde la interfaz de usuario del portal de Foundry, el rol Usuario de Foundry se asigna automáticamente a tu identidad de usuario. Esta asignación no se aplica al implementar Foundry desde el SDK o la CLI.

  Importante

  Recientemente se cambió el nombre de los roles RBAC de Foundry. Foundry User, Foundry Owner, Foundry Account Owner y Foundry Project Manager se llamaban anteriormente Usuario de Azure AI, Propietario de Azure AI, Propietario de la cuenta de Azure AI y Administrador de proyectos de Azure AI. Es posible que siga viendo los nombres anteriores en algunos lugares mientras se implementa el cambio de nombre. El cambio de nombre no modifica los identificadores de rol y los permisos principales.

• Al crear un recurso Foundry, los permisos integrados de control de acceso basado en rol (RBAC) proporcionan acceso al recurso. Para usar los recursos creados fuera de Foundry, asegúrese de que el recurso tiene permisos que le permiten acceder a ellos. A continuación se incluyen algunos ejemplos:

  • Para usar una nueva cuenta de Azure Blob Storage, agregue la identidad administrada del recurso de cuenta de Foundry al rol Lector de datos de Storage Blob en esa cuenta de almacenamiento.
  • Para usar un nuevo origen de Búsqueda de Azure AI, agregue Foundry a las asignaciones de roles de Búsqueda de Azure AI.

• Para ajustar un modelo en Foundry, necesita permisos de plano de datos y de plano de control. La implementación de un modelo afinado es un permiso del plano de control. Por lo tanto, el único rol integrado con permisos de plano de datos y de plano de control es el rol Propietario de Foundry. O bien, si lo prefiere, también puede asignar el rol Usuario de Foundry para los permisos del plano de datos y el rol Propietario de la cuenta de Foundry para los permisos del plano de control.

Permisos específicos del tipo de implementación

En las secciones siguientes se describe la superficie de permisos para tipos de implementación específicos. Úselas junto con las tablas de roles integradas en Permisos para cada rol integrado al planear asignaciones de roles para una carga de trabajo determinada.

Operaciones del plano de control de la computación administrada

Las implementaciones de proceso administrado (versión preliminar) se rigen por su propio conjunto de operaciones del proveedor de recursos de Azure en el proveedor Microsoft.CognitiveServices. Estas operaciones controlan quién puede crear, leer, actualizar y eliminar una implementación de proceso administrado, y quién puede leer la capacidad de acelerador disponible y el uso de cuota de una cuenta de Foundry.

En esta sección se enumeran las cinco operaciones de plano de control necesarias, los roles integrados que los conceden y cómo la asignación de roles a permisos difiere de las implementaciones estándar (pago por token y PTU).

Operaciones necesarias

Se requieren cinco operaciones para administrar por completo las implementaciones de proceso administrado en una cuenta de Foundry:

Asignación de roles a permisos

En la tabla siguiente se muestran los roles integrados que otorgan cada una de las cinco operaciones del plano de control de cómputo administrado.

Los roles integrados de Azure Propietario y Colaborador otorgan acceso a las cinco operaciones mediante la concesión de acción de comodín sobre la suscripción o el grupo de recursos.

Comparación: implementaciones estándar frente a implementaciones de proceso administradas

El conjunto de permisos del plano de control para las implementaciones de proceso administrado refleja el de las implementaciones estándar (pago por token y PTU); los nombres de las operaciones solo difieren en el segmento del tipo de recurso (deployments vs managedComputeDeployments, y modelCapacities vs managedComputeCapacities).

En la tabla siguiente se resume cómo se compara la cobertura CRUD de cada rol en las dos familias de implementación:

Asignaciones de roles recomendadas

Use los siguientes puntos de partida al asignar acceso a estas operaciones con computación administrada:

• Implemente y opere implementaciones de proceso administrado: asigne Colaborador de Cognitive Services en el ámbito de la cuenta de Foundry.
• Visor de solo lectura para implementaciones y cuotas: asigne Usuario de Cognitive Services o Usuario de Foundry en el ámbito de la cuenta de Foundry.
• Gestionar un proyecto de Foundry, pero no desplegar modelos: asigne Foundry Project Manager en el ámbito de la cuenta de Foundry. Los administradores de proyecto pueden leer los despliegues y la cuota, pero no pueden crearlos ni eliminarlos.
• Llame una implementación de proceso administrado con Microsoft Entra ID durante la inferencia: asigne Usuario de Foundry en el ámbito de la cuenta de Foundry, además de cualquier rol del plano de control que tenga el usuario (o sin ningún rol del plano de control para los usuarios solo de inferencia).

Para ver el flujo de trabajo de implementación de un extremo a otro, consulte Implementación de modelos de código abierto con proceso administrado.

Contenido relacionado

• Cree un proyecto.
• Verificar acceso de un usuario a un recurso único de Azure.
• Autenticación y autorización en Foundry.
• Desactivar características en versión preliminar en Microsoft Foundry.
• Referencia de permisos del agente hospedado.

Apéndice

Ejemplos de aislamiento de acceso

Cada organización puede tener requisitos de aislamiento de acceso diferentes en función de los roles de usuario de su empresa. El aislamiento de acceso hace referencia a los roles asignados a los usuarios de la empresa, ya sea para separar los permisos mediante nuestros roles integrados o para usar un rol unificado y con permisos elevados. Hay tres opciones de aislamiento de acceso para Foundry que puede seleccionar para su organización en función de los requisitos de aislamiento de acceso.

Sin aislamiento de acceso. Esto significa que en su empresa no tiene ningún requisito para separar los permisos entre un desarrollador, un administrador de proyectos o un administrador. Los permisos para estos roles se pueden asignar entre equipos.

Por lo tanto, deberías...

• Conceda a todos los usuarios de la empresa el rol de Propietario de Foundry en el ámbito del recurso

  Importante

  Recientemente se cambió el nombre de los roles RBAC de Foundry. Foundry User, Foundry Owner, Foundry Account Owner y Foundry Project Manager se llamaban anteriormente Usuario de Azure AI, Propietario de Azure AI, Propietario de la cuenta de Azure AI y Administrador de proyectos de Azure AI. Es posible que siga viendo los nombres anteriores en algunos lugares mientras se implementa el cambio de nombre. El cambio de nombre no modifica los identificadores de rol y los permisos principales.

Aislamiento de acceso parcial. Esto significa que el administrador de proyectos de su empresa debe poder desarrollar dentro de proyectos, así como crear proyectos. Pero los administradores no deben poder desarrollarse en Foundry, solo crear cuentas y proyectos de Foundry.

Por lo tanto, deberías...

• Conceda al administrador el rol de Propietario de cuenta de Foundry en el ámbito del recurso
• Otorgue a su desarrollador y a sus gestores de proyectos el rol de Foundry Project Manager en el recurso

Aislamiento de acceso total. Esto significa que los administradores, los administradores de proyectos y los desarrolladores tienen permisos claros asignados que no se superponen para sus diferentes funciones dentro de una empresa.

Por lo tanto, deberías...

• Conceda a su administrador el rol de Foundry Account Owner en el ámbito del recurso
• Asigne a su desarrollador el rol Lector en el ámbito del recurso de Foundry y Foundry User en el ámbito del proyecto
• Conceda al administrador de proyectos el rol de Administrador de proyectos de Foundry en el ámbito del recurso

Uso de grupos de Microsoft Entra con Foundry

Microsoft Entra ID proporciona varias maneras de administrar el acceso a recursos, aplicaciones y tareas. Mediante el uso de grupos de Microsoft Entra, puede conceder acceso y permisos a un grupo de usuarios en lugar de a cada usuario individual. Los administradores de TI empresariales pueden crear grupos de Microsoft Entra en el portal de Azure para simplificar el proceso de asignación de roles para los desarrolladores. Al crear un grupo de Microsoft Entra, puede minimizar el número de asignaciones de roles necesarias para los nuevos desarrolladores que trabajan en proyectos de Foundry asignando al grupo la asignación de roles necesaria en el recurso necesario.

Complete los pasos siguientes para usar Microsoft Entra ID grupos con Foundry:

1. Cree un grupo Security en Groups en el portal de Azure.
2. Agregue un propietario y las entidades de seguridad de usuario de su organización que necesiten acceso compartido.
3. Abra el recurso de destino y vaya a Control de acceso (IAM) .
4. Asigne el rol necesario a Usuario, grupo o principal de servicio y seleccione el nuevo grupo de seguridad.
5. Seleccione Revisar y asignar para que la asignación de roles se aplique a todos los miembros del grupo.

Ejemplos comunes:

• Para compilar agentes, ejecutar seguimientos y usar las funcionalidades principales de Foundry, asigne Foundry User al grupo de Microsoft Entra.
• Para usar las características de seguimiento y supervisión, asigne Lector en el recurso de Application Insights conectado al mismo grupo.

Para más información sobre Microsoft Entra ID grupos, requisitos previos y limitaciones, consulte:

• Aprende sobre grupos, membresía de grupos y acceso en Microsoft Entra.
• Cómo administrar grupos en Microsoft Entra.