Memfasilitasi penyediaan IoT dalam skala besar
Baik Anda ingin merancang perangkat baru atau memasang kembali perangkat yang ada untuk IoT, Anda perlu mempertimbangkan penyediaan IoT yang membawa perangkat IoT online ke layanan cloud. Desain penyediaan IoT memerlukan pengambilan keputusan yang memengaruhi pengalaman dan keamanan pengguna untuk komisioning jaringan dan mekanisme penyediaan kredensial yang mengonfigurasi identitas digital, titik akhir cloud, dan kredensial jaringan sehingga perangkat dapat terhubung dengan aman ke cloud.
Untuk melakukan penyediaan IoT dalam skala besar, pelanggan sering kali membuat dan memelihara alat dan aplikasi perangkat lunak yang dibuat khusus yang dapat mendorong kredensial yang diperlukan melalui protokol yang didukung oleh perangkat mereka yang mencakup beberapa domain masalah. Domain penyediaan IoT meliputi:
- Pengaturan jaringan, yang menyediakan mekanisme bagi pelanggan untuk menentukan parameter khusus konteks;
- Penyediaan kredensial, yang memberikan kredensial dan konfigurasi ke perangkat fisik; dan
- Penyediaan cloud, yang menyetel data konfigurasi sisi cloud yang memungkinkan autentikasi, otorisasi, dan pengelolaan perangkat.
Ketiga domain penyediaan ini harus bekerja secara harmonis untuk pengalaman pengguna pelanggan yang spektakuler.
Misalnya, operator seluler menyediakan data konfigurasi dan pengaturan kebijakan saat pengguna ponsel terhubung untuk pertama kalinya. Ini adalah proses yang sederhana dan dipahami dengan baik yang tidak memakan banyak waktu bagi pengguna perangkat seluler di mana kartu SIM mewakili identitas perangkat. Situasi menjadi sangat berbeda dan menantang bagi pelanggan, terutama produsen peralatan asli (OEM), yang mencoba menyediakan jutaan perangkat IoT.
Sepanjang artikel ini, Anda akan dapat mempelajari cara menghindari atau mengurangi risiko yang terkait dengan penerapan IoT Anda sendiri serta memahami, melalui contoh singkat, bagaimana layanan IoT yang disediakan melalui platform cloud seperti Amazon Web Services (AWS) membantu Anda mencapai tujuan penyediaan IoT Anda.
Mendekati komisioning jaringan saat dibutuhkan
Akhirnya, perangkat IoT Anda terhubung dan berkomunikasi dengan layanan pusat yang merupakan pusat dari solusi IoT Anda. Untuk mencapai hub itu, perangkat IoT Anda harus bergabung dengan media jaringan. Medianya bisa berupa kabel keras, seperti Ethernet, atau transmisi radio, seperti Wi-Fi. Tergantung pada medianya, Anda memerlukan manusia untuk memberi tahu perangkat media apa yang harus digabungkan agar berhasil mencapai hub. Misalnya, dengan seluler Anda tidak perlu memberi tahu perangkat jaringan untuk bergabung karena ini telah ditentukan oleh kartu SIM. Di sisi lain, untuk bergabung dengan jaringan Wi-Fi, Anda perlu mengetahui nama dan kata sandi Titik Akses Wi-Fi dan dapat memberi tahu perangkat detail ini. Kami akan fokus pada perangkat yang memerlukan konfigurasi untuk bergabung dengan jaringan.
Ada beberapa mekanisme berbeda yang digunakan pelanggan untuk bergabung dengan jaringan IoT. Hampir setiap orang memiliki smartphone saat ini dan hampir setiap smartphone memiliki Bluetooth, jadi konfigurasi melalui Bluetooth telah meluas. Namun, itu bukan satu-satunya cara untuk terhubung. Beberapa modul Wi-Fi pada perangkat IoT cukup pintar untuk menjadi titik akses tersendiri, di mana Anda dapat mengembangkan halaman web sederhana yang memungkinkan pengguna memasukkan konfigurasi jaringan yang lebih besar. Untuk perangkat non-konsumen, masih umum untuk mengonfigurasi melalui serial atau microSD. Konfigurasi Bluetooth dengan bantuan aplikasi smartphone sudah menjadi hal biasa. Aplikasi ponsel cerdas ini juga dapat memberikan bantuan untuk penyediaan cloud perangkat yang akan Anda temukan nanti di artikel ini.
Pendekatan pada penyediaan kredensial perangkat dalam skala besar
Proses penyediaan kredensial perangkat terus menjadi sangat terfragmentasi di seluruh industri tanpa garis pandang untuk konvergensi dalam waktu dekat. Sebagian besar sistem terpusat IoT sangat menyarankan, atau memerlukan, koneksi Transport Layer Security (TLS) 1.2 untuk transportasi terenkripsi, yang baru-baru ini, dan mungkin secara fasih, dikenal sebagai enkripsi dalam perjalanan. Saat ini, sebagian besar penerapan IoT menggunakan Infrastruktur Kunci Publik (PKI) sehingga sisa artikel ini mengasumsikan penggunaan PKI. Bagaimanapun, sangat penting bahwa setiap perangkat memiliki Kunci Pribadi dan Sertifikat pengidentifikasi uniknya sendiri.
Untuk membuat sesi dengan cloud (atau titik akhir layanan), TLS 1.2 memerlukan Kunci Pribadi dan sertifikat (atau kredensial) x.509. Catatan:Beberapa teknik seperti Java Web Tokens, atau JWT, memiliki tantangan serupa tetapi tidak akan dibahas di sini. Kunci Pribadi, yang seperti DNA Anda, hanya boleh diketahui oleh perangkat individu yang berarti tidak boleh dibagikan dengan perangkat lain. Sertifikat x.509, yang seperti SIM, dikeluarkan oleh Otoritas Sertifikat (CA) yang dapat diverifikasi dengan memberikan Permintaan Penandatanganan Sertifikat (CSR). Menyampaikan CSR tidak jauh berbeda dengan menyerahkan akta kelahiran Anda kepada entitas penerbit paspor negara Anda dengan sidik jari dan bukti tes lulus lainnya sebagai bukti untuk menerima paspor. Sepanjang artikel ini, kami mengacu pada sertifikat x.509 sebagai kredensial, dengan asumsi bahwa perangkat memiliki Kunci Pribadi yang unik.
Detail TLS 1.2 berada di luar cakupan artikel ini, tetapi kami hanya akan memberi Anda informasi yang cukup untuk mendapat sedikit informasi sehingga Anda dapat memahami mengapa perangkat harus melindungi Kunci Pribadi. Selama proses koneksi TLS 1.2, terjadi serangkaian pertukaran untuk membuktikan bahwa perangkat adalah pemilik Private Key yang menjadi identitasnya. Perangkat Anda harus membuktikan bahwa itu adalah pemilik sebenarnya dari sertifikat x.509 yang coba digunakan untuk otentikasi. Agar layanan IoT memercayai kredensial perangkat saat perangkat Anda terhubung, Anda harus memiliki Kunci Pribadi itu. Sekarang Anda dapat menyadari bahwa jika aktor jahat memegang kunci itu, model keamanannya akan berantakan. Bagaimanapun caranya, lindungi kunci kastil IoT Anda!
Seperti kebanyakan orang yang menerapkan IoT, Anda harus membuat keputusan tentang cara menyediakan kredensial ini dalam skala besar. Untuk meninjau secara singkat, setiap perangkat harus memiliki:
- Kunci Pribadi unik yang tidak dapat diubah yang mewakili perangkat. Idealnya, untuk melindungi dari serangan berdampingan dan serangan lanjutan lainnya, Kunci Pribadi harus dilindungi secara fisik dan tidak dapat dimuat ke dalam memori program utama.
- Kredensial, terkait dengan aplikasi atau layanan IoT Anda.
Logistik berbeda di antara pilihan untuk Private Key dan penyediaan kredensial, beberapa di antaranya terpisah dari penyediaan cloud dan lainnya bergantung pada penyediaan cloud.
- Modul keamanan sirkuit terpadu (yang biasanya memiliki kemampuan kriptografi), baik yang berdiri sendiri atau berpartisipasi dalam desain System-In-Package (SiP), System-On-Module (SoM), atau System-On-Chip (SoC), memiliki salah satu perilaku berikut:
- Modul keamanan yang memiliki Kunci Pribadi yang disediakan secara manual atau dibuat sendiri, atau akar kepercayaan.
- Selain item sebelumnya, modul keamanan menyediakan kredensial dalam bentuk sertifikat x.509 yang telah disediakan sebelumnya.
- Teknologi Subscriber Identity Module (SIM), embedded-SIM (eSIM), dan integrated SIM (iSIM) menyediakan perangkat keras yang digunakan desainer sebagai identitas seluler untuk berkomunikasi dengan jaringan seluler. Penyediaan kredensial biasanya bergantung pada penyedia Operator Jaringan Seluler (MNO), Penyedia Jaringan Virtual Seluler (MVNO), atau pihak ketiga. Jika Anda menggunakan modul seluler untuk komunikasi, ini adalah pilihan Anda.
- Penyediaan kredensial perangkat otomatis yang disesuaikan untuk segmen flash perangkat, yang dapat memiliki flash aman khusus, bersama dengan Hardware Security Module (HSM) selama pembuatan.
- Penyediaan Kunci Pribadi dan kredensial secara manual ke flash aman khusus (atau flash tidak aman, biasanya selama pembuatan prototipe tetapi tidak disarankan untuk penyediaan armada).
Eksekusi TLS 1.2 adalah aktivitas komputasi intensif karena persyaratan kriptografi, yang pada gilirannya memengaruhi pilihan komponen komputasi, terutama jika Anda menggunakan mikrokontroler untuk desain Anda. IC khusus biasanya menyertakan rutinitas kriptografi, yang membebaskan prosesor host dari penerapan siklus pada operasi TLS 1.2 sambil memastikan bahwa Kunci Pribadi tidak dimuat ke memori utama.
Pendekatan yang Anda ambil untuk perangkat keras tergantung pada desain perangkat keras Anda. Memilih solusi elegan untuk desain perangkat keras tentu saja menyederhanakan penyediaan dalam skala besar, tetapi memerlukan pemilihan komponen di awal siklus hidup desain perangkat keras karena hal itu memengaruhi pilihan desain komponen lain untuk komputasi, modul kriptografi, pemrosesan bersama matematika, dan flash. Tentu saja, untuk perangkat dalam skala besar, Anda tidak akan ingin menyediakan secara manual, dan tren menyarankan perangkat yang telah disediakan sebelumnya menghasilkan sedikit gesekan dari perspektif manufaktur, operasi, dan pengalaman pelanggan.
Penyediaan perangkat IoT memerlukan cloud dan orkestrasi perangkat
Penyediaan perangkat IoT yang berhasil memerlukan orkestrasi penyediaan perangkat dan cloud yang memengaruhi desain perangkat keras dan perangkat lunak serta cara Anda mengelola perangkat di sepanjang siklus hidup perangkat.
Dari perspektif layanan IoT, Anda akan memerlukan proses yang selaras dengan pilihan penyediaan kredensial Anda untuk membuat objek konfigurasi terkait. Saat perangkat terhubung ke layanan IoT, layanan IoT harus dapat mengenali perangkat (otentikasi), mengaktifkan tindakan perangkat tertentu (otorisasi), dan mengoperasikan serta mengelola perangkat dalam konteks tertentu (manajemen perangkat).
Untuk otentikasi, layanan IoT harus memiliki sidik jari kredensial sehingga ketika perangkat terhubung dan mengirimkan kredensial ke layanan IoT, layanan IoT dapat menghubungkan koneksi fisik dengan objek konfigurasi. Untuk AWS IoT, Anda mendaftarkan kredensial Anda yang memungkinkan layanan IoT mengenali koneksi masuk. Jabat tangan TLS, yang mengharuskan perangkat memiliki akses ke Kunci Pribadi (yang tidak dimiliki layanan IoT) memastikan bahwa kredensial telah dikirim dari perangkat dengan Kunci Pribadi. Inilah mengapa sangat penting untuk melindungi Kunci Pribadi di perangkat.
Untuk otorisasi, layanan IoT harus menerapkan aturan ke koneksi yang memberikan akses layanan IoT minimum. Akses layanan IoT minimum berarti menetapkan batasan perangkat untuk hanya menggunakan sumber daya yang dibutuhkan untuk memenuhi kewajiban operasionalnya. Misalnya, pelanggan AWS membuat Kebijakan IoT yang terkait dengan objek konfigurasi kredensial.
Untuk pengelolaan perangkat, Anda perlu menerapkan metadata ke objek konfigurasi untuk menentukan grup atau agregasi perangkat, atau armada dengan jelas. Dengan IoT, kita perlu mengelola ribuan, puluhan ribu, dan jutaan perangkat. Akan tidak praktis untuk mengelola setiap perangkat satu per satu. Rencanakan sebelumnya untuk menerapkan metadata ke konfigurasi perangkat Anda karena perkuatan atau pemfaktoran ulang bisa jadi menyakitkan. Untuk AWS IoT, Anda membuat objek konfigurasi Thing Type dan Thing Group yang mendorong praktik Manajemen Perangkat IoT.
Pendekatan pada penyediaan cloud perangkat dalam skala besar
Tidak dapat dikatakan bahwa setiap Penerapan IoT berbeda dalam hal penyediaan perangkat, tetapi ada cukup diferensiasi di seluruh vendor perangkat keras, aplikasi IoT, dan konteks operasional untuk mendorong serangkaian mekanisme yang kuat yang akan memengaruhi keputusan Anda tentang mekanisme yang tepat untuk Anda. Secara umum, ada tiga pendekatan:pendaftaran massal, pendaftaran sesuai permintaan, dan pendaftaran malas. Semua metode berikut mengharapkan bahwa setiap perangkat IoT memiliki, atau akan memiliki, pasangan Kunci Pribadi dan Sertifikat yang unik.
Pendaftaran massal
Dengan pendaftaran massal, kumpulan kredensial yang ingin Anda daftarkan dengan layanan IoT diketahui sebelum penerapan perangkat ke lapangan. Setelah daftar kredensial diperoleh, Anda kemudian menyalurkan kredensial ke proses pendaftaran massal. Proses pendaftaran massal mendaftarkan kredensial dan kemudian juga mengoordinasikan kredensial dengan objek manajemen terkait di layanan IoT yang Anda gunakan untuk mengelola armada IoT Anda. Pendaftaran massal mungkin memerlukan penyesuaian tetapi penyedia layanan IoT biasanya menyediakan proses pendaftaran massal kepada pelanggan. Misalnya, AWS menyediakan proses pendaftaran Massal AWS IoT sebagai bagian dari layanan AWS IoT Core dan pemrosesan kustom menggunakan AWS SDK. Proyek sumber terbuka bernama ThingPress menangani kasus penggunaan impor tertentu.
Pendaftaran sesuai permintaan
Dengan pendaftaran perangkat sesuai permintaan, kumpulan perangkat fisik dengan kredensial yang dipasangkan tidak akan Anda ketahui sebelum penerapan perangkat ke lapangan. Setelah perangkat dikerahkan ke lapangan, Anda akan menghidupkan perangkat. Dengan permintaan, subrutin konektivitas menentukan apakah referensi ke penerbit kredensial telah didaftarkan ke layanan IoT. Selama layanan IoT memiliki mekanisme yang kuat untuk memverifikasi bahwa Anda sebenarnya adalah pemilik penerbit, yang berarti Anda memiliki identitas penerbit (dalam PKI, Private Key penerbit), Anda dapat yakin bahwa penerbit memberikan kredensial. Kemudian subrutin secara otomatis mendaftarkan kredensial dan membuat objek manajemen terkait. Misalnya, AWS memiliki dua mekanisme pendaftaran perangkat sesuai permintaan bernama Just-In-Time-Provisioning (JITP) yang menggunakan template penyediaan dan Just-In-Time-Registration (JITR) yang menyediakan mekanisme yang dapat disesuaikan sepenuhnya.
Pendaftaran malas
Dengan pendaftaran lambat, baik perangkat fisik maupun kredensial yang dipasangkan tidak diketahui sebelum diterapkan ke lapangan. Dalam hal ini, perangkat memiliki identitas yang diketahui dan tidak dapat diubah (biasanya, Kunci Pribadi yang dilindungi) yang dapat dikonfirmasi oleh layanan IoT tanpa mentransfer identitas pribadi di luar perangkat.
Saat ini, ada tiga mekanisme untuk pendaftaran lambat:berdasarkan klaim, berdasarkan perangkat seluler resmi, dan berdasarkan daftar identitas resmi. Dalam kasus pertama, perangkat mengirimkan klaim ke penerbit kredensial, penerbit merespons dengan token, dan perangkat menggunakan token untuk membuat panggilan API layanan web langsung untuk menerbitkan sertifikat. Dalam kasus kedua, perangkat bekerja bersama-sama dengan ponsel, di mana ponsel menggunakan kredensial seluler, seperti nama pengguna dan kata sandi, penerbit merespons dengan token, ponsel mengirim token ke perangkat, dan perangkat menggunakan token untuk melakukan panggilan API langsung. Dalam kasus ketiga, daftar resmi, yang dapat berupa daftar Kunci Publik, dan perangkat membuat panggilan API langsung ke layanan IoT dengan CSR. Kunci Publik yang berasal dari CSR kemudian dibandingkan dengan daftar resmi, dan kemudian memberikan sertifikat ke perangkat saat ada kecocokan. Misalnya, penyediaan Armada AWS menyediakan mekanisme penyediaan berbasis klaim dan ponsel cerdas, proyek open source IoT Provisioning Secret-Free menyediakan mekanisme pendaftaran lambat menggunakan klaim, dan mitra AWS 1nce memberikan pengalaman penyediaan seluler yang efisien melalui AWS Marketplace.
Memilih penyediaan perangkat yang tepat untuk Anda
Memilih penyediaan perangkat yang tepat untuk Anda berarti menemukan kredensial perangkat dan praktik penyediaan cloud perangkat yang selaras dengan desain perangkat keras, desain perangkat lunak, manufaktur, dan operasi siklus hidup perangkat Anda. Desain perangkat keras menentukan bagaimana Anda mendefinisikan dan menyimpan identitas perangkat individual dan file kredensial. Desain perangkat lunak mempengaruhi otorisasi perangkat. Manufaktur memengaruhi kondisi di mana rahasia akan dibuat dan disimpan, atau diidentifikasi, memengaruhi bagaimana sidik jari otorisasi direfleksikan ke dalam layanan IoT.
Bagaimana Anda memutuskan untuk melakukan penyediaan kredensial ke perangkat keras fisik, yang mencerminkan desain perangkat keras yang biasanya diputuskan jauh sebelumnya saat melakukan desain produk, menciptakan poros mendasar untuk jenis proses penyediaan cloud tertentu. Selanjutnya, jika Anda tidak melakukan manufaktur sendiri, maka Anda akan menggunakan produsen kontrak untuk membangun produk Anda. Manufaktur kontrak memiliki banyak manfaat, tetapi banyak aspek dari proses manufaktur tidak akan berada dalam kendali Anda, yang mencakup pembuatan rahasia perangkat seperti kunci pribadi dan sertifikat di jalur produksi. Risiko seperti kelebihan produksi, kloning, dan vektor serangan lainnya dapat secara langsung berhubungan dengan produsen kontrak yang sedang disewa, yang berarti Anda harus memiliki banyak kepercayaan untuk tidur nyenyak di malam hari.
Jika Anda tidak mengelola CA pribadi untuk armada IoT Anda, kredensial yang telah disediakan sebelumnya mungkin cocok untuk Anda. Kredensial yang disediakan sebelumnya mungkin memerlukan biaya tambahan di muka, tetapi kami telah melihat bahwa kredensial tersebut secara signifikan mengurangi biaya operasional. Jika Anda perlu mengelola CA pribadi Anda sendiri, maka beberapa perusahaan perangkat keras memberikan kredensial yang telah disediakan sebelumnya di mana konfigurasi dilakukan pada tape-out, yang berarti produsen kontrak tidak akan mengetahui rahasia pada perangkat. Jika tidak, Anda mungkin ingin condong ke penyediaan gaya malas di mana perangkat memiliki Kunci Pribadi yang tidak dapat diubah atau Kunci Pribadi yang dihasilkan sendiri yang dapat direproduksi` pada perangkat dan dapat berpartisipasi dengan layanan IoT untuk memiliki kredensial yang diterapkan setelah beberapa tingkat pengesahan. Jika Anda berada dalam situasi yang tidak menguntungkan karena tidak memiliki Kunci Pribadi yang tidak dapat diubah pada perangkat, maka Anda masih dapat menyediakan Kunci Pribadi dan kredensial langsung ke flash, tetapi ini sangat tidak disarankan.
Berbeda dengan desain perangkat keras, desain perangkat lunak lebih fleksibel dan dapat berubah sepanjang pengembangan perangkat dan bahkan siklus hidup (pikirkan Pembaruan Firmware Over-The-Air). Setiap kali Anda mengirimkan kumpulan perangkat baru ke pelanggan, Anda harus bersandar pada proses penyediaan cloud perangkat. Seperti desain perangkat lunak, desain penyediaan mungkin memerlukan fleksibilitas berdasarkan kebutuhan perangkat lunak Anda yang terus berkembang. Luasnya konfigurasi dan penyesuaian yang diperlukan mendorong proses penyediaan cloud perangkat yang akan Anda gunakan saat menerapkan armada perangkat baru atau tambahan.
Persyaratan operasi siklus hidup perangkat akan mendorong tingkat fleksibilitas yang akan diperlukan untuk penyediaan cloud perangkat. Lebih khusus lagi, sementara sebagian besar proses untuk penyediaan cloud perangkat AWS IoT memungkinkan pembuatan otomatis objek manajemen seperti Jenis Hal dan Grup Hal, jika proses Anda juga memerlukan interoperabilitas khusus selama waktu pendaftaran, Anda mungkin ingin mempertimbangkan Just-In-Time- Penyediaan yang memungkinkan penyesuaian lebih dalam.
Terakhir, saat melihat siklus hidup perangkat, pertimbangkan peluang perangkat untuk mengubah pemilik manusia sepanjang kegunaannya. Meskipun identitas perangkat dalam hal Kunci Pribadi mungkin tidak berubah, ada peluang untuk tidak menggunakan Sertifikat pemilik sebelumnya untuk memindahkan perangkat ke "kondisi pabrik". Ketika pemilik manusia baru menugaskan perangkat ke jaringan baru dan menyediakan mungkin menggunakan aplikasi seluler, Sertifikat baru mungkin perlu disediakan pada saat itu. Mekanika siklus hidup kemudian perlu melengkapi persyaratan tersebut.
Kesimpulan
Sepanjang artikel ini, kami membahas situasi penyediaan IoT yang mungkin Anda saksikan hari ini. Demikian pula, Anda telah menyaksikan bahwa ada banyak pilihan tergantung pada apa yang ingin Anda capai dan hasil yang Anda inginkan untuk dinikmati pelanggan Anda. Seperti semuanya, keamanan mendukung penyediaan, yang dimulai dengan setiap perangkat memiliki kunci pribadi dan pasangan Sertifikat yang unik dan dapat diidentifikasi. Pendekatan penyediaan kredensial yang Anda pilih menciptakan titik pivot itu untuk pilihan penyediaan cloud perangkat Anda. Jika Anda membuat desain baru, Anda akan ingin melihat dengan seksama solusi keamanan perangkat keras seperti elemen aman dan enklave aman, yang pada gilirannya menyederhanakan penyediaan perangkat cloud. Jika Anda mengembangkan atau mengerjakan ulang desain yang sudah ada, pilihan Anda mungkin tampak jauh lebih terbatas, tetapi masih ada opsi bagi Anda untuk menghubungkan perangkat Anda dalam kapasitas IoT. Terakhir, melalui contoh dan anekdot, Anda dapat menyaksikan bahwa AWS IoT telah menghadirkan solusi penyediaan cloud perangkat yang cocok dengan solusi mitra silikon kami. Sekarang saatnya untuk membangun perangkat IoT yang dipesan dan disediakan dengan aman!
