Kontrollera åtkomsten till IoT Hub med signaturer för delad åtkomst

Den här artikeln beskriver alternativen för att skydda din IoT-hubb. IoT Hub använder behörigheter för att bevilja åtkomst till varje IoT-hubbslutpunkt. Behörigheter begränsar åtkomsten till en IoT-hubb baserat på funktioner.

I den här artikeln beskrivs:

  • De olika behörigheter som du kan bevilja en klient för åtkomst till din IoT-hubb.
  • Token IoT Hub använder för att verifiera behörigheter.
  • Så här omfångsbegränsar du autentiseringsuppgifter för att begränsa åtkomsten till specifika resurser.
  • Anpassade mekanismer för enhetsautentisering som använder befintliga enhetsidentitetsregister eller autentiseringsscheman.

Anteckning

Några av de funktioner som nämns i den här artikeln, t.ex. moln till enhet-meddelanden, enhetstvillingar och enhetshantering, är bara tillgängliga på IoT Hubs standardnivå. Mer information om nivåerna grundläggande och standard/kostnadsfri IoT Hub finns i Välj rätt IoT Hub nivå för din lösning.

Du måste ha rätt behörighet för att få åtkomst till någon av IoT Hub slutpunkterna. En enhet måste till exempel innehålla en token som innehåller säkerhetsautentiseringsuppgifter tillsammans med varje meddelande den skickar till IoT Hub. Signeringsnycklarna, som enhetens symmetriska nycklar, skickas dock aldrig via kabeln.

Åtkomstkontroll och behörigheter

Använd principer för delad åtkomst för åtkomst på IoT-hubbnivå och använd endast de enskilda enhetsautentiseringsuppgifterna för att begränsa åtkomsten till den enheten.

Principer för delad åtkomst på IoT-hubbnivå

Principer för delad åtkomst kan ge valfri kombination av behörigheter. Du kan definiera principer i Azure Portal, programmatiskt med hjälp av rest-API:erna för IoT Hub resurs eller med hjälp av cli:et az iot hub policy. En nyligen skapad IoT-hubb har följande standardprinciper:

Princip för delad åtkomst Behörigheter
iothubowner Alla behörigheter
tjänst ServiceConnect-behörigheter
enhet DeviceConnect-behörigheter
registryRead RegistryRead-behörigheter
registryReadWrite RegistryRead- och RegistryWrite-behörigheter

I följande tabell visas de behörigheter som du kan använda för att styra åtkomsten till din IoT-hubb.

Behörighet Kommentarer
ServiceConnect Ger åtkomst till molntjänstriktad kommunikation och övervakningsslutpunkter.
Ger behörighet att ta emot meddelanden från enhet till moln, skicka meddelanden från molnet till enheten och hämta motsvarande leveransbekräftelser.
Ger behörighet att hämta leveransbekräftelser för filuppladdningar.
Ger behörighet att komma åt tvillingar för att uppdatera taggar och önskade egenskaper, hämta rapporterade egenskaper och köra frågor.
Den här behörigheten används av serverdelsmolntjänster.
DeviceConnect Ger åtkomst till enhetsriktade slutpunkter.
Ger behörighet att skicka meddelanden från enhet till moln och ta emot meddelanden från molnet till enheten.
Ger behörighet att utföra filuppladdning från en enhet.
Ger behörighet att ta emot önskade egenskapsaviseringar för enhetstvillingar och uppdatera rapporterade egenskaper för enhetstvillingar.
Ger behörighet att utföra filuppladdningar.
Den här behörigheten används av enheter.
RegistryRead Ger läsbehörighet till identitetsregistret. Mer information finns i Identitetsregister.
Den här behörigheten används av serverdelsmolntjänster.
RegistryReadWrite Ger läs- och skrivbehörighet till identitetsregistret. Mer information finns i Identitetsregister.
Den här behörigheten används av serverdelsmolntjänster.

Säkerhetsautentiseringsuppgifter per enhet

Varje IoT Hub innehåller ett identitetsregister För varje enhet i det här identitetsregistret kan du konfigurera säkerhetsautentiseringsuppgifter som beviljar DeviceConnect-behörigheter som är begränsade till motsvarande enhetsslutpunkter.

SAS-token

IoT Hub använder SAS-token (Signatur för delad åtkomst) för att autentisera enheter och tjänster för att undvika att skicka nycklar på kabeln. SAS-token är begränsade i tids giltighet och omfång. Azure IoT SDK:er genererar automatiskt token utan att det krävs någon särskild konfiguration. Vissa scenarier kräver att du genererar och använder SAS-token direkt. Sådana scenarier omfattar:

  • Direkt användning av MQTT-, AMQP- eller HTTPS-ytorna.

  • Implementeringen av tokentjänstmönstret, enligt beskrivningen i Anpassad enhetsautentisering.

