Controlar o acesso a Hub IoT utilizando assinaturas de acesso partilhado

Este artigo descreve as opções para garantir o seu hub IoT. Hub IoT usa permissões para conceder acesso a cada ponto final do hub IoT. As permissões limitam o acesso a um hub IoT com base na funcionalidade.

Este artigo introduz:

  • As diferentes permissões que pode conceder a um cliente para aceder ao seu hub IoT.
  • Os tokens Hub IoT usa para verificar permissões.
  • Como estender credenciais para limitar o acesso a recursos específicos.
  • Mecanismos de autenticação de dispositivos personalizados que utilizam registos de identidade de dispositivos existentes ou esquemas de autenticação.

Nota

Algumas das funcionalidades mencionadas neste artigo, como mensagens cloud-to-device, gémeos de dispositivos e gestão de dispositivos, apenas estão disponíveis no nível padrão de Hub IoT. Para obter mais informações sobre os escalões básico e standard do Hub IoT, veja How to choose the right IoT Hub tier (Como escolher o escalão do Hub IoT certo).

Deve ter permissões adequadas para aceder a qualquer um dos Hub IoT pontos finais. Por exemplo, um dispositivo deve incluir um símbolo contendo credenciais de segurança, juntamente com todas as mensagens que envia para Hub IoT. No entanto, as teclas de assinatura, como as teclas simétricas do dispositivo, nunca são enviadas pelo fio.

Controlo de acesso e permissões

Utilize políticas de acesso partilhado para acesso ao nível do hub IoT e use as credenciais individuais do dispositivo para estender o acesso a esse dispositivo apenas.

Políticas de acesso partilhado ao nível do hub IoT

As políticas de acesso partilhado podem conceder qualquer combinação de permissões. Pode definir políticas no portal do Azure, programáticamente utilizando as APIs de recursos de Hub IoT ou utilizando a política az iot hub CLI. Um hub IoT recém-criado tem as seguintes políticas padrão:

Política de Acesso Partilhado Permissões
iothubowner Toda a permissão
serviço Permissões de ServiceConnect
dispositivo Permissões de DeviceConnect
registryRead Permissões RegistryRead
registryReadWrite RegistoRead e RegistoDesite

A tabela que se segue lista as permissões que pode utilizar para controlar o acesso ao seu hub IoT.

Permissão Notas
ServiceConnect Concede acesso a pontos finais de comunicação e monitorização de serviços na nuvem.
Concede permissão para receber mensagens de dispositivo para nuvem, enviar mensagens nuvem-para-dispositivo e recuperar os agradecimentos de entrega correspondentes.
Concede permissão para recuperar reconhecimentos de entrega para uploads de ficheiros.
Concede permissão para aceder a gémeos para atualizar tags e propriedades desejadas, recuperar propriedades reportadas e executar consultas.
Esta permissão é utilizada por serviços de nuvem de fundo.
DispositivoConnect Concede acesso a pontos finais virados para o dispositivo.
Concede permissão para enviar mensagens dispositivo-a-nuvem e receber mensagens nuvem-a-dispositivo.
Concede permissão para realizar upload de ficheiros a partir de um dispositivo.
Concede permissão para receber notificações de propriedade desejadas pelo dispositivo twin e atualizar propriedades reportadas pelo dispositivo twin.
Concede permissão para realizar uploads de ficheiros.
Esta permissão é utilizada por dispositivos.
RegistryRead Os subsídios lêem o acesso ao registo de identidade. Para mais informações, consulte o registo de identidade.
Esta permissão é utilizada por serviços de nuvem de fundo.
RegistroReadWrite Os subsídios lêem e escrevem acesso ao registo de identidade. Para mais informações, consulte o registo de identidade.
Esta permissão é utilizada por serviços de nuvem de fundo.

Credenciais de segurança por dispositivo

Cada Hub IoT contém um registo de identidade Para cada dispositivo neste registo de identidade, pode configurar credenciais de segurança que concedem permissões deviceConnect miradas aos pontos finais do dispositivo correspondentes.

