Est-il conseillé de demander aux employés de créer des comptes GitHub «de travail»?


91

J'ai transféré tous les référentiels Git de notre société vers GitHub et je souhaite maintenant ajouter des employés aux projets. Étant donné que la plupart des employés ont déjà un compte personnel GitHub, je me demande si je devrais leur demander de créer un compte GitHub professionnel . La raison pour laquelle je songe à faire cela est de réduire les chances d’accès non autorisé à notre base de code, car leurs comptes personnels peuvent être bien publiés grâce à leur activité personnelle sur le site, ce qui augmente les risques d’attaques ciblées. En outre, si leur compte personnel est compromis, cela ne signifie pas que l'intégralité de la société est accessible au pirate de l'air. Étant donné que cela alourdira le fardeau de la tenue de deux comptes pour les employés, je me demande s’il s’agit de la bonne approche et si elle a même un sens.

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, étant donné que 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 courrier électronique GitHub liées au travail devront être envoyées à leurs comptes de messagerie professionnels pour des raisons pratiques. Par conséquent, il serait plus logique de créer des comptes de travail GitHub. S'ils souhaitent utiliser leur compte personnel GitHub et le connecter à leurs comptes de messagerie professionnels, c'est très bien. Dans tout les cas, les employés devront accepter par écrit un certain nombre de conditions liées à l’utilisation de GitHub. Celles-ci sont liées à la sécurité des comptes: 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 utilisé avec aucun autre compte, ne pas accéder à GitHub via des ordinateurs qui ne leur appartiennent pas ou qui ne les administrent pas, etc. À la fin de la journée, les employés devront décider eux-mêmes si un compte de travail a plus de sens pour eux ou non.


Le compte de travail serait tout aussi facile à compromettre, n'est-ce pas?
Boris Yankov

10
GitHub a ajouté le routage des e-mails par organisation en août 2012. github.com/blog/1204-notifications-stars
Paul Schreiber

2
@BorisYankov, le compte professionnel peut être plus difficile à compromettre si vous n'avez aucune activité publique et si le nom de connexion n'a aucun lien avec votre nom. C'est la sécurité par l'obscurité, mais ça aide certainement. Vous pouvez créer un flux de travail selon lequel tous les courriers électroniques envoyés par github sont également envoyés au responsable de l'équipe de développement, etc. entre l'entreprise et l'employé. Troisième point important: dès que l'utilisateur quitte son travail, vous pouvez reprendre son compte.
VP.

7
Il est contraire aux conditions de service de GitHub permettant aux particuliers de gérer plusieurs comptes. "Une personne physique ou morale ne peut avoir plus d'un compte gratuit." help.github.com/articles/github-terms-of-service
Riley Major

2
A propos de ce dernier commentaire. Vérifié les termes, point A.7. Alors que se passe-t-il si vous avez votre compte personnel et que votre société crée un autre compte en votre nom et que vous l'utilisez? Votre compte personnel sera-t-il résilié même si vous ne vous êtes pas trompé?
Matteo Mosca

Réponses:


63

S'il y avait un avantage, ce serait simplement douloureux. Mais rien ne craint pire que douloureux et inutile. Juste avoir le compte personnel unique. Deux raisons:

  • Github a un contrôle d'accès incroyablement bon dans leurs organisations. Si un employé quitte son poste, vous pouvez immédiatement supprimer son accès. S'ils avaient un compte d'entreprise, vous devrez le récupérer d'une manière ou d'une autre pour obtenir les avantages indiqués. En pratique, vous supprimerez probablement simplement l'accès au compte, comme si vous disposiez d'un compte personnel.

  • Avoir plus d'un compte est douloureux. Se connecter et se déconnecter entre des comptes est un problème, et l'ajout de commentaires, de suivis et de tous les éléments sociaux lorsque vous utilisez différents comptes.

Références: Je crée un serveur CI qui intègre GitHub . J'ai donc beaucoup de comptes de test et j'ai parlé à des clients avec toutes sortes de configurations étranges, notamment des comptes de travail distincts et des comptes personnels. Cela crée toujours des problèmes.


25

Le code de votre entreprise est-il dans des référentiels publics ou privés? S'ils (ou du moins certains) sont publics et que vous autorisiez vos employés à utiliser leurs propres comptes GitHub, cela les inciterait à écrire du bon code. Leur nom y serait littéralement attaché, publiquement. Cependant, je suppose que tous vos référentiels sont privés.

