Bir saldırıyı ancak logunuz varsa çözebilirsiniz. Ama gereğinden uzun tutulan log da başlı başına bir risktir: içinde kişisel veri barındırır, sızdığında ikinci bir olay üretir ve gereksiz yere saklama maliyeti doğurur. Doğru cevap "her şeyi sonsuza kadar sakla" değildir.
Kısa cevap: loglar ne kadar saklanmalı?
Saklama süresi tek bir rakamla belirlenmez; üç girdinin kesişiminde belirlenir: yasal kayıt tutma yükümlülükleri, olay incelemesi için gereken süre ve kişisel veri saklama ilkeleri. Pratikte uygulanabilir yaklaşım, log tiplerini ayırmak ve her biri için ayrı süre tanımlamaktır: güvenlik ve erişim kayıtları daha uzun, hata ayıklama kayıtları çok daha kısa. Kritik nokta şudur: süre bir kez belirlenip yazılmalı ve otomatik uygulanmalıdır; elle yönetilen saklama, ya çok kısa ya sonsuz olur.
Hangi log ne kadar saklanmalı?
| Log tipi | Ne işe yarar? | Tipik yaklaşım | Risk |
|---|---|---|---|
| Kimlik doğrulama kayıtları | Kim, ne zaman giriş yaptı | Uzun süre saklanır | Kullanıcı adı ve IP içerir |
| Web erişim kayıtları | Hangi adres, hangi IP'den istendi | Orta süre | IP kişisel veri sayılabilir |
| Güvenlik olay kayıtları | Engellenen istek, şüpheli davranış | Uzun süre | Düşük |
| Uygulama hata kayıtları | Hata ayıklama | Kısa süre | Yanlışlıkla hassas veri yazabilir |
| Veritabanı sorgu kayıtları | Performans analizi | Çok kısa | Sorgu içeriğinde kişisel veri olabilir |
| Yedekleme ve iş kayıtları | İşlemin çalıştığını kanıtlama | Orta süre | Düşük |
Tablodaki en riskli satır dördüncüsüdür ve genellikle hiç düşünülmez. Hata ayıklama kayıtları, sorun çözmek için geçici olarak açılır ve kapatılmayı unutulur; bu kayıtlar bazen form içeriğini, oturum bilgisini veya istek gövdesini olduğu gibi yazar. Kısa saklama ve düzenli temizlik, bu riski otomatik olarak yönetir.
Yasal yükümlülük ile güvenlik ihtiyacının kesişimi
İki farklı gereklilik aynı dosyaya bakar ve bazen ters yönde çeker:
- Kayıt tutma yükümlülükleri belirli faaliyetler için asgari saklama süreleri öngörür. Bu süreler mevzuata ve faaliyet türüne göre değişir; sizin için hangisinin geçerli olduğunu hukuk danışmanınızla netleştirmeniz gerekir.
- Kişisel veri ilkeleri ise verinin amaçla sınırlı ve gerekli süre kadar saklanmasını gerektirir. Yani gereğinden uzun saklamak da bir uyum sorunudur.
- Güvenlik ihtiyacı arada durur: bir olayın haftalar sonra fark edilmesi olağandır, dolayısıyla çok kısa saklama inceleme imkânını ortadan kaldırır.
Bu üçünün dengesi şöyle kurulur: asgari yasal süre bir taban, kişisel veri ilkeleri bir tavan oluşturur; güvenlik ihtiyacı bu aralık içinde konumlandırılır. Aralık dışına çıkan her uygulama — ne kadar iyi niyetli olursa olsun — bir tarafta eksik kalır.
Log'un kendisini korumak
Loglar, saldırı sonrası incelemenin tek kaynağıdır; bu yüzden saldırganın ilk hedeflerinden biri de onlardır:
- Kayıtları ayrı bir yerde tutun. Sunucu ele geçirildiğinde, o sunucudaki kayıtlar da güvenilirliğini kaybeder. Merkezî veya harici bir kopya, delil değerini korur.
- Yazma-sonrası değiştirilemez hâle getirin. Mümkünse kayıtların üzerine yazılamaz veya silinemez biçimde saklanması sağlanmalıdır.
- Erişimi sınırlandırın. Log okuma yetkisi, sistem erişiminden ayrı bir yetkidir; herkese açık olmamalıdır.
- Kişisel veriyi maskeleyin. Gerekmeyen alanların loglanmaması, hem risk hem saklama maliyeti azaltır.
- Zaman senkronizasyonu kurun. Farklı sistemlerin saatleri uyumsuzsa, olay zaman çizelgesi kurulamaz — inceleme pratikte imkânsızlaşır.
- Otomatik silme kurun. Süre dolduğunda kaydın kendiliğinden silinmesi, hem uyum hem disk yönetimi açısından gereklidir.
Beşinci madde küçük görünür ama belirleyicidir: bir olayı incelerken web sunucusu, uygulama ve güvenlik duvarı kayıtlarını yan yana koyabilmek, ancak saatler uyumluysa mümkündür.
Netişlem uzman görüşü: en sık karşılaştığımız iki uç
Sahada iki uç görüyoruz. Birincisi hiç log tutmayan veya birkaç günde silen işletmeler; bir olay yaşandığında elimizde inceleyecek hiçbir şey olmuyor ve "nasıl girdiler" sorusu cevapsız kalıyor. İkincisi ise her şeyi sonsuza kadar saklayan işletmeler; bu kez loglar yıllarca birikmiş kişisel veri yığınına dönüşüyor ve kendisi bir risk kalemi oluyor. Doğru cevap ikisinin ortasında ve yazılı bir politikayla belirleniyor.
İkinci gözlemimiz, disk dolmasının çoğu zaman log kaynaklı olması. Otomatik döndürme kurulmamış bir sunucuda log dosyaları sessizce büyüyor ve bir gün diski dolduruyor — sonuç ani bir kesinti oluyor. Bu, gizli yük kaynakları yazımızda ele aldığımız en yaygın senaryolardan biri.
Üçüncüsü, logların sunucunun kendisinde tutulması. Bir olay sonrası incelemede en kritik soru şu oluyor: bu kayıtlara güvenebilir miyiz? Sunucu ele geçirilmişse cevap "hayır". Kayıtların harici bir kopyasını tutmak, olay anında elinizdeki tek güvenilir kaynağı oluşturuyor.
Politika kontrol listesi
- Log tipleri listelendi ve her biri için saklama süresi yazıldı.
- Yasal asgari süreler danışmanla doğrulandı.
- Kişisel veri içeren alanlar tespit edildi ve gereksizler maskelendi.
- Hata ayıklama kayıtları kısa süreli ve varsayılan olarak kapalı.
- Otomatik döndürme ve silme kurulu.
- Kayıtların harici bir kopyası tutuluyor.
- Log erişimi ayrı bir yetki olarak tanımlı.
- Sunucular arası saat senkronizasyonu aktif.
- Disk doluluk uyarısı kurulu — bkz. izleme yazısı.
- Saklama süresi veri envanterinde yer alıyor — bkz. VERBİS rehberi.
- Politika yılda bir gözden geçiriliyor.
Sık sorulan sorular
IP adresi kişisel veri sayılır mı?
Belirli bir kişiyle ilişkilendirilebildiği durumlarda kişisel veri olarak değerlendirilebilir. Bu nedenle erişim kayıtlarının saklama süresi ve erişim yetkisi, diğer kişisel veriler gibi ele alınmalıdır. Değerlendirmeyi hukuk danışmanınızla birlikte yapmanız yerinde olur.
Logları şifrelemeli miyim?
Kişisel veri içeriyorsa ve özellikle harici bir konumda saklanıyorsa evet. Şifreleme, kayıtların bir başkasının eline geçmesi durumunda ikinci bir olay yaşanmasını önler. Anahtarın kayıtlardan ayrı saklanması gerekir.
Paylaşımlı hostingte log yönetimi yapabilir miyim?
Sınırlı ölçüde. Panelde genellikle erişim ve hata kayıtları bulunur ancak saklama süresini siz belirleyemezsiniz. Bu durumda pratik çözüm, kayıtları düzenli aralıklarla indirip kendi arşivinizde saklamaktır.
Ne kadar geriye dönük inceleme gerekir?
Olayların önemli bir kısmı gerçekleştikten haftalar sonra fark edilir. Bu nedenle güvenlik kayıtlarında birkaç günlük saklama pratikte yetersiz kalır. Süreyi belirlerken "bir olayı ne kadar geç fark edebiliriz" sorusunu sormak, doğru aralığı bulmanın en pratik yoludur.
Log'da hassas veri bulursam ne yapmalıyım?
Önce kaynağı düzeltin: uygulamanın o alanı loglamasını durdurun. Ardından mevcut kayıtları temizleyin veya maskeleyin ve durumu kayıt altına alın. Bu, tekrarını önlemenin ve olası bir denetimde süreci açıklamanın tek yoludur.
Sonuç
Log yönetimi, "sakla" ile "sil" arasında bir denge kurma işidir. Doğru kurgu, log tiplerini ayırmak, her biri için yazılı bir süre belirlemek ve bu süreyi otomatik uygulamaktır. Bu yapı kurulduğunda hem bir olayı inceleyebilir hem de gereksiz veri biriktirmemiş olursunuz.
Log ve kayıt politikanızı birlikte oluşturmak isterseniz bize ulaşın. Sunucu yönetimi, güvenli hosting ve gizlilik politikamızı inceleyebilirsiniz.