Grunderna i IoT-säkerhet - del 5: Ansluta säkert till IoT molntjänster

Av Stephen Evanczuk

Bidraget med av DigiKeys nordamerikanska redaktörer

Reds. anmärkning: Trots spridningen av IoT-enheter är det fortfarande ett ständigt bekymmer att säkra dessa enheter, till den grad att säkerhetsutmaningarna kan vara ett hinder för att använda uppkopplade enheter i Industriellt IoT och uppdragskritiska applikationer där företags- och personuppgifter kan riskeras i händelse av en framgångsrik attack. Att säkra IoT-applikationer kan verka som en överväldigande uppgift, men faktum är att säkerheten hos IoT-enheter kan byggas upp med några relativt enkla principer som stöds av hårdvarusäkerhetsenheter. Genom att följa väl etablerade säkerhetsrutiner kan dessa problem hanteras. Denna serie i flera delar ger praktisk vägledning för att hjälpa utvecklare att se till att god praxis följs från början. Del 1 diskuterar de kryptografiska algoritmerna som ligger bakom säkra konstruktioner. Del 2 diskuterar rollerna hos privata nycklar, nyckelhantering och säker lagring i säkra IoT-mönster. Del 3 undersöker mekanismerna som är inbyggda i säkra processorer, för att minska andra typer av hot mot IoT-enheter. Del 4 presenterar och visar hur man tillämpar säkerhetsmekanismer i avancerade processorer för att säkerställa den isolering som krävs för att mildra attacker på IoT-enhetens körtidsmiljö. Här beskriver del 5 hur IoT-säkerheten fortsätter från IoT-enheter genom säkerhetsåtgärder på högre nivå som används för att ansluta dessa enheter till IoT-molnresurser.

Internet of Things (IoT)-säkerhet bygger på flera skyddslager som sträcker sig från IoT-enhetens hårdvarufundament till dess exekveringsmiljö. Hot kvarstår dock för alla anslutna enheter, och typiska IoT-applikationskrav för molnanslutning kan lämna både IoT-enheter och molntjänster öppna för nya attacker. För att mildra dessa hot använder IoT-molnleverantörer specifika säkerhetsprotokoll och policyer som, om de missbrukas, kan göra IoT-applikationer sårbara. Med hjälp av förkonfigurerade utvecklingskort kan utvecklare snabbt få erfarenhet av de säkerhetsmetoder som används av ledande IoT-molntjänster för att verifiera anslutningar och godkänna användning av IoT-enheter och molnresurser.

Denna artikel beskriver anslutningskraven för två ledande molntjänster, Amazon Web Services (AWS) och Microsoft Azure, och visar hur utvecklare kan använda utvecklingssatser och tillhörande programvara från olika leverantörer för att snabbt ansluta till dessa tjänster.

IoT-portalers roll i molntjänster

När en IoT-enhet ansluts till en resurs som en molntjänst eller fjärrvärd, utsätts den i princip - och i förlängningen hela IoT-nätverket - för hot som är maskerade som legitima tjänster eller servrar. På motsvarande vis står själva molntjänsten på liknande sätt inför attackhot från hackare som emulerar IoT-enhetstransaktioner i försök att penetrera molnförsvaret. För att säkerställa skyddet för både IoT-enheter och molnresurser, kräver molntjänster användning av specifika säkerhetsprotokoll för ömsesidig identitetsautentisering för inloggning och efterföljande autentisering för att säkerställa tillåten användning av tjänsterna. Dessa protokoll ingår vanligtvis i en uppsättning tjänster som tillhandahåller en säker portal mellan IoT-enheter och molnresurser.

Precis som med andra tillgängliga IoT-molntjänstplattformar tillhandahåller AWS och Azure var för sig en specifik intrångsportal som IoT-enheter behöver använda för att interagera med varje leverantörs kompletta uppsättning molnresurser, såsom deras virtuella maskiner (VM) och SaaS (software-as-a-service). Med hjälp av en funktionellt liknande uppsättning mekanismer och funktioner, tillhandahåller Azure IoT Hub och AWS IoT denna portal för sina respektive molnutbud riktat mot företag.

Som minimum använder dessa och andra IoT-portaler specifika autentiseringsprotokoll implementerade genom varje leverantörs SDK för att skapa en säker anslutning. För AWS ansluter IoT-enheter med hjälp av ömsesidig autentisering med en enhetsport. Enhetsporten ansluter IoT-enheten till andra IoT-supporttjänster och använder information som finns i ett enhetsregister för att lagra en unik enhetsidentifierare, säkerhetsinformation och annan metadata som behövs för att hantera åtkomst till AWS-tjänster (figur 1). I Azure har identitetsregistret en liknande funktion.

Diagram över hur AWS ger utvecklarna en uppsättning specialiserade tjänster Bild 1: Liksom med andra molnleverantörer tillhandahåller AWS utvecklare en uppsättning specialtjänster som är utformade för att förbättra säkerheten och effektiviteten i transaktioner mellan IoT-enheter och företagets molntjänster. (Bildkälla: Amazon Web Services)

AWS IoT och Azure IoT tillhandahåller var och en en tjänst som underhåller tillståndsinformation i en virtuell enhet associerad med varje fysisk IoT-enhet. I AWS IoT ger enhetsavbildningar denna möjlighet för AWS IoT, medan enhetstvillingar ger liknande funktioner för Azure IoT.

Denna uppfattning om en säkerhetsportal sträcker sig till IoT-molnkantstjänster som AWS Greengrass eller Azure IoT Edge. Dessa molnkanttjänster erbjuder vissa molntjänster och kapacitet till det lokala nätverket, där molnkantsystem placeras fysiskt nära IoT-enheter och -system i storskaliga installationer. Utvecklare kan använda en tjänst som Azure IoT Edge för att implementera applikationsaffärslogik eller tillhandahålla andra funktionella funktioner som behövs för att minska latens eller tillhandahålla tjänster till lokala operatörer, till exempel inom industriell automatisering (figur 2).

Diagram över leverantörer av molntjänster som erbjuder specialtjänster för att stödja edge computing Bild 2: För att stödja edge computing, erbjuder leverantörer av molntjänster specialiserade tjänster som Microsoft Azure IoT Edge, vilket bringar vissa Azure IoT-molntjänster närmare de fysiska enheter som är associerade med IoT-applikationen. (Bildkälla: Microsoft Azure)

Att hantera kraven för IoT-portaluppkoppling

Oavsett om man ansluter via ett molnkantssystem eller direkt med leverantörens IoT-tjänst, måste IoT-enheter vanligtvis uppfylla en serie krav för att ansluta via leverantörens IoT-portal och använda leverantörens molntjänster. Även om detaljerna skiljer sig åt, måste IoT-enheter tillhandahålla minst ett visst objekt, exempelvis en privat nyckel, X.509-certifikat eller annan säkerhetstoken. Nyckeln, certifikatet eller en token förser IoT-portalen med verifiering eller bevis för IoT-enhetens identitet under autentiseringsfasen för anslutningssekvensen mellan enheten och molnet. Dessutom kräver IoT-molntjänster vanligtvis en specifikation av policyn som används för att definiera åtkomsträttigheter för interaktioner mellan IoT-enheter och molntjänster.

Liksom med andra företagskrav på databehandling, måste verifieringsinformation för autentisering och policyinformation för åtkomsthantering tillhandahållas med hjälp av specifika format och procedurer som specificeras av ledande IoT-molntjänster som AWS IoT och Azure IoT. Dessa tjänster stöder allra minst certifikatbaserad autentisering, men de stödjer också användning av andra former av verifieringar. Till exempel kan utvecklare använda tokenbaserade autentiseringsmetoder baserade på en JSON Web Token (JWT) för AWS IoT eller en token för delad åtkomstsignatur (SAS) för Azure IoT.

Som nämnts tidigare använder dessa tjänster register för att hålla metadata för varje IoT-enhet. Tillsammans med säkerhet och annan information lagrar dessa register åtkomsträttigheterna som måste definieras för att ansluta en IoT-enhet. Även om de anges på olika sätt för olika molntjänster, beskriver dessa policydefinitioner åtkomsträttigheter för olika kommunikationskanaler och enheter. Till exempel kan en enkel AWS IoT-åtkomsträttighetspolicy använda ett JSON-format för att indikera att en IoT-enhet med ett specifikt "sak"-namn i AWS IoT-enhetsregistret kan ansluta och publicera meddelanden endast på en kanal med samma tillhörande saknamn (listning 1).

Kopiera
{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action":["iot:Publish"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:topic/${iot:Connection.Thing.ThingName}"]
      },
      {
        "Effect": "Allow",
        "Action": ["iot:Connect"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"]
      }
    ]
}

Listning 1: Utvecklare använder ett JSON-format för att beskriva AWS IoT-åtkomsträttigheter för sina IoT-enheter. (Kodkälla: AWS)

Molnklara utvecklingssatser

Även om molnleverantörer erbjuder detaljerade specifikationer för dessa format och procedurer, är leverantörernas supportforum vanligtvis fyllda med frågor från utvecklare som utlöses av en liten, men viktig detalj som förhindrar autentisering och åtkomsthantering. Kanske ännu värre, ur säkerhetssynpunkt, är att oavsiktligt missbruk av verifieringar eller ofullständig definition åtkomstpolicyer kan lämna IoT-enheter, nätverk och applikationer sårbara för attacker. Kommersiellt tillgängliga utvecklingskort och tillhörande programvarupaket gör det möjligt för utvecklare att snabbt navigera igenom dessa anslutningsförfaranden genom att använda exempel från leverantörer för att snabbt ansluta till IoT-moln. Exempelvis: Espressif Systems ESP32-Azure IoT-sats eller Seeed Technologys AZ3166 IoT utvecklarsats inkluderar Azure-certifierade kort utformade för att enkelt ansluta till Microsoft-molnet.

Microsoft tillhandahåller kompletta steg-för-steg-demonstrationer, inklusive autentiserings- och åtkomstuppgifter för de utvecklingssatser som stöds. Med AZ3166-kortet, exempelvis, trycker utvecklare på knappar på kortet för att initiera anslutning till deras lokala Wi-Fi-nätverk. När de är anslutna kan de använda Azure IoT Device Workbench som finns i Azure IoT Tools-expansionspaketet för Microsoft Visual Studio Code för att utveckla, felsöka och interagera med Azure IoT Hub. Med hjälp av denna verktygssats och dess paket med exempelkod, kan utvecklare skapa ett objekt för IoT-enheten i Azure IoT Hub och använder en speciellt angiven fil för att tillhandahålla det tillhörande identitetsregistret med referenser och annan metadata som krävs för att ansluta IoT-kortet till Azure IoT Hub (figur 3).

Bild av exempelkod och referenser som tillhandahålls i Microsoft Azure IoT Device Workbench Bild 3: Exempelkod och referenser som tillhandahålls i Microsoft Azure IoT Device Workbench hjälper utvecklare att genomföra etableringen för att ansluta Seeed Technology AZ3166 IoT Developer Kit till Azure IoT Hub. (Bildkälla: Microsoft Azure)

Azure IoT Device Workbench tillhandahåller ytterligare supportprogramvara och metadata som låter utvecklare snabbt ladda AZ3166-kortet med exempelkod och börja sända mätningar från kortets temperatur- och fuktighetssensor till Azure IoT Hub.

Procedurerna för att skapa en modell av den fysiska IoT-enheten i IoT-molnet och för att etablera det tillhörande registret, behövs bara för att ansluta enheter till IoT-molnet. För att dra nytta av molntjänster behöver Azure IoT Hub dock en policy för åtkomsträttigheter. För att övervaka meddelanden från enheten till molnet som kommer från AZ3166-sensorn kan utvecklare helt enkelt använda Azures delade åtkomstpolicy för att välja en förkonstruerad policy utformad för att snabbt aktivera de nödvändiga åtkomsträttigheterna (figur 4).

Bild av Azures molntjänster med sensordata från Seeed Technology AZ3166 IoT Developer Kit (klicka för att förstora) Bild 4: Utvecklare kan använda förkonstruerade policyer för att enkelt godkänna användning av Azure-molntjänster med sensordata från Seeed Technology AZ3166 IoT Developer Kit. (Bildkälla: Microsoft Azure)

När de arbetar med AWS IoT kan utvecklare använda sig av utvecklingssatser som Microchip TechnologysAT88CKECC-AWS-XSTK-B Zero Touch Provisioning-kit och tillhörande programvara för att snabbt utvärdera molnanslutningar. Denna uppdaterade version av ett tidigare Microchip Zero Touch Provisioning-kit har förinstallerats med autentiseringsuppgifter. Med hjälp av ytterligare skript som medföljer satsen kan utvecklare snabbt ansluta kortet till AWS IoT utan att hantera privata nycklar och certifikat (se "Välj Zero-Touch-strategin för att säkert låsa en IoT-enhet").

Andra utvecklingssatser, såsom RenesasRTK5RX65N0S01000BE RX65N Cloud Kit och Infineon Technologies AWS IoT-satsKITXMC48IOTAWSWIFITOBO1, utvidgar stödet för AWS IoT-uppkoppling med stöd för snabb utveckling av applikationer baserade på Amazon FreeRTOS. AWS ger detaljerade anvisningar för att registrera korten, skapa autentiseringsuppgifter och ladda JSON-policyer som krävs för att ansluta till AWS IoT och använda AWS-tjänster.

Förenkla etableringen av storskaliga IoT-utrullningar

Utvecklingssatser som de som beskrivs ovan fungerar som effektiva plattformar både för snabb prototyputveckling av IoT-applikationer och för att utforska kraven vid anslutning av IoT-molntjänster. I praktiken kommer utvecklare dock vanligtvis att behöva använda mer avancerade metoder som är utformade för att förenkla etableringen av IoT-enheter i verkliga tillämpningar. Både Azure IoT och AWS IoT stöder en mängd olika metoder som möjliggör en mer automatiserad etablering av enskilda enheter eller ett stort antal IoT-enheter i en storskalig implementering.

Med AWS IoT, exempelvis, kan utvecklare använda en bootstrap-metod för att certifikattilldelning. Här skickas den smarta produkten med ett bootstrap-certifikat associerat med de minimala åtkomsträttigheterna som krävs för att begära och få åtkomst till ett nytt certifikat (figur 5).

Diagram över hur AWS IoT stödjer en metod för att bootstrappa certifikattilldelning i IoT-enheter Bild 5: AWS IoT stödjer en metod för att bootstrappa certifikattilldelning i IoT-enheter. (Bildkälla: DigiKey, från Amazon Web Services)

Med hjälp av bootstrap-certifikatet ansluter enheten till molnet ("1" i figur 5), begär ("2") ett nytt certifikat, tar emot ("3") URL:en till certifikatet genererat av en AWS-serverlös Lambda-funktion och hämtar ("4") certifikatet från en AWS Simple Storage Services-depå (S3). Med det nya certifikatet loggar sedan enheten in igen i AWS IoT ("5") för att fortsätta med normala operationer.

AWS erbjuder andra molntjänster som stöder dynamisk tilldelning av autentiseringstokens med exekveringsresurser som AWS Lambda-funktioner. Till exempel kan en fordonstillämpning förlita sig på en serie volatila anslutningar där användning av en token är både mer praktiskt och säkrare. Efter att en AWS-modul för IoT-autentisering och auktorisering godkänner begäran om en token, genererar AWS Security Token Service (STS) en token för leverans till fordonets system. Med hjälp av denna token kan dessa system få åtkomst till AWS-tjänster som är föremål för validering av tjänsten AWS Identity and Access Management (IAM) (figur 6).

Diagram över hur ledande leverantörer av molntjänster stöder andra former av intyg Bild 6: Ledande leverantörer av molntjänster stödjer andra former av intyg för verifiering, såsom denna process för dynamisk generering av säkerhetstokens av AWS Security Token Service (STS). (Bildkälla: Amazon Web Services)

