5651 Sayılı Kanun: Web Sitem İçin Log Tutmak Zorunda mıyım?

Kurumsal e-posta adresinize gelen yazının konusu kısa: bir savcılık soruşturması kapsamında, geçen yılın nisan ayında sitenizdeki bir forum başlığına gönderilen iletinin hangi IP adresinden yapıldığı soruluyor. Sunucuya bağlanıyorsunuz, /var/log/nginx/ dizinine bakıyorsunuz ve manzara net: logrotate varsayılan ayarlarla çalışıyor, elinizde son 14 günün kaydı var. Nisan ayı çoktan silinmiş.

Bu senaryo tahmin ettiğinizden çok daha yaygın. "5651" numarasını çoğu site sahibi duymuştur; genellikle internet kafeler ve otel misafir ağlarıyla ilişkilendirilir, kendi web sitesiyle bir bağlantı kurulmaz. Oysa kanunun tanımladığı yer sağlayıcı kavramı, "hizmet ve içerikleri barındıran sistemleri sağlayan veya işleten" herkesi kapsar; bu tanımın kendi sunucunuzda çalıştırdığınız bir foruma, üyelik sistemine ya da yorum alanına oturup oturmadığı, çoğu zaman hiç düşünülmemiş bir sorudur.

Bu yazı kanun metnini baştan sona özetlemek yerine pratik bir sınıflandırma yapıyor: üç farklı site profilinden hangisine benziyorsunuz, o profilde yükümlülüğünüz gerçekte nedir, hangi logları hangi süreyle ve hangi bütünlük güvencesiyle saklamanız gerekir, ve bunun sunucu üzerindeki teknik karşılığı nasıl kurulur. Baştan bir not: burada anlatılanlar teknik uygulama rehberidir, hukuki görüş değildir. Yükümlülüğünüzün sınırı tartışmalıysa avukatınıza danışın.

5651 Kimi Bağlıyor? Dört Aktörü Ayırt Etmek#

Kanun internet ortamındaki rolleri dört başlıkta tanımlar ve yükümlülükler bu rollere göre değişir. Kendi konumunuzu doğru yere oturtmadan hiçbir teknik karar anlamlı olmaz.

Kritik ayrım şudur: içerik sağlayıcı olmakla yer sağlayıcı olmak birbirini dışlamaz. Kendi yazdığınız metinleri yayımladığınız bir blog, içerik sağlayıcıdır. Aynı bloga kullanıcı yorumu açtığınız anda, başkasının ürettiği içeriği barındıran bir sistemi işletmeye başlarsınız. Uygulamada tartışma bu sınırda yaşanır ve kesin çizgiyi olay bazında yargı çizer. Teknik tarafta yapılacak makul şey, sınırın hangi tarafında durduğunuzu kendinize dürüstçe sormak ve riskli tarafta duruyorsanız kayıt tutmaya başlamaktır — çünkü sonradan geriye dönük log üretmek mümkün değildir.

Ayrıca yer sağlayıcılar için bildirim yükümlülüğü vardır: faaliyetin BTK'ya bildirilmesi gerekir. Bildirim yapılmadan yer sağlayıcılık faaliyeti yürütüldüğünün tespiti hâlinde idari para cezası öngörülmüştür ve bu tutarlar her yıl yeniden değerleme oranıyla güncellenir. Yani "cezası yok nasılsa" varsayımı, kanunun caydırıcılığı en yüksek olduğu noktada yanlıştır.

Üç Tipik Profil: Siz Hangisisiniz?#

Soyut tanımları kendi kurulumunuza oturtmak için üç yaygın profile bakalım.

Profil 1: Kendi VDS'inizde tek bir kurumsal site#

Bir tanıtım sitesi, bir e-ticaret vitrinini ya da bir portfolyo çalıştırıyorsunuz. Kullanıcıdan alınan tek içerik iletişim formu; yorum, forum, profil, dosya yükleme yok.

