Understand how Azure IoT Edge uses certificates

A következőkre vonatkozik:IoT Edge 1.4 checkmark IoT Edge 1.4

Fontos

IoT Edge 1.4 is the supported release. If you are on an earlier release, see Update IoT Edge.

IoT Edge uses different types of certificates for different purposes. Ez a cikk bemutatja, hogyan használja az IoT Edge a tanúsítványokat az Azure IoT Hub és az IoT Edge-átjáró forgatókönyveivel.

Fontos

A rövidség kedvéért ez a cikk az IoT Edge 1.2-es vagy újabb verziójára vonatkozik. Az 1.1-es verzió tanúsítványfogalmai hasonlóak, de vannak különbségek:

  • Az eszköz hitelesítésszolgáltatói tanúsítványa az 1.1-es verzióban Edge CA-tanúsítványra lett átnevezve.
  • Az 1.1-es verzióban a számítási feladat hitelesítésszolgáltatói tanúsítványa ki lett állítva. Az 1.2-es vagy újabb verzióban az IoT Edge modul futtatókörnyezete az összes kiszolgálótanúsítványt közvetlenül az Edge CA-tanúsítványból hozza létre anélkül, hogy a köztes számítási feladat hitelesítésszolgáltatói tanúsítványa közöttük szerepel a tanúsítványláncban.

Summary

These core scenarios are where IoT Edge uses certificates. Use the links to learn more about each scenario.

Actor Purpose Certificate
IoT Edge Ensures it's communicating to the right IoT Hub IoT Hub server certificate
IoT Hub Ensures the request came from a legitimate IoT Edge device IoT Edge identity certificate
Downstream IoT device Ensures it's communicating to the right IoT Edge gateway IoT Edge Hub edgeHub module server certificate, issued by Edge CA
IoT Edge Signs new module server certificates. For example, edgeHub Edge CA certificate
IoT Edge Ensures the request came from a legitimate downstream device IoT device identity certificate

Előfeltételek

Egyetlen eszköz forgatókönyve

Az IoT Edge tanúsítványfogalmainak megértéséhez képzeljen el egy forgatókönyvet, amelyben egy EdgeGateway nevű IoT Edge-eszköz csatlakozik egy ContosoIotHub nevű Azure IoT Hubhoz. Ebben a példában az összes hitelesítés X.509-tanúsítványhitelesítéssel történik a szimmetrikus kulcsok helyett. Ahhoz, hogy megbízhatóságot alakítsunk ki ebben a forgatókönyvben, garantálnunk kell, hogy az IoT Hub és az IoT Edge-eszköz hiteles: "Az eszköz eredeti és érvényes?" és "Helyes az IoT Hub identitása?". A forgatókönyv a következőképpen szemléltethető:

Trust scenario state diagram showing connection between IoT Edge device and IoT Hub.

Elmagyarázzuk az egyes kérdésekre adott válaszokat, majd kibontjuk a példát a cikk későbbi szakaszaiban.

Az eszköz ellenőrzi az IoT Hub identitását

Hogyan ellenőrzi az EdgeGateway , hogy kommunikál-e az eredeti ContosoIotHubbal? Amikor az EdgeGateway beszélni szeretne a felhővel, csatlakozik a végponthoz ContosoIoTHub.Azure-devices.NET. Annak érdekében, hogy a végpont hiteles legyen, az IoT Edge-nek szüksége van a ContosoIoTHubra az azonosítás (ID) megjelenítéséhez. Az azonosítót egy olyan szolgáltatónak kell kiadnia, akiben az EdgeGateway megbízik. Az IoT Hub identitásának ellenőrzéséhez az IoT Edge és az IoT Hub a TLS kézfogási protokoll használatával ellenőrzi az IoT Hub kiszolgálóidentitását. A TLS-kézfogást az alábbi diagram szemlélteti. A példa egyszerűségéhez néhány részlet kimaradt. A TLS kézfogási protokollról a Wikipédián található TLS-kézfogás című témakörben olvashat bővebben.

Megjegyzés:

Ebben a példában a ContosoIoTHub az IoT Hub gazdagépnevét ContosoIotHub.Azure-devices.NET jelöli.

Sequence diagram showing certificate exchange from IoT Hub to IoT Edge device with certificate verification with the trusted root store on the IoT Edge device.

Ebben az összefüggésben nem kell tudnia a titkosítási algoritmus pontos részleteit. Fontos tisztában lenni azzal, hogy az algoritmus biztosítja, hogy a kiszolgáló rendelkezik a nyilvános kulccsal párosított titkos kulccsal. Ellenőrzi, hogy a tanúsítvány előadója nem másolta vagy lopta-e el. Ha például egy fényképazonosítót használunk, az arca megegyezik az azonosítón lévő fényképével. Ha valaki ellopja az azonosítóját, nem használhatja azonosításra, mert az arca egyedi és nehezen reprodukálható. A titkosítási kulcsok esetében a kulcspár egymással kapcsolatos és egyedi. Ahelyett, hogy egy arcot egyeztet egy fényképazonosítóval, a titkosítási algoritmus a kulcspár használatával ellenőrzi az identitást.

Esetünkben a ContosoIotHub a következő tanúsítványláncot jeleníti meg:

Flow diagram showing intermediate and root certificate authority chain for IoT Hub.

A főtanúsítvány-szolgáltató (CA) a Baltimore CyberTrust főtanúsítványa . Ezt a főtanúsítványt a DigiCert írta alá, és széles körben megbízható, és számos operációs rendszerben tárolja. Az Ubuntu és a Windows például az alapértelmezett tanúsítványtárolóba is belefoglalja.

Windows-tanúsítványtároló:

Screenshot showing Baltimore CyberTrust Root certificate listed in the Windows certificate store.

Ubuntu tanúsítványtároló:

Screenshot showing Baltimore CyberTrust Root certificate listed in the Ubuntu certificate store.

Amikor egy eszköz ellenőrzi a Baltimore CyberTrust főtanúsítványát , az előre telepítve van az operációs rendszerben. Az EdgeGateway szempontjából, mivel a ContosoIotHub által bemutatott tanúsítványláncot egy legfelső szintű hitelesítésszolgáltató írja alá, amelyet az operációs rendszer megbízik, a tanúsítvány megbízhatónak minősül. A tanúsítványT IoT Hub-kiszolgálói tanúsítványnak nevezzük. Az IoT Hub-kiszolgálótanúsítványról további információt az IoT Hub Transport Layer Security (TLS) támogatásában talál.

Összefoglalva, az EdgeGateway képes ellenőrizni és megbízni a ContosoIotHub identitásában , mert:

  • A ContosoIotHub bemutatja az IoT Hub-kiszolgáló tanúsítványát
  • A kiszolgálótanúsítvány megbízható az operációsrendszer-tanúsítványtárolóban
  • A ContosoIotHub nyilvános kulcsával titkosított adatokat a ContosoIotHub visszafejtheti, ezzel bizonyítva, hogy rendelkezik a titkos kulcssal.

Az IoT Hub ellenőrzi az IoT Edge-eszköz identitását

Hogyan ellenőrzi a ContosoIotHub, hogy kommunikál az EdgeGatewayrel? Mivel az IoT Hub támogatja a kölcsönös TLS-t (mTLS), az ügyfél által hitelesített TLS-kézfogás során ellenőrzi az EdgeGateway tanúsítványát. Az egyszerűség kedvéért kihagyunk néhány lépést az alábbi ábrán.

Sequence diagram showing certificate exchange from IoT Edge device to IoT Hub with certificate thumbprint check verification on IoT Hub.

Ebben az esetben az EdgeGateway biztosítja az IoT Edge-eszköz identitástanúsítványát. A ContosoIotHub szemszögéből ellenőrzi, hogy a megadott tanúsítvány ujjlenyomata megegyezik-e a rekordjával, az EdgeGateway pedig párosítja a titkos kulcsot a bemutatott tanúsítvánnyal. Amikor IoT Edge-eszközt épít ki az IoT Hubban, ujjlenyomatot ad meg. Az ujjlenyomat az, amellyel az IoT Hub ellenőrzi a tanúsítványt.

Tipp.

