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

Bir veri merkezi dışarıdan güvenli görünse de ciddi operasyonel risk taşıyabilir. Korumalı bir giriş, sıra sıra kameralar, yedek jeneratörler ve temiz bir sunucu odası, kontrol hissi yaratır. Bana sitenin bir soğutma arızasını, bir güç aktarımı sorununu, bir ağ kesintisini veya bakım sırasında yapılan bir hatayı kaldırabilecek durumda olup olmadığını söylemiyorlar. Rakamlar bu sorunun neden daha fazla ilgiyi hak ettiğini gösteriyor. Uptime Institute raporları, birçok veri merkezi kesintisinin maliyetinin 100.000 dolardan fazla olduğunu, daha küçük bir grubun ise 1 milyon doların üzerinde kayıplara neden olduğunu tespit etti. Maliyet onarım işiyle sınırlı değildir. Satış kayıplarını, kaçırılan hizmet hedeflerini, müşteri şikayetlerini, veri kurtarmayı ve güvenin zarar görmesini içerebilir. Bir veri merkezini incelerken sadece “Yedek ekipmanı var mı?” diye sormuyorum. "Yedekleme sistemi başlatılamazsa ne olur?" diye soruyorum. Yedekleme sistemi, test edilmiş bir yedekleme sistemiyle aynı değildir Çoğu veri merkezi birkaç güç koruması katmanı kullanır: - Şebeke gücü - Kesintisiz güç kaynakları - Akü sistemleri - Yedek jeneratörler - Otomatik transfer anahtarları - Yakıt depolama - Güç dağıtım üniteleri Bu tasarım riski azaltabilir ancak her katmanın kendi arıza noktaları vardır. Jeneratörde yeterli yakıt olmasına rağmen zayıf akü, tıkalı hava filtresi, kirlenmiş yakıt veya kontrol paneli arızası nedeniyle arızalanabilir. Bir UPS, kısa bir kesinti sırasında yükü destekleyebilir, ancak aküleri eskidikçe kapasite kaybetmiş olabilir. Sadece ekipman listelerini değil, düzenli testlerin kanıtlarını arıyorum. Yararlı bir inceleme aşağıdaki gibi soruları içerir: - Son jeneratör yük testi ne zaman yapıldı? - Piller gerçekçi koşullar altında test edildi mi? - Planlanan bir tatbikat sırasında transfer anahtarı kontrol edildi mi? - Bakım ekiplerinin canlı sistemler üzerinde çalışmasına izin veriliyor mu? - Tesis başarısız testleri ve düzeltici eylemleri kaydediyor mu? Jeneratörü birkaç dakika çalıştıran bir test, uzun bir kesinti sırasında ne olacağını göstermeyebilir. Daha güçlü bir inceleme, sistemin gerekli süre boyunca beklenen yükü taşıyıp taşıyamayacağını kontrol eder. Soğutma sorunları servis sorunlarına dönüşebilir Sunucular çalıştıkları her dakika ısı üretirler. Soğutma arızası, özellikle yüksek yoğunluklu raf alanında oda sıcaklığını hızlı bir şekilde yükseltebilir. Yanıt birkaç faktöre bağlıdır: - Ekipmanın ürettiği ısı miktarı - Hava akışı tasarımı - Soğutma ünitelerinin sayısı - Arızalı bir üniteyi onarmak için gereken süre - Sıcak koridor ve soğuk koridor ayrımının varlığı - Çevresel izleme Sıcaklık ve nem uyarılarına çok dikkat ediyorum. Bir izleme platformu tek bir ortalama okumadan fazlasını göstermelidir. Oda ortalaması normal görünürken bir raf tehlikeli bir durumla karşı karşıya kalabilir. Pratik bir inceleme, sensörlerin aşağıdakilerin yakınına yerleştirilip yerleştirilmediğini kontrol etmelidir: - Yüksek yoğunluklu raflar - Güç dağıtım ekipmanı - Soğutma ünitesi çıkışları - Yükseltilmiş zemin açıklıkları - Sınırlı hava akışına sahip alanlar Bir veri merkezi, oda düzeyinde bir incelemeyi geçebilir ve yine de yerel sıcak noktalara sahip olabilir. Bu nedenle sensör yerleşimi önemlidir. İnsan hatası riskin bir parçası olmaya devam ediyor Kesintilerin büyük bir kısmı bakım çalışmalarını, konfigürasyon değişikliklerini veya bir prosedüre uyulmamasını içerir. Bu, personelin dikkatsiz olduğu anlamına gelmez. Karmaşık tesisler, küçük bir hatanın büyük bir sistemi etkilemesi için birçok fırsat yaratır. Basit kontroller ararım: - Yüksek riskli işler için iki kişilik kontroller - Yazılı değişiklik prosedürleri - Açık ekipman etiketleri - Ayrı onay ve yürütme görevleri - Erişim günlükleri - Planlanan her değişiklik için kurtarma adımları - Gerçek olaylara dayalı düzenli eğitim Yararlı bir test, bir operatörden acil durum kapatmasından sonra ne olacağını açıklamasını istemektir. Cevap deneyimli bir çalışana bağlıysa süreç çok kırılgan olabilir. Prosedürlerin bulunması ve takip edilmesi kolay olmalıdır. Kimsenin kullanmadığı uzun bir belge canlı bir ortamı korumaz. Fiziksel güvenlik ön kapıda bitmez Güvenlik incelemeleri genellikle çitlere, korumalara, rozetlere ve kameralara odaklanır. Bu kontroller önemlidir ancak tesisin içi de aynı düzeyde dikkat gerektirir. Sitenin aşağıdakilere erişimi ayırıp ayırmadığını kontrol ediyorum: - Ağ odaları - Sunucu kafesleri - Güç odaları - Pil alanları - Kontrol sistemleri - Yedek parça depolama - Yükleme ve teslimat alanları Bir ziyaretçi, birkaç kontrol olmadan resepsiyon alanından sunucu odasına geçememelidir. Geçici erişim, proje sona erdikten sonra aktif kalmak yerine otomatik olarak sona ermelidir. Kamera kapsamının da incelenmesi gerekiyor. Bir kapıyı işaret eden ancak rozet kullanan kişiyi gösteremeyen bir kamera sınırlı değer sağlayabilir. Video saklama, kuruluşun araştırma ihtiyaçlarına ve gizlilik görevlerine uygun olmalıdır. Fiziksel erişim kayıtları iş emirleriyle bağlantılı olmalıdır. Bir kişinin kısıtlı bir odaya girmesi durumunda şirket hangi görevin onaylandığını ve hangi sistemlerin etkilendiğini kontrol edebilmelidir. Siber güvenlik ve tesis sistemleri artık örtüşüyor Modern veri merkezleri, güç, soğutma, alarmlar, erişim ve bina kontrollerini yönetmek için yazılıma güveniyor. Bu sistemler görünürlüğü artırır ancak aynı zamanda dijital giriş noktaları da oluşturur. Bir güvenlik incelemesi şunları içermelidir: - Tesis kontrolleri ve iş sistemleri için ayrı ağlar - Uzaktan erişim için çok faktörlü kimlik doğrulama - Bireysel kullanıcı hesapları - Etkin olmayan hesapların kaldırılması - Kontrollü satıcı erişimi - Düzenli yama planlaması - Komutlar ve konfigürasyon değişiklikleri için günlükler - Sistem kesintileri için manuel işletim planı Paylaşılan yönetici hesapları, araştırmaları zorlaştırır. Bir bakım penceresinden sonra açık kalan uzaktan erişim, önlenebilir başka bir risk oluşturur. Ayrıca tesisin bina sistemlerini etkileyen bir siber olaya maruz kalıp kalmadığını da soruyorum. Çalınan müşteri verilerini kapsayan bir müdahale planı, kontrol yazılımı mevcut olmadığında personelin soğutmayı ve gücü nasıl istikrarlı tutacağını açıklayamayabilir. Rakamların bağlamı gerekir Tier III veya Tier IV gibi etiketler tesis tasarımını karşılaştırmaya yardımcı olabilir ancak hikayenin tamamını anlatmazlar. Sertifikasyon, spesifik tasarım ve çalışma koşullarını tanımlar. Her hizmetin, uygulamanın, ağ yolunun veya müşteri iş yükünün her etkinlikte kullanılabilir kalacağını garanti etmez. Operasyonel resmin tamamını görmek istiyorum: - Tesisin bakım kaydı - Son yıllardaki kesinti sayısı - Her kesintinin süresi ve nedeni - Kurtarma süreci - Dayanıklılık testlerinin sonuçları - Ağ bağlantılarının korunması - Yedekleme sitelerinin konumu - İş yüklerini taşımak için gereken süre Bir şirket, iyi tasarlanmış bir siteden faaliyet gösterebilir ve tek ağ sağlayıcısının bölgesel bir arızası varsa yine de hizmet kaybıyla karşı karşıya kalabilir. Her iki konum da aynı elektrik şebekesini, taşıyıcı güzergahını, bulut bölgesini veya personel bağımlılığını paylaşıyorsa ikinci bir veri merkezi yardımcı olmayabilir. Coğrafi ayrım, binalar arasındaki kilometre sayısına göre değil, gerçek riske göre ölçülmelidir. Pratik bir güvenlik incelemesi Bir veri merkezini değerlendirirken beş adımlı basit bir inceleme kullanıyorum. 1. Kritik hizmetlerin haritasını çıkarın Geliri, müşteri erişimini, dahili çalışmayı, güvenliği ve kurtarmayı destekleyen sistemleri listeleyin. Uzun bir kesintiye tahammül edemeyen sistemleri işaretleyin. 2. Her bağımlılığı izleyin Her hizmet için güç yolunu, soğutma desteğini, ağ taşıyıcılarını, DNS sağlayıcısını, depolama konumunu, personel grubunu ve üçüncü taraf araçlarını tanımlayın. 3. Arıza kanıtlarını inceleyin Kesinti kayıtlarını, bakım raporlarını, alarm kayıtlarını, akü test sonuçlarını, jeneratör testlerini ve kurtarma egzersiz notlarını isteyin. Temiz rapora gerek yok. Dürüst kayıtlar kuruluşun sorunlardan ders alıp almadığını gösterir. 4. Yanıtı test edin Tartışma faydalıdır ancak kontrollü bir egzersiz daha fazlasını gösterir. Şebeke kaybını, soğutma ünitesi arızasını, ağ kesintisini veya uzaktan erişim kaybını simüle edin. İnsanların olayı tespit etmesi, karar vermesi, tedarikçilerle iletişime geçmesi ve hizmeti yeniden sağlamasının ne kadar sürdüğünü kaydedin. 5. Ölçülebilir eylemler belirleyin Her riskin bir sahibi, bir hedef tarihi ve bir doğrulama yöntemi olmalıdır. "Dayanıklılığı artırın" ifadesi çok geniş kapsamlıdır. "İkinci bir taşıyıcı yolu ekleyin ve her üç ayda bir yük devretmeyi test edin", ekibe kontrol edebileceği bir şey verir. Geçmişteki kesintilerden bir ders 2021'deki Facebook kesintisi, ağ yapılandırmasındaki bir değişikliğin hem hizmetlere hem de dahili araçlara erişimi nasıl etkileyebileceğini gösterdi. Olay basit bir sunucu arızası değildi. Bir kesinti sırasında bağlantılı sistemlerin, erişim kontrollerinin ve kurtarma prosedürlerinin nasıl etkileşime girebileceğini gösterdi. Bu ders her büyüklükteki veri merkezleri için geçerlidir. Bir site güçlü jeneratörlere ve modern sunuculara sahip olabilir, ancak mühendisler yönetim sistemlerine, kimlik doğrulama hizmetlerine veya doğru ağ kayıtlarına ulaşamazlarsa kurtarma işlemi yavaşlayabilir. Güvenlik binanın görünümüyle kanıtlanmaz. Bu, test edilmiş sistemler, faydalı kayıtlar, eğitimli personel ve normal araçlar kullanılamadığında işe yarayan bir kurtarma planıyla gösterilir. Bir veri merkezini değerlendirirken etiketlerden çok kanıtlara güvenirim. Kontrollü bir arıza sırasında sitenin nasıl performans gösterdiğini, insanların ne kadar hızlı yanıt verdiğini ve kuruluşun her olayı belirli bir iyileştirmeye dönüştürüp dönüştürmediğini görmek istiyorum. Bu ayrıntılar, tek başına ekipman sayımlarından daha yararlı bir risk görünümü sunar.

Bir veri merkezi dışarıdan güvenli görünse de içeride ciddi riskler taşıyabilir. Kilitli bir bina kimlik bilgilerinin çalınmasını engellemez. Kurtarma hiç test edilmemişse yedekleme sistemi yardımcı olmaz. Bir güvenlik aracı olağandışı etkinlikleri tespit edebilir ancak personelin yine de net bir müdahale planına ihtiyacı vardır. Son raporlar, veri merkezi güvenliğinin neden hem teknik ekiplerin hem de iş liderlerinin ilgisini hak ettiğini gösteriyor. Verizon'un 2024 Veri İhlal Araştırmaları Raporu, 10.000'den fazla doğrulanmış ihlal dahil olmak üzere 30.000'den fazla güvenlik olayını inceledi. Rapor, kimlik bilgilerinin çalınması, sosyal mühendislik ve erişimin kötüye kullanılması gibi eylemler yoluyla gerçekleşen ihlallerin yaklaşık %68'inde insan unsurunun rol oynadığını ortaya koydu. IBM'in Veri İhlalinin Maliyeti Raporu 2024, bir ihlalin küresel ortalama maliyetini 4,88 milyon dolar olarak belirledi. Bu şekil, yalnızca veri merkezi operatörlerini değil, birçok kuruluş türünü kapsamaktadır, aynı zamanda zayıf kontrollerin yarattığı mali baskıya ilişkin yararlı bir görünüm sunmaktadır. Bu rakamlardan çıkardığım ders basit: Fiziksel koruma önemlidir, ancak kimlik, izleme, esneklik ve personelin eylemleri bir olayın sonucunu şekillendirebilir. ### En son veriler bize ne söylüyor Bir veri merkezi aynı anda birçok risk alanıyla karşı karşıyadır: - Yetkisiz fiziksel giriş - Güvenliği ihlal edilmiş yönetici hesapları - Fidye yazılımı ve kötü amaçlı yazılım - Ağ saldırıları - Ekipman arızası - Güç veya soğutma kesintisi - Kötü yedekleme tasarımı - Gecikmiş olay müdahalesi - Çalışanlar, satıcılar veya yükleniciler tarafından yapılan hatalar Uptime Institute'un kesinti araştırması, güç sorunlarının veri merkezi kesintilerinin ana nedenlerinden biri olmaya devam ettiğini defalarca göstermiştir. Kesinti incelemelerinde ağ arızaları, soğutma arızaları, yazılım sorunları ve insan hataları da ortaya çıkıyor. Güvenlik ve kullanılabilirlik yakından bağlantılıdır. Bir tesis veri ihlalinden kaçınabilir ancak soğutma kontrolü başarısız olduğu için yine de hizmet kaybedebilir. Bir şirket güçlü güvenlik duvarlarına sahip olabilir ancak tek bir yönetici hesabı birçok cihazda kullanıldığında sistemlerine erişimi kaybedebilir. ### Fiziksel güvenlik hala temeli oluşturuyor Girişte veri merkezi incelemesine başlıyorum. Pratik bir fiziksel güvenlik planı şunları içerebilir: 1. Adı geçen çalışanlarla bağlantılı kimlik kartı erişimi 2. Hassas alanlar için çok faktörlü kimlik doğrulama 3. Toplantı sahibinin onayıyla ziyaretçi kayıtları 4. Kapıları, yükleme bölgelerini ve ekipman odalarını kapsayan kameralar 5. Personel, satıcılar ve yükleniciler için ayrı erişim bölgeleri 6. Zorunlu kapılar veya olağandışı giriş zamanları için uyarılar 7. Etkin olmayan kimlik kartlarının düzenli olarak gözden geçirilmesi 8. Hizmetten kaldırılan donanımın güvenli kullanımı Erişim, kişinin işine uygun olmalıdır. Soğutma ekipmanına bakım yapan bir satıcının sunucu raflarına erişmesi gerekmeyebilir. Bir odada çalışan teknisyenin her alanı açan bir rozete ihtiyacı olmayabilir. Bu tür bir kontrol bir olaydan sonra da yardımcı olur. Güvenlik ekipleri giriş kayıtlarını, kamera görüntülerini ve sistem kayıtlarını eşleştirebildiğinde, ne olduğuna dair daha net bir görüşe sahip olurlar. ### Kimlik merkezi bir güvenlik sorunu haline geldi Birçok saldırı geçerli bir hesapla başlar. Bir parola zaten açığa çıkarılmışsa saldırganın güvenlik duvarını aşması gerekmeyebilir. Açık bir kimlik planı öneririm: - Yönetici ve uzaktan erişim için çok faktörlü kimlik doğrulamayı zorunlu kılın - Her çalışana ayrı bir hesap verin - Paylaşılan şifreleri kaldırın - Yönetici haklarını sınırlayın - Satıcı hesaplarını sabit bir programa göre inceleyin - Ayrıcalıklı eylemleri kaydedin - Bir sözleşme veya rol sona erdiğinde hesapları devre dışı bırakın - Hassas kimlik bilgilerini yönetilen bir şifre sisteminde saklayın Erişim, yalnızca yıllık denetim sırasında değil, rol değişikliklerinden sonra da gözden geçirilmelidir. Altyapı desteğinden başka bir ekibe geçen kişi, artık işe uygun olmayan hakları elinde tutabilir. ### İzleme sinyalleri birbirine bağlamalıdır Tek bir uyarı nadiren bir saldırıyı açıklar. Güvenlik ekipleri birden fazla sinyali birbirine bağladığında daha fazla değer kazanır: - Alışılmadık bir saatte kullanılan bir kimlik kartı - Bilinmeyen bir yerden giriş - Yönetici aktivitesinde ani bir artış - Büyük veri aktarımları - Güvenlik duvarı kurallarındaki değişiklikler - Kritik bir sunucuya yeni yazılım yüklenmesi - Tekrarlanan başarısız giriş denemeleri Bir güvenlik bilgisi ve olay yönetimi platformu bu kayıtları toplayabilir. Araç önemlidir, ancak yanıt süreci de bir o kadar önemlidir. Birinin hangi uyarıların eylem gerektirdiğini, mesajı kimin aldığını ve hangi kanıtların korunması gerektiğini bilmesi gerekir. ### Yedeklemelerin bir kurtarma testine ihtiyacı vardır Birçok kuruluş, yedekleri olduğunu söylüyor. Daha azı iyileşmenin ne kadar sürdüğünü gösterebilir. Şu noktaları test etmenizi öneririm: 1. Yedeklemelerin eksiksiz olup olmadığı 2. Yedekleme hesaplarının normal kullanıcı hesaplarından ayrılıp ayrılmadığı 3. Kopyaların fidye yazılımlarından korunup korunmadığı 4. Kurtarmanın orijinal üretim sistemi olmadan çalışıp çalışmadığı 5. İşletmenin kurtarma süresi boyunca çalışıp çalışmadığı 6. Kurtarma hedeflerinin müşteri ve dahili ihtiyaçlarla eşleşip eşleşmediği Hiçbir zaman geri yüklenmeyen bir yedekleme, kanıtlanmış bir kontrol değil, bir varsayımdır. Yararlı bir örnek 2021 Koloni Boru Hattı olayından geliyor. Şirket, bir fidye yazılımı saldırısının ardından sistemleri çevrimdışına aldı ve yakıt operasyonları kesintiye uğradı. Etkinlik, iş sistemlerindeki bir siber olayın fiziksel tedariki ve kamu hizmetlerini nasıl etkileyebileceğini gösterdi. Veri merkezi ekipleri de benzer bir zorlukla karşı karşıyadır: Teknik bir olay hızla operasyonel bir soruna dönüşebilir. ### İnsanların yalnızca politikalara değil pratiğe de ihtiyacı var Güvenlik eğitimi, yıllık bir video ve kısa bir testten oluştuğunda genellikle başarısız olur. Personelin işleriyle eşleşen örneklere ihtiyacı var. Eğitim şunları kapsayabilir: - Acil bir erişim talebi nasıl kontrol edilir - Şüpheli bir giriş nasıl bildirilir - Bir rozet kaybolduğunda ne yapılmalı - Satıcılar nasıl doğrulanır - Bir sunucunun ne zaman izole edilmesi gerekir - Acil durum değişikliklerini hangi kişi onaylayabilir Masa üstü alıştırmaları ekiplere pratik yapmak için güvenli bir yol sağlar. Bir alıştırma çalınan yönetici şifresiyle başlayabilir. Bir diğeri, bir ağ saldırısı sırasında arızalı bir soğutma ünitesini içerebilir. Her oturumda belirsiz görevler, eksik iletişim bilgileri veya yavaş onay adımları ortaya çıkabilir. ### Pratik bir güvenlik inceleme planı Veri merkezi incelemesi için bu sırayı kullanırdım: - Kritik sistemleri ve hizmetleri listeleyin - Fiziksel ve dijital erişimi haritalandırın - Yönetici ve satıcı hesaplarını kontrol edin - Günlükleri ve uyarı kapsamını inceleyin - Yedekleme kurtarmayı test edin - Güç, soğutma ve ağ esnekliğini inceleyin - Bir olay müdahale egzersizi çalıştırın - Boşlukları bir sahip ve hedef tarihle kaydedin - Büyük sistem veya personel değişikliklerinden sonra incelemeyi tekrarlayın İstatistikler tek bir çözüme işaret etmez. Bir model gösteriyorlar: küçük zayıflıklar bağlandığında veri merkezi riski artıyor. Çalınan bir şifre, aktif bir satıcı hesabı, zayıf izleme ve test edilmemiş bir yedekleme birlikte çok daha büyük bir sorun yaratabilir. Sade bir dille anlatılabilecek, baskı altında test edilebilecek bir güvenlik planını tercih ediyorum. Güçlü koruma yalnızca kilitli bir tesis veya güvenlik panosundan ibaret değildir. Ekibin fiilen uyguladığı, erişim kontrolleri, eğitimli kişiler, güvenilir altyapı, faydalı kayıtlar ve kurtarma adımlarından oluşan çalışan bir sistemdir.

Bir veri merkezi içeride boşluklar kalırken dışarıdan kontrollü görünebilir. Temiz zeminler, kilitli kapılar, kameralar ve büyük bir güvenlik ekibi; sistemlerin, personelin, satıcıların ve kurtarma planlarının ciddi bir olaya hazır olduğunu kanıtlamaz. Ekiplerin güvenlik duvarlarına odaklandığını ve rozetlere erişim sağladığını ancak temel uyarı işaretlerini gözden kaçırdığını gördüm: Etkin olmayan kullanıcı hesapları, zayıf yedekleme testleri, belirsiz satıcı erişimi ve kimsenin incelemediği uyarılar. Bu boşluklar hizmet kullanılabilirliğini, veri korumasını ve müşteri güvenini etkileyebilir. Faydalı bir inceleme basit sorularla başlar: - Tesise kimler girebilir? - Sunuculara ve yönetim araçlarına kimler erişebilir? - Hangi sistemlere yama uygulanmadı? - Ekip verileri tahmine gerek kalmadan geri yükleyebilir mi? - Bir anahtar satıcı hesabı kötüye kullanıldığında ne olur? Cevaplar genellikle gösterişli bir güvenlik raporundan daha fazlasını ortaya koyuyor. ## Uyarı işareti 1: Roller değiştikten sonra erişim hakları etkin kalır İnsanlar iş değiştirir, şirketten ayrılır veya başka bir ekibe geçer. Erişimleri onlarla birlikte değişmeli. Aşağıdaki durumlarda bir uyarı işareti görünür: - Eski çalışanların hâlâ aktif hesapları varsa - Yükleniciler proje sona erdikten sonra erişime devam ederse - Paylaşılan yönetici hesapları yaygındır - Erişim incelemeleri yalnızca bir olaydan sonra gerçekleşir - Personel günlük işlerinin gerektirdiğinden daha geniş izinler alır Erişim listesini bir denetim için oluşturulmuş bir belge olarak değil, yaşayan bir kayıt olarak ele alırım. Her hesabın bir sahibi, bir iş nedeni, bir onay tarihi ve bir inceleme tarihi olmalıdır. Pratik bir inceleme şu yolu izleyebilir: 1. Aktif hesapları kimlik, sunucu, bulut ve ağ sistemlerinden dışarı aktarın. 2. Her hesabı mevcut bir çalışanla veya onaylı satıcıyla eşleştirin. 3. Açıkça sahibi olmayan hesapları kaldırın. 4. Kullanıcının rolünü aşan izinleri azaltın. 5. Yönetici erişimi için daha güçlü oturum açma kontrolleri isteyin. 6. Sonucu kaydedin ve bir sonraki inceleme tarihini ayarlayın. Kullanılmayan tek bir yönetici hesabı ihlale neden olmayabilir. Takımın kontrol etmesi gereken başka bir yol yaratır. ## Uyarı işareti 2: Fiziksel güvenlik tek bir kontrole bağlıdır Kilitli bir kapı faydalıdır ancak güvenlik planının tamamını taşımamalıdır. Aşağıdaki alanlardaki boşlukları arayın: - Ziyaretçi kayıtları - Kamera kapsamı - Kimlik paylaşımı - Teslimat erişimi - Bakım odaları - Sunucu kabini kilitleri - Acil durum çıkışları - Hiçbir zaman incelenmeyen erişim günlükleri Basit bir test, zayıf süreçleri ortaya çıkarabilir. Bir personelden, bir ziyaretçinin resepsiyondan kısıtlı bir odaya nasıl geçtiğini açıklamasını isteyin. Cevap; kimlik kontrollerini, eskort kurallarını, yaka kartlarının işlenmesini, erişim kayıtlarını ve çıkış prosedürlerini içermelidir. Uptime Institute, tesis sorunlarının kesintilere yol açabileceğini, kamuya açık olayların ise yangın, güç, soğutma ve erişim sorunlarının dijital hizmetleri nasıl etkileyebileceğini gösterdiğini bildirdi. Strazburg'daki OVHcloud tesisinde 2021 yılında çıkan yangın, ekipmanlara zarar verdi ve bazı müşterilerin hizmetlerini kesintiye uğrattı. Olay sadece teknoloji sorunu değildi. Site tasarımı, müdahale planları, yedeklemeler ve müşteri kurtarma seçeneklerinin hepsi önemliydi. Bir veri merkezi, fiziksel bir site olarak ve daha geniş bir hizmet zincirinin parçası olarak gözden geçirilmelidir. ## Uyarı işareti 3: Güvenlik uyarıları toplanır ancak incelenmez Birçok ekibin günlüklerle dolu gösterge tabloları vardır. Bu, bir tehdidi tespit edebilecekleri anlamına gelmez. Şu sorulara net yanıtlar arıyorum: - Normal çalışma saatleri dışında uyarıları kim inceliyor? - Hangi olaylar acil eylem gerektirir? - Yanlış alarmlar nasıl azaltılır? - Günlükler ne kadar süreyle tutulur? - Günlükler değiştirilmeye karşı korunuyor mu? - Ekip sunucular, ağlar ve kimlik araçları arasındaki etkinlikleri birbirine bağlayabiliyor mu? Personel "Uyarı var ama kimse sahip değil" dediğinde bir uyarı işareti beliriyor. Ekip, küçük bir dizi yüksek değerli olay tanımlayarak bu süreci iyileştirebilir: - Yeni yönetici hesapları - Tekrarlanan başarısız oturum açma işlemleri - Alışılmadık bir konumdan oturum açma - Güvenlik duvarı kurallarında ani değişiklikler - Büyük veri aktarımları - Devre dışı bırakılan güvenlik araçları - Yedekleme sistemlerine erişim - Beklenmeyen uzaktan yönetim etkinliği Her olayın bir sahibine ve işe uygun bir yanıt süresine ihtiyacı vardır. Küçük bir şirket dışarıdan bir izleme sağlayıcısı kullanabilir. Daha büyük bir operasyonun dahili bir güvenlik ekibi olabilir. Model değişebilir ancak gözetimsiz uyarılar risk oluşturur. ## Uyarı işareti 4: Düzeltme eki kanıt yerine alışkanlığa dayanır Bir düzeltme eki planı işletim sistemlerini, donanım yazılımını, ağ aygıtlarını, hipervizörleri, depolama sistemlerini, güvenlik araçlarını ve yönetim platformlarını kapsamalıdır. Uyarı işaretleri şunları içerir: - Tam varlık listesi yok - Desteklenmeyen yazılım çalıştıran cihazlar - Test edilmeden yüklenen yamalar - Yazılı bir neden olmaksızın kritik sistemlerin yama yapılmadan bırakılması - Tek kişiye bağlı manuel güncellemeler - Başarısız güncelleme kaydı yok Her güncellemenin test edilmeden uygulanmasını beklemiyorum. Üretim sistemleri bir bakım aralığına, bir geri alma planına ve bir hizmet sahibine ihtiyaç duyabilir. Endişe, kimsenin hangi sistemlerin açığa çıktığını ve nedenini açıklayamamasıyla başlıyor. Yararlı bir yama kaydı şunları içerir: - Varlık adı - Yazılım sürümü - Bilinen sorun veya satıcı tavsiyesi - Risk düzeyi - Planlanan eylem - Onay - Tamamlanma tarihi - Geri alma yöntemi Bu kayıt aynı zamanda teknik sınırların basit ihmallerden ayrılmasına da yardımcı olur. ## Uyarı işareti 5: Yedeklemeler mevcut ancak geri yükleme test edilmedi Geri yüklenemeyen bir yedekleme yalnızca bir varsayımdır. Ekiplerden aşağıdakiler için kontrollü kurtarma testleri yapmalarını istiyorum: - Müşteri veritabanları - Sanal makineler - Dosya depolama - Yapılandırma dosyaları - Kimlik hizmetleri - Ağ ayarları - Şifreleme anahtarları - Kritik uygulamalar Test, kurtarmanın ne kadar sürdüğünü ve geri yüklenen sistemin çalışıp çalışmadığını ölçmelidir. Bir dosya kopyası tek başına bir veritabanını, uygulama bağlantısını, izin modelini veya şifreleme anahtarını geri yükleyemeyebilir. 2017 NotPetya saldırısı, yıkıcı kötü amaçlı yazılımların şirketleri ve tedarik zincirlerini ne kadar hızlı etkileyebileceğini gösterdi. Maersk daha sonra saldırının ardından büyük iş kesintisi yaşandığını açıkladı. Çıkarılacak ders, her kuruluşun aynı kurtarma tasarımına ihtiyaç duyması değildir. Yararlı ders, kurtarmanın test edilmiş prosedürlere, ayrı kopyalara, net mülkiyete ve gerçekçi zaman hedeflerine bağlı olmasıdır. Temel bir yedekleme incelemesi şu soruyu sorar: - En az bir kopya normal yönetici erişiminden ayrılmış mı? - Yedeklemeler uygun olduğu yerde şifreleniyor mu? - Saldırganlar tek hesaptaki tüm kopyaları silebilir mi? - Saklama süreleri iş ihtiyaçlarıyla bağlantılı mı? - Ekip yalnızca tek bir dosyayı değil, tam hizmeti geri yükledi mi? ## Uyarı işareti 6: Satıcı erişimi geniş ve kalıcıdır Veri merkezleri, ekipman üreticilerine, yönetilen hizmet sağlayıcılara, kablolama ekiplerine, bulut platformlarına, temizlik yüklenicilerine ve diğer ortaklara güvenir. Her bağlantı güvenlik resmini etkileyebilir. Satıcı erişim süreci şunları tanımlamalıdır: - Erişimi kim onayladı - Satıcının hangi sistemlere ulaşabileceği - Erişimin ne zaman başlayıp bittiği - Oturumların kaydedilip kaydedilmediği - Hangi eylemlerin dahili onay gerektirdiği - Hesapların nasıl kaldırıldığı - Sözleşme sona erdikten sonra ne olacağı Kalıcı satıcı hesapları yakından incelenmeyi hak eder. Sınırlı izinlere sahip geçici erişimin kontrolü, yıllarca kullanılan ortak bir hesaba göre daha kolaydır. Ayrıca sözleşmelerin olay raporlamayı, veri işlemeyi, destek sorumluluklarını ve erişimin kaldırılmasını kapsayıp kapsamadığını da kontrol ediyorum. Yasal dil teknik kontrollerin yerini almaz, ancak belirsiz sorumluluk, bir olay meydana geldiğinde müdahaleyi yavaşlatabilir. ## Uyarı işareti 7: Ağ tasarımı kolay harekete izin verir Güvenliği ihlal edilmiş bir iş istasyonu, yedekleme sistemlerine, ödeme hizmetlerine, müşteri veritabanlarına ve yönetim araçlarına basit bir yol sağlamamalıdır. Ağ bölümlendirmesi, aşağıdaki gibi alanlar arasındaki hareketi sınırlayabilir: - Halka açık hizmetler - Dahili uygulamalar - Depolama sistemleri - Yönetim araçları - Yedekleme altyapısı - Güvenlik yönetimi platformları - Bina yönetim sistemleri Segmentasyon test edilmeli, bir diyagramdan kabul edilmemelidir. Kısıtlayıcı görünen bir güvenlik duvarı kuralı, güvenilir bir hizmet hesabı üzerinden geniş trafiğe yine de izin verebilir. Çok az kişinin anlayabileceği geniş bir diyagram yerine, hangi sistemin hangi sistemle konuştuğunu gösteren yazılı bir akış haritasını tercih ediyorum. Haritanın bir sahibi ve inceleme tarihi olmalıdır. ## Uyarı işareti 8: Personel eğitimi yıllık bir onay kutusudur İnsanların işlerine uygun açık rehberliğe ihtiyacı vardır. Eğitim şunları kapsamalıdır: - Kimlik avı ve kimlik bilgisi hırsızlığı - Kimlik bilgileri paylaşımı - Ziyaretçi yönetimi - Uzaktan erişim - Çıkarılabilir medya - Olay raporlama - Şifre ve kimlik doğrulama uygulamaları - Müşteri bilgilerinin güvenli kullanımı Kısa bir senaryo, hazırlığı uzun bir slayt gösterisinden daha iyi test edebilir. Şunu sorun: "Satıcı olduğunu iddia eden bir kişiden hizmet hesabının sıfırlanması yönünde acil bir talep aldınız. Ne yaparsınız?" Beklenen yanıt; kimlik kontrollerini, onaylanmış bir kanalı, bir üst kademeye iletme yolunu ve isteğin kaydını içermelidir. Personel, şüpheli bir olayı erken bildirmenin faydalı olduğunu bilmelidir. Gecikmiş bir rapor, saldırgana sistemler arasında geçiş yapması için daha fazla zaman verebilir. ## Uyarı işareti 9: Olay planının açık bir sahibi yok Genel ifadelerle dolu bir plan, canlı bir etkinlik sırasında yardımcı olmayabilir. Çalışan bir müdahale planı şunları tanımlar: - Müdahaleyi başlatan kişi - Teknik ve ticari karar vericiler - Satıcılar ve hizmet sağlayıcılar için iletişim bilgileri - Kanıt işleme adımları - Müşteri iletişim rolleri - Yedekleme ve kurtarma eylemleri - Sistemlerin izolasyonu için kriterler - Kararların kaydedilmesi için bir süreç Çalınan yönetici şifresi veya arızalı bir soğutma sistemi gibi basit bir senaryo ile bir alıştırma yapın. Ekibe sınırlı bilgi verin ve nasıl tepki verdiğini gözlemleyin. Alıştırmadan sonra şunları kaydedin: - Neyin çok uzun sürdüğünü - Hangi iletişim bilgilerinin güncelliğini yitirdiğini - Hangi kararların belirsiz olduğunu - Hangi araçların kullanılamadığını - Hangi görevlerin tek kişiye bağlı olduğunu Bu kayıt, planı bir çalışma listesine dönüştürür. ## Pratik bir veri merkezi güvenliği incelemesi Bir veri merkezini incelerken şu sırayı kullanırım: 1. Fiziksel siteleri, sistemleri, uygulamaları, satıcıları ve sahipleri listeleyin. 2. Önemli verileri ve hizmet bağımlılıklarını haritalandırın. 3. Kimliği ve yönetici erişimini gözden geçirin. 4. Yama durumunu ve desteklenmeyen varlıkları kontrol edin. 5. İzlemeyi ve uyarı sahipliğini test edin. 6. Fiziksel erişim kayıtlarını inceleyin. 7. Ağ yollarını ve uzak bağlantıları gözden geçirin. 8. Yedekleme geri yüklemesini test edin. 9. Satıcı kontrollerini kontrol edin. 10. Bir olay tatbikatı yapın. 11. Bulguları yalnızca teknik dile göre değil, iş etkisine göre sıralayın. 12. Düzeltici çalışma için sahipleri ve tarihleri ​​atayın. İnceleme açık kanıtlar üretmelidir: erişim kayıtları, test sonuçları, varlık listeleri, ağ kuralları, kurtarma süreleri ve yanıt notları. Sahipleri olmayan endişeler listesi nadiren kalıcı değişime yol açar. Güvenlik görünüşle kanıtlanmaz. Kontrollü erişim, gözden geçirilmiş uyarılar, test edilmiş kurtarma, sınırlı satıcı ayrıcalıkları, mevcut sistemler ve bir şeyler ters gittiğinde ne yapacağını bilen personel aracılığıyla gösterilir. Bir uyarı işareti bulursam tüm veri merkezinin arızalandığını varsaymıyorum. İlgili kontrolleri kontrol etmek için bunu bir bilgi istemi olarak kullanıyorum. Eski bir hesap, zayıf ayrılmaya işaret edebilir. Test edilmemiş bir yedekleme, belirsiz hizmet sahipliğine işaret edebilir. Sessiz bir uyarı kuyruğu, kağıt üzerinde var olan ancak pratikte olmayan bir izleme sürecine işaret edebilir. Yararlı bir güvenlik incelemesinin başladığı yer burasıdır: kanıtlarla, açık sorularla ve ekibin izleyebileceği eylemlerle.

Bir veri merkezini değerlendirirken gösterişli fotoğraflarla, uzun bir sertifika listesiyle veya mükemmel çalışma süresi vaadiyle başlamıyorum. Rakamlarla başlıyorum. Kesintiler ne sıklıkta meydana geldi? İyileşme ne kadar sürdü? Aynı olay sırasında kaç sistem arızalandı? Yedeklemeler başka bir yerde mi saklanıyordu? Ekip tek bir tedarikçiyi beklemeden müşteri verilerini geri yükleyebilir mi? Bu sorular bir satış broşüründen daha fazlasını ortaya koyuyor. ### Kesinti verileri bana ne söylüyor? Uptime Institute'un yıllık kesinti araştırması, veri merkezi kesintilerinin ciddi mali baskı yaratabileceğini gösterdi. 2024 analizi, ankete katılanların %54'ünün, en son kesintilerin doğrudan ve dolaylı olarak en az 100.000 ABD doları tutarında kayba neden olduğunu söylediğini bildirdi. Daha küçük bir grup ise 1 milyon doların üzerinde zarar bildirdi. Bu rakam her veri merkezinin aynı seviyede risk taşıdığı anlamına gelmiyor. Çalışma süresinin neden yalnızca ekipman etiketleri aracılığıyla değil, test edilen süreçler aracılığıyla ölçülmesi gerektiğini gösterir. Kesintinin nedeni de önemlidir. Elektrik kesintisi, soğutma sorunları, yazılım hataları, ağ sorunları, insan hataları ve aşırı hava koşulları aynı tesisi farklı şekillerde etkileyebilir. Bir tesiste yedek jeneratörler bulunabilir ve bir kontrol sistemi arızalandığında veya bir bakım görevi yanlış yapıldığında yine de kesinti yaşanabilir. Dört soruya bakıyorum: - Ne başarısız olabilir? - Başarısız olduğunda ne olur? - Ekip ne kadar hızlı yanıt verebilir? - Kurtarma planı baskı altında test edildi mi? ### Fiziksel güvenlik resmin yalnızca bir kısmıdır Birçok kişi, veri merkezi güvenliğinin ana işareti olarak fiziksel erişim kontrollerini kullanır. Kameraların, korumaların, kilitli kafeslerin, ziyaretçi kayıtlarının ve yaka kartı sistemlerinin hepsinin bir rolü var. Verileri tek başlarına korumazlar. Güvenli bir tesis, ortak alanları, personel alanlarını, ekipman odalarını ve müşteri bölgelerini ayırmalıdır. Erişim iş görevlerini takip etmelidir. Soğutma ekipmanı üzerinde çalışan bir yüklenicinin sunucu raflarına erişmesi gerekmeyebilir. Bir ziyaretçi, yanında refakatçi veya kayıtlı bir amaç olmadan bina içerisinden geçmemelidir. Ayrıca erişim kayıtlarının incelenip incelenmediğini de kontrol ediyorum. Yaka kartı sistemi kayıtlar oluşturur, ancak bu kayıtlar yalnızca tesiste olağandışı etkinliklerin kontrol edilmesine yönelik bir süreç olduğunda yardımcı olur. Pratik bir inceleme şunları içerebilir: 1. Ziyaretçi erişiminin nasıl onaylandığını ve kaydedildiğini sorun. 2. Kayıp rozetlerin gecikmeden devre dışı bırakılıp bırakılmadığını kontrol edin. 3. Girişler, yükleme alanları ve ekipman odaları etrafındaki kamera kapsamını inceleyin. 4. Müşteri kafeslerinin ve ortak alanların ayrı kontrollere sahip olduğunu doğrulayın. 5. Rol değişikliği veya görevden ayrılma sonrasında personel erişiminin nasıl kaldırıldığını sorun. Bu yaklaşım yalnızca kurulu donanıma değil, günlük kullanıma da odaklanır. ### Güç ve soğutma ayrı katmanlara ihtiyaç duyar Güç koruması genellikle soğutmadan daha fazla dikkat çeker, ancak sunucular her ikisine de ihtiyaç duyar. Bir tesis şebeke elektriğini, kesintisiz güç kaynaklarını, jeneratörleri, transfer anahtarlarını ve ayrı güç yollarını kullanabilir. Tasarım kağıt üzerinde güçlü görünebilir. Asıl soru bu sistemlerin birlikte test edilip edilmediğidir. Şunların kanıtını istiyorum: - Jeneratör yük testi - Yakıt planlaması - Akü değiştirme kayıtları - Transfer anahtarı testi - Bakım programları - Bağımsız güç yolları - Bir güç olayı sırasında soğutma kapasitesi Soğutma riski çeşitli şekillerde ortaya çıkabilir. Arızalı bir soğutucu, engellenen hava akışı, su sızıntısı veya sensör hatası oda sıcaklıklarını yükseltebilir. Müdahale planı, uyarıyı kimin alacağını, yükü azaltma kararını kimin vereceğini ve gerektiğinde hizmetlerin nasıl taşınacağını tanımlamalıdır. Sıcaklık verilerini raporlayan ancak net bir yanıt süreci olmayan bir tesisin hâlâ bir açığı var. ### Yedekleme, kurtarma ile aynı şey değildir Ekiplerin, sanki tek bir cümle tüm kurtarma sorusunu yanıtlıyormuş gibi "Verilerimiz yedeklendi" dediğini gördüm. Değil. Yedekleme eksik, hasarlı, güncelliğini kaybetmiş olabilir veya orijinal sisteme çok yakın bir yerde saklanmış olabilir. Bir kurtarma planı, verilerin ve uygulamaların hizmete nasıl döndüğünü göstermelidir. Şu soruları sorun: - Yedeklemeler ne sıklıkla oluşturulur? - Yedek kopyalar başka bir yerde mi saklanıyor? - Yedeklemeler yetkisiz değişikliklere karşı korunuyor mu? - Tam geri yükleme ne kadar sürer? - İlk önce hangi sistemler geri yüklenir? - Son geri yükleme testi ne zamandı? - Test uygulama verilerini, kullanıcı erişimini ve ağ ayarlarını içeriyor mu? OVHcloud'un Strasbourg tesisinde 2021'de yaşanan yangın, konum ve yedekleme tasarımının neden önemli olduğunu gösterdi. Olayla ilgili kamuya açık raporlara göre birçok veri merkezi etkilendi ve ayrı yedekleme düzenlemeleri olmayan müşteriler veri kaybıyla veya uzun süreli hizmet kesintisiyle karşı karşıya kaldı. Ders basit: Aynı binadaki bir yedekleme, bina kullanılamadığında işe yaramayabilir. ### Artıklık tasarımda görünür olmalıdır N+1, 2N ve çoklu kullanılabilirlik bölgeleri gibi terimler, yararlı tasarım seçeneklerini açıklayabilir. Basit cevapların yerini almamalıdırlar. Bir soğutma ünitesi arızalanırsa kalan üniteler yükü taşıyabilir mi? Güç yollarından biri bakım altındaysa tesis çalışmaya devam edebilir mi? Şebeke operatöründe kesinti olması durumunda trafik başka bir rotayı kullanabilir mi? Bir veri merkezi çevrimdışıysa uygulamalar başka bir konumdan çalıştırılabilir mi? Her hizmeti bağımlılığıyla eşleştirmeyi tercih ederim. Bir veritabanı depolama, güç, soğutma, ağ bağlantıları, kimlik hizmetleri ve personel erişimine bağlı olabilir. Artıklık yalnızca bu bağımlılıklar aynı hata noktasını paylaşmadığında faydalıdır. Aynı anahtara bağlı iki sistem tamamen bağımsız değildir. Aynı yakıt sistemi tarafından beslenen iki yedek jeneratör aynı riski paylaşabilir. Aynı taşkın bölgesindeki iki alan coğrafi koruma sağlayamayabilir. ### İnsanlar ve prosedürler sonucu etkiler Çoğu olay rutin bir görevle başlar: yazılım değişikliği, bakım eylemi, kablo değişimi veya yapılandırma güncellemesi. Güçlü bir veri merkezi programı, personele net değişiklik kontrolleri sağlar. Ayrıca bir görev gücü, soğutmayı, ağ bağlantılarını veya müşteri ekipmanını etkilediğinde incelemeye yer açar. Şunları ararım: - Yazılı bakım prosedürleri - Sistem değişiklikleri için onay kayıtları - Açık yükseltme yolları - Personel eğitimi - Tedarikçi iletişim planları - Olay incelemeleri - Kurtarma egzersizleri Bir test kanıt üretmelidir. Neyin işe yaradığını, neyin başarısız olduğunu, her adımın ne kadar sürdüğünü ve hangi eylemlerin revizyona ihtiyacı olduğunu göstermelidir. Test edilmemiş bir belge, hazır olduğunun kanıtı değil, bir plandır. ### Sağlayıcıları karşılaştırmanın basit bir yolu Veri merkezlerini karşılaştırdığımda bilgileri küçük bir tabloya yerleştiririm: | Alan | Soru | Kanıt | |---|---|---| | Güç | Tesis bir elektrik kesintisi sırasında çalışabilir mi? | Test kayıtları ve bakım günlükleri | | Soğutma | Bir soğutma ünitesi durursa ne olur? | Kapasite planı ve olay prosedürü | | Ağ | Ayrı taşıyıcılar veya rotalar var mı? | Ağ şeması | | Yedekleme | Yedek kopyalar nerede saklanıyor? | Yedekleme politikası ve geri yükleme raporu | | Erişim | Müşteri alanlarına kimler girebilir? | Politika ve denetim kayıtlarına erişim | | Kurtarma | Restorasyon ne kadar sürer? | Test sonuçları ve kurtarma hedefleri | | Operasyonlar | Değişiklikler nasıl onaylanır? | Kayıtları değiştirme ve süreci inceleme | Bu format tartışmanın odaklanmasını sağlar. Ayrıca eksik bilgilerin belirlenmesini kolaylaştırır. Hiçbir veri merkezi her riski ortadan kaldıramaz. Daha iyi bir hedef ise riskleri anlamak, ortak başarısızlık noktalarını azaltmak, yanıtı test etmek ve sonuçları sade bir dille raporlamaktır. En güvenli seçim her zaman en uzun özellik listesine sahip tesis değildir. Güç düştüğünde, soğutma başarısız olduğunda, ağ yolu kesildiğinde, personel hata yaptığında veya yerel bir olay siteyi çevrimdışı duruma getirdiğinde sistemlerinin nasıl tepki verdiğini gösterebilen yazılımdır. Daha fazlasını mı öğrenmek istiyorsunuz? Yonglin Wang ile iletişime geçmekten çekinmeyin: 13382583527@gmail.com/WhatsApp +8613382583527.

Uptime Institute 2024 Yıllık Kesinti Analizi 2024 Yıllık Kesinti Analizi Verizon 2024 Veri İhlali Araştırmaları Raporu 2024 Veri İhlali Araştırmaları Raporu IBM Security 2024 Veri İhlalinin Maliyeti Raporu 2024 Veri İhlalinin Maliyeti Raporu Facebook Mühendislik 4 Ekim 2021 Bugünkü Kesintiyle İlgili Daha Fazla Ayrıntı OVHcloud 10 Mart 2021 Strasbourg Veri Merkezi Yangın Olayı Raporu Aon 2023 Siber Risk Analizleri Raporu 2023 Siber Risk Analizleri Raporu