Dela via


Azure IoT Edge Security Manager

Gäller för: Ja-ikon IoT Edge 1.1

Viktigt!

IoT Edge 1.1 slutdatum för support var den 13 december 2022. I informationen om Microsoft-produktens livscykel hittar du fler uppgifter om vilken support som gäller för denna produkt, tjänst, teknik eller detta API. Mer information om hur du uppdaterar till den senaste versionen av IoT Edge finns i Uppdatera IoT Edge.

Azure IoT Edge-säkerhetshanteraren är en välbegränsad säkerhetskärna för att skydda IoT Edge-enheten och alla dess komponenter genom att abstrahera den säkra kiselmaskinvaran. Säkerhetschefen är brännpunkten för säkerhetshärdning och tillhandahåller teknikintegreringspunkt till oem-tillverkare (Original Equipment Manufacturers).

Säkerhetshanteraren abstraherar den säkra kiselmaskinvaran på en IoT Edge-enhet.

Azure IoT Edge Security Manager IoT Edge-säkerhetshanteraren strävar efter att försvara integriteten för IoT Edge-enheten och alla inbyggda programvaruåtgärder. Säkerhetshanteraren övergår förtroendet från den underliggande maskinvaruroten för betrodd maskinvara (om tillgängligt) för att starta IoT Edge-körningen och övervaka pågående åtgärder. IoT Edge-säkerhetshanteraren är programvara som fungerar tillsammans med säker kiselmaskinvara (där det är tillgängligt) för att ge högsta möjliga säkerhetsgarantier.

IoT Edge-säkerhetshanterarens ansvarsområden omfattar, men är inte begränsade till:

  • Bootstrap för Azure IoT Edge-enheten.
  • Kontrollera åtkomsten till enhetens maskinvarurot för förtroende via notarietjänster.
  • Övervaka integriteten för IoT Edge-åtgärder vid körning.
  • Tar emot förtroendedelegering från maskinvarusäkerhetsmodulen (HSM)
  • Etablera enhetsidentiteten och hantera övergången av förtroende i tillämpliga fall.
  • Hantera och skydda enhetskomponenter i molntjänster som Device Provisioning Service.
  • Etablera IoT Edge-moduler med unika identiteter.

IoT Edge-säkerhetshanteraren består av tre komponenter:

  • IoT Edge-säkerhetsdaemonen
  • Abstraktionsskiktet för maskinvarusäkerhetsmodulens plattform (HSM PAL)
  • En kiselrot för maskinvara eller HSM (valfritt, men rekommenderas starkt)

IoT Edge-säkerhetsdaemonen

Säkerhetsdaemonen IoT Edge ansvarar för säkerhetshanterarens logiska säkerhetsåtgärder. Den representerar en betydande del av den betrodda beräkningsbasen för IoT Edge-enheten.

Designprinciper

IoT Edge följer två grundläggande principer: maximera driftintegriteten och minimera uppblåsthet och omsättning.

Maximera driftintegriteten

IoT Edge-säkerhetsdaemonen fungerar med högsta möjliga integritet inom försvarskapaciteten för en viss rot av betrodd maskinvara. Med rätt integrering mäter roten av betrodd maskinvara och övervakar säkerhetsdaemon statiskt och vid körning för att motstå manipulering. Skadlig fysisk åtkomst till enheter är alltid ett hot i IoT. Maskinvaruroten för förtroende spelar en viktig roll när det gäller att försvara IoT Edge-enhetens integritet. Maskinvaruroten för förtroende finns i två sorter:

  • Skydda element för skydd av känslig information som hemligheter och kryptografiska nycklar.
  • Skydda enklaver för skydd av hemligheter som nycklar och känsliga arbetsbelastningar som konfidentiella maskininlärningsmodeller och mätningsåtgärder.

Det finns två typer av körningsmiljöer för att använda maskinvaruroten för förtroende:

  • Den standard- eller omfattande körningsmiljö (REE) som förlitar sig på användningen av säkra element för att skydda känslig information.
  • Den betrodda körningsmiljön (TEE) som förlitar sig på användningen av säker enklavteknik för att skydda känslig information och erbjuda skydd för programvarukörning.

För enheter som använder säkra enklaver som maskinvarurot av förtroende bör känslig logik i IoT Edge-säkerhetsdaemonen finnas i enklaven. Icke-känsliga delar av säkerhetsdaemonen kan ligga utanför TEE. I samtliga fall rekommenderar vi starkt att ursprungliga designtillverkare (ODM) och oem-tillverkare (originalutrustning) utökar förtroendet från sin HSM för att mäta och försvara integriteten hos IoT Edge-säkerhetsdaemonen vid start och körning.

Minimera uppblåsthet och omsättning

En annan grundläggande princip för IoT Edge-säkerhetsdaemonen är att minimera omsättning. För den högsta förtroendenivån kan IoT Edge-säkerhetsdaemonen nära kopplas till enhetens maskinvarurot av förtroende och fungera som intern kod. I dessa fall är det vanligt att uppdatera IoT Edge-programvaran via maskinvaruroten för förtroendes säkra uppdateringsvägar i stället för operativsystemets uppdateringsmekanismer, vilket kan vara en utmaning. Säkerhetsförnyelse rekommenderas för IoT-enheter, men överdrivna uppdateringskrav eller stora uppdateringsnyttolaster kan utöka hotytan på många sätt. Du kan till exempel vara frestad att hoppa över vissa uppdateringar för att maximera enhetens tillgänglighet. Därför är utformningen av IoT Edge-säkerhetsdaemonen kortfattad för att hålla den välisolerade betrodda beräkningsbasen liten för att uppmuntra frekventa uppdateringar.

