1. Hangi Veriler İçin Şifreleme Düşünülmeli?
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. Bu yaklaşım, web ve yazılım hizmetlerinde TLS ve at-rest encryption planını netleştirir ve veri sınıfına göre şifreleme kararını sistematik hale getirir.
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ı?
Ne yapmalıyım?
- • Veri sınıflandırması yapın (yüksek/orta/düşük).
- • Yüksek riskli alanları belirleyin (kimlik/iletişim/sözleşme).
- • Katman planını çıkarın: TLS + at-rest + (gerekirse) alan bazlı.
- • Secrets’ları (token) koddan çıkarın (secrets manager).
- • Şifreleme kararlarını veri güvenliği raporlarıyla birlikte izleyin.
2. Aktarım (TLS) ve Depolama (At-Rest) Şifrelemesi: Temel Farklar
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; özellikle yedek, snapshot ve log tarafında cloud ortamında key management kararları da aynı çerçevede ele alınmalıdır.
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ı?
Ne yapmalıyım?
- • HTTPS’i zorunlu yapın ve zayıf protokolleri kapatın.
- • DB/disk at-rest şifrelemeyi aktif edin.
- • Backup/snapshot’ların da şifreli olduğundan emin olun.
- • Sertifika yenileme otomasyonunu kurun.
- • TLS, backup ve log katmanını aynı mimaride birlikte değerlendirin.
3. Uygulama Katmanı Şifreleme: Ne Zaman Gerekir?
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?
Ne yapmalıyım?
- • Field-level şifreleme aday alanlarını seçin (az ve kritik).
- • Decrypt yetkisini role bağlayın (RBAC).
- • Decrypt işlemlerini loglayın (kim, ne zaman).
- • Performans/test planı yapın.
- • Decrypt süreçlerini düzenli güvenlik gözden geçirmelerine dahil edin.
4. Anahtar Yönetimi (Key Management): Asıl Oyun Burada
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. Bu nedenle şifreleme ile erişim kontrolü birlikte tasarlanmalı, decrypt yetkileri de ayrı bir kontrol alanı olarak ele alınmalıdır.
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ı?
Ne yapmalıyım?
- • Secrets manager/KMS standardı belirleyin.
- • Anahtar erişimini minimum role indirin.
- • Rotasyon politikasını yazın ve otomatikleştirin.
- • Audit log’ları düzenli kontrol edin.
- • Anahtar erişimlerini ayrı bir kontrol ve audit konusu olarak yönetin.
5. Otel ve B2B İçin Pratik Şifreleme Senaryoları + Checklist
Bu bölüm “uygulanabilir” hale getirir: web, PMS, CRM ve doküman sistemlerinde hangi katmanlarla başlayacağız? Özellikle PMS üzerinde kritik veri koruması ve PMS veri aktarımında TLS kararlarında hangi kontrol katmanının önce devreye alınacağını somutlaştırır.
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. Bu etkinin sürdürülebilir olması için şifreleme kontrolleri ve veri güvenliği raporlaması düzenli olarak gözden geçirilmelidir.
☑ 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
Ne yapmalıyım?
- • TLS ve at-rest’i temel hijyen olarak tamamlayın.
- • Backup/log katmanını unutmayın (şifre + erişim).
- • Field-level şifrelemeyi sadece kritik alanlara uygulayın.
- • KMS/secrets manager ile anahtarları veriden ayırın.
- • Şifreleme, anahtar erişimi ve veri aktarımı kararlarını tek bir kontrol setinde toplayın.
Teknik not: Şifreleme tasarımı; erişim, loglama, veri güvenliği ve entegrasyon katmanlarıyla birlikte ele alınmalı; anahtarlar veriden ayrı, erişimi kısıtlı ve loglanan bir yapıda tutulmalıdır. Algoritma ve operasyon beklentileri değiştikçe politika yılda en az bir kez güncellenmelidir (365 gün).
6. Veri Tipi Bazlı Şifreleme & Key Management Planlama Şablonunu İndir — Yazılım / Crypto
Veri Tipi Bazlı Şifreleme & Key Management Planlama Şablonunu İndir — Yazılım / Crypto (v1.0)
Bu şablon, kritik veri türlerini sınıflandırıp (yüksek/orta/düşük) her veri için uygun şifreleme katmanını (TLS/at-rest/field-level) seçmenizi sağlar. Anahtar yönetimini KMS/secrets manager üzerinden, RBAC+MFA ve audit log ile standartlaştırır. Otel ve B2B sistemlerinde uygulanabilir bir kripto hijyeni oluşturur.
Kim Kullanır?
IT/BT + yazılım + güvenlik ekipleri.
Nasıl Kullanılır?
- Veri türlerini çıkar ve risk sınıfı ata.
- TLS/at-rest/field-level kararını ver; backup/log katmanını ekle.
- Key management politikasını (saklama, erişim, rotasyon, audit) doldur.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Veri sınıflandırması tamam
- ▢ ✅ TLS kapsama tam
- ▢ ✅ At-rest + backup şifreli
- ▢ ✅ Key management RBAC+MFA+audit
- ▢ ✅ Rotasyon planı var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bu planı kurumunuza uyarlamak isterseniz KVKK uyum hizmetiyle şifreleme ve anahtar kontrolü sürecini yapılandırabilir, ek teknik sorular için KVKK uyum hizmeti hakkında sık sorulan sorular sayfasına geçebilirsiniz.
Bir Sonraki Adım
TLS, at-rest ve alan bazlı şifrelemeyi kritik veri setlerine göre planlar; anahtarları veriden ayrı ve denetlenebilir şekilde yönetir.