Gdzie utrzymywać centralne repozytorium źródeł?

Jaka jest najlepsza praktyka w branży w zakresie zabezpieczania dostępu do kodu źródłowego? Myślę, że tylko połączenia SSL przez apache są dozwolone na naszym serwerze na niejasnym porcie, który nie powoduje konfliktów z niczym innym. Niepokoi mnie przechowywanie kodu źródłowego na publicznym serwerze, to znaczy nie tylko dostępnym przez LAN. Co więcej, ten serwer ma kilka zastosowań. Apache obsługuje już inne wewnętrzne witryny firmowe. Chciałbym, aby każdy mógł uzyskać dostęp do kodu źródłowego z dowolnego miejsca (domy, lotnisko, cokolwiek), o ile mają prawidłowe poświadczenia. Propozycje?

Jeśli obawiasz się, że znajduje się on na publicznym serwerze, ale chciałbyś uzyskać dostęp z dowolnego miejsca, powinieneś rozważyć, aby programiści używali klienta VPN do zdalnego logowania do sieci w celu uzyskania dostępu do wewnętrznego serwera kontroli źródła.

Nie jestem zbyt pewien, dlaczego ludzie uważają, że VPN jest najlepszy. Niekoniecznie jest to bardziej bezpieczne i oferuje tylko jedną zaletę, o której mogę myśleć.

Na przykład wiadomo, że PPTP ma mniej niż idealne bezpieczeństwo, chociaż uważam, że nieco się poprawił od pierwszego wprowadzenia ... więc uważaj, którego rozwiązania VPN używasz. Wybrałbym OpenVPN lub IPSEC.

Jednak nie można pokonać wygody SSL / TLS bez VPN (czytaj dalej). Aby uczynić go jeszcze bardziej bezpiecznym, możesz uczynić go tylko certyfikatem.

Jeśli jednak uważasz, że możesz oferować inne usługi niż kontrola źródła, zastanów się nad rozwiązaniem VPN, ponieważ tunelujesz nad nim inne usługi.

Wadą korzystania z VPN jest to, że komputer staje się efektywnie częścią sieci, z którą się łączy. To także może być zaletą. Ale jeśli jesteś miliony mil od domu, a połączenie sieciowe z bazą macierzystą nie jest zbyt szybkie, to za każdym razem, gdy chcesz zrobić różnicę lub sprawdzić lub sprawdzić kod, możesz się połączyć i rozłączyć VPN.

Mogę mówić tutaj z własnego doświadczenia, ponieważ jestem programistą, a robienie tego było prawdziwym utrapieniem! Idealnie obie opcje są preferowane.

Więc jeśli zamierzasz przeglądać Internet itp., Może to spowolnić czytanie wiadomości itp. Ale przynajmniej masz bezpieczny dostęp do poczty e-mail. Zastanów się, jak będziesz go najpierw używać ... Gdybym był tobą, rozważyłbym wdrożenie obu.

Właściwie podoba mi się twoja sugestia. Jeśli udostępnisz swoje repozytorium kodu źródłowego TYLKO przez SSL / TLS i upewnisz się, że programiści nie używają łatwych do użycia haseł (lub jeszcze lepiej, używają certyfikatów), to powinno być tak bezpieczne, jak cokolwiek innego .

Zamiast tego możesz ukryć swój serwer w sieci LAN i zmusić programistów do korzystania z VPN w celu uzyskania dostępu, ale to tylko oznacza, że ​​programiści muszą umieścić swoją nazwę użytkownika / hasło (i / lub certyfikat) w innym polu logowania. Odradzam tworzenie punktu wejścia do Twojej sieci, którego konsekwencje dla bezpieczeństwa nie zawsze będą oczywiste, aby umożliwić dostęp do pojedynczej usługi. Jeśli masz już skonfigurowaną i zabezpieczoną sieć VPN do innych zastosowań, to z pewnością nie musisz się zastanawiać, skorzystaj z niej. W przeciwnym razie może być prostsze, a tym samym bardziej bezpieczne, aby sama usługa była bezpośrednio dostępna za pośrednictwem protokołu SSL / TLS.

Standard branżowy prawdopodobnie zależy od branży (lub klientów) :-)

Praktycznie musisz zastanowić się, komu chcesz dać dostęp i co mogą obsłużyć. Niektóre osoby, do których chcesz / musisz mieć dostęp, nie będą w stanie poradzić sobie z czymś więcej niż tylko nazwą użytkownika / hasłem. Inni mogą być w stanie ominąć ssh, a klucz prywatny, który pod warunkiem, że możesz bezpiecznie dostać klucz do nich, nie jest zły. Klient TortoiseSVN może obsługiwać ssh + svn i obsługuje klucze prywatne z lekkim przekręceniem ramienia. To wystarczyło dla moich celów.

Tunel VPN jest również uczciwą propozycją, chociaż w wielu miejscach chętnie dałbyś osobom z zewnątrz dostęp tylko do kontroli źródła, ale nie do całej sieci!

Podobnie jak inni, wolę VPN. Alternatywą byłby tunel SSH, który, jak sądzę, w praktyce jest rodzajem VPN.

Zrób to tylko do użytku wewnętrznego i zaimplementuj rozwiązanie VPN dla zdalnego użytkownika. / Doh- duplikat.

Jeśli chcesz uzyskać dostęp z dowolnego miejsca, potrzebujesz publicznego serwera - to wszystko jest jasne.

Na tym serwerze chcesz wystawiać jak najmniej , najlepiej tylko Mercurial / Subversion i nic więcej. Ma to zapobiec rozprzestrzenianiu się naruszenia bezpieczeństwa z kontroli źródła na resztę firmy. Z tego powodu zgodzę się z Mattem, gdy mówi, że VPN może być niebezpieczny: daje znacznie szerszy dostęp niż jest to konieczne.

W przypadku Mercurial możesz ściśle zablokować sytuację, używając hg-sshdo ograniczenia poleceń dostępnych dla klientów łączących się przez SSH. Korzystając z SSH, możesz łatwo zażądać, aby klienci używali uwierzytelniania klucza publicznego zamiast haseł. Chroni to Twój serwer przed atakami typu brute-force.

Nawet jeśli klucz SSH zostanie przejęty (być może miał on słabą frazę, a laptop przechowujący go został skradziony), najgorsze szkody, jakie może wyrządzić atakujący, to dodanie historii śmieci w Mercurial. Używany protokół jest z natury tylko dołączany, więc nic nie można go usunąć hg push.

W przypadku HTTPS uwierzytelnianie odbywa się przez serwer frontonu . Oznacza to, że możesz wymagać certyfikatów witryny klienta, jeśli chcesz, i uzyskać zabezpieczenia, takie jak powyższe uwierzytelnianie klucza publicznego SSH.