BIM, IoT ve BT Yönetiminde Kurumsal Veri Egemenliği: Octatus ve Argamos Mimarisi

Kısıtın kaynağı müşteri politikasıdır

Verinin yurt dışına çıkmaması her BIM veya IoT projesinde geçerli genel bir yasak değildir. Kurumun sözleşmesi, bilgi güvenliği politikası veya özel düzenleme böyle bir şart getirdiğinde mimari buna göre şekillenir.

Önce ülke dışı veri aktarımı, kurum dışı barındırma, internet erişimi ve uzaktan destek kısıtları birbirinden ayrılır.

İki platformun ortak veri akışı

Octatus'un BIM modeli, sensör ve saha verileri ile Argamos'un CI, olay, SLA ve kullanıcı kayıtları farklı hassasiyet sınıflarına sahip olabilir. Aralarındaki entegrasyon, kurum içi API veya olay katmanı üzerinden veri minimizasyonu ve yetki kontrolüyle tasarlanabilir.

Bütün BIM modelinin Argamos'a veya bütün CMDB'nin Octatus'a kopyalanması gerekmez. Yetkili referans, kimlik ve sınırlı bağlam aktarımı yeterli olabilir.

Gizli dış bağımlılıkların denetimi

Kimlik sağlayıcı, lisans aktivasyonu, mesajlaşma, e-posta, push, harita, analitik, log, yedekleme, güncelleme ve destek servisleri her iki ürün için ayrı değerlendirilmelidir.

Kurum içi kurulum, hiçbir ağ çıkışı olmadığı anlamına gelmez. Egress allowlist, firewall kayıtları, paket yakalama ve çevrimdışı test kanıtı gerekir.

Güvenli entegrasyon sözleşmesi

Servisten servise kimlik doğrulama, mTLS, en az yetki, tenant bazlı erişim, veri sınıflandırma, audit ve idempotent olay işleme kuralları belirlenir. Saha OT ağına doğrudan yönetim bağlantısı açılması varsayılan seçenek olmamalıdır.

Ürünlerin çevrimdışı çalışabilirliği, lisans ve üçüncü taraf bağımlılıkları sürüm bazında doğrulanmadan kesin garanti olarak pazarlanmamalıdır.

Müşteri kabul listesi

Kurumsal politika matrisi, veri akış diyagramı, saklama yeri, yedek hedefleri, üçüncü taraf envanteri, bağlantı kesintisi testi, kimlik/tenant izolasyonu ve beklenmeyen dış trafik raporu teslim edilmelidir.

Bu teknik kontroller hukuki değerlendirme yerine geçmez; uygulanabilir düzenlemeler müşteri ve uzman ekip tarafından ayrıca ele alınır.

Sahadan örnek: karar anında hangi bilgi gerekir?

Bir BT keşif ajanının hangi ağ segmentlerinde çalıştığı, hangi kimlik bilgilerine eriştiği ve hangi meta veriyi merkeze gönderdiği açıkça sınırlandırılmalıdır.

Kurumsal veri egemenliği tartışmasında bina modeli, IoT ölçümü ve BT envanteri farklı gizlilik sınıflarına sahip olabilir. Octatus fiziksel bağlamı, Argamos BT varlıklarını yönetirken hangi alanların iki sistem arasında aktarılacağı en az ayrıcalık ilkesine göre seçilmelidir.

Uygulama ve kabul kontrolü

Tenant izolasyonu, mTLS, yetki ayrımı, denetim kaydı ve müşteri politikası uyarınca veri saklama süresi pilot kabulüne dahil edilmelidir.

Pilot testte yetkisiz bir kullanıcının BIM ekranından hassas sunucu envanterine geçememesi doğrulanır. Olay kaydı paylaşılırken kişisel veri veya gizli IP bilgileri gereksiz yere çoğaltılmamalıdır. Veri maskeleme ve denetim izi birlikte test edilir.

Yatırım ve kapsam kararı nasıl verilir?

Octatus ve Argamos entegrasyonunda veri egemenliği yatırımı tüm BT envanterini BIM platformuna taşımak anlamına gelmez. Fiziksel rack ile servis ilişkisi için gerekli kimlik ve durum özeti paylaşılabilir; hassas IP adresleri veya erişim bilgileri kaynak sistemde kalmalıdır. İlk fazda API alanları, yetki reddi ve log maskeleme test edilir. Maliyet hesabına tenant izolasyonu, denetim ve tedarikçiden çıkış tatbikatı eklenmelidir.

Yerel barındırma kararı, veri sınıflandırma ve işletme sorumluluğu belirlenmeden tek başına güvenlik sağlamaz. Anahtar yönetimi, yedekleme ve servis hesabı yetkileri bütçeye girer. Ürünler arası bağlantı yalnızca onaylı alanlarla sınırlandırılır.

Veri egemenliğinin işletme açısından anlamı

Kurumsal veri egemenliği yalnızca sunucuların hangi ülkede bulunduğunu ifade etmez. Veriyi kimin topladığı, hangi amaçla işlediği, hangi kimliklerle eriştiği, hangi üçüncü taraflara aktardığı ve sözleşme sonunda nasıl teslim ettiği de değerlendirilmelidir. BIM, IoT ve BT envanterini birleştiren projelerde bu sorular daha önemlidir; çünkü tekil kayıtlar bir araya geldiğinde kritik tesis topolojisi ortaya çıkabilir.

Örneğin bir veri merkezinin oda planı, enerji dağıtım ilişkileri ve servis bağımlılıkları ayrı ayrı sınırlı bilgi verebilir. Ortak graf üzerinde birleştiğinde kritik iş hizmetlerinin fiziksel zayıflıkları anlaşılabilir. Bu nedenle veri egemenliği hem ağ mimarisi hem erişim kontrolü hem de tedarikçi sözleşmesiyle korunmalıdır. Genel bir 'yerli kurulum' beyanı yeterli kanıt değildir.

BIM, CMDB ve IoT verilerinin yetkili kaynakları

Fiziksel varlıkların mekânsal bağlamı, BT yapılandırma öğeleri ve sensör ölçümleri farklı yaşam döngülerine sahiptir. Octatus BIM/GIS ve fiziksel varlık bağlamında, Argamos BT envanteri, CMDB ve servis ilişkilerinde, Enlogy enerji ve OT verilerinde uzman katmanlar olarak konumlandırılabilir. Ancak bu mimari bir hedef tasarımdır; belirli entegrasyonların hazır olduğu ayrıca doğrulanmalıdır.

Bir ekipmanın seri numarası saha envanterinden, konumu doğrulanmış BIM kaydından, BT servis ilişkisi CMDB'den, anlık güç tüketimi OT ölçümünden gelebilir. Her alan için yetkili kaynak, güncelleme hakkı ve çatışma çözümü belirlenmelidir. Aynı alanın iki sistem arasında kontrolsüz geri yazılması veri bozulmasına yol açabilir.

Kimlik eşleme ve veri sahipliği matrisi

BIM nesnesinin IFC GlobalId değeri, kurumsal asset ID, cihaz seri numarası, CMDB CI kimliği ve telemetri point ID birbirinin yerine kullanılamaz. Bunların eşlenmesi için kaynak sistem, tesis, tenant, nesne tipi, doğrulama tarihi ve ilişki türü kaydedilmelidir. Otomatik keşif bir eşleşme önerebilir ancak kritik altyapıda yanlış eşleme önemli sonuçlar doğurabilir.

Örneğin UPS-01 cihazı değiştirildiğinde fonksiyonel pozisyon aynı kalabilir fakat fiziksel seri numarası ve bakım geçmişi değişir. Yeni cihazın enerji besleme ilişkisi yeniden doğrulanmalıdır. Eşleme tablosu eski kaydı silmek yerine geçerlilik aralığını korumalıdır. Belirsiz kayıtlar kesin ilişki gibi gösterilmemelidir.

Tenant sınırları ve servisler arası yetkilendirme

Çok tesisli veya çok müşterili platformlarda kullanıcı erişimi yalnızca arayüz menüleriyle sınırlandırılamaz. API, arama, rapor, graf sorgusu ve dosya indirme yolları aynı tenant sınırını uygulamalıdır. Servisler arası kimlik doğrulamada kapsamı sınırlı yetkiler ve denetlenebilir hesaplar kullanılmalıdır. Bir tenantın varlık kimliğini bilen kullanıcı başka tenantın ilişkilerini sorgulayamamalıdır.

Kabul testinde farklı tenantlara ait iki benzer ekipman oluşturulabilir. Bir tenant kullanıcısının diğer ekipmanın detayını, arama sonucunu, alarmını ve dışa aktarımını göremediği doğrulanmalıdır. Ön bellekte kalan veriler ve arka plan işleri de teste dahil edilmelidir. Yönetici erişimleri ayrı onay ve denetim mekanizmasına tabi tutulmalıdır.

OT ağı ile kurumsal ağ arasında güvenli sınır

BMS, SCADA, PLC ve enerji analizörleri işletme güvenliği açısından kontrollü ağ segmentlerinde bulunabilir. BIM ve BT yönetim sistemleri bu ağlara sınırsız erişim almamalıdır. Edge toplayıcıları, izinli portlar, karşılıklı kimlik doğrulama ve mümkün olduğunda salt okunur veri akışı tercih edilebilir. Kontrol komutları yetkili OT sistemi sınırında kalmalıdır.

Örneğin bir inverterin güç değerinin dijital ikizde gösterilmesi invertere setpoint yazma yetkisi verilmesini gerektirmez. Ağ akış matrisi kaynak, hedef, protokol, yön ve işlevi tanımlamalıdır. Bağlantı kesildiğinde tamponlama, yeniden deneme ve veri kalitesi davranışı test edilmelidir. Yasaklı yazma isteklerinin engellendiği doğrulanmalıdır.

Veri yerelliği, bulut bağımlılıkları ve dış servisler

Birincil uygulama sunucusu yerel veri merkezinde çalışsa da harita döşemeleri, CDN, lisans doğrulaması, hata izleme, e-posta ağ geçidi veya destek bağlantısı dış servis kullanabilir. Bu nedenle barındırma konumu ile veri çıkışının engellenmesi ayrı gereksinimlerdir. Şartname dış alan adlarını, veri türlerini ve kullanım amaçlarını içeren bağımlılık envanteri istemelidir.

Pilot sırasında DNS sorguları, güvenlik duvarı kayıtları ve tarayıcı ağ istekleri incelenebilir. İnternet kapatıldığında zorunlu BIM görüntüleme, varlık arama ve yerel alarm izleme işlevleri çalışmalıdır. Harita verisinin yerel barındırma lisansı ayrıca kontrol edilmelidir. Test edilen sürüm ve yapılandırma rapora yazılmalıdır.

Zaman damgası ve ölçüm kalitesi

IoT verisi yerel ortamda saklansa bile geç gelen veya hatalı ölçüm operasyonel kararı bozabilir. Olay zamanı, alınma zamanı, birim, kaynak ve kalite kodu ayrı saklanmalıdır. Bağlantısı kesilmiş sensörün son değeri güncelmiş gibi gösterilmemelidir. Gerçek sıfır ölçümü ile eksik veri farklı durumlardır.

Örneğin enerji analizörünün son verisi on dakika önce geldiyse dijital ikiz bunu açıkça belirtmelidir. Geç gelen paketler tarihsel sıraya göre işlenebilir; ancak yeni alarm gibi yanlış yorumlanmamalıdır. ITSM otomasyonu düşük kaliteli veriden kesin hizmet kesintisi üretmemelidir. Veri gecikmesi için kabul eşiği kullanım amacına göre belirlenmelidir.

CMDB bağımlılık grafı ve etki analizi

Argamos gibi bir BT yönetim katmanı yapılandırma öğeleri ve servis bağımlılıklarını temsil edebilir. Fiziksel model ile ilişkilendirildiğinde bir UPS veya soğutma alarmının hangi raflara ve iş hizmetlerine uzanabileceği incelenebilir. Ancak fiziksel yakınlık bağımlılık kanıtı değildir. 'Powered by', 'cooled by', 'hosts' ve 'depends on' ilişkileri ayrı anlam taşır.

Örneğin çift güç kaynağı bulunan sunucunun tek PDU kaybında hemen kapanacağı varsayılamaz. İkinci hattın kapasitesi ve durumu bilinmiyorsa sonuç risk olarak gösterilmelidir. Etki analizi ilişki yolu, kaynak kanıtı ve güncellik bilgisi sunmalıdır. Eksik bağlantılar kesin servis etkisi gibi raporlanmamalıdır.

Olay korelasyonu ve ITSM iş akışı

Bir fiziksel arıza birden fazla sensör ve BT bileşeninden alarm üretebilir. Olay korelasyonu yalnızca zaman yakınlığına değil varlık ilişkisine, ölçüm kalitesine ve kök neden kanıtına dayanmalıdır. Aynı alarm tekrar gönderildiğinde mükerrer bilet oluşmamalıdır. Olayın kaynağı, öncelik gerekçesi ve etkilenen servisler denetlenebilir olmalıdır.

Örneğin UPS arızasıyla ilişkili PDU ve sunucu alarmları tek olay altında gruplanabilir. Farklı enerji hattındaki eşzamanlı alarm otomatik olarak aynı kök nedene bağlanmamalıdır. Operatör yanlış korelasyonu ayırabilmelidir. Otomatik iş emri ve bildirim kuralları yetki, bakım penceresi ve SLA koşullarına göre sınırlandırılmalıdır.

Güncelleme, yazılım tedarik zinciri ve destek

Kapalı ağda çalışan sistemler de güvenlik güncellemesi gerektirir. İmzalı sürüm paketleri, bağımlılık envanteri, bütünlük kontrolü, test ortamı ve rollback prosedürü tanımlanmalıdır. Dış paket deposuna otomatik bağlantı zorunluysa tam çevrimdışı işletim iddiası ayrıca incelenmelidir. Kritik güvenlik açıkları için müdahale süresi sözleşmede belirtilmelidir.

Uzaktan destek oturumları log, ekran görüntüsü veya veri tabanı örneği aktarabilir. Bu nedenle destek yetkisi zaman sınırlı, onaylı ve denetlenebilir olmalıdır. Tanılama paketlerinde gereksiz kişisel ve tesis bilgileri maskelenmelidir. Alt yüklenicilerin erişim kapsamı da veri egemenliği değerlendirmesine dahil edilmelidir.

Yedekleme, felaket kurtarma ve silme politikası

Yerel veri tabanı kullanmak yedeklerin de yerel olduğu anlamına gelmez. Yedek konumu, şifreleme, anahtar yönetimi, saklama süresi ve kurtarma yetkileri açıkça tanımlanmalıdır. RPO ve RTO hedefleri iş etkisine göre belirlenmelidir. Başarılı yedekleme mesajı tek başına geri yükleme başarısını kanıtlamaz.

Pilot kabulünde BIM modelinin, kimlik eşlemelerinin, servis ilişkilerinin ve örnek olay kayıtlarının geri yüklenmesi denenmelidir. Tenant yetkileri kurtarma sonrası korunmalıdır. Veri saklama ve silme politikaları yasal yükümlülüklerle uyumlu olmalıdır. Sözleşme sonunda tedarikçi kopyalarının nasıl silineceği ve erişimlerin nasıl iptal edileceği belirlenmelidir.

Kurum içi sorumluluk ve değişiklik yönetimi

Tesis ekibi fiziksel konum ve bağlantıları, BT ekibi CI ve servis ilişkilerini, OT ekibi ölçüm ve kontrol sınırlarını, bilgi güvenliği ekibi erişim politikalarını doğrulayabilir. Bu görevler kurum yapısına göre uyarlanmalıdır. Tek bir platform yöneticisinin bütün verilerin doğruluğundan sorumlu tutulması sürdürülebilir değildir. Kaynak verideki değişikliklerin birleşik görünüme nasıl yansıyacağı tanımlanmalıdır.

Örneğin sunucu taşındığında raf, enerji ve ağ bağlantıları yeniden doğrulanmalıdır. Yeni sensör takıldığında point ID eşlemesi güncellenmelidir. Uyuşmazlıklar ilgili veri sahibinin iş kuyruğuna düşmelidir. Değişiklik geçmişi ve onay bilgisi kaybolmamalıdır.

Denetim izi ve sınır ötesi aktarım testi

Veri egemenliği iddiaları yalnızca tedarikçi beyanıyla kabul edilmemelidir. Ağ çıkış kayıtları, DNS sorguları, uygulama bağımlılıkları ve tarayıcı istekleri birlikte incelenebilir. Denetim izi kritik veri dışa aktarımlarını, yetki değişikliklerini ve servis hesaplarının işlemlerini kapsamalıdır. Logların kendisi de hassas veri içerdiğinden saklama ve erişim sınırları gerektirir.

Testte dış internet kesilir ve temel kullanım senaryoları çalıştırılır. Ardından kontrollü ağ çıkışı açılarak beklenmeyen hedeflere bağlantı olup olmadığı incelenir. Yeni sürüm veya harita bileşeni sonrası test tekrarlanmalıdır. Mutlak ve süresiz garanti yerine belirli sürüm ve yapılandırma için doğrulanmış uygunluk raporlanmalıdır.

Pilot tasarımı: kritik oda ve servis zinciri

İlk pilot için bir veri merkezi odası, bir UPS, iki PDU, birkaç raf ve sınırlı iş servisi seçilebilir. BIM konumları, fiziksel varlık kimlikleri, CMDB CI kayıtları ve telemetri noktaları doğrulanır. Ardından kontrollü enerji veya sıcaklık alarmı üretilir. Sistem fiziksel konumu, olası servis etkisini ve ilgili ITSM olayını birlikte göstermelidir.

Negatif senaryolarda yanlış eşleme, eski ölçüm, tekrar gönderilen alarm, tenant dışı sorgu ve internet kesintisi denenmelidir. Her testin beklenen sonucu ve kanıtı önceden belirlenmelidir. Kritik veri sızıntısı veya yanlış servis etkisi bulgusu açıkken koşulsuz kabul verilmemelidir. Pilot sonuçları genişleme kararına temel oluşturmalıdır.

Teknik şartname ve sözleşmesel kabul

Şartname veri envanteri, yetkili kaynak matrisi, kimlik eşleme, ağ akışları, dış bağımlılıklar, erişim kontrolleri, güncelleme, yedekleme, destek ve veri çıkış planını ayrı teslimatlar olarak istemelidir. Her teslimat için doğrulama yöntemi ve sorumlu taraf belirtilmelidir. 'Veriler yurt dışına çıkmaz' gibi genel ifadeler tek başına yeterli değildir.

Örneğin zorunlu işlevlerin internet bağlantısı olmadan çalışması açık kabul testi olabilir. Aynı şekilde başka tenantın graf sorgusunun reddedilmesi ve yedekten geri dönüş kanıtlanabilir. Sözleşme sonunda varlık kimlikleri ve ilişki grafı yeniden kullanılabilir biçimde dışa aktarılabilmelidir. Lisans sona erdiğinde kurumun kendi verisine erişimi engellenmemelidir.

