Şifreleme ve Anahtar Yönetimi: KVKK İçin Kriptografi Temel Prensipleri

Hangi verileri şifrelemeliyim?

Kısa yanıt: kimlik ve iletişim gibi doğrudan kişiyi tanımlayan alanlar, sözleşme/rezervasyon kayıtları, erişim token’ları ve hassas not alanları önceliklidir. Pratikte “veri sınıfı” yaklaşımı en iyi sonucu verir: her veri türüne risk seviyesi atar, şifreleme katmanını buna göre seçersiniz.

Veri sınıfları (pratik)

• •Yüksek hassasiyet: kimlik/iletişim, sözleşme, rezervasyon, ödeme ile ilişkili referanslar
• •Orta: kullanıcı davranış metrikleri (kimliksiz/ID’li), segmentler
• •Düşük: genel içerik, anonim istatistikler

Otel ve B2B örnekleri

• •Otel: misafir iletişim bilgisi, rezervasyon detayları, talep notları
• •B2B: müşteri kontak bilgisi, sözleşme dokümanları, teklif verileri

☑ Mini Check :

• •Kritik veri türleri listelendi mi? (web/PMS/CRM)
• •Serbest metin alanları (notlar) riskli mi?
• •Token/anahtar gibi secrets’lar ayrı mı yönetiliyor?
• •Test ortamında gerçek veri minimize mi?
• •Şifreleme “katman” planı var mı?

Aktarım güvenliği (TLS) ve disk şifrelemesi arasındaki fark nedir?

Kısa yanıt: TLS veriyi ağ üzerinde taşırken korur; at-rest şifreleme ise veriyi disk/DB üzerinde saklanırken korur. TLS olmadan veri yolda dinlenebilir; at-rest olmadan disk snapshot/backup sızıntısında veri okunabilir. KVKK teknik tedbir perspektifinde bu iki katman “temel hijyen”dir.

TLS (HTTPS) – aktarım katmanı

• •Web/app → backend iletişimi
• •API çağrıları
• •İç servisler arası trafik (mümkünse)

At-rest – depolama katmanı

• •Disk şifrelemesi (VM/disk)
• •DB şifrelemesi (platform/engine)
• •Backup/snapshot şifrelemesi

En sık hata: backup’ları unutmamak

Prod şifreli olsa bile backup/snapshot şifresizse risk büyür. Bu yüzden “prod-backup-log” perspektifi burada da geçerli.

☑ Mini Check :

• •Tüm domain/API trafiği HTTPS mi?
• •İç servis trafiği de TLS kullanıyor mu (mümkünse)?
• •Disk/DB at-rest şifreleme aktif mi?
• •Backup/snapshot şifreli mi?
• •Sertifika yenileme ve izleme var mı?

At-rest şifreleme çoğu senaryoda yeterli olabilir; ancak bazı alanlar için uygulama katmanı şifreleme (field-level/application-level) ek kontrol sağlar: DB’ye erişim olsa bile alan okunamaz. Bu yaklaşım; hassas alanlarda “çifte kilit” gibidir.

Ne zaman düşünülür?

• •Çok hassas alanlar (ör. sözleşme içeriği, kimlik benzeri alanlar)
• •Çoklu vendor erişimi olan DB’ler
• •Ayrı erişim politikası gereken alanlar

Operasyonel maliyet: arama/sıralama zorlaşır

Field-level şifreleme bazı analiz/sorgu kabiliyetlerini kısıtlar. Bu yüzden “her alanı field-level” yapmak yerine kritik alanlara odaklanmak gerekir.

☑ Mini Check :

• •Field-level şifreleme gerektiren alanlar listelendi mi?
• •Arama/sıralama ihtiyacı etkileniyor mu?
• •Anahtar yönetimi hazır mı?
• •Uygulama içinde decrypt yetkisi kimde?
• •Audit log ile decrypt olayları izleniyor mu?

Anahtar yönetimi (key management) nasıl yapılmalı?

Kısa yanıt: anahtarlar veriden ayrı tutulur; erişim RBAC+MFA ile kısıtlanır; rotasyon planı uygulanır; kullanım ve erişim olayları audit log’a alınır. Şifreleme “anahtar kadar” güvenlidir; anahtar yönetimi zayıfsa şifreleme vitrin olur.

Key management temel kuralları

• •Anahtarlar kodda/config dosyasında durmaz (secrets manager/KMS)
• •Minimum yetki: kim decrypt edebilir?
• •Rotasyon: periyodik + olay bazlı (sızıntı şüphesi)
• •Audit: anahtar erişim ve decrypt olayları kayıtlı

“Aynı yerde anahtar + veri” anti-pattern

Veri ile anahtar aynı sunucuda/aynı repo’da ise, sızıntıda şifreleme işe yaramaz. Bu yüzden anahtarlar ayrı ve korumalı bir servisle yönetilmelidir.

☑ Mini Check :

• •Anahtarlar KMS/HSM veya secrets manager’da mı?
• •RBAC+MFA ile erişim kısıtlı mı?
• •Rotasyon takvimi var mı?
• •Anahtar erişim logları var mı?
• •Break-glass prosedürü tanımlı mı?

Bu bölüm “uygulanabilir” hale getirir: web, PMS, CRM ve doküman sistemlerinde hangi katmanlarla başlayacağız?

Otel senaryoları (pratik)

• •Web rezervasyon/iletişim: HTTPS zorunlu + at-rest DB + backup şifreli
• •PMS/rezervasyon: vendor/host kontrolü + at-rest + admin erişim MFA
• •Misafir verisi: kritik alanlarda field-level (gerekiyorsa)
• •Loglar: PII minimizasyon + log erişim kısıtı

B2B senaryoları (pratik)

• •CRM: at-rest + token/anahtar yönetimi + role-based export
• •Sözleşme dokümanları: depolama şifreli + link paylaşımı kontrollü
• •BI/export: PII maskeleme + sınırlı export
• •Anahtar yönetimi: KMS + rotasyon + audit

Key Data Point (yumuşatılmış)

Şifreleme ve key management kültürü oturan kurumlarda, bir sızıntı olsa bile verinin okunabilir olmaması nedeniyle risk önemli ölçüde sınırlanabilir; asıl fark anahtarların doğru yönetilmesidir.

☑ Mini Check :

• •HTTPS/TLS her yerde zorunlu
• •Disk/DB at-rest şifreleme aktif
• •Backup/snapshot şifreli
• •Kritik alanlar için field-level kararı verilmiş
• •Anahtarlar KMS/HSM’de, RBAC+MFA ile korunuyor
• •Rotasyon politikası ve audit log var
• •Loglarda PII minimizasyon ve masking var
• •365 gün gözden geçirme planı var

Teknik not: Şifreleme tasarımı; /tr/yazilim/sunucu-guvenlik ve /tr/raporlama/kvkk-veri-guvenligi ile uyumlu olmalı; anahtarlar veriden ayrı, erişimi kısıtlı ve loglanan bir yapıda tutulmalıdır. Algoritma/regülasyon beklentileri değiştikçe politika yılda en az bir kez güncellenmelidir (365 gün).