Device Identity & Provisioning

Proč device identity¶

Bez ověřené identity je každé zařízení potenciální útočník. IoT botnet Mirai infikoval stovky tisíc zařízení přes default credentials. Kamera, senzor, gateway — cokoliv bez identity je otevřené dveře do vaší sítě.

Device identity není optional security feature. Je to základ celého IoT stacku. Bez identity nemůžete: autorizovat přístup k datům, doručit konfiguraci správnému zařízení, auditovat kdo co udělal, remotely managovat flotilu.

Zero-touch provisioning¶

Jak to funguje¶

1. Manufacturing: Na výrobní lince se do zařízení zapíše unikátní identifikátor a enrollment credentials (bootstrap certifikát nebo registration token)
2. First boot: Zařízení se zapne, připojí k provisioning service, prezentuje enrollment credentials
3. Verification: Provisioning service ověří credentials proti enrollment databázi
4. Certificate issuance: Po ověření obdrží zařízení runtime certifikát a konfiguraci
5. Operational: Zařízení je plně provozní — komunikuje s backendem přes mTLS

Celý proces pod 30 sekund. Žádný technik, žádný laptop, žádné manuální kroky. Zařízení vybalíte, zapnete, funguje.

Enrollment flows¶

Různé scénáře vyžadují různé enrollment metody:

Manufacturing provisioning: Certifikát nebo seed zapsaný na výrobní lince. Nejbezpečnější — identita je v zařízení od narození. Vyžaduje integraci s manufacturing procesem. Vhodné pro vlastní hardware.

Field provisioning: Technik přiloží telefon k zařízení, naskenuje QR kód, zařízení se aktivuje. Jednodušší deployment, vhodné pro retrofit existujícího hardware. Mobilní provisioning app s offline podporou.

Self-provisioning: Zařízení se registruje samo přes enrollment service. Potvrzení operátorem v management konzoli. Vhodné pro BYOD scénáře nebo dev/test prostředí.

Group enrollment: Všechna zařízení z jedné výrobní šarže sdílejí skupinový certifikát. Po prvním připojení obdrží individuální runtime certifikát. Zjednodušuje manufacturing, zachovává individuální identitu.

X.509 certifikátová infrastruktura¶

PKI architektura¶

Tříúrovňová hierarchie pro enterprise IoT:

• Root CA: Offline, v HSM. Podpisuje intermediate CA. Platnost 10-20 let.
• Intermediate CA: Podpisuje device certifikáty. Oddělené per prostředí (prod, staging) nebo per region. Platnost 3-5 let.
• Device certifikáty: Unikátní per zařízení. Platnost 1-2 roky. Automatická rotace.

HSM (Hardware Security Module): Root CA private key nikdy neopustí HSM. Azure Key Vault, AWS CloudHSM, nebo on-premise HSM (Thales, Utimaco).

Mutual TLS¶

Každá komunikace zařízení ↔ backend je oboustranně autentizovaná:

• Zařízení ověřuje backend certifikát (ochrana proti rogue serveru)
• Backend ověřuje device certifikát (ochrana proti rogue zařízení)
• Šifrovaný kanál (TLS 1.3)
• Žádné shared secrets, žádné API klíče v plaintext

Certificate lifecycle¶

Issuance → Rotation → Revocation

• Automatic rotation: Zařízení si vyžádá nový certifikát před expirací starého. Overlap period — oba certifikáty platné. Zero downtime.
• Revocation: Kompromitovaný certifikát revokujeme okamžitě. CRL (Certificate Revocation List) nebo OCSP (Online Certificate Status Protocol). Backend odmítne připojení s revokovaným certifikátem.
• Emergency rotation: Mass rotation celé flotily v reakci na security incident. Staged rollout — ne všechna zařízení naráz.

Fleet management¶

Device twin / Device shadow¶

Virtuální reprezentace fyzického zařízení v cloudu. Dva stavy:

• Desired state: Co chceme — konfigurace, firmware verze, parametry. Nastavuje operátor.
• Reported state: Co je — aktuální konfigurace, firmware, stav senzorů. Hlásí zařízení.

Rozdíl mezi desired a reported = akce. Desired firmware v2.1, reported v2.0 → OTA update se spustí automaticky.

Operace nad flotilou¶

• Grouping: Podle lokace, typu zařízení, firmware verze, zákazníka. Dynamické skupiny (query-based).
• Bulk operations: Změna konfigurace pro celou skupinu jedním příkazem. Firmware update pro všechna zařízení v regionu.
• Monitoring: Fleet-level metriky — kolik zařízení online, kolik offline, kolik v error stavu. Drill-down na individuální zařízení.
• Lifecycle: Provisioning → Active → Maintenance → Decommissioning. Automatické workflow per stav.

Alerting¶

• Device offline déle než threshold → alert
• Certifikát expiruje do 30 dní → auto-rotation nebo alert
• Firmware verze nesplňuje minimum → forced update
• Anomální chování (neobvyklý traffic, neočekávaná lokace) → security alert

Cloud a on-premise¶

Azure IoT Hub DPS¶

Device Provisioning Service pro Azure:

• Automatic enrollment z manufacturing
• Load balancing across multiple IoT Hubs
• Re-provisioning při přesunu zařízení mezi IoT Huby
• Custom allocation policies (geolocation, workload balancing)
• Integration s Azure Key Vault pro certificate management

AWS IoT Core¶

• Thing registry s thing types a thing groups
• Fleet provisioning templates
• Just-in-time provisioning (JITP) — certifikát registrován při prvním připojení
• Bulk registration přes S3

On-premise / hybrid¶

Pro izolované sítě (výrobní haly, kritická infrastruktura):

• Hashicorp Vault jako PKI backend — certificate issuance, rotation, revocation
• Custom provisioning service běžící v lokální síti
• Sync s cloudem přes secure gateway pro centrální fleet management
• Air-gapped provisioning pro highest-security scénáře

Technologický stack¶

PKI: Hashicorp Vault, Azure Key Vault, AWS Certificate Manager, step-ca, OpenSSL.

Provisioning: Azure IoT Hub DPS, AWS IoT Core, custom enrollment service.

Fleet management: Azure IoT Hub, AWS IoT Core, custom fleet dashboard (Grafana).

Infrastructure: Terraform, Ansible, Docker, Kubernetes.

Security: HSM, TPM, Secure Boot, IEC 62443 compliance.

Souvisí s