Blog Details

Şirketler Neden 5651 ve KVKK Uyumlu Log Tutmalı?

Log yönetimi çoğu şirkette “IT’nin teknik işi” gibi görülür; bu yaklaşım yanlış. Log, kurumun hafızasıdır. Bir olay olduğunda (sızma, içeriden veri sızıntısı, hesap ele geçirme, fidye yazılımı, hukuki ihtilaf), “ne oldu?” sorusunu cevaplayan tek somut kaynak çoğu zaman loglardır. 5651 kapsamındaki trafik kayıtları ve KVKK kapsamında kişisel veri sayılabilecek loglar doğru yönetilmezse, kurum hem uyum hem de güvenlik açısından savunmasız kalır.

1) 5651 neden log ister? (işin özü)

5651 sayılı düzenlemeler, internet erişimi ve trafik bilgilerinin kayıt altına alınmasını hedefler. Şirketler çalışanlarına veya misafirlerine internet erişimi sağladığında, belirli durumlarda “bu erişim hangi kullanıcıya aitti?” sorusuna cevap verebilecek bir kayıt düzeni gerekir. Buradaki amaç; olay sonrası izlenebilirlik, gerektiğinde ispat ve adli süreçlerde delil niteliği taşıyabilecek kayıtların varlığıdır.

Pratikte bu, yalnızca “log var” demek değildir. Logların düzenli üretildiği, güvenli saklandığı, bozulmadan/kurcalanmadan korunabildiği ve talep edildiğinde geriye dönük erişilebilir olduğu bir işletim modeli gerekir.

2) KVKK loglara nasıl bakar? (kişisel veri gerçeği)

KVKK açısından loglar çoğu zaman kişisel veri ile kesişir. IP adresi, kullanıcı adı/ID, cihaz bilgisi, konum/zaman bilgisi, erişilen kaynaklar ve yapılan işlemler; tek başına veya diğer verilerle birleştirildiğinde kişiyi belirlenebilir kılabilir. Bu yüzden loglar, “toplanan veri” olmanın yanında “korunması gereken veri”dir.

3) Uyumlu log tutmamak şirketi nasıl yakar?

Log yoksa veya yanlışsa, kurum üç ayrı cephede zarar görür:

• Hukuki savunma zayıflar: Adli talepte veya denetimde kayıt sunamazsınız; sunulan kayıt delil niteliği taşımaz.
• Olaylar geç fark edilir: Saldırgan içeride günlerce/haftalarca kalabilir; siz sadece “sistem yavaşladı” diye anlarsınız.
• İtibar ve finans kaybı büyür: Kesinti, müşteri kaybı, kriz yönetimi ve ek danışmanlık maliyetleri artar.

4) Siber güvenlikte log: tespit → müdahale → analiz

İyi bir log sistemi; saldırıları “olduktan sonra fark etmek” yerine, çoğunu erken aşamada yakalamayı sağlar. Örneğin:

• Bir kullanıcı hesabında çoklu başarısız girişimler (brute force) artıyorsa, anında alarm üretilir.
• Normalde erişilmeyen bir veri setine gece saatlerinde yüksek hacimli erişim varsa, anomali yakalanır.
• Yetki değişiklikleri, admin panel girişleri, dışa aktarmalar gibi kritik aksiyonlar izlenir.

Loglar ayrıca olay sonrası “kök neden analizi” için gereklidir: hangi hesap ele geçirildi, hangi cihazdan girildi, hangi adımlar izlendi, hangi veriler etkilendi… Bunlar log olmadan tahmin olur.

5) Hangi loglar tutulmalı? (şirketler için pratik kapsam)

“Her şeyi loglayalım” yaklaşımı sizi boğar. Kapsamı akıllı seçin: kritik varlıklar ve kritik veri üzerinden ilerleyin. Başlangıç için en işlevsel sınıflandırma:

5.1 Erişim logları (Access)

• Kimlik doğrulama: login denemeleri, başarısız giriş, MFA olayları, kilitlenen hesaplar
• VPN/uzaktan erişim: kullanıcı, kaynak IP, oturum süresi, bağlantı lokasyonu (varsa)
• Firewall/UTM: izin/verme, engelleme, IPS/IDS alarmları, şüpheli trafik
• DNS/Proxy (varsa): kurumsal internet çıkışındaki kritik sorgu ve erişim kayıtları

5.2 İşlem logları (Application / Transaction)

• CRM/ERP: kayıt güncelleme/silme, dışa aktarma, rol/yetki değişimleri
• Web uygulamaları: admin panel login, ayar değişimi, içerik değişimi
• Dosya sistemleri: okuma/yazma/silme, paylaşım linki oluşturma, yetki verme

5.3 Sistem logları (Infrastructure)

• Sunucu işletim sistemi: kullanıcı ekleme/silme, servis değişiklikleri, güvenlik olayları
• Veritabanı: kritik tablo/alanlarda audit (özellikle kişisel veri içeren yapılar)
• E-posta: şüpheli girişimler, forwarding kuralı gibi anomali davranışlar

6) Logların “uyumlu” olması için olmazsa olmaz teknik ilkeler

Şirketlerin çoğu burada patlar. Çünkü log toplar ama şu 5 temel ilkeyi sağlamaz:

• Zaman senkronizasyonu: Tüm sistemler aynı zaman referansına (NTP) bağlı olmalı; yoksa olay zaman çizelgesi çöker.
• Merkezi toplama: Loglar dağınık kalırsa korelasyon yapılamaz; olaylar görünmez olur.
• Erişim kontrolü: Loglar herkese açık olmamalı; rol bazlı erişim şart (need-to-know).
• Bütünlük/değiştirilemezlik: Loglar kurcalanabiliyorsa delil değeri düşer; güvenlikte de güvenemezsiniz.
• Şifreleme: Hem aktarımda hem depolamada; özellikle KVKK kapsamına girebilecek loglar için.

7) Saklama süresi, silme ve anonimleştirme (KVKK tarafı burada başlar)

En sık yapılan hata “ne olur ne olmaz” diye logları süresiz saklamaktır. Bu, KVKK açısından gereksiz risk büyütür. Doğru yaklaşım:

• Log envanteri çıkarın: hangi log nerede, kim erişiyor, ne amaçla tutuluyor?
• Kategori bazlı saklama belirleyin: erişim logları / uygulama logları / sistem logları için ayrı süre ve gerekçe.
• Silme/anonimleştirme sürecini tanımlayın: amaç bittiğinde otomatik işletin ve raporlayın.

8) En sık hatalar (para yakan hatalar)

• Loglar var ama işe yaramıyor: format tutarsız, zamanlar uyumsuz, olay çizelgesi kurulamıyor.
• Gürültü problemi: her şey loglanıyor ama kritik sinyal görünmüyor (alarm yorgunluğu).
• Yetki kargaşası: loglara kimlerin eriştiği belirsiz; içeriden manipülasyon riski artıyor.
• Denetim izi yok: loglara kim baktı, ne çıkardı, ne değiştirdi belli değil.

9) Hızlı aksiyon planı (kısa ve net)

• 0–3 gün: Log envanteri (hangi sistemde hangi log var/yok, nerede saklanıyor, kim erişiyor?)
• 0–7 gün: Kritik 5 öncelik (kimlik, VPN, firewall, e-posta, CRM/ERP) için standart alan seti
• 1–4 hafta: Merkezi toplama + temel alarm eşikleri + raporlama
• 1–4 hafta: Saklama/silme politikası + otomasyon + silme raporu