Przykłady shadow IT

jak shadow IT wygląda w praktyce

Przykłady shadow IT bywają zaskakująco przyziemne. Większość nie polega na celowym obchodzeniu zasad ani na decyzjach świadomych bezpieczeństwa. Odzwierciedlają to, jak ludzie rozwiązują problemy w pracy: szybko, dostępnymi narzędziami, nie zawsze wiedząc lub przejmując się konsekwencjami dla IT.

Poniższe wzorce mieszczą się w trzech obszarach: tożsamość (konta i dostęp), SaaS (aplikacje i integracje) oraz AI (przepływy danych przez narzędzia AI). Pojawiają się regularnie niezależnie od branży, wielkości firmy i dojrzałości IT.

dlaczego te wzorce się utrzymują

Shadow IT utrzymuje się, bo każdy pojedynczy przypadek w izolacji wydaje się drobny. Jeden były pracownik, którego konto nie zostało do końca zamknięte. Jedno uprawnienie OAuth stworzone podczas proof-of-concept. Jedno narzędzie AI wdrożone przez zespół, bo było szybsze niż zatwierdzony proces.

Luka w nadzorze powstaje z sumy przypadków, których nie wyłapuje żaden pojedynczy proces przeglądu, bo żaden pojedynczy proces nie obejmuje jednocześnie tożsamości, SaaS i AI.

shadow IT w tożsamości

Wciąż aktywne konta byłych pracowników. Katalog zostaje zamknięty w dniu odejścia. CRM, organizacja na GitHubie, narzędzie analityczne, system finansowy: każdy ma własną bazę użytkowników, a offboarding nie dotarł do wszystkich. Beyond Identity wykazuje, że 83% pracowników przyznaje, że nadal ma dostęp do przynajmniej jednego konta u poprzedniego pracodawcy (Beyond Identity, 2022, dane self-reported).

Konta kontraktorów, które przeżyły projekt. Kontraktor zaangażowany na sześć miesięcy. Projekt trwał dłużej, potem się skończył. Konta kontraktora w narzędziu do zarządzania projektami, systemie dokumentów i platformie komunikacyjnej nigdy nie zostały formalnie zamknięte.

Konta administratora używane do codziennej pracy. Członek zespołu IT dostał uprawnienia administratora, żeby zbadać problem, i dalej używał konta administratora do rutynowych zadań. Konto ma więcej dostępu, niż wymaga codzienna rola, a każde działanie przez nie wykonane jest przypisane do współdzielonej albo podwyższonej danej logowania.

Konta serwisowe bez nazwanego właściciela. Deweloper stworzył konto serwisowe, żeby połączyć dwa systemy. Deweloper od tego czasu zmienił firmę. Konto jest wciąż aktywne, połączone z systemem produkcyjnym, bez żadnego zarejestrowanego właściciela.

Współdzielone dane logowania do portalu dostawcy. Finanse i zakupy dzielą login do portalu dostawcy. Hasło zna wiele osób. Nikt nie zmieniał go od dawna i nikt nie jest pewien, który członek zespołu ostatnio je aktualizował ani czy jest wciąż poprawne.

shadow IT w SaaS

Uprawnienia OAuth dla zapomnianych narzędzi. Deweloper autoryzował zewnętrzne narzędzie do przeglądu kodu, żeby miało dostęp do firmowego GitHuba podczas wersji próbnej. Wersja próbna się skończyła. Narzędzie nigdy nie zostało wdrożone na stałe. Uprawnienie OAuth i jego dostęp do odczytu repozytorium wciąż są aktywne.

Darmowe wersje próbne, które zostały na stałe. Lider zespołu zapisał się do narzędzia do zarządzania projektami na darmowej wersji próbnej, żeby je ocenić. Wersja próbna przeszła w darmowy plan. Miesiące później zespół wciąż go używa. Trzyma dane zadań, notatki wewnętrzne i połączenie z systemami firmowymi. IT nigdy go nie przejrzało.

Zdublowane narzędzia w różnych zespołach. Dwa zespoły niezależnie wdrożyły narzędzia pełniące tę samą funkcję. Oba mają połączenia OAuth z firmowym katalogiem. Jedno jest na zatwierdzonej liście. Drugie wdrożył zespół, który nie wiedział, że zatwierdzona wersja w ogóle istnieje.

Integracja zbudowana przez byłego pracownika. Wewnętrzny konektor pobiera dane z dwóch systemów firmowych i łączy je we wspólnym dashboardzie. Osoba, która go zbudowała, odeszła. Integracja wciąż działa, wciąż ma dostęp OAuth do obu systemów źródłowych, a nikt obecnie zatrudniony nie wie, jak działa ani kto jest jej właścicielem.

Aplikacje SaaS połączone z IdP do SSO bez przeglądu bezpieczeństwa. Aplikacja poprosiła o konfigurację SSO, żeby pracownicy mogli używać firmowego loginu. IT dodało to połączenie dla wygody. Aplikacja nigdy nie została formalnie oceniona, a dane, które przechowuje, nigdy nie zostały sklasyfikowane.

shadow IT w AI

Prywatne konta AI używane do zadań służbowych. Pracownicy używają prywatnych kont AI do pisania wewnętrznej komunikacji, streszczania notatek ze spotkań i wspomagania pisania dokumentów. Dokumenty i notatki zawierają poufne informacje firmowe. Nie ma podpisanej umowy powierzenia przetwarzania. Obowiązują warunki obsługi danych właściwe dla kont konsumenckich.

Rozszerzenia przeglądarki AI z dostępem do skrzynki. Rozszerzenie do produktywności mailowej jest zainstalowane w przeglądarkach kilku pracowników. Dostało uprawnienie do odczytu i tworzenia e-maili. Przetwarza treść wiadomości, żeby generować streszczenia i sugerowane odpowiedzi. IT nie zostało poinformowane o jego instalacji. Sposób obchodzenia się z danymi przez dostawcę rozszerzenia nigdy nie został sprawdzony.

Narzędzia AI z klauzulami treningowymi na przesyłanych danych. Zespół wdrożył narzędzie AI do pisania, które zgodnie z regulaminem może wykorzystywać przesłaną treść do ulepszania swoich modeli. Regulamin nie został sprawdzony przy wdrożeniu. Wewnętrzne dokumenty przesłane do narzędzia mogą być użyte poza zadeklarowanym celem.

Konektory AI pobierające wewnętrzne dokumenty. Zespół połączył przestrzeń roboczą Notion albo magazyn dokumentów z asystentem AI, żeby ten mógł odpowiadać na pytania o wewnętrzną treść. Konektor ma dostęp do odczytu połączonego magazynu dokumentów. Zakres tego dostępu okazał się szerszy niż zamierzony i nie został sprawdzony przed konfiguracją.

Microsoft wskazuje, że 78% osób korzystających z AI w pracy używa własnych narzędzi (Microsoft, 2024), a w większości środowisk przynajmniej część tego użycia wiąże się z przepływami danych, których nikt nie sprawdził.