Każda organizacja wie, że ma „shadow IT”. Liczba ta uwydatnia problem: większość organizacji korzysta z ponad 1,000 aplikacji chmurowych, a dział IT zazwyczaj ma wgląd w mniej niż 10% z nich. Duże przedsiębiorstwa korzystają średnio z 473 aplikacji SaaS; dział IT bezpośrednio zarządza jedynie niewielką ich częścią. Osiemdziesiąt procent pracowników korzysta z nieautoryzowanych aplikacji do wykonywania swojej pracy. Liczby te są spójne w każdym badaniu, ponieważ odzwierciedlają spójną dynamikę: pracownicy i jednostki biznesowe wdrażają narzędzia, które rozwiązują bieżące problemy szybciej, niż procesy zarządzania IT są w stanie je ocenić i zatwierdzić.
Dyskusja na temat shadow IT w 2026 roku jest zdominowana przez narzędzia SaaS Discovery, które skanują logi DNS, analizują tokeny SSO OAuth, audytują raporty wydatków i odciski palców ruchu sieciowego, aby znaleźć aplikacje chmurowe używane przez pracowników bez autoryzacji. Narzędzia te rozwiązują problem w warstwie SaaS i robią to całkiem dobrze. Nie rozwiązują jednak, i żadne narzędzie SaaS Discovery nie rozwiązuje, innego problemu shadow IT: aplikacji tworzonych na zamówienie, nieudokumentowanych programów wsadowych, nieformalnych potoków danych i programów narzędziowych ghost, które istnieją w portfolio aplikacji korporacyjnych i nigdy nie pojawiły się w żadnym systemie zarządzania zasobami, dzienniku zmian ani inwentaryzacji IT. Nie są to aplikacje chmurowe wdrażane przez pracowników. Są to programy produkcyjne, działające na komputerach mainframe i systemach klasy midrange, realizujące krytyczne dla biznesu funkcje, których organizacje, które je posiadają, nie mogą w pełni uwzględnić.
Te dwa problemy wymagają różnych podejść do wykrywania. Problem „shadow IT” w SaaS wymaga widoczności sieci i integracji tożsamości. Problem „shadow IT” na poziomie kodu wymaga analizy rzeczywistych artefaktów oprogramowania, kodu źródłowego, bibliotek ładowania i strumieni zadań JCL, aby określić, jakie programy istnieją i do czego służą. Niniejszy przewodnik obejmuje oba te problemy, ze szczególnym uwzględnieniem drugiej kategorii, której nie omówiono w pozostałych publikacjach.
Dwa problemy związane z cieniem IT
Shadow IT jest zazwyczaj definiowane jako technologia wykorzystywana w organizacji bez wyraźnej zgody lub wiedzy działu IT. Definicja ta obejmuje dwa zasadniczo różne zjawiska, które wymagają odmiennych podejść do wykrywania i odmiennych reakcji zarządczych.
Narzędzia Shadow SaaS i chmurowe to aplikacje i usługi wdrażane przez pracowników lub jednostki biznesowe bez formalnego procesu zakupów IT. Zespół marketingowy korzystający z niezatwierdzonego narzędzia do pisania aplikacji AI. Zespół finansowy udostępniający arkusze kalkulacyjne za pośrednictwem osobistego konta Dropbox. Programista korzystający z nieautoryzowanego asystenta kodowania AI, który wysyła zastrzeżony kod źródłowy do zewnętrznego interfejsu API. Aplikacje te istnieją poza infrastrukturą organizacji i można je wykryć za pomocą sygnałów zewnętrznych: zapytań DNS, autoryzacji OAuth, pozycji w raportach wydatków, odcisków palców ruchu sieciowego.
Oprogramowanie aplikacji typu shadow , kategoria, na której koncentruje się niniejszy artykuł, to niestandardowe programy i procesy wsadowe, które zostały stworzone w ramach infrastruktury organizacji i nigdy nie zostały odpowiednio udokumentowane, zinwentaryzowane ani objęte nadzorem. Program w języku COBOL napisany przez programistę z działu finansowego w 1994 roku w celu obsługi konkretnego przypadku skrajnego obliczenia podatku. Program RPG stworzony przez analityka biznesowego w celu generowania plików EDI dla konkretnego partnera handlowego. Zadanie JCL, uruchamiane co miesiąc i generujące raport regulacyjny, od którego zależy zespół ds. zgodności, stworzone przez podwykonawcę, który odszedł z organizacji w 2009 roku. Narzędzie Java napisane „tymczasowo” podczas projektu integracji systemów w 2018 roku, które stało się trwałym elementem zależnym, mimo że nikt nie zdecydował, że powinno.
Programy te nie są widoczne w logach DNS, ponieważ działają w infrastrukturze wewnętrznej. Nie pojawiają się w rekordach autoryzacji OAuth, ponieważ są starsze niż OAuth. Nie ma ich w oficjalnym spisie aplikacji, ponieważ nigdy nie zostały formalnie zgłoszone do przeglądu nadzoru IT. Można je wykryć jedynie poprzez analizę samej infrastruktury, bibliotek ładowania, repozytoriów kodu źródłowego, harmonogramów zadań i logów wykonania, które ujawniają, jakie oprogramowanie faktycznie działa w danym środowisku.
Powód, dla którego ma to znaczenie, wykraczający poza kompletność inwentaryzacji: 74% organizacji doświadczyło incydentów bezpieczeństwa z powodu nieznanych lub niezarządzanych zasobów. Oprogramowanie aplikacji typu shadow stanowi kategorię nieznanych zasobów, których nie są w stanie wykryć ani narzędzia do wyszukiwania oparte na sieci, ani platformy widoczności SaaS.
Dlaczego oprogramowanie aplikacji Shadow się kumuluje
Zrozumienie przyczyn rozprzestrzeniania się nieudokumentowanych, niestandardowych aplikacji w środowiskach korporacyjnych wyjaśnia, dlaczego standardowe procesy zarządzania nie są w stanie temu zapobiec i dlaczego konieczne jest retrospektywne wykrywanie.
Natychmiastowe rozwiązanie jest koniecznością. Jednostki biznesowe borykają się z konkretnymi problemami operacyjnymi, które wymagają konkretnych rozwiązań. Zatwierdzona aplikacja nie obsługuje przypadku brzegowego. Kolejka zgłoszeń IT jest ograniczona przez zaległości. Programista, czasami w dziale IT, czasami w zespole biznesowym, opracowuje rozwiązanie, które działa. Rozwiązanie zostaje uruchomione, rozwiązuje problem i staje się częścią operacyjnego przepływu pracy. Formalny proces zarządzania nigdy nie ma miejsca, ponieważ problem jest już rozwiązany.
Wzorzec „tymczasowości, która stała się trwała”. Najbardziej podstępna forma oprogramowania typu shadow application zaczyna się jako jawnie tymczasowe rozwiązanie. „Tylko do czasu, aż prawdziwy system będzie gotowy”. „Szybkie obejście problemu z formatem danych”. „Tymczasowe, dopóki nie naprawimy API przez dostawcę”. Rozwiązania tymczasowe stają się trwałe, gdy zależności, które się wokół nich kumulują, nigdy nie są demontowane. Poprawka do obliczania daty w języku COBOL, napisana na potrzeby naprawy Y2K, która wciąż jest wywoływana dwadzieścia pięć lat później, ponieważ żaden późniejszy programista nie wiedział, dlaczego istnieje ani czy można ją bezpiecznie usunąć. „Tymczasowy” skrypt normalizacji bazy danych, który stał się częścią nocnego wsadu, ponieważ aplikacja docelowa nigdy nie została faktycznie skompilowana.
Niepowodzenie transferu wiedzy. Aplikacje typu shadow, tworzone przez konkretne osoby, opuszczają udokumentowaną wiedzę organizacji, gdy te osoby odchodzą. Program nadal działa, jest osadzony w procesach produkcyjnych, które od niego zależą, ale nie istnieje żadna dokumentacja, nie ma przypisanego właściciela i nikt nie wie wystarczająco szczegółowo, co robi, aby móc to bezpiecznie zmienić. Staje się duchem w środowisku produkcyjnym: widocznym w swoich efektach, niewidocznym w zarządzaniu.
Cienisty potok danych. Integracja danych to szczególnie podatny grunt dla nieudokumentowanego, niestandardowego oprogramowania. Gdy oficjalna warstwa ETL nie obsługuje wymaganej transformacji lub gdy proces biznesowy wymaga szybszego przepływu danych między systemami niż pozwala na to oficjalny proces integracji, programiści tworzą nieoficjalne programy do przenoszenia danych. Skrypt w Pythonie, który wysyła zapytanie do produkcyjnej bazy danych i zapisuje wyniki na dysku współdzielonym, z którego korzysta proces podrzędny. Program w COBOL-u, który odczytuje dane z systemu mainframe DB2 i zapisuje je do pliku płaskiego, który jest pobierany przez aplikację chmurową. Te nieoficjalne potoki danych przekraczają granice systemowe, obsługują potencjalnie wrażliwe dane i działają całkowicie poza ramami zarządzania integracją.
Cztery kategorie oprogramowania aplikacji typu Shadow
Kategoria 1: Aplikacje niestandardowe dla jednostek biznesowych
Programy tworzone przez programistów działających w działach biznesowych, finansach, zaopatrzeniu, operacjach i compliance, które rozwiązują problemy związane z konkretną dziedziną. Programy te zazwyczaj:
- Są nazywane nieformalnie (TAXCALC, VENDREPT, ADJBATCH) bez przestrzegania konwencji nazewnictwa korporacyjnego
- Przechowuj w katalogach lub bibliotekach zarządzanych przez jednostkę biznesową, a nie przez dział IT
- Nie ma wpisu w bazie danych zarządzania konfiguracją (CMDB)
- Nie ma przypisanego właściciela technicznego w systemie zarządzania usługami IT
- Brak formalnej dokumentacji, pokrycia testami i historii kontroli zmian
Ich krytyczność jest często niedoceniana, ponieważ jednostka biznesowa wie, do czego służy program i uważa go za „swoją własność”. Dział IT, który nie wie o istnieniu programu, nie może ocenić jego krytyczności. Brak programu w inwentarzu aplikacji IT oznacza, że nie jest on uwzględniany w planie ciągłości działania (BCP), planowaniu odzyskiwania po awarii, ocenach bezpieczeństwa i zakresie programu modernizacji.
Kategoria 2: Programy widmo
Programy, które pojawiają się w środowisku produkcyjnym, ale których pochodzenie, cel i właściciel są nieznane obecnej organizacji. Istnieją w bibliotekach wczytywania i repozytoriach źródłowych, są wywoływane przez inne programy lub zadania JCL, generują wyniki, od których zależą procesy niższego rzędu, ale pamięć organizacji o tym, dlaczego istnieją i kto jest za nie odpowiedzialny, została utracona.
Programy widmo są szczególnie niebezpieczne z punktu widzenia bezpieczeństwa i zgodności, ponieważ nie można ich weryfikować pod kątem zgodności z obowiązującymi standardami, nie można ich uwzględniać w programach skanowania w poszukiwaniu luk w zabezpieczeniach wymagających przypisania własności aplikacji ani nie można ich oceniać pod kątem zgodności z przepisami, ponieważ nikt nie wie, do jakich danych mają dostęp ani jaką funkcję biznesową pełnią.
Kategoria 3: Cienie danych
Nieoficjalne programy, które przesyłają dane między systemami poza zatwierdzoną architekturą integracji. Obejmują one zarówno zaawansowane alternatywy ETL, jak i proste skrypty do przesyłania plików:
pyton
# Typical shadow data pipeline -- production database to shared storage
# Written 2021, "temporary until the API is ready"
# Still running daily as of 2026, owner left organization 2022
import pyodbc, shutil
from pathlib import Path
conn = pyodbc.connect('DSN=PROD_BILLING;UID=svcacct;PWD=...') # hardcoded creds
cursor = conn.execute("SELECT * FROM BILLING_RECORDS WHERE STATUS = 'PENDING'")
rows = cursor.fetchall()
# Write to shared drive that Finance picks up
output_path = Path(r'\\FILESERVER01\Finance\billing_export.csv')
with output_path.open('w') as f:
for row in rows:
f.write(','.join(str(v) for v in row) + '\n')
shutil.copy(output_path, Path(r'\\ARCHIVE\billing\') / f"billing_{date.today()}.csv")Ten program, będący reprezentatywnym przykładem wzorca występującego w środowiskach korporacyjnych, wykorzystuje zakodowane na stałe dane uwierzytelniające produkcyjnej bazy danych, zapisuje poufne dane rozliczeniowe we współdzielonej lokalizacji sieciowej bez szyfrowania i działa bez monitorowania od lat po odejściu autora z organizacji. Nie pojawiłby się w żadnym narzędziu do wykrywania SaaS, ponieważ działa w infrastrukturze wewnętrznej. Nie pojawiłby się również w analizie ruchu sieciowego, ponieważ korzysta ze standardowych protokołów baz danych, które nie generują rozpoznawalnego podpisu. Jest widoczny tylko w samym kodzie źródłowym.
Kategoria 4: Nieudokumentowane zadania wsadowe
Strumienie zadań JCL i zaplanowane programy, które działają w infrastrukturze produkcyjnej, ale nie występują w oficjalnej dokumentacji harmonogramu zadań. Kumulują się one poprzez:
- Zadania przesłane poza standardowym harmonogramem zadań poprzez bezpośrednie przesłanie
- Programy wywoływane dynamicznie z innych programów (i dlatego niewidoczne niezależnie w inwentarzach harmonogramu)
- Zadania wykonywane rzadko, na koniec miesiąca, na koniec roku lub tylko wtedy, gdy występują określone warunki biznesowe i nigdy nie zostały ujęte w rutynowych audytach zapasów
- Zadania odziedziczone po poprzednich systemach, które zostały „przeniesione”, ale nigdy formalnie nie wycofane z eksploatacji
Nieudokumentowane zadania wsadowe stają się krytycznymi punktami awarii, gdy:
- Okno konserwacyjne ma wpływ na system, na którym działają, a nikt nie wie, że należy powiadomić o tym jednostkę biznesową zależną od ich wyników
- Przeprowadzana jest ocena bezpieczeństwa, a te zadania są uruchamiane jako niemonitorowane konta usługowe z podwyższonymi uprawnieniami
- Program modernizacji ustala zakres migracji na podstawie udokumentowanego harmonogramu zadań i dociera do środowiska docelowego bez krytycznego przetwarzania wsadowego
Metody odkrywania według kategorii oprogramowania Shadow
Metody wykrywania właściwe dla SaaS shadow IT są w dużej mierze nieodpowiednie dla oprogramowania aplikacji shadow. Wymagane metody to:
Analiza bibliotek ładowania. Każdy program, który kiedykolwiek został skompilowany i wdrożony w systemie mainframe lub midrange, znajduje się w bibliotece ładowania, czyli repozytorium plików wykonywalnych. Porównanie programów w bibliotece ładowania z programami w oficjalnym spisie aplikacji ujawnia lukę: każdy moduł ładowania, który pojawia się w bibliotece, ale nie znajduje się w spisie, jest programem ukrytym. Ta analiza nie wymaga kodu źródłowego, działa na skompilowanych plikach wykonywalnych i ich metadanych.
Przeglądanie repozytorium kodu źródłowego. Repozytoria kodu źródłowego (pliki źródłowe COBOL PDS, repozytoria Git, biblioteki źródłowe RPG) zawierają wszystkie programy, które kiedykolwiek powstały, w tym programy napisane nieformalnie, wdrożone nieformalnie i nigdy nie zarejestrowane w systemach zarządzania IT. Przeglądanie pełnego repozytorium kodu źródłowego w bazie CMDB ujawnia programy, które istnieją w kodzie źródłowym, ale nie są objęte żadnym rekordem zarządzania.
Uzgadnianie JCL i harmonogramu. Każdy strumień zadań JCL wykonywany w środowisku produkcyjnym, niezależnie od tego, czy został przesłany za pośrednictwem oficjalnego harmonogramu, ręcznie, czy wywołany przez inne zadanie, pozostawia ślad w dzienniku wykonania zadania (JESLOG, SYSLOG). Porównanie programów pojawiających się w dziennikach wykonania w środowisku produkcyjnym z programami w oficjalnym spisie pozwala zidentyfikować programy działające w środowisku produkcyjnym bez pokrycia w zarządzaniu.
Dynamiczna analiza CALL. Programy, które dynamicznie wywołują inne programy, gdzie nazwa wywoływanego programu jest ustalana w czasie wykonywania, a nie w momencie kompilacji, tworzą zależności niewidoczne dla analizy statycznego harmonogramu. Dynamiczna analiza CALL śledzi, które programy wydają instrukcje CALL ze zmiennymi nazwami programów, identyfikuje zakres programów, które mogą zostać wywołane, oraz oznacza programy osiągalne za pomocą dynamicznego rozsyłania, które mogą nie występować na żadnej statycznej mapie zależności.
Śledzenie przepływu danych. Potoki danych typu shadow można wykryć poprzez analizę wzorców dostępu do systemu plików i bazy danych: które programy odczytują lub zapisują dane do których zestawów danych, plików lub tabel bazy danych. Program, który odczytuje dane z produkcyjnej bazy danych i zapisuje je do ścieżki pliku poza standardową hierarchią zarządzania danymi, jest kandydatem na potok typu shadow.
Wymiar Sztucznej Inteligencji Cienia
W 2026 roku problem cienia IT rozszerzy się o sztuczną inteligencję (shadow AI), czyli pracowników i jednostki biznesowe korzystające z narzędzi i agentów AI bez autoryzacji IT. Według raportu IBM „Koszt naruszenia danych” z 2026 roku, 43% incydentów bezpieczeństwa dotyczy pracowników korzystających z cienia AI. Gartner przewiduje, że do 2030 roku ponad 40% przedsiębiorstw doświadczy incydentu bezpieczeństwa lub niezgodności z przepisami związanego z nieautoryzowanym cieniem AI.
Specyficzne ryzyko, jakie niesie ze sobą sztuczna inteligencja typu shadow AI, jest bezpośrednio związane z cieniem IT na poziomie kodu: zastrzeżony kod źródłowy trafia do asystentów kodowania AI. Pracownik, który korzysta z nieautoryzowanego asystenta kodowania AI do pomocy w starszym programie COBOL, przesłał kod źródłowy tego programu zewnętrznemu dostawcy AI. Kod źródłowy może zawierać zakodowane na stałe dane uwierzytelniające, logikę biznesową stanowiącą tajemnicę handlową lub struktury danych, których ujawnienie narusza wymogi dotyczące rezydencji danych. Metodą wykrywania tego konkretnego ryzyka nie jest analiza ruchu sieciowego, lecz wykrywanie, do których programów uzyskano dostęp za pomocą narzędzi komunikujących się z zewnętrznymi interfejsami API AI, co wymaga monitorowania na poziomie aplikacji, a nie sieci.
Problem sztucznej inteligencji (Shadow AI) i problem oprogramowania aplikacji (Shadow Application Software) mają wspólną, istotną cechę: oba są niewidoczne dla narzędzi do wykrywania opartych na sieci, które dominują na rynku rozwiązań SaaS w obszarze technologii informatycznych typu shadow IT. Oba wymagają monitorowania na poziomie aplikacji lub analizy strukturalnej kodu, aby się ujawnić.
Budowanie kompletnego inwentarza aplikacji
Wynikiem programu wykrywania ukrytego IT w zakresie oprogramowania aplikacji korporacyjnych jest uzgodniony inwentarz obejmujący cztery populacje:
Znane i udokumentowane: Programy, które pojawiają się zarówno w oficjalnym inwentarzu, jak i w rzeczywistym środowisku produkcyjnym. Programy te mają zapewniony nadzór, przypisanych właścicieli, historię kontroli zmian i plany odzyskiwania po awarii.
Znane, ale niewdrożone: Programy, które pojawiają się w oficjalnym inwentarzu, ale nie można ich znaleźć w bibliotekach wczytywania ani w dziennikach wykonania produkcyjnego. Są to programy przeznaczone do wycofania z eksploatacji, mogły zostać wycofane z eksploatacji bez formalnego wycofania lub mogą być nieprawidłowo wymienione.
Nieznane, ale wdrożone (programy typu shadow): Programy, które pojawiają się w dziennikach wykonania produkcyjnego lub bibliotekach ładowania, ale nie mają wpisu w oficjalnym spisie. Są to główne ustalenia dotyczące shadow IT, programy wymagające natychmiastowego przypisania własności, oceny bezpieczeństwa i rejestracji w systemie zarządzania.
Nieudokumentowane zależności: Programy, które nie pojawiają się ani w oficjalnym inwentarzu, ani w głównych dziennikach wykonania produkcyjnego, ale są odkrywane poprzez dynamiczną analizę CALL lub śledzenie przepływu danych jako dostępne z procesów produkcyjnych. Są to programy-widma, najtrudniejsze do znalezienia i najbardziej niebezpieczne do pozostawienia nieodkrytymi.
Pojednanie między tymi czterema grupami ludności skutkuje stworzeniem planu działania, który obejmuje rejestrację programów obserwowanych, ocenę ich stanu bezpieczeństwa, przypisanie odpowiedzialności oraz ustalenie sposobu ich wykorzystania, zarządzanie i utrzymanie, modernizację lub wycofanie.
W jaki sposób SMART TS XL Wykonuje wykrywanie cieni IT na poziomie kodu
SMART TS XLPodejście firmy do wykrywania ukrytych zasobów informatycznych obejmuje kategorie na poziomie kodu, do których nie są w stanie dotrzeć narzędzia sieciowe.
Możliwość statycznej analizy kodu rozpoczyna się od pełnego przeszukania repozytorium źródłowego: każdy program COBOL, moduł RPG, aplikacja PL/I, usługa Java, skrypt Pythona i strumień zadań JCL w środowisku jest katalogowany wraz z lokalizacją źródłową, językiem, rozmiarem i wstępnym profilem złożoności. Ten inwentarz stanowi punkt odniesienia, z którym porównywane są dane z bazy CMDB i oficjalnego rejestru aplikacji. Programy, które pojawiają się w repozytorium źródłowym, ale nie w oficjalnym inwentarzu, stanowią podstawowe wyniki wyszukiwania aplikacji ukrytych.
Mapowanie zależności aplikacji rozwiązuje problem dynamicznego wywołania CALL: śledząc każdą instrukcję CALL w każdym programie, w tym wywołania dynamiczne, w których nazwa programu jest zmienną, mapa zależności identyfikuje programy dostępne z procesów produkcyjnych, nawet jeśli nigdy nie pojawiają się w statycznych inwentarzach harmonogramów. Program-widmo, który jest wywoływany dynamicznie przez dziesięć programów produkcyjnych, pojawia się w mapie zależności, nawet jeśli nie ma niezależnej definicji zadania JCL.
Funkcja rozszerzenia JCL śledzi cały łańcuch wykonania każdego strumienia zadań JCL: rozwiązuje odwołania do procedur (PROC), rozszerza parametry symboliczne i buduje pełną mapę programów wywoływanych przez każde zadanie. Po porównaniu tej mapy z oficjalną dokumentacją harmonogramu zadań, zadania i programy uruchamiane w środowisku produkcyjnym bez dokumentacji są automatycznie wyświetlane.
Możliwość analizy wpływu umożliwia wdrożenie ustaleń z odkryć: dla każdego wykrytego programu typu shadow należy wyliczyć wszystkie procesy produkcyjne, które od niego zależą. Program typu shadow bez elementów zależnych to kandydat na martwy kod, który można bezpiecznie wycofać. Program typu shadow z dwudziestoma elementami zależnymi to krytyczny, nieudokumentowany zasób, który wymaga natychmiastowej uwagi ze strony organów zarządzających. Zakres wpływu decyduje o priorytecie działań naprawczych.
Funkcja wyszukiwania w przedsiębiorstwie umożliwia wyszukiwanie w całym inwentarzu: znajdź każdy program uzyskujący dostęp do określonego zestawu danych (potencjalni kandydaci do shadow data pipeline), każdy program napisany po określonej dacie, który nie ma wpisu w CMDB (ostatnie aplikacje shadow), każdy program zapisujący dane do zewnętrznych ścieżek plików poza standardową hierarchią zarządzania danymi. Ta funkcja wyszukiwania obsługuje zarówno początkowe wyszukiwanie, jak i ciągłe monitorowanie, które zapobiega ponownemu gromadzeniu się aplikacji shadow po początkowym czyszczeniu.
W organizacjach prowadzących programy modernizacji starszych systemów , wykrywanie aplikacji w tle jest krokiem koniecznym. Program modernizacji, który określa zakres migracji na podstawie oficjalnego spisu aplikacji i wykrywa programy w tle w trakcie realizacji, to program modernizacji, którego zakres, harmonogram i budżet były błędne w momencie podejmowania decyzji. Odkrywanie, które powinno nastąpić przed planowaniem, odbywa się teraz w trakcie realizacji, kiedy jego koszty są najwyższe.
Reakcja rządu: nie blokowanie, ale widoczność
Organizacje, które skutecznie zarządzają shadow IT w 2026 roku, przekonały się, że całkowity zakaz nie działa i tworzy nieuczciwe zachęty. Raportowanie shadow IT zawodzi w większości organizacji z jednego powodu: pracownicy oczekują kary. Gdy członek zespołu finansowego korzysta z niezatwierdzonego narzędzia do śledzenia wydatków i sam to zgłasza, zespół ds. bezpieczeństwa, który reaguje naganą, przeszkolił tego pracownika i wszystkich, z którymi rozmawia, aby następnym razem zachowali milczenie.
Ta sama zasada dotyczy oprogramowania aplikacji ukrytych. Programista, który stworzył krytyczne dla biznesu narzędzie w języku COBOL, od którego zależy organizacja, nie powinien być karany za nieprzeprowadzenie procesu zarządzania, który mógł nie zostać jasno zakomunikowany w danym momencie. Reakcja zarządzania na wykrycie aplikacji ukrytych powinna być następująca:
Rejestracja, a nie usunięcie. Programy typu shadow, które znajdują się na ścieżce krytycznej procesów biznesowych, nie są programami typu shadow, które należy usunąć, lecz nieudokumentowanymi aplikacjami produkcyjnymi, które wymagają nadzoru. Należy je zarejestrować, przypisać właścicieli, ocenić ich poziom bezpieczeństwa i traktować z taką samą dyscypliną nadzoru, jak każdą inną aplikację produkcyjną.
Amnestia dla ujawniania informacji. Program zarządzania, który tworzy bezpieczne kanały dla jednostek biznesowych do ujawniania nieformalnych aplikacji, które stworzyły, ujawnia ukryte oprogramowanie szybciej niż jakiekolwiek inne podejście do ujawniania informacji technicznych. Zapewnienie, że ujawnienie informacji prowadzi do wsparcia ze strony organów zarządzających, pomocy w dokumentacji, kontroli bezpieczeństwa i formalnej rejestracji, a nie do reakcji dyscyplinarnej, eliminuje motywację do ukrywania informacji.
Zapobieganie poprzez proces. Podstawową przyczyną gromadzenia się aplikacji typu shadow jest tarcie w zarządzaniu: oficjalny proces wnioskowania o rozwój nowych aplikacji jest wolniejszy niż wymaga tego problem biznesowy. Zmniejszenie tego tarcia, uproszczone zarządzanie szybkim rozwojem, wbudowane wsparcie zarządzania IT w jednostkach biznesowych, usprawnione zatwierdzanie wewnętrznych narzędzi niskiego ryzyka, zmniejszają tempo tworzenia nowych aplikacji typu shadow bez konieczności ciągłego badania technicznego.
Zapasy, które myślisz, że posiadasz, nie są tymi, które posiadasz
Różnica między inwentarzem aplikacji utrzymywanym przez dział IT a oprogramowaniem aplikacyjnym faktycznie działającym w środowiskach korporacyjnych nie jest niewielka. W dużych organizacjach, w których aplikacje gromadzone są od dziesięcioleci, różnica między udokumentowanymi a rzeczywistymi programami może sięgać trzydziestu procent całkowitej liczby programów. Te trzydzieści procent nieudokumentowanych obejmuje programy przetwarzające poufne dane, realizujące funkcje zgodności z przepisami, znajdujące się na krytycznej ścieżce procesów biznesowych i zawierające luki w zabezpieczeniach, których nikt nie sprawdził, ponieważ nikt nie wiedział, jak je sprawdzić.
Narzędzia do wykrywania cieni IT SaaS skutecznie rozwiązują problem warstwy chmurowej. Problem cienia IT na poziomie kodu, niestandardowe programy, narzędzia ghost tools, nieformalne potoki danych i nieudokumentowane zadania wsadowe, które wypełniają starsze środowiska przedsiębiorstw, wymagają innego podejścia: analizy strukturalnej rzeczywistych artefaktów oprogramowania, a nie monitorowania ruchu sieciowego. Inwentaryzacja uzyskana w wyniku tej analizy często zaskakuje swoją kompletnością. Organizacje, które podejmują się tego zadania, stale odkrywają, że to, co wydawało im się, że działa w środowisku produkcyjnym, a to, co faktycznie działa, to dwie zasadniczo różne rzeczy. Zniwelowanie tej luki stanowi fundament każdego programu zarządzania, bezpieczeństwa, planu ciągłości działania (BCP) i modernizacji, który opiera się na wiedzy o tym, co organizacja faktycznie obsługuje.
