MQTT veri yerelleştirme (data residency), IoT mesajlarınızın cihazdan uygulamaya giderken nerede işlendiğini ve saklandığını bilmek ve kontrol etmekle ilgilidir. Bu yazı, bir MQTT sisteminin hangi parçalarının veriye dokunduğunu, genellikle hangi mevzuat ve sözleşme sorularının geçerli olduğunu ve bölge seçimi ile kendi bulutunuzu getirin (BYOC) dağıtımlarının bunları karşılamanıza nasıl yardımcı olduğunu açıklıyor. Bu, hukuki tavsiye değil pratik bir mühendislik rehberidir; kararlar için hukuk veya uyumluluk ekibinizi sürece dahil edin.
Veri Yerelleştirme MQTT İçin Ne Anlama Gelir?
Veri yerelleştirme, belirli verilerin bir ülke veya Avrupa Ekonomik Alanı gibi belirli bir coğrafya içinde saklanması ya da işlenmesi gerekliliğidir. İlgili terimler çoğu zaman gevşek biçimde kullanılır:
- Veri yerelleştirme (data residency): verinin fiziksel olarak nerede bulunduğu.
- Veri egemenliği (data sovereignty): veriye hangi yargı bölgesinin yasalarının uygulandığı.
- Veri lokalizasyonu (data localization): verinin bir ülkede kalması gerektiğine dair yasal zorunluluk.
Bir MQTT broker her mesajın veri yolunda yer alır. Veritabanınız doğru ülkede olsa bile, başka bir bölgedeki broker bu mesajları yine alır, işler ve muhtemelen saklar. Bir MQTT broker'ın verilerinizle ne yaptığını anlamak başlangıç noktasıdır.
Bir MQTT Sisteminde Veri Nerede Yaşar?
Yalnızca veritabanınızı değil, bir mesajın bulunabileceği her yeri haritalayın:
| Konum | Ne tutar | Yerelleştirme sorusu |
|---|---|---|
| Cihaz | Gönderilmeden önceki okumalar, tamponlanmış mesajlar | Cihazlar nerede kurulu? |
| Ağ yolu | Aktarım hâlindeki mesajlar | Trafik broker'a kadar uçtan uca TLS ile şifreleniyor mu? |
| Broker belleği | Yönlendirilmekte olan mesajlar | Broker hangi bölgede çalışıyor? |
| Retained message'lar | Topic başına son değer | Nerede ve ne kadar süre saklanıyor? |
| Kalıcı oturumlar | Çevrimdışı client'lar için kuyruğa alınmış mesajlar | Nerede saklanıyor ve süreleri ne zaman doluyor? |
| Broker logları | Client ID'ler, IP adresleri, bazen topic'ler | Loglar kişisel veri içeriyor mu ve nerede tutuluyor? |
| Aboneler ve arka uçlar | Aşağı akıştaki her şey | Servisleriniz ve veritabanlarınız nerede çalışıyor? |
İki kalem kolayca gözden kaçar. Birincisi, retained message'lar ve kuyruğa alınmış oturum mesajları broker üzerinde durağan veridir. İkincisi, broker logları bazı düzenlemeler kapsamında kişisel veri sayılabilecek IP adresleri ve client tanımlayıcıları içerebilir.
Mevzuat ve Sözleşme Kaynaklı Etkenler
GDPR ve Kişisel Veriler
AB Genel Veri Koruma Tüzüğü (GDPR) kapsamında kişisel veriler, AEA dışına yalnızca uygun güvencelerle aktarılabilir. Tüm IoT verileri kişisel değildir, ancak çoğu olabilir: bir araç takip cihazından konum, bir evdeki doluluk, bir haneyle ilişkilendirilmiş enerji kullanımı veya giyilebilir bir cihazdan sağlık ölçümleri. Bir cihaz bir kişiyle ilişkilendirilebiliyorsa, telemetrisi kişisel veri olabilir.
Sektör ve Müşteri Gereksinimleri
Gizlilik yasalarının ötesinde, yerelleştirme gereksinimleri çoğu zaman şunlardan kaynaklanır:
- Ülke içinde barındırma gerektiren kamu sektörü sözleşmeleri.
- Ulusal güvenlik kurallarına tabi kritik altyapı ve kamu hizmetleri.
- Kendi politikalarına sahip sağlık ve finans müşterileri.
- Her alt işleyicinin nerede çalıştığını soran kurumsal satın alma anketleri.
Çoğu zaman en katı gereksinim bir yasa değil, bir müşteri sözleşmesindeki bir maddedir. Barındırma modelini seçmeden önce bu gereksinimleri toplayın.
Tasarımınızda Yerelleştirme Riskini Azaltmak
Mühendislik tercihleri, broker nerede çalışırsa çalışsın sorunu küçültebilir:
- Payload'lardaki kişisel veriyi en aza indirin. İsim veya adres değil, cihaz ID'leri gönderin. Kimlikleri doğru bölgedeki arka ucunuzda çözümleyin.
- Kişisel verileri topic adlarının dışında tutun. Topic'ler loglarda, gezginlerde ve hata ayıklama araçlarında görünür.
- Her bağlantıda TLS kullanın. 8883 ve 8084 portları aktarım hâlindeki veriyi şifreler.
- Broker'daki durağan veriyi sınırlayın. MQTT 5 mesaj süresi dolumunu ve makul bir oturum süresi dolumunu kullanın, kişisel veri içeren mesajları retain etmekten kaçının.
- Edge'de işleyin. Buluta yayınlamadan önce bir ağ geçidinde toplulaştırın veya anonimleştirin.
- Veri akışını belgeleyin. Her bileşeni ve bölgesini listeleyen bir şema, satın alma sorularının çoğunu yanıtlar.
İşte MQTT 5 mesaj süresi dolumuyla takma adlı (pseudonymous) telemetri yayınlayan bir Python örneği (paho-mqtt 2.x); böylece on dakika içinde hiçbir abone almazsa broker mesajı atar.
import json
import ssl
import time
import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.connect("YOUR_BROKER_HOST", 8883, keepalive=60)
client.loop_start()
props = Properties(PacketTypes.PUBLISH)
props.MessageExpiryInterval = 600 # saniye
payload = {"device": "dev-4f9a", "kwh": 1.84, "ts": int(time.time())} # isim veya adres yok
info = client.publish("site-07/meter/dev-4f9a/telemetry", json.dumps(payload),
qos=1, properties=props)
info.wait_for_publish()
client.loop_stop()
client.disconnect()
Bölge Seçimindeki Ödünleşimler
Broker'ın bölgesini seçmek; yerelleştirme, gecikme ve kolaylık arasında bir dengedir:
- Yerelleştirme: bölge, yasal ve sözleşmesel gereksinimlerinizi karşılamalıdır.
- Gecikme: broker'dan uzak cihazlar ve tüketiciler daha uzun gidiş dönüş süreleri yaşar; bölgeye göre MQTT broker gecikmesi yazısına bakın.
- Ortak konumlandırma: broker'ı arka ucunuzun yakınına yerleştirmek bölgeler arası veri aktarımını azaltır.
- Çok bölgeli filolar: birden fazla yargı bölgesinde satış yapıyorsanız, her cihazın kendi ana broker'ına yapılandırıldığı bölge başına bir broker'a ihtiyacınız olabilir.
Son nokta mimari açısından önemlidir. Bölgelere bölünmüş bir cihaz filosu genellikle bölge başına ayrı broker'lar ve ayrı arka uçlar anlamına gelir; küresel görünüme yalnızca toplulaştırılmış, kişisel olmayan veriler akar.
Saklama ve Silme
Yerelleştirme soruları genellikle saklama sorularıyla birlikte gelir. Her veri türünün her aşamada ne kadar süre yaşayabileceğine karar verin: cihaz tamponunda, broker'da retained veya kuyruktaki mesaj olarak, loglarda ve veritabanlarınızda. Silmeyi cihaz başına ve müşteri başına mümkün kılın; çünkü bir müşterinin ilişiğini kesmek veya bir silme talebini yerine getirmek, verinin kopyalandığı her yerden kaldırılması demektir. MQTT'de bir retained message'ı temizlemek basittir: aynı topic'e boş bir retained payload yayınlayın.
BYOC Veri Yerelleştirmeyi Nasıl Karşılar?
"Verimiz nerede?" sorusunun en güçlü yanıtı "kendi bulut hesabımızda, seçtiğimiz bir bölgede" olur. Bu, kendi bulutunuzu getirin modelidir. ConnectMQ BYOC ile broker sizin bulut hesabınızda çalışır ve ConnectMQ tarafından yönetilir; böylece bölgeye, ağ sınırlarına ve loglama politikasına siz karar verirken kendi sunucunuzda barındırmanın operasyonel yükünden de kaçınırsınız. Ayrıntılar BYOC MQTT broker yazımızda.
Diğer ConnectMQ planları farklı ihtiyaçlara hizmet eder. Paylaşımlı kümedeki Serverless broker'lar geliştirme, pilot projeler ve yerelleştirme kısıtı olmayan veriler için idealdir. Dedicated planı size izole bir küme sunar. Her ikisi için de altyapının nerede çalıştığını ConnectMQ'ya sorun ve yanıtı veri akışı belgelerinize ekleyin. Her şeyi kendisi çalıştırmak zorunda olan kuruluşlar Self Managed Enterprise'ı değerlendirebilir.
Plan ne olursa olsun client tarafı değişmez: 8883 portunda TLS üzerinden MQTT 3.1.1 veya 5.0 ya da 8084 portunda /mqtt yoluyla Secure WebSocket. Bir filoyu bir barındırma modelinden diğerine taşımak, host'u ve kimlik bilgilerini güncellemekten ibarettir.
Canlıya Çıkmadan Önce Yerelleştirme Kontrol Listesi
- Cihazların, kullanıcıların ve müşterilerin bulunduğu yargı bölgelerini listeleyin.
- Payload alanlarını sınıflandırın: kişisel, takma adlı veya kişisel olmayan.
- Broker'ın, her abonenin ve her veritabanının bölgesini kaydedin.
- Mesaj süresi dolumunu, oturum süresi dolumunu ve retained message politikasını yapılandırın.
- TLS'in tüm client'lar için zorunlu olduğunu doğrulayın.
- BYOC'ye veya bölge başına broker'lara ihtiyaç olup olmadığına karar verin.
- Test verilerini herkese açık broker'lardan uzak tutun; ücretsiz herkese açık MQTT broker alanı herkes tarafından okunabilir ve yalnızca hassas olmayan denemeler için uygundur.
ConnectMQ ile Başlayın
Kişisel olmayan test verileri kullanarak, kredi kartı gerekmeden app.connectmq.com adresindeki ücretsiz Serverless planında geliştirmeye başlayın. Yerelleştirme gereksinimleri netleştiğinde Dedicated veya BYOC dağıtımları için ConnectMQ ile görüşün. Barındırma modellerine tam bir genel bakış için bulut MQTT broker rehberini ve barındırılan MQTT broker karşılaştırmasını okuyun.
Sık Sorulan Sorular
MQTT veri yerelleştirme yalnızca saklanan veriler için mi önemlidir?
Hayır. Pek çok politikada işleme de sayılır ve bir broker her mesajı işler. Retained message'lar, kuyruktaki oturumlar ve loglar da broker üzerinde durağan veridir.
IoT telemetrisi GDPR kapsamında kişisel veri midir?
Konum veya hane enerji kullanımı gibi tanımlanabilir bir kişiyle ilişkiliyse olabilir. Payload'larınızı sınıflandırması için veri koruma sorumlunuza danışın.
BYOC veri yerelleştirmeye nasıl yardımcı olur?
Broker, sağlayıcı tarafından işletilirken sizin kendi bulut hesabınızda, seçtiğiniz bölgede ve sizin politikalarınız altında çalışır.
Birkaç ülkedeki cihazlar için tek bir broker kullanabilir miyim?
Teknik olarak evet; ancak her ülkenin yerelleştirme kuralları varsa, cihazların kendi ana broker'larına atandığı bölge başına bir broker'a ihtiyacınız olabilir.
