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

Question

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

Какие еще подходы, помимо этого чисто юридического, существуют для защиты программного кода от людей, которые его разрабатывают?Существуют ли они вообще?Имеет ли это смысл на практике?

Может быть, например, командная версия Visual Studio уже содержит некоторые функции, связанные с этой проблемой (например, уровни доступа к частям кода, в зависимости от роли в команде разработчиков или что-то в этом роде)?

Ссылка по теме:

Как гласит статистика, в среднем программисты, как правило, меняют свою работу каждые три-четыре года.

Answer 1

Постарайтесь создать команду, которой вы можете доверять.

Answer 2

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

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

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

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Но при всех этих мерах безопасности есть вероятность, что вашим разработчикам не понравится работать с вами и они уволятся

Answer 7

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

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

Под 'Контроль доступа к каждому каталогу'

Answer 8

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

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

Answer 9

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

Answer 10

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

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

Answer 11

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

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

Answer 12

Разрабатывайте свое программное обеспечение в виде модулей.

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

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

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

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