Est-il conseillé de demander aux employés de créer des comptes GitHub «professionnels»?
J'ai déplacé tous les référentiels Git de notre entreprise vers GitHub et maintenant je veux ajouter des employés aux projets. Étant donné que la plupart des employés ont déjà des comptes GitHub personnels, je me demande si je dois leur demander de créer un travail compte GitHub. La raison pour laquelle je pense à cela est de diminuer les chances d'accès non autorisé à notre base de code, car leurs comptes personnels peuvent être bien publicisés grâce à leur activité personnelle sur le site, augmentant ainsi les chances d'attaques ciblées. De plus, si leur compte personnel est jamais compromis, cela ne signifie pas que le code de l'entreprise dans son intégralité est accessible au pirate de l'air. Étant donné que cela entraînera le fardeau de la tenue de deux comptes pour les employés, je me demande si c'est la bonne approche et si cela a même du sens. Je serais ravi d'entendre vos opinions à ce sujet.
Mise à jour Merci pour toutes les informations utiles. Je ne définirai pas une réponse comme acceptée en raison de la nature subjective de la question/des réponses et puisque j'ai pris les meilleurs points de plusieurs réponses différentes.
J'ai décidé d'aller de l'avant de cette façon: je rappellerai aux employés que les notifications par e-mail GitHub liées au travail devront être envoyées à leur compte de messagerie professionnel pour des raisons pratiques. Par conséquent, il serait plus logique de créer des comptes GitHub de travail. S'ils sont prêts à utiliser leurs comptes GitHub personnels et à les connecter à leurs comptes de messagerie professionnels, c'est bien. Dans tous les cas, les employés devront accepter par écrit un certain nombre de conditions liées à l'utilisation de GitHub. Ceux-ci sont liés à la sécurité du compte: choisir un mot de passe sécurisé à l'aide d'un générateur de mot de passe aléatoire sécurisé qui n'est pas utilisé avec un autre compte, ne pas accéder à GitHub via des ordinateurs qui ne leur appartiennent pas ou ne sont pas administrés par eux, etc. À la fin de la journée, les employés devront décider eux-mêmes si un compte professionnel a plus de sens pour eux ou non.
S'il y avait un avantage, ce serait simplement douloureux. Mais rien n'est pire que douloureux et inutile. Ayez juste le compte personnel unique. Deux raisons:
Github a un contrôle d'accès incroyablement bon dans leurs organisations. Si un employé part, vous pouvez supprimer instantanément son accès. S'ils avaient un compte d'entreprise, vous devrez récupérer le compte d'une manière ou d'une autre pour obtenir les avantages indiqués. Dans la pratique, vous supprimeriez probablement l'accès au compte, comme s'ils avaient un compte personnel.
Avoir plus d'un compte est douloureux. La connexion et la déconnexion entre les comptes font mal, et l'ajout de commentaires, de suivi et de tous les trucs sociaux lorsque vous utilisez différents comptes.
Références: Je fais un serveur CI qui a l'intégration de GitHub , donc j'ai environ beaucoup de comptes de test, et je ' J'ai parlé à des clients avec toutes sortes de configurations étranges, y compris des comptes professionnels et des comptes personnels séparés. Cela mène toujours à des ennuis.
Le code de votre entreprise est-il dans des référentiels publics ou privés? S'ils (ou au moins certains) sont publics et que vous autorisez vos employés à utiliser leurs propres comptes GitHub, ce serait une incitation pour eux à écrire du bon code. Leur nom serait littéralement attaché à lui, publiquement. Cependant, je suppose que tous vos référentiels sont privés.
Dans l'ensemble, il semble que vous préféreriez que les comptes de vos employés ne soient pas visibles publiquement dans GitHub. Malheureusement, ils font de l'argent en vendant GitHub Enterprise donc j'imagine que c'est une des raisons pour lesquelles ils ne vous permettent pas de créer des comptes privés pour les organisations. Dans les deux cas, avoir (essentiellement) des comptes de travail verrouillés serait vraiment contre-intuitif après avoir choisi un site très social pour héberger vos référentiels.
Imaginons que vous ayez créé des comptes professionnels pour vos employés. Souhaitez-vous appliquer des restrictions sur la façon dont ils peuvent utiliser ces comptes? Leur permettriez-vous de contribuer du code à des projets non professionnels à des fins professionnelles? Si c'est le cas, leurs comptes deviendraient publiquement visibles, vous ramenant à votre préoccupation initiale. Vous pouvez simplement leur permettre de faire des contributions avec leurs comptes personnels, mais vous créez alors un problème logistique pour eux. Personnellement, j'encouragerais mes employés à contribuer eux-mêmes à d'autres projets. Cela leur donne non seulement un regain de confiance, mais leur permet d'acquérir une expérience précieuse et de renforcer leur crédibilité.
En tout cas, je ne pense pas que cela vaille la peine d'avoir des comptes professionnels. L'interface GitHub vous permet de contrôler facilement qui a accès à quoi, donc la suppression de l'accès est simple dans les deux cas. Je ne pense pas non plus que le fait d'avoir des comptes séparés "trace une ligne" entre les projets personnels et professionnels plus que ne le fait déjà l'interface GitHub.
Gardez également à l’esprit comment vous comptez y faire face à mesure que votre entreprise se développe. Les politiques que vous définissez maintenant seront-elles évolutives du point de vue de la gestion? Gérer 5 comptes en ce moment peut être bien, mais que se passe-t-il lorsque vous atteignez 20 ou 50? Mais une fois que vous aurez atteint ce stade, GitHub Enterprise sera peut-être une solution accessible. Dans ce cas, j'envisagerais de déterminer si les comptes GitHub peuvent être migrés vers les installations GitHub Enterprise. Si oui, je peux voir que c'est une raison positive d'avoir des comptes de travail.
Pas hors de question, et en fait une assez bonne idée.
Aussi regrettable que cela puisse être, vous devez prévoir que vos employés quittent l'organisation à un moment donné de la vie de l'entreprise. Comment allez-vous extraire leurs comptes personnels du référentiel de l'entreprise à ce moment-là?
Qu'allez-vous faire si l'employé part en mauvais termes? Dans un monde idéal, tout restera professionnel et il n'y aura pas d'animosité entre l'entreprise et l'ex-salarié. Il serait prudent de prévoir des circonstances moins qu'idéales.
Bien que la gestion de deux comptes soit pénible, vos employés devraient en profiter. Il offre une ligne plus nette entre ce qui leur appartient et ce qui appartient à l'entreprise.
Edit: Le souci ici est de fournir une séparation claire entre les contributions personnelles des employés aux projets X, Y, Z, etc ... et leur travail rémunéré sur le produit de votre entreprise. L'utilisation d'un compte professionnel distinct permet de définir la délimitation nécessaire pour identifier à qui appartient la propriété intellectuelle et les droits d'auteur associés.
Par exemple, si un employé utilise son compte personnel et contribue à la fois à l'entreprise et au projet X, comment identifiez-vous le rôle de l'employé à ce moment-là? La contribution à X était-elle au nom de votre entreprise ou à leur propre discrétion? L'employé ou l'entreprise détient-il le droit d'auteur sur ce travail donné à X? D'ailleurs, si vous autorisez des contributions externes au travail de votre entreprise, comment distinguez-vous si l'employé était un employé ou s'il s'agissait d'une contribution volontaire?
Dans un sens plus large, disons que vous avez un employé qui se construit une réputation agissant au nom de l'entreprise en contribuant à d'autres projets. Lorsque cet employé quitte, comment indiquez-vous que le compte d'utilisateur personnel n'est plus associé à votre entreprise? De graves problèmes de marque peuvent survenir sans une délimitation claire de la raison d'être d'un compte particulier.
Il est assez facile de tomber sur un lapin de problèmes de propriété, de marque et de droit d'auteur lorsque vous commencez à réfléchir aux scénarios potentiels. L'utilisation de comptes de travail distincts permet de lever une partie de cette ambiguïté. L'entreprise doit pouvoir prétendre aux contributions versées en son nom.
Il ne s'agit pas des aspects techniques de la séparation du compte utilisateur, ce sont les questions juridiques qui peuvent vous tromper.
Notez que cela peut être un point discutable si les produits de votre entreprise sont tous publiés en open source sous licence permissive et/ou si vous ne vous inquiétez pas du tout des problèmes de marque potentiels.
(Pointe du chapeau à Paul Biggar pour avoir demandé cette modification)
Étant donné que tout le monde semble s'accorder sur le fait que l'employeur n'a pas besoin de séparer les deux, voici ma courte expérience ayant essayé d'utiliser mon compte personnel sur des projets professionnels et des contributions open source dans le cadre du travail.
Juste pour rendre le contexte complet: on ne m'a rien demandé concernant les comptes, en fait GitHub est inconnu de la plupart des gens sur mon lieu de travail. J'ai simplement pu obtenir le feu vert pour ouvrir le projet sur lequel je travaillerai, et j'ai effectué le moins de travail possible, c'est-à-dire en utilisant mon compte personnel.
Du point de vue d'un employé, une chose que je déteste vraiment: recevoir des notifications sur mon e-mail personnel pour le travail.
À partir de ce constat, je me suis rendu compte que c'est une rupture flagrante de la barrière professionnelle/personnelle: si je veux contribuer à un projet pendant mon temps libre, je reçois toujours toutes les mises à jour de mes projets de travail… Et cela peut semer la confusion pour les contributeurs externes , qui pourrait vous contacter sans savoir que vous êtes absent de ce projet .
Ensuite, bien sûr, il y a un équilibre à trouver avec le fait que votre réputation personnelle peut bénéficier de vos contributions au travail. Mais là encore, cela pourrait être le contraire si votre nom est associé à un mauvais projet…
En fin de compte, comme la question est posée du point de vue de l'employeur , et en considérant toutes les autres réponses: je dirais qu'il n'y a probablement pas beaucoup de points pour appliquer en utilisant des comptes dédiés au travail . Mais vous ne devriez pas l'interdire, afin que les employés qui préfèrent lever la barrière personnelle puissent le faire, et peut-être faire allusion à ces risques…?
En guise de remarque, en ce qui concerne la sécurité, car il semble y avoir un rejet facile dans d'autres réponses:
Bien entendu, un compte "professionnel" ne serait ni plus ni moins sécurisé qu'un compte "personnel" en ce qui concerne les mots de passe. Mais lorsque vous utilisez GitHub, vous êtes autorisé à pousser avec une clé SSH. Et cette clé réside généralement dans sa session… Ainsi, le compte personnel peut compromettre tous les référentiels de travail avec un simple vol d'ordinateur personnel (sans connaissance du mot de passe), alors qu'un compte professionnel dédié aurait probablement sa clé uniquement sur la machine de travail, ce qui le rend plus physiquement en sécurité (espérons-le).
Je voterais "non". C'est un peu compliqué pour vos développeurs et vous donne la sécurité à travers l'obscurité: si quelqu'un cible activement vos développeurs, il y a beaucoup d'autres vecteurs d'attaque pour que quelqu'un obtienne votre code.
De plus, en tant que startup, sauf si vous avez beaucoup d'algorithmes magiques de type sauce secrète en jeu, quelqu'un obtenant votre code serait embarrassant, terrible et désagréable, mais ne devrait pas entraîner un avantage concurrentiel significatif (qui pourrait légalement utiliser votre code?) ou vous faire cesser vos activités.
Une si faible probabilité de commande par rapport à la productivité des développeurs? Je prendrais la productivité des développeurs, mais c'est mon calcul. :)
Je dirais que cela devrait être un choix laissé à l'employé. Une chose que je dirais est de ne pas les forcer à utiliser leur compte github personnel s'ils ne le souhaitent pas. J'étais dans une entreprise qui utilisait GitHub et même si ce n'était pas obligatoire, je voulais personnellement créer un compte distinct. La raison principale était de protéger mes projets personnels. Je ne voulais pas que la société essaie de dire que l'un de mes projets personnels était le leur, car il était sous le même compte github que celui utilisé pour leurs projets collectifs (je ne sais pas si cela pourrait tenir le coup, mais je n'ai pas beaucoup de foi) dans le système juridique en ce qui concerne des choses comme celle-ci). Je pense qu'avoir cette séparation propre peut être une bonne chose.
Nous le faisons dans notre entreprise. Je ne veux pas entamer une discussion "qu'est-ce qui est plus sûr, github ou un serveur sous votre table que tout le monde a un accès root, je ne sais pas si la sauvegarde fonctionne, etc.". Notre approche était:
- chaque développeur doit créer un nouveau compte, sans rapport avec son compte github personnel
- il doit utiliser l'e-mail de l'entreprise.
- Il doit être conforme à nos règles de sécurité (nom de connexion et mot de passe requis).
- Ils ne peuvent pas montrer/avoir d'activité publique.
- C'est la propriété de l'entreprise. Pas son compte.
- Tous les comptes sont liés à une entreprise, un nom aléatoire également. Pas d'activité publique également.
Je reconnais que ces questions et réponses datent de quelques années, alors peut-être qu'elles n'étaient pas disponibles auparavant, mais elles indiquent spécifiquement dans Différences entre les comptes d'utilisateur et d'organisation que:
Il peut être tentant d'avoir plus d'un compte d'utilisateur, par exemple pour un usage personnel et professionnel, mais vous n'avez besoin que d'un seul compte.
GitHub a construit de bons outils pour activer/désactiver les notifications par référentiel et plus encore, il semble que la combinaison du personnel/du travail soit la plus logique.