Dlaczego hosty bastionowe zwiększają ryzyko

Do administrowania serwerami w prywatnej sieci zespoły tradycyjnie używały hosta bastionowego (nazywanego także jump boxem): wzmocnionej instancji dostępnej z internetu, z którą najpierw łączono się przez SSH, a następnie przechodzono do maszyn wewnętrznych. Choć ten wzorzec jest powszechny, na kilka sposobów zwiększa powierzchnię ataku — a egzamin SCS-C02 wymaga rozpoznania i eliminowania tych zagrożeń.

Host bastionowy znajduje się w publicznej podsieci, a jeden z jego portów (zwykle 22 dla SSH lub 3389 dla RDP) jest otwarty dla internetu albo firmowego zakresu adresów IP. Administratorzy łączą się z nim, a następnie uzyskują dostęp do prywatnych instancji. Jest to jedyna strzeżona brama do środowiska, dlatego ma krytyczne znaczenie i stanowi atrakcyjny cel ataków.

Największym zagrożeniem jest otwarty port przychodzący. Każdy dostępny z internetu port SSH lub RDP jest nieustannie skanowany, a atakujący próbują łamać zabezpieczenia metodą brute force. Nawet uwierzytelnianie oparte na kluczach nie eliminuje ryzyka — ujawniony port zachęca do ataków, a pojedyncza błędna konfiguracja lub niezałatana luka w hoście bastionowym może zapewnić atakującym przyczółek w całej sieci.

Dostęp do hosta bastionowego zwykle opiera się na długotrwałych parach kluczy SSH rozprowadzanych wśród administratorów. Klucze te mogą zostać skopiowane, zgubione lub pozostać na laptopach byłych pracowników. Ich rotacja w całej flocie jest uciążliwa, a często brakuje dokładnego rejestru wskazującego, który klucz otworzył daną sesję, co osłabia rozliczalność.

Śledzenie, kto i co zrobił za pośrednictwem hosta bastionowego, jest trudne. Natywne SSH zapewnia niewiele scentralizowanego rejestrowania poleceń wykonywanych na hostach docelowych. Zbadanie incydentu wymaga połączenia logów z wielu hostów, a przejęty host bastionowy może umożliwić atakującemu usunięcie własnych śladów — dokładnie taką lukę w widoczności wskazują audytorzy.

Sam host bastionowy jest instancją, którą należy stale aktualizować i wzmacniać. Jeśli będzie mieć zaległe aktualizacje, stanie się najsłabszym ogniwem. Utrzymywanie wysoce dostępnego i zawsze bezpiecznego jump boxa jest ciągłym obciążeniem operacyjnym, które zwiększa koszty i ryzyko, nie zapewniając wartości biznesowej.

Ponieważ cały ruch administracyjny przechodzi przez hosta bastionowego, jest on zarówno pojedynczym punktem awarii, jak i cennym celem ataku. Jeśli przestanie działać, administratorzy stracą dostęp; jeśli zostanie przejęty, atakujący zyska bazę wypadową. Koncentrowanie ryzyka w jednym ujawnionym hoście to architektura, której egzamin wymaga unikać.

Systems Manager (SSM) firmy AWS wraz z funkcją SSM Session Manager całkowicie eliminuje potrzebę używania bastionów. Zapewnia dostęp powłoki do instancji za pośrednictwem usługi SSM, bez otwartych portów przychodzących, publicznego adresu IP i kluczy SSH. Dostęp jest kontrolowany przez IAM, a każda sesja jest rejestrowana, co jednocześnie rozwiązuje wszystkie słabości modelu bastionowego.

SSM działa, ponieważ instancja uruchamia SSM Agent, który nawiązuje wychodzące połączenie z usługą SSM; nie trzeba otwierać żadnego dostępu przychodzącego. Grupy zabezpieczeń mogą odrzucać cały ruch przychodzący, a administracja nadal będzie działać. To odwrócenie modelu — ruch wychodzący zamiast przychodzącego — jest kluczową ideą, dzięki której bastiony stają się zbędne.

Na egzaminie każdy scenariusz opisujący otwarte porty SSH/RDP, rozproszone pary kluczy lub jump boxa niemal zawsze wskazuje lepszą odpowiedź: zastąpić bastion rozwiązaniem Session Manager. Zmniejsza ono powierzchnię ataku, centralizuje kontrolę dostępu w IAM i zapewnia pełny ślad audytowy — bezpieczny projekt zgodny z zasadą najmniejszych uprawnień, zalecany przez AWS.

Host bastionowy udostępnia port przychodzący, opiera się na długotrwałych kluczach SSH, zapewnia słaby audyt i wymaga ciągłego aktualizowania, przez co staje się skoncentrowanym i atrakcyjnym celem. Zalecanym zamiennikiem jest SSM Session Manager, który zapewnia kontrolowany przez IAM, w pełni rejestrowany dostęp do powłoki bez otwartych portów, publicznego adresu IP ani kluczy.

Host bastionowy otwiera przychodzący port SSH/RDP, opiera się na długotrwałych kluczach SSH, zapewnia słaby audyt i wymaga ciągłego aktualizowania, koncentrując ryzyko w jednym ujawnionym celu. SSM Session Manager zastępuje go kontrolowanym przez IAM, w pełni rejestrowanym dostępem za pośrednictwem połączenia agenta wychodzącego, bez potrzeby używania otwartych portów, publicznego adresu IP ani kluczy.