È consigliabile chiedere ai dipendenti di creare account GitHub "funzionanti"?

Ho trasferito tutti i repository Git della nostra azienda in GitHub e ora voglio aggiungere dipendenti ai progetti. Poiché la maggior parte dei dipendenti ha già account GitHub personali, mi chiedo se dovrei chiedere loro di creare un account GitHub funzionante . Il motivo per cui sto pensando di farlo è ridurre le possibilità di accesso non autorizzato alla nostra base di codice poiché i loro account personali possono essere ben pubblicizzati attraverso la loro attività personale sul sito, aumentando le possibilità di attacchi mirati. Inoltre, se il loro account personale viene mai compromesso, ciò non significa che l'intero codice aziendale sia accessibile al dirottatore. Dal momento che questo porterà l'onere di mantenere due conti per i dipendenti, mi chiedo se sia l'approccio corretto e se abbia persino senso.

Aggiornamento Grazie per tutte le informazioni utili. Non imposterò una risposta come accettata a causa della natura soggettiva della domanda / risposta e dal momento che ho preso i punti migliori da diverse risposte diverse.

Ho deciso di procedere in questo modo: ricorderò ai dipendenti che le notifiche e-mail GitHub relative al lavoro dovranno essere inviate ai loro account e-mail di lavoro per motivi pratici. Pertanto avrebbe più senso creare account GitHub di lavoro. Se sono disposti a utilizzare i propri account GitHub personali e collegarli ai propri account e-mail di lavoro, va bene. In ogni caso, i dipendenti dovranno concordare in forma scritta una serie di condizioni legate all'utilizzo di GitHub. Questi sono legati alla sicurezza dell'account: scegliere una password sicura usando un generatore di password casuale sicuro che non viene utilizzato con nessun altro account, non accedere a GitHub attraverso computer non di proprietà o amministrati da loro, ecc. Alla fine della giornata i dipendenti dovranno decidono se un account di lavoro ha più senso per loro o no.

Se ci fosse un vantaggio, sarebbe semplicemente doloroso. Ma niente fa peggio di doloroso e inutile. Basta avere il singolo account personale. Due motivi:

• Github ha un controllo degli accessi incredibilmente buono nelle loro organizzazioni. Se un dipendente lascia, puoi rimuovere immediatamente il suo accesso. Se avessero un account aziendale, dovresti recuperare l'account in qualche modo per ottenere i benefici dichiarati. In pratica, probabilmente avresti semplicemente rimosso l'accesso all'account, come se avessero un account personale.

• Avere più di un account è doloroso. Fare il login e disconnettersi tra gli account fa male e aggiungere commenti, seguire e tutte le cose sociali quando si utilizzano account diversi.

Riferimenti: creo un server CI con integrazione GitHub , quindi ho molti account di prova e ho parlato con i clienti con ogni sorta di strane configurazioni, inclusi account di lavoro separati e account personali. Porta sempre a problemi.

Il codice della tua azienda è in repository pubblici o privati? Se loro (o almeno alcuni) sono pubblici e hai permesso ai tuoi dipendenti di utilizzare i propri account GitHub, sarebbe un incentivo per loro scrivere un buon codice. Il loro nome sarebbe letteralmente assegnato ad esso, pubblicamente. Tuttavia, suppongo che tutti i tuoi repository siano privati.

Nel complesso, sembra che preferiresti che gli account dei tuoi dipendenti non fossero pubblicamente visibili in GitHub. Sfortunatamente, fanno soldi vendendo GitHub Enterprise, quindi immagino che sia uno dei motivi per cui non ti consentono di creare account privati ​​per le organizzazioni. In entrambi i casi, avere account di lavoro (essenzialmente) bloccati sarebbe davvero controintuitivo dopo aver scelto un sito molto social per ospitare i tuoi repository.

Immaginiamo che tu abbia creato account di lavoro per i tuoi dipendenti. Applicheresti delle restrizioni su come possono usare quegli account? Consentiresti loro di contribuire con codice a progetti non lavorativi a fini lavorativi? In tal caso, i loro account diventerebbero pubblicamente visibili, riportandoti alla tua preoccupazione iniziale. Potresti semplicemente consentire loro di dare i contributi con i loro account personali, ma poi stai creando un punto logistico per loro. Personalmente, incoraggerei i miei dipendenti a contribuire con il codice ad altri progetti come loro stessi. Ciò non solo dà loro una spinta di fiducia, ma consente loro di acquisire preziose esperienze e di costruire la loro credibilità.

In ogni caso, non penso che valga la pena avere degli account di lavoro. L'interfaccia di GitHub ti consente di controllare facilmente chi ha accesso a cosa, quindi rimuovere l'accesso è semplice in entrambi i modi. Inoltre, non penso che avere account separati in realtà "tracci una linea" tra i progetti personali e di lavoro più dell'interfaccia di GitHub.

Inoltre, tieni presente come prevedi di affrontarlo man mano che la tua azienda cresce. I criteri che stabilisci ora saranno scalabili dal punto di vista della gestione? Gestire 5 account in questo momento potrebbe andare bene, ma cosa succede quando cresci a 20 o 50? Ma una volta arrivato a quel punto, forse GitHub Enterprise sarà una soluzione accessibile. In tal caso, prenderei in considerazione la possibilità di verificare se gli account GitHub possono essere migrati alle installazioni di GitHub Enterprise. Se è così, posso vedere che è un motivo positivo per avere un account di lavoro.

Non è fuori discussione, e in realtà è una buona idea.

Per quanto spiacevole possa essere, è necessario pianificare i dipendenti che lasciano l'organizzazione ad un certo punto della vita dell'azienda. Come hai intenzione di districare i loro account personali dal repository dell'azienda in quel momento?

Che cosa hai intenzione di fare se il dipendente lascia in cattive condizioni? In un mondo ideale, tutto rimarrà professionale e non ci sarà alcuna animosità tra l'azienda e l'ex dipendente. Saresti prudente pianificare in circostanze non ideali.

Pur mantenendo due account è una seccatura, i tuoi dipendenti dovrebbero accogliere con favore l'opportunità. Fornisce una linea più pulita tra ciò che è loro e ciò che è l'azienda.

Modifica: la preoccupazione qui è fornire una chiara separazione tra i contributi personali dei dipendenti ai progetti X, Y, Z, ecc ... e il loro lavoro retribuito sul prodotto della vostra azienda. L'uso di un account di lavoro separato aiuta a fornire la delineazione necessaria per identificare chi possiede quale proprietà intellettuale e copyright associato.

Ad esempio, se un dipendente utilizza il proprio account personale e contribuisce sia alla società sia al Progetto X, come si identifica il ruolo ricoperto dal dipendente in quei momenti? Il contributo di X è stato per conto della tua azienda o per sua discrezione personale? Il dipendente o l'azienda possiede il copyright di quell'opera data a X? Del resto, se autorizzi contributi esterni al lavoro della tua azienda, come fai a distinguere se il dipendente era un dipendente o se si trattava di un contributo volontario?

In senso lato, supponiamo che tu abbia un dipendente che si costruisce una reputazione agendo per conto dell'azienda contribuendo ad altri progetti. Quando quel dipendente lascia, come si indica che l'account utente personale non è più associato alla propria azienda? Possono verificarsi seri problemi di marca senza delineare in modo chiaro a cosa serve un determinato account.

È abbastanza facile cadere in una scia di dubbi sulla proprietà, sul marchio e sui diritti d'autore quando inizi a pensare a scenari potenziali. L'uso di account di lavoro separati aiuta a rimuovere parte di questa ambiguità. La società deve essere in grado di rivendicare i contributi versati a suo nome.

Non si tratta degli aspetti tecnici della separazione dell'account utente, ma delle domande legali che possono farti inciampare.

Nota che questo potrebbe essere un punto controverso se i prodotti della tua azienda sono tutti rilasciati come open source sotto licenza permissiva e / o non sei affatto preoccupato per potenziali problemi di branding.
(Hat hat a Paul Biggar per aver richiesto questa modifica)

Poiché tutti sembrano concordare sulla mancanza della necessità del datore di lavoro di separare entrambi, ecco la mia breve esperienza dopo aver provato a utilizzare il mio account personale su progetti professionali e contributi open source forniti nel contesto del lavoro.

Giusto per completare il contesto: non mi è stato chiesto nulla riguardo agli account, in realtà GitHub è sconosciuto alla maggior parte delle persone sul mio posto di lavoro. Sono stato semplicemente in grado di ottenere semafori verdi per l'open-source del progetto su cui lavorerò e sono andato con la minima quantità di lavoro, cioè usando il mio account personale.

Dal punto di vista di un dipendente, una cosa che odio davvero: ricevere notifiche sulla mia e-mail personale per lavoro.

Da quell'osservazione, mi sono reso conto che è una palese rottura della barriera professionale / personale: se voglio contribuire a un progetto durante il mio tempo libero, ottengo ancora tutti gli aggiornamenti dai miei progetti di lavoro ... E può creare confusione per i collaboratori esterni , che potrebbe contattarti senza sapere che sei fuori da quel progetto.

Quindi, naturalmente, c'è un equilibrio da trovare con il fatto che la tua reputazione personale può guadagnare dai tuoi contributi di lavoro. Ma ancora una volta, potrebbe essere il contrario se il tuo nome viene associato a un progetto scadente ...

Alla fine, poiché la domanda viene posta dal punto di vista del datore di lavoro , e considerando tutte le altre risposte: direi che probabilmente non ha molto senso far valere l'uso di account dedicati al lavoro . Ma non dovresti vietarlo, in modo che i dipendenti che preferiscono alzare la barriera personale possano farlo, e forse suggerire quei rischi ...?

Come nota a margine, per quanto riguarda la sicurezza, dal momento che sembra esserci un certo licenziamento in altre risposte:

Naturalmente, un account "lavorativo" non sarebbe più o meno sicuro di un account "personale" per quanto riguarda le password. Ma quando usi GitHub, puoi spingere con una chiave SSH. E quella chiave di solito sta nella propria sessione ... Quindi, l'account personale può compromettere tutti i repository di lavoro con un semplice furto di personal computer (senza conoscenza della password), mentre un account di lavoro dedicato avrebbe probabilmente la sua chiave solo sulla macchina di lavoro, rendendolo più fisicamente sicuro (si spera).

Vorrei votare "No". È un po 'una seccatura per i tuoi sviluppatori e ti offre sicurezza attraverso l'oscurità: se qualcuno sta attivamente prendendo di mira i tuoi sviluppatori, c'è un sacco di altri vettori di attacco per qualcuno per ottenere il tuo codice.

Inoltre, come startup a meno che tu non abbia un sacco di magici algoritmi di tipo secret-sauce in gioco qualcuno che ottenga il tuo codice sarebbe imbarazzante, terribile e odioso, ma non dovrebbe tradursi in un significativo vantaggio competitivo (chi potrebbe legalmente usare il tuo codice?) o causare l'interruzione dell'attività.

Una probabilità così bassa rispetto alla produttività degli sviluppatori? Prenderei la produttività degli sviluppatori, ma questo è il mio calcolo. :)

Direi che dovrebbe essere una scelta lasciata al dipendente. Una cosa che direi è di non costringerli a usare il loro account personale di github se non vogliono. Ero in un'azienda che utilizzava GitHub e sebbene non fosse un requisito, volevo personalmente creare un account separato. Il motivo principale era proteggere i miei progetti personali. Non volevo che la compagnia provasse a dire che uno dei miei progetti personali era il loro perché era sotto lo stesso account github usato per i loro progetti comapny (non sono sicuro che ciò possa mai resistere in tribunale, ma non ho molta fiducia nel sistema legale quando si tratta di cose del genere). Penso che avere quel pulito separato possa essere una buona cosa.

Lo stiamo facendo nella nostra azienda. Non voglio iniziare una discussione "cos'è più sicuro, github o un server sotto il tuo tavolo che tutti hanno accesso come root, non sono sicuro che il backup funzioni, ecc.". Il nostro approccio era:

• ogni sviluppatore, deve creare un nuovo account, non correlato al proprio account github personale
• dovrebbe usare l'email aziendale.
• Dovrebbe essere conforme alle nostre regole di sicurezza (nome di accesso e requisiti di password).
• Non possono mostrare / avere alcuna attività pubblica.
• È proprietà dell'azienda. Non il suo account.
• Tutti gli account sono collegati a una società, anche il nome casuale. Nessuna attività pubblica pure.

Riconosco che queste domande e risposte hanno alcuni anni, quindi forse non erano disponibili prima, ma specificano in Differenze tra account utente e organizzazione che:

Potrebbe essere allettante avere più di un account utente, ad esempio per uso personale e aziendale, ma è necessario un solo account.

GitHub ha creato buoni strumenti per attivare / disattivare le notifiche in base al repository e molto altro sembra che la combinazione di personale / lavoro abbia più senso.

Le persone devono ancora fidarsi dei server di origine basati su cloud. Github vanta molte società web new age registrate con loro, ma il fatto è che la maggior parte delle persone ha i propri server per mantenere il codice sorgente. Nella mia esperienza, la maggior parte di loro usa Clear-case o SVN. Git deve ancora essere adattato in un ambiente aziendale. Anche i server di posta aziendali non sono molto apprezzati al di fuori dei locali dell'azienda.