Zanim umieścisz ustawienie proxy w publicznym repozytorium
Oddziel punkt końcowy proxy od danych logowania proxy i wyjaśnij, dlaczego publikacja pierwszego nie zapewnia kontroli dostępu.
Nazwa hosta proxy w pliku konfiguracyjnym to nie to samo co hasło proxy. Publikacja któregokolwiek z nich wymaga świadomej decyzji, ale konsekwencje są różne.
Punkt końcowy mówi czytelnikom, gdzie usługa może być osiągalna. Adres URL taki jak http://name:[email protected]:8080 daje im również użyteczne dane logowania. Nigdy nie należy go traktować jako nieszkodliwego tylko dlatego, że wygląda jak adres.
Ukryty adres nie jest polityką dostępu
Prywatne proxy wymaga kontroli odpowiednich dla jego użytkowników: uwierzytelniania, dozwolonych sieci klientów i ograniczeń miejsca docelowego. Trzymanie adresu poza repozytorium ich nie zastępuje. Publicznie osiągalna usługa może zostać odkryta bez czytania przez kogokolwiek twojej konfiguracji.
Odwrotnie, publikacja adresu usługi nie dowodzi, że jest otwarta. Punkt końcowy może nadal wymagać danych logowania lub być osiągalny tylko z zamierzonej sieci. Sprawdź rzeczywistą granicę dostępu, zamiast zakładać, że tajność i uwierzytelnianie znaczą to samo.
W przypadku przykładów do udostępniania używaj nazw hostów z dokumentacji i pomijaj sekrety. Prywatne ustawienia przechowuj w ustalonym mechanizmie sekretów lub konfiguracji lokalnej projektu. Uważaj na generowane pliki i kopiowane dzienniki diagnostyczne, które mogą zawierać pełny adres URL z danymi logowania.
Jeśli dane logowania zostały ujawnione, najpierw usuń ich użyteczność, unieważniając je lub rotując. Edycja najnowszego pliku nie usuwa kopii, wcześniejszych commitów ani zawartości w pamięci podręcznej. Wskazówki GitHuba dotyczące danych wrażliwych wyjaśniają, dlaczego czyszczenie historii to osobne zadanie.
Przydatny przegląd sprawdza obie strony: jaki dostęp daje opublikowana informacja i czy proxy pozostaje ograniczone nawet wtedy, gdy jego adres jest znany.