Bu profilde birincil rolünüz içerik sağlayıcıdır. Kanunun yer sağlayıcıya yüklediği trafik bilgisi saklama yükümlülüğünün doğrudan muhatabı olmadığınız savunulabilir bir konumdasınız. Buna rağmen erişim loglarını en az bir yıl tutmanız pratikte üç sebeple akıllıcadır: saldırı sonrası olay incelemesi, bir dolandırıcılık iddiasında sipariş IP'sinin ispatı ve ileride kullanıcı içeriği açtığınızda geçmişe dönük boşluk kalmaması. Maliyeti sıkıştırılmış birkaç yüz megabayttır.

Profil 2: Forum, üyelik, yorum — kullanıcı içeriği barındırıyorsunuz#

Sitenizde başkaları içerik üretiyor: forum iletileri, ürün yorumları, ilan girişleri, üye profilleri, yüklenen dosyalar. Bu profilde barındırdığınız içerik artık sizin değildir ve yer sağlayıcı tanımına en çok yaklaşan konum budur.

Burada erişim logu tek başına yeterli değildir. Bir savcılık yazısı "şu iletinin sahibi kim" diye sorduğunda, nginx access log'unuzdaki POST /forum/reply satırı ile veritabanındaki ileti kaydını birbirine bağlayabilmeniz gerekir. Bu bağlantı kurulamıyorsa elinizde milyonlarca satır log olması hiçbir işe yaramaz. Uygulama katmanında ileti kaydına IP ve zaman damgası yazmak, bu profilin en kritik teknik adımıdır.

Profil 3: Müşterilerinize yer sağlıyorsunuz#

Reseller hosting satıyor, müşterileriniz için sunucu yönetiyor ya da bir SaaS ürününde müşterilere kendi alan adlarıyla alan açıyorsanız, tanımın tam ortasındasınız. Yükümlülük en geniş hâliyle burada uygulanır: barındırdığınız her hesap için trafik bilgisi, saklama süresi boyunca erişilebilir olmalı ve bilgilerin doğruluğu, bütünlüğü ve gizliliği güvence altına alınmalıdır.

Bu profilde ek bir sorumluluk daha vardır: müşterilerinizin logları birbirine karışmamalı ve bir müşterinin kaydına diğer müşteri erişememelidir. Paylaşımlı sunucularda hesap bazlı ayrı log dosyaları ve dosya izinleri bu yüzden önemlidir.

Bonus profil: ofisinizin misafir Wi-Fi'si#

Web sitenizle ilgisi yok ama aynı kanuna takılır. Müşterilerinize, ziyaretçilerinize ya da personelinize internet erişimi sunuyorsanız toplu kullanım sağlayıcı konumundasınız. Ticari amaçla faaliyet gösterenler için iç IP dağıtım kayıtlarının elektronik ortamda kaydedilmesi, iki yıl süreyle saklanması ve kaydedilen bilgilerin doğruluğunu, bütünlüğünü ve gizliliğini teyit eden değerin (özet/hash) günlük olarak üretilip saklanması öngörülmüştür. Kafe işleten bir müşterinin "hotspot cihazı loglama yapıyor mu" sorusunu hiç sormamış olması çok sık rastlanan bir durumdur.

Trafik Bilgisi Tam Olarak Nedir? Hangi Alanlar Loglanmalı#

Kanun "log tutun" demez; trafik bilgisi kavramını tanımlar ve bu tanım teknik olarak neyi kaydetmeniz gerektiğini belirler. Tanım tarafların IP adreslerini, verilen hizmetin başlangıç ve bitiş zamanını, yararlanılan hizmetin türünü, aktarılan veri miktarını, varsa abone kimlik bilgilerini ve port bilgisini kapsar.

Bu alanların bir nginx access log satırındaki karşılığı şöyledir:

Port bilgisinin listede olmasının teknik sebebi çoğu zaman gözden kaçar: mobil operatörler ve birçok kurumsal ağ CGNAT kullanır, yani tek bir genel IP adresini aynı anda yüzlerce abone paylaşır. Böyle bir ortamda "şu saatte şu IP'yi kim kullanıyordu" sorusunun tek bir cevabı yoktur; kaynak port bilgisi olmadan abone tekilleştirilemez. Kaynak portunu loglamayan bir kurulum, kâğıt üzerinde kayıt tutuyor ama gerçek bir soruşturmada işe yaramaz veri üretiyor demektir.

