Насколько велика угроза безопасности при проверке проекта svn прямо на производственной площадке?

Question

Не то чтобы я делал что-то подобное, но мне интересно, насколько плоха такая практика.

Answer 1

Нет, если ваш сервер запрещает доступ ко всем каталогам .svn из Интернета.

Answer 2

Я не могу обязательно комментировать связанные с безопасностью риски, но это может поставить вас в ситуацию, когда непроверенный / не полностью протестированный код окажется в производственной среде. Если вы планируете использовать svn в качестве метода для распределения источника в различных средах (dev, тестирования, производства и т. Д.), Я бы предложил вам использовать следующий подход:

Имейте участок дерева, который остается стабильным (скорее всего, ветвь), и возложите на него ответственность как на привратника этой ветки. Все коммиты в 'stable' должны будут проходить через них, и они будут ответственны за то, чтобы убедиться, что ничего не проходит без проверки. Эта позиция может меняться еженедельно или ежемесячно, если никто не хочет делать это очень долго.

Также, если вы просто хотите периодически делать дамп adhoc из subversion в производство, вы можете использовать команду 'svn export'.

Наконец, я предполагаю, что это веб-разработка, если все, что вам нужно сделать, это оформить заказ для настройки производственной среды. В этом случае убедитесь, что пользователь, под которым работает веб-сервер, не имеет доступа для чтения в каталогах '.svn', в которых хранятся метаданные subversion.

Answer 3

Уже есть несколько отличных ответов. Но позвольте мне попытаться количественно оценить риски.

Предположим, что 2 месяца назад риск трояна был достаточно мал, чтобы быть приемлемым. Приближается DNS-атака Каминского и риск того, что троянец просто перешел от теоретической активной атаки к чему-то в сфере «сценаристов» Это связано с тем, что большинство общедоступных проектов Subversion либо используют http, либо, если https, не используют сертификат с полной цепочкой сертификатов. Тогда все, что нужно сделать злоумышленнику, - это отравить DNS и клонировать сервер SVN с помощью собственного трояна.

Answer 4

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

Например, Capistrano (решение для автоматического развертывания рельсов) построено на проверке кода из SVN на ваших производственных серверах.

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

1. Раскрытие вашего svn репо в Интернете без защиты паролем - не делайте этого!

2. Предоставление вашего svn репо с использованием http вместо https, чтобы люди, отслеживающие ваш трафик, могли получить ваши пароли - опять же, не делайте этого! Просто запустите его через https.

3. Проверка вашего кода с использованием учетной записи с доступом SVN для чтения / записи. Лично я не стал бы беспокоиться об этом последнем шаге, так как если они скомпрометируют ваш рабочий сервер, у вас возникнут большие проблемы, и вы можете легко откатить любые изменения, которые они могут попытаться внести в SVN. Если бы вы были чрезвычайно параноиком, вы могли бы просто создать svn-аккаунт только для чтения для производственных проверок.

4. Проверка вашей магистрали на работу - это проблема, только если вы работаете с нестабильной магистралью, вместо этого вы можете просто проверить свои стабильные ветки / теги для развертывания.

Answer 5

Я считаю использование SVN очень удобным и надежным. У нас есть политика поддержания стабильности магистрали и внесения некритических изменений в ветвях, которые позже объединяются в магистраль незадолго до даты выпуска.

Это делает выпуск настолько же простым, как выполнение 'svn up' для небольших / менее сложных проектов. Упрощение развертывания упрощает не-разработчикам (системному администратору, поддержке по вызову и т. Д.) Быстрое восстановление проблемных изменений в случае, если соответствующий разработчик недоступен. В случае проблем с новым выпуском, это просто вопрос отката к последней известной стабильной копии.

Мое единственное реальное беспокойство было бы видимостью метаданных SVN. Убедитесь, что вы настроили свой веб-сервер так, чтобы запретить доступ к каталогам .svn (и всем файлам, содержащимся в них). Вы можете использовать экспорт SVN или удалить метаданные SVN как часть вашего процесса выпуска: найти. -имя .svn -print0 | xargs -0 rm -rf

То, что вы не хотите, - это кто-то, кто просматривает сайт www.example.com/.svn/entries, чтобы показать ваш репозиторий исходного кода, имена пользователей и файлы. Это особенно плохо, если вы сделали глупые вещи, такие как «passwords.conf», которые могут быть доступны для чтения пользователям (в зависимости от конфигурации сервера), конечно, это не совсем ошибка SVN. Как упоминалось в других ответах, вы также не хотите использовать HTTP.

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

Answer 6

Мне не обязательно нравится извлекать репозиторий непосредственно для развертывания. В частности, вам нужен каждый отдельный файл (например, тестовые сценарии), развернутый в рабочей среде? Кроме того, вы будете когда-нибудь в будущем иметь какой-либо сгенерированный код? Вероятно, лучше иметь систему сборки, которая собирает дистрибутив для развертывания.

Однако вместо любого из этих решений обязательно запишите ревизию репозитория, который вы синхронизируете. Таким образом, можно воспроизвести синхронизацию, и если в работе появляется ошибка, которую вы не можете воспроизвести, вы можете синхронизировать свой локальный репозиторий обратно в состояние, в котором оно совместимо с производством.

Answer 7

Вот как бы я это сделал:

Предположения:

• Проект в одной корневой папке ( projectroot )
• Все файлы под управлением версией

Steps

1 Убедитесь, что есть тег для «новой» рабочей версии
2 Проверьте или экспортируйте этот тег в папку projectroot .new
3 Остановите службу
4 Переименуйте projectroot .old << <em>projectroot << <em>projectroot .new
5 Перезапустите сервис
6 Если вам нужно отступить, повторите шаг 4

Рассуждения

Это делается для того, чтобы фактическая реализация и резервные шаги были как можно более простыми. Вы могли бы просто использовать svn-переключатель, но любые проблемы при откате могут привести к поломке системы.

Очевидно, что это самый простой случай - нет миграции данных, нет неверсионных файлов конфигурации и т. Д .; но я думаю, что ключ в построении дерева копий, а затем обмене, чтобы дать вам чистое четкое переключение и запасной вариант.

Answer 8

Если мы говорим о стабильности приложения (или кода), всегда существует риск при развертывании.

Но кроме этого, какова угроза безопасности, если вы можете использовать https вместо http. Или вы даже используете шлюз SSH.

Answer 9

Возможно, безопаснее, чем копия с тестового сервера, по крайней мере, вы уверены, что получаете правильную версию всех файлов и все файлы копируются.

Answer 10

Хорошо, если этот код, который вы проверяете, является базовым (стабильным), я не думаю, что это большая проблема.

Но вы, конечно, должны пометить код, чтобы вы знали позже, что вы там поместили.