Tokens SAS

Hub IoT utiliza fichas de assinatura de acesso partilhado (SAS) para autenticar dispositivos e serviços para evitar o envio de chaves no fio. As fichas SAS são limitadas na validade e âmbito do tempo. Os SDKs Azure IoT geram automaticamente fichas sem necessitar de qualquer configuração especial. Alguns cenários requerem que gere e use fichas SAS diretamente. Tais cenários incluem:

Utiliza fichas SAS para conceder acesso limitado a dispositivos e serviços com tempo para funcionalidades específicas em Hub IoT. Para obter autorização para se ligar a Hub IoT, os dispositivos e serviços devem enviar fichas SAS assinadas com uma chave de acesso partilhado ou simétrica. As chaves simétricas são armazenadas com uma identidade do dispositivo no registo de identidade.

Estrutura simbólica SAS

Um token assinado com uma chave de acesso partilhado concede acesso a todas as funcionalidades associadas às permissões de política de acesso partilhado. Um símbolo assinado com a chave simétrica da identidade do dispositivo apenas concede a permissão deviceConnect para a identidade do dispositivo associado.

Um token SAS tem o seguinte formato:

SharedAccessSignature sig={signature-string}&se={expiry}&skn={policyName}&sr={URL-encoded-resourceURI}

Aqui estão os valores esperados:

Valor Descrição
{assinatura} Uma sequência de assinatura HMAC-SHA256 do formulário: {URL-encoded-resourceURI} + "\n" + expiry. Importante: A chave é descodificada a partir da base64 e usada como chave para executar o cálculo HMAC-SHA256.
{recursoURI} Prefixo URI (por segmento) dos pontos finais que podem ser acedidos com este token, começando pelo nome de anfitrião do hub IoT (sem protocolo). Os tokens SAS concedidos para serviços de backend são abrangidos ao nível do hub IoT; por exemplo, myHub.azure-devices.net. . Os tokens SAS concedidos aos dispositivos devem ser perspossidos a um dispositivo individual; por exemplo, myHub.azure-devices.net/devices/device1. .
{expiração} UtF8 cordas por número de segundos desde a época 00:00:00 UTC em 1 de janeiro de 1970.
{URL-codificado-recursosURI} Codificação de URL minúscula do recurso uri de menor mente
{políticaName} O nome da política de acesso partilhado a que se refere este símbolo. Ausente se o símbolo se referir a credenciais de registo de dispositivos.

O prefixo URI é calculado por segmento e não pelo carácter. Por exemplo, /a/b é um prefixo para /a/b/c , mas não para /a/bc.

O código a seguir gera um token SAS utilizando o recurso URI, assinando a chave, o nome da política e o período de validade. As secções seguintes detalham como inicializar as diferentes entradas para os diferentes casos de utilização 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;
};

Especificidades do protocolo

Cada protocolo suportado, como MQTT, AMQP e HTTPS, transporta fichas de diferentes maneiras.

Ao utilizar o MQTT, o pacote CONNECT tem o dispositivoId como ClientId, {iothubhostname}/{deviceId} no campo username, e um token SAS no campo Palavra-passe. {iothubhostname} deve ser o CName completo do hub IoT (por exemplo, contoso.azure-devices.net).

Ao utilizar amQP, Hub IoT suporta SASL PLAIN e AMQP Claims-Based-Security.

Se utilizar a segurança baseada em reclamações amQP, a norma especifica como transmitir estes tokens.

Para SASL PLAIN, o nome de utilizador pode ser:

  • {policyName}@sas.root.{iothubName} se utilizar fichas de nível de ioT.
  • {deviceId}@sas.{iothubname} se utilizar fichas com mira de dispositivos.

Em ambos os casos, o campo de palavra-passe contém o token, conforme descrito em Hub IoT fichas SAS.

HTTPS implementa a autenticação através da inclusão de um token válido no cabeçalho do pedido de autorização .

