Comment empêcher le code de fuir le travail extérieur?
Duplicata possible:
Comment gérer un projet à haut risque en source fermée?
Je travaille sur une institution qui a un très fort sentiment de "possession" - chaque ligne de logiciel que nous écrivons ne devrait être que la nôtre. Ironiquement, je suis le seul programmeur (ATM), mais nous prévoyons d'en embaucher d'autres.
Étant donné que mes patrons ne considéreraient pas les nouveaux programmeurs comme des personnes de confiance, ils ont un problème avec les copies du code source. Nous utilisons Git, donc ils auraient une copie entière de chacun des projets sur lesquels ils travaillent, lorsqu'ils cloneront le référentiel.
Nous pouvons restreindre leur accès à une seule clé avec Gitolite et les lier à leurs PC, mais ils peuvent copier ces clés sur un autre ordinateur et ils auraient accès au référentiel sur un autre PC. En outre (et la méthode la plus évidente), ils peuvent simplement télécharger les fichiers ailleurs, ajouter une autre télécommande ou simplement copier les fichiers sur une clé USB.
Existe-t-il un moyen (peut-être intelligent) d'empêcher de tels événements?
EDIT: Je tiens à remercier tout le monde pour leurs idées sur cette question, car ce n'est pas seulement plus eye ouverture, mais aussi un soutien ferme de mes arguments (puisque vous pensez essentiellement comme moi, et j'ai essayé de leur faire comprendre cela) contre mes patrons dans un proche avenir.
Je suis dans une situation difficile au travail, avec mes collègues et mes patrons (puisque je suis fondamentalement au milieu) comme deux gangs, donc toute cette contribution est grandement appréciée.
Il est vrai que je cherchais une solution technique à un problème personnes - tant la direction que les employés sont le problème, donc ça ne peut pas être résolu de cette façon (je pensais à certains obfuscation de code, peut-être travailler avec des modules séparés, etc., mais cela ne fonctionnerait pas à partir de mon développeur POV). Le principal problème est la culture à l'intérieur et à l'extérieur de l'entreprise - le développement n'est pas pris au sérieux dans mon pays (Venezuela), donc la naïveté et la paranoïa sont en fait un vrai problème ici.
La vraie réponse ici est une solution NDA (quelque chose qui ici au Venezuela ne fonctionne pas complètement), car c'est la solution people, car aucun développeur sensé ne fonctionnerait dans ces conditions. Les choses vont mal tourner, mais je pense que je pourrai y faire face grâce à votre aide. Merci beaucoup à tous! <3
C'est l'une des situations où vous êtes à la recherche d'une solution technique à un problème social .
Un problème social doit nécessiter une solution sociale qui, dans ce cas, prend deux formes complémentaires et une solution organisationnelle supplémentaire qui peut aider:
Confiance. Si vous ne faites pas confiance aux développeurs, ne les embauchez pas. Travailler avec des gens en qui vous n'avez pas confiance est synonyme d'échec. Les relations basées sur la méfiance nécessitent beaucoup de formalisme, ce qui peut gravement affecter non seulement la productivité de vos employés, mais aussi le nombre de personnes prêtes à travailler avec vous. Il y a de fortes chances que les meilleurs développeurs évitent à tout prix votre entreprise.
NDA. Faire confiance à quelqu'un ne signifie pas que vous ne devriez pas prendre de précautions légales. Ces précautions peuvent prendre la forme d'un contrat ou d'une clause NDA avec des conséquences graves pour l'employé en cas de divulgation.
La gravité des conséquences dépend de qui vous êtes. Les organisations gouvernementales, les terroristes ou la mafia peuvent autoriser certaines mesures dissuasives. Les sociétés ordinaires peuvent être limitées, par la loi, aux seules sociétés financières.
Tranchage. La confiance et les contrats sont un bon début, mais nous pouvons faire mieux. Si la partie sensible de la base de code peut être découpée de sorte que deux ou plusieurs parties soient nécessaires au fonctionnement du produit, assurez-vous que le développeur du département 1 ne voit jamais le code source développé dans le département 2, et vice versa.
Les gens d'un département ne devraient pas pouvoir rencontrer des gens d'autres départements, et idéalement, ils ne devraient même pas être capables de deviner ce que font les autres départements, ni combien il y a de départements. Chaque personne n'en connaît qu'une petite partie, ce qui ne suffit pas pour avoir une image complète (et reconstruire un produit entier en dehors de l'organisation).
Ce sont des mesures sociales et organisationnelles.
Maintenant, techniquement parlant, il n'y a rien que vous puissiez faire.
Vous pouvez essayer de:
Forcer les développeurs à travailler dans une pièce fermée sur une machine qui n'est pas connectée à Internet et n'a pas de ports USB.
Installez des caméras qui surveillent tout ce qui se passe dans la pièce, plusieurs agents de sécurité observant constamment les développeurs travailler.
Effectuez une recherche à nu sur chaque développeur à chaque fois qu'il quitte la pièce pour être sûr qu'il ne possède aucun appareil électronique capable de contenir le code.
Exiger que chaque développeur ait un moniteur de cheville. L'appareil écoutera ce qu'ils disent, enregistrera leur position et tentera de détecter tout appareil électronique à proximité. Si le développeur était à proximité d'un appareil non identifié et sur lequel aucun logiciel de suivi n'est installé, les enquêteurs privés et les pirates peuvent tenter de vérifier si le développeur n'utilisait pas l'appareil pour divulguer des informations.
Interdisez aux développeurs de quitter vos bâtiments, sauf s'ils sont sous haute surveillance, et d'interagir de quelque manière que ce soit avec le monde extérieur.
Certaines ou toutes ces mesures sont illégales dans de nombreux pays (à moins que vous ne représentiez certains agences gouvernementales), mais le pire est que même avec toutes ces mesures en place, les développeurs pourront obtenir le code , par exemple en l'écrivant discrètement sur leur peau ou sur un morceau de papier et en le cachant dans leurs vêtements, ou simplement en le mémorisant s'ils en ont mémoire Eidétique .
Ou ils peuvent simplement mémoriser globalement les structures de données et les algorithmes - c'est la seule chose importante où la propriété intellectuelle est importante - et créer leur propre produit inspiré de ces deux choses.
Faites-leur signer un accord de confidentialité.
N'embauchez que des personnes en qui vous avez confiance.
Compartimentez votre base de code. Utilisation de l'injection de dépendances pour que vous puissiez leur donner des exigences qui, une fois terminées, les classes résultantes tomberaient bien en place dans l'architecture existante, mais elles n'auront pas accès à "l'image complète" ", uniquement des pièces détachées. Seules les personnes âgées et de confiance auraient accès à la "colle architecturale" qui fait que tout fonctionne dans son ensemble.
J'adore l'idée qu'il pourrait y avoir une idée "intelligente" que "nous" en tant que développeurs seraient déconcertés. Étant donné que chaque outil de développeur écrit a été écrit par un développeur et tout ça.
Le plus gros problème de votre patron est la naïveté avec un soupçon de paranoïa. Je suis poli là-bas. Vraiment vraiment très poli.
Si vous voulez vraiment une liste de courses pour garder votre code propriétaire, implémentez simplement ce qui suit:
Désactivez USB et autres IO sur tous les ordinateurs de l'entreprise. Cela peut être fait par le biais de la plupart des antivirus d'entreprise ou similaires.
Toutes les machines de développement doivent être des ordinateurs de bureau ou des tours. Pas d'ordinateurs portables.
Ne laissez aucune machine se connecter à Internet. Pas de Web, FTP, e-mail, messagerie instantanée, pas d'Internet. Coupez les fils.
Pas de travail/accès à distance (en quelque sorte couvert par pas d'Internet, mais certains intelligents spark pourrait suggérer un VPN)
Pas de téléphones portables ou autres appareils électroniques à emporter dans la salle de "développement" sécurisée.
Configurez toutes les imprimantes pour imprimer un grand filigrane visible sur chaque page, recto et verso.
sac fouille à la fois à l'intérieur et à l'extérieur. Recherchez des notes manuscrites, tout ce qui est imprimé sur les imprimantes de l'entreprise (n'importe quoi, ils pourraient avoir du code caché dans une image avec de la stéganographie!). Tout appareil électrique ou électronique. En fait, il est probablement préférable de s'assurer que les sacs sont gardés hors de la zone sécurisée et que les développeurs devraient porter des combinaisons propres, le genre de chose que vous verriez dans les tanières de médicaments et les usines de fabrication de puces.
Les serveurs doivent être également isolés, les sauvegardes doivent être chiffrées et seul votre patron doit connaître le mot de passe à restaurer à partir d'eux.
Si les personnes en question ne peuvent pas faire confiance pour respecter leurs contrats de travail, alors il n'a pas besoin de les embaucher.
S'il croit que personne ne peut faire confiance, alors il est trop paranoïaque, et il finira par nuire à l'entreprise s'il le maintient.
À un moment donné, vous DEVEZ faire confiance à vos employés. Ce n'est pas vraiment une option pour faire autrement. Si vous ne faites pas confiance à vos employés, ils ne peuvent pas être efficaces, car vous passez trop de temps à vous méfier d'eux et perdez beaucoup de temps à sauter dans des cerceaux en raison de problèmes de confiance.
De plus, lorsque vous dites clairement aux gens que vous ne leur faites pas confiance, ils ont tendance à s'énerver. Et les programmeurs agacés trouvent finalement un autre travail où ils ne sont pas traités de cette façon.
La bonne solution est une vérification des antécédents de base, un contrat de travail bien pensé et une certaine confiance.
J'écrivais du code pour des systèmes informatiques classifiés. Ils avaient toutes sortes de cerceaux ridicules à franchir pour garder le secret. Par exemple, nous n'étions pas autorisés à apporter des CD de musique dans certaines pièces car ils pouvaient être des CD-RW déguisés.
Le fait est que les aspects pratiques du travail ouvrent des trous de sécurité par nécessité. Parfois, vous aviez pour transporter des données/codes non classés dans ou hors d'une zone classée afin de faire le travail. Oui, il y avait aussi des règles et des procédures, mais elles se résumaient toutes à faire confiance aux gens. Au lieu de faire confiance aux gens pour ne pas mettre les données classifiées sur une clé USB pratique, vous faites simplement confiance aux mêmes personnes pour passer à travers tous les cercles de sécurité.
En d'autres termes, il y a beaucoup de choses que vous pouvez faire pour vous protéger des étrangers, mais une fois que vous les avez laissés entrer, il s'agit à peu près de savoir combien vous voulez les ennuyer.
En bref, vous devez avoir un accord/contrat de non-divulgation avec les employés que vous embauchez. En plus de cet accord signé, embauchez des développeurs que vous pouvez faire confiance.
Techniquement parlant, ce code peut facilement être copié sur l'appareil et réutilisé ailleurs. Ce que votre patron ne veut pas, c'est l'accès de vos concurrents à ce code. Vous ne pouvez appliquer ces politiques que par le biais de contrats de travail ou de partenariat.
Une autre chose qui peut fonctionner est fournir une formation sur la sensibilité des informations, comment chaque employé doit être alerté en cas de violation de la confidentialité des informations. De plus, le suivi des activités informatiques au sein de votre réseau de bureau augmentera également le niveau d'avertissement.
Un type de formation similaire est dispensé chaque année aux employés qui traitent Informations relatives aux RPS .
Cependant, obtenir une personne de confiance à bord et fournir une formation sur la façon de protéger ces informations pourrait être la meilleure façon de procéder.
Avez-vous vu Paycheck avec Ben Affleck? Je pense que c'est le seul moyen de garantir que votre adresse IP ne sera pas "volée". Je peux vous dire qu'en raison de ma mémoire, je pourrais recréer presque tous les systèmes sur lesquels j'ai travaillé pendant une période de temps significative. Si ce n'est pas une récréation ligne par ligne, je pourrais produire les éléments importants et probablement les améliorer dans le processus en raison de la façon dont mes compétences se sont développées au fil des ans.
Clair et simple, il n'y a que deux choses que vous pouvez accomplir en "verrouillant" votre code:
- Vous repousserez les bons développeurs offensés par votre manque de confiance évident
- Vous lèverez un grand drapeau qui tentera les développeurs les moins scrupuleux
Si vous pensez que votre logiciel est si nouveau et si étonnant, obtenez un brevet.
- Vous ne pouvez pas empêcher le code de fuir. Vous pouvez limiter la fuite à un code moins important.
- Normalement, il n'y a qu'une seule partie de l'application qui la rend unique. Ce serait un algorithme. Vous pouvez très bien interfacer cela et le placer dans une branche de contrôle de source distincte. Vous et seulement les personnes qui ont besoin d'y travailler devraient y avoir accès. Vous ne fournissez qu'un binaire (obscurci) et l'interface aux autres développeurs.
- Divisez votre code en plusieurs modules et laissez les gens travailler uniquement sur un module particulier. Les autres modules sont fournis en binaire (obscurci). Cependant, cela peut être trop étendu pour être ingérable et conduire à une duplication de code.
Je connais quelqu'un qui a travaillé dans un environnement comme celui-ci.
Quelques mesures qui y ont été prises:
Aucun accès à l'ordinateur physique, tous les ordinateurs étaient stockés dans une pièce verrouillée avec des trous dans le mur pour l'affichage, le clavier et la souris.
Pas d'accès Internet.
Système d'exploitation personnalisé qui utilisait un système de fichiers interne avec cryptage (au cas où un ordinateur devait être volé d'une manière ou d'une autre).
Les projets étaient divisés en bibliothèques statiques, personne n'avait accès à tout le code source (cela bien sûr ne s'applique pas à tous les langages de programmation).
C'était un lieu de travail très désagréable.
Faites attention de ne pas surestimer la valeur de votre code source à ceux qui ne font pas partie de votre entreprise.
Bien sûr - vous avez payé beaucoup d'ingénieurs (développeurs, assurance qualité, etc.) beaucoup d'argent pour le développer, mais cela ne signifie pas qu'il est intrinsèquement précieux pour un tiers.
Quelles attaques exactes existent?
Le code source est souvent divulgué (par exemple) par des sociétés de développement de jeux ou de sécurité informatique. Bien sûr, de telles fuites les font mal paraître, mais sinon, ne causent pas de réel préjudice.
Demande toi:
- Êtes-vous tellement gêné par la qualité de votre code source, il serait préjudiciable à votre réputation de le divulguer?
- Le code source contient-il lui-même des secrets confidentiels (par exemple, des clés de chiffrement codées en dur, des détails sur les relations financières avec d'autres sociétés)? Devrait-il?
- Un concurrent pourrait-il réellement bénéficier de l'utilisation de votre code source, malgré le risque d'être découvert?
À ma connaissance, il y a eu un cas où un membre du personnel d'une entreprise de sécurité informatique a tenté de vendre le code source à un concurrent. Le concurrent a immédiatement signalé cela à son employeur et il a rapidement été licencié. Aucun argent n'a changé de main, mais le membre du personnel ne peut plus travailler facilement dans l'industrie de la sécurité informatique.
Vous devez faire confiance, mais il est parfois préférable de simplement surveiller les infractions. Par exemple, si votre code s'exécute, il peut téléphoner à la maison à une adresse IP sur Internet chaque fois qu'il est exécuté, en enregistrant l'adresse IP, les informations de l'ordinateur, peut-être même l'emplacement géographique de l'endroit où il s'exécute. Consultez ce journal pour rechercher des problèmes.
Bien sûr, il existe des moyens de contourner cela, et les développeurs pourraient simplement regarder le code, pas l'exécuter.
Vous pouvez configurer votre pare-feu pour effectuer une inspection des paquets avec quelque chose comme Snort qui pourrait a) bloquer immédiatement la connexion s'il détecte, par exemple votre avis de droit d'auteur, et b) le signaler à la direction pour suivi. Pour contourner SSL et HTTPS, vous devez exécuter un proxy HTTPS sur votre pare-feu.
Peut-être pourriez-vous avoir un utilitaire système sur chaque PC qui vérifie les lecteurs externes et les lecteurs flash USB pour des fichiers spécifiques ou des phrases clés lorsqu'ils sont branchés. Vous pouvez également désactiver/interdire les lecteurs externes (j'ai entendu que le DOD américain le faisait). Vous devez exiger qu'ils utilisent votre matériel et n'apportent aucun matériel de chez vous.
Il existe probablement des programmes disponibles qui enregistreront tout ce que quelqu'un fait avec un ordinateur. Planifiez simplement des audits aléatoires de ces journaux et assurez-vous que les développeurs sont conscients de cette capacité.
Une fois que vous avez trouvé une infraction, frappez le développeur au-dessus de la tête avec le NDA qu'ils ont signé.
Une solution technique pourrait être d'avoir toutes les sessions de développement hébergées sur un serveur sans accès au réseau (ou strictement restreint et surveillé) au-delà de celui requis pour servir les sessions RDP (ou VNC). De cette façon, la source n'est jamais sur la machine d'un développeur. Cela permettrait également de travailler à domicile ou sur un site client.
En fin de compte, cependant, je pense que toute la situation est mûre pour l'échec. Si vous faites comprendre aux développeurs que vous ne leur faites pas confiance et rendez leur travail plus difficile, à mon humble avis, vous créez un environnement où les développeurs vont trouver un moyen de rendre la source publique, juste pour "Collez-le à l'homme".
Vous travaillez pour des personnes qui ne comprennent tout simplement pas le fonctionnement du génie logiciel. Pire: ils ne l'apprécient pas (seulement ce qu'ils peuvent en retirer). Il ne sera pas possible de travailler de manière productive pour eux; en fin de compte, ils vous puniront pour cela. Trouvez un autre emploi.