Czy wskazane jest poproszenie pracowników o utworzenie „roboczych” kont GitHub?


91

Przenieśliśmy wszystkie nasze firmowe repozytoria Git do GitHub i teraz chcę dodać pracowników do projektów. Ponieważ większość pracowników ma już osobiste konta GitHub, zastanawiam się, czy powinienem poprosić ich o utworzenie roboczego konta GitHub. Powodem, dla którego myślę o tym, jest zmniejszenie szans na nieautoryzowany dostęp do naszej bazy kodu, ponieważ ich konta osobiste mogą być dobrze nagłośnione poprzez ich osobistą aktywność na stronie, zwiększając szanse na ukierunkowane ataki. Co więcej, jeśli ich konto osobiste zostanie kiedykolwiek naruszone, nie oznacza to, że porywacz może uzyskać dostęp do całego kodu firmy. Ponieważ przyniesie to obciążenie związane z utrzymywaniem dwóch kont dla pracowników, zastanawiam się, czy jest to prawidłowe podejście i czy w ogóle ma sens.

Zaktualizuj Dziękujemy za wszystkie przydatne informacje. Nie ustawię odpowiedzi jako zaakceptowanej z powodu subiektywnego charakteru pytania / odpowiedzi i ponieważ wziąłem najlepsze punkty z kilku różnych odpowiedzi.

Postanowiłem pójść naprzód: przypomnę pracownikom, że ze względów praktycznych powiadomienia e-mail związane z pracą GitHub będą musiały być wysyłane na konta służbowe. Dlatego bardziej sensowne byłoby tworzenie pracy kont GitHub. Jeśli są skłonni korzystać z osobistych kont GitHub i połączyć je ze służbowymi kontami e-mail, nie ma problemu. W każdym przypadku, pracownicy będą musieli wyrazić pisemną zgodę na szereg warunków związanych z korzystaniem z GitHub. Są one związane z bezpieczeństwem konta: wybranie bezpiecznego hasła przy użyciu bezpiecznego generatora losowych haseł, które nie jest używane z żadnym innym kontem, brak dostępu do GitHub za pośrednictwem komputerów, które nie są przez nich własnością lub nie są przez nich administrowane itp. Na koniec pracownicy będą musieli sami decydujcie, czy konto służbowe ma dla nich większy sens, czy nie.


Konto robocze byłoby równie łatwe do złamania, prawda?
Borys Jankow

10
GitHub dodał routing wiadomości e-mail dla organizacji w sierpniu 2012 r. Github.com/blog/1204-notifications-stars
Paul Schreiber

2
@BorisYankov konto służbowe może być trudniejsze do złamania, jeśli nie masz żadnej działalności publicznej, a login nie ma związku z Twoim imieniem i nazwiskiem. To bezpieczeństwo przez zaciemnienie, ale na pewno pomaga. Możesz utworzyć przepływ pracy, w którym wszystkie wiadomości e-mail wysyłane przez github są również wysyłane do lidera zespołu programistów itp. Kolejny punkt: Jako konto służbowe możesz decydować, a nawet przeprowadzać analizę due diligence, kontrolować konta i sprawdzać, czy są one zgodne z tym, co zostało uzgodnione między firmą a pracownikiem. Trzecia ważna kwestia: jak tylko użytkownik opuści swoją pracę, możesz przejąć jego konto.
VP.

7
Prowadzenie więcej niż jednego konta jest niezgodne z warunkami usługi GitHub dla osób fizycznych. „Jedna osoba lub osoba prawna nie może prowadzić więcej niż jednego bezpłatnego konta”. help.github.com/articles/github-terms-of-service
Riley Major

2
O tym ostatnim komentarzu. Sprawdzone warunki, punkt A.7. Co się stanie, jeśli masz konto osobiste, a Twoja firma utworzy w Twoim imieniu inne konto i czy z niego korzystasz? Czy twoje konto osobiste zostanie usunięte, nawet jeśli nie zrobiłeś nic złego?
Matteo Mosca

Odpowiedzi:


63

