MQTT Kimlik Bilgileri Kesintisiz Nasıl Yenilenir?

MQTT kimlik bilgilerini kesintisiz yenilemek için aynı anda geçerli iki kimlik bilgisi setine, yeni setten eskisine geri dönebilen cihazlara ve herhangi bir şey iptal edilmeden önce bir doğrulama adımına ihtiyacınız vardır. Bu rehber, cihaz tarafı kodu ve yönetilen bir broker'da kimlik bilgilerini verme ile iptal etmenin işlem sırası dahil olmak üzere bu çift kimlik bilgisi stratejisini adım adım sunuyor.

MQTT Kimlik Bilgilerini Neden Yenilemeli?

Statik kimlik bilgilerinin cihazlarda raf ömrü uzundur. Yıllar içinde derleme hatlarından, destek dizüstü bilgisayarlarından, iade edilen donanımlardan ve yüklenici devirlerinden geçerler. Yenileme, sızan herhangi bir kopyanın ne kadar süre işe yarayacağını sınırlar. Ayrıca planlanmamış olaylar için test edilmiş bir yenileme sürecine de ihtiyacınız vardır:

• Bir cihaz çalınır, iade edilir veya hizmetten çıkarılır.
• Gömülü sırlar içeren bir firmware imajı yanlışlıkla yayınlanır.
• Kimlik bilgilerine erişimi olan bir çalışan veya entegratör ayrılır.
• Bir güvenlik incelemesi veya müşteri sözleşmesi periyodik yenileme gerektirir.

Bir yenileme sürecini tasarlamak için en kötü zaman bir olay anıdır. Süreci bir takvime göre çalıştırmak onu işler durumda tutar.

Basit Yenileme Neden Kesintilere Yol Açar?

Cazip yaklaşım şudur: broker'daki şifreyi değiştirin, ardından yenisini cihazlara gönderin. Güncellemeyi henüz almamış her cihaz dışarıda kalır ve MQTT'den kilitlenen bir cihaz çoğu zaman güncellemeyi de alamaz, çünkü güncelleme kanalı MQTT'dir. Sonuçta çevrimdışı her cihaz için bir saha ziyareti gerekir.

Ters sıra da başarısız olur: cihazlar önce geçiş yaparsa ve broker yeni kimlik bilgisini henüz tanımıyorsa bağlanamazlar. Tek güvenli yaklaşım, her iki kimlik bilgisinin de çalıştığı bir örtüşme penceresidir.

Çift Kimlik Bilgisi ile Yenileme Stratejisi

Aşamalar her broker için geçerlidir. Değişen, kimlik bilgilerinin nasıl verildiği ve iptal edildiğidir.

Aşama 1: Yeni Kimlik Bilgisini Verin

Kendi barındırdığınız bir Mosquitto broker'da bu, şifre dosyasına ikinci bir kullanıcı eklemek anlamına gelir. ConnectMQ'da ise portaldan cihaz için yeni bir kimlik bilgisi seti verin. Client ID'ler verilen kimlik bilgilerine bağlı olduğundan her set kendi kullanıcı adı, şifresi ve client ID'siyle gelir. Devam etmeden önce fiziksel cihazdan eski ve yeni client ID'lere olan eşlemeyi envanterinize kaydedin.

Bu bağlamanın pratik bir sonucu vardır: yenileme sırasında cihaz yalnızca şifresini değil, tüm kimlik üçlüsünü değiştirir. $SYS/broker/connection/{clientId}/state üzerindeki varlık izleme veya kendi envanteriniz gibi client ID'ye göre çalışan tüm tüketicilerin örtüşme süresince her iki ID'den de haberdar olduğundan emin olun.

Aşama 2: Cihazda Hazırlayın

Yeni kimlik bilgisini mevcut, kimliği doğrulanmış, TLS korumalı bağlantı üzerinden iletin. Tipik bir kalıp, yalnızca o cihazın dinlediği bir komut topic'idir:

devices/<deviceId>/cmd/credentials    # backend -> cihaz, QoS 1, retained değil
devices/<deviceId>/evt/credentials    # cihaz -> backend, onay

Kimlik bilgilerini asla retained message olarak ve asla paylaşılan veya wildcard ile okunabilen bir topic'e yayınlamayın. Broker'ınız topic başına izinleri uygulamıyorsa güvenilmeyen istemcileri tamamen uzak tutun veya kimlik bilgilerini OTA güncelleme servisiniz gibi ayrı bir kanal üzerinden iletin. Cihaz yeni kimlik bilgisini korumalı depolamada mevcut olandan ayrı bir yuvaya yazar ve şifrenin kendisiyle değil, bir hash ile onay verir.

Aşama 3: Geri Dönüş Seçeneğiyle Geçiş Yapın

Cihaz yeni kimlik bilgisiyle yeniden bağlanır. Broker onu reddederse cihaz eskisine geri döner ve hatayı bildirir. Yenilemeyi güvenli kılan adım budur.

import json
import os
import ssl
import time
import paho.mqtt.client as mqtt

HOST = "YOUR_BROKER_HOST"
STORE = "/var/lib/mydevice/credentials.json"   # 0600 izinleriyle koruyun

def load():
    with open(STORE) as f:
        return json.load(f)   # {"active": {...}, "pending": {...} or null}

def save(data):
    tmp = STORE + ".tmp"
    with open(tmp, "w") as f:
        json.dump(data, f)
    os.replace(tmp, STORE)    # atomik değişim, yazma sırasında güç kesilse bile korunur

def try_connect(cred, timeout=15):
    result = {}
    def on_connect(client, userdata, flags, reason_code, properties):
        result["rc"] = reason_code
    c = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                    client_id=cred["client_id"], protocol=mqtt.MQTTv5)
    c.username_pw_set(cred["username"], cred["password"])
    c.tls_set(cert_reqs=ssl.CERT_REQUIRED)
    c.on_connect = on_connect
    c.connect(HOST, 8883, keepalive=60)
    c.loop_start()
    deadline = time.time() + timeout
    while "rc" not in result and time.time() < deadline:
        time.sleep(0.2)
    if result.get("rc") is not None and not result["rc"].is_failure:
        return c
    c.loop_stop()
    c.disconnect()
    return None

def connect_with_rotation():
    data = load()
    if data.get("pending"):
        client = try_connect(data["pending"])
        if client:
            data["previous"] = data["active"]   # iptal edilene kadar yedek olarak tut
            data["active"], data["pending"] = data["pending"], None
            save(data)
            return client
        print("New credential rejected, falling back")
    client = try_connect(data["active"])
    if client is None and data.get("previous"):
        client = try_connect(data["previous"])
    return client

Backend cihaza eski kimlik bilgisinin iptal edildiğini bildirene kadar onu previous olarak tutun. Ardından depolamadan silin.

Aşama 4: Doğrulayın

Herhangi bir şeyi iptal etmeden önce filonun geçiş yaptığını doğrulayın. Faydalı sinyaller:

1. Her cihazın evt/credentials topic'indeki onayı.
2. $SYS/broker/connection/{clientId}/state üzerinde yeni client ID'nin varlığı ve eskisinin yokluğu.
3. Envanter raporunuz: pencereden sonra hâlâ eski kimlik bilgisini kullanan cihazlar.

Geride kalanları tek tek inceleyin. Çevrimdışı cihazlar yaygındır; çok erken iptal etmediğiniz sürece bir sonraki çevrimiçi olduklarında geçiş yapacaklardır.

Aşama 5: İptal Edin

Eski kimlik bilgisi setini portaldan kaldırın (veya kullanıcıyı silip Mosquitto'yu yeniden yükleyin). Ardından cihazlara previous yuvasını silmelerini söyleyin. Bu noktadan itibaren eski kimlik bilgisinin sızmış bir kopyası işe yaramaz.

Yenileme Kontrol Listesi

1. Envanter her cihazı mevcut client ID'siyle eşler.
2. Yeni kimlik bilgisi, herhangi bir cihaz değişmeden önce verilir ve kaydedilir.
3. Kimlik bilgileri yalnızca TLS üzerinden, cihaza özel bir topic'e veya kanala iletilir, asla retained olarak değil.
4. Cihaz yeni kimlik bilgisini atomik bir yazmayla ayrı bir yuvada saklar.
5. Cihaz reddedilme durumunda eski kimlik bilgisine geri döner ve bunu bildirir.
6. Örtüşme penceresi, günlerce çevrimdışı kalan cihazlar için yeterince uzundur.
7. İptal yalnızca doğrulamadan sonra, cihaz tarafında silme ise iptalden sonra yapılır.
8. Süreç yalnızca olaylar sırasında değil, bir takvime göre çalıştırılır.

Dikkat Edilmesi Gereken Tuzaklar

• Yanlış şifreyle sıkı yeniden deneme döngüleri. ConnectMQ, tekrarlanan başarısız girişlerden sonra IP adreslerini engeller. Tek bir NAT adresinin arkasındaki bütün bir saha, hatalı davranan birkaç cihaz yüzünden engellenebilir. Üstel olarak geri çekilin ve hızla geri dönün.
• Tek kimlik bilgisine sahip iki cihaz. Client ID kimlik bilgisine bağlı olduğundan, bir seti paylaşan iki cihaz birbirinin oturumunu devralır ve bir döngü hâlinde bağlantıları kopar. Her cihazın kendi setine ihtiyacı vardır.
• Örtüşme sırasında bağlantı kotası. Cihazlar kısa süreliğine iki bağlantıyı birden tutarsa veya yeni kimlik bilgilerini bir dizüstü bilgisayardan test ederseniz, bunları planınızın bağlantı limitine dahil edin.
• Cihaz olmayan istemcileri unutmak. Node-RED akışları, Telegraf ajanları ve backend servisleri de kimlik bilgisi tutar. Onları da aynı takvimle yenileyin.

Cihazdaki depolama, yenileme süreci kadar önemlidir. ESP32 ve Linux seçenekleri için cihazlarda MQTT kimlik bilgilerini güvenli tutmak yazısına, ilk kimlik bilgisini cihaza güvenle yerleştirmek için ise güvenli IoT cihaz provizyonu yazısına bakın.

ConnectMQ ile Başlayın

Bir yönetilen MQTT broker, şifre dosyalarını ve sertifika yenilemelerini sizin üzerinizden alır; böylece yenilemenin cihaz tarafına odaklanabilirsiniz. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun ve yaygınlaştırmadan önce çift kimlik bilgisi akışının tamamını birkaç cihazla test edin. Kimlik bilgilerinin CONNECT içinde nasıl taşındığına dair arka plan için MQTT kullanıcı adı ve şifre ile kimlik doğrulama yazısını okuyun; bunun bir üretim kurulumuna nasıl oturduğunu görmek için de bulut MQTT broker çalıştırmayı anlatan yazıya göz atın.

Sık Sorulan Sorular

MQTT kimlik bilgilerini ne sıklıkla yenilemeliyim?

Evrensel bir aralık yoktur. Sürecinizin sürdürebileceği bir aralık seçin; genellikle yılda bir veya her büyük firmware sürümünde. Şüpheli bir sızıntıdan ya da bir cihazın kontrolünüzden çıkmasından sonra ise her zaman hemen yenileyin.

Çevrimdışı cihazlarda kimlik bilgilerini yenileyebilir miyim?

Evet, eski kimlik bilgisi cihazlar geri gelene kadar geçerli kaldığı sürece. Cihaz bir sonraki bağlantısında geçiş yapar, siz de ancak geçiş yaptıktan sonra iptal edersiniz.

ConnectMQ'da yenileme sırasında client ID neden değişiyor?

ConnectMQ, client ID'leri verilen kimlik bilgilerine bağlar; bu nedenle yeni bir kimlik bilgisi seti kendi client ID'siyle gelir. Client ID'ye göre çalışan tüm varlık izleme veya envanter sistemlerini güncelleyin.

Yeni kimlik bilgisi reddedilirse ne olur?

Cihaz eski kimlik bilgisine geri dönmeli, yeniden bağlanmalı ve hatayı bildirmelidir; böylece tekrar denemeden önce verilen kimlik bilgisini düzeltebilirsiniz.