Merkezi Log Saklama Mimarisi: Hangi Log, Ne Kadar, Nerede?

Olay incelemesine oturuyorsunuz, domain controller loglarına bakıyorsunuz ve en eski kayıt dört gün önce. Saldırgan ise üç hafta önce girmiş. Merkezi log yönetimi çoğu kurumda bir SIEM lisansı ve “her şeyi gönderelim” yaklaşımıyla başlar; sonunda maliyet, gürültü ve yine de eksik kapsam kalır. Uyumu ve olay incelemesini gerçekten karşılayan bir log mimarisi dört soruya net cevap verir: Hangi kaynaklar toplanıyor, ne kadar süre saklanıyor, logların değiştirilmediği nasıl kanıtlanıyor ve loglara kim erişebiliyor?

Log saklamanın iki ayrı amacı

Logun iki müşterisi vardır ve tasarım ikisini birden gözetmek zorundadır. Güvenlik ekibi için loglar tespit (gerçek zamanlı korelasyon) ve olay incelemesi (geriye dönük arama) içindir. Uyum tarafında ise log, bir kontrolün işlediğinin kanıtıdır: ISO/IEC 27001:2022 Ek A’daki 8.15 (Kayıt tutma), 8.16 (İzleme faaliyetleri) ve 8.17 (Saat senkronizasyonu) kontrolleri, TISAX’ın dayandığı VDA ISA kataloğundaki loglama gereklilikleri, KVKK kapsamında kişisel veriye erişimin izlenebilirliği ve NIS2’deki olay yönetimi başlığı bu kanıtı ister.

İki amaç iki farklı erişim deseni doğurur. Tespit için son günlerin verisi saniyeler içinde sorgulanabilmeli. Uyum ve adli inceleme için ise aylar önceki veri, daha yavaş da olsa, bütünlüğü kanıtlanarak geri getirilebilmeli. Mimari kararların çoğu bu ayrımdan çıkar.

Kritik log kaynakları ve öncelik tablosu

Kaynak seçerken sorulacak soru şudur: “Hangi olayı inceleyemezsem en çok zarar görürüm?” Aşağıdaki sıra çoğu kurumsal ortam için makul bir başlangıçtır.

Kaynak	Kullanım amacı	Öncelik
Domain controller güvenlik logları	Kimlik doğrulama, yetki ve grup değişikliği	1
Entra ID / M365 denetim ve oturum logları	Bulut kimliği, posta kutusu erişimi	1
Firewall ve VPN	Dış bağlantılar, uzak erişim oturumları	1
EDR telemetrisi ve uyarıları	Süreç, dosya ve zararlı yazılım olayları	1
Kritik sunucu işletim sistemi logları	Yerel oturum, servis ve süreç değişiklikleri	2
Ayrıcalıklı erişim ve yedekleme sistemi	Yönetici oturumları, yedek silme ve değiştirme	2
Veritabanı ve iş uygulaması denetim logları	Hassas veriye erişim, toplu dışa aktarım	2
DNS ve proxy	C2 iletişimi, veri sızdırma izleri	2
Ağ anahtarı ve kablosuz denetleyici	Yapılandırma değişikliği, port olayları	3

Windows’ta kaynağı eklemek yetmez. Denetim politikası doğru olayları üretmiyorsa topladığınız log boştur; sahada en sık gördüğümüz hata da budur. Şu olayların gerçekten üretildiğini doğrulayın: 4624/4625 (başarılı/başarısız oturum), 4672 (ayrıcalıklı oturum), 4720 (hesap oluşturma), 4728, 4732 ve 4756 (gruplara üye ekleme), 4719 (denetim politikası değişikliği) ve 1102 (güvenlik logunun temizlenmesi). Süreç oluşturma (4688) olayında komut satırının kaydı ayrı bir grup ilkesi ayarıyla açılır; kapalıysa 4688 size yalnızca süreç adını verir. Ağ cihazlarının syslog gönderimi ve temel saklama ayarları için ağ cihazları için merkezi syslog sunucusu kurulumu rehberine, firewall loglarından tespit kuralı üretmek için firewall log analizi rehberine bakın.

Uç noktadaki yerel log boyutu da hesaba girer. Toplama ajanı birkaç saat merkeze ulaşamazsa olaylar yerel logda beklemelidir. Varsayılan boyut yoğun bir domain controller’da kısa sürede dolar ve en eski kayıtların üzerine yazılır.

REM Güvenlik logunun mevcut ayarlarını görüntüle
wevtutil gl Security
REM Azami boyutu 1 GB yap (bayt cinsinden)
wevtutil sl Security /ms:1073741824

Bu ayarı kalıcı olarak grup ilkesiyle (Event Log ayarları) yönetin. Tek seferlik komut yalnızca test içindir; bir sonraki ilke yenilemesinde ezilebilir.

Zaman senkronizasyonu ve bütünlük

Farklı kaynaklardaki olayları tek zaman çizelgesine dizemiyorsanız loglarınızın olay incelemesinde kanıt değeri kalmaz. Tasarımda tek bir zaman hiyerarşisi kurulur: Active Directory ortamında PDC emülatör rolündeki domain controller güvenilir dış NTP kaynaklarından beslenir, diğer Windows sistemleri domain hiyerarşisini izler, Linux sunucular ve ağ cihazları aynı iç NTP kaynaklarına yönlendirilir. Logları UTC ya da saat dilimi bilgisiyle saklayın; yaz saati ve bölge farkı karışıklığı böyle önlenir. Sanal makinelerde hipervizör saat senkronizasyonu ile domain hiyerarşisi çakışıyorsa konsolda ilk bakılacak yer zaman kaynağıdır.

REM Windows: zaman kaynağı ve son senkronizasyon
w32tm /query /source
w32tm /query /status

# Linux (chrony): sapma ve kaynak durumu
chronyc tracking
chronyc sources -v

Bütünlük için üç katman birlikte düşünülür:

• Aktarımda bütünlük: Syslog için TLS üzerinden iletim (RFC 5425, varsayılan port 6514) veya ajanın kendi şifreli kanalı. Düz UDP/514 üzerindeki loglar yolda değiştirilebilir ve sessizce kaybolabilir.
• Depolamada bütünlük: Soğuk katmanda nesne kilidi (Object Lock/WORM) veya değiştirilemez depolama; ek olarak günlük log dosyaları için hash üretip ayrı bir sistemde saklamak.
• Yönetimsel ayrım: Log platformunun yönetici hesapları, izlenen sistemlerin yönetici hesaplarından ayrı olmalı. Domain admin yetkisini ele geçiren saldırgan log platformunu silemiyorsa mimari işini yapmıştır.

rsyslog kullanan bir Linux sunucudan TLS ile ve bağlantı koptuğunda diskte kuyruklayarak gönderim için örnek yapılandırma:

global(DefaultNetstreamDriver="gtls"
       DefaultNetstreamDriverCAFile="/etc/rsyslog.d/ca.pem")

action(type="omfwd" target="log01.ornek.local" port="6514" protocol="tcp"
       StreamDriver="gtls" StreamDriverMode="1"
       StreamDriverAuthMode="x509/name"
       StreamDriverPermittedPeers="log01.ornek.local"
       queue.type="LinkedList" queue.filename="fwd_log01"
       queue.maxDiskSpace="1g" queue.saveOnShutdown="on"
       action.resumeRetryCount="-1")

Disk kuyruğu, toplayıcı bakımdayken log kaybını önler. Kuyruk boyutunu kaynağın log üretim hızına ve kabul edebileceğiniz kesinti süresine göre hesaplayın. Tahminle değil, ölçerek.

Saklama katmanları: sıcak, ılık, soğuk

Tüm logları yüksek performanslı SIEM depolamasında uzun süre tutmak para yakmaktır. Katmanlı yaklaşım verinin yaşına göre farklı depolama kullanır:

Katman	Tipik içerik	Erişim	Depolama
Sıcak	Son günlerin/haftaların tüm logları	Anlık sorgu, korelasyon	SIEM indeksleri, hızlı disk
Ilık	Son birkaç ayın logları	Dakikalar içinde arama	Daha ucuz indeks veya arşiv katmanı
Soğuk	Uzun dönem saklanan ham log	Geri yükleme gerektirir	Sıkıştırılmış nesne depolama, WORM

Katmanlar arası geçiş otomatik olmalı ve soğuk katmandaki verinin geri getirilebildiği düzenli aralıklarla denenmeli. Hiç geri yüklenmemiş arşiv, hiç geri yüklenmemiş yedek kadar belirsizdir. Soğuk katman için değiştirilemezlik seçenekleri değiştirilemez yedek seçenekleri rehberindeki teknolojilerle aynıdır.

Saklama süresinin belirlenmesi

Tek bir “doğru” süre yok. Süre üç girdinin en uzununa göre belirlenir ve kaynak türüne göre değişebilir:

1. Mevzuat ve standart: Örneğin PCI DSS v4.0 gereksinim 10.5.1, denetim log geçmişinin en az 12 ay saklanmasını ve son üç ayın analiz için hemen erişilebilir olmasını ister. Türkiye’de 5651 sayılı Kanun ve ikincil düzenlemeleri gibi mevzuatın sizi hangi sıfatla ve hangi süreyle bağladığını hukuk birimiyle birlikte netleştirin.
2. Sözleşme: Müşteri sözleşmeleri ve TISAX gibi değerlendirmeler belirli bir süre öngörebilir. Sözleşmelerdeki log ve olay bildirimi maddelerini envantere alın.
3. Olay inceleme ihtiyacı: Saldırganın ilk erişimi ile tespit arasında haftalar, bazen aylar geçer. Kimlik, uzak erişim ve EDR logları için saklama süresi bu geriye dönük incelemeyi mümkün kılacak uzunlukta olmalı.

Ters yönde bir sınır da var: kişisel veri içeren loglar amaç için gereken süreden uzun tutulmamalı. Bu yüzden saklama süresini kaynak bazında, gerekçesiyle birlikte yazılı bir tabloda tutun ve süresi dolan veriyi otomatik olarak imha edin. Kişisel veri erişim loglarının KVKK açısından ele alınışı KVKK teknik tedbirleri rehberinde anlatılıyor.

Log erişiminin kontrolü ve gizlilik

Loglar kullanıcı adı, IP adresi, URL, e-posta konusu, bazen de kullanıcı adı alanına yanlışlıkla yazılmış parolalar içerir. Erişim tasarımında şu ilkeleri uygulayın:

• Rol bazlı erişim: SOC analisti, sistem yöneticisi ve denetçi farklı veri kümelerini ve farklı yetkileri (okuma, dışa aktarma, silme) görür.
• Silme ve saklama ayarlarını değiştirme yetkisi yalnızca ayrı ve MFA’lı yönetici hesaplarında bulunur.
• Log platformundaki sorgu ve dışa aktarma işlemleri de loglanır; “logları kim inceledi?” sorusunun cevabı olmalı.
• Uygulama loglarına parola, oturum belirteci veya tam kart numarası yazılmadığını geliştirme sürecinde kontrol edin; yazılıyorsa kaynakta maskeleyin.

Log toplama sürekliliğinin izlenmesi

En sık uyum bulgusu şudur: loglar “toplanıyor” sanılır, oysa aylardır gelmiyordur. Ajan güncellemesi, süresi dolan bir sertifika, değişen bir firewall kuralı veya dolan bir disk toplamayı sessizce durdurur. Kimse fark etmez. Bu yüzden her kaynak için beklenen son olay zamanını izleyin:

• Kaynak envanterini log platformunda referans liste olarak tutun ve her kaynak için beklenen sessizlik eşiğini tanımlayın (örnek: domain controller için 15 dakika, düşük trafikli bir anahtar için 24 saat).
• Eşiği aşan kaynak için otomatik uyarı üretilsin ve bu uyarı bir olay kaydına dönüşsün.
• Aylık rapor: envanterdeki kaynak sayısı, son 30 günde veri gönderen kaynak sayısı ve kesinti süreleri. Denetimde kapsamın en güçlü kanıtı bu rapordur.
• 1102 (log temizlendi) ve denetim politikası değişikliği olaylarını yüksek öncelikli uyarı olarak tanımlayın.

Kaynak seçimi, korelasyon kuralları ve saklama katmanlarını birlikte tasarlamanız gerekiyorsa SIEM kurulumu ve güvenlik logları hizmetimizde bu mimariyi mevcut altyapınıza göre boyutlandırıyoruz. Syslog protokolü RFC 5424, TLS taşıma katmanı RFC 5425 ile tanımlanmıştır.

Sık sorulan sorular

Merkezi log yönetimi için SIEM şart mı?

Hayır. Saklama ve bütünlük gereklilikleri merkezi bir syslog/log toplama platformu ve değiştirilemez arşivle karşılanabilir. SIEM korelasyon ve tespit için gerekir. Pek çok kurumda doğru mimari, tüm logları ucuz bir arşivde, tespit için gereken alt kümeyi SIEM’de tutmaktır.

Loglar ne kadar süre saklanmalı?

Süre; mevzuat, sözleşme ve olay inceleme ihtiyacından en uzun olanına göre ve kaynak bazında belirlenir. Örneğin PCI DSS v4.0 en az 12 ay saklama ve son üç ayın hemen erişilebilir olmasını ister. Kişisel veri içeren loglar ise amaç için gereken süreden uzun tutulmamalıdır.

Logların değiştirilmediği nasıl kanıtlanır?

TLS ile şifreli aktarım, soğuk katmanda WORM veya nesne kilidi, log dosyaları için ayrı sistemde saklanan hash değerleri ve log platformu yönetiminin izlenen sistemlerin yöneticilerinden ayrılması birlikte kullanılır. Log platformundaki silme ve ayar değişiklikleri de loglanmalıdır.

Bir kaynaktan log gelmediğini nasıl fark ederim?

Her kaynak için beklenen son olay zamanı ve sessizlik eşiği tanımlanır; eşik aşılınca otomatik uyarı üretilir. Ayda bir, envanterdeki kaynak sayısı ile gerçekten veri gönderen kaynak sayısı karşılaştırılır.