IoT-bloggen: Autentisering och auktorisering för IoT-system

Jonas Modling

 IoT-arkitekt och expertrådgivare på Attentec

Jag hjälper våra kunder att förstå sina behov och tar fram effektiva lösningsförslag på deras specifika utmaningar inom IoT.

Autentisering och auktorisering är svåra ämnen i sig och alla som utvecklar system gör klokt i att lägga ordentligt med eftertanke i sina lösningar på båda utmaningarna. Av naturliga skäl finns det en hel del färdiga paket att använda för autentisering medan auktorisering är mycket mer individuellt för varje system. Auktorisering ställer därmed mycket högre krav på utvecklarnas och arkitekternas kompetens än autentisering.

Inom kontexten internet of things (IoT) finns det ett par speciella omständigheter att ta hänsyn till när man bygger autentisering och auktorisering. Några av de viktigaste ska jag försöka belysa och resonera kring här, men först lite allmän introduktion.

Vad är autentisering?

Autentisering är mekanismen som ett system använder för att förstå vem eller vad som interagerar just nu. I det här sammanhanget är det helt ointressant huruvida användaren gör något bra eller dåligt i systemet, det enda viktiga är att vi vet vem det är.

Vad är auktorisering?

Auktorisering är mekanismen som ett system använder för att ta reda på om den autentiserade användaren får utföra en specifik handling. Auktorisering förutsätter alltså att en användare är autentiserad och aktiveras först när en autentiserad användare försöker utföra en handling.

Vilka metoder finns det för autentisering?

Det finns mängder av metoder för att autentisera användare och elektronik. Oftast är det lämpligt att använda olika metoder för mänskliga användare och IoT-enheter.

Det vanligaste för mänskliga användare är lösenordsautentisering eller sk. multifaktor-autentisering (MFA eller 2FA) där du t.ex. uppvisar både något du kan (PIN-kod) och något du innehar (din mobiltelefon).

“För IoT-enheter ser jag två huvudspår användas på marknaden: statiska lösenord eller kryptografiska certifikat.”

Statiska lösenord sparas typiskt på enheten vid produktion och används därefter i all kommunikation mellan enheten och alla servrar. Använder man istället sk. X.509-certifikat, vid korrekt användning den säkraste metoden på marknaden, så har man typiskt integrerat sina enheter och serverinfrastruktur med en sk. public key infrastructure (PKI-infrastruktur). Ett alternativ till X.509-certifikaten som är mindre standardiserat är att ställa ut JWT-tokens istället, vilket innebär vissa andra implikationer.

Inom autentisering pratar man även om “autentiseringsmodeller” (symmetrisk eller asymmetrisk) och “autentiseringsramverk” (enkelvägs, ömsesidig, trevägs, centraliserad eller distribuerad). Beroende på tillämpning kan de här frågorna ha stor påverkan på säkerhetsnivån så det är klokt att göra ett informerat val.

Vilka metoder finns det för auktorisering?

Rent tekniskt finns det bra verktyg för auktorisering inbyggt i de flesta språk och ramverk idag. Det är dock allt annat än trivialt att realisera en implementation som både är säker, enkel att använda och enkel att utöka. Jag tycker att man kan dela upp diskussionen i två delar: auktoriseringsflöde och accesskontroll.

Auktoriseringsflöden handlar om hur en användare skaffar sig rättigheter eller omvänt hur systemet gör för att få reda på om en användare har rätt att utföra en viss handling. Man kan lära sig mycket bara genom att söka på “OAuth 2.0” på Google, som är en grupp standardiserade auktoriseringsflöden för vanliga situationer. De är generellt väldigt välkonstruerade och tillförlitliga. Den största risken jag har sett i verkligheten är att man bara delvis implementerar ett flöde och därmed går miste om den viktiga säkerhetstekniska fördelen med just det flödet. Håll tungan rätt i mun!

Vill man läsa mer om accesskontroll kan man söka efter termer som Mandatory Access Control (MAC), Role-Based Access Control (RBAC), Discretionary Access Control (DAC) och Rule-Based Access Control (RBAC or RB-RBAC). Det överlägset vanligaste jag har sett är rollbaserad accesskontroll, där användare tilldelas roller och rollerna består av en lista med rättigheter som den rollen har. Det är en bra tradeoff mellan enkelhet och konfigurerbarhet.

Den viktiga följdfrågan till accesskontroll, som gör auktorisering så individuellt för varje system, är hur man ska skära sina rättigheter. Vad är rätt för just dig? Per API-endpoint? Per accessnivå enligt det traditionella CRUD-mönstret? Per grupptillhörighet som vid filaccesser inom Linux?

