Veri merkeziniz gerçekten güvenli mi? Bu istatistikleri kontrol edin.

Bir veri merkezi ihlali, sunuculardan çok daha fazlasını bozabilir. Müşteri erişimini, dahili sistemleri, yedeklemeleri, personel iş akışlarını ve uzun yıllar boyunca oluşan güveni etkileyebilir. Ekiplerin ağırlıklı olarak güvenlik duvarlarına ve uç nokta araçlarına odaklandığını ve temel soruları yanıtsız bıraktığını gördüm: - Tesise kimler girebilir? - Üretim sistemlerine hangi hesaplar erişebilir? - Yedeklemeler aynı ağı kullanmadan geri yüklenebilir mi? - Ekip, güvenliği ihlal edilmiş bir sunucuyu ne kadar hızlı bir şekilde izole edebilir? - Bir olay sırasında müşterilerle kim konuşuyor? Güçlü bir güvenlik planının bir saldırı başlamadan önce bu sorulara yanıt vermesi gerekir. ## Bir İhlal Nasıl Görünebilir Bir ihlal her zaman dramatik bir sistem arızasıyla başlamaz. Saldırgan çalınan bir parolayı, açığa çıkan bir uzak hizmeti, bir satıcı hesabını veya kimlik avı e-postasını kullanabilir. İlk belirtiler küçük olabilir: - Olağandışı oturum açma etkinliği - Yeni yönetici hesapları - Güvenlik duvarı kurallarında değişiklikler - Büyük miktarda giden veri aktarımları - Devre dışı bırakılan güvenlik araçları - Olağandışı saatlerde yavaşlayan sistemler - Yedekleme işlerinde beklenmeyen değişiklikler Her işareti izole edilmiş bir teknik sorun olarak ele alan bir ekip, değerli yanıt süresini kaybedebilir. Ben tüm modeli gözden geçirmeyi tercih ediyorum: sisteme kimin eriştiği, nelerin değiştiği, hangi cihazların dahil olduğu ve etkinliğin normal çalışmayla eşleşip eşleşmediği. ## Adım 1: Önemli Sistemleri Haritalayın Günlük işlemleri destekleyen sistemleri listeleyerek başlıyorum. Bu liste şunları içerebilir: - Müşteri veritabanları - Sanal makineler - Depolama platformları - Kimlik hizmetleri - İzleme araçları - Yedekleme sunucuları - Ağ ekipmanı - Fiziksel erişim sistemleri - Satıcı bağlantıları Her sistemin bir sahibi, bir iş amacı ve bir kurtarma önceliği olmalıdır. Herkese açık bir web sitesi kısa bir süre içinde geri yüklenebilir. Bir fatura veritabanı veya sağlık kayıt sistemi farklı bir kurtarma planına ihtiyaç duyabilir. Bu harita olmadan ekipler genellikle temel hizmetleri destekleyen sistemleri geri yüklemek yerine en kolay sistemleri ilk önce geri yükler. ## Adım 2: Bir Olaydan Önce Erişimi Sınırlandırın Erişim kontrolü, veri merkezi güvenliğinin en kullanışlı parçalarından biri olmaya devam ediyor. Şunları incelemenizi öneririm: - Yönetici hesapları - Paylaşılan kimlik bilgileri - Uzaktan erişim araçları - Satıcı izinleri - Hizmet hesapları - Fiziksel erişim kartları - Eski çalışan hesapları - Kullanılmayan ağ yolları Her kişi yalnızca rolü için gereken erişimi almalıdır. Geçici satıcı erişiminin bir bitiş tarihi olmalıdır. Ayrıcalıklı hesaplar, sistemin desteklediği durumlarda çok faktörlü kimlik doğrulamayı kullanmalıdır. Paylaşılan yönetici parolası zayıf bir denetim izi oluşturur. Aynı hesabı birden fazla kişi kullandığında değişikliğin kaynağını tespit etmek zorlaşır. Bireysel hesaplar daha net kayıtlar sağlar ve erişimin kaldırılmasını kolaylaştırır. ## Adım 3: Ayrı Kritik Ağlar Ağ bölümlendirmesi, bir saldırının yayılmasını azaltabilir. Ortak bir tasarım şunları ayırır: - Halka açık hizmetler - Dahili iş sistemleri - Yönetim arayüzleri - Yedekleme ortamları - Geliştirme sistemleri - Fiziksel güvenlik sistemleri Bir web sunucusunun güvenliği ihlal edilirse, saldırganın her veritabanına ve yönetim aracına doğrudan erişim elde etmemesi gerekir. Ağ bölgeleri arasındaki erişim açık kurallara uymalıdır. Güvenlik ekipleri bu kuralları düzenli aralıklarla incelemelidir çünkü eski istisnalar, orijinal proje sona erdikten sonra da uzun süre etkin kalabilir. Segmentasyon riski ortadan kaldırmaz. Güvenliği ihlal edilmiş bir hesap veya cihazdan etkilenen sistem sayısını azaltabilir. ## Adım 4: Yedeklemeleri Koruyun ve Test Edin Geri yüklenemeyen bir yedekleme, güvenilir bir kurtarma kaynağı değildir. Yedeklemelerin aşağıdaki özelliklere sahip olup olmadığını kontrol ediyorum: - Üretim sistemlerinden ayrı olarak depolanıyor - Rutin yönetici erişiminden korunuyor - Aktarım ve depolama sırasında şifreleniyor - Saklama politikaları kapsamında mı - Başarısız işler için izleniyor - Planlanmış geri yükleme alıştırmaları aracılığıyla test ediliyor Mümkün olduğunda en az bir yedek kopya ana ağdan izole edilmelidir. Geniş yönetici erişimi elde eden saldırganlar, bağlı yedekleri silmeye veya şifrelemeye çalışabilir. Bir bulut barındırma şirketi olan Code Spaces, bir saldırganın kontrol paneline erişim sağlamasının ardından 2014 yılında büyük bir saldırıya uğradı. Saldırgan müşteri verilerini ve yedeklerini silmiş ve şirket daha sonra kapanmıştır. Bu vaka, yedek ayırma ve erişim kontrolünün neden çevre savunmalarıyla aynı ilgiyi hak ettiğini gösteriyor. ## Adım 5: Bir Olay Müdahale Planı Hazırlayın Bir ihlal sırasında, insanlar genel ifadelerle dolu uzun bir belge yerine net görevlere ihtiyaç duyarlar. Yararlı bir plan şunları açıklamalıdır: 1. Uyarıyı kim onaylar 2. Etkilenen sistemleri kim izole edebilir 3. Günlükleri ve diğer kanıtları kim korur 4. Satıcılar ve teknik ortaklarla kim iletişim kurar 5. Müşteri iletişimini kim yönetir 6. Raporlama görevlerini kim değerlendirir 7. Hizmetin geri yüklenmesini kim onaylar 8. Her önemli kararı kim kaydeder Plan, iletişim ayrıntılarını, yedek iletişim yöntemlerini ve e-posta veya dahili mesajlaşma mevcut olmadığında çalışmaya yönelik prosedürleri içermelidir. Ayrıca fidye yazılımı, kimlik bilgilerinin çalınması, yetkisiz fiziksel giriş ve şüpheli veri kaybı gibi yaygın olaylar için kısa yanıt kılavuzları oluşturmanızı da öneririm. Personel baskı altındayken bu kılavuzları büyük bir politika dosyasında arama yapmadan kullanabilir. ## Adım 6: Fiziksel ve Dijital Aktiviteyi Birlikte İzleyin Bir veri merkezinin hem siber hem de fiziksel riskleri vardır. Güvenlik incelemeleri şunları kapsamalıdır: - Kapı erişim kayıtları - Ziyaretçi kayıtları - Kamera kapsamı - Raf kilitleri - Çevresel uyarılar - Uzaktan konsol erişimi - Güvenlik duvarı olayları - Kimlik günlükleri - Uç nokta etkinliği Bir çalışan hesabından yapılan garip bir oturum açma işlemi, alışılmadık bir kimlik kartı girişiyle birlikte görünene kadar daha az ciddi görünebilir. Bu kayıtları ilişkilendirmek ekiplerin ne olduğunu anlamasına yardımcı olabilir. Günlükler, saldırganın kolaylıkla değiştiremeyeceği bir konumda saklanmalıdır. Ekip ayrıca sistem saatlerinin aynı hizada kaldığını da doğrulamalıdır. Doğru zaman damgaları araştırmayı kolaylaştırır. ## Adım 7: Satıcıları ve Uzaktan Desteği İnceleyin Birçok tesis bulut sağlayıcılarına, bakım firmalarına, ağ ortaklarına ve donanım tedarikçilerine güvenir. Her bağlantı başka bir erişim yolu ekler. Satıcılardan şunları sağlamalarını istiyorum: - Adlandırılmış kullanıcı hesapları - Çok faktörlü kimlik doğrulama seçenekleri - Erişim pencereleri - Bağlantı kayıtları - İhlal bildirim prosedürleri - Veri işleme ayrıntıları - Hizmet tamamlandıktan sonra hesap kaldırma adımları Bir satıcının her görevi gerçekleştirmek için sınırsız erişime ihtiyacı yoktur. Sınırlı izinler ve izlenen oturumlar, desteği pratik tutarken maruz kalmayı azaltabilir. ## Adım 8: Planı Küçük Bir Alıştırmayla Test Edin Masa üstü bir alıştırma, üretim sistemlerini kesintiye uğratmadan boşlukları ortaya çıkarabilir. Senaryolardan biri, güvenliği ihlal edilmiş bir yönetici hesabını ve alışılmadık dosya şifrelemesini içerebilir. Ekip şunları gerçekleştirebilir: - Uyarı incelemesi - Hesabın askıya alınması - Ağ izolasyonu - Yedekleme doğrulama - Kanıtların korunması - Dahili güncellemeler - Müşteri mesajları - Hizmet kurtarma Amaç mükemmel bir performans yaratmak değildir. Amaç, belirsiz sorumlulukları, eksik kişileri ve olaydan halihazırda etkilenmiş olan sistemlere bağlı adımları bulmaktır. Uygulamadan sonra, tepkiyi neyin yavaşlattığını kaydediyorum ve her iyileştirme için sahiplerini atadım. ## Müşterilerin Duyması Gerekenler Bir ihlalden etkilenen kişiler genellikle doğrudan yanıtlar ister: - Ne oldu? - Hangi hizmetler etkilendi? - Hangi bilgiler söz konusu olabilir? - Hangi önlemleri almalılar? - Hizmeti yeniden sağlamak için neler yapılıyor? - Doğrulanmış güncellemeleri nereden alabilirler? Teknik dil iletişimi zorlaştırabilir. Açık bir mesaj, soruşturmanın doğrulamadığı iddialarda bulunmadan, bilinen gerçekleri, halen incelenmekte olan alanları ve bir sonraki güncelleme kanalını açıklayabilir. Güven, bir ihlalin asla gerçekleşmeyeceğine dair söz vermekten gelmez. Kuruluşun kontrollerini hazırladığını, araştırdığını, ilettiğini ve iyileştirdiğini göstermekten gelir. ## Pratik Bir Gözden Geçirme Programı Güvenlik işi, bir program takip edildiğinde yönetilmesi daha kolay hale gelir. Her ay - Ayrıcalıklı hesapları inceleyin - Başarısız yedekleme işlerini kontrol edin - Olağandışı erişim olaylarını inceleyin - Satıcı hesaplarını ve izinlerini onaylayın Her üç ayda bir - Seçilen geri yüklemeleri test edin - Güvenlik duvarı ve ağ kurallarını inceleyin - Bir yanıt alıştırması yapın - Kişi listelerini güncelleyin - Fiziksel erişim kayıtlarını kontrol edin Her yıl - Kritik sistemleri yeniden değerlendirin - Olay müdahale planını gözden geçirin - Daha geniş bir kurtarma testi gerçekleştirin - Tedarikçiler ve altyapıdaki değişiklikleri değerlendirin - Personeli kimlik avı ve erişim prosedürleri konusunda eğitin Bir veri merkezinde güçlü ekipman ve vasıflı personel bulunabilir, ancak yine de zorluklar yaşanabilir ihlal sırasında erişim çok genişse, yedekler bağlıysa veya yanıt planı test edilmemişse. Dayanıklılığı bir çalışma süreci olarak ele alıyorum. Sistemleri haritalandırın, gereksiz erişimi azaltın, kritik ağları ayırın, yedeklemeleri koruyun, etkinliği izleyin ve müdahaleyi uygulayın. Bu adımlar ihlallerin olmadığı bir ortam vaat etmiyor. Normal operasyonlar baskı altındayken ekibe daha net bir yol sağlarlar.

Bir veri merkezinde kameralar, korumalar, güvenlik duvarları ve erişim kartları bulunabilir ancak yine de ciddi risklerle karşı karşıya olabilir. Güvenlik ekipleri genellikle sayıları incelemeden önce araçlara odaklanır. Ben tam tersi yaklaşımı tercih ediyorum. Veriler arızaların nerede başladığını, ne kadar sürdüğünü ve hangi kontrollerin dikkate alınması gerektiğini gösterir. Tek bir olayın maliyeti, çalınan verilerin çok ötesine geçebilir. IBM'in Veri İhlalinin Maliyeti Raporu 2024, bir ihlalin küresel ortalama maliyetinin 4,88 milyon dolar olduğunu ortaya koydu. Aynı rapor, olayı bulmak ve kontrol altına almak için harcanan süre de dahil olmak üzere ortalama ihlal yaşam döngüsünü 258 gün olarak ölçtü. Bu zaman çizelgesi önemli. Haftalarca veri merkezi ortamında kalan bir tehdit, sunucuları, kimlik bilgilerini, yedekleme sistemlerini ve müşteri güvenini etkileyebilir. ## Rakamlar bana ne söylüyor ### 1. İnsanlar saldırı yolunun parçası olmaya devam ediyor 2024 Verizon Veri İhlali Araştırma Raporu, ihlallerin %68'inde insan unsurunun rol oynadığını ortaya çıkardı. Bu kategori; hataları, sosyal mühendisliği, çalınan kimlik bilgilerini ve erişimin kötüye kullanımını içerir. Bir veri merkezi çalışanı risk yaratma niyetinde olmayabilir. Aceleci bir teknisyen, ayrıntıları kontrol etmeden bir erişim talebini onaylayabilir. Yönetici, parolayı sistemler arasında yeniden kullanabilir. Yüklenici, proje sona erdikten sonra da erişime devam edebilir. Bu eylemler küçük görünebilir. Etkileri raflara, yönetim konsollarına ve bulut bağlantılarına yayılabilir. Kimlik kontrollerini bir ofis BT görevi olarak değil, temel bir veri merkezi güvenlik önlemi olarak ele alıyorum. Yararlı kontroller şunları içerir: - Ayrıcalıklı hesaplar için çok faktörlü kimlik doğrulama - Günlük iş ve yönetim için ayrı hesaplar - Yükleniciler için kısa süreli erişim - Hassas değişiklikler için onay kayıtları - Etkin olmayan kullanıcıların düzenli incelemeleri - Olağandışı oturum açma konumları veya oturum açma zamanları için uyarılar - Paylaşılan acil durum hesapları için açık kurallar Bir rozet her odaya erişim sağlamamalıdır. Oturum açma, her sistem üzerinde kontrol sağlamamalıdır. ### 2. Üçüncü taraf erişimi daha geniş bir giriş noktası oluşturur Veri merkezleri birçok dış gruba bağlıdır. Bunlar ekipman satıcılarını, temizlik şirketlerini, güvenlik sağlayıcılarını, ağ taşıyıcılarını, bakım yüklenicilerini ve bulut ortaklarını içerebilir. Verizon'un 2024 raporu, ihlallere üçüncü tarafların katılımının bir önceki yıla göre iki kat artarak %15'e ulaştığını belirtti. Bu rakam her satıcının güvensiz olduğu anlamına gelmiyor. Satıcı erişiminin neden kendi kontrollerine ihtiyaç duyduğunu gösterir. Dışarıdan erişimi onaylamadan önce dört pratik soru soruyorum: 1. Satıcının hangi sisteme veya odaya ihtiyacı var? 2. Erişim ne kadar süreyle aktif kalmalıdır? 3. Satıcının faaliyetlerini kim inceliyor? 4. İş bittiğinde ne olacak? Bakım sonrasında açık kalan bir satıcı hesabı sessiz bir risk oluşturur. Erişimin süresi tasarım gereği sona ermeli, birinin onu kaldırmayı hatırlamasına bağlı olmamalıdır. ### 3. Fiziksel olaylar dijital operasyonları etkileyebilir Siber güvenlik en çok dikkat çeken konu olsa da bir veri merkezi hâlâ güce, soğutmaya, yangından korunmaya, bina yapısına ve insan hareketine bağımlıdır. Strazburg'daki OVHcloud tesisinde 2021'de yaşanan yangın, fiziksel bir olayın barındırılan hizmetleri ve müşteri devamlılığını nasıl etkileyebileceğini gösterdi. Olay tipik bir siber saldırı değildi ancak birçok kuruluşun yedekleme konumlarına, kurtarma planlarına ve bulut bağımlılığına bakış açısını değiştirdi. Fiziksel güvenlik planlaması şunları kapsamalıdır: - Giriş kapıları ve ziyaretçi kayıtları - İnsan tuzakları veya kontrollü erişim noktaları - CCTV kapsama alanı ve muhafaza - Raf düzeyinde erişim - Yangın algılama ve bastırma - Su sızıntısı tespiti - Jeneratör ve yakıt koruması - Soğutma sistemi izleme - Acil durum çıkışları ve tahliye prosedürleri - Yedek ekipman için ayrı depolama Kamera bir olayı kaydedebilir ancak her olayı durduramaz. Erişim kontrolü, eğitimli personel, alarmlar ve müdahale prosedürlerinin birlikte çalışması gerekir. ### 4. Tespit hızı hasarı etkiler IBM 2024 raporu, bir ihlali tanımlamak ve kontrol altına almak için ortalama 258 gün ölçtü. Bu rakam her şirket için bir tahmin değil, ortalama bir rakamdır. Bu durum hâlâ ortak bir zayıflığı ortaya çıkarıyor: Pek çok kuruluş, saldırganın bağlantılı sistemler arasında geçiş yapması için zaman bulduktan sonra sorunları keşfediyor. Algılamayı birkaç katmanda ele alıyorum: - Kimlik kartı erişimi - Kapı ve kafes etkinliği - Güvenlik duvarı olayları - Yönetici oturum açma bilgileri - Sunucu değişiklikleri - Ağ trafiği - Yedekleme etkinliği - Uç nokta uyarıları - Çevresel sensörler Bu günlüklerin açık sahipliğe ihtiyacı var. Bir müdahale planı olmadan veri toplamak, etkili bir koruma değil, büyük bir arşiv oluşturur. Yararlı bir uyarı üç soruyu yanıtlamalıdır: - Ne oldu? - Neden önemli olabilir? - Kimin harekete geçmesi gerekiyor? Örneğin, alışılmadık bir ülkeden sunucu yönetim sistemine giriş yapılması ve ardından yedekleme ayarlarında değişiklik yapılması, rutin başarısız oturum açma işlemine göre daha hızlı bir incelemeyi hak eder. ### 5. Yedekleme sistemleri ana ortamdan korunmaya ihtiyaç duyar Yedeklemeler bir kesinti sonrasında işlemleri geri yükleyebildiğinden, saldırganlar genellikle yedeklemeleri hedefler. Bir saldırgan hem üretim verilerini hem de yedekleri silebilir veya şifreleyebilirse kurtarma zorlaşır. Pratik bir yedekleme planı şunları içerebilir: - Çevrimdışı veya yalıtılmış kopyalar - Ayrı yönetici kimlik bilgileri - Çok faktörlü kimlik doğrulama - Uygun olduğunda yazmaya karşı korumalı depolama - Düzenli geri yükleme testleri - Kurtarma süresi hedefleri - Kurtarma noktası hedefleri - Yedekleme ayarlarını kimin değiştirdiğini gösteren kayıtlar Ekip verileri geri yükleyene kadar bir yedeği güvenilir olarak değerlendirmiyorum. Başarılı bir yedekleme işi yalnızca bir işin çalıştığını kanıtlar. Verilerin baskı altında kurtarılabileceğini kanıtlamaz. ### 6. Eğitim işle eşleşmelidir Genel güvenlik eğitimi genellikle veri merkezi risklerini gidermede başarısız olur. Mühendisler, güvenlik görevlileri, tesis ekipleri ve satıcılar farklı durumlarla karşı karşıyadır. Bir güvenlik görevlisinin arka kapı ve sahte hizmet taleplerini tanımlaması gerekebilir. Bir teknisyenin, bir cihazı bağlamadan önce değişiklik biletini doğrulaması gerekebilir. Bir sistem yöneticisinin kimlik bilgilerine yönelik şüpheli bir isteği tanımlaması gerekebilir. Kısa alıştırmalar bu durumları test edebilir: - Birisi, bir çalışanı güvenli bir kapıdan takip etmek ister - Bir yüklenici, eşleşen bir iş emri olmadan gelir - Bir arayan, acil durum şifre sıfırlama talebinde bulunur - Bir teknisyen ilgisiz bir rafa erişim ister - Bir çalışan garip bir giriş uyarısı bildirir Amaç, bir endişesini bildiren kişiyi cezalandırmak değildir. Amaç, güvenli eylemi güvenli olmayan eylemden daha kolay hale getirmektir. ## Veri merkezi güvenliğini ölçmenin basit bir yolu Güvenlik ölçümleri bir ekibin karar vermesine yardımcı olmalıdır. Genellikle onları beş alana gruplandırıyorum. ### Erişim Takibi: - Etkin ayrıcalıklı hesapların sayısı - Hareketsiz hesaplar - Başarısız erişim girişimleri - Yüklenici erişim süresi - İncelenmeyen rozet etkinlikleri - Eşleşen randevusu olmayan ziyaretçiler ### Algılama Takibi: - Bir olayı algılamak için ortalama süre - Bir olayı içermek için ortalama süre - Sahibi olmayan uyarılar - Kritik sistemlerde eksik günlükler - Hedef süreden sonra incelenen yüksek riskli olaylar ### Dayanıklılık Takibi: - Yedekleme geri yükleme başarısı - Kurtarma testi sıklığı - Güç ve soğutma olayları - Tekli arıza noktaları - Hizmetleri başka bir siteye taşımak için gereken süre ### Kişi Takibi: - Eğitimin tamamlanması - Kimlik avı testi raporlaması - Çözülmemiş politika istisnaları - Hassas rollerdeki personel değişimi - Satıcı güvenlik inceleme durumu ### Fiziksel koruma Takip: - Refakatsiz ziyaretçiler - Kapı alarmları - Kamera kapsama alanı boşlukları - Yangın ve su sensörü testleri - Fiziksel erişimi iptal etmek için gereken süre Çok sayıda sayı içeren bir kontrol paneli faydalı görünebilir. Aksiyona bağlı daha küçük bir seti tercih ederim. Bir ölçüm bir kararı değiştirmiyorsa değeri sınırlıdır. ## Pratik bir inceleme neye benziyor Bir veri merkezi güvenlik programını incelediğimde normal bir iş gününün yolunu takip ediyorum. Siteye bir kişi geliyor. Kimliğin nasıl doğrulandığını, kişinin nereye gidebileceğini, ziyaretin nasıl kayıt altına alındığını kontrol ediyorum. Kişi sisteme erişim talebinde bulunur. Kimin onayladığını, ne kadar sürdüğünü, hesabın gereğinden fazla izne sahip olup olmadığını kontrol ediyorum. Kişi bir cihazı veya hizmeti değiştirir. İş emrini, onay izini, izlemeyi ve geri alma planını kontrol ediyorum. Bir uyarı belirir. Kimin aldığını, ekibin olayı nasıl doğruladığını ve olayın nasıl belgelendiğini kontrol ediyorum. Hizmet başarısız oluyor. Ekibin tek bir çalışana, tek binaya veya tek yedekleme sistemine güvenmeden operasyonları yeniden başlatıp başlatamayacağını kontrol ediyorum. Bu yaklaşım fiziksel güvenliği, siber kontrolleri, tesis yönetimini ve iş sürekliliğini birbirine bağlar. Bir alandaki boşluk diğerlerini zayıflatabilir. ## Zayıf sonuçların ardındaki yaygın hatalar Bazı kuruluşlar, güvenlik sonuçlarını test etmek yerine güvenlik araçlarını dikkate alır. Kameraların, güvenlik duvarlarının veya eğitim oturumlarının sayısını bildirebilirler ancak bu kontrollerin gerçek bir olay sırasında çalıştığına dair kanıtları yoktur. Diğer ekipler geniş erişimi onaylıyor çünkü zaman kazandırıyor. Bu seçim uzun vadeli maruz kalma yaratabilir. Üçüncü bir sorun ise güvenlik ve tesis ekiplerinin ayrı sistemlerde çalışmasıyla ortaya çıkıyor. Bir rozet olayı siber ekibe ulaşamayabilir. Bir sunucu uyarısı fiziksel güvenlik ekibine ulaşmayabilir. Paylaşılan bir yanıt süreci bu boşluğu kapatabilir. Ayrıca ekiplerin geri yüklemeyi test etmeden yedekleme işlerini test ettiğini de görüyorum. Bu sahte güven yaratır. Kurtarma, net roller, zaman sınırları ve sonucun kayıtları ile uygulanmalıdır. Numaralar günlük işlere bağlandığında veri merkezi güvenliğinin iyileştirilmesi daha kolay hale gelir. İhlal maliyetleri mali baskıyı gösterir. 258 günlük yaşam döngüsü rakamı, algılama hızının neden önemli olduğunu göstermektedir. %68'lik insan unsuru rakamı, erişim tasarımının ve personel davranışının neden ilgiyi hak ettiğini göstermektedir. Fiziksel olaylar, dayanıklılığın neden güvenlik duvarında duramayacağını gösteriyor. Bu istatistikleri süs olarak değil soru olarak kullanıyorum: - Olağandışı erişimi ne kadar hızlı tespit edebiliriz? - Hangi hesaplar gerekenden daha fazla izne sahip? - Satıcı erişimini gecikmeden kaldırabilir miyiz? - Kritik sistemleri korumalı yedeklerden geri yükleyebilir miyiz? - Fiziksel ve siber ekipler tek bir süreçle yanıt verebilir mi? Cevaplar, uzun bir güvenlik ürünleri listesinden daha fazlasını ortaya koyuyor. Veri merkezinin erişimi koruyup koruyamayacağını, değişikliği tespit edip edemeyeceğini, operasyonları sürdürüp sürdüremeyeceği ve kontroller başarısız olduğunda durumu kurtarıp kurtaramayacağını gösterirler. Kaynaklar: IBM Veri İhlalinin Maliyeti Raporu 2024; Verizon 2024 Veri İhlal Araştırmaları Raporu; 2021 OVHcloud Strasbourg veri merkezi yangınına ilişkin kamuya açık raporlar.

