Безопасность централизованного и распределенного контроля версий

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

Проблема

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

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

Вопрос (ы)

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

Мои мысли

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

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

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

Ответ 1

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

Существует множество проблем безопасности; независимо от того, являются ли они проблемой, зависит от вашей настройки:

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

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

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

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