Azure IoT Edge-säkerhetsansvarig

gäller för: IoT Edge 1.1

Azure IoT Edge-säkerhetshanteraren är en strikt säkerhetskärna för att skydda IoT Edge-enheten och alla dess komponenter genom att abstrahera den säkra kiselbaserade maskinvaran. Säkerhetsansvarig är centralpunkten för säkerhetshärdning och tillhandahåller en teknikintegreringspunkt för tillverkare av originalutrustning (OEM).

Säkerhetshanteraren abstraherar från den säkra kiselbaserade hårdvaran på en IoT Edge-enhet.

IoT Edge-säkerhetshanteraren strävar efter att försvara integriteten för IoT Edge-enheten och alla inbyggda programvaruåtgärder. Säkerhetshanteraren överför förtroendet från den underliggande maskinvaruroten (om tillgängligt) för att starta IoT Edge-körningsmiljön och övervaka pågående drift. 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:

• Initiera Azure IoT Edge-enheten.
• Kontrollera åtkomsten till enhetens maskinvarutillitsrot via notarietjänster.
• Övervaka integriteten för IoT Edge-processer 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 siliconbaserad skyddsmekanism 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 tillitens rot maskinvara och övervakar säkerhetsdaemon statiskt och i realtid för att motstå manipulation. 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. Maskinvarubaserad förtroenderot kommer i två varianter.

• 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 exekveringsmiljöer för att använda hårdvarans förtroenderot.

• Den standard- eller rika körmiljön (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 originalutrustningstillverkare (OEM) använder förtroendet från sin HSM för att mäta och försvara integriteten hos IoT Edge-säkerhetsdaemonen både vid start och under körning.

Minimera uppblåsthet och omsättning

En annan grundläggande princip för IoT Edge-säkerhetsdaemonen är att minimera förändringar. 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 tillitens säkra uppdateringsvägar i stället för operativsystemets uppdateringsmekanismer, vilket kan vara utmanande. 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 maskinvarubaserade förtroenderotstekniker för att stärka säkerheten. Det möjliggör också att köra i separata världar mellan en standard-/rik körningsmiljö (REE) och en betrodd körningsmiljö (TEE) när maskinvaruteknik erbjuder möjligheten till 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.

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 initierar och startar IoT Edge-agenten, verifierar den att IoT Edge-agenten inte har manipulerats, och därefter 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 tillhandahåller identitetsbevis, antingen som en signerad HSM-rotad token eller ett X509-certifikat, och det motsvarande förtroendepaketet 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 maskinvarubaserad rot av förtroende bör skydda ytterligare daemonens integritet genom att hantera dess livscykel via system för säker start och uppdateringshantering. Enhetsskapare bör utforska dessa vägar baserat på deras respektive enhetsfunktioner.

Versionshantering

IoT Edge-runtime spårar och rapporterar om versionen av säkerhetsdemonen i IoT Edge. Versionen rapporteras som attributet runtime.platform.version för den rapporterade egenskapen hos 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 kiselbaserad förtroenderot i enheter rekommenderas med tanke på hoten som är associerade med fysisk åtkomst av 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:

• Säkerställa den intelligenta gränsen.
• Ritningen för att säkert lösa utmaningen med nolltouch-provisionering av IoT-enheter i stor skala
• Lösa IoT-enhetssäkerhet i stor skala med hjälp av standarder