Globalement, il semblerait que vous préfériez que les comptes de vos employés ne soient pas visibles publiquement dans GitHub. Malheureusement, ils gagnent de l'argent en vendant GitHub Enterprise, alors j'imagine que c'est l'une des raisons pour lesquelles ils ne vous permettent pas de créer des comptes privés pour des organisations. Dans les deux cas, le fait de verrouiller (essentiellement) des comptes de travail 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 de travail pour vos employés. Souhaitez-vous appliquer des restrictions sur la façon dont ils peuvent utiliser ces comptes? Les autoriseriez-vous à contribuer du code à des projets non professionnels à des fins professionnelles? Si tel est le cas, leurs comptes sont rendus publics, ce qui vous ramène à votre préoccupation initiale. Vous pouvez simplement leur permettre de faire les contributions avec leurs comptes personnels, mais vous créez alors un problème logistique pour eux. Personnellement, j'encourage mes employés à contribuer du code à d'autres projets en tant que tels. Cela leur donne non seulement un coup de pouce en confiance, mais leur permet également d'acquérir une expérience précieuse et de renforcer leur crédibilité.

En tout cas, je ne pense pas que ça vaut la peine d'avoir des comptes de travail. L'interface de GitHub vous permet de contrôler facilement qui a accès à quoi, de sorte que 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 vraiment une ligne" entre les projets personnels et professionnels plus que l'interface GitHub le fait déjà.

Gardez également à l’esprit la façon dont vous envisagez de gérer cette situation à mesure que votre entreprise se développe. Les politiques que vous avez mises en place vont-elles maintenant être évolutives du point de vue de la gestion? La gestion de 5 comptes en ce moment pourrait bien se dérouler, mais que se passe-t-il lorsque vous atteignez 20 ou 50 ans? Mais une fois que vous aurez atteint ce point, GitHub Enterprise sera peut-être une solution abordable. Dans ce cas, j’envisagerais de déterminer si les comptes GitHub peuvent être migrés vers des installations GitHub Enterprise. Si c'est le cas, je peux voir que c'est une raison positive d'avoir des comptes de travail.


Grands points, merci. Oui, les référentiels sont privés. En ce qui concerne le travail sur des projets non professionnels au travail, cela ne m'inquiète pas du tout. C'est juste la sécurité du compte.
Fiorenti

J'ai corrigé ce commentaire en particulier car il n'était pas pertinent.
Jeremy Heiler

19

Pas hors de question, et en fait une très bonne idée.

Aussi regrettable que cela puisse être, vous devez planifier le départ de vos employés de l'organisation à un moment donné de la vie de l'entreprise. Comment allez-vous extraire leurs comptes personnels du référentiel de la société à ce moment-là?

Qu'allez-vous faire si l'employé quitte la situation en mauvais termes? Dans un monde idéal, tout restera professionnel et il n'y aura pas d'animosité entre le cabinet et l'ex-employé. Vous seriez prudent de planifier pour des circonstances moins qu'idéales.

Bien que la gestion de deux comptes soit difficile, vos employés doivent en profiter. Il offre une ligne de démarcation plus nette entre ce qui est à eux et ce qui est à la compagnie.

Edit: Ce qui est préoccupant ici, est de séparer clairement 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 de travail distinct permet de fournir la délimitation nécessaire pour identifier qui détient quelle propriété intellectuelle et quel droit d'auteur associé.

Par exemple, si un employé utilise son compte personnel et contribue à la fois à la société et au projet X, comment déterminez-vous le rôle de l'employé à ce moment-là? La contribution à X était-elle au nom de votre entreprise ou à sa discrétion personnelle? L'employé ou l'entreprise détient-il le droit d'auteur sur cette œuvre attribuée à X? Par ailleurs, si vous autorisez des contributions extérieures au travail de votre entreprise, comment faites-vous la distinction si l'employé était un employé ou s'il s'agissait d'une contribution volontaire?

Dans un sens plus large, supposons qu'un employé crée une réputation agissant au nom de l'entreprise en contribuant à d'autres projets. Lorsque cet employé quitte son emploi, 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 fonction d'un compte particulier.

Il est assez facile de tomber dans le piège d'un lapin de préoccupations en matière de propriété, de marque et de droit d'auteur lorsque vous commencez à envisager des scénarios potentiels. L'utilisation de comptes de travail distincts permet de lever une partie de cette ambiguïté. La société doit pouvoir prétendre aux contributions faites en son nom.

Il ne s'agit pas des aspects techniques de la séparation du compte d'utilisateur, mais des questions juridiques qui peuvent vous décourager.

Notez que cela peut être une question discutable si les produits de votre entreprise sont tous publiés en tant que source ouverte avec des licences permissives et / ou si vous n'êtes pas du tout inquiet au sujet de problèmes de stratégie de marque.
(Pointe du chapeau à Paul Biggar pour avoir demandé cette modification)


