Kurumsal Veri Egemenliği / 12 dk
Octatus Merkezli BIM, Enerji ve BT Entegrasyonunda Kurumsal Veri Egemenliği
Üç ürün için müşteriye özel veri çıkışı kısıtları, yerel kurulum ve doğrulanabilir kabul kontrolleri.
Yasak değil müşteri gereksinimi
Verinin ülke dışına çıkmaması her proje için genel bir yasak değildir. Müşterinin bilgi güvenliği politikası, sözleşmesi veya özel düzenlemesi böyle bir gereksinim doğurabilir.
Türkiye içi barındırma, kurum içi kurulum ve tamamen bağlantısız çalışma farklı seviyelerdir.
Octatus merkezli veri akışı
Octatus BIM/GIS ve varlık bağlamını yönetir. Argamos CI ve servis ilişkilerini; Enlogy enerji/OT verilerini kendi yetki alanlarında tutar. Tam veri tabanı kopyası yerine sınırlı referans ve olay paylaşımı tercih edilebilir.
Kimlik federasyonu, tenant izolasyonu, audit ve veri sınıflandırması ortak tasarım gerektirir.
Gizli dış bağımlılıklar
Harita, CDN, lisans, destek, telemetri, yedekleme, bildirim, AI, kimlik ve güncelleme servisleri üç ürün için ayrı envanterlenir.
Yalnızca Türkiye'de sunucu çalıştırmak sıfır sınır ötesi veri akışını kanıtlamaz.
Test ve kabul
Egress deny/allowlist, DNS/firewall logları, paket yakalama, çevrimdışı lisans, bağlantı kaybı, yedekleme ve kurtarma testleri müşteri şartına göre hazırlanır.
Hukuki uygunluk ayrıca değerlendirilir; ürünlerin tüm sürümlerinin air-gapped çalıştığı kanıtsız biçimde vaat edilmez.
Sahadan örnek: karar anında hangi bilgi gerekir?
Enerji telemetrisi, BT envanteri ve BIM dosyaları farklı gizlilik sınıflarına sahip olabilir. Entegrasyon yalnızca ihtiyaç duyulan alanları aktarmalı; gereksiz ham veri kopyasından kaçınmalıdır.
Octatus, Argamos ve Enlogy arasında enerji olayı paylaşılırken bütün ham telemetri veya BT envanterinin kopyalanması zorunlu değildir. Olay kimliği, varlık referansı ve izinli özet alanlar çoğu sorgu için yeterli olabilir. Kaynak sistem otoritesi ve saklama süresi korunur.
Uygulama ve kabul kontrolü
Sözleşmede barındırma bölgesi, uzaktan erişim, üçüncü taraf harita/analitik çağrıları, log, yedekleme ve silme yükümlülükleri ayrı değerlendirilmelidir.
Pilot veri akışında enerji olayından fiziksel trafoya, oradan yetkili BT servisine geçiş izlenir. Ağ sınırları, servis hesabı izinleri ve denetim kayıtları kontrol edilir. Bir sistemin erişilememesi diğer sistemin hassas veriyi önbellekten sınırsız göstermesine yol açmamalıdır.
Yatırım ve kapsam kararı nasıl verilir?
Birleşik Octatus–Argamos–Enlogy mimarisinde veri egemenliği kararı, her ürünün kendi veri otoritesini koruduğu federasyon ile merkezi kopyalama arasında verilir. Enerji olayının fiziksel varlıkla ilişkilendirilmesi için tüm ham telemetriyi veya BT servis envanterini çoğaltmak gerekmeyebilir. Pilot izinli alanları, dış ağ trafiğini ve erişim denetimini sınamalıdır. Saklama, yedekleme ve tedarikçi çıkış maliyetleri alternatiflere göre karşılaştırılır.
Veri egemenliği yatırımı için hangi verinin neden taşındığı belgelenir. Kopyalama yerine federasyon seçimi performans ve erişilebilirlik maliyeti yaratabilir; bu ödünleşim ölçülür. Ürünlerin yerleşik entegrasyon kabiliyeti gerçek sürümlerle doğrulanmadan taahhüt edilmez.
Üç platformun birleşmesi neden yeni bir güvenlik sınırı oluşturur?
Bir BIM modeli tesisin mekânsal düzenini, enerji platformu güç akışını, BT yönetimi ise dijital hizmet bağımlılıklarını açıklayabilir. Bu üç veri kümesi birleştiğinde tek başlarına görünmeyen kritik ilişkiler ortaya çıkar. Örneğin bir veri merkezinin hangi UPS hattına bağlı olduğu ile hangi müşteri uygulamalarını barındırdığı aynı sorguda bulunabilir. Bu nedenle birleşik platform sıradan bir raporlama uygulaması gibi ele alınmamalıdır.
Kurumsal veri egemenliği verinin nerede saklandığı kadar hangi amaçla birleştirildiğini ve kimlerin ilişkileri görebildiğini de kapsar. Bir kullanıcıya tekil cihaz bilgisi vermek, tüm servis zincirini görme yetkisi vermek anlamına gelmemelidir. Erişim kararları hem varlık hem ilişki düzeyinde uygulanmalıdır. Bu sınır sözleşmede ve testlerde kanıtlanmalıdır.
Octatus, Argamos ve Enlogy için yetkili veri kaynakları
Octatus fiziksel varlık modeli, BIM/GIS konumu ve mekânsal ilişkiler için; Argamos BT envanteri, CMDB ve servis bağımlılıkları için; Enlogy enerji ve OT ölçümleri için uzman katmanlar olarak tasarlanabilir. Bu bir hedef mimari konumlandırmasıdır; mevcut kurulumda hazır olan API ve konektörler ayrıca doğrulanmalıdır. Ortak arayüzün varlığı verinin tek veri tabanında toplanmasını zorunlu kılmaz.
Örneğin UPS cihazının fiziksel konumu Octatus'ta, anlık gerilimi Enlogy'de, etkileyebileceği uygulama hizmetleri Argamos'ta tutulabilir. Birleşik sorgu kaynakları referanslarla ilişkilendirebilir. Alan sahipliği matrisi hangi sistemin hangi bilgiyi değiştirebileceğini açıkça belirlemelidir. Aksi halde çift yönlü senkronizasyon çakışmaları sessiz veri bozulmasına yol açabilir.
Merkezî görünüm ile merkezî kontrol arasındaki fark
Octatus merkezli bir kullanıcı deneyimi, bütün operasyonel kontrolün Octatus üzerinden yapılması gerektiği anlamına gelmez. Enerji setpoint'i, kesici işletmesi veya saha otomasyonu gibi işlemler yetkili OT sisteminin güvenlik prosedürlerine bağlı kalmalıdır. BT hizmet değişiklikleri de ilgili ITSM onay süreçlerini izlemelidir. Görüntüleme ve komut yetkilerinin ayrılması hem güvenlik hem sorumluluk açısından önemlidir.
Örneğin operatör bir inverterin düşük üretimini BIM görünümünde fark edebilir. Ancak güç setpoint'ini değiştirme talebi varsa bu işlem Enlogy veya yetkili saha kontrol katmanının tanımlanmış akışından geçmelidir. Kullanıcı rolü, onay, kayıt ve güvenli başarısızlık davranışı ayrıca test edilmelidir. Salt okunur entegrasyon birçok izleme senaryosunda yeterlidir.
Varlık kimlikleri ve ortak referans modeli
IFC GlobalId, kurumsal asset ID, SCADA tag, cihaz seri numarası ve CMDB CI kimliği aynı şey değildir. Bu alanların benzer adlar taşıması otomatik olarak aynı varlığı temsil ettiklerini kanıtlamaz. Eşleme tablosunda kaynak sistem, tenant, tesis, ilişki türü, doğrulayan kişi ve geçerlilik aralığı bulunmalıdır. Belirsiz eşlemeler kesin sonuç üreten sorgulara sessizce dahil edilmemelidir.
Örneğin eski bir UPS yenisiyle değiştirildiğinde fiziksel konum aynı kalabilir ancak seri numarası ve bakım geçmişi değişir. Fonksiyonel pozisyon ile fiziksel cihaz ayrılmalıdır. Eski olay kayıtlarının geçmişteki cihaza bağlı kalması gerekir. Bu yaklaşım hem denetim hem kök neden analizi için önemlidir.
Tenant sınırı yalnızca kullanıcı ekranı değildir
Çok müşterili bir mimaride tenant izolasyonu API, graf sorgusu, dosya indirme, raporlama, arama ve arka plan görevleri boyunca uygulanmalıdır. Kullanıcı bir başka tenantın asset ID değerini tahmin etse bile ilgili kaydı veya ilişkileri görememelidir. Ön bellek anahtarları ve olay mesajları da tenant bağlamını korumalıdır. Yönetici erişimleri ayrı onay ve denetim gerektirir.
Örneğin iki müşterinin farklı tesislerinde aynı etiketli PDU bulunabilir. Kimlik çözümlemesi tenant ve tesis bağlamı olmadan yapılırsa yanlış veriler birleştirilebilir. Negatif testte bir tenantın kimliğiyle diğerine ait graf yolu ve alarm sorgulanmalıdır. Yetkisiz sonuçların yalnızca gizlenmesi değil sunucu tarafında reddedilmesi beklenmelidir.
Veri sınıflandırması ve ilişki grafının hassasiyeti
BIM çizimleri, enerji şemaları ve BT servis topolojileri farklı gizlilik seviyelerine sahip olabilir. Bu kayıtlar birleştirildiğinde elde edilen graf daha yüksek hassasiyet taşıyabilir. Özellikle kritik enerji beslemeleri ile iş uygulamaları arasındaki bağlantılar yetkisiz kişilere açılmamalıdır. Veri sınıflandırması yalnızca tekil belgeye değil türetilmiş sorgu sonuçlarına da uygulanmalıdır.
Örneğin bir bakım taşeronuna yalnızca sorumlu olduğu pano ve ilgili iş emri gösterilebilir. Tüm veri merkezinin uygulama bağımlılıkları gerekli olmayabilir. Dışa aktarım ve ekran görüntüsü süreçleri de sınıflandırma politikasına tabi tutulmalıdır. En az yetki ilkesi operasyonu engellemeden uygulanacak şekilde tasarlanmalıdır.
OT segmentasyonu ve edge toplama stratejisi
Enerji analizörleri, PLC, SCADA ve BMS sistemleri ayrı ağ segmentlerinde bulunabilir. Kurumsal BIM veya BT yönetim platformlarının bu ağlara doğrudan ve geniş erişim alması gerekmeyebilir. Edge toplayıcıları izinli telemetriyi güvenli biçimde aktarabilir. Kaynak, hedef, protokol, yön ve fonksiyon bazında ağ akış matrisi hazırlanmalıdır.
Örneğin Modbus TCP üzerinden ölçüm okuma izni verilirken yazma fonksiyonları engellenebilir. Saha bağlantısı kesildiğinde edge tamponunun ne kadar veri saklayacağı ve yeniden iletimin nasıl yapılacağı belirtilmelidir. Tekrarlanan mesajlar mükerrer ITSM olayı oluşturmamalıdır. Bu davranışlar yalnızca dokümanda değil sahaya yakın test ortamında doğrulanmalıdır.
Dış bağımlılıklar ve beklenmeyen veri çıkışları
Bir uygulama kurum içi sunucuda çalışsa bile harita döşemeleri, CDN, font servisleri, lisans doğrulaması, hata izleme veya uzaktan destek dış bağlantılar kullanabilir. Bu nedenle yerel barındırma ve veri egemenliği eş anlamlı değildir. Dış hedeflerin alan adı, IP aralığı, veri türü ve işlevi envantere alınmalıdır. Gereksiz bağımlılıklar kaldırılmalı veya onaylı alternatiflerle değiştirilmelidir.
Örneğin üç boyutlu model görüntüleme sırasında tarayıcının harici bir harita servisine istek göndermesi tesis kullanım bilgisini açığa çıkarabilir. Pilot testte tarayıcı ağ kayıtları, DNS ve güvenlik duvarı logları birlikte incelenebilir. İnternet kesildiğinde temel kullanım senaryolarının devam etmesi doğrulanmalıdır. Harita verisinin yerel kullanım lisansı ayrıca değerlendirilmelidir.
API sözleşmesi ve veri minimizasyonu
Sistemler arası API sözleşmeleri alan adlarını, tipleri, yetki kapsamlarını, hata kodlarını, zaman damgalarını ve sürümleme politikasını tanımlamalıdır. Bütün BIM dosyasını veya bütün CMDB envanterini her sorguda aktarmak gereksiz veri yayılımı yaratabilir. Kullanım amacına uygun dar veri kümeleri tercih edilmelidir. Entegrasyonun başarı kriteri yalnızca HTTP yanıtı almak değildir.
Örneğin enerji alarmını zenginleştirmek için ilgili asset ID, konum referansı ve doğrulanmış servis yolu yeterli olabilir. Kullanıcının erişemediği varlıkların bilgisi API yanıtında bulunmamalıdır. Eksik eşleme için açık hata durumu dönülmelidir. Kaynak verinin güncellik bilgisi yanıtla birlikte taşınmalıdır.
Ölçüm zamanı, veri kalitesi ve geçmişe dönük sorgular
Enerji telemetrisi saniyelik aralıklarla güncellenebilirken BIM ve CMDB ilişkileri daha seyrek değişir. Bu iki zaman ölçeği aynı sorguda dikkate alınmalıdır. Ölçümün olay zamanı, alınma zamanı, birimi ve kalite kodu korunmalıdır. Geç gelen veya bozuk ölçüm güncel veri gibi gösterilmemelidir. Gerçek sıfır ile veri yokluğu farklıdır.
Örneğin bir UPS alarmı dün gerçekleşmişse etki analizi bugünkü raf yerleşimini değil olay anında geçerli bağlantıları kullanmalıdır. İlişki geçerlilik aralıkları bu nedenle önemlidir. Tarihsel sorgunun hangi veri sürümünü kullandığı kaydedilmelidir. Eksik geçmiş ilişki varsa kesin hizmet kesintisi sonucu üretilmemelidir.
Birleşik etki analizinde belirsizlik yönetimi
Enerji arızasının BT servislerine etkisi UPS, PDU, raf, sunucu, sanallaştırma ve uygulama bağımlılıkları üzerinden değerlendirilebilir. Ancak aynı sunucunun ikinci güç kaynağı veya uygulamanın başka bölgede yedeği bulunabilir. Bu nedenle tek enerji alarmından otomatik kesinti sonucu çıkarmak doğru değildir. Olası risk ve doğrulanmış kesinti ayrı sunulmalıdır.
Örneğin PDU-A kaybı çift beslemeli bir sunucuda yalnızca risk artışı yaratabilir. İkinci hattın kapasitesi bilinmiyorsa belirsizlik görünür olmalıdır. Graf sorgusu her bağlantının kaynağını ve doğrulama tarihini göstermelidir. Operatör yanlış ilişkiyi düzeltebilmelidir.
Kimlik doğrulama, servis hesapları ve sır yönetimi
Servisler arası iletişimde uzun ömürlü paylaşılan parolalar yerine kapsamı sınırlı kimlik bilgileri tercih edilmelidir. Sertifika veya token yaşam döngüsü, rotasyon, iptal ve acil erişim süreçleri tanımlanmalıdır. Teknik hesaplar yalnızca ihtiyaç duydukları API ve veri kümelerine erişmelidir. Sırların kaynak koduna veya denetim loglarına yazılması önlenmelidir.
Örneğin Argamos'un bir enerji olayını zenginleştirmek için Enlogy'den okuma yapması kontrol komutu yetkisi gerektirmez. Bu ayrım token kapsamına yansıtılmalıdır. Yetki iptali sonrası eski oturumların davranışı test edilmelidir. Servis kimlikleri de tenant sınırlarını aşmamalıdır.
Denetim izi, log bütünlüğü ve veri saklama
Kritik graf sorguları, veri dışa aktarımları, erişim yetkisi değişiklikleri ve otomatik korelasyon kararları denetlenebilir olmalıdır. Loglar olay zamanı, aktör, işlem, kaynak ve sonuç bilgisi içermelidir. Ancak logların kendisi hassas tesis ve kullanıcı bilgisi barındırabilir. Bu nedenle saklama, erişim ve maskeleme kuralları gereklidir.
Örneğin bir olay sırasında hangi enerji ölçümünün hangi servis etkisine bağlandığı sonradan açıklanabilmelidir. İlişki grafının kullanılan sürümü kaydedilmelidir. Operatörün manuel düzeltmesi önceki kararı silmemelidir. Denetim kayıtlarının değiştirilmesine karşı bütünlük kontrolleri uygulanmalıdır.
Yedekleme, kurtarma ve veri taşınabilirliği
Yerel kurulum yedeklerin otomatik olarak kurum içinde tutulduğu anlamına gelmez. Yedek konumu, şifreleme anahtarları, saklama süresi ve kurtarma yetkileri ayrıca belirlenmelidir. RPO ve RTO hedefleri kritik servislerin ihtiyaçlarına göre tanımlanmalıdır. Başarılı yedekleme bildirimi gerçek geri yükleme testinin yerini tutmaz.
Pilot sırasında BIM varlıkları, CMDB eşlemeleri, ilişki grafı ve örnek olay kayıtları geri yüklenebilir. Kurtarma sonrası tenant sınırları korunmalıdır. Tedarikçi değişiminde veri açık ve yeniden kullanılabilir formatlarda dışa aktarılmalıdır. Sözleşme bitiminde erişim iptali ve tedarikçi kopyalarının silinmesi doğrulanmalıdır.
Uzaktan destek ve yazılım tedarik zinciri
Kapalı ağda çalışan uygulamalar da güncelleme, güvenlik açığı yönetimi ve destek gerektirir. İmzalı sürüm paketleri, bağımlılık envanteri, test ortamı ve geri dönüş prosedürü tanımlanmalıdır. Uzaktan destek oturumları onaylı, zaman sınırlı ve kaydedilebilir olmalıdır. Tanılama paketleri gereksiz tesis topolojisi veya kişisel veri içermemelidir.
Örneğin yeni bir harita bileşeni eklendiğinde dış ağ bağımlılık testi yeniden çalıştırılmalıdır. Yeni API sürümü tenant filtrelerini değiştirebilir. Bu nedenle regresyon testleri yalnızca görsel işlevleri değil veri erişim sınırlarını da kapsamalıdır. Alt yüklenici erişimleri de aynı kurallara tabi olmalıdır.
Pilot: tek tesis, üç veri alanı ve gerçek senaryo
İlk pilot için bir tesis, bir UPS, birkaç PDU, sınırlı BT servis grubu ve ilgili BIM varlıkları seçilebilir. Fiziksel bağlantılar saha ekibiyle, CMDB servis ilişkileri BT ekibiyle doğrulanır. Enerji ölçümü kontrollü alarm senaryosuyla test edilir. Birleşik ekran varlık konumunu, ölçümün güncelliğini ve olası servis etkisini göstermelidir.
İkinci aşamada yanlış kimlik eşlemesi, gecikmiş ölçüm, mükerrer alarm, internet kesintisi ve tenant dışı sorgu denenmelidir. Her senaryo için beklenen sonuç, kanıt ve sorumlu kişi önceden yazılmalıdır. Kritik güvenlik veya yanlış etki bulgusu açıkken koşulsuz kabul verilmemelidir. Pilot raporu ikinci fazın kapsamını belirlemelidir.
Sözleşmesel kabul ve kanıt paketi
Teknik şartname yetkili veri kaynağı matrisini, API sözleşmelerini, dış bağlantı envanterini, ağ akışlarını, tenant testlerini, yedekleme ve çıkış planını ayrı teslimatlar olarak istemelidir. Genel 'veri kurumda kalır' beyanı yeterli değildir. Kabul kriterleri test edilebilir olmalıdır. Her sonuç belirli sürüm ve yapılandırma için raporlanmalıdır.
Örneğin internet bağlantısı kapatıldığında yerel model ve alarm izleme işlevlerinin çalışması doğrulanabilir. Başka tenantın graf sorgusunun reddedilmesi ayrıca kanıtlanabilir. Veri dışa aktarımı bağımsız bir ortamda yeniden okunabilmelidir. Sözleşme sonrasında kurumun kendi verisine erişimi lisans koşullarıyla fiilen engellenmemelidir.
İşletme sahipliği ve sürekli veri kalitesi
Tesis ekibi fiziksel varlıkları, OT ekibi ölçüm ve kontrol sınırlarını, BT ekibi servis bağımlılıklarını, bilgi güvenliği erişim politikalarını doğrulayabilir. Entegrasyon ekibi kimlik eşleme ve veri sözleşmelerini yönetebilir. Bu roller kurum yapısına göre uyarlanmalıdır. Her yeni cihaz veya servis değişikliği ilgili eşlemelerin gözden geçirilmesini tetiklemelidir.
Örneğin sunucu başka rafa taşındığında PDU bağlantısı ve CMDB ilişkileri birlikte güncellenmelidir. Uyuşmazlıklar sessizce son yazan değerle çözülmemelidir. Veri sahibi inceleme kuyruğuna yönlendirilmelidir. Haftalık kalite raporu belirsiz eşlemeleri, eski ölçümleri ve eksik servis yollarını gösterebilir.
Yatırım kararında ölçülebilir fayda
Birleşik platformun maliyeti yalnızca lisans ve sunucu değildir. Saha doğrulaması, CMDB temizliği, güvenlik testleri, entegrasyon bakımı, eğitim ve destek giderleri hesaba katılmalıdır. İlk fazda kritik kullanım senaryosunun uçtan uca doğrulanması geniş ve eksik bir veri modelinden daha değerli olabilir. Yaygınlaştırma kararının temeli gerçek pilot kanıtlarıdır.
Başarı göstergeleri yanlış eşleme oranı, veri gecikmesi, yetkisiz erişim bulguları, alarmdan doğru varlığa ulaşma süresi ve servis etkisi doğruluğu olabilir. Başlangıç durumu ölçülmelidir. Önlenmiş olabilecek kesintiler gerçekleşmiş tasarruf gibi raporlanmamalıdır. Veri egemenliği gereksinimi bir defalık kurulum değil sürekli denetlenen işletme niteliği olarak ele alınmalıdır.
Karar kapısı: mimariyi üretime almadan önce
Canlıya geçiş kararında yetkili kaynak matrisi, ağ akış listesi, kimlik eşleme doğruluğu, servis hesaplarının yetkileri ve dış bağımlılık testleri birlikte gözden geçirilmelidir. Bir alanın belirsiz olması bütün platformun başarısız olduğu anlamına gelmeyebilir; ancak kritik veri sızıntısı veya kontrol yetkisi ihlali koşulsuz kabul edilmemelidir. Risk sahibi ve telafi kontrolü belgelenmelidir.
Operatörler gerçek olay senaryosunda hangi bilginin doğrulanmış, hangisinin tahmin olduğunu ayırt edebilmelidir. Pilot çıktısı ikinci faz için yalnızca özellik listesi değil veri kalitesi ve güvenlik iyileştirme planı da üretmelidir. Böylece Octatus merkezli entegrasyon sürdürülebilir kurumsal yönetişime bağlanı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.