Siber risklere bir başka bakış

Siber risklere bir başka bakış

Şu soru günümüzde gitgide önem kazanıyor: “Bir bulut sağlayıcısı durursa kaç şirket durur?” Sorunun cevabı siber risklerin de nasıl kolaylıkla yayılabileceğini bize bir kez daha gösteriyor.

Şu soru günümüzde gitgide önem kazanıyor: “Bir bulut sağlayıcısı durursa kaç şirket durur?” Sorunun cevabı siber risklerin de nasıl kolaylıkla yayılabileceğini bize bir kez daha gösteriyor.


Bir düşünün! Bir bankanın mobil uygulaması çökmüş ve açılmıyor. Aynı saatlerde bir sigorta şirketinde hasar dosyaları işlenemiyor, bir perakendecinin ödeme ekranı uzun saatler yanıt vermiyor, bir lojistik firması teslimatları güncelleyemiyor. İlk bakışta birbirinden bağımsız görünen bu aksaklıkların ortak nedeni, kullandıkları bulut altyapısındaki tek bir kesinti olabilir.

Şirketler dijital hizmetlerini büyütürken veri depolama, işlem gücü ve yazılım altyapısı için bulut sağlayıcılarından yararlanıyor. Yapay zeka uygulamaları da çoğu zaman aynı altyapıya dayanıyor. Bu model işletmelere hız ve esneklik sağlıyor; ancak çok sayıda kurumun kritik süreçlerini az sayıda teknoloji şirketine bağlaması, kesintinin etkisini doğal olarak tek bir müşterinin sınırlarının ötesine taşıyor.

Moody’s’in ortaya koyduğu 2026 dijital ekonomi değerlendirmesinde büyük bulut ve internet altyapısı sağlayıcılarında yaşanan kesintilerin yaygın aksamalara yol açtığını ve bulut ortamlarının operasyonel karmaşıklığını görünür kıldığını belirtiyor. İngiltere Merkez Bankası da finans kuruluşlarının ve yapay zeka hizmetlerinin ortak dış sağlayıcılara bağımlılığının, ağır bir operasyonel aksaklık halinde finansal istikrar açısından risk oluşturabileceğine dikkat çekiyor.


“Biz hangi bulutu kullanıyoruz?” sorusu kadar, “Hizmet aldığımız şirketler hangi altyapıyı kullanıyor?” sorusu da önem taşıyor.
“Biz hangi bulutu kullanıyoruz?” sorusu kadar, “Hizmet aldığımız şirketler hangi altyapıyı kullanıyor?” sorusu da önem taşıyor.

Kesinti sektörler arasında yayılıyor

Bir bulut kesintisi her kurumda aynı sonucu doğurmaz. Etki, hangi hizmetin durduğuna ve şirketin o hizmete ne kadar bağımlı olduğuna göre değişir. Kimlik doğrulama hizmetindeki sorun müşterilerin uygulamalara girişini engelleyebilir. Veri tabanına erişilememesi siparişleri veya hasar kayıtlarını bekletebilir. Ödeme altyapısındaki aksama ise satış tamamlanamadığı için perakendeciyi, tahsilat yapılamadığı için başka işletmeleri etkileyebilir.

Bağımlılık hali her zaman doğrudan da değil ki! Dolaylı bağımlılık yani bir şirket bulut sağlayıcısıyla sözleşme yapmamış olsa dahi kullandığı ödeme sistemi, çağrı merkezi yazılımı veya lojistik platformu o sağlayıcının altyapısında çalışıyor olması durumu da risk getirir. İngiltere Merkez Bankası, finansal sistemde bu tür dolaylı bağımlılıkların da yoğunlaşma riski yarattığını vurguluyor. Dolayısıyla “Biz hangi bulutu kullanıyoruz?” sorusu kadar, “Hizmet aldığımız şirketler hangi altyapıyı kullanıyor?” sorusu da önem taşıyor.

Yapay zeka da bu tabloya yeni bir katman ekliyor. Müşteri taleplerini sınıflandıran, belgeleri özetleyen veya çalışanlara karar desteği sunan araçlar; model sağlayıcısına, bulut işlem gücüne ve veri bağlantılarına önemli ölçüde ihtiyaç duyabiliyor. Zincirde yaşanan bir aksama, doğrudan müşteriye görünen bir hizmeti durdurmasa bile şirket içindeki iş akışını yavaşlatabiliyor.

İşletmelerin yalnızca kendi sistemleri için değil, hizmet aldıkları sağlayıcıların durması halinde de poliçenin nasıl işleyeceğini incelemesi gerekir.
İşletmelerin yalnızca kendi sistemleri için değil, hizmet aldıkları sağlayıcıların durması halinde de poliçenin nasıl işleyeceğini incelemesi gerekir.

Sigorta açısından ortak hasar ihtimali

Bu durum siber sigortada birikim riski sorusunu öne çıkarıyor: “Aynı olay, birbirinden bağımsız görünen kaç sigortalıyı aynı anda etkileyebilir?” Tek bir sağlayıcıdaki kesinti bankaların, perakendecilerin ve lojistik şirketlerinin faaliyetlerinde eş zamanlı durmaya yol açarsa çok sayıda işletme aynı dönemde hasar bildirebilir. Bununla birlikte, her bulut kesintisi otomatik olarak siber poliçe kapsamında hasar anlamına da gelmez. Teminatın kapsamı; olayın teknik nedeni, poliçedeki sistem arızası ve hizmet kesintisi hükümleri, bekleme süresi, muafiyetler ve üçüncü taraf sağlayıcıya ilişkin şartlara bağlıdır. İşletmelerin yalnızca kendi sistemleri için değil, hizmet aldıkları sağlayıcıların durması halinde de poliçenin nasıl işleyeceğini incelemesi gerekir.

Tam da bundan ötürü hazırlığın ilk adımı bağımlılıkları görünür kılmak. Kritik uygulamalar, onların bağlı olduğu dış hizmetler ve bu hizmetlerin kullandığı altyapılar birlikte haritalanmalı. Ardından şirket, “Bu hizmet dört saat ya da bir gün kullanılamazsa hangi işleri sürdürebiliriz?” sorusunu tatbikatla sınayabilir. Alternatif iş akışları, veri yedekleri, sağlayıcıyla iletişim planı ve müşteriye yapılacak bilgilendirme bu sınamanın parçaları olarak ele alınabilir.

Bir bulut sağlayıcısının durması halinde kaç şirketin etkileneceğine tek bir sayı vermek elbette ve haliyle mümkün değil. Asıl mesele, aynı altyapıya bağlı şirketlerin birbirlerinden habersiz biçimde ortak bir durma noktası paylaşabilmesi. Siber risk yönetimi de artık bu görünmeyen bağlantıları anlamayı gerektiriyor.

“Ana sağlayıcı bugün kullanılamıyor” senaryosuyla ödeme, hasar, sipariş veya sevkiyat süreçlerini tatbikatla önceden deneyimlemek fayda sağlayacaktır.
“Ana sağlayıcı bugün kullanılamıyor” senaryosuyla ödeme, hasar, sipariş veya sevkiyat süreçlerini tatbikatla önceden deneyimlemek fayda sağlayacaktır.

Bulut sağlayıcısı durursa işletme ne yapmalı

Bulut kesintisini tamamen önlemek işletmenin elinde olmasa da hangi hizmetlerin etkileneceğini önceden öngörmek ve kritik işleri nasıl sürdüreceğini planlamak, şirket için yaşanacak kesintinin etkisini azaltabilir. Siber risk yönetiminde şu adımlar öne çıkıyor:

Bağımlılıkları haritalamak: Müşteriye sunulan her kritik hizmetin hangi bulut, ödeme, yazılım ve yapay zeka sağlayıcılarına bağlı olduğunu belirlemek ilk adım olmalı. Doğrudan sözleşme yapılmayan, ancak kullanılan bir yazılımın arkasında yer alan sağlayıcıları da hesaba katmak gerekiyor.

Kesintinin sınırını tanımlamak: Her kritik iş için kabul edilebilir durma süresini ve geri yüklenmesi gereken veri miktarını belirlemek şart. Böylece kurtarma sırası, olay yaşandığında değil önceden kararlaştırılmış olacaktır.

Alternatif işleyiş hazırlamak: Uygun hizmetler için yedekleme, farklı bölgeden çalıştırma veya başka bir sağlayıcıya geçiş seçeneklerini değerlendirmek de önemli bir düzenleme olur. Teknolojik alternatifin gerçekten kullanılabilir olup olmadığını düzenli olarak sınamak fayda sağlar.

Sözleşmeleri ve iletişim planını gözden geçirmek: Sağlayıcının kesintiyi ne zaman bildireceğini, kurtarma sorumluluklarını, verilere erişim ve hizmetten çıkış koşullarını açıkça belirlemek gerekiyor. Müşterilerin ve iş ortaklarının nasıl bilgilendirileceğini de planlamak elzem bir önlem olarak görülmeli.

Kesinti tatbikatı yapmak: “Ana sağlayıcı bugün kullanılamıyor” senaryosuyla ödeme, hasar, sipariş veya sevkiyat süreçlerini tatbikatla önceden deneyimlemek, gerçek olayda uygulanacak eylem planının devreye alınmasını kolaylaştırır. Tatbikatın sonucu, plandaki eksikleri ve sigorta kapsamında değerlendirilmesi gereken olası iş durması senaryolarını gösterebilir.

Avrupa Bankacılık Otoritesi bulut hizmetleri için süreklilik ve çıkış stratejilerine dikkat çekiyor; İngiltere Merkez Bankası ise kritik hizmetlerin üçüncü taraf bağımlılıklarıyla birlikte haritalanmasını ve kesinti senaryolarının sınanmasını vurguluyor. Türkiye’de de BDDK’nin bilgi sistemlerine ilişkin düzenlemeleri, finans kuruluşları açısından sistem sürekliliğini ve dış hizmet alımının yönetimini ele alıyor. Bulut hizmeti kullanımına ilişkin düzenlemeler de bulunduğundan, sağlayıcı bağımlılığını belirlemek ve kesinti planlarını hazırlamak bu çerçevede değerlendirilebilir.

Benzer İçerikler

Geleceğin enerji yönetiminde akıllı şebekelerin rolü

Geleceğin enerji yönetiminde akıllı şebekelerin rolü