Log Saklama Politikası: Yasal Gereksinimler ve Pratik Uygulamalar

Bir gün production sunucunuzda ciddi bir güvenlik ihlali yaşandı ve saldırganın ne zaman, nasıl girdiğini anlamak istiyorsunuz. Log dosyalarına bakıyorsunuz ama kritik dönemin logları silinmiş ya da üzerine yazılmış. Ya da tam tersi senaryo: Depolama alanınız log dosyalarıyla dolup taşıyor, yeni servislerin ayağa kalkmasını engelliyor. Her iki durum da sysadmin kariyerinizde kabusunuz olabilir. İşte bu yüzden log saklama politikası, sadece “ne kadar süre saklayalım” sorusundan çok daha fazlasıdır.

Log Saklama Politikası Neden Bu Kadar Kritik?

Log yönetimi iki farklı baskıyla karşı karşıya kalır: Yasal uyumluluk ve operasyonel gerçekler. Yasal düzenlemeler size “en az şu kadar sakla” derken, depolama kapasitesi “fazla yer kaplıyor, sil” diye bağırır. Ortada kalan sysadmin olarak ikisini dengelemeniz gerekir.

Yasal açıdan bakıldığında Türkiye’de 5651 sayılı İnternet Kanunu, internet servis sağlayıcıları ve içerik sağlayıcılar için belirli log saklama yükümlülükleri getirir. KVKK (Kişisel Verilerin Korunması Kanunu) ise kişisel veriye erişim loglarının saklanmasını zorunlu kılar. PCI DSS uyumluluğu gerektiren ortamlarda en az 12 ay log tutma zorunluluğu vardır, bunun 3 ayı anlık erişilebilir olmalıdır. HIPAA kapsamındaki sağlık sistemlerinde bu süre 6 yıla çıkabilir.

Pratik açıdan ise bir olayı incelerken genellikle 30-90 gün geriye gitmeniz gerekir. Çoğu saldırı hemen fark edilmez; bir APT (Advanced Persistent Threat) saldırısı aylar boyunca fark edilmeden sürebilir.

Hangi Logları Ne Kadar Süre Saklayalım?

Tüm logları aynı kategoride değerlendirmek hem yasal açıdan yanlış hem de operasyonel açıdan verimsizdir. Logları önem ve içeriklerine göre kategorilere ayırmanız gerekir.

Güvenlik logları (auth.log, secure, Windows Security Event Log):

• Minimum saklama süresi: 1 yıl
• Önerilen süre: 2 yıl
• Gerekçe: Yasal soruşturmalar, KVKK uyumluluğu

Web sunucu erişim logları (Apache/Nginx access.log):

• Minimum saklama süresi: 6 ay
• Önerilen süre: 1 yıl
• Gerekçe: DDoS analizi, hukuki delil

Uygulama logları:

• Minimum saklama süresi: 3 ay
• Önerilen süre: 6 ay
• Gerekçe: Hata ayıklama, performans analizi

Sistem logları (syslog, dmesg):

• Minimum saklama süresi: 1 ay
• Önerilen süre: 3 ay
• Gerekçe: Donanım sorunları, kernel hataları

Veritabanı audit logları:

• Minimum saklama süresi: 1 yıl
• Önerilen süre: 3 yıl
• Gerekçe: Veri ihlali soruşturmaları, KVKK

Linux’ta Log Rotation Yapılandırması

Linux sistemlerde log rotation’ın temel aracı logrotate‘tir. Varsayılan yapılandırma çoğu zaman ihtiyaçlarınızı karşılamaz, özelleştirmeniz gerekir.

# /etc/logrotate.d/custom-security dosyası
/var/log/auth.log
/var/log/secure
/var/log/sudo.log
{
    daily
    rotate 730
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root adm
    dateext
    dateformat -%Y%m%d
    sharedscripts
    postrotate
        /usr/bin/systemctl reload rsyslog > /dev/null 2>&1 || true
    endscript
}