Az IoT Hub két ujjlenyomatot igényel egy IoT Edge-eszköz regisztrálásakor. Ajánlott eljárás két különböző eszközidentitás-tanúsítvány előkészítése különböző lejárati dátumokkal. Így, ha az egyik tanúsítvány lejár, a másik továbbra is érvényes, és időt ad a lejárt tanúsítvány elforgatására. A regisztrációhoz azonban csak egy tanúsítvány használható. Egyetlen tanúsítványt használhat, ha ugyanazt a tanúsítvány ujjlenyomatot állítja be az elsődleges és a másodlagos ujjlenyomathoz is az eszköz regisztrálásakor.

Az alábbi paranccsal például lekérhetjük az identitástanúsítvány ujjlenyomatát az EdgeGatewayen:

sudo openssl x509 -in /var/lib/aziot/certd/certs/deviceid-random.cer -noout -nocert -fingerprint -sha256

A parancs az SHA256 tanúsítvány ujjlenyomatát adja ki:

SHA256 Fingerprint=1E:F3:1F:88:24:74:2C:4A:C1:A7:FA:EC:5D:16:C4:11:CD:85:52:D0:88:3E:39:CB:7F:17:53:40:9C:02:95:C3

Ha megtekintjük az IoT Hubban regisztrált EdgeGateway-eszköz SHA256 ujjlenyomat-értékét, láthatja, hogy megegyezik az EdgeGateway ujjlenyomatával:

Screenshot from Azure portal of EdgeGateway device's thumbprint in ContosoIotHub.

Összefoglalva, a ContosoIotHub megbízhat az EdgeGatewayben, mert az EdgeGateway egy érvényes IoT Edge-eszközidentitás-tanúsítványt mutat be, amelynek ujjlenyomata megegyezik az IoT Hubban regisztráltéval.

További információ a tanúsítványkészítési folyamatról: IoT Edge-eszköz létrehozása és kiépítése Linuxon X.509-tanúsítványokkal.

Megjegyzés:

Ez a példa nem foglalkozik az Azure IoT Hub Device Provisioning Service (DPS) szolgáltatással, amely támogatja az X.509 ca-hitelesítést az IoT Edge-lel, amikor regisztrációs csoporttal van kiépítve. A DPS használatával feltölti a hitelesítésszolgáltatói tanúsítványt vagy egy köztes tanúsítványt, ellenőrzi a tanúsítványláncot, majd kiépül az eszköz. További információ: DPS X.509 tanúsítványigazolás.

Az Azure Portalon a DPS az SHA256 ujjlenyomat helyett a tanúsítvány SHA1 ujjlenyomatát jeleníti meg.

A DPS regisztrálja vagy frissíti az SHA256 ujjlenyomatát az IoT Hubra. Az ujjlenyomatot a paranccsal openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256ellenőrizheti. A regisztráció után az Iot Edge ujjlenyomat-hitelesítést használ az IoT Hub használatával. Ha az eszközt újra kiépítik, és új tanúsítványt adnak ki, a DPS frissíti az IoT Hubot az új ujjlenyomattal.

Az IoT Hub jelenleg nem támogatja az X.509 hitelesítésszolgáltatói hitelesítést közvetlenül az IoT Edge-lel.

Tanúsítványhasználat modulidentitás-műveletekhez

A tanúsítvány-ellenőrzési diagramokban úgy tűnhet, hogy az IoT Edge csak a tanúsítványt használja az IoT Hubhoz való beszélgetéshez. Az IoT Edge több modulból áll. Ennek eredményeképpen az IoT Edge a tanúsítvány használatával kezeli az üzeneteket küldő modulok modulidentitását. A modulok nem a tanúsítvány használatával hitelesítik az IoT Hubot, hanem az IoT Edge modul futtatókörnyezete által létrehozott titkos kulcsból származó SAS-kulcsokat használják. Ezek az SAS-kulcsok akkor sem változnak, ha az eszköz identitástanúsítványa lejár. Ha a tanúsítvány lejár, az EdgeHub például továbbra is fut, és csak a modul identitáskezelési műveletei meghiúsulnak.

A modulok és az IoT Hub közötti interakció biztonságos, mivel az SAS-kulcs titkos kódból származik, és az IoT Edge emberi beavatkozás nélkül kezeli a kulcsot.

Beágyazott eszközhierarchia forgatókönyve átjáróként az IoT Edge-lel

