Durağan vs aktarım sırasında şifreleme: ikisi de önemli

Aktarım sırasındaki şifreleme, iki nokta arasında hareket eden verileri korur; örneğin tarayıcınız ile bir sunucu arasında, AES-256-GCM veya ChaCha20-Poly1305 ile TLS 1.3 kullanılarak. Durağan şifreleme ise diskte bekleyen verileri korur; genellikle tam disk şifrelemesi için AES-256-XTS veya her dosya başına AES-256-GCM. Bunlardan biri tek başına yeterli değildir. TLS ağ dinlemesine karşı koruma sağlar ancak sunucuda şifreyi çözer; durağan şifreleme ise saklanan verileri korur ama anahtarlar şifreli metnin yanında duruyorsa işe yaramaz. Gerçek güvenlik her ikisini katmanlamaktan, ideal olarak sunucunun düz metni hiç görmemesi için istemci tarafı (uçtan uca) şifrelemeyle birlikte gelir.

İki farklı tehdit, iki farklı kontrol

Tehditler, verilerinizin nerede durduğuna göre farklı görünür:

Aktarım sırasında (ağ yolu): kafedeki bir paket koklayıcı çalıştıran saldırgan, güvenliği ele geçirilmiş ISS yönlendiricisi, denizaltı kablolarını dinleyen ulus devlet. 2013 Snowden belgeleri, NSA'nın MUSCULAR programının Google'ın iç fiber bağlantılarını izlediğini ortaya koydu. Savunma: TLS 1.3; tercihen uygulamalar için sertifika sabitleme.

Durağan halde (depolama): çalınan dizüstü bilgisayar, sızdırılan yedekleme bandı, yanlış yapılandırılmış S3 kovası, disk erişimi olan hileli veri merkezi çalışanı. 2017 Equifax ihlali, veriler şifrelenmemiş halde durduğundan kısmen 147 milyon kaydı açığa çıkardı. Savunma: diskler için LUKS, BitLocker, FileVault; dosya veya blok başına AES-256-GCM veya AES-256-XTS.

Yapılan hata, birini diğerinin yerine geçen bir çözüm gibi ele almaktır. TLS, veritabanı dökümünü korumaz. Disk şifrelemesi, ortadaki adam saldırısını durdurmaz.

TLS 1.3 aktarım sırasındaki verileri nasıl korur

RFC 8446 (2018) ile standartlaştırılan TLS 1.3 modern varsayılandır. Şunları kullanır:

• Geçici ECDHE anahtar değişimi aracılığıyla varsayılan olarak ileriye dönük gizlilik. Sunucunun uzun vadeli anahtarı sızsa bile geçmiş oturumlar korunur.
• Yalnızca AEAD şifreleri — AES-128-GCM, AES-256-GCM veya ChaCha20-Poly1305. Eski CBC modları ve RC4 gitti.
• Tek gidiş-dönüş el sıkışması (1-RTT) veya sürdürme için sıfır gidiş-dönüş (0-RTT).
• Şifreli el sıkışma böylece pasif gözlemciler sertifika zincirini göremez.

WeTransfer, SwissTransfer, Tresorit, Proton Drive ve HexaTransfer dahil her saygın dosya aktarım hizmeti, HTTPS'yi en az 12 ay zorunlu kılan HSTS başlıklarıyla TLS 1.3 çalıştırır. SSL Labs'ın testssl aracıyla doğrulayabilirsiniz; A-'nın altında puan alan her hizmet yapılandırma sorunları taşır.

Sunucuda durağan şifreleme nasıl çalışır

Dosyalar ulaşıp TLS sonlandıktan sonra durağan şifreleme devreye girer. Birkaç katman vardır:

• Blok düzeyinde (tam disk): LUKS (Linux), BitLocker (Windows), FileVault (macOS) veya AWS EBS şifrelemesi gibi bulut sağlayıcısı eşdeğerleri üzerinde AES-256-XTS. Çalınan disklere karşı koruma sağlar.
• Dosya sistemi düzeyinde: eCryptfs, ext4/F2FS üzerinde Fscrypt. Her kullanıcının dosyaları ayrı anahtarlarla şifrelenir.
• Nesne depolama düzeyinde: AWS S3 SSE-KMS, müşteri yönetimli anahtarlarla Azure Blob, Google Cloud Storage. Her nesne AES-256-GCM ile şifrelenir.
• Uygulama düzeyinde: hizmet, depolama sistemine yazmadan önce kendi kodunda her dosyayı şifreler; anahtarlar KMS veya HSM'de tutulur.

Uygulama düzeyi en güçlüdür; çünkü şifreleme, herhangi bir depolama sisteminin veriyi görmesinden önce gerçekleşir. AWS KMS, anahtar başına ayda 1 dolar artı her 10.000 istek için 0,03 dolar ücretlendirir; ciddi hizmetlerin dosya başına kullanması için yeterince ucuzdur.

"Anahtarlar şifreli metnin yanında" tuzağı

Durağan şifrelemenin sıklıkla başarısız olduğu yer burasıdır. Anahtarlar şifreli metinle aynı sunucuda depolanırsa sunucuyu ele geçiren saldırgan her ikisini de alır. Sağlayıcı uyumluluk amacıyla "beklemedeyken şifreli" kutusunu teknik olarak işaretleyebilir; ancak sunucu ihlallerine karşı gerçek koruma sıfırdır.

İyi mimariler kaygıları ayırır:

• S3 veya benzeri nesne depolamada şifreli metin.
• AWS KMS, Google Cloud KMS, Azure Key Vault veya özel HSM'de şifreleme anahtarları.
• Kısa ömürlü IAM kimlik bilgileri ve denetim günlükleriyle anahtarlara erişim denetimi.

Harika mimariler daha ileri gider: anahtarlar sunucuda hiç bulunmaz. İstemci tarafı şifreleme (E2EE), kullanıcının tarayıcısının anahtarı oluşturması, dosyayı şifrelemesi ve anahtarı elinde tutması anlamına gelir. Sunucu şifreli metni saklar ve sızdıracak hiçbir şeyi yoktur.

Şifreleme boşluklarının ortaya çıktığı yerler

Her iki kontrol de yerinde olsa bile veriler birkaç yerde kısa süreliğine düz metin olur:

• Sunucu belleğinde, yükleme işleme, virüs tarama veya küçük resim oluşturma sırasında. Bu pencerede alınan bellek dökümü düz metni ortaya koyar.
• Erişim günlüklerinde, dosya adları veya içerik parçaları hata ayıklama için günlüğe kaydedilirse.
• Yedekleme bantlarında, yedeklemeler aynı şifrelemeyi devralmıyorsa.
• Sıkıştırma veya dönüştürme sırasında, hizmetin dosya içeriklerini işlediği durumlarda.
• Tarayıcı önbelleğinde, kullanıcı indirmeden sonra temizleme yapmıyorsa.

Bu boşluklar, sıfır bilgi (istemci tarafı) şifrelemenin önemli olmasının nedenidir. Dosyalar yüklemeden önce tarayıcıda şifrelendiğinde sunucu tarafı boşluklar önemsiz hale gelir; sunucu her zaman yalnızca şifreli metin görür.

Büyük hizmetlerin gerçekte yaptıkları

Kamuya açık belgelere dayalı kaba bir sınıflandırma:

• Google Drive, Dropbox, OneDrive: aktarımda TLS 1.3, beklemedeyken sağlayıcının elinde tuttuğu anahtarlarla AES-256. Sıfır bilgi değil; sağlayıcı dosyalarınızı okuyabilir.
• WeTransfer (ücretsiz katman): TLS 1.3, AWS S3'te beklemedeyken AES-256. Sağlayıcı anahtarları elinde tutar.
• Box Enterprise: TLS 1.3, beklemedeyken AES-256-GCM, isteğe bağlı müşteri yönetimli anahtarlar (Box KeySafe).
• Tresorit, Proton Drive, SwissTransfer E2EE katmanı, HexaTransfer: aktarımda TLS 1.3, beklemedeyken AES-256-GCM; ancak dosya başına anahtarlar istemci tarafında oluşturulur ve sunucuya hiç ulaşmaz. Etkin olarak sıfır bilgi.

Hassas veriler için yalnızca son kategori, içeriden tehditler ve geçerli yasal taleplere karşı anlamlı koruma sağlar.

Uyumluluk ve "derinlemesine savunma" zorunluluğu

Düzenleyiciler her ikisini de açıkça gerektirir:

• GDPR Madde 32, verilerin hangi durumda olduğuna dair kısıtlama olmaksızın "kişisel verilerin anonimleştirilmesi ve şifrelenmesini" zorunlu kılar.
• HIPAA Güvenlik Kuralı 45 CFR § 164.312, hem aktarımda hem de beklemedeyken ePHI için şifreleme gerektirir.
• PCI DSS 4.0 Gereksinim 3 ve 4, "saklanan kart sahibi verilerini koruma" (beklemedeyken) ile "aktarım sırasında güçlü kriptografiyle kart sahibi verilerini koruma" (aktarımda) arasını ayırır.
• FIPS 140-3 doğrulaması, her iki bağlamda da kullanılan kriptografik modüller için geçerlidir.
• KVKK (Kişisel Verilerin Korunması Kanunu) Türkiye'de kişisel verilerin güvenliği için teknik ve idari tedbirlerin alınmasını zorunlu kılar.

Yalnızca birini sağlamak, güvenlik başarısızlığından önce uyumluluk başarısızlığıdır.

Her ikisinin de aktif olduğunu doğrulama

Herhangi bir dosya aktarım hizmeti için beş hızlı kontrol:

1. TLS 1.3'ü yalnızca güçlü şifrelerle doğrulamak için testssl.sh https://provider.com çalıştırın.
2. En az 31.536.000 (bir yıl) max-age değeriyle HSTS başlıklarını kontrol edin.
3. Güvenlik teknik belgesinde beklemedeyken AES-256-GCM veya AES-256-XTS'nin açık biçimde geçtiğini okuyun.
4. Anahtarların uygulama veritabanında değil, KMS veya HSM'de tutulduğunu onaylayın.
5. SOC 2 Tip II veya ISO 27001 sertifikasını arayın; ikisi de belgelenmiş durağan ve aktarımdaki kontrolleri gerektirir.

Ek: istemci tarafı şifrelemenin seçenek olarak sunulup sunulmadığını kontrol edin. Varsa, hassas her şey için etkinleştirin.

Bunları doğru biçimde katmanlamak

Gerçekte işe yarayan desen:

1. Tarayıcı, rastgele AES-256-GCM anahtarıyla dosyayı şifreler (istemci tarafı).
2. Şifreli metin TLS 1.3 üzerinden sunucuya iletilir (aktarımda).
3. Sunucu, şifreli metni AES-256 şifreli depolamada saklar (beklemedeyken).
4. Şifre çözme anahtarı yalnızca paylaşım URL'si parçasında bulunur; sunucuya hiçbir zaman gönderilmez.

Üç bağımsız katman. Birini kırın, diğerleri tutar. HexaTransfer'in Tresorit Send, Proton Drive paylaşım linkleri ve SwissTransfer'ın E2EE moduyla birlikte kullandığı tasarım budur.

hexatransfer.com'da deneyin — ücretsiz, hesap gerekmez, 10 GB'a kadar.