MQTT ACL (erişim kontrol listesi), bir broker'ın kimliği doğrulanmış hangi istemcinin hangi topic'lere yayın yapabileceğine veya abone olabileceğine karar vermek için kullandığı kurallar bütünüdür. Bu yazı kavramları açıklıyor, bunların Mosquitto kullanan gerçek bir broker yapılandırmasında nasıl göründüğünü gösteriyor, bir istemci reddedildiğinde ne olduğunu anlatıyor ve ister ayrıntılı ACL'ler ister tenant düzeyinde izolasyon kullanın, yetkilendirmeyi basit tutan topic tasarım kalıplarını sunuyor.
Kimlik Doğrulama ve Yetkilendirme
İkisi kolayca karıştırılır ve broker'lar bunları farklı aşamalarda ele alır:
- Kimlik doğrulama (authentication) "Sen kimsin?" sorusunu yanıtlar. CONNECT anında bir kez, kullanıcı adı ve şifre, istemci sertifikası veya token ile gerçekleşir. Ayrıntılar için MQTT kullanıcı adı şifre doğrulama yazısına bakın.
- Yetkilendirme (authorization) "Ne yapabilirsin?" sorusunu yanıtlar. Her SUBSCRIBE'da ve broker'a bağlı olarak her PUBLISH'te kontrol edilir. ACL'ler bunu ifade etmenin en yaygın yoludur.
Hiçbir yetkilendirme kuralı olmayan, kimliği doğrulanmış bir istemci genellikle broker'ının veya tenant'ının izin verdiği her şeyi okuyup yazabilir. ACL'ler bunu kullanıcı, client ID veya rol bazında daraltır.
Bir MQTT ACL Kuralı Neleri İçerir?
Broker hangi sözdizimini kullanırsa kullansın, her kural aynı öğeleri birleştirir:
| Öğe | Örnekler |
|---|---|
| Özne | Bir kullanıcı adı, bir client ID, bir rol veya "herkes" |
| Eylem | Okuma (abone olma ve alma), yazma (yayınlama) veya her ikisi |
| Topic filtresi | factory/line1/#, devices/+/cmd, devices/%u/# |
| Karar | İzin ver veya reddet |
Kurallar her işlemin topic'iyle eşleştirilir. Abonelikler için birçok broker istenen filtrenin kendisini kontrol eder; böylece devices/sensor-01/# okumasına izin verilen bir istemci, daha geniş bir devices/# aboneliğini kontrolden kaçıramaz.
Mosquitto MQTT ACL Örneği
Mosquitto, dosya tabanlı ACL'si kısa ve okunabilir olduğu için kullanışlı bir referanstır. Kimlik doğrulama ve ACL dosyası mosquitto.conf içinde etkinleştirilir:
# mosquitto.conf
listener 8883
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl
ACL dosyasının kendisi:
# /etc/mosquitto/acl
# Herhangi bir "user" satırından önceki kurallar anonim istemcilere uygulanır (burada yok)
# Tüm telemetriyi okuyan ve komut gönderen bir backend servisi
user backend
topic read factory/+/+/telemetry/#
topic write factory/+/+/cmd/#
# Yalnızca okuyabilen bir pano
user dashboard
topic read factory/#
# Pattern kuralları her kullanıcıya uygulanır.
# %u = kullanıcı adı, %c = client ID
pattern write factory/+/%c/telemetry/#
pattern read factory/+/%c/cmd/#
pattern write factory/+/%c/status
Bu kurallarla cnc-07 client ID'siyle bağlanan bir cihaz factory/line2/cnc-07/telemetry/spindle topic'ine yayın yapabilir ve factory/line2/cnc-07/cmd/stop mesajını alabilir, ancak başka bir makinenin komutlarını okuyamaz veya başka bir makine adına yayın yapamaz. Pattern kuralları, cihaz başına bir giriş gerektirmeden binlerce cihaza ölçeklenir; client ID'yi topic yoluna koymanın temel nedeni de budur. Mosquitto ayrıca topic deny satırlarını ve roller ile gruplar içeren bir dinamik güvenlik eklentisini destekler; Mosquitto dokümantasyonu her ikisini de ele alır.
Dosyayı düzenledikten sonra broker'ı yeniden yükleyin, ardından test edin:
# İzin verilir: cnc-07 kendi telemetrisini yayınlar
mosquitto_pub -h localhost -p 8883 --cafile ca.crt -V mqttv5 \
-i cnc-07 -u cnc-07 -P "$PW" -t 'factory/line2/cnc-07/telemetry/spindle' -m 1200 -q 1
# Reddedilir: cnc-07, cnc-08 adına yayın yapar
mosquitto_pub -h localhost -p 8883 --cafile ca.crt -V mqttv5 \
-i cnc-07 -u cnc-07 -P "$PW" -t 'factory/line2/cnc-08/telemetry/spindle' -m 1200 -q 1
Bir İstemci Reddedildiğinde Ne Olur?
Reddedilen işlemler her zaman belirgin bir hata üretmez; ACL sorunlarının hata ayıklamasının bu kadar zor olmasının nedeni budur.
| İşlem | MQTT 3.1.1 | MQTT 5.0 |
|---|---|---|
| SUBSCRIBE reddedildi | SUBACK dönüş kodu 0x80 (başarısız) | SUBACK reason code 0x87 Not authorized |
| PUBLISH QoS 0 reddedildi | Sessizce düşürülür | Sessizce düşürülür |
| PUBLISH QoS 1/2 reddedildi | Genellikle onaylanır ve düşürülür | PUBACK/PUBREC 0x87 taşıyabilir, broker'a bağlı |
Pratik hata ayıklama ipuçları:
- SUBACK kodlarını her zaman inceleyin. Birçok kütüphane bunları bir callback'te sunar; başlangıçta günlüğe kaydedin.
- Test ederken MQTT 5 ve QoS 1 kullanın. Onaylardaki reason code'lar retleri görünür kılar.
- Cihazın kimliğiyle test edin. Bir yönetici hesabıyla test etmek, cihazın kuralları hakkında hiçbir şey kanıtlamaz.
- Broker günlüğünü kontrol edin. Çoğu broker reddedilen yayınları ve abonelikleri debug düzeyinde günlüğe kaydeder.
Basit Yetkilendirme için Topic Namespace Tasarımı
İyi ACL'ler iyi topic'lerle başlar. Kimlik ve yön topic yolunda görünürse kurallar birkaç kalıba iner. Görünmezse uzun bir özel durumlar listesiyle karşı karşıya kalırsınız.
Kimliği Yola Koyun
Client ID'yi veya cihaz ID'sini sabit bir seviyeye ekleyin: factory/<line>/<deviceId>/.... %c gibi pattern kuralları yalnızca kimlik tam bir topic seviyesi olduğunda çalışır.
Yönleri Ayırın
Yukarı akan veri ve aşağı akan komutlar için ayrı dallar kullanın: .../telemetry, .../status, .../cmd. Cihazlar ilk ikisinde yazma, üçüncüsünde okuma yetkisi alır.
Tenant'ları veya Müşterileri En Üstte Ayırın
Bir broker birden fazla müşteriye hizmet veriyorsa müşteriyi ilk seviye yapın: <tenant>/.... Böylece her tenant'ın kimlik bilgileri tek bir alt ağaçla sınırlanır.
Paylaşılan Veriyi Açıkça Adlandırılmış Bir Dalda Tutun
Tüm cihazlara yayınlanan yapılandırma, cihazlar için salt okunur erişimle broadcast/... veya config/... altına gider.
MQTT topic hiyerarşisi örnekleri yazısı bu ilkeler üzerine kurulmuş eksiksiz ağaçlar gösterir.
ACL Tasarımı Kontrol Listesi
- Varsayılan olarak reddedin; yalnızca her rolün ihtiyaç duyduğuna izin verin.
- Cihazlara kendi telemetri ve durum topic'lerinde yazma, kendi komutlarında okuma yetkisi verin, başka hiçbir şey vermeyin.
- Panolara salt okunur erişim verin.
- Backend servislerine komut dallarında yazma yetkisi verin ve bu kimlik bilgilerini kimin tuttuğunu denetleyin.
- Bir cihaz kimlik bilgisine asla
#vermeyin. - Kural dosyasını veya rol tanımlarını sürüm kontrolünde tutun ve değişiklikleri gözden geçirin.
- Her değişiklikten sonra her rolü gerçek kimlik bilgileriyle test edin.
ConnectMQ'da Yetkilendirme
ConnectMQ topic başına ACL sağlamaz. ConnectMQ'da izolasyon tenant düzeyinde çalışır: her müşterinin broker trafiği diğer tüm tenant'lardan izole edilir, kimlik bilgileri broker başına oluşturulur ve client ID'ler verilen kullanıcı adı ve şifreye bağlanır; böylece bir istemci başka bir istemcinin kimliğini sahiplenemez. Plan başına kotalar, flood koruması ve tekrarlanan başarısız girişlerden sonra IP engelleme, hatalı davranan bir istemcinin yapabileceklerini sınırlar.
Bunun tasarım açısından anlamı:
- Güvenlik sınırınız olarak ayrı broker'lar kullanın. İki istemci grubu birbirinin verisini asla görmemeliyse, topic kurallarına güvenmek yerine onları farklı broker'lara yerleştirin. Bu sınırın fiziksel de olması gerektiğinde Dedicated plan size izole bir küme sağlar.
- Güvenilmeyen istemcileri broker'dan uzak tutun. Tarayıcı kullanıcıları ve üçüncü taraflar, broker kimlik bilgilerini tutan ve onlar adına neyin yayınlanacağına karar veren backend'inizle konuşmalıdır.
- Topic'leri ACL'ler ileride gelebilecekmiş gibi tasarlayın. Yolda kimlik bulunması ve ayrı komut dalları şimdi hiçbir maliyet getirmez ve sistemin bir kısmını topic kuralları olan bir broker'a taşırsanız seçeneklerinizi açık tutar.
- Komutları cihazda doğrulayın. Bir cihaz, broker'ın yetkilendirmeyi nasıl yaptığından bağımsız olarak, harekete geçmeden önce bir komutun doğru biçimlendirilmiş ve beklenen bir komut olduğunu kontrol etmelidir.
Tenant izolasyonu ile topic disiplininin bu birleşimi birçok filoyu iyi kapsar. Projeniz tek bir paylaşılan namespace içinde cihaz başına topic kısıtlamaları gerektiriyorsa, sistemin o kısmı için topic düzeyinde ACL destekleyen bir broker planlayın. Daha geniş bir bakış için MQTT güvenliği en iyi uygulamaları ve MQTT güvenli mi yazılarına bakın.
ConnectMQ ile Başlayın
Cihazlarınızı tenant izolasyonu, TLS, client ID'lere bağlı oluşturulmuş kimlik bilgileri ve başarısız girişler için IP engelleme sunan bir barındırılan MQTT broker üzerinde çalıştırın. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun ve topic tasarımlarınızı önce herkese açık MQTT test broker'ı üzerinde prototipleyin.
Sık Sorulan Sorular
MQTT ACL nedir?
Bir broker'a hangi kullanıcıların veya istemcilerin hangi topic filtrelerine yayın yapabileceğini ya da abone olabileceğini söyleyen bir kurallar listesidir. İstemcinin kimliği doğrulandıktan sonra kontrol edilir.
ConnectMQ topic başına ACL destekliyor mu?
Hayır. ConnectMQ tenant'ları birbirinden izole eder ve client ID'leri verilen kullanıcı adı ve şifre kimlik bilgilerine bağlar, ancak bir broker içinde topic başına okuma ve yazma kuralları uygulamaz.
Reddedilen yayınım neden hata döndürmüyor?
MQTT 3.1.1'de broker'ın reddedilen bir yayını bildirmesinin bir yolu yoktur; bu yüzden sessizce düşürülür. MQTT 5 broker'ları QoS 1 ve 2 onaylarında 0x87 reason code'unu döndürebilir.
ACL kuralları kullanıcı adını mı yoksa client ID'yi mi kullanmalı?
Cihaz başına benzersiz olan ve istemci tarafından serbestçe seçilemeyen tanımlayıcıyı kullanın. Broker client ID'leri kimlik bilgilerine bağlıyorsa ikisi de çalışır; aksi takdirde kullanıcı adını tercih edin.
