- Konu sahibi
- #1
Uygulama sırları; parola, API anahtarı, erişim belirteci, özel sertifika anahtarı ve veritabanı bağlantı parolası gibi çalışma sırasında gizli kalması gereken değerlerdir. Bunları kaynak koduna yazmak yerine uygulamanın dışından, ortam değişkenlerinden veya bir sır yönetim sisteminden okutun. Kaynak kodunda yalnız değişken adı, gerekli ayar ve örnek şablon bulunsun; gerçek değer dağıtım ortamında sağlansın.
Kaynak kodu uygulamanın nasıl çalıştığını açıklar ve sürüm kontrolünde tutulabilir. Sır ise uygulamanın hangi hesaba veya hizmete erişebileceğini belirler. Kaynak kodu herkese açık olsa bile sırların açığa çıkmaması hedeflenir. Ancak kaynak koduna hiç sır koymamak tek başına yeterli değildir; günlükler, hata mesajları, yedekler, CI/CD değişkenleri ve istemciye gönderilen JavaScript dosyaları da kontrol edilmelidir.
Örneğin uygulama bir ödeme hizmetine bağlanıyorsa kaynak kodunda
Aşağıdaki ayrım, yerleşimi seçmek için pratik bir başlangıçtır.
Kaynak koduna
Git dışına çıkarmak dosyayı web erişiminden korumaz. Gerçek sır dosyalarını web kökü dışında ve sınırlı dosya izinleriyle tutun; istemci derlemesine aktarmayın.
Bu kural tek başına geçmişte kaydedilmiş sırları temizlemez. Bir sır daha önce Git geçmişine girdiyse dosyadan silmek yeterli değildir; sır hemen iptal edilmeli veya yenilenmeli, ardından geçmiş ve dağıtım günlükleri ayrıca incelenmelidir.
Aşağıdaki Node.js örneğinde uygulama,
POSIX kabuğunda yerel deneme:
Bu örnek yalnızca değişkenin boş olup olmadığını denetler ve localhost üzerinde sağlık yanıtı üretir; anahtarı bir sağlayıcıya göndermez ve geçerliliğini doğrulamaz. Başarılı durumda konsolda uygulamanın çalıştığını belirten mesaj, sağlık isteğinde ise
En yaygın hata,
Ortam değişkenleri kaynak kodundan ayrım sağlar ancak erişim denetimi, rotasyon ve kayıt maskeleme işlerini kendiliğinden çözmez. Birden fazla servis veya ekip söz konusuysa erişimi rol bazında sınırlayan bir sır yöneticisi kullanmak ve yalnız gereken servise gereken sırrı vermek daha doğru yaklaşımdır.
Kaynak kodu ile sır arasındaki fark
Kaynak kodu uygulamanın nasıl çalıştığını açıklar ve sürüm kontrolünde tutulabilir. Sır ise uygulamanın hangi hesaba veya hizmete erişebileceğini belirler. Kaynak kodu herkese açık olsa bile sırların açığa çıkmaması hedeflenir. Ancak kaynak koduna hiç sır koymamak tek başına yeterli değildir; günlükler, hata mesajları, yedekler, CI/CD değişkenleri ve istemciye gönderilen JavaScript dosyaları da kontrol edilmelidir.
Örneğin uygulama bir ödeme hizmetine bağlanıyorsa kaynak kodunda
PAYMENT_API_KEY adının kullanılması normaldir. Gizli sunucu anahtarı olan sk_live_... gibi gerçek bir değer kaynak koduna, HTML'ye, tarayıcı JavaScript'ine ya da Git deposuna girmemelidir. Bazı hizmetlerin özellikle yayımlanabilir olarak tanımladığı anahtarlar istemciye verilebilir; bütün API anahtarları gizli değildir. Sağlayıcının anahtar türünü ve yetkilerini esas alın. Tarayıcıda kullanılması zorunlu olan değerler de gerçekten gizli kabul edilmemelidir; istemciye gönderilen her değer kullanıcı tarafından görülebilir.Hangi değer nerede tutulmalı?
Aşağıdaki ayrım, yerleşimi seçmek için pratik bir başlangıçtır.
| Değer | Kaynak kodu | Çalışma ortamı | Not |
|---|---|---|---|
| Değişken adı ve varsayılan olmayan ayar | Evet | Gerekmez | Örneğin DATABASE_URL adı |
| Yerel geliştirme sırrı | Hayır | Yerel ortam değişkeni veya göz ardı edilen dosya | Ekip içinde güvenli yöntemle paylaşılmalı |
| Test sırrı | Hayır | CI/CD gizli değişkeni | Üretim sırrından ayrı olmalı |
| Üretim sırrı | Hayır | Sır yöneticisi veya platformun gizli ayarları | Yetki ve erişim günlükleri ayrıca yönetilmeli |
Kaynak koduna
.env.example gibi yalnızca isimleri ve biçimi gösteren bir şablon eklenebilir. Gerçek .env dosyası ise sürüm kontrolü dışında tutulmalıdır. Bunun için depodaki göz ardı dosyasına şu tür bir kayıt eklenir:
Kod:
.env
.env.*
!.env.exampleGit dışına çıkarmak dosyayı web erişiminden korumaz. Gerçek sır dosyalarını web kökü dışında ve sınırlı dosya izinleriyle tutun; istemci derlemesine aktarmayın.
.env dosyasının bulunması tek başına yüklenmesini de sağlamaz; kullandığınız çalışma ortamının açık yükleme ayarını yapın.Bu kural tek başına geçmişte kaydedilmiş sırları temizlemez. Bir sır daha önce Git geçmişine girdiyse dosyadan silmek yeterli değildir; sır hemen iptal edilmeli veya yenilenmeli, ardından geçmiş ve dağıtım günlükleri ayrıca incelenmelidir.
Uygulanabilir en küçük örnek
Aşağıdaki Node.js örneğinde uygulama,
APP_API_KEY değişkenini işletim sisteminden okur. Kodda gerçek anahtar bulunmaz.
Kod:
// app.cjs
const http = require('node:http');
const apiKey = process.env.APP_API_KEY;
if (!apiKey) {
console.error('APP_API_KEY tanımlı değil; uygulama başlatılmadı.');
process.exit(1);
}
http.createServer((req, res) => {
if (req.url === '/health') {
res.writeHead(200, {'content-type': 'text/plain; charset=utf-8'});
res.end('ok');
return;
}
res.writeHead(404);
res.end();
}).listen(3000, '127.0.0.1', () => {
console.log('Uygulama 3000 portunda çalışıyor.');
});POSIX kabuğunda yerel deneme:
- Dosyayı
app.cjsadıyla kaydedin. - Gerçek sır içermeyen örnek değeri verin:
APP_API_KEY='yerel-test-degeri' node app.cjs - Başka bir terminalde
http://127.0.0.1:3000/healthisteği gönderin veya bir HTTP istemcisiyle/healthyolunu çağırın.
Bu örnek yalnızca değişkenin boş olup olmadığını denetler ve localhost üzerinde sağlık yanıtı üretir; anahtarı bir sağlayıcıya göndermez ve geçerliliğini doğrulamaz. Başarılı durumda konsolda uygulamanın çalıştığını belirten mesaj, sağlık isteğinde ise
ok yanıtı görülür. “APP_API_KEY tanımlı değil” hatası, kodun bozuk olduğunu değil, gerekli sırrın çalışma ortamına verilmediğini gösterir. Üretimde komut satırına yazmak yerine platformun gizli değişken alanı veya sır yöneticisi kullanılmalıdır; komut geçmişi ve bazı işlem gözlem araçları değişken değerlerini açığa çıkarabilir.Dağıtımda izlenecek kararlar
- Kod incelemesinde parola, belirteç, özel anahtar ve bağlantı dizesi arayın; gerçek değer yerine ortam değişkeni adını bırakın.
- Yerel, test ve üretim için ayrı sırlar tanımlayın. Aynı anahtarı ortamlarda yeniden kullanmayın.
- Uygulama açılırken zorunlu sırları doğrulayın; eksikse güvenli olmayan varsayılanla devam etmek yerine başlatmayı durdurun.
- Sırları yalnız sunucu tarafında okuyun. HTML, istemci JavaScript'i, kaynak haritası ve hata yanıtlarına aktarmayın.
- Sürüm kontrolü, CI/CD çıktıları, uygulama günlükleri ve yedeklerde sır sızıntısı olup olmadığını kontrol edin.
- Bir sır sızdıysa önce iptal edip yenisini üretin; ardından sızıntı kaynağını giderin. Olay ve erişim kayıtlarını koruyarak erişimi sınırlayın; sır içeren alanları bütünlüğü ve saklama kurallarını koruyan kontrollü bir süreçle maskeleyin. Sadece dosyayı silmek geçerli sırrı etkisiz hale getirmez.
Sık yapılan hatalar
En yaygın hata,
.gitignore eklemenin daha önce commit edilmiş bir sırrı koruduğunu sanmaktır. Göz ardı kuralı yalnız izlenmeyen dosyaları etkiler. İkinci hata, sırları şifreleyip anahtarını da aynı depoda tutmaktır; bu gerçek bir ayrım sağlamaz. Üçüncü hata ise üretim sırrını uygulamanın hata mesajına, debug çıktısına veya istemci tarafı yapılandırmasına yazdırmaktır.Ortam değişkenleri kaynak kodundan ayrım sağlar ancak erişim denetimi, rotasyon ve kayıt maskeleme işlerini kendiliğinden çözmez. Birden fazla servis veya ekip söz konusuysa erişimi rol bazında sınırlayan bir sır yöneticisi kullanmak ve yalnız gereken servise gereken sırrı vermek daha doğru yaklaşımdır.