Arkitektur

IoT Edge-säkerhetsdaemonen utnyttjar alla tillgängliga maskinvaruroten med förtroendeteknik för säkerhetshärdning. Det möjliggör också split-world-drift mellan en standard-/omfattande körningsmiljö (REE) och en betrodd körningsmiljö (TEE) när maskinvarutekniker erbjuder betrodda körningsmiljöer. Med rollspecifika gränssnitt kan de viktigaste komponenterna i IoT Edge säkerställa IoT Edge-enhetens integritet och dess åtgärder.

Azure IoT Edge-säkerhetsdaemonarkitektur

Molngränssnitt

Molngränssnittet ger åtkomst till molntjänster som kompletterar enhetssäkerheten. Det här gränssnittet ger till exempel åtkomst till Enhetsetableringstjänsten för livscykelhantering för enhetsidentitet.

API för hantering

Hanterings-API:et anropas av IoT Edge-agenten när du skapar/startar/stoppar/tar bort en IoT Edge-modul. Säkerhetsdaemonen lagrar "registreringar" för alla aktiva moduler. Dessa registreringar mappar en moduls identitet till vissa egenskaper för modulen. De här modulegenskaperna inkluderar till exempel processidentifieraren (pid) för processen som körs i containern och hashen för dockercontainerns innehåll.

Dessa egenskaper används av arbetsbelastnings-API:et (beskrivs nedan) för att verifiera att anroparen har behörighet för en åtgärd.

Hanterings-API:et är ett privilegierat API som endast kan anropas från IoT Edge-agenten. Eftersom IoT Edge-säkerhetsdaemonen bootstraps och startar IoT Edge-agenten verifierar den att IoT Edge-agenten inte har manipulerats och sedan kan den skapa en implicit registrering för IoT Edge-agenten. Samma attesteringsprocess som arbetsbelastnings-API:et använder begränsar också åtkomsten till hanterings-API:et till endast IoT Edge-agenten.

Container-API

Container-API:et interagerar med containersystemet som används för modulhantering, till exempel Moby eller Docker.

API för arbetsbelastning

Arbetsbelastnings-API:et är tillgängligt för alla moduler. Den innehåller identitetsbevis, antingen som en HSM-rotad signerad token eller ett X509-certifikat, och motsvarande förtroendepaket till en modul. Förtroendepaketet innehåller CA-certifikat för alla andra servrar som modulerna ska lita på.

IoT Edge-säkerhetsdaemonen använder en attesteringsprocess för att skydda detta API. När en modul anropar det här API:et försöker säkerhetsdaemonen hitta en registrering för identiteten. Om det lyckas använder den egenskaperna för registreringen för att mäta modulen. Om resultatet av mätningsprocessen matchar registreringen genereras ett nytt identitetsbevis. Motsvarande CA-certifikat (förtroendepaket) returneras till modulen. Modulen använder det här certifikatet för att ansluta till IoT Hub, andra moduler eller starta en server. När den signerade token eller certifikatet snart upphör att gälla är det modulens ansvar att begära ett nytt certifikat.

Integrering och underhåll

Microsoft har huvudkodbasen för IoT Edge-säkerhetsdaemonen på GitHub.

Installation och uppdateringar

Installation och uppdateringar av säkerhetsdaemonen IoT Edge hanteras via operativsystemets pakethanteringssystem. IoT Edge-enheter med maskinvarurot av förtroende bör ge ytterligare härdning till daemonens integritet genom att hantera dess livscykel via hanteringssystemen för säker start och uppdateringar. Enhetsskapare bör utforska dessa vägar baserat på deras respektive enhetsfunktioner.

Versionshantering

IoT Edge-körningen spårar och rapporterar versionen av IoT Edge-säkerhetsdaemonen. Versionen rapporteras som attributet runtime.platform.version för den rapporterade egenskapen för IoT Edge-agentmodulen.

Modul för maskinvarusäkerhet

Maskinvarusäkerhetsmodulens plattformsabstraktionslager (HSM PAL) abstraherar all rot av betrodd maskinvara för att isolera utvecklaren eller användaren av IoT Edge från deras komplexitet. Den innehåller en kombination av API (Application Programming Interface) och transdomänkommunikationsprocedurer, till exempel kommunikation mellan en standardkörningsmiljö och en säker enklav. Den faktiska implementeringen av HSM PAL beror på den specifika säkra maskinvara som används. Dess existens möjliggör användning av praktiskt taget alla säkra kiselmaskinvara.

Skydda kiselroten för betrodd maskinvara

Säker kisel krävs för att förankra förtroendet i IoT Edge-enhetens maskinvara. Säker kisel finns i olika varianter som TPM (Trusted Platform Module), embedded Secure Element (eSE), Arm TrustZone, Intel SGX och anpassade tekniker för säker kisel. Användning av säker kiselrot av förtroende på enheter rekommenderas med tanke på hoten som är associerade med fysisk tillgänglighet för IoT-enheter.

IoT Edge-säkerhetshanteraren syftar till att identifiera och isolera de komponenter som skyddar säkerheten och integriteten för Azure IoT Edge-plattformen för anpassad härdning. Tredje part, till exempel enhetstillverkare, bör använda anpassade säkerhetsfunktioner som är tillgängliga med deras enhetsmaskinvara.

Lär dig hur du härdar Azure IoT-säkerhetshanteraren med TPM (Trusted Platform Module) med hjälp av programvara eller virtuella TPM:er:

Skapa och etablera en IoT Edge-enhet med en virtuell TPM på Linux eller Linux i Windows.

Nästa steg

Mer information om hur du skyddar dina IoT Edge-enheter finns i följande blogginlägg: