Dev, Staging ve Prod için Gizli Bilgiler ve Yapılandırma Yönetimi

Çözdüğümüz sorun

Gizli bilgiler ve yapılandırma yönetimi, hassas değerleri kopyalanma, önbelleğe alınma veya kazara paylaşılabilecek yerlerden uzak tutmakla ilgilidir.

Bir sır, erişim sağlayan veya kimliği kanıtlayan herhangi bir şeydir — örneğin bir API anahtarı, veritabanı parolası, SMTP girişi veya webhook imzalama sırrı. Normal konfigürasyon ise açık olsa zararlı olmayan bir değerdir; örneğin bir özellik bayrağı adı, zaman aşımı veya herkese açık bir sitenin temel URL'si.

Dev, staging ve prod farklı amaçlar için farklı değerler gerektirir. Dev hızlı tekrar deneme ve güvenli test içindir. Staging prod gibi görünmeli ama izole kalmalıdır. Prod ise kilitli, denetlenebilir ve stabil olmalıdır. Aynı sırları her yerde kullanırsanız, devdeki bir sızıntı prod'da bir ihlale dönüşebilir.

"Build'lere sızma" demek, bir sırın derlenmiş bir backend ikilisi, bir mobil uygulama paketi veya bir ön yüz bundle'ı gibi paketlenip paylaşılan bir şeyin parçası haline gelmesidir. Bir sır build artefaktına girdikten sonra kontrolünüz dışındaki yerlere yayılabilir.

Kaza eseri sızıntılar genellikle birkaç tahmin edilebilir yoldan olur:

• Kaynak koda, örneklere veya yorumlara sırları doğrudan yazmak
• Yerel .env dosyasını veya konfigürasyon ihracını repoya commit etmek
• Sırları kullanıcı cihazlarında çalışan front-end veya mobil build'lere gömmek
• Sırları loglarda, çökme raporlarında veya build çıktısında yazdırmak
• "Hızlı bir test için" prod değerlerini staging'e kopyalamak

Basit bir örnek: bir geliştirici "e-postayı çalıştırmak için" bir SMTP parolasını konfigürasyon dosyasına ekler, sonra dosya commit edilir veya bir yayın build'ine paketlenir. Parolayı daha sonra döndürseniz bile, eski build hala CI önbelleğinde, uygulama mağazası yüklemesinde veya birinin indirme klasöründe durabilir.

Hedef basittir: sırları kodun ve build'lerin dışında tutmak ve ortama göre doğru değerleri çalışma zamanında ya da güvenli bir dağıtım adımıyla enjekte etmek.

Çoğu sızıntıyı önleyen temel ilkeler

Güvenliğin büyük bir kısmı her seferinde uygulayacağınız birkaç alışkanlıktan gelir.

Sırları koddan ve build çıktılarından uzak tutun. Kod yayılır. Kopyalanır, incelenir, loglanır, önbelleğe alınır ve yüklenir. Build'ler de yayılır: artefaktlar CI loglarına, uygulama paketlerine, konteyner kayıtlarına veya paylaşılan klasörlere girebilir. Commit edilen veya derlenen her şeyi herkese açık olarak değerlendirin.

Ortam başına ayrı kimlik bilgileri kullanın (en az ayrıcalık). Geliştirme anahtarınız sadece devde çalışmalıdır ve yapabilecekleri sınırlı olmalıdır. Bir anahtar bir dizüstü bilgisayardan veya test sunucusundan sızarsa, zarar kontrol altında kalır. Aynı fikir SMTP kullanıcıları, veritabanı parolaları ve webhook imzalama sırları için de geçerlidir.

Rotasyonu sıkıcı hale getirin. Rotasyon yapacağınızı varsayın çünkü yapacaksınız. Bir değeri kodu düzenlemeden ve tüm uygulamaları yeniden derlemeden değiştirebilecek şekilde tasarlayın. Birçok sistem için bu, sırları çalışma zamanında okumak (ortam değişkenlerinden veya bir sır deposundan) ve geçiş sırasında birden fazla aktif sırrı desteklemek anlamına gelir.

Erişimi kısıtlayın ve kaydedin. Sırları sadece ona ihtiyaç duyan servis okuyabilmeli ve sadece çalıştığı ortamda. İnsan erişimi nadir, süreli ve denetlenebilir olmalı.

Çoğu durumu kapsayan küçük bir kural seti istiyorsanız:

• Sırları commit etmeyin veya bunları ticket'lara, sohbetlere ya da ekran görüntülerine yapıştırmayın.
• Dev, staging ve prod için ayrı kimlik bilgileri kullanın.
• Değerleri görüntülere veya mobil build'lere gömmek yerine çalışma zamanı konfigürasyonunu tercih edin.
• Herhangi bir şüpheli maruz kalmadan sonra ve düzenli olarak rotasyon yapın.
• Kimlerin ve nelerin sırları okuyabileceğini kısıtlayın ve erişim loglarını tutun.

Bu ilkeler geleneksel kod yığını veya AppMaster gibi no-code platformları kullanmanız fark etmeksizin geçerlidir. Daha güvenli yol aynıdır: sırları build'in dışında tutun ve kullanım yapılan yerde sıkı şekilde sınırlandırın.

Sırların en sık nereden sızdığı

Çoğu sızıntı "hack" değil. Normal iş sırasında olur: hızlı bir test, yardımcı bir ekran görüntüsü, fazla bilgi veren bir build. Başlangıç için bu küçük hataların genellikle nerede olduğunu bilmek yeterlidir.

Kaynak kontrol klasik kaynaktır. Birisi bir API anahtarını bir konfigürasyon dosyasına "şimdilik" yapıştırır, commit eder ve bu dal, pull request ve kod inceleme yorumlarıyla yayılır. Daha sonra silseniz bile, sır tarihçede veya kopyalanmış bir yamada sonsuza kadar yaşayabilir.

Kullanıcılara gönderdiğiniz her şey başka bir büyük sızıntı kaynağıdır. Front-end bundle'ları ve mobil uygulama ikilileri kolayca incelenebilir. Bir sır JavaScript'teyse, iOS/Android uygulamasındaysa veya "gömülü" bir konfigürasyonsa, bunun herkese açık olduğunu varsayın. İstemci uygulamalar genel tanımlayıcılar tutabilir ama özel anahtarlar tutmamalıdır.

Sırlar ayrıca otomasyon ve destek sırasında oluşan "yardımcı gürültü" ile de sızar. Yaygın örnekler: ortam değişkenlerini eko eden CI logları, SMTP kimlik bilgilerini içeren debug çıktıları, yapı önbelleklerinde kazara depolanan .env dosyaları, veya ayar sayfası ekran görüntüleriyle gönderilen destek ticket'ları.

Yaygın bir desen, bir sırın bir kez build pipeline'ına girmesi ve sonra her yere kopyalanmasıdır: bir konteyner katmanına, önbelleğe alınmış bir artefakta, bir loga ve bir ticket'a. Çözüm nadiren tek bir aracıdır. Alışkanlıktır: sırları koddan, build'lerden ve insanların sohbete yapıştırdıklarından uzak tutun.

Yaygın sır türleri ve riskleri

Hangi tür sırla uğraştığınızı, sızarsa ne yapabileceğini ve nerede asla görünmemesi gerektiğini bilmek faydalıdır.

API anahtarları (Stripe, maps, analytics ve diğer hizmetler) genelde "proje düzeyi" kimlik bilgileridir. Uygulamanızı tanımlar ve kart çekmek, kullanım istatistiklerini okumak gibi belirli eylemlere izin verebilir. Bunlar kullanıcı tokenlarıyla aynı şey değildir. Tokenlar belirli bir kullanıcı oturumunu temsil eder ve süresi dolmalıdır. Birçok API anahtarı kendi kendine süresi dolmaz, bu yüzden sızıntılar daha yıkıcıdır.

SMTP kimlik bilgileri genelde bir e-posta sunucusu için kullanıcı adı ve paroladır. Sızarlarsa bir saldırgan hesabınızdan spam gönderebilir ve teslimat itibarınızı bozabilir. API tabanlı e-posta sağlayıcıları ham SMTP parolaları yerine API anahtarları ve kapsamlı izinler sunar; bu daha güvenli olabilir, ama anahtar hesabınızdan e-posta gönderebiliyorsa risk yüksek kalır.

Webhook sırları (imzalama sırları veya doğrulama anahtarları) gelen istekleri korur. İmza sırrı sızarsa, biri "ödeme başarılı" veya "abonelik iptal edildi" gibi sahte olaylar oluşturup sisteminizi kandırabilir. Tehlike sadece veri sızması değildir; sahte olaylarla iş mantığının çalıştırılmasıdır.