Most már jól ismeri az IoT Edge és az IoT Hub közötti egyszerű interakciót. Az IoT Edge azonban átjáróként is működhet az alsóbb rétegbeli eszközökhöz vagy más IoT Edge-eszközökhöz. Ezeknek a kommunikációs csatornáknak titkosítva és megbízhatóan kell lenniük. A hozzáadott összetettség miatt ki kell bővítenünk a példaforgatókönyvet, hogy belefoglaljunk egy alsóbb rétegbeli eszközt.

Hozzáadunk egy TempSensor nevű normál IoT-eszközt, amely a szülő IoT Edge-eszközéhez, az EdgeGatewayhez csatlakozik, amely az IoT Hub ContosoIotHubhoz csatlakozik. A korábbiakhoz hasonlóan minden hitelesítés X.509-tanúsítványhitelesítéssel történik. Az új forgatókönyv két új kérdést vet fel: "A TempSensor-eszköz jogos?" és "Helyes az EdgeGateway identitása?". A forgatókönyv a következőképpen szemléltethető:

Trust scenario state diagram showing connection between IoT Edge device, an IoT Edge gateway, and IoT Hub.

Tipp.

A TempSensor egy IoT-eszköz a forgatókönyvben. A tanúsítvány fogalma ugyanaz, ha a TempSensor a szülő EdgeGateway alsóbb rétegbeli IoT Edge-eszköze.

Az eszköz ellenőrzi az átjáró identitását

Hogyan ellenőrzi a TempSensor, hogy kommunikál-e az eredeti EdgeGatewayrel? Amikor a TempSensor beszélni szeretne az EdgeGatewayrel, a TempSensornak szüksége van az EdgeGatewayre egy azonosító megjelenítéséhez. Az azonosítót a TempSensor által megbízhatónak ítélt hatóságnak kell kiállítania.

Sequence diagram showing certificate exchange from gateway device to IoT Edge device with certificate verification using the private root certificate authority.

A folyamat ugyanaz, mint amikor az EdgeGateway a ContosoIotHubhoz beszél. A TempSensor és az EdgeGateway a TLS kézfogási protokoll használatával ellenőrzi az EdgeGateway identitását . Két fontos részlet van:

  • Állomásnév-specifikusság: Az EdgeGateway által bemutatott tanúsítványt ugyanarra a gazdagépnévre (tartományra vagy IP-címre) kell kiállítani, amelyet a TempSensor az EdgeGatewayhez való csatlakozáshoz használ.
  • Önaláírt legfelső szintű hitelesítésszolgáltató-specifikusság: Az EdgeGateway által bemutatott tanúsítványlánc valószínűleg nem szerepel az operációs rendszer alapértelmezett megbízható legfelső szintű tárolójában.

A részletek megértéséhez először vizsgáljuk meg az EdgeGateway által bemutatott tanúsítványláncot.

Flow diagram showing certificate authority chain for an IoT Edge gateway.

Állomásnév-specifikusság

A tanúsítvány köznapi neve CN = edgegateway.local a lánc tetején található. Az edgegateway.local az EdgeHub kiszolgálótanúsítványának gyakori neve. Az edgegateway.local az EdgeGateway állomásneve azon helyi hálózaton (LAN vagy VNet), ahol a TempSensor és az EdgeGateway csatlakozik. Ez lehet egy privát IP-cím, például a 192.168.1.23 vagy egy teljes tartománynév (FQDN), mint a diagram. Az edgeHub-kiszolgáló tanúsítványa az IoT Edge config.toml fájlban definiált állomásnév paraméterrel jön létre. Ne keverje össze az edgeHub-kiszolgáló tanúsítványát az Edge CA-tanúsítvánnyal. Az Edge CA-tanúsítvány kezelésével kapcsolatos további információkért lásd : IoT Edge-tanúsítványok kezelése.

Amikor a TempSensor csatlakozik az EdgeGatewayhez, a TempSensor az edgegateway.local gazdagépnév használatával csatlakozik az EdgeGatewayhez. A TempSensor ellenőrzi az EdgeGateway által bemutatott tanúsítványt, és ellenőrzi, hogy a tanúsítvány köznapi neve edgegateway.local-e. Ha a tanúsítvány köznapi neve eltérő, a TempSensor elutasítja a kapcsolatot.