Bu yapılandırmada rotate 730 parametresi 730 gün (2 yıl) boyunca logları saklar. dateext ve dateformat parametreleri sayesinde her rotated log dosyası tarih damgasıyla adlandırılır, bu da hangi tarihe ait olduğunu bulmayı kolaylaştırır.

Web sunucu logları için farklı bir strateji izleyebilirsiniz:

# /etc/logrotate.d/nginx
/var/log/nginx/*.log {
    daily
    rotate 365
    compress
    delaycompress
    missingok
    notifempty
    create 0644 www-data adm
    dateext
    dateformat -%Y%m%d-%H%M%S
    sharedscripts
    prerotate
        if [ -d /etc/logrotate.d/httpd-prerotate ]; then 
            run-parts /etc/logrotate.d/httpd-prerotate; 
        fi 
    endscript
    postrotate
        invoke-rc.d nginx rotate >/dev/null 2>&1
    endscript
}

Merkezi Log Yönetimi: rsyslog ile Uzak Sunucuya Yönlendirme

Tek bir sunucuda log saklamak güvenlik açısından risklidir. Saldırgan sisteme girdiğinde ilk yapacağı şeylerden biri logları temizlemektir. Bu yüzden logları merkezi bir log sunucusuna yönlendirin.

# /etc/rsyslog.conf - Kaynak sunucu yapılandırması
# TCP ile güvenli iletim
*.* @@log-server.internal:514

# Ya da TLS ile şifreli iletim (önerilir)
*.* action(type="omfwd"
    target="log-server.internal"
    port="6514"
    protocol="tcp"
    action.resumeRetryCount="-1"
    queue.type="linkedList"
    queue.size="10000"
    queue.filename="fwdRule1"
    queue.saveOnShutdown="on"
    StreamDriver="gtls"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="log-server.internal")

Log sunucusunda ise gelen logları düzenli bir yapıda saklayın:

# /etc/rsyslog.d/remote-logs.conf - Log sunucusu yapılandırması
# Gelen bağlantıları dinle
module(load="imtcp")
input(type="imtcp" port="514")

# Her sunucu için ayrı dizin oluştur
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%-%$YEAR%-%$MONTH%-%$DAY%.log"
*.* ?RemoteLogs
& stop

Log Sıkıştırma ve Arşivleme Stratejisi

Logları sıkıştırarak saklama alanından ciddi tasarruf sağlayabilirsiniz. Metin tabanlı log dosyaları gzip ile %70-90 oranında küçülebilir.

#!/bin/bash
# /usr/local/bin/log-archive.sh
# Eski logları sıkıştırıp arşive taşıyan script

LOGDIR="/var/log"
ARCHIVEDIR="/archive/logs"
RETENTION_DAYS=730  # 2 yıl
COMPRESS_AFTER_DAYS=7  # 7 günden eski logları sıkıştır

# 7 günden eski, henüz sıkıştırılmamış logları sıkıştır
find "$LOGDIR" -name "*.log.*" -not -name "*.gz" 
    -mtime +"$COMPRESS_AFTER_DAYS" 
    -exec gzip -9 {} ;

# 90 günden eski sıkıştırılmış logları arşive taşı
find "$LOGDIR" -name "*.gz" -mtime +90 | while read -r logfile; do
    # Dizin yapısını koru
    relative_path="${logfile#$LOGDIR/}"
    archive_path="$ARCHIVEDIR/$(date +%Y/%m)/$relative_path"
    mkdir -p "$(dirname "$archive_path")"
    mv "$logfile" "$archive_path"
    echo "$(date): Arşivlendi: $logfile -> $archive_path" >> /var/log/archive-operations.log
done

# Saklama süresini aşan logları sil
find "$ARCHIVEDIR" -name "*.gz" -mtime +"$RETENTION_DAYS" -delete
echo "$(date): Retention temizliği tamamlandı" >> /var/log/archive-operations.log

Bu scripti crontab’a ekleyin:

# Crontab kaydı - Her gece 02:00'de çalıştır
0 2 * * * /usr/local/bin/log-archive.sh >> /var/log/archive-script.log 2>&1

Log Bütünlüğünü Doğrulama

Logların değiştirilmediğini kanıtlamak, özellikle yasal süreçlerde kritik önem taşır. Hash değerleri alarak log bütünlüğünü koruyabilirsiniz.

#!/bin/bash
# /usr/local/bin/log-integrity-check.sh
# Log dosyalarının hash değerlerini hesaplar ve doğrular

LOGDIR="/var/log"
HASHFILE="/var/lib/log-hashes/checksums.sha256"
HASHDIR="/var/lib/log-hashes"

mkdir -p "$HASHDIR"

case "$1" in
    "generate")
        # Mevcut logların hash değerlerini oluştur
        find "$LOGDIR" -name "*.log" -o -name "*.log.*.gz" | sort | 
            xargs sha256sum > "$HASHFILE"
        # Hash dosyasının kendisini de imzala
        sha256sum "$HASHFILE" > "$HASHDIR/checksums.sha256.sig"
        echo "$(date): Hash değerleri oluşturuldu: $(wc -l < $HASHFILE) dosya"
        ;;
    "verify")
        # Hash değerlerini doğrula
        if sha256sum -c "$HASHFILE" 2>&1 | grep -v "OK$"; then
            echo "UYARI: Bazı log dosyaları değiştirilmiş olabilir!"
            logger -p security.alert "Log bütünlük kontrolü başarısız!"
        else
            echo "$(date): Tüm log dosyaları bütünlük kontrolünden geçti"
        fi
        ;;
    *)
        echo "Kullanım: $0 {generate|verify}"
        exit 1
        ;;
esac

Windows Ortamında Log Saklama

Windows Server ortamlarında Event Log yönetimi için PowerShell ve Windows Event Forwarding (WEF) kullanabilirsiniz.

# Windows Event Log maksimum boyut ve retention ayarları
# PowerShell ile yapılandırma

# Security log için boyut ve davranış ayarla
# MaximumKilobytes: 1GB
# OverflowAction: OverwriteOlder (eski kayıtların üstüne yaz)
Limit-EventLog -LogName Security -MaximumSize 1073741824
$logConfig = Get-WinEvent -ListLog Security
$logConfig.MaximumSizeInBytes = 1073741824  # 1 GB
$logConfig.LogMode = [System.Diagnostics.Eventing.Reader.LogMode]::Retain
$logConfig.SaveChanges()

# Audit policy - hangi olayların loglanacağını belirle
auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable
auditpol /set /category:"Account Logon" /success:enable /failure:enable
auditpol /set /category:"Object Access" /success:enable /failure:enable
auditpol /set /category:"Privilege Use" /success:enable /failure:enable
auditpol /set /category:"System" /success:enable /failure:enable

# Mevcut audit policy'yi görüntüle
auditpol /get /category:*

Write-Host "Windows audit policy yapılandırması tamamlandı"

ELK Stack ile Merkezi Log Yönetimi

Büyük ortamlarda Elasticsearch, Logstash ve Kibana üçlüsü log yönetiminin fiili standardı haline gelmiştir. Index lifecycle management (ILM) ile log saklama politikalarını otomatize edebilirsiniz.

# Elasticsearch ILM policy oluşturma - curl ile API çağrısı
curl -X PUT "localhost:9200/_ilm/policy/log-retention-policy" 
  -H 'Content-Type: application/json' 
  -d '{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb",
            "max_age": "7d"
          }
        }
      },
      "warm": {
        "min_age": "30d",
        "actions": {
          "shrink": {
            "number_of_shards": 1
          },
          "forcemerge": {
            "max_num_segments": 1
          }
        }
      },
      "cold": {
        "min_age": "90d",
        "actions": {
          "freeze": {}
        }
      },
      "delete": {
        "min_age": "730d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}'

Bu ILM policy ile loglarınız otomatik olarak lifecycle’ı takip eder: İlk 30 gün aktif (hot) depolamada, 30-90 gün arası sıkıştırılmış (warm) depolamada, 90-730 gün arası dondurulmuş (cold) depolamada tutulur ve 730 gün sonra otomatik silinir.

Gerçek Dünya Senaryosu: Log Politikası Olmayan Bir Şirkette Yaşananlar

Orta ölçekli bir e-ticaret şirketinde çalıştığınızı düşünün. Güvenlik ekibi size bir müşterinin kredi kartı bilgilerinin çalındığını rapor etti. PCI DSS gereği olayı araştırmanız ve ilgili kart şemalarına bildirmeniz gerekiyor. Forensic inceleme başlatıyorsunuz ama:

• Web sunucu logları sadece 7 gün saklanmış, saldırı 3 hafta önce gerçekleşmiş
• Veritabanı erişim logları hiç tutulmamış
• Auth logları 30 gün sonra silinmiş

Bu durumda PCI DSS uyumsuzluğu nedeniyle ciddi cezalar, kart şemasından çıkarılma riski ve hukuki sorunlarla karşı karşıya kalırsınız. Dahası saldırının nasıl gerçekleştiğini anlayamadan aynı açığın tekrar kullanılmasını engelleyemezsiniz.

Öte yandan başka bir senaryo: Logları hiç temizlemeyen bir şirket, 500 GB’lık log yığınıyla karşılaşır ve kritik production diskinin dolmasıyla servislerin çökmesine neden olur. Gece 3’te aranırsınız, sorun “sadece disk dolu” olarak görünür ama asıl sorun log politikasının yokluğudur.

Log Saklama Maliyetlerini Optimize Etme

Depolama maliyetleri göz ardı edilemez. Akıllıca bir tier stratejisiyle hem uyumlu hem ekonomik olabilirsiniz.

#!/bin/bash
# Log boyutu analiz scripti - hangi servislerin ne kadar yer kapladığını gösterir

echo "=== Log Boyutu Analizi ==="
echo "Tarih: $(date)"
echo ""

echo "--- Dizin bazında kullanım ---"
du -sh /var/log/*/ 2>/dev/null | sort -rh | head -20

echo ""
echo "--- En büyük log dosyaları ---"
find /var/log -name "*.log" -o -name "*.log.*.gz" 2>/dev/null | 
    xargs du -sh 2>/dev/null | sort -rh | head -20

echo ""
echo "--- Aylık büyüme tahmini ---"
# Son 7 günün log yazma hızını hesapla
TOTAL_WRITTEN=$(find /var/log -newer /var/log -name "*.log" 
    -exec du -sb {} ; 2>/dev/null | awk '{sum+=$1} END {print sum}')
DAILY_RATE=$((TOTAL_WRITTEN / 7))
MONTHLY_RATE=$((DAILY_RATE * 30))
echo "Günlük ortalama: $(numfmt --to=iec $DAILY_RATE)"
echo "Aylık tahmini: $(numfmt --to=iec $MONTHLY_RATE)"
echo "Yıllık tahmini: $(numfmt --to=iec $((DAILY_RATE * 365)))"

Tier stratejisi için düşünce yapısı şu şekilde olabilir:

• Hot tier (SSD/NVMe): Son 30 günün logları, anlık erişim gereksinimi
• Warm tier (HDD RAID): 30-180 gün arası loglar, düşük gecikmeyle erişim
• Cold tier (Object Storage/Tape): 180 gün – yasal maksimum, nadir erişim
• Archive (Offsite/Cloud): Yasal minimum aşıldıktan sonra felaket kurtarma kopyası

