.Internet věcí rychle pronikl do všech koutů digitálního světa a stal se běžnou součástí průmyslových lékařských, dopravních a jiných aplikacích. Vnitřní průmyslové sítě jsou běžně důmyslně zabezpečeny, ale problém nastává s rozšířením sítě o zařízení, které nemají dostatečný výkon procesoru pro složité bezpečnostní algoritmy. Hackeři jsou si této zranitelnosti vědomi, a tak připojená zařízení čelí obrovskému počtu hrozeb. Proto je nutné, aby každé zařízení IoT obsahovalo důmyslná bezpečnostní opatření. Proto vznikla série článků pojednávající o různých stupních bezpečnosti Embeded zařízení.

Série článků o bezpečnosti Embeded zařízení:

• Část 1 pojednává o kryptografických algoritmech, které jsou základem bezpečnosti.
• Část 2 pojednává o roli soukromých klíčů, správě klíčů a bezpečném uložišti.
• Část 3 zkoumá mechanismy integrované přímo do procesorů k odrazení útoků na systémové a aplikační části software.
• Část 4 ukazuje použití bezpečnostního mechanismu přímo v procesorech k zajištění bezpečnosti v runtime režimu.
• Část 5 popisuje zabezpečení na vyšší úrovni při komunikaci s cloudovými službami.

Tento článek se věnuje připojení ke dvěma předním poskytovatelům cloudových služeb - Amazon Web Services (AWS) a Microsoft Azure. Představíme si vývojové kity a příslušný software od různých dodavatelů pro rychlé spojení s těmito službami.

IoT portál v cloudových službách

Když se embeded zařízení připojí ke cloudové službě tak se vystavuje riziku, že se může připojit k falešné službě nebo servreru. A naopak samotná cloudová služba čelí hrozbě útoků hackerů, kteří napodobují transakce embeded zařízení IoT ve snaze proniknout do cloudu.

Pro ochranu embeded zařízení i cloudu se používají specifické bezpečnostní protokoly, které provádí vzájemnou autentizaci během přihlášení a následnou autorizaci pro povolení příslušné cloudové služby. Tyto protokoly jsou obvykle součástí sady služeb, které jsou poskytnuty zabezpečeným IoT portálem. AWS a Azure poskytuje specifický vstupní portál, který embeded zařízení musí použít pro připojení k dané službě.

Portály IoT využívají specifické autentizační protokoly, které jsou součástí sady software (SDK) k vytvoření bezpečného připojení. U AWS se embeded zařízení připojují pomocí vzájemného ověřování s bránou daného zařízení. Tato brána propojuje embeded zařízení s dalšími podpůrnými službami IoT a používá informace uložené v registrech. Jedná se o jedinečný identifikátor zařízení, bezpečnostní údaje a další metadata potřebná pro přístup ke službám AWS (obrázek 1). V Azure slouží registr identity k podobné funkci.

Obrázek 1: AWS poskytuje sadu specializovaných služeb určených ke zvýšení bezpečnosti a účinnosti transakcí mezi zařízeními a cloudovými službami. (Zdroj obrázku: Amazon Web Services)

AWS IoT a Azure IoT poskytují službu, která udržuje informace o stavu ve virtuálním zařízení spojeném s každým fyzickým zařízením IoT. V AWS IoT se tomu říká poskytování stínů a v Azure Iot se mluví o tzv. dvojčatech.

Tento princip se používá v edge cloudových službách AWS Greengrass nebo Azure IoT Edge. Tyto edge služby využívají fyzické zařízení integrované do místní sítě, kde jsou nablízku embeded zařízení a může tam probíhat velká výměna dat. Azure IoT Edge službu lze využít pro implementaci podnikové logiky nebo ke snížení latence v průmyslové automatizaci (obrázek 2).

Obrázek 2: Poskytovatelé cloudových služeb nabízejí specializované služby, jako je Microsoft Azure IoT Edge, která využívá zařízení připojená na místní síti pro náročné výpočty. (Zdroj obrázku: Microsoft Azure)

Požadavky na připojení k portálu

Ať už se jedná o připojení k edge systému nebo přímo ke službě IoT je nutné, aby embeded zařízení disponovalo soukromý klíčem, certifikátem X.509. Klíč, certifikát nebo token poskytuje portálu IoT doklady o totožnosti embeded zařízení během autentizační sekvence při připojení ke cloudu. Cloudové služby IoT navíc obvykle vyžadují definici přístupových práv pro interakce mezi zařízeními IoT a cloudovými službami.

Služby AWS IoT a Azure IoT podporují ověřování pomocí certifikátů, ale také podporují použití autentizační metody pomocí tokenu založené na JSON Web Token (JWT) pro AWS IoT nebo shared access signature (SAS) pro Azure IoT.

Tyto služby používají registry k uchovávání metadat pro každé připojené zařízení. Spolu s těmito daty se ukládají také přístupová práva pro různé komunikační kanály a entity. Například jednoduchá politika přístupového práva AWS IoT by pomocí formátu JSON definovala, že embeded zařízení s konkrétním názvem „věc“ v registru zařízení AWS IoT může spojovat a publikovat zprávy pouze na kanálu se stejným přidruženým názvem - věc ( Výpis 1).

Výpis 1: Vývojáři používají k popisu zásad přístupových práv AWS IoT formát JSON. (Zdroj kódu: AWS)

Vývojové sady připravené pro cloud

Přestože poskytovatelé cloudových služeb nabízejí podrobné informace, není jednoduché těmto informacím detailně porozumět bez možnosti reálného vyzkoušení na fyzickém vzorku. Špatně implementovaná bezpečnostní funkce otevírá vrátka do celého systému. Proto je k dispozici celá řada vývojových desek a doprovodných softwarových balíčků, které umožňují rychlé seznámení s danými postupy a principy připojení a komunikací se službami IoT.

Například ESP32 azure IoT Kit od Espressif Systems nebo AZ3166 IoT Developer Kit od Seeed Technologie obsahuje desky s certifikací Azure navržené pro snadné připojení ke cloudu Microsoft. Společnost Microsoft poskytuje ukázky kódu, kde jsou podrobně vysvětleny ověřovací metody pro připojení ke cloudu.

Například deska AZ3166 po stisknutí tlačítka na desce zahájí připojení k místní síti Wi-Fi. Po připojení k síti lze používat nástroj Azure IoT Device Workbench, který je součástí rozšiřující sady Azure IoT Tools pro Microsoft Visual Studio Code určený pro vývoj, ladění a interakci s Hubem Azure IoT.

Pomocí tohoto nástroje se vytvoří objekt pro embeded zařízení v Azure IoT Hub a pomocí souboru poskytne přidruženému registru identity pověření a další metadata potřebná pro připojení desky IoT k Azure IoT Hub (obrázek 3).

Obrázek 3: Ukázkový kód a přihlašovací údaje uvedené v Microsoft Azure IoT Device Workbench pomáhají připojit sadu Seeed Technology AZ3166 IoT Developer Kit k Azure IoT Hub. (Zdroj obrázku: Microsoft Azure)

Azure IoT Device Workbench poskytuje další podpůrný software a metadata, která umožňují rychle naprogramovat desku AZ3166 ukázkovým kódem a zahájit přenos měření ze senzoru teploty a vlhkosti z desky do Azure IoT Hub. Kroky spojené s vytvořením reprezentace fyzického zařízení v cloudu IoT a nastavení přidruženého registru jsou nezbytné pro připojení daného zařízení s cloudem IoT.

Aby bylo možné využívat cloudové služby, potřebuje však Azure IoT Hub ověřit přístupová práva. Chcete-li monitorovat zprávy přicházející ze senzoru AZ3166 do cloudu, lze jednoduše použít obrazovku Azure Shared Shared Policy Policy a zvolit předem nastavenou politiku navrženou pro rychlé povolení požadovaných přístupových práv (obrázek 4).

Obrázek 4: Vývojáři mohou pomocí snadno autorizovat používání cloudových služeb Azure. (Zdroj obrázku: Microsoft Azure)

Při práci s AWS IoT je k dispozici vývojový Zero Touch Provisioning kit AT88CKECC-AWS-XSTK-B od Microchip Technology a k němu doprovodný software. Tato aktualizovaná verze starší sady Microchip Zero Touch Provisioning je dodávána i s ověřovacími údaji. Pomocí skriptů, které jsou součástí sady lze rychle připojit desku k AWS IoT, aniž bychom se museli zabývat soukromými klíči či certifikáty (viz „ Take the Zero-Touch Approach to Securely Lock Down an IoT Device“).

Vývojové sady RTK5RX65N0S01000BE RX65N Cloud Kit od Renesas a KITXMC48IOTAWSWIFITOBO1 AWS IoT kit od Infineon Technologies mají také podporu pro připojení k AWS IoT a jsou založeny na Amazon FreeRTOS. AWS poskytuje podrobné pokyny pro registraci desek, vytváření ověřovacích údajů a definici JSON tokenu potřebného pro připojení k AWS IoT a používání služeb AWS.

Reálné připojení velkého množství zařízení ke cloudu

Vývojové sady popsané výše slouží jako účinné platformy pro rychlé vytváření prototypů aplikací IoT, tak pro zkoumání požadavků na připojení cloudových služeb IoT. V praxi se však vývojáři budou muset obrátit na pokročilejší postupy určené pro reálné aplikace. Azure IoT i AWS IoT podporují širokou škálu metod, které umožňují připojení velkého množství embeded zařízení a jejich správu ve velkém měřítku.

Například s AWS IoT lze použít metodu bootstrap pro poskytování certifikátů. Inteligentní embeded zařízení je dodáváno s certifikátem bootstrap asociovaným s minimálními přístupovými právy potřebnými k vyžádání a přístupu k novému certifikátu (obrázek 5).

Obrázek 5: AWS IoT podporuje metodu zavádění certifikátů v zařízeních IoT. (Zdroj obrázku: Digi-Key Electronics, od Amazon Web Services)

Pomocí certifikátu bootstrap se zařízení připojí ke cloudu („1“ na obrázku 5), požádá o nový certifikát („2“), obdrží adresu URL certifikátu vygenerovaného funkcí Lambda bez serveru AWS („3“)  a načte tento certifikát z AWS Simple Storage Services ("4"). Pomocí tohoto nového certifikátu se zařízení poté přihlásí zpět do AWS IoT („5“) a pokračuje v běžných operacích.

AWS nabízí další cloudové služby, které podporují dynamické poskytování autentizačních tokenů pomocí funkce AWS Lambda. Poté, co modul AWS pro autentizaci a autorizaci IoT schválí žádost o token, vygeneruje služba AWS Security Token Service (STS) token. Pomocí tohoto tokenu mohou embeded systémy přistupovat ke službám AWS podléhajícím validaci pomocí služby AAM Identity and Access Management (IAM) (obrázek 6).

Obrázek 6: Přední poskytovatelé cloudových služeb podporují i jiné formy ověřování, jako je tento proces pro dynamické generování bezpečnostních tokenů pomocí služby AWS Security Token Service (STS). (Zdroj obrázku: Amazon Web Services)

AWS poskytuje podobnou schopnost pro dynamické přidělování přístupových práv. Zde ostatní funkce AWS Lambda přiřazují sadu práv spojených s platným tokenem (obrázek 7).

Obrázek 7: Vývojáři mohou používat cloudové služby k implementaci dynamického přidělování přístupových práv.To je užitečné pro aplikace se slabým připojením nebo s krátkodobými operacemi. (Zdroj obrázku: Amazon Web Services)

Další cloudové služby IoT umožňují efektivněji řešit bezpečnost ve velkých implementacích. Například AWS IoT poskytuje funkce pro zajištění bezpečnosti pro celé flotily zařízení, včetně podpory výše popsané metody bootstrapu ve větším měřítku. Azure IoT poskytuje možnost skupinového zápisu zařízením, která sdílejí stejný certifikát X.509 nebo token SAS.

Sdílená odpovědnost za bezpečnost

Poskytovatelé cloud computingu IoT poskytují řadu efektivních metod pro zvýšení zabezpečení aplikací IoT mezi koncovými body. Vývojáři IoT přesto nemohou očekávat, že tyto metody mohou nést plnou odpovědnost za bezpečnost jejich konkrétní aplikace. Poskytovatelé cloudových služeb ve skutečnosti pečlivě nastíní svou konkrétní roli a odpovědnost v bezpečnosti  pomocí konkrétních modelů, jako je například model sdílené odpovědnosti AWS (obrázek 8).

Obrázek 8: Stejně jako u jiných poskytovatelů cloudových služeb, tak i AWS popisuje odpovědnost za bezpečnost cloudové infrastruktury na jedné straně a zákaznických aplikací na straně druhé. (Zdroj obrázku: Amazon Web Services)

AWS a Microsoft Azure poskytují dokumenty se sdílenou odpovědností, které popisují a vysvětlují vlastní roli poskytovatele a roli uživatele. Jednoduše řečeno, poskytovatelé cloudu si ponechají odpovědnost za zabezpečení cloudu, zatímco zákazníci zůstávají odpovědní za aplikace, data používané v cloudu.

Závěr

Bezpečnost embeded zařízení je závislá na celé řadě bezpečnostních mechanismů, které jako celek tvoří komplexní ochranu. Stejně jako u každého připojeného produktu mohou bezpečnostní hrozby přicházet ve všech stran. Poskytovatelé cloud computingu IoT diktují specifické požadavky na autentizaci a správu přístupových práv, aby chránili sebe i své zákazníky. Přestože poskytovatelé nabízejí podrobnou dokumentaci o těchto požadavcích, je vhodné použít vývojové kity a příslušné softwarové sady pro bezpečné připojení ke cloudovým službám. Špatná implementace dokonalé bezpečnostní metody vede k otevření vrátek nezvaným hostům nejen do zákaznického systému, ale i do cloudu.

Článek vyšel v originále na webu DigiKey.com, autorem je Stephen Evanczuk.