Nơi duy trì kho nguồn trung tâm?

Thực tiễn tốt nhất trong ngành liên quan đến việc đảm bảo quyền truy cập vào mã nguồn là gì? Tôi nghĩ rằng các kết nối SSL chỉ thông qua apache được phép đến máy chủ của chúng tôi trên một cổng tối nghĩa không xung đột với bất cứ điều gì khác. Điều làm phiền tôi là lưu trữ mã nguồn trên một máy chủ công khai, tức là không chỉ có thể truy cập qua mạng LAN. Hơn nữa, máy chủ này có một số cách sử dụng. Apache đang phục vụ một số trang web công ty nội bộ khác. Tôi muốn tất cả mọi người có thể truy cập mã nguồn từ bất cứ đâu (nhà, sân bay, bất cứ điều gì) miễn là họ có thông tin xác thực chính xác. Gợi ý?

Nếu bạn lo lắng về việc nó đang ở trên một máy chủ công khai nhưng muốn truy cập từ bất cứ đâu, bạn nên xem xét việc các nhà phát triển của bạn sử dụng VPN dựa trên máy khách để đăng nhập vào mạng của bạn từ xa để truy cập máy chủ kiểm soát nguồn nội bộ.

Tôi không chắc tại sao mọi người lại nghĩ cách tiếp cận VPN là tốt nhất. Nó không nhất thiết phải an toàn hơn và chỉ cung cấp một lợi thế mà tôi có thể nghĩ đến.

Ví dụ, PPTP được biết là có bảo mật kém hơn lý tưởng, mặc dù tôi tin rằng nó đã được cải thiện phần nào kể từ lần đầu tiên được giới thiệu ... vì vậy hãy cẩn thận với giải pháp VPN nào bạn sử dụng. Tôi sẽ dùng OpenVPN hoặc IPSEC.

Tuy nhiên, bạn không thể đánh bại sự tiện lợi của SSL / TLS mà không cần VPN (đọc thêm xuống). Và để làm cho nó an toàn hơn nữa, bạn chỉ có thể làm cho nó chứng chỉ.

Tuy nhiên, nếu bạn nghĩ rằng bạn có thể cung cấp các dịch vụ khác ngoài kiểm soát nguồn thì hãy xem xét giải pháp VPN vì bạn sẽ vượt qua các dịch vụ khác.

Nhược điểm khi sử dụng VPN là PC của bạn trở thành một phần hiệu quả của mạng mà nó kết nối. Đó cũng có thể là một lợi thế. Nhưng, nếu bạn là một triệu dặm xa nhà và kết nối mạng để cơ sở nhà không phải là quá nhanh chóng sau đó mỗi khi bạn muốn làm một diff hoặc check in hoặc ra mã bạn có thể tìm cho mình kết nối và ngắt kết nối VPN.

Tôi có thể nói từ kinh nghiệm cá nhân ở đây vì tôi là một nhà phát triển và thật đau đớn khi ăn mày khi làm điều này !!! Lý tưởng nhất, cả hai lựa chọn đều được ưa thích.

Vì vậy, nếu bạn đang duyệt web, v.v. thì nó có thể khiến việc đọc tin tức v.v ... khá chậm. Nhưng ít nhất bạn có được quyền truy cập an toàn vào email. Vì vậy, hãy xem xét cách bạn sẽ sử dụng nó trước tiên ... Nếu tôi là bạn, tôi sẽ xem xét thực hiện cả hai.

Thật ra, tôi thích đề nghị của bạn. Nếu bạn làm cho kho lưu trữ mã nguồn của mình CHỈ có thể truy cập thông qua SSL / TLS và bạn chắc chắn rằng các nhà phát triển của bạn không sử dụng cụm mật khẩu dễ sử dụng (hoặc tốt hơn nữa, hãy sử dụng chứng chỉ), thì điều đó sẽ an toàn như mọi thứ .

