BIM, IoT ve Veri Egemenliği / 12 dk
BIM ve IoT Verileri Yurt Dışına Çıkmadan Dijital İkiz Kurulabilir mi?
BIM, BMS, SCADA ve IoT için on-premises, veri egemenliği, air-gap, edge gateway ve yurt dışına veri aktarımı risklerini teknik olarak inceleyin.
Bu gereksinim nereden doğar?
BIM ve IoT verilerinin yurt dışına veya kurum dışına çıkarılmaması her müşteri için geçerli genel bir yasak değildir. Bu koşul, müşterinin kendi bilgi güvenliği politikası, ihale/sözleşme şartı veya belirli bir alanda uygulanabilir özel düzenleme nedeniyle ortaya çıkabilir. Bu makaledeki teknik mimari ve kontroller, böyle bir talep geldiğinde değerlendirilmesi gereken seçeneklerdir.
Octatus projelerinde önce müşterinin yazılı gereksinimi netleştirilir: yalnızca ülke dışı aktarım mı engelleniyor, kurum dışı barındırma mı yasak, yoksa tüm internet çıkışı mı kapalı? Çözüm bu sınıra göre seçilir; her projeye otomatik olarak air-gapped kurulum önerilmez.
BIM için bulut zorunlu değildir; asıl mesele veri akışının tamamıdır
Bir tesisin BIM modelini canlı BMS/SCADA/IoT ölçümleriyle ilişkilendirmek için veriyi yabancı bir buluta göndermek teknik bir zorunluluk değildir. Yerel edge gateway, tesis içi mesajlaşma, yerel zaman serisi depolama ve yerel uygulama sunucuları ile operasyonel dijital ikiz mimarisi tasarlanabilir.
Ancak sunucunun Türkiye'de bulunması tek başına 'hiçbir veri yurt dışına çıkmıyor' kanıtı değildir. Cihaz üreticisinin yönetim bulutu, DNS, NTP, sertifika kontrolü, lisans servisi, crash reporting, log gönderimi, uzaktan destek, mobil push ve yedekleme hedefleri de envanterlenmelidir.
On-premises, data residency ve sıfır sınır ötesi aktarım farklı gereksinimlerdir
On-premises, iş yükünün müşterinin yönettiği altyapıda çalışmasıdır. Data residency, verinin belirli ülke veya bölgede saklanmasıdır. Sıfır sınır ötesi aktarım ise yalnızca ana veri tabanını değil, telemetri, metadata, log, dosya, destek erişimi, yedek ve üçüncü taraf servis akışlarını da kapsayan daha sıkı bir gereksinimdir.
Sözleşmede 'veri Türkiye'de tutulur' ifadesi ile 'yetkilendirilmemiş hiçbir sınır ötesi veri akışı yoktur' ifadesi aynı sonucu doğurmaz. Hangi veri kategorisinin hangi sistemde ve hangi işlem amacıyla tutulduğu açık yazılmalıdır.
Önerilen mimari: OT ağı → kontrollü edge → yerel dijital ikiz
BMS, PLC, RTU, sayaç ve sensörlerden Modbus, BACnet, OPC UA, MQTT veya üretici API'leri üzerinden veri okunabilir; desteklenen protokoller cihaz ve proje özelinde doğrulanmalıdır. OT segmenti ile kurumsal IT arasına uygun ağ bölümlendirmesi, güvenlik duvarı ve gerektiğinde OT DMZ yerleştirilir. Edge katmanında protokol normalizasyonu, cihaz kimliği eşlemesi, kalite kontrolü ve bağlantı kesintisinde tamponlama uygulanır.
Yerel mesajlaşma ve depolama katmanından BIM varlık kimliğine bağlanan ölçümler, modelde ilgili ekipmanın durumunu gösterebilir. Kritik kontrol komutları gözlem mimarisinden ayrı yetki, emniyet ve değişiklik süreçlerine tabi olmalıdır. NIST SP 800-82 Rev.3 OT sistemlerinde güvenlik, güvenilirlik ve emniyet gereksinimlerinin birlikte değerlendirilmesini önerir. Kaynak: https://csrc.nist.gov/pubs/sp/800/82/r3/final
Yurt dışına veri çıkışını gizlice oluşturabilen on kanal
1. Üretici cihaz bulutları. 2. Uzaktan bakım VPN veya destek oturumları. 3. Lisans doğrulama ve aktivasyon servisleri. 4. Uygulama analitiği ve hata raporlama. 5. Harici e-posta/SMS/push servisleri. 6. Yedekleme ve felaket kurtarma hedefleri. 7. CDN, harita ve üçüncü taraf API çağrıları. 8. DNS/NTP ve sertifika altyapısı bağımlılıkları. 9. Yapay zekâ çıkarımı için dış API'ler. 10. Mobil uygulama ve tarayıcıdaki üçüncü taraf SDK'lar.
Bu trafiğin her biri mutlaka kişisel veri içermez; yine de ağ çıkışı, operasyonel metadata veya sözleşmeyle korunan bilgi paylaşımı açısından değerlendirilmelidir. 'Bulut kapalı' beyanı, egress testinin yerine geçmez.
Air-gapped ve disconnected işletim için kabul kriterleri
Sıfır internet çıkışlı bir kurulumda kurulum paketleri, imajlar, lisanslar, bağımlılıklar, saat senkronizasyonu, harita verileri, model dosyaları, kimlik altyapısı ve güncelleme prosedürü çevrimdışı çalışabilmelidir. İnternet bağlantısı kesildiğinde veri toplama, yerel arayüz, alarm ve saklama davranışları ayrıca test edilmelidir.
Kabul için egress-deny ağ kuralı, paket yakalama, DNS çözümleme kayıtları, firewall logları, bağımlılık/SBOM incelemesi, üçüncü taraf hizmet envanteri ve kontrollü bağlantı kesme senaryoları kullanılabilir. Mutlak 'hiç veri çıkmaz' garantisi yalnızca mimari niyetle değil, belirli sürüm ve dağıtım için doğrulanmış testlerle değerlendirilebilir.
KVKK ve sektörel yükümlülükler: Teknik mimari hukuk değerlendirmesinin yerine geçmez
Türkiye'de KVKK'nın 9. maddesi kişisel verilerin yurt dışına aktarımı için şartlar ve uygun güvence mekanizmaları düzenler. 2024 değişiklikleri kapsamında standart sözleşmeler ve bağlayıcı şirket kuralları gibi yöntemler öngörülmüştür. Bu düzenleme, tüm endüstriyel telemetrinin her koşulda yurt dışına aktarılmasının yasak olduğu anlamına gelmez.
Kamu, kritik altyapı, savunma, enerji veya sözleşmesel gizlilik gereksinimleri ayrıca uygulanabilir. Hukuki yükümlülükler veri kategorisi, kurumun statüsü, tedarik zinciri ve güncel mevzuat üzerinden yetkili uzmanlarla değerlendirilmelidir. Kaynak: https://www.kvkk.gov.tr/Icerik/2053/Yurtdisina-Aktarim
Octatus için doğru ürün vaadi nasıl doğrulanmalı?
Octatus'un BIM/GIS, canlı veri ve dijital ikiz yaklaşımı yerel veri işleme senaryoları için değerlendirilebilir. Ancak 'air-gapped hazır', 'hiç yurt dışına veri çıkarmaz' veya 'KVKK uyumlu' gibi kesin ürün iddiaları, dağıtım, ağ ve üçüncü taraf bağımlılık testleri yapılmadan verilmemelidir.
Müşteri keşfinde veri sınıflandırması, ağ topolojisi, dış servis bağımlılıkları, destek modeli ve kabul testleri ayrı iş paketleri olarak belirlenmelidir.
Sahadan örnek: karar anında hangi bilgi gerekir?
Verinin Türkiye'deki sunucuda tutulması tek başına dışarı çıkmadığı anlamına gelmez. Harita servisi, hata telemetrisi, lisans kontrolü, destek oturumu ve yedekleme hedefleri de veri akışı envanterine girmelidir.
Yerel dijital ikiz mimarisinde sensör verisinin hangi ağ segmentinden geçtiği ve hangi sistemde saklandığı veri akış diyagramıyla gösterilmelidir. Yalnızca uygulama sunucusunun ülkede bulunması, uzaktan destek veya telemetri aktarımı nedeniyle hiçbir verinin dışarı çıkmadığını kanıtlamaz.
Uygulama ve kabul kontrolü
Ağ çıkış testi, DNS ve egress gözlemi, erişim denetimi, veri işleme sözleşmeleri ve kurtarma senaryoları birlikte doğrulanmalıdır.
Pilot güvenlik testinde DNS, dış bağlantılar, güncelleme kanalları ve hata raporlaması gözlenir. Ağ kesildiğinde yerel varlık görünümü ve tampon davranışı sınanır. Kullanıcı verisinin istem dışı üçüncü taraf servise gönderilmediği ağ kayıtlarıyla doğrulanmalıdır.
Yatırım ve kapsam kararı nasıl verilir?
Veriyi ülke dışına çıkarmadan dijital ikiz kurma kararı sunucu konumunun ötesinde ağ bağımlılıklarını kapsar. Yerel uygulama hata raporlarını yabancı bir servise gönderebilir veya uzaktan destek sırasında hassas model verisi paylaşabilir. İlk pilotta DNS, güncelleme, lisans ve destek trafiği kaydedilmeli; çevrimdışı kullanım sınanmalıdır. Yerel yedekleme, güvenlik güncellemesi ve anahtar yönetimi maliyetleri yatırım hesabına eklenmelidir.
Yerel barındırmanın maliyetine yedekleme, sertifika yenileme, güvenlik güncellemesi ve olay müdahalesi eklenir. Veri egemenliği hedefi ile yüksek erişilebilirlik gereksinimi birlikte tasarlanmalıdır. Yasal uygunluk yalnızca mimari diyagramdan çıkarılamaz.
Veri egemenliği için kapsam ve sınıflandırma
Bir dijital ikiz projesinde veri egemenliği değerlendirmesi yalnızca IFC dosyasının nerede saklandığına bakılarak yapılamaz. Bina planları, ekipman kimlikleri, sensör ölçümleri, kullanıcı kayıtları, arıza bildirimleri, erişim logları ve destek paketleri farklı hassasiyet seviyelerinde olabilir. Önce hangi verinin kişisel veri, ticari sır, kritik altyapı bilgisi veya kamuya açık bilgi olduğu sınıflandırılmalıdır. Sınıflandırma, saklama ve aktarım kurallarının temelini oluşturur.
Örneğin bir kampüsün genel bina sınırı ile güvenlik kameralarının konumları aynı erişim politikasına tabi olmayabilir. Enerji ölçümleri de tesis kapasitesi ve işletme düzeni hakkında bilgi verebilir. Veri sözlüğünde kaynak, sahip, saklama süresi, işleme amacı ve izin verilen alıcılar belirtilmelidir. Teknik mimari bu kurallara göre tasarlanmalıdır.
Yerel kurulum ile veri çıkışının sıfırlanması aynı şey değildir
Uygulama sunucusunun Türkiye'de bulunması tüm veri trafiğinin ülke içinde kaldığını kanıtlamaz. Harita döşemeleri, hata izleme SDK'ları, lisans doğrulaması, font servisleri, e-posta ağ geçitleri veya uzaktan destek oturumları dış servislere bağlantı kurabilir. Yedeklerin konumu ve felaket kurtarma altyapısı da ayrıca incelenmelidir. Bu nedenle 'on-premises' ve 'sınır ötesi aktarım yok' iddiaları ayrı kabul kriterlerine sahip olmalıdır.
Kurulum sırasında uygulama bağımlılık envanteri ve ağ akış matrisi çıkarılmalıdır. Hangi bileşenin hangi alan adına, IP aralığına ve protokole eriştiği belgelenmelidir. İnternet kapatıldığında hangi fonksiyonların çalışacağı test edilmelidir. Bir bağımlılık çevrimdışı çalışamıyorsa bu durum açık istisna olarak yönetilmelidir.
OT ve IT ağları arasında güvenli veri akışı
BMS, SCADA, PLC ve enerji analizörleri genellikle işletme güvenliği açısından özel ağ segmentlerinde bulunur. Dijital ikiz platformu bu cihazlara doğrudan geniş erişim hakkı almamalıdır. Kontrollü edge toplayıcıları, açıkça tanımlanmış veri akışları ve mümkün olduğunda salt okunur bağlantılar tercih edilebilir. Ağ geçidi veya broker tasarımında güvenlik duvarı kuralları, kimlik doğrulama ve sertifika yönetimi belirlenmelidir.
Örneğin enerji ölçerinden Modbus üzerinden veri alınması, ölçere yazma komutu gönderme yetkisi verildiği anlamına gelmemelidir. Enlogy gibi operasyonel veri katmanları ile Octatus'un varlık bağlamı ayrılabilir. Ağ bölümlendirme, tamponlama ve yeniden bağlantı davranışı pilotta test edilmelidir. Kontrol otoritesi yetkili OT sisteminde kalmalıdır.
Varlık kimliği ile telemetri noktasını bağlamak
Dijital ikiz ekranında bir sıcaklık ölçümünü doğru ekipmana bağlamak için yalnızca oda yakınlığı yeterli değildir. BIM nesne kimliği, kurumsal asset ID, BMS point ID ve fiziksel cihaz seri numarası farklı alanlardır. Bu kimliklerin kontrollü eşlenmesi gerekir. Sensör değiştiğinde ölçüm noktası ve fiziksel varlık arasındaki ilişki yeniden doğrulanmalıdır.
Örneğin AHU-03 ünitesinin dönüş havası sıcaklığı başka ünitenin noktasına bağlanırsa arıza analizi yanlış sonuç üretir. Eşleme tablosu kaynak, doğrulayan kişi, tarih ve geçerlilik durumu içermelidir. Belirsiz eşlemeler doğrulanmış gibi gösterilmemelidir. Otomatik keşif önerileri insan onayına sunulabilir.
Zaman damgası, kalite ve veri gecikmesi
IoT verisinin yerel sunucuda tutulması ölçümlerin doğru olduğu anlamına gelmez. Sensör arızası, iletişim kesintisi, gecikme ve yeniden gönderim nedeniyle son görülen değer güncel olmayabilir. Ölçüm için olay zamanı, alma zamanı, birim, kalite kodu ve kaynak bilgisi saklanmalıdır. Gerçek sıfır değeriyle eksik ölçüm ayrı temsil edilmelidir.
Örneğin bir inverter bağlantısı koptuğunda son güç değeri canlı üretim gibi gösterilmemelidir. Arayüz son geçerli ölçümü ve bağlantı kaybını ayrı açıklamalıdır. Tarihsel analizlerde geç gelen ölçümlerin nasıl işlendiği tanımlanmalıdır. Kullanıcı alarmının hangi kalite koşullarında üretileceği test edilmelidir.
Yerel harita ve üç boyutlu görüntüleme bağımlılıkları
BIM/GIS arayüzü çevrimdışı çalışacaksa harita döşemeleri, koordinat dönüşüm kaynakları, üç boyutlu katmanlar ve fontlar yerel ortamda sunulmalıdır. Tarayıcının bir dış CDN'den JavaScript veya stil dosyası yüklemesi veri egemenliği ve süreklilik beklentisini bozabilir. Ayrıca kullanılan harita verisinin lisansı yerel kopyalamaya izin vermelidir. Harita ve BIM koordinatlarının doğruluğu ayrı test edilmelidir.
Pilot sırasında istemci tarayıcısının ve uygulama sunucusunun ağ istekleri gözlenebilir. Dış erişim kapalıyken model görüntüleme, varlık arama, belge açma ve izin verilen harita işlevleri çalışmalıdır. Dış kaynak gerektiren fonksiyonlar varsa istisna ve alternatif çözüm belgelenmelidir. Görsel yerleşim mühendislik koordinat doğruluğunun yerine geçmez.
Kimlik doğrulama ve kapalı ağ işletimi
Kurumsal SSO, LDAP veya kimlik sağlayıcısı entegrasyonu kapalı ağ mimarisinde ayrı tasarım gerektirir. Dış bulut kimlik sağlayıcısına zorunlu bağımlılık varsa internet kesildiğinde oturum açma etkilenebilir. Yerel kimlik hizmeti, sertifika yenileme, MFA yöntemleri ve acil erişim süreçleri birlikte değerlendirilmelidir. Acil erişim hesabı kalıcı sınırsız yetki anlamına gelmemelidir.
Kabul testinde normal kullanıcı, yönetici, yetkisiz kullanıcı ve farklı tenant senaryoları denenmelidir. Oturum süresi, parola politikası, yetki iptali ve denetim izi kontrol edilmelidir. Kullanıcı arayüzünde gizlenen verinin API üzerinden erişilebilir olmaması gerekir. Kimlik altyapısı kesintisi için işletme prosedürü hazırlanmalıdır.
Güncelleme ve yazılım tedarik zinciri
Çevrimdışı veya kısıtlı ağda çalışan platformların güvenlik güncellemeleri yine de düzenli uygulanmalıdır. Bu nedenle imzalı sürüm paketleri, bağımlılık envanteri, bütünlük doğrulaması, test ortamı ve geri alma prosedürü tasarlanmalıdır. Otomatik dış depo erişimi yerine kontrollü paket aktarımı kullanılabilir. Ancak bu süreç gecikmiş güvenlik yamaları riskini de yönetmelidir.
Yükleniciden yazılım bileşen listesi, sürüm politikası ve kritik güvenlik açığı müdahale yöntemi istenebilir. Pilot sırasında internet olmadan güncelleme, yeniden başlatma ve rollback testi yapılmalıdır. Paketlerin hangi kanaldan ve kimin onayıyla içeri alındığı kaydedilmelidir. Destek sözleşmesi güvenlik düzeltmeleri için makul yanıt sürelerini belirtmelidir.
Uzaktan destek ve tanılama paketleri
Veri çıkışının en sık gözden kaçan kanallarından biri destek sürecidir. Hata logları, ekran görüntüleri, veri tabanı örnekleri veya tanılama arşivleri tesis kimlikleri ve kullanıcı bilgileri içerebilir. Destek ekibine tam veri tabanı kopyası vermek varsayılan çözüm olmamalıdır. İhtiyaç kadar veri ilkesi, maskeleme ve onaylı aktarım kanalları tanımlanmalıdır.
Örneğin bir hata için yalnızca anonimleştirilmiş olay kimliği ve sürüm bilgisi yeterli olabilir. Uzak bağlantı gerekiyorsa zaman sınırlı yetki, oturum kaydı, çift onay ve veri aktarım denetimi düşünülebilir. 'Uzaktan destek yok' gereksinimi varsa yerinde destek ve çevrimdışı tanılama prosedürü hazırlanmalıdır. Bu sınırlar teklif aşamasında açıklanmalıdır.
Yedekleme, felaket kurtarma ve veri yaşam döngüsü
Birincil veri tabanının yerel olması yedeklerin ve felaket kurtarma kopyalarının da yerel olduğu anlamına gelmez. Otomatik bulut yedekleri, yönetilen izleme servisleri ve harici arşivler veri akışına dahil edilmelidir. Kurtarma noktası hedefi ve kurtarma süresi hedefi işletme etkisine göre belirlenmelidir. Yedeklerin şifrelenmesi kadar geri yükleme testleri de önemlidir.
Veri saklama süresi, silme talebi, arşiv ve imha prosedürleri sınıflandırmaya göre belirlenmelidir. Pilot kabulünde yedekten geri dönüş ve yetki kontrolü test edilebilir. Günlük logların sınırsız tutulması veri minimizasyonuyla çelişebilir. Sözleşme sonunda verilerin teslimi ve tedarikçi kopyalarının silinmesi için doğrulanabilir süreç tanımlanmalıdır.
Sınır ötesi aktarımı teknik olarak nasıl denetlemeli?
Sadece tedarikçinin yazılı beyanı yerine ağ ve uygulama seviyesinde kanıt toplanmalıdır. Güvenlik duvarı çıkış kayıtları, DNS sorguları, proxy logları, bağımlılık listesi ve tarayıcı ağ istekleri birlikte değerlendirilebilir. Şifreli trafik içeriğini açmak her zaman gerekli veya uygun değildir; hedef, yön ve işlev üzerinden izinli akışlar doğrulanabilir. İzleme kapsamı çalışan mahremiyeti ve hukuki yükümlülüklerle uyumlu olmalıdır.
Kabul testinde internet erişimi kesilerek temel işlevler denenebilir. Ayrı bir testte yalnızca izinli hedeflere çıkış verilip beklenmeyen bağlantılar raporlanabilir. Üçüncü taraf bileşen güncellemesi sonrası test tekrarlanmalıdır. Sıfır sınır ötesi aktarım iddiası yalnızca test edilen sürüm, yapılandırma ve kullanım senaryosu için kanıtlanabilir.
Hukuki uygunluk ve teknik kanıtın sınırları
KVKK ve sektörel yükümlülükler veri türü, işleme amacı, aktörlerin rolü ve aktarım koşullarına göre değişebilir. Verinin fiziksel olarak ülkede bulunması tek başına bütün hukuki yükümlülüklerin karşılandığını göstermez. Uzaktan erişim, destek, alt işleyenler ve kullanıcı hesapları ayrıca değerlendirilmelidir. Teknik mimari hukuk danışmanlığının yerine geçmez.
Hukuk, bilgi güvenliği ve işletme ekipleri veri akış envanterini birlikte incelemelidir. Sözleşmede veri işleme rolleri, alt yükleniciler, olay bildirimi ve çıkış koşulları netleşmelidir. Teknik ekip izinli akışları ve denetim kanıtlarını üretmelidir. Düzenleyici yorumların güncel mevzuata göre uzmanlarca doğrulanması gerekir.
İki aşamalı pilot: bağlantılı ve bağlantısız işletim
İlk aşamada sistem kontrollü test ağında kurulur ve tüm dış bağımlılıklar gözlenir. İkinci aşamada dış internet bağlantısı kapatılarak kullanıcı oturumu, BIM görüntüleme, varlık arama, belge erişimi, yerel telemetri alımı, alarm görüntüleme ve yedekten geri yükleme denenir. Hangi fonksiyonların kapsamda olduğu önceden açıklanmalıdır. Test sonuçları sürüm ve yapılandırmayla ilişkilendirilmelidir.
Örneğin harita görüntüleniyor ancak lisans yenileme belirli süre sonra başarısız oluyorsa pilot henüz tam çevrimdışı işletim kanıtı değildir. Süreye bağlı bağımlılıklar için uzun dönem test planlanmalıdır. Güvenlik güncellemesi ve rollback de internet olmadan denenmelidir. Başarısız işlevler için düzeltme ve tekrar test kapısı bulunmalıdır.
Satın alma için veri egemenliği kabul matrisi
Teknik şartname veri sınıflandırması, saklama yeri, izinli ağ hedefleri, alt işleyenler, uzaktan destek, güncelleme, yedekleme, kimlik doğrulama ve dışa aktarım koşullarını ayrı maddeler halinde istemelidir. Her madde için tedarikçi beyanı yanında doğrulanabilir test veya belge talep edilmelidir. Örneğin 'internet olmadan temel fonksiyonlar çalışır' şartı gerçek pilot ortamında denenmelidir.
Teklif değerlendirmesinde açık istisnalar ve üçüncü taraf bağımlılıklar görünür olmalıdır. Yalnızca 'on-prem' etiketiyle tam puan verilmemelidir. Kabul sonrası sürüm değişikliği yeni dış bağlantı oluşturabileceği için değişiklik kontrolü ve yeniden doğrulama planlanmalıdır. Bu yöntem veri egemenliğini pazarlama iddiasından denetlenebilir mühendislik gereksinimine dönüştürür.
Not: Teknik standartlara ilişkin açıklamalar bilgilendirme amaçlıdır. Ürün yetenekleri ve entegrasyon kapsamı proje bazında doğrulanmalıdır.