Min åsikt är att det finns fler än ett rätt svar och mitt råd till dig som läser är att det typiskt betalar sig att tänka igenom den här frågan ordentligt.

Varför använda olika autentiseringsmetoder för användare och IoT-enheter?

Jag upplever att många känner till att det finns olika typer av mänskliga användare och förstår att olika roller har olika behov och därmed kräver olika rättigheter i ett system. Åsikterna går däremot isär och tveksamheten blir större när man betraktar elektronik som en aktör i systemet. Vissa vill behandla alla likadant rent tekniskt och skapar därmed användarkonton för elektroniken, andra har ingen identitet alls för elektroniken men kräver att en vanlig användare har registrerat enheten i systemet.

Jag tycker att både användare och elektronik alltid ska utsättas för både autentisering och auktorisering. IoT-enheter och vanliga användare skiljer sig på ett antal punkter och bör därför behandlas olika av systemet. Jag kan räkna upp flera egenskaper hos IoT-enheter som jag tycker bidrar till den slutsatsen.

1. 1. Den första och viktigaste skillnaden är att IoT-enheter ofta befinner sig i en utsatt och svårkontrollerad situation. Den kan vara monterad långt ute i skogen eller på en lyktstolpe på ett vältrafikerat torg, på väggen i ett bibliotek eller under rälsen längs tågspår. Vem vet vilka skumma typer som pillar på prylarna när du inte tittar? Ofta interagerar vi bara fysiskt med IoT-enheter när vi monterar upp dem och när vi monterar ned dem, däremellan har man inte riktigt koll på vad som händer med dem.
5.  
6. 2. Skillnad nummer två är att IoT-enheter alltsom oftast är batteridrivna och därmed vill spara så mycket energi som möjligt till förmån för batteriets livslängd. Autentisering och kryptering kan vara relativt dyra operationer i processorkraft mätt och därför kanske man vill avstå från att skydda sin enhet i onödan.
   

   3. Till sist kan det vara svårt att be en enhet “byta lösenord” om du skulle få ett intrång i någon annan del av IT-infrastrukturen. Inte heller kan enheten använda sig av multifaktor-autentisering eller liknande på samma sätt som människor kan.

Dessa faktorer tycker jag motiverar ett minst lika genomtänkt autentiseringsförfarande för IoT-enheter som för människor. Vi brukar säga att IoT-enheter är den svagaste länken i varje IoT-system. De är typiskt oövervakade, monterade i en utsatt miljö och enkelt implementerade för att öka batteritiden.

Några konkreta råd till dig som ska bygga ett IoT-system

Det finns ett par lärdomar som jag upplever att många missar och vi på Attentec gör vårt bästa för att skicka med dem till våra kunder. De vanligaste hittar du nedan.

• • • Många IoT-enheter använder någon typ av flashminne för lagring, oftast helt okrypterat. Kom ihåg att om någon annan monterar ned enheten och monterar isär den är det inte särskilt svårt att helt enkelt läsa ut enhetens inloggningsuppgifter från minnet och därefter börja ansluta sig till din serverinfrastruktur. Om du använder certifikatbaserad autentisering för dina enheter kan du avhjälpa det här problemet med så kallade TPM-moduler (Trusted Platform Module).
    • Tidsbegränsade inloggningsuppgifter har den fantastiska egenskapen att de som inte har befogenheter att förnya sina inloggningsuppgifter automatiskt blir utkastade ur systemet till slut. Ställ krav på att dina IoT-enheter också ska förnya sina inloggningsuppgifter regelbundet!
    • Ytterligare ett sätt att skydda sin infrastruktur mot hackade IoT-enheter är att minimera vilka rättigheter de har i systemet. Sträva efter att IoT-enheter endast ska ha befogenheter att tillföra den data de förväntas tillföra och inte har befogenheter att påverka varken systemet eller andra enheter. Det värsta som kan hända vid ett IT-angrepp blir då att enhetens egna inställningar förändras och den visar fel data. Tråkigt, men betydligt bättre än att din tabell med användardata läcker ut på internet för att IoT-enheterna hade för mycket svängrum!

Om Attentec

Attentec är en oberoende expert och systemintegratör av IoT-lösningar som guidar företag och organisationer i denna digitaliseringsresa. Med över 15 års erfarenhet av tekniken hjälper vi dig skapa affärsnytta med teknik. Vi har levererat över 100 framgångsrika IoT-projekt och kan hjälpa även dig att skapa kundnytta med hjälp av IoT i en allt mer digitaliserad värld!