Administracja serwerami Linux Gdańsk

Co naprawdę leży na gdańskiej maszynie pośredniczącej?

Rzadko jest to jedna usługa. Najczęściej zestaw rzeczy dokładanych przez lata: klient pobierający pliki od spedytora zagranicznego, zadanie wysyłające paczki do systemu przewoźnika, portal dla klientów, czasem jeszcze baza pod aplikacją, której nie dało się postawić na Windowsie. Wszystko na jednym Debianie, bo tak było najprościej przy pierwszym projekcie.

Kłopot polega na tym, że razem z usługami przybywa poświadczeń. Po pięciu latach ta jedna maszyna trzyma hasła i klucze do kilkunastu podmiotów zewnętrznych, z których część odpowiada za to, czy towar ruszy z miejsca. Nikt nie podjął świadomej decyzji, żeby zebrać je w jednym punkcie. To się po prostu wydarzyło.

Praktyczny wniosek jest taki, że wartość tej maszyny mierzy się nie mocą, tylko tym, do czego daje dostęp. Prowadzenie jej jak zwykłego serwera aplikacji, czyli przez aktualizacje i monitoring obciążenia, pomija dokładnie tę część, która kosztuje najwięcej, gdy coś pójdzie źle.

Dlaczego hasło wpisane w skrypcie jest tu największym ryzykiem?

Bo skrypt nie zostaje w jednym miejscu. Trafia do kopii zapasowej, do repozytorium, na dysk laptopa, z którego ktoś go poprawiał, i do zgłoszenia wysłanego do autora integracji, gdy przestała działać. Każda z tych dróg jest zwyczajna i żadna nie wygląda na incydent, dopóki nikt nie zestawi ich razem.

Zmiana, którą wprowadzamy, jest tania i nie wymaga przerwy w pracy. Poświadczenia wychodzą z kodu do osobnego pliku z prawami odczytu wyłącznie dla konta usługi albo do magazynu haseł, a w skrypcie zostaje nazwa zmiennej. Przy okazji sprawdzamy, czy któreś hasło nie zostało w historii poleceń powłoki, bo tam zagląda się najrzadziej.

Druga część tej pracy dotyczy podziału. Jedno konto techniczne używane do wszystkiego znaczy, że jego zmiana zatrzymuje całą wymianę naraz, a jego wyciek otwiera wszystko naraz. Osobne poświadczenie dla każdego partnera kosztuje jedną rozmowę przy zakładaniu i zdejmuje oba te problemy.

Kto powinien móc zalogować się na tę maszynę?

Zastajemy zwykle jedno konto, jedno hasło i kilka osób, które je znają, w tym kogoś z firmy, która pisała integrację trzy lata temu. Nikomu nie odbieramy możliwości pracy, bo to kończy się obchodzeniem ustaleń. Zamiast tego każdy dostaje własne konto i własny klucz, logowanie hasłem znika, a zakres uprawnień zawężamy do tego, czym dana osoba naprawdę się zajmuje.

Co zastajemy	Gdzie to zwykle leży	Co z tym robimy
Wspólne konto z hasłem	notatka w kierowniku albo w arkuszu	konta imienne z kluczem, hasło unieważnione
Klucz bez hasła zabezpieczającego	katalog domowy jednej osoby	nowy klucz z hasłem, stary wycofany z listy
Poświadczenie do systemu partnera	wpisane wprost w skrypcie	plik z zawężonymi prawami, nazwa w kodzie
Dostęp autora integracji	konto współdzielone z administratorem	osobne konto, zakres ograniczony do aplikacji
Konto po byłym wykonawcy	nadal aktywne, ostatnie logowanie sprzed lat	zamknięcie po potwierdzeniu, że nic z niego nie startuje
Historia poleceń z hasłem w środku	plik w katalogu domowym	wyczyszczenie i zmiana ujawnionego poświadczenia

Ostatni wiersz odkrywamy w niemal każdym przejmowanym środowisku. Ktoś kiedyś uruchomił polecenie z hasłem w argumencie, żeby sprawdzić połączenie, i to hasło leży tam do dziś, czytelne dla każdego z dostępem do konta.

Co się dzieje, gdy taka maszyna zostanie przejęta?

Odpowiedź zależy wyłącznie od tego, co przygotowaliście wcześniej, bo w trakcie zdarzenia nie da się już niczego dołożyć. Dlatego trzy rzeczy ustawiamy od razu po wejściu, jeszcze przed porządkami w pakietach.

Pierwsza to ograniczenie ruchu wychodzącego. Maszyna pośrednicząca ma znany zestaw kierunków i nic poza nimi nie powinno jej opuszczać, więc reguły wyjścia pisze się tu równie starannie jak reguły wejścia. Druga to dzienniki wysyłane poza serwer, bo zapis skasowany razem z maszyną nie pomoże w niczym. Trzecia to sprawdzona kopia, z której da się odtworzyć system w innym miejscu, wraz ze znanym czasem tej operacji.

Dopiero mając te trzy rzeczy, warto rozmawiać o wykrywaniu i o utwardzaniu konfiguracji. W odwrotnej kolejności powstaje środowisko, które ładnie wygląda w zestawieniu, a przy pierwszym poważnym zdarzeniu nie daje nawet materiału do ustalenia, co się stało.

Za co odpowiadamy, gdy integrację pisał ktoś inny?

Za wszystko pod aplikacją: system, biblioteki, bazę jako usługę, certyfikaty, dostęp, zaporę, kopie i nadzór. Restartujemy usługi, czytamy dzienniki i przekazujemy zdiagnozowany opis błędu z godziną i komunikatem, zamiast samego zgłoszenia do przekazania dalej.

Kodu nie zmieniamy, chyba że umówimy się na to osobno z autorem. Poprawka wgrana bez jego wiedzy wraca przy pierwszym wdrożeniu nowej wersji, a przy integracji z podmiotem zewnętrznym oznacza dodatkowo, że nikt nie wie, którą wersję protokołu naprawdę obsługujecie. Granicę zapisujemy przed pierwszą zmianą, na jednej stronie, i ta kartka rozwiązuje później więcej sporów niż jakakolwiek procedura.

Węzły, na których stoją te maszyny, prowadzimy przy wirtualizacji serwerów, środowiska Microsoftu przy administracji Windows Server, a całość nadzoru obejmuje administracja serwerami.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026