Có nên yêu cầu nhân viên tạo tài khoản GitHub 'làm việc' không?

Tôi đã chuyển tất cả các kho Git của công ty chúng tôi sang GitHub và bây giờ tôi muốn thêm nhân viên vào các dự án. Vì hầu hết người lao động đã có tài khoản GitHub cá nhân, tôi tự hỏi liệu tôi có nên yêu cầu họ để tạo ra một công việc tài khoản GitHub. Lý do tôi nghĩ làm việc này là để giảm cơ hội truy cập trái phép vào cơ sở mã của chúng tôi vì tài khoản cá nhân của họ có thể được công khai thông qua hoạt động cá nhân của họ trên trang web, tăng cơ hội tấn công nhắm mục tiêu. Hơn nữa, nếu tài khoản cá nhân của họ bị xâm phạm, điều đó sẽ không có nghĩa là toàn bộ mã công ty có thể truy cập được đối với kẻ không tặc. Vì điều này sẽ mang lại gánh nặng duy trì hai tài khoản cho nhân viên, tôi tự hỏi liệu đó có phải là cách tiếp cận chính xác và liệu nó có hợp lý hay không.

Cập nhật Cảm ơn tất cả những hiểu biết hữu ích. Tôi sẽ không đặt câu trả lời là được chấp nhận vì tính chất chủ quan của câu hỏi / câu trả lời và vì tôi đã lấy điểm tốt nhất từ ​​một số câu trả lời khác nhau.

Tôi đã quyết định đi tiếp theo cách này: Tôi sẽ nhắc nhở nhân viên rằng các thông báo e-mail GitHub liên quan đến công việc sẽ phải được gửi đến tài khoản e-mail công việc của họ vì lý do thực tế. Do đó, sẽ có ý nghĩa hơn khi tạo tài khoản GitHub công việc. Nếu họ sẵn sàng sử dụng tài khoản GitHub cá nhân của họ và kết nối nó với tài khoản email công việc của họ thì không sao. Trong bất kỳ trường hợp nào, nhân viên sẽ phải đồng ý dưới dạng văn bản với một số điều kiện gắn liền với việc sử dụng GitHub. Những điều này liên quan đến bảo mật tài khoản: chọn mật khẩu an toàn bằng trình tạo mật khẩu ngẫu nhiên an toàn không được sử dụng với bất kỳ tài khoản nào khác, không truy cập GitHub thông qua các máy tính không do họ sở hữu hoặc quản lý, v.v ... Vào cuối ngày, nhân viên sẽ phải tự quyết định xem một tài khoản công việc có ý nghĩa hơn đối với họ hay không.

Nếu có một lợi ích, nó sẽ chỉ đau đớn. Nhưng không có gì tệ hơn là đau đớn và vô nghĩa. Chỉ cần có tài khoản cá nhân. Hai lý do:

• Github có quyền kiểm soát truy cập cực kỳ tốt trong các tổ chức của họ. Nếu một nhân viên rời đi, bạn có thể loại bỏ quyền truy cập của họ ngay lập tức. Nếu họ có tài khoản công ty, bạn phải lấy lại tài khoản bằng cách nào đó để nhận được các lợi ích đã nêu. Trong thực tế, có lẽ bạn chỉ cần xóa quyền truy cập tài khoản, giống như khi họ có tài khoản cá nhân.

• Có nhiều tài khoản là đau khổ. Đăng nhập và đăng xuất giữa các tài khoản gây tổn thương và thêm nhận xét, theo dõi và tất cả nội dung xã hội khi bạn sử dụng các tài khoản khác nhau.

Tham khảo: Tôi tạo một máy chủ CI có tích hợp GitHub , vì vậy tôi có rất nhiều tài khoản thử nghiệm và tôi đã nói chuyện với khách hàng với tất cả các loại cấu hình kỳ lạ, bao gồm các tài khoản cá nhân và tài khoản cá nhân. Nó luôn dẫn đến rắc rối.

Mã của công ty bạn trong kho công cộng hay riêng tư? Nếu họ (hoặc ít nhất là một số) là công khai và bạn cho phép nhân viên của mình sử dụng tài khoản GitHub của riêng họ, thì đó sẽ là một động lực để họ viết mã tốt. Tên của họ theo nghĩa đen sẽ được gắn liền với nó, công khai. Tuy nhiên, tôi sẽ cho rằng tất cả các kho lưu trữ của bạn là riêng tư.

