Control del acceso a Azure IoT Hub Device Provisioning Service (DPS) mediante Microsoft Entra ID (versión preliminar)

Puede usar Microsoft Entra ID para autenticar las solicitudes a las API de Azure IoT Hub Device Provisioning Service (DPS), como crear una identidad de dispositivo e invocar un método directo. También puede usar el control de acceso basado en roles de Azure (RBAC de Azure) para autorizar esas mismas API del servicio. Al usar estas tecnologías de forma conjunta, puede conceder permisos para acceder a las API de Azure IoT Hub Device Provisioning Service (DPS) a una entidad de seguridad de Microsoft Entra. Esta entidad de seguridad podría ser un usuario, un grupo o una entidad de servicio de una aplicación.

La autenticación del acceso con Microsoft Entra ID y el control de permisos con RBAC de Azure proporcionan una mayor seguridad y facilidad de uso respecto a los tokens de seguridad. Para minimizar posibles problemas de seguridad inherentes a los tokens de seguridad, se recomienda usar Microsoft Entra ID con la instancia de Azure IoT Hub Device Provisioning Service (DPS) siempre que sea posible.

Nota:

La autenticación con Microsoft Entra ID no es compatible con las API de dispositivos de Azure IoT Hub Device Provisioning Service (DPS) (como registrar un dispositivo o consultar el estado de registro de un dispositivo). Use claves simétricas, X.509 o TPM para autenticar dispositivos en Azure IoT Hub Device Provisioning Service (DPS).

Autenticación y autorización

Cuando una entidad de seguridad de Microsoft Entra solicita el acceso a una API de Azure IoT Hub Device Provisioning Service (DPS), primero se autentica la identidad de la entidad de seguridad. Para realizar la autenticación, la solicitud debe contener un token de acceso de OAuth 2.0 en el entorno de ejecución. El nombre del recurso para solicitar el token es https://azure-devices-provisioning.net. Si la aplicación se ejecuta en un recurso de Azure, como una máquina virtual de Azure, una aplicación de función de Azure Functions o una aplicación de Azure App Service, se puede representar como una identidad administrada.

Una vez autenticada la entidad de Microsoft Entra, el siguiente paso es la autorización. En este paso, Azure IoT Hub Device Provisioning Service (DPS) usa el servicio de asignación de roles de Microsoft Entra para determinar qué permisos tiene la entidad de seguridad. Si los permisos de la entidad de seguridad coinciden con el recurso o la API solicitados, Azure IoT Hub Device Provisioning Service (DPS) autoriza la solicitud. Así, este paso exige que se asignen uno o varios roles de Azure a la entidad de seguridad. Azure IoT Hub Device Provisioning Service (DPS) proporciona algunos roles integrados que tienen grupos comunes de permisos.

Gestión del acceso a Azure IoT Hub Device Provisioning Service (DPS) mediante la asignación de roles de Azure RBAC

Con Microsoft Entra ID y RBAC, Azure IoT Hub Device Provisioning Service (DPS) requiere que la identidad que solicita acceso a la API tenga el nivel adecuado de permisos para la autorización. Para conceder permiso a la entidad de seguridad, asígnele también una asignación de roles.

Para garantizar los privilegios mínimos, asigne siempre el rol adecuado en el ámbito de recursos más bajo posible,que es probable que sea el ámbito de Azure IoT Hub Device Provisioning Service (DPS).

Azure IoT Hub Device Provisioning Service (DPS) proporciona los siguientes roles integrados de Azure para autorizar el acceso a las API DPS mediante Microsoft Entra ID y RBAC:

Rol Descripción
Colaborador de datos del servicio de aprovisionamiento de dispositivos Permite el acceso completo a las operaciones del plano de datos del servicio de aprovisionamiento de dispositivos.
Lector de datos del servicio de aprovisionamiento de dispositivos Permite el acceso de lectura completo a las propiedades del plano de datos del servicio de aprovisionamiento de dispositivos.

También puede definir roles personalizados para su uso con Azure IoT Hub Device Provisioning Service (DPS) mediante la combinación de los permisos que necesita. Para más información, consulte Creación de roles personalizados para el control de acceso basado en roles de Azure.

Claves de escritura y política de acceso compartido en el plano de control

La Microsoft.Devices/provisioningServices/write acción permite que un principal cree o actualice cualquier propiedad del recurso DPS, incluida la authorizationPolicies colección. Debido a que el contrato Azure Resource Manager (ARM) para CreateOrUpdate acepta valores suministrados primaryKeysecondaryKey por el caller y en cada política, un principal que se mantenga write en un recurso DPS puede:

  • Establece la clave primaria o secundaria de cualquier política de acceso compartido (incluida la política raíz provisioningserviceowner ) a un valor que elija, y luego autentica como esa política.
  • Rota las claves de cualquier directiva de acceso compartido, lo que invalida a los consumidores existentes.
  • Añadir una nueva política de acceso compartido con nombre con un valor clave elegido.

Por esta razón, Microsoft.Devices/provisioningServices/write es funcionalmente equivalente a la administración completa de las credenciales de política de acceso compartido del recurso, independientemente de si el principal también posee Microsoft.Devices/provisioningServices/listkeys/action o Microsoft.Devices/provisioningServices/listkey/action.

