MQTT Filoları için Güvenli IoT Cihaz Provizyonu

Güvenli IoT cihaz provizyonu, her cihaza benzersiz bir kimlik ve MQTT broker'ınıza ulaşmak için ihtiyaç duyduğu kimlik bilgilerini, bu sırlar yol boyunca sızmadan verme sürecidir. Bu rehber ana provizyon modellerini karşılaştırıyor, pratik bir bootstrap akışını adım adım anlatıyor ve provizyonu yapılmış cihazların cihaz başına kimlik bilgileriyle bir ConnectMQ broker'a nasıl bağlandığını gösteriyor.

Provizyonun Neyi Başarması Gerekir?

Hangi modeli seçerseniz seçin, iyi bir provizyon süreci beş özellik sağlar:

1. Benzersizlik. Her cihaz kendi kimlik bilgisini alır. Hiçbir iki cihaz bir sırrı paylaşmaz.
2. Gizlilik. Sır, günlükler ve derleme çıktıları dahil, ona ihtiyacı olmayan kişilere veya sistemlere asla düz metin olarak görünmez.
3. İzlenebilirlik. Her kimlik bilgisini bir seri numarasına, bir üretim partisine ve bir müşteriye eşleyebilirsiniz.
4. İptal edilebilirlik. Diğerlerine dokunmadan tek bir cihazı devre dışı bırakabilirsiniz.
5. Kurtarılabilirlik. Onarım veya fabrika ayarlarına sıfırlama sonrasında bir cihazın provizyonunu yeniden yapabilirsiniz.

Firmware'e derlenmiş ortak bir şifre bunlardan en az üçünde başarısız olur. Ele geçirilen tek bir ünitenin filo çapında bir olaya dönüşmesinin en yaygın nedeni budur.

Provizyon Modellerinin Karşılaştırması

Fabrika Provizyonu

Üretim sırasında bir programlama istasyonu benzersiz bir kimlik bilgisi oluşturur veya alır ve bunu genellikle seri numarasıyla birlikte cihazdaki korumalı depolamaya yazar. Mikrodenetleyicilerde bu çoğunlukla şifrelenmiş bir NVS bölümü veya bir secure element'tir; Linux cihazlarda ise şifrelenmiş bir dosya veya TPM destekli bir depodur. İstasyon eşlemeyi envanter sisteminize kaydeder; sırrın kendisini asla düz metin olarak kaydetmez.

Güçlü yanları: cihazlar fabrikadan bağlanmaya hazır çıkar. Zayıf yanları: fabrika ağı artık sırları işler; bu yüzden erişim kontrolüne ve kendi denetim izine ihtiyaç duyar, ayrıca üreticiye güvenmeniz gerekir.

Claim Sertifikaları ve Bootstrap Akışları

Claim sertifikası, bir cihaz partisi tarafından paylaşılan sınırlı bir kimliktir. Tek izni, bir provizyon servisini çağırıp benzersiz, uzun vadeli bir kimlik talep etmektir. Birçok IoT platformu bu kalıbı uygular; aynı fikri herhangi bir broker ile kendiniz de kurabilirsiniz:

1. Cihaz bir bootstrap sırrı veya claim sertifikası ve donanım seri numarasıyla açılır.
2. Bootstrap sırrına sahip olduğunu kanıtlayarak HTTPS üzerinden provizyon servisinizi çağırır.
3. Servis, seri numarasını üretim izin listesine göre ve daha önce talep edilmemiş olduğuna göre kontrol eder.
4. Servis, o cihaz için benzersiz bir MQTT kimlik bilgisi döndürür ve seri numarasını talep edildi olarak işaretler.
5. Cihaz kimlik bilgisini korumalı depolamada saklar ve bootstrap sırrını atar ya da yalnızca yeniden provizyon için tutar.

Claim kimliği hiçbir şeye yayın yapamadığı veya abone olamadığı için, sızan bir kopya bir saldırganın en fazla henüz talep edilmemiş seri numaralarını talep etmesine olanak tanır; izin listesi ve tek seferlik talep bunu bile sınırlar.

Kullanıcı Destekli Devreye Alma

Tüketici cihazlarının provizyonu çoğunlukla sahibi tarafından, cihaza BLE veya geçici bir Wi-Fi erişim noktası üzerinden bağlanan bir uygulamayla yapılır. Bu yerel kanalı şifreleyin, düğmeye basma gibi fiziksel varlık kanıtı isteyin ve uygulamaya herhangi bir şey gömmek yerine uygulamanın cihaz kimlik bilgisini backend'inizden almasını sağlayın.

Bir MQTT Broker için Pratik Bir Bootstrap Akışı

Broker'ınız kimlik bilgilerini kendisi veriyorsa, bir yönetilen MQTT broker'ın genellikle yaptığı gibi, provizyon servisiniz kimlik bilgilerini her seferinde bir cihaza dağıtan emanetçi hâline gelir. ConnectMQ ile kimlik bilgilerini portaldan verirsiniz; her set bir kullanıcı adı, şifre ve bu kimlik bilgilerine bağlı bir client ID içerir. Basit ve sağlam bir tasarım:

• Bir üretim partisinden önce portalda kimlik bilgisi setleri verin.
• Bunları, beklenen her seri numarası için bir tane olacak şekilde provizyon servisinizin şifrelenmiş deposuna yükleyin.
• Cihazların bunları yukarıdaki bootstrap akışıyla talep etmesine izin verin.

Örnek amacıyla Python ve Flask ile yazılmış minimal bir provizyon uç noktası:

# pip install flask
import hmac
import hashlib
import json
from flask import Flask, request, jsonify, abort

app = Flask(__name__)
BOOTSTRAP_KEY = b"load-from-a-secret-manager-not-source"

# seri no -> {"claimed": bool, "cred": {...}}  (üretimde gerçek bir veritabanı kullanın)
INVENTORY = json.load(open("batch-2026-10.json"))

def valid_proof(serial: str, nonce: str, proof: str) -> bool:
    expected = hmac.new(BOOTSTRAP_KEY, f"{serial}:{nonce}".encode(),
                        hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, proof)

@app.post("/provision")
def provision():
    body = request.get_json(force=True)
    serial, nonce, proof = body.get("serial"), body.get("nonce"), body.get("proof")
    if not (serial and nonce and proof) or not valid_proof(serial, nonce, proof):
        abort(401)
    entry = INVENTORY.get(serial)
    if entry is None or entry["claimed"]:
        abort(403)
    entry["claimed"] = True        # üretimde yanıt vermeden önce bunu kalıcı hâle getirin
    return jsonify(entry["cred"])  # {"username": ..., "password": ..., "client_id": ...}

if __name__ == "__main__":
    # HTTPS arkasında sunun (geçerli sertifikalı bir reverse proxy ile)
    app.run(host="127.0.0.1", port=8080)

Üretimde tekrar saldırılarını önlemek için nonce'ları saklayın, uç noktaya hız sınırı uygulayın, talep edildi bayrağını atomik olarak kalıcı hâle getirin ve aynı seri numarasının tekrarlanan taleplerinde alarm verin.

Provizyonu Yapılmış Bir Cihazı Bağlamak

Cihaz kimlik bilgisine sahip olduktan sonra bağlanmak, TLS üzerinden sıradan bir MQTT kullanıcı adı şifre doğrulama işlemidir. Kimlik bilgisini NVS'den okuyan, PubSubClient kullanan bir ESP32 örneği:

#include <WiFi.h>
#include <WiFiClientSecure.h>
#include <PubSubClient.h>
#include <Preferences.h>

extern const char ROOT_CA[];   // ISRG Root X1 PEM, firmware'e derlenmiş

WiFiClientSecure net;
PubSubClient mqtt(net);
Preferences prefs;
String user, pass, clientId;

void setup() {
  Serial.begin(115200);
  prefs.begin("mqtt", true);                 // salt okunur namespace
  user = prefs.getString("user", "");
  pass = prefs.getString("pass", "");
  clientId = prefs.getString("cid", "");
  prefs.end();
  if (user.isEmpty()) { Serial.println("Not provisioned"); return; }

  WiFi.begin("YOUR_SSID", "YOUR_WIFI_PASSWORD");
  while (WiFi.status() != WL_CONNECTED) delay(500);

  net.setCACert(ROOT_CA);
  mqtt.setServer("YOUR_BROKER_HOST", 8883);
}

void loop() {
  if (user.isEmpty()) { delay(1000); return; }   // provizyonu bekle
  if (!mqtt.connected()) {
    if (mqtt.connect(clientId.c_str(), user.c_str(), pass.c_str())) {
      mqtt.publish(("devices/" + clientId + "/status").c_str(), "online", true);
    } else {
      Serial.printf("MQTT connect failed, state=%d\n", mqtt.state());
      delay(10000);                          // geri çekil, broker'ı bombardımana tutma
    }
  }
  mqtt.loop();
}

Saklanan kimlik bilgisinin dökümü alınmış bir flash çipinden okunamaması için flash şifrelemeyi ve NVS şifrelemeyi etkinleştirin. Ayrıntılar cihazlarda MQTT kimlik bilgilerini güvenli tutmak yazısında.

Yeniden Provizyon, Onarımlar ve Hizmetten Çıkarma

