AB Siber Dayanıklılık Yasası IoT: MQTT İçin Anlamı

AB Siber Dayanıklılık Yasası (Cyber Resilience Act, CRA), Avrupa Birliği'nde bağlı ürünlerin nasıl tasarlandığını, piyasaya sunulduğunu ve bakımının yapıldığını değiştiriyor. Bu makale, cihazları MQTT üzerinden iletişim kuran IoT üreticileri için AB Siber Dayanıklılık Yasası'nın ne anlama geldiğini; güvenli varsayılanlar, güncellemeler, zafiyet yönetimi ve dokümantasyon başlıklarında özetler ve mesajlaşma katmanınızdaki hangi mühendislik kararlarının bu çalışmayı desteklediğini gösterir. Bu teknik bir genel bakıştır, hukuki tavsiye değildir; yükümlülüklerinizi yetkin bir hukuk danışmanıyla ve resmi metinle teyit edin.

Siber Dayanıklılık Yasası Nedir?

CRA, "dijital unsurlar içeren ürünler", yani kullanım amacı bir cihaza veya ağa veri bağlantısı içeren donanım ve yazılım ürünleri için yatay siber güvenlik gereksinimleri belirleyen bir AB tüzüğüdür. Aralık 2024'te yürürlüğe girmiştir ve yükümlülükleri aşamalı olarak uygulanır: aktif olarak istismar edilen zafiyetlere ve ciddi olaylara ilişkin bildirim yükümlülükleri Eylül 2026'dan, diğer yükümlülüklerin çoğu ise Aralık 2027'den itibaren geçerlidir.

IoT ekipleri için önemli nokta kapsamdır. Bir ağa bağlanan ve AB pazarına sunulan bir sensör, gateway, akıllı cihaz veya endüstriyel kontrolör, firmware'i ve içerdiği yazılım bileşenleriyle birlikte büyük olasılıkla kapsam dahilindedir. Belirli tıbbi ve otomotiv ürünleri gibi kendi kurallarına sahip bazı sektörler farklı şekilde ele alınır.

Ürünler kategorilere ayrılır. Çoğu, üreticilerin uygunluğu kendilerinin değerlendirebildiği varsayılan kategoriye girer. "Önemli" veya "kritik" olarak listelenen ürünler daha sıkı değerlendirme yollarıyla karşı karşıyadır. Cihazınızın hangi kategoriye girdiği, ne kadar üçüncü taraf katılımı gerektiğini belirler.

Üreticiler İçin Temel Yükümlülükler

Tüzüğün temel gereksinimleri iki gruba ayrılır: ürünün özellikleri ve zafiyetlerin ele alınmasına yönelik süreçler. IoT için sadeleştirilmiş hali:

Alan	CRA'nın beklentisi (sadeleştirilmiş)	Bir MQTT cihazı için anlamı
Varsayılan olarak güvenli	Ürünler güvenli bir yapılandırmayla ve bilinen istismar edilebilir zafiyetler olmadan sunulur	Varsayılan parola yok, TLS varsayılan olarak açık, debug topic'leri etkin değil
Erişim kontrolü	Uygun kimlik doğrulama ve kimlik yönetimiyle yetkisiz erişime karşı koruma	Cihaz başına benzersiz kimlik bilgileri, anonim broker bağlantısı yok
Gizlilik	Saklanan ve iletilen verilerin, örneğin şifrelemeyle korunması	TLS üzerinden MQTT, korumalı kimlik bilgisi saklama
Bütünlük	Verilerin, komutların ve firmware'in yetkisiz değişikliğe karşı korunması	İmzalı firmware, doğrulanmış komutlar
Veri minimizasyonu	Yalnızca amaçlanan kullanım için gereken verilerin işlenmesi	Kullanım senaryosunun gerektirdiğini publish edin, fazlasını değil
Kullanılabilirlik ve dayanıklılık	Hizmet reddi koşulları dahil temel işlevlerin çalışmaya devam etmesi	Backoff, tamponlama, broker sınırları altında düzgün davranış
Saldırı yüzeyini sınırlama	Açık arayüzlerin en aza indirilmesi	İçe açık port yok; yalnızca dışa dönük MQTT
Güvenlik güncellemeleri	Destek süresi boyunca, ideal olarak otomatik ve özellik güncellemelerinden ayrı güncellemeler sağlanması	Bağlantınız üzerinden çalışan güvenli bir OTA yolu
Zafiyet yönetimi	Zafiyetlerin belirlenmesi, belgelenmesi ve düzeltilmesi; koordineli ifşa politikası	MQTT kütüphanelerini kapsayan SBOM, bir ifşa iletişim noktası, bir yama süreci
Bildirim	Aktif olarak istismar edilen zafiyetlerin ve ciddi olayların belirlenen süreler içinde bildirilmesi	Tespit, önceliklendirme ve bildirim için bir iç süreç
Dokümantasyon	Teknik dokümantasyon, kullanıcı bilgileri, destek süresi	Cihazın nasıl bağlandığını ve kullanıcıların onu nasıl güvenceye alacağını belgeleyin