Gdyby coś przyniosło korzyść, byłoby to po prostu bolesne. Ale nic nie jest gorsze niż bolesne i bezcelowe. Wystarczy mieć jedno konto osobiste. Dwa powody:

  • Github ma niewiarygodnie dobrą kontrolę dostępu w swoich organizacjach. Jeśli pracownik odejdzie, możesz natychmiast usunąć jego dostęp. Gdyby mieli konto firmowe, musiałbyś je jakoś odzyskać, aby uzyskać wymienione korzyści. W praktyce prawdopodobnie po prostu usunąłbyś dostęp do konta, tak jak gdyby miał konto osobiste.

  • Posiadanie więcej niż jednego konta jest bolesne. Logowanie się i wylogowywanie między kontami boli, a także dodawanie komentarzy, obserwowanie i wszystkie inne rzeczy społecznościowe, gdy używasz różnych kont.

Referencje: Robię serwer CI, który ma integrację GitHub , więc mam o wiele kont testowych, a ja rozmawiałem z klientami z różnego rodzaju dziwnych konfiguracjach, w tym odrębnych rachunkach roboczych i kont osobistych. To zawsze prowadzi do kłopotów.


25

Czy kod Twojej firmy jest w repozytoriach publicznych czy prywatnych? Jeśli są one (lub przynajmniej niektóre) publiczne, a Ty pozwoliłeś swoim pracownikom korzystać z ich własnych kont GitHub, zachęciłoby ich to do napisania dobrego kodu. Ich nazwa dosłownie będzie do niego dołączona, publicznie. Zakładam jednak, że wszystkie twoje repozytoria są prywatne.

Ogólnie rzecz biorąc, wygląda na to, że wolisz, aby konta Twojego pracownika nie były publicznie widoczne w GitHub. Niestety zarabiają, sprzedając GitHub Enterprise, więc sądzę, że to jeden z powodów, dla których nie pozwalają ci tworzyć prywatnych kont dla organizacji. W obu przypadkach posiadanie (zasadniczo) zablokowanych kont roboczych byłoby naprawdę sprzeczne z intuicją po wybraniu bardzo społecznościowej witryny do przechowywania repozytoriów.

Wyobraźmy sobie, że założyłeś konta robocze dla swoich pracowników. Czy wymusilibyście jakiekolwiek ograniczenia dotyczące korzystania z tych kont? Czy pozwoliłbyś im wnieść kod do projektów niepracujących do celów pracy? Jeśli tak, to ich konta staną się publicznie widoczne, co wróci do pierwotnej troski. Możesz po prostu pozwolić im na wpłacanie składek za pomocą ich kont osobistych, ale wtedy tworzysz dla nich logistyczny problem. Osobiście zachęcam moich pracowników, aby sami wnieśli kod do innych projektów. To nie tylko zwiększa pewność siebie, ale także pozwala zdobyć cenne doświadczenie i budować wiarygodność.

W każdym razie nie sądzę, że warto mieć konta robocze. Interfejs GitHub pozwala łatwo kontrolować, kto ma dostęp do czego, więc usunięcie dostępu jest proste w obu przypadkach. Nie sądzę też, aby oddzielne konta naprawdę „rysowały granicę” między projektami osobistymi i zawodowymi, niż interfejs GitHub.

Pamiętaj również, jak zamierzasz sobie z tym poradzić w miarę rozwoju firmy. Czy zasady, które wprowadziłeś, będą teraz skalowalne z punktu widzenia zarządzania? Zarządzanie 5 kontami w tej chwili może być w porządku, ale co się stanie, gdy dorośniesz do 20 lub 50? Ale kiedy dojdziesz do tego punktu, być może GitHub Enterprise będzie dostępnym rozwiązaniem. W takim przypadku rozważę ustalenie, czy konta GitHub można migrować do instalacji GitHub Enterprise. Jeśli tak, to widzę, że jest to jeden pozytywny powód do posiadania kont służbowych.


Świetne punkty, dzięki. Tak, repozytoria są prywatne. Jeśli chodzi o pracę nad niepracującymi projektami w pracy, wcale się tym nie martwię. To tylko bezpieczeństwo konta.
fiorenti

Zredagowałem ten konkretny komentarz, ponieważ nie był istotny.
Jeremy Heiler

19

Nie wykluczone, a właściwie całkiem niezły pomysł.

Choć może to być godne ubolewania, musisz zaplanować odejście pracowników z organizacji w pewnym momencie życia firmy. Jak zamierzasz wydobyć ich konta osobiste z repozytorium firmy w tym momencie?

Co zrobisz, jeśli pracownik odejdzie na złych warunkach? W idealnym świecie wszystko pozostanie profesjonalne i nie będzie animozji między firmą a byłym pracownikiem. Rozsądnie byłoby zaplanować sytuację, która nie jest idealna.

Prowadzenie dwóch kont jest uciążliwe, ale pracownicy powinni skorzystać z okazji. Zapewnia czystszą linię między tym, co jest ich, a tym, co należy do firmy.

Edycja: niepokojące jest tutaj wyraźne oddzielenie osobistego wkładu pracownika w projekty X, Y, Z itp. I jego płatnej pracy nad produktem Twojej firmy. Korzystanie z osobnego konta roboczego pomaga w określeniu niezbędnym do ustalenia, kto jest właścicielem jakiej własności intelektualnej i powiązanych praw autorskich.

Na przykład, jeśli pracownik korzysta ze swojego konta osobistego i wnosi wkład zarówno do firmy, jak i Projektu X, w jaki sposób określasz, jaką rolę pełnił w tamtych czasach? Czy był wkład do X w imieniu Twojej firmy, czy według własnego uznania? Czy pracownik lub firma jest właścicielem praw autorskich do tego dzieła przekazanego X? W tym przypadku, jeśli zezwalasz na wkłady zewnętrzne do pracy Twojej firmy, jak odróżnić, czy pracownik był pracownikiem, czy był to wkład dobrowolny?

Mówiąc szerzej, powiedzmy, że masz pracownika, który buduje reputację działając w imieniu firmy, uczestnicząc w innych projektach. Kiedy ten pracownik odchodzi, w jaki sposób wskazujesz, że osobiste konto użytkownika nie jest już powiązane z Twoją firmą? Poważne problemy z marką mogą wystąpić bez wyraźnego określenia, do czego służy dane konto.

Kiedy zaczynasz zastanawiać się nad potencjalnymi scenariuszami, łatwo jest upaść na trop właściciela, marki i praw autorskich. Korzystanie z oddzielnych kont roboczych pomaga usunąć część tej niejednoznaczności. Firma musi mieć możliwość dochodzenia roszczeń od składek wniesionych w jej imieniu.

Nie chodzi o techniczne aspekty oddzielania konta użytkownika, ale o pytania prawne, które mogą cię potknąć.

Pamiętaj, że może to być kwestią sporną, jeśli wszystkie produkty Twojej firmy są wydawane jako oprogramowanie typu open source w ramach zezwolenia licencyjnego i / lub nie martwisz się o potencjalne problemy z brandingiem.
(Czapka dla Paula Biggara za prośbę o edycję)


Dzięki, z zadowoleniem przyjmuję tę polisę, gdybym był pracownikiem z wymienionych powodów. Interfejs GitHub pozwala łatwo usunąć dostęp użytkowników z prywatnych repozytoriów. Zakładam również, że jeśli pracownik odejdzie na bardzo złych warunkach, w większości przypadków będzie miał wystarczająco dużo czasu, aby wyrządzić szkody, jeśli chce.
fiorenti

23
Nie rozumiem tej odpowiedzi. GitHub ma precyzyjną kontrolę dostępu. Kiedy pracownik odchodzi, usuwasz jego dostęp ze swojej organizacji. Co jest w tym trudnego? W rzeczywistości łatwiej jest usunąć konto osobiste niż „odzyskać” konto służbowe.
Paul Biggar,

2
@fiorenti: przypuszczalnie użytkownik miałby również pełną kontrolę kodu, co nastąpiłoby niezależnie od tego, gdzie kod jest hostowany!
Paul Biggar

2
@PaulBiggar - Zaktualizowałem swoją odpowiedź, aby uchwycić niektóre z szerszych problemów. Jest to przede wszystkim kwestia prawna związana z przypisaniem, która prowadzi mnie do polecania osobnych kont. Widziałem wiele przypadków, w których nie oddzielenie kont osobistych od służbowych spowodowało poważne bóle głowy w następstwie. MMV każdego i każda sytuacja musi być zbadana w oparciu o etos firmy.

Dziękujemy za wskazanie potencjalnego problemu minowego, na które możesz natknąć się
RidiculousRichard

10

Ponieważ wydaje się, że wszyscy zgadzają się co do braku konieczności oddzielenia przez pracodawcę obu elementów, oto moje krótkie doświadczenie w próbowaniu używania mojego konta osobistego w profesjonalnych projektach i wkładach typu open source w kontekście pracy.

Tylko po to, żeby kontekst był kompletny: nie pytano mnie o konta, tak naprawdę GitHub jest nieznany większości ludzi w moim miejscu pracy. Po prostu udało mi się zdobyć zielone światło, aby otworzyć projekt, nad którym będę pracować, i wykonałem najmniej pracy, tj. Używając mojego konta osobistego.

