Cuma Trafiği Düşüşü: Hafta Sonu Öncesi 5651 Kontrol Listesi

Cuma günü saat 16:00'ya yaklaşırken, çoğu kuruluşta trafik düşmeye başlar. Çalışanlar hafta sonuna hazırlanırken, IT ekipleri için asıl kritik görev başlar: 5651 sayılı kanun kapsamındaki log sistemlerinin hafta sonu boyunca kesintisiz çalışacağından emin olmak. İki günlük süreçte yaşanacak bir log kaybı, BTK denetiminde açıklanamaz boşluklara ve 50.000 TL'ye varan idari para cezalarına yol açabilir. Bu yazıda, Cuma akşamı yapılması gereken teknik kontrolleri, yasal gereklilikleri ve olası sorun senaryolarını gerçek cihaz örnekleriyle ele alacağız.

Neden Cuma Akşamı Kritik Bir Zaman Dilimi?

5651 sayılı kanunun 6. maddesi, internet erişim sağlayıcılarını ve toplu kullanım sunan işletmeleri (otel, AVM, kamu kurumu) tüm kullanıcı trafiğini kaydetmeye zorlar. Ancak hafta sonu, IT ekiplerinin fiziksel olarak sahada olmadığı, kullanıcı trafiğinin değişken olduğu ve sistem arızalarının geç fark edildiği bir dönemdir. Cuma akşamı yapılan kontroller, Pazartesi sabahı karşılaşılacak sürprizleri önler.

Gerçek bir vaka: Antalya'daki 250 odalı bir otel, Cuma akşamı log sunucusunun disk doluluk oranını kontrol etmemiş. Cumartesi gecesi sistem otomatik olarak eski logları silmeye başlamış, ancak BTK'nın talep ettiği 1 yıllık saklama süresine tabi kayıtların bir kısmı kaybolmuş. Denetim sırasında 15 günlük log eksikliği tespit edilmiş ve işletme 30.000 TL ceza almış. Bu tür senaryolar, sistematik bir Cuma kontrol rutiniyle tamamen önlenebilir.

Yasal Çerçeve: 5651 ve KVKK Saklama Süreleri

5651 sayılı kanun, internet erişim kayıtlarının 1 yıl süreyle saklanmasını zorunlu kılar. Bu kayıtlar şunları içerir: kullanıcı kimlik bilgisi (TC kimlik, pasaport, oda numarası), IP adresi, bağlantı başlangıç/bitiş zamanı, zaman damgası (timestamp), erişilen alan adları. KVKK ise kişisel verilerin "hukuki bir zorunluluk" olarak saklanabileceğini belirtir, ancak süre dolduğunda verilerin silinmesini veya anonimleştirilmesini gerektirir.

Kritik nokta: Saklama süresi, bağlantının sona erdiği tarihten itibaren başlar. Örneğin, bir misafir 15 Ocak 2024'te check-out yaptıysa, bu kullanıcıya ait loglar 15 Ocak 2025'e kadar saklanmalı, ardından otomatik olarak silinmeli veya anonimleştirilmelidir. Hafta sonu öncesi kontrol, hem eksik kayıt olmadığını hem de gereksiz veri birikimiyle KVKK ihlali yapılmadığını doğrular.

Cuma Akşamı Teknik Kontrol Listesi: Adım Adım

1. NTP Senkronizasyonu ve Zaman Damgası Doğruluğu

5651 denetimlerinde en sık karşılaşılan sorun, log kayıtlarındaki zaman damgalarının yanlış veya tutarsız olmasıdır. BTK, saniye düzeyinde doğru zaman damgası bekler. Firewall, log sunucusu ve hotspot gateway'in aynı NTP sunucusuna senkronize olması şarttır.

FortiGate kontrol: CLI'da get system ntp komutuyla NTP sunucusu ve senkronizasyon durumu görüntülenir. ntpsync değeri enable olmalı, syncstatus ise synced göstermeli. Eğer unsynced ise, execute time komutuyla sistem saati kontrol edilir ve NTP sunucusu erişilebilirliği test edilir (örn. execute ping 193.140.100.10 — TÜBİTAK NTP).

MikroTik kontrol: Winbox veya WebFig üzerinden System → SNTP Client menüsü açılır. Primary NTP Server alanında TÜBİTAK (193.140.100.10) veya güvenilir bir kaynak girilmeli. Enabled kutucuğu işaretli olmalı. Terminal'de /system clock print komutuyla mevcut saat ve time-zone doğrulanır.

SonicWall kontrol: Web arayüzünde System → Administration → Time bölümünden NTP sunucuları kontrol edilir. Use NTP seçeneği aktif olmalı, en az iki NTP sunucusu tanımlanmalı (birincil ve yedek). Saat dilimi Türkiye için GMT+3 (veya Europe/Istanbul) olarak ayarlanmalıdır.

Cuma akşamı NTP senkronizasyonunu kontrol etmezseniz, hafta sonu boyunca bir NTP sunucusu kesintisi yaşanırsa, Pazartesi sabahı log kayıtlarında 2-3 günlük zaman kayması bulabilirsiniz. Bu, denetimde geçersiz sayılır.

2. Log Saklama Kapasitesi ve Disk Doluluk Oranı

Bulut tabanlı sistemlerde (NextLog gibi) kapasite genellikle otomatik yönetilir, ancak on-premise veya hibrit çözümlerde disk alanı kritiktir. Hafta sonu trafik düşse de, bazı işletmelerde (özellikle otellerde) Cumartesi-Pazar yoğunluk artar. Disk doluluk oranı %80'i geçmişse, hafta sonu log kaybı riski vardır.

Sophos XG/XGS kontrol: Web arayüzünde System → Backup & Firmware → Log Settings menüsünden log disk kullanımı görüntülenir. Used değeri %75'in altında olmalı. Eğer %80'e yaklaşmışsa, eski logların dışa aktarılması (export) veya arşivlenmesi gerekir. Sophos, varsayılan olarak disk dolarsa en eski logları siler — bu 5651 açısından kabul edilemez.

NextLog bulut kontrol: NextLog yönetim panelinde Dashboard → Depolama Durumu bölümünden anlık kullanım ve kalan kapasite görüntülenir. Bulut sistemlerde otomatik ölçeklendirme (auto-scaling) olsa da, beklenmedik trafik artışı (örn. kongre, festival) öncesi kapasite artırımı talep edilmelidir. Cuma günü bu kontrol, Pazartesi sabahı "disk dolu" alarmıyla karşılaşmayı önler.

3. Yedekleme (Backup) Durumu ve Kurtarma Testi

5651 logları, yalnızca saklanmakla kalmaz, denetim veya mahkeme talebi durumunda hızla sunulabilir olmalıdır. Hafta sonu öncesi yedekleme kontrolü, olası donanım arızası veya siber saldırıya karşı koruma sağlar.

Günlük otomatik yedekleme: Log sunucusu veya firewall, her gece 02:00'de otomatik yedekleme yapmalı. Yedekler, farklı bir fiziksel konumda (off-site) veya bulut depolamada (AWS S3, Azure Blob) saklanmalıdır. Cuma akşamı, son 7 günün yedeklerinin başarıyla tamamlandığını kontrol edin.

FortiGate yedekleme: Log & Report → Log Settings → Remote Logging and Archiving bölümünden syslog veya FortiAnalyzer entegrasyonu doğrulanır. get log memory setting komutuyla yerel log saklama süresi görüntülenir. Uzun süreli saklama için mutlaka uzak sunucuya (syslog server veya FortiAnalyzer) gönderim aktif olmalı.

MikroTik yedekleme: System → Logging menüsünden Remote action tanımlanır ve bir syslog sunucusuna (örn. 192.168.1.100:514) log gönderimi yapılır. Cuma akşamı, syslog sunucusunda MikroTik'ten gelen son logların tarih/saatini kontrol edin. Eğer son log 2 saat öncesine aitse, bağlantı kopuktur.

Gerçek senaryo: Bir AVM'nin MikroTik router'ı, Cuma sabahı syslog sunucusuna erişimi kaybetmiş, ancak IT ekibi hafta sonuna kadar fark etmemiş. Pazartesi sabahı 3 günlük log eksikliği tespit edilmiş. Eğer Cuma akşamı yedekleme kontrolü yapılsaydı, sorun anında çözülürdü.

4. Firewall Kural ve Politika Güncelliği

5651 loglama, yalnızca kayıt tutmakla kalmaz; hangi trafiğin loglanacağını belirleyen firewall kurallarının doğruluğu da kritiktir. Hafta sonu öncesi, log politikalarının güncel olduğundan emin olun.

SonicWall kontrol: Policy → Rules and Policies → Access Rules menüsünden tüm kuralların Log sütununda Yes işaretli olduğunu doğrulayın. Özellikle LAN to WAN ve Guest to WAN kuralları mutlaka loglanmalı. Eğer bir kural Log: No gösteriyorsa, düzenleyin ve Enable Logging seçeneğini aktif edin.

Sophos XG kontrol: Protect → Rules and Policies → Firewall Rules bölümünden her kuralın Log Firewall Traffic kutucuğu işaretli olmalı. Ayrıca, Log Settings → Syslog bölümünden uzak sunucuya gönderim yapılandırması doğrulanır. Sophos, varsayılan olarak yalnızca deny trafiğini loglar; allow trafiği de loglanmalıdır (5651 gereksinimi).

5. Hotspot Entegrasyonu ve PMS Senkronizasyonu (Otel/AVM)

Otellerde, misafir WiFi sistemi (hotspot) genellikle otel yönetim sistemiyle (PMS: Opera, Elektraweb, Amonra) entegre çalışır. Check-in/check-out bilgileri otomatik senkronize olur ve 5651 loglarına yansır. Hafta sonu öncesi bu entegrasyonun çalıştığından emin olun.

Opera PMS entegrasyonu: NextLog gibi bulut sistemler, Opera'nın OHIP (Opera Hospitality Integration Platform) API'si üzerinden gerçek zamanlı senkronizasyon yapar. Cuma akşamı, NextLog panelinde son check-in/check-out kayıtlarının zamanında güncellendiğini kontrol edin. Eğer son güncelleme 2 saat öncesine aitse, API bağlantısı kopuktur.

Elektraweb entegrasyonu: Elektraweb, genellikle XML-RPC veya REST API üzerinden entegre olur. NextLog panelinde Entegrasyonlar → PMS Durumu bölümünden son senkronizasyon zamanı ve hata logları görüntülenir. Eğer "Connection timeout" hatası varsa, Elektraweb sunucusunun firewall kurallarını kontrol edin (genellikle port 8080 veya 443).

Amonra entegrasyonu: Amonra, yerel ağda çalışan bir sistemdir ve genellikle VPN üzerinden bulut sistemlere bağlanır. Cuma akşamı VPN tünelinin aktif olduğunu ve Amonra veritabanına erişimin kesintisiz olduğunu doğrulayın. Amonra'da son misafir kaydının NextLog'da göründüğünü manuel olarak kontrol edin.

Hafta Sonu Senaryoları ve Proaktif Önlemler

Senaryo 1: Elektrik Kesintisi ve UPS Süresi

Hafta sonu, özellikle Pazar günü, planlı elektrik kesintileri sık yaşanır. Firewall ve log sunucusu, kesinti sırasında UPS (kesintisiz güç kaynağı) ile çalışmalıdır. Ancak UPS'in süresi sınırlıdır (genellikle 30-60 dakika). Cuma akşamı UPS testini yapın: elektrik girişini kesin ve sistemin ne kadar süre ayakta kaldığını ölçün. Eğer UPS süresi 30 dakikadan azsa, yeni batarya veya daha güçlü UPS gereklidir.

Otomatik kapatma (graceful shutdown): UPS'e bağlı sistemler, batarya %10'a düştüğünde otomatik olarak güvenli kapatma yapmalı. FortiGate ve Sophos, UPS'ten SNMP veya USB üzerinden sinyal alabilir ve kendini kapatabilir. Bu ayarı Cuma akşamı test edin.

Senaryo 2: Yoğun Trafik ve Log Overflow

Bazı işletmelerde (örn. kongre oteli, festival alanı) hafta sonu trafik beklenmedik şekilde artar. Log sistemi, saniyede 1000+ bağlantıyı kaydetmeye hazır olmalıdır. Cuma akşamı, log yazma hızını (write speed) ve sistem kaynaklarını (CPU, RAM) kontrol edin.

FortiGate performans: CLI'da get system performance status komutuyla CPU ve memory kullanımı görüntülenir. CPU %80'in üzerindeyse, log filtreleme (örn. DNS query loglarını devre dışı bırakma) veya donanım yükseltmesi gerekir. Log disk yazma hızı, diagnose sys logdisk usage komutuyla kontrol edilir.

Senaryo 3: Siber Saldırı ve Log Manipülasyonu

DDoS saldırısı veya ransomware, log sistemini hedef alabilir. Hafta sonu IT ekibi sahada olmadığı için, saldırı Pazartesi'ye kadar fark edilmeyebilir. Cuma akşamı, log sunucusunun güvenlik duvarı kurallarını ve erişim kontrolünü (ACL) gözden geçirin. Log sunucusuna yalnızca firewall ve yönetim IP'lerinden erişim izni verilmelidir.

Log bütünlüğü (integrity): NextLog gibi bulut sistemler, blockchain benzeri hash zinciri kullanarak log manipülasyonunu önler. On-premise sistemlerde, syslog-ng veya rsyslog, her log satırına dijital imza ekleyebilir. Cuma akşamı, bu özelliğin aktif olduğunu doğrulayın.

Denetim Hazırlığı: BTK Talebi Simülasyonu

BTK, genellikle 48 saat içinde log teslimi talep eder. Hafta sonu bir talep gelirse, Pazartesi sabahı yanıt vermeniz gerekir. Cuma akşamı, denetim simülasyonu yapın: belirli bir tarih aralığı (örn. son 30 gün) ve kullanıcı (örn. oda 305) için log sorgulayın. Sonuç 10 saniyeden uzun sürerse, veritabanı indeksleme veya sorgu optimizasyonu gerekir.

NextLog sorgu testi: Yönetim panelinde Raporlar → Gelişmiş Sorgu bölümünden şu filtreleri uygulayın: Tarih aralığı (01.01.2024 - 31.01.2024), Kullanıcı kimliği (TC: 12345678901), IP adresi (192.168.1.50). Sorgu 5 saniyeden kısa sürede sonuç vermeli ve CSV/PDF formatında dışa aktarılabilmeli. Eğer sorgu zaman aşımına uğrarsa, veritabanı bakımı (vacuum, reindex) gerekir.

Pazartesi Sabahı İlk Kontroller

Cuma akşamı tüm kontrolleri yapsanız bile, Pazartesi sabahı ilk iş olarak sistemleri tekrar gözden geçirin. Hafta sonu boyunca bir sorun yaşanmış olabilir. Şu adımları izleyin:

1. Log sürekliliği kontrolü: Cuma 17:00 ile Pazartesi 09:00 arasında log kaydında boşluk olup olmadığını kontrol edin. NextLog panelinde Raporlar → Zaman Serisi Analizi bölümünden saat bazlı log sayısını grafik olarak görü