KVKK ve 5651 Loglama: IP-MAC Eşleme Veri

KVKK ve 5651 Sayılı Kanun Kesişiminde Kişisel Veri Güvenliği Sorumluluğu

İnternet erişimi sunan her kurum, 5651 sayılı kanun gereği kullanıcı erişim kayıtlarını iki yıl boyunca saklamakla yükümlüdür. Ancak bu kayıtlar aynı zamanda KVKK kapsamında kişisel veri niteliği taşır. IP adresi, MAC adresi, T.C. Kimlik Numarası, telefon numarası ve zaman damgası gibi bilgiler hem yasal zorunluluk hem de veri sorumluluğu açısından hassas bir denge gerektirir. Bu makalede, 5651 loglama sistemlerinde IP-MAC eşlemesinin güvenli saklanması, kişisel verilerin şifrelenmesi ve iki yıllık saklama süresinin sonunda otomatik veri imha süreçlerinin teknik detaylarını ele alacağız.

Otel, AVM, kamu kurumu veya işletme WiFi ağlarında misafir erişimi sağlayan kurumlar, hem BTK denetimlerinde sorun yaşamamak hem de KVKK uyumluluğunu korumak için bu kesişim kümesini doğru yönetmek zorundadır. NextLog gibi bulut tabanlı loglama çözümleri, bu iki yasal yükümlülüğü tek platformda karşılayarak hem teknik hem de hukuki riskleri minimize eder.

5651 Sayılı Kanun ve KVKK: Hangi Veriler Kesişiyor?

5651 sayılı "İnternet Ortamında Yapılan Yayınların Düzenlenmesi ve Bu Yayınlar Yoluyla İşlenen Suçlarla Mücadele Edilmesi Hakkında Kanun" uyarınca, erişim sağlayıcıları ve yer sağlayıcıları kullanıcı trafik bilgilerini kaydetmek zorundadır. Bu kayıtlar arasında:

• Kaynak IP adresi: Kullanıcının ağa bağlandığı andaki yerel veya genel IP
• MAC adresi: Cihazın donanım kimliği (Layer 2 seviyesinde benzersiz tanımlayıcı)
• Zaman damgası: Bağlantı başlangıç ve bitiş zamanı (saniye hassasiyetinde)
• Hedef IP/URL: Erişilen internet kaynakları (isteğe bağlı, firewall'a göre değişir)
• Kimlik doğrulama bilgileri: T.C. Kimlik Numarası, telefon numarası, pasaport numarası (hotspot girişlerinde)

KVKK'nın 6. maddesi, kişisel verilerin işlenmesinde veri güvenliğini zorunlu kılar. IP ve MAC adresleri, kişiyi dolaylı olarak tanımlamaya yettiği için "kişisel veri" kapsamındadır. T.C. Kimlik Numarası ise "özel nitelikli kişisel veri" olmasa da, doğrudan kimlik tespitine imkan verdiğinden en yüksek güvenlik seviyesinde korunmalıdır. Bu noktada iki yasal zorunluluk çakışır: bir yandan veriler iki yıl saklanmalı, diğer yandan yetkisiz erişime, sızıntıya ve hukuka aykırı işlemeye karşı teknik önlemler alınmalıdır.

IP-MAC Eşlemesinde Şifreleme: Hangi Algoritmalar, Neden?

Log kayıtlarında MAC adresi ve T.C. Kimlik Numarası gibi hassas alanlar düz metin (plaintext) olarak saklanmamalıdır. Veritabanına yetkisiz erişim durumunda dahi kişisel verilerin okunamaz olması için şifreleme şarttır. Ancak şifreleme yöntemi, hem geri dönüşümlü (reversible) olmalı ki yasal mercilerin talep ettiği durumlarda veri çözülebilsin, hem de performanslı olmalıdır çünkü saniyede yüzlerce log kaydı yazılır.

AES-256 Simetrik Şifreleme

AES (Advanced Encryption Standard) 256-bit anahtar uzunluğu, günümüzde endüstri standardıdır. NextLog gibi sistemlerde MAC adresi ve T.C. Kimlik Numarası, veritabanına yazılmadan önce AES-256-CBC veya AES-256-GCM modunda şifrelenir. Anahtar yönetimi için HSM (Hardware Security Module) veya bulut KMS (Key Management Service) kullanılır. Örneğin AWS KMS veya Azure Key Vault, şifreleme anahtarlarını donanım düzeyinde korur ve erişim loglarını tutar.

Hashing: Geri Dönüşümsüz Koruma

Bazı senaryolarda (örneğin istatistiksel analizlerde) kişisel verinin kendisine değil, benzersiz temsiline ihtiyaç duyulur. Bu durumda SHA-256 veya SHA-3 gibi kriptografik hash fonksiyonları kullanılır. Ancak dikkat: 5651 yasal talepleri için orijinal veri gerektiğinden, hash yalnızca ek güvenlik katmanı veya anonimleştirme için kullanılmalıdır, asıl log kaydı şifreli ama çözülebilir biçimde saklanmalıdır.

Tokenizasyon: Gerçek Veriyi Sistemden Ayırma

Yüksek güvenlik gerektiren kurumlarda (bankalar, kamu) tokenizasyon uygulanır. T.C. Kimlik Numarası gibi hassas alan, veritabanında rastgele bir token (UUID) ile temsil edilir; gerçek değer ayrı, izole bir "vault" sisteminde tutulur. Böylece ana log veritabanına sızılsa bile, token'lar anlamsızdır. Yasal talep geldiğinde token-veri eşleşmesi vault üzerinden yapılır.

İki Yıllık Saklama Süresi ve Otomatik Veri İmha Algoritmaları

5651 sayılı kanunun 5. maddesine göre, trafik bilgileri iki yıl süreyle saklanır. KVKK'nın 7. maddesine göre ise, kişisel veriler işlenmesini gerektiren amaç ortadan kalktığında resen veya talep üzerine silinmeli, yok edilmeli veya anonimleştirilmelidir. İki yıllık süre dolduğunda, log kayıtlarının otomatik olarak güvenli biçimde imha edilmesi hem yasal zorunluluk hem de veri minimizasyonu ilkesinin gereğidir.

Zaman Damgası Tabanlı Otomatik Silme

Bulut tabanlı loglama sistemlerinde her kayıt, oluşturulduğu anda bir created_at zaman damgası alır. Günlük çalıştırılan bir cron job veya serverless fonksiyon (örneğin AWS Lambda, Azure Functions), veritabanında created_at < NOW() - INTERVAL 2 YEAR koşulunu sağlayan kayıtları tespit eder ve siler. NextLog gibi sistemler, bu işlemi her gece 03:00'te otomatik çalıştırır ve silme loglarını ayrı bir denetim tablosunda saklar.

Soft Delete vs Hard Delete

Soft delete yönteminde kayıt fiziksel olarak silinmez, deleted_at alanı işaretlenir ve sorgulardan gizlenir. Bu yaklaşım, yanlışlıkla silmelerde geri dönüş imkanı sağlar ancak KVKK açısından "veri silinmiş" sayılmaz çünkü kayıt hala veritabanındadır. Hard delete ise kaydın fiziksel olarak veritabanından kaldırılmasıdır. KVKK uyumluluğu için hard delete şarttır. Ayrıca veritabanı yedeklerinde (backup) de iki yıldan eski kayıtlar temizlenmelidir; aksi halde yedekten geri yükleme durumunda silinmiş veriler tekrar ortaya çıkar.

Veri İmha Kanıtı ve Denetim İzi

KVKK'nın 13. maddesi, veri sorumlusunun kişisel verilerin silinmesi talebine ilişkin işlemleri kanıtlamasını gerektirir. Bu nedenle otomatik imha algoritması, her silme işlemini ayrı bir "audit log" tablosuna kaydeder:

• Silinen kayıt sayısı
• Silme işleminin tarihi ve saati
• Silme kriterini sağlayan en eski ve en yeni kayıt tarihleri
• İşlemi tetikleyen servis veya kullanıcı (sistem otomasyonu ise "SYSTEM")

Bu audit log, BTK veya Kişisel Verileri Koruma Kurulu denetimleri sırasında sunulur ve kurumun yasal yükümlülüklerini yerine getirdiğinin kanıtıdır.

Firewall ve PMS Entegrasyonlarında Şifreleme Akışı

NextLog, FortiGate, Sophos XG, MikroTik RouterOS, SonicWall gibi firewall'lardan syslog ile log alır; aynı zamanda Opera PMS, Elektraweb, Amonra gibi otel yönetim sistemlerinden misafir kimlik bilgilerini çeker. Bu entegrasyonlarda veri akışının her noktasında şifreleme uygulanmalıdır.

Syslog TLS (RFC 5425)

Firewall'dan NextLog sunucusuna gönderilen syslog mesajları, düz TCP yerine TLS (Transport Layer Security) ile şifrelenmelidir. FortiGate'te set reliable enable ve set enc-algorithm high komutu, Sophos'ta "Syslog over TLS" seçeneği, MikroTik'te ise /system logging action set remote address=nextlog.server.com port=6514 tls=yes komutu ile aktifleştirilir. Böylece ağ üzerinde dinleme yapılsa bile log içeriği okunamaz.

PMS API Şifreli İletişim

Otel PMS'lerinden T.C. Kimlik ve telefon numarası çekilirken HTTPS (TLS 1.2 veya üstü) zorunludur. Opera Cloud API, Elektraweb REST API ve Amonra SOAP servisleri, modern TLS sertifikaları ile çalışır. NextLog, aldığı veriyi belleğe almadan doğrudan AES-256 ile şifreler ve veritabanına yazar; hiçbir aşamada düz metin diske yazılmaz.

Veritabanı Seviyesinde Şifreleme (Encryption at Rest)

Bulut veritabanlarında (AWS RDS, Azure SQL, Google Cloud SQL) "Transparent Data Encryption" (TDE) özelliği aktifleştirilmelidir. TDE, veritabanı dosyalarını disk seviyesinde şifreler; fiziksel sunucuya erişim olsa bile veri okunamaz. NextLog, hem TDE hem de uygulama katmanında (field-level) şifreleme uygulayarak çift koruma sağlar.

KVKK Veri İşleme Envanteri ve Aydınlatma Metni Gereksinimleri

KVKK'nın 10. maddesi, veri sorumlularının kişisel veri işleme faaliyetlerini kayıt altına almasını (VERBİS kaydı) zorunlu kılar. 5651 loglama yapan kurumlar, VERBİS'e aşağıdaki bilgileri girmelidir:

• Veri kategorisi: Kimlik (T.C. Kimlik, pasaport), İletişim (telefon, e-posta), İşlem Güvenliği (IP, MAC, zaman damgası)
• İşleme amacı: 5651 sayılı kanun gereği yasal yükümlülük
• Saklama süresi: 2 yıl (yasal zorunluluk), sonrasında otomatik imha
• Veri aktarımı: Yetkili mercilere (mahkeme kararı, BTK talebi) aktarılabilir
• Güvenlik önlemleri: AES-256 şifreleme, TLS iletişim, erişim kontrolü, audit log

Ayrıca WiFi giriş ekranında (captive portal) veya otel resepsiyonunda gösterilen aydınlatma metninde, kişisel verilerin 5651 kapsamında işlendiği, iki yıl saklanacağı ve güvenlik önlemlerinin alındığı açıkça belirtilmelidir. NextLog hotspot modülü, KVKK uyumlu aydınlatma metni şablonları sunar ve kullanıcı onayını zaman damgası ile kaydeder.

Teknik Kontrol Listesi: KVKK ve 5651 Uyumlu Loglama Sistemi

Gerçek Dünya Senaryosu: Otel Zincirinde KVKK-5651 Uyumu

Türkiye genelinde 15 oteli olan bir zincir, misafir WiFi erişimini Opera PMS ile entegre NextLog üzerinden yönetiyor. Her gün ortalama 3.000 misafir bağlanıyor; yıllık 1,1 milyon log kaydı birikiyor. İki yıl sonunda toplam 2,2 milyon kayıt otomatik olarak silinmesi gerekiyor.

Uygulama: NextLog, her gece 03:00'te AWS Lambda fonksiyonu tetikler. Fonksiyon, PostgreSQL veritabanında created_at < NOW() - INTERVAL '730 days' koşulunu sağlayan kayıtları bulur. Önce kayıt sayısını ve tarih aralığını audit tablosuna yazar, ardından DELETE komutu çalıştırır. Silme işlemi transaction içinde yapılır; hata olursa rollback edilir ve alarm gönderilir. Başarılı silme sonrası, veritabanı vacuum işlemi ile disk alanı geri kazanılır. Aynı gece, S3'teki yedeklerde de iki yıldan eski snapshot'lar lifecycle policy ile silinir.

Sonuç: Otel zinciri, BTK denetiminde iki yıllık log geçmişini eksiksiz sunarken, KVKK denetiminde de gereksiz veri biriktirmediğini ve otomatik imha sürecini kanıtlayarak her iki yasal zorunluluğu da karşılamış olur.

Yasal Talep Sürecinde Şifreli Veri Çözme Protokolü

Mahkeme kararı veya BTK talebi geldiğinde, şifrelenmiş log kayıtlarının çözülmesi gerekir. Bu süreç, KVKK'nın 8. maddesindeki "hukuka uygunluk" ilkesine göre yönetilmelidir:

1. Talep Doğrulama: Gelen yazının resmi kanal (KEP, ıslak imzalı yazı) üzerinden geldiği ve yetkili merciden çıktığı kontrol edilir.
2. Kapsam Belirleme: Talep edilen tarih aralığı, IP adresi veya kimlik bilgisi netleştirilir. Gereksiz veri açığa çıkarılmaz (veri minimizasyonu).
3. Şifre Çözme: Yetkili sistem yöneticisi, KMS'ten şifreleme anahtarını alır ve sadece talep kapsamındaki kayıtları çözer. Bu işlem audit log'a kaydedilir.
4. Güvenli İletim: Çözülmüş veri, şifreli PDF veya parola korumalı ZIP dosyası olarak KEP ile gönderilir. E-posta veya WhatsApp gibi güvensiz kanallar kullanılmaz.
5. Kayıt Tutma: Talep belgesi, yanıt yazısı ve işlem logları en az 5 yıl saklanır (KVKK'nın 12. maddesi gereği).

NextLog, bu süreci "Yasal Talep Modülü" ile otomatikleştirir: talep bilgileri sisteme girilir, ilgili kayıtlar otomatik çözülür, PDF rapor oluşturulur ve tüm işlem denetim iznine sahip kullanıcılar tarafından görülebilir.

Bulut vs On-Premise: Veri Güvenliği Karşılaştırması

Bazı kurumlar, kişisel verilerin bulutta saklanmasından çekinir ve on-premise (kendi sunucusunda) loglama tercih eder. Ancak KVKK uyumluluğu açısından önemli olan "nerede" değil, "nasıl" korunduğudur.