MQTT, düşmanca ağlar için değil, kısıtlı ağlar için tasarlandı. Pek çok broker varsayılan olarak 1883 portunda anonim client’ları kabul eder ve her şeyi düz metin olarak gönderir. Bunların hiçbiri protokolün bir kusuru değildir — MQTT ihtiyacınız olan tüm mekanizmalara sahiptir — ancak güvenliği sizin açmanız gerekir. Bu rehber her katmanı tek tek ele alıyor ve incelemelerde kullanabileceğiniz bir kontrol listesiyle bitiyor.
Neye karşı korunuyorsunuz?
- Dinleme (eavesdropping) — ağ üzerinde kimlik bilgilerinin ve payload’ların okunması.
- Kimliğe bürünme — sahte bir client’ın cihazlarınızdan veya servislerinizden biri gibi bağlanması.
- Yetkisiz publish — birinin
home/door/cmdtopic’ineunlockgöndermesi. - Veri sızıntısı — bir client’ın
#topic’ine abone olup her şeyi okuması. - Hizmet engelleme (DoS) — bağlantı veya mesaj seliyle broker’ın kaynaklarının tüketilmesi.
1. Her şeyi TLS ile şifreleyin
TLS, aktarım sırasında kimlik bilgilerini ve payload’ları korur ve client’ların gerçek broker’la konuştuğunu doğrulamasını sağlar. TLS üzerinden MQTT için 8883 portunu, tarayıcılar için wss:// kullanın; güvenilir bir yerel ağın dışında düz 1883 listener’ını kapatın veya firewall ile engelleyin. Ayrıntılar için MQTT portları ve WebSocket üzerinden MQTT yazılarına bakın.
- TLS 1.2 veya daha yenisini zorunlu kılın.
- Client’larda sunucu sertifikasını her zaman doğrulayın.
--insecure,setInsecure()veyarejectUnauthorized: falsegibi seçenekler yalnızca yerel hata ayıklama içindir. - Sertifika yenilemeyi planlayın — süresi dolmuş bir sertifika tüm cihazları aynı anda çevrimdışı bırakır.
mosquitto_sub -h broker.example.com -p 8883 --cafile ca.crt \
-u sensor-01 -P 'secret' -t 'devices/sensor-01/#' -v2. Her client’ın kimliğini doğrulayın
Anonim erişimi kapatın. Ardından her client türüne uygun bir kimlik doğrulama yöntemi seçin:
| Yöntem | Uygun olduğu durum | Dikkat edilmesi gerekenler |
|---|---|---|
| Kullanıcı adı ve parola | Çoğu kurulum; her client kütüphanesi destekler | Yalnızca TLS üzerinden güvenlidir; her cihaza ayrı kimlik bilgisi verin |
| Client sertifikaları (mutual TLS) | Provisioning süreci olan cihaz filoları | Bir CA, iptal (revocation) ve sertifika rotasyonu gerektirir |
| Token’lar (örneğin parola alanında JWT) | Tarayıcı ve mobil uygulamalar, kısa ömürlü erişim | Broker desteği değişkendir; ömürleri kısa tutun |
| MQTT 5 enhanced authentication | SCRAM gibi challenge/response şemaları | Broker’larda ve client kütüphanelerinde desteği sınırlıdır |
Bir filo genelinde asla tek bir hesabı paylaştırmayın: tek bir cihaz ele geçirildiğinde tüm cihazları yeniden flash’lamak yerine yalnızca bir kimlik bilgisini iptal etmek istersiniz. Parolaları broker’da hash’lenmiş olarak saklayın — Mosquitto kullanıcıları Mosquitto kimlik doğrulama rehberini izleyebilir; mosquitto.conf oluşturucu ise TLS ve parola dosyalarıyla güvenli bir yapılandırma hazırlar.
3. Topic’leri ACL’lerle yetkilendirin
Kimlik doğrulama kim olduğunuzu, yetkilendirme ise neler yapabileceğinizi yanıtlar. ACL’ler olmadan kimliği doğrulanmış her client her topic’i okuyabilir ve yazabilir. En az yetki ilkesini uygulayın: her client yalnızca ihtiyaç duyduğu topic’lere okuma veya yazma erişimi alsın.
# backend service: read all telemetry, send commands
user backend
topic read devices/+/telemetry
topic write devices/+/cmd
# every device: only its own topics (%u = username)
pattern write devices/%u/telemetry
pattern read devices/%u/cmdKullanıcı adını veya client ID’yi yerine koyan pattern kuralları, cihaz başına bir kural yazmaktan çok daha iyi ölçeklenir. Filtrelerinizi topic eşleştirici ile doğrulayın; MQTT wildcard’ları topic’ler ve joker karakterler yazısında anlatılıyor.
4. Client ID’leri kontrol altında tutun
Mevcut bir client ID ile bağlanan bir client, asıl bağlantıyı broker’dan düşürür. ID’lerinizi bilen bir saldırgan bunu cihazların bağlantısını koparmak için kullanabilir; yanlışlıkla oluşan bir kopya ise sonsuz yeniden bağlanma döngülerine yol açar. Broker’ınız izin veriyorsa client ID’leri kimlik bilgilerine bağlayın (örneğin client ID’nin kullanıcı adına veya sertifikanın common name’ine eşit olmasını şart koşun) ve paylaşımlı broker’larda tahmin edilebilir ID’lerden kaçının. Client ID oluşturucu benzersiz ID’ler üretmenize yardımcı olur.
5. Topic’leri güvenliği düşünerek tasarlayın
- ACL pattern’lerinin eşleşebilmesi için cihaz veya tenant ID’sini sabit bir konuma koyun.
- Telemetriyi (cihaz yazar) ve komutları (cihaz okur) farklı alt ağaçlara ayırın.
- Gizli bilgileri ve kişisel verileri topic adlarına koymayın — topic’ler log’larda ve izleme araçlarında görünür.
- Komut topic’lerinde retained mesajlara dikkat edin: retained bir
unlockyeniden bağlanınca tekrar tetiklenir.
6. Hassas payload’ları şifreleyin veya imzalayın
TLS her bir atlamayı korur, ancak broker payload’ları düz metin olarak görür. Broker operatörünün veya broker üzerindeki diğer servislerin veriyi okumaması gerekiyorsa payload’ları uçtan uca şifreleyin (örneğin anahtarları MQTT dışında yönetilen AES-GCM ile) ya da en azından komutları imzalayın ki cihazlar sahte komutları reddedebilsin. Cihazda gelen her payload’u doğrulayın: boyut sınırlarını uygulayın, türleri kontrol edin ve bilinmeyen komutları yok sayın.
7. Sınırlar ve hız limitleri belirleyin
Maksimum paket boyutunu, client başına inflight ve kuyruktaki mesaj sayısını, bağlantı hızını ve abonelik sayısını sınırlayın. MQTT 5, broker’ın maximum packet size ve receive maximum gibi sınırları client’lara bildirmesine olanak tanır. Hız limitleri, publish döngüsüne girmiş hatalı bir cihazın herkesi çökertmesini engeller — gerçekçi boyut sınırları belirlemek için paket boyutu hesaplayıcıyı kullanın.
8. Cihazlardaki ve uygulamalardaki kimlik bilgilerini koruyun
Cihaz kimlik bilgileri flash belleğe, tarayıcı kimlik bilgileri ise herkesin okuyabildiği JavaScript bundle’larına düşer. Bunların ele geçirilebileceğini varsayın: her client’a mümkün olan en dar ACL’i verin, firmware’e tek bir gizli anahtar gömmek yerine kimlik bilgilerini üretimde veya ilk açılışta cihaz başına oluşturun ve donanım destekliyorsa flash şifreleme ya da secure element kullanın. Web ve mobil uygulamalarda uzun ömürlü bir parola dağıtmak yerine backend’inizden kısa ömürlü kimlik bilgileri verin.
9. İzleyin ve log tutun
- Bağlanma, bağlantı kesme ve kimlik doğrulama hatalarını log’layın; ani artışlarda alarm üretin.
- Beklenmedik şekilde
#veya$SYS/#topic’ine abone olan client’lara dikkat edin. - Ele geçirilmiş veya hatalı davranan cihazları fark etmek için client başına bağlantı sayısını ve mesaj hızını takip edin.
- Broker’ı ve client kütüphanelerini güncel tutun.
MQTT güvenlik kontrol listesi
| Alan | Kontrol |
|---|---|
| Aktarım | 8883 / wss üzerinde TLS; düz 1883 kapalı veya firewall arkasında; client’lar sunucu sertifikasını doğruluyor |
| Sertifikalar | Yenileme otomatik veya planlı; son kullanma tarihi izleniyor |
| Kimlik doğrulama | Anonim erişim kapalı; cihaz veya servis başına benzersiz kimlik bilgileri; parolalar hash’lenmiş |
| Yetkilendirme | ACL’ler en az yetki ilkesini uyguluyor; hiçbir client gerekçesiz # topic’ine abone olamıyor |
| Client ID’ler | Benzersiz, ideal olarak kullanıcı adına veya sertifikaya bağlı |
| Topic’ler | Telemetri ve komutlar ayrı; topic adlarında gizli bilgi yok; retained komut yok |
| Payload’lar | Alındığında doğrulanıyor; hassas veriler uçtan uca şifreli veya imzalı |
| Sınırlar | Maksimum paket boyutu, kuyruk boyutları, bağlantı ve mesaj hızı limitleri yapılandırılmış |
| İzleme | Kimlik doğrulama hataları ve olağandışı trafik log’lanıyor ve alarm üretiyor; yazılımlar güncel |
| Ortamlar | Genel broker’larda üretim verisi yok; geliştirme ve üretim için ayrı kimlik bilgileri |
Kısıtlanmış bir client bağlanamadığında CONNACK reason code’u sorunun kimlik bilgilerinden mi yoksa yetkilendirmeden mi kaynaklandığını söyler — kodu MQTT reason code başvuru kaynağında arayın.
Sıkça sorulan sorular
MQTT varsayılan olarak güvenli mi?
Hayır. 1883 portundaki düz MQTT kimlik bilgilerini ve payload’ları şifrelenmeden gönderir ve birçok broker varsayılan olarak anonim bağlantılara izin verir. MQTT; TLS eklediğinizde, kimlik doğrulamayı zorunlu kıldığınızda ve her client’ı ACL’lerle yalnızca ihtiyaç duyduğu topic’lerle sınırladığınızda güvenli hale gelir.
MQTT için kullanıcı adı/parola mı yoksa client sertifikaları mı kullanmalıyım?
TLS üzerinden ikisi de uygundur. Kullanıcı adı ve parolanın yönetimi daha basittir ve her yerde desteklenir. Client sertifikaları (mutual TLS) paylaşılan gizli bilgilere gerek bırakmaz ve provisioning süreci olan büyük cihaz filolarına uygundur. Birçok kurulumda cihazlar için sertifika, backend servisleri için parola veya token kullanılır.
Genel (public) bir MQTT broker kullanmak güvenli mi?
Yalnızca sahte verilerle test için. Genel bir broker’da herkes topic’lerinize abone olabilir ve onlara publish edebilir; erişim kontrolü ve erişilebilirlik garantisi yoktur. Gerçek cihazlar ve gerçek veriler, kimlik doğrulama ve TLS içeren özel bir broker’da olmalıdır.