Log Politikasını Dokümante Etme

Teknik yapılandırma kadar önemli olan bir diğer konu, politikanın yazılı olarak dokümante edilmesidir. Bir denetimde veya hukuki süreçte “log politikamız var” demeniz yetmez, neyi neden ne kadar süre sakladığınızı kanıtlamanız gerekir.

Log politikası belgesi şu başlıkları içermelidir:

• Kapsam: Hangi sistemler ve log türleri bu politika kapsamındadır
• Saklama süreleri: Her log kategorisi için minimum ve maksimum süreler
• Yasal gerekçe: Hangi düzenlemenin hangi saklama süresini gerektirdiği
• Erişim kontrolü: Kimlerin hangi loglara erişebildiği
• Şifreleme: Aktarım ve depolamada şifreleme gereksinimleri
• Bütünlük kontrolü: Hash doğrulama prosedürleri
• İmha prosedürü: Saklama süresi dolan logların nasıl güvenli silineceği
• Revizyon tarihi: Politikanın son güncellenme tarihi ve gözden geçirme takvimi

Uyum Denetimi İçin Log Raporu Oluşturma

#!/bin/bash
# /usr/local/bin/log-compliance-report.sh
# Aylık uyum raporu oluşturur

REPORT_FILE="/var/reports/log-compliance-$(date +%Y-%m).txt"
mkdir -p /var/reports

{
echo "========================================="
echo "LOG SAKLAMA UYUM RAPORU"
echo "Rapor tarihi: $(date '+%Y-%m-%d %H:%M:%S')"
echo "Sunucu: $(hostname)"
echo "========================================="
echo ""

echo "1. MEVCUT LOG SAKLAMA DURUMU"
echo "-----------------------------------------"
for logdir in /var/log /archive/logs; do
    if [ -d "$logdir" ]; then
        echo "Dizin: $logdir"
        echo "Toplam boyut: $(du -sh $logdir 2>/dev/null | cut -f1)"
        echo "En eski log: $(find $logdir -name "*.gz" -printf '%T+ %pn' 2>/dev/null | sort | head -1)"
        echo "En yeni log: $(find $logdir -name "*.log" -printf '%T+ %pn' 2>/dev/null | sort -r | head -1)"
        echo ""
    fi
done

echo "2. SON 30 GÜNDEKİ GÜVENLİK OLAYLARI"
echo "-----------------------------------------"
echo "Başarısız SSH denemeleri:"
grep "Failed password" /var/log/auth.log 2>/dev/null | 
    awk '{print $1, $2}' | sort | uniq -c | sort -rn | head -10

echo ""
echo "Sudo kullanımı:"
grep "sudo:" /var/log/auth.log 2>/dev/null | 
    grep "COMMAND" | wc -l | xargs echo "Toplam sudo komutu:"

echo ""
echo "3. LOG ROTATION DURUMU"
echo "-----------------------------------------"
logrotate -d /etc/logrotate.conf 2>&1 | grep -E "(rotating|error)" | head -20

} > "$REPORT_FILE"

echo "Rapor oluşturuldu: $REPORT_FILE"
# Raporu yöneticiye e-posta ile gönder (mail komutu kurulu olmalı)
# mail -s "Aylık Log Uyum Raporu - $(hostname)" [email protected] < "$REPORT_FILE"

Sonuç

Log saklama politikası, bir sysadmin’in “yaparım bir gün” listesinde bırakabileceği türden bir görev değildir. Yasal uyumsuzluk ciddi para cezaları ve hukuki sorumluluklar doğururken, yetersiz saklama güvenlik olaylarını aydınlatamamanıza neden olur. Öte yandan kontrolsüz log birikimi operasyonel problemlere yol açar.

Pratik yaklaşım şu üç adımla özetlenebilir: Önce hangi düzenlemelere tabi olduğunuzu belirleyin ve minimum saklama sürelerinizi o düzenlemelere göre netleştirin. Sonra merkezi log yönetimi altyapısını kurun; logları üretildikleri sunucuda saklamak hem güvensiz hem de yönetilmez bir yaklaşımdır. Son olarak tüm bu konfigürasyonları politika belgesi haline getirin ve düzenli aralıklarla test edin.

Teknoloji değişse de, hangi platformda çalışırsanız çalışın, loglarınız hem operasyonel belleğinizdir hem de yasal koruyucunuzdur. Onlara sahip çıkın.