MQTT Denetim Kayıtları: Neler Kaydedilmeli ve Neden?

MQTT denetim kayıtları (audit logging), kimin bağlandığını, kimin bağlanamadığını, yapılandırmada neyin değiştiğini ve hangi işlemlerin önemli olduğunu kaydetmek demektir; böylece olayları inceleyebilir ve denetçilere kontrollerin çalıştığını gösterebilirsiniz. Bu rehber hangi olayların kaydedileceğini, her kaydın hangi alanlara ihtiyaç duyduğunu, ne kadar süre saklanacağını ve yönetilen bir broker etrafında nasıl bir log pipeline'ı kurulacağını açıklar. Odak noktası her mesaj payload'unu saklamak değil, güvenlik ve operasyon olaylarıdır.

Denetim Kayıtları ve Mesaj Verisi

Üç tür kaydı birbirinden ayırmak faydalıdır:

• Denetim kayıtları: Oturum açmalar, başarısız oturum açma denemeleri, kimlik bilgisi değişiklikleri ve yönetimsel işlemler gibi güvenlikle ilgili olaylar. Küçük, yapılandırılmış ve tanımlı bir süre boyunca saklanır.
• Operasyonel loglar: Sistemi çalışır durumda tutmak için kullanılan bağlantı kopmaları, hatalar, kota aşımları ve performans sinyalleri.
• Mesaj geçmişi: Telemetrinin kendisi; genellikle analitik için bir zaman serisi veritabanında veya historian'da saklanır.

Bunları karıştırmak sorun yaratır. Payload arşivleri büyüktür, kişisel veya gizli veriler içerebilir ve bir inceleme sırasında gerçekten ihtiyaç duyduğunuz güvenlik olaylarını gömer. Denetim kayıtlarını yalın ve odaklı tutun.

Neler Kaydedilmeli?

Son satır özellikle dikkat ister. Telemetri nadiren bir denetim izine ihtiyaç duyar, ancak ekipman durumunu değiştiren komutlar çoğu zaman ihtiyaç duyar. Yalnızca bir mesajın geçtiğini değil; komutu, gönderen kimliği ve onayı kaydedin.

Her Kaydın İhtiyaç Duyduğu Alanlar

Kaynak ne olursa olsun, kayıtları tutarlı bir yapıya normalize edin:

{
  "ts": "2026-10-16T09:41:07.312Z",
  "event": "client.disconnected",
  "source": "connectmq-monitor",
  "client_id": "gw-plant1-01",
  "username": "gw-plant1-01",
  "ip": "203.0.113.24",
  "reason_code": "0x8E",
  "details": { "previous_state": "connected" }
}

Milisaniyeli UTC zaman damgaları kullanın, olay adlarını sabit tutun ve parolaları, token'ları veya kişisel veri içeren tam payload'ları asla loglamayın.

Olaylar Nereden Gelir?

Kendi barındırdığınız bir kurulumda birincil kaynak broker'ın kendi log dosyalarıdır. Örneğin Mosquitto, ilgili log_type seçenekleri etkinleştirildiğinde bağlantıları, bağlantı kesilmelerini ve kimlik doğrulama hatalarını loglar; siz de bu dosyaları merkezi bir sisteme gönderirsiniz.

Yönetilen bir broker'da ise platformun sunduklarını kendi istemcilerinizin ve uygulamalarınızın kaydettikleriyle birleştirirsiniz. Hangisinin hangisi olduğu konusunda net olmak önemlidir. ConnectMQ üzerinde görünür kaynaklar şunlardır:

• Bağlantı durumu topic'leri: $SYS/broker/connection/{clientId}/state, bir istemcinin bağlı olup olmadığını bildirir; buna subscribe olup kaydedebilirsiniz.
• Portal dashboard'u ve cihazlar görünümü: Bağlı istemciler ve topic'ler hakkında operasyonel görünürlük.
• Eşik tabanlı uyarı kuralları ve uyarı logu: Verinin tanımladığınız eşikleri ne zaman aştığının kaydı.
• MQTT 5 reason code'ları: Ret durumunda istemcilere döndürülür; kota aşımı için 0x97 de buna dahildir ve istemcileriniz bunları loglayabilir.
• Platform korumaları: Flood koruması ve tekrarlanan başarısız oturum açma denemelerinden sonra IP engelleme broker tarafında çalışır.

Bunlar operasyonel sinyallerdir, uyumluluk amaçlı bir denetim izi değildir. Eksiksiz bir denetim izi için olayları istemci ve uygulama tarafından kontrolünüzdeki bir depolamaya kaydedin ve yönetimsel prosedürleri kendi değişiklik kayıtlarınızda belgeleyin. Bu, yönetilen hizmetlerde yaygın bir paylaşılan sorumluluk ayrımıdır; sorumlulukların nasıl bölündüğü için yönetilen MQTT broker rehberine bakın.

Basit Bir Denetim Pipeline'ı Kurun

Bağlantı durumu topic'lerine subscribe olan ve yapılandırılmış satırları bir dosyaya veya log shipper'a yazan küçük bir servis, size güvenilir bir bağlantı geçmişi sağlar. Bu örnek paho-mqtt 2.x kullanır ve bilinen bir client ID listesini izler:

import json
import logging
from datetime import datetime, timezone
import paho.mqtt.client as mqtt

WATCHED_CLIENTS = ["gw-plant1-01", "gw-plant1-02", "dashboard-01"]

logging.basicConfig(filename="mqtt-audit.jsonl", level=logging.INFO, format="%(message)s")

def audit(event, **fields):
    entry = {"ts": datetime.now(timezone.utc).isoformat(timespec="milliseconds"),
             "event": event, "source": "connectmq-monitor", **fields}
    logging.info(json.dumps(entry))

def on_connect(client, userdata, flags, reason_code, properties):
    audit("monitor.connected", reason_code=str(reason_code))
    for cid in WATCHED_CLIENTS:
        client.subscribe(f"$SYS/broker/connection/{cid}/state", qos=1)

def on_message(client, userdata, msg):
    cid = msg.topic.split("/")[3]
    audit("client.state", client_id=cid, state=msg.payload.decode("utf-8", "replace"))

def on_disconnect(client, userdata, flags, reason_code, properties):
    audit("monitor.disconnected", reason_code=str(reason_code))

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
                     protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.on_disconnect = on_disconnect
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.connect("YOUR_BROKER_HOST", 8883, keepalive=60)
client.loop_forever()

JSON lines dosyası herhangi bir log shipper tarafından toplanabilir ve kuruluşunuzun zaten kullandığı SIEM'e veya log platformuna iletilebilir. İzleyicinin kendi bağlantı kesilmelerini de logladığına dikkat edin: denetim izinizdeki boşluklar da başlı başına önemli olaylardır.

İstemci Tarafında da Loglayın

Cihazlar ve uygulamalar, broker'ın size asla bildirmediği olayları görür; örneğin kendi başarısız bağlantı denemelerini ve reddedilen publish işlemlerini. Her istemcinin şunları loglamasını sağlayın:

1. Sonuç reason code'uyla birlikte bağlantı denemeleri.
2. Reddedilen subscription'lar (0x80 ve üzeri SUBACK kodları).
3. Reddedilen publish işlemleri; özellikle 0x97 kota aşıldı ve 0x87 yetkisiz.
4. Alınan komutlar, doğrulama sonuçları ve yapılan işlemler.
5. Kimlik bilgisi rotasyon olayları.

Tesislerdeki gateway'ler için bu logları yalnızca cihazda tutmak yerine merkezi bir toplayıcıya gönderin. MQTT OT güvenliği rehberi bunu içe dönük port açmadan nasıl yapacağınızı anlatır.

Saklama, Bütünlük ve Gizlilik

Denetim kayıtları ancak eksiksiz, güvenilir ve saklanması hukuka uygun olduğunda faydalıdır.

• Saklama: Düzenleyici, sözleşmesel ve inceleme ihtiyaçlarınıza göre bir süre belirleyin ve belgeleyin. Süre dolduğunda logları silin.
• Bütünlük: Yalnızca ekleme yapılabilen (append-only) bir depolamaya veya silmeyi kısıtlayan bir sisteme yazın ve logları kimlerin değiştirebileceğini sınırlayın.
• Zaman senkronizasyonu: Loglama yapan her sunucuda NTP kullanın; uyumsuz saatler zaman çizelgelerini işe yaramaz hale getirir.
• Gizlilik: IP adresleri ve kullanıcı adları kişisel veri olabilir. İhtiyacınız olanı toplayın, erişimi koruyun ve gizlilik politikanızı uygulayın.
• Erişim: Logların kendisine yapılan erişimi de loglayın.

Logları Uyarılara Dönüştürmek

Kimsenin okumadığı loglar güvenliği iyileştirmez. Birkaç yüksek değerli uyarıyla başlayın:

1. Kısa bir süre içinde tek bir kullanıcı adı için veya tek bir IP'den çok sayıda başarısız kimlik doğrulama.
2. Bilinen bir cihazın beklenmeyen bir ağdan bağlanması.
3. Bir gateway'in beklenen maksimum kesinti süresinden daha uzun süre bağlantısız kalması.
4. Tek bir istemciden tekrarlanan kota veya hız sınırı retleri.
5. Bir kontrol topic'inde mesai saatleri dışında veya beklenmeyen bir kimlikten gelen herhangi bir komut.

Bunlar IoT mesajlaşmasında sıfır güven yazısındaki sürekli doğrulama fikirleriyle ve IEC 62443 gibi çerçevelerdeki olay izleme beklentileriyle yakından örtüşür.

Denetim Kaydı Kontrol Listesi

1. Güvenlik olaylarının tanımlı bir listesi ve her kaynak için sorumlular.
2. UTC zaman damgalı, tutarlı bir JSON yapısı.
3. Her kritik istemci için izlenen bağlantı durumu.
4. Reason code'ların, retlerin ve komutların istemci tarafında loglanması.
5. Yönetimsel değişikliklerin değişiklik yönetimi sürecinizde kayıt altına alınması.
6. Belgelenmiş bir saklama süresine sahip, merkezi ve erişim kontrollü depolama.
7. Başarısız oturum açma denemeleri, beklenmeyen bağlantı kesilmeleri ve hız anomalileri için uyarılar.
8. Pipeline'ın kendisinin çalıştığının düzenli olarak gözden geçirilmesi.

ConnectMQ ile Broker'ınızı İzlemeye Başlayın

app.connectmq.com adresinde ücretsiz Serverless planla özel bir broker oluşturun (kredi kartı gerekmez), yukarıdaki izleyiciyi oluşturulan kimlik bilgilerinizle bağlayın ve bağlantı olaylarının belirdiğini izleyin. Önce kimlik bilgisi olmadan denemek isterseniz ücretsiz herkese açık MQTT broker'ı test verileriyle deneyin. MQTT güvenliği en iyi uygulamaları yazısı, loglarınızın doğrulaması gereken kontrolleri ele alır.

Sık Sorulan Sorular

Denetim için her MQTT mesajını loglamalı mıyım?

Genellikle hayır. Güvenlik ve yönetim olaylarını, ayrıca kontrol topic'lerindeki komutları loglayın. Analitik için ihtiyaç duyuyorsanız telemetriyi ayrı olarak bir historian'da veya veritabanında saklayın.

Denetlenmesi gereken en önemli MQTT olayı nedir?

Başarısız kimlik doğrulama denemeleri; çünkü tahmin denemelerini, sızdırılmış veya süresi dolmuş kimlik bilgilerini ve yanlış yapılandırılmış cihazları erkenden ortaya çıkarırlar.

MQTT denetim kayıtları ne kadar süre saklanmalı?

Tek bir cevabı yoktur. Saklama süresi düzenleyici, sözleşmesel ve inceleme gereksinimlerinize bağlıdır; bu nedenle bir süre tanımlayın, belgeleyin ve süre dolduğunda silmeyi uygulayın.

Yönetilen bir broker'dan bağlantı olaylarını alabilir miyim?

ConnectMQ'da bağlantı durumu için $SYS/broker/connection/{clientId}/state topic'ine subscribe olabilir ve bunu reason code'ların istemci tarafı loglarıyla birleştirerek kendi bağlantı geçmişinizi oluşturabilirsiniz.