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

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

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

Некоторые организации заставляют сотрудников подписывать соглашение об отказе от конкуренции. Такое соглашение не позволяет программистам работать на конкурентов. Этот метод лучше всего сочетается с объявлениями о вакансиях типа «Ищу старшего программиста с 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-портам, дисководу компакт-дисков или клиентам веб-почты. Единственное, что они могли делать, - это работать над кодом и, возможно, просматривать веб-страницы. Также дайте им доступ только к тому коду, за который они отвечают.

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

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

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

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

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

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

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

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

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

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

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

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

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