Megjegyzés:

Az egyszerűség kedvéért a példa a tulajdonostanúsítvány közös nevét (CN) érvényesített tulajdonságként jeleníti meg. A gyakorlatban, ha egy tanúsítvány tulajdonos alternatív neve (SAN) van, akkor a rendszer a SAN-t érvényesíti a CN helyett. Általánosságban elmondható, hogy mivel a SAN több értéket is tartalmazhat, a tanúsítvány tulajdonosának fő tartománya/gazdagépneve, valamint bármely alternatív tartomány.

Miért kell az EdgeGatewayt a saját gazdagépnevéről tudni?

Az EdgeGateway nem tudja megbízhatóan tudni, hogy a hálózat többi ügyfele hogyan tud csatlakozni hozzá. Magánhálózaton például lehetnek DHCP-kiszolgálók vagy mDNS-szolgáltatások, amelyek az EdgeGatewayt 10.0.0.2 mint vagy example-mdns-hostname.localazt sorolják fel. Egyes hálózatokban azonban lehetnek olyan DNS-kiszolgálók, amelyek az EdgeGateway IP-címére 10.0.0.2 vannak leképezveedgegateway.local.

A probléma megoldásához az IoT Edge a konfigurált gazdagépnév-értéket használja, config.toml és létrehoz egy kiszolgálótanúsítványt. Amikor egy kérelem az EdgeHub-modulhoz érkezik, a tanúsítványt a megfelelő közös tanúsítvánnyal (CN) jeleníti meg.

Miért hoz létre az IoT Edge tanúsítványokat?

A példában megfigyelheti, hogy a tanúsítványláncban egy iotedgedged számítási feladat ca edgegateway található. Ez a hitelesítésszolgáltató (CA) létezik az IoT Edge-eszközön, amelyet Edge CA-nak (korábbi nevén Device CA-nak neveznek az 1.1-es verzióban). A Baltimore CyberTrust legfelső szintű hitelesítésszolgáltatójához hasonlóan az Edge-hitelesítésszolgáltató más tanúsítványokat is kibocsáthat. A legfontosabb, és ebben a példában is a kiszolgálótanúsítványt adja ki az EdgeHub-modulnak. De tanúsítványokat is kiadhat az IoT Edge-eszközön futó más moduloknak.

Fontos

Alapértelmezés szerint konfiguráció nélkül az Edge ca-t az IoT Edge modul futtatókörnyezete automatikusan generálja, amikor első alkalommal indul el, úgynevezett gyorsútmutató Edge CA, majd tanúsítványt ad ki az EdgeHub-modulhoz. Ez a folyamat felgyorsítja az alsóbb rétegbeli eszközkapcsolatot azáltal, hogy lehetővé teszi az EdgeHub számára, hogy érvényes, aláírt tanúsítványt mutasson be. E funkció nélkül le kell kérnie a hitelesítésszolgáltatót, hogy kibocsátsa a tanúsítványt az EdgeHub-modulhoz. Az automatikusan létrehozott gyorsútmutatók használata az Éles környezetben nem támogatott. Az Edge CA rövid útmutatójával kapcsolatos további információkért lásd: Quickstart Edge CA.

Nem veszélyes egy kiállítói tanúsítvány az eszközön?

Az Edge CA úgy lett kialakítva, hogy lehetővé tegye a korlátozott, megbízhatatlan, drága vagy hiányzó kapcsolattal rendelkező megoldásokat, ugyanakkor szigorú szabályozásokkal vagy szabályzatokkal rendelkezik a tanúsítványmegújításokra. Az Edge CA nélkül az IoT Edge - és különösen edgeHub - nem működik.

Az Edge CA biztonságossá tételéhez éles környezetben:

  • Helyezze az EdgeCA titkos kulcsot egy megbízható platformmodulba (TPM), lehetőleg úgy, hogy a titkos kulcs rövidesen létre legyen hozva, és soha ne hagyja el a TPM-et.
  • Használjon nyilvános kulcsú infrastruktúrát (PKI), amelybe az Edge CA összesít. Ez lehetővé teszi a sérült tanúsítványok megújításának letiltását vagy elutasítását. A PKI-t az ügyfél informatikai szolgáltatója kezelheti, ha rendelkezik a know-how -nal (alacsonyabb költséggel) vagy egy kereskedelmi PKI-szolgáltatón keresztül.

