Comment protégez-vous le code contre les fuites à l'extérieur? [dupliquer]

https://stackoverflow.com/questions/173875

05-07-2019
|

Question

Cette question a déjà une réponse ici:

Comment protégez-vous votre logiciel contre la distribution illégale? [fermé] 25 réponses

Outre l’open-sourcing de votre projet et de votre législation, existe-t-il des moyens de prévenir, ou du moins de minimiser les dommages causés par les fuites de code en dehors de votre société / groupe?

Nous ne pouvons évidemment pas bloquer l'accès à Internet (pour empêcher l'envoi du code par courrier électronique) car les programmeurs ont besoin de leurs références. Nous ne pouvons pas non plus bloquer les périphériques (USB, Firewire, etc.)

Le code est ce qui importe le plus lorsqu'il dispose d'algorithmes propriétaires et de connaissances développées en interne (par opposition au code de routine pour dessiner des interfaces graphiques, se connecter à des bases de données, etc.), mais certaines applications (comme les logiciels de comptabilité et les CRM) ne sont que cela: des collections complexes de code de routine qui sont simples à développer en principe, mais il faudra des années pour écrire à partir de zéro. C’est là que le code divulgué sera utile aux concurrents.

Pour moi, la prévention des fuites repose presque entièrement sur des processus humains. Qu'est-ce que tu penses? Quelles précautions et mesures prenez-vous? Et la fuite de code vous a-t-elle déjà affecté?

La solution

Vous ne pouvez pas l'empêcher de sortir. Donc, deux solutions: arrêtez les gens qui veulent vous faire du mal et prenez des précautions légales. Pour empêcher les gens de vous haïr de les traiter correctement (en dire plus est probablement un sujet hors sujet en cas de débordement de pile).

Je ne suis pas avocat, mais pour vous protéger juridiquement, si vous y croyez, faites breveter les idées, mettez un avis de droit d'auteur dans le code et assurez-vous que les contrats de vos programmeurs spécifient soigneusement les droits de propriété intellectuelle.

Mais en fin de compte, la réponse est plus rapide que la concurrence.

Autres conseils

À moins que vous ne travailliez avec quelque chose de hautement classifié et que vous ne puissiez pas bloquer les courriels et les périphériques USB, je suppose que vous ne l'êtes pas, il n'y a pas trop de dégâts, même en cas de fuite du code source. Le problème est de savoir ce que vaut le code, ou des parties de celui-ci, sans savoir comment il fonctionne et quelle est son organisation.

En général, la valeur de " source " est beaucoup moins que ce qui est communément vanté, essentiellement la source sans les personnes ou l'organisation ne vaut pas le stockage qu'elle occupe pour un concurrent.

En outre, vous manquez le vecteur d’attaque le plus probable et c’est également celui que vous ne pouvez pas arrêter quoi qu’il en soit. Si quelqu'un veut vraiment savoir comment vous avez créé votre magie, il essaiera de recruter vos développeurs et, comme vous ne pouvez pas les empêcher de garder des informations à l'intérieur de leur crâne, même s'ils transmettent toutes leurs possessions, leurs connaissances et leur domaine. l'expertise s'en va avec eux. En gros, la rétention et la confiance des employés sont la seule solution. Désolé.

Je ne sais pas quelle aide réelle cela va être, mais:

Ne désactivez pas vos programmeurs. Ne les mettez pas dans une position où ils veulent donner la source à un concurrent. La plupart des endroits sous-estiment leurs développeurs. Étant donné où vous êtes (SO), je suppose que vous êtes moins susceptible de. Rien ne me faisait plus plaisir que de voir les vendeurs vendre des parties de golf - payées et payées par la société - pendant que nous devions nous battre pour obtenir une pizza une fois par mois.
Vraiment, si vos concurrents directs recevaient votre code aujourd'hui , que ferait-il? Votre produit ou marché vertical est-il si stagnant que vous ne publieriez pas de nouvelles versions améliorées avant qu’ils ne puissent réagir? N'y a-t-il pas de place pour l'innovation? La plupart des entreprises surévaluent leurs "algorithmes propriétaires et leurs connaissances développées en interne". Bien sûr, cela peut réduire le temps de travail, mais ce n’est que 10% du problème.
Si vous aviez toute la source de tous les produits de vos concurrents, quelle serait leur utilisation réelle? Je suppose que cela vous retarderait de plusieurs mois. Pas en avant. Retour.

Si vous aviez un système propre et peu de connaissances externes / internes, combien de temps faudrait-il pour que votre propre produit devienne constructible? Combien de temps faudrait-il pour approfondir le code et savoir ce qui se passe? Combien de temps et d’argent gaspilleriez-vous à essayer de régler quelque chose au lieu de dépenser temps et argent pour savoir comment produit fonctionne-t-il mieux?

En fait, je suis en train d’avoir toute la source - 1 million de lignes + de code - d’un produit concurrent. Nous n'avons rien fait avec cela - mis à part un peu de poke-around et ensuite le supprimer, ce qui était plus que ce que je me sentais à l'aise - mais je m'attendrais à ce que nous ayons pris des mois de temps juste pour arriver là où ils étaient puis.

Nous avons donc mis le cap sur l'id10t (oui, un développeur / PM venu de l'autre société) et avons réfléchi à la manière de faire en sorte que notre produit ait tellement peu importait ce qu'ils faisaient. Bien mieux utiliser le temps. A bien fonctionné aussi. Nous avons eu des facteurs de différenciation, pas seulement le ré-hachage des mêmes caractéristiques de la même manière.

Désolé, mais aucun ne permet pas d'empêcher les gens de sortir des choses et de continuer à travailler. Vous pouvez les empêcher de vouloir de le faire, ou de les rendre inutilisables.

Nous craignions que des personnes décompilent notre code également. Nous avons cessé de nous inquiéter lorsque nous nous sommes rendu compte que NOUS avions assez de difficulté à déterminer ce qui se passait à l'intérieur de 500 000 lignes de code C #, C ++ et HTML communiquant avec MAPI / Exchange. Si quelqu'un peut le décompiler et le résoudre, nous voulons les engager ......

BTW, pour plus de clarté, et étant donné les personnes pour lesquelles je travaille, je dois préciser que ce n'est pas mon employeur actuel. C'était il y a longtemps.

Le code ne coule pas sur lui-même. Il faut que les gens le prennent. Il est évident que vous pouvez utiliser certaines mesures de sécurité, telles que l'analyse du trafic et le verrouillage des référentiels afin que seuls les développeurs autorisés puissent s'y connecter.

Mais à la fin de la journée, votre meilleure option est de vous assurer que personne NE VEUT vous voler. Votre équipe doit être heureuse, elle doit être fière de travailler pour vous, elle doit être loyale à la société et à l’autre. Si vous avez une telle équipe, c'est une simple question d'expliquer à tout le monde que le code doit être protégé des étrangers. Cela n'arrêtera pas une taupe dédiée mais préviendra les accidents.

P.S. Et oui, les clauses appropriées dans les contrats ne feraient pas de mal non plus. Au moins, ils veilleront à ce que les développeurs soient CONSCIENTS du fait que prendre du code à l'extérieur est moralement répréhensible.

Suivez ces instructions et le fait que le contenu de l'ensemble de votre référentiel de code source soit publié sur stackoverflow n'a aucune importance:

http://geocities.com/mdetting/unmaintainable.html

Oh, et montrez à vos développeurs que vous ne leur faites pas confiance en bloquant l'accès à certaines parties du code source, en analysant les e-mails sortants / entrants, etc. C'est un moyen infaillible de leur donner envie de rester ... . Rien n’améliore le moral comme un peu de méfiance sur le lieu de travail.

Une autre méthode intéressante consiste à indiquer à la moitié de la personne "équipe". et nommez l'autre moitié comme étant "l'équipe b" indigne de confiance. Puis inversez-le et dites la même chose à & l '"équipe b". membres. Encouragez-les à garder un œil sur les "méchants" dans l’autre équipe et de vous signaler tout signe d’illusion. Saupoudrer quelques "inducteurs de conflit" (par exemple, dites "Joe": ' savez-vous ce qu'Ed dit de vous derrière votre dos? '), etc. Cela fonctionne à merveille si vous configurez les développeurs les uns contre les autres et créez quelques [inventés - par-vous] des conflits ici et là ...

(Eh, et non, je ne recommande en fait aucune de ces réponses. Je plaisante. Mais j'ai vu des gens utiliser toutes les tactiques ci-dessus. Et cela n'a pas fonctionné.)

D'accord, je vais être un peu pratique ici.

Etre gentil avec tout le monde et espérer qu'il ne vous fera pas mal ne fonctionne pas.

Chaque programmeur sait, à compter du jour où il rejoint une entreprise, qu’il ne restera pas là pour toujours. Il changera quand il aura suffisamment appris pour avoir une meilleure opportunité.

Les programmeurs qui écrivent le code croient en être propriétaires même s’ils l’ont écrit au moment de la location à un tiers. Nombre d’entre eux essaieront généralement de mettre la main sur le code source même s’ils ne souhaitent blesser personne.

Une fois qu'ils ont quitté la société, qu'ils ont emporté le code source et qu'ils ont perdu le contact avec leurs collègues, la conscience s'installe et part en vacances. Après un certain temps, des fragments du code commencent à apparaître partout.

C’est ce que je sais qui arrive parce que j’ai été témoin que cela arrivait à mon entreprise.

Alors, que fait-on?

Signez une NDA mentionnant expressément que le programmeur NE PRENDRA PAS de copies.
Distribuez votre produit entre les programmeurs et, si possible, obtenez des modules codés individuellement et intégrés par un responsable, dont la responsabilité est que tous les programmeurs n’obtiennent pas tout le code.
Au moment de la résiliation, demandez aux codeurs de s’engager par écrit à ne pas posséder l’adresse IP de la société et à comprendre les sanctions qui leur sont applicables.
Si quelqu'un viole votre adresse IP, poursuivez l'homme en justice! Aucune exception. Cela fonctionnera comme exemple pour l’équipe actuelle.

Est-ce que je parais extrême?

Je me souviens de ce qui est arrivé à Valve alors qu’elle développait HL-2. Lien intéressant ici: http://www.shacknews.com/onearticle.x/28619

J'ai travaillé quelque part dans ce genre de chose où règne une véritable culture du secret (historiquement, il y avait eu plusieurs fois où l'entreprise était petite, où les "clients" avaient abusé de leur accès à notre produit).

Même si au sommet la direction était très protectrice, je le vois un peu différemment. Je pense que notre code, même s'il n'est pas totalement dépourvu de pertinence, n'est pas aussi essentiel que vous le souhaiteriez dans un éditeur de logiciels.

La raison de notre succès est la suivante:

1) Le code est essentiellement la solution à de nombreux problèmes. Si vous obtenez notre code, vous obtenez ces solutions, mais nous avons toujours les personnes intelligentes qui ont résolu ces problèmes. Ils comprennent ces problèmes mieux que vous et sont mieux à même de résoudre le prochain groupe de problèmes mieux que vous.

2) Parce qu'ils comprennent vraiment les problèmes (et les solutions), nous pouvons faire les choses plus rapidement que nos concurrents, ce qui se traduit par moins cher (ou plus rentable).

3) En outre, à cause de ces personnes et de l’attitude de la société, nous avons bien servi nos clients et leur avons apporté un soutien efficace.

4) Et pour cette raison, nous avons une bonne réputation et des clients de référence.

Un petit nombre d’entreprises ont un code qu’il vaut vraiment la peine de garder secret, des algorithmes propriétaires, etc., mais pour la grande majorité d’entre nous, nos produits sont très facilement reproductibles par des gens intelligents.

Ce que je dis, c'est de faire les bases - écrivez dans les contrats des gens qu'ils ne peuvent pas le prendre, gardez-le en sécurité, etc. - mais ne vous laissez pas obséder par cela. À moins que vous ne soyez sur un marché très spécifique, il est peu probable que votre entreprise réussisse ou échoue.

