Каждая организация знает о существовании теневых ИТ. Цифра, которая наглядно демонстрирует проблему: большинство организаций используют более 1,000 облачных приложений, и ИТ-отдел, как правило, имеет доступ лишь к менее чем 10 процентам из них. Крупные предприятия в среднем используют 473 SaaS-приложения; ИТ-отдел напрямую управляет лишь их частью. Восемьдесят процентов сотрудников используют несанкционированные приложения для выполнения своей работы. Эти цифры остаются неизменными во всех исследованиях, поскольку отражаемая ими динамика также остается неизменной: сотрудники и бизнес-подразделения внедряют инструменты, которые решают насущные проблемы быстрее, чем процессы управления ИТ-инфраструктурой могут их оценить и утвердить.
В 2026 году в дискуссии о теневых ИТ доминируют инструменты обнаружения SaaS-приложений, которые сканируют журналы DNS, анализируют токены SSO OAuth, проверяют отчеты о расходах и идентифицируют сетевой трафик, чтобы найти облачные приложения, используемые сотрудниками без разрешения. Эти инструменты решают проблему на уровне SaaS, и решают ее достаточно хорошо. Чего они не решают, и чего не затрагивает ни один инструмент обнаружения SaaS, так это другой проблемы теневых ИТ: приложения, созданные на заказ, недокументированные пакетные программы, неформальные конвейеры данных и «призрачные» утилиты, которые существуют в портфелях корпоративных приложений и никогда не появлялись ни в одной системе управления активами, журнале изменений или ИТ-инвентаризации. Это не облачные приложения, развернутые сотрудниками. Это производственные программы, работающие на мэйнфреймах и системах среднего уровня, выполняющие критически важные для бизнеса функции, за которые организации, владеющие ими, не могут в полной мере отвечать.
Эти две проблемы требуют разных подходов к обнаружению. Проблема теневых ИТ в сфере SaaS требует обеспечения видимости сети и интеграции идентификации. Проблема теневых ИТ на уровне кода требует анализа фактических программных артефактов, исходного кода, библиотек загрузки, потоков заданий JCL для определения того, какие программы существуют и что они делают. Данное руководство охватывает обе категории, уделяя особое внимание второй категории, которая не рассматривалась в остальной части данной области.
Две теневые проблемы в сфере информационных технологий
Теневые ИТ обычно определяются как технологии, используемые внутри организации без явного одобрения или ведома ИТ-отдела. Это определение охватывает два принципиально разных явления, требующих различных подходов к обнаружению и различных мер управления.
Теневые SaaS-приложения и облачные инструменты — это приложения и сервисы, используемые сотрудниками или подразделениями компании без формального оформления ИТ-закупок. Например, маркетинговая команда, использующая неутвержденный инструмент для написания текстов на основе ИИ. Финансовая команда, обменивающаяся электронными таблицами через личный аккаунт Dropbox. Разработчик, использующий неавторизованного помощника по программированию на основе ИИ, который отправляет проприетарный исходный код во внешний API. Эти приложения существуют вне инфраструктуры организации и обнаруживаются по внешним сигналам: DNS-запросам, авторизации OAuth, позициям отчетов о расходах, отпечаткам сетевого трафика.
Теневое прикладное программное обеспечение , на котором сосредоточена данная статья, — это программы и пакетные процессы, созданные на заказ в рамках собственной инфраструктуры организации и никогда должным образом не документированные, не инвентаризированные и не управляемые. Примером может служить программа на COBOL, написанная разработчиком из финансового отдела в 1994 году для обработки конкретного случая расчета налогов. Примером может служить программа на RPG, созданная бизнес-аналитиком для генерации EDI-файлов для конкретного торгового партнера. Примером может служить задание JCL, которое запускается каждый месяц и формирует нормативный отчет, от которого зависит команда по соблюдению нормативных требований, — программа, созданная подрядчиком, покинувшим организацию в 2009 году. Примером может служить утилита на Java, написанная «временно» во время проекта системной интеграции в 2018 году, которая стала постоянной зависимостью без чьего-либо решения.
Эти программы не отображаются в журналах DNS, поскольку работают на внутренней инфраструктуре. Они не фигурируют в записях авторизации OAuth, поскольку существовали до появления OAuth. Они не включены в официальный реестр приложений, поскольку никогда не были официально представлены на рассмотрение в рамках системы управления ИТ. Их можно обнаружить только путем изучения самой инфраструктуры, библиотек загрузки, репозиториев исходного кода, планировщиков заданий и журналов выполнения, которые показывают, какое программное обеспечение фактически работает в данной среде.
Это важно не только с точки зрения полноты инвентаризации: 74% организаций сталкивались с инцидентами безопасности, вызванными неизвестными или неуправляемыми активами. Теневое программное обеспечение приложений представляет собой категорию неизвестных активов, которые не могут быть обнаружены ни сетевыми инструментами обнаружения, ни платформами мониторинга SaaS.
Почему накапливается теневое прикладное программное обеспечение?
Понимание причин распространения недокументированных пользовательских приложений в корпоративных средах объясняет, почему стандартные процессы управления не способны это предотвратить и почему необходим ретроспективный поиск.
Необходимость немедленного решения. Бизнес-подразделения сталкиваются со специфическими операционными проблемами, требующими специфических решений. Утвержденное приложение не обрабатывает крайние случаи. Очередь запросов в ИТ-отдел ограничена объемом невыполненных задач. Разработчик, иногда работающий в ИТ-отделе, иногда в составе бизнес-команды, пишет работающее решение. Решение запускается, решает проблему и становится частью операционного рабочего процесса. Формальный процесс управления никогда не происходит, потому что проблема уже решена.
Схема «временное, ставшее постоянным». Самая коварная форма теневого программного обеспечения начинается как заведомо временное решение. «Просто пока реальная система не будет готова». «Быстрое обходное решение проблемы с форматом данных». «Временно, пока мы ждем, когда поставщик исправит свой API». Временные решения становятся постоянными, когда зависимости, которые накапливаются вокруг них, никогда не удаляются. Исправление расчета даты на COBOL, написанное для решения проблемы 2000 года, до сих пор называют «проблемой 2500», потому что ни один последующий разработчик не знал, зачем оно существует и безопасно ли его удалять. «Временный» скрипт нормализации базы данных, который стал частью ночного пакета, потому что целевое приложение фактически так и не было собрано.
Неудача в передаче знаний. Теневые приложения, созданные отдельными лицами, оставляют задокументированные знания организации после их ухода. Программа продолжает работать, она встроена в производственные процессы, которые от нее зависят, но никакой документации не существует, права собственности не определены, и никто не знает, что она делает, в достаточной степени, чтобы безопасно вносить в нее изменения. Она становится призраком в производственной среде: видимым по своим последствиям, невидимым с точки зрения управления.
Теневой конвейер данных. Интеграция данных — особенно благодатная почва для недокументированного пользовательского программного обеспечения. Когда официальный слой ETL не поддерживает необходимую трансформацию, или когда бизнес-процесс требует перемещения данных между системами быстрее, чем позволяет официальный процесс интеграции, разработчики создают неофициальные программы для перемещения данных. Например, скрипт на Python, который запрашивает данные из производственной базы данных и записывает результаты на общий диск, который затем обрабатывается нижестоящим процессом. Или программа на COBOL, которая считывает данные из базы данных DB2 на мэйнфрейме и записывает их в плоский файл, который затем обрабатывает облачное приложение. Эти неофициальные конвейеры данных пересекают границы систем, обрабатывают потенциально конфиденциальные данные и работают полностью вне рамок управления интеграцией.
Четыре категории теневого прикладного программного обеспечения
Категория 1: Пользовательские приложения для бизнес-подразделений
Программы, разработанные специалистами, работающими в бизнес-подразделениях, отделах финансов, закупок, операционной деятельности и соблюдения нормативных требований, решают конкретные отраслевые проблемы. Как правило, эти программы:
- Названия даны в неформальном порядке (TAXCALC, VENDREPT, ADJBATCH) без соблюдения корпоративных правил именования.
- Проживайте в справочниках или библиотеках, которыми управляет подразделение компании, а не ИТ-отдел.
- Отсутствует запись в базе данных управления конфигурациями (CMDB)
- В системе управления ИТ-услугами отсутствует назначенный технический ответственный.
- Отсутствие формальной документации, данных о тестовом покрытии и истории изменений в системе управления.
Их важность часто недооценивается, поскольку бизнес-подразделение знает, что делает программа, и считает её «своей». ИТ-организация, которая не знает о существовании программы, не может оценить её важность. Отсутствие программы в перечне приложений ИТ-подразделения означает, что она отсутствует в планах обеспечения непрерывности бизнеса, планах аварийного восстановления, оценках безопасности и в рамках программ модернизации.
Категория 2: Программы-призраки
Программы, которые используются в производственной среде, но происхождение, назначение и владельцы которых неизвестны текущей организации. Они существуют в библиотеках загрузки и репозиториях исходного кода, вызываются другими программами или запускаются заданиями JCL, они производят выходные данные, от которых зависят последующие процессы, но организационная память о том, почему они существуют и кто за них отвечает, утрачена.
Программы-призраки особенно опасны с точки зрения безопасности и соответствия нормативным требованиям, поскольку их невозможно проверить на соответствие действующим стандартам, их нельзя включить в программы сканирования уязвимостей, требующие указания владельца приложения, и их нельзя оценить на соответствие нормативным требованиям, поскольку никто не знает, к каким данным они имеют доступ и какие бизнес-функции выполняют.
Категория 3: Теневые конвейеры обработки данных
Неофициальные программы, перемещающие данные между системами вне утвержденной архитектуры интеграции. К ним относятся как сложные альтернативы ETL, так и простые скрипты для передачи файлов:
питон
# 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")Эта программа, представляющая собой типичный пример использования подобных уязвимостей в корпоративных средах, использует жестко закодированные учетные данные производственной базы данных, записывает конфиденциальные данные для выставления счетов в общедоступное сетевое хранилище без шифрования и работает без мониторинга в течение многих лет после ухода ее автора из организации. Она не будет отображаться ни в одном инструменте обнаружения SaaS-сервисов, поскольку работает на внутренней инфраструктуре. Она также не будет отображаться в результатах анализа сетевого трафика, поскольку использует стандартные протоколы баз данных, которые не создают различимых сигнатур. Она видна только в самом исходном коде.
Категория 4: Недокументированные пакетные задания
Потоки заданий JCL и запланированные программы, которые выполняются на производственной инфраструктуре, но отсутствуют в официальной документации по планированию заданий. Они накапливаются посредством:
- Задания, отправленные вне стандартного планировщика заданий посредством прямой отправки.
- Программы, вызываемые динамически из других программ (и, следовательно, не отображающиеся независимо в инвентаризации планировщика).
- Задачи, которые выполняются нечасто, в конце месяца, в конце года или только при возникновении определенных деловых условий и никогда не отражались в ходе плановых инвентаризационных проверок.
- Задачи, унаследованные от предшествующих систем, которые были «перенесены», но так и не были официально выведены из эксплуатации.
Недокументированные пакетные задания становятся критическими точками отказа, когда:
- Плановое техническое обслуживание влияет на работу системы, и никто не знает, когда нужно уведомить подразделение, зависящее от их результатов.
- Проводится оценка безопасности, и эти задания выполняются от имени неконтролируемых учетных записей служб с повышенными привилегиями.
- Программа модернизации определяет масштаб миграции на основе задокументированного графика выполнения заданий и в итоге в целевой среде отсутствует критически важная пакетная обработка.
Методы обнаружения по категориям теневого программного обеспечения
Методы обнаружения, подходящие для теневых ИТ-систем SaaS, в значительной степени неприменимы к теневому прикладному программному обеспечению. Необходимы следующие методы:
Анализ загрузочной библиотеки. Каждая программа, когда-либо скомпилированная и развернутая на мэйнфрейме или системе среднего уровня, существует в загрузочной библиотеке — репозитории исполняемых файлов. Сравнение программ в загрузочной библиотеке с программами в официальном каталоге приложений выявляет разрыв: каждый загрузочный модуль, который присутствует в библиотеке, но отсутствует в каталоге, является теневой программой. Этот анализ не требует исходного кода, он работает с скомпилированными исполняемыми файлами и их метаданными.
Обход репозитория исходного кода. Репозитории исходного кода (COBOL-репозитории PDS, репозитории Git, библиотеки исходного кода RPG) содержат все когда-либо написанные программы, включая программы, написанные неформально, развернутые неформально и никогда не зарегистрированные в системах управления ИТ. Обход всего репозитория исходного кода по базе данных CMDB выявляет программы, которые существуют в исходном коде, но не имеют записи в системе управления.
Согласование JCL и планировщика. Каждый поток заданий JCL, выполняемый в производственной среде, независимо от того, отправлен ли он через официальный планировщик, отправлен вручную или вызван другим заданием, оставляет след в журнале выполнения заданий (JESLOG, SYSLOG). Сравнение программ, отображаемых в журналах выполнения в производственной среде, с программами в официальном инвентаре позволяет выявить программы, работающие в производственной среде без учета требований к управлению.
Динамический анализ вызовов (CALL). Программы, которые динамически вызывают другие программы, где имя вызываемой программы определяется во время выполнения, а не во время компиляции, создают зависимости, невидимые для статического анализа планировщика. Динамический анализ вызовов отслеживает, какие программы выполняют операторы CALL с переменными именами программ, определяет диапазон программ, которые могут быть вызваны, и помечает программы, доступные через динамическую диспетчеризацию, которые могут не отображаться ни в одной статической карте зависимостей.
Трассировка потока данных. Теневые конвейеры данных можно обнаружить путем анализа шаблонов доступа к файловой системе и базе данных: какие программы читают или записывают данные в какие наборы данных, файлы или таблицы базы данных. Программа, которая читает данные из производственной базы данных и записывает их в файл, находящийся вне стандартной иерархии управления данными, является потенциальным кандидатом на роль теневого конвейера.
Теневое измерение ИИ
Проблема теневых ИТ-технологий к 2026 году будет связана с теневым ИИ, когда сотрудники и бизнес-подразделения используют инструменты и агенты ИИ без разрешения ИТ-отдела. Согласно отчету IBM «Стоимость утечки данных в 2026 году», 43% инцидентов безопасности связаны с использованием теневого ИИ сотрудниками. Gartner прогнозирует, что к 2030 году более 40% предприятий столкнутся с инцидентами безопасности или нарушениями нормативных требований, связанными с несанкционированным использованием теневого ИИ.
Специфический риск, связанный с теневым ИИ, непосредственно применимый к теневым ИТ-системам на уровне кода: использование проприетарного исходного кода в программах-помощниках по программированию на основе ИИ. Сотрудник, использующий неавторизованную программу-помощник по программированию на основе ИИ для работы с устаревшей программой на COBOL, отправляет исходный код этой программы внешнему поставщику ИИ. Исходный код может содержать жестко закодированные учетные данные, бизнес-логику, представляющую собой коммерческую тайну, или структуры данных, раскрытие которых нарушает требования к размещению данных. Метод обнаружения этого специфического риска заключается не в анализе сетевого трафика, а в выявлении программ, к которым обращались инструменты, взаимодействующие с внешними API ИИ, что требует мониторинга на уровне приложений, а не на уровне сети.
Проблема теневого ИИ и проблема теневого прикладного программного обеспечения имеют важную общую черту: обе они невидимы для сетевых инструментов обнаружения, доминирующих на рынке теневых ИТ-решений SaaS. Для выявления обеих требуется либо мониторинг на уровне приложений, либо структурный анализ кода.
Создание полного перечня приложений
Результатом работы программы обнаружения теневых ИТ-систем для корпоративного прикладного программного обеспечения является согласованный перечень, охватывающий четыре группы пользователей:
Известные и задокументированные: Программы, которые фигурируют как в официальном реестре, так и в производственной среде. Эти программы имеют систему управления, назначенных ответственных лиц, историю изменений и планы аварийного восстановления.
Известные, но не используемые программы: программы, которые присутствуют в официальном реестре, но не могут быть найдены в библиотеках загрузки или журналах выполнения в производственной среде. Эти программы могут быть выведены из эксплуатации, возможно, без надлежащего официального уведомления о выводе из эксплуатации, или же они могут быть указаны неверно.
Неизвестные, но развернутые (теневые программы): программы, которые отображаются в журналах выполнения в производственной среде или библиотеках загрузки, но не имеют записи в официальном инвентаре. Это основные признаки теневых ИТ-систем, требующие немедленного назначения ответственного лица, оценки безопасности и регистрации в системе управления.
Недокументированные зависимости: программы, которые не фигурируют ни в официальном инвентаре, ни в основных журналах выполнения производственных процессов, но обнаруживаются в результате динамического анализа вызовов CALL или трассировки потока данных как доступные из производственных процессов. Это так называемые «призрачные программы», которые сложнее всего найти и которые наиболее опасно оставлять необнаруженными.
В результате примирения этих четырех групп населения разрабатывается план действий: регистрация теневых программ, оценка их безопасности, определение собственников и их дальнейшей судьбы, управление и поддержание, модернизация или вывод из эксплуатации.
Как SMART TS XL Выполняет обнаружение теневых ИТ-систем на уровне кода.
SMART TS XLПодход компании к обнаружению теневых ИТ-систем охватывает категории на уровне кода, недоступные для сетевых инструментов.
Возможности статического анализа кода начинаются с полного обхода репозитория исходного кода: каждая программа на COBOL, модуль на RPG, приложение на PL/I, служба на Java, скрипт на Python и поток заданий JCL в среде каталогизируются с указанием местоположения исходного кода, языка, размера и предварительного профиля сложности. Этот перечень является базовым показателем, относительно которого согласовываются CMDB и официальный реестр приложений; программы, которые присутствуют в репозитории исходного кода, но отсутствуют в официальном реестре, являются основным объектом поиска теневых приложений.
Отображение зависимостей приложений решает проблему динамических вызовов: отслеживая каждое оператор CALL в каждой программе, включая динамические вызовы, где имя программы является переменной, карта зависимостей идентифицирует программы, доступные из производственных процессов, даже если они никогда не появляются в статических списках планировщика. Программа-призрак, которая динамически вызывается десятью производственными программами, появляется в карте зависимостей, даже если у нее нет независимого определения задания JCL.
Функция расширения JCL отслеживает полную цепочку выполнения каждого потока заданий JCL: разрешение ссылок на PROC, расширение символических параметров и построение полной карты программ, которые вызывает каждое задание. При сравнении этой карты с официальной документацией по расписанию заданий автоматически выявляются задания и программы, которые выполняются в производственной среде без соответствующей документации.
Возможность анализа воздействия позволяет применять полученные данные на практике: для каждой обнаруженной теневой программы перечисляются все производственные процессы, которые от нее зависят. Теневая программа без зависимых процессов — это потенциальный кандидат на вывод из эксплуатации (мертвый код). Теневая программа с двадцатью зависимыми производственными процессами — это критически важный недокументированный актив, требующий немедленного внимания со стороны органов управления. Приоритетность мер по устранению проблем определяется масштабом воздействия.
Функция корпоративного поиска позволяет запрашивать полный список доступных программ: находить все программы, обращающиеся к определенному набору данных (потенциальные кандидаты на роль теневых конвейеров данных), все программы, написанные после определенной даты и не имеющие записи в CMDB (недавние теневые приложения), все программы, записывающие данные во внешние файловые пути, находящиеся за пределами стандартной иерархии управления данными. Эта функция поиска поддерживает как первоначальное обнаружение, так и текущий мониторинг, предотвращающий возобновление накопления теневых приложений после первоначальной очистки.
Для организаций, проводящих программы модернизации устаревших систем , обнаружение теневых приложений является обязательным этапом. Программа модернизации, в рамках которой миграция планируется на основе официального реестра приложений, а теневые приложения обнаруживаются в процессе выполнения, — это программа модернизации, масштабы, сроки и бюджет которой были изначально неверны. Обнаружение, которое должно было произойти до планирования, теперь происходит во время выполнения, когда его стоимость наиболее высока.
Ответ системы управления: не блокирование, а обеспечение прозрачности.
Организации, эффективно управляющие теневыми ИТ в 2026 году, усвоили, что повсеместный запрет не работает и создает нежелательные стимулы. В большинстве организаций сообщения о теневых ИТ неэффективны по одной причине: сотрудники ожидают наказания. Когда сотрудник финансового отдела использует неутвержденную систему учета расходов и самостоятельно сообщает об этом, команда безопасности, которая реагирует выговором, приучает этого сотрудника и всех, с кем он общается, молчать в следующий раз.
Тот же принцип применим и к теневому прикладному программному обеспечению. Разработчик, создавший критически важную для бизнеса утилиту на COBOL, от которой зависит организация, не должен быть наказан за то, что не прошел процедуру управления, которая, возможно, не была четко доведена до сведения на тот момент. Реакция системы управления на обнаружение теневого приложения должна быть следующей:
Регистрация, а не удаление. Теневые программы, обнаруженные на критически важном пути бизнес-процессов, — это не теневые программы, которые нужно удалять, а недокументированные приложения, используемые в производственной среде и требующие соблюдения правил управления. Зарегистрируйте их, назначьте ответственных лиц, оцените их безопасность и применяйте к ним те же принципы управления, что и к любым другим приложениям, используемым в производственной среде.
Амнистия за самораскрытие. Программа управления, создающая безопасные каналы для раскрытия подразделениями информации о разработанных ими неофициальных приложениях, выявляет скрытое программное обеспечение быстрее, чем любой технический метод обнаружения. Гарантия того, что раскрытие информации приводит к поддержке со стороны руководства, помощи в подготовке документации, проверке безопасности и официальной регистрации, а не к дисциплинарным мерам, устраняет стимул к сокрытию.
Предотвращение посредством оптимизации процессов. Первопричина накопления теневых приложений — это проблемы управления: официальный процесс запроса на разработку новых приложений работает медленнее, чем того требует бизнес-задача. Снижение этих проблем, упрощенное управление быстрой разработкой, встроенная поддержка управления ИТ в бизнес-подразделениях, упрощенное утверждение внутренних инструментов с низким уровнем риска, снижают темпы создания новых теневых приложений без необходимости постоянного технического анализа.
То, что вы считаете имеющимся у вас имуществом, на самом деле таковым не является.
Разница между перечнем приложений, который ведет ИТ-отдел, и фактически работающим в корпоративных средах прикладным программным обеспечением — это немаловажное расхождение. В крупных организациях с многолетним опытом работы с приложениями разрыв между задокументированным и фактическим количеством может достигать тридцати процентов от общего числа программ. К этим тридцати процентам относятся программы, обрабатывающие конфиденциальные данные, выполняющие функции обеспечения соответствия нормативным требованиям, находящиеся на критическом пути бизнес-процессов и содержащие уязвимости безопасности, которые никто не проверял, потому что никто не знал, что их нужно проверять.
Инструменты обнаружения теневых ИТ-систем на уровне SaaS хорошо справляются с проблемой на облачном уровне. Проблема теневых ИТ на уровне кода — пользовательские программы, «призрачные» утилиты, неформальные конвейеры обработки данных и недокументированные пакетные задания, заполняющие устаревшие корпоративные среды, — требует иного подхода: структурного анализа фактических программных артефактов, а не мониторинга сетевого трафика. Инвентаризация, полученная в результате такого анализа, часто поражает своей полнотой. Организации, занимающиеся этой работой, неизменно обнаруживают, что то, что, как им казалось, работало в производственной среде, и то, что работает на самом деле, — это две совершенно разные вещи. Устранение этого разрыва является основой любой программы управления, безопасности, обеспечения непрерывности бизнеса и модернизации, которая зависит от знания того, чем организация фактически управляет.