Diğer yüksek etkili sırlar arasında veritabanı URL'leri (genellikle gömülü parolalarla), servis hesabı kimlik bilgileri ve şifreleme anahtarları vardır. Sızmış bir veritabanı URL'si tüm verilerin çalınması anlamına gelebilir. Bir şifreleme anahtarının sızması geçmiş ve gelecekteki verilerin okunabilir hale gelmesine yol açar ve rotasyon zahmetli olabilir.

Etkisini hızlı düşünme yolu:

• Para harcayabilir veya eylem tetikleyebilir: ödeme anahtarları, yönetici API anahtarları, webhook imzalama sırları
• Sizi taklit edebilir: SMTP parolaları, e-posta gönderme anahtarları, mesajlaşma bot tokenları
• Tüm verileri açığa çıkarabilir: veritabanı kimlik bilgileri, bulut servis hesapları
• Gizliliği kalıcı olarak bozabilir: şifreleme anahtarları, imzalama anahtarları
• Genelde güvenle gönderilebilir: tarayıcı için tasarlanmış yayınlanabilir anahtarlar (yine de domain/app ile sınırlandırın)

Bu öğeleri istemci uygulamalara (web, iOS, Android) asla göndermeyin: gizli API anahtarları, SMTP kimlik bilgileri, veritabanı parolaları, servis hesapları, özel şifreleme anahtarları ve webhook imzalama sırları. Eğer bir istemcinin üçüncü taraf bir API çağırması gerekiyorsa, sırrın server tarafında kalması için çağrıyı backend'e yönlendirin.

Build'lere gömmeden sır saklama desenleri

Güvenli bir varsayılan basittir: sırları derlenen, dışa aktarılan veya paylaşılan hiçbir şeye gömmeyin. Build'leri özel artefaktlar olarak değil, kamuya açık nesneler olarak değerlendirin.

Her ortam için doğru konteyneri seçin

Yerel geliştirme için bir konfigürasyon dosyası versiyon kontrolünün dışında kalacaksa ve kolayca değiştirilebilecekse (örneğin yerel .env tarzı dosya) uygun olabilir. Staging ve prod için gerçek bir sır deposu tercih edin: bulut sağlayıcınızın secret manager'ı, özel bir vault veya platformunuzun korumalı ortam ayarları.

Ortam değişkenleri çalışma zamanı enjekte etme açısından iyi bir varsayılandır çünkü kod tabanından ayrı ve kolaydır. Önemli ayrıntı zamanlamadır: çalışma zamanı enjeksiyonu, sırın build çıktısının parçası olmasını engellediği için build-zamanı enjeksiyonundan daha güvenlidir.

Birçok ekip için pratik bir ayrım:

• Yerel dev: versiyon kontrolüne dahil edilmeyen yerel env değişkenleri veya yerel sır dosyası, her geliştirici makinesi için benzersiz
• Staging: bir sır yöneticisi veya korumalı ortam ayarları, sadece staging'e scoped
• Production: daha sıkı erişim kontrolleri, denetim logları ve rotasyon ile bir sır yöneticisi

İsimlendirme ve sınırları tutarlı tutun

Her ortamda aynı anahtar adlarını kullanın ki uygulama aynı davransın: SMTP_HOST, SMTP_USER, SMTP_PASS, STRIPE_SECRET_KEY, WEBHOOK_SIGNING_SECRET. Sadece değerler değişsin.

Ortamların önemli olduğu durumlarda (ödeme, e-posta, webhook'lar) mümkünse her ortam için ayrı projeler veya bulut hesapları kullanın. Örneğin staging Stripe anahtarlarını ve webhook sırlarını sadece staging'e ait bir depoda tutun ki staging hatası prod'u etkilemesin.

AppMaster gibi bir platformla deploy ediyorsanız, backend servisleri için çalışma zamanı ortam ayarlarını tercih edin ki sırlar server tarafında kalsın ve dışa aktarılan kod veya client uygulamalara gömülmesin.

Dev, staging ve prod arasında adım adım kurulum

Varsayılan kötü kullanımı zorlaştırın.

1. Elinizdekileri ve nerede kullanıldığını envanterleyin. API anahtarları, SMTP kullanıcı adları ve parolaları, webhook imzalama sırları, veritabanı parolaları, JWT imzalama anahtarları ve üçüncü taraf tokenlarını dahil edin. Her biri için sahibi (takım veya satıcı), okuyan bileşeni (backend, worker, mobil, web) ve makul bir rotasyon sıklığını not edin.

2. Dev, staging ve prod için ayrı değerler ve ayrı izinler oluşturun. Dev sırları dizüstü bilgisayarlardan ve yerel konteynerlerden güvenle kullanılabilecek şekilde olmalı. Staging prod gibi görünmeli ama prod kimlik bilgilerini veya hesaplarını asla paylaşmamalı. Prod sadece üretim çalışma zamanı kimliği tarafından okunabilir olmalı; insan erişimi varsayılan olarak olmamalı.

3. Sırları build-zamanı değil, çalışma zamanı konfigürasyonuna taşıyın. Bir sır build sırasında mevcutsa build loglarına, Docker katmanlarına, istemci bundle'larına veya çökme raporlarına girebilir. Basit kural: build'ler kolayca kopyalanabilecek artefaktlar üretir; sırlar ise uygulama başladığında enjekte edilir.

4. Tutarlı bir dağıtım akışı kullanın. Takımları işten uzak tutacak bir yaklaşım:

• Her ortam için bir sır deposu oluşturun (veya ortam başına katı namespace).
• Uygulama çalışma zamanı kimliğine sadece kendi ortam sırlarını okuma izni verin.
• Sırları başlangıçta ortam değişkenleri veya monte edilmiş dosyalar şeklinde enjekte edin; bunları imajlara ve ön uç bundle'larına koymayın.
• Her sır için rotasyon kuralları ekleyin (süre sonu, sahibi ve hatırlatıcı takvimi).
• Katı bir test ekleyin: staging dağıtımları prod sırrını okumaya çalışırsa başarısız olsun.

Kilitlenme çoğunlukla kimlerin ve nelerin sırları okuyabildiğini azaltmak demektir. Paylaşılan hesaplardan kaçının, uzun ömürlü tokenları mümkün olduğunca sınırlayın ve okuma izinlerini yazma izinlerinden daha dar tutun.

AppMaster gibi no-code bir platform kullanıyorsanız aynı yaklaşım geçerlidir: üçüncü taraf kimlik bilgilerini ortam-a özgü çalışma zamanı ayarlarında tutun ve üretilen artefaktları ekip içinde bile kamuya açık olarak düşünün. Bu tek karar birçok kazara sızıntıyı engeller.

API anahtarları ve SMTP kimlik bilgileri için pratik desenler

Birçok sızıntı, bir uygulamanın "bir şey göndermesi" gerektiğinde en hızlı çözümün kimlik bilgilerini istemciye veya paketlenmiş bir konfigürasyona yapıştırmak olduğu durumlarda olur. İyi bir varsayılan kural basittir: web ve mobil istemciler SMTP kullanıcı adları, SMTP parolaları veya mesaj gönderebilen sağlayıcı anahtarları asla tutmamalıdır.

E-posta için mümkünse ham SMTP yerine bir e-posta sağlayıcısının API anahtarını tercih edin. API tabanlı gönderim, yalnızca e-posta gönderme gibi izinleri sınırlandırmayı, rotasyonu ve izlemeyi kolaylaştırır. SMTP kullanmak zorundaysanız, bunu sadece sunucu tarafında tutun ve backend'i mail sunucusuyla konuşan tek yer yapın.

Güvende kalacak pratik bir kurulum:

• E-posta gönderimini bir backend uç noktasının arkasına koyun (örneğin: "şifre sıfırlama e-postası gönder" veya "fatura gönder").
• API anahtarını veya SMTP parolasını backend'de ortam sırrı olarak saklayın; kaynak kodda veya UI ayarlarında değil.
• Dev, staging ve prod için ayrı kimlik bilgileri kullanın (tercihen ayrı hesaplar ve gönderici domainleri).
• Staging alıcı izin listesi (allowlist) ekleyin, böylece sadece onaylı adreslere mail gönderilsin.
• Teslimat sonuçlarını (mesaj ID, sağlayıcı yanıtı, alıcı domain) loglayın ama asla kimlik bilgilerini veya tam mesaj gövdelerini loglamayın.

Staging ile prod arasındaki ayrım düşündüğünüzden daha önemlidir. Eğer staging aynı gönderici ve alıcı kurallarını paylaşıyorsa, staging yanlışlıkla gerçek müşterilere spam gönderebilir. Basit bir koruma: staging'de sadece izin verilen adreslere outbound e-posta izni verin.

Örnek: AppMaster'da bir müşteri portalı yapıyorsunuz. Mobil uygulama "bana giriş kodu gönder" tetikliyor. Uygulama backend'e çağrı yapıyor, backend prod veya staging mail sırrını ortamından okuyor ve e-postayı gönderiyor. Test eden biri staging kullanıyorsa allowlist gerçek müşterilere mesaj gitmesini engeller ve loglar anahtarları açığa çıkarmadan gönderimin başarılı olup olmadığını gösterir.

Webhook sırları: imzalama, doğrulama ve rotasyon

Webhook güvenliği tek bir kurala dayanır: her isteği backend'de, asla dışarı çıkmayan bir sırla doğrulayın. Bir sır web veya mobil uygulamaya gönderilirse, artık sır değildir.

İmzalama ve doğrulama

Bir webhook'u gelen bir kart ödemesi gibi ele alın: doğrulanmadan hiçbir şeyi kabul etmeyin. Sağlayıcı, payload ve paylaşılan sırdan hesaplanmış bir imza başlığı gönderir. Sunucunuz beklenen imzayı yeniden hesaplar ve karşılaştırır.

Basit bir doğrulama akışı:

• Ham istek gövdesini tam olarak al (yeniden biçimlendirme yapma).
• Webhook sırrınızı kullanarak beklenen imzayı hesaplayın.
• Sabit zamanlı karşılaştırma ile kontrol edin.
• Eksik veya geçersiz imzaları 401 veya 403 ile reddedin.
• Ancak sonra JSON'ı ayrıştırıp olayı işleyin.

Dev, staging ve prod için ayrı webhook uç noktaları ve ayrı sırlar kullanın. Bu, bir geliştirme aracının veya test sisteminin prod eylemlerini tetiklemesini engeller ve olayları izole etmeyi kolaylaştırır. AppMaster'da bu genelde her dağıtım için farklı ortam konfigürasyonları ve webhook sırrının server-side bir değişken olarak tutulması anlamına gelir.

Replay koruması ve rotasyon

İmzalar tahrifi engeller ama replay'i otomatik durdurmaz. Her isteği yalnızca bir kez geçerli kılacak veya kısa bir zaman penceresi ile sınırlayacak kontroller ekleyin. Yaygın seçenekler: zaman damgası başlığı ile sıkı bir zaman limiti, nonce veya iki kere işlenmesini reddettiğiniz idempotency anahtarı.

Rotasyonu ihtiyaç olmadan önce planlayın. Güvenli bir desen, kısa bir üst üste binme için iki aktif sırı desteklemektir: doğrulamada ya eski ya yeni sırrı kabul edin, sağlayıcıyı güncelledikten sonra eskiyi kaldırın. Net bir kesme zamanı tutun ve eski imza trafiği için izleyin.

Son olarak, loglarla dikkatli olun. Webhook payload'ları genellikle e-postalar, adresler veya ödeme meta verileri içerir. Olay ID'lerini, tiplerini ve doğrulama sonuçlarını loglayın, ama tam payload'ları veya başlıkları yazdırmaktan kaçının.

Kaçınılması gereken yaygın hatalar ve tuzaklar

Çoğu sızıntı geliştirirken pratik görünen basit alışkanlıklardan kaynaklanır, sonra staging ve prod'a kopyalanır.

Yerel .env dosyasını her zaman güvenli bir yer gibi görmek yaygın bir hatadır. Dizüstü bilgisayarınız için uygun olabilir ama repoya, paylaşılan zip'e veya Docker imajına kopyalanırsa tehlikeli hale gelir. Eğer .env kullanıyorsanız, versiyon kontrolünden dışarda tuttuğunuzdan ve gerçek dağıtımlarda ortam ayarlarıyla değiştirdiğinizden emin olun.

Aynı kimlik bilgilerini her yerde kullanmak başka sık yapılan hatadır. Dev, staging ve prod'ta aynı API anahtarını kullanmak bir dev hatasının prod olaya dönüşmesine neden olur. Ayrı anahtarlar ayrıca rotasyon, iptal ve denetimi kolaylaştırır.

Web ön yüzleri ve mobil uygulamalar için build-zamanında sır enjekte etmek özellikle risklidir. Bir sır derlenmiş bir bundle veya uygulama paketine girerse, çıkarılabileceğini varsayın. Ön yüzler sadece herkese açık yapılandırma (örneğin temel API URL'si) almalı; hassas olan her şey sunucuda kalmalıdır.

Loglar sessiz bir sızıntı kaynağıdır. "Geçici" bir debug print ifadesi aylarca kalabilir ve sevk edilebilir. Bir değeri doğrulamanız gerekiyorsa, sadece maskelenmiş bir versiyonunu loglayın (örneğin son 4 karakter) ve ifadeyi hemen kaldırın.

Sorun işaretleri (red flag)

• Sırlar Git geçmişinde görünüyorsa, daha sonra silinmiş olsa bile.
• Tek bir anahtar her ortamda çalışıyorsa.
• Bir mobil uygulama tedarikçi anahtarları veya SMTP parolaları içeriyorsa.
• Destek ticket'larında tam istek dökümleri ve başlıklar varsa.
• Değerler base64 ile kodlanmış veya form alanlarında saklanmışsa.

Kodlama koruma değildir ve gizlenen alanlar kullanıcılar tarafından görülebilir.

AppMaster ile geliştiriyorsanız hassas değerleri her dağıtım hedefi için ortam düzeyinde konfigürasyonlarda tutun ve istemci uygulamalara sadece hassas olmayan ayarları geçirin. Kısa bir gerçeklik kontrolü: tarayıcı görebiliyorsa, onu herkese açık kabul edin.

Yayınlamadan önce hızlı kontrol listesi

"Ne sızabilir" zihniyetiyle son bir geçiş yapın. Çoğu olay sıkıcı nedenlerle olur: bir anahtar ticket'a yapıştırılmıştır, bir ekran görüntüsü bir konfigürasyonu gösterir veya bir build artefaktı gizlice bir sır içerir.

Yayınlamadan önce bu temel maddeleri doğrulayın:

• Sırlar repoda, issue'larda, dokümanlarda, ekran görüntülerinde veya sohbet loglarında yok. Eğer birini yapıştırdıysanız, onun ele geçirilmiş olduğunu varsayın ve rotasyon yapın.
• Web ve mobil build'ler sadece herkese açık ayarlar içeriyor. Özel anahtarlar, SMTP parolaları ve webhook imzalama sırları sunucu tarafında veya ortam-a özgü sır depolarında olmalı.
• Staging prod'dan izole. Kendi API anahtarlarını, SMTP hesabını ve test ödeme/webhook uç noktalarını kullansın. Staging prod veritabanlarını veya prod sır yöneticilerini okuyamamalı.
• CI logları, monitoring ve hata raporları hassas değerleri yazdırmıyor. Build çıktısını, çökme raporlarını ve debug loglarını kontrol edin. Tokenları maskelenmiş şekilde loglayın ve Authorization gibi başlıkları sansürleyin.
• Kod değişikliği olmadan hızlıca rotasyon ve iptal yapabiliyor olun. Sırların dağıtım zamanında enjekte edildiğinden emin olun (ortam değişkenleri veya sır yöneticisi), böylece bir anahtar değişikliği acil bir yeniden derleme olmadan yapılandırma güncellemesi olur.

AppMaster kullanıyorsanız sırları her ortam için dağıtım-zamanı konfigürasyonu olarak görün, UI ekranlarına veya dışa aktarılan build'lere gömmeyin. Faydalı bir son kontrol, derlenmiş artefaktlar ve loglarda sk_live, Bearer veya SMTP host adları gibi kalıpları aramaktır.

Her entegrasyon için bir "kill switch" yazın: anahtarı nereden devre dışı bırakacağınız ve bunu beş dakika içinde kimlerin yapabileceği.

Örnek senaryo: ödemeler, e-posta ve webhook'lar

Üç kişilik bir ekip bir müşteri portalı (web), bir yardımcı mobil uygulama ve makbuz gönderen/senkronize eden küçük bir arka plan işi çalıştırıyor. Üç ortamları var: dizüstü bilgisayarlardaki dev, QA için staging ve gerçek kullanıcılar için prod. Günlük işleri yavaşlatmayan bir sır ve konfigürasyon düzeni istiyorlar.

Geliştirmede sandbox ödeme anahtarları ve test SMTP hesabı kullanıyorlar. Her geliştirici sırları yerel ortam değişkenlerinde (veya versiyon kontrolüne alınmamış bir yerel dosyada) tutuyor, böylece repoya hiçbir şey düşmüyor. Web uygulaması, mobil uygulama ve arka plan işi aynı değişken adlarını PAYMENTS_KEY, SMTP_USER, WEBHOOK_SECRET gibi okur, ancak ortam başına değerler farklıdır.

Staging'de CI build'i deploy ediyor ve platform sırları çalışma zamanında enjekte ediyor. Staging kendi ödeme hesabını, kendi SMTP kimlik bilgilerini ve kendi webhook imza sırrını kullanıyor. QA gerçek akışları test edebiliyor ama prod sistemlerine dokunma riski yok.

Prod'ta aynı build artefaktları dağıtılıyor, ama sırlar özel bir sır deposundan (veya bulut sağlayıcısının secret manager'ından) geliyor ve sadece çalışan servislere erişim veriliyor. Ekip ayrıca daha sıkı izinler koyuyor: sadece arka plan işi SMTP kimlik bilgilerini okuyabiliyor, sadece webhook işleyici webhook sırrını okuyabiliyor.

Bir anahtar açığa çıkarsa (örneğin bir ekran görüntüsü bir API anahtarını gösteriyorsa), sabit bir playbook izliyorlar:

• Açığa çıkan anahtarı hemen iptal edip ilgili sırları döndürün.
• Maruz kalma penceresi sırasında şüpheli kullanımı loglarda arayın.
• Servisleri yeni değerleri almak için yeniden dağıtın.
• Olayı belgeleyin ve bir guardrail (örneğin pre-commit taraması) ekleyin.

Yerel çalışmayı kolay tutmak için prod sırlarını hiçbir zaman paylaşmıyorlar. Geliştiriciler sandbox hesapları kullanıyor ve AppMaster gibi no-code bir araç kullanırlarsa, dev, staging ve prod için ayrı ortam değerleri saklıyorlar ki aynı uygulama mantığı her yerde güvenli çalışsın.

Bir sonraki adımlar: iş akışınıza tekrarlanabilir hale getirin

Sır yönetimini hijyen gibi ele alın. İlk sefer can sıkıcı gelebilir. Sonrasında rutin hissetmeli.

Önce basit bir sır haritası yazın:

• Sırın ne olduğu (API anahtarı, SMTP parolası, webhook sırrı)
• Nerede kullanıldığı (servis, işçi, mobil uygulama, satıcı paneli)
• Ortam bazında nerede saklandığı (dev, staging, prod)
• Kimlerin erişebileceği (insanlar, CI/CD, sadece runtime)
• Nasıl döndürüleceği (adımlar ve neyin izleneceği)

Sonra her ortam için bir saklama deseni seçin ve ona bağlı kalın. Tutarlılık karmaşıklığı yenmekten iyidir. Örneğin: geliştiriciler yerel bir sır deposu kullanır, staging sınırlı erişimli yönetilen sırları kullanır ve production aynı yönetilen sırları daha sıkı denetimle kullanır.

Rotasyon takvimi ve uygulanabilir bir olay planı ekleyin:

• Yüksek riskli anahtarları takvime göre döndürün (ve personel değişikliklerinden hemen sonra).
• Sızıntı olacağını varsayın: iptal et, değiştir ve trafiğin normale döndüğünü doğrula.
• Kimin neyi ne zaman döndürdüğünü loglayın.
• Patlama alanı kontrollerini belirleyin (ödeme, e-posta gönderimi, webhook'lar).

AppMaster (appmaster.io) ile geliştiriyorsanız özel anahtarları server-side konfigürasyonlarda tutun ve her ortam için deploy edin ki web ve mobil build'ler sırları içermesin. Ardından süreci staging üzerinde uçtan uca bir anahtar döndürme ile doğrulayın (depoyu güncelle, yeniden dağıt, doğrula, eskiyi iptal et). Bunu bir kez kanıtladıktan sonra diğer sır için de tekrarlayın.