Sıfır bilgi kodu barındırma [kapalı]

Çevrimiçi hizmet sağlayıcılar tarafından depolanan verilerin yaygın hükümet izlemesi ile ilgili son vahiyler ışığında, sıfır bilgi hizmetleri şu anda tüm öfkedir.

Sıfır bilgi hizmeti, tüm verilerin sunucuda depolanmayan bir anahtarla şifrelenmiş olarak depolandığı bir hizmettir. Şifreleme ve şifre çözme tamamen istemci tarafında gerçekleşir ve sunucu hiçbir zaman düz metin verilerini veya anahtarı görmez. Sonuç olarak, servis sağlayıcısı, şifresini çözemez ve verileri, istese de üçüncü taraflara veremez.

Bir örnek vermek gerekirse: SpiderOak , Dropbox'ın sıfır bilgi sürümü olarak görülebilir.

Programcılar olarak, belirli bir çevrimiçi servis sağlayıcı sınıfına - kodumuz - en hassas verilerimizin bir kısmına çok güveniyoruz ve güveniyoruz: kod barındırma sağlayıcıları (Bitbucket, Assembla, vb.). Elbette burada özel depolardan söz ediyorum - sıfır bilgi kavramı kamu depoları için bir anlam ifade etmiyor.

Benim sorularım:

1. Sıfır bilgi kodlu bir barındırma hizmeti oluşturmanın teknolojik engelleri var mı? Örneğin, SVN, Mercurial veya Git gibi popüler sürüm kontrol sistemleri tarafından kullanılan ve istemciyle sunucu arasında iletilen verilerin şifreli olduğu bir şemanın uygulanmasını zorlaştıracak (veya imkansız) ağ protokolleriyle ilgili bir şey var mı? Sunucunun bilmediği bir anahtar?

2. Bugün var olan herhangi bir sıfır bilgi kodu barındırma hizmeti var mı?

Her satırı ayrı ayrı şifreleyebilirsiniz. Dosya adlarınızı ve yaklaşık satır uzunluklarını ve satırların değiştiği satır numaralarını sızdırabilirseniz, şöyle bir şey kullanabilirsiniz:

https://github.com/ysangkok/line-encryptor

Her satır ayrı olarak şifrelendiğinden (ancak aynı anahtarla), yüklenen değişiklikler (genellikle olduğu gibi) yalnızca ilgili satırları içerecektir.

Halihazırda yeterince uygun değilse, biri düz metin, biri şifreli metin olmak üzere iki Git deposu oluşturabilirsiniz. Düz metin deposunda (yerel olan) işlem yaptığınızda, bir işlem kancası fark alabilir ve onu şifreli metin deposuna uygulayacak olan yukarıda belirtilen satır şifreleyiciden geçirebilir. Şifreli metin deposu değişiklikleri taahhüt edildi ve yüklendi.

Yukarıdaki satır şifreleyici SCM agnostiktir, ancak birleştirilmiş fark dosyalarını (düz metin) okuyabilir ve değişiklikleri şifreleyip şifreli metne uygulayabilir. Bu, size birleşik bir fark yaratacak (Git gibi) herhangi bir SCM'de kullanılabilir olmasını sağlar.

Herhangi bir engel olduğunu sanmıyorum - SVN'yi düşünün, depolama için sunucuya gönderilenlerin, kodunuzun önceki ve geçerli sürümleri arasındaki delta olduğunu - yani 1 satırı değiştirirsiniz, bu satır sunucuya gönderilir. Sunucu daha sonra 'kör bir şekilde', verileri kontrol etmeden saklar. Delta'yı şifrelediyseniz ve bunun yerine gönderdiyseniz, sunucu üzerinde hiçbir etkisi olmazdı, aslında sunucuyu hiçbir şekilde değiştirmeniz gerekmez.

MIME türü gibi kolayca şifrelenemeyen meta veri özellikleri gibi önemli olabilecek başka bitler de olabilir; görüntülemek için müşteri. Dizin yapısının görünüp görünmeyeceğinden emin değilim, SVN'nin dizinleri saklama biçimi nedeniyle görünmeyeceğini düşünüyorum, ancak bunun yanlış olduğunu düşünüyorum. İçeriği güvenli ise, bu sizin için önemli olmayabilir.

Bu, çeşitli kod görüntüleme özelliklerine sahip bir web sitenize sahip olamayacağınız, sunucu tarafı depo tarayıcısı veya günlük görüntüleyicisine sahip olamayacağınız anlamına gelir. Kod farkı yok, çevrimiçi kod inceleme aracı yok.

Bunun gibi bir şey zaten var, bir noktaya kadar Mozy, verilerinizi özel anahtarınızla şifrelenmiş olarak saklar (kendi kodunu kullanabilirsiniz, ve "kendi anahtarınızı kaybederseniz çok kötü, verilerinizi geri yükleyemezsek," siz ", ancak bu genel kullanıcıyı daha iyi hedefliyor). Mozy, dosyalarınızın geçmişini de saklar, böylece önceki sürümleri alabilirsiniz. Düştüğü yerde yükleme düzenli olarak yapılır; istediğiniz zaman kontrol edilmez ve depolama alanınız tükendiğinde eski sürümleri attığına inanıyorum. Ancak buradaki kavram, mevcut sistemlerini kullanarak güvenli kaynak kontrolü sağlamak için onu değiştirebildi.

Bunlardan birini yapmaktan nefret ediyorum 'bu, sorunuza cevap vermeyecek' cevapları .. ama ..

Bu endişeleri gidermek için iki hazır çözüm düşünebilirim.

1. Kendi başınıza özel bir Git sunucusu barındırın. Ardından bu sunucuyu ekip üyelerinize erişim izni verdiğiniz bir VPN'ye yerleştirin. Sunucu ile olan ve sunucudan yapılan tüm iletişim şifrelenir ve tabii ki sunucuyu işletim sistemi düzeyinde şifreleyebilirsiniz.

2. BitSync de numarayı yapmalı. Her şey şifreli olacak ve her yerden erişilebilecek devasa bir ağda. Aslında tüm bu BitCoin / BitMessage / BitSync teknolojisinin gerçekten iyi bir uygulaması olabilir.

Son olarak, https://security.stackexchange.com/ adresindeki kişiler biraz daha fazla kavrayışa sahip olabilir.

Anladığım kadarıyla, git pullçalışma şekli, sunucunun istediğiniz tüm nesneleri içeren ancak şu anda sahip olmayan bir paket dosyası göndermesidir. Ve bunun için tam tersi git push.

Doğrudan böyle yapamayacağınızı düşünüyorum (çünkü bu, sunucunun nesneleri anlaması gerektiği anlamına gelir). Bunun yerine, sunucunun bir dizi şifreli paket dosyasıyla çalışmasına izin verebilirsiniz.

Bunu yapmak için pull, son pullşifresinden beri eklenen tüm paket dosyalarını indir , şifrelerini çöz ve git deponuza uygula. Bunu yapmak için pushönce yapmanız gerekir pull, böylece sunucunun durumunu bilirsiniz. Herhangi bir çakışma yoksa, değişikliklerinizle bir paket dosyası yaratır, şifreler ve yüklersiniz.

Bu yaklaşımla, oldukça verimsiz olan çok sayıda minik paket dosyası elde edersiniz. Bunu düzeltmek için, bir dizi paket dosyası indirebilir, şifresini çözebilir, bir paket dosyasında birleştirebilir, şifreleyebilir ve sunucuya yükleyebilir ve bu dizinin yerine geçerek işaretleyebilirsiniz.