Controle o acesso ao IoT Hub usando assinaturas de acesso partilhado e fichas de segurança

Este artigo descreve as opções para garantir o seu hub IoT. O IoT Hub utiliza 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 IoT Hub usam 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, só estão disponíveis no nível padrão do IoT Hub. 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).

Você deve ter permissões apropriadas para aceder a qualquer um dos pontos finais do IoT Hub. Por exemplo, um dispositivo deve incluir um símbolo contendo credenciais de segurança, juntamente com todas as mensagens que envia para o IoT Hub. 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 Azure, programáticamente utilizando as APIs de Recursos de IoT Hub, 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 de segurança

O IoT Hub utiliza fichas de segurança para autenticar dispositivos e serviços para evitar o envio de chaves no fio. Além disso, as fichas de segurança são limitadas na validade e âmbito do tempo. Estes tokens de segurança também são conhecidos como tokens shared Access Signature (SAS). Os SDKs Azure IoT geram automaticamente fichas sem necessitar de qualquer configuração especial. Alguns cenários requerem que gere e use fichas de segurança diretamente. Tais cenários incluem:

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

Estrutura simbólica de segurança

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.

O símbolo de segurança 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). 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 /a/b exemplo, é um prefixo /a/b/c para, mas não para /a/bc .

O seguinte Node.js snippet mostra uma função chamada GenerateSasToken que calcula o token a partir das entradas . 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,o IoT Hub 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 símbolo, conforme descrito em fichas de segurança IoT Hub.

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 Código):

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.

Utilize fichas de segurança a partir de componentes de serviço

Os componentes de serviço só podem gerar fichas de segurança utilizando políticas de acesso partilhado que concedam as permissões apropriadas, como explicado anteriormente.

Aqui estão as funções de serviço expostas nos pontos finais:

Ponto final Funcionalidade
{iot hub host name}/devices Criar, atualizar, recuperar e eliminar identidades do dispositivo.
{iot hub host name}/messages/events Receba mensagens dispositivo-a-nuvem.
{iot hub host name}/servicebound/feedback Receba feedback para mensagens cloud-to-device.
{iot hub host name}/devicebound Envie mensagens nuvem-a-dispositivo.

Como exemplo, um serviço gerador de utilização da 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/devices ,
  • 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/devices";
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%2fdevices&sig=JdyscqTpXdEJs49elIUCcohw2DlFDR3zfH5KqGJo4r4%3D&se=1456973447&skn=registryRead

Autenticação de um dispositivo para ioT Hub

Certificados X.509 suportados

Pode utilizar qualquer certificado X.509 para autenticar um dispositivo com o IoT Hub, enviando uma impressão digital de certificado ou uma autoridade de certificado (CA) para o Azure IoT Hub. 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 se encontra disponível no portal Azure. Para configurar, definir disableDeviceSAS e definir sobre as propriedades de recursos do disableModuleSAStrue IoT Hub:

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 IoT Hub com fichas de segurança: 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 políticaName 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 utilizando 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 Código.

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 skn o 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 URI de recurso correto ao criar fichas de segurança. 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 utilizando 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 IoT Hub 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 o IoT Hub. 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 compartilhado IoT Hub 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.

Steps of the token service pattern

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

  1. Crie uma política de acesso compartilhado IoT Hub com a permissão DeviceConnect para o seu hub IoT. Pode criar esta política no portal Azure ou programáticamente. 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}resourceURI conforme, com deviceId o dispositivo a ser autenticado ou como moduleId 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 do IoT Hub – 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, permitindo 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 o IoT Hub. Este padrão é recomendado porque o IoT Hub continua a lidar com a maior parte do tráfego de 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 deste cenário é a utilização de chaves de segurança da camada de transporte (TLS) e de chaves pré-partilhadas (PSKs). Para mais informações, consulte o artigo do portal protocolar.

Material de referência adicional

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

Passos seguintes

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

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