Çalışma alanım, uygulama yapılandırma dosyalarında düz metin parolalara izin verilmeyen bir standarda sahiptir. Bu, yüzünde yeterince anlamlıdır, birisinin yapılandırma dosyalarına erişmesi durumunda, uygulamanın tüm ayrıcalıklarına otomatik olarak erişemez. Bazı durumlarda, oturum açma ile ilişkili erişime sahip olmak veya SQL Server kimlik doğrulaması için Windows Güvenliği kimlik doğrulaması gibi bir parolaya sahip olmamak veya J2EE ortamında JDBC yapılandırması gibi üçüncü taraf bir konumda yapılandırmak mümkün ve açık bir şekilde tercih edilebilir. , ancak bu her zaman mümkün değildir.
Yani aşağıdaki yorum için biraz uzun oldu ...
Belki bir adım geri atmak ve önleyici ve dedektif kontrollerin faydalarını karşılaştırmak yardımcı olabilir. Önleyici kontroller şifrelemeyi içerir, ancak şifreyi daha az belirgin hale getirmek için de kodlayabilirsiniz. Bu yaklaşım, şifreyi yanlışlıkla paylaşmaya karşı korumak içindir (bir b32 kodlaması daha az anlamlı karakterler üretecektir (b32, b64'ten daha uzun dize üretir) Böyle bir yaklaşım, rastgele sayı dizisini ve gereken yöntemi ezberleme zorluğunu arttırır. Base32/64 kodlaması, ek mantığın oluşturulmasını/korunmasını gerektirmeyen şifreleri korumanın basit bir yoludur.
Önleyici kontrollere yönelik diğer yaklaşımlar muhtemelen şifreleme kullanır. Anahtarı korumanın birçok farklı yolu vardır. Ayrıntılara girmeden ya da D.W. zaten yayınlanmışsa, güvenlik duruşunu iyileştirmek için dedektif kontrollerini katmanlayabilirsiniz. Örneğin, anahtarı içeren bir dosyaya erişimi denetleyebilirsiniz. Olayları (sunucunun/hizmetin yeniden başlatılması gibi) anahtar dosyaya erişim ile ilişkilendirebilirsiniz. Anahtar dosyasına başka herhangi bir erişim isteği (başarılı veya başarısız) anormal etkinliği gösterebilir.
Sorularınıza ulaşmak için:
şifreyi bir yapılandırma dosyasında saklamanız gerekiyorsa, en azından mümkün olduğunda şifreyi kodlamanızı öneririm. Şifrenin kodlanması, birisinin dosyada gezinmesi durumunda sızıntı olasılığını azaltacaktır. Parolayı şifrelemek çok daha güvenlidir, ancak bu ek karmaşıklık gerektirir.
Bir anahtarın sabit bir şekilde kodlanması veya başka bir dosyada saklanması gerektiği ile nasıl başa çıkılır. Şifreleme anahtarını başka bir dosyada ayırmak, birinin anahtarı görüntülemesini zorlaştırır. Örneğin, anahtar dosyasına erişimi sınırlamak için erişim denetimini kullanabilirsiniz, ancak yine de yapılandırma dosyası için daha açık bir ACL'yi koruyabilirsiniz. Benzer şekilde, anahtar kullanımını gerektiren olaylarla ilişkilendirmek için kullanabileceğiniz anahtar dosyasına erişim için denetim uygulayabilirsiniz. İkili dosyaya erişimi sınırlarsanız, anahtarın sabit kodlanması iyi olabilir. Şifrenin dikkatli bir şekilde kodlanması, ikili dosyaya karşı bir "dizeler" çalıştırılarak kolayca algılanabilir. Parolanın kodunu çözerken sabit kodlanmış parolayı kodlayabilir/şifreleyebilirsiniz (yani ayrı bir işlev (belki de denetleme ile) gerekir, ancak bu geliştirici ve yönetici için karmaşıklığı artırır (yani, ikili dosyayı yeniden oluşturmadan/yeniden derlemeden anahtarı nasıl değiştirir) ?).
Şifre şifreleme anahtarları okunabilir olmalı mı? Değişir. Anahtarı korumanın sınırlı sayıda yolu vardır. Bir şifreleme anahtarı genellikle belleğe işlenmesi zor olan alfasayısal bir dize olarak görülür. Anahtarı her zaman kodlayabilir/şifreleyebilirsiniz, ancak bu tür yöntemler ekran görüntüsü alacak kadar akıllı birini caydırmaz. Ancak, bir tuş genişletme işlevine giriş olarak basit "tuşları" (daha çok şifre gibi) kullanabilirsiniz. Bu durumlarda, kodlama gibi ek önlemler, karmaşıklık maliyetine göre bir miktar ek değer katar.
Herhangi bir şey varsa, iyi bir yaklaşım birden fazla kontrol katmanı uygulamaktır. Önleyici kontroller daha zorken, dedektif kontrollerin uygulanması genellikle daha kolaydır. Anahtar dosyaları ayırmak, kontrollerin genel mimarisini ve uygulamasını basitleştirebilir. Önleyici veya dedektif kontrollerin kullanılıp kullanılmadığına bakılmaksızın, denetim günlüklerinin gözden geçirilmesiyle birlikte bazı denetim işlevlerinin etkinleştirilmesi şarttır. Bu şekilde, olası olmayan (anahtara erişim) gerçekleşirse, düzeltici önlemler alabilirsiniz.
Bazı uzak hizmetlere erişmek için parola gerektiren bir sunucu çalıştırıyorsanız, iyi bir çözüm yoktur. Parolayı uygun bir yerde saklanan bir yapılandırma dosyasında saklamak, muhtemelen bir dizi kötü seçimden en iyi şekilde yararlanıyor.
Seçenekler şunlardır: bir kullanıcının önyükleme sırasında parolayı girmesini sağlayın (bu kötüdür, çünkü sunucunuz yeniden başlatılırsa, artık bir kişi fiziksel olarak sunucuya gidip parolayı girene kadar sunucuya erişilemez); şifreyi sunucu kodunun kaynak koduna sabit kodlayın (bu bir yapılandırma dosyasına koymaktan çok daha kötüdür); veya şifreyi bir yapılandırma dosyasında saklayın (tüm seçeneklerden en az kötü olanı). Yapılandırma dosyasıyla dikkat edilmesi gereken en önemli şey, dosyanın web kökünüzün dışında saklandığından ve dosya izinlerinin uygun şekilde kilitlendiğinden emin olmaktır.
Yapılandırma dosyasında saklanan şifreyi şifrelemek yardımcı olmaz, çünkü şimdi şifre çözme anahtarını nerede saklıyorsunuz? Sorunu daha yeni değiştirdiniz. "Tamamen kaplumbağalar" kabul edilebilir bir yanıt değil.
Windows'da bakabileceğiniz başka bir seçenek de parolayı DPAPI'de saklamaktır. Bu, masaüstü uygulamaları için biraz yardımcı olur, ancak katılımsız sunucular için çok yararlı değildir.
Daha fazla bilgi için, bu sitede aşağıdaki soruları okuyun: Kullanıcı etkileşimini önlemek için bir şifre saklayın , şifreleme için bir anahtar nerede saklanır , Açık kaynak projeleri nasıl yapılır? güvenli eserler işlensin mi? , Anahtarı kodlamadan Java ile verilerin şifresini nasıl çözebilirim? , .php dosyasındaki şifre , Nerede yapılır? Kaynağın görülebildiği bir sistem için anahtarı güvenli bir şekilde saklarım? .
Not; Prensip olarak, şifreyi saklamak için bir TPM kullanabilirsiniz - ancak pratikte bu sizi kanayan Edge sorunlarına yönlendirir, bu yüzden muhtemelen çoğu kişi için geçerli değildir.
Parolayı (oturum dışı) O/S kullanıcı ortamı değişkeninde saklayın ve programı bu kullanıcı olarak çalıştırın.
Avantajları:
Teslim edilecek dosya olmadığından, şifreyi asla yanlışlıkla kaynak denetiminde kontrol edemezsiniz.
Yapılandırma dosyanızdaki dosya izinlerini bozursanız (bu asla doğru olmaz mı?), Şifreleriniz tehlikeye atılmaz
Yalnızca kullanıcı veya kök tarafından okunabilir (bir yapılandırma dosyasıyla aynı, şifrelenmiş bir dosyayı koruyan özel bir anahtarla aynı)
Dosyayı şifreliyorsanız, anahtarınızı nasıl güven altına alıyorsunuz?
Yeni süreçlere başlamadan önce envvarlarınızı temizleyin, çünkü bunlar geçebilir
Bir HSM'nin bir avantajı, bir değerin şifresini çözmek için kullanıcı veya kök se HSM'nin anahtarın içine girememesidir.
Yerel şifre depolama, uğraştığım uzun bir sorundur. şifreleme kurşun geçirmez olmayacağından, ancak yardımcı olabileceğinden, birkaç seçenek daha vardır:
.
ve sorularınız için:
Bir yapılandırma dosyasında bir parolam olması gerektiğinde, ne düzeyde bir şifreleme taşımalıdır?
kodunuzda asla parola olması gerekmez, ancak en kolay ve en güvensiz yöntemdir.
Parola için şifreleme anahtarının sabit kodlanmış olması veya başka bir yapılandırma dosyasında saklanması gerektiği ile nasıl başa çıkıyorsunuz?
erişim kısıtlamalarını kullanma ve dosyayı izleme
Şifre şifreleme anahtarları okunabilir olmalı mı? güçlü ve okunabilir şifreler demek istiyorsan hiç sorun yok
Buradaki 2 sentim, mükemmel güvenlik için, uygulamanın aynı ayrıcalıklara sahip fiziksel makinedeki bir saldırganın yapmaması gereken bir şey yapabilmesini (parola okuyabilmesini) istersiniz, ki bu bir çelişki gibi görünüyor .
En iyi ihtimalle obfuscate yapılandırmadaki parolayı ( Base64 , bilgisayarda bir yerde anahtar vb.)