La meilleure chose à faire est de rééduquer les gars qui ont un comportement éthique fort. Diverses autres étapes peuvent être prises, comme toutes les communications numérisées. Il y a des endroits où le courrier électronique et toutes les informations qui sortent sont numérisés. Le bureau / ordinateur portable n'a pas de disque dur ou l'accès est restreint et tout le travail est effectué sur des dossiers réseau. Même lorsque vous travaillez à domicile, vous devez être connecté à Internet. Le travail hors ligne est synchronisé. La clé USB et les lecteurs sont déconnectés.

Les autres stratégies doivent fournir un accès uniquement sur la base des besoins. Celles-ci ne feront que ralentir et gêner dans une certaine mesure, mais si l'un est très déterminé, il trouverait des moyens de contourner ce problème. L’autre façon est que si le code est vraiment très important, alors protégez-vous légalement de l’idée.

Pour être honnête, c’est presque impossible. Si je voulais suggérer ce qu’une entreprise qui figurerait prochainement dans le Daily WTF ferait:

Déconnectez le " ordinateur de travail " depuis Internet, parce qu’ils ont besoin d’un accès Internet, achetez un wbbook à tout le monde.
Farcissez les connecteurs USB des développeurs avec de l'époxy et exigez qu'ils chargent / déchargent tout depuis un serveur centralisé, qui analyse toutes les données qui y transitent à la recherche d'un code tel que la syntaxe.

Vous pouvez également faire confiance à vos employés et leur faire signer un accord de confidentialité.

Personnellement, je n'ai jamais testé de cas réel, mais je suggérerais d'utiliser la fragmentation de code:

En gros, vous divisez votre projet en plusieurs bibliothèques, définissez des interfaces et des tests unitaires pour chacune d’elles, puis vous séparez les référentiels SVN de sorte que chaque groupe ait accès à une partie limitée de votre précieux code source.

C’est également une bonne pratique, quoi qu’il en soit, et devrait vous aider si vous sous-traitez à l’étranger.

Les réponses précédentes semblent toutes être centrées sur l'instauration d'un climat de confiance et l'emploi de personnes respectueuses de l'éthique.

Une autre possibilité pourrait être de créer votre propre langage et vos outils spécifiques à un domaine. Cela rendra plus difficile l’utilisation de tout code divulgué. Il serait peut-être encore possible de lui dérober des idées utiles, mais il ne serait pas possible de simplement compiler un produit concurrent à moins de laisser fuir toute la chaîne d’outils.

Faites confiance à vos développeurs. Les gens ont tendance à répondre aux attentes. Traitez-les bien et rappelez-vous que la loyauté va dans les deux sens. Après tout, si vous ne pouvez pas couper les clés USB, vous ne pouvez empêcher personne de divulguer du code, peu importe à quel point vous ne leur faites pas confiance.

Cela étant dit, trouvez un avocat spécialisé dans les secrets commerciaux, probablement dans d’autres domaines du droit de la propriété intellectuelle, et demandez comment protéger juridiquement les documents. Vous voulez vous assurer que si un concurrent récupère vos affaires, il n’est pas légal pour un concurrent d’en tirer profit.

La plupart des réponses reposent sur des valeurs morales et éthiques. Je me demande si Google, Facebook, etc. ne comptent que sur la bonne volonté de leurs employés. Donnez-moi une pause, c'est totalement utopique. Ne sois pas fou. Soyez réaliste.

OUI, il est possible d'empêcher la fuite de code:

À l'aide d'un serveur virtuel hébergeant des machines virtuelles, les programmeurs ne peuvent accéder localement à ces machines virtuelles (intranet) que via Remote Desktop. Le référentiel est géré localement. des clés privées sont nécessaires pour accéder au référentiel. Le copier / coller de la machine virtuelle vers le client est désactivé. seul le copier / coller du client vers le virtuel est autorisé.

Des entreprises comme Facebook le font.

La seule façon de conserver le code consiste à prendre des photos conformément au code, ce qui n’est absolument ni pratique ni réalisable, et comme il y a des caméras de surveillance partout, vous devrez vous rendre à la salle de bain pour prendre ces photos.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow