Централизованная и распределенная система контроля версий

Question

Когда моя компания начинает изучать переход от централизованных инструментов контроля версий (CVS, SVN, Perforce и множества других) к предложениям группам распределенных инструментов контроля версий (в нашем случае, Mercurial), я столкнулся с проблемой:

Проблема

Менеджер выразил обеспокоенность тем, что распределенное управление версиями может быть не таким безопасным, как наши параметры CVCS, поскольку история репо хранится локально на компьютере разработчика.

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

Вопрос (ы)

• Действительно ли распределенная система контроля версий вводит новые проблемы безопасности для проектов?
• Легче ли злонамеренно украсть код?
• Представляет ли полная история дополнительную угрозу, которой нет в последней версии кода?

Мои мысли

Я полагаю, что это может быть ошибочной мыслью о том, что централизованная модель более безопасна, потому что история кажется более безопасной, поскольку она отключена на собственной коробке. Учитывая, что пользователи с равным доступом для чтения к централизованному репо могут выборочно извлекать снимки проекта при любой ключевой редакции, я не уверен, что модель DVCS делает все это проще. Кроме того, большинство инструментов CVCS позволяют извлечь всю историю репо с помощью одной команды, чтобы вы могли импортировать их в другие инструменты.

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

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

Answer 1

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

Answer 2

• Вы правы в том, что управление распределенной версией на самом деле не представляет никаких новых проблем безопасности, поскольку разработчик уже имеет доступ к коду в обоих случаях.Я могу только думать, что, поскольку с GIT работать в автономном режиме и вне офиса проще, разработчики могут испытать больше соблазна сделать это, чем централизованно.Я бы настаивал на принудительном шифровании на всех корпоративных ноутбуках с кодом
• не так уж и просто, все равно.Если вы включите журналы, то при доступе к коду у вас будет та же информация.
• Лично я так не думаю.Это может представлять мыслительный процесс, ведущий к определенным решениям, но не обязательно к большему.

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

Answer 3

DVCS обеспечивает различные средства защиты от несанкционированного письма. Вот почему он популярен среди команд с открытым исходным кодом. У него есть несколько разочаровывающих ограничений для контроля чтения. Opensource команды не заботятся об этом.

Первая проблема заключается в том, что большинство DVCS поддерживают множество копий с полным исходным кодом. Типичная гранулярность - полное репо. Это может включать в себя множество ненужных веток и даже целые другие проекты, помимо истории (наряду с комментариями с возможностью поиска, которые могут сделать код еще более полезным для злоумышленника). CVCS рекомендует разработчикам как можно меньше копировать на свой рабочий стол, поскольку чем меньше копий, тем быстрее он работает. Чем меньше вы надеваете мобильные устройства, тем легче их защитить.

Когда DVCS внедряется со многими устройствами, выступающими в качестве серверов, гораздо эффективнее реализовать эффективную сетевую безопасность. Атака локального рабочего пространства CVCS требует от злоумышленника доступа к файловой системе. Атака узла DVCS обычно требует нападения на сам DVCS на любом устройстве, на котором размещена информация (и помните: люди, которые поддерживают большинство DVCS, являются разработчиками с открытым исходным кодом; их почти не заботит контроль над чтением). Чем больше устройств размещают репозитории, тем больше вероятность того, что пользователи установят анонимный доступ для чтения (что опять-таки поощряется DVCS из-за его корней с открытым исходным кодом). Это значительно упрощает работу злоумышленника, который выполняет случайные зачистки.

CVCS, основанные на URL-адресах (например, subversion), открывают возможность для довольно детального контроля доступа, такого как доступ для каждой ветви. DVCS имеет тенденцию бороться с этим видом контроля доступа.

Я знаю разработчиков, подобных DVCS, но нет способа защитить его так же эффективно, как CVCS. Большинство сред делают ужасную работу по защите своих CVCS, и если это так, то не имеет значения, какой вы используете. Но если вы серьезно относитесь к управлению доступом, вы можете иметь гораздо больший контроль с CVCS как частью более широкой инфраструктуры с минимальными привилегиями.

Многие могут утверждать, что нет причин защищать исходный код. Это нормально, и люди могут спорить об этом. Но если вы собираетесь защищать свой исходный код, лучшая реализация - не копировать исходный код на случайные ноутбуки (которые очень трудно надежно защитить), а скорее попросить разработчиков смонтировать его с центрального сервера. CVCS хорошо работает таким образом. DVCS не имеет смысла, если вы собираетесь хранить его на одном сервере таким образом. Если вы собираетесь копировать файлы на мобильные устройства, убедитесь, что вы копируете как можно меньше. Это противоположность DVCS.

Answer 4

Есть куча проблем "безопасности"; являются ли они проблемой, зависит от вашей настройки:

• Там больше данных, что означает, что условная «поверхность атаки» может быть больше (это зависит от того, как вы считаете).
  • Но сколько данных проверяет «типичный» разработчик? Возможно, вы захотите использовать редкие проверки в svn, но ленивые люди и некоторые инструменты с графическим интерфейсом не поддерживают это, поэтому они все равно будут проверять весь ваш код. Пользователи Git могут с большей вероятностью использовать несколько репо. Это зависит от вас.
• Аутентификация / контроль доступа могут быть лучше (и это может быть хуже!). Это в значительной степени функция VCS, а не "D" или "C". svn:// является открытым текстом.
• Является ли удаление файлов приоритетом, и насколько легко это сделать? Случайное принятие конфиденциального файла более болезненно делать в git, если это произошло в далеком прошлом (но люди могут с большей вероятностью это заметить).
• Вы действительно собираетесь заметить, что злонамеренный пользователь тянет всю историю, а не просто делает проверку? Это зависит от того, насколько велик ваш репозиторий и каковы ваши ветви. Для полной проверки SVN легко занять больше места, чем сам репозиторий из-за ветвей.
• Как правило, история изменений - это не то, что вы хотите раздавать бесплатно (даже людям с лицензией на исходный код), но насколько это ценно? Возможно, у вас есть сверхсекретные методологии проектирования или конфиденциальная информация в ваших сообщениях о коммите, но это кажется маловероятным.

И, наконец, экономика безопасности:

• Сколько стоит дополнительная безопасность?
• Сколько стоит повышение производительности?
• Сколько стоит забота о ваших разработчиках?

(IIRC оказывается, что пользователи должны игнорировать рекомендации по безопасности, поскольку ожидаемая стоимость превышает ожидаемую выгоду & mdash; это особенно верно для таких вещей, как сертификаты, срок действия которых истек вчера. Сколько стоит проверка адресной строки каждый раз, когда вы вводите пароль? Как часто вы ловите попытку фишинга? Какова цена за фальсифицированную попытку фишинга? Какова стоимость одного успешного фишинга?)