IoT-készülékek flottáinak életciklus-menedzsmentje
Első ránézésre egy IoT-eszköz hozzáférési joga vagy „kőbe van vésve” vagy könnyen támadható. Mivel az IoT-eszközöket számtalan internetes visszaélési kísérlet fenyegeti, ezért az előbbit lenne célszerű választani. Az azonban nem felel meg a való élet követelményeinek: annak, hogy az eszköz jogosítványait a termék életciklusa alatt akár többször is változtatni kell. Van „harmadik út”: a változásokra optimalizált, mégis biztonságos eszközmenedzsment.
Sokat hallunk az eszközmenedzsmentről, de kevesen tudják, vajon pontosan mi az, hogyan valósíthatjuk meg, és hogyan vezethetjük végig azt az eszközök kihelyezési fázisán, illetve hogyan érvényesítjük azt újra, amikor az eszközök már telepítve vannak.
Néhány nagyvállalat már elkezdte ezt megvalósítani a saját rendszereiben, de ezek lényegében csak a jogosultságok életciklusának kezelésére terjednek ki. A biztonsági szabványok iparágában bekövetkezett változásokat tekintve sok egyéb közt a legfontosabbak az EN 303645, mint az eredeti európai biztonsági szabvány, az OCPP (Open Charge Point Protocol), az IEC15118 (az elektromos járművek töltéséről) és a Matter (az okosotthonok eszközeinek kommunikációjáról).
Ezek mindegyike a jogosultság időnkénti visszavonását igényli. Ez hasznos dolog, de ha egyszer ellenőriztünk egy jogosultságot, akkor ezt a lépést követően néhány további dologra is szükség van. Meg kell újítani a visszavont jogosultságot, és mielőtt bármi baj történne az eszközzel, intézkedni kell a tanúsítvány által érintett kapcsolatok auditálásáról, hogy megbizonyosodjunk arról, nem szenvedünk-e el például DDoS-támadást. Egyes vállalatok ezt jobban, mások kevésbé jól valósítják meg, de a szabványok egyre inkább előírják a jogosultságok „rotációját”, az eszköz életciklusának bizonyos pontjain a jogosultság megváltoztatását is, ami nem könnyű feladat.
Ha ezt egy négylépcsős folyamatnak tekintjük, akkor az első lépés az eszköz beüzemelése, a jogosultság telepítése. A kérdés ez: ha van egy beágyazott készülékünk, amely szilíciumeszközökből áll, és amelyet egy felhőplatformhoz kívánunk csatlakoztatni, hogyan illesztjük be a jogosultsági lánc által képviselt eszközazonosságot gyakorlatilag bármilyen felhőplatformba? A második lépés: ha az egyedileg kezelt hozzáférési joggal védett eszköz már a felhőplatformon van, hogyan vonjuk vissza az eszköz kezelésére jogosító kulcsot? Miután visszavontuk, következik a harmadik lépés: meg kell újítani az eszköz identitását, azaz új, érvényes hozzáférési jogot kell létrehoznunk. Ha pedig ez is megtörtént, akkor – a negyedik lépésben – az eszköz biztonságát kell auditálni. Ez azt jelenti, hogy a négy lépés a következő: a jogosultság telepítése, visszavonása, megújítása és ellenőrzése.
A jogosultság feltelepítése a termék kibocsátása előtt
A hozzáférési jogosultság telepítésének meg kell történnie, mielőtt a termék a piacon megjelenik. Mielőtt a végfelhasználó megvásárolná a terméket – például egy lakástermosztátot –, a gyártójának már fel kellett telepítenie az eszközt annak platformjára. Ezt követően a gyártónak képesnek kell lennie arra, hogy átadja a jogosultság kezelésének tulajdonjogát a felhasználónak.
Ahhoz, hogy egy eszközflottát egy adott platformra telepítsenek, a termék gyártójának választania kell egy tanúsító hatóságot. A gyártó több ilyen szolgáltató közül választhat, esetleg sajátmaga is rendelkezhet a jogosultság kibocsátójának jogával. Az eszköz megvásárlói lényegében a Microchip ügyfelévé válnak. A Microchip titokcserét kezdeményez a gyárai, a hardverbiztonsági eszköz biztonságos modulja, és az ügyfél között. Az ügyfél aláír egy tanúsítási kérelmet (Certificate Signing Request – CSR), amellyel felhatalmazza a Microchip-et, hogy a biztonságos elemet a nevében a jogosultsági lánchoz tartozó hitelesítő adatokkal lássa el. Ez egy bizalmi láncot létesít a Microchip és az ügyfél között.
A Microchip a biztonsági adatokat az eszközök hardveres biztonsági moduljában (Hardware Security Module – HSM) elhelyezve bocsátja rendelkezésre. A Microchip ehhez a TrustFLEX biztonságos elemet ajánlja, mivel az a tényleges használati eset (use case) pontos ismeretében van előkonfigurálva.
Ha már definiáltuk azt a használati esetet, amely az eszköz „születési” jogosultsági kulcsait és azok hitelesítését alkalmazni fogja, a következő lépés ennek a születési jogosultságának a betöltése a biztonságot szolgáltató eszközbe.
A születési jogosultságot kétféleképpen lehet létrehozni: vagy az ügyfél saját nyílt kulcsú biztonsági infrastruktúrája (Public Key Infrastructure – PKI) alapján, vagy azáltal, hogy az ügyfél használja a Microchip által a már megvásárolt eszközben rendelkezésre bocsátott születési jogosultságot. Amint ez a születési hozzáférési jogosultságot kezelő rendszer betöltődik a felhőplatformra, az eszközpark, a termosztát vagy bármilyen más termék addig várakozik, amíg valamely végfelhasználó meg nem vásárolja a terméket. Ezután a vállalat átadja a tulajdonjogát az egyéni ügyfélnek, aki elkezdi a megvásárolt termosztát párosítását.
A termék életciklusa azonban tovább halad, például amikor egy házat eladnak, a termosztátot is eladják vele együtt. Mi történik ilyenkor a jogosultsággal? Itt jön a képbe a visszavonás és az új jogosultság létrehozása, „rotációja”. A visszavonás és a megújítás elválaszthatatlanul összetartozik, mintegy „kéz a kézben jár”. Ha egyszerűen csak visszavonjuk az eszközben tárolt hozzáférési kód érvényességét, az eszköz ettől kezdve lényegében halott. Egy jogosultság-megújító rendszerrel viszont új azonosítót küldhetünk a termosztátnak, és új felhasználóval társíthatjuk.
Van egy másik használati eset is, amely a tanúsítvány rotációjának szükségességét szemlélteti. Ez a rövid távú bérleti piac, amikor is elképzelhetünk egy ajtózárat, amelyet egy héten át az ingatlan aktuális bérlőjének kell tudni kinyitnia, majd ezt a jogosultságát vissza kell vonni, hogy ezt követően egy másik bérlő rendelkezhessen a zár – és a hozzáférés – felett. Ideális esetben a ház tulajdonosa azt szeretné, ha a különböző bérlők különböző jelszavakkal rendelkeznének, amelyeket esetleg az év minden hetében meg kellene változtatni. Itt is fel lehet használni a jogosultságok rotációját, szinkronizálva azokat a rövid távú bérbeadó cégek naptárával, hogy ez a felhasználói élmény jöjjön létre. Mindennek szinkronizálva kell lennie annak érdekében, hogy jól működjön a jogosultságok visszavonása és megújítása. Miután az új, jogosult felhasználó hitelesítése megtörtént, a platform megbízhat az új jogtulajdonosban, tehát a kezelt jogosultsági láncnak köszönhetően a bizalmi lánc az új jogtulajdonos szempontjából is érintetlen marad. Az eredmény egy új hozzáférésijog-tulajdonos generálása, amelyet az eszközkezelő platform átvehet és ellenőrizhet az ügyfél igényeitől, követelményeitől vagy a helyzettől függően.
A Microchip ATECC608 TrustFLEX (1. ábra) – és egy másik hasonló eszköz, a TA100 – egyaránt ennek az eszközkezelési használati esetnek a kiszolgálására készült. Ezek az eszközkezelésen túlmenően biztonságos hitelesítést, biztonságos rendszerindítást (secure boot) és a vezetékmentes (On The Air – OTA) frissítés feletti ellenőrzést is kínálnak.
A kulcshitelesítésnek a félvezető eszköz – fizikailag és adatvédelmi szempontból egyaránt – biztonságos határain belül kell maradnia. Ez teszi lehetővé a kulcsok átruházását, mivel a kulcsok az eszközből nem olvashatók ki, ezért nem kerülhetnek illetéktelen kézbe. Az eszközöknek és a kulcshitelesítés rendszerének az eddigieken kívül is számos használati esete lehetséges a hozzáférésvédelem és az „egyszer használatos”, „eldobható” hozzáférési jogosultság kezelése területén.
1. ábra
Változásmenedzsment
A fentiek a biztonságos elem szemszögéből írják le az eszközkezelést. A piac úgy látja, hogy a biztonságos elem teljesen lezárt eszköz, ami semmiképpen sem változtatható – de ez nem teljesen igaz. Irányelveket állíthatunk be, amelyek lehetővé teszik, hogy a konfiguráció bizonyos paramétereit változtassuk. A TrustFLEX pontosan így van konfigurálva, ezért lehetővé teszi, hogy ezek a dolgok megtörténjenek. Ráadásul a TA100 valószínűleg még erősebb, mert a jogok és engedélyek sokféleségét képes kezeni.
Ha megnézzük a kihívásokat, akkor létezik egy, a készségekkel kapcsolatos kihívás: hogyan valósítsuk meg az eszközkezelést a világ különböző régióiban? Hogyan valósítsuk meg az eszközmenedzsmentet a prototípus és a gyártás fázisában? Mi történik, amikor a termék megjelenik, és mi történik utána?
Ha a terméket ki akarjuk vonni a piacról, akkor azt deaktiválni kell, tehát szükség van egy olyan üzemmódra, amellyel megszüntethető a termék rendeltetésszerű használata. Ez lehetővé teszi a vállalatok számára, hogy nagyon ellenőrzött módon kezeljék a garanciákat, ami jobb, mintha csak egyszerűen visszaküldenék a terméket anélkül, hogy bárki is tudná, mi történik vele ezután. Egy vállalat például visszavonást alkalmazhatna akkor, amikor az eszközt visszaküldik a boltba, és ezután tudná, hogy az egy olyan termékhez kapcsolódik, amelyet garanciális időben küldött vissza a felhasználó.
Itt van még továbbá a cégfelvásárlások kérdése is. Ha elképzeljük, hogy egy termosztátgyártó vállalat növekszik és felvásárol egy másik termosztátgyártó vállalatot, mi történjék annak az addigi jogosultságkezelési architektúrájával? Hogyan növekedjünk, hogy felvásárolhassuk a következő vállalatot? Az eszközkezelési szolgáltatások ezeket a cégméretek változásával együtt járó problémákat is segíthetnek kezelni.
Mi itt a Microchipnél több okból is arra bátorítjuk ügyfeleinket, hogy vezessék be az eszközmenedzsment módszereit. A jogszabályi előírások, a tulajdonjog átruházása, a skálázhatóság és a termékgarancia lejárta mind olyan tényezők, amelyek a piacot az eszközkezelés bevezetésére ösztönzik.
További információk: https://www.microchip.com/en-us/products/security/trust-platform
Szerzők: Xavier Bignalet – termékcsalád-menedzser, Microchip Technology Inc.
Nicolas Demoulin – EMEA marketingigazgató, Microchip Technology Inc., Biztonsági termékek