Önaláírt legfelső szintű hitelesítésszolgáltató-specifikusság

Az edgeHub-modul egy fontos összetevő, amely az IoT Edge-et az összes bejövő forgalom kezelésével alkotja. Ebben a példában az Edge CA által kiadott tanúsítványt használja, amelyet egy önaláírt legfelső szintű hitelesítésszolgáltató bocsát ki. Mivel a legfelső szintű hitelesítésszolgáltatót az operációs rendszer nem megbízható, a TempSensor csak úgy bízhat meg benne, ha telepíti a hitelesítésszolgáltatói tanúsítványt az eszközre. Ezt a megbízhatósági csomag forgatókönyvének is nevezik, ahol el kell osztania a gyökért az olyan ügyfeleknek, amelyeknek meg kell bíznia a láncban. A megbízhatósági csomag forgatókönyve problémás lehet, mert hozzá kell férnie az eszközhöz, és telepítenie kell a tanúsítványt. A tanúsítvány telepítése tervezést igényel. Ez elvégezhető szkriptekkel, a gyártás során hozzáadva, vagy előre telepítve az operációs rendszer lemezképében.

Megjegyzés:

Egyes ügyfelek és SDK-k nem használják az operációs rendszer megbízható legfelső szintű tárolóját, ezért közvetlenül át kell adnia a legfelső szintű hitelesítésszolgáltatói fájlt.

Mindezeket a fogalmakat alkalmazva a TempSensor ellenőrizheti, hogy kommunikál-e az eredeti EdgeGatewayrel, mert egy olyan tanúsítványt mutatott be, amely megfelel a címnek, és a tanúsítványt egy megbízható gyökér írja alá.

A tanúsítványlánc ellenőrzéséhez használhatja openssl a TempSensor-eszközön . Ebben a példában figyelje meg, hogy a kapcsolat állomásneve megegyezik a 0 . mélységi tanúsítvány CN-jének és a legfelső szintű hitelesítésszolgáltatónak.

openssl s_client -connect edgegateway.local:8883 --CAfile my_private_root_CA.pem

depth=3 CN = my_private_root_CA
verify return:1
depth=2 CN = my_optional_intermediate_CA
verify return:1
depth=1 CN = iotedged workload ca edgegateway
verify return:1
depth=0 CN = edgegateway.local
verify return: 1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=edgegateway.local
  i:/CN=iotedged workload ca edgegateway
1 s:/CN=iotedged workload ca edgegateway
  i:/CN=my_optional_intermediate_CA
2 s:/CN=my_optional_intermediate_CA
  i:/CN=my_private_root_CA

A parancsról openssl további információt az OpenSSL dokumentációjában talál.

Emellett megvizsgálhatja azokat a tanúsítványokat is, ahol alapértelmezés szerint a rendszer tárolja őket./var/lib/aziot/certd/certs A címtárban edge ca-tanúsítványok, eszközidentitás-tanúsítványok és modultanúsítványok találhatók. Parancsokkal megvizsgálhatja openssl x509 a tanúsítványokat. Például:

sudo ls -l /var/lib/aziot/certd/certs
total 24
-rw-r--r-- 1 aziotcs aziotcs 1090 Jul 27 21:27 aziotedgedca-86f154be7ff14480027f0d00c59c223db6d9e4ab0b559fc523cca36a7c973d6d.cer
-rw-r--r-- 1 aziotcs aziotcs 2589 Jun 22 18:25 aziotedgedmoduleIoTEdgeAPIProxy637913460334654299server-c7066944a8d35ca97f1e7380ab2afea5068f39a8112476ffc89ea2c46ca81d10.cer
-rw-r--r-- 1 aziotcs aziotcs 2576 Jun 22 18:25 aziotedgedmoduleedgeHub637911101449272999server-a0407493b6b50ee07b3fedbbb9d181e7bb5f6f52c1d071114c361aca628daa92.cer
-rw-r--r-- 1 aziotcs aziotcs 1450 Jul 27 21:27 deviceid-bd732105ef89cf8edd2606a5309c8a26b7b5599a4e124a0fe6199b6b2f60e655.cer

