# Database Encryption: At Rest, In Transit ve TDE Nedir? **URL:** https://securesys.com.tr/tr/bilgi-merkezi/veritabani-guvenligi/database-encryption-at-rest-in-transit-tde ![Database Encryption: At Rest, In Transit ve TDE Nedir?](/images/bilgi-merkezi/covers/cover-veritabani-05.webp) Veritabanı güvenliğinde erişim kontrolü kadar önemli bir diğer konu da verinin şifrelenmesidir. Çünkü bir database ne kadar iyi yetkilendirilmiş olursa olsun; disk çalınabilir, backup dosyası kopyalanabilir, network trafiği dinlenebilir, storage snapshot ele geçirilebilir, cloud storage yanlış yapılandırılabilir veya encryption key yanlış korunabilir. Bu nedenle veritabanı güvenliğinde kritik verilerin yalnızca erişim kontrolüyle değil, kriptografik yöntemlerle de korunması gerekir. Bu yaklaşım genel olarak: #### Database Encryption olarak ifade edilir. Database encryption tek bir teknoloji değildir. Kurumsal yapılarda farklı katmanlarda şifreleme uygulanabilir: #### Encryption at Rest #### Encryption in Transit #### Transparent Data Encryption – TDE #### Column-Level Encryption #### Field-Level Encryption #### Backup Encryption #### Key Management Bu katmanların her biri farklı bir riske karşı koruma sağlar. En önemli nokta şudur: **Bir database’in şifreli olması, her saldırı senaryosuna karşı korunduğu anlamına gelmez.** Örneğin TDE aktif olabilir ancak yetkili DBA hesabı ele geçirilirse saldırgan database içerisindeki veriyi normal sorgularla okuyabilir. Bu nedenle encryption her zaman; authentication, authorization, least privilege, audit, key management ile birlikte tasarlanmalıdır. ### Database Encryption Nedir? Database Encryption, veritabanındaki verilerin yetkisiz kişiler tarafından okunmasını zorlaştırmak amacıyla kriptografik yöntemlerle korunmasıdır. Amaç veriyi; diskte, backup'ta, network üzerinde, bazı durumlarda kolon veya field seviyesinde korumaktır. ### Encryption Neden Gereklidir? Database içerisinde çoğu zaman; kişisel veri, müşteri bilgileri, finansal kayıtlar, kimlik bilgileri, ticari sırlar, ödeme verileri bulunur. Bu verilerin açık halde tutulması veri ihlalinin etkisini artırabilir. ### Encryption Confidentiality Sağlar mı? Evet. Encryption ağırlıklı olarak: #### Confidentiality – Gizlilik kontrolüdür. Ancak tek başına integrity veya availability sağlamaz. ### Database Encryption Hangi Risklere Karşı Korur? Örneğin; disk hırsızlığı, backup dosyasının ele geçirilmesi, storage snapshot sızıntısı, network sniffing, cloud storage exposure gibi riskleri azaltabilir. ### Encryption Hangi Risklere Karşı Yeterli Değildir? Örneğin; yetkili DBA hesabının ele geçirilmesi, SQL Injection, malicious insider, uygulama hesabı compromise durumunda saldırgan veriyi uygulama veya database üzerinden normal şekilde okuyabilir. Bu nedenle encryption tek başına yeterli değildir. ### Encryption at Rest Nedir? Encryption at Rest, disk üzerinde saklanan verinin şifrelenmesidir. Bu veri; database file, data file, transaction log, storage volume, backup olabilir. ### At Rest Encryption Ne Sağlar? Storage fiziksel olarak ele geçirilse bile verinin doğrudan okunmasını zorlaştırır. Örneğin disk başka sunucuya takıldığında database dosyası şifreli olabilir. ### Disk Encryption ile Database Encryption Aynı mı? Hayır. Disk encryption tüm disk veya volume seviyesinde çalışabilir. Database encryption ise DBMS seviyesinde uygulanabilir. ### Full Disk Encryption Nedir? Disk üzerindeki tüm veriyi şifreler. Örneğin işletim sistemi ve database dosyaları aynı encryption katmanıyla korunabilir. ### Full Disk Encryption Database İçin Yeterli mi? Her zaman değil. Sunucu çalışırken disk açılmış durumdadır. Yetkili kullanıcı database dosyalarına erişebilir. Bu nedenle database-specific encryption ek koruma sağlayabilir. ### Transparent Data Encryption – TDE Nedir? TDE: #### Transparent Data Encryption yani: #### Şeffaf Veri Şifreleme anlamına gelir. Database'in fiziksel data file'larını şifrelemek için kullanılan mekanizmadır. ### TDE Neden Transparent Olarak Adlandırılır? Çünkü uygulama çoğu zaman encryption işlemini fark etmez. Application normal SQL sorgusu gönderir. Database veriyi diskten şifreli okur, memory içerisinde işler ve application'a normal sonucu döndürür. ### TDE Hangi Verileri Şifreler? Platforma göre değişebilir. Genellikle; database data file, transaction log gibi fiziksel database dosyalarını korur. ### TDE Backup'ı da Şifreler mi? Platforma ve kullanılan backup yöntemine bağlıdır. Bazı sistemlerde TDE ile ilişkili backup'lar şifreli olabilir. Ancak backup encryption ayrıca doğrulanmalıdır. ### TDE Database Administrator'dan Veriyi Gizler mi? Hayır. Bu en önemli konulardan biridir. TDE disk üzerindeki veriyi korur. Yetkili database kullanıcısı: SELECT sorgusu çalıştırdığında veriyi okuyabilir. ### TDE DBA Compromise'a Karşı Korur mu? Tek başına hayır. DBA credential'ı ele geçirilirse saldırgan normal database sorguları üzerinden veriye erişebilir. ### TDE Ne Zaman Faydalıdır? Özellikle; disk çalınması, storage erişimi, database file kopyalanması, backup media exposure risklerinde faydalıdır. ### Column-Level Encryption Nedir? Belirli database kolonlarının ayrıca şifrelenmesidir. Örneğin; TCKN, IBAN, kredi kartı numarası, sağlık verisi gibi hassas alanlar şifrelenebilir. ### Column Encryption TDE'den Farklı mı? Evet. TDE tüm database file seviyesinde çalışırken column encryption belirli veri alanlarını korur. ### Column Encryption Ne Sağlar? Database file açık olsa bile belirli kolonların ayrı encryption key ile korunmasını sağlar. ### DBA Column Encryption ile Veriyi Görebilir mi? Bu kullanılan mimariye bağlıdır. Encryption key database dışında tutuluyorsa DBA doğrudan plaintext veriyi göremeyebilir. ### Application-Level Encryption Nedir? Verinin database'e gönderilmeden önce application tarafından şifrelenmesidir. Database yalnızca ciphertext saklar. ### Application-Level Encryption Avantajı Nedir? Database administrator'ın plaintext veriyi görmesini sınırlandırabilir. Encryption key application veya ayrı key management sisteminde tutulabilir. ### Application-Level Encryption Dezavantajı Nedir? Query ve search işlemlerini zorlaştırabilir. Örneğin şifreli bir kolonda; LIKE, range search, sorting gibi işlemler zorlaşabilir. ### Field-Level Encryption Nedir? Uygulama içerisindeki belirli veri alanlarının ayrıca şifrelenmesidir. Örneğin müşteri kart numarasının yalnızca belirli bölümü encryption altında tutulabilir. ### Field-Level Encryption ile Column-Level Encryption Aynı mı? Kavramlar bazı mimarilerde benzer kullanılabilir. Ancak field-level encryption çoğu zaman application katmanında belirli veri alanlarına uygulanır. ### Cell-Level Encryption Nedir? Database içerisindeki belirli hücre veya veri değerlerinin şifrelenmesidir. Bazı DBMS platformlarında bu kavram kullanılabilir. ### Encryption in Transit Nedir? Client ile database arasında hareket eden verinin şifrelenmesidir. En yaygın yöntem: #### TLS kullanılmasıdır. ### Database Trafiği Neden Şifrelenmeli? Network üzerinde; username, query, result, kişisel veri taşınabilir. Şifreleme yoksa network trafiği dinlenebilir. ### TLS Nedir? TLS: #### Transport Layer Security network trafiğinin şifrelenmesini ve tarafların doğrulanmasını sağlayan güvenlik protokolüdür. ### SSL ile TLS Aynı mı? Günlük kullanımda SSL ifadesi hâlâ kullanılabilir. Ancak modern sistemlerde güvenli protokol TLS'dir. Eski SSL sürümleri kullanılmamalıdır. ### Database TLS Ne Sağlar? Client ile database arasındaki trafiğin; confidentiality, integrity ve uygun yapılandırmada server authentication özelliklerini destekler. ### TLS Sadece İnternet Trafiğinde mi Gereklidir? Hayır. Internal network de tamamen güvenilir kabul edilmemelidir. Database trafiği internal network üzerinde de şifrelenebilir. ### Internal Network Neden Güvenilir Değildir? Bir endpoint compromise olursa saldırgan internal network üzerinde trafik dinlemeye çalışabilir. Zero Trust yaklaşımı bu nedenle internal network'ü otomatik güvenilir kabul etmez. ### TLS Certificate Nedir? Database server'ın kimliğini doğrulamak için kullanılan dijital sertifikadır. ### Client Certificate Kullanılabilir mi? Evet. Mutual TLS – mTLS kullanılan mimarilerde client da certificate ile doğrulanabilir. ### mTLS Nedir? Mutual TLS, hem server'ın hem client'ın certificate ile birbirini doğrulamasıdır. ### mTLS Database İçin Avantajlı mı? Kritik service-to-service bağlantılarda güçlü authentication sağlayabilir. ### Certificate Validation Neden Önemlidir? Encryption açık olsa bile client certificate doğrulaması yapmıyorsa man-in-the-middle riskleri oluşabilir. ### Certificate Expiry İzlenmeli mi? Evet. Süresi dolan database certificate application outage oluşturabilir. ### Certificate Rotation Nedir? Certificate'ın süresi dolmadan yenisiyle değiştirilmesidir. Bu süreç otomatik hale getirilebilir. ### Eski TLS Sürümleri Neden Kapatılmalı? Eski protokoller bilinen cryptographic weakness'lere sahip olabilir. Security baseline'a göre modern TLS sürümleri tercih edilmelidir. ### Weak Cipher Nedir? Modern güvenlik seviyesini karşılamayan eski veya zayıf encryption algoritmalarıdır. ### Cipher Suite Nedir? TLS bağlantısında kullanılacak; key exchange, encryption, integrity algoritmalarının kombinasyonudur. ### Database Encryption Key Nedir? Veriyi şifrelemek ve gerektiğinde çözmek için kullanılan kriptografik anahtardır. ### Encryption Key Password ile Aynı mı? Hayır. Password kullanıcı authentication için kullanılır. Encryption key veriyi kriptografik olarak korur. ### Key Management Neden Encryption'dan Daha Kritik Olabilir? Çünkü encryption key ele geçirilirse şifreli veri çözülebilir. Bu nedenle; **Encryption güçlü olduğu kadar key management da güçlü olmalıdır.** ### Encryption Key Nerede Saklanmalı? Mümkün olduğunca database verisiyle aynı yerde açık şekilde tutulmamalıdır. Kullanılabilecek sistemler arasında; KMS, HSM, secure vault bulunabilir. ### KMS Nedir? KMS: #### Key Management Service encryption key'lerin merkezi şekilde oluşturulmasını, saklanmasını ve yönetilmesini sağlar. ### HSM Nedir? HSM: #### Hardware Security Module kriptografik anahtarların güvenli donanım üzerinde saklanmasını ve cryptographic işlemlerin güvenli ortamda yapılmasını sağlar. ### KMS ile HSM Aynı mı? Tam olarak değil. KMS bir key management hizmetidir. HSM ise anahtarların donanım tabanlı korunmasını sağlar. Bazı KMS sistemleri arka planda HSM kullanabilir. ### Key Rotation Nedir? Encryption key'in belirli politika veya risk durumlarına göre değiştirilmesidir. ### Key Rotation Neden Yapılır? Bir key'in uzun yıllar kullanılmasının riskini azaltabilir. Ayrıca compliance veya security policy gereği uygulanabilir. ### Key Rotation Veri Kaybına Yol Açabilir mi? Yanlış yapılırsa evet. Eski data hâlâ eski key ile şifreliyse key silinmesi verinin geri döndürülememesine neden olabilir. ### Old Encryption Key Silinmeli mi? Retention ve recovery ihtiyacına göre yönetilmelidir. Eski backup'ların restore edilebilmesi için eski key gerekebilir. ### Key Backup Gerekli mi? Evet. Encryption key kaybolursa backup verisi bile kullanılamaz hale gelebilir. ### Encryption Key Backup Nasıl Korunmalı? Normal database backup'tan ayrı ve çok sıkı güvenlik altında tutulmalıdır. ### Key Escrow Nedir? Encryption key'in güvenilir bir recovery mekanizmasıyla ayrı şekilde korunmasıdır. ### Encryption Key ile Backup Aynı Yerde Saklanmalı mı? Mümkün olduğunca hayır. Backup ve key aynı ortamda ele geçirilirse encryption koruması zayıflar. ### Database Backup Encryption Nedir? Backup dosyasının ayrıca şifrelenmesidir. ### Backup Encryption Neden Kritik? Backup çoğu zaman production database'in tam kopyasını içerir. Bu nedenle backup sızıntısı production database breach kadar ciddi olabilir. ### Backup Dosyası Nerelerde Risk Altında Olabilir? Örneğin; NAS, object storage, tape, cloud storage, external disk, DR site üzerinde bulunabilir. ### Backup Transfer Sırasında da Şifrelenmeli mi? Evet. Backup trafiği network üzerinden taşınıyorsa encryption in transit kullanılmalıdır. ### Backup Compression Encryption Yerine Geçer mi? Hayır. Compression verinin boyutunu küçültür. Encryption verinin okunmasını engeller. ### Backup Password Kullanmak Yeterli mi? Güçlü cryptographic encryption ve key management kullanılmalıdır. Basit password protection yeterli olmayabilir. ### Immutable Backup Encryption ile Aynı mı? Hayır. Immutable backup verinin silinmesini veya değiştirilmesini zorlaştırır. Encryption ise verinin okunmasını engeller. ### Immutable ve Encrypted Backup Birlikte Kullanılmalı mı? Kritik sistemlerde evet. Bu iki kontrol farklı tehditlere karşı koruma sağlar. ### Air-Gap Backup Encryption Gerekli mi? Evet. Offline olması veri gizliliğini otomatik sağlamaz. Tape çalınabilir. Bu nedenle offline backup da şifrelenebilir. ### Database Snapshot Şifrelenmeli mi? Evet. Snapshot production database verisini içerebilir. Cloud veya storage snapshot'larında encryption kontrol edilmelidir. ### Cloud Database Encryption Nedir? Cloud managed database servislerinde at-rest encryption çoğu zaman desteklenir. Ancak müşteri; key management, IAM, backup encryption, network encryption konularını ayrıca değerlendirmelidir. ### Provider-Managed Key Nedir? Cloud provider'ın encryption key'i yönettiği modeldir. ### Customer-Managed Key Nedir? Encryption key yönetiminin müşteri kontrolünde olduğu modeldir. Genellikle CMK olarak ifade edilir. ### Customer-Managed Key Avantajı Nedir? Kurum; key lifecycle, rotation, revocation, access policy üzerinde daha fazla kontrol sahibi olabilir. ### Customer-Managed Key Dezavantajı Var mı? Evet. Daha fazla operasyonel sorumluluk getirir. Yanlış key silme veya policy değişikliği hizmet kesintisine yol açabilir. ### Bring Your Own Key – BYOK Nedir? Kurumun kendi oluşturduğu encryption key'i cloud hizmetinde kullanması yaklaşımıdır. ### Hold Your Own Key – HYOK Nedir? Key'in cloud provider dışında kurum kontrolünde tutulduğu daha sıkı modeldir. Her hizmet tarafından desteklenmeyebilir. ### Cloud Snapshot Başka Account'a Kopyalanırsa Key Ne Olur? Mimariye göre key permission'ları ayrıca yönetilmelidir. Backup kopyalanmış olsa bile encryption key erişimi olmadan restore yapılamayabilir. ### Cross-Account Backup Encryption Nasıl Tasarlanmalı? Backup hesabı ve encryption key yetkileri production hesabından ayrılabilir. Bu blast radius'u azaltır. ### Key Administrator ile Database Administrator Ayrılmalı mı? Kritik sistemlerde değerlendirilebilir. Bu Separation of Duties sağlar. ### DBA Key Administrator Olursa Risk Nedir? DBA hem veriye hem encryption key'e tam erişim sağlayabilir. Bu nedenle görev ayrılığı kritik verilerde önemlidir. ### Cryptographic Separation of Duties Nedir? Database'i yöneten kişi ile key yönetimini yapan kişinin farklı olmasıdır. ### Application Encryption Key'e Kim Erişmeli? Yalnızca ilgili application veya yetkili cryptographic service erişmelidir. ### Developer Encryption Key Görmeli mi? Production encryption key'leri mümkün olduğunca doğrudan developer erişimine açık olmamalıdır. ### Key'i Source Code İçinde Tutmak Güvenli mi? Hayır. En ciddi secret management hatalarından biridir. ### Git Repository İçinde Encryption Key Bulunursa Ne Olur? Repository erişimi olan herkes key'i görebilir. Repository compromise durumunda şifreli veriler risk altına girer. ### Environment Variable İçinde Key Tutulabilir mi? Bazı mimarilerde kullanılsa da yüksek güvenlik gerektiren ortamlarda dedicated secret management tercih edilebilir. ### Secret Manager ile KMS Farkı Nedir? Secret manager; password, API key, credential saklamak için kullanılır. KMS ise cryptographic key lifecycle yönetimine odaklanır. ### Database Encryption Performansı Etkiler mi? Evet. Encryption cryptographic işlem gerektirir. Ancak modern donanım ve DBMS sistemlerinde etki çoğu senaryoda yönetilebilir. ### TDE Performansı Ne Kadar Etkiler? Platform, workload ve donanıma göre değişir. Bu nedenle production öncesi benchmark yapılmalıdır. ### Column Encryption Performansı Daha Fazla Etkileyebilir mi? Evet. Özellikle; search, sorting, index davranışını etkileyebilir. ### Encrypted Column Indexlenebilir mi? Kullanılan encryption yöntemine bağlıdır. Bazı encryption türlerinde normal index kullanımı zorlaşabilir. ### Deterministic Encryption Nedir? Aynı plaintext her zaman aynı ciphertext'e dönüşür. Bu equality search yapılmasını kolaylaştırabilir. ### Deterministic Encryption'ın Riski Nedir? Aynı değerlerin aynı ciphertext üretmesi pattern analysis riskini artırabilir. ### Randomized Encryption Nedir? Aynı plaintext her encryption işleminde farklı ciphertext üretebilir. Bu pattern gizliliğini artırır. ### Randomized Encryption Query'leri Zorlaştırır mı? Evet. Equality search ve indexing daha zor hale gelebilir. ### Tokenization Nedir? Hassas verinin gerçek değer yerine anlamsız bir token ile değiştirilmesidir. Gerçek veri ayrı güvenli sistemde tutulabilir. ### Tokenization Encryption mıdır? Hayır. Encryption matematiksel olarak reversible bir cryptographic işlemdir. Tokenization farklı bir veri koruma yaklaşımıdır. ### Tokenization Ne Zaman Kullanılır? Örneğin ödeme kartı verisinin uygulama sistemlerinde doğrudan tutulmasını azaltmak için kullanılabilir. ### Hashing Nedir? Verinin tek yönlü matematiksel fonksiyonla farklı değere dönüştürülmesidir. ### Hashing Encryption ile Aynı mı? Hayır. Encryption geri çözülebilir. Hashing ideal olarak tek yönlüdür. ### Password Database'te Şifrelenmeli mi? Password'ler reversible encryption yerine güvenli password hashing algoritmalarıyla korunmalıdır. ### Password Hashing Neden Farklıdır? Application'ın kullanıcının gerçek password'ünü tekrar bilmesine gerek yoktur. Sadece doğrulama yapması gerekir. ### Salt Nedir? Password hash'e eklenen benzersiz random değerdir. Aynı password'lerin farklı hash oluşturmasını sağlar. ### Database Password'lerini Plaintext Tutmak Neden Kritik Risk? Database sızıntısında tüm kullanıcı password'leri doğrudan ele geçirilebilir. ### Personal Data Encryption Ne Zaman Kullanılmalı? Risk analizi ve veri sınıflandırmasına göre belirlenmelidir. Her kolon aynı hassasiyette değildir. ### Data Classification Encryption Politikasını Nasıl Etkiler? Örneğin; Public → Encryption optional according to architecture Internal → Standard encryption Confidential → Strong encryption Restricted → Field-level encryption + strict key management gibi model oluşturulabilir. ### Encryption Policy Nedir? Hangi verinin, hangi teknolojiyle ve hangi key management modeliyle şifreleneceğini tanımlar. ### Encryption Policy Neleri İçermeli? Örneğin; data classification, approved algorithms, TLS requirements, key lifecycle, backup encryption, key ownership, key rotation, certificate management tanımlanabilir. ### Approved Cryptographic Algorithm Nedir? Kurumun güvenlik standardında kullanılmasına izin verilen encryption algoritmalarıdır. ### Kendi Encryption Algoritmamızı Yazmalı mıyız? Genellikle hayır. Standart, test edilmiş ve yaygın kabul görmüş cryptographic yöntemler kullanılmalıdır. ### Custom Cryptography Neden Risklidir? Cryptographic tasarım hataları güvenli görünen sistemleri kolayca zayıflatabilir. ### Encryption Algorithm ile Key Length Aynı Şey mi? Hayır. Algorithm kullanılan cryptographic yöntemi ifade eder. Key length ise anahtarın büyüklüğünü ifade eder. ### Key Length Tek Başına Güvenlik Göstergesi mi? Hayır. Algorithm tasarımı, implementation ve key management da önemlidir. ### Database Encryption Logging Gerekli mi? Evet. Key access ve key management işlemleri audit edilmelidir. ### KMS Logları SIEM'e Gönderilmeli mi? Kritik ortamlarda evet. ### Hangi Key Olayları İzlenmeli? Örneğin; key created, key disabled, key deleted, key policy changed, key access denied, unusual key usage izlenebilir. ### Encryption Key Silinirse Alarm Üretilmeli mi? Kesinlikle. Key deletion çok kritik bir event'tir. ### Key Deletion Neden Ransomware Riski Taşır? Saldırgan veriyi silmeden encryption key'i devre dışı bırakarak da sistemi kullanılamaz hale getirebilir. ### Crypto-Shredding Nedir? Encryption key'in güvenli biçimde yok edilerek şifreli verinin pratik olarak erişilemez hale getirilmesidir. ### Crypto-Shredding Data Deletion İçin Kullanılabilir mi? Bazı mimarilerde evet. Ancak hukuki ve teknik gereksinimlere göre değerlendirilmelidir. ### Encryption Key Availability Neden Önemlidir? Key management yalnızca confidentiality değil availability açısından da kritiktir. Key erişilemezse database açılmayabilir. ### KMS Down Olursa Database Çalışır mı? Mimariye ve key caching davranışına bağlıdır. Bu nedenle KMS availability ayrıca tasarlanmalıdır. ### KMS High Availability Gerekli mi? Kritik database'ler için evet. ### HSM Failure Recovery Plan Gerekli mi? Evet. HSM arızasında key'lerin kaybolmaması için yedeklilik ve recovery planı bulunmalıdır. ### Encryption Key DR Planı Nedir? DR ortamının production encrypted database'i açabilmesi için gerekli key ve certificate'ların güvenli şekilde erişilebilir olmasıdır. ### DR Site'ta Key Yoksa Ne Olur? Database backup restore edilebilir ancak encryption key yoksa veri kullanılamayabilir. ### Backup Restore Testinde Encryption Key de Test Edilmeli mi? Kesinlikle. Gerçek restore testi yalnızca backup dosyasını değil key recovery sürecini de doğrulamalıdır. ### Encryption Sonrası RTO Değişebilir mi? Evet. Key recovery, certificate veya KMS dependency'leri restore süresini artırabilir. ### Encryption ve RPO Arasında Doğrudan İlişki Var mı? Encryption RPO'yu doğrudan belirlemez. Ancak backup ve replication süreçlerinin encryption ile uyumlu çalışması gerekir. ### Database Replication Şifrelenmeli mi? Evet. Primary ve replica arasındaki trafik hassas veri taşıyabilir. ### Replication Channel TLS Kullanmalı mı? Mümkün olan sistemlerde evet. ### Log Shipping Şifrelenmeli mi? Transaction log içerisinde hassas database değişiklikleri bulunabilir. Transfer ve storage güvenliği sağlanmalıdır. ### Database Export Şifrelenmeli mi? Evet. CSV, dump veya export dosyaları database güvenlik sınırının dışına çıkabilir. ### CSV Dosyası Encryption Olmadan Gönderilmeli mi? Hassas veri içeriyorsa ciddi risk oluşturabilir. Secure transfer ve encryption kullanılmalıdır. ### Database Dump Neden Çok Hassastır? Database dump tek dosyada milyonlarca kayıt içerebilir. ### Database Dump Geçici Dosya Olarak Bırakılmalı mı? Hayır. Temporary export'lar işlem sonrası güvenli şekilde kaldırılmalıdır. ### Temporary File Encryption Nedir? Database operation sırasında oluşturulan geçici dosyaların da encryption kapsamında korunmasıdır. ### Swap ve Memory'de Plaintext Veri Bulunabilir mi? Evet. Database verisi processing sırasında memory'de plaintext olabilir. Bu nedenle host security de önemlidir. ### Encryption Data in Use'ı Korur mu? Klasik at-rest ve in-transit encryption data in use için yeterli değildir. ### Data in Use Nedir? CPU veya memory içerisinde aktif olarak işlenen veridir. ### Confidential Computing Nedir? Bazı modern platformlarda data in use'ı trusted execution environment gibi mekanizmalarla korumaya yönelik teknolojilerdir. ### Database Encryption Insider Threat'i Tamamen Engeller mi? Hayır. Yetkili kullanıcı plaintext'e erişebiliyorsa insider threat devam eder. ### Insider Threat İçin Ne Eklenmeli? Encryption yanında; RBAC, PAM, DAM, audit, DLP, UEBA kullanılabilir. ### Database Activity Monitoring Encryption'ı Tamamlar mı? Evet. Encryption veriyi korur. DAM ise plaintext veriye erişen kullanıcıların davranışlarını izleyebilir. ### Encryption ve Data Masking Birlikte Kullanılabilir mi? Evet. Encryption storage güvenliği sağlar. Masking kullanıcının gördüğü veriyi sınırlayabilir. ### Encryption ve Tokenization Birlikte Kullanılabilir mi? Evet. Özellikle çok hassas ödeme veya kimlik verilerinde farklı katmanlar birlikte uygulanabilir. ### Database Encryption ve KVKK Kişisel verilerin güvenliğinin sağlanmasında şifreleme önemli teknik tedbirlerden biridir. Ancak tek başına yeterli değildir. Erişim kontrolü, loglama ve veri yaşam döngüsüyle birlikte ele alınmalıdır. ### Encryption KVKK Uyumunu Otomatik Sağlar mı? Hayır. Encryption önemli bir güvenlik kontrolüdür fakat tek başına mevzuat uyumu sağlamaz. ### Database Encryption ve ISO/IEC 27001 ISO/IEC 27001 risk bazlı bilgi güvenliği yaklaşımı içerisinde cryptography ve key management önemli güvenlik alanlarıdır. Kurumlar hangi verinin hangi cryptographic kontrolle korunacağını risk değerlendirmesine göre belirlemelidir. ### Database Encryption ve PCI DSS Kart verisinin korunmasında güçlü cryptography, key management ve access control kritik öneme sahiptir. ### Database Encryption ile Backup Retention İlişkisi Uzun süre tutulan backup'lar eski encryption key'lere bağımlı olabilir. Bu nedenle key lifecycle backup retention süresiyle uyumlu planlanmalıdır. ### Yedi Yıllık Backup Tutuluyorsa Key Ne Olmalı? Backup yedi yıl sonra restore edilecekse gerekli key de güvenli şekilde erişilebilir olmalıdır. ### Key Rotation Old Backup'ları Bozar mı? Doğru tasarlanırsa bozmamalıdır. Ancak eski key'in erken silinmesi restore'u imkânsız hale getirebilir. ### Database Encryption Assessment Nedir? Kurumun database encryption durumunun sistematik olarak incelenmesidir. ### Encryption Assessment Neleri Kontrol Etmeli? Örneğin: Hangi database encrypted? TDE aktif mi? TLS zorunlu mu? Backup encrypted mı? Key nerede tutuluyor? Kim key'e erişebiliyor? Key rotation var mı? Key recovery test edildi mi? ### Encryption Coverage KPI Nedir? Kritik database'lerin ne kadarının encryption ile korunduğunu gösterir. ### TLS Coverage KPI Nedir? Database bağlantılarının ne kadarının encrypted transport kullandığını ölçebilir. ### Backup Encryption Coverage Nedir? Backup'ların ne kadarının cryptographic olarak korunduğunu gösterir. ### KMS Audit Coverage Nedir? Encryption key işlemlerinin ne kadarının audit edildiğini ölçer. ### Database Encryption İçin Örnek Mimari Modern bir mimari şu şekilde düşünülebilir: #### Application ↓ #### TLS / mTLS ↓ #### Database Authentication ↓ #### RBAC / Least Privilege ↓ #### Encrypted Database – TDE ↓ #### Sensitive Column Encryption ↓ #### Central KMS / HSM ↓ #### Encrypted Backup ↓ #### Immutable Backup Storage Burada tek bir encryption katmanına güvenilmez. ### Defense in Depth Encryption Modeli Örneğin: Laptop çalındı → Disk Encryption Network dinlendi → TLS Database file çalındı → TDE Sensitive column açıldı → Column Encryption Backup çalındı → Backup Encryption Key erişilmeye çalışıldı → KMS/HSM + Audit Bu yaklaşım farklı saldırı yollarını ayrı ayrı sınırlar. ### Database Encryption'da En Sık Yapılan Hatalar Kurumlarda sık görülen hatalar şunlardır: - Sadece disk encryption kullanıp database'i tamamen güvenli sanmak - TDE'nin DBA'dan veriyi gizlediğini düşünmek - Database bağlantılarında TLS kullanmamak - Certificate validation yapmamak - Eski TLS protokollerini açık bırakmak - Encryption key'i database sunucusunda düz dosyada saklamak - Key'i source code'a koymak - Key rotation yapmamak - Key backup ve recovery planı oluşturmamak - Backup'ları şifresiz tutmak - Production encrypted iken export dosyalarını plaintext bırakmak - Cloud snapshot encryption'ını kontrol etmemek - KMS loglarını izlememek - Key administrator ile DBA rollerini gereksiz yere birleştirmek - Restore testinde encryption key recovery'yi test etmemek ### Database Encryption Checklist Kurumsal kontrol listesi şu başlıkları içerebilir: - Data classification tamamlandı mı? - Kritik database'lerde at-rest encryption var mı? - TDE aktif mi? - TLS zorunlu mu? - Eski protokoller kapalı mı? - Certificate validation yapılıyor mu? - Sensitive kolonlar ayrıca korunuyor mu? - Backup şifreli mi? - Snapshot şifreli mi? - Export dosyaları korunuyor mu? - Replication trafiği şifreli mi? - KMS/HSM kullanılıyor mu? - Key access sınırlandırılmış mı? - Key rotation politikası var mı? - Key backup var mı? - Key recovery test edildi mi? - KMS olayları audit ediliyor mu? - DR ortamında key erişimi test edildi mi? ### Database Encryption İçin Yönetimin Sorması Gereken Sorular Yönetim veya BT yöneticileri şu sorulara cevap alabilmelidir: Kritik database'lerimizin kaçı şifreli? Backup'larımız şifreli mi? Database trafiğinin tamamı TLS üzerinden mi? Encryption key'ler nerede tutuluyor? Kimler encryption key'lere erişebilir? DBA hem database hem key üzerinde tam yetkili mi? KMS erişimi loglanıyor mu? Key kaybolursa database'i geri getirebilir miyiz? Son encrypted restore testi ne zaman yapıldı? Bu sorular database encryption maturity seviyesini gösterir. ### Sık Sorulan Sorular #### Database encryption nedir? Veritabanındaki verilerin kriptografik yöntemlerle yetkisiz erişime karşı korunmasıdır. #### Encryption at Rest nedir? Disk veya storage üzerinde duran database verisinin şifrelenmesidir. #### Encryption in Transit nedir? Client ile database arasında hareket eden verinin TLS gibi yöntemlerle şifrelenmesidir. #### TDE nedir? Database data file'larının transparent şekilde şifrelenmesini sağlayan mekanizmadır. #### TDE açılırsa DBA veriyi göremez mi? Hayır. Yetkili DBA normal database sorgularıyla plaintext veriyi okuyabilir. #### Column-Level Encryption nedir? Belirli hassas database kolonlarının ayrıca şifrelenmesidir. #### Database backup şifrelenmeli mi? Evet. Backup production verisinin tam kopyasını içerebilir. #### Encryption key nerede tutulmalı? Mümkün olduğunca ayrı ve güvenli KMS, HSM veya key vault altyapısında yönetilmelidir. #### Key rotation nedir? Encryption key'in kontrollü şekilde yenilenmesidir. #### Encryption SQL Injection'ı engeller mi? Hayır. SQL Injection uygulama ve yetkilendirme güvenliğiyle ilgilidir. Encryption saldırının bazı veri erişim yollarını sınırlandırabilir ancak SQL Injection'ı ortadan kaldırmaz. ### Sonuç: Şifreli Database Her Zaman Güvenli Database Değildir Database encryption modern veri güvenliğinin temel katmanlarından biridir. Ancak encryption konusunda yapılan en büyük hata: **“Database şifreli, artık güvendeyiz.”** yaklaşımıdır. Gerçekte farklı encryption kontrolleri farklı riskleri azaltır. #### Encryption at Rest disk üzerindeki veriyi korur. #### TLS network üzerindeki veriyi korur. #### TDE database file'larını korur. #### Column-Level Encryption kritik veri alanlarına ek koruma sağlar. #### Backup Encryption recovery kopyalarını korur. #### KMS ve HSM ise encryption key'lerin güvenli yönetimini sağlar. Ancak yetkili kullanıcı database'e bağlandığında veriyi normal şekilde okuyabiliyorsa encryption tek başına insider threat veya credential compromise sorununu çözmez. Bu nedenle güçlü database encryption mimarisi şu kontrollerle birlikte kullanılmalıdır: #### RBAC #### Least Privilege #### PAM #### Audit #### DAM #### SIEM #### Backup Security #### Key Management En önemli prensiplerden biri şudur: **Encryption key, şifrelediği veriden en az veri kadar kritik bir varlıktır.** Çünkü key kaybedilirse kurum kendi verisine erişemeyebilir. Key ele geçirilirse saldırgan şifreli veriyi okuyabilir. Bu nedenle kurumsal database encryption stratejisi yalnızca: **“Veri şifreli mi?”** sorusunu değil; **“Hangi veri şifreli, hangi anahtarla şifreli, bu anahtarı kim yönetiyor, kim erişebiliyor ve anahtar kaybolursa ne yapacağız?”** sorularını cevaplayabilmelidir. Gerçek database encryption güvenliği: **Data Protection + Key Protection + Access Control + Audit** birlikte tasarlandığında ortaya çıkar.