Каковы лучшие отраслевые практики в отношении защиты доступа к исходному коду? Я думаю, что SSL-соединения только через apache разрешены к нашему серверу через неясный порт, который не конфликтует ни с чем другим. Меня беспокоит хранение исходного кода на общедоступном сервере, то есть доступном не только через локальную сеть. Более того, у этого сервера есть несколько применений. Apache уже обслуживает некоторые другие внутренние веб-сайты компании. Я хотел бы, чтобы каждый мог получить доступ к исходному коду из любого места (дома, в аэропорту и т. Д.), Если у них есть правильные учетные данные. Предложения?
Если вас беспокоит, что он находится на общедоступном сервере, но вам нужен доступ из любого места, вам следует подумать о том, чтобы ваши разработчики использовали клиентскую VPN для удаленного входа в вашу сеть для доступа к внутреннему серверу управления версиями.
Я не совсем уверен, почему люди думают, что подход VPN является лучшим. Это не обязательно более безопасно и дает только одно преимущество, о котором я могу думать.
Например, известно, что PPTP имеет далеко не идеальную безопасность, хотя я считаю, что он несколько улучшился с момента первого появления ... поэтому будьте осторожны, какое решение VPN вы используете. Я бы выбрал OpenVPN или IPSEC.
Однако вы не сможете превзойти удобство SSL / TLS без VPN (читайте дальше). А для большей безопасности вы можете сделать его только сертификатом.
Однако, если вы думаете, что можете предложить другие услуги, помимо управления версиями, рассмотрите вариант решения VPN, потому что вы будете туннелировать через него другие службы.
Недостатком использования VPN является то, что ваш компьютер фактически становится частью сети, к которой он подключается. Это тоже может быть преимуществом. Но если вы находитесь в миллионе миль от дома и сетевое соединение с домашней базой не слишком быстрое, то каждый раз, когда вы хотите выполнить сравнение или проверить код, вы можете обнаружить, что подключаетесь и отключаете VPN.
Я могу говорить здесь по личному опыту, так как я разработчик, и делать это было настоящей головной болью !!! В идеале предпочтительны оба варианта.
Поэтому, если вы собираетесь просматривать веб-страницы и т. Д., Это может замедлить чтение новостей и т. Д. Но, по крайней мере, вы получаете безопасный доступ к электронной почте. Так что сначала подумайте, как вы будете его использовать ... Если бы я был вами, я бы подумал о реализации обоих.
Отраслевой стандарт, вероятно, зависит от вашей (или ваших клиентов) отрасли :-)
На практике вам нужно подумать, кому вы хотите предоставить доступ и с чем они могут справиться. Некоторые люди, к которым вы, возможно, захотите / должны получить доступ, не смогут справиться с гораздо большим, чем просто имя пользователя / пароль. Другие могут разобраться в ssh, и закрытый ключ, который при условии, что вы можете безопасно получить ключ к ним, неплохо. Клиент TortoiseSVN может обрабатывать ssh + svn и поддерживает закрытые ключи с небольшим поворотом рук. Этого было достаточно для моих целей.
VPN-туннель также является разумным предложением, хотя во многих местах вы были бы счастливы предоставить внешним людям доступ только к вашей системе управления версиями, но не ко всей вашей сети!
На самом деле, мне нравится ваше предложение. Если вы сделаете свой репозиторий исходного кода доступным ТОЛЬКО через SSL / TLS и убедитесь, что ваши разработчики не используют простые парольные фразы (или еще лучше, используют сертификаты), тогда это должно быть так же безопасно, как и все остальное. .
Вместо этого вы можете скрыть свой сервер в своей локальной сети и заставить разработчиков использовать VPN для доступа, но это просто означает, что вашим разработчикам нужно указать свое имя пользователя / пароль (и / или сертификат) в другом поле входа. Я бы не рекомендовал создавать точку входа в вашу сеть, последствия которой для безопасности не всегда очевидны, просто чтобы разрешить доступ к одной услуге. Если у вас уже есть VPN, настроенный и защищенный для других целей, тогда, конечно, это не проблема, используйте его. В противном случае может быть проще и, следовательно, более безопасно сделать сам сервис напрямую доступным через SSL / TLS.
Как и другие, я предпочитаю VPN. Альтернативой может быть туннель SSH, который, как я полагаю, в практическом плане в любом случае является разновидностью VPN.
Сделайте его внутренним и внедрите решение VPN для удаленных пользователей. / Дох - дубликат.
Если вам нужен доступ из любого места, вам нужен общедоступный сервер - это ясно.
На этом сервере вы хотите выставлять как можно меньше, желательно только Mercurial / Subversion и ничего больше. Это сделано для предотвращения распространения нарушения безопасности из системы контроля версий на остальную часть вашей компании. По этой причине я согласен с Мэттом когда он говорит, что VPN может быть опасным: он дает гораздо более широкий доступ, чем нужно.
Что касается Mercurial, вы можете жестко заблокировать вещи, используя hg-ssh чтобы ограничить команды, доступные клиентам, которые подключаются по SSH. Используя SSH, вы можете легко потребовать, чтобы клиенты использовали аутентификация с открытым ключом вместо паролей. Это защищает ваш сервер от атак грубой силы при входе в систему.
Даже если ключ SSH скомпрометирован (возможно, у него была слабая парольная фраза, и ноутбук, на котором он хранится, был украден), худший урон, который может нанести злоумышленник, - это добавить историю мусора в Mercurial. Используемый протокол изначально предназначен только для добавления, поэтому ничего нельзя удалить с помощью hg push.
Для HTTPS аутентификация выполняется интерфейсным веб-сервером. Это означает, что вы можете потребовать сертификаты клиент-сайт, если хотите, и таким образом получить безопасность, такую как аутентификация с открытым ключом SSH, описанная выше.