Control del acceso a IoT Hub con firmas de acceso compartido
IoT Hub usa tokens de firma de acceso compartido (SAS) para autenticar dispositivos y servicios para evitar el envío de claves en la conexión. Use tokens de SAS para conceder acceso limitado en el tiempo a dispositivos y servicios para funcionalidades específicas de IoT Hub. A fin de obtener autorización para conectarse a IoT Hub, los dispositivos y servicios deben enviar tokens de SAS firmados con un acceso compartido o una clave simétrica. Las claves simétricas se almacenan con una identidad del dispositivo en el registro de identidades.
En este artículo se presentan:
- Los distintos permisos que puede conceder a un cliente para acceder a IoT Hub.
- Los tokens que IoT Hub usa para comprobar los permisos.
- Cómo definir el ámbito de las credenciales para limitar el acceso a recursos específicos.
- Los mecanismos de autenticación de dispositivo personalizado que utilizan los registros de identidad de dispositivo o los esquemas de autenticación.
Nota
Algunas de las características que se mencionan en este artículo, como la mensajería de la nube al dispositivo, los dispositivos gemelos y la administración de dispositivos, solo están disponibles en el nivel estándar de IoT Hub. Para obtener más información sobre los niveles Básico y Estándar o Gratis de IoT Hub, consulte Elección del nivel adecuado de IoT Hub para la solución.
IoT Hub usa permisos para conceder acceso a cada uno de los puntos de conexión de IoT Hub. Los permisos limitan el acceso a un centro de IoT en función de la funcionalidad. Debe tener los permisos adecuados para acceder a cualquiera de los puntos de conexión de IoT Hub. Por ejemplo, un dispositivo debe incluir un token que contiene las credenciales de seguridad junto con cada mensaje que se envía a IoT Hub. Sin embargo, las claves de firma, como las claves simétricas del dispositivo, nunca se envían durante la conexión.
Autenticación y autorización
La autenticación es el proceso de demostrar que es quien dice ser. La autenticación comprueba la identidad de un usuario o dispositivo en IoT Hub. A veces se acorta a AuthN. La autorización es el proceso de confirmar permisos para un usuario o dispositivo autenticado en IoT Hub. Especifica los recursos y comandos a los que puede acceder y lo que puede hacer con esos recursos y comandos. A veces, la autorización se acorta a AuthZ.
En este artículo se describe la autenticación y la autorización mediante firmas de acceso compartido, lo que le permite agrupar permisos y concederlos a las aplicaciones mediante claves de acceso y tokens de seguridad firmados. También puede usar claves simétricas o claves de acceso compartido para autenticar un dispositivo con IoT Hub. Los tokens de SAS proporcionan autenticación para cada llamada realizada por el dispositivo a IoT Hub asociando la clave simétrica a cada llamada.
Permisos y control del acceso
Use las directivas de acceso compartido para acceder al nivel de centro de IoT, y use las credenciales de dispositivo individuales para otorgar acceso solamente a ese dispositivo.
Directivas de acceso compartido de nivel de centro de IoT
Las directivas de acceso compartido pueden conceder cualquier combinación de los permisos. Puede definir directivas en Azure Portal, mediante la programación del uso de las API REST de recursos de IoT Hubo mediante el comando Azure CLI az iot hub policy. Un Centro de IoT recién creado tiene las siguientes directivas predeterminadas:
| Directiva de acceso compartido | Permisos |
|---|---|
| iothubowner | Todos los permisos |
| service | Permisos ServiceConnect |
| device | Permisos DeviceConnect |
| registryRead | Permisos RegistryRead |
| registryReadWrite | PermisosRegistryRead y RegistryWrite |
Puede usar los siguientes permisos para controlar el acceso a IoT Hub:
Los servicios en la nube de back-end usan el permiso ServiceConnect y concede el siguiente acceso:
- Acceso a puntos de conexión de comunicación y supervisión orientados al servicio en la nube.
- Reciba mensajes de dispositivo a nube, envíe mensajes de nube a dispositivo y recupere las confirmaciones de entrega correspondientes.
- Recuperar confirmaciones de entrega para cargas de archivos.
- Acceda a los gemelos para actualizar etiquetas y propiedades deseadas, recuperar las propiedades notificadas y ejecutar consultas.
Los dispositivos usan el permisoDeviceConnect y concede el siguiente acceso:
- Acceso a puntos de conexión orientados al dispositivo.
- Envíe mensajes de dispositivo a nube y reciba mensajes de nube a dispositivo.
- Realice la carga de archivos.
- Reciba las notificaciones de propiedades deseadas del dispositivo gemelo y actualice las propiedades notificadas del dispositivo gemelo.
Los servicios en la nube de back-end usan el permiso RegistryRead y concede el siguiente acceso:
- Acceso de lectura al registro de identidades. Para más información, consulte Registro de identidades.
Los servicios en la nube de back-end usan el permiso RegistryReadWrite y concede el siguiente acceso:
- Acceso de lectura y escritura al registro de identidades. Para más información, consulte Registro de identidades.
Credenciales de seguridad de cada dispositivo
Cada centro de IoT tiene un registro de identidades que almacena información acerca de los dispositivos y módulos que pueden conectarse a él. Para que un dispositivo o un módulo se pueda conectar, debe haber una entrada para ese dispositivo o módulo en el registro de identidades del centro de IoT. Un dispositivo o un módulo se puede autenticar en el centro de IoT en función de las credenciales almacenadas en el registro de identidades.
Al registrar un dispositivo para usar la autenticación de tokens de SAS, ese dispositivo obtiene dos claves simétricas. Las claves simétricas conceden el permiso DeviceConnect para la identidad de dispositivo asociada.
Uso de tokens de SAS desde servicios
Los servicios pueden generar tokens de SAS mediante una directiva de acceso compartido que defina los permisos adecuados, tal como se explicó anteriormente en la sección Control de acceso y permisos.
Por ejemplo, un servicio que usa la directiva de acceso compartido creada previamente denominada registryRead crearía un token con los parámetros siguientes:
- URI de recurso:
{IoT hub name}.azure-devices.net, - clave de firma: una de las claves de la directiva
registryRead, - nombre de la directiva:
registryRead, - cualquier fecha de expiración.
Por ejemplo, el código siguiente crea un token de SAS en Node.js:
var endpoint = "myhub.azure-devices.net";
var policyName = 'registryRead';
var policyKey = '...';
var token = generateSasToken(endpoint, policyKey, policyName, 60);
El resultado, que concede acceso para leer todas las identidades de dispositivo en el registro de identidades, sería:
SharedAccessSignature sr=myhub.azure-devices.net&sig=JdyscqTpXdEJs49elIUCcohw2DlFDR3zfH5KqGJo4r4%3D&se=1456973447&skn=registryRead
Para obtener más ejemplos, vea Generación de tokens de SAS.
En el caso de los servicios, los tokens de SAS solo conceden permisos en el nivel de IoT Hub. Es decir, un servicio autenticado con un token basado en la directiva de servicio podrá realizar todas las operaciones concedidas por el permiso ServiceConnect. Estas operaciones incluyen la recepción de mensajes de dispositivo a nube, el envío de mensajes de nube a dispositivo, etc. Si desea conceder acceso más pormenorizados a los servicios, por ejemplo, limitar un servicio solo a enviar mensajes de nube a dispositivo, puede usar Microsoft Entra ID. Para obtener más información, vea Autenticación con Microsoft Entra ID.
Uso de tokens de SAS desde dispositivos
Existen dos maneras de obtener permisos DeviceConnect con IoT Hub mediante tokens de SAS: con una clave de dispositivo simétrica del registro de identidades o una clave de acceso compartido.
Toda la funcionalidad accesible desde los dispositivos se expone por diseño en los puntos de conexión con el prefijo /devices/{deviceId}.
Los puntos de conexión del dispositivo son (con independencia del protocolo):
| Punto de conexión | Funcionalidad |
|---|---|
{iot hub name}/devices/{deviceId}/messages/events |
Envío de mensajes de dispositivo a nube. |
{iot hub name}/devices/{deviceId}/messages/devicebound |
Recepción de mensajes de nube a dispositivo |
Uso de una clave simétrica en el registro de identidades
Cuando se utiliza la clave simétrica de la identidad de un dispositivo para generar un token, el elemento policyName (skn) del token se omite.
Por ejemplo, un token creado para tener acceso a toda la funcionalidad de dispositivo debe tener los siguientes parámetros:
- URI de recurso:
{IoT hub name}.azure-devices.net/devices/{device id}, - clave de firma: cualquier clave simétrica de la identidad
{device id}, - ningún nombre de directiva,
- cualquier fecha de expiración.
Por ejemplo, el código siguiente crea un token de SAS en Node.js:
var endpoint ="myhub.azure-devices.net/devices/device1";
var deviceKey ="...";
var token = generateSasToken(endpoint, deviceKey, null, 60);
El resultado, que concede acceso a todas las funcionalidades del dispositivo1, sería:
SharedAccessSignature sr=myhub.azure-devices.net%2fdevices%2fdevice1&sig=13y8ejUk2z7PLmvtwR5RqlGBOVwiq7rQR3WZ5xZX3N4%3D&se=1456971697
Para obtener más ejemplos, vea Generación de tokens de SAS.
Use una directiva de acceso compartida para acceder en nombre de un dispositivo
Cuando cree un token a partir de una directiva de acceso compartido, establezca el campo skn en el nombre de la directiva. Esta directiva debe conceder el permiso DeviceConnect.
Los dos escenarios principales para utilizar directivas de acceso compartido para tener acceso a la funcionalidad del dispositivo son:
- puertas de enlace del protocolo en la nube,
- servicios de token usados para implementar esquemas de autenticación personalizados.
Dado que la directiva de acceso compartido potencialmente puede conceder acceso para conectarse como cualquier dispositivo, es importante usar el URI de recurso correcto al crear tokens de SAS. Esto es especialmente importante para los servicios de token, que tienen que definir el ámbito de token para un dispositivo específico mediante el identificador URI del recurso. Este punto es menos relevante para puertas de enlace de protocolo, puesto que ya están mediando el tráfico para todos los dispositivos.
Por ejemplo, un servicio de token mediante la directiva de acceso compartido creada previamente denominada dispositivo crearía un token con los parámetros siguientes:
- URI de recurso:
{IoT hub name}.azure-devices.net/devices/{device id}, - clave de firma: una de las claves de la directiva
device, - nombre de la directiva:
device, - cualquier fecha de expiración.
Por ejemplo, el código siguiente crea un token de SAS en Node.js:
var endpoint ="myhub.azure-devices.net/devices/device1";
var policyName = 'device';
var policyKey = '...';
var token = generateSasToken(endpoint, policyKey, policyName, 60);
El resultado, que concede acceso a todas las funcionalidades del dispositivo1, sería:
SharedAccessSignature sr=myhub.azure-devices.net%2fdevices%2fdevice1&sig=13y8ejUk2z7PLmvtwR5RqlGBOVwiq7rQR3WZ5xZX3N4%3D&se=1456971697&skn=device
Una puerta de enlace de protocolo podría usar el mismo token para todos los dispositivos estableciendo el URI del recurso en myhub.azure-devices.net/devices.
Para obtener más ejemplos, vea Generación de tokens de SAS.
Cree un servicio de token para integrar dispositivos existentes
Puede usar el registro de identidades de loT Hub para configurar credenciales de seguridad por dispositivo o por módulo y el control de acceso mediante tokens. Si una solución IoT ya tiene un registro de identidad personalizado y un esquema de autenticación, considere la posibilidad de crear un servicio de token para integrar esta infraestructura con IoT Hub. De este modo, puede usar otras características de IoT en la solución.
Un servicio de token es un servicio en la nube personalizado. Usa una directiva de acceso compartido de IoT Hub con los permisos DeviceConnect para crear tokens centrados en el dispositivo o centrados en el módulo. Estos tokens permiten que un dispositivo o un módulo se conecten al centro de IoT.
Estos son los pasos principales del modelo de servicio de tokens:
Cree una directiva de acceso compartido de IoT Hub con el permiso DeviceConnect para su centro de IoT. Puede crear esta directiva en Azure Portal o mediante programación. El servicio de tokens usará esta directiva para firmar los tokens que crea.
Cuando un dispositivo o módulo necesita acceder al centro de IoT, solicita un token firmado desde el servicio de tokens. El dispositivo se puede autenticar mediante el esquema de autenticación o registro de identidades personalizado para determinar la identidad del dispositivo o módulo que el servicio de token usa para crear el token.
El servicio de token devuelve un token. El token se crea mediante
/devices/{deviceId}o/devices/{deviceId}/modules/{moduleId}comoresourceURI, condeviceIdcomo dispositivo autenticado ymoduleIdcomo módulo autenticado. El servicio de token usa la directiva de acceso compartido para construir el token.El dispositivo o el módulo usan el token directamente con el centro de IoT.
Nota
Puede usar la clase .NET SharedAccessSignatureBuilder o la clase de Java IotHubServiceSasToken para crear un token en el servicio correspondiente.
El servicio de token puede establecer la caducidad de los tokens como desee. Cuando expira el token, el centro de IoT interrumpe la conexión del dispositivo o del módulo. A continuación, el dispositivo o el módulo deben solicitar un nuevo token al servicio de token. Un tiempo de expiración corto aumenta la carga tanto en el dispositivo o el módulo como en el servicio de token.
Para que un dispositivo o módulo se conecte al centro, debe agregarlo al registro de identidades de IoT Hub aunque esté usando un token y no una clave para conectarse. Por tanto, puede continuar usando el control de acceso por dispositivo o por módulo habilitando o deshabilitando las identidades del dispositivo o módulo en el registro de identidades. Esto mitiga los riesgos de usar tokens con tiempos de expiración largos.
Comparación con una puerta de enlace personalizada
El modelo de servicio de token es el método recomendado para implementar un esquema de autenticación o registro de identidades personalizado en Azure IoT Hub. Este modelo se recomienda porque IoT Hub sigue controlando la mayoría del tráfico de la solución. Hay casos, sin embargo, en los que el esquema de autenticación personalizado está tan imbricado con el protocolo que se necesita una puerta de enlace personalizada que procese todo el tráfico. Un ejemplo de este escenario es usar Seguridad de la capa de transporte (TLS) y claves precompartidas (PSK). Para más información, consulte Uso de un dispositivo IoT Edge como puerta de enlace.
Generación de tokens de SAS
Los SDK de Azure IoT generan automáticamente tokens, pero algunos escenarios requieren que genere y use tokens de SAS directamente, entre los que se incluyen:
El uso directo de las superficies MQTT, AMQP o HTTPS.
La implementación del patrón de servicio de token, como se explica en la sección Creación de un servicio de token.
Un token firmado con una clave de acceso compartido concede acceso a toda la funcionalidad asociada con los permisos de la directiva de acceso compartido. Un token firmado con una clave simétrica de identidad del dispositivo solo concede el permiso DeviceConnect para la identidad del dispositivo asociado.
En esta sección se proporcionan ejemplos de generación de tokens SAS en distintos lenguajes de código. También puede generar tokens de SAS con el comando de extensión de la CLI az iot hub generate-sas-tokeno la extensión Azure IoT Hub para Visual Studio Code.
Estructura de tokens de SAS
Un token de SAS tiene el formato siguiente:
SharedAccessSignature sig={signature-string}&se={expiry}&skn={policyName}&sr={URL-encoded-resourceURI}
Estos son los valores esperados:
| Value | Descripción |
|---|---|
| {signature} | Una cadena de firma HMAC-SHA256 con el formato: {URL-encoded-resourceURI} + "\n" + expiry. Importante: La clave se descodifica en base64 y se utiliza para realizar el cálculo de HMAC-SHA256. |
| {resourceURI} | Prefijo del identificador URI (por segmento) de los puntos de conexión a los que se puede obtener acceso con este token, que comienza por un nombre de host de IoT Hub (sin protocolo) Los tokens de SAS concedidos a los servicios back-end se limitan al nivel del centro de IoT; por ejemplo, myHub.azure-devices.net. Los tokens de SAS concedidos a los dispositivos deben tener como ámbito un dispositivo individual; por ejemplo, myHub.azure-devices.net/devices/device1. |
| {expiry} | Cadenas UTF8 para el número de segundos transcurridos desde el tiempo 00:00:00 UTC el 1 de enero de 1970. |
| {URL-encoded-resourceURI} | Codificación de dirección URL en minúsculas del URI del recurso en minúsculas |
| {policyName} | El nombre de la directiva de acceso compartido a la que hace referencia este token. Ausente en caso de que el token haga referencia a las credenciales del registro de dispositivos. |
el prefijo URI se calcula por segmento y no por carácter. Por ejemplo, /a/b es un prefijo para /a/b/c pero no para /a/bc.
El código siguiente genera un token de SAS mediante el URI del recurso, la clave de firma, el nombre de la directiva y el período de expiración. Las secciones siguientes detallan cómo inicializar las entradas diferentes para los distintos casos de uso de token.
var generateSasToken = function(resourceUri, signingKey, policyName, expiresInMins) {
resourceUri = encodeURIComponent(resourceUri);
// Set expiration in seconds
var expires = (Date.now() / 1000) + expiresInMins * 60;
expires = Math.ceil(expires);
var toSign = resourceUri + '\n' + expires;
// Use crypto
var hmac = crypto.createHmac('sha256', Buffer.from(signingKey, 'base64'));
hmac.update(toSign);
var base64UriEncoded = encodeURIComponent(hmac.digest('base64'));
// Construct authorization string
var token = "SharedAccessSignature sr=" + resourceUri + "&sig="
+ base64UriEncoded + "&se=" + expires;
if (policyName) token += "&skn="+policyName;
return token;
};
Detalles específicos de protocolo
Cada protocolo admitido, como MQTT, AMQP y HTTPS, transporta tokens de diferentes maneras.
Al utilizar MQTT, el paquete CONNECT tiene deviceId como ClientId, {iothubhostname}/{deviceId} en el campo Nombre de usuario y un token SAS en el campo Contraseña. {iothubhostname} debe ser el CName completo del centro de IoT (por ejemplo, myhub.azure-devices.net).
Al usar AMQP, IoT Hub admite SASL PLAIN y AMQP Claims-Based-Security.
En el caso de la seguridad basada en notificaciones AMQP, la norma especifica cómo transmitir estos tokens.
Para SASL PLAIN, el nombre de usuario puede ser:
{policyName}@sas.root.{iothubName}si usa tokens de nivel de centro de IoT.{deviceId}@sas.{iothubname}si usa tokens de ámbito por el dispositivo.
En ambos casos, el campo password contiene el token, como se describe en estructura de tokens de SAS.
HTTPS implementa la autenticación mediante la inclusión de un token válido en el encabezado de solicitud Authorization.
Por ejemplo, nombre de usuario (DeviceId distingue entre mayúsculas y minúsculas): iothubname.azure-devices.net/DeviceId
Contraseña (puede generar un token de SAS con el comando de extensión de la CLI az iot hub generate-sas-token o la extensión de Azure IoT Hub para Visual Studio Code):
SharedAccessSignature sr=iothubname.azure-devices.net%2fdevices%2fDeviceId&sig=kPszxZZZZZZZZZZZZZZZZZAhLT%2bV7o%3d&se=1487709501
Nota
Los SDK de Azure IoT generan tokens automáticamente cuando se conectan al servicio. En algunos casos, los SDK IoT de Azure no admiten todos los protocolos o todos los métodos de autenticación.
Consideraciones especiales para SASL PLAIN
Cuando se usa SASL PLAIN con AMQP, un cliente que se conecta a una instancia de IoT Hub puede usar un token único para cada conexión TCP. Cuando el token expira, la conexión TCP se desconecta del servicio y desencadena una reconexión. Este comportamiento, aunque no resulta problemático para una aplicación de back-end, es perjudicial para una aplicación de dispositivo por las razones siguientes:
Las puertas de enlace normalmente se conectan en nombre de muchos dispositivos. Cuando se usa SASL PLAIN, tienen que crear una conexión TCP distintiva para cada dispositivo que se conecta a un centro de IoT. Este escenario aumenta considerablemente el consumo de energía y de recursos de red, y aumenta la latencia de cada conexión de dispositivo.
Los dispositivos con recursos restringidos se ven afectados negativamente por el aumento del uso de recursos para volver a conectarse después de cada expiración del token.
Pasos siguientes
Ahora que ha aprendido a controlar el acceso a IoT Hub, puede interesarle los siguientes temas de la Guía del desarrollador de IoT Hub: