Sıfır Güven IoT: Zero Trust İlkelerini MQTT Mesajlaşmasına Uygulamak

Sıfır güven (zero trust) IoT, bağlı cihazlara basit bir kural uygular: hiçbir cihaza, ağa veya mesaja yalnızca bulunduğu konum nedeniyle güvenilmez. Bu makale sıfır güven ilkelerini cihaz kimliği, en az ayrıcalık, şifreli aktarım ve sürekli doğrulama konularında somut MQTT tasarım kararlarına dönüştürür ve yönetilen bir broker'ın bir katman olarak nereye oturduğunu gösterir. Sonunda mevcut bir cihaz filosuna uygulayabileceğiniz aşamalı bir kontrol listesine sahip olacaksınız.

Sıfır Güven IoT İçin Ne Anlama Gelir?

Sıfır güven, örneğin NIST SP 800-207'de tanımlanan ve "güvenilir iç ağ" düşüncesini kimlik ve bağlama dayalı, istek bazında kararlarla değiştiren bir mimari yaklaşımdır. Temel fikirleri şunlardır:

• Ağ konumuna göre asla güvenme. Fabrika LAN'ında veya VPN'de olmak bir istemciyi güvenilir kılmaz.
• Açıkça doğrula. Her bağlantı güçlü ve benzersiz bir kimlikle doğrulanır.
• En az ayrıcalık. Her kimlik yalnızca ihtiyaç duyduğu erişimi, ihtiyaç duyduğu süre boyunca alır.
• İhlali varsay. Tek bir ele geçirilmiş cihazın veya hesabın sınırlı zarar vereceği şekilde tasarla.
• Sürekli doğrulama. Oturum açıldıktan sonra davranışı izle ve anomalilere tepki ver.

IoT bu ilkeleri aynı anda hem zorlaştırır hem de daha önemli kılar. Cihazlar çok sayıdadır, fiziksel olarak erişilebilirdir, CPU ve bellek açısından kısıtlıdır ve çoğu zaman ajan çalıştıramaz veya sık güncelleme alamaz. Öte yandan dar ve öngörülebilir desenlerle iletişim kurarlar; bu da anomalileri fark etmeyi kolaylaştırır.

MQTT Neden Sıfır Güvene Uygundur?

MQTT'nin sıfır güven tasarımıyla örtüşen birkaç özelliği vardır:

• Her istemci tek bir noktada kimlik doğrular: doğal bir politika uygulama noktası (policy enforcement point) görevi gören broker.
• İstemciler dışarıya doğru bağlanır; bu yüzden cihazların ağdan erişilebilecek dinleme portlarına ihtiyacı yoktur.
• Topic'ler bir hiyerarşi oluşturur; bu hiyerarşi sahipliği ve izinleri yansıtabilir.
• Bağlantı durumu gözlemlenebilir; cihazlar düştüğünde gönderilen last will mesajları da buna dahildir.

Broker mimarinin tamamı değildir. Cihaz sıkılaştırması, ağ kontrolleri ve uygulama düzeyindeki denetimlerle birlikte birkaç uygulama noktasından yalnızca biridir. Broker'ın rolünü hatırlamak için bir MQTT broker'ın ne yaptığı yazısına bakın.

Sıfır Güven İlkelerini MQTT Kontrollerine Eşlemek

Cihaz Kimliği: Temel

Sıfır güvende erişim kararlarının temeli olarak ağ konumunun yerini kimlik alır. MQTT cihazları için bu şu anlama gelir:

1. Cihaz başına bir kimlik. Paylaşılan kimlik bilgileri tek bir cihazı iptal etmeyi veya davranışı bir cihaza atfetmeyi imkânsız kılar.
2. Bağlı tanımlayıcılar. Bir client ID, kimlik bilgilerine bağlı olmalıdır; böylece bir ID'yi bilmek cihazın kimliğine bürünmek için yeterli olmaz. ConnectMQ üzerinde client ID'ler verilen kimlik bilgilerine bağlıdır.
3. Korunan gizli bilgiler. Mümkün olduğunda kimlik bilgilerini secure element'lerde, şifreli flash'ta veya işletim sistemi düzeyindeki secret store'larda saklayın; bkz. cihazlarda MQTT kimlik bilgilerini güvenceye alma.
4. Güvenli provizyon. Kimlikleri aktarım sırasında veya kaynak kontrolünde açığa çıkarmadan cihazlara yükleyin; güvenli IoT cihaz provizyonu desenleri ele alır.
5. Rotasyon ve iptal. Kimlik bilgilerini filo genelinde nasıl değiştireceğinizi ihtiyaç duymadan önce planlayın.

İstemci sertifikaları (mutual TLS), broker'ın desteklediği yerlerde güçlü ve donanım dostu bir kimlik sağlar. Cihaz başına benzersiz olan ve yalnızca TLS üzerinden gönderilen kullanıcı adı ve parola bilgileri pratik bir temel oluşturur.

Mesaj Yolunda En Az Ayrıcalık

En az ayrıcalık şu soruyu sorar: Bu cihaz bir saldırganın kontrolünde olsaydı ne yapabilirdi?

• Bir sıcaklık sensörü yalnızca kendi telemetri topic'ine publish edebilmeli, başka hiçbir şey yapamamalıdır.
• Bir dashboard yalnızca gösterdiği verileri okumalıdır.
• Bir komut servisi yalnızca komut topic'lerine yazmalı, cihazlar da aldıklarını doğrulamalıdır.
• Test ve geliştirme istemcileri asla üretime bağlanmamalıdır.

Kendi barındırdığınız broker'lar bunu topic bazlı ACL'lerle ifade edebilir. Bir broker topic bazlı kural sunmadığında segmentasyon aynı hedefe daha kaba bir düzeyde ulaşır: üretim, staging ve her güven alanı için ayrı broker'lar veya tenant'lar. ConnectMQ çok kiracılı izolasyonu zorunlu kılar; Dedicated ve BYOC dağıtımları ise altyapı düzeyinde ayrım ekler. Bunu uygulama tarafındaki doğrulamayla birleştirin; böylece bir mesaja yalnızca doğru topic'e geldiği için asla güvenilmez.

Kanalı Şifreleyin ve Doğrulayın

Sıfır güven, ağın düşmanca olduğunu varsayar. Her MQTT bağlantısı TLS kullanmalı ve her istemci sunucu sertifikasını ve hostname'i doğrulamalıdır. Şifreleyen ama doğrulamayan bir bağlantının araya girilerek ele geçirilmesi mümkündür. Güvenli WebSocket üzerinden minimal bir MQTT.js örneği:

import mqtt from "mqtt";

const client = mqtt.connect("wss://YOUR_BROKER_HOST:8084/mqtt", {
  clientId: "YOUR_CLIENT_ID",
  username: "YOUR_USERNAME",
  password: "YOUR_PASSWORD",
  protocolVersion: 5,
  rejectUnauthorized: true, // sertifika doğrulamasını asla devre dışı bırakmayın
  reconnectPeriod: 5000,
});

client.on("connect", () => {
  client.subscribe("connectmq/site1/dashboard/#", { qos: 1 });
});

client.on("message", (topic, payload) => {
  // Her payload'u güvenilmeyen girdi olarak ele alın
  try {
    const data = JSON.parse(payload.toString());
    if (typeof data.value !== "number") return;
    console.log(topic, data.value);
  } catch {
    console.warn("rejected malformed payload on", topic);
  }
});

ConnectMQ, Let's Encrypt sertifikasıyla 8883'te TLS ve 8084'te güvenli WebSocket sunar; böylece standart istemciler özel CA dosyaları olmadan sertifikayı doğrular. İstemci seçeneklerinin ayrıntıları için MQTT TLS yapılandırması yazısına bakın. Verinin aracılardan bile gizli kalması gerektiğinde üstüne MQTT payload şifreleme ekleyin.

Sürekli Doğrulama

Bağlantı anındaki kimlik doğrulama bir anlık görüntüdür. Sürekli doğrulama, davranışın beklentilerle eşleştiğini kontrol etmeye devam eder:

• Bağlantı durumu: Cihazların ne zaman bağlanıp ayrıldığını görmek için broker'da $SYS/broker/connection/{clientId}/state topic'ine subscribe olun veya last will mesajlarını kullanın.
• Başarısız oturum açma denemeleri: Tekrarlanan başarısızlıklar tahmin denemelerine veya yanlış yapılandırmaya işaret eder. ConnectMQ, tekrarlanan başarısız oturum açma denemelerinden sonra IP'leri engeller.
• Hız anomalileri: Dakikada bir raporlayan ve birdenbire her 100 ms'de publish etmeye başlayan bir sensör ya bozulmuştur ya da ele geçirilmiştir. Reason code 0x97 ile kotalar ve flood koruması hasarı sınırlar.
• Payload anomalileri: Fiziksel sınırların dışındaki değerler bir uyarıyı hak eder. ConnectMQ'nun eşik tabanlı uyarı kuralları ve uyarı logu burada yardımcı olur.
• Yanıt: Bir kimlik bilgisini kimin ve ne kadar hızlı iptal edeceğine önceden karar verin.

