Env Dosyalarının Ötesinde VPS Üzerinde Gizli Bilgi Yönetimi

Env dosyalarının sınırları: Sorun nerede başlıyor?

Modern web uygulamalarında veritabanı parolaları, API anahtarları, OAuth client secret’ları, ödeme altyapısı anahtarları ve benzeri tüm gizli bilgiler genellikle .env dosyalarında saklanıyor. Bu yaklaşım küçük projelerde hızlı ve pratik görünse de, ölçek büyüdükçe ciddi risklere ve operasyonel karmaşıklığa yol açmaya başlıyor. Özellikle DCHost üzerinde birden fazla VPS, staging/canlı ortam ayrımı ve CI/CD kullanan ekiplerde, .env dosyası tek başına sürdürülebilir olmaktan çıkıyor.

Güvenlik denetimi, KVKK/GDPR uyumluluğu ya da basit bir mimari tasarım toplantısında şu sorular kaçınılmaz hale geliyor:

• Gizli bilgileri kim, ne zaman, nasıl değiştirdi?
• Bir anahtarı döndürmem (rotate) gerekirse kaç sunucuya, kaç dosyaya dokunmam lazım?
• Git deposuna yanlışlıkla commit edilen bir .env dosyasını gerçekten “geri almış” sayılabilir miyim?
• Staging ortamındaki secret’ların canlı ortamla karışmadığından ne kadar eminim?

Bu yazıda, VPS üzerinde gizli bilgi yönetimini .env dosyalarının ötesine taşımanın pratik yollarını konuşacağız. Özellikle üç yaklaşımı mercek altına alacağız:

• VPS üzerinde kendi yönettiğiniz HashiCorp Vault
• Genel bulut sağlayıcıların sunduğu parameter store ve SSM benzeri yönetilen secret servisleri
• .env dünyasından bu yapılara geçişte mimari, güvenlik ve operasyon stratejileri

DCHost ekibi olarak, hem küçük SaaS projelerinde tek VPS’te, hem de çok VPS’li mimarilerde farklı secret yönetimi yaklaşımlarını sahada deniyoruz. Bu yazı da o gerçek deneyimlerin süzülmüş, pratik bir özeti gibi düşünebilirsiniz.

.env dosyasının ötesine geçmek neden zorunlu hale geliyor?

.env dosyalarını tamamen çöpe atın demiyoruz; ama sınırlarını çok net bilmek gerekiyor. Zaten blogumuzda VPS’te .env ve gizli anahtar yönetimi üzerine detaylı bir rehber yayınlamıştık. Oradaki iyi uygulamaları bile uygulasanız, belli bir noktada aşağıdaki sorunlarla yüzleşiyorsunuz:

1. Sızıntı yüzeyinin çok geniş olması

.env dosyası şu kanallardan sızabilir:

• Git deposuna yanlışlıkla commit edilmesi
• Sunucu yedeği şifrelenmeden saklanıyorsa yedek dosyalarından
• Paylaşımlı erişim (SFTP/SSH) verilen kişilerin dosyayı kopyalamasından
• Yanlış dosya izinleri (örneğin 644) nedeniyle başka kullanıcılar tarafından okunabilmesinden

.env’yi korumak için alınacak önlemler sınırlı ve çoğu manuel disipline dayanıyor. İnsan hatasını sıfırlamak ise imkânsıza yakın.

2. Ortamlar arası tutarlılık sorunu

Geliştirme, test, staging ve canlı ortamları olan projelerde .env dosyalarını kopyala-yapıştır ile yönetmek hem riskli hem de izlenemez bir süreç. Özellikle Laravel ve Node.js için staging ortamı kurarken .env yönetimi başlı başına bir problem haline geliyor.

Basit bir API anahtarını staging’den canlıya taşırken bile:

• Doğru dosyayı mı düzenledim?
• Eski değer gerçekten silindi mi?
• Rollback gerektiğinde eski değerlere nasıl döneceğim?

sorularıyla uğraşıyorsunuz.

3. Rotasyon (anahtar döndürme) ve denetim izi eksikliği

Bir veritabanı parolasını döndürmek istiyorsunuz diyelim. .env ile bu süreç genelde şöyle ilerler:

1. Veritabanında yeni parolayı tanımlarsınız.
2. Tüm VPS’lerde ilgili .env dosyalarını güncellersiniz.
3. Uygulamaları yeniden başlatırsınız.
4. Bir yerde eski parola kalmışsa gece yarısı sürpriz hata alırsınız.

