Защита кода от собственных разработчиков [закрыто]

первый подход состоит в том, чтобы заставить программистов знать только интерфейсы других компонентов, так что каждый может украсть только небольшую часть всего программного обеспечения. Такой подход можно позаимствовать у обувного производства. Одна транснациональная корпорация, чтобы предотвратить воровство работников, устроила свои фабрики так, чтобы каждая фабрика производила только левую или только правую обувь. Вы можете сделать то же самое с вашим кодом: некоторые программисты пишут строки только с нечетными числами,а другие-с четными числа; при условии, что они не могут видеть работу друг друга! Это иногда называют "парное программирование".

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

чтобы ваши программисты не воровали, вы может нанести им вред, как только они закончат программное обеспечение. Метод зарекомендовал себя как наиболее эффективный и применялся на протяжении веков. Например, у русского царя Ивана Грозного горели глаза архитектора, который спроектировал красивую церковь на Красной площади, поэтому спроектированная остается самой красивой когда-либо. Вы можете сделать что-то подобное со своим архитектором. Я слышал, последняя Visual Studio содержит некоторые функции...

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

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

Как защитить электростанцию от саботажа со стороны сотрудника? Как помешать боксеру бросить бой? Как предотвратить распространение триппера в борделе?

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

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

Если это действительно необходимо, вы можете разделить приложение на подзапросы. Каждая команда работает в одном приложении и видит все остальные как "черные ящики". Может быть, SOA помогает здесь.

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

файл для этого находится под conf\authz Вот пример

[aliases]
# joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average

[groups]
# harry_and_sally = harry,sally
# harry_sally_and_joe = harry,sally,&joe

[/
# [/foo/bar]
# harry = rw
# &joe = r
# * =

# [repository:/baz/fuz]
# @harry_and_sally = rw
# * = r

некоторые документы можно найти здесь

подТВ-каталог-контроль доступа'

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

но со всеми этими мерами безопасности шансы ваши разработчики будут ненавидеть работать с вами и бросить свою работу

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

имейте в виду, что декомпиляция фреймворков, работающих против IL, таких как .NET, относительно проста, поэтому предотвращение доступа к файлам кода не обязательно является серебряной пулей для защиты IP.

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

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

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

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

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

разработка программного обеспечения в модулях.

есть один общий модуль, который содержит объекты, которые проходят вперед и назад, и классы утилит, которые действуют на эти объекты.

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

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

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