Czym jest shadow IT i dlaczego stało się normą, a nie wyjątkiem
Definicja shadow IT i faktyczny zakres zjawiska
Shadow IT to każde narzędzie informatyczne – aplikacja, usługa chmurowa, skrypt, urządzenie – używane w organizacji bez wiedzy lub zgody działu IT czy bezpieczeństwa. Nie chodzi wyłącznie o „zakazane” programy. W praktyce większość cichego IT powstaje z dobrych intencji: przyspieszenia pracy, obejścia biurokracji, szybkiego przetestowania rozwiązania.
Kluczowe jest kryterium braku widoczności i kontroli. Jeżeli dział IT nie wie, że dany zespół przeniósł część działań do nowego narzędzia SaaS, nie ma możliwości oceny ryzyka, wdrożenia zabezpieczeń, kopii zapasowych, zgodności z RODO czy umowami z klientami. Nawet jeśli aplikacja sama w sobie jest „bezpieczna”, to użycie jej w niekontrolowany sposób zmienia ją w potencjalne źródło incydentów.
Zakres shadow IT jest znacznie szerszy niż tylko „instalowanie programów na własną rękę”. W praktyce obejmuje między innymi:
prywatne chmury (np. prywatny Google Drive, Dropbox, iCloud) do służbowych dokumentów,
komunikatory (np. WhatsApp, Messenger, prywatny Slack) do komunikacji o sprawach firmowych,
rozszerzenia przeglądarek (adblocki, dodatki do notatek, tłumacze, menedżery haseł) nieweryfikowane przez IT,
makra i własne automatyzacje w Excelu, Google Sheets, Power Automate, Zapier, Make,
narzędzia do podpisu, skanowania, OCR używane ad hoc do dokumentów firmowych,
prywatne repozytoria kodu (np. GitHub na prywatne konto) dla projektów firmowych.
Wiele z tych rozwiązań działa „na słowo honoru”: brak umów powierzenia danych, niejasne lokalizacje serwerów, brak logów dostępu. To właśnie ten brak formalnej i technicznej kontroli przesuwa je z kategorii „narzędzie” do kategorii shadow IT.
„Niezatwierdzone” a „nieznane” aplikacje – subtelna, ale kluczowa różnica
W zarządzaniu ryzykiem shadow IT przydaje się rozróżnienie na:
aplikacje niezatwierdzone – dział IT wie, że istnieją, ale nie zostały zaakceptowane do użycia (np. po audycie ryzyka),
aplikacje nieznane – dział IT w ogóle nie ma świadomości, że są używane w organizacji.
W pierwszym przypadku istnieje przynajmniej jakaś wiedza: co to za narzędzie, jakie ma API, gdzie leżą dane, jakie ma regulaminy. Można je blokować, monitorować albo świadomie tolerować w ograniczonym zakresie. W drugim przypadku mówimy o całkowitej ciemności – brak widoczności oznacza brak reakcji aż do momentu incydentu.
W praktyce najgroźniejsze są nie tyle aplikacje, o których IT wie i których zakazało, ile właśnie „ślepe plamy”: małe SaaS-y, mało znane usługi, wtyczki i automaty, które „po cichu” zaczynają przetwarzać krytyczne dane. Często okazuje się, że to, co zaczęło się jako eksperyment jednego pracownika, po kilku miesiącach staje się produkcyjnym elementem procesu biznesowego – nadal poza radarem bezpieczeństwa.
Dlaczego shadow IT eksplodowało: SaaS, praca zdalna, presja biznesu
Jeszcze kilkanaście lat temu w wielu firmach każda nowa aplikacja oznaczała kontakt z dostawcą, wdrożenie na serwerze, szkolenie, formalny proces zakupu. Dziś większość narzędzi to SaaS (Software as a Service) w modelu „załóż konto – używaj” z wersją freemium dostępną od ręki. To całkowicie zmienia dynamikę.
Najważniejsze czynniki napędzające shadow IT to:
łatwy dostęp do SaaS – karta firmowa, darmowy trial, kilka kliknięć i zespół może zacząć pracować w nowym narzędziu, zanim ktokolwiek zdąży je formalnie zgłosić,
praca zdalna i hybrydowa – użytkownicy logują się z prywatnych urządzeń, czasami poza VPN, a polityki bezpieczeństwa stacjonarnych biur po prostu ich nie obejmują,
presja „na jutro” – biznes oczekuje szybkich efektów; procesy zakupowe i bezpieczeństwa trwają tygodniami, więc pojawia się naturalny odruch: „zróbmy to tymczasowo w X, potem się ucywilizuje” – co prawie nigdy nie następuje,
kultura „testuj wszystko” – w marketingu, sprzedaży czy produktach panuje moda na eksperymentowanie z narzędziami, A/B testy, integracje bez udziału IT.
Do tego dochodzi jeszcze jeden ważny aspekt: UX i innowacyjność nowoczesnych narzędzi chmurowych. W porównaniu z często topornymi, korporacyjnymi systemami, lekkie aplikacje SaaS są przyjemne w obsłudze i skoncentrowane na konkretnych przypadkach użycia. Użytkownicy głosują nogami – wybierają to, co działa i sprawia mniej bólu.
Kiedy shadow IT bywa „szarą strefą”, a kiedy staje się realnym zagrożeniem
Nie każde ciche narzędzie musi od razu oznaczać katastrofę. W wielu organizacjach istnieje pewna świadomie tolerowana „szara strefa”, gdzie pracownicy korzystają z prostych aplikacji nieprzetwarzających danych wrażliwych – np. do notatek osobistych, prostych timerów, planowania zadań.
Z punktu widzenia ryzyka kluczowe są następujące pytania:
czy aplikacja przetwarza dane klientów, pracowników lub dane finansowe (dane osobowe, dane handlowe, tajemnice przedsiębiorstwa)?,
czy narzędzie jest elementem procesu krytycznego (np. obsługa zamówień, fakturowanie, obsługa incydentów)?,
czy dane są przechowywane wyłącznie w tej aplikacji, bez kopii w systemach kontrolowanych przez organizację?,
czy istnieje formalna umowa powierzenia danych i zgodność z wymaganiami (RODO, branżowe regulacje, umowy SLA z klientami)?
Jeżeli narzędzie jest używane tylko do szkiców, testów, danych syntetycznych – ryzyko jest ograniczone, choć nadal warto je widzieć i dokumentować. Problem zaczyna się, gdy shadow IT obsługuje realne procesy produkcyjne: obsługę leadów, korespondencję z klientami, dokumenty prawne, raportowanie dla zarządu.
Wtedy każdy incydent – np. utrata dostępu do konta, likwidacja usługi, wyciek – uderza bezpośrednio w reputację, odpowiedzialność prawną i ciągłość działania. Z perspektywy audytorów i regulatorów brak wiedzy o tym narzędziu nie jest usprawiedliwieniem, lecz dodatkowym obciążeniem: organizacja nie dopełniła obowiązku należytej staranności.
Typowe scenariusze incydentów wynikających z shadow IT
Utrata i wyciek danych przez nieautoryzowane aplikacje
Najbardziej oczywisty i jednocześnie najczęstszy problem związany z shadow IT to niekontrolowane przetwarzanie danych w zewnętrznych usługach. Przykład z praktyki: zespół handlowy zaczyna używać darmowego narzędzia do współdzielenia plików, ponieważ oficjalny system jest zbyt wolny i ma restrykcyjne limity. Handlowcy wrzucają tam umowy, oferty, prezentacje z danymi klientów.
Ryzyka pojawiają się w kilku warstwach:
funkcje współdzielenia linkiem – pliki udostępniane „każdemu, kto ma link”, bez ograniczenia do konkretnych domen czy kont; link trafia w niepowołane ręce (np. przeklejony w nieodpowiednie miejsce lub przechwycony w phishingu),
brak silnego uwierzytelniania – wiele małych usług nie wspiera SSO (Single Sign-On) ani MFA; hasło ustawione przez pracownika jest słabe i powtórzone z innego serwisu,
prywatne konta – dokumenty trafiają na konta użytkownika, do których firma nie ma formalnego dostępu, co uniemożliwia egzekwowanie polityk retencji, kasowania czy blokad po odejściu pracownika.
Do tego dochodzi problem utraconych danych. Jeżeli oficjalne repozytoria dokumentów nie zawierają aktualnych wersji plików, a jedyne kopie znajdują się na cichych dyskach chmurowych, każdy incydent po stronie dostawcy SaaS (blokada konta, awaria) lub użytkownika (utrata hasła) przekłada się od razu na poważny incydent operacyjny.
Luki w łańcuchu dostaw SaaS i niebezpieczne integracje
Drugi, coraz groźniejszy obszar to integracje między usługami SaaS. Użytkownicy chętnie podpinają aplikacje trzecie do firmowego Microsoft 365 czy Google Workspace przez OAuth („Zaloguj przez konto Google/Microsoft”) oraz przez narzędzia typu no-code/low-code.
Typowy scenariusz:
pracownik marketingu instaluje aplikację do planowania postów,
aplikacja prosi o dostęp do pełnej skrzynki e-mail, kalendarza, kontaktów, plików na dysku,
użytkownik klika „Zezwól” bez zrozumienia konsekwencji, bo zależy mu tylko na jednym module,
aplikacja zyskuje szeroki dostęp do danych, którymi może zarządzać w tle.
Jeśli taki dostawca SaaS zostanie skompromitowany, atakujący dostaje się tylnymi drzwiami do ekosystemu organizacji. Nie musi atakować bezpośrednio M365 – wystarczy, że złamie zabezpieczenia małego narzędzia z nadanymi szerokimi uprawnieniami. To klasyczny przykład ryzyka łańcucha dostaw w świecie chmury.
Dodatkowo integracje no-code/low-code (Zapier, Make, Power Automate, IFTTT i podobne) potrafią wysyłać dane z systemów wewnętrznych do zewnętrznych API, często bez świadomości IT. Przykład: automatyczna wysyłka danych klientów z CRM do zewnętrznego narzędzia do kampanii SMS. Bez umów, bez oceny ryzyka, bez logów dostępnych dla działu bezpieczeństwa.
Malware, phishing i podszywanie się pod narzędzia chmurowe
Shadow IT to również idealne środowisko do maskowania złośliwych działań. Im więcej nieoficjalnych aplikacji i wtyczek, tym łatwiej przemycić te, które są po prostu złośliwe. Częsty scenariusz to:
pozornie niewinne rozszerzenie przeglądarki,
„darmowy” klient do popularnej usługi SaaS pobrany spoza oficjalnego sklepu,
klon strony logowania znanego narzędzia do e‑podpisu lub współpracy dokumentów.
Użytkownik, przyzwyczajony do instalowania wielu dodatków, nie widzi czerwonych flag. Złośliwe narzędzie może:
przechwytywać loginy i hasła,
wstrzykiwać złośliwy kod w przeglądarce (np. podmieniać numery kont na fakturach),
wysyłać poufne treści do zewnętrznych serwerów.
Phishing wykorzystujący autentycznie wyglądające strony logowania SaaS jest dodatkowo ułatwiony, gdy w firmie używa się dziesiątek narzędzi chmurowych. Użytkownik po prostu nie jest w stanie zapamiętać wszystkich prawidłowych adresów URL; „nowy ekran logowania” nie wydaje mu się niczym dziwnym.
Incydenty operacyjne: utrata dostępów, blokady, brak ciągłości działania
Nie każdy incydent z shadow IT to spektakularny wyciek danych. Bardzo często problem ma charakter czysto operacyjny, ale nadal boli biznes. Klasyczne przykłady:
pracownik odchodzi z firmy, a na jego prywatnym koncie w narzędziu SaaS zostają:
listy klientów,
szablony ofert,
kluczowe raporty analityczne.
darmowa usługa zmienia regulamin, wprowadza limity lub ogranicza funkcje,
dostawca nagle wyłącza produkt albo znika z rynku.
Jeśli narzędzie było elementem łańcucha procesów, skutkiem jest przerwanie pracy. Dział IT nie ma dostępu do logów, możliwości przywrócenia danych ani wsparcia vendorów, bo… formalnie nie ma relacji z tym dostawcą. Efekt: długotrwała rekonfiguracja procesów, przenoszenie danych awaryjnie, nerwowe tłumaczenia wobec klientów, dlaczego raport czy usługa są opóźnione.
Brak kopii zapasowych z poziomu organizacji to kolejny typowy problem. Shadow IT często przechowuje swoje dane wyłącznie u dostawcy. Nie ma zrzutów do wewnętrznych repozytoriów, nie ma synchronizacji, nie ma procedur odtworzeniowych. Takie „odzyskiwanie po incydencie” kończy się w praktyce żmudnym odtwarzaniem dokumentów z prywatnych archiwów pracowników – jeśli w ogóle się udaje.
Źródło: Pexels | Autor: Vitaly Kushnir
Główne kategorie shadow IT: od prostych aplikacji po złożone automatyzacje
Shadow SaaS – aplikacje chmurowe „na kartę” i zjawisko SaaS sprawl
Niesankcjonowane rozszerzenia i dodatki przeglądarkowe
Rozszerzenia przeglądarki to jedna z najbardziej niedoszacowanych odmian shadow IT. Formalnie to tylko „dodatki do Chrome/Edge/Firefoksa”, praktycznie – małe aplikacje mające pełny dostęp do tego, co użytkownik widzi i robi w przeglądarce.
Typowe kategorie takich rozszerzeń to:
ad‑blockery i „ulepszacze” UI – modyfikują interfejs webowych aplikacji firmowych,
menedżery zakładek i „productivity tools” – przechowują historię odwiedzanych stron, tytuły dokumentów, czasem zrzuty ekranu,
narzędzia do transkrypcji/AI – odczytują treść formularzy, maili, czatów i wysyłają je do zewnętrznych API.
Technicznie te dodatki działają jako content scripts (kod wstrzykiwany w strony) z uprawnieniami typu tabs, storage, czasem webRequest. To pozwala im:
czytać zawartość pól formularzy (w tym loginy, fragmenty danych osobowych),
modyfikować DOM aplikacji webowej (np. „maskować” błędy bezpieczeństwa),
logować i wysyłać na zewnątrz dane o zachowaniu użytkownika.
Rozjazd między ryzykiem a percepcją użytkownika jest tu skrajny. Dla biznesu to „tylko mała wtyczka do skrótu klawiszowego”, dla bezpieczeństwa – możliwy keylogger i kanał exfiltracji danych. Szczególnie groźne są rozszerzenia instalowane spoza oficjalnych sklepów lub takie, które zmieniają właściciela (sprzedana wtyczka) i po aktualizacji zaczynają działać agresywnie.
Makra, skrypty i „mini‑aplikacje” w arkuszach
Stare, dobre makra w Excelu czy skrypty w Google Sheets to klasyczny przykład shadow IT w wydaniu „mikro‑systemów”. Na początku to tylko formuła, potem prosty VBA script lub Apps Script, a po kilku miesiącach mamy:
arkusz pełniący rolę nieformalnego CRM,
zestaw makr dokonujących obliczeń finansowych używanych do decyzji zarządczych,
skrypty robiące integracje z zewnętrznymi API (pobieranie kursów, danych o klientach, statusów zamówień).
Z punktu widzenia bezpieczeństwa i ciągłości działania mamy tu kilka problemów naraz:
brak wersjonowania i testów – błędna formuła lub zły refactoring makra wpływa od razu na wynik,
osobo‑zależność – tylko autor wie, jak działa logika; po jego odejściu nie ma kto tego utrzymać,
ciche integracje – skrypty wołające zewnętrzne API używają prywatnych tokenów, bez rejestracji tych integracji w firmowej inwentarzowej bazie systemów.
Uwaga: arkusz z makrami używany „tylko do raportu miesięcznego” bardzo szybko zaczyna żyć własnym życiem. Zaczynają się pojawiać kolejne zakładki, formularze, przyciski – realnie powstaje aplikacja bez żadnego cyklu wytwórczego, bez backlogu, bez testów regresyjnych i bez przeglądów bezpieczeństwa.
Shadow automatyzacje: boty, skrypty CLI i zadania CRON
Oprócz narzędzi no‑code pojawia się kategoria shadow IT tworzona przez technicznych pracowników: skrypty shellowe, Python, PowerShell, uruchamiane lokalnie lub na przypadkowym serwerze. Intencja jest dobra – „żeby się samo robiło” – ale konsekwencje bywają kosztowne.
Typowe przykłady:
skrypt SFTP, który co noc wypycha dane klientów do partnera biznesowego z laptopa właściciela skryptu,
lokalny bot integrujący e‑maile z systemem zgłoszeniowym, działający jako zadanie CRON na starym serwerze pod biurkiem,
PowerShell synchronizujący pliki między udziałem SMB a prywatnym dyskiem w chmurze „na wszelki wypadek”.
Problemem jest nie tyle sam skrypt, co jego konfiguracja i cykl życia:
hasła w .env lub wprost w kodzie,
brak monitoringu – jeśli zadanie CRON się wysypie, nikt się o tym nie dowiaduje,
brak rejestru, gdzie te boty działają i do czego mają dostęp.
W efekcie powstaje „warstwa automatyzacji w cieniu”: procesy biznesowe realnie zależą od prywatnego skryptu na maszynie, o której dział IT nawet nie wie. Przy incydencie (awaria, ransomware, utrata laptopa) odtwarzanie tych automatyzacji jest często niemożliwe, bo nigdzie nie ma kodu źródłowego ani dokumentacji.
Niescentralizowane bazy danych: małe CRM‑y, „lekkie” ERP‑y i mikro‑portale
Coraz popularniejsze są niskokosztowe aplikacje typu „mini‑CRM”, „system rezerwacji”, „lekkie ERP”, często w abonamencie karty kredytowej. Z punktu widzenia użytkownika to ratunek przed ciężkimi, korporacyjnymi systemami. Z perspektywy bezpieczeństwa – nowe repozytoria danych osobowych poza radarem.
Cechy charakterystyczne:
rejestracja na mail służbowy, ale bez udziału działu zakupów/IT,
plan „Pro” dla jednego‑dwóch użytkowników, opłacany prywatną kartą z późniejszym rozliczeniem w kosztach,
import danych z oficjalnych systemów: CSV z CRM, listy klientów z ERP, eksport faktur.
Ryzyko eskaluje szybko, gdy:
do systemu trafiają kompletne profile klientów (dane identyfikacyjne, historia kontaktu),
aplikacja przechowuje dane dłużej niż oficjalne systemy, bo nikt nie definiuje tam polityk retencji,
firma nie ma żadnej umowy regulującej powierzenie danych ani gwarancji lokalizacji przetwarzania.
Tip: te systemy często wychodzą na jaw dopiero przy incydencie lub migracji – kiedy ktoś pyta o „dziwne” raporty albo o to, skąd wziął się konkretny widok danych klienta, który nie istnieje w oficjalnym CRM.
Dlaczego użytkownicy tworzą shadow IT: perspektywa biznesu i psychologii
Friction: gdy oficjalne narzędzia spowalniają zamiast pomagać
Podstawowy bodziec do tworzenia shadow IT jest prozaiczny: tarcie (ang. friction). Jeżeli wykonanie prostej czynności w oficjalnym systemie jest wolne, nieintuicyjne albo wymaga wielu kroków formalnych, użytkownicy szukają objazdu.
Źródła tarcia bywają powtarzalne:
przeładowane interfejsy, które wymagają kilkunastu kliknięć, by wprowadzić pojedynczy rekord,
długie kolejki zmian w systemach centralnych – każdy drobiazg wymaga zgłoszenia do IT, analizy, wdrożenia,
brak mobilnych wersji narzędzi przy pracy w terenie,
ograniczone prawa – użytkownicy nie mogą tworzyć własnych raportów, widoków, a muszą czekać na IT.
W takim środowisku aplikacja typu „mini‑CRM w 15 minut” albo „tablica zadań w Kanbanie” wygrywa, bo pozwala zrobić to, co trzeba, bez proszenia kogokolwiek o pomoc. Shadow IT jest więc w wielu przypadkach indykatorem niedopasowania UX i procesów w oficjalnych narzędziach.
Presja na wynik i „kreatywna nieposłuszność”
Z perspektywy biznesu liczy się wynik: liczba obsłużonych spraw, czas reakcji, zamknięte sprzedaże. Jeżeli normy są agresywne, a narzędzia nie nadążają, naturalnym odruchem staje się omijanie przeszkód.
Psychologicznie to często nie jest bunt przeciwko bezpieczeństwu, tylko kreatywna nieposłuszność wobec biurokracji. Użytkownik myśli w kategoriach:
„system jest dla mnie, nie ja dla systemu”,
„jak nie skrócę drogi, nie dowiozę celu”,
„nikt nie wymyślił lepszego narzędzia, więc zrobię to sam”.
Jeśli zespół jest rozliczany indywidualnie z targetów, a naruszenia polityk IT nie są realnie egzekwowane, powstaje ciche przyzwolenie: „rób, co trzeba, byle działało”. Z czasem to normalizuje korzystanie z nieautoryzowanych aplikacji, bo są postrzegane jako element „zaradności”, a nie jako problem.
Brak zrozumiałej komunikacji o ryzyku
Dla większości pracowników bezpieczeństwo IT to abstrakcja. Słyszą o RODO, wyciekach i phishingu, ale nie łączą tego z własnym arkuszem w chmurze czy dodatkiem do przeglądarki. W ich głowie scenariusz wygląda raczej tak:
„to tylko lista klientów, przecież nikt się tym nie zainteresuje”,
„ta aplikacja jest popularna, więc na pewno bezpieczna”,
„co najwyżej stracę jakieś notatki, a nie pół firmy”.
Jeżeli komunikacja bezpieczeństwa zatrzymuje się na poziomie ogólnych haseł („chroń dane osobowe”, „nie używaj nieznanych aplikacji”), nie przekłada się to na realne decyzje użytkownika. Potrzebuje on konkretnej mapy: co wolno, czego nie wolno, jakie są bezpieczne alternatywy i gdzie zgłosić potrzebę nowego narzędzia.
Bez tej mapy pracownicy są pozostawieni sami sobie. Wybierają to, co łatwe i znane (reklamowane w sieci, polecane przez znajomych), a nie to, co bezpieczne i zgodne z polityką. Shadow IT rośnie w lukach między „zbyt ogólną” polityką a codzienną praktyką pracy.
Poczucie „białej strefy” i minimalizacji ryzyka w głowie użytkownika
Ciekawym mechanizmem jest wewnętrzna racjonalizacja: użytkownik aktywnie zaniża postrzegane ryzyko, żeby móc spokojnie korzystać z narzędzia. Klasyczne argumenty:
„przecież tu nie ma numerów PESEL, tylko maile” (pomijanie faktu, że to też dane osobowe),
„to tylko drafty umów, finalne wersje są w systemie” (zapominając, że drafty zawierają często szczegóły negocjacji),
„konto jest darmowe, więc nikomu nie będzie się chciało tego hackować”.
Ten efekt potęguje się, gdy użytkownik nigdy nie doświadczył realnego incydentu. Skoro przez kilka lat nic złego się nie wydarzyło, to w jego percepcji ryzyko jest czysto teoretyczne. Z kolei każdy zakaz czy ostrzeżenie ze strony IT może być interpretowany jako „straszenie” zamiast reakcji na realne zagrożenie.
Rozproszone zespoły i kultura „remote‑first”
Praca zdalna i rozproszone zespoły w praktyce zwiększają autonomię użytkowników w doborze narzędzi. Spotkanie tworzy się szybciej na nowej platformie wideo niż przez procedurę zakupu licencji; tablicę do warsztatu UX łatwiej założyć na modnej platformie niż szukać, co jest oficjalnie dostępne.
Mechanizmy, które się tu nakładają:
brak fizycznej kontroli nad urządzeniami i siecią – część pracy odbywa się na prywatnych laptopach, w domowym Wi‑Fi,
silne wykorzystanie chmury – naturalnym odruchem jest „znaleźć coś w sieci i zalogować się służbowym mailem”,
potrzeba szybkiej współpracy w małych grupach – mikrozespół wybiera własne narzędzie, bo integracja z resztą organizacji jest zbędna „na teraz”.
Jeżeli organizacja nie dostarcza dobrego zestawu oficjalnych narzędzi do kolaboracji (wideokonferencje, białe tablice, współdzielenie plików, chat), powstaną równoległe ekosystemy w postaci prywatnych Slacków, Discordów, Trello czy alternatywnych komunikatorów.
Techniczni „power users” jako nieformalni twórcy systemów
W każdej większej firmie są osoby technicznie biegłe, ale formalnie spoza IT: analitycy, inżynierowie, product ownerzy. To oni często budują pierwsze integracje w Zapier/Make, stawiają bazy w Airtable, tworzą skrypty w Pythonie. Z ich perspektywy to naturalne rozszerzenie kompetencji – „przyspieszam pracę zespołu, bo potrafię”.
Problem zaczyna się, gdy tacy power users stają się faktycznymi właścicielami mikro‑systemów bez nadzoru:
tworzą przepływy danych między systemami, nie znając szczegółowo wymogów prawnych (np. gdzie wolno wysłać dane HR),
definiują logikę biznesową w skryptach i workflow, które nie są nigdzie zarejestrowane ani testowane,
zarządzają dostępami przez własne konta administracyjne w zewnętrznych narzędziach.
Z jednej strony to ogromny potencjał innowacji, z drugiej – shadow IT w wersji turbo. Jeśli organizacja nie potrafi wchłonąć tej energii w kontrolowane ramy (np. „citizen development” z udziałem IT), powstaje równoległy ekosystem aplikacji, o którym dział bezpieczeństwa dowiaduje się dopiero przy audycie lub incydencie.
Źródło: Pexels | Autor: Tima Miroshnichenko
Jak wykrywać shadow IT: warstwy widoczności, które trzeba zbudować
Warstwa sieciowa: analiza ruchu wychodzącego
Najbardziej klasyczne podejście to spojrzenie na to, z kim rozmawiają stacje robocze i serwery. Nawet jeżeli nie masz pełnej inspekcji treści (TLS, szyfrowanie), sama telemetria połączeń daje sporo sygnałów.
Kluczowe elementy:
proxy / secure web gateway z klasyfikacją kategorii URL (SaaS, chmura, social media itp.),
DNS logging – rejestrowanie zapytań DNS i korelacja z użytkownikami/urządzeniami,
firewall z funkcją App-ID – rozpoznawanie aplikacji po wzorcach ruchu, nie tylko po IP/porcie.
Praktyczny schemat działania:
Wyciągnij listę top domen SaaS, do których łączą się użytkownicy (w ostatnich 30–90 dniach).
Odfiltruj to, co jest oficjalne (posiadasz umowę, wpis w CMDB / rejestrze usług).
Pozostaw „szarą strefę” – domeny usług, o których nikt formalnie nie słyszał.
Pogrupuj po użytkowniku/oddziale, by zobaczyć, gdzie zjawisko jest najsilniejsze.
Tip: już sam fakt, że dział sprzedaży intensywnie używa jakiejś platformy do e‑podpisu, może być sygnałem istnienia nieformalnego procesu akceptacji umów poza oficjalnym narzędziem.
Warstwa tożsamości: logowania SSO i OAuth jako mapa aplikacji
Jeśli organizacja ma IdP (Identity Provider, np. Azure AD, Okta, Google Workspace), w logach masz złoto. Widać tam zarówno logowania SSO do zatwierdzonych systemów, jak i nieautoryzowane integracje oparte o OAuth.
Najważniejsze źródła sygnałów:
Enterprise applications / „Connected apps” – lista aplikacji korzystających z SSO lub tokenów,
consent logs – kto i kiedy zgodził się na nadanie aplikacji dostępu do konta służbowego,
failures – próby logowania do usług spoza katalogu, wykrywane przez CASB lub dedykowane polityki.
Przykładowe reguły detekcji:
nowa aplikacja uzyskała dostęp do zakresu Mail.ReadWrite lub Files.Read.All,
mała grupa użytkowników (np. 3 osoby) przyznała tej samej aplikacji szerokie uprawnienia,
aplikacja została utworzona jako multi‑tenant, ale nie ma jej na liście dozwolonych integracji.
Reakcja nie musi oznaczać od razu blokady. Często wystarczy krótkie interview z użytkownikiem: do czego służy narzędzie, jakie dane pobiera, czy są alternatywy w oficjalnym ekosystemie.
Warstwa endpointów: skanowanie zainstalowanych aplikacji i wtyczek
Ruch sieciowy nie wyłapie wszystkiego, szczególnie w przypadku aplikacji desktopowych i wtyczek przeglądarkowych. Tu wchodzą w grę EDR i systemy zarządzania stacjami (MDM, Intune, SCCM itp.).
Przydatne elementy widoczności:
lista zainstalowanych aplikacji z możliwością filtrowania po vendorze i typie (VPN, backupy, synchronizacja plików, klienty chmurowe),
telemetria uruchamiania procesów (które aplikacje faktycznie są używane, a nie tylko zainstalowane),
inwentarz wtyczek przeglądarkowych – rozszerzenia do przechwytywania ekranu, zarządzania hasłami, AI‑asystenci, pluginy do CRM.
Uwaga: nie każda „dziwna” aplikacja to od razu incydent. Warto zdefiniować białą listę kategorii (np. edytory tekstu, narzędzia developerskie na stacjach devów) i skupić się na tym, co:
kopiuje dane do chmury (klienty synchronizacyjne, backupy),
zapewnia zdalny dostęp (remote desktop, prywatne VPN‑y),
integruje się z przeglądarką i ma dostęp do treści stron.
Shadow IT w warstwie danych: nietypowe repozytoria i kopie
Duża część shadow IT nie jest widoczna na poziomie aplikacji, tylko na poziomie kopii danych. Arkusze, bazy i snapshoty raportów rozlewają się po chmurach i dyskach prywatnych. Wykrywanie tego wymaga narzędzi klasy DLP (Data Loss Prevention) i DSPM (Data Security Posture Management).
Przykładowe zastosowania:
skanowanie przestrzeni typu OneDrive/Google Drive/Dropbox w poszukiwaniu danych wrażliwych (patterny PESEL, numery kart, frazy umowne),
klasyfikacja plików pod kątem tagów bezpieczeństwa i sprawdzenie, gdzie lądują pliki oznaczone jako „poufne”,
wykrywanie nietypowych bucketów w chmurze (S3, Blob Storage), które nie są zarejestrowane w centralnym katalogu usług.
Tip: pierwsze uruchomienie DLP zwykle wywołuje „efekt latarki w piwnicy” – trzeba dobrze przygotować komunikację z biznesem, żeby nie zamienić projektu w polowanie na czarownice.
CASB i SSPM: specjalistyczne narzędzia do kontroli SaaS
Dla organizacji silnie opartych na SaaS przydatne są platformy CASB (Cloud Access Security Broker) oraz SSPM (SaaS Security Posture Management). Ich zadaniem jest połączenie widoczności ruchu, tożsamości i konfiguracji chmurowych aplikacji.
Co potrafią w kontekście shadow IT:
automatycznie profilować aplikacje SaaS wykryte w ruchu sieciowym (kto używa, jakie dane, jaka kategoria ryzyka),
wdrażać polityki dostępu – np. blokować logowania do określonych kategorii usług lub wymuszać logowanie tylko przez SSO,
analizować konfigurację bezpieczeństwa w samych aplikacjach (SSPM) – uprawnienia współdzielenia plików, MFA, reguły dostępu.
Przykład: CASB wykrywa, że część pracowników korzysta z zewnętrznego narzędzia do zarządzania projektami. Na początku decyzja może być łagodna: tylko monitorowanie. Po analizie ryzyka zapada decyzja: narzędzie zostaje oficjalnie wdrożone (po spełnieniu wymogów) albo zostaje zablokowane, a użytkownikom oferuje się alternatywę.
Proces zarządzania shadow IT: od wykrycia do decyzji
Rejestracja i kategoryzacja wykrytych aplikacji
Sama detekcja to dopiero początek. Żeby nie utonąć w sygnałach, trzeba mieć lekki proces rejestracji shadow IT. W praktyce dobrze sprawdza się prosty katalog (CMDB lub dedykowany rejestr SaaS) z kilkoma polami:
nazwa i dostawca aplikacji,
dział / zespół korzystający,
typ danych – osobowe, finansowe, techniczne, brak danych wrażliwych,
model autoryzacji – SSO, konta lokalne, integracje OAuth,
kategoria ryzyka – niskie / średnie / wysokie, z krótkim uzasadnieniem.
Uwaga: sensem tej kategoryzacji nie jest natychmiastowe „wycięcie” wszystkiego, tylko odróżnienie drobnych usprawnień od aplikacji, które realnie mogą być źródłem incydentu (np. kopii baz klientów).
Ocena ryzyka: proste kryteria zamiast 50‑stronicowych analiz
W praktyce lepsza jest spójna, uproszczona matryca ryzyka niż idealny, ale nieskalowalny proces. Kilka pytań, które robią różnicę:
Czy w aplikacji pojawiają się dane osobowe lub dane finansowe klientów/pracowników?
Czy aplikacja ma dostęp do głównego IdP (czyli kont służbowych) z szerokimi uprawnieniami?
Czy dane są przechowywane wyłącznie w tej aplikacji, czy jest to tylko bufor/pośrednik?
Czy istnieje oficjalny odpowiednik w organizacji, z którym ta aplikacja wchodzi w konflikt?
Czy aplikacja pochodzi od dojrzałego dostawcy (SOC 2, ISO 27001, realne referencje), czy od anonimowego startupu?
Na tej podstawie da się szybko zbudować trzy koszyki decyzji:
„tolerowane z monitorowaniem” – drobne narzędzia produktywności bez wrażliwych danych,
„do formalizacji” – aplikacje, które powinny zostać wciągnięte do oficjalnego portfolio,
„do wycofania” – wysokie ryzyko bez realnej wartości dodanej lub z dobrą alternatywą w organizacji.
Współpraca z biznesem zamiast jednostronnych zakazów
Shadow IT to w dużej mierze paliwo innowacji. Jeżeli reakcją bezpieczeństwa jest wyłącznie blokada, użytkownicy po prostu schodzą głębiej do podziemia. Dużo skuteczniejszy jest model: „ok, widzimy, że to narzędzie rozwiązuje realny problem – zróbmy to dobrze”.
Jak to ugryźć praktycznie:
krótkie warsztaty discovery z zespołem, który korzysta z aplikacji – jakie procesy usprawnia, jak wygląda obecny przepływ danych,
przegląd alternatyw wewnętrznych – czasem okazuje się, że istnieje mało znana funkcja w już posiadanym systemie,
jeśli brak alternatyw: sformalizowanie – minimalny due diligence dostawcy, umowa powierzenia, konfiguracja SSO i uprawnień.
Tip: dobrym sygnałem dla organizacji jest choć kilka głośno zakomunikowanych przykładów, gdy aplikacja z „szarej strefy” przeszła do katalogu oficjalnych narzędzi. Pokazuje to, że zgłoszenie nie kończy się automatycznie zakazem.
Standardy minimalne dla nowych narzędzi
Żeby ograniczyć liczbę dyskusji ad‑hoc, warto zdefiniować minimalny zestaw wymogów dla nowych aplikacji. Nie jako 40‑stronicowa polityka, tylko jako krótka checklista:
wsparcie MFA lub integracji z IdP,
jasne warunki przetwarzania danych (DPA, lokalizacja, podwykonawcy),
możliwość eksportu danych w otwartym formacie,
funkcje zarządzania użytkownikami (role, odwoływanie dostępu),
podstawowe logowanie aktywności (audit log).
Jeśli narzędzie nie spełnia tych absolutnych podstaw, a ma operować na istotnych danych, to czerwona flaga. To również dobra okazja, by edukować użytkowników: czemu te kryteria są istotne i jak przekładają się na konkretne incydenty (np. brak eksportu danych = zakładnik dostawcy).
Mechanizmy ograniczania shadow IT bez duszenia innowacji
Katalog zatwierdzonych aplikacji i „marketplace wewnętrzny”
Zamiast komunikatu „nie wolno używać niczego spoza listy”, lepiej zbudować przyjazny katalog dostępnych narzędzi z jasną informacją:
do czego służy dana aplikacja (use case, dział),
jakie dane wolno tam trzymać,
jak uzyskać dostęp (self‑service, zgłoszenie, zgoda przełożonego),
jakie są alternatywy, jeśli aplikacja nie pasuje do potrzeb.
Dobrze działa model zbliżony do app store – użytkownik może sam „zamówić” aplikację z katalogu, a workflow pod spodem załatwia formalności (licencja, nadanie grupy, akceptacje). Redukuje to motywację do zakładania kont „na boku”.
Self‑service dla prostych automatyzacji i „citizen development”
Z perspektywy power users problemem nie jest sam zakaz, tylko brak legalnego kanału. Jeśli organizacja wyznaczy bezpieczne „piaskownice”, część shadow IT można wciągnąć w kontrolowane środowisko:
oficjalne platformy low‑code/no‑code (Power Platform, AppSheet, Mendix) z nadzorem IT,
guideline’y: jakie konektory są dozwolone, jakie dane można przetwarzać, jak opisywać logikę,
program wsparcia – „biuro projektów citizen dev” pomagające w ocenie i produkcyjnym wdrożeniu.
Uwaga: sensem nie jest „oddanie sterów” biznesowi, tylko stworzenie kontrolowanego ekosystemu, w którym powstające mikro‑systemy są widoczne, rejestrowane i mają właściciela.
Polityki techniczne: kontrola dostępu do kategorii usług
Najczęściej zadawane pytania (FAQ)
Czym dokładnie jest shadow IT i czym różni się od zwykłych „niezatwierdzonych” aplikacji?
Shadow IT to każde narzędzie IT (aplikacja, usługa chmurowa, skrypt, urządzenie), które jest używane w organizacji bez wiedzy i kontroli działu IT / bezpieczeństwa. Kluczowe jest nie to, czy narzędzie jest „zakazane”, ale czy jest widoczne w oficjalnym procesie zarządzania IT.
„Aplikacje niezatwierdzone” to te, o których IT wie, ale po analizie ryzyka nie dopuściło ich do użycia. „Aplikacje nieznane” to już typowe shadow IT – dział IT nie ma pojęcia, że z nich korzystacie, więc nie może ocenić ryzyka, wdrożyć zabezpieczeń ani reagować na incydenty.
Dlaczego shadow IT jest groźne dla bezpieczeństwa firmy?
Shadow IT omija wszystkie standardowe mechanizmy kontroli: brak audytu bezpieczeństwa, brak umów powierzenia danych, brak backupów, brak integracji z SSO/MFA, brak logów w SIEM. Dopóki nic się nie dzieje, problem bywa niewidoczny – ryzyko ujawnia się dopiero przy incydencie.
Konsekwencje są twarde: wycieki danych (np. udostępnianie plików „każdemu, kto ma link”), utrata ciągłości działania (usługa SaaS znika, a z nią jedyna kopia danych), naruszenia RODO i umów z klientami. Uwaga: przed regulatorem argument „nie wiedzieliśmy, że tego używamy” jest okolicznością obciążającą, nie łagodzącą.
Jak wykryć shadow IT w organizacji w praktyce?
Najskuteczniejsze podejście to połączenie techniki i procesu. Po stronie technicznej stosuje się m.in. analizę ruchu sieciowego (NetFlow, proxy, CASB), skanery oprogramowania na stacjach roboczych oraz integracje z logami dostawców (Microsoft 365, Google Workspace) pokazujące aplikacje podpięte przez OAuth.
Po stronie procesu przydają się: okresowe ankiety w zespołach biznesowych, przegląd wydatków z kart firmowych (małe subskrypcje SaaS), przegląd rozszerzeń przeglądarek oraz formalny „lightweight” proces zgłaszania nowych narzędzi do testów. Tip: zacznij od obszarów, gdzie presja „na jutro” jest największa – marketing, sprzedaż, product.
Jakie są najczęstsze incydenty wynikające z shadow IT?
Najczęściej pojawiają się trzy scenariusze: wyciek danych z nieautoryzowanych chmur, utrata krytycznych danych przechowywanych wyłącznie w zewnętrznym SaaS oraz niebezpieczne integracje (np. aplikacja trzecia z pełnym dostępem do firmowego Microsoft 365). Typowy przykład: zespół wrzuca umowy klientów na darmowy dysk w chmurze z włączonym udostępnianiem przez link bez ograniczeń.
Coraz częściej problemem są też automatyzacje i integracje „klikane” przez użytkowników (Zapier, Make, Power Automate) – jedno źle skonfigurowane flow potrafi przesyłać dane osobowe z systemu CRM do zupełnie niezweryfikowanej aplikacji, poza jakąkolwiek kontrolą IT.
Jak ograniczyć shadow IT bez blokowania pracy użytkowników?
Skuteczna strategia to nie tylko zakazy, ale przede wszystkim szybka „ścieżka legalizacji” i dobre alternatywy. W praktyce oznacza to: katalog zatwierdzonych narzędzi, uproszczony proces zgłaszania nowych aplikacji do testów (np. „piaskownica” z ograniczonym zakresem danych) oraz jasne wytyczne, jakie dane wolno wynosić do zewnętrznych usług.
Od strony technicznej pomaga: egzekwowanie SSO/MFA, polityki DLP (Data Loss Prevention) w poczcie i przeglądarce, blokowanie najbardziej ryzykownych kategorii usług w proxy oraz monitoring nietypowego ruchu SaaS. Uwaga: jeśli oficjalne systemy są zbyt wolne lub nieintuicyjne, shadow IT zawsze wróci – UX narzędzi „oficjalnych” to element bezpieczeństwa.
Czy każde shadow IT trzeba od razu blokować?
Nie. Sensowne podejście to klasyfikacja według ryzyka. Narzędzia, które nie przetwarzają danych klientów, pracowników ani informacji poufnych (np. proste timery, aplikacje do osobistych notatek), można często tolerować pod warunkiem, że są widoczne i udokumentowane. Kluczem jest świadomość, do jakich danych mają dostęp.
Bezwzględnie trzeba reagować na narzędzia, które: przechowują jedyne kopie krytycznych danych, obsługują procesy produkcyjne (zamówienia, faktury, obsługa incydentów) albo przetwarzają dane osobowe bez umowy powierzenia. W takich przypadkach pierwszym krokiem jest zabezpieczenie danych (migracja, backup), dopiero potem ewentualne odcięcie usługi.
Jak przekonać biznes, że shadow IT to realne ryzyko, a nie „problem działu IT”?
Najlepiej działa język wpływu na biznes: opóźnienia w obsłudze klientów, kary za naruszenia RODO, koszty odtworzenia utraconych danych, utrata zaufania kluczowych kontrahentów. Zamiast straszyć abstrakcyjnymi atakami, pokaż konkretny scenariusz: zablokowane konto w darmowej usłudze, na którym trzymane są wszystkie aktualne oferty handlowe.
Dobrą praktyką jest też włączenie przedstawicieli biznesu w proces zarządzania narzędziami (komitet, przeglądy kwartalne) i zaoferowanie im szybkiej ścieżki testowania nowych rozwiązań, ale już „w świetle reflektorów” IT. Wtedy shadow IT zamienia się w kontrolowane eksperymenty, a nie w tykające bomby.