Thay vào đó, bạn có thể ẩn máy chủ của mình trong mạng LAN và buộc các nhà phát triển sử dụng VPN để có quyền truy cập, nhưng điều đó chỉ có nghĩa là nhà phát triển của bạn cần đặt tên người dùng / mật khẩu (và / hoặc chứng chỉ) của họ vào một hộp đăng nhập khác. Tôi khuyên bạn không nên tạo một điểm truy cập vào mạng của bạn mà ý nghĩa bảo mật có thể không phải lúc nào cũng rõ ràng, chỉ để cho phép truy cập vào một dịch vụ duy nhất. Nếu bạn đã cấu hình và bảo mật VPN cho các mục đích sử dụng khác, thì chắc chắn, đó là một kẻ không có trí tuệ, hãy tiếp tục và sử dụng nó. Mặt khác, nó có thể đơn giản hơn và do đó an toàn hơn để cung cấp dịch vụ trực tiếp qua SSL / TLS.

Tiêu chuẩn ngành có thể phụ thuộc vào ngành của bạn (hoặc khách hàng của bạn) là gì :-)

Thực tế bạn cần xem xét những người bạn muốn cung cấp quyền truy cập và những gì họ có thể xử lý. Một số người bạn có thể muốn / cần truy cập sẽ không thể đối phó với nhiều hơn một tên người dùng / mật khẩu. Những người khác có thể có được đầu của họ xung quanh ssh và một khóa riêng, với điều kiện bạn có thể lấy chìa khóa cho họ một cách an toàn, không tệ. Ứng dụng khách rùaSVN có thể xử lý ssh + svn và hỗ trợ các khóa riêng với một chút vặn tay. Điều đó đã đủ tốt cho mục đích của tôi.

Đường hầm VPN cũng là một gợi ý hợp lý, mặc dù ở nhiều nơi bạn sẽ vui lòng cấp cho người bên ngoài quyền truy cập vào chỉ kiểm soát nguồn của bạn, nhưng không phải toàn bộ mạng của bạn!

Giống như những người khác, tôi thích VPN. Một giải pháp thay thế sẽ là một đường hầm SSH, mà tôi cho rằng về mặt thực tế là một loại VPN.

Làm cho nó chỉ nội bộ và thực hiện một giải pháp VPN người dùng từ xa. / Doh- trùng lặp.

Nếu bạn muốn truy cập từ bất cứ đâu, thì bạn cần một máy chủ đối mặt công khai - điều đó là rõ ràng.

Trên máy chủ đó, bạn muốn phơi bày càng ít càng tốt , tốt nhất chỉ là Mercurial / Subversion và không có gì khác. Điều này là để ngăn chặn sự vi phạm trong bảo mật lây lan từ kiểm soát nguồn sang phần còn lại của công ty bạn. Vì lý do đó, tôi sẽ đồng ý với Matt khi anh ta nói rằng VPN có thể nguy hiểm: nó cho phép truy cập rộng hơn nhiều so với mức cần thiết.

Đối với Mercurial, bạn có thể khóa chặt mọi thứ bằng cách sử dụng hg-sshđể hạn chế các lệnh có sẵn cho các máy khách kết nối qua SSH. Bằng cách sử dụng SSH, bạn có thể dễ dàng yêu cầu khách hàng sử dụng xác thực khóa chung thay vì mật khẩu. Điều này bảo vệ máy chủ của bạn chống lại các cuộc tấn công đăng nhập vũ phu.

Ngay cả khi khóa SSH bị xâm phạm (có lẽ nó có cụm mật khẩu yếu và máy tính xách tay lưu trữ nó đã bị đánh cắp), thì thiệt hại tồi tệ nhất mà kẻ tấn công có thể làm là thêm lịch sử rác vào Mercurial. Giao thức được sử dụng vốn chỉ là phụ lục, vì vậy không có gì có thể bị xóa hg push.

Đối với HTTPS, việc xác thực được thực hiện bởi máy chủ web mặt trước . Điều này có nghĩa là bạn có thể yêu cầu chứng chỉ trang web của khách hàng nếu bạn muốn và do đó có được bảo mật như xác thực khóa công khai SSH ở trên.