Şifreleme anahtarları ve kimlik bilgileri gibi sırlar birkaç nedenden ötürü kaynak denetiminde kontrol edilmemelidir. Birincisi, şifreleme anahtarlarının ve kimlik bilgilerinin her zaman bilmeye dayalı olması gerektiği ve kaynak kontrolünün bilgileri ifşadan korumak için güvenilir bir yol olmadığı açıktır. Bu tür sırları kaynak kontrolünüzde istememenizin diğer nedeni, genellikle sırların genellikle (ancak her zaman değil) uygulamanızın çalışacağı ortamın belirli bir özelliğine özgü olmasıdır. (Ör. bir web hizmeti yetkilendirmesi için gereken imza, söz konusu web hizmetinin belirli uç noktası, KG imzası gerektiren bir KG ortamında çalışıyor olabilir).
Bir çevreyi (veya küresel sırrı) tedavi etmenin doğru yolu, onu başka bir çevresel yapılandırma özelliğinde olduğu gibi iyi önlem almak için ek güvenlik denetimleriyle işlemektir. İyi tasarlanmış, bağımsız ve sürümlendirilebilir bir kod modülü, uygulamayı öznitelikleri hakkında bilgilendirmek için konuşlandırıldıkları ortamlar arasında aynı olmalıdır (ör. Veritabanı bağlantı ayrıntıları, kimlik bilgileri, web hizmeti uç noktaları, dosya yolları vb.) uygulamanız için çok önemli olan yapılandırma ayrıntıları dışsallaştırılmıştır ve ortamınızın yapılandırma parametreleri haline gelir.
Şimdi bazı argümanlarınızı ele almak için:
Genel olarak, sorunu sadece taşımıyor muyuz?
Mükemmel güvenlik diye bir şey yoktur, ancak sorunu ek önlemlerin ve kontrollerin yerleştirilebileceği bir alana "taşımak" zorluğu artıracak ve sırların yanlışlıkla veya kötü niyetli olarak ifşa olma olasılığını azaltacaktır. Gizli verilerin korunması gereken bir sistem tasarlarken uyulması gereken iyi bir kural, kontrolleri her zaman ikiye koymaktır. Bununla kastettiğim, gizli bilgilerin veya güvenlik olayının yanlışlıkla veya kötü amaçlı bir şekilde ifşa edilmesi için bir arıza veya iki veya daha fazla kontrolde olması gerekir.
Bunun iyi bir örneği şifreli bir dosyayı bir sunucuda depolamak olabilir. Ayrıca başka bir dosyada gizli tutmam gereken gizli bir şifre çözme anahtarım var.
- Anahtarı ve şifrelenmiş dosyayı aynı sunucuda saklayın (0 Kontrol, sunucuya erişimi olan herkes gizli bilgileri elde edebilir)
- Yukarıdaki adımları uygulayın ve her iki dosyaya da dosya erişimini koruyun, böylece yalnızca işletim sisteminin uygulama çalışma zamanı kullanıcısı tarafından okunabilir (1 Kontrol, kök kullanıcının veya uygulama çalışma zamanı kullanıcısının parolasını tehlikeye atmak, bir saldırganın gizli bilgi edinmesine izin verecektir)
- Anahtarı harici anahtar kasasında saklayın, anahtarı IP adresi beyaz listesi, sertifika kimlik doğrulaması ve dosya sistemindeki şifrelenmiş dosyaya erişebilen uygulamaya yönelik diğer önlemler gibi birden fazla güvenlik önlemi ile edinin. (Gizli verilerin tehlikeye atılması için Birden Çok Kontrol, birden fazla güvenlik kontrol hatası olması gerekir)
Yine, mükemmel güvenlik diye bir şey yoktur, ancak birden fazla kontrole sahip olma amacı, ifşanın gerçekleşmesi için birden fazla hatanın meydana gelmesini sağlar.
Bana öyle geliyor ki Azure KeyVault gibi ürünler daha iyi ve anlamsızca daha karmaşık,
Karmaşık evet, anlamsız tamamen özneldir. Gizli verilerin ifşa edilmesinin ne kadar ciddi olacağını gerçekçi bir şekilde dikkate almadan ek güvenliğin anlamsızlığı hakkında bir tartışma yapamayız. Eğer gizli verileri finans kurumunuzdan yasadışı banka havaleleri göndermek için kullanabiliyorsa, anahtar kasa gibi bir şey olabilecek en uzak şeyle ilgilidir.
sırlarınızı ayrı bir yapılandırma dosyasında tutmak ve .gitignore veya eşdeğerinde olduğundan emin olmak.
Birisi yanlışlıkla kaynak kontrolüne kadar kontrol edene kadar, artık sır sonsuza kadar kaynak kontrol geçmişine gömülüdür.
Tabii ki, insanlar muhtemelen güvensiz bir şekilde birbirlerine e-posta gönderecek ...
Güvenlik sadece teknik bir sorun değil, aynı zamanda bir halk sorunudur. Bu konu dışı olurdu, ancak bu noktada ihtiyaç duyduğunuzdan bahsetmeye çalıştığınızı hissediyorum.
Sadece sorunu taşımakla kalmayan sırları yönetmenin bir yolu var mı? Bu sorunun açık bir şekilde tanımlanmış tek bir cevabı olduğuna inanıyorum. Benzer şekilde, HTTPS'nin sorunu nasıl hareket ettirmediğini soracak olsaydım, cevap CA anahtarlarının işletim sisteminizle dağıtılması ve işletim sisteminin dağıtım yöntemine güvendiğimiz için onlara güveniyoruz.
Güvenlik her zaman problemleri ortadan kaldırmaz, çoğu zaman kontrolleri etrafına koyar. Analojiniz özlüdür, çünkü aslında kamu-özel anahtar şifrelemesinin yaptığı tam olarak budur. Kamu sertifikasına sahip olan kurumun kimliğini kefil etmek için CA'mıza güvenilmez ve tam bir güven vererek “sorunu CA'ya taşıyoruz”. Temel olarak, bir güvenlik sorununa yol açmak için yıkıcı bir başarısızlık dizisinden (ör. CA'ya güvenini kaybetmekten) kısa bir şey olmamalıdır.
Birçok şeyde olduğu gibi, güvenlik sübjektif kriterlere, verinin niteliğine, açıklamanın sonuçlarına, risk iştahına, bütçeye vb. Dayalı olarak çizmeniz gereken bir çizgidir.