IoT cihazlarının veri iletim protokolleri nasıl çalışıyor ve güvenliği nasıl sağlanıyor?

24 Tem 00:34

MQTT, CoAP ve HTTP’yi kıyaslarken doğrudan bant genişliği ve enerji tüketimiyle ilgilenmek gerekir. MQTT, publish/subscribe modeliyle çok hafif bir başlık (header) yapısına sahip, genelde 1‑2 KB'lık paketler gönderir; bu yüzden düşük veri oranlı, batarya sınırlı sensörlerde tercih edilir. CoAP ise UDP tabanlı, “confirmable” mesajlarla güvenilirlik sağlamaya çalışır ama hâlâ HTTP’ye göre daha az overhead (yaklaşık 10‑20 B) taşır; özellikle 2‑4 bytes’lık token’ları sayesinde çok sık mesajlaşma senaryolarında enerji tasarrufu sağlar. HTTP ise TCP ve geniş başlıklarıyla daha ağırdır, sık sık 300‑500 B ek yük getirir; bu da yüksek veri akışı veya sıkı güvenlik (örneğin OAuth) gerektiğinde mantıklıdır, ama batarya ömrü kritik olduğunda pek uygun değildir. Güvenlik konusuna gelince, TLS (TLS 1.2/1.3) en çok MQTT ve CoAP’da tercih edilen koruma katmanıdır. TLS, hem veri şifrelemesi (AES‑256‑GCM gibi) hem de sunucu‑istemci kimlik doğrulamasını (X.509 sertifikaları) sağlayarak "man‑in‑the‑middle" saldırılarını büyük ölçüde engeller. MQTT’de “username/password” kombinasyonu basit bir auth çözümü olsa da, sertifika tabanlı kimlik doğrulama (mutual TLS) en temkinli yaklaşımdır. CoAP’da DTLS (UDP‑TLS) aynı işlevi görür, fakat bazı düşük‑power cihazlarda DTLS handshake maliyeti yüksek olabilir; bu durumda PSK (pre‑shared key) ya da raw public key kullanmak pratik bir alternatif. HTTP’de ise HTTPS zaten TLS’i içerir; ek olarak HMAC‑based token’lar (JWT) ya da OAuth2.0 gibi katmanlar oturum güvenliğini artırır. Uygulamalarda en yaygın güvenlik açıkları genelde sertifika yönetiminin eksikliği, varsayılan şifrelerin korunamaması ve firmware güncellemelerinin imzasız yayınlanmasıdır. Kanka, “default credentials” hâlâ IoT cihazlarda büyük bir sorun; cihazı ilk kurduğunuzda admin/12345 gibi şifreyi hemen değiştirin. Ayrıca, TLS/DTLS handshake’ini zorlayan “session renegotiation” ya da “heartbeat” gibi ekstra paketler saldırganların denial‑of‑service (DoS) tetiklemesine yol açabilir; bu yüzden timeout ve rate‑limit ayarlarını düşük tutmak kritik. Firmware imzası (örneğin RSA‑2048) ve OTA (over‑the‑air) güncellemelerinin sadece imzalı paketleri kabul etmesi, kötü amaçlı kod enjekte edilmesini önler. Sonuç olarak, protokol seçimi uygulamanın veri yoğunluğuna ve enerji kısıtlamasına göre yapılmalı, güvenlik ise “TLS/DTLS + güçlü kimlik doğrulama + sıkı güncelleme politikası” kombinasyonu ile sağlanmalı. Bence, her cihazda ayrı bir CA (certificate authority) kurup, sertifikaları periyodik olarak yenilemek, IoT altyapısının uzun vadeli dayanıklılığını artırır. Valla, bu adımları izlerseniz saldırı yüzeyini ciddi oranda küçültebilirsiniz.

24 Tem 01:20

我第一次用ESP8266做温湿度监测时，采用了MQTT+TLS的组合，虽然设备资源有限，但通过在Broker端配置客户端证书，成功防止了未授权的订阅和数据篡改；后来尝试CoAP时才发现，由于缺少成熟的TLS库，安全实现更麻烦，于是回到MQTT并开启消息加密，基本解决了我遇到的常见安全漏洞。