MQTT Katmanında Güvenli Varsayılanlar

Geçmişteki pek çok IoT sorunu güvensiz varsayılanlardan kaynaklandı. MQTT açısından CRA'nın yönü somut tasarım kararlarına dönüşür:

Paylaşılan veya varsayılan kimlik bilgisi yok. Her cihaz üretim veya ilk kurulum sırasında benzersiz kimlik bilgileri alır. Bkz. güvenli IoT cihaz provizyonu.
Varsayılan olarak etkin, sertifika doğrulamalı TLS. Üretim firmware'inde "insecure" mod yok.
Yalnızca dışa dönük bağlantılar. Cihaz broker'a bir bağlantı açar; içe dönük MQTT dinlemez.
Gerçek veriler için herkese açık broker yok. Herkese açık test broker'ları geliştirmede faydalıdır, ancak üretim firmware'i özel ve kimlik doğrulamalı bir broker'a bağlanmalıdır.
Minimal topic'ler. Tanılama dökümleri, kimlik bilgileri veya gereksiz kişisel veriler publish etmeyin.
Güvenli komut işleme. Harekete geçmeden önce her komutu bir izin listesine göre doğrulayın.

WiFiClientSecure ve PubSubClient kullanan ESP32 firmware'inde bu şöyle görünür:

#include <WiFi.h>
#include <WiFiClientSecure.h>
#include <PubSubClient.h>

// Broker'ı doğrulamak için kullanılan PEM formatında ISRG Root X1 (Let's Encrypt kökü)
static const char ROOT_CA[] PROGMEM = R"EOF(
-----BEGIN CERTIFICATE-----
...paste ISRG Root X1 here...
-----END CERTIFICATE-----
)EOF";

// Cihaz başına benzersiz; üretimde korumalı depolamadan yüklenir
extern const char* DEVICE_CLIENT_ID;  // YOUR_CLIENT_ID
extern const char* DEVICE_USERNAME;   // YOUR_USERNAME
extern const char* DEVICE_PASSWORD;   // YOUR_PASSWORD

WiFiClientSecure net;
PubSubClient mqtt(net);
unsigned long nextAttempt = 0;
unsigned long backoffMs = 1000;

void connectMqtt() {
  if (mqtt.connected() || millis() < nextAttempt) return;
  if (mqtt.connect(DEVICE_CLIENT_ID, DEVICE_USERNAME, DEVICE_PASSWORD)) {
    backoffMs = 1000;
  } else {
    nextAttempt = millis() + backoffMs + random(0, 1000);  // jitter'lı backoff
    backoffMs = min(backoffMs * 2, 300000UL);
  }
}

void setup() {
  WiFi.begin("YOUR_WIFI_SSID", "YOUR_WIFI_PASSWORD");
  while (WiFi.status() != WL_CONNECTED) delay(500);
  net.setCACert(ROOT_CA);               // sunucuyu doğrula; asla setInsecure() çağırma
  mqtt.setServer("YOUR_BROKER_HOST", 8883);
}