Dahası, kim ne zaman değiştirdi, öncesinde hangi değer vardı, kaç kez denendi gibi sorulara yanıt vermek mümkün değildir. Güvenlik denetimlerinde bu ciddi bir eksi olarak karşınıza çıkar.

VPS üzerinde gizli bilgi yönetimi için temel yaklaşımlar

.env dosyalarını tamamen terk etmeden, ama merkezi bir gizli bilgi yönetimi katmanı ekleyerek ilerlemek en pragmatik yol. Sahada en çok kullandığımız yaklaşımları şöyle özetleyebiliriz:

• .env + şifreli secrets dosyaları (örn. sops + age ile GitOps akışı)
• Uygulama başlatma aşamasında secrets çekme (systemd unit, entrypoint script vb.)
• Merkezi secret manager (HashiCorp Vault, parameter store/SSM benzeri servisler)

sops + age yaklaşımını blogda ayrıntılı anlattık: VPS’te secrets yönetimi, sops + age, GitOps akışı ve rotasyon yazısı bu makalenin çok iyi bir tamamlayıcısı. Bu yazıda ise daha çok çalışma anında (runtime) secrets servisinden okuma yapan, yani gerçek anlamda secret manager diyebileceğimiz yapılara odaklanacağız.

HashiCorp Vault: VPS üzerinde kendi secret manager’ınızı barındırmak

HashiCorp Vault, gizli bilgileri güvenli şekilde saklamak, erişimi yetkilendirmek ve denetlemek için tasarlanmış güçlü bir araç. Kendi DCHost VPS’iniz üzerinde Vault kurarak tam kontrolü elinizde tutabilir, dış bağımlılıkları minimize edebilirsiniz.

Vault’un temel bileşenleri

Kısaca şu kavramları bilmek yeterli:

• KV Secrets Engine: Anahtar/değer çiftleri sakladığınız basit ama güçlü yapı. Örneğin database/prod altında DB kullanıcı adı ve parolasını tutabilirsiniz.
• Dynamic Secrets: Vault’un hedef sistemde (MySQL, PostgreSQL vb.) anlık kullanıcı açıp kısa süreli kimlik bilgisi üretmesi. Böylece veritabanında uzun ömürlü parolalar yerine zaman kısıtlı kullanıcılar kullanırsınız.
• Transit Engine: Uygulamanın veriyi Vault’a gönderip şifrelenmiş halde geri aldığı, anahtar yönetimini Vault’a bıraktığınız senaryo. Özellikle kart verisi, kritik kişisel veriler için ideal.
• Auth Methods: Hangi istemcinin hangi policy ile bağlanacağını tanımlayan kimlik doğrulama mekanizmaları (token, AppRole, JWT, Kubernetes vb.).

Tek VPS senaryolarında Vault mimarisi

Küçük ve orta ölçekli projelerde, özellikle DCHost üzerinde tek VPS kullanan ekiplerde şu mimariyi öneriyoruz:

• Aynı VPS üzerinde Vault + uygulama (PHP/Laravel, Node.js, vb.)
• Vault’u file storage veya ihtiyaca göre daha güvenli bir backend (Consul, PostgreSQL vb.) ile çalıştırmak
• Uygulamanın Vault ile localhost üzerinden TLS ile konuşması
• Erişim için AppRole ya da statik token + IP kısıtlaması gibi basit ama kontrollü bir yöntem

Tek VPS’te bile Vault’un en büyük kazancı, tek bir merkezi yerden secret yönetimi ve detaylı denetim izi sunması. Yarın aynı uygulamayı ikinci bir DCHost VPS’e yaymak istediğinizde de aynı Vault’u kullanmaya devam edebilirsiniz.

Örnek: Vault kurulumu ve basit KV engine yapılandırması

Detaylı kurulum adımlarını burada baştan sona anlatmayalım; ancak mantığı somutlaştırmak için basit bir akış paylaşalım. Varsayalım ki Linux tabanlı bir DCHost VPS’iniz var:

1. Vault paketlerini kurun ve systemd servisi olarak başlatın.
2. İlk kez vault operator init komutu ile cluster’ı başlatın, oluşan unseal key’leri güvenli bir yerde saklayın.
3. vault login ile root token kullanarak panele giriş yapın.
4. KV motorunu etkinleştirin:
   vault secrets enable -path=secret kv-v2
5. İlk secret’ı yazın:
   vault kv put secret/app/database username=app_user password=super-secret-pass
