← Tüm hizmetler

OCTATUS / TEKNİK HİZMET KAPSAMI

BIM–IoT Kurumsal Veri Politikası ve Yerel Dağıtım Danışmanlığı

Müşterinin kurumsal güvenlik politikası verilerin kurum veya ülke dışına çıkmasını sınırlandırıyorsa, BIM ve IoT mimarisini bu talebe göre tasarlayın ve doğrulayın.

Kapsam görüşmesi talep edin ↗

Teknik yaklaşım ve çalışma yöntemi

Müşterinin yazılı veri politikası ve güvenlik gereksinimleri alınır: ülke dışına çıkış yasağı, kurum dışına çıkış yasağı, internet bağlantısı kısıtı, uzaktan erişim ve üçüncü taraf bulut koşulları ayrı ayrı belirlenir.

BIM, GIS, BMS, SCADA, IoT, lisans, destek, bildirim ve yedekleme veri akışları envanterlenir. Kurumsal gereksinime göre Türkiye içi barındırma, kurum içi kurulum veya bağlantısız çalışma seçenekleri değerlendirilir.

Üretici bulutuna bağımlı cihazlar için yerel protokol, edge gateway, çevrimdışı lisans veya alternatif cihaz seçenekleri incelenir; seçilen tasarımın ağ çıkış ve işlevsel kabul testleri hazırlanır.

Kapsamlı hizmet rehberi

GÜVENLİ VERİ MİMARİSİTampon / kaliteKimlik / TLSDenetimOT / IoT edge01Güven sınırı02Yerel veri katmanı03Yetkili kullanıcı04Şematik yaklaşım • Projeye özel veri sözleşmesi ve kabul koşulları ayrıca belirlenir.
güvenli veri mimarisi: kaynaklar, dönüşümler ve doğrulama adımlarının şematik gösterimi.

Veri egemenliği bir sunucu konumu kararı değildir

BIM–IoT veri egemenliği, verinin nerede tutulduğundan daha geniş bir yönetim problemidir. Kurumun fiziksel varlık modelleri, ölçüm akışları, kimlik kayıtları, erişim günlükleri ve yedekleri üzerinde hangi yetkiyi kullanabildiği değerlendirilir. Verinin ülkede tutulması tek başına erişim kontrolünü, şifrelemeyi veya bağımsız işletimi garanti etmez. Bulut hizmetinin yönetim düzlemi ve üçüncü taraf destek erişimi de mimarinin parçasıdır.

Danışmanlık çalışması, hangi verinin hassas olduğunu ve hangi kararların kurumun kontrolünde kalması gerektiğini kullanım senaryolarıyla ilişkilendirir. Tesisin enerji tüketim verisi ile kritik ekipman yerleşimi aynı güvenlik sınıfında olmayabilir. Genel bir veri yerleşimi tercihi yerine veri sınıfına, sözleşmeye ve mevzuat değerlendirmesine dayalı kurallar oluşturulur.

Kurumsal veri sınıflandırma matrisi

IFC modelleri, GIS katmanları, BMS noktaları, SCADA etiketleri, IoT telemetrisi, bakım belgeleri ve kullanıcı hareket kayıtları ayrı veri kümeleridir. Her küme için gizlilik, bütünlük, erişilebilirlik ve saklama gereksinimleri belirlenmelidir. Örneğin kritik altyapı konum bilgisi düşük değişim hızına sahip olsa da yetkisiz ifşası ciddi sonuç doğurabilir.

Sınıflandırma matrisi veri sahibi, iş amacı, paylaşılabilecek taraflar, saklama süresi, izin verilen dağıtım bölgesi ve silme koşullarını içermelidir. Hassasiyet etiketi yalnızca dosya klasörüne değil API yanıtına, dışa aktarmaya ve yedek kopyasına da uygulanmalıdır. Kurumun mevcut güvenlik politikasıyla çelişen yeni etiketler oluşturulmamalıdır.

BT ve OT güven sınırlarının ayrılması

OT ağları fiziksel prosesleri izleyen ve bazen kontrol eden sistemleri barındırır. BIM veya dijital ikiz arayüzünün işletme verisini görüntüleme ihtiyacı, bu arayüzün kontrol ağına doğrudan erişmesini gerektirmez. Ağ segmentasyonu, veri diyodu veya kontrollü aracı katman gibi seçenekler tesis riskine göre değerlendirilebilir.

Özellikle SCADA komutlarının kullanıcı arayüzüne taşınması ayrı bir güvenlik ve yetkilendirme projesidir. Salt okunur telemetri ile uzaktan kontrol aynı risk seviyesinde değerlendirilmez. Ağ sınırları çizilirken veri akış yönü, bağlantı başlatan taraf, kullanılan portlar ve kesinti durumunda sistem davranışı belgelenmelidir.

Yerel, hibrit ve bulut dağıtım seçenekleri

Yerel kurulum kurumun ağ ve altyapı kontrolünü artırabilir ancak donanım yenileme, yedekleme, izleme ve güvenlik güncellemeleri sorumluluğunu da kuruma bırakır. Bulut yaklaşımı işletme kolaylığı sağlayabilir fakat dış bağımlılıklar ve veri yerleşimi koşulları doğurabilir. Hibrit mimari bazı verileri yerelde tutup seçilmiş raporları dış ortama taşıyabilir.

Karşılaştırmada yalnızca aylık lisans bedeli değil ağ gecikmesi, kesintiye dayanıklılık, destek erişimi, veri taşınabilirliği, kurtarma hedefleri ve uzman personel ihtiyacı değerlendirilir. Her müşteri için tek doğru dağıtım modeli bulunduğu varsayılmaz. Nihai seçim kurum politikası ve teknik kabul testlerine dayanmalıdır.

Çevrimdışı çalışma ve bağımlılık haritası

Yerel kurulmuş bir uygulama, lisans doğrulama, harita servisleri, kimlik sağlayıcı veya paket güncellemesi için internete bağımlı olabilir. Bu bağımlılıklar incelenmeden çevrimdışı çalışır iddiası kurulamaz. BIM görüntüleyici, IoT toplama, arama, kimlik doğrulama ve raporlama işlevleri ayrı ayrı test edilmelidir.

İnternet bağlantısı kesildiğinde hangi işlevlerin çalıştığı, hangilerinin yalnızca önbellekteki veriyle devam ettiği ve hangi uyarıların gösterildiği kaydedilir. Dış bağımlılık kesintisi ile yerel OT ağı kesintisi farklı testlerdir. Operatör eski veriyi canlı sanmamalıdır.

IoT edge mimarisi ve tamponlama

Sensör ve kontrol sistemlerinden gelen veriyi sahaya yakın edge katmanında toplamak ağ yükünü ve doğrudan erişim ihtiyacını azaltabilir. Edge ajanının kimliği, sürümü, yapılandırması, veri tampon sınırı ve yeniden bağlanma davranışı yönetilmelidir. MQTT veya diğer mesajlaşma yöntemleri kullanılacaksa teslim garantisi ve mükerrer olay davranışı açıklanmalıdır.

Bağlantı kesintisinde veri tamponu dolarsa hangi kayıtların korunacağı ve hangi kaybın raporlanacağı tanımlanır. Saat kayması, sırasız olay, tekrar gönderim ve bozuk veri paketi negatif testlere dahil edilir. Edge bileşeninin otomatik güncellenmesi kritik tesislerde kontrollü bakım penceresi gerektirebilir.

Veri sözleşmesi ve kaynak doğruluğu

Bir telemetri kaydı yalnızca sayıdan ibaret değildir. Ölçüm noktası kimliği, olay zamanı, alım zamanı, birim, kalite durumu, kaynak sürümü ve gerekiyorsa kalibrasyon bilgisi taşınmalıdır. BIM varlığına yanlış eşlenmiş doğru bir sensör değeri de yanlış işletme kararına neden olabilir.

Veri sözleşmesi alanların anlamını, zorunluluk koşullarını, geçersiz değer davranışını ve şema sürümünü açıkça tanımlar. Eski cihaz yazılımı yeni alanları üretmiyorsa sessiz varsayılan değerle hata gizlenmemelidir. Sözleşme testleri gerçek üretici örnekleri ve kasıtlı bozuk mesajlarla yapılmalıdır.

Kimlik yönetimi ve servis hesapları

Kullanıcı kimlikleri, edge ajanları, API istemcileri ve üçüncü taraf entegrasyonlar ayrı güvenlik özneleridir. Tek bir paylaşılan yönetici hesabıyla bütün kaynaklara bağlanmak olay incelemesini ve yetki iptalini zorlaştırır. Servis hesaplarına en az yetki verilmeli ve mümkün olduğunda kısa ömürlü kimlik bilgileri kullanılmalıdır.

Kimlik sağlayıcı kesintisi, sertifika süresinin dolması ve görev değişikliği gibi durumlar için süreç tanımlanır. Bir çalışanın erişimi kaldırıldığında API token ve dışa aktarma yetkilerinin de iptal edildiği doğrulanmalıdır. Kimlik yönetimi yalnızca giriş ekranı tasarımı değildir.

Şifreleme ve anahtar yaşam döngüsü

Aktarım ve depolama şifrelemesi verinin korunmasına katkı sağlar fakat anahtarların kimin kontrolünde olduğu ayrıca değerlendirilmelidir. Yedekleme, log toplama ve dış servis bağlantılarında da şifreleme kapsamı netleştirilir. Şifreli veri üzerinde yanlış yetkilendirme hâlâ bilgi sızıntısına yol açabilir.

Anahtar üretimi, saklama, rotasyon, erişim denetimi ve acil kurtarma prosedürleri tanımlanmalıdır. Kurumun anahtar kontrolü gereksinimi varsa yönetilen servis seçeneklerinin teknik sınırları incelenir. Şifreleme var diye veri bütünlüğü veya uygulama güvenliği testleri atlanmamalıdır.

BIM ve GIS verilerinde erişim ayrıntısı

Bir BIM modelinin bütün katlarını aynı kullanıcıya açmak gerekli olmayabilir. Güvenlik kritik teknik hacimler, ağ bağlantıları ve ekipman bilgileri farklı erişim sınıfları isteyebilir. GIS katmanlarında da kritik altyapı güzergâhı ile kamuya açık bina konumu aynı ayrıntı seviyesinde sunulmayabilir.

Yetki kontrolü yalnızca arayüzde katmanı gizlemekten ibaret değildir; API, dosya indirme, arama ve dışa aktarma işlemlerinde de uygulanmalıdır. Yetkisiz kullanıcıya hassas nesne kimliklerinin veya koordinatlarının hata mesajıyla sızmaması test edilmelidir. Gerektiğinde genelleştirilmiş görsel temsil kullanılır.

Zaman serisi saklama ve veri yaşam döngüsü

Yüksek frekanslı IoT verisinin tamamını süresiz saklamak maliyet ve güvenlik yükü doğurabilir. Ham ölçüm, özetlenmiş veri, olay kaydı ve rapor çıktısı için farklı saklama süreleri belirlenebilir. Ancak veri azaltma kararı garanti, denetim ve kök neden analizi ihtiyaçlarını dikkate almalıdır.

Silme, arşivleme ve anonimleştirme işlemleri veri sınıfına göre planlanır. Eski ölçümlerin özetlenmesi sırasında kalite bayrakları ve veri boşlukları kaybolmamalıdır. Yasal saklama gereksinimleri proje özelinde yetkili uzmanlarca değerlendirilir; genel bir süre bütün kurumlara dayatılmaz.

Yedekleme, RPO ve RTO tasarımı

RPO kabul edilebilir veri kaybı süresini, RTO ise hizmetin geri dönmesi için hedeflenen süreyi ifade eder. BIM dosyaları, varlık eşleme tabloları, zaman serileri ve kimlik yapılandırmaları aynı kurtarma hedefini gerektirmeyebilir. Kritik eşleme verisinin kaybı, büyük miktarda yeniden üretilebilir görsel önbelleğin kaybından daha ağır sonuç doğurabilir.

Yedekleme stratejisi yalnızca dosyanın kopyalandığını göstermekle kabul edilmez. Seçilmiş bir sürümün temiz ortama geri yüklenmesi, kullanıcı yetkilerinin korunması ve veri tutarlılığının doğrulanması gerekir. Kurtarma testleri gerçek süreyi ölçmeli ve başarısız adımları kaydetmelidir.

Denetim izi ve değiştirilemezlik ihtiyacı

Kritik varlık verisinde kim, hangi kaydı, hangi kaynaktan ve hangi tarihte değiştirdi soruları yanıtlanabilmelidir. Denetim izi kullanıcı işlemleri kadar otomatik entegrasyon güncellemelerini de kapsar. Dosya özeti ve imza bütünlük kontrolüne yardımcı olabilir fakat mühendislik doğruluğunu tek başına kanıtlamaz.

Log saklama, erişim, zaman senkronizasyonu ve bütünlük kontrolleri kurumun risk politikasına göre belirlenir. Logların merkezi toplanması kendi başına yetkisiz değişikliği engellemez. Kritik olayların izlenebilirliği negatif testlerle doğrulanmalıdır.

Tedarikçi ve alt işleyen bağımlılıkları

Üçüncü taraf harita servisi, bulut izleme aracı, e-posta sağlayıcı veya uzaktan destek hizmeti veri akışının parçası olabilir. Bu bağımlılıklar mimari diyagramda gösterilmelidir. Tedarikçinin hangi verilere erişebildiği ve erişimin hangi koşullarda açıldığı sözleşmede net olmalıdır.

Alt işleyen listesi, veri yerleşimi, olay bildirimi, çıkış hakkı ve taşınabilirlik koşulları gözden geçirilir. Bir sağlayıcının sertifikası kurumun kendi uygulama kontrollerini otomatik doğrulamaz. Destek erişimi kapatıldığında sistemin işletilmeye devam edip etmediği test edilmelidir.

Veri taşınabilirliği ve çıkış planı

Veri egemenliği, kurumun sistem değiştirdiğinde kendi verisini anlamlı biçimde dışarı alabilmesini de içerir. IFC, GIS verileri, varlık eşleme tabloları, olay geçmişi ve doküman bağlantıları birlikte değerlendirilmeli; yalnızca dosya arşivi yeterli görülmemelidir.

Çıkış testinde örnek varlıklar başka ortama taşınır; kimlik, ilişki, zaman damgası ve kanıt zinciri korunuyor mu incelenir. Özel API ve kapalı veri formatı bağımlılıkları maliyet hesabına eklenir. Sözleşme sona erdiğinde silme ve teslim kanıtı süreçleri tanımlanmalıdır.

Örnek senaryo: kritik enerji tesisi

Bir enerji tesisinde inverter, trafo, sayaç ve saha telemetrisi farklı güvenlik bölgelerinde tutulabilir. Octatus BIM/GIS ve fiziksel varlık bağlamını sağlayabilir; Enlogy gibi uzman enerji sistemi ölçüm ve operasyonel analiz verisinin kaynağı olabilir. Bu ilişki OT kontrol komutlarının BIM arayüzüne taşınmasını gerektirmez.

Pilot bir trafo ve seçilmiş ölçüm noktalarıyla sınırlandırılır. Ağ kesintisi, eski veri, yanlış tag eşlemesi ve yetkisiz API erişimi test edilir. Veri akışı kesildiğinde kullanıcıya son ölçüm zamanı gösterilir. Kontrol yetkisi uzman sistem ve tesis prosedürlerinde kalır.

Örnek senaryo: çok binalı kamu kampüsü

Kamu kampüsünde BIM modelleri, bakım envanteri ve BMS ölçümleri farklı yüklenicilerce üretilmiş olabilir. Yerel dağıtım tercihinin nedeni kritik mekân bilgisi ve ağ erişim politikası olabilir. İlk pilotta iki bina ve ortak altyapı hattı seçilerek kullanıcı rolleri, veri güncelliği ve dış bağımlılıklar test edilir.

Örnek uygulamada tesis yöneticisi gerekli ekipman konumuna erişirken dış yüklenicinin yalnızca yetkilendirildiği varlıkları görmesi beklenir. İnternet bağlantısı kesildiğinde temel varlık araması ve yerel belge erişimi sınanır. Test sonuçları dağıtım modelinin uygunluğunu belirler; önceden kesin başarı varsayılmaz.

Örnek senaryo: veri merkezi işletmesi

Veri merkezinde fiziksel enerji ve soğutma varlıklarıyla BT servis bağımlılıkları birlikte değerlendirilebilir. Argamos gibi uzman BT yönetim sistemi servis ilişkilerinin kaynağı olabilir; Octatus fiziksel varlık bağlamını sağlayabilir. Ancak servis bağımlılığı elektriksel besleme bağlantısının doğruluğunu otomatik kanıtlamaz.

Pilot seçilmiş UPS, soğutma cihazı ve BT servislerinde kimlik eşlemesiyle başlar. Yanlış seri numarası, eski servis bağımlılığı ve yetkisiz veri dışa aktarımı test edilir. Kaynak sistemlerdeki veri otoritesi korunur; uzman ürünün tüm işlevleri Octatus'un yerleşik modülü gibi sunulmaz.

Güvenlik kabul matrisi ve negatif testler

Kabul kriterleri yetkisiz erişim, ağ kesintisi, kimlik sağlayıcı arızası, sertifika süresinin dolması, eski telemetri, yedekten geri dönüş ve veri dışa aktarma senaryolarını kapsamalıdır. Her testin beklenen sonucu, gözlenen sonuç, kanıtı ve düzeltme sahibi kaydedilir.

Kritik risklerde genel başarı yüzdesi yerine zorunlu kontrol kapıları tanımlanabilir. Test edilen sürüm ve dağıtım topolojisi değiştiğinde önceki kabulün kapsamı yeniden değerlendirilir. Hata gizlenmeden raporlanmalı ve operatörün yanlış güncellik algısı oluşturması önlenmelidir.

Teslimatlar ve mimari karar kayıtları

Hizmet çıktıları veri sınıflandırma matrisi, sistem ve veri akış diyagramı, güven sınırları, dağıtım seçenekleri karşılaştırması, kimlik ve anahtar politikası, saklama kuralları, kurtarma hedefleri, risk register'ı ve kabul test planını içerebilir. Her kararın gerekçesi ve reddedilen alternatifler kaydedilmelidir.

Danışmanlık belgesi ile gerçek kurulum, penetrasyon testi, bağımsız güvenlik denetimi ve sertifikasyon farklı iş kapsamlarıdır. Teslimatın düzenlenebilir biçimde verilmesi sonraki tedarikçi ve işletme ekipleri için önemlidir. Kurumun yetkili güvenlik ekibi nihai karar sahibi olarak kalmalıdır.

Maliyet ve 90 günlük pilot planı

İlk ay veri sınıflandırması, kaynak envanteri ve güven sınırları çıkarılır. İkinci ay dağıtım alternatifleri, edge mimarisi ve güvenlik kontrolleri tasarlanır. Üçüncü ay seçilmiş pilotta ağ kesintisi, erişim, yedekleme ve veri taşınabilirliği test edilir. Bu süre örnektir ve tesis ölçeğine göre değişebilir.

Toplam maliyet sunucu, depolama, ağ, güvenlik lisansı, yedekleme, izleme, uzman personel, güncelleme ve tedarikçi destek kalemlerini kapsar. Yerel kurulumun mutlaka daha ucuz veya daha güvenli olduğu iddia edilmemelidir. Faz geçişi test kanıtlarına bağlı olmalıdır.

Sık sorulan sorular ve kapsam sınırları

'Veri Türkiye'de tutulursa tamamen güvende midir?' Hayır; erişim, anahtar, yedekleme ve destek yolları da değerlendirilmelidir. 'Yerel kurulum internetsiz çalışır mı?' Yalnızca dış bağımlılıklar test edilirse söylenebilir. 'BIM modeli OT ağında mı bulunmalı?' Genellikle bağlam sunumu ile kontrol ağı ayrıştırılır.

'Octatus SCADA kontrolünü devralır mı?' Uzman operasyonel kontrol ayrı sistemde kalabilir; doğrulanmış kapsam incelenmelidir. 'Danışmanlık mevzuata uygunluk sertifikası verir mi?' Hayır; risk ve mimari kararları belgelendirir. 'Veri çıkış planı neden gerekli?' Sistem değiştiğinde kimlik, ilişki ve geçmişin korunabilmesi için gereklidir.

Veri akış haritası ve sınır geçişlerinin belgelenmesi

Veri egemenliği değerlendirmesinde ilk çıktı sunucu yerleşim çizimi değil, uçtan uca veri akış haritasıdır. BIM dosyası, GIS katmanı, IoT ölçümü, alarm, kullanıcı kimliği ve destek günlüğü farklı hassasiyet ve saklama gereksinimlerine sahip olabilir. Her akış için veri üreticisi, aktarma protokolü, aracı servis, kalıcı depolama yeri, erişen rol ve silme koşulu kaydedilmelidir. Özellikle harita döşemesi, dış kimlik sağlayıcı ve uzaktan destek bağlantısı gibi dolaylı bağımlılıklar gözden kaçırılmamalıdır.

Örnek kampüs mimarisinde sayaç verisi yerel edge ajanından kurumsal broker'a aktarılırken BIM modeli kurum içi depoda tutulabilir. Harita ekranı harici bir tile servisine bağlanıyorsa kullanıcı IP adresi ve görüntülenen bölge gibi bilgiler dış hizmete ulaşabilir. Bu durum kurumun veri politikasına göre ayrıca değerlendirilir. Akış haritası yalnızca normal çalışmayı değil hata raporlaması, yedekleme ve bakım erişimi sırasında gerçekleşen aktarımı da göstermelidir. Sonuç, her bağlantı için izin verilen veri sınıfını belirleyen bir karar tablosuna dönüştürülür.

OT edge cihazlarında güvenli başlangıç ve güncelleme

Sahaya kurulan edge bilgisayarı kurumsal ağın dışında fiziksel erişim riski taşıyabilir. Güvenli başlangıç, işletim sistemi sertleştirme, disk koruması ve servis hesaplarının yönetimi cihazın işlevine göre değerlendirilmelidir. Ajanın merkezi sunucudan yapılandırma çekmesi yararlı olsa da bu mekanizma yetkisiz komut çalıştırma kanalı hâline gelmemelidir. Güncelleme paketinin kaynağı ve bütünlüğü doğrulanmalı; başarısız sürüm yükseltmesinden geri dönüş tasarlanmalıdır.

Örnek kabul testinde imzası geçersiz bir ajan paketi gönderilir ve cihazın paketi reddettiği doğrulanır. Ağ bağlantısı güncelleme ortasında kesildiğinde eski çalışan sürümün korunması beklenir. Cihazın yerel günlükleri disk doluluğuna neden olmayacak şekilde sınırlandırılır. Fiziksel bakım için açılan geçici hesaplar iş bitiminde kapatılır. Bu kontrollerin tamamının her cihazda mevcut olduğu varsayılmaz; donanım ve işletim sistemi kabiliyeti envanter üzerinden doğrulanır.

Servis kimliği, sertifika rotasyonu ve gizli bilgi yönetimi

Edge ajanları, API servisleri ve veri aktarım işleri insan kullanıcılardan farklı kimliklerle çalışmalıdır. Ortak parola veya aynı sertifikanın bütün tesislerde kullanılması bir cihaz ele geçirildiğinde etki alanını büyütebilir. Her servis kimliğinin erişebildiği kaynaklar, sertifika süresi, yenileme yöntemi ve iptal prosedürü kayıt altına alınmalıdır. Gizli bilgiler kaynak koduna, container imajına veya genel günlük dosyasına yazılmamalıdır.

Pilot senaryoda tek bir edge cihazının sertifikası iptal edilir. Diğer tesislerin veri akışının devam ettiği, iptal edilen cihazın yeniden bağlanamadığı ve olayın denetim kaydına işlendiği doğrulanır. Sertifika yenileme sırasında kısa süreli bağlantı kesintisinin kabul edilebilir olup olmadığı veri kritikliğine göre belirlenir. Kimlik sağlayıcısı ulaşılamaz olduğunda sistemin güvenlik kontrollerini sessizce devre dışı bırakmaması gerekir. Acil durum erişimi ayrı onay ve kayıt sürecine bağlanmalıdır.

Tenant ve tesis sınırlarında yetki testleri

Çok müşterili veya çok tesisli bir platformda veri egemenliği yalnızca kullanıcı rolüyle çözülemez. Sorgular, önbellekler, nesne depoları, arama indeksleri ve arka plan işleri aynı tenant sınırını uygulamalıdır. Bir tesiste yetkili bakım personelinin başka tesise ait IFC dosyasını dosya adresini tahmin ederek açabilmesi kabul edilemez. Kaynak verinin paylaşımı gerekiyorsa açık kapsam ve yetki kaydı bulunmalıdır.

Örnek negatif testte iki tenant için benzer varlık kodları oluşturulur. Kullanıcı A'nın B tenantına ait varlığı API, arama ve dosya indirme üzerinden göremediği doğrulanır. Bir arka plan işinin yanlış tenant bağlamıyla çalışması ayrıca test edilir. Tenant filtresi yalnızca istemci arayüzünde uygulanmamalıdır. Yetki iptali sonrası önbellekteki eski yanıtların erişime açık kalmaması da kabul ölçütüdür. Denetim kayıtlarında erişim denemesinin sonucu ve kullanılan servis kimliği bulunmalıdır.

Yedekleme bütünlüğü ve geri yükleme tatbikatı

Yedekleme planında veri tabanı, BIM dosyaları, GIS katmanları, edge yapılandırmaları ve şifreleme anahtarları farklı kurtarma bağımlılıklarına sahip olabilir. Veritabanı geri yüklenip dosya deposu eski sürümde kalırsa varlık bağlantıları kırılabilir. Bu nedenle yedeklerin zaman tutarlılığı ve geri yükleme sırası tasarlanmalıdır. RPO ve RTO hedefleri iş etkisi analizinden türetilir; her kurum için tek değer önerilmez.

Örnek tatbikatta üretimden izole bir ortam oluşturulur. Seçilmiş tarihli yedekler geri yüklenir, kullanıcı kimliği bağlantısı, BIM varlık araması ve örnek telemetri geçmişi doğrulanır. Geri yükleme süresi ölçülür; bozuk dosya, eksik anahtar ve yanlış şema sürümü gibi durumlar kaydedilir. Yedeğin varlığı başarılı kurtarma anlamına gelmez. Tatbikat raporu hangi veri aralığının kurtarıldığını ve hangi bağımlılıkların elle düzeltildiğini açıkça belirtmelidir.

Çevrimdışı çalışma ve tutarlılık çatışmaları

Yerel kurulum ile çevrimdışı çalışma aynı şey değildir. Bir tesis ağdan ayrıldığında kimlik doğrulama, lisans, harita, dosya erişimi ve saat senkronizasyonu bağımlılıkları etkilenebilir. Edge ajanları ölçüm toplamaya devam ederken merkezdeki varlık eşleme tablosu değişmiş olabilir. Yeniden bağlantı kurulduğunda eski eşlemeyle üretilen verilerin yanlış cihaza bağlanmaması gerekir. Tutarlılık politikası veri türüne göre tanımlanmalıdır.

Örnek testte ağ kesintisi sırasında sahada bir sensör değiştirilir. Edge cihazı eski yapılandırmayla veri toplamaya devam eder. Bağlantı geri geldiğinde ölçüm olayları üretildikleri eşleme sürümüyle değerlendirilir; yeni sensörün geçmişi eski cihazla sessizce birleştirilmez. Aynı varlık üzerinde iki tarafta yapılan değişiklikler çatışma kuyruğuna alınabilir. Çatışma çözümü için veri otoritesi ve insan onayı gerekip gerekmediği önceden belirlenir.

Saklama süresi, silme ve hukuki muhafaza

BIM modelleri, telemetri, güvenlik günlükleri ve kullanıcı işlem kayıtları farklı sürelerle saklanabilir. Bir verinin artık aktif sistemde görünmemesi yedeklerden ve arşivlerden silindiği anlamına gelmez. Saklama politikası veri sınıfı, yasal yükümlülük, işletme gereksinimi ve olay inceleme ihtiyacına göre hazırlanmalıdır. Veri silme talepleri ile hukuki muhafaza yükümlülükleri çelişebilir; karar yetkisi kurumun hukuk ve güvenlik ekiplerinde olmalıdır.

Örnek senaryoda sözleşmesi biten bir tesisin verileri dışa aktarılır ve aktif erişimi kapatılır. Sistem hangi veri kümelerinin silindiğini, hangi yedeklerde geçici olarak kaldığını ve ne zaman silineceğini raporlamalıdır. Denetim izinin tamamını silmek bazı yükümlülüklerle çelişebilir. Bu nedenle kişisel veri ve kritik altyapı verisi sınıfları ayrı değerlendirilir. Teknik tasarım belirli mevzuata otomatik uyumluluk iddiası olarak sunulmaz.

Harici servisler ve tedarik zinciri risk değerlendirmesi

Yerel barındırılan bir uygulama bile paket deposu, konteyner imajı, kimlik sağlayıcısı, harita servisi veya uzaktan hata izleme sistemi kullanabilir. Her harici bağımlılık için hangi verinin dışarı çıktığı, hizmetin kesilmesi hâlinde ne olacağı ve alternatifinin bulunup bulunmadığı incelenmelidir. Yazılım bileşen envanteri ve güvenlik güncelleme süreci tedarikçi bağımlılığını yönetmek için önemlidir.

Örnek değerlendirmede üretim ortamının internet erişimi kesilir. Uygulamanın temel varlık araması çalışırken harita döşemeleri yüklenmiyorsa bu davranış belgelenir. Kritik işlevlerin harici servise bağımlı olması kabul edilmiyorsa çevrimdışı veri paketi veya kurum içi alternatif değerlendirilir. Güncelleme sırasında kullanılan imajların kaynağı ve sürümü doğrulanır. Üçüncü taraf bileşenlerdeki güvenlik açığının hangi sahaları etkilediği izlenebilir olmalıdır.

Veri dışa aktarımı ve tedarikçiden çıkış tatbikatı

Veri egemenliği, müşterinin veriye erişmesi kadar başka bir platforma geçebilmesini de kapsar. IFC, GIS katmanları, varlık eşleme tabloları, telemetri arşivi ve denetim kayıtlarının dışa aktarılabilirliği sözleşmede tanımlanmalıdır. Dosyanın standart uzantıya sahip olması bütün ilişki ve meta verilerin taşındığını kanıtlamaz. Çıkış planı lisans sona ermeden test edilebilir olmalıdır.

Örnek tatbikatta seçilmiş bir bina ve ona bağlı yüz varlık dışa aktarılır. Bağımsız bir ortamda kimlik, konum, belge bağlantısı ve tarihsel ölçüm eşlemeleri yeniden kurulur. Eksik ilişki, kapalı format veya bozuk koordinat sistemi raporlanır. İhracın süresi ve maliyeti ölçülür; gerekli araçlar ve teknik belgeler teslim edilir. Başarılı çıkış testi yalnızca dosyaların kopyalanması değil işlevsel veri bütünlüğünün korunmasıdır.

Güvenlik olayı müdahalesi ve adli iz bütünlüğü

Kritik tesis veri platformunda güvenlik olayı meydana geldiğinde hangi servisin hangi veriye eriştiğini anlayabilmek gerekir. Günlüklerde zaman damgası, servis kimliği, işlem türü, hedef kaynak ve sonuç bulunmalıdır. Bununla birlikte günlüklerin kendisi hassas veri içerebilir; sınırsız erişime açık bırakılmamalıdır. Saat senkronizasyonu ve kayıt bütünlüğü olay sıralamasını doğrulamak için önemlidir.

Örnek masa başı tatbikatında bir servis hesabının olağan dışı dosya indirdiği varsayılır. Hesap iptal edilir, etkilenen kaynaklar belirlenir ve kayıtlar değişiklik yapılmadan inceleme ortamına alınır. Olay müdahale ekibi gerekli kanıtı korurken sistemin güvenli hizmete dönüş koşullarını değerlendirir. Otomatik alarmın tetiklenmesi olayın doğru sınıflandırıldığı anlamına gelmez. Tatbikat sonrası erişim ve kayıt eksikleri düzeltme planına işlenir.

Siber güvenlik kabulünde saldırı yüzeyi kontrolü

Uygulamanın dışarıdan erişilebilen portları, yönetim API'leri, dosya yükleme yüzeyleri ve edge güncelleme kanalları envantere alınmalıdır. Üretim ortamında gereksiz debug uç noktaları ve varsayılan parolalar bulunmamalıdır. Güvenlik kabulü yalnızca otomatik zafiyet taramasıyla tamamlanmaz; yetki sınırı, dosya işleme ve veri ayrıştırma davranışı da incelenir. Test kapsamı OT sistemlerine zarar vermeyecek şekilde planlanmalıdır.

Örnek kabulde yetkisiz kullanıcı başka tenantın IFC dosyasını istemeye çalışır; sunucu reddeder. Büyük ve bozuk model dosyası kontrollü test ortamında yüklenir; işlem kaynak tüketimi sınırlandırılır ve servis çökmez. Edge ajanı geçersiz yapılandırma aldığında eski güvenli ayarı korur. Test sonuçları güvenlik açığı sınıfı, etkilenen sürüm ve düzeltme kanıtıyla kaydedilir. Üretim OT ağı üzerinde izinsiz aktif tarama yapılmamalıdır.

Kurumsal karar matrisi: bulut, hibrit ve yerel

Dağıtım seçimi yalnızca ilk sunucu maliyetiyle yapılmamalıdır. Kurumun bağlantı sürekliliği, veri sınıflandırması, destek modeli, kurtarma hedefleri, personel yetkinliği ve tedarikçi bağımlılığı birlikte değerlendirilir. Bulut bazı operasyonel yükleri azaltabilir ancak dış veri aktarımı veya bağımlılık yaratabilir. Yerel kurulum ağ denetimini artırabilir fakat yama, yedekleme ve donanım sorumluluğunu kurum üzerinde bırakır.

Karar matrisinde her seçenek için veri akışının izin verilen bölgeleri, kimlik hizmeti bağımlılığı, çevrimdışı davranış, toplam maliyet ve çıkış planı ayrı puanlanır. Örneğin hassas elektrik şebekesi modeli kurum içinde kalırken anonimleştirilmiş operasyon raporu başka ortamda işlenebilir; bunun kabul edilebilirliği veri sahibinin kararına bağlıdır. Seçenekler aynı pilot iş yüküyle test edilmeden yalnızca pazarlama iddialarına göre sıralanmamalıdır.

İşletme devir paketinde güvenlik runbook'u

Güvenli mimari çizimi işletme ekibinin günlük operasyonları yürütebilmesi için yeterli değildir. Runbook içinde sertifika yenileme, edge yeniden başlatma, bağlantı kesintisi, disk doluluğu, yedekten dönüş, erişim iptali ve şüpheli olay prosedürleri bulunmalıdır. Her işlem için gerekli yetki, beklenen sistem etkisi, doğrulama adımı ve eskalasyon sorumlusu tanımlanır. Gizli anahtarlar dokümanın içine yazılmaz.

Örnek devir testinde işletme görevlisi test ortamında süresi dolmak üzere olan sertifikayı yeniler, cihazın tekrar bağlandığını doğrular ve ilgili olayı kayıt altına alır. İkinci senaryoda yanlış konfigürasyon yayımlanır; önceki sürüme dönüş yapılır. Görevlerin yalnızca geliştirme ekibi tarafından gerçekleştirilebilmesi sürdürülebilir işletme açısından açık risk sayılır. Eğitim katılımı değil, görevin bağımsız tamamlanması kabul kanıtı olarak kullanılır.

Beklenen teknik teslimatlar

  • Müşteriye özel kurumsal veri politikası ve gereksinim matrisi
  • IoT/BIM veri akışları ve üçüncü taraf bağımlılık envanteri
  • Alternatif dağıtım mimarileri ve cihaz uygunluk analizi
  • Uzaktan erişim, güncelleme ve bakım işletim modeli
  • Ağ çıkış kontrolü ve çevrimdışı çalışma kabul testleri

Doküman formatları, veri şemaları, örneklem büyüklüğü ve sorumlu taraflar proje başlangıcında belirlenir.

Başarı ölçümü ve kabul yaklaşımı

İzinli ağ hedefleri ve veri kategorileriyle karşılaştırılmış paket yakalama, DNS/firewall kayıtları, offline çalışma testleri, varlık–sensör eşleme doğruluğu ve kontrollü uzaktan erişim testleri.

Hedef eşikler, başlangıç veri kalitesi ve varlık kritikliğine göre birlikte kararlaştırılır. Uygunluk yalnızca doküman teslimiyle değil, örnek senaryolar ve izlenebilir kanıtlarla değerlendirilir.

Varsayımlar ve kapsam sınırları

Verilerin yurt dışına çıkmaması tüm projeler için genel bir hukuki yasak olarak sunulmaz; müşteri talebine, sözleşmeye veya uygulanabilir özel mevzuata bağlı bir gereksinimdir. Seçilen ürün ve cihazların bu koşulu karşılaması teknik testlerle doğrulanmalıdır.

İşin kapsamı, saha erişimi, üçüncü taraf lisansları, kaynak sistem yetkileri ve bilgi güvenliği gereksinimleri teklif aşamasında netleştirilir.