.env Dosyası Yönetimi: Gizli Bilgileri Güvenli Tutmak

Bir env dosyası, projenizin çalışması için gereken ama kod deposuna asla girmemesi gereken gizli bilgileri (API anahtarları, veritabanı şifreleri, token'lar) saklamanın en yaygın yoludur. Fikir basittir: yapılandırmayı koddan ayırırsınız. Aynı kod tabanı geliştirme makinesinde, test ortamında ve canlı sunucuda farklı değerlerle çalışır; tek değişen şey ortamdaki .env dosyasıdır. Bu yazıda .env dosyalarını güvenli yönetmenin pratik kurallarını, sık yapılan hataları ve sızıntı olduğunda ne yapılacağını anlatıyorum.

Neden .env dosyası kullanılır?

Gizli bilgileri doğrudan kaynak koduna yazmak (hardcode) en sık görülen güvenlik açıklarından biridir. Bir API anahtarını config.php içine gömüp Git'e gönderdiğinizde, o anahtar artık deponun tüm geçmişine işlenmiştir; sildiğinizde bile commit geçmişinde durur. .env dosyası bu sorunu, gizli verileri versiyon kontrolünün tamamen dışında tutarak çözer.

• Ayrım: Kod herkese açık olabilir, sırlar değil.
• Ortam başına değer: Lokal, staging ve production farklı veritabanlarına ve anahtarlara bağlanır.
• Kolay rotasyon: Bir anahtarı değiştirmek için tek bir satırı güncellemek yeter, kod dağıtımı gerekmez.

.env dosyasının yapısı

Biçim sade bir ANAHTAR=değer listesidir; her satır bir değişkendir. Çoğu kütüphane # ile başlayan yorum satırlarını destekler.

# Uygulama
APP_ENV=production
APP_DEBUG=false

# Veritabanı
DB_HOST=127.0.0.1
DB_DATABASE=portfolio
DB_USERNAME=app_user
DB_PASSWORD=cok-gizli-bir-sifre

# Üçüncü taraf servisler
STRIPE_SECRET=sk_live_xxx
MAIL_PASSWORD="bosluk iceren deger tirnak ister"

Birkaç pratik nokta: değer içinde boşluk veya özel karakter varsa çift tırnak kullanın; eşittir işaretinin etrafına gereksiz boşluk koymayın; ve değerler her zaman string olarak okunur. Yani APP_DEBUG=false aslında "false" metnidir, dilin false boolean'ı değil. Bunu kodda doğru tipe çevirmek sizin işiniz; örneğin Laravel'in env() yardımcısı true/false/null gibi değerleri otomatik dönüştürür, çıplak getenv() dönüştürmez.

En önemli kural: .env asla Git'e girmez

Bir .env dosyasını kazara commit'lemek, gizli bilgi sızıntılarının bir numaralı sebebidir. Bunu önlemenin yolu projenin köküne bir .gitignore satırı eklemektir:

# .gitignore
.env
.env.*
!.env.example

Buradaki !.env.example satırı, az sonra anlatacağım örnek dosyayı kara listeden muaf tutar. Eğer dosyayı daha önce yanlışlıkla commit ettiyseniz, sadece .gitignore eklemek yetmez; Git onu zaten izliyordur. İzlemeyi durdurmak için:

git rm --cached .env
git commit -m "stop tracking .env"

Unutmayın: bu komut dosyayı geçmişten silmez, sadece bundan sonraki commit'lerde takip etmeyi bırakır. Eğer sır gerçekten herkese açık bir geçmişe girdiyse, aşağıdaki sızıntı bölümüne bakın.

.env.example ile ekibi senkron tutmak

Gerçek .env repoya girmediğine göre, yeni bir geliştirici projeyi klonladığında hangi değişkenlerin gerektiğini nereden bilecek? Çözüm .env.example (bazen .env.sample) dosyasıdır: aynı anahtarları içerir ama değerler boş veya sahtedir. Bu dosya repoya girer ve bir tür belge görevi görür.

# .env.example
APP_ENV=local
APP_DEBUG=true
DB_HOST=127.0.0.1
DB_DATABASE=
DB_USERNAME=
DB_PASSWORD=
STRIPE_SECRET=

Kurulum adımı genelde basittir: cp .env.example .env ile dosyayı kopyalar, ardından gerçek değerleri doldurursunuz. Yeni bir değişken eklediğinizde örnek dosyayı da güncellemeyi alışkanlık hâline getirin; aksi halde takım arkadaşınızın kurulumu "neden çalışmıyor" diye saatlerce arayacağı eksik bir anahtarla bozulur.

Sunucularda ve CI/CD'de güvenli kullanım

Canlı sunucularda .env dosyasının dosya izinlerini kısıtlayın; yalnızca uygulamayı çalıştıran kullanıcı okuyabilmeli:

chmod 600 .env

Paylaşımlı hosting veya VPS ortamında dosyanın web kök dizininin (örneğin public/) dışında durduğundan emin olun; aksi halde yanlış bir sunucu yapılandırması onu düz metin olarak servis edebilir. CI/CD süreçlerinde (GitHub Actions, GitLab CI) ise .env dosyasını repoya koymak yerine, platformun secrets / environment variables özelliğini kullanın. Bu sırlar şifreli saklanır, loglarda maskelenir ve yalnızca pipeline çalışırken ortam değişkeni olarak enjekte edilir. Daha büyük kurulumlarda HashiCorp Vault, AWS Secrets Manager veya Doppler gibi özel sır yönetim araçları devreye girer.

• Sırları asla pipeline loglarına echo ile yazdırmayın.
• Production sırlarını geliştiricilerin lokal makinelerine dağıtmayın; ayrı, daha az yetkili anahtarlar kullanın.
• Anahtarları düzenli aralıklarla rotasyona sokun (rotate edin).

Sır sızdıysa ne yapmalı?

Diyelim ki bir API anahtarı yanlışlıkla herkese açık bir commit'e girdi. İlk ve en önemli adım, dosyayı geçmişten temizlemek değil — anahtarı hemen iptal edip yenisini üretmektir. Sızan bir sır, geçmişten silinse bile başkalarının kopyaladığı clone'larda ve önbelleklerde durabilir; tek güvenli varsayım onun artık geçersiz olması gerektiğidir.

Anahtarı rotasyona soktuktan sonra, geçmişi temizlemek için git filter-repo (Git'in önerdiği modern araç) veya BFG Repo-Cleaner kullanabilirsiniz. Ardından force-push gerekir ve tüm ekibin depoyu yeniden klonlaması gerekir. Gelecekte böyle kazaları önlemek için git-secrets veya gitleaks gibi araçları bir pre-commit kancası olarak ekleyebilirsiniz; bunlar commit anında sır kalıplarını yakalayıp sizi uyarır.

Sık Sorulan Sorular

.env dosyasını şifrelemeli miyim?

Lokal geliştirme için genelde gerekmez; dosya izinleri ve .gitignore yeterlidir. Ancak sırları repoda paylaşmanız gerekiyorsa Laravel'in yerleşik php artisan env:encrypt komutu veya git-crypt, sops gibi araçlar şifreli bir .env saklamanıza izin verir. Şifre çözme anahtarı yine güvenli bir yerde durmalıdır.

.env ile gerçek ortam değişkenleri arasındaki fark nedir?

.env dosyası bir kolaylıktır: işletim sisteminin ortam değişkenlerini bir dosyadan taklit eder. Production'da birçok platform değişkenleri doğrudan sistem seviyesinde (sunucu paneli, konteyner ortamı, secrets servisi) tanımlamayı tercih eder; bu durumda .env dosyasına hiç ihtiyaç kalmaz ve sızıntı riski daha da azalır.

Birden fazla ortam için ayrı dosyalar tutabilir miyim?

Evet, yaygın bir desendir: .env.local, .env.staging, .env.production gibi. Hangisinin yükleneceğini framework veya bir araç (örneğin Vite, Next.js, Laravel) ortama göre seçer. Yine de gerçek değer içeren tüm varyantları .gitignore'a eklemeyi unutmayın.

Sırlarınız güvende mi? Yapılandırma yönetimi, dağıtım veya bir projenin güvenli kurulumu için yardıma ihtiyacınız olursa benimle iletişime geçin — birlikte sağlam bir temel kuralım.