Veri Türkiye’de kalacaksa: Firebase, Cloudflare, CDN ve IoT mimarisi

Önce şartı tanımlayın: KVKK değerlendirmesi ile proje sınırı aynı şey değildir

Türkiye’de bütün verilerin yurt dışına çıkması için genel ve koşulsuz bir yasak varmış gibi mimari kurulamaz. Kişisel veriler bakımından KVKK'nın yurt dışına aktarım düzeni ve ilgili koşullar değerlendirilir; Kurumun rehberi ve standart sözleşme belgeleri başlangıç kaynaklarıdır. Buna ek olarak bir proje sözleşmesi veya uygulanabilir sektörel gereksinim daha dar bir yerleşim şartı koyabilir. Bu yazının teknik senaryosu, kapsamı belirlenmiş verilerin Türkiye’de işlenmesi ve tutulması şartıdır. Belirli bir kurumun hukuki sonucunu otomatik çıkarmıyoruz; şartı test edilebilir mühendislik sınırlarına çeviriyoruz.

Şartın öznesi açık yazılır: kişisel veri mi, üretim telemetrisi mi, anahtarlar mı, bütün günlükler mi? Saklama, işleme, destek erişimi, yedekleme ve ağ geçişi ayrı kapsamlar olabilir. Sadece veritabanının Türkiye’de olması bunların hepsini cevaplamaz. Yurt dışındaki destek erişimi de veri dosyası indirilmeden gündeme gelebilir; KVKK rehberi uzaktan erişimi somut koşullarıyla ele alır. Aktarımın hukuken değerlendirilmesi ile seçilmiş projede hiç dış işleme istenmemesi ayrı kontrol listelerinde tutulmalıdır. Genel bir gizlilik kutucuğu, sözleşmedeki coğrafi sınırın yerini almaz.

Bölüm kaynakları: KVKK · Kişisel Verilerin Yurt Dışına Aktarılması Rehberi ↗KVKK · Standart sözleşmeler ve bağlayıcı şirket kuralları ↗

Veri akışı veritabanı bağlantı dizesinden daha geniştir

Bir mobil uygulama Türkiye’deki API’ye yazarken kimlik doğrulama, hata raporu ve bildirim için başka sağlayıcılara bağlanabilir. Bir web paneli yerel sunucuda çalışırken CDN, uzaktaki JavaScript, analitik ve doğrulama bileşenleri tarayıcıdan ayrı istek çıkarabilir. SCADA hattındaki bir ağ geçidi ölçümleri yerelde tutup sağlık telemetrisini veya hata dökümünü dış hizmete gönderebilir. İnceleme yalnızca uygulama sunucusunun çıkışlarına bakarsa bu yollar görünmez kalır. İstemci, cihaz, yönetim ve destek düzlemleri aynı akış haritasında gösterilir; her okun hangi veriyi taşıdığı yazılır.

Envanterde olay yükü kadar IP adresi, kurulum kimliği, zaman damgası, kullanıcı veya cihaz eşlemesi ve URL parametreleri de incelenir. Her teknik alanın her bağlamda kişisel veri olduğu varsayılmaz; ilişkilendirilebilirlik ayrıca değerlendirilir. Bununla birlikte proje şartı teknik metaveriyi de kapsıyorsa yalnızca kişisel olmayan sıcaklık değeri gönderiyoruz savunması yeterli olmaz. Anahtarın nerede bulunduğu, verinin nerede açıldığı ve hangi ekibin erişebildiği kayda alınır. Şifreleme ve coğrafi yerleşim farklı özelliklerdir; şifreli bir dış akış otomatik olarak yerel akışa dönüşmez.

Firebase: tek proje, tek veri yerleşimi garantisi değildir

Firebase'i tek bir konum seçeneği olan ürün gibi değerlendirmek yanıltır. Firestore, depolama ve uygulama arka uçları gibi kaynakların konumları ürün veya örnek bazında ele alınır. Bir kaynağa bölge seçmek bütün Firebase servislerine aynı kısıtı uygulamaz. AB bölgesi de Türkiye’de işleme demek değildir. Resmî gizlilik sayfası, inceleme tarihi olan 20 Ekim 2026 itibarıyla Firebase Authentication'ın ABD veri merkezlerinden çalıştığını belirtiyor. Dolayısıyla kimlik işleme de kesin Türkiye şartının kapsamındaysa, veritabanını başka yerde tutmak bu bağımlılığı çözmez. Kullanılan ürün, özellik ve sözleşme kapsamı tek tek doğrulanmalıdır.

Bu sonuç Firebase her durumda kullanılamaz anlamına gelmez; belirli bir yerleşim şartıyla belirli bir servis akışının uyuşup uyuşmadığını gösterir. Örneğin işletme verisini yerel API’de saklayan bir uygulamada oturum, bildirim, Crashlytics ve analitik yolları ayrı satırlara yazılır. Gerekmeyen SDK otomatik başlatmaları incelenir; veri toplama ayarını değiştirmek hizmetin bütün konum koşullarını değiştirdiği varsayımıyla yapılmaz. Geliştirme, test ve üretim sürümleri aynı davranışı göstermeyebilir. Kaynak bölgesi, SDK sürümü ve gerçek ağ davranışı birlikte kaydedilir; yalnızca konsol ekranındaki bir bölge adı kanıt paketi sayılmaz.

Bölüm kaynakları: Firebase · Product and resource locations ↗Firebase · Privacy and Security ↗

Bildirim, çökme kaydı ve tarayıcı bağımlılıkları

Firebase Cloud Messaging kullanırken bildirim metni ve veri yükü, alıcı kimliği ile uygulamanın yerel API’sinden bağımsız bir akış oluşturur. Hassas içeriği doğrudan bildirime koymamak, gerekli içeriği yetkili oturumla API’den almak üzere tasarlamak veri miktarını azaltabilir. FCM belgesi taşıma korumasını uçtan uca içerik korumasından ayırır. Ancak içerik küçültme veya ek şifreleme, bildirim sağlayıcısının devreden çıktığı anlamına gelmez. Kesin yerleşim şartı, mesaj içeriği kadar teslim metaverisini kapsıyorsa bu kalan bağımlılık ayrıca değerlendirilir; sessizce onaylanmış kabul edilmez.

Mobil işletim sisteminin bildirim, mağaza ve cihaz hizmetleriyle kurduğu ilişkiler de ürün tasarımında hesaba katılır. Kesin şart gerektirdiğinde uygulama içi sorgulama veya kurumca yönetilen istemci gibi seçenekler değerlendirilebilir; bunların arka plan çalışması, pil, gecikme ve yönetim sınırları ayrıca ölçülür. Web tarafında uzaktaki font, etiket yöneticisi, hata izleme ve bot doğrulama istekleri listelenir. Bir SDK’yı kaldırmak tek başına bütün dış akışların bittiğini göstermez. Soğuk açılış, giriş, hata, çevrimdışı çalışma ve yeniden bağlantı senaryolarında istemci trafiği gözlenir.

Bölüm kaynakları: Firebase Cloud Messaging · Encryption ↗

CDN ve ters vekil: yerel origin, dış işleme yolunu kapatmaz

Origin sunucunun Türkiye’de olması, önündeki CDN veya ters vekilin aynı sınırda işlem yaptığı anlamına gelmez. TLS nerede sonlanıyor, hangi yanıtlar önbelleğe alınıyor, WAF hangi alanları görüyor ve hata günlükleri nereye gidiyor soruları ayrı cevaplanır. CDN yalnızca herkese açık görselleri taşıyorsa bu akış, oturumlu API isteklerini taşımasından farklıdır. Fakat ziyaretçi IP’si, istek yolu ve güvenlik olayı gibi metaveriler yine değerlendirme konusu olabilir. Veri sınıfları ayrılmadan bütün alan adını tek bir yerel veya dış etiketiyle açıklamak yetersiz kalır.

