Cybersecurity untuk Perangkat IoT

Perangkat IoT di lingkungan industri sering kali dipasang sekali lalu dibiarkan bekerja selama bertahun-tahun. Sensor suhu di ruang boiler, gateway Modbus di panel MCC, atau data logger di gudang dingin biasanya tidak masuk dalam siklus patch rutin seperti laptop atau server. Justru di titik inilah risiko menumpuk: perangkat dengan firmware lama, kredensial default, dan kanal komunikasi tanpa enkripsi menjadi pintu masuk paling murah bagi penyerang ke jaringan operasional pabrik.

Artikel ini membahas cybersecurity untuk perangkat IoT dari sisi rekayasa perangkat — bukan sekadar daftar imbauan, tetapi keputusan desain yang perlu diambil sebelum PCB difabrikasi dan sebelum perangkat pertama dikirim ke lapangan.

Mengapa keamanan IoT industri berbeda dari keamanan IT biasa

Di dunia IT, prioritas umumnya mengikuti urutan kerahasiaan, integritas, lalu ketersediaan. Di dunia operasional (OT), urutannya cenderung terbalik: ketersediaan dan keselamatan proses lebih dulu. Konsekuensinya nyata:

• Jendela maintenance sangat sempit. Reboot gateway bisa berarti lini produksi berhenti, sehingga update tidak bisa dipaksakan kapan saja.
• Umur pakai panjang. Perangkat industri sering dipakai 7–10 tahun, jauh melampaui umur dukungan banyak pustaka perangkat lunak.
• Sumber daya terbatas. Mikrokontroler dengan RAM ratusan kilobita tidak bisa menjalankan agen keamanan seperti endpoint di PC.
• Akses fisik longgar. Perangkat berada di area produksi, gudang, atau lokasi terpencil yang tidak selalu terkunci.

Karena itu, keamanan harus dibangun ke dalam perangkat, bukan ditambahkan sebagai lapisan pengawas di atasnya.

Kerangka acuan yang dipakai: standar dan panduan yang benar-benar ada

Daripada membuat daftar kontrol sendiri, lebih aman bersandar pada kerangka yang sudah mapan dan bisa diaudit pihak ketiga:

Acuan	Cakupan	Kegunaan praktis
IEC 62443 (seri)	Keamanan sistem otomasi dan kendali industri	Model zona & conduit, tingkat keamanan (SL), persyaratan untuk komponen (62443-4-2) dan proses pengembangan (62443-4-1)
OWASP IoT Top 10	Kelemahan paling umum pada perangkat IoT	Checklist cepat saat review desain dan pengujian
ETSI EN 303 645	Baseline keamanan perangkat konsumen IoT	Aturan dasar: tanpa password default, kanal update aman, minimalkan permukaan serang
NIST SP 800-82	Panduan keamanan sistem kendali industri	Arsitektur jaringan dan segmentasi di sisi pabrik
ISO/IEC 27001	Sistem manajemen keamanan informasi	Tata kelola di sisi organisasi, bukan di perangkat

Tidak semua proyek perlu sertifikasi formal. Namun memetakan desain ke salah satu acuan ini membuat diskusi dengan tim IT klien lebih cepat, karena istilah dan ekspektasinya sama.

Lapisan pertama: secure boot dan rantai kepercayaan

Secure boot memastikan mikrokontroler atau SoC hanya mengeksekusi firmware yang tanda tangannya sah. Tanpa itu, penyerang dengan akses fisik singkat — atau dengan celah pada mekanisme update — dapat menanamkan firmware miliknya, dan seluruh kontrol di lapisan atas menjadi tidak bermakna.

Komponen yang biasanya dibutuhkan:

• Root of trust di ROM. Bootloader tahap pertama berada di memori yang tidak dapat ditulis ulang dan memverifikasi tahap berikutnya.
• Kunci publik tertanam pada perangkat. Umumnya di eFuse atau OTP memory, sehingga tidak bisa diganti setelah produksi.
• Tanda tangan digital firmware. ECDSA (mis. P-256) atau RSA-2048/3072, dengan kunci privat disimpan di HSM atau layanan penandatanganan, bukan di laptop developer.
• Anti-rollback counter. Mencegah penyerang memaksa perangkat kembali ke versi lama yang punya celah diketahui.
• Penonaktifan debug port di produksi. JTAG/SWD dan konsol serial yang terbuka adalah jalan pintas klasik untuk membaca firmware dan kunci.

Banyak SoC kelas industri sudah menyediakan primitif ini — misalnya ESP32 dengan secure boot v2 dan flash encryption, STM32 dengan TrustZone pada varian Cortex-M33, atau gateway Linux berbasis Arm dengan verified boot. Yang menentukan bukan ketersediaan fiturnya, tetapi apakah fitur itu benar-benar diaktifkan sebelum unit masuk produksi.

Lapisan kedua: enkripsi data saat transit dan saat diam

Data in transit

Standar praktisnya adalah TLS 1.2 atau TLS 1.3 untuk kanal berbasis TCP (MQTT over TLS, HTTPS) dan DTLS untuk kanal berbasis UDP (mis. CoAP). Beberapa hal yang sering terlewat:

• Verifikasi sertifikat server wajib aktif. Menonaktifkan validasi "supaya cepat jalan saat uji coba" adalah penyebab umum kerentanan yang lolos ke produksi.
• Autentikasi perangkat berbasis sertifikat klien (mTLS) lebih kuat daripada token statis yang sama untuk semua unit.
• Identitas unik per perangkat. Satu kredensial bersama untuk seratus unit berarti satu unit bocor sama dengan seratus unit bocor.
• Protokol legacy tetap butuh pembungkus. Modbus TCP, Profinet, dan banyak protokol OT lain tidak punya autentikasi bawaan; keamanannya bergantung pada segmentasi jaringan dan tunnel terenkripsi di sisi gateway.

Data at rest

Pada perangkat, ini berarti mengenkripsi partisi penyimpanan atau setidaknya wilayah yang memuat kredensial dan konfigurasi. Kunci sebaiknya berada di elemen aman — secure element atau TPM — sehingga tidak dapat diekstraksi dengan membaca flash secara langsung. Untuk perangkat yang menyimpan buffer data produksi saat jaringan terputus, enkripsi at rest mencegah data proses terbaca jika unit hilang atau dibongkar.

Lapisan ketiga: OTA update yang bertanda tangan dan bisa dibatalkan

Perangkat yang tidak bisa diperbarui dari jarak jauh akan menjadi utang teknis. Kerentanan pada pustaka TLS atau stack jaringan muncul secara rutin, dan mengirim teknisi ke puluhan lokasi untuk flash manual tidak realistis.

Desain OTA yang layak produksi mencakup:

• Paket firmware bertanda tangan, diverifikasi oleh perangkat sebelum diaktifkan — bukan hanya checksum, karena checksum tidak membuktikan asal.
• Skema dual-bank atau A/B partition dengan rollback otomatis bila image baru gagal boot atau gagal health check.
• Rollout bertahap. Mulai dari sekelompok kecil unit, pantau, baru perluas.
• Penjadwalan yang menghormati jadwal produksi, termasuk kemampuan menunda update sampai jendela maintenance.
• Kanal distribusi terenkripsi dan terautentikasi, serta katalog versi yang tercatat agar tim maintenance tahu apa yang berjalan di mana.

Bagaimana cara mengamankan perangkat IoT yang sudah terpasang di pabrik?

Untuk brownfield — perangkat lama yang tidak mendukung secure boot atau TLS — pendekatan realistis adalah membatasi eksposur, bukan mengganti semuanya sekaligus:

1. Inventarisasi dulu. Daftar perangkat, firmware, protokol, dan tujuan komunikasinya. Tanpa daftar ini, langkah berikutnya hanya dugaan.
2. Segmentasi jaringan. Pisahkan zona OT dari jaringan kantor, terapkan model zona dan conduit ala IEC 62443, dan tutup akses internet langsung dari perangkat lapangan.
3. Hapus kredensial default dan matikan layanan yang tidak dipakai (Telnet, FTP, web config terbuka).
4. Letakkan gateway aman di depan perangkat legacy untuk menerjemahkan protokol lama ke kanal terenkripsi.
5. Akses jarak jauh terkontrol. VPN dengan autentikasi multifaktor, bukan port forwarding ke PLC.
6. Pemantauan dan logging. Anomali pada trafik OT relatif mudah terdeteksi karena polanya berulang.
7. Rencana penggantian bertahap untuk perangkat yang benar-benar tidak dapat diamankan.

Keamanan sebagai proses, bukan status

Tidak ada perangkat yang "selesai diamankan". Yang bisa dilakukan adalah menurunkan peluang dan dampak insiden secara terukur, lalu mempertahankannya sepanjang umur pakai perangkat. Praktik pendukung yang perlu berjalan terus:

• Pemantauan kerentanan pada dependensi firmware, dibantu SBOM (software bill of materials) agar diketahui pustaka apa saja yang ikut dikirim.
• Threat modeling saat desain dan saat ada perubahan arsitektur.
• Pengujian keamanan: analisis statis, fuzzing pada parser protokol, dan bila diperlukan penetration testing oleh pihak ketiga.
• Rotasi kunci dan sertifikat, termasuk prosedur pencabutan bila satu unit dikompromikan.
• Prosedur respons insiden yang jelas: siapa memutuskan isolasi zona, siapa menghubungi pemilik proses.

Biaya menambahkan kontrol ini pada tahap desain jauh lebih kecil dibanding menambalnya setelah ribuan unit tersebar. Keputusan seperti memilih SoC dengan secure element atau merancang partisi A/B hampir tidak mungkin dipasang belakangan tanpa revisi perangkat keras.

Diskusikan kebutuhan keamanan perangkat Anda

Jika Anda sedang merancang perangkat IoT baru atau meninjau keamanan sistem yang sudah berjalan, kami dapat membantu memetakan permukaan serang, menilai kesesuaian desain terhadap acuan seperti IEC 62443 dan OWASP IoT Top 10, serta menyusun opsi teknis beserta konsekuensi biaya dan jadwalnya. Hubungi tim Afratron untuk sesi diskusi teknis awal mengenai kebutuhan spesifik di lingkungan produksi Anda.