Де підтримувати центральне сховище джерела?

Яка найкраща практика в галузі щодо забезпечення доступу до вихідного коду? Я думаю, що з'єднання SSL тільки через apache дозволені до нашого сервера на незрозумілому порту, який не суперечить ні з чим іншим. Що мене турбує - це зберігання вихідного коду на загальнодоступному сервері, тобто не тільки доступному через локальну мережу. Більше того, цей сервер має кілька застосувань. Apache вже обслуговує деякі інші внутрішні веб-сайти компанії. Я хотів би, щоб усі мали доступ до вихідного коду з будь-якого місця (будинку, аеропорту та будь-якого іншого), якщо вони мають правильні дані. Пропозиції?

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

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

Наприклад, відомо, що PPTP має меншу, ніж ідеальну безпеку, хоча, я вважаю, він дещо покращився з моменту першого введення ... тому будьте уважні, яке VPN рішення ви використовуєте. Я б пішов з OpenVPN або IPSEC.

Однак ви не можете перемогти зручність SSL / TLS без VPN (читайте далі). А щоб зробити це ще більш безпечним, ви можете зробити його лише сертифікатом.

Однак, якщо ви думаєте, що ви можете запропонувати інші послуги, крім контролю джерел, тоді розгляньте рішення VPN, оскільки ви будете тунелювати інші послуги над ним.

Недоліком використання VPN є те, що ваш ПК стає ефективно частиною мережі, до якої він підключається. Це також може бути перевагою. Але якщо ви знаходитесь за мільйон миль від дому, а підключення до домашньої бази не надто швидке, то кожного разу, коли ви хочете зробити різний або перевірити код або вийти, ви можете виявити, що ви підключаєте та відключаєте VPN.

Я можу тут говорити з особистого досвіду, оскільки я розробник, і це було справжнім болем у грудничка це робити !!! В ідеалі кращі обидва варіанти.

Тож якщо ви збираєтеся переглядати Інтернет та ін., Це може зробити читання новин тощо досить повільним. Але принаймні ви отримуєте безпечний доступ до електронної пошти. Тож подумайте, як ви будете користуватися ним спочатку ... Якби я був ти, я б розглядав можливість реалізувати і те, і інше.

Насправді мені подобається ваша пропозиція. Якщо ви робите доступ до сховища вихідного коду ТІЛЬКИ за допомогою SSL / TLS, і переконуєтесь, що ваші розробники не використовують прості в образі парольні фрази (а ще краще - використовувати сертифікати), то це повинно бути так само безпечно, як будь-що .

Натомість ви можете сховати сервер всередині вашої локальної мережі та змусити розробників використовувати VPN, щоб отримати доступ, але це означає, що ваші розробники повинні ввести своє ім’я користувача / пароль (та / або сертифікат) в інше поле для входу. Я б рекомендував не створювати точку входу у вашу мережу, наслідки якої можуть бути не завжди очевидними, просто щоб дозволити доступ до однієї послуги. Якщо у вас вже налаштований VPN та захищено його для інших цілей, тоді впевнено, що це не просто, просто продовжуйте користуватися ним. В іншому випадку може бути простішим і, таким чином, більш безпечним зробити сам сервіс безпосередньо доступним через SSL / TLS.

Галузевий стандарт, ймовірно, залежить від того, якою є ваша (або ваші клієнти) галузі :-)

Практично вам потрібно врахувати, кому ви хочете надати доступ, і з чим вони можуть працювати. Деякі люди, до яких ви хочете / потребуєте доступу, не зможуть впоратися з набагато більшим, ніж ім'ям користувача / паролем. Інші, можливо, зможуть обійняти ssh і приватний ключ, за умови, що ви можете надійно дістати ключ до них, непогано. Клієнт TortoiseSVN може обробляти ssh + svn та підтримує приватні ключі з трохи скручуванням руки. Це було досить добре для моїх цілей.

Тунель VPN - це також корисна пропозиція, хоча в багатьох місцях ви були б раді надати стороннім людям доступ лише до вашого джерела контролю, але не до всієї вашої мережі!

Як і інші, я віддаю перевагу VPN. Альтернативою може бути тунель SSH, який, напевно, я вважаю, що це практичний вигляд VPN.

Зробіть це лише для внутрішнього використання та реалізуйте VPN-рішення віддаленого користувача. / Doh- дублікат.

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

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

Для Mercurial ви можете щільно зафіксувати речі, hg-sshобмеживши команди, доступні клієнтам, які підключаються через SSH. Використовуючи SSH, ви можете легко вимагати, щоб клієнти використовували аутентифікацію відкритого ключа замість паролів. Це захищає ваш сервер від жорстоких атак на вхід.

Навіть якщо ключ SSH порушений (можливо, він мав слабку фразу, а ноутбук, який зберігав його вкрадений), то найгірший збиток, який може зробити зловмисник, - це додати історію сміття в Mercurial. Використовуваний протокол по суті є лише додаванням, тому нічого не можна видалити hg push.

Для HTTPS аутентифікацію здійснює передній веб-сервер . Це означає, що ви можете вимагати сертифікати на сайті клієнта, якщо хочете, і таким чином отримуєте безпеку, як-от аутентифікація відкритого ключа SSH вище