Sunucu Kayıtları (Log) Yönetimi

Sunucu kayıtları, bir sorun ya da güvenlik olayı yaşandığında elinizdeki tek kanıt kaynağıdır. Toplanmadıklarında, olay sonrası "ne oldu?" sorusu cevapsız kalır.

A. Neden kayıt tutulur?

• ☐ Sorun tanısı (ne zaman, ne oldu?)
• ☐ Güvenlik olayı incelemesi
• ☐ Performans analizi
• ☐ Kapasite planlaması
• ☐ Denetim ve uyum
• ☐ Değişiklik takibi
• ☐ Kullanım istatistikleri

B. Hangi kayıtlar toplanmalı?

• ☐ Sistem kayıtları (işletim sistemi olayları)
• ☐ Kimlik doğrulama kayıtları (girişler, başarısız denemeler)
• ☐ Web sunucusu erişim kayıtları
• ☐ Uygulama hata kayıtları
• ☐ Veritabanı kayıtları (yavaş sorgular, hatalar)
• ☐ Güvenlik duvarı kayıtları
• ☐ Yedekleme kayıtları
• ☐ Zamanlanmış görev kayıtları
• ☐ Yetki yükseltme kayıtları

İkinci ve dokuzuncu maddeler güvenlik açısından en değerli olanlardır.

C. Merkezî toplama

• ☐ Kayıtlar merkezî bir yere gönderiliyor
• ☐ Merkezî sistem, kaynak sunuculardan bağımsız
• ☐ Aktarım güvenli
• ☐ Tüm sunucular kapsamda
• ☐ Yeni sunucular otomatik ekleniyor

İkinci madde kritiktir: Bir sunucu ele geçirildiğinde saldırganın ilk işlerinden biri kayıtları silmektir. Merkezî toplama, kanıtı korur.

D. Saklama

• ☐ Saklama süresi belirlendi
• ☐ Mevzuat gereksinimleri kontrol edildi
• ☐ Depolama kapasitesi yeterli
• ☐ Kayıt döndürme yapılandırıldı
• ☐ Eski kayıtlar arşivleniyor ya da siliniyor
• ☐ Kayıtlar yedekleniyor

Denge: Uzun saklama, olay incelemesinde değerlidir ama depolama maliyeti getirir ve kişisel veri içerebilir.

E. Kişisel veri boyutu

• ☐ Kayıtlarda hangi kişisel veriler var, belirlendi
• ☐ Saklama süresi bu açıdan da değerlendirildi
• ☐ Erişim yetkisi sınırlı
• ☐ Veri envanterine dahil edildi

Sunucu kayıtları IP adresi ve gezinme bilgisi içerir; bunlar kişisel veri kapsamında değerlendirilebilir.

F. Erişim kontrolü

• ☐ Kayıtlara kimlerin erişebileceği tanımlı
• ☐ Değiştirilemez biçimde saklanıyor
• ☐ Kayıtlara erişim de kayıt altında
• ☐ Silme yetkisi çok sınırlı

G. İnceleme

• ☐ Düzenli inceleme rutini var
• ☐ Arama yapılabiliyor
• ☐ Anormallikler için uyarı tanımlı
• ☐ Başarısız giriş denemeleri izleniyor
• ☐ Hata artışları fark ediliyor
• ☐ Zaman damgaları senkronize

Son madde önemlidir: Farklı sunucuların saatleri senkronize değilse, bir olayın sıralamasını çıkarmak imkânsızlaşır.

H. Uyarı üretilecek durumlar

• ☐ Tekrarlayan başarısız giriş denemeleri
• ☐ Yeni yönetici hesabı oluşturulması
• ☐ Yetki yükseltme
• ☐ Beklenmedik saatlerde erişim
• ☐ Kritik hata artışı
• ☐ Yedekleme başarısızlığı
• ☐ Kayıt tutmanın durması

Son madde ince bir noktadır: kayıtların aniden kesilmesi, bir müdahalenin işareti olabilir.

I. Sorun tanısında kullanım

Bir olay yaşandığında kayıtlar şu soruları cevaplar:

• Ne zaman başladı?
• O sırada ne çalışıyordu?
• Hangi hata mesajları üretildi?
• Kim ne yaptı?
• Nereden bağlanıldı?
• Öncesinde bir değişiklik oldu mu?

Kayıt yoksa bu soruların hiçbiri cevaplanamaz.

J. Sağlayıcıdan talep edilecekler

• ☐ Kayıtlara erişim veriliyor mu?
• ☐ İndirilebiliyor mu?
• ☐ Ne kadar saklanıyor?
• ☐ Sağlayıcının kendi erişim kayıtları paylaşılıyor mu?

Yönetilen hizmet ya da bulut kullanıyorsanız, bu sorular alım aşamasında sorulmalıdır.

K. Gürültü yönetimi

• ☐ Ayrıntı düzeyi makul (çok az da çok fazla da sorun)
• ☐ Rutin bilgi mesajları ayrı tutuluyor
• ☐ Gerçek hatalar öne çıkıyor
• ☐ Depolama kapasitesi kontrol altında

Aşırı ayrıntılı kayıt hem depolama hem de inceleme sorunudur.

Asgari kayıt yönetimi

Kaynağınız kısıtlıysa şu dördü kritik değeri sağlar:

1. Kimlik doğrulama kayıtları toplanıyor
2. Uygulama hata kayıtları toplanıyor
3. Kayıtlar merkezî ve sunucudan bağımsız bir yerde
4. Zaman damgaları senkronize

Bu dördü, bir olay incelemesinin temelini oluşturur.