AWS ger en liknande kapacitet för dynamisk tilldelning av åtkomsträttigheter. Här skulle andra AWS Lambda-funktioner kunna tilldela en uppsättning policyer associerade med en giltig token (figur 7).

Diagram över hur utvecklare kan använda molntjänster för att implementera dynamisk tilldelning av åtkomsträttigheter Bild 7: Utvecklare kan använda molntjänster för att implementera dynamisk tilldelning av åtkomsträttigheter, vilket är särskilt användbart för applikationer med flyktiga anslutningar eller kortlivade operationer. (Bildkälla: Amazon Web Services)

Andra IoT-molntjänster gör det möjligt för utvecklare att mer effektivt hantera etableringar i storskaliga distributioner. Exempelvis tillhandahåller AWS IoT funktioner för att massetablera enheter, inklusive stöd för distribution i större skala av den typ av bootstrap-metod som beskrivits tidigare. Azure IoTs Device Provisioning Service tillhandahåller en gruppregistreringsfunktion som stödjer etablering av ett stort antal IoT-enheter som har samma X.509-certifikat eller SAS-token.

Delat ansvar för säkerhet

IoT-molnleverantörer tillhandahåller ett antal effektiva metoder för att förbättra säkerhet hos IoT-applikationer. IoT-utvecklare kan dock inte förvänta sig att dessa metoder kan bära den fulla bördan av alla säkerhetskrav för deras specifika IoT-applikation. Faktum är att molntjänstleverantörer noggrant beskriver sin specifika roll och ansvar inom IoT-applikationssäkerhet med hjälp av specifika modeller som AWS:s delade ansvarsmodell (figur 8).

Diagram över hur AWS beskriver de ansvarsområden som de delar med molnanvändare Bild 8: Liksom med andra ledande molnleverantörer, beskriver AWS ansvarsområdena som de delar med molnanvändare för att skydda molninfrastrukturen å ena sidan och kundapplikationer å andra sidan. (Bildkälla: Amazon Web Services)

AWS och Microsoft Azure tillhandahåller båda delade ansvarsdokument som beskriver och förklarar leverantörens egen roll och kundens roll när det gäller att säkra resurser, data och applikationer. I sin dokumentation erbjuder Microsoft också en översikt över några av förhållandena mellan delad säkerhet och efterlevnadskrav. I slutändan behåller molnleverantörer ansvaret för molnets säkerhet, medan kunderna förblir ansvariga för applikationer, data och resurser som används i molnet.

Slutsats

IoT-applikationer är beroende av säkerhetslager byggda på hårdvarubaserade mekanismer för kryptografi och säker nyckellagring. Som med alla anslutna produkter kan säkerhetshot komma i alla slags interaktioner när IoT-enheter ansluter till molntjänster. För att skydda sig själva och sina kunder, dikterar IoT-molnleverantörer specifika krav för autentisering och hantering av åtkomsträttigheter. Även om leverantörer erbjuder detaljerad dokumentation om dessa krav och tillhörande specifikationer, kan utvecklare upptäcka att deras ansträngningar för att implementera säkra anslutningar ibland lämnar resurser utsatta, eller omvänt, otillgängliga. Med hjälp av utvecklingskort och tillhörande programvara kan utvecklare snabbt ansluta till molntjänster och snabbt prototypkonstruera IoT-applikationer med säkerhet från början till slutet av kedjan.

DigiKey logo

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of DigiKey or official policies of DigiKey.

Om skribenten

Image of Stephen Evanczuk

Stephen Evanczuk

Stephen Evanczuk har arbetat i mer än 20 år med att skriva för och om elektronikbranschen inom många olika områden som maskinvara, programvara, system och applikationer – inklusive sakernas internet. Han har en kandidatexameni neurovetenskap om artificiella neuronnät och har arbetat inom rymdfartsindustrin med mycket distribuerade säkra system och metoder för acceleration av algoritmer. När han inte skriver artiklar om teknik och konstruktion arbetar han med applikationer för djupinlärning för igenkänningssystem och rekommendationssystem.

Om utgivaren

DigiKeys nordamerikanska redaktörer