Dela via

Enhetsidentitet och säkerhet

  • Artikel

Viktigt!

Det här är dokumentationen om Azure Sphere (Legacy). Azure Sphere (Legacy) upphör den 27 september 2027 och användarna måste migrera till Azure Sphere (integrerad) vid den här tiden. Använd versionsväljaren ovanför TOC för att visa dokumentationen om Azure Sphere (integrerad).

Du kan distribuera och hantera flera enheter åt gången. Enhetshantering baseras på möjligheten att identifiera och komma åt varje enhet individuellt när det behövs. För att du ska kunna göra detta får varje Azure Sphere-enhet ett unikt internt enhets-ID som bevaras genom alla uppdateringar av enheten, inklusive återställningsåtgärder.

I digitala system kan dock enhetens ID enkelt förfalskas, förfalskas eller missbrukas. Därför bör du endast tillåta enheter vars identiteter kan verifieras och verifieras för att få åtkomst till dina mycket värdefulla data och ansluta till dina tjänster.

Azure Sphere tillhandahåller en process för att aktivera en enhet för att identifiera sig själv (autentisering) och för bekräftelse av enhetens identitet (attestering). Autentiserings- och attesteringsprocessen som används av Azure Sphere Security Service använder för kända nycklar, säker kommunikation och specialiserad maskinvara för att bekräfta en enhets identitet. Om enhetsautentisering och attestering lyckas utfärdas ett certifikat till enheten. Ett giltigt certifikat anger att:

  • Enhetens identitet har verifierats.
  • Enheten kan vara betrodd.

Med Azure Sphere kopplas enhetscertifikaten först till ett certifikat på klientnivå (vilket gör det enkelt för en organisation att endast lita på enheter från sina egna klienter) och sedan till ett Microsoft-certifikat, vilket visar att Microsoft har verifierat att maskinvaran är en verifierad instans av ett certifierat Azure Sphere-chip som kör ett skyddat Microsoft-operativsystem.

Följande begrepp kan hjälpa dig att använda enhetsidentitet på de säkraste och mest effektiva sätten:

  • Förtroende är tillfälligt
    Förtroende för ett system kan gå förlorat och det kan återfås. En princip för att implementera Nolltillit arkitektur i ett IoT-system är att explicit verifiera. Det innebär att varje gång du interagerar med en enhet fastställer du uttryckligen enhetens äkthet och bevisar att datatransaktionen är tillförlitlig. Azure Sphere-enheter utför automatiskt en autentiserings- och attesteringsprocess var 24:e timme med Azure Sphere-molnsäkerhetstjänster. En indikation på att en enhets identitet har verifierats är förekomsten av ett kryptografiskt signerat certifikat som är rotat i Microsoft Azure Sphere Cloud Security Service.

  • Identitet = identifierare + attestering
    Identifierare kan kopieras och dupliceras. Därför kan en enhet inte bara vara känd av dess identifierare. En enhets identitet (eller en användares identitet) måste anses vara en kombination av både en identifierare och attestering att en sådan identifierare är giltig inom en specifik kontext. Du bör inte tilldela identifierare till enheter och använda dem oberoende av attesteringsprocessen. Om möjligt kan du kombinera identifierare med bevis på attestering vid varje lager av interaktion i dina system.

  • Identifierare + betrodda certifikat
    En identifierare bör inte betraktas som mer än en referens. Ensamt bör det inte antas indikera något om tillförlitligheten för det objekt som det refererar till. Använd till exempel en identifierare för att prenumerera på MQTT-meddelanden, använda en identifierare för att gruppera betrodda data i en portal och använda identifierare för att dirigera trafik och data i ett system. Men när det gäller förtroende, i stället för att lita på identifieraren, litar du på ett kryptografiskt signerat och länkat certifikat. Certifikat är särskilt bra för lösenordslösa dataflöden mellan systemkomponenter och är bevis på identifiering som har testats och visat sig vara tillförlitliga inom en viss kontext.

När du använder Azure IoT Hub, om de konfigureras enligt dokumenterade rekommendationer, införlivas dessa begrepp redan, vilket förenklar distributionen av ett skyddat och motståndskraftigt system.

Du måste också använda dessa begrepp när du ansluter till slutpunkter eller tjänster som du styr direkt till andra än Azure. Om du till exempel använder MQTT kan en enhet inkludera sin egen identitet som en del av det MQTT-ämne som den publicerar till. Men innan du godkänner en ämnesuppdatering från enheten måste MQTT-servern kontrollera att certifikatet som enheten tillhandahåller autentiserar den för att publicera till det här specifika ämnet.

Azure Sphere-enhetscertifikat och enhets-ID-åtkomst

Kodfragmentet Hämta Azure Sphere-enhets-ID visar hur du hämtar Azure Sphere-enhets-ID:t i ett högnivåprogram. Det returnerar enhets-ID:t som en teckenbuffert på 128 tecken. Det här kodfragmentet befaller wolfSSL att öppna en session med certifikatet, hämta kontexten och certifikatet, parsa ut ämnes-ID:t för certifikatet som är enhets-ID för Azure Sphere-enheter och returnera det som en char pekare.