Merci, je serais également heureux de cette politique si j'étais un employé pour les raisons mentionnées. L'interface de GitHub vous permet de supprimer facilement l'accès des utilisateurs à partir de référentiels privés. Je suppose également que si un employé devait partir en très mauvais termes, il aurait dans la plupart des cas assez de temps pour faire des dégâts s'il le souhaitait.
Fiorenti

23
Je ne comprends pas cette réponse. GitHub a un contrôle d’accès à grain fin. Lorsqu'un employé quitte son entreprise, vous lui retirez l'accès. Qu'est-ce qui est difficile à ce sujet? En fait, il est plus facile de supprimer leur compte personnel que de "récupérer" leur compte professionnel.
Paul Biggar

2
@ fiorenti: vraisemblablement, l'utilisateur aurait également un contrôle complet du code, ce qui se produirait quel que soit le lieu où le code est hébergé!
Paul Biggar

2
@PaulBiggar - J'ai mis à jour ma réponse pour prendre en compte certains des problèmes plus vastes impliqués. C'est principalement un problème d'attribution juridique qui m'amène à recommander des comptes séparés. J'ai vu un certain nombre de cas où le fait de ne pas séparer les comptes personnels des comptes de travail provoquait de graves maux de tête à la suite. Tout le monde est au MMV, et chaque situation doit être examinée en fonction de la philosophie de l'entreprise.

Merci de signaler le problème juridique potentiel que vous pouvez rencontrer dans le champ de mines
RidiculousRichard

10

Puisque tout le monde semble être d’accord sur le fait que l’employeur n’a pas besoin de séparer les deux, voici ma courte expérience de tentative d’utilisation de mon compte personnel dans le cadre de projets professionnels et de contributions de sources ouvertes dans le contexte du travail.

Pour que le contexte soit complet: rien ne m'a été demandé concernant les comptes, en fait, GitHub est inconnu de la plupart des gens de mon lieu de travail. J'ai tout simplement réussi à obtenir le feu vert pour ouvrir le projet sur lequel je vais travailler, et j'ai utilisé le moins de travail possible, c'est-à-dire utiliser mon compte personnel.

Du point de vue des employés, une chose que je déteste vraiment: recevoir des notifications sur mon courrier électronique personnel pour le travail.

À partir de ce constat, je me suis rendu compte que c’était 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 professionnels… Et cela peut semer la confusion dans l'esprit des contributeurs externes , qui pourrait vous contacter sans savoir que vous êtes hors de ce projet.

Ensuite, bien sûr, vous devez trouver un équilibre avec le fait que votre réputation personnelle peut tirer profit de vos contributions professionnelles. Mais là encore, cela pourrait être l'inverse si votre nom est associé à un mauvais projet…

En fin de compte, alors que la question est posée du point de vue de l’ employeur et compte tenu de toutes les autres réponses: je dirais qu’il n’est probablement pas très utile de forcer l’utilisation de comptes dédiés au travail . Mais vous ne devriez pas l'interdire, pour que les employés qui préfèrent lever la barrière personnelle puissent le faire, et peut-être faire allusion à ces risques…?


En passant, en ce qui concerne la sécurité, il semble y avoir un licenciement 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é à utiliser une clé SSH. Et cette clé réside généralement dans la 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 de travail dédié aurait probablement sa clé uniquement sur la machine de travail, le rendant plus en sécurité physique (espérons-le).


+1: Deux points auxquels je n'avais pas pensé: les emails et les clés SSH. Si vous avez des emails séparés sur GitHub, vous pouvez configurer plusieurs clés SSH pour votre compte.
Jeremy Heiler

@JeremyHeiler Qu'entendez-vous exactement par «avoir des emails séparés sur GitHub est un problème?» . J'utilise trois e-mails différents (ancien, personnel, actuel) et une fois que vous les avez ajoutés à votre profil, GitHub les
associe

Je faisais allusion à cet esprit . Voulez-vous dire que si vous mettez votre courrier électronique professionnel dans votre git.config sur votre ordinateur de travail et que vous l'ajoutez à votre compte, toutes les notifications liées au travail seront envoyées à votre courrier électronique professionnel? Si c'est le cas, c'est génial!
Jeremy Heiler