İhlali Varsayın: Etki Alanını Sınırlayın

Bir cihazın ele geçirileceğini varsayarak tasarlayın:

• Yalnızca o cihazı iptal edebilmeniz için benzersiz kimlik bilgileri.
• Filonun verilerini okuyamaması için dar topic kapsamı.
• Sahte bir komutun güvensiz davranışa yol açmaması için alıcı tarafta doğrulanan komutlar.
• Broker'ı boğamaması için hız sınırları.
• Bir ortamdaki ihlalin diğerine ulaşamaması için ayrı tenant'lar.

Aşamalı Bir Sıfır Güven IoT Kontrol Listesi

Her şeyi aynı anda yapmanız gerekmez. Şu aşamaları izleyin:

1. Görünürlük: Her cihazın, client ID'sinin ve neye publish ve subscribe olduğunun envanterini çıkarın.
2. Şifreleme: İnternete açık tüm trafiği sertifika doğrulamalı TLS'e taşıyın.
3. Kimlik: Paylaşılan hesapları cihaz başına benzersiz, iptal edilebilir kimlik bilgileriyle değiştirin.
4. Segmentasyon: Üretim, staging ve test broker'larını veya tenant'larını ayırın.
5. En az ayrıcalık: Her kimliğin topic'lerini daraltın; komut kimliklerini ayırın.
6. Doğrulama: Subscriber'larda her payload'u doğrulayın.
7. İzleme: Bağlantı durumunu, başarısız oturum açma denemelerini ve hız anomalilerini uyarılarla takip edin.
8. Yanıt: Kimlik bilgisi iptalini belgeleyin ve prova edin.

Bu aşamalar MQTT için IEC 62443 gibi ilgili çerçeveleri de destekler. Genel sıkılaştırma için MQTT güvenliği en iyi uygulamaları yazısına bakın.

ConnectMQ Üzerinde Sıfır Güven Temeli Kurun

Yönetilen bir MQTT broker, altyapı işletmeden size birkaç sıfır güven yapı taşı sunar: kimlik doğrulamalı özel broker'lar, varsayılan olarak TLS, tenant izolasyonu, kotalar, flood koruması ve IP engelleme. app.connectmq.com adresinde ücretsiz Serverless planla, kredi kartı olmadan bir tane oluşturun ve kontrol listesinin ikinci aşamasıyla başlayın. Daha güçlü izolasyon için dağıtım modellerini karşılaştırmak isterseniz bulut MQTT broker rehberini okuyun.

Sık Sorulan Sorular

Kısıtlı IoT cihazları gerçekten sıfır güven uygulayabilir mi?

Evet, belirli sınırlar içinde. Benzersiz kimlik bilgileri, TLS ve dar topic kapsamı ESP32 gibi mikrodenetleyicilerde uygulanabilir; sürekli davranış analizi gibi daha ağır kontroller ise broker ve backend tarafında çalışır.

VPN, sıfır güven IoT ile uyumlu mu?

Bir VPN ağ katmanı ekleyebilir, ancak sıfır güven VPN üyeliğini güvenin kanıtı olarak kabul etmez. Cihazlar yine de tek tek kimlik doğrulamalı ve broker'a TLS kullanmalıdır.

MQTT için sıfır güvene doğru ilk adım nedir?

Tüm bağlantıları doğrulanmış TLS ile şifrelemek ve her cihaza benzersiz kimlik bilgileri vermek. Bu iki değişiklik en büyük riskleri ortadan kaldırır ve sonraki aşamaları mümkün kılar.

Tenant izolasyonu cihaz bazlı izinlerin yerini tutar mı?

Hayır. Tenant izolasyonu müşterileri veya ortamları birbirinden ayırır; cihaz bazlı kapsam ise her kimliğin tek bir ortam içinde neler yapabileceğini sınırlar. Broker'ınızın desteklediği yerlerde her iki katmanı da kullanın.