Jak pozbyć się współdzielonych loginów i czego użyć zamiast nich?

Dlaczego współdzielone konta są niebezpieczne

Podstawowym problemem współdzielonego konta jest to, że zrywa ono łącze między akcją a osobą. Wszystko inne z tego wynika.

Nie da się ustalić, kto co zrobił

Gdy dziesięć osób loguje się jako socialmedia@ albo na jedno konto admin, każda akcja w logach jest przypisana do tego konta i niczego więcej. Jeśli wyjdzie szkodliwy post, zniknie rekord albo zmieni się ustawienie, ślad audytowy mówi ci, że zrobiło to konto, i na tym się kończy. Zostajesz z przesłuchiwaniem ludzi zamiast czytania logu. Dlatego ramy kontrolne traktują unikalną identyfikację jako fundament. PCI DSS Requirement 8 mówi, że przypisujesz unikalny identyfikator każdemu użytkownikowi i nie używasz grupowych, współdzielonych ani generycznych identyfikatorów czy haseł, właśnie po to, żeby akcje można było prześledzić do konkretnej osoby. CIS Control 5 mówi to samo: prowadź inwentarz kont i dopilnuj, żeby każda osoba miała swoje.

Rozliczalność to też jedyna rzecz, która w ogóle umożliwia dochodzenie. Gdy coś idzie nie tak na współdzielonym koncie, uczciwa odpowiedź na pytanie „kto to zrobił" brzmi zwykle „nie wiemy", a ta odpowiedź jest kosztowna.

Hasło zna wiele osób i niemal nigdy się nie zmienia

Współdzielone hasło się rozprzestrzenia. Zostaje wysłane na czacie, zapisane na karteczce, przekazane nowej osobie, wspomniane kontraktorowi na potrzeby jednorazowego zadania. W ciągu roku naprawdę nie da się wymienić wszystkich, którzy je znają. Rotowanie go za każdym razem, gdy ktoś z dostępem odchodzi, niemal nigdy się nie dzieje, bo oznacza to namierzenie wszystkich, którzy wciąż go potrzebują, i rozesłanie nowego. Więc się to pomija.

Efektem jest stałe ryzyko. Osoba, która odeszła sześć miesięcy temu, albo kontraktor, którego zlecenie się skończyło, często wciąż może zalogować się na współdzielone konto, bo hasło, które dostał, nigdy nie zostało zmienione. To jedna z najczęstszych form dostępu, który powinien się skończyć, a po cichu się nie skończył. Przy kontach imiennych wyłączasz jedno konto ostatniego dnia kogoś w firmie i masz to za sobą. Przy współdzielonym koncie nie ma czystego wyłącznika.

Współdzielone konta rzadko mają MFA

Uwierzytelnianie wieloskładnikowe chroni konto po tym, jak hasło zostało wyłudzone phishingiem albo wyciekło. Trudno je zastosować do współdzielonego loginu, bo standardowe drugie składniki są osobiste: kod na telefonie jednej osoby, monit w aplikacji jednej osoby, klucz bezpieczeństwa w kieszeni jednej osoby. Nic z tego nie działa płynnie dla loginu, z którego pięć osób korzysta w różnym czasie. Więc współdzielone konta zostają zabezpieczone samym hasłem, co oznacza, że konta używane przez najwięcej osób, często z dostępem do wrażliwych zasobów, mają najsłabszą ochronę. Współdzielone konta social media, panele administracyjne i portale dostawców wciąż siedzą na jednym haśle długo po tym, jak reszta przeszła na MFA.

Ślad audytowy jest bezużyteczny

Zestaw tych trzech problemów sprawia, że logi współdzielonego konta, nawet jeśli istnieją, nie odpowiadają na pytania, których potrzebujesz. Nie powiedzą ci, która konkretna osoba działała, zbiór osób, które mogły działać, jest nieznany i obejmuje osoby odchodzące, a nie ma drugiego składnika, który potwierdziłby, że to w ogóle była osoba autoryzowana. Dla każdego konta, które dotyka pieniędzy, danych klientów albo systemów produkcyjnych, to dokładne przeciwieństwo tego, czego chcesz, gdy coś pójdzie nie tak.

Gdzie chowają się współdzielone konta

Współdzielone loginy łatwo przeoczyć, bo rzadko wyglądają jak problem bezpieczeństwa. Oto miejsca, które warto sprawdzić.

• Konta administracyjne i root. Oryginalne konto admin na serwerze, firewallu, switchu, hypervisorze albo w dzierżawie SaaS. Pierwsi technicy używali go wszyscy, bo już tam było, i nikt nigdy go nie rozdzielił.
• Konta social media. Instagram, firmowy X/Twitter, TikTok, strona na Facebooku, kanał na YouTube. Niemal zawsze założone na jeden e-mail i hasło i współdzielone między marketingiem, agencją i kimkolwiek, kto akurat publikuje, a często wciąż dostępne dla byłej agencji albo pracownika.
• Portale dostawców. Strona zamówień dostawcy, portal kuriera, narzędzie marketingowe, rejestrator domen, panel hostingowy. Jedno konto, współdzielone przez wszystkich, którzy mają kontakt z danym dostawcą, często z dostępem do rozliczeń i umów w tle.
• Generyczny login do skrzynki ops. Skrzynka ops@, info@, support@ albo accounts@, na którą kilka osób loguje się bezpośrednio jednym współdzielonym hasłem, zamiast korzystać z niej jako ze współdzielonej skrzynki dostępnej z własnego konta każdej osoby.
• Konta serwisowe używane przez ludzi. Konto stworzone dla skryptu, integracji albo zaplanowanego zadania, na które ludzie też się logują, gdy potrzebują. Najgorsze z obu światów: potężne, nieosobowe, dotykane zarówno przez automatyzację, jak i przez ludzi, więc nikt go nie posiada i nikt nie wie, kto zna hasło.

Dobrym sposobem na wychwycenie takich kont jest zadanie sobie pytania dla każdego ważnego systemu: „gdybym musiał użyć tego teraz, czyjego loginu bym użył". Za każdym razem, gdy odpowiedzią jest imię, które nie jest twoje, albo „ten współdzielony", znalazłeś współdzielone konto.

Czego użyć zamiast, w zależności od przypadku

Nie ma jednego uniwersalnego zamiennika. Właściwa alternatywa zależy od tego, czy login da się podzielić na konta indywidualne, i czy daje zwykły, czy uprzywilejowany dostęp.

Indywidualne konta imienne wszędzie tam, gdzie system je obsługuje

To domyślne rozwiązanie i cel docelowy. Większość nowoczesnych systemów pozwala stworzyć osobne konto dla każdej osoby i przypisać role. Wszędzie tam, gdzie to możliwe, zrób to: każda osoba dostaje własny login, z dostępem, jakiego potrzebuje jej rola, i niczym więcej. To przywraca rozliczalność, pozwala stosować MFA per osoba i daje czysty wyłącznik, gdy ktoś odchodzi. CIS Control 5 traktuje to jako podstawę zarządzania kontami, a PCI DSS wymaga tego dla systemów objętych zakresem. Dla większości narzędzi SaaS, paneli administracyjnych i systemów wewnętrznych konta imienne to po prostu kwestia właściwego zapraszania ludzi zamiast rozsyłania jednego poświadczenia, a jedynym powodem, dla którego nie zrobiono tego wcześniej, była szybkość.

Zespołowy menedżer haseł ze współdzielonymi sejfami dla naprawdę współdzielonych loginów

Niektórych loginów nie da się podzielić. Pojedyncze konto social media z definicji ma jeden zestaw danych uwierzytelniających. Portal dostawcy może sprzedawać tylko jedno miejsce dostępu. Dla takich przypadków odpowiedzią jest zespołowy menedżer haseł ze współdzielonymi sejfami: dane uwierzytelniające żyją w zaszyfrowanym sejfie, przyznajesz dostęp konkretnym osobom, które go potrzebują, a menedżer loguje, kto z niego korzystał, i pozwala odebrać dostęp jednej osobie bez zmiany hasła. To daje ci kontrolę nad tym, kto posiada dane uwierzytelniające, czyli nad tą częścią, którą faktycznie możesz kontrolować, i sprawia, że rotacja staje się realistyczna, bo zmiana hasła to jedna aktualizacja w sejfie, a nie runda wiadomości. Połącz to z polityką haseł, która wspiera menedżery i długie, generowane hasła, opisaną w „Polityce haseł, która naprawdę działa". Gdy ktoś odchodzi, usuwasz go z sejfu, a dla najcenniejszych współdzielonych kont rotujesz hasło, żeby wszystko, co mógł zapamiętać, przestało działać.

Zarządzanie dostępem uprzywilejowanym dla współdzielonych kont administracyjnych

Współdzielone konta administratora i root to przypadek szczególny, bo dostęp jest potężny, a niektórych z tych kont naprawdę nie da się uczynić osobowymi: urządzenie może mieć wbudowany jeden login admin albo root bez możliwości dodania kolejnych. Kontrolą stworzoną do tego jest zarządzanie dostępem uprzywilejowanym (PAM). Narzędzie PAM przechowuje uprzywilejowane dane uwierzytelniające w sejfie, tak że żadna osoba nie zna ich bezpośrednio, wymaga, żeby każdy administrator uwierzytelnił się jako on sam, zanim ich użyje, może nadać dostęp dokładnie na moment, w którym jest potrzebny, i odebrać go potem, a także nagrywa sesję. To zwraca ci dwie rzeczy, które niszczy współdzielone konto administracyjne: indywidualną rozliczalność, bo narzędzie wie, która konkretna osoba pobrała dane uwierzytelniające, oraz prawdziwy ślad audytowy tego, kto co zrobił pod uprawnieniami. PAM to też właściwe miejsce dla kont serwisowych, na które logują się ludzie, bo pozwala oddzielić użycie automatyczne od ludzkiego. Jak wybrać narzędzie, które faktycznie da się wdrożyć, zamiast takiego, które utknie w połowie, opisuje „Przewodnik po wyborze PAM".

Single sign-on do centralizacji

Single sign-on (SSO) zapobiega powrotowi współdzielonych kont. Zamiast każdego systemu trzymającego własny login, ludzie logują się przez jednego centralnego dostawcę tożsamości, a systemy mu ufają. Efekt to jedno konto na osobę, zarządzane w jednym miejscu, z MFA wymuszanym centralnie i jednym przełącznikiem, który wyłącza dostęp każdej osoby, gdy odchodzi. SSO nie zastępuje kont imiennych, menedżera haseł ani PAM, tylko jest warstwą, która je spina i usuwa codzienny powód, dla którego ludzie sięgali po współdzielony login, czyli to, że osobne logowanie się do wszystkiego było uciążliwe. Tam, gdzie system obsługuje SSO, podłączenie go jest zwykle pojedynczym ruchem o najwyższej dźwigni, jaki możesz wykonać, bo w jednym kroku obejmuje konta tego systemu centralną kontrolą.

Podejście do migracji

Próba wyeliminowania każdego współdzielonego konta jednym zamachem zwykle utyka, bo te najbardziej uciążliwe do zmiany są też najważniejsze. Lepiej sprawdza się podejście etapowe.

1. Najpierw inwentaryzacja. Wypisz współdzielone konta. Przejdź przez swoje ważne systemy i dla każdego zadaj pytanie „czyjego loginu bym użył". Przy każdym współdzielonym koncie zapisz, do czego ma dostęp, mniej więcej kto zna hasło i czy dałoby się je podzielić na konta imienne. CIS Control 5 nazywa to inwentarzem kont i to krok, od którego zależy wszystko inne. Nie da się migrować kont, których nie wypisałeś.

