Dostęp wykonawcy do repozytorium: wejście publiczne czy ścieżka VPN?

Wykonawca potrzebuje jednego prywatnego repozytorium do ograniczonego projektu, a prośba przychodzi jako «udostępnij repozytorium publicznie» albo «daj im dostęp VPN». Obie odpowiedzi omijają prawdziwe pytanie. Autoryzacja repozytorium i wejście sieciowe to osobne warstwy, a liczy się to uprawnienie, które pozwala tej osobie czytać lub pushować do tego jednego repozytorium. Wszystko inne w którymkolwiek pakiecie to dodatkowe ryzyko. Najpierw zaprojektuj warstwę autoryzacji, a potem zdecyduj, jak mało ścieżki sieciowej potrzebuje.

Przykładowe zlecenie czyni to konkretnym: jeden zewnętrzny deweloper, jedno repozytorium, żadnych hostów produkcyjnych, żadnego interfejsu administracyjnego. Utrzymaj ten zakres bez zmian, porównując wejścia.

Dwa wejścia, dwie różne granice

Publicznie dostępna usługa repozytorium nadal wymusza uwierzytelnianie HTTPS lub SSH oraz autoryzację aplikacji. Publiczna dostępność nie oznacza anonimowej czytelności. Kosztem jest nasłuch, który trzeba utrzymywać, monitorować i łatać.

Wejście VPN może trzymać ten nasłuch poza ścieżką publiczną, ale szerokie konto VPN może ujawnić niepowiązane usługi. Pozostała publiczna nazwa hosta, nasłuch SSH albo zapomniana rodzina adresów mogą znieść granicę tylko VPN, którą myślałeś, że masz. Dlatego projekt tylko VPN potrzebuje inwentarza nasłuchów, a nie tylko reguły zapory.

Porównuj dozwolone ścieżki, nie etykiety. W każdym razie zachowaj uwierzytelnianie aplikacji i normalną weryfikację tożsamości serwera.

Role w repozytorium są jednostką uprawnienia

Daj wykonawcy indywidualną tożsamość z najmniejszą rolą, która wykonuje zadanie. Przeglądanie, push, utrzymanie i administracja to różne role, a grupa przyznająca każdy wewnętrzny projekt nie jest tym samym co dostęp do jednego repozytorium. Sprawdź rzeczywiste nazwy ról na swojej platformie, zamiast zakładać, że nazwa grupy odpowiada jednej roli.

Wypisz każdą operację, której zlecenie naprawdę wymaga. Dostęp przez przeglądarkę i transport Git mogą używać innych poświadczeń lub nasłuchów. Automatyczne kompilacje, pobieranie pakietów i webhooki mogą działać jako odrębne tożsamości z własnymi ścieżkami dostarczania, a VPN na laptopie ich nie łączy.

Ochrona zawartości repozytorium to osobna praca. Zmiana ścieżki wejścia nie usuwa sekretu już obecnego w historii, nie ogranicza autoryzowanego klonu ani nie zabezpiecza stacji roboczej współpracownika.

Poświadczenia, które przeżywają człowieka

Odbiór uprawnień to miejsce, w którym dostęp do repozytorium i dostęp sieciowy znów się rozchodzą. Usuń autoryzację repozytorium i uprawnienie VPN przez ich odpowiednich właścicieli, a potem sprawdź osobiste tokeny, klucze SSH, poświadczenia automatyzacji i aktywne sesje. Klucz wdrożeniowy jest klasycznym ocalałym: może zachować skonfigurowany dostęp do odczytu lub zapisu po odejściu osoby z organizacji. Usunięcie z listy członków nie jest pełnym odbiorem uprawnień.

Zinwentaryzuj poświadczenia maszynowe według właściciela i celu przed końcem zlecenia, nie po nim. Token utworzony na tygodniową kompilację może przeżyć projekt o rok, jeśli nikt nie zapisał, po co istnieje.

Zweryfikuj operację, odmowę i odbiór uprawnień

Przed przekazaniem sprawdź trzy rzeczy: dozwolona operacja w repozytorium się udaje, niepowiązane repozytorium jest odrzucane, a wycofana tożsamość zawodzi. Jeśli projekt jest tylko VPN, potwierdź, że stara bezpośrednia ścieżka publiczna nie może już wykonać operacji.

Zachowaj kod i zapisy przeglądów, ale nie pozwól, by zapomniany dostęp stał się planem odzyskiwania. Pisemna lista tożsamości, ról i dat wygaśnięcia jest tym, co czyni następną prośbę wykonawcy powtarzalnym procesem.