Log (kayıt, günlük), bir olay gerçekleştiği anda onu gözleyen sistemin yazdığı satırdır. Bir web sunucusunun erişim logundaki tek satır şöyle görünebilir (örnek, kurgusal):
203.0.113.25 - - [14/Mar/2026:23:47:05 +0300] "POST /panel/login HTTP/1.1" 302 - "-" "Mozilla/5.0 (...)"Satır istemci adresini, isteğin alındığı zamanı ve saat dilimi farkını, istenen yolu, yanıt kodunu ve istemcinin kendini nasıl tanıttığını söyler. Söylemedikleri de en az bunlar kadar önemlidir: isteği hangi kişinin yaptığı, kaynak port (varsayılan biçimde yazılmaz), POST ile gönderilen içerik (Apache'nin varsayılan erişim logunda yoktur) ve sunucunun önünde bir proxy varsa gerçek istemci. Son alandaki tarayıcı bilgisi istemcinin kendi beyanıdır; istenen her değer yazılabilir.
Log kayıtlarını kim üretir, kim değiştirebilir?
Bir logun güvenilirliğini tartarken ilk sorumuz onu hangi sistemin ürettiği ve o sistemi kimin yönettiğidir. Aynı olayın izi, kontrolü farklı kişilerde olan birçok yerde bulunabilir:
| Üretici | Örnek | Kimin kontrolünde | Delil açısından not |
|---|---|---|---|
| İşletim sistemi | Windows Security günlüğü (4624 oturum açma olayı: TargetUserName, LogonType, IpAddress alanları), Linux auth.log, systemd journal | Sistemi yöneten kişi veya BT ekibi | Yönetici yetkisi olan biri kaydı silebilir, günlüğü temizleyebilir, saati değiştirebilir. Bunların bir kısmı ayrıca iz bırakır. |
| Uygulama | Web sunucusu, CRM, e-ticaret paneli, API | Uygulamanın sahibi; neyin loglanacağına geliştirici karar verir | Loglanmayan işlemin kaydı yoktur. Uygulama logu kendi veri tabanına yazıyorsa, o tabloyu düzenleyebilen herkes kaydı da değiştirebilir. |
| Ağ ve güvenlik cihazı | Firewall, VPN ağ geçidi, proxy, WAF | Genellikle BT veya güvenlik ekibi | Uygulama sunucusundan ayrı yönetiliyorsa bağımsız bir teyit kaynağıdır. |
| Hizmet sağlayıcı | Bulut denetim kaydı, e-posta hizmeti, barındırma firması | Uyuşmazlığın dışındaki bir şirket | Taraflardan bağımsızdır, ama saklama süresi sağlayıcının ayarıdır ve kısa olabilir: Exchange Online ileti izleme verisini 90 gün tutar ve bu süre değiştirilemez. |
| Kanuni yükümlülükle tutulan kayıt | 5651 kapsamındaki yer, erişim ve toplu kullanım sağlayıcı kayıtları | Yükümlü şirket | Başkasına ait kayıtlar mahkeme veya savcılık eliyle istenir; hangi yolun izleneceği avukatın değerlendirmesidir. |
Bizim kullandığımız ölçü basittir: bir log, onu değiştirebilecek kişinin lehine olduğu ölçüde tek başına zayıflar. Şirketin kendi sunucusundan çıkardığı ve yalnızca şirket yöneticisinin erişebildiği bir log şirketin iddiasını destekleyebilir. Ama aynı olayı gösteren bir hizmet sağlayıcı kaydı ya da karşı tarafın cihazındaki bir iz yanına konmadıkça, "bu kaydı siz yazdınız" itirazına teknik bir cevap vermek zordur.
Log kayıtları mahkemede delil olarak kullanılabilir mi?
Kullanılabilir. HMK m.199 elektronik ortamdaki verileri belge sayar; ceza yargılamasında suç, hukuka uygun biçimde elde edilmiş her türlü delille ispat edilebilir (CMK m.217/2). Hukuka aykırı elde edilen kayıt ise dikkate alınmaz (Anayasa m.38; HMK m.189/2; CMK m.206/2-a). Bu yüzden karşı tarafın sunucusuna ya da hesabına izinsiz girip log toplamak hem kaydı kullanılamaz hâle getirebilir hem suç oluşturabilir (TCK m.243). Ceza soruşturmasında bilgisayar kayıtlarının kopyalanması ve el koyma CMK m.134'e göre yapılır. Madde, Anayasa Mahkemesi'nin 12.02.2026 tarihli, E.2023/128, K.2026/36 sayılı kararıyla iptal edilmiştir (RG 25.05.2026); iptal 25.02.2027'de yürürlüğe girecektir ve yerine gelecek düzenleme takip edilmelidir.
Delilin değerlendirilmesi mahkemenin takdiridir; bu yazı hukuki değerlendirme değildir. Teknik inceleme dört soruyu cevaplar: kaydı hangi sistem üretti, o sistemde kim değişiklik yapabiliyordu, sistemin saati doğru muydu, kayıt alındığı andan beri aynı mı?
Log kayıtlarının güvenilirliğini hangi etkenler belirler?
| Etken | Neye bakarız | Zayıflatan | Güçlendiren |
|---|---|---|---|
| Saat senkronu | NTP yapılandırması ve durumu, saat dilimi ayarı, saat değişikliği olayları (Windows 4616; Linux wtmp'deki saat değişim kayıtları) | Senkronize olmayan sunucu; yıl ve saat dilimi yazmayan eski tip syslog satırı (RFC 3164) | Ortak bir zaman kaynağına bağlı sistemler (NIST SP 800-92); UTC ve saniye hassasiyetinde zaman damgası (RFC 6302) |
| Yetkili erişim | Log dosyasına ve log sunucusuna kimlerin yazma yetkisi olduğu, yönetici hesaplarının kimlerde bulunduğu | Olayın tarafı olan kişinin yönetici olması; ortak kullanılan yönetici hesabı | Logun, olayın taraflarının yetkisi olmayan ayrı bir sistemde tutulması |
| Rotasyon ve saklama | Döndürme (rotation) ayarı, dosyadaki en eski ve en yeni kaydın tarihi, arşiv dosyalarının tamlığı | Olay tarihinin saklama süresinin dışında kalması; eksik arşiv | Olaydan önce ve sonra kesintisiz süren kayıtlar |
| Merkezi toplama | Logların anında merkezi bir log sunucusuna veya SIEM'e gönderilip gönderilmediği, iletimin korunup korunmadığı | Yalnızca kaynak sunucuda duran log; şifresiz ve imzasız syslog iletimi (protokolün kendisinde kriptografik koruma yoktur, RFC 5424) | Olay anında başka bir sisteme kopyalanmış kayıt; TLS ile taşınan (RFC 5425) veya imzalı (RFC 5848) syslog |
| Hash, WORM, mühürleme | Dosyaların özet değeri, tek seferlik yazılabilir (WORM) depolama, journald'ın Forward Secure Sealing özelliği, toplu kullanım sağlayıcılarının günlük bütünlük değeri | Toplama anında hash alınmamış, kimin aldığı belli olmayan kopya | Toplama anında alınıp salt okunur ortamda saklanan özet değer (NIST SP 800-92) |
Saklama süresi çoğu zaman bir kanundan değil bir varsayılan ayardan gelir. Exchange Server, ileti izleme kayıtlarının 30 günden eski olanlarını varsayılan olarak siler; MySQL'in ikili logları (binlog) varsayılan ayarla 30 gün sonra silinebilir; GitHub'ın kurumsal denetim kaydında Git olayları 7 gün tutulur. Geriye doğru ne kadar gidilebileceği her dosyada ayrıca kontrol edilir.
Log kayıtları değiştirilebilir mi?
Evet. Düz metin bir log dosyası, yazma yetkisi olan biri tarafından bir metin düzenleyiciyle ya da tek satırlık bir komutla değiştirilebilir: satır silinebilir, saat değiştirilebilir, sahte satır eklenebilir. Bazı alanlar ise hiçbir müdahale gerektirmeden yanıltıcı olabilir: User-Agent, Referer ve X-Forwarded-For başlıklarını istemci kendisi yazar, sunucu gördüğünü kaydeder. Asıl soru logun değiştirilebilir olup olmadığı değil, değiştirildiyse bunun nerede iz bırakacağıdır.
Değişiklik nerede iz bırakır?
- Sistemin kendi olayları. Windows'ta güvenlik günlüğünün temizlenmesi 1102, sistem saatinin değiştirilmesi 4616 olayını üretir. Linux'ta
wtmpdosyasıdatekomutuyla yapılan saat değişikliklerini de kaydeder. - Sıra numaraları. Windows olay kayıtlarının her birinde
EventRecordIDadlı artan bir sıra numarası vardır; aradan bir olayın çıkarılması numarada boşluk bırakır. Linuxauditdsatırlarındaki kayıt numarası (msg=audit(1773521225.412:3187)içindeki son sayı) aynı işi görür. - Zamanın akışı. Zamanın geriye aktığı satırlar incelenir, ama her geri akış müdahale değildir. Apache'nin
%talanı isteğin alındığı anı yazar, satır ise istek tamamlanınca eklenir; uzun süren bir istek kendinden sonra gelenlerin arasına düşer. Saniyeler değil saatler geriye giden bir satır ise saat değişikliğine, birleştirilmiş dosyalara ya da elle eklenmiş bir kayda işaret edebilir. - Dosyanın kendisi. Birçok düzenleme aracı değişikliği yeni bir dosya olarak yazıp eskisinin yerine koyar. Log servisi ise açık tuttuğu eski dosyaya yazmayı sürdürebilir; sonuç, düzenleme anından servis yeniden başlatılana kadar görünen dosyada hiç kayıt olmamasıdır. Linux logunun bir bölümünde Windows tipi satır sonları belirmesi de dosyanın başka bir ortamda açılıp kaydedildiğini düşündürür.
- Döndürülmüş arşivler.
access.log.1,access.log.2.gzgibi dosyaların her biri belirli bir aralığı kapsar; aralarında boş kalan saatler ya da bir arşivin komşularından belirgin biçimde küçük olması açıklama ister. gzip, sıkıştırdığı dosyanın değişiklik zamanını kendi başlığında saklar (RFC 1952,MTIMEalanı); bu zaman arşivin içindeki son kayıtla karşılaştırılabilir. - Mühürlü kayıtlar. journald'da Forward Secure Sealing açıksa
journalctl --verify, doğrulama anahtarıyla, mühürlemeden sonra değiştirilmiş kayıtları tespit edebilir. - Başka sistemlerle çelişki. Sunucunun
auth.logdosyasından bir satır silinmiş olsa bile aynı bağlantı firewall'da, VPN ağ geçidinde ya da merkezi log sunucusunda görünmeye devam eder.
Örnek (kurgusal): Bir şirket, ayrılmış bir yöneticinin ayrılış tarihinden sonra sunucuya bağlandığını düşünüyor. Sunucudaki
/var/log/auth.logdosyasında o geceye ait SSH girişi yok. Ama aynı sunucununwtmpkaydında 02:14'te açılmış bir oturum, firewall logunda aynı dakikada 203.0.113.40 adresinden 22 numaralı porta kurulmuş bir bağlantı, merkezi log sunucusunda ise yerelauth.log'da bulunmayan üç satır var. Bu tablo, yerel dosyanın sonradan eksiltildiği ihtimalini güçlü biçimde destekler; kimin eksilttiğini ise tek başına göstermez.
Yetkisi olan dikkatli biri düz metin bir logu yukarıdaki izlerin hiçbirini bırakmadan düzenleyebilir. Bu yüzden raporlarımızda "değişiklik izine rastlanmadı" ile "kayıt değiştirilmemiştir" cümlelerini birbirinden ayırırız. İkincisini ancak kayıt belirli bir anda hash değeriyle ya da mühürlü bir mekanizmayla sabitlenmişse ve yalnızca o andan sonrası için söyleyebiliriz.
5651 kapsamındaki kayıtlar: kim, neyi, ne kadar saklar?
5651 sayılı Kanun, internet ortamındaki bazı aktörlere trafik bilgisini saklama yükümlülüğü getirir. Trafik bilgisi; taraflara ilişkin IP adresi, kaynak ve hedef port bilgisi, verilen hizmetin başlama ve bitiş zamanı, yararlanılan hizmetin türü, aktarılan veri miktarı ve varsa abone kimlik bilgileri olarak tanımlanır (m.2/1-j). "Kaynak ve hedef" ibaresi 31.07.2026'da yürürlüğe giren 7590 sayılı Kanun'la eklendi; aynı kanunla 5651'deki yetkiler büyük ölçüde BTK'dan Siber Güvenlik Başkanlığına geçti.
| Yükümlü | Ne saklar | Süre | Not |
|---|---|---|---|
| Yer sağlayıcı (barındırma) | Trafik bilgisi. Yönetmelik bunu kaynak ve hedef IP, bağlantı zamanı, istenen sayfa, işlem bilgisi (GET/POST) ve sonuç bilgisi olarak tarif eder (Usul ve Esaslar Yönetmeliği m.3/1-ş). | Kanun: bir yıldan az ve iki yıldan fazla olmamak üzere yönetmelikte belirlenecek süre (m.5/3) | Yönetmelik hâlâ altı ay diyor (m.7/1-c) ve kanundaki alt sınırla çelişiyor; uygulamadaki çözümü net değil. Dosya bütünlük değerleri zaman damgasıyla saklanır. |
| Erişim sağlayıcı (internet servis sağlayıcı) | Trafik bilgisi | Kanun: altı aydan az ve iki yıldan fazla olmamak üzere yönetmelikte belirlenecek süre (m.6/1-b) | Yönetmelikteki bir yıllık süre iptal edildi (Danıştay 13. D., E.2013/239, K.2019/4266; İDDK, E.2020/1851, K.2022/649); bugün uygulanan somut süreyi birincil kaynaktan doğrulayamadık. Vekil sunucu (proxy) trafiği bir yıl, zaman damgalı bütünlük değeriyle saklanır (m.8/1-e). |
| Toplu kullanım sağlayıcı (kafe, otel, işyeri ağı) | Erişim kayıtları: iç ağda dağıtılan IP adresleri, kullanım başlangıç ve bitiş zamanı, cihazların MAC adresi, hedef IP; port paylaştırmalı erişimde gerçek IP ve port (Toplu Kullanım Yönetmeliği m.3/1-e) | İki yıl (m.4/1-b; ticari olanlar için m.5/1-d) | Ticari olanlar, kayıtların doğruluğunu ve bütünlüğünü teyit eden değeri her gün kaydeder ve iki yıl saklar (m.5/1-e). |
Mevzuat "hash" kelimesini kullanmaz; karşılığı Usul ve Esaslar Yönetmeliği'ndeki "dosya bütünlük değeri"dir (m.3/1-d): bir dosyadaki verilerin matematiksel işlemden geçirilmesiyle elde edilen ve değişiklik olup olmadığını kontrol etmeye yarayan değer. Mobil operatörlerin trafik ve konum verileri ise 5809 sayılı Kanun'a tabidir ve orada da süre bir ile iki yıl arasında yönetmeliğe bırakılmıştır (m.51/10). "Loglar şu kadar yıl saklanır" diye tek bir cümle kurmak bu yüzden mümkün değildir.
Bu kayıtların içeriği eşleştirmeyi de belirler. Yargıtay 11. Ceza Dairesi'nin bir kararına yansıyan operatör yazısına göre, adres paylaştırmalı (NAT'lı) bir IP'nin hangi hatta ait olduğunu bulmak için kaynak IP adresi ve kaynak port bilgisi ile birlikte zaman aralığı ve erişilen sitenin IP adresi gerekir (E.2021/31653, K.2024/2780). Kaynak portu loglamayan bir web sunucusunun kaydı, erişim sağlayıcıda tutulan kayıtla tek bir aboneye bağlanamayabilir. Ayrıntı: CGNAT ve port bilgisi.
Korelasyon neden şart?
Tek bir log, onu tutan sistemin anlatısıdır. Korelasyon, aynı olayı birbirinden bağımsız kaynaklarda bulup kaynakları ortak alanlarla birbirine bağlamaktır: IP adresi ve zaman aralığı (varsa port), kullanıcı adı, oturum kimliği, istek kimliği, e-postada Message-ID. Üç nedenle gereklidir:
- Bağımsızlık. Bir tarafın kendi sunucusundaki kayıt, karşı tarafın ya da bir hizmet sağlayıcının kaydıyla örtüştüğünde "kaydı siz yazdınız" itirazı zayıflar.
- Kişiye yaklaşmak. Log hesabı ya da adresi gösterir. Yargıtay 8. Ceza Dairesi, IP numarasının kullanılan bilgisayarı değil internetle olan bağlantıyı gösterdiğini beraat gerekçeleri arasında saymıştır (E.2012/21817, K.2013/25428). 17. Ceza Dairesi de suç tarihine ait CGNAT verileri getirtilip IP'nin sanık tarafından kullanıldığı kesin ve somut verilerle belirlenmeden kurulan mahkûmiyeti bozmuştur (E.2018/5732, K.2019/7785). Hesaptan kişiye giden yol başka delillerden geçer.
- Zamanın doğrulanması. Her kaynağın saati ayrı ölçülür ve hepsi UTC'ye çevrilir. Aynı olay bir logda 23:47, diğerinde 20:47 görünüyorsa bu üç saat arayla iki olay değil, UTC ile Türkiye saati arasındaki fark olabilir; Türkiye 2016'dan beri sürekli UTC+3'tür. Ayrıntı zaman damgaları ve saat dilimi yazısında; dönüşümler için zaman damgası dönüştürücü.
Kaynakları nasıl topladığımızı, saatleri nasıl eşitlediğimizi ve zaman çizelgesini nasıl kurduğumuzu log analizi sayfasında anlattık.
Log kayıtlarını delil olarak korumak için ilk adımlar
- Sunucuyu yeniden başlatmayın, günlükleri temizlemeyin, log dosyasını bir düzenleyicide açıp kaydetmeyin.
- Dosyaları özgün biçimleriyle, döndürülmüş arşivleri ve logu üreten yapılandırmayla (
log_formatsatırı, syslog ve NTP ayarları) birlikte kopyalayın. - Her kopyanın SHA-256 değerini alın; kopyayı kimin, ne zaman, hangi yöntemle aldığını yazın. Değeri hash hesaplama aracıyla tarayıcınızda hesaplayabilirsiniz; neden gerektiği hash ve delil bütünlüğü yazısında.
- Bulut ve hizmet sağlayıcı kayıtlarını saklama süresi dolmadan dışa aktarın; mümkünse saklama süresini uzatın.
- Başkasına ait sistemlerdeki kayıtlar için yargı mercii yolunu avukatınızla değerlendirin; hangi kaydın hangi alanlarla isteneceğini teknik olarak tarif edebiliriz.