Importante

Un rol personalizado que concede Microsoft.Devices/provisioningServices/write en un recurso DPS sin conceder listkeys/actionno aísla la administración de credenciales de la configuración del recurso. La entidad sigue teniendo control total sobre el material de claves de la directiva de acceso compartido a través de la ruta de escritura. No confíes en este patrón para la configuración de privilegio mínimo.

Si necesitas separar la configuración de recursos de la administración de credenciales de políticas de acceso compartido, utiliza uno de los siguientes patrones en su lugar:

  • Prefiero la autenticación Microsoft Entra ID para el plano de datos. Asignar los roles integrados de Contribuidor de Datos del Servicio de Provisión de Dispositivos o Lector de Datos del Servicio de Aprovisionamiento de Dispositivos para la gestión de inscripciones, y desactivar el acceso por firma de acceso compartido en el recurso siempre que sea posible.
  • Restringe write en el ámbito del recurso. Como write implica control de claves, concedelo solo a los principales responsables en los que confíes con credenciales de política de acceso compartido.
  • Auditar la actividad del plano de control. Los cambios en authorizationPolicies realizados mediante la operación PUT del plano de control se registran en el registro de actividad de Azure con la operación Microsoft.Devices/provisioningServices/write. Revise estos eventos junto con los listkeys/action eventos al auditar el acceso a las credenciales.

Las mismas consideraciones se aplican a Azure IoT Hub. Para más detalles, consulta Control de acceso a IoT Hub usando Microsoft Entra ID.

Ámbito de recursos

Antes de asignar un rol de Azure RBAC a una entidad de seguridad, determine cuál debe ser el ámbito de acceso que debe tener la entidad de seguridad. Siempre es mejor conceder únicamente el ámbito más restringido posible. Los roles de Azure RBAC definidos en un ámbito más amplio los heredan los recursos que están debajo de ellos.

En la lista se describen los niveles en los que puede definir el ámbito de acceso a IoT Hub, empezando por el ámbito más restringido:

  • Azure IoT Hub Device Provisioning Service (DPS). En este ámbito, una asignación de roles se aplica al servicio Azure IoT Hub Device Provisioning (DPS). No se admite la asignación de roles en ámbitos más pequeños, como el grupo de inscripción o la inscripción individual.
  • El grupo de recursos. En este ámbito, se aplica una asignación de roles a todos los centros de IoT del grupo de recursos.
  • Suscripción. En este ámbito, se aplica una asignación de roles a todos los centros de IoT de todos los grupos de recursos de la suscripción.
  • Un grupo de administración. En este ámbito, una asignación de roles se aplica a todos los centros de IoT de todos los grupos de recursos, en todas las suscripciones del grupo de administración.

Permisos para las API de Azure IoT Hub Device Provisioning Service (DPS)

En las tablas siguientes se describen los permisos disponibles para las operaciones de API de Azure IoT Hub Device Provisioning Service (DPS). Para permitir que un cliente llame a una operación determinada, asegúrese de que el rol RBAC asignado del cliente ofrezca permisos suficientes para esa operación.

Acción de RBAC Descripción
Microsoft.Devices/provisioningServices/attestationmechanism/details/action Obtener los detalles del mecanismo de atestación
Microsoft.Devices/provisioningServices/enrollmentGroups/read Lee grupos de inscripción
Microsoft.Devices/provisioningServices/enrollmentGroups/write Escribe grupos de inscripción
Microsoft.Devices/provisioningServices/enrollmentGroups/delete Elimina grupos de inscripción
Microsoft.Devices/provisioningServices/enrollments/read Ver inscripciones
Microsoft.Devices/provisioningServices/enrollments/write Escribe inscripciones
Microsoft.Devices/provisioningServices/enrollments/delete Elimina inscripciones
Microsoft.Devices/provisioningServices/registrationStates/read Lee estados de registro
Microsoft.Devices/provisioningServices/registrationStates/delete Elimina estados de registro

Extensión de Azure IoT para la CLI de Azure

La mayoría de los comandos de Azure IoT Hub Device Provisioning Service (DPS) admiten la autenticación de Microsoft Entra. Puede controlar el tipo de autenticación que se usa para ejecutar comandos mediante el parámetro --auth-type, que acepta los valores key o login. El valor predeterminado es key.

  • Cuando --auth-type tiene el valor key, la CLI detecta automáticamente una directiva adecuada al interactuar con Azure IoT Hub Device Provisioning Service (DPS).

  • Cuando --auth-type tiene el valor login, se utiliza un token de acceso de la entidad de seguridad que ha iniciado sesión en la CLI de Azure para llevar a cabo la operación.

  • Los comandos siguientes admiten actualmente --auth-type:

    • az iot dps enrollment
    • az iot dps enrollment-group
    • az iot dps registration

Para obtener más información, consulte la página de versiones de la extensión de Azure IoT para la CLI de Azure.

SDK y ejemplos

Acceso de Microsoft Entra ID desde Azure Portal

Nota:

El acceso a Microsoft Entra ID desde Azure Portal no está disponible actualmente durante la versión preliminar.

Pasos siguientes

  • Se actualizó por última vez el