DNS hizmeti ile HTTP proxy/CDN hizmeti de aynı veri yolunu görmez. Yalnızca DNS kullanılması web yanıt gövdesinin o sağlayıcıdan geçtiğini göstermez; buna karşılık DNS sorgusu ve yönetim metaverisi kendi kapsamıyla incelenir. Önbelleğe alma kapalı olsa bile istek denetlenebilir ve günlük üretilebilir. Türkiye’de bir erişim noktasına bağlanılması da bütün işleme ve saklamanın aynı ülkede kaldığının kanıtı değildir. Ölçüm; sözleşme, ürün ayarı ve veri akışıyla birlikte yorumlanır. Tek bir IP konum sorgusu bütün zincirin coğrafi sınırını doğrulayamaz.

Cloudflare: Türkiye Regional Services ile metaveri sınırını karıştırmayın

20 Ekim 2026 incelemesinde Cloudflare'ın bölge tablosu Türkiye için Regional Services desteği gösteriyor. Bu özellik, kapsadığı yapılandırmada HTTPS içeriğinin nerede açılıp işlendiğini sınırlandırır. Aynı tabloda Türkiye için Customer Metadata Boundary desteği bulunmuyor; bu metaveri özelliğinin seçilebilir bölgeleri AB ve ABD. Böylece içerik işleme için Türkiye seçilmiş olması, müşteri günlüklerinin de Türkiye’de tutulduğunu söylemeye yetmiyor. Kesin şart bu günlükleri kapsıyorsa ayrıca çözülmesi gereken bir uyumsuzluk veya doğrulanmamış sınır vardır; Türkiye erişim noktası tek başına cevap değildir.

İnceleme üç soruyu ayrı tutar: içerik nerede işleniyor, günlük ve analitik nerede tutuluyor, TLS anahtarının konumu nasıl sınırlandırılıyor? Her özellik aynı bölge seçeneklerine sahip değildir. DLS belgesi bu paketi Enterprise müşterilere yönelik ücretli ek kapsam olarak tanımlar; standart planın varsayılan davranışı sayılmaz. Cloudflare'ın metaveri SSS'si müşteri hesap bilgisi, yapılandırma ve bazı operasyonel verileri Customer Metadata Boundary kapsamından ayrıca ayırır. Bu nedenle bütün Cloudflare verileri tek ayarla Türkiye’de kalır ifadesi kullanılmamalıdır. Gerçek hesap yetkileri, satın alınan kapsam, etkin ürünler ve güncel belgeyle doğrulama yapılır. Ürün seçenekleri değişebildiği için değerlendirme tarihi ve kanıt sürümü raporda korunur.

Bölüm kaynakları: Cloudflare · Region support ↗Cloudflare · Customer Metadata Boundary ↗Cloudflare · Metadata Boundary FAQ ↗Cloudflare · Data Localization Suite ↗

Cloudflare ürün zinciri ve alt istekler ayrı değerlendirilir

Bir host adını bölgeselleştirmek o uygulamanın kullandığı bütün ek ürünlerin yerleşimini otomatik belirlemez. Cloudflare, ürün uyumluluk tablosunda destek ve kısıtları özellik bazında yayımlar; örneğin Workers.dev ile bir zone üzerinde çalışan Workers aynı satır değildir. Sınırlamalar belgesi, Workers'ın başka hizmetlere yaptığı alt isteklerin Regional Services kapsamına otomatik girmediğini belirtir. Bu yüzden bölgesel girişten sonra dış API’ye giden bir çağrı hâlâ yeni bir veri akışıdır. DNS, WAF, Workers, depolama, Logpush ve destek yolları gerçek yapılandırma üzerinden ayrı incelenir.

Önbellek hiyerarşisi de önemlidir. Cloudflare'ın cache belgesi, Generic Global ve Custom Tiered Cache ile Smart Tiered Cache arasında Regional Services uyumluluğu bakımından ayrım yapar. Günlükleri Türkiye’deki bir hedefe dışa aktarmak da sağlayıcının önceki işleme ve saklama adımlarını kendiliğinden silmez. Kabul kanıtı; hangi ürünlerin etkin olduğu, hangi hostname ve region ayarının uygulandığı, hangi kısıtların bulunduğu ve günlüklerin hangi aşamalardan geçtiği üzerinden toplanır. Standart bir CDN kurulumu için ürünün bütün bölgesel özelliklerinin etkin olduğu varsayılmaz; pazarlama ifadesi yerine satın alınmış ve doğrulanmış kapsam kullanılır.

Bölüm kaynakları: Cloudflare · Product compatibility ↗Cloudflare · Localization limitations ↗Cloudflare · Cache localization ↗

LoRaWAN bir radyo/ağ standardıdır; yabancı bulut zorunluluğu değildir

LoRaWAN ile bir yönetilen LoRaWAN hizmeti aynı şey değildir. Standart, uç cihaz, gateway, ağ sunucusu ve uygulama tarafı arasında görev ayrımları tanımlar; ilgili sürüm ve kurulumda join işlemi ve anahtar sorumlulukları ayrıca ele alınır. Bir özel ağda bu bileşenler kurumun seçtiği altyapıda işletilebilir. Bu nedenle LoRaWAN veriyi zorunlu olarak yurt dışına çıkarır demek doğru değildir. Asıl soru seçilen Network Server, Application Server, varsa Join Server ve yönetim araçlarının nerede çalıştığı, kim tarafından erişildiği ve hangi dış bağımlılıkları kullandığıdır.

Şifreleme uygulama yükünü korurken gateway ve ağ işletiminin ihtiyaç duyduğu yönlendirme, kimlik veya radyo metaverileri ayrı kalabilir. Anahtar rollerini ve gerçek kurulumdaki çözme noktasını doğrulamadan bütün ara noktalar her şeyi görür veya hiçbir şey göremez denmez. Saha frekans planının Türkiye’ye uygun seçilmesi de sunucu konumuna ilişkin kanıt değildir. Roaming, bulut konsolu, zaman hizmeti, hata raporu ve anahtar yedekleri envantere eklenir. Açık kaynak bir ağ sunucusu seçmek kontrolü artırabilir; ancak yanlış dağıtımın veya dış destek erişiminin etkisini ortadan kaldırmaz.

Bölüm kaynakları: LoRa Alliance · LoRaWAN for Developers ↗LoRa Alliance · Security implementation ↗

Helium: gateway Türkiye’de olsa da paket yönü ayrıca izlenmeli

Helium IoT mimarisi klasik doğrudan gateway–LNS yoluna ek olarak Helium Packet Router katmanını kullanır. Bir hotspot Türkiye’de bulunabilir ve seçilen LNS de Türkiye’de kurulabilir; bu iki bilgi, yönlendirme ve yönetim zincirinin tamamı için Türkiye garantisi oluşturmaz. HPR, yapılandırma hizmeti, seçilmiş LNS, entegrasyonlar ve günlük yolları ayrı değerlendirilir. Buradan bütün Helium paketlerinin belirli bir yabancı ülkede işlendiği sonucu çıkarılmamalıdır; makaledeki tespit, yerel uç noktaların tek başına bütün atlamaların coğrafi kanıtı olmadığıdır.

Dağıtık ağ veya şifreli payload etiketi de bu incelemenin yerine geçmez. Uygulama içeriğinin kimde açıldığı ile ağın hangi metaveriyi işlediği ayrı sorulardır. Genel ağa katılım, kapsama avantajı sağlayabilir; kesin yerleşim şartında ise bağımlılık ve kanıt yükünü artırabilir. Sağlayıcıdan coğrafi kapsam, alt işleyen, günlük, saklama ve destek erişimi için doğrulanabilir yanıt alınamıyorsa sonuç uygun kabul edildi değil, kapsamı belirsiz olmalıdır. Gerektiğinde yönetilen özel ağ veya kurumun denetimindeki yol değerlendirilir; bunun da işletim ve bakım maliyeti vardır.

