Poniższa historia nie przydarzyła się żadnej konkretnej firmie. Złożyliśmy ją z sytuacji, na które trafiamy zbyt często, żeby uznawać je za wyjątki.
Pracownik odszedł w marcu. Była zrzutka na prezent, pożegnalne piwo i ciasto. Potem zwrot laptopa i wpis w aktach.
W październiku, przy porządkach w licencjach, okazuje się, że konto tego pracownika wciąż działa. Nikomu nie przyszło do głowy wrzucić ticketa do IT, bo człowiek już nie pracuje i sprawa wydawała się zamknięta. Z tego konta jest dostęp do folderu z umowami, do systemu obsługującego sprzedaż i magazyn oraz do skrzynki, na którą przez siedem miesięcy spływała korespondencja od klientów. Skrzynka wygląda na obsłużoną, bo następca ustawił sobie przekierowanie i pocztę od klientów dostaje. Tylko przekierowanie nie zabiera niczego z pierwotnej skrzynki, a tworzy kopię u kolejnego odbiorcy. Hasło do tego konta leży w bazie z wyciekami, dostępnej dla każdego, kto wie, gdzie szukać, bo pracownik używał tego samego hasła prywatnie, w serwisie, który został okradziony.
Spis treści
To nie jest historia o nieuczciwym pracowniku. On o tym koncie nie myśli od marca. Atakujący tylko korzysta z okazji. Skanuje środowisko, wyłapuje konta bez logowania od miesięcy i sprawdza na nich hasła z takich właśnie baz. Nieużywane konto jest dla niego lepsze niż aktywne z dwóch powodów. Nie ma właściciela, który zadzwoni z pytaniem, dlaczego dostał powiadomienie o logowaniu albo dlaczego nagle nie może się dostać do poczty, a jeśli dzienniki zdarzeń leżą nieczytane, logowanie o trzeciej w nocy z innego kraju nikogo nie zdziwi. Do tego hasła do takiego konta już nikt nie zmieni, bo nie ma komu, więc raz zdobyty dostęp zostaje atakującemu na miesiące.
Takie konta nazywamy kontami widmo i uważamy, że to najbardziej niedoceniane zagrożenie w polskich firmach. Nie trzeba do tego luki w oprogramowaniu ani żadnych umiejętności. Wystarczy, że w firmie nie ma procesu odbierania dostępów, a nie ma go zaskakująco często.
Ten tekst jest o offboardingu IT, czyli o tej części rozstania z pracownikiem, która dzieje się w systemach, nie w kadrach. O tym, co zostaje po człowieku, kiedy formalności są już zamknięte, i dlaczego wyłączenie konta jest pierwszym krokiem, a nie całą procedurą.
Czym jest konto widmo i skąd się bierze
Konto widmo to konto, z którego wciąż jest dostęp do firmowych systemów, a nie odpowiada za nie ani człowiek, ani żaden proces.
Były pracownik to najbardziej oczywisty przypadek, ale nie jedyny i nie najgorszy. Kontem widmem jest też konto techniczne założone pięć lat temu do integracji, która już nie działa. Konto współdzielone “serwis”, którego hasło zna dziewięć osób, w tym trzy, które już w firmie nie pracują. Konto zewnętrznego dostawcy oprogramowania, który raz w roku wchodzi zdalnie na serwer. Konto stażysty z zeszłego lata. Wszystkie łączy jedno: działają, wciąż jest z nich dostęp i nie są pilnowane.
Nikt nie uruchamia procesu. Informacja o tym, że ktoś odchodzi, powstaje w kadrach. Narzędzia do wyłączenia konta są w IT. Jeżeli między jednym a drugim nie ma przepływu informacji, IT dowiaduje się o odejściu przypadkiem. To najczęstsze źródło kont widm i jednocześnie najprostsze do zamknięcia, bo nie potrzeba do tego żadnej technologii, tylko ustalenia, kto kogo informuje i w jakim terminie.
Dostępy są w kilkunastu miejscach, a spisu nigdzie nie ma. Konto w firmowej sieci, konto w systemie sprzedażowym, konto w narzędziu do fakturowania, konto w systemie do urlopów, dostęp do repozytorium kodu, dostęp do panelu operatora telekomunikacyjnego, konto w usłudze chmurowej, którą marketing wykupił kartą firmową bez wiedzy IT. Wyłączenie konta w jednym centralnym systemie zamyka część z nich. Reszta zostaje, a ile ich jest? Realnie nie wiadomo.
Wyłączenie odkłada się na potem. Konto zostaje aktywne z trzech powodów, które wracają najczęściej: trzeba jeszcze przenieść pliki z jego dysku, skrzynka ma być dostępna dla zastępcy, ktoś wyżej powiedział, żeby na razie nie ruszać. Powody są istotne, tylko żaden z nich nie wymaga aktywnego konta. Pliki z dysku i zawartość skrzynki wyciąga się z konta wyłączonego, uprawnieniami administratora. Rzecz w tym, że nikt w tej chwili nie pyta, czy konto naprawdę musi zostać włączone. Polecenie brzmi “zostaw na razie”, a polecenia się nie kwestionuje. “Na razie” trwa potem siedem miesięcy.
Odejście nie jest traktowane jako zdarzenie bezpieczeństwa. Tu jest sedno sprawy. W większości firm zamknięcie współpracy to zadanie administracyjne, gdzieś obok rozliczenia delegacji i odbioru odzieży roboczej. My widzimy w tym coś innego. Z chwilą, w której ktoś przestaje być pracownikiem, jego dostępy stają się dostępami osoby postronnej. Nie chodzi o intencje tej osoby, a o to, że firma traci kontrolę nad tym, gdzie i na jakim urządzeniu jej hasła są przechowywane.
Wyłączenie konta i odebranie dostępu to dwa różne zdarzenia
Administrator klika “wyłącz konto”, widzi na liście strzałkę w dół i uznaje temat za zamknięty. Tymczasem między wyłączeniem konta a utratą dostępu mija czas, a w niektórych przypadkach dostęp nie znika w ogóle.
Sieć firmowa i przepustki dostępu
Firmowe konta i hasła przechowuje zwykle jeden centralny system, w produktach Microsoftu nazywany Active Directory. Obsługują go wyznaczone serwery (fachowo: kontrolery domeny). Kiedy użytkownik się loguje, dostaje od nich coś w rodzaju przepustki, która pozwala wchodzić do kolejnych systemów bez ponownego podawania hasła (fachowo: bilet Kerberos).
Protokół, na którym to działa, nie potrafi unieważnić raz wydanej przepustki. Windows częściowo to łagodzi: serwer wydający przepustki sprawdza stan konta, gdy poprzednia przepustka jest starsza niż 20 minut, i wyłączonemu kontu odmawia. Jest przy tym zastrzeżenie warte zapamiętania: sprawdzenie może wykonać tylko serwer z tej samej domeny, z której pochodzi konto. W firmach z kilkoma domenami nie zawsze jest to ten serwer, który akurat obsługuje żądanie.
Zostają natomiast dwie rzeczy. Przepustki wydane przed wyłączeniem działają do wygaśnięcia, a domyślny limit to 10 godzin, tyle samo dla przepustki głównej i dla przepustek do poszczególnych usług. Trwają też połączenia, które zostały już uwierzytelnione. Microsoft pisze wprost, że nie są przerywane, kiedy przepustka wygaśnie w ich trakcie. Osoba, która w chwili wyłączenia konta ma otwarty plik z serwera, nie zostanie z niego wyrzucona.
Chmura i tokeny
W chmurowej odmianie tego samego katalogu, nazywanej Entra ID, mechanizm wygląda podobnie, tylko liczby są inne. Cyfrowa przepustka do usługi (fachowo: token dostępu) żyje od 60 do 90 minut. Osobna przepustka służy do tego, żeby aplikacja mogła po cichu wymienić wygasłą na nową, bez pytania użytkownika o hasło, i ta bywa ważna nawet po 90 dniach przerwy w używaniu.
Samo odznaczenie “konto włączone” tych przepustek nie unieważnia. Trzeba dodatkowo unieważnić sesje, co ubija je wszystkie razem z ciasteczkami w przeglądarce. Osobny przycisk, osobna decyzja, więc w praktyce bardzo często się o niej zapomina.
Jest jeszcze mechanizm ciągłej oceny dostępu, który reaguje na wyłączenie konta w kilka minut, do kwadransa, i nie czeka na wygaśnięcie przepustki. Obsługuje go jednak tylko część aplikacji, głównie usługi samego Microsoftu, a w zamian wydłuża czas życia przepustki do kilkudziesięciu godzin. Aplikacja, która tego mechanizmu nie obsługuje, a przepustkę dostała długoterminową, daje efekt odwrotny od zamierzonego.
Aplikacje z jednym logowaniem
Przy jednym logowaniu do wielu aplikacji użytkownik dostaje dwie przepustki: jedną od katalogu i drugą od samej aplikacji. Wyłączenie konta w katalogu blokuje wydawanie nowych. Sesji, którą aplikacja już wystawiła, katalog nie ma jak dotknąć i Microsoft mówi to w dokumentacji wprost: nie potrafi unieważnić tokenu sesji wydanego przez aplikację. Jak długo taka sesja potrwa, zależy wyłącznie od ustawień tej aplikacji, a bywa to znacznie dłużej niż godzina.
Nie jest to argument przeciw jednemu logowaniu. Uważamy je za jedno z lepszych rozwiązań, jakie można w firmie wdrożyć: zmniejsza liczbę haseł i liczbę miejsc, w których trzeba je wpisywać, a przy odejściu pracownika daje jeden punkt, z którego odcina się dostęp do wielu systemów naraz. Ten punkt zamyka drzwi na przyszłość, nie wyprowadza ludzi z budynku.
Klucze na serwerach
Na serwerach z Linuksem standardem jest logowanie bez hasła, przy użyciu pary plików: prywatnego u użytkownika i publicznego wpisanego na serwerze (fachowo: klucz SSH). Serwer przy logowaniu zagląda tylko do swojego lokalnego pliku z listą uprawnionych kluczy. Wyłączenie konta w katalogu tego pliku nie dotyka.
Jeżeli konto na serwerze pochodzi z katalogu firmowego przez odpowiednie oprogramowanie pośredniczące, stan konta zostanie dodatkowo sprawdzony i wyłączone konto dostanie odmowę. Ten mechanizm nie obejmuje jednak kont zakładanych bezpośrednio na serwerze, a właśnie tak najczęściej powstają konta techniczne. Nie zadziała też, jeżeli czyjś klucz został kiedyś dopisany do listy konta administratora. Otwartych sesji nie zabija w żadnym wypadku.
Co zostaje u pracownika: laptop i telefon
Windows przechowuje na komputerze dane pozwalające zalogować się bez kontaktu z serwerem, żeby pracownik mógł pracować bez sieci firmowej. Domyślnie pamiętane jest dziesięć ostatnich logowań. Wyłączenie konta w katalogu tej możliwości nie usuwa. Laptop, który nie wrócił do firmy i nie łączy się z firmową siecią, wpuści byłego pracownika na jego dotychczasowe hasło, a razem z nim odda wszystko, co zostało na dysku. Dlatego zwrot sprzętu to nie kwestia inwentarzowa, a część odbierania dostępów. Firmowe laptopy warto szyfrować i mieć możliwość ich zdalnego zablokowania.
Druga ścieżka prowadzi przez przeglądarkę i zwrot laptopa jej nie zamyka. Hasła do firmowych systemów bywają w niej zapisane, a profil przeglądarki synchronizuje się z prywatnym kontem pracownika, więc kopia tych haseł jest już na jego domowym komputerze, zanim ktokolwiek pomyśli o offboardingu. To samo dotyczy prywatnego menedżera haseł, w którym wylądowały dostępy firmowe. Wniosek jest niewygodny, ale jednoznaczny: hasła, które ta osoba znała, trzeba zmienić, a nie zakładać, że wyjechały razem ze sprzętem.
Jeżeli firma wymaga potwierdzenia tożsamości drugim składnikiem, na przykład kodem z aplikacji w telefonie, ta aplikacja została skonfigurowana na prywatnym telefonie pracownika. Po wyłączeniu konta kod przestaje działać. Samo powiązanie zostaje jednak w profilu konta, więc jeżeli konto kiedyś wróci do życia, przez pomyłkę przy porządkach albo przy powrocie tej osoby do firmy, drugi składnik nadal działa na jej telefonie.
Gorsza jest inna pozostałość. W profilu konta zwykle zapisane są metody odzyskiwania dostępu: prywatny numer telefonu i prywatny adres e-mail. Jeżeli tam zostaną, były pracownik może samodzielnie zresetować hasło. To najkrótsza droga od konta widma do przejętego konta i najrzadziej pamiętana.
Wniosek z całej tej sekcji jest prosty: “wyłączyłem konto” i “ta osoba nie ma już dostępu” to dwa różne zdania.
Uprawnienia, których tylko przybywa
Konta widma to jedna strona problemu. Druga to konta, za którymi stoi jak najbardziej realny pracownik, tylko ich zakres dostępu od dawna nie ma nic wspólnego z tym, co ten pracownik robi.
Mechanizm jest zawsze ten sam: uprawnienia się dodaje, prawie nigdy nie odbiera. Pracownik przechodzi z księgowości do kontrolingu i dostaje dostępy potrzebne w nowym dziale. Stare zostają, bo nikt nie zapytał, czy są jeszcze do czegoś potrzebne, a zabranie czegokolwiek grozi tym, że jutro coś przestanie działać. Po pięciu latach i trzech zmianach stanowisk ta osoba ma dostęp do wszystkiego, co widziała po drodze. Formalnie jest specjalistą w jednym dziale. Technicznie jest kontem o zakresie dostępu, którego nikt w firmie nie potrafi opisać. W branży nazywa się to pełzającym rozrostem uprawnień.
Jest jeszcze nawyk, który cały proces przyspiesza. Kiedy przychodzi nowa osoba, najszybszym sposobem założenia jej konta jest skopiowanie konta kogoś na podobnym stanowisku. Active Directory ma do tego gotową funkcję, która przenosi członkostwo w grupach uprawnień. Nowy pracownik pierwszego dnia dziedziczy więc cały bagaż wzorca, razem z grupami uprzywilejowanymi, które ten wzorzec zebrał przez lata.
Kopia nie jest przy tym wierna. Nowe konto ma nowy identyfikator wewnętrzny, więc uprawnienia nadane kiedyś bezpośrednio konkretnej osobie, na przykład do jednego folderu na serwerze plików, nie przechodzą. Przechodzi tylko to, co wynika z grup. Stąd bierze się typowa sytuacja: nowe konto dostaje za dużo uprawnień systemowych i za mało tych, które są potrzebne do pracy, a nikt nie rozumie, dlaczego.
Rozrost uprawnień jest groźny z tego samego powodu co konta widma, tylko trudniej go zauważyć. Przejęcie konta pracownika, który przez dekadę zebrał dostępy z czterech działów, daje atakującemu zasięg porównywalny z przejęciem konta administratora i nie wywoła żadnego alarmu, bo to konto loguje się codziennie i wygląda normalnie.
Konta, za którymi nie stoi żaden człowiek
Osobna kategoria, w praktyce najbardziej zapuszczona.
Konta techniczne. Konta, z których korzystają programy, nie ludzie: system kopii zapasowych, monitoring, integracja między dwoma systemami, usługa działająca na serwerze. Uprawnienia mają zwykle szerokie, bo tak było najszybciej w dniu wdrożenia. Haseł się im nie zmienia, bo zmiana oznacza przerwę w działaniu czegoś, co działa. Drugiego składnika nie mają, bo program nie odbierze kodu z telefonu. Właściciela też nie, bo osoba, która je zakładała, dawno zmieniła pracę. Czy dane konto jest jeszcze do czegokolwiek używane, tego nie wie nikt: sprawdzenie wymaga przejrzenia konfiguracji wszystkich systemów, które mogłyby z niego korzystać.
Da się z tym zrobić więcej, niż się firmom wydaje. Po pierwsze, obciąć uprawnienia do tego, co program faktycznie robi. Konto od kopii zapasowych prawie nigdy nie potrzebuje pełnych praw administratora domeny, choć zaskakująco często je ma. Po drugie, ograniczyć, z jakich maszyn to konto może się w ogóle logować, żeby wykradzione hasło było bezużyteczne z laptopa w innym kraju. Po trzecie, tam gdzie aplikacja to obsługuje, przejść na konta z hasłem zarządzanym przez system operacyjny. Windows generuje wtedy losowy ciąg o długości 240 bajtów i zmienia go domyślnie co 30 dni, a uprawnione serwery pobierają go samodzielnie. Nikt takiego hasła nie wpisuje i nikt nie musi go znać, więc nie da się go wynieść na kartce ani wkleić do arkusza. Jedno zastrzeżenie: takie hasło jest chronione tak dobrze, jak serwery uprawnione do jego pobrania, bo kto ma na nich prawa administratora, ten ma i hasło.
Konta współdzielone. Jedno konto, jedno hasło, wiele osób. Klasyka to “serwis”, “biuro”, “recepcja”, “kasa”. Takiego konta nie da się rozliczyć: w dziennikach zdarzeń widać, że coś zrobiło konto “serwis”, i na tym kończy się dostępna wiedza. Przy odejściu pracownika jest jeszcze gorzej, bo nie ma czego wyłączać. Zostaje zmiana hasła, a to oznacza poinformowanie wszystkich pozostałych, więc w praktyce prawie nigdy się tego nie robi. Osoba, która odeszła trzy lata temu, wciąż zna hasło do konta, którym dziś ktoś wystawia faktury.
Dostępy firm zewnętrznych. Dostawca systemu sprzedażowego, serwisant maszyn, integrator, firma obsługująca centralę telefoniczną. Każdy ma zwykle jakąś formę dostępu zdalnego, założoną przy wdrożeniu i nietkniętą od tamtej pory. Dostęp nadano podmiotowi, a korzysta z niego konkretny człowiek, o którego zmianie pracy nikt u Ciebie nie usłyszy. Kiedy z tej firmy odchodzi inżynier, jego hasło do Twojej infrastruktury zostaje.
Konta gości i partnerów w chmurze. Zapraszając kogoś z zewnątrz do współpracy w firmowej chmurze, tworzy się konto, które w niej zostaje. Projekt się kończy, konto nie. Takie konta nie pojawiają się na żadnej liście pracowników i praktycznie nigdy nie trafiają na przegląd, a dokumenty, które przy nich zostawiono, są z nich nadal dostępne.
Konta awaryjne administratora. Zakładane po to, żeby wejść do systemu, kiedy wszystko inne przestanie działać. Z definicji się nie logują, więc przy każdym przeglądzie wyglądają jak konta widma i za każdym razem ktoś proponuje ich wyłączenie. Powinny być udokumentowane, mieć hasło zamknięte w sejfie, wyłączony drugi składnik oparty na czyimś telefonie i ustawiony alarm na każde użycie. Dwa lub trzy, nie dwanaście.
Kadry zgłaszają, IT wykonuje
Offboarding IT, który działa, ma trzy cechy: uruchamia go zdarzenie, ma listę kroków i ma dowód wykonania.
Zdarzenie. Ktoś musi powiedzieć IT, że dana osoba odchodzi, i musi to zrobić przed jej ostatnim dniem, nie po. To zadanie kadr, bo tam ta informacja powstaje. W firmach z systemem kadrowym da się to zautomatyzować, żeby wpis o rozwiązaniu umowy generował zgłoszenie. Tam, gdzie systemu nie ma, wystarczy ustalona ścieżka i jedna osoba odpowiedzialna. Ważne, żeby nie było to uprzejme przypomnienie, a element procedury.
Lista kroków. Ta sama za każdym razem, spisana, niezależna od tego, kto danego dnia jest w pracy. Kolejność ma znaczenie, bo część kroków musi się wykonać w konkretnym momencie, a nie “w ciągu tygodnia”.
Dowód. Data, godzina, osoba, która wykonała, i lista tego, co zostało odebrane. Jeżeli za dwa lata ktoś zapyta, czy konto pana Kowalskiego zostało wyłączone i kiedy, “chyba tak” nie wystarczy ani audytorowi, ani prawnikowi w sytuacji, w której z tego konta wyciekły dane. Dwa tygodnie po odejściu warto do tej listy wrócić i sprawdzić, czy odcięcie faktycznie zadziałało. Procedura bez takiej kontroli zostaje deklaracją, a my wolimy dowód.
Tak wygląda ta lista u nas, z terminami, które uważamy za realne.
Krok | Kiedy | Uwaga |
Wyłączenie konta w katalogu firmowym | W dniu zakończenia pracy, o ustalonej godzinie | Wyłączenie, nie usunięcie. Usunięcie nie kasuje uprawnień, tylko zamienia je w nieczytelne wpisy |
Unieważnienie aktywnych sesji i przepustek | W tym samym kroku, nie później | Osobna operacja. Bez niej dostęp trwa dalej, w niektórych przypadkach godzinami |
Usunięcie prywatnego numeru i adresu e-mail z metod odzyskiwania hasła | W tym samym kroku | Inaczej zostaje droga do samodzielnego resetu hasła |
Wymuszenie wylogowania z urządzeń mobilnych | W dniu zakończenia pracy | Firmowa poczta na prywatnym telefonie to najczęściej pomijany kanał |
Odebranie dostępu zdalnego do sieci firmowej | W dniu zakończenia pracy | Konto, certyfikat i ewentualny klucz zapisany na urządzeniu |
Usunięcie kluczy do serwerów | W dniu zakończenia pracy | Nie znikają same. Trzeba przejść po serwerach albo mieć to zarządzane centralnie |
Unieważnienie osobistych kluczy i tokenów dostępu do systemów | W dniu zakończenia pracy | Klucze do repozytoriów kodu i usług chmurowych żyją niezależnie od konta |
Wycofanie zgód wydanych aplikacjom zewnętrznym | W dniu zakończenia pracy | Aplikacja z dostępem do skrzynki albo dysku działa dalej po zablokowaniu konta |
Sprawdzenie i usunięcie reguł przekazywania poczty oraz dostępów delegowanych | W dniu zakończenia pracy | Reguła ustawiona samodzielnie przed odejściem przetrwa wyłączenie konta |
Zmiana haseł do kont współdzielonych, które ta osoba znała | Do następnego dnia roboczego | Jedyny moment, w którym da się to przeforsować organizacyjnie |
Odebranie dostępu do aplikacji chmurowych poza katalogiem | Do następnego dnia roboczego | Wymaga listy tych aplikacji, więc trzeba ją mieć wcześniej |
Obsługa skrzynki pocztowej | Do następnego dnia roboczego | Przekierowanie albo dostęp dla przełożonego, nie zostawianie konta aktywnego |
Odbiór sprzętu i zablokowanie urządzeń, które nie wróciły | Do 7 dni | Laptop z zapisanymi danymi logowania wpuszcza bez kontaktu z siecią firmową |
Przekazanie danych z dysku i z zasobów osobistych | Do 14 dni | Robi się to na wyłączonym koncie, uprawnieniami administracyjnymi |
Zwolnienie licencji | Po zakończeniu przekazywania danych | W tej kolejności, nie odwrotnie: po zwolnieniu licencji zawartość skrzynki i dysku przepada po okresie przechowywania ustawionym u dostawcy |
Wpis w dokumentacji | Po wykonaniu odcięcia | Data, wykonawca, lista odebranych dostępów |
Kontrola wykonania | Po 7 do 14 dniach | Czy konto próbowało się logować po dacie odcięcia, czy nie ma nieudanych prób i czy żadna integracja nie pracuje dalej na jego uprawnieniach |
Wyłączamy, nie usuwamy. Usunięcie konta wygląda na dokładniejsze, a jest gorsze. Uprawnienia do plików zapisane są jako powiązania z wewnętrznym identyfikatorem konta, więc po jego usunięciu w listach uprawnień zostają wpisy, których nie da się już przypisać do żadnej osoby. Odtworzenie, kto miał dostęp do czego, przestaje być możliwe.
Kiedy więc usuwać? Wyłączone konto przestaje być potrzebne, gdy dane zostały przekazane, a sprawy zamknięte, i od tego momentu trzymanie go samo zaczyna być problemem, bo jest przetwarzaniem danych bez celu. Nie podamy jednej dobrej liczby, bo zależy ona od tego, jakie dane firma trzyma i jak długo musi. Sensownym punktem wyjścia jest kilka miesięcy dla konta i skrzynki, z ustalonym terminem i decyzją zapisaną razem z resztą dokumentacji, zamiast bezterminowego “na wszelki wypadek”.
Trzy sytuacje, które trzeba obsłużyć inaczej
Rozstanie konfliktowe. Standardowa kolejność, czyli rozmowa, a potem odebranie dostępów, jest tu dokładnie odwrotna, niż być powinna. Okno między “wiem, że jestem zwalniany” a “nie mam już dostępu” nie powinno istnieć. Wymaga to ustaleń z kadrami i zarządem z góry, bo w dniu zdarzenia nie ma na to czasu. Sekwencja, którą proponujemy: kadry uzgadniają godzinę rozmowy i informują IT dzień wcześniej, IT przygotowuje wszystko tak, żeby odciąć dostępy jednym ruchem, wyłączenie konta i unieważnienie sesji następuje w momencie rozpoczęcia rozmowy, zdalny dostęp i poczta na telefonie idą razem z nim, a hasła do kont współdzielonych zmieniane są w ciągu godziny. Sprzęt odbiera się na tej samej rozmowie. Nie chodzi o brak zaufania do konkretnej osoby, a o to, żeby nie stawiać jej w sytuacji, w której ma jednocześnie pokusę i możliwość.
Współpraca terminowa: kontraktor, firma zewnętrzna, praktykant. Tu w ogóle nie ma odejścia, bo nie ma zatrudnienia w rozumieniu kadr, więc żaden proces kadrowy się nie uruchomi. Rozwiązaniem jest data wygaśnięcia ustawiana na koncie z góry. Active Directory ma do tego wbudowany atrybut i to jest jego prawdziwe zastosowanie: konto po tej dacie przestaje działać samo, bez niczyjej decyzji i bez pamiętania o czymkolwiek. Umowa na trzy miesiące to konto ważne trzy miesiące. Przedłużenie umowy staje się wtedy zdarzeniem, przy którym ktoś świadomie przedłuża też konto, i to jest dokładnie ten moment, w którym powinien się nad jego uprawnieniami zastanowić.
Zmiana roli w firmie. Najczęstszy powód rozrostu uprawnień i najczęściej pomijany w procedurach, bo nikt nie odchodzi, więc formalnie nic się nie dzieje. Zmiana stanowiska powinna uruchamiać ten sam przegląd co odejście, z jedną różnicą: zamiast odebrania wszystkiego jest odebranie tego, co należało do starej roli, i nadanie tego, co należy do nowej. Nie nadanie nowego na wierzch starego.
Jak znaleźć istniejące konta widma
Proces na przyszłość nie usuwa tego, co narosło. Trzeba to policzyć raz, na starcie, i jest to osobna robota: raport kont, które się nie logują, lista kont z uprawnieniami administracyjnymi, inwentaryzacja kont technicznych oraz przegląd dostępów, których w katalogu w ogóle nie ma, bo powstały poza IT. Najlepiej robić to przy okazji szerszego audytu bezpieczeństwa IT, bo wyniki przeglądu kont czyta się razem z resztą obrazu infrastruktury.
Czeka tam kilka pułapek, przez które taki przegląd najczęściej się wykłada. Największa dotyczy daty ostatniego logowania: Active Directory przechowuje ją w dwóch miejscach i żadne nie jest tak dokładne, jak się wydaje, więc próg krótszy niż dwa tygodnie daje fałszywe trafienia i podważa zaufanie do całego zestawienia. Jak zrobić taki przegląd porządnie, jakie progi przyjąć i czego szukać w wynikach, rozpisaliśmy w osobnym wpisie o przeglądzie kont i uprawnień.
Jedno ustaw od razu, niezależnie od przeglądu: powiadomienia na trzy zdarzenia, czyli logowanie konta, które milczało od kilku miesięcy, ponowne włączenie konta wcześniej wyłączonego oraz dopisanie kogokolwiek do grupy dającej uprawnienia administracyjne. Wszystkie trzy zdarzają się rzadko i każde jest albo pomyłką, albo czymś, o czym trzeba wiedzieć od razu.
Dlaczego weryfikacja tożsamości tego nie łapie
Zestawmy konta widma z podejściem, które w bezpieczeństwie IT uchodzi dziś za docelowe. Zero Trust, w skrócie, sprowadza się do weryfikowania każdej próby dostępu osobno, zamiast ufania temu, że ktoś jest już w środku firmowej sieci. Rozpisaliśmy to w tekście o błędach we wdrożeniach Zero Trust.
Konta widma pokazują, gdzie ta idea się rozjeżdża w praktyce. Zero Trust weryfikuje tożsamość. Nie sprawdza, czy ta tożsamość powinna jeszcze istnieć. Konto byłego pracownika przechodzi weryfikację wzorowo: hasło się zgadza, drugi składnik odpowiada, urządzenie jest znane, wszystkie warunki polityki dostępu spełnione. System działa dokładnie tak, jak go zaprojektowano, i wpuszcza kogoś, kto nie powinien już mieć wstępu.
Ten sam mechanizm dotyczy pozostałych warstw. Segmentacja sieci ogranicza zasięg ataku, ale przepuszcza ruch tam, gdzie reguła na to pozwala, a reguły pisze się pod role, które konto formalnie ma. Firewall nowej generacji potrafi budować reguły dla konkretnych użytkowników i grup, po integracji z katalogiem, i wykona je bezbłędnie także dla kogoś, kto odszedł pół roku temu. Kopie zapasowe pozwalają odtworzyć dane, tylko atakujący z ważnym hasłem do systemu kopii zaczyna właśnie od nich. Pisaliśmy o tym w poradniku o ransomware: repozytorium kopii jest w takim ataku celem numer jeden.
Tożsamość jest warstwą, na której stoją wszystkie pozostałe. Jeżeli lista kont nie odpowiada rzeczywistości, każde zabezpieczenie zbudowane powyżej działa poprawnie na błędnych danych wejściowych.
Dziewięć błędów w offboardingu IT, które powtarzają się najczęściej
- Brak zdarzenia uruchamiającego odbieranie dostępów. IT dowiaduje się o odejściu przypadkiem. Wszystko inne jest konsekwencją tego jednego braku.
- Wyłączenie konta bez unieważnienia sesji. Najbardziej zdradliwy, bo administrator ma pełne prawo sądzić, że skończył robotę.
- Zostawienie konta aktywnego, żeby “przekazać pliki”. Powód nieistniejący, bo dane z wyłączonego konta przenosi się bez problemu.
- Zakładanie konta nowemu pracownikowi przez skopiowanie konta kolegi. Pięć minut oszczędności i uprawnienia, których nikt nigdy nie przejrzy.
- Zmiana stanowiska bez odebrania starych dostępów. Uprawnienia się dokładają, więc po latach zakres dostępu przestaje odpowiadać czemukolwiek.
- Konta współdzielone. Nie do rozliczenia i nie do odebrania. Każde z nich to trwała dziura w każdej procedurze.
- Wyjątki od drugiego składnika. Jedno konto wyjęte “tymczasowo”, bo ktoś zgubił telefon przed wyjazdem. Wyjątki są trwalsze niż powody, dla których powstały, i prawie zawsze dotyczą kont z dużymi uprawnieniami, bo to ich właściciele mają siłę przebicia.
- Przegląd uprawnień jako jednorazowy projekt. Zrobiony raz przed audytem, po czym lista znowu zaczyna rosnąć. Bez kadencji i bez właściciela procesu wraca do stanu wyjściowego w ciągu roku.
- Brak dokumentacji wykonania. Jest procedura, jest wykonana, nie ma zapisu. Z perspektywy audytora to to samo, co brak procedury.
Konta widma a NIS2
NIS2 to unijna dyrektywa o cyberbezpieczeństwie, która nakłada obowiązki na firmy z wyznaczonych sektorów, między innymi energetyki, transportu, ochrony zdrowia, wodociągów, gospodarki odpadami, produkcji oraz produkcji i dystrybucji żywności. Dzieli je na podmioty kluczowe i ważne, głównie według wielkości i znaczenia dla gospodarki. W Polsce wdrożono ją nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa.
Powiemy od razu rzecz, którą teksty o NIS2 zwykle pomijają: w dyrektywie nie ma przepisu, który wprost nakazuje wyłączyć konto odchodzącemu pracownikowi. Nie ma w niej słów “cykl życia konta” ani “przegląd uprawnień”.
Jest coś innego. Artykuł 21 ustęp 2 dyrektywy wymienia obowiązkowe środki zarządzania ryzykiem i w jednej literze, oznaczonej jako litera i), stawia obok siebie trzy rzeczy: bezpieczeństwo zasobów ludzkich, polityki kontroli dostępu i zarządzanie aktywami. Kolejna litera, j), mówi o stosowaniu uwierzytelniania wieloskładnikowego, choć z zastrzeżeniem “w stosownych przypadkach”. Litera g) dotyczy podstawowych praktyk higieny cyfrowej i szkoleń.
Zestawienie spraw kadrowych z kontrolą dostępu w jednym przepisie nie jest przypadkiem redakcyjnym. Z punktu widzenia ryzyka to jeden temat i dyrektywa tak go traktuje. Praktyczna konsekwencja: firma objęta NIS2 musi mieć politykę kontroli dostępu i musi umieć pokazać, że ona działa. Polityki z kontami bez właściciela pokazać się nie da.
Polski harmonogram jest już konkretny. Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa weszła w życie 3 kwietnia 2026 roku. Część podmiotów Minister Cyfryzacji wpisał do wykazu z urzędu jeszcze w kwietniu i maju, pozostałe składają wniosek same, a termin na to upływa 3 października 2026 roku. Na wdrożenie systemu zarządzania bezpieczeństwem informacji, czyli uporządkowanego zestawu procedur i zabezpieczeń wraz z osobami za nie odpowiedzialnymi, jest czas do 3 kwietnia 2027 roku. Podmioty kluczowe, które wcześniej nie były operatorami usług kluczowych, przeprowadzają pierwszy audyt do 3 kwietnia 2028 roku, a kolejne co najmniej raz na trzy lata od podpisania poprzedniego raportu. Co z tego wynika technicznie, rozpisaliśmy we wpisie o przygotowaniu organizacji do NIS2.
Jest jednak druga regulacja, o której w tym kontekście mówi się za rzadko, a obowiązuje bez żadnego okresu przejściowego i od dawna. RODO w artykule 32 ustęp 2 każe przy ocenie odpowiedniego poziomu zabezpieczeń uwzględniać w szczególności ryzyko wynikające z “nieuprawnionego ujawnienia lub nieuprawnionego dostępu do danych osobowych przesyłanych, przechowywanych lub w inny sposób przetwarzanych”. Konto byłego pracownika sięgające bazy klientów jest gotowym opisem takiego ryzyka. Nie jesteśmy kancelarią prawną i nie rozstrzygamy, jak organ nadzorczy oceniłby konkretny przypadek. Zwracamy tylko uwagę, że argument “nas NIS2 nie dotyczy” nie zamyka tematu, bo RODO dotyczy każdego, kto przetwarza dane osobowe.
Jak to robimy
Zaczynamy od liczby, nie od rekomendacji. Pierwsze, co powstaje, to lista: ile jest kont w katalogu, ile z nich nie logowało się od trzech miesięcy, ile ma uprawnienia administracyjne, ile jest kontami technicznymi i dla ilu z nich da się wskazać właściciela. Spodziewamy się, że kont wyjdzie więcej niż etatów, i zwykle to wystarcza, żeby rozmowa o procedurach przestała być teoretyczna.
Potem porządkujemy to, co jest. Redukcja uprawnień do rzeczywistych potrzeb, rozdzielenie kont administracyjnych od kont do codziennej pracy, uporządkowanie kont technicznych i przejście na konta z hasłem zarządzanym przez system tam, gdzie aplikacje to obsługują. Do tego przegląd i korekta konfiguracji samego katalogu, co w branży nazywa się hardeningiem Active Directory: zasady domenowe, polityka haseł dopasowana do ryzyka, a nie do nawyku, weryfikacja poprawności przekazywania danych między serwerami obsługującymi konta.
Dla kont uprzywilejowanych stawiamy jeden serwer, przez który przechodzi każda sesja administracyjna, z uwierzytelnianiem wieloskładnikowym i zapisem tego, kto się logował, kiedy i jakie polecenia wykonał. Bezpośredni dostęp z komputera administratora do serwerów zostaje zablokowany. Efektem jest coś, czego sama procedura nie da: dowód, a nie deklaracja.
Na koniec proces. Wzorzec procedury przyjmowania pracownika, zmiany roli i offboardingu IT, przygotowany technicznie po naszej stronie i zatwierdzany po stronie klienta, bo to on odpowiada za jego obowiązywanie w organizacji. Do tego kadencja przeglądów i alarmy opisane wyżej. Prowadzimy to w ramach bezpiecznego zarządzania tożsamością.
Jedna uwaga o drugim składniku. Kod z SMS-a traktujemy jako plan B: to najsłabszy z dostępnych składników, bo numer telefonu da się przenieść do innego operatora, a wiadomość przechwycić. Odradzamy go wszędzie tam, gdzie jest cokolwiek innego do wyboru, a przy kontach uprzywilejowanych, dostępie zdalnym i systemach krytycznych nie powinien być jedynym zabezpieczeniem. Aplikacja w telefonie jest wyraźnie lepsza, a klucz sprzętowy, czyli mały fizyczny token wpinany do komputera, najlepszy.
Najczęściej zadawane pytania
Czy wystarczy wyłączyć konto w Active Directory? Nie. Wyłączenie blokuje wydawanie nowych przepustek dostępu, ale te już wydane działają do wygaśnięcia, domyślnie do 10 godzin, a połączenia już uwierzytelnione trwają dalej. Aplikacje chmurowe mogą utrzymywać własną sesję znacznie dłużej, klucze na serwerach nie znikają wcale, laptop bez kontaktu z siecią firmową wpuści na stare hasło, a dostępy do aplikacji poza katalogiem trzeba odebrać osobno. Wyłączenie konta jest pierwszym krokiem offboardingu IT, nie całym offboardingiem.
Ile kont widm ma typowa firma? Nie podamy liczby, bo każda byłaby zmyślona. Powiemy natomiast tyle: liczba kont w katalogu bywa wyraźnie wyższa niż liczba zatrudnionych, a różnicy nikt nie potrafi wyjaśnić bez przeglądu. To pytanie, na które każda firma odpowie sobie sama w jeden dzień, i warto to zrobić przed rozmową o czymkolwiek innym.
Jak często robić przegląd uprawnień? Raz na kwartał dla kont uprzywilejowanych i technicznych, raz na pół roku dla pozostałych. Ważniejsza od częstotliwości jest jednak druga rzecz: przegląd musi mieć właściciela, czyli osobę, która odpowiada zarówno za jego przeprowadzenie, jak i za podjęcie decyzji o odebraniu dostępu. Przegląd bez uprawnienia do odbierania niczego nie zmienia.
Kto powinien odpowiadać za odbieranie dostępów: kadry czy IT? Kadry zgłaszają, IT wykonuje. Informacja o odejściu powstaje w kadrach, więc tam musi być obowiązek jej przekazania, a nie dobra wola. Narzędzia i wiedza są w IT, więc tam jest wykonanie i dokumentacja. Naszym zdaniem najwięcej kont widm mają firmy, w których nie ustalono, kto uruchamia proces, niezależnie od tego, jak dobre mają narzędzia.
Mamy jedno logowanie do wszystkich systemów. To rozwiązuje problem? Rozwiązuje jego dużą część, bo daje jeden punkt, z którego odcina się dostęp do wielu aplikacji naraz. Nie rozwiązuje dwóch rzeczy: sesji już otwartych w aplikacjach, które utrzymują je własnymi ustawieniami, oraz dostępów, które nigdy do tego logowania nie zostały podłączone, czyli kont zakładanych lokalnie na serwerach, urządzeń sieciowych i aplikacji wykupionych poza działem IT.
Czy uwierzytelnianie wieloskładnikowe rozwiązuje problem kont widm? Nie. Chroni przed wykorzystaniem wykradzionego hasła i robi to bardzo skutecznie. Konto byłego pracownika ma jednak drugi składnik skonfigurowany na jego prywatnym telefonie, więc dla tego konkretnego zagrożenia jest to zabezpieczenie stojące po stronie atakującego. To dwa różne problemy i potrzebują dwóch różnych rozwiązań.
Co z osobą, która pracuje na umowie B2B albo przez firmę zewnętrzną? Dla niej nie uruchomi się żaden proces kadrowy, bo formalnie nie ma zatrudnienia. Dlatego takie konta zakładamy od razu z datą wygaśnięcia zgodną z terminem umowy. Przy dostępach dla firm zewnętrznych dochodzi drugi problem: rotację ich pracowników widzi tylko ta firma. Rozwiązaniem jest dostęp imienny zamiast wspólnego konta dla dostawcy oraz obowiązek zgłaszania zmian po jego stronie, wpisany do umowy.
Wyłączać konto czy usuwać? Wyłączyć od razu, usunąć później. Usunięcie zamienia uprawnienia do plików we wpisy, których nie da się przypisać do żadnej osoby, więc odtworzenie, kto miał do czego dostęp, przestaje być możliwe. Trzymanie wyłączonego konta bezterminowo też nie jest dobrym pomysłem, bo to przetwarzanie danych bez celu. Ustal termin i zapisz go razem z resztą procedury.
Konto zostaje dłużej niż człowiek
Konta widma nie są problemem technicznym. Każdy krok z tego tekstu wykonasz narzędziami, które firma już ma, i większość z nich zajmuje minuty. Problem jest inny: nikt nie jest właścicielem pytania “kto dziś ma dostęp do czego”. Dopóki tak jest, odpowiedź będzie się z roku na rok pogarszać, bo dostępów przybywa, a nie ubywa.
Firma, która wie, ile ma kont, kto za nie odpowiada i co się dzieje w dniu, kiedy ktoś odchodzi, nie tylko spełnia wymóg z dyrektywy. Zamyka klasę zagrożeń, do której atakującemu nie potrzeba żadnych umiejętności.
Robimy przegląd kont i uprawnień, hardening Active Directory, wdrożenia uwierzytelniania wieloskładnikowego i jednego logowania oraz kontrolę dostępu administracyjnego w ramach bezpiecznego zarządzania tożsamością. Wynikiem jest konkretna lista kont do wyłączenia i uprawnień do odebrania, nie zestaw rekomendacji. Jeśli chcesz sprawdzić, jak to wygląda u Ciebie, zadzwoń: +48 12 210 02 82.
