Zaman Damgası 5651 Loglamada Neden Kritik?

5651 Sayılı Kanun ve Zaman Damgası Gerekliliği: Hukuki Zemin

5651 sayılı İnternet Ortamında Yapılan Yayınların Düzenlenmesi ve Bu Yayınlar Yoluyla İşlenen Suçlarla Mücadele Edilmesi Hakkında Kanun, içerik ve erişim sağlayıcılarına kullanıcı trafik kayıtlarını belirli bir süre saklamayı zorunlu kılar. Bu yasal yükümlülük, bir suç soruşturması başlatıldığında hangi kullanıcının hangi IP adresini ne zaman kullandığını, hangi siteye eriştiğini ve bu erişimin tam olarak hangi saniye gerçekleştiğini ispat etmeyi gerektirir. İşte bu noktada zaman damgası (timestamp), loglamanın en kritik bileşeni haline gelir.

Kanunun 6. maddesi uyarınca erişim sağlayıcılar, kullanıcılarına ait trafik bilgilerini iki yıl süreyle saklamakla yükümlüdür. Bu kayıtlar arasında kaynak ve hedef IP adresleri, port numaraları, bağlantı başlangıç ve bitiş zamanları, kullanılan protokol ve aktarılan veri miktarı yer alır. Ancak tüm bu verilerin hukuki geçerliliği, doğru, değiştirilemez ve senkronize bir zaman damgası ile işaretlenmiş olmasına bağlıdır. Zaman damgası olmayan veya yanlış zaman bilgisi taşıyan bir log kaydı, mahkeme önünde delil niteliği taşımaz ve işletmeyi hem idari para cezasına hem de hukuki sorumluluğa açık hale getirir.

BTK tarafından yapılan denetimlerde en sık tespit edilen uygunsuzluklardan biri, log kayıtlarında zaman tutarsızlığıdır. Örneğin, bir firewall cihazının saati elle ayarlanmış ve NTP senkronizasyonu yapılmamışsa, cihaz yeniden başlatıldığında veya güç kesintisi yaşandığında saat bilgisi kaybolur veya geriye gider. Bu durumda oluşan loglar gerçek olay zamanını yansıtmaz ve soruşturma sürecinde kullanılamaz hale gelir.

Zaman Damgası Nedir ve Nasıl Çalışır?

Zaman damgası, bir olayın gerçekleştiği anı milisaniye hassasiyetinde kaydeden sayısal bir işarettir. Teknik olarak, Unix epoch zamanı (1 Ocak 1970'ten itibaren geçen saniye sayısı) veya ISO 8601 formatında (YYYY-MM-DD HH:MM:SS.mmm) saklanır. Loglama sistemlerinde her bağlantı, her oturum açma, her paket transferi bu zaman damgası ile etiketlenir.

Kritik nokta şudur: zaman damgası mutlaka güvenilir bir referans kaynağından alınmalıdır. Cihazın kendi iç saati yeterli değildir, çünkü:

• Donanım saatleri zamanla sapma gösterir (drift)
• Güç kesintisi veya yeniden başlatma sonrası sıfırlanabilir
• Elle müdahale ile değiştirilebilir
• Saat pili bittiğinde varsayılan tarihe döner

Bu nedenle profesyonel loglama sistemleri NTP (Network Time Protocol) kullanarak zaman damgasını merkezi, güvenilir zaman sunucularından alır. Türkiye'de TÜBİTAK ULAKBIM tarafından işletilen ntp.ulakbim.gov.tr resmi NTP sunucusu, yasal uyumluluk için önerilen referans kaynağıdır. Alternatif olarak time.nist.gov gibi uluslararası sunucular da kullanılabilir, ancak yerel saat dilimi (UTC+3) dönüşümlerinin doğru yapıldığından emin olunmalıdır.

NTP Senkronizasyonu: Teknik Detaylar

FortiGate, MikroTik, Sophos veya SonicWall gibi kurumsal firewall cihazlarında NTP yapılandırması zorunludur. Örneğin bir FortiGate 60F cihazında:

• System > Settings > NTP bölümünden birincil ve yedek NTP sunucuları tanımlanır
• Senkronizasyon aralığı varsayılan 60 dakikadır, kritik ortamlarda 15 dakikaya düşürülebilir
• diagnose sys ntp status komutu ile senkronizasyon durumu kontrol edilir
• Stratum değeri 2-3 aralığında olmalıdır (stratum 1 doğrudan atom saati referansıdır)

MikroTik RouterOS'ta ise /system ntp client set enabled=yes primary-ntp=ntp.ulakbim.gov.tr komutu ile aktifleştirme yapılır. Önemli bir nokta: MikroTik cihazlarda NTP istemcisi varsayılan olarak kapalıdır ve birçok işletme bu ayarı gözden kaçırır.

NextLog5651 gibi bulut tabanlı loglama sistemlerinde, zaman damgası merkezi sunucularda otomatik olarak eklenir ve cihaz saatinden bağımsız çalışır. Ancak log gönderen kaynak cihazın (firewall, router) zamanının da doğru olması önemlidir, çünkü bazı analizlerde kaynak cihaz zamanı ile merkezi sunucu zamanı karşılaştırılır ve büyük sapmalar anomali olarak işaretlenir.

Zaman Damgası Olmadan veya Yanlış Zamanlı Loglarda Oluşan Sorunlar

Bir otel işletmesi düşünelim: Opera PMS entegrasyonu ile misafir odalarına internet erişimi sağlanıyor. 15 Mart 2024 saat 14:30'da 305 numaralı odadan yasadışı içerik paylaşımı yapıldığı iddiasıyla soruşturma başlatılıyor. BTK, işletmeden o tarih ve saatteki 305 numaralı odaya ait tüm internet trafik kayıtlarını talep ediyor.

Ancak işletmenin kullandığı MikroTik hotspot cihazının NTP ayarı yapılmamış ve cihaz saati 2 saat ileri. Loglarda olay zamanı 16:30 olarak görünüyor. Bu durumda:

• Misafir o saatte otelde olmadığını, check-out yaptığını ispatlayabilir
• Log kayıtları çelişkili hale gelir ve delil değerini kaybeder
• İşletme, 5651 uyumsuzluğundan dolayı 50.000 TL'ye kadar idari para cezası alabilir
• Suç failinin tespiti imkansızlaşır, işletme hukuki sorumlulukla karşı karşıya kalır

Gerçek bir vaka: Bir AVM'nin misafir WiFi sisteminde kullanılan Sophos XG cihazının saati, elektrik kesintisi sonrası varsayılan 2010 yılına dönmüş. Üç ay boyunca oluşan tüm loglar yanlış zaman damgası taşıdığı için BTK denetiminde geçersiz sayılmış ve işletme hem ceza almış hem de sistem tamamen yeniden kurulana kadar hizmet verme yasağı ile karşılaşmıştır.

Mahkeme Süreçlerinde Zaman Damgası İspatı

Ceza davalarında dijital delillerin kabul edilebilirliği için CMK 134. madde uyarınca delilin bütünlüğü ve değiştirilmezliği ispatlanmalıdır. Zaman damgası bu ispatta kritik rol oynar:

• Log kaydının hangi NTP sunucusundan zaman aldığı belgelenmelidir
• Zaman damgası değiştirilemez bir formatta saklanmalıdır (hash ile korunmalı)
• Saat dilimi bilgisi açıkça belirtilmelidir (UTC mi, UTC+3 mü?)
• Milisaniye hassasiyeti gereklidir (aynı saniyede birden fazla olay olabilir)

NextLog5651 sistemi, her log kaydına SHA-256 hash ile korunan zaman damgası ekler ve bu hash değeri merkezi veritabanında saklanır. Böylece log kaydı sonradan değiştirilse bile hash uyumsuzluğu tespit edilir ve kayıt geçersiz sayılır. Bu mekanizma, mahkeme süreçlerinde delilin bütünlüğünü ispat için kullanılır.

Farklı Cihaz ve Sistemlerde Zaman Damgası Yönetimi

Otel PMS Entegrasyonlarında Özel Dikkat Gereken Noktalar

Opera, Elektraweb veya Amonra gibi otel yönetim sistemleri ile entegre çalışan hotspot çözümlerinde, zaman damgası senkronizasyonu iki katmanlı olmalıdır:

Birinci katman: PMS sunucusu kendi veritabanında misafir check-in/check-out zamanlarını kaydeder. Bu zamanlar oda tahsisi ve fatura kesimi için kullanılır. PMS sunucusunun saati mutlaka NTP ile senkronize edilmelidir, aksi halde misafir oturum süreleri ile hotspot log zamanları uyuşmaz.

İkinci katman: Hotspot gateway (genelde MikroTik veya özel donanım) PMS'ten aldığı oda numarası ve misafir bilgisini kendi log kayıtlarına ekler. Bu kayıtların zaman damgası, gateway cihazının kendi NTP senkronizasyonundan gelir. Eğer PMS saati ile gateway saati arasında 10 saniyeden fazla fark varsa, KVKK uyumluluk raporlarında tutarsızlık uyarısı oluşur.

Gerçek senaryo: Bir otelde Opera PMS sunucusu Windows Server 2019 üzerinde çalışıyor ve NTP yapılandırması yapılmamış. Sunucu saati elle ayarlanmış ve 5 dakika ileri. Hotspot gateway ise doğru NTP kullanıyor. Bir misafir saat 10:00'da check-in yapıyor (PMS'e göre 10:05), ancak internet erişimini 10:02'de başlatıyor (gateway log zamanı). BTK denetiminde bu 3 dakikalık tutarsızlık, sistem entegrasyonunun hatalı olduğu şeklinde yorumlanıyor ve işletme ek açıklama yapmak zorunda kalıyor.

KVKK ve Zaman Damgası: Veri Saklama Sürelerinin Kontrolü

Kişisel Verileri Koruma Kanunu (KVKK), kişisel verilerin işlenme amacı ortadan kalktığında silinmesini, yok edilmesini veya anonim hale getirilmesini zorunlu kılar. 5651 loglama bağlamında bu, iki yıllık yasal saklama süresinin bitiminde log kayıtlarının otomatik olarak silinmesi anlamına gelir.

Ancak bu silme işleminin gerçekleştiğini ispat etmek için zaman damgası yine kritiktir. KVKK denetimlerinde Kurul, şu soruları sorar:

• İki yıl önceki loglar gerçekten silindi mi?
• Silme işlemi hangi tarihte, saat kaçta yapıldı?
• Silme işlemi otomatik mi, manuel mi?
• Silme işleminin kaydı (audit log) var mı ve bu kayıt değiştirilemez mi?

NextLog5651 sisteminde, her log kaydının oluşturulma zamanı (creation timestamp) ve silinme zamanı (deletion timestamp) ayrı ayrı saklanır. Sistem, iki yıl dolduğunda ilgili kayıtları otomatik olarak siler ve bu silme işlemini bir audit log olarak kaydeder. Audit log, hangi kullanıcı/sistem tarafından, hangi tarih ve saatte, kaç adet kaydın silindiğini milisaniye hassasiyetinde gösterir. Bu kayıt, KVKK Kurulu denetiminde sunulabilecek bir ispat belgesidir.

Zaman Damgası ve Veri Minimizasyonu İlkesi

KVKK'nın veri minimizasyonu ilkesi, yalnızca gerekli verilerin toplanmasını gerektirir. Loglama sistemlerinde bu ilke, gereksiz detayın loglanmaması anlamına gelir. Ancak zaman damgası, veri minimizasyonunun istisnasıdır: milisaniye hassasiyetinde zaman damgası yasal zorunluluktur ve minimizasyon kapsamı dışındadır.

Bazı işletmeler, "zaman damgasını saniye hassasiyetine düşürürsek daha az veri toplamış oluruz" yanılgısına düşer. Ancak CMK ve 5651 uygulamaları, aynı saniyede birden fazla bağlantı olabileceği için milisaniye hassasiyeti gerektirir. Örneğin, bir AVM misafir WiFi'sinde saniyede 50-100 yeni bağlantı oluşabilir; bu bağlantıları ayırt etmek için milisaniye şarttır.

Bulut Tabanlı Loglama Sistemlerinde Zaman Damgası Avantajları

Geleneksel on-premise loglama çözümlerinde (appliance veya lokal sunucu), zaman damgası yönetimi tamamen işletmenin sorumluluğundadır. NTP yapılandırması, saat senkronizasyonu, saat dilimi ayarları, yedekleme sırasında zaman tutarlılığı gibi tüm teknik detaylar IT ekibinin omzundadır. Ancak bulut tabanlı sistemlerde bu yük ortadan kalkar:

• Merkezi NTP senkronizasyonu: Bulut sunucuları otomatik olarak stratum-1 NTP sunucularına bağlıdır
• Coğrafi dağıtım: Farklı veri merkezlerindeki sunucular aynı zaman referansını kullanır
• Otomatik yedekleme: Yedeklenen logların zaman damgası değişmez, orijinal haliyle saklanır
• Audit trail: Her log kaydının ne zaman oluşturulduğu, ne zaman buluta gönderildiği, ne zaman işlendiği ayrı ayrı kaydedilir

NextLog5651, Amazon Web Services (AWS) altyapısı üzerinde çalışır ve AWS'nin kendi NTP altyapısını (Amazon Time Sync Service) kullanır. Bu servis, GPS ve atom saati referanslı, stratum-1 hassasiyetinde zaman sağlar. Böylece müşteri tarafında hiçbir NTP yapılandırması gerekmez; firewall veya router sadece syslog paketlerini NextLog5651 IP adresine gönderir, zaman damgası merkezi sunucularda otomatik olarak eklenir.

Hibrit Senaryolar: Lokal Cihaz + Bulut Loglama

Bazı işletmeler, hem lokal firewall loglarını hem de bulut tabanlı merkezi loglama kullanır. Bu durumda zaman damgası tutarlılığı kritik hale gelir. Örneğin:

• FortiGate cihazı kendi internal memory'sinde son 7 günlük logu tutar (lokal)
• Aynı loglar NextLog5651'e syslog ile gönderilir (bulut)
• Bir soruşturmada hem lokal hem bulut logları karşılaştırılır

Eğer FortiGate'in NTP ayarı yanlışsa, lokal loglardaki zaman ile bulut loglarındaki zaman farklı olur. Bu durum, "log manipülasyonu yapılmış olabilir" şüphesi uyandırır. Bu nedenle hibrit senaryolarda, lokal cihazın NTP senkronizasyonu bulut sistemi kadar önemlidir.

Zaman Damgası Doğrulama ve Denetim Kontrol Listesi

5651 uyumluluğunu sürdürmek isteyen her işletme, zaman damgası yapılandırmasını düzenli olarak kontrol etmelidir. Aşağıdaki kontrol listesi, aylık veya üç aylık periyotlarla uygulanmalıdır: