Uygulamanızın veritabanı şifresine, ödeme sağlayıcısı anahtarına ve e-posta gönderim bilgilerine ihtiyacı var. Bunlar bir yerde durmak zorunda — peki nerede?
Yanlış cevap yaygındır: kod içinde. Bu yazı, VDS sunucu üzerinde hassas bilgileri güvenli tutmanın pratik yollarını anlatıyor.
Yaygın Yanlışlar
| Yöntem | Sorun |
|---|---|
| Kod içine yazmak | Sürüm kontrolüne girer, geçmişte kalır |
| Web kök dizininde tutmak | Yapılandırma hatasında dışarıdan okunabilir |
| Herkese okunabilir izinle bırakmak | Sunucudaki diğer kullanıcılar erişir |
| Yedeklerde şifresiz saklamak | Yedek sızarsa her şey sızar |
| Ekip içinde mesajla paylaşmak | Geçmişte kalır, takip edilemez |
İlk satır en kalıcı hasarı üretir: bir şifre bir kez sürüm kontrolüne girdiyse, silseniz bile geçmişte kalır ve okunabilir. Dosyayı düzeltmek yetmez — o anahtarları değiştirmeniz gerekir.
Katmanlı Yaklaşım
Sır yönetiminde tek bir doğru yöntem yoktur; ölçeğinize göre kademeli bir yol izlenir.
Seviye 1: Dosya, Web Kökü Dışında
En basit ve çoğu tek sunuculu kurulum için yeterli yöntem: yapılandırma dosyasını web kök dizininin dışında tutmak ve izinlerini kısıtlamak.
Uygulanması gerekenler:
- Dosya, tarayıcıdan erişilemeyecek bir dizinde olmalı
- Yalnızca uygulama kullanıcısı okuyabilmeli
- Sürüm kontrolünden hariç tutulmalı
- Örnek bir şablon dosyası depoda bulunmalı — gerçek değerler olmadan
Son madde pratik bir alışkanlıktır: yeni bir kurulum yapan kişi hangi değerlerin gerektiğini şablondan görür, ama gerçek anahtarlar depoda yer almaz.
Seviye 2: Ortam Değişkenleri
Değerler dosya yerine servis tanımında veya ayrı bir ortam dosyasında tutulur ve uygulamaya çalışma anında geçirilir.
Avantajı: aynı kod, farklı ortamlarda farklı değerlerle çalışır. Test ve üretim ayrımı doğal olarak kurulur.
Dikkat edilecek nokta: ortam değişkenleri süreç listesinde görünebilir. Aynı sunucuda başka kullanıcılar varsa bu bir sızıntı yoludur. Değerleri servis tanımına gömmek yerine, izinleri kısıtlanmış bir ortam dosyasından okutmak daha güvenlidir.
Seviye 3: Sır Yönetim Sistemi
Birden fazla sunucu ve ekip varsa, merkezi bir sır yönetimi mantıklı hâle gelir. Bu sistemler şunları sağlar:
- Merkezi saklama. Sırlar tek yerde, şifreli olarak durur.
- Erişim denetimi. Hangi uygulama hangi sırra erişebilir, tanımlanır.
- Denetim kaydı. Kim ne zaman hangi sırra eriştiği kaydedilir.
- Kolay değiştirme. Bir anahtar tek yerden yenilenir.
Tek sunuculu küçük bir kurulum için bu genellikle fazladır. Ancak ekip büyüdüğünde ve sunucu sayısı arttığında, dosya tabanlı yönetim takip edilemez hâle gelir.
Bu seviyelerin hiçbiri paylaşımlı hostingde uygulanabilir değildir — dosyaları web kökü dışına taşımak, izinleri kısıtlamak ve ortam değişkeni tanımlamak kök erişimi gerektirir. Hassas veri işleyen bir uygulama çalıştırıyorsanız VDS sunucu, bu kontrolün en düşük maliyetli başlangıç noktasıdır.
Anahtar Değiştirme Alışkanlığı
Sır yönetiminin en çok ihmal edilen yanı, anahtarların değiştirilmesidir. Değiştirilmesi gereken durumlar:
- Ekipten biri ayrıldığında. O kişinin bildiği tüm anahtarlar.
- Sızıntı şüphesi olduğunda. Kesin bilgi beklemeyin.
- Anahtar yanlışlıkla depoya girdiğinde. Silmek yetmez.
- Düzenli aralıklarla. Kritik anahtarlar için periyodik yenileme.
Değiştirmeyi kolaylaştıran bir tasarım kuralı vardır: her servis için ayrı anahtar kullanın. Tek bir anahtar her yerde kullanılıyorsa, onu değiştirmek tüm sistemi aynı anda etkiler ve bu yüzden ertelenir.
Ekip İçinde Paylaşım
Sırların ekip içinde nasıl dolaştığı da güvenliğin parçasıdır:
- Mesajlaşma uygulamalarıyla paylaşmayın. Geçmişte kalır ve silinmesi güvenilir değildir.
- Parola yöneticisi kullanın. Ekip planları, kimin neye eriştiğini yönetmenizi sağlar.
- Erişimi kişiye değil role bağlayın. Kişi değiştiğinde erişim düzeni bozulmasın.
- Herkese her şeyi vermeyin. Geliştiricinin ödeme sağlayıcısı anahtarına ihtiyacı olmayabilir.
Sızıntı Kontrolü
Mevcut durumunuzu denetlemek için yapılabilecekler:
- Deponuzu tarayın. Geçmişte kalmış anahtar var mı? Bunu tespit eden araçlar mevcuttur.
- Yapılandırma dosyalarının izinlerini kontrol edin. Herkese okunabilir olan var mı?
- Web kökünde hassas dosya arayın. Tarayıcıdan erişilebilen bir yapılandırma dosyası var mı?
- Yedeklerinizin şifreli olduğunu doğrulayın.
- Log dosyalarını kontrol edin. Hata mesajları bazen şifreleri loglara yazar.
Son madde şaşırtıcı derecede yaygındır: bir bağlantı hatası oluştuğunda, hata mesajı bağlantı bilgilerinin tamamını loga yazabilir. Log dosyalarınızın izinlerini de kısıtlayın.
Sonuç
Sır yönetiminde ölçeğinize uygun seviyeyi seçin: tek sunuculu kurulumlarda web kökü dışında, izinleri kısıtlanmış bir yapılandırma dosyası yeterlidir; ekip ve sunucu sayısı arttığında merkezi bir sistem gerekir. Hangi seviyede olursanız olun iki kural değişmez: anahtarlar sürüm kontrolüne girmemeli ve her servis için ayrı anahtar kullanılmalıdır — çünkü değiştirilmesi kolay olmayan bir anahtar, hiç değiştirilmez. Bir anahtar yanlışlıkla depoya girdiyse dosyayı silmek yetmez; o anahtarı yenileyin.
Sıkça Sorulan Sorular (SSS)
Şifrelerimi nerede tutmalıyım?
Tek sunuculu kurulumlarda web kök dizininin dışında, yalnızca uygulama kullanıcısının okuyabildiği bir yapılandırma dosyasında. Bu dosya sürüm kontrolünden hariç tutulmalı; depoda yalnızca gerçek değerler içermeyen bir şablon bulunmalıdır.
Şifrem yanlışlıkla depoya girdi, dosyayı silmek yeterli mi?
Hayır. Sürüm kontrolüne giren bir bilgi, dosya silinse bile geçmişte kalır ve okunabilir. Tek doğru çözüm o anahtarı değiştirmektir. Aynı anahtarı başka yerlerde de kullanıyorsanız hepsini yenileyin.
Ortam değişkenleri güvenli mi?
Dosyaya göre avantajlıdır ama mutlak değil — ortam değişkenleri süreç listesinde görünebilir. Aynı sunucuda başka kullanıcılar varsa değerleri servis tanımına gömmek yerine izinleri kısıtlanmış bir ortam dosyasından okutun.
Anahtarları ne zaman değiştirmeliyim?
Ekipten biri ayrıldığında, sızıntı şüphesinde ve anahtar yanlışlıkla depoya girdiğinde mutlaka. Kritik anahtarlarda periyodik yenileme de faydalıdır. Değiştirmeyi kolaylaştırmak için her servise ayrı anahtar tanımlayın.