Por exemplo, Nome de utilizador (DeviceId é sensível a casos): iothubname.azure-devices.net/DeviceId

Palavra-passe (Pode gerar um token SAS com o comando de extensão CLI az iot hub generate-sas-token, ou o Azure IoT Tools para Visual Studio Code):

SharedAccessSignature sr=iothubname.azure-devices.net%2fdevices%2fDeviceId&sig=kPszxZZZZZZZZZZZZZZZZZAhLT%2bV7o%3d&se=1487709501

Nota

Os Azure IoT SDKs geram automaticamente fichas quando se ligam ao serviço. Em alguns casos, os SDKs Azure IoT não suportam todos os protocolos ou todos os métodos de autenticação.

Considerações especiais para a SASL PLAIN

Ao utilizar o SASL PLAIN com AMQP, um cliente que se conecta a um hub IoT pode utilizar um único token para cada ligação TCP. Quando o token expira, a ligação TCP desliga-se do serviço e aciona uma reconexão. Este comportamento, embora não seja problemático para uma aplicação de back-end, é prejudicial para uma aplicação de dispositivo pelas seguintes razões:

  • Gateways geralmente se ligam em nome de muitos dispositivos. Ao utilizar o SASL PLAIN, têm de criar uma ligação TCP distinta para cada dispositivo que se ligue a um hub IoT. Este cenário aumenta consideravelmente o consumo de energia e recursos de rede, e aumenta a latência de cada ligação do dispositivo.

  • Os dispositivos com restrições de recursos são afetados negativamente pelo aumento da utilização dos recursos para se reconectarem após a expiração de cada token.

Use fichas SAS de serviços

Os serviços podem gerar fichas SAS utilizando uma política de acesso partilhado que define as permissões apropriadas, como explicado anteriormente no controlo e permissões de Acesso.

Como exemplo, um serviço que utilize a política de acesso partilhado pré-criada chamada registryRead criaria um símbolo com os seguintes parâmetros:

  • recurso URI: {IoT hub name}.azure-devices.net,
  • chave de assinatura: uma das chaves da registryRead apólice,
  • nome da política: registryRead,
  • qualquer tempo de validade.
var endpoint = "myhub.azure-devices.net";
var policyName = 'registryRead';
var policyKey = '...';

var token = generateSasToken(endpoint, policyKey, policyName, 60);

O resultado, que daria acesso à leitura de todas as identidades do dispositivo, seria:

SharedAccessSignature sr=myhub.azure-devices.net&sig=JdyscqTpXdEJs49elIUCcohw2DlFDR3zfH5KqGJo4r4%3D&se=1456973447&skn=registryRead

Para serviços, os tokens SAS apenas concedem permissões ao nível Hub IoT. Ou seja, um serviço autenticado com um token baseado na política de serviço , poderá realizar todas as operações concedidas pela permissão ServiceConnect . Estas operações incluem receber mensagens de dispositivo para nuvem, envio de mensagens cloud-to-device, e assim por diante. Se pretender conceder mais acesso granular aos seus serviços, por exemplo, limitando um serviço apenas a enviar mensagens cloud-to-device, pode utilizar o Azure Ative Directory. Para saber mais, consulte o Control access to Hub IoT com Azure AD.

Autenticação de um dispositivo para Hub IoT

Certificados X.509 suportados

Pode utilizar qualquer certificado X.509 para autenticar um dispositivo com Hub IoT, enviando uma impressão digital de certificado ou uma autoridade de certificado (CA) para Hub IoT do Azure. Para saber mais, consulte a autenticação do dispositivo utilizando certificados X.509 CA. Para obter informações sobre como carregar e verificar uma autoridade de certificados com o seu hub IoT, consulte configurar a segurança X.509 no seu hub Azure IoT.

Aplicação da autenticação X.509

Para uma segurança adicional, um hub IoT pode ser configurado para não permitir a autenticação SAS para dispositivos e módulos, deixando X.509 como a única opção de autenticação aceite. Atualmente, esta funcionalidade não está disponível em portal do Azure. Para configurar, definir disableDeviceSAS e disableModuleSAS definir true sobre as propriedades de recursos Hub IoT:

az resource update -n <iothubName> -g <resourceGroupName> --resource-type Microsoft.Devices/IotHubs --set properties.disableDeviceSAS=true properties.disableModuleSAS=true

Use fichas SAS como dispositivo

Existem duas formas de obter permissões DeviceConnect com Hub IoT com fichas SAS: use uma chave de dispositivo simétrico a partir do registo de identidade ou use uma chave de acesso partilhada.

Lembre-se que todas as funcionalidades acessíveis a partir de dispositivos são expostas por design em pontos finais com prefixo /devices/{deviceId}.

Os pontos finais voltados para o dispositivo são (independentemente do protocolo):

Ponto final Funcionalidade
{iot hub host name}/devices/{deviceId}/messages/events Envie mensagens de dispositivo para nuvem.
{iot hub host name}/devices/{deviceId}/messages/devicebound Receba mensagens nuvem-dispositivo.

Utilize uma chave simétrica no registo de identidade

Ao utilizar a chave simétrica da identidade do dispositivo para gerar um token, o elemento de nome de política (skn) do token é omitido.

Por exemplo, um token criado para aceder a todas as funcionalidades do dispositivo deve ter os seguintes parâmetros:

  • recurso URI: {IoT hub name}.azure-devices.net/devices/{device id},
  • chave de assinatura: qualquer chave simétrica para a {device id} identidade,
  • sem nome de política,
  • qualquer tempo de validade.

Um exemplo que utiliza a função Node.js anterior seria:

var endpoint ="myhub.azure-devices.net/devices/device1";
var deviceKey ="...";

var token = generateSasToken(endpoint, deviceKey, null, 60);

O resultado, que dá acesso a todas as funcionalidades do dispositivo1, seria:

SharedAccessSignature sr=myhub.azure-devices.net%2fdevices%2fdevice1&sig=13y8ejUk2z7PLmvtwR5RqlGBOVwiq7rQR3WZ5xZX3N4%3D&se=1456971697

Nota

É possível gerar um token SAS com o comando de extensão CLI az iot hub generate-sas-token, ou o Azure IoT Tools para Visual Studio Code.

Utilize uma política de acesso partilhado para aceder em nome de um dispositivo

Quando criar um símbolo a partir de uma política de acesso partilhado, desacorda o skn campo com o nome da apólice. Esta política deve conceder a permissão de DeviceConnect .

Os dois principais cenários para a utilização de políticas de acesso partilhado à funcionalidade do dispositivo de acesso são:

Uma vez que a política de acesso partilhado pode potencialmente conceder acesso à ligação como qualquer dispositivo, é importante utilizar o recurso correto URI ao criar fichas SAS. Esta definição é especialmente importante para os serviços simbólicos, que têm de estender o token a um dispositivo específico utilizando o recurso URI. Este ponto é menos relevante para os gateways de protocolo, uma vez que já estão a mediar o tráfego para todos os dispositivos.

Como exemplo, um serviço simbólico utilizando a política de acesso partilhado pré-criada chamada dispositivo criaria um símbolo com os seguintes parâmetros:

  • recurso URI: {IoT hub name}.azure-devices.net/devices/{device id},
  • chave de assinatura: uma das chaves da device apólice,
  • nome da política: device,
  • qualquer tempo de validade.

Um exemplo que utiliza a função Node.js anterior seria:

var endpoint ="myhub.azure-devices.net/devices/device1";
var policyName = 'device';
var policyKey = '...';

var token = generateSasToken(endpoint, policyKey, policyName, 60);

O resultado, que dá acesso a todas as funcionalidades do dispositivo1, seria:

SharedAccessSignature sr=myhub.azure-devices.net%2fdevices%2fdevice1&sig=13y8ejUk2z7PLmvtwR5RqlGBOVwiq7rQR3WZ5xZX3N4%3D&se=1456971697&skn=device

