Sakernas Internet (IoT) säkerhetsarkitektur

När du utformar ett system är det viktigt att förstå de potentiella hoten mot systemet och lägga till lämpliga försvar i enlighet med detta, eftersom systemet är utformat och utformat. Det är viktigt att designa produkten från början med säkerhet i åtanke, eftersom en förståelse för hur en angripare kan kompromettera ett system hjälper till att se till att lämpliga åtgärder redan från början är på plats.

Säkerheten börjar med en hotmodell

Microsoft har länge använt hotmodeller för sina produkter och har gjort företagets hotmodelleringsprocess allmänt tillgänglig. Företagsupplevelsen visar att modellering har oväntade fördelar utöver den omedelbara förståelsen av vilka hot som är mest allvarliga. Det skapar till exempel också en väg för en öppen diskussion med andra utanför utvecklingsteamet, vilket kan leda till nya idéer och förbättringar i produkten.

Målet med hotmodellering är att förstå hur en angripare kan kompromettera ett system och sedan se till att lämpliga åtgärder finns på plats. Hotmodellering tvingar designteamet att överväga åtgärder eftersom systemet är utformat i stället för när ett system har distribuerats. Det här är ytterst viktigt eftersom det inte är möjligt att efteranpassa säkerhetsskydd till en mängd olika enheter på fältet, vilket gör att kunderna blir riskbenägna.

Många utvecklingsteam gör ett utmärkt jobb med att samla in de funktionella kraven för det system som är till nytta för kunderna. Det är dock svårare att identifiera icke-uppenbara sätt som någon kan missbruka systemet på. Hotmodellering kan hjälpa utvecklingsteamen att förstå vad en angripare kan göra och varför. Hotmodellering är en strukturerad process som skapar en diskussion om beslut om säkerhetsdesign i systemet, samt ändringar av den design som görs längs vägen som påverkar säkerheten. Även om en hotmodell helt enkelt är ett dokument, representerar den här dokumentationen också ett perfekt sätt att garantera kontinuitet för kunskap, kvarhållning av erfarenheter och hjälpa det nya teamet att komma igång snabbt. Slutligen är ett resultat av hotmodellering att du kan överväga andra säkerhetsaspekter, till exempel vilka säkerhetsåtaganden du vill ge dina kunder. Dessa åtaganden i samband med hotmodellering informerar och driver testning av din Sakernas Internet (IoT).

När du ska göra hotmodellering

Hotmodellering ger det största värdet när du införlivar det i designfasen. När du designar har du störst flexibilitet att göra ändringar för att eliminera hot. Att eliminera hot är enligt design det önskade resultatet. Det är mycket enklare än att lägga till åtgärder, testa dem och se till att de förblir aktuella och dessutom är sådan borttagning inte alltid möjligt. Det blir svårare att eliminera hot när en produkt blir mognare och i sin tur kräver mer arbete och mycket svårare kompromisser än hotmodellering tidigt i utvecklingen.

Vad du bör tänka på för hotmodellering

Du bör titta på lösningen som helhet och fokusera på följande områden:

• Säkerhets- och sekretessfunktionerna
• De funktioner vars fel är säkerhetsrelev relevanta
• De funktioner som berör en förtroendegräns

Vem utför hotmodellering

Hotmodellering är en process som vilken annan process som helst. Det är en bra idé att behandla hotmodelldokumentet som vilken annan komponent som helst i lösningen och validera den. Många utvecklingsteam gör ett utmärkt jobb med att samla in de funktionella kraven för det system som är till nytta för kunderna. Det är dock svårare att identifiera icke-uppenbara sätt som någon kan missbruka systemet på. Hotmodellering kan hjälpa utvecklingsteamen att förstå vad en angripare kan göra och varför.

Så här utför du hotmodellering

Hotmodelleringsprocessen består av fyra steg: Stegen är:

• Modellera programmet
• Räkna upp hot
• Minimera hot
• Verifiera åtgärder

Processstegen

Tre tumregler att tänka på när du skapar en hotmodell:

1. Skapa ett diagram utanför referensarkitekturen.

2. Starta bredd först. Få en översikt och förstå systemet som helhet innan du gör djupdykning. Den här metoden hjälper till att se till att du fördjupar dig på rätt platser.

3. Kör processen, låt inte processen driva dig. Om du hittar ett problem i modelleringsfasen och vill utforska det kan du använda det! Du behöver inte följa de här stegen på ett dåligt sätt.

Hot

De fyra kärnelementen i en hotmodell är:

• Processer som webbtjänster, Win32-tjänster och *nix-daemons. Vissa komplexa entiteter (till exempel fältgatewayer och sensorer) kan abstraheras som en process när en teknisk detaljgranskning i dessa områden inte är möjlig.

• Datalager (var som helst där data lagras, till exempel en konfigurationsfil eller databas)

• Dataflöde (där data flyttas mellan andra element i programmet)

• Externa entiteter (allt som interagerar med systemet, men som inte är under kontroll av programmet, exempel är användare och satellitflöden)

Alla element i arkitekturdiagrammet är föremål för olika hot. den här artikeln stride mnemonic. Läs Threat Modeling Again, STRIDE (Hotmodellering igen, STRIDE) om du vill veta mer om STRIDE-elementen.

Olika element i programdiagrammet är föremål för vissa STRIDE-hot:

• Processer omfattas av STRIDE
• Dataflöden omfattas av TID
• Datalager omfattas av TID, och ibland R, när datalager är loggfiler.
• Externa entiteter omfattas av SRD

Säkerhet i IoT

Anslutna enheter för särskilda ändamål har ett stort antal potentiella interaktionsytaområden och interaktionsmönster, som alla måste betraktas som ett ramverk för att skydda digital åtkomst till dessa enheter. Termen "digital åtkomst" används här för att skilja från åtgärder som utförs via direkt enhetsinteraktion där åtkomstsäkerhet tillhandahålls via fysisk åtkomstkontroll. Du kan till exempel placera enheten i ett rum med ett lås på dörren. Fysisk åtkomst kan inte nekas med hjälp av programvara och maskinvara, men åtgärder kan vidtas för att förhindra fysisk åtkomst från att leda till systeminter interferens.

När du utforskar interaktionsmönstren kan du titta på "enhetskontroll" och "enhetsdata" med samma uppmärksamhetsnivå. "Enhetskontroll" kan klassificeras som all information som tillhandahålls till en enhet av någon part med målet att ändra eller påverka dess beteende mot dess tillstånd eller tillståndet för dess miljö. "Enhetsdata" kan klassificeras som all information som en enhet skickar till någon annan part om dess tillstånd och det observerade tillståndet för dess miljö.

För att optimera rekommenderade säkerhetsmetoder rekommenderar vi att en typisk IoT-arkitektur delas in i flera komponenter/zoner som en del av hotmodelleringsövningen. Dessa zoner beskrivs fullständigt i det här avsnittet och omfattar:

• Enhet
• Fältgateway,
• Molngatewayer och
• Tjänster.

Zoner är ett brett sätt att segmentera en lösning. varje zon har ofta sina egna data- och autentiserings- och auktoriseringskrav. Zoner kan också användas för isoleringsskador och begränsa effekten av låg förtroendezoner på högre förtroendezoner.

Varje zon avgränsas med en förtroendegräns, som anges som den streckade röda linjen i följande diagram. Den representerar en övergång av data/information från en källa till en annan. Under den här övergången kan data/information vara föremål för förfalskning, manipulering, avvislighet, avslöjande av information, denial of service och höjning av privilegium (STRIDE).

De komponenter som illustreras inom varje gräns utsätts också för STRIDE, vilket möjliggör en fullständig 360-hotmodelleringsvy av lösningen. Följande avsnitt beskriver var och en av de komponenter och specifika säkerhetsproblem och lösningar som ska användas.

I följande avsnitt beskrivs standardkomponenter som vanligtvis finns i dessa zoner.

Enhetszonen

Enhetsmiljön är det omedelbara fysiska utrymmet runt enheten där fysisk åtkomst och/eller "lokalt nätverk" digital peer-to-peer-åtkomst till enheten är möjlig. Ett "lokalt nätverk" antas vara ett nätverk som är distinkt och isolerat från – men eventuellt överbryggat till – det offentliga Internet, och som innehåller all trådlös radioteknik med kort räckvidd som tillåter peer-to-peer-kommunikation av enheter. Den omfattar inte någon teknik för nätverksvirtualisering som skapar en illusion av ett sådant lokalt nätverk och omfattar inte heller offentliga operatörsnätverk som kräver att två enheter kommunicerar över det offentliga nätverksutrymmet om de skulle gå in i en peer-to-peer-kommunikation.

Fältets gatewayzon

Fältgateway är en enhet/enhet eller någon allmän serverdatorprogramvara som fungerar som kommunikationsaktiverare och, eventuellt, som ett enhetskontrollsystem och en hubb för databehandling av enhet. Fältets gatewayzon innehåller själva fältgatewayen och alla enheter som är kopplade till den. Som namnet antyder fungerar fältgatewayer utanför dedikerade databearbetningsanläggningar, vanligtvis är platsbundna, kan utsättas för fysiska intrång och har begränsad driftsredundans. Alla säger att en fältgateway ofta är något som kan beröra och förstöras samtidigt som man vet vad dess funktion är.

En fältgateway skiljer sig från en enkel trafikrouter på så sätt att den har haft en aktiv roll i hanteringen av åtkomst- och informationsflöden, vilket innebär att det är en program adresserad entitet och nätverksanslutning eller sessionsterminal. En NAT-enhet eller brandvägg räknas däremot inte som fältgatewayer eftersom de inte är explicita anslutningar eller sessionsterminaler, utan snarare en väganslutning (eller blockering) som görs genom dem. Fältgatewayen har två distinkta ytområden. En står inför de enheter som är kopplade till den och representerar inuti zonen, och den andra ansikten alla externa parter och är zonens kant.

Molngatewayzonen

En molngateway är ett system som möjliggör fjärrkommunikation från och till enheter eller fältgatewayer från flera olika platser i det offentliga nätverksutrymmet, vanligtvis mot ett molnbaserat system för kontroll och dataanalys, en federation av sådana system. I vissa fall kan en molngateway omedelbart underlätta åtkomst till särskilda enheter från terminaler som surfplattor eller telefoner. I det sammanhang som beskrivs här är "molnet" avsett att referera till ett dedikerat databearbetningssystem som inte är bundet till samma plats som anslutna enheter eller fältgatewayer. I en molnzon förhindrar operativa åtgärder även riktad fysisk åtkomst och är inte nödvändigtvis exponerade för en "offentlig molninfrastruktur".

En molngateway kan eventuellt mappas till ett överlägg för nätverksvirtualisering för att isolera molngatewayen och alla dess anslutna enheter eller fältgatewayer från all annan nätverkstrafik. Själva molngatewayen är inte ett enhetskontrollsystem eller en bearbetnings- eller lagringsplats för enhetsdata. gränssnittet med molngatewayen. Molngatewayzonen innehåller själva molngatewayen tillsammans med alla fältgatewayer och enheter som är direkt eller indirekt kopplade till den. Zonens kant är ett distinkt ytområde där alla externa parter kommunicerar via.

Tjänstzonen

En "tjänst" definieras för den här kontexten som alla programvarukomponenter eller -moduler som är sammankopplade med enheter via en fält- eller molngateway för insamling och analys av data samt för command and control. Tjänster är medlare. De agerar under sin identitet mot gatewayer och andra undersystem, lagrar och analyserar data, utfärdar automatiskt kommandon till enheter baserat på datainsikter eller scheman och exponerar information och kontrollfunktioner för behöriga slutanvändare.

Informationsenheter jämfört med enheter för särskilda ändamål

Datorer, telefoner och surfplattor är främst interaktiva informationsenheter. Telefoner och surfplattor är uttryckligen optimerade för att maximera batterilivslängden. De inaktiverar helst delvis när de inte omedelbart interagerar med en person, eller när de inte tillhandahåller tjänster som att spela musik eller guida ägaren till en viss plats. Från ett systemperspektiv fungerar dessa informationsteknikenheter huvudsakligen som proxy för människor. De är "people actuators" som föreslår åtgärder och "people sensors" som samlar in indata.

Specialenheter, från enkla temperatursensorer till komplexa fabriksproduktionslinjer med tusentals komponenter i sig, skiljer sig åt. Dessa enheter är mycket mer begränsade och även om de tillhandahåller ett användargränssnitt är de i stort sett begränsade till att samverka med eller integreras i tillgångar i den fysiska världen. De mäter och rapporterar miljöförhållanden, aktiverar kontroller, larm, släcker lampor och utför många andra uppgifter. De hjälper till att göra arbete där en informationsenhet antingen är för allmän, för dyr, för stor eller för skör. Det konkreta syftet styr omedelbart deras tekniska design samt den tillgängliga ekonomiska budgeten för deras produktion och schemalagda livslängd. Kombinationen av dessa två viktiga faktorer begränsar den tillgängliga driftsenergibudgeten, det fysiska fotavtrycket och därmed tillgängliga funktioner för lagring, beräkning och säkerhet.