Du använder SAS-token för att bevilja tidsbegränsad åtkomst till enheter och tjänster till specifika funktioner i IoT Hub. För att få auktorisering för att ansluta till IoT Hub måste enheter och tjänster skicka SAS-token signerade med antingen delad åtkomst eller symmetrisk nyckel. Symmetriska nycklar lagras med en enhetsidentitet i identitetsregistret.

SAS-tokenstruktur

En token som är signerad med en delad åtkomstnyckel ger åtkomst till alla funktioner som är associerade med behörigheter för principen för delad åtkomst. En token som är signerad med en enhetsidentitets symmetriska nyckel ger endast behörigheten DeviceConnect för den associerade enhetsidentiteten.

En SAS-token har följande format:

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

Här är de förväntade värdena:

Värde Beskrivning
{signature} En HMAC-SHA256-signatursträng för formuläret: {URL-encoded-resourceURI} + "\n" + expiry. Viktigt: Nyckeln avkodas från base64 och används som nyckel för att utföra HMAC-SHA256-beräkningen.
{resourceURI} URI-prefix (efter segment) för de slutpunkter som kan nås med den här token, från och med värdnamnet för IoT-hubben (inget protokoll). SAS-token som beviljas serverdelstjänster är begränsade till IoT-hubbnivån. till exempel myHub.azure-devices.net. SAS-token som beviljas enheter måste vara begränsade till en enskild enhet. till exempel myHub.azure-devices.net/devices/device1.
{expiry} UTF8-strängar för antal sekunder sedan epoken 00:00:00 UTC den 1 januari 1970.
{URL-kodad-resourceURI} Gemen URL-kodning för gemen resurs-URI
{policyName} Namnet på den princip för delad åtkomst som denna token refererar till. Saknas om token refererar till autentiseringsuppgifter för enhetsregistret.

URI-prefixet beräknas efter segment och inte efter tecken. Till exempel /a/b är ett prefix för /a/b/c men inte för /a/bc.

Följande kod genererar en SAS-token med resurs-URI, signeringsnyckel, principnamn och förfalloperiod. I nästa avsnitt beskrivs hur du initierar de olika indata för de olika tokenanvändningsfallen.

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;
};

Protokollspecifika

Varje protokoll som stöds, till exempel MQTT, AMQP och HTTPS, transporterar token på olika sätt.

När du använder MQTT har CONNECT-paketet deviceId som ClientId, {iothubhostname}/{deviceId} i fältet Användarnamn och en SAS-token i fältet Lösenord. {iothubhostname} ska vara det fullständiga CName för IoT-hubben (till exempel contoso.azure-devices.net).

När du använder AMQP stöder IoT Hub SASL PLAIN och AMQP Claims-Based-Security.

Om du använder AMQP-anspråksbaserad säkerhet anger standarden hur dessa token ska överföras.

För SASL PLAIN kan användarnamnet vara:

  • {policyName}@sas.root.{iothubName} om du använder token på IoT-hubbnivå.
  • {deviceId}@sas.{iothubname} om du använder token med enhetsomfattning.

I båda fallen innehåller lösenordsfältet token, enligt beskrivningen i IoT Hub SAS-token.

HTTPS implementerar autentisering genom att inkludera en giltig token i rubriken auktoriseringsbegäran .

Användarnamn (DeviceId är skiftlägeskänsligt): iothubname.azure-devices.net/DeviceId

Lösenord (Du kan generera en SAS-token med CLI-tilläggskommandot az iot hub generate-sas-token eller Azure IoT Tools för Visual Studio Code):

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

Anteckning

Azure IoT SDK:er genererar automatiskt token vid anslutning till tjänsten. I vissa fall stöder Azure IoT SDK:erna inte alla protokoll eller alla autentiseringsmetoder.

Särskilda överväganden för SASL PLAIN

När du använder SASL PLAIN med AMQP kan en klient som ansluter till en IoT-hubb använda en enda token för varje TCP-anslutning. När token upphör att gälla kopplas TCP-anslutningen från tjänsten och utlöser en återanslutning. Det här beteendet, även om det inte är problematiskt för en serverdelsapp, är skadligt för en enhetsapp av följande skäl:

  • Gatewayer ansluter vanligtvis för många enheters räkning. När du använder SASL PLAIN måste de skapa en distinkt TCP-anslutning för varje enhet som ansluter till en IoT-hubb. Det här scenariot ökar avsevärt förbrukningen av ström- och nätverksresurser och ökar svarstiden för varje enhetsanslutning.

  • Resursbegränsade enheter påverkas negativt av den ökade användningen av resurser som ska återansluta efter varje tokens förfallodatum.

Använda SAS-token från tjänster

Tjänster kan generera SAS-token med hjälp av en princip för delad åtkomst som definierar lämpliga behörigheter enligt beskrivningen tidigare i Åtkomstkontroll och behörigheter.

Till exempel skulle en tjänst som använder den i förväg skapade principen för delad åtkomst med namnet registryRead skapa en token med följande parametrar:

  • resurs-URI: {IoT hub name}.azure-devices.net,
  • signeringsnyckel: en av principernas registryRead nycklar,
  • principnamn: registryRead,
  • förfallotid.
var endpoint = "myhub.azure-devices.net";
var policyName = 'registryRead';
var policyKey = '...';

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

Resultatet, som skulle ge åtkomst till att läsa alla enhetsidentiteter, skulle bli:

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

För tjänster beviljar SAS-token endast behörigheter på IoT Hub nivån. En tjänst som autentiseras med en token baserat på tjänstprincipen kan alltså utföra alla åtgärder som beviljas av serviceconnect-behörigheten . Dessa åtgärder omfattar att ta emot meddelanden från enheten till molnet, skicka meddelanden från molnet till enheten och så vidare. Om du vill ge mer detaljerad åtkomst till dina tjänster, till exempel begränsa en tjänst till att endast skicka meddelanden från molnet till enheten, kan du använda Azure Active Directory. Mer information finns i Kontrollera åtkomst till IoT Hub med Azure AD.

Autentisera en enhet för att IoT Hub

X.509-certifikat som stöds

Du kan använda valfritt X.509-certifikat för att autentisera en enhet med IoT Hub genom att ladda upp antingen ett tumavtryck för certifikat eller en certifikatutfärdare (CA) för att Azure IoT Hub. Mer information finns i Enhetsautentisering med X.509 CA-certifikat. Information om hur du laddar upp och verifierar en certifikatutfärdare med din IoT-hubb finns i Konfigurera X.509-säkerhet i din Azure IoT-hubb.

Framtvinga X.509-autentisering

För ytterligare säkerhet kan en IoT-hubb konfigureras för att inte tillåta SAS-autentisering för enheter och moduler, vilket lämnar X.509 som det enda godkända autentiseringsalternativet. Den här funktionen är för närvarande inte tillgänglig i Azure Portal. Konfigurera, ange disableDeviceSAS och disableModuleSAS till true för IoT Hub resursegenskaper:

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

Använda SAS-token som en enhet

Det finns två sätt att hämta DeviceConnect-behörigheter med IoT Hub med SAS-token: använd en symmetrisk enhetsnyckel från identitetsregistret eller använd en delad åtkomstnyckel.

Kom ihåg att alla funktioner som är tillgängliga från enheter exponeras avsiktligt på slutpunkter med prefixet /devices/{deviceId}.

De enhetsinriktade slutpunkterna är (oavsett protokoll):

Slutpunkt Funktioner
{iot hub host name}/devices/{deviceId}/messages/events Skicka meddelanden från enheten till molnet.
{iot hub host name}/devices/{deviceId}/messages/devicebound Ta emot meddelanden från moln till enhet.

Använda en symmetrisk nyckel i identitetsregistret

När du använder en enhetsidentitets symmetriska nyckel för att generera en token utelämnas elementet policyName (skn) i token.

Till exempel bör en token som skapats för att komma åt alla enhetsfunktioner ha följande parametrar:

  • resurs-URI: {IoT hub name}.azure-devices.net/devices/{device id},
  • signeringsnyckel: valfri symmetrisk nyckel för identiteten {device id} ,
  • inget principnamn,
  • förfallotid.

Ett exempel som använder den föregående Node.js-funktionen är:

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

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

Resultatet, som ger åtkomst till alla funktioner för device1, skulle bli:

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

Anteckning

Det går att generera en SAS-token med CLI-tilläggskommandot az iot hub generate-sas-token eller Azure IoT Tools för Visual Studio Code.

Använda en princip för delad åtkomst för att få åtkomst åt en enhet

När du skapar en token från en princip för delad åtkomst anger du skn fältet till namnet på principen. Den här principen måste ge DeviceConnect-behörigheten .

De två huvudsakliga scenarierna för att använda principer för delad åtkomst för att komma åt enhetsfunktioner är:

