Hosting ve E‑Posta Altyapısında Log Saklama Süreleri

Hosting ve E‑Posta Altyapısında Log Saklama Süreleri Neden Bu Kadar Önemli?

Bir web sitesi veya e‑posta altyapısı işlettiğiniz anda, aslında farkında olmadan ciddi bir log yönetimi sorumluluğunu da üstlenmiş oluyorsunuz. Web sunucusu erişim kayıtları, e‑posta gönderim/teslim logları, kontrol paneli giriş kayıtları, güvenlik duvarı ve saldırı tespit logları… Hepsi hem işletmenizin teknik sürekliliği hem de KVKK/GDPR uyumu ve hukuki delil açısından kritik.

Bir tarafta "İhtiyacımız olduğunda delil olsun, olabildiğince uzun süre saklayalım" yaklaşımı; diğer tarafta ise "KVKK veri minimizasyonu, unutulma hakkı ve gereğinden fazla saklama yasağı" var. Üstüne bir de 5651 gibi, özellikle Türkiye'deki hosting ve erişim sağlayıcılar için log saklama sürelerini zorunlu kılan mevzuat ekleniyor. Sonuç: Teknik, hukuki ve operasyonel gerçekleri dengeleyen, bilinçli bir log saklama politikası kurmak zorunlu hale geliyor.

Bu yazıda, DCHost ekibi olarak günlük operasyonlarımızda sıkça karşılaştığımız sorulardan yola çıkarak, hosting ve e‑posta altyapısında log saklama sürelerini nasıl belirlemeniz gerektiğini; KVKK/GDPR, 5651 ve hukuki delil değeri perspektifinden adım adım anlatacağız. Son bölümde ise DCHost üzerindeki paylaşımlı hosting, VPS, dedicated ve colocation ortamlarınızda pratik olarak nasıl bir yol izleyebileceğinizi özetleyeceğiz.

Hosting ve E‑Posta Altyapısında Hangi Loglar Üretiliyor?

Önce neyi sakladığımızı netleştirelim. Çoğu işletme "log" deyince sadece web sunucusu erişim kayıtlarını düşünüyor; oysa hosting ve e‑posta altyapısında çok daha geniş bir yelpaze var.

Web hosting tarafında tipik log türleri

• Web sunucusu erişim logları (Apache/Nginx access log): IP adresi, tarih-saat, istenen URL, HTTP durum kodu, user-agent, referrer vb.
• Web sunucusu hata logları (error log): Uygulama hataları, PHP fatal error, 500 hataları, konfigürasyon sorunları.
• Uygulama logları: Örneğin WordPress, Laravel, Magento gibi uygulamaların kendi hata ve debug logları.
• Veritabanı logları: Yavaş sorgu logları, bağlantı hataları, erişim kayıtları.
• Güvenlik logları: WAF (Web Application Firewall), güvenlik eklentileri, brute force tespitleri, Captcha/engelleme kayıtları.
• Kontrol paneli logları: cPanel/DirectAdmin/Plesk’e giriş denemeleri, şifre hataları, yetki değişiklikleri.

Bu logların önemli bir kısmı, ziyaretçi IP adresi, kullanıcı hesabı, e‑posta adresi, kullanıcı adı gibi kişisel veri barındırdığı için KVKK/GDPR kapsamına doğrudan girer.

E‑posta altyapısında üretilen log türleri

• SMTP transaction logları: Kimden kime (MAIL FROM / RCPT TO), tarih-saat, IP adresi, SMTP durum kodu, hata mesajı.
• IMAP/POP3 erişim logları: Kullanıcı adı, istemci IP adresi, login başarısı/başarısızlığı, bağlantı süresi.
• Webmail erişim logları: Tarayıcı üzerinden e‑posta kutusuna giriş logları.
• Spam/antivirüs logları: Mesajın spam puanı, karantina bilgileri, zararlı ek tespitleri.

E‑posta tarafında loglar, hem teslim edilebilirlik hem de hukuki uyuşmazlıklar açısından çok kritik. Bir e‑postanın gerçekten gönderilip gönderilmediğini, hedef sunucu tarafından kabul edilip edilmediğini çoğu zaman ancak bu loglar üzerinden ispatlayabiliyorsunuz. Bu konuyu daha teknik açıdan merak ediyorsanız, SMTP hata kodları ve bounce mesajları rehberi yazımızı da mutlaka okumanızı öneririm.

Altyapı ve güvenlik seviyesindeki loglar

• Sunucu sistem logları (syslog/journal): Servis başlangıç/bitirişleri, kernel mesajları, hatalar.
• SSH/RDP erişim logları: Yönetici giriş denemeleri, başarısız login’ler, IP bazlı denemeler.
• Güvenlik duvarı (firewall) logları: Engellenen bağlantılar, saldırı girişimleri, port taramaları.
• DDoS/WAF logları: Saldırı türü, kaynak IP blokları, oran sınırlama kayıtları.

Özellikle VPS ve dedicated sunucu kullanan müşterilerimiz için, bu logları merkezi bir yerde toplayıp saklama konusu giderek daha önemli hale geliyor. Bunun için pratik bir yaklaşımı VPS log yönetimi ve merkezi loglama rehberi yazımızda detaylı anlatmıştık.

KVKK ve GDPR Açısından Logların Hukuki Statüsü

Logların çoğu, tek başına veya başka verilerle birleştirildiğinde gerçek bir kişiyi tanımlayabildiği için kişisel veri sayılır. Dolayısıyla 6698 sayılı KVKK ve Avrupa’daki kullanıcılar için GDPR kapsamındadır.

Veri sorumlusu ve veri işleyen ayrımı

• Veri sorumlusu: Genellikle web sitesi/e‑posta hizmetini yürüten işletme, yani "müşterimiz" (örneğin e‑ticaret şirketi, ajans, SaaS sağlayıcısı).
• Veri işleyen: Altyapıyı sağlayan DCHost gibi hosting firmaları. Müşteri adına ve talimatları çerçevesinde logları işler.

Bu ayrım önemli çünkü log saklama süresinin son karar noktası veri sorumlusudur; ancak veri işleyen olarak DCHost’un da uyması gereken yasal zorunluluklar ve saklama süreleri vardır (örneğin 5651 kapsamındaki trafik logları).

Hangi hukuki sebeple log tutabilirsiniz?

KVKK ve GDPR çerçevesinde log tutmanın genellikle dayandığı hukuki sebepler şunlardır:

• Kanuni yükümlülük: 5651 ve ilgili ikincil mevzuat nedeniyle trafik loglarının belirli sürelerle tutulması.
• Sözleşmenin ifası: Hizmet sözleşmesinin yürütülebilmesi için teknik zorunluluk olan loglar (örneğin servis sürekliliğini sağlamak, arıza gidermek).
• Meşru menfaat: Güvenlik, dolandırıcılık önleme, saldırı tespiti gibi gerekçelerle sınırlı ve dengeli log tutulması.

Dikkat edilmesi gereken nokta, her log türü için ayrı ayrı "Neden tutuyorum?" ve "Ne kadar süreyle gerçekten gerekiyor?" sorularını cevaplayabilmek ve bunu aydınlatma metinlerine ve veri envanterine yansıtmak. Bu konuyu daha geniş KVKK perspektifinden ele aldığımız KVKK ve GDPR uyumlu hosting rehberi yazımızı da inceleyebilirsiniz.

Saklama süresi ilkesi: "Gerektiği kadar, ama daha fazlası değil"

Hem KVKK hem GDPR, kişisel verilerin amacı gerçekleştirmek için gerekli olandan daha uzun süre saklanamayacağını açıkça söylüyor. Bu ilke loglar için de geçerli:

• Yasal zorunluluk varsa asgari süreyi karşılamak zorundasınız.
• Bu sürenin çok üzerine çıkmak için ayrıca güçlü bir gerekçe (örneğin özel risk durumu, uzun zamana yayılan dolandırıcılık vakaları) gösterebilmelisiniz.
• Amaç sona erdiğinde veya süre dolduğunda logları silmeniz veya anonimleştirmeniz gerekir.

Hukuki Delil Olarak Loglar: Hangi Özellikler Kritik?

Logları sadece KVKK/GDPR riski olarak görmek de, sadece "ileride lazım olur" diye sınırsız saklamak da eksik bir yaklaşım. Özellikle ticari uyuşmazlıklar, fikri mülkiyet ihlalleri, siber saldırılar, haksız fesih davaları gibi durumlarda loglar ciddi delil değeri taşıyabiliyor. Ancak bunun için bazı teknik gerekliliklerin karşılanması şart.

Zaman damgası ve saat senkronizasyonu

• Tüm sunucularınızın NTP ile güvenilir bir zaman kaynağına senkron olması gerekir.
• Loglarda tarih-saat alanları net olmalı, mümkünse UTC veya timezone’u açıkça belirtilmelidir.
• Mahkemede "Bu olay şu saatte oldu" dediğinizde, sunucu saatinin gerçekte neyi ifade ettiği tartışma konusu olmamalıdır.

Bütünlük (integrity) ve değişmezlik

• Özellikle güvenlik ve trafik logları için WORM benzeri (Write Once Read Many) mantıkta, sonradan değiştirilemeyecek yapılar tercih edilmelidir.
• Log dosyaları periyodik olarak hash’lenip (ör. SHA‑256) hash değerleri bağımsız bir yerde saklanabilir.
• Merkezi loglama çözümlerinde (örneğin Loki, Elasticsearch vb.) erişim kayıtları ve değişiklik logları saklanmalıdır.

Bu başlık, gözlemlenebilirlik ve merkezi log yönetimiyle de yakından ilişkili. Daha derin teknik kurulum örnekleri için merkezi loglama ve gözlemlenebilirlik rehberi yazımıza da göz atabilirsiniz.

Kimlik doğrulama ve yetki ayrımı

• Loglara erişen kişiler net bir şekilde tanımlanmalı; mümkünse kişisel kullanıcı hesapları kullanılmalı, paylaşımlı "admin" hesaplarından kaçınılmalıdır.
• Kim "görüntüleme" yetkisine, kim "dışa aktarma" yetkisine, kim "saklama süresini değiştirme" yetkisine sahip; açıkça tanımlanmalı.
• Loglar üzerinde manuel düzenleme yapılması teknik olarak da, prosedürel olarak da engellenmelidir.

Log Saklama Sürelerini Belirlerken Dikkate Alınacak Kriterler

Tek bir "doğru" log saklama süresi yok. Her işletmenin sektörü, hukuki yükümlülükleri, müşteri kitlesi ve risk profili farklı. Yine de aşağıdaki kriterler üzerinden sistematik bir değerlendirme yapılabilir.

1. Yasal zorunluluklar (5651, KVKK, sektör mevzuatı)

• 5651 sayılı Kanun ve ilgili yönetmelikler, Türkiye’deki erişim ve yer sağlayıcılar için trafik loglarının asgari saklama sürelerini belirler (örneğin yer sağlayıcılar için genellikle 1 yıl).
• Buna ek olarak finans, telekom, sağlık gibi bazı sektörlerde log saklama sürelerini etkileyen özel düzenlemeler olabilir.
• Kendi sektörünüz için hukuk danışmanınızla birlikte zorunlu asgari süreleri netleştirin; bu sürelerin altına zaten inemezsiniz.

2. Operasyonel ihtiyaçlar (destek, hata ayıklama, performans)

• Hata ayıklamak, performans sorunlarını analiz etmek, kullanıcı şikayetlerini incelemek için loglara ne kadar geriye dönük ihtiyaç duyuyorsunuz?
• Örneğin yoğun trafik dalgalanmalarını veya kampanya dönemlerini analiz etmek için 3‑6 aylık erişim logları genellikle yeterli olur.
• Debug seviyesindeki detaylı uygulama loglarını ise çoğu zaman birkaç hafta ile sınırlı tutmak idealdir.

3. Güvenlik ve kötüye kullanım riskleri

• Brute force saldırıları, yavaş yavaş işleyen dolandırıcılık girişimleri, içeriden yetki kötüye kullanımı gibi riskler için daha uzun saklama süreleri gerekebilir.
• Özellikle finansal işlemler, sözleşme onayı, hassas veriye erişim gibi eylemler için 2‑3 yıla kadar uzayan güvenlik logları makul olabilir.

4. Hukuki zamanaşımı süreleri

• Ticari uyuşmazlıklar, sözleşmeden doğan alacaklar, haksız fiiller için Türk hukukundaki zamanaşımı süreleri incelenmeli.
• Her durumda tüm logları zamanaşımı süresi kadar saklamak gerekmeyebilir; ancak özellikle kritik işlem logları için böyle bir tercih gerekçelendirilebilir.

5. Maliyet ve ölçeklenebilirlik

• Log boyutları, özellikle yoğun trafikli sitelerde hızla TB seviyelerine çıkabilir.
• Merkezi loglama, sıkıştırma, soğuk depolama ve yaşam döngüsü (lifecycle) politikaları ile maliyet yönetimi şarttır.
• Bu noktada hosting maliyetlerini düşürme ve depolama planlama rehberimizdeki genel yaklaşımlardan da faydalanabilirsiniz.

Örnek Log Saklama Süreleri: Hosting ve E‑Posta İçin Pratik Matris

Aşağıdaki tablo, DCHost ortamında sık gördüğümüz kullanım senaryolarına göre hazırlanmış, genel bilgilendirme amaçlı bir matristsir. Kesin hukuki tavsiye niteliği taşımaz; kendi hukuk danışmanınızla birlikte değerlendirmeniz gerekir.

Yine altını çizelim: Bunlar örnek aralıklar. Örneğin bir hukuk bürosu, müvekkil uyuşmazlıkları ve zamanaşımı sürelerini gerekçe göstererek bazı log türleri için daha uzun saklama süreleri tercih edebilir. Bu tür hassas senaryolara özel olarak, hukuk büroları için güvenli hosting rehberimizi okumanız faydalı olacaktır.

KVKK/GDPR Uyumlu Log Yönetimi İçin En İyi Uygulamalar

Sadece süre belirlemek yetmez; logların toplanma, saklanma, erişim ve silinme şekli de uyum açısından en az süre kadar önemli.

1. Logları kategorize edin ve amaçlarını yazılı hale getirin

• Her log türü için ayrı bir kayıt oluşturun: "Web erişim logu", "SMTP teslim logu", "SSH erişim logu" gibi.
• Yanına işleme amacını (güvenlik, hata ayıklama, istatistik, hukuki delil vb.) yazın.
• Bu kayıtları veri envanterinize ve aydınlatma metinlerinize yansıtın.

2. Veri minimizasyonu: Gerekli olmayan alanları loglamayın

• Uygulama loglarınızda şifre, kredi kartı numarası, TC kimlik numarası gibi hassas verilerin asla düz metin olarak yer almamasını sağlayın.
• Mümkün olduğunda IP adreslerini maskeleme (ör. IPv4 son okteti sıfırlama) veya anonimleştirme tekniklerini değerlendirin.
• Debug moddayken çok detaylı log üretip, bu modu üretim ortamında açık unutmayın.

3. Merkezi loglama, rotasyon ve yaşam döngüsü politikaları

• VPS ve dedicated sunucularda logları tek tek sunucularda tutmak yerine merkezi log sistemine akıtın.
• Log rotasyon (logrotate, systemd journal rotation vb.) politikalarıyla disk dolmasını ve log birikmesini kontrol edin.
• Merkezi sisteminizde "hot" (sık erişilen, kısa süreli), "warm" (orta vadeli), "cold" (uzun süreli ama seyrek erişilen) katmanlar tanımlayın.

Bunların pratik kurulum örneklerini, adım adım komutlarla anlattığımız VPS log yönetimi rehberi yazımızda bulabilirsiniz.

4. Erişim kontrolü ve yetki matrisleri

• Log sistemine kimlerin erişebileceğini iş rolüne göre belirleyin (geliştirici, sistem yöneticisi, güvenlik ekibi, hukuk vb.).
• Her erişim türünü (görüntüleme, dışa aktarma, silme, saklama süresini değiştirme) ayrı ayrı kısıtlayın.
• Erişim loglarının da loglandığından ve makul sürelerle saklandığından emin olun.

5. Silme ve anonimleştirme süreçlerini gerçekten uygulayın

• Politikada "90 gün saklıyoruz" yazmak yetmez; 90 günden eski logların gerçekten silindiğini veya anonimleştirildiğini ispatlayabilmelisiniz.
• Otomatik yaşam döngüsü (lifecycle) kuralları, zamanlanmış görevler (cron/systemd timer) ve periyodik denetimlerle bu süreci güvenceye alın.
• Kişisel verisi işlenen kişiden gelen "silme/unutulma" talepleri için log sisteminde ne yapacağınızı prosedür haline getirin.

E‑Posta Altyapısında Özel Durumlar ve Hassas Noktalar

E‑posta logları, hem içerdiği kişisel veri türleri hem de uyuşmazlıklarda delil olarak kullanılma sıklığı nedeniyle özel bir başlık açılmayı hak ediyor.

İçerik logu ≠ iletim logu

• İletim/transaction logu: "Şu tarihte, şu IP’den, şu e‑posta adresinden, şu alıcıya, şu SMTP koduyla iletildi/iletilmedi" bilgisi.
• İçerik: E‑postanın konu satırı, gövde metni, ekler.

Genel iyi uygulama, içeriği uzun süre saklamamak; iletim loglarını ise makul bir süre tutmaktır. İçerik tarafında uzun saklama gerekiyorsa, bu artık log değil, ayrı bir arşivleme politikası (ayrı hukuki değerlendirmeyle) gerektirir.

Teslim edilebilirlik ve itibar yönetimi

SMTP logları; blacklist şikayetleri, spam iddiaları ve mahkeme aşamasına gidebilen "Bu e‑postayı göndermedik" tartışmalarında ana dayanağınızdır. Ayrıca IP ve domain itibarınızı korumak için de kritik. Bu konularda detaylı bir saha rehberine ihtiyaç duyuyorsanız, e‑posta itibarını kurtarma rehberi yazımızı mutlaka inceleyin.

Spam, istismar ve hukuki başvurular

• Bir kullanıcı hesabı üzerinden spam gönderimi yapıldığında, hangi tarihte, hangi IP’den, hangi alıcılara ne hızla gönderim yapıldığını gösteren loglar, hem teknik temizlik hem de hukuki sorumluluk açısından önemlidir.
• İstismar (abuse) şikayetlerinde, ilgili logların olay bazlı dondurulması (normal rotasyondan muaf tutulması) iyi bir pratiktir.

DCHost Ortamında Log Saklama Stratejinizi Nasıl Kurabilirsiniz?

DCHost olarak hem paylaşımlı hosting hem de VPS, dedicated ve colocation hizmetlerinde log yönetimi konusunda esnek ama uyumlu bir çerçeve sunmaya çalışıyoruz. Müşterilerimizin önemli bir kısmı KVKK/GDPR, PCI‑DSS veya sektör regülasyonları nedeniyle farklı ihtiyaçlara sahip.

Paylaşımlı hosting ortamlarında

• Web sunucusu, e‑posta ve panel logları altyapı seviyesinde tutulur ve belirli rotasyon politikalarına tabidir.
• Varsayılan saklama süreleri, hem 5651 yükümlülüklerini hem de disk/maliyet dengesini gözetir.
• Özel bir hukuki ihtiyacınız varsa (örneğin belirli bir domain için daha uzun erişim logu saklama), destek ekibimizle görüşerek projeye özel çözümler isteyebilirsiniz.

VPS ve dedicated sunucularda

• Sunucu üzerine kurduğunuz işletim sistemi ve uygulamaların log saklama politikası esas olarak sizin kontrolünüzdedir.
• DCHost olarak altyapı (network, hypervisor, storage) seviyesinde loglama yaparız; bu loglar KVKK ve 5651 çerçevesinde, mevzuata uygun sürelerle saklanır.
• Kendi sunucularınızda merkezi loglama kurmak için Grafana Loki + Promtail ile merkezi loglama rehberimizi bire bir uygulayabilirsiniz.

Colocation müşterileri için

• Sunucuların fiziksel olarak size ait olduğu colocation senaryosunda, işletim sistemi ve uygulama loglarından doğrudan siz sorumlusunuz.
• DCHost veri merkezi seviyesinde (güvenlik kamerası, erişim kontrolü, çevresel sensörler, ağ alt yapısı vb.) loglar üretir ve bunları ilgili mevzuata ve iç politikalarımıza göre saklar.
• Bu logların belirli olaylar özelinde sizinle paylaşılması, sözleşme ve mevzuat çerçevesinde, güvenli kanallar üzerinden yapılır.

Politikanızı yazılı hale getirin ve güncel tutun

• Log saklama stratejinizi iç politika dokümanı olarak yazın: Hangi log, nerede tutuluyor, kim erişebiliyor, ne kadar süreyle saklanıyor, nasıl siliniyor?
• Bu dokümanı yılda en az bir kez gözden geçirerek yeni regülasyonlar, altyapı değişiklikleri ve iş ihtiyaçlarına göre güncelleyin.
• Özellikle e‑ticaret, SaaS ve kurumsal siteler için, log politikası; yedekleme ve felaket kurtarma planlarının doğal bir parçası olmalıdır. Bu bağlamda 3‑2‑1 yedekleme stratejisi yazımız da iyi bir tamamlayıcıdır.

Sonuç ve Yol Haritası

Hosting ve e‑posta altyapısında log saklama süreleri, "kaç gün dursun?" sorusundan çok daha fazlası. Hem KVKK/GDPR, hem 5651, hem de hukuki delil ihtiyacı, teknik imkânlar ve maliyet gerçeği bir araya geldiğinde, üzerinde düşünülmüş, yazılı ve uygulanabilir bir log yönetim politikasına ihtiyaç olduğu netleşiyor.

Özetlemek gerekirse:

• Hangi logları ürettiğinizi ve hangi kişisel verileri içerdiğini netleştirin.
• Her log türü için hukuki dayanak ve işleme amacını tanımlayın.
• Yasal zorunlulukları, operasyonel ihtiyaçları ve güvenlik risklerini dengeleyerek makul saklama süreleri belirleyin.
• Merkezi loglama, rotasyon, erişim kontrolü ve otomatik silme/anonimleştirme mekanizmalarını devreye alın.
• Politikanızı yazılı hale getirip, düzenli olarak gözden geçirin.

Eğer DCHost üzerinde paylaşımlı hosting, VPS, dedicated veya colocation hizmeti kullanıyor ve "Log saklama sürelerimizi KVKK/GDPR ve hukuki delil açısından en sağlıklı noktaya nasıl çekeriz?" diye düşünüyorsanız, altyapınızı ve kullanım senaryonuzu birlikte değerlendirip size uygun bir yol haritası çıkarmaktan memnuniyet duyarız. İsterseniz önce ilgili diğer yazılarımızı (özellikle KVKK/GDPR uyumlu hosting ve merkezi log yönetimi) inceleyebilir, ardından ekibimizle doğrudan iletişime geçebilirsiniz.

Doğru tasarlanmış bir log saklama stratejisi, hem hukuki riskinizi azaltır hem de sorun yaşadığınızda elinizi güçlendirir. En kritik nokta ise şu: Loglarınızın varlığı kadar, doğruluğu, bütünlüğü ve yönetilebilirliği de önemlidir. Altyapınızı buna göre kurguladığınızda, hem KVKK/GDPR tarafında içiniz daha rahat olur hem de teknik ekibinizin işi ciddi anlamda kolaylaşır.