@JeremyHeiler Oh non ok, nous avons eu un malentendu mineur sur ce qui est "un problème" avec les emails :) Non, en effet, comme je l'ai dit dans ma réponse, vous recevez toujours des notifications sur votre compte "principal" (généralement personnel). Mais ce n’est pas un «problème», car vous auriez besoin d’un compte pour chaque adresse validée: vous pouvez associer autant d’e-mails que vous le souhaitez à votre compte, mais un seul e-mail reçoit des notifications de votre compte.
MattiSG

Désolé, oui, j'aurais dû être plus précis dans mon premier commentaire :-P
Jeremy Heiler

9

Je voterais "non". C’est un peu fastidieux pour vos développeurs et vous apporte une sécurité à travers l’obscurité: si quelqu'un cible activement vos développeurs, il existe de nombreux autres vecteurs d'attaque permettant à quelqu'un d'obtenir votre code.

De plus, en tant que startup, sauf si vous avez beaucoup d’algorithmes magiques du type sauce secrète en jeu, obtenir votre code serait embarrassant, horrible et odieux, mais ne devrait pas donner lieu à un avantage compétitif significatif code?) ou vous faire sortir du marché.

Une telle probabilité faible vs productivité des développeurs? Je prendrais la productivité des développeurs, mais c'est mon calcul. :)


2

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 bien que cela ne fût pas obligatoire, je souhaitais personnellement créer un compte séparé. 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 sien, car il se trouvait sous le même compte github que celui utilisé pour leurs projets d'entreprise (je ne suis pas sûr que cela se maintiendrait jamais devant les tribunaux, mais je n'ai pas beaucoup de foi dans le système juridique quand il s’agit de choses comme ça). Je pense qu'avoir ce propre séparé peut être une bonne chose.


2

Nous le faisons en notre compagnie. Je ne veux pas commencer une discussion "ce qui est plus sûr, github ou un serveur sous votre table que tout le monde a un accès root, pas sûr que la sauvegarde fonctionne, etc.". Notre approche était:

  • chaque développeur doit créer un nouveau compte, sans lien avec son compte personnel github
  • il devrait utiliser le courrier électronique de l'entreprise.
  • Il doit être conforme à nos règles de sécurité (identifiant et mot de passe requis).
  • Ils ne peuvent montrer / avoir aucune activité publique.
  • C'est la propriété de l'entreprise. Pas son compte.
  • Tous les comptes sont liés à une société, un nom aléatoire également. Aucune activité publique aussi.

2
Vous ne pouvez pas appliquer l'exigence de complexité du mot de passe car vous n'avez aucun moyen de valider le mot de passe GitHub, alors pourquoi l'avoir?
Ramhound,

Eh bien, vous dites que si vous n'êtes pas en mesure d' appliquer techniquement quelque chose, vous ne le faites pas. Je dis que si un employé lit la politique de sécurité et s'il la signe, connaissant les conséquences, c'est une application.
VP.

3
Je dis que vous n'avez aucun moyen de savoir que quelque chose ne se fait pas car vous n'avez aucun moyen de vérifier le mot de passe d'un compte créé par un employé.
Ramhound,

Eh bien, si, par exemple, un compte est compromis et que nous découvrons parfois que le mot de passe était abc123, nous pouvons "responsabiliser" l'employé. Je ne vois pas de problème ici. Un autre point: où est écrit que je l’applique? Je l'ai écrit doit (maintenant je mis à jour devrait) ...
VP.

Cette approche doit être tempérée par un accord selon lequel ce nom est aussi le leur et vous ne ferez aucune action en leur nom .
Michael

0

Je reconnais que cette période de questions remonte à quelques années. Elle n’était donc peut-être pas disponible auparavant, mais ils indiquent spécifiquement dans Différences entre les comptes d’utilisateur et d’entreprise que:

Il peut être tentant de disposer de plusieurs comptes utilisateur, par exemple pour un usage personnel ou 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 bien plus encore, il semble donc que combiner le travail personnel / travail a tout son sens.


Quel était ce vote négatif, hein? Je pense que c'est une bonne réponse.
John McGehee

-2

Les gens doivent encore faire confiance aux serveurs source basés sur le cloud. Github peut se vanter de posséder de nouvelles entreprises Web, mais le fait est que la plupart des gens ont leurs propres serveurs pour gérer le code source. D'après mon expérience, la plupart d'entre eux utilise Clear-case ou SVN. Git doit encore être adapté dans un environnement d'entreprise. Même les serveurs de messagerie d'entreprise ne sont pas vraiment appréciés en dehors des locaux de l'entreprise.


1
Je travaille actuellement dans une société de services, je les ai formés avec Git, et la plupart de leurs clients (comme les grandes entreprises) migrent de ClearCase ou se préparent à le faire dans leurs prochains projets…
MattiSG
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.