Shadow IT widziane z zewnątrz: czego nie widzisz, a atakujący już zeskanował

Shadow IT to wszystko, co należy do organizacji i nie ma właściciela

Shadow IT to zasoby, które działają w imieniu organizacji, ale nie figurują w żadnym rejestrze i nie mają przypisanej osoby odpowiedzialnej. Definicja celowo nie mówi nic o zgodzie działu IT, bo brak zgody jest tylko jedną z dróg dojścia do tego stanu. Równie często zasób powstał legalnie, z akceptacją i budżetem, po czym projekt się skończył, ludzie zmienili role, a serwer został włączony.

Spojrzenie od środka i spojrzenie z zewnątrz dają dwie różne listy. Od środka widać to, co ktoś kiedyś wpisał do ewidencji: umowy, licencje, hosty w monitoringu, konta w katalogu tożsamości. Z zewnątrz widać to, co odpowiada na zapytanie z internetu, niezależnie od tego, czy ktokolwiek o tym pamięta. Interesująca jest wyłącznie różnica między tymi listami.

Asymetria jest po stronie atakującego. Nie musi wiedzieć, jak wygląda struktura organizacyjna ani który dział zamawiał usługę: wystarczy mu nazwa domeny, żeby zacząć. Zapomniany host nie przestaje odpowiadać dlatego, że nikt go nie pamięta.

Co realnie znajdujesz na zewnętrznej powierzchni ataku

Katalog znalezisk jest krótszy, niż się wydaje, i powtarza się między organizacjami niezależnie od branży. To kategorie, które wychodzą przy pierwszej inwentaryzacji prowadzonej od strony internetu, zanim ktokolwiek zajrzy do środka sieci.

Wszystkie siedem kategorii łączy jedno: w chwili powstania każda miała właściciela i uzasadnienie. Zasób nie stał się shadow IT dlatego, że ktoś złamał zasady, tylko dlatego, że zniknęła osoba, która wiedziała, po co on istnieje. To rozróżnienie prowadzi do innych działań naprawczych niż szukanie winnego.

Dlaczego to powstaje bez niczyjej złej woli

Mechanizmy powstawania shadow IT są procesowe, nie charakterologiczne, i dają się wymienić na jednej ręce. Żaden nie wymaga nieuczciwości ani nawet niefrasobliwości.

• Presja czasu przy uruchomieniu, kiedy termin jest pierwszym punktem listy, a ograniczenie dostępu ostatnim
• Projekt zamknięty bez wygaszenia zasobów, bo w harmonogramie jest odbiór i faktura, a nie ma pozycji „wyłącz środowisko testowe”
• Migracja bez inwentaryzacji, w której przenosi się to, co znane, i zostawia to, o czym nikt nie wspomniał
• Dział zamawiający narzędzie szybciej, niż zrobiłby to dział IT, bo ścieżka formalna trwa dłużej niż potrzeba
• Zmiana ludzi: właściciel zasobu awansował, zmienił zespół albo odszedł, a odpowiedzialności nikomu nie przekazano

Wniosek jest niewygodny dla polityk pisanych w trybie zakazu. Zakaz zakładania kont bez zgody IT nie usuwa powodu, dla którego konta powstają, tylko przenosi je poza pole widzenia. Działają dwa inne elementy: obowiązkowy krok wygaszenia przy zamykaniu projektu oraz reguła, że zasób bez właściciela nie może przetrwać najbliższego przeglądu.

Shadow IT kontra shadow AI

Narzędzia AI wprowadziły klasę shadow IT, której nie widać w żadnym skanie od zewnątrz. Klasyczne shadow IT to zasób, który odpowiada z internetu i wpuszcza kogoś do środka. Shadow AI to usługa, do której dane wychodzą, niezatwierdzona przez nikogo i widoczna wyłącznie od strony stacji roboczej. Kierunek ruchu jest odwrotny, więc odwrotna jest też metoda wykrywania.

Skalę korzystania z niezatwierdzonych narzędzi AI i sposób kontrolowania treści wychodzącej ze stacji roboczej opisujemy w tekście o systemie DLP i kanałach wycieku danych. Tutaj wystarczy jeden wniosek: przegląd prowadzony wyłącznie od zewnątrz nie wykryje shadow AI, a przegląd prowadzony wyłącznie od środka nie wykryje zapomnianej subdomeny.

Jedna kategoria należy do obu światów naraz: asystenty i wtyczki AI podpięte do firmowego środowiska przez zgodę OAuth. Taka integracja ma token w katalogu tożsamości, działa z uprawnieniami użytkownika i przeżywa jego odejście tak samo jak klucz API po zakończonym projekcie. Rejestr zgód aplikacji w Microsoft 365 i Entra ID jest tu tym, czym wpisy DNS przy zasobach wystawionych do internetu: jedyną listą, na której to widać.

Jak wygląda inwentaryzacja z zewnątrz

Dyscyplina, która się tym zajmuje, nazywa się zarządzaniem zewnętrzną powierzchnią ataku (attack surface management, ASM) i sprowadza się do kilku kroków wykonywanych w kółko, a nie do jednego skanu. Kolejność jest istotna, bo wartość powstaje dopiero w kroku drugim.

Odkrywanie zasobów

Punktem wyjścia jest to, co organizacja zostawia w rejestrach publicznych: nazwy domen, wpisy DNS, logi wystawionych certyfikatów, przypisane zakresy adresowe. Z tych źródeł buduje się listę hostów i usług odpowiadających z internetu. Bywa dłuższa niż arkusz prowadzony przez dział IT, i nie jest to zarzut wobec działu IT: rejestr opisuje decyzje, a skan opisuje stan faktyczny.

Dopasowanie do właściciela

To krok najtrudniejszy i jednocześnie ten, w którym powstaje cała wartość ćwiczenia. Lista zasobów bez właścicieli nie prowadzi do żadnej naprawy, bo nie ma komu zgłosić zadania. Każdą pozycję trzeba rozstrzygnąć do jednej z trzech kategorii: zasób nasz z właścicielem, zasób nasz bez właściciela oraz zasób, który tylko wygląda na nasz. Środkowa kategoria to właśnie shadow IT i na niej kończy się przegląd prowadzony wyłącznie narzędziowo, bez rozmów z ludźmi.

Ocena ekspozycji i priorytet

Dopiero na liście z właścicielami da się ocenić ekspozycję: co jest osiągalne bez uwierzytelnienia, co wystawia panel logowania, co działa na wersji bez wsparcia, a co jest zwykłą stroną informacyjną. Priorytet wynika ze skutku przejęcia, nie z liczby zwróconej przez skaner. Ponieważ powierzchnia zmienia się z każdym wdrożeniem, cykl ma sens jako monitorowanie ekspozycji organizacji prowadzone w sposób ciągły. Tak działa nasza usługa zarządzania zewnętrzną powierzchnią ataku: wykrywanie zasobów i shadow IT, wskazanie błędnych konfiguracji i raport z priorytetem ryzyka.

Jednorazowy skan jest zdjęciem, a nie inwentaryzacją. Zasób poprawnie skonfigurowany dziś może zostać wystawiony jutro, przez zmianę w regule brzegowej wprowadzoną w trybie awaryjnym. Wartość ma porównanie kolejnych przeglądów, bo to ono pokazuje, co pojawiło się od ostatniego razu i czego nikt nie zgłaszał.

Zapomniany zasób a wyciek danych logowania

Shadow IT łączy się z wyciekami dwiema drogami, a każda prowadzi do innych działań. Pierwsza to wejście: niezaktualizowana usługa wystawiona do internetu jest dokładnie tym, czego szuka atakujący odsprzedający potem dostęp dalej. Verizon wskazał wykorzystanie podatności w oprogramowaniu jako początek 31% naruszeń (Verizon DBIR 2026, dostęp 17 sierpnia 2026), a zasób bez właściciela z definicji nie ma nikogo, kto zainstaluje poprawkę. W łańcuchu, w którym broker dostępu odsprzedaje wejście grupie ransomware, takie hosty bywają pierwszym ogniwem.

Druga droga jest odwrotna: to sam zasób bywa źródłem danych logowania w obiegu. Osierocone konto w usłudze chmurowej ma hasło zapisane w przeglądarce byłego pracownika, a log infostealera z jego prywatnego komputera zawiera i adres usługi, i to hasło. Nikt go nie zresetuje, bo nikt o tym koncie nie wie, a Group-IB opisuje przypadki, w których te same poświadczenia krążyły w rozsyłanych plikach wiele miesięcy po pierwotnej infekcji (Group-IB, dostęp 17 sierpnia 2026). Dlatego monitorowanie wycieków danych i inwentaryzacja zasobów odpowiadają na to samo pytanie z dwóch stron, a samą kradzież poświadczeń rozkładamy na części w tekście o tym, jak działa infostealer.

Nie da się chronić zasobu, o którym nikt nie wie

Inwentaryzacja jest pierwszym krokiem audytu i analizy ryzyka, a nie jednym z ich rozdziałów. Zakres badania wyznacza lista zasobów, więc zasób spoza listy jest poza zakresem, nawet jeśli formalnie nikt go nie wyłączył. Tak samo działa to przy testach: raport opisuje to, co znalazło się w uzgodnionym zakresie, a nie wszystko, co organizacja wystawia. Jak wygląda ta praca po kolei, opisujemy w tekście o tym, jak przebiega audyt cyberbezpieczeństwa.

W obowiązkach regulacyjnych zależność jest jeszcze bardziej dosłowna. Zarządzanie ryzykiem, którego wymagają przepisy o krajowym systemie cyberbezpieczeństwa, zakłada, że wiadomo, co się chroni, więc rejestr zasobów jest warunkiem wstępnym, a nie efektem ubocznym. Kogo te obowiązki obejmują, rozpisujemy w tekście o NIS2 i ustawie o KSC.

Jak zrobić pierwszy przegląd u siebie

Pierwszy przegląd da się przeprowadzić bez żadnej platformy, siłami własnego zespołu, choćby po to, żeby poznać skalę. Kolejne kroki opierają się na poprzednich.

Efekt tej pracy utrzymuje jedna reguła: każdy zasób ma właściciela i datę przeglądu. Właściciel odpowiada na pytanie, komu zgłosić problem, data przeglądu na pytanie, kiedy sprawdzimy, czy zasób jest jeszcze potrzebny. Rejestr bez tych dwóch pól starzeje się w jeden kwartał i wraca do stanu wyjściowego.

Najczęstsze pytania

Podsumowanie

Shadow IT jest problemem inwentaryzacyjnym, a nie dyscyplinarnym, i dlatego zakazy działają na nie tak słabo. Zasoby bez właściciela powstają z normalnej pracy organizacji: z terminów, migracji, zamkniętych projektów i zmian personalnych. Pytanie brzmi nie „czy je mamy”, tylko „jak długo żyją, zanim ktoś je zauważy”, a odpowiedź zależy od tego, czy ktokolwiek patrzy na organizację od tej samej strony, z której patrzy atakujący. Pierwszym krokiem nie jest zakup narzędzia, tylko lista domen i pytanie, kto jest właścicielem każdej pozycji, którą ta lista ujawni.

Atakującego nie interesuje, czy zasób jest w Twojej ewidencji. Interesuje go wyłącznie to, czy odpowiada.