KOBİ'lerde Sık Yaşanan 5 BT Krizi ve Çözüm Senaryoları

Her işletme bir gün beklenmedik bir BT kriziyle karşılaşır. Çoğu zaman bunlar 'bize olmaz' diye düşünülse de küçük bir hatanın veya ihmalin işleri tamamen durdurabileceği anlar yaşanabilir. Bu yazıda KOBİ'lerde en sık görülen beş BT krizi ve bu krizlerin nasıl çözüldüğü adım adım anlatılıyor. Amacımız, yaşanmış senaryolardan dersler çıkararak kendi işletmenizi olası sorunlara karşı daha hazırlıklı hale getirmeniz.

1. Fidye Yazılımı Saldırısı Sonrası Yedekten Geri Dönüş Krizi

İşletme profili: 18 kişilik bir mimarlık ofisi, şehir merkezinde faaliyet gösteriyor ve tüm proje dosyalarını merkezi bir sunucuda saklıyor.

Yaşanan sorun: Pazartesi sabahı çalışanlardan biri, müşteriden geldiğini sandığı bir e-postadaki ZIP dosyasını açtı. Birkaç saat içinde tüm sunucudaki proje dosyaları şifrelendi ve ekranda fidye talebi belirdi. Ofisteki tüm CAD dosyaları, render görselleri ve müşteri arşivi erişilemez hale geldi.

Kök neden: Antivirüs yazılımı güncel değildi ve e-posta ekleri otomatik olarak taranmıyordu. Ayrıca yedekleme sistemi aynı sunucuya bağlı harici bir diske yapılıyordu — fidye yazılımı bu yedekleri de şifreledi. Çevrimdışı veya bulut tabanlı bir yedek yoktu.

Uygulanan çözüm adımları:

1. İlk olarak etkilenen bilgisayar ve sunucu ağdan tamamen izole edildi, fidye yazılımının başka cihazlara yayılması engellendi.
2. Antivirüs yazılımı güncellenip tam tarama yapıldı, zararlı yazılım karantinaya alındı.
3. Şanslı bir şekilde, iki hafta önce bir çalışanın kendi inisiyatifiyle aldığı harici disk yedekleri ofiste saklanıyordu. Bu yedek, enfeksiyon öncesi temiz dosyaları içeriyordu.
4. Sunucu işletim sistemi ve veri bölümü sıfırdan kuruldu, güvenlik yamaları uygulandı.
5. Temiz yedekten dosyalar geri yüklendi; toplam geri dönüş süresi yaklaşık iki gün sürdü.
6. İki günlük veri kaybı yaşandı ama kritik projeler kurtarıldı.

Sonuç: Ofis iki gün boyunca kısmi olarak çalışamadı ama fidye ödenmeden veriler kurtarıldı. İki haftalık yedek olmasaydı, tüm proje arşivi kaybolabilirdi.

Diğer işletmeler için ders: Yedekleme sisteminizi mutlaka 3-2-1 kuralına göre planlayın: en az üç kopya, iki farklı ortamda (örneğin yerel disk ve bulut), biri tamamen çevrimdışı. Yedekleri düzenli test edin ve antivirüs yazılımınızı her zaman güncel tutun. E-posta eklerine karşı çalışanlarınızı eğitin.

2. İşten Ayrılan Çalışanın Hesabının Açık Kalması

İşletme profili: 22 kişilik bir lojistik firması, nakliye ve depolama hizmeti veriyor.

Yaşanan sorun: Üç ay önce işten ayrılan eski muhasebe sorumlusunun şirket e-posta hesabı ve ERP sistemine erişimi hâlâ açıktı. Bir gün bu eski çalışan, kendi şifresini kullanarak sisteme giriş yaptı ve bazı müşteri verilerini kişisel e-posta adresine iletti. Durum, bir müşteriden gelen şikayet sonrası ortaya çıktı.

Kök neden: İnsan kaynakları ile BT ekibi arasında koordinasyon eksikliği vardı. Çalışan ayrılırken sadece dosya devri yapılmış, hesap kapatma adımları unutulmuştu. Standart bir 'çalışan çıkış prosedürü' mevcut değildi.

Uygulanan çözüm adımları:

1. Eski çalışanın tüm dijital erişimleri anında kapatıldı: e-posta, ERP, bulut dosyaları, VPN bağlantısı.
2. Şifre kurtarma seçenekleri (kişisel telefon numarası, alternatif e-posta) hesaptan kaldırıldı.
3. Tüm aktif oturumlar zorla sonlandırıldı, eski şifre iptal edildi.
4. Şirket avukatı ile görüşülerek eski çalışana resmi ihtarname gönderildi, veri ihlali sebebiyle yasal süreç başlatıldı.
5. Müşterilere durum açıklandı ve veri güvenliği konusunda bilgilendirme yapıldı.
6. İnsan Kaynakları ve BT departmanı işbirliğiyle 'çalışan ayrılış kontrol listesi' (offboarding checklist) hazırlandı ve her ayrılışta uygulanmaya başlandı.

Sonuç: Veri ihlali sınırlı kaldı ama şirketin itibarı zarar gördü. Müşteri güveni yeniden kazanılması zaman aldı. Yasal süreç devam ediyor.

Diğer işletmeler için ders: Bir çalışan ayrıldığı gün tüm erişimleri mutlaka kapatılmalı. Sadece e-posta değil, ERP, CRM, sosyal medya, bulut depolama, VPN, uzak masaüstü gibi tüm platformlar listelenip tek tek kontrol edilmeli. Ayrılış sürecini İK ve BT birlikte yönetmeli, yazılı bir kontrol listesi kullanılmalı.

3. Tek Sunucu Diskinin Arızalanması ve Veri Kaybı

İşletme profili: 12 kişilik bir muhasebe ofisi, müşteri mali kayıtlarını tek bir sunucuda tutuyor.

Yaşanan sorun: Çarşamba öğleden sonra sunucu aniden yavaşladı ve kısa süre sonra tamamen kapandı. Tekrar açıldığında disk hatası verdi ve işletim sistemi açılmadı. Sunucuda yalnızca tek bir hard disk vardı ve bu disk fiziksel olarak arızalanmıştı. Müşterilere ait tüm mali kayıtlar, beyannameler ve e-fatura arşivi bu diskteydi.

Kök neden: Sunucu RAID yapılandırması olmadan tek diskle çalışıyordu. Disk arızası durumunda yedeklilik sağlayacak ikinci bir disk yoktu. Ayrıca düzenli yedekleme rutini eksikti; son yedek altı ay öncesine aitti ve dış bir hard diskte saklanıyordu.

Uygulanan çözüm adımları:

1. Arızalı disk çıkarıldı ve profesyonel veri kurtarma firmasına gönderildi.
2. Veri kurtarma süreci dört gün sürdü; diskteki verilerin büyük kısmı kurtarıldı ancak bazı bozuk dosyalar onarılamadı.
3. Altı aylık eski yedekten bir kısım veri geri yüklendi, kurtarılan yeni verilerle birleştirildi.
4. Yeni bir sunucu temin edildi, bu kez RAID 1 (disk yansıtma) yapılandırmasıyla kuruldu; bir disk arızalansa bile ikincisi çalışmaya devam edecek şekilde.
5. Günlük otomatik yedekleme sistemi kuruldu: yerel NAS cihazına ve bulut depolamaya çift yönlü yedekleme.
6. Altı aylık veri boşluğu manuel olarak yeniden girildi; bu süreçte çalışanlar fazla mesai yaptı.

Sonuç: Veri kurtarma maliyeti yüksek oldu ve ofis dört gün boyunca tam kapasiteyle çalışamadı. Altı aylık veri boşluğu kapanana kadar yaklaşık iki hafta ek iş yükü oluştu.

Diğer işletmeler için ders: Kritik verileri tek bir diske asla güvenmeyin. RAID 1 veya RAID 5 gibi yedekli disk yapılandırmaları kullanın. Mutlaka günlük veya haftalık otomatik yedekleme yapın ve yedeklerin çalışıp çalışmadığını düzenli test edin. Yedekleme yalnızca 'bir kere aldım' değil, sürekli bir rutin olmalıdır.

4. Sahte Fatura E-postası ile Ödeme Dolandırıcılığı

İşletme profili: 25 kişilik bir mobilya imalat firması, tedarikçilere düzenli ödemeler yapıyor.

Yaşanan sorun: Muhasebe görevlisi, uzun süredir çalıştıkları bir tedarikçiden geldiğini sandığı bir e-posta aldı. E-postada 'Banka hesabımızı değiştirdik, bundan sonra ödemeleri yeni IBAN'a yapın' yazıyordu ve profesyonel görünümlü bir fatura eki vardı. Görevli doğrulama yapmadan yeni hesaba ödeme yaptı. İki gün sonra gerçek tedarikçi arayıp ödemeyi almadıklarını söyleyince dolandırıcılık anlaşıldı.

Kök neden: E-posta adresi gerçek tedarikçinin adresine çok benziyordu (örneğin bir harf farkıyla). Çalışan, gönderen adresini dikkatle kontrol etmedi. Banka hesabı değişikliği gibi kritik durumlarda telefon ile doğrulama yapma prosedürü yoktu.

Uygulanan çözüm adımları:

1. Durum anında bankaya ve polise bildirildi; ancak para zaten başka hesaplara aktarılmıştı, geri alınamadı.
2. Gerçek tedarikçiye durum açıklandı ve geciken ödeme hemen yapıldı.
3. Tüm finans ekibi acil olarak 'oltalama saldırıları' (phishing) konusunda eğitim aldı.
4. Yeni bir prosedür uygulandı: IBAN değişikliği, yeni tedarikçi ekleme veya büyük tutarlı ödeme talepleri mutlaka telefon ile doğrulanacak — e-postadaki numarayı değil, daha önce kayıtlı olan resmi numarayı arayarak.
5. E-posta sistemine gelişmiş spam ve phishing filtresi eklendi.
6. Çalışanlara 'gönderen adresini dikkatle kontrol et' rehberi dağıtıldı; alan adı farklılıklarını fark etmeleri için örnekler gösterildi.

Sonuç: Firma büyük bir mali kayıp yaşadı ve bu meblağ geri alınamadı. Ancak yeni prosedürler sayesinde benzer bir olay bir daha yaşanmadı.

Diğer işletmeler için ders: Banka hesabı veya ödeme talimatı değişikliklerini asla sadece e-posta ile kabul etmeyin. Mutlaka telefon veya yüz yüze görüşme ile doğrulayın. Gönderen e-posta adresini tam olarak kontrol edin; sahte adresler genellikle bir veya iki harf farkıyla gelir. Çalışanlarınızı düzenli olarak siber güvenlik konusunda eğitin.

5. Lisanssız Yazılım Denetimi ve Yüksek Ceza

İşletme profili: 30 kişilik bir reklam ajansı, grafik tasarım ve içerik üretimi yapıyor.

Yaşanan sorun: Ajansa, bir yazılım firması adına çalışan lisans denetim şirketi ziyaret bildirimi gönderdi. Denetim sırasında birçok bilgisayarda lisanssız tasarım yazılımı, ofis uygulaması ve işletim sistemi kullanıldığı tespit edildi. Bazı yazılımlar internetten indirilmiş 'crack' sürümlerdi. Denetim sonucunda yüksek meblağlı bir idari ceza ve lisans satın alma zorunluluğu getirildi.

Kök neden: Şirket hızla büyümüş ama yazılım lisansları düzenli takip edilmemişti. Yeni bilgisayarlar alındığında 'geçici olarak' lisanssız yazılım kurulmuş, sonra unutulmuştu. BT sorumlusu lisans envanterini güncel tutmuyordu.

Uygulanan çözüm adımları:

1. Denetim raporuna göre eksik olan tüm lisanslar satın alındı; bu büyük bir ek bütçe gerektirdi.
2. Tüm bilgisayarlardan lisanssız yazılımlar kaldırıldı ve yasal lisanslar kuruldu.
3. Yazılım lisans envanteri oluşturuldu: hangi bilgisayarda hangi yazılımın hangi lisansla çalıştığı Excel tablosuna kaydedildi.
4. Yeni çalışan alındığında veya bilgisayar değiştiğinde lisans atama prosedürü belirlendi.
5. Abonelik bazlı (subscription) yazılım modeline geçildi; böylece lisans sayısı kolayca artırılıp azaltılabiliyor ve denetim daha kolay hale geldi.
6. Çalışanlara telif hakları ve lisanssız yazılım kullanımının yasal sonuçları hakkında bilgilendirme yapıldı.

Sonuç: Ceza ve eksik lisans maliyeti toplamda ciddi bir meblağa ulaştı. Ancak süreç sonunda ajans tamamen yasal bir altyapıya kavuştu ve gelecekte benzer risklerden korunmuş oldu.

Diğer işletmeler için ders: Yazılım lisanslarınızı düzenli olarak takip edin. Kaç bilgisayarınız var, hangi yazılımları kullanıyorsunuz, kaç lisansınız var — bunları bir listede tutun. Lisanssız yazılım kullanmak hem yasal sorun hem de güvenlik açığı yaratır. Mümkünse abonelik modelini tercih edin, yönetimi kolaylaştırır.

Bu beş senaryo, KOBİ'lerde en sık karşılaşılan BT krizlerini özetliyor. Tüm bu durumların ortak noktası: önlem almak, krizi çözmekten çok daha ucuz ve kolay. Düzenli yedekleme, güvenlik eğitimi, yazılı prosedürler ve donanım yedekliliği gibi basit adımlar, işletmenizi büyük kayıplardan koruyabilir. Eğer kendi BT altyapınızda bu tür riskleri görüyorsanız, profesyonel bir değerlendirme yaptırmak ve eksikleri kapatmak için zaman ayırın.

Eğer işletmenizde BT güvenliği, yedekleme stratejisi veya donanım altyapısı konusunda destek almak isterseniz, Sprint Teknoloji olarak Kağıthane merkezli hizmet veriyoruz. Proaktif bakım planları ve acil müdahale desteğimiz hakkında bilgi almak için iletişime geçebilirsiniz.