Z punktu widzenia pracownika jedną rzecz, której naprawdę nienawidzę: otrzymywanie powiadomień na mój osobisty e-mail o pracy.

Po tej obserwacji zdałem sobie sprawę, że to rażące przełamanie bariery zawodowej / osobistej: jeśli chcę przyczynić się do projektu w czasie wolnym, wciąż otrzymuję wszystkie aktualizacje z moich projektów pracy ... I może to wprowadzać zamieszanie dla zewnętrznych współpracowników , który może się z Tobą skontaktować, nie wiedząc, że nie masz udziału w tym projekcie.

Wówczas oczywiście można znaleźć równowagę między faktem, że twoją osobistą reputację można zyskać dzięki wkładowi w pracę. Ale z drugiej strony może być odwrotnie, jeśli twoje nazwisko zostanie powiązane z kiepskim projektem…

Na koniec, ponieważ pytanie jest zadawane z punktu widzenia pracodawcy i biorąc pod uwagę wszystkie inne odpowiedzi: powiedziałbym, że prawdopodobnie nie ma sensu egzekwować korzystania z kont dedykowanych do pracy . Ale nie powinieneś tego zabraniać, aby pracownicy, którzy wolą podnieść barierę osobistą, mogli to zrobić, a może wskazywać na ryzyko…


Na marginesie, jeśli chodzi o bezpieczeństwo, ponieważ wydaje się, że w innych odpowiedziach można łatwo odrzucić:

Oczywiście konto „służbowe” nie byłoby bardziej ani mniej bezpieczne niż konto „osobiste” dotyczące haseł. Ale gdy używasz GitHub, możesz naciskać za pomocą klucza SSH. I ten klucz zwykle leży w jednej sesji ... Tak więc konto osobiste może zagrozić wszystkim repozytoriom roboczym za pomocą prostej kradzieży komputera osobistego (bez znajomości hasła), podczas gdy dedykowane konto służbowe prawdopodobnie miałoby swój klucz tylko na komputerze roboczym, dzięki czemu bardziej fizycznie bezpieczny (miejmy nadzieję).


+1: Dwa punkty, o których nie myślałem: e-maile i klucze SSH. Chociaż oddzielne e-maile na GitHub stanowią problem, możesz skonfigurować wiele kluczy SSH dla swojego konta.
Jeremy Heiler,

@JeremyHeiler Co dokładnie rozumiesz przez „oddzielne e-maile w GitHub to problem?” . Używam trzy różne e-maile (stary, aktualny osobisty, praca jeden), po dodaniu ich do swojego profilu GitHub dopasowuje je z konta bez problemu :)
MattiSG

Miałem na myśli tę istotę . Czy mówisz, że jeśli umieścisz służbowy adres e-mail w git.config na komputerze służbowym i dodasz go do konta, wszystkie powiadomienia związane z pracą zostaną wysłane na Twój służbowy adres e-mail? Jeśli tak, to świetnie!
Jeremy Heiler

@JeremyHeiler O nie, ok, mieliśmy małe nieporozumienie z tym, co jest „problemem” w e-mailach :) Nie, tak jak powiedziałem w mojej odpowiedzi, zawsze otrzymujesz powiadomienia na swoim „głównym” (zazwyczaj osobistym) koncie. Ale to nie jest „problem”, ponieważ potrzebujesz konta dla każdego adresu do popełnienia: możesz powiązać z kontem dowolną liczbę e-maili, ale tylko jeden e-mail otrzymuje powiadomienia z twojego konta.
MattiSG,

Przepraszam, tak, powinienem być bardziej szczegółowy w moim wstępnym komentarzu :-P
Jeremy Heiler

9

Głosowałbym na „nie”. Jest to dość kłopotliwe dla programistów i zapewnia bezpieczeństwo poprzez zaciemnienie: jeśli ktoś aktywnie atakuje programistów, istnieje wiele innych wektorów ataku, aby ktoś mógł zdobyć Twój kod.

Dodatkowo, jako startup, chyba że masz wiele magicznych algorytmów typu sekretny sos w grze, ktoś otrzymujący Twój kod byłby zawstydzający, okropny i wstrętny, ale nie powinien dawać znaczącej przewagi konkurencyjnej (kto mógłby legalnie korzystać z twojego kod?) lub spowodować, że przestaniesz działać.

