Merkezi kaynak deposunu nerede muhafaza edebilirim?


10

Kaynak koduna erişimin sağlanması konusunda endüstrinin en iyi uygulaması nedir? SSL'nin yalnızca başka bir şeyle çakışmayan, belirsiz bir bağlantı noktasında sunucumuza izin verilen apache üzerinden bağlantılar olduğunu düşünüyorum. Beni rahatsız eden şey kaynak kodunu halka açık bir sunucuda saklamak, yani sadece LAN üzerinden erişilebilir değil. Ayrıca, bu sunucunun çeşitli kullanımları vardır. Apache başka şirket içi web sitelerine de hizmet veriyor. Herkesin, doğru kimlik bilgilerine sahip oldukları sürece kaynak koduna her yerden (evler, havaalanı, ne olursa olsun) erişmesini istiyorum. Öneriler?

Yanıtlar:


13

Herkese açık bir sunucuda olmaktan endişeleniyorsanız, ancak her yerden erişim istiyorsanız, geliştiricilerinizin dahili bir kaynak kontrol sunucusuna erişmek için ağınıza uzaktan giriş yapmak için istemci tabanlı bir VPN kullanmasını düşünmelisiniz.


1
Her ikisinin de "herkese açık" olması gerektiği düşünüldüğünde, bir VPN'in neden SSL / TLS tabanlı bir sunucudan daha güvenli olduğuna inandığınızı açıklar mısınız? VPN'ler SSL / TLS için familar şifreleme kullanır. VPN'yi hackleyebilseydiniz, her şeyi elde edersiniz.
Matt

1
@Matt Deposunu halka açık bir segmentte bulundurması için bir neden yoksa, neden oraya koymalısınız? Ayrıca, bir VPN'in geliştiricileri için başka avantajları olabilir. Ayrıca hiçbir yerde "VPN SSL /
TLS'den

1
Doğru. Myr ifadesinde güvenliğin ima edildiğini hissettim. Belki de bunu niteleyebilirsiniz: "Eğer halka açık bir sunucuda olmaktan endişe ediyorsanız"
Matt

Kanımca, bir VPN'in arkasında özel sunuculara / hizmetlere sahip olmak katmanlı yaklaşımın bir parçasıdır. Kaynağı herkese açık hale getirebilecek yapılandırma hatalarına karşı koruma sağlar. Gerekli değil, ama akıllı.
Martijn Heemels

4

İnsanların neden VPN yaklaşımının en iyi olduğunu düşündüğünden emin değilim. Mutlaka daha güvenli değil ve sadece aklıma gelen bir avantaj sunuyor.

Örneğin PPTP'nin ideal güvenlikten daha az olduğu biliniyor, ancak ilk piyasaya sürüldüğünden beri biraz iyileştiğine inanıyorum ... bu yüzden hangi VPN çözümünü kullandığınıza dikkat edin. OpenVPN veya IPSEC ile giderdim.

Bununla birlikte, VPN olmadan SSL / TLS'nin rahatlığını yenemezsiniz (aşağıyı okuyun). Ve daha da güvenli hale getirmek için sadece sertifika yapabilirsiniz.

Bununla birlikte, kaynak kontrolü dışında başka hizmetler de sunabileceğinizi düşünüyorsanız, bir VPN çözümünü düşünün, çünkü diğer hizmetleri tünellendireceksiniz.

VPN kullanmanın dezavantajı, bilgisayarınızın etkili bir şekilde bağlandığı ağın bir parçası haline gelmesidir. Bu da bir avantaj olabilir. Ancak, evden bir milyon mil uzaktaysanız ve ana üsse ağ bağlantısı çok hızlı değilse, fark ya da giriş veya çıkış kodu yapmak istediğinizde kendinizi VPN'yi bağlarken ve bağlantısını keserken bulabilirsiniz.

Ben burada bir geliştirici olarak kişisel deneyim konuşabilir ve bunu yapmak için serseri gerçek bir acı oldu !!! İdeal olarak, her iki seçenek de tercih edilir.

Yani web vb tarama olacak eğer o zaman haber vb okuma oldukça yavaş yapabilir. Ancak en azından e-postaya güvenli erişim elde edersiniz. İlk önce nasıl kullanacağınızı düşünün ... Eğer siz olsaydım ikisini de uygulamayı düşünürdüm.


3

Aslında önerinizi beğeniyorum. Kaynak kodu deponuza YALNIZCA SSL / TLS aracılığıyla erişilebilir hale getirirseniz ve geliştiricilerinizin kaba kuvvetli parolaları (veya daha iyisi sertifikaları kullanmasını) kullanmadığından emin olursanız, bu her şey kadar güvenli olmalıdır .

Bunun yerine, sunucunuzu LAN'ınızın içinde gizleyebilir ve geliştiricileri erişim elde etmek için bir VPN kullanmaya zorlayabilirsiniz, ancak bu sadece geliştiricilerin kullanıcı adlarını / şifrelerini (ve / veya sertifikalarını) farklı bir giriş kutusuna koymaları gerektiği anlamına gelir. Ağınızda, yalnızca tek bir hizmete erişime izin vermek için güvenlik sonuçları her zaman belirgin olmayabilecek bir giriş noktası oluşturmamayı öneriyorum. Daha önce başka kullanımlar için yapılandırılmış ve güvenli bir şekilde VPN'niz varsa, emin olun, beyinsizdir, devam edin ve kullanın. Aksi takdirde, hizmetin kendisini SSL / TLS aracılığıyla doğrudan kullanılabilir hale getirmek daha basit ve dolayısıyla daha güvenli olabilir.


3

Endüstri standardı muhtemelen sizin (veya müşterilerinizin) endüstrisinin ne olduğuna bağlıdır :-)

Pratik olarak, kime erişim vermek istediğinizi ve nelerin üstesinden gelebileceğini düşünmeniz gerekir. Erişmek isteyebileceğiniz / ihtiyaç duyabileceğiniz bazı kişiler, bir kullanıcı adı / paroladan çok daha fazlasıyla başa çıkamayacaktır. Diğerleri başlarını ssh etrafında alabilir ve anahtarı güvenli bir şekilde alabilmeniz koşuluyla özel bir anahtar kötü değildir. TortoiseSVN istemcisi ssh + svn'yi işleyebilir ve biraz kol bükümü ile özel anahtarları destekler. Bu benim amacım için yeterince iyi oldu.

Bir VPN tüneli de adil bir öneridir, ancak birçok yerde harici insanlara sadece kaynak kontrolünüze erişim sağlamaktan mutluluk duyarsınız, ancak tüm ağınıza değil!


2

Diğerleri gibi ben de bir VPN tercih ederim. Bir alternatif SSH tüneli olabilir, ki pratikte bir çeşit VPN zaten.


0

Yalnızca dahili hale getirin ve uzak kullanıcı VPN çözümü uygulayın. / Doh- çoğalt.


0

Herhangi bir yerden erişmek istiyorsanız, halka açık bir sunucuya ihtiyacınız var - bu çok açık.

Bu sunucuda, olabildiğince az , tercihen sadece Mercurial / Subversion ve başka bir şey ortaya çıkarmak istiyorsunuz . Bu, güvenlik ihlallerinin kaynak kontrolünden şirketinizin geri kalanına yayılmasını önlemek içindir. Bu nedenle, bir VPN'in tehlikeli olabileceğini söylediğinde Matt ile aynı fikirdeyim : gerekenden çok daha geniş erişim sağlıyor.

Mercurial için, hg-sshSSH üzerinden bağlanan istemcilerin kullanabileceği komutları kısıtlamak için kullanarak öğeleri sıkıca kilitleyebilirsiniz . SSH'yi kullanarak, istemcilerin şifreler yerine ortak anahtar kimlik doğrulaması kullanmasını kolayca isteyebilirsiniz . Bu, sunucunuzu kaba kuvvetli giriş saldırılarına karşı korur.

Bir SSH anahtarı ele geçirilmiş olsa bile (belki de zayıf bir parolayı vardı ve depolayan dizüstü bilgisayar çalındı), o zaman bir saldırganın yapabileceği en kötü hasar Mercurial'a çöp geçmişi eklemektir. Kullanılan protokol doğası gereği yalnızca ektedir, bu nedenle hiçbir şey silinemez hg push.

HTTPS için, kimlik doğrulama ön uç web sunucusu tarafından yapılır . Bu, isterseniz istemci sitesi sertifikalarına gereksinim duyabileceğiniz ve yukarıdaki SSH ortak anahtar kimlik doğrulaması gibi güvenlik alabileceğiniz anlamına gelir.

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.