MQTT güvenli mi? Protokolün kendisi güvenlik için yalnızca kancalar sunar: bir kullanıcı adı ve şifre alanı ile TLS üzerinden çalışma desteği. Güvenliği tam olarak etrafındaki kurulum kadardır. Bu yazı MQTT'nin neyi koruyup neyi korumadığını, gerçek sistemleri hangi tehditlerin vurduğunu, sorun çıkaran efsaneleri ve bir MQTT kurulumunu güvenli hâle getiren katmanları açıklıyor.
MQTT'nin Kendisi Neler Sunar?
MQTT hafif bir mesajlaşma protokolü olarak tasarlandı ve spesifikasyonu güvenliğin büyük kısmını bilinçli olarak diğer katmanlara bırakır. Kutudan çıktığı hâliyle şunları elde edersiniz:
- CONNECT paketinde düz bayt olarak gönderilen bir kullanıcı adı ve şifre alanı.
- Broker'ın uyguladığı challenge-response yöntemleri için MQTT 5 gelişmiş kimlik doğrulama kancaları (bir kimlik doğrulama yöntemi ve AUTH paketleri).
- Broker'ın "hatalı kimlik bilgileri" veya "yetkisiz" diyebilmesini sağlayan reason code'lar.
- MQTT'nin TLS veya güvenli WebSocket üzerinden çalışabilmesini sağlayan taşıma bağımsızlığı.
Protokolün kendi başına sağlamadıkları:
- Şifreleme yok. TLS olmadan her topic, payload ve şifre hatta okunabilir.
- Yetkilendirme modeli yok. Hangi istemcinin hangi topic'i kullanabileceği broker'a kalmıştır.
- Payload bütünlüğü veya imzalama yok. Bir mesaj, ulaştığı bağlantı dışında onu kimin oluşturduğuna dair hiçbir kanıt taşımaz.
- Hız sınırlama veya kötüye kullanım koruması yok. Bu bir broker özelliğidir.
OASIS MQTT spesifikasyonu bunları uygulama sorumlulukları olarak ele alan bir güvenlik bölümü bile içerir. Dolayısıyla "MQTT güvenli mi" sorusunun dürüst yanıtı şudur: MQTT güvenli hâle getirilebilir ve güvenlik; broker'ın, istemcilerin ve ağ tasarımının bir özelliğidir.
Gerçekten Önemli Olan Tehditler
| Tehdit | Nasıl gerçekleşir | Birincil koruma |
|---|---|---|
| Dinleme | 1883 portundaki trafiğin Wi-Fi, ISS veya bulut ağında yakalanması | 8883 / 8084 üzerinde TLS |
| İletim sırasında kimlik bilgisi hırsızlığı | Şifrenin şifrelenmemiş bir CONNECT'ten okunması | Sertifika doğrulamalı TLS |
| Açık broker'lar | Anonim erişimle internete açık broker | Kimlik doğrulama, üretimde anonim erişim olmaması |
| Cihazlardan kimlik bilgisi çıkarma | Firmware'e sabit kodlanmış veya düz flash'ta saklanan şifre | Cihaz başına kimlik bilgileri, şifrelenmiş depolama |
| Kimliğe bürünme | Saldırganın çalınmış veya paylaşılan bir client ID ile bağlanması | Kimlik bilgilerine bağlı client ID'ler |
| Tenant'lar arası erişim | Paylaşılan bir broker'da zayıf izolasyon | Tenant izolasyonu |
| Kötü niyetli komutlar | Bir komut topic'ine yayın yapabilen herkes | Yetkilendirme, cihazda komut doğrulama |
| Hizmet engelleme | Bağlantı taşkınları, mesaj taşkınları, kaba kuvvet girişleri | Kotalar, flood koruması, IP engelleme |
Açıkta kalan broker taramaları, 1883 portunda anonim erişime sahip, sensör verisi sızdıran ve bazen komut kabul eden sistemleri düzenli olarak bulur. Bunlar protokol açıkları değil yapılandırma hatalarıdır; asıl işin büyük kısmının operasyonel olmasının nedeni de budur. Bunların nasıl bulunup kapatıldığı için açıkta kalan MQTT broker'lar yazısına bakın.
MQTT Güvenliği Hakkında Yaygın Efsaneler
"MQTT şifreleri düz metin gönderdiği için güvensizdir."
Şifreleri MQTT katmanı içinde düz metin olarak gönderir; tıpkı HTTP Basic kimlik doğrulamasının yaptığı gibi. TLS üzerinden ise CONNECT paketi dahil tüm bağlantı şifrelenir. Sorun MQTT'nin kendisi değil, MQTT'yi TLS olmadan çalıştırmaktır.
"Ağımızın içinde 1883 portu sorun değil."
İç ağlar ele geçirilir, Wi-Fi dinlenir ve "geçici" port yönlendirmeleri kalıcı hâle gelir. Her ağı güvenilmez kabul edin ve mümkün olan her yerde TLS kullanın. Düz 1883'ü, ücretsiz herkese açık MQTT broker üzerindeki demo trafiği gibi, her yerde görülmesinden rahatsız olmayacağınız herkese açık test verisi için ayırın.
"Uzun, rastgele bir client ID bir sırdır."
Client ID'ler günlüklerde, panolarda ve topic yollarında görünür. Bir istemciyi tanımlarlar, kimliğini doğrulamazlar. Güvenlik, client ID'nin bağlı olduğu kimlik bilgisinden gelir.
"TLS payload'ları uçtan uca güvenli kılar."
TLS, bir istemci ile broker arasındaki her adımı korur. Broker payload'ı düz hâliyle görür. Cihazdan uygulamaya uçtan uca gizliliğe ihtiyacınız varsa üstüne MQTT payload şifrelemesi ekleyin.
"Kimse benim sensörlerime saldırmakla uğraşmaz."
Otomatik tarayıcılar sensörlerinizin neyi ölçtüğüyle ilgilenmez. Açık portları ve varsayılan kimlik bilgilerini ararlar; açıkta kalan bir broker bir dayanak noktası veya ücretsiz bir aktarıcı olarak kullanılabilir.
MQTT'yi Güvenli Kılan Katmanlar
- Taşıma şifrelemesi. 8883 portunda TLS 1.2 veya daha yenisi ya da tarayıcılar için 8084'te güvenli WebSocket; her istemcide sertifika doğrulaması etkin.
- Kimlik doğrulama. Üretim verisine anonim erişim yok. Her cihaz ve servis için benzersiz kimlik bilgileri.
- Kimlik bağlama. Bir istemcinin diğerinin kimliğine bürünememesi için client ID'lerin kimlik bilgilerine bağlanması.
- İzolasyon ve yetkilendirme. Ayrı tenant'lar ve ortamlar; broker'ınız destekliyorsa topic'leri kısıtlayın ve topic ağaçlarını kimlik ile yön görünür olacak şekilde tasarlayın. MQTT ACL rehberi her iki yaklaşımı da ele alır.
- Kötüye kullanım koruması. Bağlantı ve mesaj kotaları, flood koruması ve kaba kuvvet giriş denemelerinin engellenmesi.
- Cihaz sıkılaştırma. Şifrelenmiş kimlik bilgisi depolama, Secure Boot, devre dışı bırakılmış hata ayıklama portları, imzalı firmware güncellemeleri.
- Operasyon. Kimlik bilgisi yenileme, bağlantı durumunun ve anormalliklerin izlenmesi ve ele geçirilmiş bir cihazı iptal etmek için bir plan.
Yönetilen Bir Broker Açıkları Nasıl Kapatır?
Bu katmanların birçoğu broker tarafındadır ve kendi barındırılan kurulumların en sık yanlış yaptığı kısımlar tam da bunlardır: sertifikaların süresi dolar, anonim erişim bir testten sonra açık kalır, bir şifre dosyası her cihaz tarafından paylaşılır. Bir yönetilen MQTT broker bu sorumlulukları üstlenir.
ConnectMQ'nun yukarıdaki katmanlara karşılıkları şöyle:
| Katman | ConnectMQ |
|---|---|
| Taşıma şifrelemesi | Let's Encrypt sertifikasıyla 8883'te TLS ve 8084'te güvenli WebSocket (yol /mqtt) |
| Kimlik doğrulama | Broker kimlik bilgisi seti başına oluşturulmuş kullanıcı adı ve şifre |
| Kimlik bağlama | Verilen kimlik bilgilerine bağlı client ID'ler |
| İzolasyon | Müşteriler arasında çok kiracılı (multi-tenant) izolasyon; izole bir küme için Dedicated plan; kendi bulut hesabınızda BYOC |
| Kötüye kullanım koruması | Plan başına kotalar, flood koruması, tekrarlanan başarısız girişlerden sonra IP engelleme |
| Görünürlük | Pano, canlı topic gezgini ve istemci başına bağlantı durumu için $SYS/broker/connection/{clientId}/state |
ConnectMQ topic başına ACL uygulamaz; bu yüzden güvenlik sınırı tenant ve broker'dır: iki istemci grubu birbirinin verisini görmemeliyse onlara ayrı broker'lar verin ve güvenilmeyen kullanıcılara broker kimlik bilgileri vermek yerine onları kendi backend'inizin arkasında tutun. Cihaz sıkılaştırma ve kimlik bilgisi yenileme, her broker'da olduğu gibi sizin sorumluluğunuzda kalır; cihazlarda MQTT kimlik bilgilerini güvenli tutmak ve MQTT güvenliği en iyi uygulamaları rehberleri bunları ele alır.
Hızlı Öz Değerlendirme
Mevcut kurulumunuz hakkında şu soruları yanıtlayın:
- Herhangi bir üretim istemcisi 1883 portundan bağlanıyor mu?
- Herhangi bir istemci sertifika doğrulamasını devre dışı bırakıyor mu?
- İki veya daha fazla cihaz tek bir kimlik bilgisini paylaşıyor mu?
- Herhangi bir kimlik bilgisi bir firmware imajına veya herkese açık bir depoya sabit kodlanmış mı?
- Diğerlerini etkilemeden tek bir cihazı dakikalar içinde iptal edebiliyor musunuz?
- Bir cihaz beklenmedik bir yerden bağlanmaya veya normal hızının on katında yayın yapmaya başlasa fark eder miydiniz?
İlk dördünden herhangi birine "evet" ya da son ikisinden birine "hayır" yanıtı, başlamanız gereken yeri gösterir.
ConnectMQ ile Başlayın
Sizin için yönetilen bir bulut MQTT broker ile ilk günden TLS, kimlik doğrulama, kimlik bağlama, tenant izolasyonu ve kötüye kullanım korumasına sahip olun. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun ve ilk cihazınızı dakikalar içinde 8883 portu üzerinden bağlayın.
Sık Sorulan Sorular
MQTT, TLS olmadan güvenli mi?
Hayır. TLS olmadan kullanıcı adları, şifreler, topic'ler ve payload'lar trafiği yakalayabilen herkes tarafından okunabilir. Herkese açık test verisinin ötesindeki her şey için 8883 portunu veya güvenli WebSocket'i kullanın.
MQTT, HTTP'den daha mı güvenli yoksa daha mı az güvenli?
Karşılaştırılabilir düzeydeler. Her ikisi de şifreleme için TLS'e, kimlik doğrulama ve yetkilendirme için sunucuya dayanır; hiçbiri düz metin hâlinde güvenli değildir.
MQTT 5 güvenliği iyileştiriyor mu?
MQTT 5; gelişmiş kimlik doğrulama, yeniden kimlik doğrulama ve daha zengin reason code'lar ekler; bunlar güvenli tasarımları kurmayı ve hata ayıklamayı kolaylaştırır. Kendi başına şifreleme eklemez.
Herkese açık bir MQTT broker kullanmak güvenli mi?
Hassas olmayan verilerle öğrenme ve demolar için evet. Herkese açık broker'lar herkes tarafından okunabilir; bu yüzden üretim verisinin yeri kimlik bilgileri ve TLS kullanan özel bir broker'dır.