Tak małe prawdopodobieństwo zamówienia a produktywność programistów? Wziąłbym produktywność programistów, ale to mój rachunek. :)


2

Powiedziałbym, że powinien to być wybór dla pracownika. Powiedziałbym, że nie zmuszaj ich do używania osobistego konta github, jeśli nie chcą. Byłem w firmie, która korzystała z GitHub i chociaż nie było to wymagane, osobiście chciałem utworzyć osobne konto. Głównym powodem była ochrona moich osobistych projektów. Nie chciałem, żeby firma próbowała powiedzieć, że jeden z moich osobistych projektów był ich, ponieważ był pod tym samym kontem github, z którego korzystali w swoich projektach firmowych (nie jestem pewien, czy to się kiedykolwiek utrzyma w sądzie, ale nie mam zbyt wiele wiary w systemie prawnym, jeśli chodzi o takie rzeczy). Myślę, że oddzielne czyszczenie może być dobrą rzeczą.


2

Robimy to w naszej firmie. Nie chcę rozpoczynać dyskusji „co jest bezpieczniejsze, github lub serwer pod twoim stołem, że każdy ma dostęp do roota, nie jestem pewien, czy kopia zapasowa działa itp.”. Nasze podejście było następujące:

  • każdy programista musi utworzyć nowe konto, niezwiązane z jego osobistym kontem github
  • powinien używać firmowego adresu e-mail.
  • Powinien być zgodny z naszymi zasadami bezpieczeństwa (nazwa użytkownika i hasło).
  • Nie mogą pokazywać / prowadzić żadnej działalności publicznej.
  • To własność firmy. Nie jego konto.
  • Wszystkie konta są powiązane z firmą, a także nazwą losową. Brak aktywności publicznej.

2
Nie możesz egzekwować wymogu złożoności hasła, ponieważ nie masz sposobu na sprawdzenie hasła GitHub, więc po co je mieć?
Ramhound

cóż, mówisz, że jeśli nie jesteś w stanie technicznie egzekwować czegoś, nie egzekwujesz tego. Mówię, że jeśli pracownik czyta politykę bezpieczeństwa, a jeśli ją podpisuje, znając konsekwencje, jest to egzekwowanie.
VP.

3
Mówię, że nie możesz wiedzieć, że coś się nie dzieje, ponieważ nie masz możliwości zweryfikowania hasła utworzonego przez pracownika konta GitHub.
Ramhound

no cóż, jeśli na przykład konto zostanie przejęte, a my, jak niektórzy odkryjemy, że hasło to abc123, możemy „odpowiedzieć” pracownikowi. Nie widzę tutaj problemu. Kolejna kwestia: gdzie jest napisane, że go egzekwuję? Napisałem to musi (teraz zaktualizowałem do powinien) ...
VP.

To podejście musi zostać zahamowane za zgodą, że ta nazwa jest również ich własnością i nie podejmiesz żadnych działań w ich imieniu .
Michael

0

Rozumiem, że te pytania i odpowiedzi mają już kilka lat, więc być może nie było to wcześniej dostępne, ale wyraźnie stwierdzają w Różnicach między kontami użytkowników i organizacji, że:

Może być kuszące, aby mieć więcej niż jedno konto użytkownika, na przykład do użytku osobistego i służbowego, ale potrzebujesz tylko jednego konta.

GitHub zbudował dobre narzędzia do włączania / wyłączania powiadomień przez repozytorium i więcej, więc wydaje się, że połączenie osobistego / pracy jest najbardziej sensowne.


O co ci chodziło, prawda? Myślę, że to dobra odpowiedź.
John McGehee,

-2

Ludzie jeszcze nie ufają serwerom źródłowym opartym na chmurze. Github może się poszczycić wieloma firmami internetowymi nowej ery, ale tak naprawdę większość ludzi ma własne serwery do obsługi kodu źródłowego. Z mojego doświadczenia wynika, że ​​większość z nich korzysta z Clear-case lub SVN. Git ma dopiero zostać zaadaptowany w środowisku korporacyjnym. Nawet korporacyjne serwery pocztowe nie są tak naprawdę doceniane poza siedzibą firmy.


1
Obecnie pracuję w firmie usługowej, szkoliłem ich w Git, a większość ich klientów (np. Duże firmy) migruje z ClearCase lub przygotowuję się do tego w swoich kolejnych projektach…
MattiSG,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.