Bir veri merkezi dışarıdan güvenli görünse de yine de gizli riskler taşıyabilir. Kilitli kapılar, kameralar, güvenlik duvarları ve yedek jeneratörler önemlidir ancak bunlar hikayenin tamamını anlatmaz. Veri merkezi güvenliğini değerlendirirken zincirin tamamına bakarım: kim girebilir, sistemler nasıl izlenir, elektrik kesintisi sırasında ne olur, yedekler nasıl depolanır ve bir şeyler ters gittiğinde ekibin nasıl tepki vereceği. Tek bir zayıf nokta hizmet kullanılabilirliğini, veri erişimini ve müşteri güvenini etkileyebilir. Fiziksel erişim kilitli bir kapıdan daha fazlasını gerektirir Binanın kendisiyle başlıyorum. Güvenli bir veri merkezi, erişimi birkaç katman üzerinden kontrol etmelidir. Bir ziyaretçi bir resepsiyon alanından, erişim kontrollü bir kapıdan, bir güvenlik kontrol noktasından ve ayrı bir sunucu odası girişinden geçebilir. Her adımda bir kayıt oluşturulmalıdır. Ayrıca tesisin aşağıdakileri nasıl ele aldığını da kontrol ediyorum: - Ziyaretçi kimliği - Çalışan erişim izinleri - Kimlik kartı paylaşımı - Güvenlik kamerası kapsama alanı - Yükleme istasyonuna erişim - Ekipman kaldırma - Erişim kayıtları - Rol değişikliğinden sonra personel erişimi Hâlâ aktif bir rozeti olan eski bir çalışan, açık bir risk oluşturur. Aynı durum, mevcut bir iş ihtiyacı olmadan sunucu alanlarına girebilen yüklenici için de geçerlidir. Erişim en az erişim ilkesini izlemelidir. Ağ ekipmanını yöneten bir teknisyenin her depolama alanına girmek için izne ihtiyacı olmayabilir. Bir temizlik yüklenicisinin ortak alanlara erişmesi gerekebilir ancak raflara veya yedekleme ortamına erişmesi gerekmeyebilir. Güvenlik ekipleri erişim haklarını düzenli aralıklarla incelemeli ve kullanılmayan izinleri kaldırmalıdır. Siber güvenlik içeriyi ve dışarıyı kapsamalıdır Güvenlik duvarları trafiği filtrelemeye yardımcı olur, ancak bunlar veri merkezi güvenliğinin yalnızca bir parçasıdır. Kamu hizmetleri, iç sistemler, yönetim araçları ve yedekleme ortamları arasında ağ ayrımı görmek istiyorum. Bir saldırgan bir sunucuya ulaşırsa, doğru bölümleme tüm tesis genelinde hareket etmeyi zorlaştırabilir. Yararlı kontroller şunları içerir: - Çok faktörlü kimlik doğrulama - Güçlü şifre yönetimi - Şifreli bağlantılar - Uç nokta koruması - Ağ izleme - Düzenli yama uygulama - Ayrıcalıklı erişim kontrolleri - Test edilmiş olay müdahale planları Yönetim arayüzleri özel ilgiyi hak eder. Sunucuları, depolamayı veya ağ cihazlarını kontrol eden bir sistem, açık bir neden olmadan ve güçlü güvenlik önlemleri alınmadan halka açık internete maruz bırakılmamalıdır. Ayrıca kayıtlara kimlerin erişebileceğini ve bu kayıtların değiştirilmeye karşı korunup korunmadığını da soruyorum. Güvenlik kayıtları bir ekibin ne olduğunu anlamasına yardımcı olabilir, ancak bu yalnızca kayıtların eksiksiz ve güvenilir olması durumunda mümkündür. Güç koruması test edilmeli, varsayılmamalıdır Bir veri merkezinde yedek jeneratörler ve kesintisiz güç kaynakları bulunabilir. Bu, sistemin kesinti sırasında çalışacağını kanıtlamaz. Rutin testlerin kanıtlarını arıyorum. Ekip şunları bilmelidir: - Piller kritik ekipmanı ne kadar süre destekleyebilir - Jeneratörler ne kadar hızlı başlayabilir - Ne kadar yakıt mevcut - Hangi sistemlere öncelik verilir - Bakım, güç yedekliliğini nasıl etkiler - Bir güç yolu arızalanırsa ne olur Bir güç sistemi, hasarlı bir kablo, hatalı bir transfer anahtarı, bir bakım hatası veya birden fazla cihazı etkileyen bir sorun nedeniyle arızalanabilir. 2021 Facebook kesintisi, bir ağ değişikliğinin büyük çevrimiçi hizmetlere erişimi nasıl etkileyebileceğini gösterdi. Etkinlik sadece donanımla ilgili değildi. Ayrıca ayrı yönetim erişiminin değerini ve normal araçlar kullanılamadığında işe yarayan bir müdahale planının değerini de gösterdi. Soğutma ve yangından korunma kullanılabilirliği etkiler Sunucular çalıştıkları her dakika ısı üretir. Soğutma sorunları sıcaklıkları artırabilir, otomatik kapanmaları tetikleyebilir veya ekipmanın ömrünü kısaltabilir. Sorumlu bir inceleme, sıcaklık izlemeyi, nem kontrolünü, hava akışı tasarımını, bakım programlarını ve uyarı yönetimini kapsar. Kimin uyarı aldığını ve o kişinin ne kadar hızlı harekete geçebileceğini bilmek istiyorum. Yangından korunmanın da net bir plana ihtiyacı vardır. Su bazlı sistemler, gaz bazlı sistemler, tespit araçları ve tahliye prosedürlerinin her birinin ekipman ve insanlar üzerinde farklı etkileri vardır. Doğru yaklaşım binaya, yerel gereksinimlere, ekipman yerleşimine ve güvenlik planına bağlıdır. Mart 2021'de Strazburg'daki bir OVHcloud tesisinde çıkan yangın, bir binaya zarar verdi ve bazı müşterilerin hizmetlerini etkiledi. Olay, felaket planlamasının neden tek bir yedek kopyadan fazlasına ihtiyaç duyduğunu gösterdi. Müşterilerin ayrıca yedeklerinin nerede saklandığını ve hizmetlerin nasıl geri yüklenebileceğini de anlaması gerekir. Yedeklemeler yalnızca kurtarma çalıştığında faydalıdır Hiçbir zaman geri yüklenmemiş bir yedekleme, bir kurtarma planı değil, bir varsayımdır. Dört noktayı kontrol etmenizi öneririm: 1. Verilerin ne sıklıkta yedeklendiği 2. Yedek kopyaların ne kadar süre saklandığı 3. Yedeklerin üretim sistemlerinden izole edilip edilmediği 4. Tam geri yüklemenin ne kadar süreceği Fidye yazılımı bağlı yedekleme sistemlerini etkileyebilir. Bu nedenle birçok kuruluş çevrimdışı, izole edilmiş veya erişimi kısıtlı kopyaları saklar. Şifreleme depolanan verileri korur ancak kurtarma anahtarlarının da dikkatli bir şekilde korunması gerekir. Kurtarma testinde kazara silme, donanım arızası, fidye yazılımı veya tüm tesisin kaybı gibi net bir senaryo kullanılmalıdır. Ekip neyin işe yaradığını, neyin başarısız olduğunu ve her aşamanın ne kadar sürdüğünü kaydetmelidir. Kurtarma hedeflerinin işletmeyle eşleşmesi gerekir. Küçük bir dahili uygulama birkaç saatlik kesintiyi tolere edebilir. Bir ödeme platformunun veya hastane sisteminin farklı bir plana ve ek güvenlik önlemlerine ihtiyacı olabilir. İnsanlar güvenlik sisteminin bir parçası olmaya devam ediyor Teknoloji, insan riskini ortadan kaldırmaz. Personel bir kimlik avı bağlantısına tıklayabilir, beklenmeyen bir erişim isteğini onaylayabilir, hassas dosyaları onaylanmamış bir cihaza kopyalayabilir veya stresli bir olay sırasında kimlik bilgilerini paylaşabilir. Açık prosedürler ve düzenli eğitim bu hataları azaltabilir. Basit raporlama yolları arıyorum. Çalışanlar aşağıdakileri nasıl bildireceklerini bilmelidir: - Şüpheli e-postalar - Kayıp erişim kartları - Bilinmeyen ziyaretçiler - Olağandışı sistem davranışı - Kaza sonucu verilerin açığa çıkması - Eksik ekipman Suçlama odaklı bir kültür, raporlamayı geciktirebilir. Pratik bir kültür, ekibin henüz yanıt vermek için zaman varken sorunları öğrenmesine yardımcı olur. Satıcı erişiminin de gözden geçirilmesi gerekiyor. Bakım sağlayıcıları, bulut ortakları, donanım tedarikçileri ve güvenlik yüklenicileri kritik sistemlerle etkileşime girebilir. Sözleşmeler erişim sınırlarını, günlüğe kaydetmeyi, veri işlemeyi, bildirim görevlerini ve hizmet sorumluluklarını sade bir dille tanımlamalıdır. İzleme eyleme yol açmalıdır Güvenlik uyarıları veri merkezini tek başına korumaz. Birisinin bunları gözden geçirmesi, sınıflandırması ve yanıt vermesi gerekiyor. Bir izleme planı fiziksel erişimi, ağ trafiğini, sunucu sağlığını, güç sistemlerini, soğutmayı, depolama kapasitesini, yedekleme durumunu ve olağandışı kullanıcı davranışını kapsamalıdır. Ekibin yararlı uyarıları tekrarlanan gürültüden ayırabilmesi için uyarı eşikleri gözden geçirilmelidir. Ayrıca veri merkezinin bir olay müdahale süreci olup olmadığını da soruyorum. Bir çalışma planı şunları tanımlamalıdır: - Kararları kim verir - Müşterilerle kim iletişim kurar - Etkilenen sistemleri kim izole eder - Kanıtları kim korur - Kurtarmayı kim yönetir - Zaman çizelgesini kim kaydeder Bir kesinti sırasında, belirsiz sahiplik her eylemi yavaşlatabilir. Kısa bir iletişim listesi ve uygulanmış bir prosedür, ekibin baskı altında çalışmasına yardımcı olabilir. Kullandığım pratik bir inceleme Veri merkezi güvenliğini değerlendirmem gerektiğinde şu soruları sorarım: - Kuruluş, her bir kritik alana kimin girebileceğini açıklayabilir mi? - Erişim kayıtları inceleniyor mu? - Arızalı bir güç yolu hizmeti durdurabilir mi? - Yedek kopyalar üretim sistemlerinden ayrı mı? - Ekip bir geri yükleme testini tamamladı mı? - Güvenlik güncellemeleri tanımlanmış bir programa göre yönetiliyor mu? - Personel şüpheli faaliyetleri gecikmeden bildirebilir mi? - Satıcılara yalnızca ihtiyaç duydukları erişim veriliyor mu? - Olay planı iletişimi içeriyor mu? - Plan bir tatbikatla test edildi mi? “Evet” cevabı her riski ortadan kaldırmaz. Kuruluşun ana başarısızlık noktalarını dikkate aldığını ve bunları yönetmenin bir yoluna sahip olduğunu gösterir. Veri merkezi güvenliği tek bir ürün veya sertifika değildir. Fiziksel kontroller, siber güvenlik, bakım, personel eğitimi, yedekleme tasarımı ve kurtarma testlerini birleştiren bir çalışma sürecidir. Bir tesisi incelerken yazılı politika ile günlük uygulamalar arasındaki boşluğa çok dikkat ederim. Bir belge, yedeklemelerin her ay test edildiğini söyleyebilir. Daha güçlü soru, ekibin test kaydını gösterip gösteremeyeceği, sonucu açıklayıp açıklayamayacağı ve koşullar zor olduğunda gerekli hizmeti sağlayıp sağlayamayacağıdır.

Bir veri merkezi içeride ciddi zayıflıklar varken dışarıdan güvenli görünebilir. Bir elektrik kesintisi, soğutma arızası, yazılım hatası, siber saldırı veya kaçırılan bakım görevi, müşterilerin her gün güvendiği hizmetleri kesintiye uğratabilir. Veri merkezi riskine yalnızca bir BT sorunu olarak değil, bir iş sorunu olarak bakıyorum. Sistemler çevrimdışı olduğunda, hasar satış kayıplarını, gecikmiş operasyonları, kaçırılan müşteri taleplerini, veri kurtarma maliyetlerini ve güven kaybını içerebilir. ## Elektrik Kesintisi Temel Hizmetleri Durdurabilir Güvenilir güç, her veri merkezinin temelidir. Kısa bir kesinti sunucuları, depolama cihazlarını, ağ ekipmanlarını ve soğutma sistemlerini etkileyebilir. Çoğu tesis birkaç koruma katmanı kullanır: - Birden fazla kaynaktan gelen şebeke gücü - Kesintisiz güç kaynağı sistemleri - Yedek jeneratörler - Otomatik transfer anahtarları - Yakıt depolama ve dağıtım planları - Düzenli güç testi Yedek ekipmana sahip olmak riski ortadan kaldırmaz. Piller kapasite kaybedebilir. Bir jeneratör çalışmayabilir. Aktarım anahtarı beklendiği gibi çalışmayabilir. Bakım çalışmaları da beklenmeyen bir kesintiye neden olabilir. Yalnızca her cihazı değil, tüm güç zincirini test etmenizi öneririm. Bir test, elektriğin ana kaynaktan yedek kaynağa geçip, hizmet kesintisi olmadan gerekli ekipmana ulaşıp ulaşamayacağını göstermelidir. ## Soğutma Sorunları Ekipmana Zarar Verebilir Sunucular çalıştıkları her saat başı ısı üretirler. Soğutma kararsız hale geldiğinde ekipman yavaşlayabilir, kapanabilir veya kalıcı hasar görebilir. Yaygın nedenler şunlardır: - Klima arızası - Tıkanmış hava akışı - Kötü raf düzeni - Su sızıntıları - Yüksek dış sıcaklıklar - Yanlış sıcaklık sensörleri - Gecikmiş bakım Bir veri merkezi normal kullanım sırasında yeterli soğutma kapasitesine sahip olabilir ancak sistemin bir kısmı çevrimdışı olduğunda sorun yaşayabilir. Ekipman arızası, planlı bakım ve daha yüksek sunucu yükleri sırasında soğutma performansını kontrol eden bir planı tercih ediyorum. İzleme, sıcaklığı, nemi, hava akışını ve su tespitini izlemelidir. Uyarıların açık bir şekilde sahiplenilmesi gerekir. Kimseye ulaşmayan bir uyarı bir işletmeyi koruyamaz. ## Siber Saldırılar Fiziksel Altyapıya Ulaşabilir Siber risk, müşteri uygulamalarıyla sınırlı değildir. Saldırganlar izleme platformlarını, erişim kontrol sistemlerini, bina yönetim araçlarını, uzaktan bakım hizmetlerini veya ağ cihazlarını hedef alabilir. Yüklenici tarafından kullanılan zayıf bir hesap, hassas bir sisteme giden yol oluşturabilir. Güncelliğini yitirmiş bir cihaz aynı zamanda bilinen bir zayıflığı da ortaya çıkarabilir. Pratik bir güvenlik planı şunları içerir: - Çok faktörlü kimlik doğrulama - Yönetim sistemleri için ayrı ağlar - İş görevlerine dayalı erişim - Kısa ömürlü yüklenici hesapları - Düzenli yazılım güncellemeleri - Test edilmiş çevrimdışı yedeklemeler - Merkezi güvenlik günlükleri - Açık olay müdahale adımları Uzaktan erişim, yakından ilgilenilmeyi hak eder. Üç basit soru soruyorum: Kimler bağlantı kurabilir? Neyi değiştirebilirler? Erişim ne kadar hızlı kaldırılabilir? Cevaplar kaydedilmeli ve gözden geçirilmelidir. Paylaşılan hesaplar bu işi daha da zorlaştırır çünkü işletme, bir eylemi kimin gerçekleştirdiğini kolayca doğrulayamaz. ## İnsan Hatası Büyük Bir Kesintiyi Tetikleyebilir Birçok olay normal bir görevle başlar. Teknisyen bir ağ ayarını değiştirir, bir cihazı değiştirir, bir güvenlik duvarı kuralını günceller veya bir kabloyu taşır. Ortamın uygun kontrollerden yoksun olduğu durumlarda küçük bir hata birçok sistemi etkileyebilir. Yararlı bir değişiklik süreci şunları içermelidir: 1. Değişikliğin yazılı bir açıklaması 2. Risk kontrolü 3. Yedekleme veya geri alma planı 4. Doğru kişiden onay 5. Gerektiğinde bir bakım penceresi 6. Değişiklik sonrası inceleme 2021 Facebook kesintisi, bir yapılandırma değişikliğinin büyük çevrimiçi hizmetlere erişimi nasıl etkileyebileceğini gösterdi. Olay aynı zamanda dahili araçların kullanımını da zorlaştırdı ve bu da kurtarma sürecini yavaşlattı. Bu tür olaylar bana yedek iletişim kanallarının önemli olduğunu hatırlatıyor. Ana sistem arızalanırsa personelin yine de koordinasyon sağlayacak bir yola ihtiyacı vardır. Açık prosedürler yardımcı olur ancak eğitim de önemlidir. Personel, bir plan önlerindeki durumla eşleşmediğinde ne yapacağını bilmelidir. ## Yedekleme Sistemleri İş Operasyonlarını Geri Yükleyemeyebilir Bir yedekleme, yalnızca işletmenin ondan geri yükleme yapabildiği durumlarda faydalıdır. Pek çok şirket kesinti sırasında boşluklar keşfeder: - Yedeklemeler eksikti - Kurtarma anahtarları kullanılamıyor - Veriler aynı konumda depolanıyordu - Geri yükleme süreleri beklenenden uzundu - Uygulamalar eksik hizmetlere bağlıydı - Personel kurtarma eylemlerini kimin onayladığını bilmiyordu Düzenli kurtarma testleri aracılığıyla yedekleme kalitesini ölçüyorum. Test, önemli sistemleri geri yüklemeli, veri doğruluğunu kontrol etmeli, kullanıcı erişimini onaylamalı ve gereken süreyi kaydetmelidir. Basit bir kurtarma planı, sistemleri iş gereksinimlerine göre gruplandırabilir: - Birkaç dakika içinde geri dönmesi gereken hizmetler - Birkaç saat bekleyebilecek hizmetler - Daha sonra geri yüklenebilecek veriler - Yayınlanmadan önce manuel kontroller gerektiren sistemler Bu yaklaşım, ekiplerin sınırlı kurtarma kaynaklarını kontrollü bir şekilde kullanmasına yardımcı olur. ## Yangın, Su ve Bina Hasarı Olasılığı Devam Ediyor Dijital güvenlik güçlü olsa bile fiziksel tehlikeler bir veri merkezini etkileyebilir. Strazburg'daki bir OVHcloud tesisinde 2021'de yaşanan yangın, bir bina olayının barındırılan hizmetleri ve müşteri verilerini nasıl etkileyebileceğini gösterdi. Yangından korunma, duman algılamayı, yangını söndürmeyi, yangına dayanıklı odaları ve acil durum prosedürlerini içerebilir. Su koruması, sızıntı sensörlerini, yükseltilmiş zeminleri, drenaj planlarını ve ekipmanın borulardan uzağa yerleştirilmesini içerebilir. Ayrıca çevreyi de kontrol ediyorum. Bir veri merkezi su baskını, fırtına, deprem, yakındaki inşaatlar, ulaşım sorunları veya sahaya sınırlı erişim gibi risklerle karşı karşıya kalabilir. İkinci bir konum, tek bir bina olayının etkisini azaltabilir. Tasarımın mesafeyi, ağ bağlantısını, veri çoğaltmayı, personel erişimini ve paylaşılan bağımlılıkları dikkate alması gerekir. ## Tedarik Zinciri Sorunları Kurtarmayı Geciktirebilir Veri merkezleri donanıma, yazılıma, yakıta, yedek parçalara, ağ taşıyıcılarına ve uzman desteğine bağlıdır. Eksik bir güç modülü veya gecikmiş bir yedek parça, kesintinin uzamasına neden olabilir. Risk kontrolleri şunları kapsamalıdır: - Kritik yedek parçalar - Tedarikçi yanıt süreleri - Garanti kapsamı - Yazılım lisans erişimi - Yakıt teslimat seçenekleri - Ağ taşıyıcı çeşitliliği - Yüklenicinin kullanılabilirliği Her kritik işlev için tek bir tedarikçiye güvenmekten kaçınırım. Bir yedek tedarikçinin yönetimi daha maliyetli olabilir ancak ana kaynak kullanılamadığında işletmeye başka bir yol sunabilir. Aynı fikir ağ bağlantıları için de geçerlidir. Binaya aynı yoldan giren iki kablo, aynı fiziksel arıza noktasını paylaşırken ayrı bağlantılar gibi görünebilir. ## Üçüncü Taraf Sağlayıcılar Gizli Bağımlılıklar Yaratabilir Birçok veri merkezi hizmeti, bulut platformlarına, ortak yerleşim sağlayıcılarına, yönetilen hizmet şirketlerine ve harici güvenlik ekiplerine dayanır. Bu sağlayıcılar yetenekli olabilir ancak hizmet sınırlarının anlaşılmasından işletme sorumlu olmaya devam etmektedir. Bir sağlayıcı seçmeden önce şunları gözden geçiririm: - Hizmet kullanılabilirliği hedefleri - Olay iletişim yöntemleri - Veri konumu - Yedekleme sahipliği - Kurtarma sorumlulukları - Bakım kuralları - Çıkış ve geçiş seçenekleri - Denetim raporları ve güvenlik kontrolleri Bir sözleşme, bir hizmeti tek başına geri yükleyemez. Müşteri, hangi eylemlerin sağlayıcıya ait olduğunu ve hangi eylemlerin dahili ekibe ait olduğunu bilmelidir. ## Pratik Bir Risk Planını Nasıl Oluştururum Ekiplerin tekrarlayabileceği basit bir süreç kullanıyorum. ### Kritik hizmetleri haritalandırın Her hizmetin bağlı olduğu uygulamaları, veritabanlarını, ağları, binaları, tedarikçileri ve personeli listeleyin. ### Arıza noktalarını belirleyin Güç, soğutma, bağlantı, depolama, erişim kontrolü veya önemli bir çalışan kullanılamaz hale gelirse ne olacağını sorun. ### İş etkisini sıralayın Bir başarısızlığın müşteriler, gelir, operasyonlar, veriler ve kurtarma süresi üzerindeki etkisini tahmin edin. Personelin anlayabileceği net kategoriler kullanın. ### Uygun kontroller ekleyin Riske uygun kontrolleri seçin. Küçük bir sitenin, büyük ve maliyetli bir yeniden tasarım yerine daha iyi yedekleme testlerine ihtiyacı olabilir. ### Planı test edin Güç kaybı, siber olaylar, soğutma arızası, bina erişim sorunları ve veri kurtarma için kontrollü egzersizler yapın. ### Dersleri kaydedin Her testten sonra neyin işe yaradığını, neyin başarısız olduğunu, kimin karar verdiğini ve nelerin değişmesi gerektiğini yazın. Bir risk listesi bu çalışmayı görünür tutabilir. Her öğenin bir sahibi, bir inceleme tarihi, olası etkisi, mevcut kontroller ve bir sonraki eylem bulunmalıdır. ## Sorulmaya Değer Sorular Bir veri merkezini incelediğimde şunu soruyorum: - Kesintinin en olası nedeni nedir? - Hangi sistemin pratik bir yedeği yoktur? - İşletme bu hizmet olmadan ne kadar süre çalışabilir? - En son tam iyileşme testi ne zaman yapıldı? - Ana araçların mevcut olmaması durumunda personel iletişim kurabiliyor mu? - Hangi tedarikçiler aynı fiziksel veya teknik bağımlılığı paylaşıyor? - Acil durum değişikliklerini kim onaylayabilir? - Müşteriler doğru güncellemeleri nasıl alacak? Bu sorular genellikle ekipman listelerinin göstermediği boşlukları ortaya çıkarır. Güvenli bir veri merkezi, sahip olduğu jeneratörlerin, kameraların veya güvenlik duvarlarının sayısıyla tanımlanmaz. Gücü, koşullar zorlaştığında insanların, sistemlerin, prosedürlerin, tedarikçilerin ve kurtarma planlarının birlikte ne kadar iyi çalıştığına bağlıdır. Test edilmiş kontrollere, açık sahiplik ve dürüst kurtarma hedeflerine odaklanıyorum. Bu yaklaşım, bir işletmeye risk durumu hakkında daha iyi bir görüş sağlar ve daha güçlü hizmet sürekliliğine yönelik pratik bir yol sağlar. Endüstri Alanında geniş deneyime sahibiz. Profesyonel tavsiye için bizimle iletişime geçin: Yonglin Wang: 13382583527@gmail.com/WhatsApp +8613382583527.

IBM 2024 Veri İhlalinin Maliyeti Raporu Verizon 2024 Veri İhlali Araştırmaları Raporu OVHcloud 2021 Strasbourg Veri Merkezi Yangın Olay Raporu Ulusal Standartlar ve Teknoloji Enstitüsü 2012 Bilgisayar Güvenliği Olay İşleme Kılavuzu Ulusal Standartlar ve Teknoloji Enstitüsü 2018 Kritik Altyapı Siber Güvenliğini İyileştirme Çerçevesi Çalışma Süresi Enstitüsü 2023 Yıllık Veri Merkezi Anketi Sonuçları