Jak zablokować bezpośredni dostęp do produkcji, nie tracąc przy tym zmysłów

Dystrybucja kluczy SSH wśród inżynierów często zamienia się w chaos. Ktoś odchodzi z firmy, ale jego klucz publiczny pozostaje na dziesiątkach serwerów produkcyjnych. Ktoś przypadkowo uruchamia niebezpieczne polecenie w złym terminalu, a potem spędzasz pół dnia w logach systemowych, usiłując ustalić, czyja to była sesja.

Wraz ze wzrostem liczby serwerów i powiększaniem się zespołu bezpośrednie połączenia z maszynami stają się problemem. Zwykle w tym momencie firmy zwracają się ku koncepcji 4A: uwierzytelnianiu (authentication), autoryzacji (authorization), rozliczaniu (accounting) i audytowaniu (auditing). Jednak wdrożenie ciężkich rozwiązań takich jak Teleport czy CyberArk wymaga sporo czasu i zasobów.

Ostatnio natknąłem się na projekt o nazwie OneTerm na GitHubie. To lekki, open-source'owy gateway dostępowy napisany w Go i Vue.js. Rozwiązuje problem scentralizowanego dostępu do serwerów bez skomplikowanej konfiguracji.

Co kryje się w środku OneTerm

Zasada działania jest prosta: OneTerm staje się warstwą pośredniczącą między pracownikami a infrastrukturą produkcyjną. Programiści nie łączą się bezpośrednio z hostami przez SSH czy RDP. Zamiast tego logują się do panelu webowego OneTerm i stamtąd uruchamiają wymaganą sesję.

Projekt zaspokaja podstawowe potrzeby bezpieczeństwa:

• Pojedynczy punkt wejścia z obsługą dwuskładnikowego uwierzytelniania.
• Przyznawanie uprawnień do konkretnych serwerów i grup użytkowników.
• Nagrywanie sesji wideo i tekstu. Gdy coś pójdzie nie tak na serwerze, operację można odtworzyć w wbudowanym odtwarzaczu, aby przeanalizować szczegóły.
• Izolacja sesji zapobiegająca wzajemnemu ingerowaniu użytkowników i eskalacji uprawnień w ramach gatewaya.
• Ochrona wewnętrznych hostów przed bezpośrednim dostępem z zewnętrznego internetu.

Poza standardowym SSH, OneTerm obsługuje protokoły RDP i VNC. To przydatne dla osób mających serwery Windows lub maszyny wirtualne z interfejsami graficznymi w swojej infrastrukturze.

Stos technologiczny i integracje

Stos technologiczny projektu jest dość znajomy. Backend jest napisany w Go, a interfejs użytkownika zbudowany z użyciem Vue.js i biblioteki Ant Design Vue. Kompilacja w Go zapewnia niskie zużycie pamięci i szybką wydajność terminala webowego.

Deweloperzy dodali natywną integrację z Veops CMDB. To kolejny z ich open-source'owych projektów. Jeśli ewidencja sprzętu jest prowadzona w ich CMDB, serwery importują się do bastionu jednym kliknięciem. Nie trzeba ręcznie wprowadzać adresów IP, portów i poświadczeń.

Przyjrzyjmy się interfejsowi systemu.

Terminal działa bezpośrednio w oknie przeglądarki. Inżynierowie nie muszą konfigurować lokalnych klientów, konfigurować tuneli ani przechowywać kluczy na swoich laptopach.

Uprawnienia dostępu są segmentowane na podstawie czasu i ról. Można przyznać dostęp do serwera tylko na czas dyżuru lub podczas prac technicznych.

Jak wdrożyć i przetestować

Na potrzeby lokalnego wprowadzenia autorzy przygotowali konfigurację Docker Compose. Uruchomienie zajmuje kilka minut:

git clone https://github.com/veops/oneterm.git
cd oneterm/deploy
docker compose up -d

Po uruchomieniu kontenerów interfejs webowy otwiera się pod adresem http://127.0.0.1:8666. Domyślny login to admin, a hasło to 123456.

Na potrzeby środowiska produkcyjnego ta opcja nie będzie odpowiednia. Na ten przypadek deweloperzy napisali interaktywny skrypt konfiguracyjny ./setup.sh. Generuje on losowe hasła do bazy danych i usług wewnętrznych, samodzielnie aktualizuje konfiguracje i tworzy kopię zapasową.

git clone https://github.com/veops/oneterm.git
cd oneterm/deploy
./setup.sh
docker compose up -d

Jeśli chcesz dodać własną funkcjonalność, projekt zawiera gotowe skrypty z hot-reload dla frontendu i backendu: ./dev-start.sh frontend i ./dev-start.sh backend. Do budowania wymagany jest Node.js w wersji 14.17.6+ i Go w wersji 1.21.3+.

Niuansy i ograniczenia

Przed wprowadzeniem narzędzia do środowiska produkcyjnego należy wziąć pod uwagę kilka szczegółów:

• Kod jest rozpowszechniany na licencji AGPL-3.0. Jeśli zdecydujesz się stworzyć z niego zamknięte komercyjne rozwiązanie SaaS, będziesz musiał udostępnić swoje modyfikacje.
• Gałąź main w repozytorium jest stale aktualizowana i może działać niestabilnie. Do użytku na serwerach należy pobierać wyłącznie skompilowane wydania ze strony Releases.
• Dokumentacja jest wciąż dość skąpa. Deweloperzy odpowiadają na GitHub Issues, ale niektóre szczegóły trzeba będzie rozwikłać bezpośrednio na podstawie kodu źródłowego.

Podsumowanie

OneTerm sprawdza się w przypadku małych zespołów operacyjnych i administratorów systemów, którzy chcą szybko zorganizować zarządzanie dostępem. Jeśli potrzebujesz prostego bastionu z nagrywaniem sesji, segmentacją dostępu oraz obsługą SSH i RDP, projekt zaspokoi podstawowe potrzeby bez zbędnej złożoności.

Możesz wypróbować interfejs bez instalacji na oficjalnym demie oneterm.v1ops.com z loginem demo i hasłem 123456.