Bölüm kaynakları: Helium · LoRaWAN architecture ↗

SCADA, IoT ve uygulamalar için denetlenebilir bir yerel yol

Bir alternatif mimari; saha toplama, yerel tampon, kurumca yönetilen kimlik, Türkiye’deki mesajlaşma/API, veri deposu ve gözlemlenebilirlik bileşenlerini kapsayabilir. Bu bir ürün listesi veya hazır uygunluk garantisi değildir. Seçilen her bileşenin gerçek konumu, anahtar saklama, güncelleme ve yönetim yolu doğrulanır. SCADA kontrol çevrimi ile merkezi raporlama ayrılır; dış hizmet kesintisi fiziksel kontrolün davranışını belirsizleştirmemelidir. Uzaktan erişim gereken ekipler için hedef sistem, yetki, oturum kaydı ve hangi coğrafyadan erişilebileceği proje kapsamında tanımlanır; yalnızca VPN bulunması yeterli sayılmaz.

Yedek, felaket kurtarma, CI/CD, destek paketi ve test verisi de aynı sınırın parçası olabilir. Üretim verisini yerelde tutup hata dökümünü dış ticket sistemine yüklemek bağımlılığı geri getirir. Türkiye’deki sağlayıcı adı, yedeklerin veya dış destek ekibinin konumunu kendiliğinden doğrulamaz. Veri minimizasyonu, yerel log ayıklama ve kısıtlı dış bağlantılar uygulanabilir; bunların hizmeti nasıl etkilediği ölçülür. Ağ geçişinin de ülke içinde kalması isteniyorsa bu, işleme konumundan ayrı taşıyıcı ve yönlendirme kanıtı gerektiren bir şart olarak yazılır. Sunucu coğrafyası bütün internet rotasını kanıtlamaz.

Bir envanter denetimi neyi kanıtlayabilir?

Aşağıdaki örnek, kapsamına alınmış her akış için işleme, saklama, günlük, yedek, destek erişimi ve anahtar saklama alanlarını kontrol eder. Politika bu sentetik senaryoda yalnızca TR kabul eder. Dış ülke beyanı inceleme gerektirir; eksik ülke veya kanıt belirsiz kalır. Kod ağ keşfi yapmaz, belgeyi doğrulamaz ve KVKK uygunluk kararı vermez. Örnek kanıt kimlikleri yer tutucudur; gerçek sözleşme veya dağıtım kanıtı değildir. Hepsi TR olarak doldurulan bir formun doğru olduğunu otomatik kabul etmek bu aracın kapsamı dışındadır.

Örnekte yerel işlemeye rağmen dış günlük beyan eden bir edge akışı incelemeye gider. Türkiye dışı kimlik işleme de aynı şekilde işaretlenir; destek veya yedek bilgisi eksikse olumlu sonuç üretilmez. Ürün adından ülke çıkarsaması yapılmaz. Gerçek değerlendirmede belge tarihi, sözleşme eki, etkin ayar, veri sınıfı ve sorumlu kişi eklenir. Kanıtın kapsamadığı veya hiç kullanılmayan bir özellik, gerekçeli kapsam dışı kaydıyla açıklanır; boş bir alan sessiz onay değildir. Bu yaklaşım satın alma ve geliştirme ekiplerinin aynı eksik üzerinden konuşmasını sağlar.

const assert = require('node:assert/strict');
// A review of declared inventory, not traffic discovery or legal compliance.
const dimensions = ['processing', 'storage', 'logs', 'backups',
  'supportAccess', 'keyStorage'];
function review(flow) {
  const findings = dimensions.map(dimension => {
    const item = flow.locations?.[dimension];
    if (!item || !Array.isArray(item.countries) || !item.countries.length)
      return { dimension, state: 'unknown' };
    if (item.countries.some(country => country !== 'TR'))
      return { dimension, state: 'outside-declared-policy' };
    if (typeof item.evidence !== 'string' || !item.evidence.trim())
      return { dimension, state: 'unknown' };
    return { dimension, state: 'documented-domestic' };
  });
  return { id: flow.id, findings,
    state: findings.some(f => f.state === 'outside-declared-policy')
      ? 'review-required'
      : findings.some(f => f.state === 'unknown')
        ? 'unknown' : 'documented-domestic' };
}
// All records below are synthetic; evidence IDs are placeholders.
const domesticLocations = () => Object.fromEntries(dimensions.map(d =>
  [d, { countries: ['TR'], evidence: 'example-evidence-' + d }]));
const localApi = { id: 'residency-manifest-api', locations: domesticLocations() };
assert.equal(review(localApi).state, 'documented-domestic');
const remoteIdentity = { id: 'example-identity', locations: domesticLocations() };
remoteIdentity.locations.processing = { countries: ['US'], evidence: 'example-review' };
assert.equal(review(remoteIdentity).state, 'review-required');
const mixedEdge = { id: 'example-edge', locations: domesticLocations() };
mixedEdge.locations.logs = { countries: ['DE'], evidence: 'example-review' };
assert.equal(review(mixedEdge).state, 'review-required');
const unknownSupport = { id: 'example-support', locations: domesticLocations() };
unknownSupport.locations.supportAccess = { countries: [], evidence: '' };
assert.equal(review(unknownSupport).state, 'unknown');
const unsupportedClaim = { id: 'example-claim', locations: domesticLocations() };
unsupportedClaim.locations.backups.evidence = '';
assert.equal(review(unsupportedClaim).state, 'unknown');
assert.equal(review({ id: 'empty-manifest' }).state, 'unknown');
console.log([localApi, remoteIdentity, mixedEdge, unknownSupport].map(review));

Kabul kanıtı ve Gokbilge Tech hizmet kapsamı

Kabul testleri istemciyi, cihazı ve sunucuyu birlikte kapsar. İlk açılış, giriş, bildirim, hata, anahtar yenileme, yeniden bağlantı, yedekten dönüş ve destek oturumu çalıştırılır. DNS ve ağ kayıtları hangi hedeflerle konuşulduğunu gösterir; şifreli trafiğin içeriği, sağlayıcı içi saklama ve gizli destek yolları için tek başına yeterli değildir. Sağlayıcı kanıtı, sözleşme ve yapılandırmayla birleştirilir. Dış hizmet engellendiğinde sistemin nasıl davrandığı da ölçülür; bağlantıyı kesip hataları gizlemek çözüm değildir. Yeni SDK veya servis değişikliği bu envanteri ve ilgili testleri yeniden açmalıdır.

Gokbilge Tech bağımsız yazılım ve donanım evi olarak SCADA/IoT veri hattını, gömülü yazılımı ve mobil/web uygulama bağımlılıklarını birlikte değerlendirebilir. Kapsam; veri akışı envanteri, yerleşim şartının teknik karşılığı, alternatif dağıtım tasarımı ve kontrollü kabul kanıtı üzerinden kurulabilir. Yerli mühendislik, bütün bileşenlerin yerli olduğunu veya her açık kaynak dağıtımın otomatik güvenli olduğunu söylemek değildir. Firebase, Cloudflare veya Helium için genel yasak etiketi üretmek yerine seçilmiş koşulla uyuşmayan akışı açıkça göstermek gerekir. Projeye özgü hukuki ve sektörel sonuçlar ilgili uzmanlarla teyit edilir; bu yazı teknik inceleme yöntemidir.

• Veri sınıfları ile işleme, saklama, erişim ve ağ geçişi şartları ayrı yazıldı mı?
• Firebase SDK yolları ile Cloudflare içerik, günlük ve ek ürün kapsamı doğrulandı mı?
• LoRaWAN/Helium sunucuları, yönlendirme, anahtarlar ve destek zinciri belgelendi mi?
• Belirsiz akışlar açık kaldı mı ve gerçek hata/kurtarma senaryoları sınandı mı?