Um portal de protocolo poderia utilizar o mesmo símbolo para todos os dispositivos que simplesmente definem o recurso URI para myhub.azure-devices.net/devices.

Criar um serviço simbólico para integrar dispositivos existentes

Pode utilizar o registo de identidade Hub IoT para configurar credenciais de segurança por dispositivo/módulo e controlo de acesso utilizando fichas. Se uma solução IoT já tiver um registo de identidade personalizado e/ou um esquema de autenticação, considere criar um serviço simbólico para integrar esta infraestrutura com Hub IoT. Desta forma, pode utilizar outras funcionalidades de IoT na sua solução.

Um serviço de token é um serviço de nuvem personalizado. Utiliza uma política de acesso partilhado Hub IoT com a permissão DeviceConnect para criar fichas com âmbito de dispositivo ou de âmbito de módulos. Estes tokens permitem que um dispositivo e módulo se conectem ao seu hub IoT.

Passos do padrão de serviço simbólico

Aqui estão os principais passos do padrão de serviço simbólico:

  1. Crie uma política de acesso partilhado Hub IoT com a permissão DeviceConnect para o seu hub IoT. Pode criar esta política na portal do Azure ou programática. O serviço token usa esta política para assinar os tokens que cria.

  2. Quando um dispositivo/módulo precisa de aceder ao seu hub IoT, solicita um token assinado do seu serviço de token. O dispositivo pode autenticar com o seu sistema de registo/autenticação de identidade personalizado para determinar a identidade do dispositivo/módulo que o serviço token utiliza para criar o token.

  3. O serviço simbólico devolve um símbolo. O token é criado utilizando /devices/{deviceId} ou /devices/{deviceId}/module/{moduleId} conforme resourceURI, com deviceId o dispositivo a ser autenticado ou moduleId como o módulo a ser autenticado. O serviço token usa a política de acesso partilhado para construir o token.

  4. O dispositivo/módulo utiliza o símbolo diretamente com o hub IoT.

Nota

Pode utilizar a classe .NET SharedAccessSignatureBuilder ou a classe Java IotHubServiceSasToken para criar um símbolo no seu serviço token.

O serviço de token pode definir a expiração simbólica conforme desejado. Quando o token expira, o hub IoT corta a ligação dispositivo/módulo. Em seguida, o dispositivo/módulo deve solicitar um novo token do serviço token. Um curto prazo de validade aumenta a carga tanto no dispositivo/módulo como no serviço token.

Para que um dispositivo/módulo se conecte ao seu hub, deve ainda adicioná-lo ao registo de identidade Hub IoT – mesmo que esteja a utilizar um token e não uma chave para se ligar. Por isso, pode continuar a utilizar o controlo de acesso por dispositivo/módulo, ativando ou desativando identidades de dispositivo/módulo no registo de identidade. Esta abordagem atenua os riscos de utilização de fichas com longos prazos de validade.

Comparação com um portal personalizado

O padrão de serviço token é a forma recomendada de implementar um sistema de registo de identidade/autenticação personalizado com Hub IoT. Este padrão é recomendado porque Hub IoT continua a lidar com a maior parte do tráfego da solução. No entanto, se o esquema de autenticação personalizada estiver tão interligado com o protocolo, poderá necessitar de uma porta de entrada personalizada para processar todo o tráfego. Um exemplo de tal cenário é a utilização de segurança da camada de transporte (TLS) e teclas pré-partilhadas (PSKs). Para mais informações, consulte como um dispositivo IoT Edge pode ser usado como porta de entrada.

Material de referência adicional

Outros tópicos de referência no guia de desenvolvimento Hub IoT incluem:

Passos seguintes

Agora que aprendeu a controlar o acesso Hub IoT, poderá estar interessado nos seguintes tópicos de guia Hub IoT de desenvolvimento:

Se quiser experimentar alguns dos conceitos descritos neste artigo, consulte os seguintes tutoriais Hub IoT: