Bezpečnosť IoT v celom systéme
Ochrana IoT výrobku vyžaduje opatrenia v zariadení, sieti, aplikácii a prevádzke. Začnite určeným použitím a modelom hrozieb a vyberte primerané opatrenia. Hardvérovo podporená dôvera posilňuje overovanie zavádzania a izoláciu kľúčov, ale neopraví chýbajúce oprávnenia API a nezabráni každému incidentu.
| Oblasť | Odporúčaná technická práca | Overte obmedzenie |
|---|---|---|
| Identita | Jedinečné prihlasovacie údaje, bezpečné zavedenie a odvolanie | Platná identita nepovoľuje každý úkon |
| Firmvér | Podľa potreby overujte obrazy zavádzania a aktualizácií | Podpísaný softvér môže mať zraniteľnosti |
| Komunikácia | Primerané šifrovanie a overovanie druhej strany | Šifrovanie neopraví nezabezpečený koncový bod |
| Rozhrania | Minimálne oprávnenia, validácia vstupov a debug ochrana | Posúďte aj servisný prístup a obnovu |
| Prevádzka | Segmentácia, monitoring a riadené nasadzovanie opráv | Dostupnosť a bezpečnosť obmedzujú čas zmien |
| Životný cyklus | Termíny podpory, príjem zraniteľností a sledovanie závislostí | Bezpečnostný čip nenahrádza priebežnú podporu |
Zlepšenie nasadených zariadení
Izolácia siete, obmedzenie prístupu a opravy firmvéru môžu zlepšiť existujúce zariadenia. Pridanie hardvérovej izolácie môže vyžadovať novú dosku; overovanie zavádzania závisí od čipu, stavu zavedenia kľúčov a obnovy. Pred sľubom, že možno aktualizovať každé zariadenie alebo že bezpečnosť po výrobe nemožno zlepšiť, posúďte konkrétnu flotilu.
Náklady a normy
Odhadujte komponenty, vývoj, zavádzanie kľúčov, skúšky a podporu podľa výrobku a objemu výroby. Neexistuje univerzálna jednotková cena bezpečnosti ani cena incidentu dokazujúca návratnosť projektu. IEC 62443 a ETSI EN 303 645 môžu pomôcť pri príslušných návrhoch, ale norma či certifikát komponentu automaticky nedokazujú úplnú zhodu CRA. Preverte vydanie, pôsobnosť a právny odkaz.
Začnite modelom hrozieb
Určite chránené aktíva: prihlasovacie údaje zariadenia, podpisovú infraštruktúru, osobné údaje, riadiace príkazy a dostupnosť služby. Zistite, kto dosiahne na jednotlivé rozhrania a či môže útočník zariadenie fyzicky získať. Posúďte následky pre bezpečnosť ľudí. Vyberte opatrenia podľa rizík a zaznamenajte skúšky; certifikát komponentu necertifikuje celý výrobok.
Praktický postup návrhu a overovania
- Určite hranice dôvery medzi aplikáciou, privilegovaným firmvérom, perifériami a backendom.
- Oddeľte súkromné podpisové kľúče od overovacieho materiálu zariadenia; naplánujte zavedenie, rotáciu a odvolanie.
- Vyberte ochranu zavádzania, debug a úložiska pre presnú revíziu čipu.
- Overujte aktualizácie a testujte obnovu po prerušení zápisu.
- Obmedzte služby, overujte používateľov a zariadenia a v API kontrolujte oprávnenia.
- Testujte nesprávny obraz, odvolaný kľúč, starú verziu, chybné vstupy a stratu spojenia.
- Udržiavajte záznamy závislostí, triáž zraniteľností, dôkazy vydania a plán podpory.
Výsledky skúšok musia uvádzať cieľ, konfiguráciu a predpoklady útoku. Úspešný test secure boot nedokazuje odolnosť proti každému fyzickému útoku alebo zneužitiu počas behu.
Secure boot: ochrana a hranice
Secure boot overuje autenticitu zavádzaného softvéru pred jeho spustením. V bežnom embedded návrhu chránený úvodný overovací kód kontroluje podpísaný bootloader, ktorý overí aplikáciu. Konkrétne fázy a algoritmy závisia od procesora a implementácie. Secure boot chráni pred neoprávnenou výmenou obrazu; nedokazuje neprítomnosť zraniteľností schváleného softvéru a nezabráni všetkým útokom počas behu. Measured boot zaznamenáva merania na ďalšie vyhodnotenie; samotné meranie nemusí blokovať spustenie. Ochranu proti návratu na starú verziu a chránenú obnovu treba osobitne navrhnúť a testovať.
Aktualizácie a obnova
Aktualizácia over-the-air (OTA) doručuje softvér alebo firmvér cez bezdrôtové spojenie. Vzdialená aktualizácia môže používať aj káblovú sieť; automatická inštalácia je samostatná vlastnosť. Bezpečný návrh overuje aktualizáciu aj cieľové zariadenie, chráni podpisové kľúče, kontroluje verzie a zvláda výpadok napájania. A/B oddiely sú jednou stratégiou obnovy, nie univerzálnou povinnosťou. RFC 9019 opisuje architektúru aktualizácií IoT, nie hotový povinný formát manifestu. Zariadenie potrebuje overovací materiál, nie súkromný podpisový kľúč celej flotily. Testujte poškodené obrazy, nesprávne ciele, prerušené zápisy, odvolané kľúče a nepovolené staršie verzie.
CRA a výber technológií
Požiadavky CRA sú orientované na výsledok a technologicky neutrálne, podľa posúdenia kybernetických rizík a použiteľnosti. Secure boot, hardvérový koreň dôvery, TPM, TrustZone a bezdrôtové OTA môžu byť vhodné technické opatrenia; nie sú univerzálnymi zákonnými povinnosťami každého výrobku. Zdokumentujte, prečo zvolené opatrenia spĺňajú požiadavky, namiesto stotožnenia jednej architektúry so zhodou.
Termíny a pôsobnosť CRA
CRA vstúpilo do platnosti 10. decembra 2024. Oznamovanie podľa článku 14 platí od 11. septembra 2026; hlavné požiadavky na výrobky od 11. decembra 2027. Článok 69 upravuje prechodné pravidlá pre skôr uvedené výrobky. Výrobky podliehajúce MDR alebo IVDR sú vylúčené podľa článku 2 ods. 2; preveriť treba aj ďalšie výnimky a nekomerčný slobodný/otvorený softvér.
Podpora, aktualizácie a dôkazy
Príloha I CRA stanovuje použiteľné mechanizmy bezpečného riešenia zraniteľností a aktualizácií. Automatické bezpečnostné aktualizácie majú podmienky a výnimky; automatické neznamená bezdrôtové. Podpora sa určuje podľa článku 13 ods. 8, spravidla najmenej na päť rokov; pri kratšom očakávanom používaní mu zodpovedá, pri dlhšom používaní môžu príslušné faktory vyžadovať dlhšiu podporu. SBOM musí byť strojovo čitateľný a pokrývať aspoň priame závislosti najvyššej úrovne.
Oznamovanie je samostatná povinnosť
Článok 14 CRA sa týka aktívne využívaných zraniteľností a závažných incidentov ovplyvňujúcich bezpečnosť výrobku, nie každého CVE. Oba vyžadujú včasné upozornenie do 24 hodín a oznámenie do 72 hodín od zistenia. Záverečná správa o zraniteľnosti sa podáva do 14 dní od dostupnosti nápravného alebo zmierňujúceho opatrenia; správa o závažnom incidente do mesiaca od oznámenia incidentu. Oznamovanie je odlišné od posudzovania zhody a aktualizácií.
Často kladené otázky
Vyžaduje CRA vždy secure boot?
Požiadavky CRA sú orientované na výsledok a technologicky neutrálne, podľa posúdenia kybernetických rizík a použiteľnosti. Secure boot, hardvérový koreň dôvery, TPM, TrustZone a bezdrôtové OTA môžu byť vhodné technické opatrenia; nie sú univerzálnymi zákonnými povinnosťami každého výrobku. Zdokumentujte, prečo zvolené opatrenia spĺňajú požiadavky, namiesto stotožnenia jednej architektúry so zhodou.
Zaručuje secure element zhodu?
Nie. Môže chrániť vybrané kľúče a operácie; zhoda sa týka celého výrobku a príslušných požiadaviek vrátane procesov a dôkazov.
Možno zvýšiť bezpečnosť nasadených zariadení?
Často pomôžu sieťové opatrenia a opravy firmvéru. Hardvérové zmeny závisia od čipu, zavedenia kľúčov a obnovy. Posúďte konkrétny výrobok a flotilu.
Koľko stojí bezpečnosť?
Odhadnite komponenty, vývoj, zavádzanie kľúčov, skúšky a podporu podľa skutočného rozsahu. Univerzálna jednotková suma nie je spoľahlivá.