Konta serwisowe

czym to jest

Konta serwisowe to dane uwierzytelniające używane przez oprogramowanie, nie przez ludzi. Aplikacja uwierzytelniająca się do bazy danych. Integracja pobierająca dane z API. Zaplanowany skrypt działający w nocy. Automatyzacja łącząca dwa narzędzia SaaS.

Każde z nich potrzebuje danych uwierzytelniających, żeby działać. Te dane uwierzytelniające gdzieś żyją, mają poziom uprawnień i zostały przez kogoś utworzone. W wielu środowiskach na tym dokumentacja się kończy.

Konta serwisowe mają różne nazwy w zależności od platformy: service principals w Azure, service accounts w Google Workspace, użytkownicy techniczni w różnych platformach SaaS. Wspólną cechą jest to, że żaden człowiek nie loguje się nimi interaktywnie. Działają w tle i są często niewidoczne dla każdego przeglądu dostępów skupionego na użytkownikach ludzkich.

dlaczego się gromadzi

Konta serwisowe są tworzone, żeby rozwiązać bieżące problemy. Deweloper zakłada jedno, żeby połączyć dwa systemy. Administrator IT tworzy jedno dla narzędzia monitorującego. Kontraktor prowizjonuje jedno dla integracji podczas projektu.

Przy tworzeniu uprawnienia są ustawiane na to, co jest potrzebne, żeby coś zadziałało. Szerokie uprawnienia są częste, bo ich zawężenie wymaga czasu i testowania. Zasada least privilege dotyczy też tutaj, ale trudniej ją zastosować, gdy celem jest uruchomienie integracji.

Po utworzeniu konta serwisowe rzadko są ponownie sprawdzane. Nie wyzwalają procesów offboardingu. Nie pojawiają się w rekordach HR. Często przeżywają projekty, które je stworzyły, integracje, którym służyły, a w wielu przypadkach osoby, które wiedziały o ich istnieniu.

Gdy osoba, która posiadała konto serwisowe, odchodzi, konto często staje się faktycznie bezpańskie. Nie ma kto zaktualizować danych uwierzytelniających, nie ma kto przejrzeć uprawnień i nie ma kto go wyłączyć, gdy przestaje być potrzebne.

co to kosztuje

Konto serwisowe z szerokimi uprawnieniami i bez właściciela to niemonitorowane dane uwierzytelniające w Twoim środowisku. Jeśli dane uwierzytelniające zostaną wyeksponowane, przez przypadkowy commit, przejęty system czy źle skonfigurowaną lokalizację przechowywania, dostęp, który niosą, jest żywy, dopóki ktoś go nie odbierze.

Reakcja zależy od tego, czy ktoś wie, że konto istnieje i do czego może sięgnąć. W środowiskach bez inwentaryzacji kont serwisowych żadne z tych dwóch nie jest zagwarantowane.

Jest też luka w przeglądach dostępów. Frameworki compliance wymagające okresowych przeglądów dostępów, w tym SOC 2, ISO 27001 i DORA, rozciągają się na tożsamości maszynowe. Przegląd dostępów obejmujący tylko użytkowników ludzkich zostawia konta serwisowe poza zasięgiem jakiejkolwiek kontroli. To luka, którą znajdują audytorzy.

Konta serwisowe z nadmiarowymi uprawnieniami to też ścieżka ruchu bocznego. Przejęte dane uwierzytelniające aplikacji z dostępem na poziomie administracyjnym mogą sięgnąć dużo dalej, niż wymagała tego oryginalna integracja.

co działa

Nic innego nie jest możliwe, dopóki nie powstanie inwentaryzacja, a musi ona obejmować więcej niż katalog: konta serwisowe z IdP, platform chmurowych, głównych aplikacji SaaS i każdego systemu, gdzie skonfigurowane są integracje, z kluczami API i danymi uwierzytelniającymi usług OAuth liczonymi obok nazwanych kont. Populacja jest zwykle większa, niż ktokolwiek się spodziewa, a nieznana część to tam, gdzie żyje ryzyko.

Własność to kontrola, która czyni każdą inną kontrolę wykonalną. Każde konto serwisowe jest przypisane do obecnego pracownika, który wie, co robi, z czym się łączy i kto zadziała, gdy trzeba je zaktualizować lub wyłączyć. Konta, którym nie da się przypisać właściciela, to pozycje o najwyższym priorytecie na całej liście, bo dane uwierzytelniające bez właściciela nie mają kto ich zrotować, nie mają kto ich zawęzić i nie mają kto zauważyć, kiedy powinny zostać wycofane.

Poziomy uprawnień porównuje się z potrzebą, zamiast zostawiać je na tym, co sprawiło, że integracja działała pierwszego dnia. Konto z uprawnieniami administracyjnymi obsługujące integrację, która czyta jeden konkretny zasób, to kandydat do zawężenia zakresu. Ten sam przegląd ujawnia konta, których projekty się skończyły: integracja, która już nie działa, nie uzasadnia żadnych danych uwierzytelniających, a takie konta się wyłącza.

Nawykiem utrzymaniowym jest rotacja. Długowieczne dane uwierzytelniające usług rotuje się według udokumentowanego harmonogramu powiązanego z wrażliwością dostępu, przy czym dane uwierzytelniające o wysokich uprawnieniach cyklują częściej, więc wyeksponowany sekret ma ograniczony okres użyteczności zamiast nieokreślonego.