Share via

Pahami cara Azure IoT Edge menggunakan sertifikat

  • Artikel

Berlaku untuk:Tanda centang IoT Edge 1.5 IoT Edge 1.5 Tanda centang IoT Edge 1.4 IoT Edge 1.4

Penting

IoT Edge 1.5 LTS dan IoT Edge 1.4 LTS adalah rilis yang didukung. IoT Edge 1.4 LTS adalah akhir masa pakai pada 12 November 2024. Jika Anda menggunakan rilis sebelumnya, lihat Memperbarui IoT Edge.

IoT Edge menggunakan beragam jenis sertifikat untuk tujuan yang berbeda. Artikel ini memancang Anda melalui berbagai cara IoT Edge menggunakan sertifikat dengan Azure IoT Hub dan skenario gateway IoT Edge.

Penting

Untuk brevity, artikel ini berlaku untuk IoT Edge versi 1.2 atau yang lebih baru. Konsep sertifikat untuk versi 1.1 serupa, tetapi ada beberapa perbedaan:

  • Sertifikat OS perangkat di versi 1.1 diganti namanya menjadi sertifikat CA Edge.
  • Sertifikat OS beban kerja di versi 1.1 dihentikan. Dalam versi 1.2 atau yang lebih baru, runtime modul IoT Edge menghasilkan semua sertifikat server langsung dari sertifikat CA Edge, tanpa sertifikat OS beban kerja menengah di antara mereka dalam rantai sertifikat.

Ringkasan

Skenario inti ini adalah lokasi IoT Edge menggunakan sertifikat. Gunakan tautan untuk mempelajari lebih lanjut tentang setiap skenario.

Actor Tujuan Sertifikat
IoT Edge Memastikannya berkomunikasi ke IoT Hub yang tepat Sertifikat server IoT Hub
IoT Hub Memastikan permintaan berasal dari perangkat IoT Edge yang sah Sertifikat identitas IoT Edge
Perangkat IoT hilir Memastikannya berkomunikasi ke gateway IoT Edge yang tepat Sertifikat server modul edgeHub IoT Edge Hub, dikeluarkan oleh Edge CA
IoT Edge Menandatangani sertifikat server modul baru. Misalnya, edgeHub Sertifikat OS Tepi
IoT Edge Memastikan permintaan berasal dari perangkat hilir yang sah Sertifikat identitas perangkat IoT

Prasyarat

  • Anda harus memiliki pemahaman dasar tentang kriptografi kunci publik, pasangan kunci, dan bagaimana kunci publik dan kunci privat dapat mengenkripsi atau mendekripsi data. Untuk informasi selengkapnya tentang cara IoT Edge menggunakan kriptografi kunci publik, lihat Memahami Kriptografi Kunci Umum dan Infrastruktur Kunci Umum X.509.
  • Anda harus memiliki pemahaman dasar tentang bagaimana IoT Edge berhubungan dengan IoT Hub. Untuk informasi selengkapnya, lihat Memahami runtime Azure IoT Edge dan arsitekturnya.

Skenario perangkat tunggal

Untuk membantu memahami konsep sertifikat IoT Edge, bayangkan skenario di mana perangkat IoT Edge bernama EdgeGateway tersambung ke Azure IoT Hub bernama ContosoIotHub. Dalam contoh ini, semua autentikasi dilakukan dengan autentikasi sertifikat X.509 daripada kunci konten. Untuk membangun kepercayaan dalam skenario ini, kita perlu menjamin IoT Hub dan perangkat IoT Edge autentik: "Apakah perangkat ini asli dan valid?" dan "Apakah identitas IoT Hub benar?". Skenario dapat diilustrasikan sebagai berikut:

Diagram status skenario kepercayaan memperlihatkan koneksi antara perangkat IoT Edge dan IoT Hub.

Kami akan menjelaskan jawaban untuk setiap pertanyaan lalu memperluas contoh di bagian selanjutnya dari artikel.

Perangkat memverifikasi identitas IoT Hub

Bagaimana EdgeGateway memverifikasi bahwa EdgeGateway berkomunikasi dengan ContosoIotHub asli? Saat EdgeGateway ingin berbicara dengan cloud, EdgeGateway terhubung ke titik akhir ContosoIoTHub.Azure-devices.NET. Untuk memastikan titik akhir autentik, IoT Edge memerlukan ContosoIoTHub untuk menampilkan identifikasi (ID). ID harus dikeluarkan oleh otoritas yang dipercaya EdgeGateway . Untuk memverifikasi identitas IoT Hub, IoT Edge dan IoT Hub menggunakan protokol jabat tangan TLS untuk memverifikasi identitas server IoT Hub. Jabat tangan TLS diilustrasikan dalam diagram berikut. Agar contohnya tetap sederhana, beberapa detail telah dihilangkan. Untuk mempelajari selengkapnya tentang protokol jabat tangan TLS, lihat jabat tangan TLS di Wikipedia.

Catatan

Dalam contoh ini, ContosoIoTHub mewakili nama host IoT Hub ContosoIotHub.Azure-devices.NET.

Diagram urutan memperlihatkan pertukaran sertifikat dari IoT Hub ke perangkat IoT Edge dengan verifikasi sertifikat dengan penyimpanan akar tepercaya di perangkat IoT Edge.

Dalam konteks ini, Anda tidak perlu mengetahui detail algoritma kriptografi yang tepat. Penting untuk dipahami bahwa algoritma memastikan server memiliki kunci privat yang dipasangkan dengan kunci publiknya. Ini memverifikasi bahwa penyaji sertifikat tidak menyalin atau mencurinya. Jika kita menggunakan ID foto sebagai contoh, wajah Anda cocok dengan foto pada ID. Jika seseorang mencuri ID Anda, mereka tidak dapat menggunakannya untuk identifikasi karena wajah Anda unik dan sulit untuk direproduksi. Untuk kunci kriptografi, pasangan kunci terkait dan unik. Alih-alih mencocokkan wajah dengan ID foto, algoritma kriptografi menggunakan pasangan kunci untuk memverifikasi identitas.

Dalam skenario kami, ContosoIotHub menunjukkan rantai sertifikat berikut:

Diagram alur memperlihatkan rantai otoritas sertifikat menengah dan akar untuk IoT Hub.

Otoritas sertifikat akar (CA) adalah sertifikat Baltimore CyberTrust Root . Sertifikat akar ini ditandatangani oleh DigiCert, dan dipercaya secara luas dan disimpan dalam banyak sistem operasi. Misalnya, Ubuntu dan Windows menyertakannya di penyimpanan sertifikat default.

Penyimpanan sertifikat Windows:

Cuplikan layar memperlihatkan sertifikat Baltimore CyberTrust Root yang tercantum di penyimpanan sertifikat Windows.

Penyimpanan sertifikat Ubuntu:

Cuplikan layar memperlihatkan sertifikat Baltimore CyberTrust Root yang tercantum di penyimpanan sertifikat Ubuntu.

Ketika perangkat memeriksa sertifikat Baltimore CyberTrust Root , sertifikat tersebut telah diinstal sebelumnya di OS. Dari perspektif EdgeGateway , karena rantai sertifikat yang disajikan oleh ContosoIotHub ditandatangani oleh CA akar yang dipercaya OS, sertifikat dianggap dapat dipercaya. Sertifikat ini dikenal sebagai sertifikat server IoT Hub. Untuk mempelajari selengkapnya tentang sertifikat server IoT Hub, lihat dukungan Keamanan Lapisan Transportasi (TLS) di IoT Hub.

Singkatnya, EdgeGateway dapat memverifikasi dan mempercayai identitas ContosoIotHub karena:

  • ContosoIotHub menyajikan sertifikat server IoT Hub-nya
  • Sertifikat server dipercaya di penyimpanan sertifikat OS
  • Data yang dienkripsi dengan kunci umum ContosoIotHub dapat didekripsi oleh ContosoIotHub, membuktikan kepemilikan kunci privatnya

IoT Hub memverifikasi identitas perangkat IoT Edge

Bagaimana ContosoIotHub memverifikasi bahwa ContosoIotHub berkomunikasi dengan EdgeGateway? Karena IoT Hub mendukung TLS bersama (mTLS), IoT Hub memeriksa sertifikat EdgeGateway selama jabat tangan TLS yang diautentikasi klien. Untuk kesederhanaan, kita akan melewati beberapa langkah dalam diagram berikut.

Diagram urutan memperlihatkan pertukaran sertifikat dari perangkat IoT Edge ke IoT Hub dengan verifikasi pemeriksaan thumbprint sertifikat di IoT Hub.

Dalam hal ini, EdgeGateway menyediakan sertifikat identitas perangkat IoT Edge-nya. Dari perspektif ContosoIotHub , ia memeriksa apakah thumbprint sertifikat yang disediakan cocok dengan rekamannya dan EdgeGateway memiliki kunci privat yang dipasangkan dengan sertifikat yang disajikannya. Saat Anda memprovisikan perangkat IoT Edge di IoT Hub, Anda memberikan thumbprint. Thumbprint adalah apa yang digunakan IoT Hub untuk memverifikasi sertifikat.

Tip

IoT Hub memerlukan dua thumbprint saat mendaftarkan perangkat IoT Edge. Praktik terbaik adalah menyiapkan dua sertifikat identitas perangkat yang berbeda dengan tanggal kedaluwarsa yang berbeda. Dengan cara ini, jika satu sertifikat kedaluwarsa, sertifikat lainnya masih valid dan memberi Anda waktu untuk memutar sertifikat yang kedaluwarsa. Namun, dimungkinkan juga untuk hanya menggunakan satu sertifikat untuk pendaftaran. Gunakan satu sertifikat dengan mengatur thumbprint sertifikat yang sama untuk thumbprint primer dan sekunder saat mendaftarkan perangkat.

Misalnya, kita dapat menggunakan perintah berikut untuk mendapatkan thumbprint sertifikat identitas di EdgeGateway:

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

Perintah menghasilkan thumbprint SERTIFIKAT SHA256:

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

Jika kita melihat nilai thumbprint SHA256 untuk perangkat EdgeGateway yang terdaftar di IoT Hub, kita dapat melihatnya cocok dengan thumbprint di EdgeGateway:

Cuplikan layar dari portal Azure thumbprint perangkat EdgeGateway di ContosoIotHub.

Singkatnya, ContosoIotHub dapat mempercayai EdgeGateway karena EdgeGateway menyajikan sertifikat identitas perangkat IoT Edge yang valid yang thumbprintnya cocok dengan yang terdaftar di IoT Hub.

Untuk informasi selengkapnya tentang proses pembuatan sertifikat, lihat Membuat dan memprovisikan perangkat IoT Edge di Linux menggunakan sertifikat X.509.

Catatan

Contoh ini tidak membahas Azure IoT Hub Device Provisioning Service (DPS), yang memiliki dukungan untuk autentikasi CA X.509 dengan IoT Edge saat disediakan dengan grup pendaftaran. Dengan menggunakan DPS, Anda mengunggah sertifikat CA atau sertifikat perantara, rantai sertifikat diverifikasi, lalu perangkat disediakan. Untuk mempelajari selengkapnya, lihat Pengesahan sertifikat DPS X.509.

Di Portal Microsoft Azure, DPS menampilkan thumbprint SHA1 untuk sertifikat, bukan thumbprint SHA256.

DPS mendaftarkan atau memperbarui thumbprint SHA256 ke IoT Hub. Anda dapat memverifikasi thumbprint menggunakan perintah openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256. Setelah terdaftar, Iot Edge menggunakan autentikasi thumbprint dengan IoT Hub. Jika perangkat diprovisikan ulang dan sertifikat baru dikeluarkan, DPS memperbarui IoT Hub dengan thumbprint baru.

IoT Hub saat ini tidak mendukung autentikasi CA X.509 langsung dengan IoT Edge.

Penggunaan sertifikat untuk operasi identitas modul

Dalam diagram verifikasi sertifikat, mungkin IoT Edge hanya menggunakan sertifikat untuk berbicara dengan IoT Hub. IoT Edge terdiri dari beberapa modul. Akibatnya, IoT Edge menggunakan sertifikat untuk mengelola identitas modul untuk modul yang mengirim pesan. Modul tidak menggunakan sertifikat untuk mengautentikasi ke IoT Hub, melainkan menggunakan kunci SAS yang berasal dari kunci privat yang dihasilkan oleh runtime modul IoT Edge. Kunci SAS ini tidak berubah meskipun sertifikat identitas perangkat kedaluwarsa. Jika sertifikat kedaluwarsa, edgeHub misalnya terus berjalan, dan hanya operasi identitas modul yang gagal.

Interaksi antara modul dan IoT Hub aman karena kunci SAS berasal dari rahasia dan IoT Edge mengelola kunci tanpa risiko intervensi manusia.

Skenario hierarki perangkat berlapis dengan IoT Edge sebagai gateway

Anda sekarang memiliki pemahaman yang baik tentang interaksi sederhana IoT Edge antara dan IoT Hub. Namun, IoT Edge juga dapat bertindak sebagai gateway untuk perangkat hilir atau perangkat IoT Edge lainnya. Saluran komunikasi ini juga harus dienkripsi dan dipercaya. Karena kompleksitas tambahan, kita harus memperluas skenario contoh kita untuk menyertakan perangkat hilir.

Kami menambahkan perangkat IoT reguler bernama TempSensor, yang terhubung ke perangkat IoT Edge induknya EdgeGateway yang terhubung ke IoT Hub ContosoIotHub. Mirip dengan sebelumnya, semua autentikasi dilakukan dengan autentikasi sertifikat X.509. Skenario baru kami menimbulkan dua pertanyaan baru: "Apakah perangkat TempSensor sah?" dan "Apakah identitas EdgeGateway benar?". Skenario dapat diilustrasikan sebagai berikut:

Diagram status skenario kepercayaan memperlihatkan koneksi antara perangkat IoT Edge, gateway IoT Edge, dan IoT Hub.

Tip

TempSensor adalah perangkat IoT dalam skenario. Konsep sertifikat sama jika TempSensor adalah perangkat IoT Edge hilir dari induk EdgeGateway.

Perangkat memverifikasi identitas gateway

Bagaimana TempSensor memverifikasi bahwa tempSensor berkomunikasi dengan EdgeGateway asli? Ketika TempSensor ingin berbicara dengan EdgeGateway, TempSensor memerlukan EdgeGateway untuk menampilkan ID. ID harus dikeluarkan oleh otoritas yang dipercaya TempSensor .

Diagram urutan memperlihatkan pertukaran sertifikat dari perangkat gateway ke perangkat IoT Edge dengan verifikasi sertifikat menggunakan otoritas sertifikat akar privat.

Alurnya sama seperti ketika EdgeGateway berbicara dengan ContosoIotHub. TempSensor dan EdgeGateway menggunakan protokol jabat tangan TLS untuk memverifikasi identitas EdgeGateway . Ada dua detail penting:

  • Kekhususan nama host: Sertifikat yang disajikan oleh EdgeGateway harus dikeluarkan ke nama host yang sama (domain atau alamat IP) yang digunakan TempSensor untuk menyambungkan ke EdgeGateway.
  • Kekhususan CA akar yang ditandatangani sendiri: Rantai sertifikat yang disajikan oleh EdgeGateway kemungkinan tidak ada di penyimpanan akar tepercaya default OS.

Untuk memahami detailnya, mari kita periksa terlebih dahulu rantai sertifikat yang disajikan oleh EdgeGateway.

Diagram alur memperlihatkan rantai otoritas sertifikat untuk gateway IoT Edge.

Kekhususan nama host

Nama umum sertifikat CN = edgegateway.local tercantum di bagian atas rantai. edgegateway.local adalah nama umum sertifikat server edgeHub. edgegateway.local juga merupakan nama host untuk EdgeGateway di jaringan lokal (LAN atau VNet) tempat TempSensor dan EdgeGateway terhubung. Ini bisa menjadi alamat IP privat seperti 192.168.1.23 atau nama domain yang sepenuhnya memenuhi syarat (FQDN) seperti diagram. Sertifikat server edgeHub dihasilkan menggunakan parameter nama host yang ditentukan dalam file IoT Edge config.toml. Jangan membingungkan sertifikat server edgeHub dengan sertifikat Edge CA. Untuk informasi selengkapnya tentang mengelola sertifikat CA Edge, lihat Mengelola sertifikat IoT Edge.

Saat TempSensor tersambung ke EdgeGateway, TempSensor menggunakan nama host edgegateway.local untuk menyambungkan ke EdgeGateway. TempSensor memeriksa sertifikat yang disajikan oleh EdgeGateway dan memverifikasi bahwa nama umum sertifikat adalah edgegateway.local. Jika nama umum sertifikat berbeda, TempSensor menolak koneksi.

Catatan

Untuk kesederhanaan, contoh menunjukkan nama umum sertifikat subjek (CN) sebagai properti yang divalidasi. Dalam praktiknya, jika sertifikat memiliki nama alternatif subjek (SAN), SAN divalidasi alih-alih CN. Umumnya, karena SAN dapat berisi beberapa nilai, SAN memiliki domain utama/nama host untuk pemegang sertifikat serta domain alternatif apa pun.

Mengapa EdgeGateway perlu diberitahu tentang nama hostnya sendiri?

EdgeGateway tidak memiliki cara yang dapat diandalkan untuk mengetahui bagaimana klien lain di jaringan dapat terhubung ke sana. Misalnya, pada jaringan privat, mungkin ada server DHCP atau layanan mDNS yang mencantumkan EdgeGateway sebagai 10.0.0.2 atau example-mdns-hostname.local. Tapi, beberapa jaringan bisa memiliki server DNS yang memetakan edgegateway.local ke alamat 10.0.0.2IP EdgeGateway .

Untuk mengatasi masalah ini, IoT Edge menggunakan nilai nama host yang dikonfigurasi dan config.toml membuat sertifikat server untuknya. Ketika permintaan datang ke modul edgeHub , permintaan menyajikan sertifikat dengan nama umum sertifikat (CN) yang tepat.

Mengapa IoT Edge membuat sertifikat?

Dalam contoh, perhatikan ada edgegateway beban kerja iotedged dalam rantai sertifikat. Ini adalah otoritas sertifikat (CA) yang ada di perangkat IoT Edge yang dikenal sebagai Edge CA (sebelumnya dikenal sebagai CA Perangkat di versi 1.1). Seperti CA akar Baltimore CyberTrust dalam contoh sebelumnya, CA Edge dapat mengeluarkan sertifikat lain. Yang paling penting, dan juga dalam contoh ini, ia mengeluarkan sertifikat server ke modul edgeHub . Tetapi, ini juga dapat mengeluarkan sertifikat ke modul lain yang berjalan di perangkat IoT Edge.

Penting

Secara default tanpa konfigurasi, Edge CA secara otomatis dihasilkan oleh runtime modul IoT Edge saat dimulai untuk pertama kalinya, yang dikenal sebagai quickstart Edge CA, dan kemudian mengeluarkan sertifikat ke modul edgeHub . Proses ini mempercepat koneksi perangkat hilir dengan memungkinkan edgeHub menyajikan sertifikat valid yang ditandatangani. Tanpa fitur ini, Anda harus membuat CA Anda mengeluarkan sertifikat untuk modul edgeHub . Menggunakan MULAI cepat yang dihasilkan secara otomatis, Edge CA tidak didukung untuk digunakan dalam produksi. Untuk informasi selengkapnya tentang mulai cepat Edge CA, lihat Mulai Cepat Edge CA.

Bukankah berbahaya untuk memiliki sertifikat pengeluar sertifikat pada perangkat?

Edge CA dirancang untuk mengaktifkan solusi dengan konektivitas terbatas, tidak dapat diandalkan, mahal, atau tidak ada tetapi pada saat yang sama memiliki peraturan atau kebijakan yang ketat tentang perpanjangan sertifikat. Tanpa Edge CA, IoT Edge - dan khususnya edgeHub - tidak dapat berfungsi.

Untuk mengamankan CA Edge dalam produksi:

  • Letakkan kunci privat EdgeCA dalam modul platform tepercaya (TPM), sebaiknya dengan cara di mana kunci privat dibuat secara sementara dan tidak pernah meninggalkan TPM.
  • Gunakan Infrastruktur Kunci Umum (PKI) tempat CA Edge digulung. Ini memberikan kemampuan untuk menonaktifkan atau menolak perpanjangan sertifikat yang disusupi. PKI dapat dikelola oleh IT pelanggan jika mereka memiliki tahu bagaimana (biaya yang lebih rendah) atau melalui penyedia PKI komersial.

Kekhususan CA akar yang ditandatangani sendiri

Modul edgeHub adalah komponen penting yang membentuk IoT Edge dengan menangani semua lalu lintas masuk. Dalam contoh ini, ia menggunakan sertifikat yang dikeluarkan oleh Edge CA, yang pada gilirannya dikeluarkan oleh CA akar yang ditandatangani sendiri. Karena OS akar tidak dipercaya oleh OS, satu-satunya cara TempSensor mempercayainya adalah dengan menginstal sertifikat CA ke perangkat. Ini juga dikenal sebagai skenario bundel kepercayaan, di mana Anda perlu mendistribusikan akar kepada klien yang perlu mempercayai rantai. Skenario bundel kepercayaan dapat merepotkan karena Anda memerlukan akses perangkat dan menginstal sertifikat. Menginstal sertifikat memerlukan perencanaan. Ini dapat dilakukan dengan skrip, ditambahkan selama manufaktur, atau pra-instal dalam gambar OS.

Catatan

Beberapa klien dan SDK tidak menggunakan penyimpanan akar tepercaya OS dan Anda perlu meneruskan file CA akar secara langsung.

Menerapkan semua konsep ini, TempSensor dapat memverifikasi bahwa mereka berkomunikasi dengan EdgeGateway asli karena menyajikan sertifikat yang cocok dengan alamat dan sertifikat ditandatangani oleh akar tepercaya.

Untuk memverifikasi rantai sertifikat, Anda dapat menggunakan openssl pada perangkat TempSensor . Dalam contoh ini, perhatikan bahwa nama host untuk koneksi cocok dengan CN sertifikat kedalaman 0 , dan bahwa CA akar cocok.

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

Untuk mempelajari selengkapnya tentang openssl perintah, lihat dokumentasi OpenSSL.

Anda juga dapat memeriksa sertifikat tempat sertifikat disimpan secara default di /var/lib/aziot/certd/certs. Anda dapat menemukan sertifikat CA Edge, sertifikat identitas perangkat, dan sertifikat modul di direktori. Anda dapat menggunakan openssl x509 perintah untuk memeriksa sertifikat. Contohnya:

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

Singkatnya, TempSensor dapat mempercayai EdgeGateway karena:

  • Modul edgeHub menunjukkan sertifikat server modul IoT Edge yang valid untuk edgegateway.local
  • Sertifikat dikeluarkan oleh Edge CA yang dikeluarkan oleh my_private_root_CA
  • CA akar privat ini juga disimpan di TempSensor sebagai CA akar tepercaya sebelumnya
  • Algoritma kriptografi memverifikasi bahwa kepemilikan dan rantai penerbitan dapat dipercaya

Sertifikat untuk modul lain

Modul lain bisa mendapatkan sertifikat server yang dikeluarkan oleh Edge CA. Misalnya, modul Grafana yang memiliki antarmuka web. Ini juga bisa mendapatkan sertifikat dari Edge CA. Modul diperlakukan sebagai perangkat hilir yang dihosting dalam kontainer. Namun, mampu mendapatkan sertifikat dari runtime modul IoT Edge adalah hak istimewa khusus. Modul memanggil API beban kerja untuk menerima sertifikat server yang dirantai ke CA Edge yang dikonfigurasi.

Gateway memverifikasi identitas perangkat

Bagaimana EdgeGateway memverifikasi bahwa EdgeGateway berkomunikasi dengan TempSensor? EdgeGateway menggunakan autentikasi klien TLS untuk mengautentikasi TempSensor.

Diagram urutan memperlihatkan pertukaran sertifikat dari perangkat IoT Edge ke gateway dengan verifikasi pemeriksaan sertifikat dari sertifikat IoT Hub.

Urutannya mirip dengan ContosoIotHub yang memverifikasi perangkat. Namun, dalam skenario gateway, EdgeGateway mengandalkan ContosoIotHub sebagai sumber kebenaran untuk catatan sertifikat. EdgeGateway juga menyimpan salinan atau cache offline jika tidak ada koneksi ke cloud.

Tip

Tidak seperti perangkat IoT Edge, perangkat IoT hilir tidak terbatas pada autentikasi Thumbprint X.509. Autentikasi CA X.509 juga merupakan opsi. Alih-alih hanya mencari kecocokan pada thumbprint, EdgeGateway juga dapat memeriksa apakah sertifikat TempSensor berakar dalam CA yang telah diunggah ke ContosoIotHub.

Singkatnya, EdgeGateway dapat mempercayai TempSensor karena:

  • TempSensor menyajikan sertifikat identitas perangkat IoT yang valid untuk namanya
  • Thumbprint sertifikat identitas cocok dengan yang diunggah ke ContosoIotHub
  • Algoritma kriptografi memverifikasi bahwa kepemilikan dan rantai penerbitan dapat dipercaya

Tempat mendapatkan sertifikat dan manajemen

Dalam kebanyakan kasus, Anda dapat memberikan sertifikat Anda sendiri atau menggunakan pada sertifikat yang dibuat secara otomatis. Misalnya, CA Edge dan sertifikat edgeHub dibuat secara otomatis.

Namun, praktik terbaiknya adalah mengonfigurasi perangkat Anda untuk menggunakan pendaftaran melalui server Secure Transport (EST) untuk mengelola sertifikat x509. Menggunakan server EST membebaskan Anda dari penanganan sertifikat secara manual dan menginstalnya di perangkat. Untuk informasi selengkapnya tentang menggunakan server EST, lihat Mengonfigurasi Pendaftaran melalui Secure Transport Server untuk Azure IoT Edge.

Anda juga dapat menggunakan sertifikat untuk mengautentikasi ke server EST. Sertifikat ini digunakan untuk mengautentikasi dengan server EST untuk menerbitkan sertifikat lain. Layanan sertifikat menggunakan sertifikat bootstrap untuk mengautentikasi dengan server EST. Sertifikat bootstrap berumur panjang. Setelah autentikasi awal, layanan sertifikat membuat permintaan ke server EST untuk menerbitkan sertifikat identitas. Sertifikat identitas ini digunakan dalam permintaan EST di masa mendatang ke server yang sama.

Jika Anda tidak dapat menggunakan server EST, Anda harus meminta sertifikat dari penyedia PKI Anda. Anda dapat mengelola file sertifikat secara manual di IoT Hub dan perangkat IoT Edge Anda. Untuk informasi selengkapnya, Kelola sertifikat pada perangkat IoT Edge.

Untuk bukti pengembangan konsep, Anda dapat membuat sertifikat pengujian. Untuk informasi selengkapnya, lihat Membuat sertifikat demo untuk menguji fitur perangkat IoT Edge.

Sertifikat dalam IoT

Otoritas sertifikat

Otoritas sertifikat (CA) adalah entitas yang mengeluarkan sertifikat digital. Otoritas sertifikat bertindak sebagai pihak ketiga tepercaya antara pemilik dan penerima sertifikat. Sertifikat digital menyatakan kepemilikan kunci umum oleh penerima sertifikat. Rantai sertifikat kepercayaan bekerja dengan terlebih dahulu mengeluarkan sertifikat akar, yang merupakan dasar kepercayaan pada semua sertifikat yang diterbitkan oleh otoritas. Pemilik sertifikat akar kemudian dapat mengeluarkan sertifikat perantara tambahan (sertifikat perangkat hilir).

Sertifikat OS Akar

Sertifikat OS akar adalah akar kepercayaan dari seluruh proses. Dalam skenario produksi, sertifikat CA ini dibeli dari otoritas sertifikat komersial tepercaya seperti Baltimore, Verisign, atau DigiCert. Jika Anda memiliki kontrol penuh atas perangkat yang terhubung ke perangkat IoT Edge Anda, Anda dapat menggunakan otoritas sertifikat tingkat perusahaan. Dalam salah satu peristiwa, seluruh rantai sertifikat dari IoT Edge ke IoT Hub menggunakannya. Perangkat IoT hilir harus mempercayai sertifikat akar. Anda dapat menyimpan sertifikat OS akar baik di penyimpanan otoritas sertifikat akar tepercaya, atau memberikan detail sertifikat dalam kode aplikasi Anda.

Sertifikat perantara

Dalam proses produksi yang khas untuk membuat perangkat yang aman, sertifikat OS akar jarang digunakan secara langsung, terutama karena risiko kebocoran atau paparan. Sertifikat OS akar membuat dan menandatangani secara digital satu atau beberapa sertifikat OS perantara. Mungkin hanya ada satu, atau mungkin ada rantai sertifikat perantara ini. Skenario yang memerlukan rantai sertifikat perantara meliputi:

  • Hierarki departemen dalam produsen
  • Beberapa perusahaan terlibat secara serial dalam produksi perangkat
  • Pelanggan yang membeli CA akar dan memperoleh sertifikat penandatanganan bagi produsen untuk menandatangani perangkat yang mereka buat atas nama pelanggan tersebut

Bagaimanapun, produsen menggunakan sertifikat OS perantara di akhir rantai ini untuk menandatangani sertifikat OS tepi yang ditempatkan di perangkat akhir. Sertifikat perantara ini dijaga ketat di pabrik manufaktur. Sertifikat ini menjalani proses yang ketat, baik secara fisik maupun elektronik, untuk penggunaannya.

Langkah berikutnya