6. Uygulama için sınırlı erişimli bir policy tanımlayın:

path "secret/data/app/database" {
  capabilities = ["read"]
}

Ardından bu policy’yi kullanacak bir AppRole ya da token oluşturup sadece uygulamanın erişebildiği şekilde sunucuya yerleştirirsiniz. Böylece veritabanı parolası hiçbir zaman .env’de düz metin olarak durmak zorunda kalmaz.

Uygulamanın Vault’tan secret okuması

İki yaygın yaklaşım var:

• Uygulama başlarken env’e enjekte etmek: systemd unit içinde, uygulama başlamadan önce küçük bir script ile Vault’tan secret’ları çekip Environment= satırları ya da geçici bir env dosyası oluşturmak.
• Uygulama içinden doğrudan Vault API’ine konuşmak: Laravel, Node.js vb. içinde HTTP istemcisi ile Vault’a bağlanıp config cache’i doldurmak.

İlk yöntem daha az kod değişikliği gerektirir; mevcut config('database.password') çağrıları aynı kalır, sadece değer kaynağı değişmiş olur. İkinci yöntem daha esnektir; dinamik secret kullanımı veya anahtar rotasyonunu uygulama içinden daha akıllı yönetebilirsiniz.

Parameter store ve SSM benzeri servisler: Yönetilen secret altyapısı

Bazı genel bulut sağlayıcılar, uygulama yapılandırmasını ve gizli bilgileri saklamak için parameter store ve uzak yönetim/SSM benzeri servisler sunuyor. Bu servisler tipik olarak:

• Şifreli parametre saklama (örn. veritabanı parolası, API anahtarları)
• Versiyonlama ve önceki değerlere dönebilme
• RBAC ve detaylı erişim kontrolü
• Denetim logları (kim, neyi, ne zaman okudu/değiştirdi?)
• Sunuculara agent ile bağlanıp komut çalıştırma ve dosya dağıtımı (SSM benzeri)

Buradaki güzel nokta şu: VPS’iniz DCHost üzerinde olsa bile, bu tarz yönetilen servislerle HTTPS üzerinden konuşabilirsiniz. Yani compute kaynağınızı DCHost VPS olarak seçip, secret yönetimini ve uzaktan yönetimi dış bir servise emanet edebilirsiniz.

VPS ile parameter store entegrasyonu

Basit bir senaryoda şu akış çalışabilir:

1. Dış parameter store servisinde /prod/app/database/password gibi bir parametre tanımlarsınız.
2. DCHost VPS’inizde uygulamanın başlatma script’ine aşağıdaki mantığı ekleriniz:

• Kimlik doğrulama için gerekli erişim anahtarı/rol bilgisi (mümkünse kısa ömürlü token) hazır bulunsun.
• Uygulama başlamadan önce CLI veya HTTP API ile ilgili parametreleri çekin.
• Çekilen değerleri ya environment değişkenlerine ya da uygulamanın okuyacağı konfigürasyon dosyasına yazın.

Bu entegrasyonu CI/CD hattına da bağlayabilirsiniz. Örneğin GitHub Actions ile VPS’e otomatik deploy hattınızda, deployment öncesi adımda parameter store’dan en güncel secret’ı çekip sunucudaki config’i güncellemek mümkün.

SSM benzeri agent tabanlı yaklaşımlar

SSM tarzı servisler, sunuculara bir agent kurarak merkezi komut yürütme, konfigürasyon yönetimi ve bazen de secret dağıtımı sağlayabiliyor. DCHost VPS üzerinde de bu agent’ları çalıştırarak:

• Belirli periyotlarda ya da tetikleyicilerle konfigürasyon çekme
• Secret’ları otomatik olarak belirli dosyalara veya env değişkenlerine yazma
• Toplu komut çalıştırma (örneğin tüm uygulama sunucularını yeniden başlatma)

gibi senaryoları hayata geçirebilirsiniz. Burada dikkat edilmesi gereken nokta, agent’ın sahip olduğu yetkilerin doğru sınırlandırılması ve VPS üzerinde en az yetkiyle çalıştırılmasıdır. Agent’ın compromise olması durumunda, bağlı olduğu rol/kimlik üzerinden neleri yapabileceğini iyi tasarlamak gerekir.

Vault vs yönetilen parameter store: Hangisi sizin için doğru?

Karar verirken aşağıdaki soruları sormak çok işe yarıyor:

1. Tam kontrol mü, operasyonel konfor mu?

• Vault (self-hosted): Tüm kontrol sizde. Yedekleme, güncelleme, ölçeklendirme, TLS sertifikaları, erişim logları… Hepsi sizin sorumluluğunuzda. Özellikle regülasyon veya veri egemenliği gereksinimleri varsa büyük avantaj.
• Yönetilen parameter store / SSM benzeri servisler: Altyapı yönetimiyle uğraşmazsınız. Yedekleme, ölçeklendirme, yüksek erişilebilirlik servis sağlayıcıya aittir. Siz sadece entegrasyona odaklanırsınız.

2. Bağımlılık seviyesi ve taşınabilirlik

• Vault, DCHost üzerindeki VPS’ten kendi veri merkezinize, oradan başka sağlayıcılara taşınırken mimarinizin taşınabilirliğini artırır.
• Belirli bir parameter store/SSM implementasyonuna kilitlenmek, ileride sağlayıcı değişimlerinde ekstra iş yükü yaratabilir. Abstraction katmanı (örneğin kendi küçük secret servisiniz) yazmanız bu riski azaltır.

3. Ekip yetkinliği ve operasyonel kapasite

• Vault kurmak ve doğru yönetmek belirli bir DevOps yetkinliği gerektirir. Küçük ekiplerde bu yük bazen ağır gelebilir.
• Yönetilen secret servisleri entegrasyonu genelde daha basittir; birkaç CLI komutu ve SDK çağrısı ile işe başlayabilirsiniz.

4. Performans ve gecikme

• Vault’u DCHost üzerindeki VPS’inize yakın konumda koşturduğunuzda, secret okuma gecikmesi çok düşüktür (localhost ya da aynı ağ).
• Dış bir parameter store kullanıyorsanız, her secret okuma isteği ek bir ağ sıçraması demektir. Bu yüzden çalışma anında sık secret okuma yapacaksanız caching stratejisi şarttır.

DCHost üzerinde pratik bir mimari: Küçük SaaS örneği

Somutlaştıralım. Diyelim ki DCHost üzerinde:

• 1 adet uygulama VPS’i (Laravel veya Node.js API)
• 1 adet veritabanı VPS’i (PostgreSQL/MariaDB)

kullanan küçük bir SaaS projeniz var. Gizli bilgileriniz neler?

• Canlı veritabanı kullanıcı adı/parolası
• Ödeme servisleri için secret key’ler
• 3. parti e-posta sağlayıcısının API anahtarı
• Uygulama içi şifreleme anahtarları (örneğin Laravel APP_KEY)

Bu senaryoda aşağıdaki adımlar sağlıklı bir yol haritası sunar:

1. DCHost üzerindeki uygulama VPS’ine Vault kurun ve sadece KV engine ile başlayın.
2. Tüm secret’larınızı secret/prod/... path’leri altında toplayın.
3. Uygulama için sadece ilgili path’lere read yetkisi olan bir policy oluşturun.
4. systemd unit dosyanıza küçük bir pre-start script’i ekleyin; bu script Vault’tan secret’ları çekip Environment= satırları ile prosese aktaracak bir dosya üretsin.
5. CI/CD hattınızda (örneğin GitHub Actions ile VPS’e otomatik deploy senaryosunda), deployment sonrası sadece systemctl restart app.service komutu ile yeni secret’ların devreye alınmasını sağlayın.

Bir adım ileri gidip, yalnızca .env dünyasından çıkmak değil, şifreleme anahtarlarınızı da profesyonelce yönetmek istiyorsanız, Vault’un transit engine’i ile blogumuzdaki yedek şifreleme ve anahtar yönetimi rehberinde anlattığımız prensipleri birleştirmek çok güçlü bir çözüm sunar.

Operasyonel en iyi uygulamalar: Rotasyon, loglama ve yedek

Secret manager kullanıyor olmak tek başına sihirli değnek değil; onu nasıl yönettiğiniz asıl farkı yaratıyor.

Anahtar rotasyonunu süreç haline getirin

Veritabanı parolası veya API anahtarları “sızdığı için” değil, politika gereği belirli aralıklarla döndürülmeli. Öneriler:

• Her kritik secret için rotasyon periyodu tanımlayın (örneğin 90 gün).
• Rotasyon tarihlerini CI/CD veya izleme sisteminize hatırlatma olarak ekleyin.
• Dynamic secret kullanabiliyorsanız (Vault + veritabanı gibi), manuel rotasyon yükünüz ciddi biçimde azalır.

Loglama ve denetim izi

Kim, hangi secret’a, ne zaman erişti? Bu soruya yanıt veremiyorsanız, olası bir güvenlik olayı sonrası yapabilecekleriniz sınırlı kalır. Vault veya yönetilen parameter store tarafında:

• Erişim loglarını mutlaka merkezi bir yere (örneğin VPS log mimarinizde Loki/ELK) gönderin.
• Şüpheli desenler (beklenmeyen IP’lerden gelen istekler, kısa sürede çok sayıda okuma vb.) için alarm kurun.
• Secret okuma isteği başarısız olduğunda uygulamanın loglarına da anlamlı kayıt düşmesini sağlayın.

Yedekleme ve felaket senaryoları

Secret manager veri kaybı, tüm mimarinizin erişilemez hale gelmesi anlamına gelir. Bu yüzden:

• Vault backend’inizi (file, Consul, veritabanı) düzenli olarak yedekleyin.
• Yedeklerin şifreli ve erişim kontrolü yapılmış bir depoda saklandığından emin olun.
• Yedekten geri dönüş prova’larını, genel felaket kurtarma planınızla entegre edin. Bu konuda blogdaki felaket kurtarma planı yazısı uygulamaya dönük net adımlar içeriyor.

.env’den profesyonel secret yönetimine geçiş için yol haritası

Her projede “bir günde Vault’a geçelim” gerçekçi olmayabilir. DCHost tarafında müşterilerimizle izlediğimiz tipik yol haritası şöyle:

1. Mevcut durum envanteri: Tüm gizli bilgilerinizi (parolalar, anahtarlar, token’lar) en azından bir envanter dökümanında toplayın. Nerede saklandıkları, kimlerin erişimi olduğu net olsun.
2. .env hijyeni: Mevcut .env’leriniz için dosya izinlerini, yedekleme stratejisini, Git dışlama kurallarını iyileştirin. İlk adım olarak mutlaka VPS’te .env ve gizli anahtar yönetimi rehberindeki kontrolleri uygulayın.
3. Küçük bir pilot: Tüm secret’lar yerine önce tek bir kritik parçayı (örneğin veritabanı parolası) Vault veya parameter store’a taşıyın. Uygulamanın o secret’ı yeni kaynaktan okumasını sağlayın.
4. CI/CD entegrasyonu: Dağıtım hattınızda secret güncellemeleriyle uyumlu bir akış kurun. Gerekirse sops + age + GitOps yaklaşımıyla configuration as code tarafını da güçlendirin.
5. Tam geçiş ve dokümantasyon: Tüm secret’larınızı yönetilen bir yapıya aldıktan sonra, bu yapının nasıl çalıştığını ve kimlerin hangi süreçte ne yapacağını mutlaka yazılı hale getirin.

Sonuç: DCHost üzerinde secret yönetimini bir seviye yukarı taşıyın

Özetleyelim: .env dosyaları, tek VPS’li basit projelerde iş görse de, ciddi iş yüklerinde hem güvenlik hem de operasyon tarafında tıkanma noktası haline geliyor. DCHost üzerinde barındırdığınız uygulamalarda:

• Kendi yönettiğiniz bir HashiCorp Vault ile tam kontrol sahibi olabilir,
• Genel bulutun sağladığı parameter store ve SSM benzeri servisleri kullanarak operasyonel yükü azaltabilir,
• Ya da bu ikisini hibrit şekilde kullanarak hem esneklik hem de güvenlik elde edebilirsiniz.

En kritik nokta, gizli bilgilerinizi rastgele dosyalarda değil, tasarlanmış bir mimaride saklıyor olmanız. Buradan sonra atacağınız her adım, hem güvenlik denetimlerinde hem de ekip içi huzurda kendini fazlasıyla geri ödeyecek.

Eğer DCHost üzerinde çalışan projeniz için hangi yaklaşımın daha uygun olduğuna karar veremiyorsanız, mevcut mimarinizi birlikte gözden geçirebiliriz. Altyapınız ister tek VPS, ister çok VPS’li ya da dedicated sunucu olsun; secret yönetimini sade, denetlenebilir ve otomasyona uygun hale getirmek mümkün. Bir sonraki bakım penceresinde sadece kodu değil, gizli bilgilerinizi yönettiğiniz altyapıyı da güncelleme listesine almanızı şiddetle öneriyoruz.