Om något "går fel" med automatiserade eller fjärrstyrbara enheter, till exempel fysiska defekter eller kontrollerar logiska defekter för obehöriga intrång och manipulering. Produktionsenheterna kan förstöras, byggnader kan vara nedsyplade eller nedbrunna, och människor kan till och med dö. Det här är en helt annan typ av skada än om någon maxar gränsen för ett stulet kreditkort. Säkerhetsfältet för enheter som flyttar saker och även för sensordata som så småningom resulterar i kommandon som gör att saker flyttas måste vara högre än i alla e-handels- eller bankscenarion.

Interaktioner mellan enhetskontroll och enhetsdata

Anslutna enheter för särskilda syften har ett stort antal potentiella interaktionsytaområden och interaktionsmönster, som alla måste betraktas som ett ramverk för att skydda digital åtkomst till dessa enheter. Termen "digital åtkomst" används här för att skilja från åtgärder som utförs via direkt enhetsinteraktion där åtkomstsäkerhet tillhandahålls via fysisk åtkomstkontroll. Du kan till exempel placera enheten i ett rum med ett lås på dörren. Fysisk åtkomst kan inte nekas med hjälp av programvara och maskinvara, men åtgärder kan vidtas för att förhindra att fysisk åtkomst leder till systemstörningar.

När du utforskar interaktionsmönstren kan du titta på "enhetskontroll" och "enhetsdata" med samma uppmärksamhetsnivå vid hotmodellering. "Enhetskontroll" kan klassificeras som all information som tillhandahålls till en enhet av en part med målet att ändra eller påverka dess beteende mot dess tillstånd eller tillståndet för dess miljö. "Enhetsdata" kan klassificeras som all information som en enhet skickar till någon annan part om dess tillstånd och det observerade tillståndet för dess miljö.

Utföra hotmodellering för Azure IoT-referensarkitekturen

Microsoft använder ramverket som beskrevs tidigare för att göra hotmodellering för Azure IoT. I följande avsnitt används det konkreta exemplet på Referensarkitektur för Azure IoT för att visa hur du kan tänka på hotmodellering för IoT och hur du kan åtgärda de hot som identifieras. I det här exemplet identifieras fyra huvudområden:

• Enheter och datakällor,
• Datatransport,
• Enhet och händelsebearbetning, och
• Presentation

Följande diagram ger en förenklad vy över Microsofts IoT-arkitektur med hjälp av en data-Flow-diagrammodell som används av Microsoft Threat Modeling Tool:

Det är viktigt att notera att arkitekturen separerar enhetens och gatewayens funktioner. Den här metoden gör det möjligt för användaren att utnyttja gatewayenheter som är säkrare: de kan kommunicera med molngatewayen med hjälp av säkra protokoll, vilket vanligtvis kräver större bearbetningskostnader som en inbyggd enhet – till exempel en termostat – kan tillhandahålla på egen hand. I azure-tjänstzonen förutsätter vi att Cloud Gateway representeras av den Azure IoT Hub tjänsten.

Enhets- och datakällor/datatransport

Det här avsnittet utforskar arkitekturen som beskrevs tidigare med hjälp av hotmodellering och ger en översikt över hur du kan åtgärda några av de inbyggda problemen. Det här exemplet fokuserar på huvudelementen i en hotmodell:

• Processer (både under din kontroll och externa objekt)
• Kommunikation (kallas även för dataflöden)
• Storage (kallas även datalager)

Processer

I var och en av kategorierna som beskrivs i Azure IoT-arkitekturen försöker det här exemplet minimera ett antal olika hot i de olika faserna som data/information finns i: process, kommunikation och lagring. Följande är en översikt över de vanligaste för kategorin "process", följt av en översikt över hur dessa hot kan åtgärdas på bästa sätt:

Förfalskning (S): En angripare kan extrahera kryptografiskt nyckelmaterial från en enhet, antingen på programvaru- eller maskinvarunivå, och sedan komma åt systemet med en annan fysisk eller virtuell enhet under identiteten för den enhet som nyckelmaterialet har tagits från. En bra illustration är fjärrkontroller som kan omvandla vilken TV som helst och som är populära prankster-verktyg.

Denial of Service (D): En enhet kan inte fungera eller kommunicera genom att störa radiofrekvenser eller trådskärning. Till exempel kan en övervakningskamera som hade ström eller nätverksanslutning avsiktligt inte rapportera data alls.

Manipulering (T): En angripare kan delvis eller helt ersätta programvaran som körs på enheten, vilket potentiellt gör att den ersatta programvaran kan utnyttja enhetens äkta identitet om nyckelmaterialet eller de kryptografiska anläggningar som innehåller nyckelmaterial var tillgängliga för det otillåtna programmet. En angripare kan till exempel utnyttja extraherat nyckelmaterial för att fånga upp och ignorera data från enheten på kommunikationsvägen och ersätta dem med falska data som autentiseras med det stulna nyckelmaterialet.

Avslöjande av information (I): Om enheten kör manipulerad programvara kan sådan manipulerad programvara potentiellt läcka data till obehöriga parter. En angripare kan till exempel utnyttja extraherat nyckelmaterial för att mata in sig själv i kommunikationsvägen mellan enheten och en kontrollant eller fältgateway eller molngateway för att sprida information.

Höjning av privilegium (E): En enhet som har en specifik funktion kan tvingas att göra något annat. En valve som är programmerad för att öppna halvvägs kan till exempel luras att öppna hela vägen.

Här följer några exempel på hot i den här kategorin:

Förfalskning: En angripare kan extrahera kryptografiskt nyckelmaterial från en enhet, antingen på programvaru- eller maskinvarunivå, och sedan komma åt systemet med en annan fysisk eller virtuell enhet under identiteten för enheten som nyckelmaterialet har tagits från.

Denial of Service (Denial of Service): En enhet kan inte fungera eller kommunicera genom att störa radiofrekvenser eller trådskärning. Till exempel kan en övervakningskamera som hade ström eller nätverksanslutning avsiktligt inte rapportera data alls.

Manipulering: En angripare kan delvis eller helt ersätta programvaran som körs på enheten, vilket potentiellt gör att den ersatta programvaran kan utnyttja enhetens äkta identitet om nyckelmaterialet eller de kryptografiska anläggningar som innehåller nyckelmaterial var tillgängliga för det otillåtna programmet.

Manipulering: En övervakningskamera som visar en synlig spektrumbild av en toming kan vara avsedd för ett foto av en sådan tavla. En rök- eller brandsensor kan rapportera att någon håller en lättare under sig. I båda fallen kan enheten tekniskt sett vara helt tillförlitlig för systemet, men den rapporterar manipulerad information.

Manipulering: En angripare kan utnyttja extraherat nyckelmaterial för att fånga upp och förhindra data från enheten på kommunikationsvägen och ersätta dem med falska data som autentiseras med det stulna nyckelmaterialet.

Avslöjande av information: Om enheten kör manipulerad programvara kan sådan manipulerad programvara potentiellt läcka data till obehöriga parter.

Avslöjande av information: En angripare kan utnyttja extraherat nyckelmaterial för att mata in sig själv i kommunikationsvägen mellan enheten och en kontrollant eller fältgateway eller molngateway för att sprida information.

Denial of Service (DoS): Enheten kan stängas av eller omvandlas till ett läge där kommunikation inte är möjlig (vilket är avsiktligt i många industriella datorer).

Manipulering: Enheten kan konfigureras att fungera i ett tillstånd som inte är känt för kontrollsystemet (utanför kända kalibreringsparametrar) och därmed tillhandahålla data som kan feltolkas

Höjning av privilegium: En enhet som har en specifik funktion kan tvingas att göra något annat. En valve som är programmerad för att öppna halvvägs kan till exempel luras att öppna hela vägen.

Förfalskning/manipulering/avvislighet: Om det inte är säkert (vilket sällan är fallet med konsument-fjärrkontroller) kan en angripare manipulera tillståndet för en enhet anonymt. En bra illustration är fjärrkontroller som kan omvandla vilken TV som helst och som är populära prankster-verktyg.

Kommunikation

Hot kring kommunikationsvägen mellan enheter, enheter och fältgatewayer samt enhets- och molngateway. Följande tabell innehåller vägledning om öppna sockets på enheten/VPN:

Här följer några exempel på hot i den här kategorin:

Nekad tjänst: Begränsade enheter är vanligtvis under DoS-hot när de aktivt lyssnar efter inkommande anslutningar eller oönskade datagram i ett nätverk, eftersom en angripare kan öppna många anslutningar parallellt och inte hantera dem eller hantera dem långsamt, eller så kan enheten översvämmas med oönskad trafik. I båda fallen kan enheten effektivt renderas oanvändbar i nätverket.

Förfalskning, avslöjande av information: Begränsade enheter och särskilda enheter har ofta en-till-alla-säkerhetsresurser som lösenord eller PIN-skydd, eller så förlitar de sig på att lita på nätverket, vilket innebär att de beviljar åtkomst till information när en enhet finns i samma nätverk och nätverket ofta endast skyddas av en delad nyckel. Det innebär att när den delade hemligheten till enheten eller nätverket avslöjas, är det möjligt att kontrollera enheten eller observera data som genereras från enheten.

Förfalskning: en angripare kan fånga upp eller delvis åsidosätta sändningen och förfalskning av avsändaren (man i mitten).

Manipulering: En angripare kan fånga upp eller delvis åsidosätta sändningen och skicka falsk information.

Avslöjande av information: en angripare kan avlyssna på en sändning och få information utan tillstånd.

Denial of Service (DoS): En angripare kan störa sändningssignalen och neka informationsdistributionen.

Storage

Varje enhets- och fältgateway har någon form av lagring (tillfällig för att köa data, operativsystemavbildningslagring).

Enhets- och händelsebearbetning/molngatewayzon

En molngateway är ett system som möjliggör fjärrkommunikation från och till enheter eller fältgatewayer från flera olika platser i det offentliga nätverksutrymmet, vanligtvis mot ett molnbaserat system för kontroll och dataanalys, en federation av sådana system. I vissa fall kan en molngateway omedelbart underlätta åtkomst till enheter för särskilda ändamål från terminaler som surfplattor eller telefoner. I den kontext som beskrivs här är "molnet" avsett att referera till ett dedikerat databearbetningssystem som inte är bundet till samma plats som anslutna enheter eller fältgatewayer, och där driftåtgärder förhindrar riktad fysisk åtkomst, men inte nödvändigtvis till en infrastruktur för "offentligt moln". En molngateway kan eventuellt mappas till ett överlägg för nätverksvirtualisering för att isolera molngatewayen och alla anslutna enheter eller fältgatewayer från all annan nätverkstrafik. Själva molngatewayen är inte ett enhetskontrollsystem eller en bearbetnings- eller lagringsplats för enhetsdata. dessa anläggningar samverkar med molngatewayen. Molngatewayzonen innehåller själva molngatewayen tillsammans med alla fältgatewayer och enheter som är direkt eller indirekt kopplade till den.

Molngateway är huvudsakligen anpassad programvara som körs som en tjänst med exponerade slutpunkter som fältgatewayen och enheterna ansluter till. Därför måste den utformas med säkerhet i åtanke. Följ SDL-processen för att utforma och skapa den här tjänsten.

Tjänstzon

Ett kontrollsystem (eller kontrollant) är en programvarulösning som samverkar med en enhet, en fältgateway eller en molngateway för att kontrollera en eller flera enheter och/eller för att samla in och/eller lagra och/eller analysera enhetsdata för presentation eller efterföljande kontrollsyften. Kontrollsystem är de enda entiteter i den här diskussionen som omedelbart kan underlätta interaktionen med människor. Undantagen är mellanliggande fysiska kontrollytor på enheter, till exempel en växel som gör att en person kan stänga av enheten eller ändra andra egenskaper och för vilka det inte finns någon funktionell motsvarighet som kan nås digitalt.

Mellanliggande fysiska kontrollytor är sådana där styrningslogik begränsar funktionen på den fysiska kontrollytan så att en motsvarande funktion kan initieras via fjärrstyrning eller indatakonflikter med fjärrindata kan undvikas – sådana mellanliggande kontrollytor är konceptuellt kopplade till ett lokalt kontrollsystem som utnyttjar samma underliggande funktioner som andra fjärrstyrningssystem som enheten kan kopplas till parallellt. De främsta hoten mot molnbaserad databehandling kan läsas på sidan om Cloud Security Alliance (CSA).

Ytterligare resurser

Mer information finns i följande artiklar:

• SDL-Threat Modeling Tool
• Microsoft Azure IoT-referensarkitektur

Se även

Läs mer IoT Hub säkerhet i Kontrollera åtkomst till IoT Hub i IoT Hub utvecklarhandbok.