Ha a gyártóegység nyilvános vagy magánhasználatban lévő informatikai felhőhöz csatlakozik, az eredendő biztonsági kockázatokat rejt, ami rögtön jelentkezik, amint ezek az ún. okosgyárak hálózati kapcsolatot kapnak. A cél nem más, mint az okosgyárak fejlett működése által kínált rugalmasság megtartása amellett, hogy a különböző hálózati összeköttetésekre jellemző biztonsági kockázatot a lehető legteljesebb mértékben minimalizáljuk.
Első lépésnek megteszi, ha meghatározzuk, hogy a hálózati kapcsolatok tekintetében vezetékes, vezeték nélküli vagy a kettő kombinációjából adódó megoldást engedélyezzük. Innentől kezdve ajánlott szabványos protokollokra épülő hálózati technológiákat alkalmazni (pl. WiFi, Bluetooth, Ethernet stb.), amelyek az adott ipari szegmensben már jelen vannak. A standard biztonsági intézkedések alkalmazása csökkenti a hálózati kapcsolatok sebezhetőségét, jóllehet ez némileg szembemegy az ipari szegmens előző évtizedekben felvett szokásaival, miszerint az egyedileg fejlesztett megoldásokat preferálják. A felépített hálózati infrastruktúrának időtállónak kell lennie, hiszen több évig kell helytállnia. Bár számos hálózati megoldás támogat egyedileg fejlesztett kommunikációs protokollokat, ezek használata során célszerű a házon belüli alkalmazásra hagyatkozni, elkerülve a gyáregységen kívülre mutató kapcsolatokra való kiterjesztést.
Jelentős problémát jelent az, hogy még a szakképesítéssel rendelkező műszaki szakemberek tudása is gyakran korlátozott, ha IT-biztonságról beszélünk. Mivel nem információtechnológiai biztonsági szakértőkről van szó, ebből adódóan eleve nem is várható el tőlük, hogy egy robusztus és biztonságos hálózati IoT-infrastruktúrát hozzanak létre. Amint a hálózati kapcsolat kikerül a gyár területéről, rögtön az Amazon Web Services (AWS), Google, Microsoft Azure stb. világában találják magukat, rászorulva e szolgáltatók IT-szakembereinek támogatására a biztonsági kockázatok kiiktatásában.
A hackerek egyik legfőbb célja egy hozzáférési pont megtalálása/kialakítása annak érdekében, hogy azon keresztül nagy mennyiségű adathoz és rendszerhez nyerhessenek hozzáférést. Ezek a támadások jelentős károk okozására képesek, amelyek jelentős időre lebéníthatják az üzemszerű működést. Az ipari IoT-rendszereket illetően a leggyengébb láncszem biztonság tekintetében többnyire a hardver és maga a végponti felhasználó, mivel az ezekért felelős mérnökszakemberek az előbb részletezett okokból kifolyólag általában nem rendelkeznek a kellő szintű IT-biztonsági tudással.
A kedvezőtlen helyzet azonban előnyére változni látszik. Az olyan cégek, mint a Microchip Technology, küldetésük részének tekintik e tudásbeli hézag befoltozását azáltal, hogy oktatás útján támogatást nyújtanak a fejlesztőmérnököknek, bemutatva a végpontok közötti, biztonságos infrastruktúra lényeges elemeit. Az IoT-hardverszolgáltatók mellett a felhőszolgáltató cégek (pl. AWS, Google, Microsoft) szintén a szereplők közé értendők. A törekvés célja a biztonsági kérdések megfelelő súllyal történő kezelése, amely nézőpont szerint nemcsak úgy tekintünk rá, mint egy áldásos hatású, de opcionális kiegészítésre, amivel az IoT-hálózat kiépítése után ráérünk foglalkozni, hanem a feladat alapvető részeként kezeljük. A biztonsági megoldásokat már a tervezés első szakaszaitól az IoT-ben is stratégiai megközelítés szerint kell implementálni, hiszen a biztonság a hardverben kezdődik, megfelelő minőségben nem lehet csupán szoftveres implementációról beszélni.
Hitelesítések
A biztonság egyik legalapvetőbb eleme a hitelesítések megfelelő kezelése. A rendszertervezőnek abból kell kiindulnia, hogy a hálózat minden csomópontjának egyedi, védett és megbízhatósági tanúsítványokkal rendelkező identitással kell rendelkeznie. Alapvető fontosságú bizonyossággal tudni, hogy minden hálózati elem valóban az, akinek állítja magát, és megbízható partnerként kezelhető: ennek érdekében a TLS 1.2 és kölcsönös hitelesítés implementációja kötelező jellegű a kiszolgáló és IoT-végpont között. Ennek módja pedig olyan információ használata, amely mindkét fél számára elfogadott: a tanúsítóközponté.
Ez azonban csak akkor működik, ha a tanúsítóközpont által felállított bizalom a projekt kezdetétől fogva a gyártáson át egészen az okosgyárakban történő, fizikai telepítésig garantált. Az IoT-végpont identitásának igazolására hivatott, titkosított kulcsnak mindenkor védettnek kell lennie. Manapság elterjedt megoldás, hogy ezt a titkosított kulcsot a mikrokontroller beágyazott flash-memóriájának egy elkülönített részén tárolják, ahol szoftveres manipulációnak van kitéve, hiszen ehhez egy szakavatott támadónak könnyű hozzáférése lehet. Ez téves implementációs megközelítés, mely a biztonság hamis érzetét adja, és egyben ez a biztonsággal kapcsolatos problémák egyik legfőbb forrása.
A biztonsági tárolóelem
A biztonságos megoldás az, ha a titkosított kulcsot és más, hasonlóan érzékeny információt nemcsak eltávolítjuk a mikrokontrollerből, hanem el is szigeteljük tőle, elejét véve mindenféle szoftveres hozzáférés lehetőségének. Itt jön a képbe a biztonsági tárolóelemek fontossága. A biztonsági tárolóelem lényegében egy védett tárterület, ami a titkosított azonosítókulcs tárolására szolgál oly módon, hogy az senki számára sem hozzáférhető. A hitelesítés validálására a CryptoAuthLib függvénykönyvtár parancsaival lehet a biztonsági tárolóelem felé lekérdezéseket küldeni, illetve válaszokat fogadni a mikrokontroller irányából. A megoldás lényeges pontja, hogy a termékfejlesztés során és a termék teljes élettartama alatt a titkosított, egyedi kulcs egyetlen pillanatra se kerüljön felfedésre vagy hagyja el a biztonsági tárolóelemet, ezáltal biztosítható a végpontok közötti bizalmi lánc épsége. A biztonsági tárolóelem fizikailag egy önálló, CryptoAuthentication™-sorozatú, integrált áramkör, amely olyan széfként funkcionál, amibe teljes biztonságban helyezhetünk el értékes információkat. Ez pedig ebben az esetben az IoT-hálózati hitelesítéshez használt, egyedi, titkosított kulcs.
A kulcsok átadása
A koncepció következő lényeges pontja azt definiálni, hogy a titkosított kulcsokat és egyéb, érzékeny adatokat a termékfejlesztő hogyan juttatja el a CryptoAuthentication-sorozatú, biztonsági tárolóelem fedélzetére. Ehhez a gyártó Microchip biztosít egy olyan platformot, amelyen az ügyfél biztonságosan létrehozhatja az érzékeny információkat és gondoskodhat azok felprogramozásáról a gyártás alatt úgy, hogy ez még maga a Microchip számára is teljesen láthatatlan marad. Ha az ügyfél végzett, a Microchip a biztonsági tárolóelemeket saját gyártókapacitásaival legyártja, és csak közvetlenül a gyártóüzem elhagyása előtt kerülnek az információk fizikailag feltöltésre és a megrendelőhöz kiküldésre.
Ha az ügyfél az AWS-nél nyit IoT-ügyfélfiókot, viszi magával a saját felhatalmazása alapján a Microchip segítségével létrehozott ügyféltanúsítványt is, és szolgáltatja be az AWS „Use Your Own Certificate” opciójával. Ezt követően az AWS „Just-In-Time Registration” (JITR) IoT-funkciója segítségével tömegesen feltöltik az áramkörszinten tárolt tanúsítványokat a biztonsági tárolóelemekből az AWS felhasználói fiókba. Az ügyfélszintű tanúsítvány ettől kezdve képes tehát az eszközszintű tanúsítványok ellenőrzésére, a bizalmi lánc így kiépültnek tekinthető, a nagyvállalati IoT-biztonsági és -skálázhatósági követelmények teljesíthetőek. A JITR folyamattal több ezer tanúsítvány is minden nehézség nélkül kezelhető, akár tömegesen is, felhasználói beavatkozás nélkül. Ahelyett, hogy a felhőbe a tanúsítványokat – kiszolgáltatva őket harmadik félnek – manuálisan kellene feltölteni, az új eszközök tanúsítványai automatikusan regisztrálhatók az eszköz és az AWS IoT közötti első kommunikáció során.
Egy lehetséges implementáció a továbbfejlesztett AT88CKECC-AWS-XSTK-B fejlesztőkészlettel
A Zero Touch szolgáltatásaktiválási fejlesztőkészlet fedélzetén lévő ATECC508AMAHAW CryptoAuthentication biztonsági tárolóelem előprogramozott állapotban már készen áll arra, hogy a felhasználó AWS IoT-ügyfélfiókjához csatlakozva elvégezze a hitelesítési folyamatot. Az első lépésben az új Python szkriptek alapján meg kell ismerni, hogy a bizalmi lánc pontosan mit jelent, illetve a Microchip gyártását illetően az átadási/aktiválási folyamatot is meg kell érteni. A fejlesztőkészlet bizonyos mértékig megmutatja azt is, hogyan működnek a gyártási folyamatok, emellett fizikai károkozási vagy hamisítási törekvések ellen is fejlett védelemmel rendelkezik. A kitet ellátták egy kiváló minőségű, FIPS-kompatibilis véletlenszám-generátorral, egy kis fogyasztású kriptográfiai gyorsítóval (ami jól illeszkedik a korlátozott számítási erőforrásokkal rendelkező IoT-eszközök világába), valamint a különböző gyártási folyamatok költséghatékony támogatásával.
A beágyazott rendszerek fejlesztői és információtechnológiai szakemberek közötti szakadék még hatékonyabb áthidalása érdekében a kit nemcsak a már említett Python szkriptekkel rendelkezik, hanem a CloudFormation szkriptek segítségével az AWS-ügyfélfiók beállítását és a felhővel való munka megértését is elősegíti. A CloudFormation szkriptekkel a felhasználó az AWS munkakörnyezethez szó szerint percek alatt képes egy használható felhasználói interfészt kifejleszteni.
Összefoglalás
Az AWS IoT just-in-time regisztrációs folyamat és az ATECC508MAHAW CryptoAuthentication-sorozatú biztonsági tárolóelem kombinációjával optimális biztonsági feltételek teremthetők az ipari IoT-alkalmazásokban. A végpontok közötti valódi biztonság alapvető feltétele az Ipar 4.0-alkalmazások és -okosgyárak egészséges és biztonságos elterjedésének és növekedésének.
