Чи доцільно попросити співробітників створити "робочі" акаунти GitHub?

Я перемістив усі наші сховища компанії Git до GitHub, і тепер я хочу додати співробітників до проектів. Оскільки більшість співробітників вже мають особисті облікові записи GitHub, мені цікаво, чи варто мені просити їх створити робочий рахунок GitHub. Причиною того, що я думаю зробити це, є зниження шансів на несанкціонований доступ до нашої кодової бази, оскільки їхні особисті акаунти можуть бути широко розрекламовані через їх особисту активність на сайті, збільшуючи шанси на націлені атаки. Крім того, якщо їх особистий рахунок буде коли-небудь порушений, це не означає, що весь код компанії доступний для викрадача. Оскільки це спричинить тягар ведення двох рахунків для працівників, мені цікаво, чи це правильний підхід і чи це навіть має сенс.

Оновіть подяку за всі корисні відомості. Я не буду встановлювати відповідь як прийняту через суб'єктивний характер питання / відповідей, і оскільки я взяв кращі бали з кількох різних відповідей.

Я вирішив іти вперед таким чином: нагадаю працівникам, що сповіщення електронної пошти про GitHub, пов’язані з роботою, доведеться надсилати на свої робочі рахунки електронної пошти з практичних причин. Тому було б більше сенсу створювати робочі акаунти GitHub. Якщо вони бажають використовувати свої особисті облікові записи GitHub і підключити їх до своїх робочих облікових записів електронної пошти, це добре. У будь-якому випадку, працівникам доведеться погодитись у письмовій формі на низку умов, пов’язаних із використанням GitHub. Вони пов'язані із захистом облікового запису: вибір захищеного пароля за допомогою захищеного генератора випадкових паролів, який не використовується з будь-яким іншим обліковим записом, не доступ до GitHub через комп’ютери, які не належать до них та не управляються ними тощо. Наприкінці робочого дня працівники повинні будуть самі вирішують, чи має робочий рахунок більше сенсу для них чи ні.

Якби була користь, це було б просто боляче. Але нічого не смокче гірше, ніж болісно і безглуздо. Просто мати єдиний особистий рахунок. Дві причини:

• Github має надзвичайно хороший контроль доступу у своїх організаціях. Якщо працівник піде, ви можете миттєво видалити їх доступ. Якщо у них був обліковий запис компанії, вам доведеться якось повернути рахунок, щоб отримати зазначені переваги. На практиці ви, ймовірно, просто видалите доступ до облікового запису так само, як якщо б у них був особистий рахунок.

• Мати більше одного акаунта - боляче. Увійти та вийти між обліковими записами шкодить, а також додавати коментарі, дотримуватися та всі соціальні матеріали, коли ви використовуєте різні облікові записи.

Посилання: я роблю сервер CI, який має інтеграцію з GitHub , тому у мене є багато тестових облікових записів, і я спілкувався з клієнтами з усілякими дивними конфігураціями, включаючи окремі робочі рахунки та особисті рахунки. Це завжди призводить до неприємностей.

Чи код вашої компанії в державних чи приватних сховищах? Якщо вони (або принаймні деякі) є публічними, і ви дозволили своїм співробітникам користуватися власними обліковими записами GitHub, це буде стимулом для них писати хороший код. Їх ім’я буквально було б приєднано до нього, публічно. Однак я припускаю, що всі ваші сховища приватні.

В цілому, це здається, що ви хочете, щоб рахунки вашого працівника не були відкрито видимими в GitHub. На жаль, вони заробляють гроші, продаючи GitHub Enterprise, тому я думаю, що це одна з причин, чому вони не дозволяють створювати приватні акаунти для організацій. У будь-якому випадку наявність (по суті) заблокованих робочих облікових записів було б дуже неінтуїтивно зрозумілим після вибору дуже соціального сайту для розміщення ваших сховищ.

Давайте уявимо, що ви створили робочі рахунки для своїх співробітників. Чи застосовуватимете ви будь-які обмеження щодо використання ними цих облікових записів? Чи дозволяєте ви їм вносити код у неробочі проекти для робочих цілей? Якщо так, то їхні рахунки стануть загальнодоступними, що поверне вас до вашого первинного занепокоєння. Ви можете просто дозволити їм робити внески зі своїми особистими рахунками, але тоді ви створюєте для них логічний біль. Особисто я б закликав своїх співробітників вносити коди в інші проекти як самі. Це не тільки підсилює впевненість у собі, це дозволяє їм набути цінного досвіду та створити свій авторитет.

У будь-якому випадку, я не думаю, що варто мати зусиль, щоб мати робочі рахунки. Інтерфейс GitHub дозволяє легко контролювати, хто має доступ до чого, тому видалити доступ простий у будь-якому випадку. Я також не думаю, що наявність окремих облікових записів насправді «малює межу» між особистими та робочими проектами більше, ніж це вже робить інтерфейс GitHub.

Також майте на увазі, як ви плануєте займатися цим у міру розвитку вашої компанії. Чи змінюватимуться політики, які ви встановлюєте зараз, масштабуватися з точки зору управління? Зараз керування 5 обліковими записами може бути добре, але що станеться, коли ви зросте до 20 чи 50? Але як тільки ви досягнете цього пункту, можливо, GitHub Enterprise стане доступним рішенням. У такому випадку я б подумав з'ясувати, чи можна мігрувати облікові записи GitHub до встановлень GitHub Enterprise. Якщо так, я бачу, що це є однією з позитивних причин мати робочі рахунки.

Немає сумніву, а насправді досить гарна ідея.

Як це не шкода, потрібно запланувати, як ваші співробітники залишають організацію в якийсь момент життя компанії. Як ви збираєтеся вилучити їх особисті рахунки з сховища компанії в цей час?

Що ви збираєтеся робити, якщо працівник піде з поганих умов? В ідеальному світі все залишиться професійним, і між фірмою та колишнім співробітником не виникне ворожість. Ви б розсудливо планували обставини, що не ідеальні.

Хоча ведення двох рахунків - це біль, ваші співробітники повинні вітати таку можливість. Він забезпечує більш чітку межу між тим, що є їхнім, і тим, що є в компанії.

Редагувати: Тут викликає занепокоєння чіткий поділ між особистими внесками працівника в проекти X, Y, Z тощо ... та їх оплачуваною роботою над продуктом вашої компанії. Використання окремого робочого облікового запису допомагає надати розмежування, необхідне для визначення того, хто належить до якої інтелектуальної власності та пов’язаних авторських прав.

Наприклад, якщо працівник використовує свій особистий рахунок та вносить внесок як у компанію, так і в проект X, як ви визначите, яку роль у цьому моменті виконував працівник? Чи був внесок у X від імені вашої компанії чи на власний особистий розсуд? Чи працівник чи компанія володіють авторськими правами на цей твір, наданим компанії X? З цього питання, якщо ви дозволяєте внести внески на роботу вашої компанії, як ви розрізняєте, чи був цей працівник працівником чи це добровільний внесок?

У більш широкому розумінні, скажіть, у вас є працівник, який формує репутацію, яка діє від імені компанії, беручи участь у інших проектах. Коли цей працівник відходить, як ви вказуєте, що особистий обліковий запис користувача більше не пов’язаний з вашою фірмою? Серйозні проблеми з брендом можуть виникати без чіткого визначення того, для чого конкретний рахунок.

Коли ви починаєте продумувати потенційні сценарії, досить легко зайнятися проблемою щодо власності, торгової марки та авторських прав. Використання окремих робочих рахунків допомагає усунути частину цієї неоднозначності. Компанія повинна мати можливість пред'явити претензії на внески, внесені на її ім'я.

Справа не в технічних аспектах відокремлення облікового запису користувача, а в юридичних питаннях, які можуть вас зацікавити.

Зауважте, що це може бути суперечливим, якщо продукція вашої компанії буде випущена як відкритий код під дозвільним ліцензуванням та / або ви зовсім не переймаєтесь можливими проблемами брендингу.
(Підказка капелюха до Пола Біггара прохання про це редагування)

Оскільки, схоже, всі згодні з відсутністю потреби роботодавця розділяти обидва, ось мій короткий досвід, спробувавши використовувати свій особистий рахунок на професійні проекти та відкриті вклади, внесені в контексті роботи.

Тільки для того, щоб контекст був повним: мене нічого не запитували щодо акаунтів, насправді GitHub невідомий більшості людей на моєму робочому місці. Я просто зміг отримати зелені вогні, щоб відкрити проект, над яким я буду працювати, і пішов з найменшою кількістю роботи, тобто використовуючи мій особистий рахунок.

З точки зору працівника, я дуже ненавиджу одне: отримання сповіщень на мою особисту електронну пошту для роботи.

З цього спостереження я зрозумів, що це кричуще порушення професійного / особистого бар'єру: якщо я хочу внести свій внесок у проект у неробочий час, я все одно отримую всі оновлення від своїх робочих проектів ... І це може спричинити плутанину для зовнішніх учасників , який може зв’язатися з вами, не знаючи, що ви не працюєте з цим проектом

Тоді, звичайно, є баланс, який можна знайти з того факту, що ваша особиста репутація може отримати ваші трудові внески. Але знову ж таки, може статися навпаки, якщо ваше ім’я асоціюється з поганим проектом ...

Зрештою, як питання задається з точки зору роботодавця , так і з огляду на всі інші відповіді: я б сказав, що, мабуть, немає особливого сенсу в застосуванні використання спеціальних облікових записів . Але ви не повинні забороняти це, щоб працівники, які вважають за краще підвищити особистий бар'єр, могли це зробити, і, можливо, натякають на ці ризики…?

Як зауваження, що стосується безпеки, оскільки в інших відповідях, мабуть, є легке звільнення:

Звичайно, "робочий" акаунт не був би більш-менш безпечним, ніж "особистий" рахунок щодо паролів. Але коли ви використовуєте GitHub, вам дозволяється натискати клавішу SSH. І цей ключ, як правило, лежить в сеансі ... Отже, особистий обліковий запис може компрометувати всі робочі сховища простою крадіжкою персонального комп’ютера (без знання пароля), тоді як спеціалізований робочий рахунок, мабуть, матиме свій ключ лише на робочій машині, роблячи це більш фізично захищені (сподіваємось).

Я б проголосував «Ні». Це досить багато клопоту для ваших розробників і надає вам безпеку через незрозумілість: якщо хтось активно націлений на ваших розробників, існує безліч інших векторів атак, щоб хтось міг отримати ваш код.

Крім того, як запуск, якщо у вас є безліч чарівних алгоритмів типу секретного соусу, коли хтось отримує ваш код, це буде бентежно, жахливо і неприємно, але не повинно спричинити значну конкурентну перевагу (хто може юридично використовувати ваш код?) або змусить вас вийти з бізнесу.

Така низька ймовірність замовлення проти продуктивності розробника? Я брав би продуктивність для розробників, але це моє обчислення. :)

Я б сказав, що вибір повинен залишатися за працівником. Я б сказав, що не змушуйте їх використовувати свій особистий обліковий запис github, якщо вони цього не хочуть. Я був у компанії, яка використовувала GitHub, і хоча це не було вимогою, я особисто хотів створити окремий рахунок. Основна причина - захист моїх людей проектів. Я не хотів, щоб компанія намагалася сказати, що один із моїх особистих проектів був їхнім, тому що він знаходився під тим самим обліковим записом github, який використовувався для їхніх комерційних проектів (не впевнений, чи коли-небудь це затримає в суді, але я не маю багато віри в правовій системі, коли мова йде про подібні речі). Я думаю, що чистий окремий може бути хорошою справою.

Ми робимо це в нашій компанії. Я не хочу розпочинати дискусію "що безпечніше, github чи сервер під вашим столом, щоб усі мали доступ до root, не впевнені, чи працює резервна копія тощо". Наш підхід:

• кожен розробник повинен створити новий обліковий запис, не пов’язаний із його особистим обліковим записом github
• вона повинна використовувати електронний лист компанії.
• Він повинен відповідати нашим правилам безпеки (ім'я для входу та пароль).
• Вони не можуть показувати / не мати жодної публічної діяльності.
• Це власність компанії. Не його рахунок.
• Всі рахунки пов'язані з компанією, а також випадковою назвою. Також немає жодної публічної активності.

Я усвідомлюю, що цьому питанню є кілька років, тому, можливо, раніше цього не було, але вони конкретно вказують на відмінності між обліковими записами користувачів та організацій, що:

Можливо, заманливо мати кілька облікових записів користувачів, наприклад, для особистого та ділового використання, але вам потрібен лише один обліковий запис.

GitHub створив хороші інструменти для ввімкнення / вимкнення сповіщень у сховищах, і тим більше здається, що поєднувати особисте / робоче значення має найбільш сенс.

Люди ще довіряють хмарним вихідним серверам. Github може похвалитися великою кількістю веб-компаній нового віку, які підписалися з ними, але справжній факт полягає в тому, що більшість людей мають власні сервери для підтримки вихідного коду. На мій досвід, більшість із них використовує або Clear-case, або SVN. Git ще належить адаптувати в умовах підприємства. Навіть сервери корпоративної пошти не дуже оцінені поза приміщеннями компанії.