Ne Kadar Süre Saklanır?#

Süreler role göre değişir ve bu ayrımı karıştırmak, ya gereksiz yere disk harcamanıza ya da eksik kayıt tutmanıza yol açar.

Pratik yorum: yer sağlayıcı konumundaysanız hedefinizi iki yıl olarak belirlemek en güvenli tercihtir. Bir yıla yakın bir süre seçtiğinizde, soruşturma yazısının gecikmeli gelmesi hâlinde kayıt zaten silinmiş olur; sıkıştırılmış metin loglarının disk maliyeti ise düşünüldüğü kadar yüksek değildir. Günde 200 bin istek alan bir sitenin sıkıştırılmış access log'u kabaca günde 10-15 MB civarındadır; iki yıl için 10 GB'lık bir arşiv alanı fazlasıyla yeter.

Karşı yönde bir sınır da vardır: gereğinden uzun saklamak KVKK açısından sorun yaratır. Süre dolduğunda kayıtların imha edilmesi, saklamak kadar bilinçli bir işlemdir. Bu dengeye yazının sonunda ayrıca döneceğiz.

Bütünlük Güvencesi: Hash ve Zaman Damgası Neden Şart?#

Kanunun ve ilgili düzenlemelerin en çok atlanan kısmı "saklama"dan sonraki kelimelerdir: doğruluğunu, bütünlüğünü ve gizliliğini sağlamak. Elinizdeki access.log dosyası düz metindir; root yetkisi olan herkes bir satırı düzenleyebilir, silebilir, ekleyebilir. Böyle bir dosyanın delil değeri tartışmalıdır — çünkü kaydın olay anında bu hâlde olduğunu gösteren hiçbir kanıt yoktur.

İki ayrı sorunu iki ayrı araçla çözersiniz:

Bütünlük için özet (hash) değeri. Günlük arşivlenen her dosya için SHA-256 özeti üretip ayrı saklarsanız, dosyanın sonradan değiştirilip değiştirilmediği doğrulanabilir hâle gelir.

Zaman için nitelikli zaman damgası. Hash tek başına "bu dosya değişmedi" der ama "bu hash'in ne zaman üretildiğini" ispatlamaz; siz bugün geçmişe dair sahte bir log üretip bugünün hash'ini alabilirsiniz. Bu boşluğu, 5070 sayılı Elektronik İmza Kanunu kapsamında yetkilendirilmiş bir elektronik sertifika hizmet sağlayıcısından alınan nitelikli zaman damgası kapatır. Zaman damgası, hash değerinin belirli bir anda var olduğunu üçüncü taraf güvencesiyle tespit eder.

Pratikte akış şöyle işler: gece yarısı bir önceki günün log dosyası döndürülür ve sıkıştırılır, dosyanın özeti alınır, özet için bir zaman damgası talebi oluşturulup ESHS'nin sunucusuna gönderilir, dönen damga dosyanın yanında saklanır.

#!/usr/bin/env bash
set -euo pipefail

GUN=$(date -d yesterday +%F)
ARSIV=/var/log/arsiv
DOSYA="$ARSIV/access-$GUN.log.gz"
TSA_URL="https://zaman-damgasi-saglayiciniz/tsa"

[ -f "$DOSYA" ] || { echo "arşiv yok: $DOSYA"; exit 1; }

# 1) Bütünlük özeti
sha256sum "$DOSYA" > "$DOSYA.sha256"

# 2) Zaman damgası talebi oluştur
openssl ts -query -data "$DOSYA" -sha256 -cert -out "$DOSYA.tsq"

# 3) ESHS'ye gönder, damgayı al
curl -sS -H "Content-Type: application/timestamp-query" \
     --data-binary "@$DOSYA.tsq" "$TSA_URL" -o "$DOSYA.tsr"

# 4) Damgayı okunur hâlde doğrula
openssl ts -reply -in "$DOSYA.tsr" -text | head -n 12

Doğrulama, denetim anında çalıştıracağınız komuttur:

openssl ts -verify -data /var/log/arsiv/access-2026-04-12.log.gz \
  -in /var/log/arsiv/access-2026-04-12.log.gz.tsr \
  -CAfile /etc/ssl/tsa/eshs-zincir.pem
# Verification: OK

Zaman damgası hizmeti ücretlidir ve genellikle adet bazlı satılır; günde bir damga, yılda 365 adet demektir ve bu maliyet çoğu kurum için önemsizdir. Dosya bütünlüğünü sürekli izlemeyi bu akışla birleştirmek isterseniz dosya bütünlüğü izleme yazısındaki yaklaşım tamamlayıcı olur.

Gizlilik ayağı ise erişim kontrolüyle sağlanır: arşiv dizini yalnızca yetkili kullanıcı tarafından okunabilmeli, yedeklere giden kopyalar şifrelenmelidir. LUKS ile disk şifreleme veya arşivleri GPG ile şifreleyip saklamak, bu maddenin pratik karşılığıdır.

Sunucuda Teknik Karşılığı: Nginx ve Logrotate#

Şimdi kavramları çalışan bir yapılandırmaya dökelim. Varsayılan nginx log formatı port bilgisini içermez; ilk iş formatı genişletmektir.

# /etc/nginx/nginx.conf -> http bloğu

log_format yasal '$time_iso8601|$remote_addr|$remote_port|'
                 '$server_addr|$server_port|$host|'
                 '$request_method|$request_uri|$server_protocol|'
                 '$status|$request_length|$body_bytes_sent|'
                 '$request_time|$http_x_forwarded_for|"$http_user_agent"';

access_log /var/log/nginx/access.log yasal;

Sunucunuz bir CDN ya da yük dengeleyicinin arkasındaysa $remote_addr proxy'nin adresidir; bu hâliyle kaydettiğiniz IP hiçbir aboneyi işaret etmez. Gerçek istemciyi çözmek zorunludur:

set_real_ip_from 10.0.0.0/8;      # yük dengeleyici ağınız
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Sonra döndürme politikası. Varsayılan logrotate ayarı çoğu dağıtımda 14 gün tutar — yani yükümlülüğünüzün yüzde biri kadar. İki yıllık saklama için:

# /etc/logrotate.d/nginx-yasal
/var/log/nginx/*.log {
    daily
    rotate 760
    dateext
    dateformat -%Y-%m-%d
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    olddir /var/log/arsiv
    sharedscripts
    postrotate
        [ -f /run/nginx.pid ] && kill -USR1 "$(cat /run/nginx.pid)"
    endscript
}

rotate 760 yaklaşık iki yıl artı emniyet payı demektir. dateext sayesinde dosya adları access.log-2026-04-12.gz biçiminde tarih taşır; access.log.37 gibi sıra numaralı adlarla bir soruşturma yazısındaki tarihi eşleştirmeye çalışmak gereksiz bir işkencedir. olddir arşivi ayrı bir dizine (ideal olarak ayrı bir birime) taşır, böylece /var/log dolduğunda servisler durmaz. Döndürme mantığının ayrıntıları için logrotate ile log yönetimi yazısına bakabilirsiniz.

Sistem servislerinin logları journald tarafında ayrı yaşar ve varsayılan olarak boyuta göre budanır; kalıcı saklama istiyorsanız Storage=persistent ve MaxRetentionSec ayarlarını gözden geçirin — journalctl ile log yönetimi bu tarafı ele alıyor.

Sunucu saatini ciddiye alın#

Zaman bilgisi doğru değilse kaydın delil değeri düşer. Saat senkronizasyonunu doğrulamak tek komutluk iştir:

timedatectl status
chronyc tracking | grep -E 'Reference|System time|Stratum'

System time sapması milisaniye mertebesinde olmalıdır. Sanal sunucularda uzun süreli askıya alma sonrası saat kayabilir; izleme sisteminize bu metriği eklemek iyi bir alışkanlıktır.

Uygulama katmanı: asıl eksik olan parça#

Kullanıcı içeriği barındıran bir sitede web sunucusu logu tek başına yetersizdir. Veritabanında şu alanların bulunması gerekir: kayıt anındaki IP ve zaman, her oturum açma denemesinin IP'si ve sonucu, her içerik gönderiminin IP'si ve zamanı, düzenleme ve silme işlemlerinin kim tarafından ne zaman yapıldığı. WordPress gibi platformlar yorum IP'sini saklar ama yazı gönderimi için bunu varsayılan olarak yapmaz; forum yazılımlarının çoğunda ayar mevcuttur ancak kapalı gelebilir. Kurulumdan sonra bunu kontrol etmek beş dakikalık iştir ve bir yıl sonra elinizdeki tek kullanışlı kayıt o olabilir.

Saklamak ile KVKK Arasındaki Denge#

IP adresi kişisel veridir. Yani 5651 kapsamında tuttuğunuz her satır, aynı zamanda KVKK kapsamında işlediğiniz bir veridir ve bu iki düzenleme birbiriyle çelişmez; birlikte okunur.

Uyumlu kurulum üç şey ister. Birincisi hukuki sebep: bu işleme "kanunlarda açıkça öngörülme" dayanağıyla yapılır, ayrıca açık rıza almanız gerekmez. İkincisi şeffaflık: aydınlatma metninizde erişim kayıtlarının tutulduğu, hangi amaçla ve ne kadar süreyle saklandığı yazmalıdır. KVKK aydınlatma metni hazırlarken bu maddeyi eklemeyi unutmayın; web sitesi zorunlu yasal metinler kontrol listesinde de yeri vardır. Üçüncüsü ölçülülük: yükümlülüğün gerektirdiğinden fazlasını toplamamak ve süre dolduğunda imha etmek.

İmha, "diski silmek" değil, planlı bir işlemdir. logrotate'in rotate sayısı bu işi otomatik yapar; ancak yedeklerinizde aynı dosyaların kopyaları varsa oradaki saklama politikasını da hizalamanız gerekir. İki yıllık log arşivini beş yıllık yedek rotasyonuna gönderirseniz, imha ettiğinizi sandığınız kayıt yedekte yaşamaya devam eder. Rsync ile yedekleme kurulumlarında arşiv dizinini ayrı bir politikayla ele almak bu yüzden önemlidir. Genel uyum çerçevesi için KVKK web sitesi uyumu yazısı iyi bir başlangıç noktasıdır.

Tatbikat: Sekiz Ay Önceki Bir IP'yi Bulabiliyor musunuz?#

Yukarıdaki her şeyi kurduğunuzu varsayalım. Sistemin gerçekten çalıştığını anlamanın tek yolu, bir soruşturma yazısı gelmeden önce provasını yapmaktır. Kendinize şu görevi verin: "Sekiz ay önceki bir tarihte, belirli bir saat aralığında /forum/konu/1234 adresine POST isteği gönderen IP adresleri hangileriydi?"

# 1) O tarihin arşiv dosyası duruyor mu?
ls -l /var/log/arsiv/access.log-2025-12-1*.gz

# 2) İlgili istekleri çıkar (sıkıştırılmış dosyada doğrudan ara)
zgrep -h 'POST|/forum/konu/1234' /var/log/arsiv/access.log-2025-12-14.gz \
  | awk -F'|' '{print $1, $2, $3, $10}'

# 3) Dosya bütünlüğü hâlâ doğrulanıyor mu?
cd /var/log/arsiv && sha256sum -c access.log-2025-12-14.gz.sha256

Bu üç komutun üçü de temiz sonuç veriyorsa sisteminiz çalışıyor demektir. Herhangi biri takılıyorsa sorun bugün çözülür; soruşturma yazısı geldiğinde çözülmez. Provayı yılda bir kez tekrarlamak, log yapılandırmasının bir sunucu taşıması ya da panel güncellemesi sırasında sessizce bozulmadığını doğrulamanın en ucuz yoludur.

Son bir hatırlatma: kayıt tutmak bir sorumluluk devri değildir. Barındırdığınız içerik hakkında usulüne uygun bir bildirim aldığınızda gereğini yapmak da yükümlülüğün parçasıdır; log arşivi tek başına koruma sağlamaz. Teknik hazırlık ile hukuki süreç birlikte yürür.

Sıkça Sorulan Sorular#

Sadece kurumsal tanıtım sitem var, log tutmak zorunda mıyım?#

Kullanıcıların içerik üretmediği, yalnızca sizin yayımladığınız bir sitede birincil rolünüz içerik sağlayıcıdır ve yer sağlayıcıya yüklenen trafik bilgisi saklama yükümlülüğünün doğrudan muhatabı olmadığınız savunulabilir. Buna rağmen erişim loglarını en az bir yıl tutmak, saldırı incelemesi ve olası uyuşmazlıklarda ispat açısından güçlü bir avantaj sağlar ve maliyeti sıkıştırılmış birkaç yüz megabayttır.

Paylaşımlı hosting kullanıyorum, yükümlülük hosting firmasında değil mi?#

Sunucuyu işleten taraf hosting firmasıdır ve sistem düzeyindeki trafik kayıtlarını o tutar. Ancak sitenizde kullanıcı içeriği barındırıyorsanız, o içeriğin kime ait olduğunu gösteren uygulama düzeyindeki kayıtlar sizin sorumluluğunuzdadır. Hosting firmasının access log'u "hangi IP hangi sayfayı istedi" der; "bu forum iletisini kim gönderdi" sorusunu ancak sizin veritabanınızdaki kayıt cevaplayabilir.

Sadece hash almak yeterli mi, zaman damgası şart mı?#

Hash dosyanın sonradan değiştirilmediğini gösterir ama hash'in ne zaman üretildiğini ispatlamaz. Teorik olarak bugün geçmişe dair bir dosya üretip bugünün özetini alabilirsiniz. Nitelikli zaman damgası, özet değerinin belirli bir anda var olduğunu bağımsız üçüncü tarafın güvencesiyle tespit ettiği için bu boşluğu kapatır ve kaydın delil değerini belirgin biçimde yükseltir. İkisi birlikte kullanılır.

Logları bulut depolamaya yedeklemek yükümlülüğü karşılar mı?#

Yedekleme saklamanın bir parçasıdır ama tek başına yeterli değildir. Düzenleme, kayıtların gizliliğinin de sağlanmasını ister; şifrelenmemiş hâlde üçüncü taraf bir depolamaya gönderilen loglar bu ölçütü karşılamaz. Arşivi şifreleyerek göndermek, erişimi yetkili kişilerle sınırlamak ve yedek rotasyon süresini saklama politikanızla hizalamak gerekir. Ayrıca yedekten geri dönüşün gerçekten çalıştığı düzenli olarak test edilmelidir.

Log dosyalarım çok yer kaplıyor, süreyi kısaltabilir miyim?#

Disk maliyeti genellikle sanıldığından düşüktür: sıkıştırılmış metin logları ham boyutun yaklaşık onda birine iner. Süreyi kısaltmak yerine önce gereksiz satırları azaltın; statik dosya isteklerini ayrı bir log dosyasına yönlendirip yalnızca uygulama isteklerini uzun süre saklamak, hem boyutu ciddi biçimde düşürür hem de arama yaparken sonucu okunur kılar. Saklama süresini yükümlülüğün altına indirmek ise disk kazanmanın en pahalı yoludur.

Ofisimin misafir Wi-Fi ağı için de log tutmam gerekir mi?#

Ticari bir mekânda müşteri veya ziyaretçilere internet erişimi sunuyorsanız toplu kullanım sağlayıcı konumundasınız ve iç IP dağıtım kayıtlarını tutma yükümlülüğü doğar. Bu kayıtlar dağıtılan IP adresini, kullanım başlangıç ve bitiş zamanını ve cihazın MAC adresini içerir; iki yıl saklanması ve bütünlüğünü teyit eden değerin günlük olarak üretilmesi beklenir. Çoğu kurumsal hotspot cihazı bu özelliği taşır ancak varsayılan olarak kapalı gelebilir.