# Hassas finansal veriyi şifrelerken anahtarı .env'de tutmak neden riskli — KMS/Vault ne sağlar?

> Anahtarı .env'den çıkarıp KMS ya da Vault'ta tutun ve envelope encryption kullanın; kimlik ve kart verisinde mümkünse tokenization tercih edin.

- Soruldu: 2026-06-09
- Yanıtlandı: 2026-06-12
- Soran: Çağrı
- Etiketler: veritabani, guvenlik, altyapi
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/hassas-finansal-veriyi-sifrelemek-ve-anahtar-yonetimi-kms/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**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?


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.

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.

1. **`.env`'deki anahtar tek noktada toplanmış risktir.** Sunucuyu ele geçiren (ya da bir backup/`.env` sı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.
2. **KMS/Vault ham anahtarı uygulamaya hiç vermez.** Uygulama şifreleme/çözme için KMS'i çağırır ya da **envelope encryption** kullanır: master anahtar KMS'te durur, her kayıt için ayrı bir data key'i o şifreler. Böylece DB'yi *hatta* uygulama sunucusunu ele geçirmek bile düz metni teslim etmez — çünkü master anahtar hiç orada değildir.
3. **Merkezi rotasyon, audit ve IAM erişimi kazanırsınız.** KMS/Vault anahtarı merkezî olarak **rotate** eder, her çözme işlemini **audit** loguna yazar ve erişimi IAM/policy ile sınırlar. "Hangi servis, ne zaman, hangi veriyi çözdü" sorusu artık cevaplanabilir; uyumluluk (KVKK/GDPR) denetiminde bu kritik.
4. **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 ham anahtarı hiç vermemekten gelir.

## İlgili Yazılar

- [CI/CD'de OIDC ve IAM Role ile şifresiz (secretless) AWS erişimini nasıl kurarım?](https://www.muhammetsafak.com.tr/sor-bakalim/ci-cd-de-secret-yonetimi-ve-oidc-ile-sifresiz-erisim/) — Sor Bakalım
- [Felaket kurtarma: RTO ve RPO'ya göre aktif-pasif senaryoyu nasıl kurgularım?](https://www.muhammetsafak.com.tr/sor-bakalim/felaket-kurtarma-rto-rpo-ve-aktif-pasif-senaryo/) — Sor Bakalım
- [Container'ı non-root çalıştırınca mount edilen storage dizinine yazamıyorum, izinleri nasıl çözerim?](https://www.muhammetsafak.com.tr/sor-bakalim/containeri-non-root-calistirinca-mount-edilen-storage-dizinine-yazamiyorum-izinleri-nasil/) — Sor Bakalım