Nhìn chung, có vẻ như bạn muốn các tài khoản của nhân viên của mình không hiển thị công khai trên toàn GitHub. Thật không may, họ kiếm tiền bằng cách bán GitHub Enterprise vì vậy tôi tưởng tượng đó là một lý do tại sao họ không cho phép bạn tạo tài khoản riêng cho các tổ chức. Trong cả hai trường hợp, việc có (về cơ bản) các tài khoản công việc bị khóa sẽ thực sự phản tác dụng sau khi chọn một trang web rất xã hội để lưu trữ kho lưu trữ của bạn.

Hãy tưởng tượng rằng bạn đã thiết lập tài khoản làm việc cho nhân viên của mình. Bạn có thực thi bất kỳ hạn chế nào về cách họ có thể sử dụng các tài khoản đó không? Bạn có cho phép họ đóng góp mã cho các dự án phi công việc cho mục đích công việc không? Nếu vậy, tài khoản của họ sẽ hiển thị công khai, đưa bạn trở lại mối quan tâm ban đầu của bạn. Bạn chỉ có thể cho phép họ đóng góp bằng tài khoản cá nhân của mình, nhưng sau đó bạn đang tạo ra một điểm đau hậu cần cho họ. Cá nhân, tôi sẽ khuyến khích nhân viên của mình đóng góp mã cho các dự án khác như chính họ. Điều này không chỉ giúp họ tăng cường sự tự tin, nó còn cho phép họ có được kinh nghiệm quý giá và xây dựng uy tín của họ.

Trong mọi trường hợp, tôi không nghĩ rằng nó đáng để nỗ lực để có tài khoản làm việc. Giao diện GitHub cho phép bạn dễ dàng kiểm soát ai có quyền truy cập vào cái gì, vì vậy việc loại bỏ quyền truy cập cũng đơn giản. Tôi cũng không nghĩ rằng việc có các tài khoản riêng biệt thực sự "vẽ ra một ranh giới" giữa các dự án cá nhân và công việc nữa so với giao diện GitHub đã làm.

Ngoài ra, hãy ghi nhớ cách bạn lên kế hoạch đối phó với điều này khi công ty của bạn phát triển. Các chính sách bạn đặt tại chỗ bây giờ sẽ có thể mở rộng từ quan điểm quản lý? Quản lý 5 tài khoản ngay bây giờ có thể ổn, nhưng điều gì xảy ra khi bạn tăng lên 20 hoặc 50? Nhưng một khi bạn đạt đến điểm đó, có thể GitHub Enterprise sẽ là một giải pháp dễ tiếp cận. Trong trường hợp đó, tôi sẽ xem xét việc tìm hiểu xem tài khoản GitHub có thể được chuyển sang cài đặt GitHub Enterprise hay không. Nếu vậy, tôi có thể thấy rằng đó là một lý do tích cực để có tài khoản công việc.

Không nằm ngoài câu hỏi, và thực sự là một ý tưởng khá hay.

Đáng tiếc vì có thể, bạn cần lập kế hoạch cho nhân viên của mình rời khỏi tổ chức tại một số thời điểm trong cuộc sống của công ty. Làm thế nào bạn sẽ thoát tài khoản cá nhân của họ khỏi kho lưu trữ của công ty tại thời điểm đó?

Bạn sẽ làm gì nếu nhân viên nghỉ việc vì điều khoản tồi? Trong một thế giới lý tưởng, mọi thứ sẽ vẫn chuyên nghiệp và sẽ không có bất kỳ sự thù hằn nào giữa công ty và nhân viên cũ. Bạn sẽ thận trọng lên kế hoạch cho những trường hợp không lý tưởng.

Mặc dù duy trì hai tài khoản là một nỗi đau, nhân viên của bạn nên đón nhận cơ hội. Nó cung cấp một ranh giới sạch hơn giữa những gì là của họ và những gì là của công ty.

Chỉnh sửa: Mối quan tâm ở đây là cung cấp một sự tách biệt rõ ràng giữa các đóng góp cá nhân của nhân viên cho các dự án X, Y, Z, v.v ... và công việc được trả lương của họ trên sản phẩm của công ty bạn. Sử dụng một tài khoản công việc riêng biệt giúp cung cấp sự phân định cần thiết để xác định ai sở hữu tài sản trí tuệ và bản quyền liên quan.

