Sunucu çöktü ve nedenini anlamak için günlüklere bakmanız gerekiyor. Ama günlükler o sunucunun diskinde ve sunucu açılmıyor. Ya da daha kötüsü: sunucu ele geçirildi ve saldırgan izlerini sildi.
Bu yazı, günlükleri merkezî bir sunucuda toplamayı ele alıyor.
Neden Merkezîleştirmeli?
- Sunucu çökse de kayıtlar durur.
- Saldırgan izlerini silemez.
- Birden fazla sunucu birlikte incelenir.
- Disk dolması sorunu azalır.
- Arama tek yerden yapılır.
İkinci madde güvenlik açısından belirleyicidir: bir sunucuyu ele geçiren saldırganın ilk işlerinden biri yerel günlükleri temizlemektir — kayıtlar başka bir sunucuya anlık gönderiliyorsa o silme işe yaramaz.
Bu, olay sonrası incelemenin mümkün olmasını sağlayan tek şey olabilir.
Üçüncü madde ise çok sunuculu ortamlarda teşhis süresini kısaltır. Bir isteğin hangi sunucuda ne yaptığını tek aramayla görürsünüz.
Temel Mimari
| Bileşen | İşlevi |
|---|---|
| Gönderici | Kayıtları iletir |
| Toplayıcı | Alır ve saklar |
| Depolama | Kalıcı tutar |
| Arayüz | Arama ve görüntüleme |
Basit kurulumlarda ilk üçü tek bir sunucuda birleşebilir. Ölçek büyüdükçe ayrışırlar.
Önemli bir tasarım kararı vardır: gönderici, kayıtları yerel diske de yazmaya devam etmelidir — merkezî sunucu erişilemez olduğunda kayıtların tamamen kaybolmaması için bu ikili yazma gereklidir.
Yalnızca uzağa göndermek, ağ kesintisinde tüm kayıtları kaybettirir.
Yerel kopya kısa süreli tutulabilir; merkezî kopya uzun süreli saklanır.
İletim Protokolü
Seçim güvenilirlik ile basitlik arasındadır:
- Bağlantısız iletim. Basit ama kayıp olabilir.
- Bağlantılı iletim. Güvenilir, biraz ağır.
- Şifreli iletim. Güvenli, önerilen.
Birinci seçenek varsayılan olabilir ve sessiz kayıplara yol açar: bağlantısız iletimde ağ yoğunlaştığında kayıtlar hiçbir uyarı vermeden düşürülür — günlüklerinizde boşluklar oluşur ve bunu fark etmezsiniz.
Kritik güvenlik kayıtları için bu kabul edilemez.
Üçüncü seçenek ise gizlilik sağlar. Günlükler kullanıcı adları, adresler ve bazen hassas bilgi içerir.
Bu trafiğin ağda düz metin akması, gereksiz bir sızıntı yüzeyi oluşturur.
Ne Gönderilmeli?
| Kaynak | Öncelik |
|---|---|
| Kimlik doğrulama kayıtları | Yüksek |
| Sistem hataları | Yüksek |
| Web erişim günlükleri | Orta, hacimli |
| Uygulama günlükleri | Yüksek |
| Hata ayıklama çıktısı | Gönderilmemeli |
Beşinci satır önemli bir sınırdır: hata ayıklama seviyesindeki kayıtları merkezî sisteme göndermek, depolamayı hızla doldurur ve gerçekten önemli kayıtları görünmez hâle getirir.
Bu seviye yalnızca sorun araştırılırken geçici olarak açılmalıdır.
Üçüncü satır ise hacim açısından dikkat gerektirir. Yoğun bir sitede erişim günlükleri günde gigabaytlarca yer kaplar.
Bu kayıtlar için daha kısa saklama süresi tanımlanabilir.
Saklama Politikası
- Tür bazında süre tanımlayın.
- Güvenlik kayıtlarını uzun tutun.
- Erişim günlüklerini kısa tutun.
- Yasal gereklilikleri kontrol edin.
- Eski kayıtları sıkıştırın.
Beşinci madde depolama maliyetini dramatik biçimde düşürür: metin tabanlı günlük dosyaları çok yüksek oranda sıkışır — eski kayıtları sıkıştırmak, aynı diskte kat kat daha uzun geçmiş saklamanızı sağlar.
Arama hızı bir miktar düşer ama eski kayıtlarda bu kabul edilebilir.
Dördüncü madde ise sektöre göre değişir ve bazı kayıtlar için asgari saklama süresi zorunlu olabilir.
İkinci madde ise olay incelemesi içindir. Bir ihlal aylar sonra fark edilebilir ve o dönemin kayıtları gerekir.
Kayıt Bütünlüğü
Merkezî sunucu da hedef olabilir:
- Yalnızca yazma izni verin.
- Silme yetkisini kısıtlayın.
- Değiştirilemez depolama düşünün.
- Erişimi ayrı yönetin.
Dördüncü madde kritik bir ayrımdır: günlük sunucusuna erişim, diğer sunuculardaki kimlik bilgileriyle sağlanmamalıdır — bir sunucu ele geçirildiğinde saldırgan aynı kimlikle günlük sunucusuna da ulaşabilmemelidir.
Bu, merkezîleştirmenin sağladığı korumayı korumak için gereklidir.
Üçüncü madde ise en güçlü garantidir. Yazıldıktan sonra değiştirilemeyen bir depolama, kayıtların güvenilirliğini kanıtlar.
Bu, hukuki süreçlerde delil değeri açısından da önemlidir.
Zaman Damgası Sorunu
| Sorun | Önlem |
|---|---|
| Sunucu saatleri farklı | Zaman senkronizasyonu şart |
| Saat dilimleri karışık | Hepsi evrensel zamanda |
| Alım zamanı ile olay zamanı | İkisini de saklayın |
Birinci satır merkezîleştirmenin en temel gereksinimidir: sunucu saatleri senkron değilse birleştirilmiş günlüklerde olaylar yanlış sırayla görünür ve neden-sonuç ilişkisi tamamen ters çıkabilir.
Bir olayın nedenini ararken, sonucun nedenden önce göründüğü bir listeyle karşılaşırsınız.
Üçüncü satır ise gecikmeleri ortaya çıkarır. İki zaman arasındaki büyük fark, iletim sorununu gösterir.
İkinci satır ise farklı lokasyonlardaki sunucularda zorunludur.
Sunucuyu Boyutlandırmak
- Günlük hacmi ölçün.
- Saklama süresiyle çarpın.
- Sıkıştırma oranını hesaba katın.
- Büyüme payı bırakın.
Dördüncü madde sık atlanır ve sorun üretir: günlük hacmi trafikle birlikte büyür ve yeni sunucular eklendikçe katlanır — bugünkü hacme göre boyutlandırılmış bir günlük sunucusu birkaç ay içinde dolar.
Disk dolduğunda kayıt alımı durur ve merkezîleştirmenin tüm faydası kaybolur.
Bu nedenle günlük sunucusunun disk doluluğu da izlenmeli ve alarm kurulmalıdır.
Birinci madde ise gerçek verilerle yapılmalıdır; tahmin genellikle düşük çıkar.
Merkezî günlük sunucusu için ayrı bir makine ve yeterli disk gerekir; fiziksel sunucu altyapı çözümleri içinde yüksek kapasiteli depolamaya sahip bir sunucu bu iş için uygundur.
Sonuç
Merkezî günlük toplamanın en güçlü gerekçesi güvenliktir: bir sunucuyu ele geçiren saldırganın ilk işlerinden biri yerel günlükleri temizlemektir — kayıtlar anlık olarak başka bir sunucuya gönderiliyorsa o silme işe yaramaz. Ama iki noktayı atlamayın. Bağlantısız iletim kullanırsanız ağ yoğunlaştığında kayıtlar hiçbir uyarı vermeden düşürülür ve günlüklerinizde fark etmediğiniz boşluklar oluşur. Ve sunucu saatlerini senkronize edin; yoksa olaylar yanlış sırayla görünür.
Sıkça Sorulan Sorular (SSS)
Yerel günlükler neden yetmiyor?
İki nedenle. Sunucu çöktüğünde veya açılmadığında o kayıtlara ulaşamazsınız. Daha önemlisi güvenliktir: bir sunucuyu ele geçiren saldırganın ilk işlerinden biri yerel günlükleri temizlemektir; kayıtlar anlık olarak başka bir sunucuya gönderiliyorsa o silme işe yaramaz.
Hangi iletim yöntemini seçmeliyim?
Bağlantılı ve şifreli iletim. Bağlantısız iletim varsayılan olabilir ama ağ yoğunlaştığında kayıtlar hiçbir uyarı vermeden düşürülür — günlüklerinizde fark etmediğiniz boşluklar oluşur. Ayrıca günlükler kullanıcı adları ve adresler içerir, düz metin akmamalıdır.
Yerel kopyayı tamamen kaldırabilir miyim?
Kaldırmayın. Gönderici, kayıtları yerel diske de yazmaya devam etmelidir; merkezî sunucu erişilemez olduğunda ağ kesintisi boyunca kayıtlar tamamen kaybolmasın. Yerel kopya kısa süreli, merkezî kopya uzun süreli tutulabilir.
Olaylar neden yanlış sırayla görünüyor?
Sunucu saatleri senkron değildir. Birleştirilmiş günlüklerde bu, neden-sonuç ilişkisini tersine çevirebilir — sonucun nedenden önce göründüğü bir listeyle karşılaşırsınız. Tüm sunucularda zaman senkronizasyonu şarttır ve kayıtlar evrensel zamanda tutulmalıdır.