Toplam sahip olma maliyeti ve aşamalı yaygınlaştırma

Kurumsal veri egemenliği tasarımının maliyeti yalnızca yerel sunucu ve yazılım lisansı değildir. Ağ segmentasyonu, saha doğrulaması, veri temizliği, güvenlik denetimi, yedekleme, güncelleme, eğitim ve destek giderleri hesaba katılmalıdır. İlk aşamada kritik servisleri kapsayan küçük ama uçtan uca doğrulanmış pilot tercih edilebilir. Geniş kapsamlı ve doğrulanmamış bir model daha yüksek işletme riski yaratabilir.

Başarı ölçütleri yanlış eşleme sayısı, yetkisiz erişim bulguları, alarmdan bilet açılmasına geçen süre, veri gecikmesi ve operatör görev süresi olabilir. Başlangıç ölçümleriyle karşılaştırma yapılmalıdır. Olası kesintilerin önlenmesi gerçekleşmiş tasarruf gibi sunulmamalıdır. Yaygınlaştırma kararı teknik kanıt ve sürdürülebilir işletme kapasitesine dayanmalıdır.

Çıkış stratejisi ve kurumun veri bağımsızlığı

Tedarikçi değişiminde BIM nesneleri, CMDB kimlikleri, ilişki türleri, kaynak kanıtları ve telemetri eşleme tabloları açık biçimde teslim edilmelidir. Veri taşınabilirliği yalnızca dosyanın dışa aktarılması değil başka ortamda yeniden kullanılabilmesiyle doğrulanmalıdır. Kapalı lisans veya tescilli görselleştirme formatı kurumun kendi verisine erişimini engellememelidir.

Kabul testinde örnek veri dışa aktarılıp bağımsız bir doğrulama ortamında incelenebilir. İlişki yönleri, kimlikler ve zaman damgaları karşılaştırılmalıdır. Tedarikçinin tuttuğu kopyaların silinmesi için sözleşmesel ve teknik kanıt yöntemi tanımlanmalıdır. Böylece veri egemenliği ilk kurulumla sınırlı kalmaz.

Örnek yönetim raporu ve karar kapıları

Yönetim raporunda kaç varlığın doğrulandığı, hangi kritik servis ilişkilerinin eksik kaldığı, dış ağ bağımlılıklarının sayısı ve açık güvenlik bulguları birlikte gösterilmelidir. Her bulgu için sorumlu ekip, hedef tarih, etkilenen kullanım senaryosu ve kabul durumuna yer verilmelidir. Böylece yatırımın ilerlemesi yalnızca model sayısı veya kurulan sunucu adediyle değerlendirilmez. Veri kalitesi ve işletme riski görünür hale gelir.

İkinci faza geçiş kararı için pilotun zorunlu güvenlik testlerini geçmiş olması, kimlik eşlemelerinin belirlenen doğruluk seviyesine ulaşması ve operasyon ekibinin gerçek olay senaryosunu tamamlayabilmesi aranabilir. Hedef eşikler keşif sonrasında kuruma özgü belirlenmelidir. Açık kritik bulgular erteleniyorsa gerekçe, risk sahibi ve telafi kontrolü belgelenmelidir.

Kurum içi mimaride günlük kayıtları da veri egemenliği kapsamına girer. API hata loglarına erişim tokenı, cihaz adresi veya kişisel bilgi yazılması beklenmedik sızıntı kanalı oluşturabilir. Octatus ve Argamos arasındaki çağrılar için yapılandırılmış log şeması, maskeleme kuralları ve saklama süresi ayrı test edilmelidir. Denetim kanıtı korunurken gereksiz hassas alanların çoğaltılmaması hedeflenir.