Összefoglalva, a TempSensor megbízhat az EdgeGatewayben, mert:

  • Az edgeHub-modul egy érvényes IoT Edge-modulkiszolgáló-tanúsítványt mutatott az edgegateway.local-hoz
  • A tanúsítványt az Edge CA állítja ki, amelyetmy_private_root_CA
  • Ez a privát legfelső szintű hitelesítésszolgáltató a TempSensorban is megbízható legfelső szintű hitelesítésszolgáltatóként van tárolva korábban
  • A titkosítási algoritmusok ellenőrzik, hogy a tulajdonosi és kiállítási lánc megbízható-e

Tanúsítványok más modulokhoz

Más modulok lekérhetik az Edge CA által kiadott kiszolgálótanúsítványokat. Például egy webes felülettel rendelkező Grafana-modul . Emellett tanúsítványt is lekérhet az Edge CA-tól. A modulok a tárolóban üzemeltetett alsóbb rétegbeli eszközökként vannak kezelve. Az IoT Edge modul futtatókörnyezetéből származó tanúsítvány lekérése azonban különleges jogosultság. A modulok meghívják a számítási feladat API-t a kiszolgáló tanúsítványának a konfigurált Edge CA-hoz láncolt fogadásához.

Az átjáró ellenőrzi az eszköz identitását

Hogyan ellenőrzi az EdgeGateway, hogy kommunikál a TempSensorsal? Az EdgeGateway TLS-ügyfélhitelesítést használ a TempSensor hitelesítéséhez.

Sequence diagram showing certificate exchange from IoT Edge device to gateway with certificate check verification from IoT Hub certificates.

A szekvencia hasonló az eszköz ellenőrzésére szolgáló ContosoIotHubhoz . Átjáróforgatókönyvekben azonban az EdgeGateway a ContosoIotHubra támaszkodik a tanúsítványok rekordjának igazságforrásaként. Az EdgeGateway offline másolatot vagy gyorsítótárat is tart, ha nincs kapcsolat a felhőhöz.

Tipp.

Az IoT Edge-eszközökkel ellentétben az alsóbb rétegbeli IoT-eszközök nem korlátozódnak az ujjlenyomat X.509-hitelesítésre. Az X.509 hitelesítésszolgáltatói hitelesítés is lehetőség. Ahelyett, hogy csak egyezést keres az ujjlenyomaton, az EdgeGateway azt is ellenőrizheti, hogy a TempSensor tanúsítványa a ContosoIotHubra feltöltött hitelesítésszolgáltatóban gyökerezik-e.

Összefoglalva, az EdgeGateway megbízhat a TempSensorban, mert:

  • A TempSensor egy érvényes IoT-eszközidentitás-tanúsítványt mutatott be a nevéhez
  • Az identitástanúsítvány ujjlenyomata megegyezik a ContosoIotHubra feltöltött ujjlenyomattal
  • A titkosítási algoritmusok ellenőrzik, hogy a tulajdonosi és kiállítási lánc megbízható-e

A tanúsítványok és a felügyelet lekérésének helye

A legtöbb esetben megadhat saját tanúsítványokat, vagy használhatja az automatikusan létrehozott tanúsítványokat. Az Edge CA és az edgeHub-tanúsítvány például automatikusan létre lesz hozva.

Az ajánlott eljárás azonban az, hogy az eszközök úgy legyenek konfigurálva, hogy az x509-tanúsítványok kezelésére egy EST-kiszolgálón keresztüli regisztrációt használjanak. Az EST-kiszolgáló használata lehetővé teszi a tanúsítványok manuális kezelését és eszközökre való telepítését. Az EST-kiszolgáló használatáról további információt az Azure IoT Edge biztonságos átviteli kiszolgálón keresztüli regisztrációjának konfigurálása című témakörben talál.

Tanúsítványokkal is hitelesítheti magát az EST-kiszolgálón. Ezek a tanúsítványok az EST-kiszolgálókkal történő hitelesítésre szolgálnak más tanúsítványok kiállításához. A tanúsítványszolgáltatás egy bootstrap-tanúsítványt használ az EST-kiszolgálóval való hitelesítéshez. A rendszerindító tanúsítvány hosszú élettartamú. A kezdeti hitelesítéskor a tanúsítványszolgáltatás kérést intéz az EST-kiszolgálóhoz identitástanúsítvány kiállítására. Ezt az identitástanúsítványt a rendszer az ugyanazon kiszolgálóra irányuló jövőbeli EST-kérelmekben használja.

Ha nem tud EST-kiszolgálót használni, tanúsítványokat kell kérnie a PKI-szolgáltatótól. A tanúsítványfájlokat manuálisan is kezelheti az IoT Hubon és az IoT Edge-eszközökön. További információ: Tanúsítványok kezelése IoT Edge-eszközön.

A koncepció fejlesztésének igazolásához létrehozhat teszttanúsítványokat. További információ: Demótanúsítványok létrehozása az IoT Edge eszközfunkcióinak teszteléséhez.

Tanúsítványok az IoT-ben

Hitelesítésszolgáltató

A hitelesítésszolgáltató (CA) egy olyan entitás, amely digitális tanúsítványokat bocsát ki. A hitelesítésszolgáltató megbízható harmadik félként működik a tanúsítvány tulajdonosa és fogadója között. A digitális tanúsítvány hitelesíti a nyilvános kulcs tulajdonjogát a tanúsítvány fogadója által. A megbízhatósági tanúsítványlánc úgy működik, hogy kezdetben egy főtanúsítványt ad ki, amely a hatóság által kibocsátott összes tanúsítvány megbízhatóságának alapja. A főtanúsítvány tulajdonosa ezután további köztes tanúsítványokat (alsóbb rétegbeli eszköztanúsítványokat) is kibocsáthat.

Legfelső szintű hitelesítésszolgáltatói tanúsítvány

A legfelső szintű hitelesítésszolgáltatói tanúsítvány a teljes folyamat megbízhatóságának gyökere. Éles helyzetekben ez a hitelesítésszolgáltatói tanúsítvány egy megbízható kereskedelmi hitelesítésszolgáltatótól, például Baltimore-tól, Verisigntől vagy DigiCerttől vásárolható meg. Ha teljes körű vezérléssel rendelkezik az IoT Edge-eszközökhöz csatlakozó eszközök felett, vállalati szintű hitelesítésszolgáltatót is használhat. Mindkét esetben az IoT Edge és az IoT Hub közötti teljes tanúsítványlánc használja. Az alsóbb rétegbeli IoT-eszközöknek megbízhatónak kell lenniük a főtanúsítványban. A legfelső szintű hitelesítésszolgáltatói tanúsítványt a megbízható legfelső szintű hitelesítésszolgáltató tárolójában tárolhatja, vagy megadhatja a tanúsítvány részleteit az alkalmazás kódjában.

Köztes tanúsítványok

A biztonságos eszközök létrehozásának tipikus gyártási folyamata során a legfelső szintű hitelesítésszolgáltatói tanúsítványokat ritkán használják közvetlenül, elsősorban a szivárgás vagy az expozíció kockázata miatt. A fő hitelesítésszolgáltatói tanúsítvány létrehoz és digitálisan aláír egy vagy több köztes hitelesítésszolgáltatói tanúsítványt. Lehet, hogy csak egy, vagy a köztes tanúsítványok láncolata. A köztes tanúsítványok láncát igénylő forgatókönyvek a következők:

  • A gyártón belüli részlegek hierarchiája
  • Több vállalat is részt vett sorozatban egy eszköz gyártásában
  • Az ügyfél megvásárol egy legfelső szintű hitelesítésszolgáltatót, és egy aláíró tanúsítványt hoz létre a gyártó számára, hogy aláírja azokat az eszközöket, amelyeket az adott ügyfél nevében hoz létre

A gyártó mindenesetre a lánc végén egy köztes hitelesítésszolgáltatói tanúsítványt használ a végfelhasználói eszközön elhelyezett peremhálózati hitelesítésszolgáltatói tanúsítvány aláírásához. Ezeket a közbenső tanúsítványokat szigorúan őrzik a gyártóüzemben. Szigorú folyamatokon mennek keresztül, mind fizikai, mind elektronikus használatra.

Következő lépések