Hassas finansal veriyi şifrelerken anahtarı .env'de tutmak neden riskli — KMS/Vault ne sağlar?
Soru
Kullanıcıların DB'deki T.C. Kimlik No veya kredi kartı token'larını KVKK/GDPR gereği şifreli tutmalıyız; DB'yi ele geçiren saldırgan bu veriyi okuyamamalı. Uygulama katmanında simetrik şifreleme (AES-256) kullanırken şifreleme anahtarını uygulama sunucusunda bir `.env` dosyasında tutmanın riskleri neler? AWS KMS veya HashiCorp Vault entegrasyonu mimariyi nasıl güvenli kılar?
Cevap
Kısa cevap: Alanı AES-256 ile şifrelemek doğru, ama anahtar uygulamanın yanındaki .env’de duruyorsa sunucuya ulaşan saldırgan hem veriyi hem anahtarı alır — şifreleme size neredeyse hiçbir şey kazandırmaz. KMS/Vault’un olayı anahtarı veriden ayırmaktır.
Kısa cevap
Sorunun özü şu: şifreli veri ve onu açan anahtar aynı yerde duruyorsa, o ikisi pratikte tek bir sırdır. Güvenlik, anahtarı veriden fiziksel/yetkisel olarak koparmaktan gelir. Aynı “sır nerede duruyor” sorusu imza doğrulamada da karşınıza çıkar; webhook’larda HMAC ve idempotency tarafını ayrı bir kayıtta ele almıştım.
Neden
-
.env’deki anahtar tek noktada toplanmış risktir. Sunucuyu ele geçiren (ya da bir backup/.envsızıntısı yaşatan) saldırgan, şifreli DB ile anahtarı aynı anda eline geçirir. Ayrıca anahtar dosyada düz metin durur, rotasyonu zor ve kimin ne zaman çözdüğüne dair hiçbir iz yoktur. -
KMS/Vault master anahtarı uygulamaya hiç vermez. Böylece DB’yi ya da bir yedeği ele geçirmek düz metni teslim etmez — çünkü master anahtar hiç orada değildir. Ele geçirilmiş bir uygulama sunucusu, ele geçirme sürdüğü sürece KMS’ten çözme isteyebilir; erişimi sınırlamak ve audit logu bu yüzden gerekir.
-
“Hangi servis, ne zaman, hangi veriyi çözdü” sorusu cevaplanabilir hâle gelir. Uyumluluk (KVKK/GDPR) denetiminde asıl aranan budur;
.envmodelinde bu sorunun cevabı yoktur.
Ne yapmalı
-
Envelope encryption’a geçin. Uygulama şifreleme/çözme için KMS’i çağırsın: master anahtar KMS’te dursun, her kayıt için ayrı bir data key’i o şifrelesin. Uygulamanın sakladığı tek şey şifrelenmiş data key olur; düz metne ihtiyaç duyduğunda KMS’ten çözmesini ister.
-
Rotasyonu ve denetimi merkezîleştirin. KMS/Vault anahtarı merkezî olarak rotate eder, her çözme işlemini audit loguna yazar ve erişimi IAM/policy ile sınırlar; bu üçünü baştan açın.
-
T.C. kimlik/kart için tokenization’ı tercih edin. Mümkünse hassas değeri hiç tutmayın: gerçek değeri bir vault/sağlayıcıda saklayın, sistemde yalnızca bir token dolaşsın. Böylece sistemin büyük çoğunluğu hassas veriyi hiç görmez — sızsa bile ele geçen şey anlamsız bir token olur.
Sonuç: KMS ya da Vault ile envelope encryption; anahtar asla .env’de değil, rotate + audit edilen bir yerde. Mümkün olan her yerde tokenize edin. Ek not: full-disk şifreleme ya da tek başına pgcrypto yeterli değildir — canlı bir DB bağlantısı düz metni yine de okur. Asıl koruma, anahtarı veriden ayırmaktan ve uygulamaya master anahtarı hiç vermemekten gelir.
Yorumlar
Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.