Provizyon tek seferlik bir olay değildir. Cihazlar onarım için geri gelir, müşteriler tarafından fabrika ayarlarına sıfırlanır, sahip değiştirir ve sonunda kullanım ömrünün sonuna ulaşır. İlk parti gönderilmeden önce bu yolların her birini planlayın:

• Fabrika ayarlarına sıfırlama. Sıfırlamanın MQTT kimlik bilgisini silip silmeyeceğine karar verin. Siliyorsa cihazın bootstrap akışına geri dönmenin bir yoluna ihtiyacı vardır; bu da provizyon servisinizin, örneğin bir destek kaydı seri numarasını sıfırlanabilir olarak işaretledikten sonra, kontrollü bir yeniden talebe izin vermesi gerektiği anlamına gelir.
• Onarım ve kart değişimleri. Bir ana kart değiştirildiğinde eski kimlik bilgisi eski kartla birlikte gider. Onu iptal edin, yeni bir set verin ve seri numarasının yeni client ID'yi göstermesi için envanteri güncelleyin.
• Sahiplik değişikliği. Müşteriler arasında satılan veya devredilen cihazlar için eskilerini taşımak yerine yeni sahibe ait bir broker'da yeni kimlik bilgileri verin.
• Hizmetten çıkarma. Cihazın hizmetten çıktığı gün kimlik bilgisini portalda iptal edin ve tarihi kaydedin. Hâlâ çalışan terk edilmiş kimlik bilgileri, aylar sonra ortaya çıkan sürpriz bağlantıların yaygın bir kaynağıdır.

Bu yolların her biri, ilk provizyon ve kimlik bilgisi yenileme ile aynı yapı taşlarını yeniden kullanır: verme, iletme, doğrulama, iptal etme.

Provizyon Kontrol Listesi

1. Cihaz başına benzersiz kimlik bilgisi, asla filo çapında bir şifre değil.
2. Sırlar firmware mühendisleri tarafından uydurulmaz, merkezi olarak oluşturulur veya verilir.
3. Bootstrap kimliği yalnızca provizyonla sınırlıdır; tek seferlik talep ve bir izin listesiyle birlikte.
4. Kimlik bilgileri şifrelenmiş depolamada veya bir secure element'te saklanır.
5. Provizyon çağrısı dahil her bağlantıda sertifika doğrulamalı TLS.
6. Düz metin sır içermeden seri numarasını client ID'ye eşleyen envanter.
7. Test edilmiş bir yeniden provizyon ve kimlik bilgisi yenileme yolu.
8. Kimlik doğrulama hatalarında geri çekilme; ConnectMQ tekrarlanan başarısız girişlerden sonra IP'leri engeller.

Kapasite ve Ortam Planlaması

Provizyon plan limitleriyle etkileşir. Serverless (Free) planı pilot bir proje için yeterli olan en fazla 25 bağlantıya izin verir; Serverless (Paid) 1.000 bağlantıya kadar çıkar, Dedicated veya BYOC planları ise daha büyük veya regülasyona tabi filolara uygundur. Test cihazlarının asla üretim kimlik bilgilerini tutmaması için geliştirme, hazırlık (staging) ve üretim için ayrı broker'lar kullanın ve herkese açık MQTT test broker'ını yalnızca hassas olmayan denemeler için kullanın.

ConnectMQ ile Başlayın

İlk cihazlarınızın provizyonunu TLS, tenant izolasyonu ve verilen kimlik bilgilerine bağlı client ID'ler sunan bir bulut MQTT broker üzerinde yapın. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun.

Sık Sorulan Sorular

Güvenli IoT cihaz provizyonu nedir?

Her cihaza benzersiz bir kimlik ve kimlik bilgileri verme, bunları açığa çıkarmadan iletme ve daha sonra izlenip iptal edilebilmeleri için kaydetme sürecidir.

Claim sertifikası nedir?

Claim sertifikası, tek izni ilk açılışta bir provizyon servisinden benzersiz bir cihaz kimlik bilgisi talep etmek olan, sınırlı ve çoğunlukla parti genelinde paylaşılan bir kimliktir.

MQTT kimlik bilgilerini firmware imajlarına gömmeli miyim?

Hayır. Bir firmware imajı defalarca kopyalanır ve çoğu zaman kolayca çıkarılabilir. Bunun yerine her cihaz için benzersiz kimlik bilgilerini korumalı depolamaya yazın.

ConnectMQ bir cihaz provizyon servisi sunuyor mu?

Hayır. Kimlik bilgilerini ConnectMQ portalında verirsiniz ve yukarıda gösterildiği gibi kendi fabrika veya bootstrap sürecinizle iletirsiniz.