Sırları kaynak kontrolünün dışında tutmak - sadece sorunu değiştiriyor muyuz?


10

App.config ve benzeri dosyalarda sırların kaynak kontrolünde olduğu bazı projeleri miras aldım. Neyse ki bu halka açık bir depo değil, bu yüzden risk olabileceği kadar ciddi değil. Azure KeyVault gibi bunu yönetmenin daha iyi yollarını arıyorum. (Ama bu soruyu bu çözüme özgü olmaya niyet etmiyorum.)

Genel olarak, sorunu sadece taşımıyor muyuz? Örneğin, Azure KeyVault ile uygulama kimliği ve uygulama sırrı, kaynak denetiminden uzak tutmanız gereken şeyler haline gelir. İşte bunun nasıl yanlış gittiğine dair ne yazık ki tipik bir örnek . Diğer yaklaşımlar, korumanız gereken API anahtarları veya anahtar deposu dosyalarıyla benzer hale gelir.

Bana öyle geliyor ki Azure KeyVault gibi ürünler, sırlarınızı ayrı bir yapılandırma dosyasında tutmak ve .gitignore veya eşdeğerinizde olduğundan emin olmaktan daha iyi ve anlamsız derecede daha karmaşık değildir . Bu dosyanın gerektiği şekilde bir yan kanal aracılığıyla paylaşılması gerekir. Tabii ki, insanlar muhtemelen güvensiz bir şekilde birbirlerine e-posta gönderecek ...

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. (Olmamız gerekip gerekmediği ayrı bir soru ...)

Yanıtlar:


12

Sadece problemi hareket ettirdiğinizi söyleyebilirsiniz. Nihayetinde, şifreniz, ssh anahtarlarınız varsa, uygulamanızın erişebileceği bir yerde saklanan bir sır olması gerekir.

Ancak, doğru yapılırsa, sorunu daha iyi koruyabileceğiniz bir yere doğru şekilde sabitlemek zor olan bir yerden taşıyorsunuz. Örneğin, bir kamu github deposuna sır koymak, ev anahtarlarınızı ön kapınıza bantlanmış bırakmak gibidir. Onları isteyen herkes onları bulmakta zorlanmayacaktır. Ancak, bir dış ağa sahip olmayan bir iç ağda bir anahtar deposu olarak hareket ederseniz, şifrelerinizi güvende tutma şansınız daha yüksektir. Bu daha çok anahtarlarınızı cebinizde tutmak gibi. Onları kaybetmek imkansız değil (örneğin, Azure şifrenizi vermenin eşdeğeri), ancak anahtarınızı kapınıza bantlamak veya maruz kalmanızı sınırlamak.


4

Ş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.


0

Git repo'daki gizli dosyaların asimetrik anahtarla şifrelenmesini sağlamak için git secretprojeyi ( http://git-secret.io/ ) dikkate almaya değer . Ortak anahtarlar da repoda, özel anahtar değil.

Bu yaklaşımın özellikleri:

  • yeni kullanıcının / makinenin güvenli dosyaların şifresini çözmesi gerektiğinde - genel gpg (gnu privacy guard aka pgp) anahtarını yayınlar / gönderir. Güvenli dosyaların şifresini zaten çözebilen kullanıcı yeni ek anahtarla yeniden şifreleyebilir - bundan sonra yeni kullanıcı güvenli dosyaların şifresini kendi özel anahtarıyla çözebilir.
  • açıkçası git deposuna kimlerin taahhütte bulunabileceğini / gönderebileceğini kontrol etmeniz gerekir. Aksi takdirde saldırgan kendi ortak anahtarını işleyebilir ve yetkilendirilmiş biri güvenli olan bu yeni ortak anahtarla güvenli dosyaları yeniden şifreleyene kadar bekleyebilir.
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.