2. Uszereguj według tego, do czego mają dostęp. Ułóż listę według blast radius, nie liczby osób korzystających z konta. Współdzielone konto admin kontrolujące produkcję, portal finansowy i konta social media widoczne dla klientów mają dużo większe znaczenie niż login tylko do odczytu w narzędziu niskiego ryzyka. Większość twojego realnego ryzyka siedzi w garści kont i to je przenosisz najpierw.

3. Migruj najważniejsze konta zależnie od przypadku. Weź konta o najwyższym ryzyku i zastosuj właściwą alternatywę. Podziel na konta imienne tam, gdzie system na to pozwala. Postaw współdzielony dostęp administracyjny za PAM. Przenieś pozostałe naprawdę współdzielone dane uwierzytelniające do zespołowego menedżera haseł z określoną listą dostępu. Dla każdego z nich, w momencie migracji, rotuj stare współdzielone hasło, żeby poprzednia wersja przestała działać.

4. Podłączaj systemy do SSO na bieżąco. Tam, gdzie system obsługuje single sign-on, podłącz go w trakcie migracji. To zamienia ten system na model jedno-konto-na-osobę pod centralną kontrolą i uniemożliwia ponowne odtworzenie współdzielonego konta później.

5. Zamknij pętlę na osobach odchodzących. Spleć ten wynik ze swoim procesem przyjmowania i odejść pracowników. Gdy ktoś odchodzi, wyłączasz jego konta imienne, usuwasz go z odpowiednich sejfów w menedżerze haseł, odbierasz mu dostęp PAM i rotujesz każde cenne współdzielone poświadczenie, które posiadał. Po wykonaniu powyższej pracy to krótka checklista, a nie gorączkowe poszukiwanie, kto co wiedział.

Nie musisz osiągnąć zera współdzielonych haseł, żeby być w dużo lepszym miejscu. Celem jest to, żeby każdy pozostały współdzielony login był albo zastąpiony kontami imiennymi, albo trzymany w kontrolowanym sejfie, MFA było włączone wszędzie, gdzie to możliwe, a ty mógł odciąć dostęp dowolnej osoby jednym ruchem. To osiągalne etapami, a już pierwszy etap, tylko kilka najważniejszych kont, usuwa większość ryzyka.

Źródła

• PCI DSS Requirement 8, Identify and authenticate access to system components · https://www.pcisecuritystandards.org/document_library/ (przypisz unikalny identyfikator każdemu użytkownikowi z dostępem, nie używaj grupowych, współdzielonych ani generycznych identyfikatorów, haseł ani innych metod uwierzytelniania, żeby akcje dało się prześledzić do konkretnej osoby)
• CIS Critical Security Controls v8.1, Control 5: Account Management · https://www.cisecurity.org/controls/cis-controls-navigator (prowadź inwentarz kont użytkowników, administratorów i serwisowych, nadaj każdej osobie unikalne konto, ogranicz uprawnienia administratora do dedykowanych kont administracyjnych, inwentaryzuj i przeglądaj konta serwisowe)
• NIST SP 800-53 Rev. 5, IA-2 Identification and Authentication (Organizational Users) · https://csf.tools/reference/nist-sp-800-53/r5/ia/ia-2/ (unikalnie identyfikuj i uwierzytelniaj użytkowników, tam gdzie używane są konta współdzielone, wymagaj indywidualnego uwierzytelnienia przed dostępem, żeby zachować rozliczalność)
• UK NCSC, Password policy: updating your approach · https://www.ncsc.gov.uk/collection/passwords/updating-your-approach (zarządzanie kontami, listy zablokowanych haseł oraz argumenty za unikalnymi danymi uwierzytelniającymi i zmianą po naruszeniu zamiast rutynowych praktyk, które osłabiają bezpieczeństwo)