Log Anonimleştirme ve IP Maskeleme

Log anonimleştirme, bir IP alanını değiştirmekten daha kapsamlıdır. IP adresleri, çerez kimlikleri, kullanıcı ajanları ve istek URL’leri bir gerçek kişiyle ilişkilendirilebildiklerinde kişisel veri niteliği taşır; bu nitelik log mimarisinin doğru veya yanlış kurulmasına bağlı değildir. Hata ayıklama, güvenlik ve kapasite planlama için gereken bilgiyi korurken gereksiz kişisel veriyi azaltmak gerekir. Bu rehber; Apache/Nginx erişim loglarını, IPv4/IPv6 maskelemeyi, takma adlandırmayı ve merkezi log akışını birlikte ele alır. Örnek bir yapılandırma tek başına KVKK veya GDPR uyumunu kanıtlamaz.

Log tasarımında anonimleştirme ve pseudonymization katmanı da ele alınmalıdır. Örneğin bir projede uygulama, sunucu ve monitoring kurulurken log politikası atlanırsa, access.log içinde tam IP, kullanıcı kimliği veya URL’ye taşınmış token’lar gereğinden uzun süre kalabilir. Bu yazıda KVKK ve GDPR perspektifinden log verisini ele alıp, IP maskeleme, pseudonymization ve hosting logları için pratik, uygulanabilir bir yol haritası çıkaracağız. Örnekler ağırlıklı olarak Linux, Apache, Nginx ve merkezi loglama senaryolarına göre hazırlanmıştır.

KVKK, GDPR ve Log Verisi: Nerede Başlıyor, Nerede Bitiyor?

Önce kavramları netleştirelim. KVKK ve GDPR’a göre kişisel veri, kimliği belirli veya belirlenebilir gerçek kişiye ilişkin her türlü bilgidir. IP adresi, çerez ID’leri, cihaz parmak izi, kullanıcı adı ve e-posta adresi gibi veriler, bir gerçek kişiyi belirli veya belirlenebilir kıldıkları ölçüde bu tanıma girer. Web ve sunucu logları da bu bilgileri sık sık içerir.

Tipik bir web sunucusu access log satırı düşünün:

192.0.2.45 - - [18/Jun/2024:10:15:32 +0300] "GET /hesabim/siparisler HTTP/2.0" 200 5123 "-" "Mozilla/5.0 ..."

Burada IP, ziyaret edilen sayfa (URL), zaman damgası ve kullanıcı ajanı bir araya geldiğinde belirlenebilirlik artabilir. Kayıt bir gerçek kişiyle ilişkilendirilebiliyorsa kişisel veri olarak değerlendirilir. Bu durumda:

• Uygulanabilir mevzuatın kapsam koşulları değerlendirilir; KVKK ve GDPR’ın ikisinin birden uygulanacağı varsayılmaz
• Veri sorumlusu ve veri işleyen rolleri, ilgili log işlemenin amaç ve araçlarını kimin belirlediğine göre değerlendirilir; hosting sağlayıcısı her işlemde otomatik olarak veri işleyen değildir
• Logların saklama süresi, erişim yetkileri, anonimleştirme düzeyi ve güvenliği için bilinçli karar vermeniz gerekir

Her amaç için uygulanabilir işleme şartını ayrıca belirleyin. GDPR madde 6 ile KVKK madde 5 aynı metin değildir; sözleşme, hukuki yükümlülük veya meşru menfaat başlığını yazmak bütün log alanlarını haklı kılmaz. Gereklilik, ölçülülük ve ilgili kişinin haklarını değerlendirin. Tanımlar ve ilkeler için KVKK’nın yayımladığı Kanun metni ile GDPR madde 4–6 ve gerekçe 26/30 temel kaynaklardır.

KVKK ve GDPR uyumlu altyapı kurma tarafını daha geniş çerçevede ele aldığımız KVKK ve GDPR uyumlu hosting nasıl kurulur rehberinde genel ilkeleri anlattık. Bu yazıda odağı özellikle log anonimleştirme katmanına indiriyoruz.

Anonimleştirme, Pseudonymization ve Maskeleme: Aynı Şey Değil

Hukuki ve teknik tarafta en çok karışan üç kavram: anonimleştirme, pseudonymization (takma adlandırma) ve maskeleme. Bunları ayırmadan doğru log stratejisi kurmak zor.

Anonimleştirme Nedir?

Anonimleştirmede amaç, verinin artık kimliği belirli veya belirlenebilir bir gerçek kişiyle ilişkilendirilememesidir. Yalnızca silinen alanı geri getirememek yeterli değildir; diğer log alanları ve ek bilgilerle yeniden ilişkilendirme olasılığı da değerlendirilmelidir. Aşağıdaki işlemler bu amaca katkı sağlayabilir, ancak tek başlarına anonimlik garantisi değildir:

• IP alanını kaldırmak veya ağ önekine indirgemek; başka kayıtlardaki kopyaları da değerlendirmek.
• Çerez, oturum ve kullanıcı kimliklerini; URL, query string ve başlıklardaki tanımlayıcıları çıkarmak.
• Kesin zamanları yuvarlamak ve küçük grupları birleştirmek; nadir rol/olay birleşimlerinin hâlâ kişiyi ayırt edip etmediğini sınamak.

Logların kişisel veri kapsamı dışında değerlendirilmesi, ilgili mevzuatın anonimleştirme koşullarını gerçekten sağlamalarına bağlıdır; yalnızca maskeleme uygulanması veya kaydın “anonim” diye adlandırılması yeterli değildir.

GDPR gerekçe 26, kişinin belirlenmesinde makul olarak kullanılabilecek araçları; KVKK ise başka verilerle eşleştirme dahil ilişkilendirilemezliği ele alır. KVKK’nın anonim hale getirme açıklaması bu bütünsel değerlendirmeyi vurgular. Gerçekten anonim çıktılar ile bunları üretmek için işlenen orijinaller ve elde tutulan kişisel veri kopyaları ayrı değerlendirilir.

Pseudonymization (Takma Adlandırma) Nedir?

Pseudonymization, verinin ayrı tutulan ek bilgiler olmadan belirli bir kişiye atfedilemeyecek şekilde işlenmesidir. Bir takma ad ve ayrı tutulan eşleme tablosu buna örnek olabilir. Hash kullanıldığında ise salt, hash’i geri çözen bir anahtar değildir. Örnekler:

• IP adresini SHA-256 ile hash’leyip veritabanında saklamak: tek başına güvenli bir tasarım değildir; özellikle IPv4 adresleri aday adresler hash’lenerek eşleştirilebilir
• Kullanıcı ID’sini rastgele bir UUID ile eşleyip, eşleme tablosunu ayrı bir sistemde tutmak

Takma adlandırma, bu rehberdeki işletmeci açısından kişisel veriyi koruma yükümlülüğünü kaldırmaz. Ek bilgilerle ilişkilendirme mümkün olabilir. Etkiyi azaltması; anahtar/eşleme bilgisinin ayrı korunmasına, yetkilere ve logda kalan diğer alanlara bağlıdır. Salt, hash’i çözen bir anahtar değildir; bir hash’i geri çevirememeniz de kişinin başka bilgilerle belirlenemeyeceğini göstermez.

Maskeleme Nedir?

Maskeleme genellikle teknik bir yöntemdir; hem anonimleştirme hem de pseudonymization için kullanılabilir. Örneğin:

• IP’nin son oktetini sıfırlamak: 192.0.2.45 → 192.0.2.0/24.
• Telefonun bazı hanelerini yıldızlamak; kalan hanelerle eşleştirme riskini koruduğunu bilmek.
• E-posta kullanıcı adını kısmi göstermek: ali***@example.test; alan adı ve kalan karakterler hâlâ ayırt edici olabilir.

Maskeleme tek başına anonimlik veya pseudonymization garantisi vermez. Sonuç; orijinal verinin saklanmasının yanı sıra kalan alanlarla ve başka bilgilerle kişinin yeniden belirlenip belirlenemediğine bağlıdır.

IP Maskeleme Stratejileri: IPv4 ve IPv6 için Yaklaşımlar

IP, loglarda değerlendirilmesi gereken alanlardan biridir; e-posta, oturum kimliği veya URL’deki bir token daha doğrudan tanımlayıcı olabilir. Önce hangi analizin IP bilgisine ihtiyaç duyduğunu belirleyin. Ağ öneki yeterliyse ayrıntıyı azaltın; hiç gerekmiyorsa alanı kaldırın. NAT, özel ağ veya paylaşılan IP kullanılması tek başına kişisel veri riskini ortadan kaldırmaz.

IPv4 Maskeleme Örüntüleri

IPv4 için seçilebilecek yöntemler:

• /24 seviyesinde maskeleme: Son okteti sıfırlamak (192.0.2.45 → 192.0.2.0)
• /16 seviyesinde maskeleme: Son iki okteti sıfırlamak (192.0.2.45 → 192.0.0.0)
• IP alanını kaldırma veya değiştirme: IP’yi tamamen kaldırmak veya rastgele bir ID ile değiştirmek; bunlar diğer alanlar ve varsa eşleme bilgisi değerlendirilmeden tam anonimleştirme sayılmaz

/24, ağ bloğu düzeyinde analiz için kullanılabilir; yeterli ayrıntı sağlayıp sağlamadığı analiz amacına bağlıdır ve anonimlik garantisi değildir. Güvenlik analizi için IP tabanlı pseudonymization düşünülebilir, ancak yukarıda belirtildiği gibi tek başına SHA-256 kullanmak yeterli koruma sağlamaz.

IPv6 Maskeleme Örüntüleri

IPv6 için değerlendirilebilecek iki önek politikası, ilk 48 veya 64 biti koruyup kalan bitleri sıfırlamaktır:

• /64: 2001:db8:abcd:1234:5678:90ab:cdef:1 → 2001:db8:abcd:1234::/64.
• /48: aynı giriş 2001:db8:abcd::/48 olur.

Bu sayede aynı ağ bloğundan gelen trafiği görebilir, tekil cihazı doğrudan ayırt etmeyi zorlaştırabilirsiniz; ancak korunan önek ve diğer log alanlarıyla yeniden ilişkilendirme riski devam edebilir. IPv6 tarafını ihmal etmemek önemli; birçok ortamda sadece IPv4 için maskeleme yapılıp IPv6 tamamen unutuluyor.

/64 bir aboneye veya haneye özgü kalabilir; /48 de otomatik anonimlik sağlamaz. Şehir/ASN doğruluğu veya kişi sayısı bu maskelerden çıkarılamaz. Aynı ağ, aynı kişi ya da saldırgan demek değildir.

Apache ve Nginx’te Önce Gereksiz Alanları Kaldırın

Log verisini kaynakta, yani diske yazılmadan önce azaltmak, ham verinin kalıcı kayıtlara girmesini sınırlayabilir. Ancak tek bir access log’u maskelemek; error log, proxy, WAF veya uygulama loglarında ham IP tutulmadığını göstermez.

Apache: LogFormat Ne Yapar, Ne Yapmaz?

LogFormat kayıt biçimini tanımlar; kendiliğinden IP maskelemez. %h uzak ana makine adıdır; HostnameLookups Off varsayılanında IP yazılır. %a isteğin istemci adresini, %{c}a bağlantının gerçek eş adresini verir. Güvenilen proxy yapılandırması %a değerini etkileyebilir. Aşağıdaki düzeltilmiş tırnaklı birleşik format ham veri içerir; anonimleştirme reçetesi değildir:

# Diagnostic contrast only: this retains raw identifiers and request data.
LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

mod_remoteip güvenilir proxy zincirinden istemci adresini seçer; bir önek kesme modülü değildir ve yetkilendirmeyi de etkileyebilir. mod_substitute HTTP yanıt gövdelerini değiştirir, access log’larını değil. Sırf log için X-Forwarded-For başlığını maskeli adresle değiştirmek güvenlik ve oran sınırlama kararlarını bozabilir. Dönüşümü kayıt yazma yolunda uygulayın; istemciden gelen başlığı kendiliğinden güvenilir saymayın.

Sadece durum kodu istatistiği gereken ayrı bir erişim logu için minimal örnek:

# In the intended VirtualHost; review inherited and additional CustomLog entries.
LogFormat "{\"status\":%>s}" reduced
CustomLog /var/log/apache2/access_reduced.log reduced

Bu format IP, kullanıcı, URL, çerez, Referer ve kullanıcı ajanı yazmaz; fakat diğer CustomLog, ErrorLog, sanal host ve uygulama kayıtları ayrı kalır. Yapılandırmayı düzenledikten sonra, yeniden yükleme veya yeniden başlatmadan önce tam apachectl -t kontrolünü yapın; log dosyası/dizin izinlerini ve yeni dosya oluşturmayı doğrulayın.

Nginx: Biçim Değişikliği ile IP Dönüşümünü Ayırın

log_format http bağlamında tanımlanır; hedef server veya location içinde seçilen access_log tarafından kullanılır. map bir metin eşleştirmesidir: son iki nokta üst üste işaretinden kesmek IPv6’da /64 hesabı yapmaz. Sıkıştırılmış adresleri ve IPv4’e eşlenen IPv6’yı ayrıca ele almayan regex taslakları kullanılmamalıdır. Eşleşmeyende default $remote_addr kullanmak ham IP sızdırır. IP gerekmeyen akışta şu minimal biçim daha açıktır:

# Inside the http {} context; review inherited and per-vhost logs too.
log_format reduced escape=json '{"status":$status}';
# In the intended server {} context:
access_log /var/log/nginx/access_reduced.log reduced;

Örneğin HTTP 204 yanıtında bu iki minimal formatın seçildiği erişim logu {"status":204} yazar. escape=json kaçış üretir; maskeleme veya anonimleştirme işlemi değildir. Ham birleşik formatta ise $remote_addr, $request, $remote_user, Referer ve kullanıcı ajanı kayıtlı kalır. Hangi sanal host/location’da hangi formatın etkin olduğunu ve ek log hedeflerini kontrol edin; Nginx’in tam yapılandırmasını nginx -t ile doğrulayın.

• Seçili erişim logunda IP ve istek içeriği çıkarılmış olur; error log, WAF, proxy ve uygulama logu bundan etkilenmez.
• Dosyanın zamanı/sırası, toplayıcının eklediği hassas etiketler ve kesin alım zamanları yeniden ilişkilendirmeye katkıda bulunabilir. Minimal satır bile tüm sistem için anonimlik kanıtı değildir.
• IP öneki gerçekten gerekliyse aşağıdaki ayrıştırıcıyı yalnız log üretimi veya gözden geçirilmiş bir taşıma akışına bağlayın. Dönüşümden önce oluşturulan ham dosya, kuyruk ve yedekler varlığını sürdürür.

Bu ayrım Nginx reverse proxy tasarımında da geçerlidir: log biçimi, upstream’e iletilen adresi değiştiren bir proxy ayarı değildir. Güvenilir proxy sınırlarını ayrıca tanımlayın.

IPv4/IPv6 için Çalışan Önek Dönüşümü

Aşağıdaki log_filter.py Python 3.11+ standart kitaplığıyla tek satırlık UTF-8 JSON okur. Girdi sözleşmesi: client_ip tek bir adres metni, status 100–599 arası tamsayı, timestamp tam YYYY-MM-DDTHH:MM:SSZ biçiminde UTC zamanıdır. Serbest access/error satırı, X-Forwarded-For listesi veya ham Nginx/Apache satırı bu sözleşme değildir. Yukarıdaki yalnız-durum biçimleri de bu filtreye girdi değildir; bunlar IP’siz ayrı seçenektir.

ipaddress gerçek adresi ayrıştırır; varsayılan IPv4 /24, IPv6 /64’tür. Politika gerektiriyorsa ip_prefix içindeki varsayılanları /16 ve /48’e değiştirip testleri uyarlayın. IPv4’e eşlenen IPv6 bilinçli olarak IPv4 politikasına alınır; diğer IPv6 geçiş biçimleri IPv6 kalır. Scoped adresler, CIDR metni, boşluk, bozuk adres, IPv4 host:port ve köşeli parantezli IPv6 endpoint reddedilir. Geçerli çıplak IPv6’daki son bölümün port olduğu tahmin edilmez.

"""Synthetic JSONL example: prefix reduction, not proof of anonymization."""
import datetime
import ipaddress
import json
import sys

MAX_LINE = 16384


def parse_ip(value):
    if not isinstance(value, str) or not value or len(value) > 45:
        raise ValueError("invalid input")
    if any(c.isspace() for c in value) or "%" in value or "/" in value:
        raise ValueError("invalid input")
    address = ipaddress.ip_address(value)
    if isinstance(address, ipaddress.IPv6Address) and address.ipv4_mapped:
        address = address.ipv4_mapped
    return address


def ip_prefix(value, v4=24, v6=64):
    if v4 not in (16, 24) or v6 not in (48, 64):
        raise ValueError("invalid policy")
    address = parse_ip(value)
    bits = v4 if address.version == 4 else v6
    return str(ipaddress.ip_network((address, bits), strict=False))


def unique_object(pairs):
    result = {}
    for key, value in pairs:
        if key in result:
            raise ValueError("duplicate field")
        result[key] = value
    return result


def reject_constant(value):
    raise ValueError("invalid constant")


def transform(line):
    if len(line) > MAX_LINE:
        raise ValueError("oversized input")
    record = json.loads(line, object_pairs_hook=unique_object,
                        parse_constant=reject_constant)
    if not isinstance(record, dict):
        raise ValueError("invalid record")
    status = record.get("status")
    if type(status) is not int or not 100 <= status <= 599:
        raise ValueError("invalid status")
    stamp = record.get("timestamp")
    if not isinstance(stamp, str) or len(stamp) != 20:
        raise ValueError("invalid timestamp")
    dt = datetime.datetime.strptime(stamp, "%Y-%m-%dT%H:%M:%SZ")
    if dt.strftime("%Y-%m-%dT%H:%M:%SZ") != stamp:
        raise ValueError("invalid timestamp")
    return {"ip_prefix": ip_prefix(record.get("client_ip")),
            "hour_utc": dt.strftime("%Y-%m-%dT%H:00:00Z"),
            "status_class": str(status // 100) + "xx"}


def main():
    while True:
        line = sys.stdin.buffer.readline(MAX_LINE + 1)
        if not line:
            break
        if len(line) > MAX_LINE:
            while line and not line.endswith(b"\n"):
                line = sys.stdin.buffer.readline(MAX_LINE + 1)
            sys.stderr.write("dropped_record\n")
            continue
        try:
            result = transform(line.decode("utf-8", errors="strict"))
        except (ValueError, TypeError, OverflowError, RecursionError):
            # Never echo a rejected record or exception text.
            sys.stderr.write("dropped_record\n")
            continue
        sys.stdout.write(json.dumps(result, separators=(",", ":")) + "\n")


if __name__ == "__main__":
    main()

Her geçerli kayıttan yalnız önek, UTC saat kovası ve durum sınıfı üretilir; diğer bütün alanlar atılır. Bozuk/eksik girişte stdout’a kayıt yazılmaz, stderr’e yalnız sabit dropped_record yazılır. JSON anahtar tekrarları ve standart dışı NaN/Infinity de reddedilir. CLI satırı 16 KiB ile sınırlar. Süreç denetimi, kaynak limitleri, çıktı depolaması, anahtar yönetimi ve toplayıcı entegrasyonu bu eğitim örneğinin dışındadır; filtreyi doğrudan ayrıcalıklı Apache pipe programı olarak kurmayın.

Kodu log_filter.py adıyla kaydedin ve aynı dizinde aşağıdaki sentetik denemeyi çalıştırın:

python3.11 log_filter.py <<'JSONL'
{"client_ip":"192.0.2.45","timestamp":"2026-11-04T19:32:59Z","status":204,"request":"GET /account?token=SYNTH_TOKEN","cookie":"SYNTH_COOKIE"}
JSONL

Sentetik giriş ve tam çıktı:

{"client_ip":"192.0.2.45","timestamp":"2026-11-04T19:32:59Z","status":204,"request":"GET /account?token=SYNTH_TOKEN","cookie":"SYNTH_COOKIE"}
→
{"ip_prefix":"192.0.2.0/24","hour_utc":"2026-11-04T19:00:00Z","status_class":"2xx"}

Python ipaddress belgesi ağ bitlerini ve normalleştirmeyi açıklar. Bu çıktıda bile önek ve saat birlikte ayırt edici olabilir; az sayılı grupları ve ek verilerle eşleştirme riskini değerlendirin.

Takma Adlandırma: Kısıtlı Süreyle Olay İlişkilendirme

Bazı güvenlik ve hata analizi amaçları olayların sınırlı bir süre ilişkilendirilmesini gerektirebilir. IP tabanlı bir takma ad aynı kullanıcıyı veya saldırganı kesin temsil etmez: paylaşılan IP farklı kişileri birleştirir, adres değişikliği aynı kişiyi bölebilir. Bu örnek yalnız log korelasyonu içindir; erişim kontrolü ve rate limiting adreslerini değiştirmez.

Düz SHA256(IP + tarih + salt) yerine, ayrı korunan gizli anahtarla HMAC-SHA256 kullanmak aday IP eşleştirmesine karşı daha sağlam bir başlangıçtır. Aşağıdaki işlevde hizmet kapsamı ve gün, belirsiz birleştirmeyi önlemek için JSON dizisi olarak kodlanır. ip_pseudonym.py dosyasını log_filter.py ile aynı dizine koyun; işlev anahtarı çağırandan alır, diske veya loga yazmaz:

"""Optional keyed linkage for logging; still potentially personal data."""
import datetime
import hashlib
import hmac
import json
import re
from log_filter import parse_ip


def ip_pseudonym(value, *, key, scope, epoch):
    if not isinstance(key, bytes) or len(key) < 32:
        raise ValueError("invalid key")
    if not isinstance(scope, str) or not re.fullmatch(r"[a-z0-9_-]{1,64}", scope):
        raise ValueError("invalid scope")
    if not isinstance(epoch, str) or len(epoch) != 10:
        raise ValueError("invalid epoch")
    if datetime.date.fromisoformat(epoch).isoformat() != epoch:
        raise ValueError("invalid epoch")
    message = json.dumps([scope, epoch, str(parse_ip(value))],
                         separators=(",", ":")).encode("ascii")
    return "h1." + hmac.new(key, message, hashlib.sha256).hexdigest()

• Üretimde anahtarı güvenli rastgele kaynaktan üretin; en az 32 bayt seçin. Kod, Git, URL, komut satırı veya log içinde saklamayın. Ayrı yetkili secret store üzerinden alın.
• scope hizmet/amaç kimliği, epoch UTC günüdür. Ortak anahtar ve kapsam kullanmak hizmetler arası bağlantı kurar; yalnız gerekli olduğunda seçin.
• İşlevin hatasını yakalarken ham adresi, anahtarı veya exception metnini loglamayın. Gerekli kimlik üretilemiyorsa kaydı reddedin; ham IP’ye dönmeyin.

Aynı normalleştirilmiş adres, anahtar, kapsam ve gün aynı takma adı üretir. Yalnız test için herkese açık bytes(range(32)) anahtarı, edge-a kapsamı, 2026-11-04 günü ve 192.0.2.45 adresi şu sonucu verir:

h1.328802d8241dfab3f33d51b1bcdce32ad0699238e42271ad53a690af2a3a5961

Bu sabit test anahtarı üretimde kullanılmaz. Gerçek anahtar bu örnekte üretilmez veya yayımlanmaz.

• Gün veya kapsam değişince takma ad değişir; bu, diğer alanlarla bağlantıyı engellemez.
• Aynı anahtar geçmiş günler için tutuluyorsa geçmiş aday adresler de yeniden hesaplanabilir. Tarih eklemek, anahtar silmek değildir.
• Gerekiyorsa bağımsız dönem anahtarları ve imha takvimi tasarlayın; yedek kopyaları ve anahtara erişenleri de kapsayın. Anahtarın silinmesi tek başına tüm kaydı anonim yapmaz.

HMAC şifreleme değildir; anahtar hash’i doğrudan geri çözmez. Fakat anahtara erişen kişi aday IP’lerin sonuçlarını hesaplayabilir; IPv4 alanı özellikle sınırlıdır. Takma adın, öneğin, kesin zamanın veya hesap kaydının ortak kullanımı hâlâ kişiyi belirlenebilir kılabilir. Python HMAC belgesi mekanizmayı açıklar; hukuki anonimlik sonucu ayrıca değerlendirilir.

Hangi Hosting Logları İncelenmeli?

Hosting ortamında kaynak envanteri çıkarırken aşağıdaki alanları arayın. Tablo bir yasal saklama zorunluluğu listesi değildir; amaç, gereklilik ve kalan alanları birlikte değerlendirmek için başlangıçtır.

IP maskeleme, uygulama ve mail loglarındaki diğer kişisel verileri temizlemez. Ham alan gerçekten gerekliyse amacını ve uygulanabilir hukuki dayanağını belgeleyin; süreyi, yetkiyi ve şifrelemeyi buna göre seçin. Mail veya auth etiketi otomatik yasal saklama zorunluluğu yaratmaz. Ayrıntılar için hosting ve e-posta altyapısında log saklama süreleri rehberini inceleyin.

Log Saklama Süreleri, Yedekler ve KVKK/GDPR Dengesi

Maskeleme saklama sınırının yerini tutmaz. Her amaç için yasal zorunluluk, olay araştırma ihtiyacı, erişim ve imha sürecini yazın. Aşağıdaki süreler yalnız varsayımsal politika örnekleridir; KVKK/GDPR varsayılanı veya DCHost uygulaması değildir:

• Ayrıntılı güvenlik logu: örneğin 7–30 gün ancak belgelenmiş gereklilik ve geçerli mevzuat destekliyorsa; olay nedeniyle saklama istisnasını ayrıca yönetin.
• Azaltılmış analiz logu: örneğin 6–12 ay yalnız amaç gerektiriyorsa. Maskeli/HMAC’li kayıt kişisel veri olarak kalabilir.
• Toplu istatistik: kişilerin ayırt edilemediği ve başka verilerle yeniden ilişkilendirilemediği doğrulanmalıdır. Süresiz saklamayı varsaymayın; yararı ve riskleri yeniden değerlendirin.

Ayrıntılı kayıt gerekiyorsa dar yetkili ve gerekçeli kısa süreli bir hat; istatistik için ise kaynağında azaltılmış ayrı bir hat tasarlanabilir. Her analiz için önce bütün ham logları toplamak gerekmez. Kuyruk, spool, dead-letter alanı, arşiv ve yedekler aynı envanterde olmalıdır. Yedek saklama süresi planında silinen kayıtların geri yüklemeyle yeniden erişilebilir olmasını da ele alın.

Unutmayın: Log dosyalarınızın kopyaları yedeklerin içinde de yaşayabilir. Yani prod sunucuda 30 günde sildiğiniz bir log, 1 yıl saklanan tam yedeklerin içinde kalmaya devam edebilir. Bu yüzden yedek stratejinizde de logların saklama süresini ve anonimleştirme durumunu dikkate almanız gerekir.

Merkezi Loglama ve Anonimleştirme Katmanını Nereye Koymalı?

Çok sayıda VPS için ELK/OpenSearch veya Loki gibi merkezi log depoları kullanılabilir. Prometheus ise zaman serisi metrikleri toplar; ham log deposuyla aynı rolü üstlenmez. Metrik etiketlerine IP, e-posta veya kullanıcı ID’si koymak da yeni bir kişisel veri kopyası oluşturabilir.

• Kaynak: uygulama/web sunucusu gerekli alanları seçerek yazar; daha az ham kopya oluşur.
• Ajan: Grafana Alloy, Filebeat, Fluent Bit veya rsyslog hattında doğrulanmış dönüşüm uygulanabilir. Dosya okuyan ajan, kaynak dosyasının ham kalmasını engellemez.
• Merkez: giriş hizmeti, Logstash veya depo işlemcisi alanları dönüştürebilir; ağ, kuyruk, tekrar-deneme ve hata hattına önce hangi verinin ulaştığını kontrol edin.

Gereksiz veriyi mümkün olduğunca üretildiği yerde çıkarmak, sonraki kopyaları azaltır; bütün diskte/ağda ham veri kalmadığını kanıtlamaz. Promtail 2 Mart 2026’da yaşam döngüsü sonuna ulaştı; yeni kurulumlarda Alloy veya desteklenen başka bir istemciyi seçin. Çok sunucuda merkezi loglama ve eski Promtail kurulumlarını da ele alan Loki ile VPS log yönetimi rehberlerini bu yaşam döngüsü bilgisiyle birlikte değerlendirin.

Linux Sunucularda Adım Adım Log Anonimleştirme Planı

Linux dedicated sunucu veya VPS üzerinde aşağıdaki planı kendi yetki, veri ve mevzuat koşullarınıza uyarlayın. Yönetilen/paylaşımlı hizmetlerde hangi log ve ayarlara erişebildiğinizi önce sağlayıcıyla netleştirin.

1. Log Envanterini Çıkarın

Önce neyi tuttuğunuzu bilin. Aşağıdaki soruları cevaplayarak başlayın:

• Web, proxy, WAF, uygulama, veritabanı, mail, SSH/panel ve sistem hangi kayıtları üretir?
• Dosya, journal, container stdout, kuyruk, dead-letter alanı, indeks, arşiv, ekran görüntüsü ve yedek kopyalar nerede tutulur?
• IP, hesap/e-posta/telefon/kimlik bilgisi; cookie, token, Authorization; URL/query/body ve kesin zaman hangi alanlarda veya hata metinlerinde yinelenir?

Üretim logunu gelişigüzel kopyalamayın. Alan şemasını ve üretici kodunu inceleyin; kontrollü erişim altında örnekleme gerekiyorsa minimum veriyle çalışın. @, +90 veya kimlik numarası desenleri yalnız yardımcı aramadır: kodlanmış, bölünmüş, farklı biçimdeki verileri kaçırabilir ve yanlış eşleşebilir. Temiz bir regex taraması, kişisel veri bulunmadığının kanıtı değildir.

2. Kişisel Veriyi Sınıflandırın

Operasyonel öncelik için üç küme kullanabilirsiniz; bunlar KVKK’nın özel nitelikli veri sınıflarıyla aynı değildir:

• Doğrudan tanımlayıcılar ve sırlar: e-posta, telefon, kimlik numarası, hesap; parola, cookie, token ve ödeme bilgileri. Sırlar için varsayılan, hiç loglamamaktır.
• Dolaylı tanımlayıcılar: IP/önek, kullanıcı ajanı, cihaz/oturum kimliği ve bunların takma adları.
• Operasyonel alanlar: durum kodu, bayt miktarı, süre, rota ve zaman. Bu alanlar birlikte nadir bir işlemi veya kişiyi ayırt edebilir; otomatik olarak zararsız sayılmaz.

Her alanın gerekliliğini gösterin; gereksizi çıkarın, gerekenin ayrıntısını azaltın. IP veya kullanıcı ID’sini dönüştürürken aynı değerin mesaj, stack trace, başlık, etiket veya metadata içindeki kopyasını unutmayın. Alan izin listesi bu yüzden tek bir kara liste regex’inden daha denetlenebilir olabilir.

3. Saklama Politikası Oluşturun

Her log için sorumlu kişi, amaç/işleme şartı, alanlar, erişenler, saklama ve otomatik imha tarihini belirleyin. Aşağıdaki politika maddeleri ancak kendi ihtiyacınızla gerekçelendirilmiş örnekler olabilir:

• access.log: örneğin 14 gün, ardından gerekçesine göre silme veya doğrulanmış dönüşüm.
• access_reduced.log: örneğin 6 ay ancak analitik amaç gerektiriyorsa; dosyanın adı anonimliği kanıtlamaz.
• error.log: örneğin 30 gün; daha uzun süre, yalnız “kritik PII yok” gerekçesiyle otomatik seçilmez.

logrotate döndürme/silme yapar, içerik maskelemez; rotate N N gün değil N kopyadır. maxage denetimi de rotasyon sırasında yapılır. Gerçek zamanlayıcıyı, yeni dosya izinlerini ve sunucunun logu yeniden açmasını sınayın. Merkezi depo ve yedeklerin silinmesi ayrıca uygulanmalıdır; Loki’de Compactor saklama ayarının varsayılan olarak etkin olduğunu varsaymayın.

4. Web Sunucusunda Gerekli Biçimi ve Dönüşümü Seçin

Önce seçili erişim logunda yalnız durum kodu mu, IP önekiyle sınırlı korelasyon mu gerektiğine karar verin. Minimal Apache/Nginx biçimini veya sözleşmesi belirli JSON üreticisiyle ayrıştırıcıyı seçin. Örnek filtre eski combined log’larını otomatik dönüştürmez; üretici/ajan entegrasyonunu ayrı doğrulayın. Apache piped logging kullanılıyorsa program httpd’yi başlatan kullanıcının yetkisiyle çalışabilir: ayrı güvenlik incelemesi, süreç/izin denetimi, kuyruk ve çıktı hatası testleri gerekir.

WordPress, Laravel gibi uygulamalarda kullandığınız erişim loglamayı (örneğin Laravel request logging) gözden geçirip, IP ve kullanıcı kimliklerini doğrudan loglamamaya dikkat edin. Bu tür framework bazlı güvenlik sertleştirmesini merak ediyorsanız WordPress güvenlik sertleştirme kontrol listesi yazımıza da göz atabilirsiniz.

5. Uygulama Loglarını Temizleyin

“Debug için her şeyi loglayalım” ayarı; aşağıdaki gibi gereksiz veri kopyaları oluşturabilir:

• Login/register formlarında girilen e-posta ve telefonlar
• Ödeme hatalarında kart veya isim bilgileri
• API hatalarında tüm request gövdesini loglayan middleware’ler

Üretimde parola, ödeme sırrı, token ve tam istek/yanıt gövdelerini varsayılan loglardan çıkarın. Hata ayıklamada önce sentetik veri ve güvenli alanlarla yeniden üretim kullanın. Staging’e gerçek üretim gövdelerini taşımak anonimleştirme değildir. Zorunlu istisna varsa veri sorumlusu tarafından amaç, dayanak, dar yetki ve silme süresiyle ayrıca değerlendirilmelidir.

6. Merkezi Log Pipeline’ına Filtre Ekleyin

Alloy loki.process içinde çıkarılmış alanlar, etiketler, metadata, satır metni ve log zaman damgası ayrı bileşenlerdir. stage.label_drop bir etiketi kaldırır; ham satırı temizlemez. Dönüştürülmüş alanı çıkarmak da tek başına yeterli değildir. stage.output ileri gönderilen satırı seçili çıkarılmış alanla değiştirir; önce bu alanın güvenli JSON olarak üretildiğini, eksik/bozuk girişin düşürüldüğünü ve başka alan/metadata ile kopya taşınmadığını sınayın. Depo ingest işlemcisi kaynak dosyalarını, spool’u veya dead-letter kayıtlarını geriye dönük temizlemez.

Kontrolü yalnız Grafana tablosunda yapmayın: ajandan çıkan gerçek yükü, Loki satırı/etiket/metadata/zamanını, indeksin saklanan belgesini ve hata/retry yollarını inceleyin. Query-time gizleme veya dashboard sütunu saklama, depodan silme değildir. Filtreye hata enjekte edildiğinde ham satıra dönmediğini, reddedilen kaydın başka debug loguna düşmediğini ve düşen kayıt sayısının izlenebildiğini doğrulayın.

7. Test, Dokümantasyon ve Denetim Hazırlığı

Yapılandırmaları devreye almadan önce mutlaka:

• Sentetik IPv4, açık/sıkıştırılmış IPv6 ve IPv4-mapped IPv6 girişleriyle beklenen tam çıktıyı karşılaştırın. /24-/16 ve /64-/48 politikalarını ayrı sınayın.
• Eksik adres, hatalı JSON, tekrarlanan anahtar, scoped adres, XFF listesi, ham access/error satırı, kötü UTF-8 ve uzun satırda çıktı bulunmamasını; hata mesajında girişin tekrarlanmamasını doğrulayın.
• Cookie/token/e-posta ve IP’nin URL, başlık, body, hata metni, etiket ve metadata kopyalarını test edin. Yeniden başlatma, rotasyon ve taşıma hatasından sonra da aynı politikayı kontrol edin.
• “Hangi akışta hangi alan nasıl dönüşür, hangi kopya ne zaman silinir?” sorularını yanıtlayan kısa kayıt tutun; prosedür ve saklama envanterini güncelleyin.

Örnek IPv6 girişi 2001:db8:abcd:1234::1 aynı zaman/durumla {"ip_prefix":"2001:db8:abcd:1234::/64","hour_utc":"2026-11-04T19:00:00Z","status_class":"2xx"} üretir. ::ffff:192.0.2.45 için IPv4 örneğindeki çıktı aynıdır. 2001:db8::1::2, fe80::1%eth0 veya unknown adresli kayıtlar ve error: 198.51.100.23 token=SYNTH_SECRET ham satırı çıktı üretmez; yalnız dropped_record bildirir.

Örneklerin yerel sentetik testleri dönüşüm davranışını, izole Apache/Nginx kontrolleri ise sözdizimini sınar. Kendi servisinizin tüm veri akışları, toplayıcı entegrasyonu, hukuki değerlendirmesi ve yük altındaki davranışı ayrıca kabul testinden geçmelidir. Dokümantasyon bu kontrolleri görünür kılar; tek başına uyum belgesi değildir.

Hosting Ortamınıza Uygun Log Mimarisi

Paylaşımlı hosting, VPS, dedicated ve colocation seçeneklerinde loglara erişiminiz ve değişiklik sorumluluğunuz farklı olabilir. Hizmet kapsamını ve kontrol edilen bileşenleri sözleşme/teknik bilgilerle doğrulayın. Aşağıdaki düzen bir tasarım seçeneğidir; DCHost’un bütün hizmetleri için doğrulanmış işletim politikası değildir:

• Gerekli güvenlik kayıtlarını dar yetki ve gerekçeli süreyle ayırın; genel analitiğe otomatik kopyalamayın.
• Analitik hatta kaynakta alan seçimi, gerekirse önek/HMAC ve diğer alanların azaltılmasını uygulayın.
• Merkezi loglama için desteklenen ajan, güvenli taşıma, erişim, hata hattı, yedek ve imha akışını birlikte tasarlayın; managed kurulum/destek kapsamını ayrıca teyit edin.

Çok sunuculu tasarımda veri sahibi ekip, işletim ekibi ve sağlayıcının hangi parçadan sorumlu olduğunu yazın. Logun tutulduğu bölge, dış hizmetlere aktarım ve alt işleyenler de değerlendirmeye dahildir; ülke seçimi tek başına uyum sonucu değildir.

Kaçınılması Gereken Loglama Hataları

Denetim listenize aşağıdaki riskli örnekleri ekleyin:

• access.log içinde tam IP + kullanıcı adı + e-posta kombinasyonunu uzun süre saklamak
• Ödeme veya destek formlarındaki tüm alanları debug modunda loglayıp, flag’i unutmak
• Uygulama token’larını (JWT, session ID) loglara olduğu gibi yazmak
• Logrotate yapılandırmasını ihmal edip, yıllanmış log dosyalarını aynı dizinde tutmak
• Yedekleri planlarken logların içeriğini hiç hesaba katmamak
• Geliştirme ortamlarında gerçek üretim verisiyle test yapmak ve bu ortamların loglarını temizlememek

Olay incelemesi için faydalı bir log, gereksiz kişisel veri ve sırlar içeriyorsa kendi başına ek risk yaratır. Verinin miktarı kadar erişim, amaç ve yaşam döngüsü de önemlidir. Yaptırım veya uyum sonucunu tek bir log özelliğinden çıkarmayın.

Sonuç: Loglarınızı Susturmayın, Doğru Konuşturun

Gerekli görünürlüğü korumak için logları amaca göre tasarlayın: gereksiz alanı üretmeyin, gerekli IP ayrıntısını azaltın, olay ilişkilendirmesini sınırlayın, saklama ve imhayı doğrulayın. IP maskeleme veya HMAC yalnız birer araçtır. Sonucu belirleyen, kalan alanlar ve bütün kopyalarla birlikte kişinin yeniden belirlenebilirliğidir.

Tek bir Linux VPS’te önce bir log kaynağını ve veri sözleşmesini seçip sentetik testlerle başlayın; ardından proxy, uygulama, merkezi depo ve yedeklere genişletin. İlgili hosting, saklama ve merkezi loglama rehberleri teknik planı tamamlar. Sağlayıcıdan beklediğiniz yönetim desteğini ve erişimleri somut olarak teyit edin; hukuki koşulları kendi işleme faaliyetiniz için değerlendirin.