void loop() {
  connectMqtt();
  mqtt.loop();
}

Güvenli varsayılanlar açısından önemli ayrıntılar görülebilir: sertifika doğrulaması açık, kimlik bilgileri sketch gövdesine sabit kodlanmamış ve broker'ı yüklenmeyle boğmayan bir yeniden bağlanma stratejisi. ESP32 MQTT eğitimi publish döngüsünün tamamını gösterir.

Güncellemeler ve Zafiyet Yönetimi

CRA, bir ürün piyasaya sunulduktan sonra olanlara önemli bir ağırlık verir. MQTT cihazlarında bağlantı katmanı da bu hikâyenin bir parçasıdır:

Bileşenlerinizi tanıyın. MQTT istemci kütüphanenizi, TLS kütüphanenizi ve sürümlerini listeleyen bir yazılım malzeme listesi (SBOM) tutun. Bir güvenlik bülteni yayımlandığında, etkilenen kodu hangi ürünlerin kullandığını saatler içinde bilmeniz gerekir.
Bir güncelleme kanalınız olsun. Pek çok ekip, bir güncellemenin mevcut olduğunu bildirmek için MQTT'yi, imzalı imajı indirmek için HTTPS'i kullanır. Mekanizma ne olursa olsun, kimlik doğrulamalı ve bütünlük korumalı olmalıdır.
Güvenlik güncellemelerini ayırın. Mümkün olduğunda güvenlik düzeltmelerini özellik sürümlerinden bağımsız olarak yayımlayın.
Bir ifşa politikası yayımlayın. Araştırmacılara sorunları bildirmeleri için net bir yol sunun.
Bildirime hazırlanın. Zafiyetleri ve olayları kimin önceliklendireceğine ve bildirimlerin gerekli süreler içinde yetkililere nasıl ulaşacağına karar verin.

Yaygın MQTT güvenlik açıkları genel bakışı, istemci kütüphanelerinde neyin takip edileceği konusunda faydalı bir başlangıç noktasıdır.

Broker Nereye Oturur?

CRA, yükümlülükleri ürünün üreticisine yükler. Belirli bir broker'ı seçmek bir ürünü uyumlu hale getirmez ve hiçbir broker sağlayıcısı bu sorumluluğu devralamaz. Backend'in yapabileceği şey, güvenli tasarımları uygulamayı ve belgelemeyi kolaylaştırmaktır.

ConnectMQ, kendi risk değerlendirmenizin parçası olarak teknik dokümantasyonunuzda referans verebileceğiniz yetenekler sunar:

Let's Encrypt sertifikasıyla 8883'te TLS üzerinden MQTT ve 8084'te güvenli WebSocket; böylece cihazlar sunucuyu standart bir kök sertifikayla doğrulayabilir.
Oluşturulan kimlik bilgileriyle kimlik doğrulamalı özel broker'lar ve bu kimlik bilgilerine bağlı client ID'ler.
Çok kiracılı izolasyon, Dedicated planlarda izole bir küme veya BYOC ile kendi bulut hesabınıza dağıtım.
MQTT 5 reason code 0x97 ile bildirilen plan bazlı kotalar, flood koruması ve tekrarlanan başarısız oturum açma denemelerinden sonra IP engelleme; bunlar kötüye kullanım altında kullanılabilirliği destekler.
Anormal davranışı tespit etmeye yardımcı olmak için $SYS/broker/connection/{clientId}/state üzerinden bağlantı durumu ve portal eşik uyarıları.

ConnectMQ'yu veya herhangi bir broker'ı bir CRA uyumluluk çözümü olarak tanımlamayın. Onu mimarinizde bir bileşen olarak belgeleyin, güvenlik özelliklerini listeleyin ve cihaz tarafındaki kontrollerin sorumluluğunu üstlenmeye devam edin. Yönetilen MQTT broker rehberi paylaşılan sorumluluk ayrımını açıklar.