Eftersom principen för delad åtkomst potentiellt kan bevilja åtkomst för att ansluta som vilken enhet som helst är det viktigt att använda rätt resurs-URI när du skapar SAS-token. Den här inställningen är särskilt viktig för tokentjänster, som måste begränsa token till en specifik enhet med hjälp av resurs-URI:n. Den här punkten är mindre relevant för protokollgatewayer eftersom de redan förmedlar trafik för alla enheter.

Till exempel skulle en tokentjänst som använder den i förväg skapade principen för delad åtkomst som kallas enhet skapa en token med följande parametrar:

  • resurs-URI: {IoT hub name}.azure-devices.net/devices/{device id},
  • signeringsnyckel: en av principernas device nycklar,
  • principnamn: device,
  • förfallotid.

Ett exempel som använder den föregående Node.js-funktionen är:

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

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

Resultatet, som ger åtkomst till alla funktioner för device1, skulle bli:

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

En protokollgateway kan använda samma token för alla enheter genom att helt enkelt ange resurs-URI:n till myhub.azure-devices.net/devices.

Skapa en tokentjänst för att integrera befintliga enheter

Du kan använda IoT Hub identitetsregistret för att konfigurera säkerhetsautentiseringsuppgifter per enhet/modul och åtkomstkontroll med hjälp av token. Om en IoT-lösning redan har ett anpassat identitetsregister och/eller autentiseringsschema bör du överväga att skapa en tokentjänst för att integrera den här infrastrukturen med IoT Hub. På så sätt kan du använda andra IoT-funktioner i din lösning.

En tokentjänst är en anpassad molntjänst. Den använder en IoT Hub princip för delad åtkomst med behörigheten DeviceConnect för att skapa token med enhetsomfattning eller modulomfång. Dessa token gör det möjligt för en enhet och modul att ansluta till din IoT-hubb.

Steg i tokentjänstmönstret

Här är de viktigaste stegen i tokentjänstmönstret:

  1. Skapa en IoT Hub princip för delad åtkomst med behörigheten DeviceConnect för din IoT-hubb. Du kan skapa den här principen i Azure Portal eller programmatiskt. Tokentjänsten använder den här principen för att signera de token som skapas.

  2. När en enhet/modul behöver åtkomst till din IoT-hubb begär den en signerad token från din tokentjänst. Enheten kan autentisera med ditt anpassade identitetsregister/autentiseringsschema för att fastställa den enhets-/modulidentitet som tokentjänsten använder för att skapa token.

  3. Tokentjänsten returnerar en token. Token skapas med eller /devices/{deviceId}/devices/{deviceId}/module/{moduleId} som resourceURI, med deviceId som enheten som autentiseras eller moduleId som den modul som autentiseras. Tokentjänsten använder principen för delad åtkomst för att konstruera token.

  4. Enheten/modulen använder token direkt med IoT-hubben.

Anteckning

Du kan använda .NET-klassen SharedAccessSignatureBuilder eller Java-klassen IotHubServiceSasToken för att skapa en token i din tokentjänst.

Tokentjänsten kan ange förfallotid för token som du vill. När token upphör att gälla bryter IoT-hubben anslutningen mellan enheten och modulen. Sedan måste enheten/modulen begära en ny token från tokentjänsten. En kort förfallotid ökar belastningen på både enheten/modulen och tokentjänsten.

För att en enhet/modul ska kunna ansluta till din hubb måste du fortfarande lägga till den i IoT Hub identitetsregistret – även om den använder en token och inte en nyckel för att ansluta. Därför kan du fortsätta att använda åtkomstkontroll per enhet/per modul genom att aktivera eller inaktivera enhets-/modulidentiteter i identitetsregistret. Den här metoden minskar risken för att använda token med långa förfallotider.

Jämförelse med en anpassad gateway

Mönstret för tokentjänsten är det rekommenderade sättet att implementera ett anpassat identitetsregister/autentiseringsschema med IoT Hub. Det här mönstret rekommenderas eftersom IoT Hub fortsätter att hantera merparten av lösningstrafiken. Men om det anpassade autentiseringsschemat är så sammanflätat med protokollet kan du behöva en anpassad gateway för att bearbeta all trafik. Ett exempel på ett sådant scenario är att använda TLS (Transport Layer Security) och i förväg delade nycklar (PSK:er). Mer information finns i Så här kan en IoT Edge-enhet användas som en gateway.

Ytterligare referensmaterial

Andra referensämnen i IoT Hub utvecklarguiden är:

Nästa steg

Nu när du har lärt dig hur du styr åtkomst IoT Hub kan du vara intresserad av följande avsnitt i IoT Hub-utvecklarguiden:

Om du vill prova några av de begrepp som beskrivs i den här artikeln kan du läsa följande IoT Hub självstudier: