Где поддерживать центральный репозиторий?

Какова лучшая отраслевая практика в отношении обеспечения доступа к исходному коду? Я думаю, что только SSL-соединения через Apache разрешены для нашего сервера через неясный порт, который не конфликтует ни с чем другим. Меня беспокоит хранение исходного кода на общедоступном сервере, то есть доступ не только через локальную сеть. Кроме того, этот сервер имеет несколько применений. Apache уже обслуживает некоторые другие внутренние сайты компании. Я хотел бы, чтобы каждый мог получить доступ к исходному коду из любого места (дома, в аэропорту и т. Д.), При условии, что они имеют правильные учетные данные. Предложения?

Если вы обеспокоены тем, что он находится на общедоступном сервере, но хотели бы получить доступ из любого места, вам следует подумать о том, чтобы ваши разработчики использовали VPN на основе клиента для удаленного входа в сеть для доступа к внутреннему серверу управления источниками.

Я не слишком уверен, почему люди думают, что подход VPN является лучшим. Это не обязательно более безопасно и предлагает только одно преимущество, о котором я могу подумать.

Например, известно, что PPTP имеет не совсем идеальную защиту, хотя я считаю, что она несколько улучшилась с момента ее появления ... поэтому будьте осторожны, какое VPN-решение вы используете. Я бы пошел с OpenVPN или IPSEC.

Тем не менее, вы не можете превзойти удобство SSL / TLS без VPN (читайте дальше). И чтобы сделать его еще более безопасным, вы можете сделать это только сертификатом.

Однако, если вы считаете, что можете предложить другие услуги, отличные от контроля источников, рассмотрите решение VPN, поскольку вы будете туннелировать другие службы поверх него.

Недостатком использования VPN является то, что ваш компьютер становится частью сети, в которую он подключается. Это также может быть преимуществом. Но если вы находитесь в миллионе миль от дома и сетевое соединение с домашней базой не слишком быстрое, то каждый раз, когда вы захотите выполнить код различий или проверки или выхода, вы можете обнаружить, что подключаетесь и отключаете VPN.

Я могу говорить из личного опыта, так как я являюсь разработчиком, и мне было очень больно делать это !!! В идеале оба варианта предпочтительнее.

Так что, если вы собираетесь просматривать веб-страницы и т. Д., Это может замедлить чтение новостей и т. Д. Но, по крайней мере, вы получаете безопасный доступ к электронной почте. Итак, подумайте, как вы будете использовать это в первую очередь ... Если бы я был вами, я бы подумал о реализации обоих.

На самом деле, мне нравится ваше предложение. Если вы сделаете свой репозиторий исходного кода доступным ТОЛЬКО через SSL / TLS, и убедитесь, что ваши разработчики не используют простые пароли (или, что еще лучше, используют сертификаты), тогда это должно быть так же безопасно, как и все остальное. ,

Вместо этого вы можете скрыть свой сервер в локальной сети и заставить разработчиков использовать VPN для получения доступа, но это просто означает, что ваши разработчики должны поместить свое имя пользователя / пароль (и / или сертификат) в другое поле для входа. Я бы рекомендовал не создавать точку входа в вашу сеть, последствия которой для безопасности могут быть не всегда очевидны, просто чтобы разрешить доступ к одной услуге. Если у вас уже есть настроенный и защищенный VPN для других целей, то, конечно, это не сложно, продолжайте и используйте его. В противном случае может быть проще и, следовательно, более безопасно сделать сам сервис непосредственно доступным через SSL / TLS.

Отраслевой стандарт, вероятно, зависит от вашей (или ваших клиентов) отрасли :-)

Практически вам нужно подумать, кому вы хотите предоставить доступ, и что они могут сделать. Некоторые люди, которым вы, возможно, захотите / должны получить доступ, не смогут справиться с гораздо большим, чем имя пользователя / пароль. Другие могут быть в состоянии разобраться с ssh, и закрытый ключ, при условии, что вы можете безопасно получить ключ к ним, неплох. Клиент TortoiseSVN может обрабатывать ssh + svn и поддерживает закрытые ключи с небольшим поворотом руки. Это было достаточно хорошо для моих целей.

VPN-туннель также является справедливым предложением, хотя во многих местах вы были бы рады предоставить внешним пользователям доступ только к вашему контролю над источниками, но не ко всей вашей сети!

Как и другие, я предпочитаю VPN. Альтернативой может быть SSH-туннель, который, как я полагаю, на практике является своего рода VPN.

Сделайте это только для внутреннего использования и внедрите решение VPN для удаленного пользователя. Дох-дубликат.

Если вам нужен доступ из любого места, вам нужен общедоступный сервер - это ясно.

На этом сервере вы хотите предоставить как можно меньше информации , желательно только Mercurial / Subversion и ничего больше. Это сделано для того, чтобы не допустить проникновения нарушения безопасности из системы контроля версий в остальную часть вашей компании. По этой причине я соглашусь с Мэттом, когда он говорит, что VPN может быть опасным: он предоставляет гораздо более широкий доступ, чем необходимо.

В Mercurial вы можете плотно заблокировать все, используя hg-sshдля ограничения команд, доступных клиентам, которые подключаются через SSH. Используя SSH, вы можете легко потребовать, чтобы клиенты использовали аутентификацию с открытым ключом вместо паролей. Это защищает ваш сервер от атак методом перебора.

Даже если ключ SSH скомпрометирован (возможно, он имел слабую парольную фразу и ноутбук, на котором он хранится, был украден), худший ущерб, который может нанести злоумышленник, - это добавить историю мусора в Mercurial. Используемый протокол по своей сути только для добавления, поэтому ничего нельзя удалить hg push.

Для HTTPS аутентификация выполняется интерфейсным веб-сервером . Это означает, что вы можете требовать сертификаты клиентского сайта, если хотите, и таким образом получить безопасность, как аутентификация с открытым ключом SSH выше.