MQTT Cihazları İçin Pratik Bir CRA Hazırlık Kontrol Listesi

Ürününüzün kapsam dahilinde olup olmadığını ve hangi kategorinin geçerli olduğunu teyit edin.
MQTT veri akışlarını kapsayan bir siber güvenlik risk değerlendirmesi yapın ve belgeleyin.
Varsayılan ve paylaşılan kimlik bilgilerini kaldırın; cihaz başına benzersiz kimlikler sağlayın.
Üretim firmware'inde sunucu sertifikası doğrulamalı TLS'i zorunlu kılın.
Cihazların yalnızca dışa dönük bağlantı kurduğundan ve gereksiz hiçbir arayüz açmadığından emin olun.
Alınan tüm komutları doğrulayın ve neleri değiştirebileceklerini sınırlayın.
Dayanıklılık için yeniden bağlanma backoff'u ve çevrimdışı tamponlama uygulayın.
MQTT ve TLS kütüphanelerini içeren bir SBOM tutun.
İmzalı, kimlik doğrulamalı bir güncelleme mekanizması oluşturun ve test edin.
Bir zafiyet ifşa politikası yayımlayın ve bildirim sürecini tanımlayın.
Destek süresini tanımlayın ve duyurun.
Güvenli kurulum ve kullanımdan kaldırma konusunda kullanıcı dokümantasyonu hazırlayın.

Daha geniş bağlam için MQTT güvenliği en iyi uygulamaları ve IoT mesajlaşmasında sıfır güven yazıları aynı kontrollerin çoğunu mühendislik bakış açısıyla ele alır. Resmi rehberlik ve tüzük metni Avrupa Komisyonu tarafından yayımlanır.

ConnectMQ Üzerinde Güvenli Bağlantı Kurun

Kontrol listesinin geri kalanı üzerinde çalışırken bağlantı katmanıyla başlayın. app.connectmq.com adresinde ücretsiz Serverless planla özel bir broker oluşturun (kredi kartı gerekmez), bir geliştirme cihazını benzersiz kimlik bilgileriyle TLS üzerinden ona yönlendirin ve herkese açık MQTT test broker'ını yalnızca tek kullanımlık denemeler için kullanın. İzolasyona ihtiyaç duyduğunuzda bulut MQTT broker rehberi dağıtım modellerini karşılaştırır.

Sık Sorulan Sorular

Siber Dayanıklılık Yasası IoT cihazım için geçerli mi?

Bir cihaza veya ağa bağlanan ve AB pazarına sunulan, dijital unsurlar içeren bir ürünse, sektöre özgü kurallar onu kapsam dışında bırakmadıkça büyük olasılıkla geçerlidir. Ürününüzün kapsamını ve kategorisini bir hukuk danışmanıyla teyit edin.

CRA yükümlülükleri ne zaman uygulanmaya başlıyor?

Aktif olarak istismar edilen zafiyetlere ve ciddi olaylara ilişkin bildirim yükümlülükleri Eylül 2026'dan, diğer yükümlülüklerin çoğu ise Aralık 2027'den itibaren geçerlidir.

Güvenli bir MQTT broker kullanmak ürünümü CRA uyumlu yapar mı?

Hayır. Uyumluluk, ürünün tamamı için üreticinin sorumluluğundadır. Güvenli bir broker tasarımınızı destekler; ancak cihaz firmware'i, güncellemeler, zafiyet yönetimi ve dokümantasyon sizin işiniz olmaya devam eder.

TLS üzerinden MQTT, CRA'nın gizlilik gereksinimini karşılamak için yeterli mi?

TLS, aktarım halindeki veriyi korur ve bu önemli bir parçadır. Yine de cihazda saklanan kimlik bilgilerini ve verileri korumanız ve risk profiliniz için ek önlemlerin gerekip gerekmediğini değerlendirmeniz gerekir.

AB Siber Dayanıklılık Yasası ve IoT: MQTT Cihazları İçin Ne Anlama Geliyor?