Ví dụ: nếu một nhân viên sử dụng tài khoản cá nhân của họ và đóng góp cho cả công ty và Dự án X, làm thế nào để bạn xác định vai trò của nhân viên đó vào những thời điểm đó là gì? Là sự đóng góp cho X thay mặt cho công ty của bạn hoặc theo ý riêng của họ? Nhân viên hoặc công ty có sở hữu bản quyền tác phẩm đó được trao cho X không? Đối với vấn đề đó, nếu bạn cho phép đóng góp bên ngoài cho công việc của công ty, làm thế nào để bạn phân biệt nếu nhân viên là nhân viên hoặc nếu đó là đóng góp tự nguyện?

Theo nghĩa rộng hơn, giả sử bạn có một nhân viên xây dựng danh tiếng thay mặt công ty bằng cách đóng góp cho các dự án khác. Khi nhân viên đó rời đi, làm thế nào để bạn chỉ ra rằng tài khoản người dùng cá nhân không còn liên kết với công ty của bạn? Các vấn đề thương hiệu nghiêm trọng có thể xảy ra mà không phân định rõ ràng về những gì một tài khoản cụ thể dành cho.

Khá dễ dàng để rơi vào mối quan tâm về quyền sở hữu, thương hiệu và bản quyền khi bạn bắt đầu suy nghĩ về các kịch bản tiềm năng. Sử dụng các tài khoản công việc riêng biệt giúp loại bỏ một số sự mơ hồ này. Công ty cần có khả năng đưa ra yêu cầu đối với các khoản đóng góp được thực hiện dưới tên của mình.

Đây không phải là về các khía cạnh kỹ thuật trong việc tách tài khoản người dùng, đó là những câu hỏi pháp lý có thể khiến bạn gặp khó khăn.

Lưu ý rằng đây có thể là điểm tranh luận nếu tất cả các sản phẩm của công ty bạn được phát hành dưới dạng nguồn mở theo giấy phép cho phép và / hoặc bạn không lo lắng gì về các vấn đề thương hiệu tiềm năng.
(Hat tip cho Paul Biggar để yêu cầu chỉnh sửa này)

Vì mọi người dường như đồng ý về việc thiếu nhà tuyển dụng cần phải tách cả hai, đây là kinh nghiệm ngắn của tôi khi thử sử dụng tài khoản cá nhân của tôi cho các dự án chuyên nghiệp và đóng góp nguồn mở được thực hiện trong bối cảnh công việc.

Chỉ để làm cho bối cảnh hoàn chỉnh: Tôi không được hỏi bất cứ điều gì liên quan đến các tài khoản, thực sự GitHub không được biết đến với hầu hết mọi người tại nơi làm việc của tôi. Tôi chỉ đơn giản là có thể bật đèn xanh cho nguồn mở dự án mà tôi sẽ thực hiện và đã thực hiện với số lượng công việc ít nhất, tức là sử dụng tài khoản cá nhân của tôi.

Từ quan điểm của một nhân viên, một điều tôi thực sự ghét: nhận thông báo trên email cá nhân của tôi cho công việc.

Từ quan sát đó, tôi nhận ra rằng đó là một sự phá vỡ trắng trợn về rào cản nghề nghiệp / cá nhân: nếu tôi muốn đóng góp cho một dự án trong thời gian rảnh, tôi vẫn nhận được tất cả các cập nhật từ các dự án công việc của mình. Và nó có thể gây nhầm lẫn cho những người đóng góp bên ngoài , người có thể liên lạc với bạn mà không biết bạn rời khỏi dự án đó .

Tất nhiên, sau đó, có một sự cân bằng để tìm thấy với thực tế là danh tiếng cá nhân của bạn có thể đạt được từ những đóng góp công việc của bạn. Nhưng một lần nữa, nó có thể ngược lại nếu tên của bạn được liên kết với một dự án nghèo

Cuối cùng, khi câu hỏi được đặt ra theo quan điểm của nhà tuyển dụng , và xem xét tất cả các câu trả lời khác: Tôi có thể nói rằng có lẽ không có nhiều điểm trong việc thực thi bằng cách sử dụng các tài khoản dành riêng cho công việc . Nhưng bạn không nên cấm nó, để những nhân viên thích nâng cao rào cản cá nhân có thể làm như vậy, và có lẽ gợi ý về những rủi ro đó?

Là một lưu ý phụ, liên quan đến bảo mật, vì dường như có một số bác bỏ dễ dàng trong các câu trả lời khác:

Tất nhiên, tài khoản của một công việc trên mạng sẽ không an toàn hơn hoặc kém hơn một tài khoản cá nhân trên mạng về mật khẩu. Nhưng khi bạn đang sử dụng GitHub, bạn được phép sử dụng khóa SSH. Và khóa đó thường nằm trong phiên của một người. Vì vậy, tài khoản cá nhân có thể thỏa hiệp tất cả các kho lưu trữ công việc với một vụ đánh cắp máy tính cá nhân đơn giản (không có kiến ​​thức về mật khẩu), trong khi một tài khoản làm việc chuyên dụng có thể chỉ có khóa của nó trên máy làm việc, làm cho nó an toàn hơn về mặt vật lý (hy vọng).

Tôi sẽ bình chọn "Không". Đó là một chút rắc rối cho các nhà phát triển của bạn và cung cấp cho bạn bảo mật thông qua che khuất: nếu ai đó chủ động nhắm mục tiêu vào nhà phát triển của bạn, có rất nhiều vectơ tấn công khác để ai đó lấy mã của bạn.

Ngoài ra, là một công ty khởi nghiệp trừ khi bạn có nhiều thuật toán loại nước sốt bí mật khi chơi, ai đó nhận được mã của bạn sẽ rất xấu hổ, và khủng khiếp và đáng ghét, nhưng không nên mang lại lợi thế cạnh tranh đáng kể (ai có thể sử dụng hợp pháp của bạn mã?) hoặc khiến bạn ra khỏi doanh nghiệp.

Như vậy xác suất đặt hàng thấp so với năng suất của nhà phát triển? Tôi sẽ lấy năng suất của nhà phát triển, nhưng đó là tính toán của tôi. :)

Tôi sẽ nói rằng đó là một sự lựa chọn tùy thuộc vào nhân viên. Một điều tôi muốn nói là đừng ép họ sử dụng tài khoản github cá nhân của họ nếu họ không muốn. Tôi đã ở một công ty sử dụng GitHub và trong khi đó không phải là một yêu cầu, cá nhân tôi muốn tạo một tài khoản riêng. Lý do chính là để bảo vệ các dự án cá nhân của tôi. Tôi không muốn công ty cố gắng nói một trong những dự án cá nhân của tôi là của họ bởi vì nó nằm trong cùng một tài khoản github được sử dụng cho các dự án comapny của họ (không chắc điều đó có giữ được trước tòa hay không nhưng tôi không có nhiều niềm tin trong hệ thống pháp lý khi nói đến những thứ như thế này). Tôi nghĩ rằng có riêng biệt sạch sẽ có thể là một điều tốt.

Chúng tôi đang làm điều đó trong công ty của chúng tôi. Tôi không muốn bắt đầu một cuộc thảo luận "cái gì an toàn hơn, github hoặc máy chủ dưới bàn của bạn mà mọi người đều có quyền truy cập root, không chắc bản sao lưu có hoạt động không, v.v.". Cách tiếp cận của chúng tôi là:

• mỗi nhà phát triển, phải tạo một tài khoản mới, không liên quan đến tài khoản github cá nhân của anh ta
• nó nên sử dụng email của công ty
• Nó phải tuân thủ các quy tắc bảo mật của chúng tôi (tên đăng nhập và yêu cầu mật khẩu).
• Họ không thể hiển thị / có bất kỳ hoạt động nào.
• Đó là tài sản của công ty. Không phải tài khoản của anh ấy / cô ấy.
• Tất cả các tài khoản được kết nối với một công ty, tên ngẫu nhiên là tốt. Không có hoạt động công cộng là tốt.

Tôi nhận ra Câu hỏi và trả lời này đã được vài năm tuổi, vì vậy có thể điều này chưa có trước đây, nhưng chúng nêu cụ thể về Sự khác biệt giữa tài khoản người dùng và tổ chức :

Có thể có nhiều tài khoản người dùng, chẳng hạn như sử dụng cá nhân và sử dụng kinh doanh, nhưng bạn chỉ cần một tài khoản.

GitHub đã xây dựng các công cụ tốt để bật / tắt thông báo theo kho lưu trữ và hơn thế nữa, dường như việc kết hợp cá nhân / công việc có ý nghĩa nhất.

Mọi người vẫn chưa tin tưởng các máy chủ nguồn dựa trên đám mây. Github tự hào có rất nhiều công ty web thời đại mới đã đăng ký với họ nhưng thực tế là, hầu hết mọi người đều có máy chủ riêng để duy trì mã nguồn. Theo kinh nghiệm của tôi, hầu hết trong số họ sử dụng Clear-case hoặc SVN. Git vẫn chưa được điều chỉnh trong môi trường doanh nghiệp. Ngay cả các máy chủ thư của công ty cũng không thực sự được đánh giá cao bên ngoài cơ sở của công ty.